Programación en ambiente Cliente/Servidor

Unidad 1 Contexto de la programación Cliente Servidor

1.1. Arquitectura del modelo cliente/servidor.

CONCEPTO DE ARQUITECTURA CLIENTE / SERVIDOR.

La tecnología Cliente/Servidor es el procesamiento cooperativo de la información por medio de un conjunto de procesadores, en el cual múltiples clientes, distribuidos geográficamente, solicitan requerimientos a uno o más servidores centrales.

Desde el punto de vista funcional, se puede definir la computación Cliente/Servidor como una arquitectura distribuida que permite a los usuarios finales obtener acceso a la información de forma transparente aún en entornos multiplataforma. Se trata pues, de la arquitectura más extendida en la realización de Sistemas Distribuidos.

Un sistema Cliente/Servidor es un Sistema de Información distribuido basado en las siguientes características:

Servicio: unidad básica de diseño. El servidor los proporciona y el cliente los utiliza.
Recursos compartidos: Muchos clientes utilizan los mismos servidores y, a través de ellos, comparten tanto recursos lógicos como físicos.
Protocolos asimétricos: Los clientes inician “conversaciones”. Los servidores esperan su establecimiento pasivamente.
Transparencia de localización física de los servidores y clientes: El cliente no tiene por qué saber dónde se encuentra situado el recurso que desea utilizar.
Independencia de la plataforma HW y SW que se emplee.
Sistemas débilmente acoplados. Interacción basada en envío de mensajes.
Encapsulamiento de servicios. Los detalles de la implementación de un servicio son transparentes al cliente.
Escalabilidad horizontal (añadir clientes) y vertical (ampliar potencia de los servidores).
Integridad: Datos y programas centralizados en servidores facilitan su integridad y mantenimiento.

En el modelo usual Cliente/Servidor, un servidor, (daemon en la terminología sajona basada en sistemas UNIX/LINUX, traducido como "demonio") se activa y espera las solicitudes de los clientes. Habitualmente, programas cliente múltiples comparten los servicios de un programa servidor común. Tanto los programas cliente como los servidores son con frecuencia parte de un programa o aplicación mayores.

El Esquema de funcionamiento de un Sistema Cliente/Servidor sería:

El cliente solicita una información al servidor.
El servidor recibe la petición del cliente.
El servidor procesa dicha solicitud.
El servidor envía el resultado obtenido al cliente.
El cliente recibe el resultado y lo procesa.

COMPONENTES DE LA ARQUITECTURA CLIENTE/SERVIDOR

El modelo Cliente/Servidor es un modelo basado en la idea del servicio, en el que el cliente es un proceso consumidor de servicios y el servidor es un proceso proveedor de servicios. Además esta relación está establecida en función del intercambio de mensajes que es el único elemento de acoplamiento entre ambos.

De estas líneas se deducen los tres elementos fundamentales sobre los cuales se desarrollan e implantan los sistemas Cliente/Servidor: el proceso cliente que es quien inicia el diálogo, el proceso servidor que pasivamente espera a que lleguen peticiones de servicio y el middleware que corresponde a la interfaz que provee la conectividad entre el cliente y el servidor para poder intercambiar mensajes.

Para entender en forma más ordenada y clara los conceptos y elementos involucrados en esta tecnología se puede aplicar una descomposición o arquitectura de niveles. Esta descomposición principalmente consiste en separar los elementos estructurales de esta tecnología en función de aspectos más funcionales de la misma:

Nivel de Presentación: Agrupa a todos los elementos asociados al componente Cliente.
Nivel de Aplicación: Agrupa a todos los elementos asociados al componente Servidor.
Nivel de comunicación: Agrupa a todos los elementos que hacen posible la comunicación entre los componentes Cliente y servidor.
Nivel de base de datos: Agrupa a todas las actividades asociadas al acceso de los datos.

Este modelo de descomposición en niveles, como se verá más adelante, permite introducir más claramente la discusión del desarrollo de aplicaciones en arquitecturas de hardware y software en planos.

ELEMENTOS PRINCIPALES

CLIENTE

Un cliente es todo proceso que reclama servicios de otro. Una definición un poco más elaborada podría ser la siguiente: cliente es el proceso que permite al usuario formular los requerimientos y pasarlos al servidor. Se lo conoce con el término front-end.

Éste normalmente maneja todas las funciones relacionadas con la manipulación y despliegue de datos, por lo que están desarrollados sobre plataformas que permiten construir interfaces gráficas de usuario (GUI), además de acceder a los servicios distribuidos en cualquier parte de la red. Las funciones que lleva a cabo el proceso cliente se resumen en los siguientes puntos:

Administrar la interfaz de usuario.
Interactuar con el usuario.
Procesar la lógica de la aplicación y hacer validaciones locales.
Generar requerimientos de bases de datos.
Recibir resultados del servidor.
Formatear resultados.

La funcionalidad del proceso cliente marca la operativa de la aplicación (flujo de información o lógica de negocio). De este modo el cliente se puede clasificar en:

Cliente basado en aplicación de usuario. Si los datos son de baja interacción y están fuertemente relacionados con la actividad de los usuarios de esos clientes.
Cliente basado en lógica de negocio. Toma datos suministrados por el usuario y/o la base de datos y efectúa los cálculos necesarios según los requerimientos del usuario.

SERVIDOR

Un servidor es todo proceso que proporciona un servicio a otros. Es el proceso encargado de atender a múltiples clientes que hacen peticiones de algún recurso administrado por él. Al proceso servidor se lo conoce con el término back-end. El servidor normalmente maneja todas las funciones relacionadas con la mayoría de las reglas del negocio y los recursos de datos. Las principales funciones que lleva a cabo el proceso servidor se enumeran a continuación:

Aceptar los requerimientos de bases de datos que hacen los clientes.
Procesar requerimientos de bases de datos.
Formatear datos para trasmitirlos a los clientes.
Procesar la lógica de la aplicación y realizar validaciones a nivel de bases de datos.

Puede darse el caso que un servidor actúe a su vez como cliente de otro servidor. Existen numerosos tipos de servidores, cada uno de los cuales da lugar a un tipo de arquitectura Cliente/Servidor diferente.

