TCP Y UDP EN JAVA

TCP en Java

Ejemplos Servidor

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.PrintStream;
import java.net.ServerSocket;
import java.net.Socket;

public class Servidor {

    public static void main(String[] args) {

        ServerSocket    s;  //Socket servidor
        Socket      sc;      //Socket cliente

        PrintStream     p;    //Canal de escritura
        BufferedReader  b;      //Canal de Lectura
       
        String    mensaje;
       
        try {
            //Creo el socket server
            s = new ServerSocket(9999);
           
            //Invoco el metodo accept del socket servidor, me devuelve una referencia al socket cliente
            sc = s.accept();
           
            //Obtengo una referencia a los canales de escritura y lectura del socket cliente
            b = new BufferedReader( new InputStreamReader ( sc.getInputStream() ) );
            p = new PrintStream   ( sc.getOutputStream() );

            while ( true ) {
                //Leo lo que escribio el socket cliente en el canal de lectura
                mensaje = b.readLine();
                System.out.println(mensaje);
               
                //Escribo en canal de escritura el mismo mensaje recibido
                p.println(mensaje);

                if ( mensaje.equals("by")) {
                    break;
                }
            }
           
            p.close();
            b.close();
           
            sc.close();
            s.close();
        } catch (IOException e) {
            System.out.println("No puedo crear el socket");
        }
    }

}

Ejemplo Cliente

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.PrintStream;
import java.net.Socket;
import java.net.UnknownHostException;

public class Cliente {

    public static void main(String[] args) {

        Socket      s;
        PrintStream             p;
        BufferedReader    b;

        String          host = "localhost";
        int      port = 9999;
        String          respuesta;

        //Referencia a la entrada por consola (System.in)
        BufferedReader    in = new BufferedReader(new InputStreamReader(System.in));

        try {

            //Creo una conexion al socket servidor
            s = new Socket(host,port);  

            //Creo las referencias al canal de escritura y lectura del socket
            p = new PrintStream(s.getOutputStream());
            b = new BufferedReader ( new InputStreamReader ( s.getInputStream() ) );

            while ( true ) {
                //Ingreso un String por consola 
                System.out.print("Mensaje a enviar: ");

                //Escribo en el canal de escritura del socket
                p.println( in.readLine() );
               
                //Espero la respuesta por el canal de lectura
                respuesta = b.readLine();
                System.out.println(respuesta);
                if ( respuesta.equals("by")) {
                    break;
                }         
            }
            p.close();
            b.close(); 
            s.close();

        } catch (UnknownHostException e) {
            System.out.println("No puedo conectarme a " + host + ":" + port);
        } catch (IOException e) {
            System.out.println("Error de E/S en " + host + ":" + port);
        }
    }
}

UDP en JAVA

UNA PEQUEÑA INTRODUCCIÓN

En los sockets TCP es necesario establecer una conexión. El servidor TCP espera que un cliente TCP se le conecte. Una vez hecha la conexión, se pueden enviar mensajes. El protocolo TCP garantiza que todos los mensajes enviados van a llegar bien y en el orden enviado. Sólo el cliente necesita saber dónde está el servidor y en qué puerto está escuchando.

Por el contrario, en los sockets UDP no se establece conexión. El servidor se pone a la escucha de un puerto de su ordenador. El cliente también se pone a la escucha de un puerto de su ordenador. En cualquier momento, cualquiera de ellos puede enviar un mensaje al otro.  Ambos necesitan saber en qué ordendador y en qué puerto está escuchando el otro. Aquí el concepto de cliente y servidor está un poco más difuso que en el caso de TCP. Podemos considerar servidor al que espera un mensaje y responde. Cliente sería el que inicia el trasiego de mensajes. El servidor debería, además, estar siempre arrancado y a la escucha.

Además, en contra de TCP, el protocolo UDP sólo garantiza que si el mensaje llega, llega bien. No garantiza que llegue ni que lleguen en el mismo orden que se han enviado. Este tipo de sockets es útil para el envío más o menos masivo de información no crucial. Por ejemplo, enviar los datos para el refresco de gráficos en una pantalla.

Otra ventaja de UDP respecto a TCP, es que con UDP se puede enviar un mensaje a varios receptores a la vez, mientras que en TCP, al haber una conexión previa, sólo se puede enviar el mensaje al que está conectado al otro lado. Con UDP se puede, por ejemplo, enviar una sola vez los datos para que varias pantallas refresquen sus gráficos a la vez.

LA CLASE DatagramSocket

Tanto cliente como servidor, para ponerse a la escucha de un puerto UDP, únicamente tienen que instanciar la clase DatagramSocket, pasándole los parámetros adecuados:

• El número de puerto que están escuchando.
• El InetAddress del ordenador en que se está corriendo cada uno, habitualmente InetAddress.getLocalHost();

Por ello, el código del servidor es tan sencillo como esto

ServidorUdp.java

DatagramSocket socket = new DatagramSocket(
   Constantes.PUERTO_DEL_SERVIDOR,
   InetAddress.getByName("localhost"));

y el del cliente se parece bastante

ClienteUdp.java

DatagramSocket socket = new DatagramSocket(
   Constantes.PUERTO_DEL_CLIENTE,
   InetAddress.getByName("localhost"));

LA CLASE DatagramParcket

Esta es la clase que se va a enviar y recibir como mensaje. Lleva dentro un array de bytes que es el que debemos rellenar con lo queremos enviar o en el que estará lo que hemos recibido.

Dependiendo de si es para enviar o recibir, esta clase se instancia de forma distinta. En ambos casos hay que pasarle el array de bytes. En el caso de enviar, hay que pasarle además la InetAdress del destinatario y el puerto en el que está escuchando el destinatario.

Para enviar

DatagramPacket dato = new DatagramPacket(
   elDatoEnBytes, // El array de bytes
   elDatoEnBytes.length, // Su longitud
   InetAddress.getByName(Constantes.HOST_SERVIDOR),  // Destinatario
   Constantes.PUERTO_DEL_SERVIDOR);   // Puerto del destinatario

Para recibir

DatagramPacket dato = new DatagramPacket(new byte[100], 100);

ENVIAR Y RECIBIR LOS DatagramPacket

Para enviar el DatagramPacket, debemos llamar al método send() de DatagramSocket pasando como parámetro el DatagramPacket que acabamos de crear.

Enviar DatagramPacket

socket.send(dato);

Para recibir, igual pero con socket.receive().

Recibir DatagramPacket

socket.receive(dato);

CONVERTIR UNA CLASE Serializable A ARRAY DE BYTES Y VICEVERSA

Lo de meter un array de bytes en el DatagramPacket está muy bien si leemos bytes de un fichero o de algún otro sitio. Sin embargo, si queremos enviar o recibir clases (Serializable, por supuesto), tenemos que hacer una conversión. Los siguientes código nos ayudan a hacer este tipo de conversiones. Suponemos que la clase se llamaDatoUdp y que implenta la interface Serializable.

