Tutorial Web Services (I): Definición de términos

Los Web Services proporcionan operaciones multiplataforma en internet. Los servicios pueden ser accedidos por diferentes plataformas y lenguajes de programación.

Endpoint:
Nombre del host que alberga el web service + nombre del web service.
Si el host fuera http://www.prueba.com y el web service BasicService, la URL completa, es decir, el endpoint sería http://www.prueba.com/BasicService

QName(Qualified name)
El web service puede dar soporte a una o más operaciones. Cada operación debe tener un nombre global único. Para ello, se declara un namespace que es como un paquete en Java pero con formato URL. El QName está formado por el namespace + el nombre de la operación.

RPC style web service
La operación concatenar puede tomar 2 parámetros, "s1" y "s2", ambos tipo String y devuelve como resultado otro String que es la concatenación de ambos parámetros.

Sin embargo, el tipo string debe ser de un lenguaje de programación neutral. Para ello, se usa la especificación XML schema.

En web services la llamada de la operación definida por un web service se denomina "mensaje de entrada" y cada parámetro se denomina "parte". El valor de retorno es el "mensaje de salida" y puede contener múltiples partes. Con estos términos podríamos definir la interface de la operación:

Para invocar esta operación, se podría mandar un elemento XML como mensaje de entrada:

 <foo:concatenar xmlns:foo="http://prueba.com/bs">
     <s1>abc</s1>
     <s2>123</s2>
</foo:concatenar>

El resultado sería un mensaje de salida:

<foo:concatenar xmlns:foo="http://prueba.com/bs">
     <retorno>abc123</retorno>
</foo:concatenar>

Este estilo de web service se llama "RPC Style" web service. Como puede observarse, el QName de la operación y el nombre de las partes se utilizan para crear los mensajes de entrada y salida.

Document style web service

El mensaje de entrada sólo contiene una única parte, que es un elemento definido en un schema. En ese schema, el elemento se llamará concatRequest y tendrá dos elementos hijos: <s1> y <s2>. 

Schema:

<xsd:schema

      targetNamespace="http://ttdev.com/ss"

      xmlns:xsd="http://www.w3.org/2001/XMLSchema">

            <xsd:element name="concatRequest">

                  <xsd:complexType>

                        <xsd:sequence>

                              <xsd:element name="s1" type="xsd:string"/>

                              <xsd:element name="s2" type="xsd:string"/>

                        </xsd:sequence>

                 </xsd:complexType>

            </xsd:element>

</xsd:schema>

El schema se incluye en la interface del web service:

Como puede observarse, una parte (un parámetro) puede ser declarado como un elemento particular (<concatRequest>) definido en un schema o como un elemento con un tipo particular (string definido en la especificación XML schema). En cualquier caso se identifica usando un QName.

 

Cuando alguien invoque la operación, se mandará un mensaje de entrada con un elemento <concatRequest>

<foo:concatRequest xmlns:foo="http://ttdev.com/ss">

      <s1>abc</s1>

      <s2>123</s2>

</foo:concatRequest>

Similarmente, para el mensaje de salida puedes especificar que contendrá una única parte, y que será un elemento <concatResponse> 

<foo:concatResponse xmlns:foo="http://ttdev.com/ss">

    abc123

</foo:concatResponse>

Comparación de los mensajes de entrada en RPC y Document style.

La principal diferencia es que en el estilo RPC no se puede validar contra un schema, mientras que en el estilo Document si. Por esta razón, Document se está convirtiendo en el estilo dominante.

Determinando la operación en un Document Style web service: 

Para invocar una operación en un Document Style web service, se manda una única parte como mensaje de entrada. NUNCA se manda el nombre de la operación en ningún modo. Por lo tanto si hay más de una operación que toma el mismo elemento como mensaje de entrada se producirá un error y el web service no funcionará.

Port type

Las operaciones de un web service se agrupan en uno o más “port types”. El port type es como una clase Java y cada operación es como un método static. El nombre de un port type debe ser un QName.

Binding

Los port types pueden ser accedidos utilizando diferentes formatos de mensaje. Hasta ahora se ha empleado el formato “Simple Object Access Protocol (SOAP)”. Otro tipo de formato podría ser texto plano.

Además del formato del mensaje, un port type puede permitir que el mensaje sea transportado en una petición HTTP POST o en un email. Cada combinación que se soporta se llama “binding”. La combinación más común es SOAP + HTTP.

Port

Supón que hay mucha gente usando el web service y decides hacerlo accesible en más de un computador. Puedes desplegar el binding1 descrito arriba en las computadoras c1, c2 y c3 y desplegar el binding2 en c3. En este caso hay 4 puertos.

En las 3 computadoras habrá instalado cierto software que implementa el port type. No es necesario que sea el mismo software en las 3 computadoras; en c1 puede estar escrito en Java mientras que en c2 puede estar escrito en C#. Lo importante es que deben soportar todas las operaciones descritas en el port type y el formato de mensaje y transporte especificados en el binding.

Los ports se incluyen en la interface del web service.

Target namespace

Hemos empleado el mismo namespace para los nombres de las operaciones, de los port type, etc. Por defecto, todos estos nombres se encuentran en un único namespace, que se denomina “target namespace” del web service. 

El namespace debe ser globalmente único, por ejemplo http://ttdev.com/ss. Este namespace tiene formato URL, puede haber gente que intente acceder a él como a una página web y cuando no funcione, pueden pensar que el web service es incorrecto. Para evitar esta confusión se debe emplear formato URN.

El namespace debe ser una URI. Hay dos tipos de URI (Uniform Resource Identifier). Una es URL como en http://prueba.com. Otra es URN con formato <tipo-objeto>:<id-objeto>

Un namespace en XML debe ser un URI. Puedes usar URL o URN. Por ejemplo, puedes usar urn:ttdev.com:ss como el target namespace del web service en vez de http://ttdev.com/ss sin ningún cambio en la funcionalidad. 

WSDL

Interface del web service. 

Describe completamente el web service. El lenguaje de descripción se llama WSDL (Web Service Description Language).