El término "servidor" se suele utilizar también para designar el hardware, de gran potencia, capacidad y prestaciones, utilizado para albergar servicios que atienden a un gran número de usuarios concurrentes. Desde el punto de vista de la arquitectura cliente/servidor y del procesamiento cooperativo un servidor es un servicio software que atiende las peticiones de procesos software clientes.

MIDDLEWARE

El middleware es un módulo intermedio que actúa como conductor entre sistemas permitiendo a cualquier usuario de sistemas de información comunicarse con varias fuentes de información que se encuentran conectadas por una red. En el caso que nos concierne, es el intermediario entre el cliente y el servidor y se ejecuta en ambas partes.

La utilización del middleware permite desarrollar aplicaciones en arquitectura Cliente/Servidor independizando los servidores y clientes, facilitando la interrelación entre ellos y evitando dependencias de tecnologías propietarias. El concepto de middleware no es un concepto nuevo. Los primeros * monitores de teleproceso* de los grandes sistemas basados en tecnología Cliente/Servidor ya se basaban en él, pero es con el nacimiento de la tecnología basada en sistemas abiertos cuando el concepto de middleware toma su máxima importancia. El middleware se estructura en tres niveles:

Protocolo de transporte.
Network Operating System (NOS).
Protocolo específico del servicio.

Las principales características de un middleware son:

Simplifica el proceso de desarrollo de aplicaciones al independizar los entornos propietarios.
Permite la interconectividad de los Sistemas de Información del Organismo.
Proporciona mayor control del negocio al poder contar con información procedente de distintas plataformas sobre el mismo soporte.
Facilita el desarrollo de sistemas complejos con diferentes tecnologías y arquitecturas.

Dentro de los inconvenientes más importantes destacan la mayor carga de máquina necesaria para que puedan funcionar.

1.2 Modelos de dos y tres capas

Modelo En Dos Capas

En una arquitectura cliente/servidor clásica tenemos dos "capas" (two-tier):

o Una donde está el cliente que implementa la interface.

Otra donde se encuentra el gestor de bases de datos que trata las peticiones recibidas desde el cliente.

La lógica de la aplicación se encuentra por tanto repartida entre el cliente y servidor.

Un ejemplo de esta configuración podría ser un applet Java que se carga en el navegador del cliente y trabaja directamente con la base de datos mediante JDBC.

Figura A: Esquema de arquitectura Cliente/Servidor clásica.

Ventajas de este modelo:

o Se mantiene una conexión persistente con la base de datos.

Se minimizan las peticiones en el servidor trasladándose la mayor parte del trabajo al cliente.
Se gana en rendimiento gracias a la conexión directa y permanente con la base de datos. A través de una única conexión se realiza el envío y recepción de varios datos.

Inconvenientes:

o La más importante desventaja, es que esta solución es muy dependiente del tipo controlador JDBC que se utilice para acceder a la base de datos. El acceso se realiza desde el cliente y esto significa que es él el que tiene que tener instalado en su sistema los controladores necesarios para que se produzca la comunicación con la base de datos.

Además hay que tener en cuenta que el modelo de seguridad de Java impide que desde un applet sin validar (lo que se conoce como untrusted applet), como lo son la mayoría de los que se ejecutan en un navegador, se puedan realizar las siguientes operaciones:

1. El acceso general, y por supesto mediante JDBC, a bases de datos situadas en direcciones URL distintas a las que procede el mismo applet.

La configuración de recursos locales como, por ejemplo, la información de la fuente de datos ODBC para usar el puente JDBC-ODBC.
La descarga de clases nativas, es decir, aquellas cuyo nombre empieza por Java. Esta restricción afecta directamente a los navegadores que utilizan JDK 1.0.2 o anterior, pues JDBC es posterior a esta versión, de forma que las clases apropiadas no estarán instaladas localmente ni podrán ser descargadas de Internet por el applet.

o Finalmente debemos tener en cuenta que es bien conocido que los programas Java pueden ser descompilados muy fácilmente con lo que introducir el acceso a nuestras bases de datos mediante un applet Java conlleva un riesgo considerable en cuanto a la seguridad.

Arquitectura en tres capas

Con la arquitectura cliente/servidor en tres capas (three-tier) añadimos una nueva capa entre el cliente y el servidor donde se implementa la lógica de la aplicación. De esta forma el cliente es básicamente una interface, que no tiene por qué cambiar si cambian las especificaciones de la base de datos o de la aplicación; queda aislado completamente del acceso a los datos.

Así un applet de Java se carga en el navegador del cliente y se comunica con un servlet que corre en la máquina servidor; o bien accedemos a la base de datos a través de un formulario HTML. El servlet establece una conexión a la base de datos mediante JDBC.

En este caso se tiene total libertad para escoger dónde se coloca la lógica de la aplicación: en el cliente, en el servidor de base de datos, o en otro(s) servidor(es). También se tiene total libertad para la elección del lenguaje a utilizar.

Se utiliza un lenguaje de tipo general (probablemente C) por lo que no existen restricciones de funcionalidad.

Los programas serán óptimos desde el punto de vista de la performance.

También deberá implementarse especialmente el Call remoto, lo que seguramente se hará de una forma más libre que los Remote Procedure Call actualmente disponibles.

No existe compromiso alguno con el uso de lenguajes propietarios, por lo que las aplicaciones serán totalmente portables sin cambio alguno.

Puede determinarse en qué servidor(es) se quiere hacer funcionar estos procedimientos. En aplicaciones críticas se pueden agregar tantos servidores de aplicación como sean necesarios, de forma simple, y sin comprometer en absoluto la integridad de la base de datos, obteniéndose una escalabilidad muy grande sin necesidad de tocar el servidor de dicha base de datos.

El problema de esta arquitectura es ¿cómo se implementa?. Parece ilusorio tratar de programar manualmente estos procedimientos, mientras que, si se dispone de una herramienta que lo hace automáticamente, presenta ventajas claras sobre la alternativa anterior:

Figura B: Arquitectura Cliente/Servidor en tres capas (three-tier)

Como se podría esperar cada uno de los componentes de la aplicación en una arquitectura three-tier se separa en una sola entidad. Esto te permite implementar componentes de una manera más flexible. Algo que no creo que sorprenda es la afirmación de que este tipo de arquitectura es la más compleja.

Figura 4. Arquitectura Three-Tier.