De Serializable a byte[]

ByteArrayOutputStream bytes = new ByteArrayOutputStream();
ObjectOutputStream os = new ObjectOutputStream (bytes);
os.writeObject(this);  // this es de tipo DatoUdp
os.close();
return bytes.toByteArray(); // devuelve byte[]

De byte[] a Serializable

ByteArrayInputStream byteArray = new ByteArrayInputStream(bytes); // bytes es el byte[]
ObjectInputStream is = new ObjectInputStream(byteArray);
DatoUdp aux = (DatoUdp)is.readObject();
is.close();
return aux;

EL EJEMPLO

Con todo esto ya sabemos lo necesario para hacer un pequeño ejemplo de Servidor udp y cliente udp. Los fuentes del ejemplo los tienes en socketudp.zip. Si lo descomprimes, simplemente compila y ejecuta de la siguiente manera:

Para arrancar el servidor

$ unzip socketudp.zip
$ javac chuidiang\ejemplos\*.java
$ java chuidiang.ejemplos.ServidorUdp

Para arrancar el cliente

$ unzip socketudp.zip
$ javac chuidiang\ejemplos\*.java
$ java chuidiang.ejemplos.ClienteUdp

Deberías ver cómo el cliente envía 10 mensajes y el servidor los escribe en pantalla. Si no ejecutas ambos programas en el mismo ordenador, tendrás que cambiar los fuentes para que el cliente tenga el nombre del servidor.

SERVICIOS WEB,XML,UDDI,WSDL,SOAP

SERVICIOS WEB,XML,UDDI,WSDL,SOAP

Servicio web

Un servicio web (en inglés, Web service) es una pieza de software que utiliza un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de programación diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar los servicios web para intercambiar datos en redes de ordenadores como Internet. La interoperabilidad se consigue mediante la adopción de estándares abiertos. Las organizaciones OASIS y W3C son los comités responsables de la arquitectura y reglamentación de los servicios Web. Para mejorar la interoperabilidad entre distintas implementaciones de servicios Web se ha creado el organismo WS-I, encargado de desarrollar diversos perfiles para definir de manera más exhaustiva estos estándares.

Estándares empleados

• Web Services Protocol Stack: Así se denomina al conjunto de servicios y protocolos de los servicios Web.
• XML (Extensible Markup Language): Es el formato estándar para los datos que se vayan a intercambiar.
• SOAP (Simple Object Access Protocol) o XML-RPC (XML Remote Procedure Call): Protocolos sobre los que se establece el intercambio.
• Otros protocolos: los datos en XML también pueden enviarse de una aplicación a otra mediante protocolos normales como HTTP (Hypertext Transfer Protocol), FTP (File Transfer Protocol), o SMTP (Simple Mail Transfer Protocol).
• WSDL (Web Services Description Language): Es el lenguaje de la interfaz pública para los servicios Web. Es una descripción basada en XML de los requisitos funcionales necesarios para establecer una comunicación con los servicios Web.
• UDDI (Universal Description, Discovery and Integration): Protocolo para publicar la información de los servicios Web. Permite comprobar qué servicios web están disponibles.
• WS-Security (Web Service Security): Protocolo de seguridad aceptado como estándar por OASIS (Organization for the Advancement of Structured Information Standards). Garantiza la autenticación de los actores y la confidencialidad de los mensajes enviados.

 Ventajas de los servicios web

• Aportan interoperabilidad entre aplicaciones de software independientemente de sus propiedades o de las plataformas sobre las que se instalen.
• Los servicios Web fomentan los estándares y protocolos basados en texto, que hacen más fácil acceder a su contenido y entender su funcionamiento.
• Permiten que servicios y software de diferentes compañías ubicadas en diferentes lugares geográficos puedan ser combinados fácilmente para proveer servicios integrados.

Inconvenientes de los servicios Web

• Para realizar transacciones no pueden compararse en su grado de desarrollo con los estándares abiertos de computación distribuida como CORBA (Common Object Request Broker Architecture).
• Su rendimiento es bajo si se compara con otros modelos de computación distribuida, tales como RMI (Remote Method Invocation), CORBA o DCOM (Distributed Component Object Model). Es uno de los inconvenientes derivados de adoptar un formato basado en texto. Y es que entre los objetivos de XML no se encuentra la concisión ni la eficacia de procesamiento.
• Al apoyarse en HTTP, pueden esquivar medidas de seguridad basadas en firewall cuyas reglas tratan de bloquear o auditar la comunicación entre programas a ambos lados de la barrera.

Razones para crear servicios Web

La principal razón para usar servicios Web es que se pueden utilizar con HTTP sobre TCP (Transmission Control Protocol) en el puerto 80. Dado que las organizaciones protegen sus redes mediante firewalls -que filtran y bloquean gran parte del tráfico de Internet-, cierran casi todos los puertos TCP salvo el 80, que es, precisamente, el que usan los navegadores. Los servicios Web utilizan este puerto, por la simple razón de que no resultan bloqueados. Es importante señalar que los servicios web se pueden utilizar sobre cualquier protocolo, sin embargo, TCP es el mas común.

Otra razón es que, antes de que existiera SOAP, no había buenas interfaces para acceder a las funcionalidades de otros ordenadores en red. Las que había eran ad hoc y poco conocidas, tales como EDI (Electronic Data Interchange), RPC (Remote Procedure Call), u otras APIs.

Una tercera razón por la que los servicios Web son muy prácticos es que pueden aportar gran independencia entre la aplicación que usa el servicio Web y el propio servicio. De esta forma, los cambios a lo largo del tiempo en uno no deben afectar al otro. Esta flexibilidad será cada vez más importante, dado que la tendencia a construir grandes aplicaciones a partir de componentes distribuidos más pequeños es cada día más utilizada.

Se espera que para los próximos años mejoren la calidad y cantidad de servicios ofrecidos basados en los nuevos estándares.

Plataformas

Servidores de aplicaciones para servicios Web:

• JBoss servidor de aplicaciones J2EE Open Source de Red Hat inc.
• Oracle Fusion Middleware
• IBM Lotus Domino a partir de la versión 7.0
• Axis y el servidor Jakarta Tomcat (de Apache)
• ColdFusion MX de [[Macromedia]httpd ]
• Java Web Services Development Pack (JWSDP) de Sun Microsystems(basado en Jakarta Tomcat)
• JOnAS (parte de ObjectWeb una iniciativa de código abierto)
• Microsoft .NET
• Novell exteNd (basado en la plataforma J2EE)
• WebLogic
• WebSphere
• JAX-WS con GlassFish
• Zope es un servidor de aplicaciones Web orientado a objetosdesarrollado en el lenguaje de programación Python
• VERASTREAM de AttachmateWRQ para modernizar o integrar aplicaciones host IBM y VT
• PHP

XML