En esta Arquitectura todas las peticiones de los clientes se controlan en la capa correspondiente a la lógica del negocio. Cuando el cliente necesita hacer una petición se la hace a la capa en la que se encuentra la lógica del negocio. Esto es bastante importante pues eso quiere decir que:

1.- El cliente no tiene que tener drivers ODBCni la problemática consiguiente de instalación de los drivers por tanto se reduce el costo de mantener las aplicaciones cliente
2.- El Cliente y el Gestor de Reglas de negocio tienen que hablar el mismo lenguaje (en nuestro caso COM)
3.- El Gestor de Reglas de Negocio y el Servidor de Datos tienen que hablar el mismo lenguaje (en nuestro caso ODBC)

Lo ideal sería que el Gestor de Reglas de Negocio no sólo OLE y ODBC sino otros estandares como DBLib, OLI, DRDA, SQL/API y X/Open

Ventajas de este modelo:

o No existe ningún problema con respecto al tipo de controlador JDBC utilizado para acceder a la base de datos.Todos los recursos necesarios para establecer la conexión con la base de datos se encuentran en el servidor y por tanto, el cliente no necesita instalar nada adicional en su máquina para poder acceder a la base de datos.

Esta arquitectura proporciona considerables mejoras desde el punto de vista de la portabilidad de la aplicación, escalabilidad, robustez y reutilización del código. Asimismo facilita las tareas de migración o cambios en el sistema gestor de la base de datos.
Desaparecen las restricciones debidas a las limitaciones de los applets impuestas por el modelo de seguridad de Java.

Inconvenientes:

o Esta solución es algo menos eficiente que la del modelo de dos capas, ya que hemos añadido una capa intermedia más de software.

1.3 Usos y aplicaciones

Tipos de sistemas de los Cliente-Servidor dependiendo de las aplicaciones que el servidor pone a disposición de los clientes.

• Servidores de Impresión, mediante el cual los usuarios comparten impresoras.

• Servidores de Archivos, con el cual los clientes comparten discos duros.

•Servidores de Bases de Datos, donde existe una única base de datos.

• Servidores de Lotus Notes, que permite el trabajo simultáneo de distintos clientes con los mismos datos, documentos o modelos.

• Servidores Web, también utilizan la tecnología Cliente- Servidor, aunque añaden aspectos nuevos y propios a la misma.

Algunos servidores esperan las solicitudes en puertos bien conocidos de modo que sus clientes saben a que zócalo IP deben dirigir sus peticiones. El cliente emplea un puerto arbitrario para comunicarse. Los clientes que se quieren comunicar con un servidor que no usa un puerto bien conocido tienen otro mecanismo para saber a qué puerto dirigirse. Este mecanismo podría usar un servicio de registro como Portmap, que utiliza un puerto bien conocido.

1.4 Comunicaciones entre programas

El proceso para la creacion de un servicio siempre comienza con la creacion del Socker. Asi como el cliente necesita llamadas especificas en determinados mometos, el servidor trabajo de modo similar pero añade unas pocas llamadas extras al sistema. El servidor utiliza la llamada del sistema Socket(), pero debe hacer un trabajo extra que era opcional para el cliente,

el cliente simpre realiza un a conexión activa porque la persigue energicamente
los servidores por otro lado necesitan proporcionar un numero de puesto especifico y consiste a los programas clientes si les va a prestar servicio. El programa servido que escriba debera utilizar las llamadas de sistema socker(), bind(), listen(), accept(). Y mientras el programa cliente es una conexión activa,el servidor es una conexión pasiva. Las llamadas de isistemas() y accept() crean una coneccion solo cuando el cliente pide una conexión (similar a la accion de responder al timbre de un telefono

El ejemplo de servidor escucha en un socket (puerto 8000) esperando peticiones entrantes. Cualquier programa, como el client.c de ejemplo, puede conectar con este servidor y pasarle hasta 16.384 hytes de datos
El servidor trata los datos como datos ASCII y los convierte en mayúsculas antes de pasárselos a! programa cliente.
Estos dos sencillos programas se pueden volver a utilizar fácilmente cuando se escriban programas cliente-servidor basados en socket

Los servidores que pueden recibir muchas peticiones simultáneas utilizan fork para crear un proceso separado para la administración de peticiones de servicio constitucionalmente caras.
server.c crea un socket permanente para la escucha de peticiones de servicio; cuando un cliente conecta con el servidor, se crea un socket temporal. Cada vez que un cliente conecta con un servidor, se abre un nuevo socket temporal entre el cliente y el servidor.

1.5 Modelos de computacion distribuida

1.5.1 RMI

RMI (Java Remote Method Invocation) es un mecanismo ofrecido por Java para invocar un método de manera remota. Forma parte del entorno estándar de ejecución de Java y proporciona un mecanismo simple para la comunicación de servidores en aplicaciones distribuidas basadas exclusivamente en Java. Si se requiere comunicación entre otras tecnologías debe utilizarse CORBAo SOAP en lugar de RMI.

RMI se caracteriza por la facilidad de su uso en la programación por estar específicamente diseñado para Java; proporciona paso de objetos por referencia (no permitido por SOAP), recolección de basura distribuida (Garbage Collector distribuido) y paso de tipos arbitrarios (funcionalidad no provista por CORBA).

A través de RMI, un programa Java puede exportar un objeto, con lo que dicho objeto estará accesible a través de la red y el programa permanece a la espera de peticiones en un puerto TCP. A partir de ese momento, un cliente puede conectarse e invocar los métodos proporcionados por el objeto.

La invocación se compone de los siguientes pasos:

Encapsulado (marshalling) de los parámetros (utilizando la funcionalidad de serialización de Java).
Invocación del método (del cliente sobre el servidor). El invocador se queda esperando una respuesta.
Al terminar la ejecución, el servidor serializa el valor de retorno (si lo hay) y lo envía al cliente.
El código cliente recibe la respuesta y continúa como si la invocación hubiera sido local.

1.5.2 COM/DCOM

1. COM / DCOM

Como DCOM es una evolución lógica de COM, se pueden utilizar los componentes creados en aplicaciones basadas en COM, y trasladarlas a entornos distribuidos. DCOM maneja detales muy bajos de protocolos de red, por lo que uno se puede centrar en la realidad de los negocios: proporcionar soluciones a clientes.

Atualmente DCOM viene con los sistemas operativos Windows 2000, NT, 98 y también está disponible una versión para Windows 95 en la página de Microsoft. También hay una implementación de DCOM para Apple Macintosh y se está trabajando en implementaciones para plataformas UNIX como Solaris.

1.1 La arquitectura DCOM

DCOM es una extensión de COM, y éste define como los componentes y sus clientes interactuan entre sí. Esta interacción es definida de tal manera que el cliente y el componente puede conectar sin la necesidad de un sistema intermedio. El cliente llama a los métodos del componente sin tener que preocuparse de niveles más complejos

En los actuales sistemas operativos, los procesos están separados unos de otros. Un cliente que necesita comunicarse con un componente en otro proceso no puede llamarlo directamente, y tendrá que utilizar alguna forma de comunicación entre procesos que proporcione el sistema operativo. COM proporciona este tipo de comunicación de una forma transparente: intercepta las llamadas del cliente y las reenvía al componente que está en otro proceso.

Las librería de COM proporcionan servicios orientados a objetos a los clientes y componentes, y utilizan RPC y un proveedor de seguridad para generar paquetes de red estándar que entienda el protocolo estándar de DCOM.

1.2 Los Componentes y su reutilización

Muchas aplicaciones distribuidas no están desarrolladas

Al existir infraestructuras de hardware, software, componentes, al igual que herramientas, se necesita poder integrarlas y nivelarlas para reducir el desarrollo y el tiempo de trabajo y coste. DCOM toma ventaja de forma directa y transparente de los componentes COM y herramientas ya existentes. Un gran mercado de todos los componentes disponibles haría posible reducir el tiempo de desarrollo integrando soluciones estandarizadas en las aplicaciones de usuario. Muchos desarrolladores están familiarizados con COM y pueden aplicar fácilmente sus conocimientos a las aplicaciones distribuidas basadas en DCOM.

Cualquier componente que sea desarrollado como una parte de una aplicación distribuida es un candidato para ser reutilizado. Organizando los procesos de desarrollo alrededor del paradigma de los componentes permite continuar aumentando el nivel de funcionalidad en las nuevas aplicaciones y reducir el tiempo de desarrollo.

Diseñando para COM y DCOM se asegura que los componentes creados serán útiles ahora y en el futuro.

1.3 Independencia de la localización

Cuando se comienza a implementar una aplicación distribuida en una red reak, aparecen distintos conflictos en el diseño:

Los componentes que interactuan más a menudo deberían estar localizados más cerca.
Algunos componentes solo pueden ser ejecutados en máquinas específicas o lugares específicos.
Los componentes más pequeños aumentan la flexibilidad, pero aumentan el tráfico de red.
Los componentes grandes reducen el tráfico de red, pero también reducen la flexibilidad.

La independencia de localización en DCOM simplifica enormemente las tarea de los componentes de aplicaciones distribuidas para alcanzar un nivel de funcionamiento óptimo. Supongamos, por ejemplo, que cierto componente debe ser localizado en una máquina específica en un lugar determinado. Si la aplicación tiene numerosos componentes pequeños, se puede reducir la carga de la red situándolos en la misma LAN, en la misma máquina, o incluso en el mismo proceso. Si la aplicación está compuesta por un pequeño número de grandes componentes, la carga de red es menor y no es un problema, por tanto se pueden poner en las máquinas más rápidas disponibles independientemente de donde esten situadas.

Con la independencia de localización de DCOM, la aplicación puede combinar componentes relacionados en máquinas "cercanas" entre si, en una sola máquina o incluso en el mismo proceso. Incluso si un gran número de pequeños componentes implementan la funcionalidad de un gran módulo lógico, podrán interactuar eficientemente entre ellos.

1.4 Independencia del lenguaje de programación

Con la independencia de lenguaje de DCOM, los desarrolladores de aplicaciones puede elegir las herramientas y lenguajes con los que estén más familiarizados. La independencia del lenguaje permite crear componentes en lenguajes de nivel superior como Microsoft Visual Basic, y después reimplementarlos en distintos lenguajes como C++ o Java, que permiten tomar ventaja de características avanzadas como multihilo.

1.5 Independencia del protocolo

DCOM proporciona esta transparencia: DCOM puede utilizar cualquier protocolo de transporte, como TCP/IP, UDP, IPX/SPX y NetBIOS. DCOM proporciona un marco de seguridad a todos estos protocolos.

Los desarrolladores pueden simplemente utilizar las características proporcionadas por DCOM y asegurar que sus aplicaciones son completamente independiente del protocolo.

1.5.3 Servicios WEB

Un servicio web (en inglés, Web Service o Web services) es una tecnología 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. Es una máquina que atiende las peticiones de los clientes web y les envía los recursos solicitados.

Unidad 2 Programación Cliente/Servidor de bajo nivel Sockets y Canales

Los sockets no son más que puntos o mecanismos de comunicación entre procesos que permiten que un proceso hable ( emita o reciba información ) con otro proceso incluso estando estos procesos en distintas máquinas. Esta característica de interconectividad entre máquinas hace que el concepto de socket nos sirva de gran utilidad. Esta interfaz de comunicaciones es una de las distribuciones de Berkeley al sistema UNIX, implementándose las utilidades de interconectividad de este Sistema Operativo ( rlogin, telnet, ftp, ... ) usando sockets.

     Un socket es al sistema de comunicación entre ordenadores lo que un buzón o un teléfono es al sistema de comunicación entre personas: un punto de comunicación entre dos agentes ( procesos o personas respectivamente ) por el cual se puede emitir o recibir información. La forma de referenciar un socket por los procesos implicados es mediante undescriptor del mismo tipo que el utilizado para referenciar ficheros. Debido a esta característica, se podrá realizar redirecciones de los archivos de E/S estándar (descriptores 0,1 y 2) a los sockets y así combinar entre ellos aplicaciones de la red. Todo nuevo proceso creado heredará, por tanto, los descriptores de sockets de su padre.

     La comunicación entre procesos a través de sockets se basa en la filosofía CLIENTE-SERVIDOR: un proceso en esta comunicación actuará de proceso servidor creando un socket cuyo nombre conocerá el proceso cliente, el cual podrá "hablar" con el proceso servidor a través de la conexión con dicho socket nombrado.

     El proceso crea un socket sin nombre cuyo valor de vuelta es un descriptor sobre el que se leerá o escribirá, permitiéndose una comunicación bidireccional, característica propia de los sockets y que los diferencia de los pipes, o canales de comunicación unidireccional entre procesos de una misma máquina. El mecanismo de comunicación vía sockets tiene los siguientes pasos:

     1º) El proceso servidor crea un socket con nombre y espera la
          conexión.
     2º) El proceso cliente crea un socket sin nombre.
     3º) El proceso cliente realiza una petición de conexión al socket
          servidor.
     4º) El cliente realiza la conexión a través de su socket mientras el
          proceso servidor mantiene el socket servidor original con
          nombre.

     Es muy común en este tipo de comunicación lanzar un proceso hijo, una vez realizada la conexión, que se ocupe del intercambio de información con el proceso cliente mientras el proceso padre servidor sigue aceptando conexiones. Para eliminar esta característica se cerrará el descriptor del socket servidor con nombre en cuanto realice una conexión con un proceso socket cliente.