XML es una tecnología en realidad muy sencilla que tiene a su alrededor otras tecnologías que la complementan y la hacen mucho más grande y con unas posibilidades enormes y básicas para la sociedad de la información. Vamos a ver a lo largo de varios capítulos una introducción al mundo XML, es decir, al lenguaje así como a las tecnologías que trabajan con él, sus usos, ventajas y modos de llevar a cabo las tareas.

XML, con todas las tecnologías relacionadas, representa una manera distinta de hacer las cosas, más avanzada, cuya principal novedad consiste en permitir compartir los datos con los que se trabaja a todos los niveles, por todas las aplicaciones y soportes. Así pues, el XML juega un papel importantísimo en este mundo actual, que tiende a la globalización y la compatibilidad entre los sistemas, ya que es la tecnología que permitirá compartir la información de una manera segura, fiable, fácil. Además, XML permite al programador y los soportes dedicar sus esfuerzos a las tareas importantes cuando trabaja con los datos, ya que algunas tareas tediosas como la validación de estos o el recorrido de las estructuras corre a cargo del lenguaje y está especificado por el estándar, de modo que el programador no tiene que preocuparse por ello.

Vemos que XML no está sólo, sino que hay un mundo de tecnologías alrededor de él, de posibilidades, maneras más fáciles e interesantes de trabajar con los datos y, en definitiva, un avance a la hora de tratar la información, que es en realidad el objetivo de la informática en general. XML, o mejor dicho, el mundo XML no es un lenguaje, sino varios lenguajes, no es una sintaxis, sino varias y no es una manera totalmente nueva de trabajar, sino una manera más refinada que permitirá que todas las anteriores se puedan comunicar entre si sin problemas, ya que los datos cobran sentido. Todo esto lo veremos con calma en la Introducción a XML.

XML es interesante en el mundo de Internet y el e-bussiness, ya que existen muchos sistemas distintos que tienen que comunicarse entre si, pero como se ha podido imaginar, interesa por igual a todas las ramas de la informática y el tratamiento de datos, ya que permite muchos avances a la hora de trabajar con ellos.

Así pues, os recomendamos seguir esta lectura en la introducción a XML. A lo largo de los siguientes capítulos, vamos a ver algunas características importantes de la tecnología que nos permitirán comprender mejor el mundo XML y cómo soluciona nuestros problemas a la hora de trabajar con los datos.

Secciones CData

Le indican al parser que ignore todos los caracteres de marcas que se encuentren en el interior de esta/s sección/es. (ed, son como comentarios a lo bestia)
Son muy útiles cuando queremos (x ej. a modo de tutorial) visualizar código XML como parte del texto.
Todos los caracteres que existan entre son pasados directamente a la aplicación sin interpretación.
El único literal q no puede ser utilizado dentro de la sección es, lógicamente, el ]]>.

Ej.

<![CDATA[    <!ENTITY amp "&"> <!-- &= ampersand -->
<CODIGO>
*p=&q->campo;
a=(x<y)?33:44;
</CODIGO>
]]>

Elementos

Son las etiquetas más frecuentemente utilizadas dentro de un documento XML.
Están delimitadas por los símbolos < y >, sintaxis de todos conocida, puesto q era la usada en HTML.
Si el contenido de la etiqueta es vacío (al igual q <BR> ó <IMG> en HTML), entonces se delimitan por los símbolos < y />.
Las etiquetas de apertura (las que empiezan por >) pueden incluir atributos, los cuales son pares nombre/valor al estilo color=”verde”. (x ej, en HTML <font color=”green”>).
OJO!! En XML los atributos siempre deben ir encerrados entre comillas dobles.

Ejs:

<nombre id=”surname”>Perez</nombre>
<vacia color=”verde”/>

Referencias a entidades

Las entidades(entity) se usan en XML básicamente como representación alternativa de los caracteres especiales (como por ejemplo las comillas dobles ó la marca de apertura en un elemento), aunque también pueden emplearse para incluir el contenido de otros documentos ó para hacer referencia a trozos de texto repetitivos.

Sintaxis: &xxx;     donde xxx es el nombre de la entidad, y , &xxx; es la manera de referirse a la entidad.

Ej: &eacute; —-> Representa al símbolo é.

Existe una referencia a entidades “especial”, denominada referencia a caracteres.
Ésta se usa para representar caracteres que no pueden ser escritos desde el teclado.
No tienen un nombre de cadena (como eacute x ej) sino q su nombre es, ó un nº decimal, ó un nº hexadecimal.

Ej:  <!– Ampersand –>

Tambien se pueden crear constantes (ó macros) para que no nos tengamos q acordar de los numeross.
Para ello usamos la definición “real” de entidad:
Ej:

<!ENTITY amp “”&gt;
Para referenciarlo: &amp;

Dicen que el XML es un 10% del SGML y de verdad lo es, porque en realidad las normas que tiene son muy simples. Se escribe en un documento de texto ASCII, igual que el HTML y en la cabecera del documento se tiene que poner el texto

<?xml version=”1.0″?>

En el resto del documento se deben escribir etiquetas como las de HTML, las etiquetas que nosotros queramos, por eso el lenguaje se llama XML, lenguaje de etiquetas extendido. Las etiquetas se escriben anidas, unas dentro de otras.

<ETIQ1>…<ETIQ2>…</ETIQ2>…</ETIQ1>

Cualquier etiqueta puede tener atributos. Le podemos poner los atributos que queramos.

<ETIQ atributo1=”valor1″ atributo2=”valor2″…>

Los comentarios de XML se escriben igual que los de HTML.

<!– Comentario –>

Y esto es todo lo que es el lenguaje XML en si, aunque tenemos que tener en cuenta que el XML tiene muchos otros lenguajes y tecnologías trabajando alrededor de él. Sin embargo, no cabe duda que la sintaxis XML es realmente reducida y sencilla.

Para definir qué etiquetas y atributos debemos utilizar al escribir en XML tenemos que fijarnos en la manera de guardar la información de una forma estructurada y ordenada. Por ejemplo, si deseamos guardar la información relacionada con una película en un documento XML podríamos utilizar un esquema con las siguientes etiquetas.

<?xml version=”1.0″?>
<PELICULA nombre=”El Padrino” año=1985>
<PERSONAL>
</DIRECTOR nombre=”Georgie Lucar”>
</INTERPRETE nombre=”Marlon Brando” interpreta-a=”Don Corleone”>
</INTERPRETE nombre=”Al Pacino” interpreta-a=”Michael Corleone”>
</PERSONAL>
</ARGUMENTO descripción=”Pelicula de mafias sicilianas en Estados Unidos”>
</PELICULA>

Como podéis ver, nos hemos inventado las etiquetas que nos venían en gana para poner este ejemplo y las hemos anidado de manera que la etiqueta más grande es la PELICULA y dentro de ella tenemos el PRESONAL y el ARGUMENTO. A su vez, dentro de PERSONAL tenemos tanto al DIRECTOR como a los actores (INTERPRETE).