-> Todo socket viene definido por dos características fundamentales:

     - El tipo del socket, que indica la naturaleza del mismo, el tipo de comunicación que puede generarse entre los sockets.

     - El dominio del socket especifica el conjunto de sockets que pueden establecer una comunicación con el mismo.

Vamos a estudiar con más detalle estos dos aspectos:

4.1.- Tipos de sockets.

     Define las propiedades de las comunicaciones en las que se ve envuelto un socket, esto es, el tipo de comunicación que se puede dar entre cliente y servidor. Estas pueden ser:
     - Fiabilidad de transmisión.
     - Mantenimiento del orden de los datos.
     - No duplicación de los datos.
     - El "Modo Conectado" en la comunicación.
     - Envío de mensajes urgentes.

Los tipos disponibles son los siguientes:

     * Tipo SOCK_DGRAM:     sockets para comunicaciones en modo no conectado, con envío de datagramas de tamaño limitado ( tipo telegrama ). En dominios Internet como la que nos ocupa el protocolo del nivel de transporte sobre el que se basa es el UDP.

     * Tipo SOCK_STREAM:     para comunicaciones fiables en modo conectado, de dos vías y con tamaño variable de los mensajes de datos. Por debajo, en dominios Internet, subyace el protocolo TCP.

     * Tipo SOCK_RAW:     permite el acceso a protocolos de más bajo nivel como el IP ( nivel de red )

     * Tipo SOCK_SEQPACKET: tiene las características del    SOCK_STREAM pero además el tamaño de los mensajes es fijo.

4.2.- El dominio de un socket.

     Indica el formato de las direcciones que podrán tomar los sockets y los protocolos que soportarán dichos sockets.
     La estructura genérica es

     struct sockaddr {
               u__short     sa__family;         /* familia */
               char         sa__data[14];       /* dirección */
          };

Pueden ser:

     * Dominio AF_UNIX ( Address Family UNIX ):

               El cliente y el servidor deben estar en la misma máquina. Debe incluirse el fichero cabecera /usr/include/sys/un.h. La estructura de una dirección en este dominio es:
               struct sockaddr__un {
               short          sun__family; /* en este caso AF_UNIX */
               char          sun__data[108]; /* dirección */
                    };

     * Dominio AF_INET ( Address Family INET ):
               El cliente y el servidor pueden estar en cualquier máquina de la red Internet. Deben incluirse los ficheros cabecera /usr/include/netinet/in.h, /usr/include/arpa/inet.h, /usr/include/netdb.h. La estructura de una dirección en este dominio es:

               struct in__addr {
                    u__long     s__addr;
               };

               struct sockaddr__in {
               short          sin_family; /* en este caso AF_INET */
               u__short     sin_port;   /* numero del puerto */
               struct in__addr          sin__addr; /* direcc Internet */
               char          sin_zero[8];    /* campo de 8 ceros */
                    };

          Estos dominios van a ser los utilizados en xshine. Pero existen otros como:
     * Dominio AF_NS:
          Servidor y cliente deben estar en una red XEROX.
     * Dominio AF_CCITT:
          Para protocolos CCITT, protocolos X25, .

Unidad 3 RMI (Remote Method Invocation)

Desde la versión 1.1 de JDK, Java tiene su propio ORB: RMI (Remote Method Invocation). A pesar de que RMI es un ORB en el sentido general, no es un modelo compatible con CORBA. RMI es nativo de Java, es decir, es una extensión al núcleo del lenguaje. RMI depende totalmente del núcleo de la Serialización de Objetos de Java, así como de la implementación tanto de la portabilidad como de los mecanismos de carga y descarga de objetos en otros sistemas, etc.

El uso de RMI resulta muy natural para todo aquel programador de Java ya que éste no tiene que aprender una nueva tecnología completamente distinta de aquella con la cual desarrollará. Sin embargo, RMI tiene algunas limitaciones debido a su estrecha integración con Java, la principal de ellas es que esta tecnología no permite la interacción con aplicaciones escritas en otro lenguaje.

RMI como extensión de Java, es una tecnología de programación, fue diseñada para resolver problemas escribiendo y organizando código ejecutable. Así RMI constituye un punto específico en el espacio de las tecnologías de programación junto con C, C++, Smalltalk, etc.

La principal diferencia de utilizar RPC o RMI, es que RMI es un mecanismo para invocación remota de procedmientos basado en el lenguaje de programación Java que soporta interacción entre objetos, mientras que RPC no soporta esta característica.

Arquitectura

La arquitectura RMI puede verse como un modelo de cuatro capas.

Primera capa

La primera capa es la de aplicación y se corresponde con la implementación real de las aplicaciones cliente y servidor. Aquí tienen lugar las llamadas a alto nivel para acceder y exportar objetos remotos. Cualquier aplicación que quiera que sus métodos estén disponibles para su acceso por clientes remotos debe declarar dichos métodos en una interfaz que extienda java.rmi.Remote. Dicha interfaz se usa básicamente para "marcar" un objeto como remotamente accesible. Una vez que los métodos han sido implementados, el objeto debe ser exportado. Esto puede hacerse de forma implícita si el objeto extiende la clase UnicastRemoteObject (paquete java.rmi.server), o puede hacerse de forma explícita con una llamada al método exportObject() del mismo paquete.

Segunda capa

La capa 2 es la capa proxy, o capa stub-skeleton. Esta capa es la que interactúa directamente con la capa de aplicación. Todas las llamadas a objetos remotos y acciones junto con sus parámetros y retorno de objetos tienen lugar en esta capa.

Tercera capa

La capa 3 es la de referencia remota, y es responsable del manejo de la parte semántica de las invocaciones remotas. También es responsable de la gestión de la replicación de objetos y realización de tareas específicas de la implementación con los objetos remotos, como el establecimiento de las persistencias semánticas y estrategias adecuadas para la recuperación de conexiones perdidas. En esta capa se espera una conexión de tipo stream (stream-oriented connection) desde la capa de transporte.

Cuarta Capa

La capa 4 es la de transporte. Es la responsable de realizar las conexiones necesarias y manejo del transporte de los datos de una máquina a otra. El protocolo de transporte subyacente para RMI es JRMP (Java Remote Method Protocol), que solamente es "comprendido" por programas Java.

Elementos

Toda aplicación RMI normalmente se descompone en 2 partes:

Un servidor, que crea algunos objetos remotos, crea referencias para hacerlos accesibles, y espera a que el cliente los invoque.
Un cliente, que obtiene una referencia a objetos remotos en el servidor, y los invoca.

Ejemplo

Un servidor RMI consiste en definir un objeto remoto que va a ser utilizado por los clientes. Para crear un objeto remoto, se define una interfaz, y el objeto remoto será una clase que implemente dicha interfaz. Veamos como crear un servidor de ejemplo mediante 3 pasos:

Definir la interfaz remota. Cuando se crea una interfaz remota:

La interfaz debe ser pública.
Debe heredar de la interfaz java.rmi.Remote, para indicar que puede llamarse desde cualquier máquina virtual Java.
Cada método remoto debe lanzar la excepción java.rmi.RemoteException en su cláusula throws, además de las excepciones que pueda manejar.

public interface MiInterfazRemota extends java.rmi.Remote

{

public void miMetodo1() throws java.rmi.RemoteException;

public int miMetodo2() throws java.rmi.RemoteException;

}

Implementar la interfaz remota

public class MiClaseRemota

extends java.rmi.server.UnicastRemoteObject

implements MiInterfazRemota