.

XML tiene una ventaja que se puede convertir en un inconveniente: cada persona/autor puede crear sus propias etiquetas.

Esto no trae problemas si trabajamos solos; pero, ¿y si trabajamos en equipo?, ¿y si queremos exportar nuestros documentos? ¿qué estándar seguiremos?

Ej:

“A” puede escribir el nombre como sigue:
<nombre>Juan</nombre>
Sin embargo, “B” puede hacerlo así:
<nombre id=”Juan”/>

Las 2 versiones son igual de correctas pero son diferentes; si extrapolamos esto a muchas marcas, entonces la lectura y/o modificación de documentos por diferentes personas puede ser un caos.

Para resolver estos problemas, proporcionando un pequeño estandar acerca de la sintaxis a utilizar, XML ofrece dos posibles soluciones:

• Las DTD’s.
• Los XML Schemas.

En las DTD’s podemos hacer 4 tipos de declaraciones:

1. Declaraciones de tipo de elemento (Element Type Declarations).
2. Declaraciones de listas de atributos (Attribute List Declarations).
3. Declaraciones de Entidades (Entity Declarations).
4. Declaraciones de notación (Notation Declarations).

Las trataré una a una en los siguientes apartados.

Declaraciones de tipo de elemento

Estas declaraciones establecen qué elementos pueden formar parte del documento y cuáles pueden formar parte de su interior (los elementos se anidan unos dentro de otros).

Sintaxis:

Los elementos que puede contener cada elemento (valga la redundancia) van siempre encerrados entre paréntesis y precedidos de la etiqueta <!ELEMENT.

Dentro de las etiquetas, cada elemento (atributo) podrá llevar uno de los siguientes símbolos detrás de su nombre:

SÍMBOLO	SIGNIFICADO (Indica…)
,	Secuencia de elementos
?	0 o 1 ocurrencias
*	0 o más ocurrencias
+	1 o más ocurrencias
Empty	que el elemento está vacío. Estos elementos NO tienen etiqueta de cierre.
Any	Cualquier contenido es válido. Yo no recomiendo su uso.
#PCDATA	que el contenido de la cadena puede ser una cadena de texto.

Ejs:

<!ELEMENT nombre (#PCDATA)>
<!ELEMENT nombre EMPTY>
<!ELEMENT cliente (nombre,apellidos,nif?,tlf*,direccion+)>

Este último ej. quiere expresar lo siguiente:

El elemento cliente debe contener a nombre y apellidos, puede contener a nif y tlf – a este incluso más de una vez- y debe contener al menos una vez la dirección del cliente (para poder enviarle el pedido a casa).

Nota: Luego podemos hacer una redefinición de los subelementos si queremos.

EJ:
<!ELEMENT cliente (nombre,apellidos,nif?,tlf*,direccion+)>
<!ELEMENT nombre (#PCDATA)>
<!ELEMENT apellidos(ape1,ape2?)>
…..

Además de esto, tambien podemos indicar que existen varias alternativas; para ello se usa el símbolo | (relación OR). Ej:

<!ELEMENT apellidos (#PCDATA|(ape1,ape2))>>
<!ELEMENT ape1 (#PCDATA)>
<!ELEMENT ape2 (#PCDATA)>

indica q se puede elejir entre teclear los 2 apellidos juntos o por separado:

• <apellidos> Perez López </apellidos>
• <apellidos> <ape1> Perez </ape1> <ape2> López </ape2> </apellidos>

Declaraciones de listas de atributos

Ya hemos visto como denotar los elementos que puede tener el documento. Pero, ¿qué pasa con los atributos (si es que tienen) de todos y acada uno de los elementos?

Para definirlos se usan las declaraciones de listas de atributos, cuya sintaxis es la siguiente:

Sintaxis:

Todas las definiciones de atributos empezarán por: <!ATTLIST

Cada atributo está formado por 3 partes:

Nombre
Tipo del atributo
Valor por defecto

Las posibilidades para describir el tipo de un atributo (campo) y el valor por defecto del mismo las podeis ver en las siguientes tablas:

Tipo del atributo

VALOR	SIGNIFICADO
CDATA	El atributo será una cadena de caracteres. No todos los caracteres son válidos. Usaremos secciones PCDATA cuando queramos incluir los carácteres no válidos.
ID	El atributo sirve para identificar al elemento dentro del documento. Sólo puede haber un atributo de tipo ID por elemento.
IDREF/S	Este atributo se empleará para referenciar a otros elementos del documento a partir de su ID.
ENTITY/S	Contiene nombres de entidades. Ver siguiente apdo.
NMTOKEN/S	Contiene una única cadena de texto (ed, una sola palabra).
(<<enumerados>>)	Aquí especificamos EL conjunto de valores q puede tomar el atributo; esto lo hacemos separandolos con |.

Nota: El valor para los atributos acabados en S (ej. IDEREFS) será una lista de valores separados por espacios en blanco.

Valores por defecto

VALOR	SIGNIFICADO
#REQUIRED	Con esto indicamos que es obligatorio darle un valor al atributo.
#IMPLIED	Con esto indicamos que es opcional darle un valor al atributo.
<<valor>>	Podemos poner un valor (NO lista de valores) opcional directamente; entonces, si no se le otorga un nuevo valor posteriormente, asumirá el dado (ed, es el valor x por defecto). No es obligatorio darle un valor en el doc.
#FIXED <<valor>>>	Con esto obligamos a q el atributo tome necesariamente el valor especificado en <<valor>>

EJ:

<!ATTLIST cliente
numcli ID #REQUIRED
edad (“Menos de 18″ | “entre 18 y 65″ | “Más de 65″) #IMPLIED
>

Al ser numcli de tipo ID indicamos q no puede haber 2 clientes con idéntico numcli.
Edad es un atributo no obligatorio q sólo puede tomar los valores de la lista enumerada.

UDDI

UDDI son las siglas del catálogo de negocios de Internet denominadoUniversal Description, Discovery and Integration. El registro en el catálogo se hace en XML. UDDI es una iniciativa industrial abierta (sufragada por laOASIS) entroncada en el contexto de los servicios Web. El registro de un negocio en UDDI tiene tres partes:

• Páginas blancas – dirección, contacto y otros identificadores conocidos.
• Páginas amarillas – categorización industrial basada en taxonomías.
• Páginas verdes – información técnica sobre los servicios que aportan las propias empresas.

UDDI es uno de los estándares básicos de los servicios Web cuyo objetivo es ser accedido por los mensajes SOAP y dar paso a documentos WSDL, en los que se describen los requisitos del protocolo y los formatos del mensaje solicitado para interactuar con los servicios Web del catálogo de registros.

UDDI Un registro global de servicios Web

UDDI es un registro público diseñado para almacenar de forma estructurada información sobre empresas y los servicios que éstas ofrecen. A través de UDDI, se puede publicar y descubrir información de una empresa y de sus servicios. Se puede utilizar sistemas taxonómicos estándar para clasificar estos datos y poder encontrarlos posteriormente en función de la categorización. Lo más importante es que UDDI contiene información sobre las interfaces técnicas de los servicios de una empresa. A través de un conjunto de llamadas a API XML basadas en SOAP, se puede interactuar con UDDI tanto en tiempo de diseño como de ejecución para descubrir datos técnicos de los servicios que permitan invocarlos y utilizarlos. De este modo, UDDI sirve como infraestructura para una colección de software basado en servicios Web.

• ¿Por qué UDDI? ¿Por qué resulta necesario un registro de este tipo? Teniendo en cuenta que existe una colección de software de miles (quizás millones) de servicios Web, se nos plantean varias cuestiones difíciles:
• ¿Cómo se descubren los servicios Web?
• ¿Cómo se categoriza la información de forma coherente?
• ¿Cómo repercute esto en la localización?
• ¿Cómo afecta a las tecnologías de propietario? ¿Cómo se puede garantizar la interoperabilidad del mecanismo de descubrimiento?
• ¿Cómo se puede interactuar en tiempo de ejecución con este mecanismo de descubrimiento cuando mi aplicación depende de un servicio Web?

La iniciativa UDDI surgió como respuesta a estas preguntas. Varias empresas, incluidas Microsoft, IBM, Sun, Oracle, Compaq, Hewlett Packard, Intel, SAP y unas trescientas más (para obtener un listado completo, consulte UDDI: Community [en inglés]), unieron sus esfuerzos para desarrollar una especificación basada en estándares abiertos y tecnologías no propietarias que permitiera resolver los retos anteriores. El resultado, cuya versión beta se lanzó en diciembre de 2000 y estaba en producción en mayo de 2001, fue un registro empresarial global alojado por varios nodos de operadores en el que los usuarios podían realizar búsquedas y publicaciones sin coste alguno.

A partir de la creación de esta infraestructura para servicios Web, los datos sobre estos servicios se pueden encontrar de forma sistemática y confiable en una capacidad universal totalmente independiente de proveedores. Se pueden llevar a cabo búsquedas categóricas precisas utilizando sistemas de identificación y taxonómicos extensibles. La integración de UDDI en tiempo de ejecución se puede incorporar a las aplicaciones. Como resultado, se fomenta el desarrollo de un entorno de software de servicios Web.

¿Cómo funciona UDDI?

La información de UDDI se aloja en nodos de operador, empresas que se han comprometido a ejecutar un nodo público conforme a la especificación que rige el consorcio UDDI.org. En la actualidad existen dos nodos públicos que se ajustan a la versión 1 de la especificación UDDI: Microsoft aloja uno e IBM el otro. Hewlett Packard se ha comprometido a alojar un nodo bajo la versión 2 de la especificación. Los operadores del host deben replicar datos entre ellos a través de un canal seguro, para conseguir la redundancia de la información en el registro UDDI. Se pueden publicar los datos en un nodo y descubrirlos en otro tras la réplica. Actualmente, la réplica se produce cada 24 horas. En el futuro, este intervalo entre réplicas se reducirá, ya que habrá más aplicaciones que dependan de los datos de UDDI.

Resulta importante observar que no existen requisitos de propietario respecto al modo en que el operador del host implementa su nodo. El nodo sólo se debe ajustar a la especificación UDDI. El nodo de Microsoft (http://uddi.microsoft.com/default.aspx [en inglés]), por ejemplo, se ha escrito por completo en C# y se ejecuta en producción en tiempo de ejecución en lenguaje común .NET Beta 2. El código de base se beneficia claramente de la compatibilidad nativa con SOAP y de la serialización que ofrecen las clases de sistema .NET. En el lado del servidor, el nodo del operador Microsoft utiliza Microsoft® SQL Server 2000 como almacén de datos. Creo que basta con mencionar que IBM utiliza tecnologías diferentes para ejecutar su nodo, ¿verdad?. No obstante, los dos nodos se comportan exactamente igual, ya que se ajustan al mismo conjunto de llamadas a API XML basadas en SOAP. Las herramientas de los clientes pueden interoperar con ambos nodos sin problemas. Por eso, el nodo público UDDI constituye un claro ejemplo de que el modelo de servicios Web XML funciona en entornos heterogéneos.

El próximo paso para comprender la iniciativa UDDI consiste en ver qué datos se almacenan en UDDI y cómo se estructuran. UDDI es relativamente ligero; se ha diseñado como registro, no como depósito. La diferencia, aunque sutil, resulta esencial. Un registro redirige al usuario a recursos, mientras que un depósito sólo almacena información. El registro Microsoft® Windows® puede servir de ejemplo: contiene las configuraciones y parámetros básicos pero, en última instancia, su función es la de dirigir la aplicación a un recurso o binario. Buscar un componente COM basándonos en su Id. de programa nos conducirá a un Id. de clase, que a su vez nos dirigirá a la ubicación del binario.

UDDI se comporta de forma similar: como el registro de Windows, se basa en identificadores únicos globales (GUID) para garantizar la capacidad de búsquedas y determinar la ubicación de recursos. En última instancia, las consultas a UDDI conducen a una interfaz (un archivo .WSDL, .XSD, .DTD, etc.) o a una implementación (como un archivo .ASMX o .ASP) ubicadas en otro servidor. Por tanto, UDDI puede responder a este tipo de preguntas:

• “¿Qué interfaces de servicios Web basadas en WSDL se han publicado y establecido para un sector determinado?”
• “¿Qué empresas han escrito una implementación basada en una de estas interfaces?”
• “¿Qué servicios Web, categorizados de algún modo, se ofrecen actualmente?”
• “¿Qué servicios Web ofrece una empresa determinada?”
• “¿Con quién se debe poner en contacto el usuario para utilizar los servicios Web de una empresa?”
• “¿Cuáles son los detalles de implementación de un servicio Web concreto?”

WSDL y UDDI

WSDL se ha convertido en una pieza clave de la pila de protocolos de los servicios Web. Por eso, es importante saber cómo colaboran UDDI y WSDL y por qué la idea de interfaces frente implementaciones forma parte de cada protocolo. WSDL y UDDI se diseñaron para diferenciar claramente los metadatos abstractos y las implementaciones concretas. Para entender cómo funcionan WSDL y UDDI resulta esencial comprender las consecuencias de esta división.

Por ejemplo, WSDL distingue claramente los mensajes de los puertos: los mensajes (la sintaxis y semántica que necesita un servicio Web) son siempre abstractos, mientras que los puertos (las direcciones de red en las que se invoca al servicio Web) son siempre concretos. No es necesario que un archivo WSDL incluya información sobre el puerto. Un archivo WSDL puede contener simplemente información abstracta de interfaz, sin facilitar datos de implementación concretos, y ser válido. De este modo, los archivos WSDL se separan de las implementaciones.

Una de las consecuencias más interesantes de esto es que pueden existir varias implementaciones de una única interfaz WSDL. Este diseño permite que sistemas dispares escriban implementaciones de la misma interfaz, para garantizar así la comunicación entre ellos. Si tres empresas diferentes implementan el mismo archivo WSDL y una parte del software de cliente crea el código auxiliar/proxy a partir de esa interfaz, dicho software se podrá comunicar con las tres implementaciones con el mismo código de base, cambiando simplemente el punto de acceso.

UDDI establece una distinción similar entre la abstracción y la implementación con el concepto de tModels. La estructura tModel, abreviatura de “Technology Model” (modelo de tecnología), representa huellas digitales técnicas, interfaces y tipos abstractos de metadatos. El resultado de los tModels son las plantillas de enlace, que son la implementación concreta de uno o más tModels. Dentro de una plantilla de enlace se registra el punto de acceso de una implementación particular de un tModel. Del mismo modo que el esquema de WSDL permite separar la interfaz y la implementación, UDDI ofrece un mecanismo que permite publicar por separado los tModels de las plantillas de enlace que hacen referencia a ellos. Por ejemplo, un grupo industrial o de estándares publica la interfaz canónica para un sector particular y, a continuación, varias empresas escriben implementaciones de esta interfaz. Obviamente, cada una de estas implementaciones haría referencia al mismo tModel. Los archivos WSDL constituyen un ejemplo perfecto de tModel de UDDI.

WSDL

WSDL son las siglas de Web Services Description Language, un formato XML que se utiliza para describir servicios Web (algunas personas lo leen como wisdel). La versión 1.0 fue la primera recomendación por parte del W3C y la versión 1.1 no alcanzó nunca tal estatus. La versión 2.0 se convirtió en la recomendación actual por parte de dicha entidad.

WSDL describe la interfaz pública a los servicios Web. Está basado en XML y describe la forma de comunicación, es decir, los requisitos del protocolo y los formatos de los mensajes necesarios para interactuar con los servicios listados en su catálogo. Las operaciones y mensajes que soporta se describen en abstracto y se ligan después al protocolo concreto de red y al formato del mensaje.

Así, WSDL se usa a menudo en combinación con SOAP y XML Schema. Un programa cliente que se conecta a un servicio web puede leer el WSDL para determinar qué funciones están disponibles en el servidor. Los tipos de datos especiales se incluyen en el archivo WSDL en forma de XML Schema. El cliente puede usar SOAP para hacer la llamada a una de las funciones listadas en el WSDL.

El WSDL nos permite tener una descripción de un servicio web. Especifica la interfaz abstracta a través de la cual un cliente puede acceder al servicio y los detalles de cómo se debe utilizar.

Estructura del WSDL

Como vemos, la estructura del WSDL tiene los siguientes elementos:

Tipos de Datos

<types>: Esta sección define los tipos de datos usados en los mensajes. Se utilizan los tipos definidos en la especificación de esquemas XML.

Mensajes

<message>: Aquí definimos los elementos de mensaje. Cada mensaje puede consistir en una serie de partes lógicas. Las partes pueden ser de cualquiera de los tipos definidos en la sección anterior.

Tipos de Puerto

<portType>: Con este apartado definimos las operaciones permitidas y los mensajes intercambiados en el Servicio.

 Bindings

<binding>: Especificamos los protocolos de comunicación usados.

Servicios

<service>: Conjunto de puertos y dirección de los mismos. Esta parte final hace referencia a lo aportado por las secciones anteriores.

Con estos elementos no sabemos que hace un servicio pero si disponemos de la información necesaria para interactuar con él (funciones, mensajes de entrada/salida, protocolos…).

Ejemplo

A continuación se muestra un ejemplo de un documento WSDL y sus diferentes secciones. En este ejemplo concreto se implementa un servicio que muestra a partir del nombre de un valor bursátil su valor actual en el mercado.

 <definitions name="StockQuote"

          targetNamespace="http://example.com/stockquote.wsdl"

          xmlns:tns="http://example.com/stockquote.wsdl"

          xmlns:xsd1="http://example.com/stockquote.xsd"

          xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

          xmlns="http://schemas.xmlsoap.org/wsdl/">

    <types>

       <schema targetNamespace="http://example.com/stockquote.xsd"

              xmlns="http://www.w3.org/2000/10/XMLSchema">

           <element name="TradePriceRequest">

              <complexType>

                  <all>

                      <element name="tickerSymbol" type="string"/>

                  </all>

              </complexType>

           </element>

           <element name="TradePrice">

              <complexType>

                  <all>

                      <element name="price" type="float"/>

                  </all>

              </complexType>

           </element>

       </schema>

    </types>

    <message name="GetLastTradePriceInput">

        <part name="body" element="xsd1:TradePriceRequest"/>

    </message>

    <message name="GetLastTradePriceOutput">

        <part name="body" element="xsd1:TradePrice"/>

    </message>

    <portType name="StockQuotePortType">

        <operation name="GetLastTradePrice">

           <input message="tns:GetLastTradePriceInput"/>

           <output message="tns:GetLastTradePriceOutput"/>

        </operation>

    </portType>

    <binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">

        <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>

        <operation name="GetLastTradePrice">

           <soap:operation soapAction="http://example.com/GetLastTradePrice"/>

           <input>

               <soap:body use="literal"/>

           </input>

           <output>

               <soap:body use="literal"/>

           </output>

        </operation>

    </binding>

    <service name="StockQuoteService">

        <documentation>My first service</documentation>

        <port name="StockQuotePort" binding="tns:StockQuoteSoapBinding">

           <soap:address location="http://example.com/stockquote"/>

        </port>

    </service>

 </definitions>

WSDL WSDL son las siglas en inglés de “Lenguaje de Descripción de Servicios Web” (o “Web Services Description Language”), un lenguaje que está basado en XML y que permite la descripción de los servicios web desplegados. WSDL se utiliza también para la localización y ubicación de estos servicios en Internet. Un documento WSDL no es más que un documento XML que describe ciertas características propias de un servicio web, así como su localización y aquellos parámetros y métodos que soporta. Un documento WSDL define un servicio web utilizando a tal fin elementos XML, como: <portType> para las operaciones que proporciona el servicio web <message> para los mensajes que utiliza por el servicio web <types> para los tipos de datos que utiliza el servicio web <binding> para los protocolos de comunicaciones que utiliza el servicio web Un documento WSDL tiene una estructura semejante a la siguiente: <definitions> <types> los tipos de datos… </types> <message> las definiciones del mensaje… </message> <portType> las definiciones de operación … </portType> <binding> las definiciones de protocolo… </binding> </definitions> Los puertos de WSDL <portType> es el elemento XML de WSDL que define el servicio web, así como las operaciones posibles mediante dicho servicio y los mensajes vinculados. <portType> cumple una función análoga a la de una función de biblioteca en programación clásica o a la de una clase en programación orientada a objetos. Los mensajes WSDL El elemento message define los datos que participan en una operación. Cada mensaje puede tener una o varias partes, y cada parte puede considerarse como si fuera los parámetros que se pasan en la llamada a una función en programación clásica o un método en programación orientada a objetos. Los tipos de datos en WSDL Mediante el elemento <types> se definen los tipos de datos utilizados en el servicio web. Para ello, WSDL utiliza XML Schema. Los vínculos en WSDL <binding> define el formato del mensaje y el protocolo para cada uno de los puerto. Ejemplo de un documento WSDL: <message name=”obtTerminoDePet”> <part name=”param” type=”xs:string”/> </message> <message name=”obtTerminoDeResp”> <part name=”valor” type=”xs:string”/> </message> <portType name=”terminosDeDiccionario”> <operation name=”obtTermino”> <input message=”obtTerminoDePet”/> <output message=”optTerminoDeResp”/> </operation> </portType> Vemos como el portType define terminosDeDiccionario como el nombre de un puerto y define obtTermino como el nombre de una operación. Esta operación tiene un mensaje de entrada (es decir, un parámetro) denominado obtTerminoDePet y un mensaje de salida (esto es, un resultado) denominado obtTerminoDeResp. Los elementos message definen los tipos de datos que están asociados a los mensajes. terminosDeDiccionario equivale en programación clásica a una librería de funciones; obtTermino equivale a una función, y obtTerminoDePet y obtTerminoDeResp equivalen respectivamente a los parámetros de entrada y salida. Puertos Un puerto define el punto de conexión a un servicio web. Es posible definirlo como una librería de funciones (en programación clásica) o una clase (en programación orientada a objetos). Puede compararse cada operación que esté definida para un puerto a una función en cualquier lenguaje de programación clásico. Tipos de operación Existen varios tipos de operación en WSDL. El tipo más frecuente es el denominado “de petición-respuesta”. Disponemos, además, de: Unidireccional: la operación recibe mensajes, sin retornar respuestas. Petición-respuesta: la operación recibe una petición y devuelve una respuesta. Solicitud-respuesta: la operación puede enviar una petición y permanecerá a la espera de una respuesta. Notificación: la operación puede enviar un mensaje sin esperar respuesta. Un ejemplo de operación de tipo unidireccional: <message name=”valorNuevo”> <part name=”termino” type=”xs:string”/> <part name=”valor” type=”xs:string”/> </message> <portType name=”terminosDeDiccionario”> <operation name=”terminoNuevo”> <input name=”terminoNuevo” message=”valorNuevo”/> </operation> </portType> En el ejemplo se define una operación unidireccional llamada terminoNuevo, que permite introducir nuevos términos en el diccionario. Utiliza un mensaje de entrada llamado valorNuevo, que maneja los parámetros “termino” y “valor”. Sin embargo, no se ha definido salida alguna para la operación. Un ejemplo de operación de tipo petición-respuesta: <message name=”obtTerminoDePet”> <part name=”param” type=”xs:string”/> </message> <message name=”obtTerminoDeResp”> <part name=”valor” type=”xs:string”/> </message> <portType name=”terminosDeDiccionario”> <operation name=”obtTermino”> <input message=”obtTerminoDePet”/> <output message=”optTerminoDeResp”/> </operation> </portType> En el ejemplo se definen 2 mensajes, de entrada y de salida, para la operación obtTermino. Enlaces Los enlaces o vínculos de WSDL (también denominados “bindings”) permiten la definición de los formatos de mensaje y de protocolo para los servicios web. Un ejemplo posible de enlace para una operación de tipo petición-respuesta para SOAP sería: <message name=”obtTerminoDePet”> <part name=”param” type=”xs:string”/> </message> <message name=”obtTerminoDeResp”> <part name=”valor” type=”xs:string”/> </message> <portType name=”terminosDeDiccionario”> <operation name=”obtTermino”> <input message=”obtTerminoDePet”/> <output message=”optTerminoDeResp”/> </operation> </portType> <binding type=”terminosDeDiccionario” name=”tD”> <soap:binding style=”document” transport=”http://schemas.xmlsoap.org/soap/http” /> <operation> <soap:operation soapAction=”http://uoc.edu/obtTermino”/> <input> <soap:body use=”literal”/> </input> <output> <soap:body use=”literal”/> </output> </operation> </binding> El elemento <binding> cuenta con 2 atributos: “name” y “type”. Con “name” (se puede utilizar cualquier nombre, sin que coincida necesariamente con el utilizado en la definición de port) se define el nombre del vínculo, y el atributo “type” apunta al puerto del vínculo, que es, en este caso, terminosDeDiccionario. El elemento soap:binding cuenta con 2 atributos: “style” y “transport”. “style” puede ser “rpc” o “document”. En el ejemplo se ha utilizado “document”. “transport” define qué protocolo SOAP se debe utilizar; en el ejemplo, HTTP. “operation” define las operaciones que proporciona el puerto. Para cada se debe especificar la acción SOAP que corresponda. También se debe especificar el método para codificar la entrada (o “input”) y la salida (u “output”). En el ejemplo, la codificación es “literal”.

Los manuales titulados Introducción a las aplicaciones web, Instalación del servidor web y Servicios web han sido extraídos, con algunas modificaciones, del manual “Desarrollo de aplicaciones web”, publicado por la UOC dentro de su máster de software libre, escrito por Carles Mateu i Piñol.

El manual tiene licencia GFDL, la cual otorga permiso para copiar, distribuir y modificar el documento según los términos de la GNU Free Documentation License, Version 1.2 o cualquiera posterior publicada por la Free Software Foundation, sin secciones invariantes ni textos de cubierta delantera o trasera.

SOAP

SIMPLE OBJECT ACCESS PROTOCOL

SOAP estructura

SOAP (siglas de Simple Object Access Protocol) es un protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML. Este protocolo deriva de un protocolo creado por David Winer en 1998, llamado XML-RPC. SOAP fue creado por Microsoft, IBM y otros y está actualmente bajo el auspicio de la W3C. Es uno de los protocolos utilizados en los servicios Web.

SOAP sobre correo electrónico

Los desarrolladores de aplicaciones hoy en día, pueden utilizar la infraestructura de correo electrónico de Internet para transmitir mensajes SOAP ya sean como mensajes de correo electrónico de texto o como adjuntos. Los ejemplos que se muestran a continuación muestran un modo de transmitir mensajes SOAP, y deben ser tomados como el modo estándar de hacerlo. Las especificaciones SOAP Versión 1.2 no especifican tal vínculo. Sin embargo, existe una Nota W3C no-normativa [SOAP Email Binding] que describe un vínculo de SOAP con el correo electrónico, su propósito principal es comenzar a demostrar la aplicación de la Infraestructura general de Vínculos con el Protocolo SOAP.

El Ejemplo muestra el mensaje de petición de reserva de viaje del Ejemplo 1 transportado como un mensaje de correo electrónico entre un agente de usuario remitente y un agente de usuario destinatario. Está implícito que el nodo destinatario tiene capacidad para entender SOAP, por lo que se envía el mensaje de correo electrónico para su procesamiento. (Se asume que también el nodo remitente puede manejar errores SOAP que pudiera recibir en la respuesta o correlacionar cualesquiera mensajes SOAP recibidos en respuesta a éste).

Ejemplo

De: a.oyvind@miempresa.example.com

A: reservas@empresaviajes.example.org

Asunto: Viaje a LA

Fecha: Thu, 29 Nov 2001 13:20:00 EST

Message-Id: <EE492E16A090090276D208424960C0C@miempresa.example.com>

Content-Type: application/soap+xml

<?xml version='1.0' ?>

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">

  <env:Header>

    <m:reserva xmlns:m="[[http://www.mouta.com.ar]]"

               env:role="http://www.w3.org/2003/05/soap-envelope/role/next"

               env:mustUnderstand="true">

      <m:referencia>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:referencia>

      <m:fechaYHora>2001-11-29T13:20:00.000-05:00</m:fechaYHora>

    </m:reserva>

    <n:pasajero xmlns:n="http://miempresa.example.com/empleados"

                env:role="http://www.w3.org/2003/05/soap-envelope/role/next"

                env:mustUnderstand="true">

      <n:nombre>Åke Jógvan Øyvind</n:nombre>

    </n:pasajero >

  </env:Header>

  <env:Body>

    <p:itinerario xmlns:p="http://empresaviajes.example.org/reserva/viaje">

      <p:ida>

        <p:salida>Nueva York</p:salida>

        <p:llegada>Los Angeles</p:llegada>

        <p:fechaSalida>2001-12-14</p:fechaSalida>

        <p:horaSalida>última hora de la tarde</p:horaSalida>

        <p:preferenciaAsiento>pasillo</p:preferenciaAsiento>

      </p:ida>

      <p:vuelta>

        <p:salida>Los Angeles</p:salida>

        <p:llegada>Nueva York</p:llegada>

        <p:fechaSalida>2001-12-20</p:fechaSalida>

        <p:horaSalida>media-mañana</p:horaSalida>

        <p:preferenciaAsiento />

      </p:vuelta>

    </p:itinerario>

    <q:alojamiento xmlns:q="http://empresaviajes.example.org/reserva/hoteles">

      <q:preferencia>ninguna</q:preferencia>

    </q:alojamiento>

  </env:Body>

</env:Envelope>Mensaje SOAP del Ejemplo 1 transportado como un mensaje SMTP

El encabezado del Ejemplo tiene la forma estándar de [RFC 2822] para mensajes de correo electrónico.

Aunque el correo electrónico es un intercambio de mensajes en un solo sentido, y no se da ninguna garantía de entrega, infraestructuras como la de la especificación Simple Mail Transport Protocol (SMTP) ofrecen un mecanismo de notificación de entrega que, en el caso de SMTP, se denominan Delivery Status Notification (DSN) [Notificación de Estado de Entrega] y Message Disposition Notification (MDN) [Notificación de Disposición de Mensaje]. Estas notificaciones toman la forma de mensajes de correo electrónico enviados a la dirección de correo electrónico especificada en el encabezamiento del mensaje de correo. Las aplicaciones, así como los usuarios finales del correo, pueden utilizar estos mecanismos para proporcionar el estado de una transmisión de correo electrónico, pero estos, si existiesen, serían notificaciones al nivel SMTP. El desarrollador de aplicaciones debe comprender completamente las capacidades y limitaciones de estas notificaciones de entrega o el riesgo de asumir que haya existido una entrega del mensaje con éxito cuando podría no haberse producido.

Los mensajes de estado de entrega SMTP son separados del procesamiento del mensaje en la capa SOAP. Las respuestas SOAP resultantes a los datos SOAP serán devueltas a través de un mensaje de correo electrónico nuevo que podría tener o no un enlace con el mensaje de la petición original al nivel SMTP. El uso del encabezado In-reply-to: [En-respuesta-a] según [RFC 2822] puede conseguir una correlación al nivel SMTP, pero no implica necesariamente una correlación al nivel SOAP.

Ejemplos de mensajes SOAP

Como ejemplo se muestra la forma en que un cliente solicitaría información de un producto a un proveedor de servicios Web:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

   <soap:Body>

     <getProductDetails xmlns="http://warehouse.example.com/ws">

       <productId>827635</productId>

     </getProductDetails>

   </soap:Body>

</soap:Envelope>

Y esta sería la respuesta del proveedor:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

   <soap:Body>

     <getProductDetailsResponse xmlns="http://warehouse.example.com/ws">

       <getProductDetailsResult>

         <productName>Toptimate 3-Piece Set</productName>

         <productId>827635</productId>

         <description>3-Piece luggage set.  Black Polyester.</description>

         <price>96.50</price>

         <inStock>true</inStock>

       </getProductDetailsResult>

     </getProductDetailsResponse>

   </soap:Body>

</soap:Envelope>

XML EN PHP COMO INTEGRARLO

Generar un documento xml a partir de un php es relativamente sencillo. Es primordial generar el Content-Type adecuado y a partir de ahí generar una estructura válida de xml que luego podremos utilizar, por ejemplo, para leer datos en una película de Flash. Supongamos que queremos generar un documento xml como el siguiente para después poder cargarlo dentro de un visor de imágenes generado con Flash.

<album>
<elemento>
<src>imagen1.jpg</src>
<titulo>un barco</titulo>
<url>pagina1.html</url>
</elemento>
<elemento>
<src>imagen2.jpg</src>
<titulo>un coche</titulo>
<url>pagina2.html</url>
</elemento>
<elemento>
<src>imagen3.jpg</src>
<titulo>retrato</titulo>
<url>pagina3.html</url>
</elemento>
</album>

El documento php se podría construir con un script similar al siguiente.

<?
header(“Content-type: text/xml”);
//los arrays se podrían alimentar
//con datos extraidos de una base de datos
$imagenes = array(‘imagen1.jpg’, ‘imagen2.jpg’, ‘imagen3.jpg’);
$titulos = array(‘un barco’, ‘un coche’, ‘retrato’);
$enlaces = array(‘pagina1.html’,’pagina2.html’,’pagina3.html’);
echo ‘<?xml version=”1.0″?>’;
echo ‘<album>’;
$pos = 0;
foreach ($imagenes as $valor) {
echo ‘<elemento>’;
echo ‘<img>’;
echo $valor;
echo ‘</img>’;
echo ‘<titulo>’;
echo $titulos[$pos];
echo ‘</titulo>’;
echo ‘<src>’;
echo $enlaces[$pos];
echo ‘</src>’;
$pos++;
echo’</elemento>’;
}
echo ‘</album>’;
?>