{

public MiClaseRemota() throws java.rmi.RemoteException

{

// Código del constructor

}

public void miMetodo1() throws java.rmi.RemoteException

{

// Aquí ponemos el código que queramos

System.out.println("Estoy en miMetodo1()");

}

public int miMetodo2() throws java.rmi.RemoteException

{

return 5; // Aquí ponemos el código que queramos

}

public void otroMetodo()

{

// Si definimos otro método, éste no podría llamarse

// remotamente al no ser de la interfaz remota

}

public static void main(String[] args)

{

try

{

MiInterfazRemota mir = new MiClaseRemota();

java.rmi.Naming.rebind("//" + java.net.InetAddress.getLocalHost().getHostAddress() +

":" + args[0] + "/PruebaRMI", mir);

}

catch (Exception e)

{

}

Como se puede observar, la clase MiClaseRemota implementa la interfaz MiInterfazRemota que hemos definido previamente. Además, hereda de UnicastRemoteObject, que es una clase de Java que podemos utilizar como superclase para implementar objetos remotos.
Luego, dentro de la clase, definimos un constructor (que lanza la excepción RemoteException porque también la lanza la superclase UnicastRemoteObject), y los métodos de la/las interfaz/interfaces que implemente.
Finalmente, en el método main, definimos el código para crear el objeto remoto que se quiere compartir y hacer el objeto remoto visible para los clientes, mediante la clase Naming y su método rebind(...).

Nota: Hemos puesto el método main() dentro de la misma clase por comodidad. Podría definirse otra clase aparte que fuera la encargada de registrar el objeto remoto.

Compilar y ejecutar el servidor

Ya tenemos definido el servidor. Ahora tenemos que compilar sus clases mediante los siguientes pasos:

Compilamos la interfaz remota. Además lo agrupamos en un fichero JAR para tenerlo presente tanto en el cliente como en el servidor:

javac MiInterfazRemota.java

jar cvf objRemotos.jar MiInterfazRemota.class

Luego, compilamos las clases que implementen las interfaces. Y para cada una de ellas generamos los ficheros Stub y Skeleton para mantener la referencia con el objeto remoto, mediante el comando rmic:

set CLASSPATH=%CLASSPATH%;.\objRemotos.jar;.

javac MiClaseRemota.java

rmic -d . MiClaseRemota

Observamos en nuestro directorio de trabajo que se han generado automáticamente dos ficheros.class (MiClaseRemota_Skel.class y MiClaseRemota_Stub.class) correspondientes a la capa stub-skeleton de la arquitectura RMI.

Para ejecutar el servidor, seguimos los siguientes pasos:

Se arranca el registro de RMI para permitir registrar y buscar objetos remotos. El registro se encarga de gestionar un conjunto de objetos remotos a compartir, y buscarlos ante las peticiones de los clientes. Se ejecuta con la aplicación rmiregistry distribuida con Java, a la que le podemos pasar opcionalmente el puerto por el que conectar (por defecto, el 1099).

En el caso de Windows, se debe ejecutar:

start rmiregistry 1234

Y en el caso de Linux:

rmiregistry &

Por último, se lanza el servidor:

java -Djava.rmi.server.hostname=127.0.0.1 MiClaseRemota 1234

Crear un cliente RMI

Vamos ahora a definir un cliente que accederá a el/los objeto/s remoto/s que creemos. Para ello seguimos los siguientes pasos:

Definir la clase para obtener los objetos remotos necesarios

La siguiente clase obtiene un objeto de tipo MiInterfazRemota, implementado en nuestro servidor:

public class MiClienteRMI

{

private MiClienteRMI(){};

public static void main(String[] args)

{

try

{

MiInterfazRemota mir = (MiInterfazRemota)java.rmi.Naming.lookup("//" +

args[0] + ":" + args[1] + "/PruebaRMI");

// Imprimimos miMetodo1() tantas veces como devuelva miMetodo2()

for (int i=1;i<=mir.miMetodo2();i++)

mir.miMetodo1();

}

catch (Exception e)

{

e.printStackTrace();

}

Como se puede observar, simplemente consiste en buscar el objeto remoto en el registro RMI de la máquina remota. Para ello usamos la clase Naming y su método lookup(...).

Compilar y ejecutar el cliente

Una vez que ya tenemos definido el cliente, para compilarlo hacemos:

set CLASSPATH=%CLASSPATH%;.\objRemotos.jar;.

javac MiClienteRMI.java

Luego, para ejecutar el cliente hacemos:

java MiClienteRMI 127.0.0.1 1234

Se debe poder acceder al fichero Stub de la clase remota. Para ello, o bien lo copiamos al cliente y lo incluimos en su CLASSPATH, o lo eliminamos del CLASSPATH del servidor e incluimos su ruta en el java.rmi.codebase del servidor (si no se elimina del CLASSPATH del servidor, se ignorará la opción java.rmi.codebase, y el cliente no podrá acceder al Stub).. Si echamos un vistazo a la ventana donde está ejecutándose el servidor RMI, veremos como se ha encontrado el objeto remoto y ejecutado sus métodos.

Unidad 4 COM y DCOM

Microsoft Distributed COM (DCOM) extiende COM (Component Object Model) para soportar comunicación entre objetos en ordenadores distintos, en una LAN, WAN, o incluso en Internet. Con DCOM una aplicación puede ser distribuida en lugares que dan más sentido al cliente y a la aplicación.
Como DCOM es una evolución lógica de COM, se pueden utilizar los componentes creados en aplicaciones basadas en COM, y trasladarlas a entornos distribuidos. DCOM maneja detales muy bajos de protocolos de red, por lo que uno se puede centrar en la realidad de los negocios: proporcionar soluciones a clientes.

Donde conseguir DCOM

La arquitectura DCOM

Figura 1. Componentes COM en el mismo proceso.

Figure 2. Componentes COM en procesos distintos.

Cuando el cliente y el componente residen en distintas máquinas, DCOM simplemente reemplaza la comunicación entre procesos locales por un protocolo de red. Ni el cliente ni el componente se enteran de que la unión que los conecta es ahora un poco más grande.
La Figura 3 representa la arquitectura DCOM en su conjunto: Las librería de COM proporcionan servicios orientados a objetos a los clientes y componentes, y utilizan RPC y un proveedor de seguridad para generar paquetes de red estándar que entienda el protocolo estándar de DCOM.

Figura 3. DCOM: componentes COM en distintas máquinas.

Los Componentes y su reutilización

Muchas aplicaciones distribuidas no están desarrolladas
Al existir infraestructuras de hardware, software, componentes, al igual que herramientas, se necesita poder integrarlas y nivelarlas para reducir el desarrollo y el tiempo de trabajo y coste. DCOM toma ventaja de forma directa y transparente de los componentes COM y herramientas ya existentes. Un gran mercado de todos los componentes disponibles haría posible reducir el tiempo de desarrollo integrando soluciones estandarizadas en las aplicaciones de usuario. Muchos desarrolladores están familiarizados con COM y pueden aplicar fácilmente sus conocimientos a las aplicaciones distribuidas basadas en DCOM.
Cualquier componente que sea desarrollado como una parte de una aplicación distribuida es un candidato para ser reutilizado. Organizando los procesos de desarrollo alrededor del paradigma de los componentes permite continuar aumentando el nivel de funcionalidad en las nuevas aplicaciones y reducir el tiempo de desarrollo.
Diseñando para COM y DCOM se asegura que los componentes creados serán útiles ahora y en el futuro.

Independencia de la localización

Cuando se comienza a implementar una aplicación distribuida en una red reak, aparecen distintos conflictos en el diseño:

· Los componentes que interactuan más a menudo deberían estar localizados más cerca.

· Algunos componentes solo pueden ser ejecutados en máquinas específicas o lugares específicos.

· Los componentes más pequeños aumentan la flexibilidad, pero aumentan el tráfico de red.

· Los componentes grandes reducen el tráfico de red, pero también reducen la flexibilidad.

Con DCOM, estos temas críticos de diseño pueden ser tratados se forma bastante sencilla, ya que estos detalles no se especifican en el código fuente. DCOM olvida completamente la localización de los componentes, ya esté en el mismo proceso que el cliente o en una máquina en cualquier lugar del mundo. En cualquier caso, la forma en la que el cliente se conecta a un componente y llama a los métodos de éste es identica. No es solo que DCOM no necesite cambios en el código fuente, sino que además no necesita que el programa sea recompilado. Una simple reconfiguración cambia la forma en la que los componentes se conectan entre sí.
La independencia de localización en DCOM simplifica enormemente las tarea de los componentes de aplicaciones distribuidas para alcanzar un nivel de funcionamiento óptimo. Supongamos, por ejemplo, que cierto componente debe ser localizado en una máquina específica en un lugar determinado. Si la aplicación tiene numerosos componentes pequeños, se puede reducir la carga de la red situándolos en la misma LAN, en la misma máquina, o incluso en el mismo proceso. Si la aplicación está compuesta por un pequeño número de grandes componentes, la carga de red es menor y no es un problema, por tanto se pueden poner en las máquinas más rápidas disponibles independientemente de donde esten situadas.
La Figura 4 representa como un "componente de validación" puede ser situado en la misma máquina, cuando el ancho de red entre la máquina "cliente" y la máquina "middle-tier" es suficiente, y en la máquina "servidor", cuando el cliente accede a la aplicación a través de una red lenta.

Figura 4. Independencia de localización

Independencia del lenguaje de programación

Una cuestión importante durante el diseño e implementación de una aplicación distribuida es la elección del lenguaje o herramienta de programación. La elección es generalmente un termino medio entre el coste de desarrollo, la experiencia disponible y la funcionalidad. Como una extensión de COM, DCOM es completamente independiente del lenguaje. Virtualmentem cualquier lenguaje puede ser utilizado para crear componentes COM, y estos componentes puede ser utilizado por muchos más lenguajes y herramientas. Java, Microsoft Visual C++, Microsoft Visual Basic, Delphi, PowerBuilder, y Micro Focus COBOL interactuan perfectamente con DCOM.
Con la independencia de lenguaje de DCOM, los desarrolladores de aplicaciones puede elegir las herramientas y lenguajes con los que estén más familiarizados. La independencia del lenguaje permite crear componentes en lenguajes de nivel superior como Microsoft Visual Basic, y después reimplementarlos en distintos lenguajes como C++ o Java, que permiten tomar ventaja de características avanzadas como multihilo.

Independencia del protocolo

Muchas aplicaciones distribuidas tienen que ser integradas en la infraestructura de una red existente. Necesitar un protocolo específico de red, obligará a mejorar todos los cliente, lo que es inaceptable en muchas situaciones. Los desarrolladores de aplicaciones tienen que tener cuidado de mantener la aplicación lo más independiente posible de la infraestructura de la red.
DCOM proporciona esta transparencia: DCOM puede utilizar cualquier protocolo de transporte, como TCP/IP, UDP, IPX/SPX y NetBIOS. DCOM proporciona un marco de seguridad a todos estos protocolos.
Los desarrolladores pueden simplemente utilizar las características proporcionadas por DCOM y asegurar que sus aplicaciones son completamente independiente del protocolo.

Unidad 5 Servicios Web XML

Un servicio web XML es una entidad programable que proporciona un elemento determinado de funcionalidad, como lógica de la aplicación y es accesible por diversos sistemas potencialmente dispares usando los estándares de Internet ubicuos, como XML y HTTP. Los servicios web XML dependen en gran medida de la amplia aceptación de XML y otros estándares de Internet para crear una infraestructura que admita la interoperabilidad de aplicaciones en un nivel que resuelva muchos de los problemas que anteriormente impidieron tales intentos.

Un servicio web XML puede usarse internamente por una sola aplicación o exponerse externamente a través de Internet para su uso por diversas aplicaciones. Puesto que es accesible a través de una interfaz estándar, un servicio web XML permite a sistemas heterogéneos funcionar juntos como una sencilla web de cálculo.

En lugar de seguir las funciones genéricas de portabilidad de código, los servicios web XML proporcionan una solución viable para habilitar los datos y la interoperabilidad del sistema. Los servicios web XML usan la mensajería basada en XML como un medio fundamental para la comunicación de datos y ayudar a salvar las diferencias que existen entre los sistemas que usan modelos de componentes, sistemas operativos y lenguajes de programación incongruentes. Los programadores pueden crear aplicaciones que desarrollen juntas servicios web XML de varios orígenes de la misma manera que usan tradicionalmente los componentes para crear una aplicación distribuida.

Una de las características básicas de un servicio web XML es el alto grado de abstracción que existe entre la implementación y el uso de un servicio. Al usar la mensajería basada en XML como el mecanismo para crear y tener acceso al servicio, el cliente y el proveedor del servicio web XML se liberan de la mutua necesidad de tener información de las entradas, las salidas y la ubicación.

Los servicios web XML habilitan una nueva era de desarrollo de aplicaciones distribuidas. Ya no se trata de una guerra de modelos de objetos o concursos de belleza de lenguajes de programación. Cuando los sistemas cooperan estrechamente usando infraestructuras de propietario, esto se hace con cargo a la interoperabilidad de la aplicación. Los servicios web XML proporcionan la interoperabilidad en un nivel completamente nuevo que niega tales rivalidades contraproducentes. El próximo avance revolucionario de Internet será que los servicios web XML se convertirán en la estructura fundamental que vincule juntos los dispositivos informáticos.

SOAP Simpli Object Access Protocol

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. Está actualmente bajo el auspicio de la W3C. Es uno de los protocolos utilizados en los servicios Web.

en una base de datos, indicando los parámetros necesitados en la consulta. El sitio podría retornar un documento formateado en XML con el resultado, ejemplo, precios, localización, características. Teniendo los datos de respuesta en un formato estandarizado "parseable", este puede ser integrado directamente en un sitio Web o aplicación externa.

La arquitectura SOAP consiste de muchas capas de especificación: para el formato del mensaje, MEP (Message Exchange Patterns), subyacentes enlaces de protocolo de transporte, modelo de procesamiento de mensajes, y extensibilidad del protocolo. SOAP es el sucesor de XML-RPC, a pesar de que toma el transporte y la neutralidad de la interacción y el envelope / header /body de otra parte (probablemente de WDDX).

Historia

SOAP fue diseñado como un protocolo de acceso a objetos en 1998 por David Winer, Don Box, Bob Atkinson y Mohsen Al-Ghosein por Microsoft, donde Atkinson y Al-Ghosein trabajaban en aquel entonces. La especificación SOAP actualmente es mantenida por el XML Protocol Working Group del World Wide Web Consortium.

SOAP originalmente significaba "Simple Object Access Protocol", pero esta sigla se abandonó con la versión 1.2 de la norma. La versión 1.2 se convirtió en una recomendación del W3C el 24 de junio de 2003. El acrónimo se confunde a veces con SOA, siglas de arquitectura orientada a servicios, pero las siglas no están relacionados.

Después que SOAP se introdujo por primera vez, se convirtió en la capa subyacente de un conjunto más complejo de los web services, basada en la WSDL (Web Services Description Language) y UDDI (Universal Description Discovery and Integration). Estos servicios, especialmente UDDI, han demostrado ser de mucho menos interés, pero una apreciación de ellos da una comprensión más completa del esperado rol de SOAP comparado a como los web services están actualmente desarrollados.

SOAP

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).

WSDL

WSDL son las siglas de Web Services Description Language, un formato XML que se utiliza para describir servicios Web . 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.

UDDI

UDDI son las siglas del catálogo de negocios de Internet denominado Universal Description, Discovery and Integration. El registro en el catálogo se hace en XML. UDDI es una iniciativa industrial abierta (sufragada por la OASIS) 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.

SOAP puede formar la capa base de una "pila de protocolos de web service", ofreciendo un framework de mensajería básica en la cual los web services se puedan construir. Este protocolo basado en XML consiste de tres partes: un sobre (envelope), el cual define qué hay en el mensaje y cómo procesarlo; un conjunto de reglas de codificación para expresar instancias de tipos de datos; y una convención para representar llamadas a procedimientos y respuestas. El protocolo SOAP tiene tres características principales:

· Extensibilidad (seguridad y WS-routing son extensiones aplicadas en el desarrollo).

· Neutralidad (SOAP puede ser utilizado sobre cualquier protocolo de transporte como HTTP, SMTP, TCP o JMS).

· Independencia (SOAP permite cualquier modelo de programación).

Como ejemplo de cómo los procedimientos SOAP pueden ser utilizados, un mensaje SOAP podría ser enviado a un sitio Web que tiene habilitado Web service, para realizar la búsqueda de algún precio