Diseño de Software Orientado a “SERVICIOS WEB”

Fundación Politécnica de Cataluña Master en Ingeniería del Software Proyecto Final ��

�

Diseño de Software Orientado a “SERVICIOS WEB”

Una Introducción �

��

Alumnos: Erika Febres U. Jimmy A. Useche V. Johann H. Granados U.

Fundación Politécnica de Cataluña Master en Ingeniería del Software

Servicios Web 2

Tabla de contenidos Tabla de contenidos ................................................................................................................ 2 INTRODUCCIÓN.................................................................................................................. 5

Objetivos Generales............................................................................................................ 6 Estructura del Documento .................................................................................................. 6

CAPITULO 1 ......................................................................................................................... 7 SECCION 1.1: Definición de los Servicios Web ................................................................... 7

¿Qué es un Servicio Web?.................................................................................................. 7 Historia ............................................................................................................................... 8

SECCION 1.2: Arquitectura de los Servicios Web.............................................................. 10 ¿Qué es una arquitectura orientada a servicios (SOA)? ................................................... 10 Modelo arquitectónico básico........................................................................................... 10

Componentes ................................................................................................................ 10 Servicio .................................................................................................................... 10 Descripción del servicio.......................................................................................... 11

Roles ............................................................................................................................. 11 Proveedor ................................................................................................................ 11 Solicitante ................................................................................................................ 11 Agencia de servicios (“Discovery agency”) .......................................................... 11

Operaciones .................................................................................................................. 11 Publicar.................................................................................................................... 11 Encontrar ................................................................................................................ 11 Interactuar .............................................................................................................. 11

Los Servicios Web en las arquitecturas orientadas a servicios ........................................ 12 Niveles arquitectónicos..................................................................................................... 13 Modelo de capas para Servicios Web (“Web Services Stack”)........................................ 14

Las capas verticales ...................................................................................................... 16 Diseño arquitectónico de Servicios Web.......................................................................... 17

SECCION 1.3: Descripción de componentes del Stack de Servicios Web.......................... 18 1.3.1 Universal Description, Discovery, and Integration (UDDI).................................... 18

Historia de los UDDI.................................................................................................... 18 Importancia de UDDI ................................................................................................... 19 Características de UDDI............................................................................................... 19 ¿Qué se almacena en los registros? .............................................................................. 20 ¿Cómo se registra la información pública del negocio?............................................... 20 ¿Cómo es el modelo de datos de los UDDI? ................................................................ 21 ¿Cómo se publica el servicio? ...................................................................................... 21

1.3.2 Simple Object Access Protocol (SOAP) ................................................................. 24 Historia de SOAP ......................................................................................................... 24 Características de SOAP............................................................................................... 25 SOAP consta de tres partes........................................................................................... 26 Ventajas de SOAP ........................................................................................................ 28 ¿Cómo se describe el servicio?..................................................................................... 28 Capas del Service Description Stack:........................................................................... 29

1.3.3 Web Services Description Language (WSDL)........................................................ 32


Servicios Web 3

Modelo de información del WSDL .............................................................................. 32 CAPITULO 2 ....................................................................................................................... 34 SECCION 2.1: Requerimientos del Sistema ........................................................................ 34

Objetivos específicos del Sistema ................................................................................ 35 SECCION 2.2: Análisis Funcional ....................................................................................... 36

Escenarios ..................................................................................................................... 36 Casos de Uso del Sistema............................................................................................. 38 Diagramas de Actividad ............................................................................................... 41 Diagramas de Secuencia............................................................................................... 43

Modelo de datos................................................................................................................ 45 Definición de Entidades................................................................................................ 45

SECCION 2.3: Diseño Tecnológico................................................................................. 48 Modelo del entorno general .............................................................................................. 48 Modelo del entorno para la gestión de ofertas.................................................................. 49 Sistemas de información................................................................................................... 51 Modelo de procesos .......................................................................................................... 52

Crear demanda.............................................................................................................. 52 Crear Oferta .................................................................................................................. 53 Crear Contra Oferta ...................................................................................................... 53 Resumen de procesos.................................................................................................... 54

Entidades Internas............................................................................................................. 54 Diseño de la arquitectura del sistema distribuido............................................................. 55

Análisis de datos........................................................................................................... 55 Localización de datos ................................................................................................... 55 Flujo de datos................................................................................................................ 56

Procesos de actualización de datos ................................................................................... 57 Iniciar sesión................................................................................................................. 57 Publicar demanda ......................................................................................................... 57 Publicar oferta............................................................................................................... 58 Publicar Contra Oferta.................................................................................................. 58 Identificación de funciones........................................................................................... 59 Ubicación procesos....................................................................................................... 59 Identificación de servicios ............................................................................................ 60 Interfaces ...................................................................................................................... 62 �� ................................................................................................. 62 �� ........................................................................................................ 62 �� ........................................................................................................ 62 �� ................................................................................................... 62

Arquitectura Cliente Servidor........................................................................................... 63 Iniciar sesión................................................................................................................. 63 Publicar demanda ......................................................................................................... 64 Enviar notificaciones .................................................................................................... 64

“Map to reality” ................................................................................................................ 65 Infraestructura del sistema............................................................................................ 65

SECCION 2.4: Diseño de la consistencia ............................................................................ 66 2.4.1 Semántica de servicios......................................................................................... 66


Servicios Web 4

2.4.2 Diseño de la Situación de emergencia................................................................. 66 CAPITULO 3 ................................................................................................................... 68

CONCLUSIONES................................................................................................................ 68 ANEXO 1: Notación del Diseño de Sistemas Distribuidos ................................................. 69 Elemento ............................................................................................................................. 69 Descripción ......................................................................................................................... 69 Icono .................................................................................................................................... 69 Anexo 2: Implementación Ejemplo Práctico........................................................................ 70

Mapas conceptuales de navegación.................................................................................. 70 a) Cliente constructor.................................................................................................... 70 b) Cliente proveedor ..................................................................................................... 71

Los servicios ..................................................................................................................... 73 a) Archivos de descripción (WSDL) ............................................................................ 73 a.1) Servicio de publicación ......................................................................................... 73 a.2) Servicio de actualización....................................................................................... 76 b) Invocación de las operaciones del Servicio.............................................................. 79 b.1) Servicio de actualización....................................................................................... 79

El enlace con los clientes.................................................................................................. 82 Los objetos “proxy”...................................................................................................... 82

Bibliografía ........................................................................................................................... 84 Glosario Acronimos.......................................................................................................... 85


Servicios Web 5

INTRODUCCIÓN El mundo de la tecnología es un mundo cambiante, en especial cuando se trata de métodos de programación, lenguajes y estándares, cada día surge una nueva aplicación y se buscan formas para facilitar cualquier labor que tenga que ver con el mundo de los sistemas de información, una de las tecnologías de punta en este mundo son los Servicios Web. Los Servicios Web como muchas cosas en nuestro planeta buscan la globalización de las tecnologías, el mundo de negocios a nivel tecnológico sin importar las barreras geográficas y/o tecnológicas existentes. El presente proyecto tiene como finalidad elaborar el análisis, diseño e implementación de un caso práctico de servicios distribuidos basado en Servicios Web para así llegar a conocer los aspectos básicos de dicha tecnología, permitiendo la aplicación de los conocimientos adquiridos durante la investigación. En este documento se establece el concepto, la arquitectura y demás tecnologías que los servicios Web engloban. Estas definiciones son la base del desarrollo del caso práctico, el cual permite demostrar la integración y funcionalidad de los componentes de dicha tecnología, enlazando procesos de negocio de diferentes empresas o entidades. Considerando que los Servicios Web han surgido como una solución para la interconexión entre plataformas y servicios que se ven involucrados en un proceso de negocios, hemos realizado el caso práctico basándonos en el diseño de un sistema de información para la compañía ISERVI, la cual desempeña funciones relacionadas con la Arquitectura y Construcción. El sistema de información de ISERVI es complejo e implica muchas áreas de negocio o subsistemas, como lo son Manejo de Personal, Facturación, Presupuestos, Relaciones de Clientes, Relaciones de Proveedores, entre otras. El subsistema ISERVI correspondiente a la gestión de presupuestos1, se pensará y diseñará considerando que será implementado siguiendo los estándares asociados a los Servicios Web y utilizando las metodologías, notaciones y demás nociones aprendidas en el transcurso del Master de Ingeniería del Software. Se asume de antemano que el público lector posee conocimientos básicos de diseño de arquitecturas distribuidas, programación por componentes, diseño de aplicaciones Web y XML.

1 No es objeto de éste proyecto realizar el desarrollo de todo el sistema de ISERVI


Servicios Web 6

Objetivos Generales

Aplicar los conocimientos adquiridos en los diversos cursos de diseño del Master de Ingeniería de Software de la Fundación Politécnica de Cataluña, como lo son Diseño de Bases de Datos, Diseño de aplicaciones Distribuidas, Diseño Avanzado Orientado a Objetos, entre otras, al diseño de servicios distribuidos implementados por Servicios Web.

Conocer y comprender los conceptos generales básicos de las arquitecturas orientadas a servicios implementadas sobre Servicios Web con el fin de aplicarlas posteriormente en el plano profesional y educativo.

Diseñar de modo parcial el sistema de información requerido por la empresa ISERVI con el fin de aplicar o ejemplificar los conceptos estudiados.

Establecer un marco conceptual que facilite el desarrollo de investigaciones posteriores, tanto personales como eventuales proyectos del Master, las cuales exploren con mayor detalle cada uno de los elementos explicados en el presente documento así como temas afines a los mismos que por su extensión son tan sólo mencionados en el mismo.

Estructura del Documento Este documento esta organizado en capítulos. El capitulo 1 establece el Marco Teórico que comprende la base de partida de la investigación. Se introducen los Servicios Web, un poco de su historia, la arquitectura en la cual se basan, elementos que los componen y definición de las diversas tecnologías que integran el “stack”. En el capitulo 2 se aplican diversos conceptos aprendidos en el transcurso del master de ingeniería del software como son, por ejemplo, la metodología de diseño de aplicaciones distribuidas, notaciones estándar 2 y demás nociones básicas para llevar a cabo el establecimiento de requerimientos del sistema, análisis funcional, diseño arquitectónico así como el desarrollo del caso practico. El último capitulo lo comprende las conclusiones correspondientes al proyecto.

2 Notación UML: Universal Modeling Language


Servicios Web 7

CAPITULO 1 SECCION 1.1: Definición de los Servicios Web ¿Qué es un Servicio Web? El término Servicios Web es bastante general. Aunque comparado con otros términos que él mismo engloba (como UDDI, WSDL, XML), es un término bastante “sencillo” (distinto a acrónimos y nombres de otras tecnologías) que puede dar cabida a diversas interpretaciones. El nombre Servicios Web, en su definición más amplia, tiene dos significados, uno especifico y uno conceptual: Específicamente: los Servicios Web son una pila de estándares, emergentes, que describen la arquitectura de una aplicación basada en componentes y orientada a servicios (SOA). Funcionalmente: los Servicios Web representan un modelo en el cual las tareas discretas de los procesos “e-business” son distribuidas ampliamente en una “red de valor”. Teniendo en cuenta estos significados, el Stencil Group �� define los Servicios Web como: Componentes de software reutilizables, ligeramente acoplados que semánticamente encapsulan funcionalidades discretas que son distribuidas y accesibles a nivel de programación a través de protocolos de Internet. Desglosando el significado de la definición anterior podemos describir varias características que poseen los servicios Web:

• Primero, los Servicios Web son componentes de software reutilizables. En vez de exigirles a los programadores que escriban un conjunto de instrucciones de principio a fin unas tras otras, el modelo basado en componentes permite que los desarrolladores reutilicen los bloques de código creados por otros para ensamblarlos e integrarlos en un nuevo programa.

• Segundo, estos son componentes de software ligeramente acoplados. El diseño

tradicional de aplicaciones depende de la fuerte interconexión o acoplamiento de todos los elementos involucrados. La complejidad de estas conexiones requiere que los programadores comprendan de modo exhaustivo y tengan control sobre ambos extremos de la conexión; mas aun, una vez establecida la conexión, es muy difícil extraer un componente y sustituirlo por otro. Los sistemas ligeramente acoplados, por el otro lado requieren un nivel mucho más simple de coordinación y permiten mayor flexibilidad en la re-configuración.

• Los Servicios Web envuelven semánticamente funcionalidades discretas. Un

servicio Web es un “applet” que se contiene a él mismo y realiza una tarea simple.


Servicios Web 8

El componente describe sus propias entradas y salidas de modo tal que cualquier software puede determinar lo que hace, como se invoca su funcionalidad, y que resultados esperar en respuesta.

• Los Servicios Web pueden ser accedidos de modo programático. A diferencia de

sitios Web y aplicaciones de escritorio, los Servicios Web no están diseñados para interactuar directamente con los humanos y no tienen una interfaz gráfica de usuarios, operan a nivel de código; son llamados por otro software e intercambian datos.

• Finalmente, los Servicios Web se distribuyen sobre Internet. Los Servicios Web

hacen uso de protocolos de transporte ubicuos como HTTP. A groso modo se podría decir que un servicio Web es un “conjunto de aplicaciones” que proporcionan funcionalidades determinadas a otras aplicaciones, sin importar las plataformas en la que están soportadas ni el lenguaje en el cual están implementadas. Historia La evolución de los sistemas de e-business, ha llevado a que las aplicaciones sean construidas por un conjunto de componentes de servicio, que pueden ser descubiertos, publicados, combinados y consumidos sobre Internet, en otras palabras negocios electrónicos basados en servicios. El potencial de Internet hoy en día no está en las .com, este potencial lo tienen los grandes proveedores de hardware y software, entre ellos Microsoft, Oracle, IBM y SUN. La primera compañía en publicar la idea de los Servicios Web fue Hewlett-Packard (HP). Ellos desarrollaron la especificación para e-speak, propuesta que se convirtió en la siguiente generación de intercambio de información en Internet. Posteriormente, Microsoft apareció en el mercado con su estrategia de .Net, IBM siguió con su “Web Services Toolkit” (WSTK), y el “Web Services Development Enviroment” (WSDE). A su vez, Oracle anunció el lanzamiento de su “Dynamic Services” el cual fue integrado dentro de Oracle 8i Release 2. Otros proveedores como SUN desarrollaron su “framework” para Servicios Web, cuya iniciativa está centrada alrededor del ambiente J2EE. Actualmente están construyendo herramientas de desarrollo rápido tanto para clientes como para servidores. Como se puede observar, la evolución de los Servicios Web ha sido un trabajo no de uno, sino de varios proveedores de tecnología, que de una u otra forma han encontrado útil la integración de los servicios en la red. Con excepción de Microsoft, se han usado productos de la suite de Java, estos productos han evolucionado en los últimos cinco años.


Servicios Web 9

En la figura 1, se puede observar la evolución de los Servicios Web desde el año 1998 hasta el 2002.

Figura 1.1: Evolución de los Servicios Web.


Servicios Web 10

SECCION 1.2: Arquitectura de los Servicios Web Ya que los servicios Web se basan en la arquitectura orientada a servicios a continuación explicaremos más detalladamente a que nos referimos con “orientada a servicios” y nos adentraremos en el mundo de los Servicios Web y las tecnologías que le componen: ¿Qué es una arquitectura orientada a servicios (SOA)? Es una forma de diseñar una aplicación de software para proveer servicios, ya sea a aplicaciones finales o a otros servicios, mediante la publicación y descubrimiento de sus interfaces [Service-Architecture] Una arquitectura orientada a servicios es esencialmente una colección de servicios. Estos servicios se comunican unos con otros. La comunicación puede tratarse simplemente de un intercambio de datos o puede ser tan compleja como la coordinación de varios servicios para llevar a cabo una determinada actividad. Son necesarios servicios de comunicación para comunicar unos con otros. [Service-Architecture] Modelo arquitectónico básico

Figura 1.2: Modelo Arquitectónico Básico.

Componentes

Servicio Un servicio es un módulo de software accesible por diversas plataformas de red. Existe para ser invocado o para interactuar con sus clientes pudiendo también fungir como cliente de otros servicios.


Servicios Web 11

Descripción del servicio La descripción del servicio contiene los detalles de la interfase y la implementación del servicio. Esto incluye sus tipos de datos, operaciones, información de enlace y su localización en la red. La descripción del servicio puede ser publicada directamente a los clientes o bien enviada a una agencia (servicio) que facilita el rastreo de servicios a los clientes.

Roles

Proveedor Esta es la plataforma que brinda acceso al servicio. Se le puede ver también como el ambiente de ejecución del servicio o simplemente el contenedor del servicio. Su rol en el esquema de intercambio de mensajes del modelo cliente-servidor es el de servidor. Solicitante Esta es la aplicación que busca, invoca o inicia la interacción con un servicio. Su rol en el esquema de intercambio de mensajes del modelo cliente-servidor es el de cliente. Agencia de servicios (“Discovery agency”) Esta es una colección de descripciones de servicios que pueden ser accesibles por diversos solicitantes para lograr la conexión con un determinado proveedor.

Operaciones

Publicar Con el fin de ser accesible un servicio necesita publicar su descripción con el fin de que los solicitantes pueden hallarle e invocarle. Encontrar En esta operación un solicitante obtiene directamente la descripción de un servicio o bien consulta una agencia por el tipo de servicio requerido. Interactuar En esta operación un solicitante invoca o inicia en tiempo de ejecución una interacción con un proveedor utilizando los detalles de su descripción para localizarle, contactarle e invocarle.


Servicios Web 12

Ejemplos de interacción pueden ser: mensajes de una vía, mensajes a múltiples destinatarios, conversación de mensajes múltiples y unos procesos de negocio (“workflow”). Cualquiera de estas interacciones puede ser síncrona o asíncrona.

Los Servicios Web en las arquitecturas orientadas a servicios

Figura 1.3: SOA y los Servicios Web

En la figura 1.3 se muestra los diferentes estándares que giran alrededor de los servicios Web, ubicados dentro del esquema conceptual de las arquitecturas orientadas a servicios. A nivel de localización del servicio se encuentra el estándar WSDL el cual facilita una descripción de las operaciones brindadas por el servicio y las formas de invocarlas. La comunicación entre solicitante y servicio se realiza a través de protocolos comunes a Internet, destacándose el HTTP por su facilidad de uso y amplia implementación. No obstante puede observarse que de acuerdo con las características particulares de cada aplicación pueden utilizarse otros protocolos de comunicación que podrían resultar de mayor utilidad; por ejemplo los protocolos de correo electrónico y FTP.


Servicios Web 13

Niveles arquitectónicos

Figura 1.4: Niveles arquitectónicos Las arquitecturas orientadas a servicios son una evolución de las arquitecturas por componentes; las cuales a su vez surgieron gracias a la aparición del concepto de clases en los leguajes de programación. Este carácter evolutivo no significa una desaparición del nivel anterior, al contrario cada capa utiliza el nivel anterior como esquema básico de construcción; esto significa que los servicios Web se construyen utilizando componentes como puede verse en la Figura 1.4.

Es importante destacar que el hecho de que los servicios Web se fundamenten sobre componentes no significa que estos últimos puedan reconvertirse automáticamente en servicios. Es decir la actualización de una arquitectura orientada a componentes a una orientada a servicios conlleva un trabajo de rediseño y re-codificación importante


Servicios Web 14

Modelo de capas para Servicios Web (“Web Services Stack”) Con el fin de realizar las operaciones de publicación, conexión y comunicación los Servicios Web requieren de un conjunto de estándares que faciliten la ejecución de dichos procesos. Estos estándares conforman lo que se conoce como “Modelo de capas de los Servicios Web” el cual se muestra en la figura 1.5. Las capas verticales de dicho modelo se fundamentan la una en la anterior mientras que las capas horizontales representan aspectos que deben ser tomados en cuenta en cada una de las capas verticales.

Figura 1.5: Modelo de capas para Servicios Web

La capa base de los Servicios Web es la capa de red. Los Servicios Web deben ser accesibles a través de una red con el objeto de ser invocados por quienes les requieren (sus clientes). Debido a su amplio uso, HTTP es el estándar para esta capa; sin embargo, también se utilizan otros estándares como SMTP o FTP.

La siguiente capa representa el uso de XML como la base del protocolo de

mensajería. El estándar mas utilizado por diversas razones en esta capa es SOAP, ya que es un mecanismo estandarizado para comunicación remota y que utiliza un esquema basado en documentos. Se prefiere al simple uso de XML sobre HTTP debido a la posibilidad de incorporar extensiones propias de cada empresa a través de encabezados y la codificación de operaciones y funciones.

La capa de descripción del servicio es básicamente una pila de documentos que

contienen diversas descripciones del servicio. Dichos documentos se basan en su gran mayoría en el estándar WSDL3 el cual a su vez se fundamenta en XML.

La descripción básica de un Servicio Web especifica las operaciones brindadas por éste y los mecanismos de interacción necesarios para su invocación.

3 WSDL (Web Services Description Language) será descrito en la sección 1.3.3


Servicios Web 15

Descripciones adicionales son necesarias para especificar el contexto del negocio, aspectos de calidad y relaciones servicio-servicio. El documento WSDL puede ser complementado con otros documentos descriptivos que especifican aspectos de alto nivel relacionados con el servicio. Por ejemplo, el contexto del negocio es descrito usando estructuras de datos UDDI que se agregan al documento WSDL.

Las tres primeras capas del modelo son siempre requeridas. La versión más simple del modelo correspondería a HTTP para la capa de red, SOAP como protocolo de mensajería y WSDL para la descripción del servicio. De esta manera se logra una capa base que favorece la interoperabilidad al fundamentarse en estándares “abiertos” y de uso extendido. Sin embargo, esto no significa que sean los únicos estándares admitidos.

Cualquier acción que permita hacer “visible” un servicio a posibles clientes se ubica en la capa de publicación del servicio. En su versión más simple la publicación puede lograrse enviando el documento WSDL directamente al cliente. A este tipo de publicación se le conoce como “publicación directa” y puede resultar muy útil para aplicaciones enlazadas estáticamente. De forma alternativa el proveedor puede publicar su documento WSDL en un “host” local, un registro privado UDDI4 o un operador de este tipo para un enlace dinámico.

Debido a que un Servicio Web no puede ser descubierto si no ha sido publicado, la

capa de rastreo o descubrimiento depende de la capa de publicación. Cualquier mecanismo que permita a los clientes lograr el acceso a la descripción del servicio haciéndolo disponible en tiempo de ejecución se incluye dentro de la capa de descubrimiento. El mecanismo más simple de este tipo se da cuando un cliente obtiene el documento WSDL desde el sistema de archivos local. A este tipo de descubrimiento se le conoce como “descubrimiento estático”y se logra gracias a la publicación directa del documento WSDL o a una operación de búsqueda previa. De forma alternativa el servicio puede ser descubierto en tiempo de diseño o ejecución usando un registro u operador UDDI.

Debido a que la implementación de un servicio Web es a fin de cuentas un módulo

de software es natural que se produzcan composiciones entre ellos para formar otros servicios. Una composición de Servicios Web puede jugar muchos roles en el desarrollo de aplicaciones de software. En aplicaciones internas distintos Servicios Web pueden colaborar para presentar una única interfaz a otras aplicaciones o servicios. También pueden darse colaboraciones entre Servicios Web para realizar transacciones máquina a máquina (también conocidas como “negocio a negocio”). De forma alternativa un administrador de flujos de trabajo puede invocar un Servicio Web para que participe en la ejecución de un proceso de negocio. Este tipo de comunicaciones, colaboraciones y control de flujo es el que se especifica en la superior de las de capas de los Servicios Web. El estándar WSFL es utilizado para la descripción de este tipo de interacciones. 5

4 UDDI (Universal Description, Discovery, and Integration) será definido en la sección 1.3 5 WSFL y el uso de Servicios Web para la implementación de procesos de negocio no forma parte del presente documento.


Servicios Web 16

Las capas verticales Existen otro tipo de requerimientos no técnicos vinculados con los Servicios Web exigidos por la naturaleza propia de las aplicaciones de software de hoy en día (en especial las aplicaciones de negocios basadas en Internet “ebusiness”). Este tipo de requerimientos incluyen aspectos de seguridad, calidad de servicio y actividades de administración en cada una de las capas del modelo de Servicios Web. Existen además requerimientos adicionales relacionados con la infraestructura necesario para dar soporte a los Servicios Web como son: gestión de contenido, gestión de conversaciones y actividades entre servicios, gestión de intermediarios (“middleware”), integración de portales y administración de flujos de trabajo. 6

6 El tratamiento de este tipo de requerimientos no técnicos vinculados con los Servicios Web se encuentra fuera del alcance del presente documento.


Servicios Web 17

Diseño arquitectónico de Servicios Web Existen ciertos conceptos importantes que se deben tomar en cuenta al momento de realizar un diseño con servicios Web:

Granularidad:

Los Servicios Web están pensados para trabajar con grandes volúmenes de datos. Es decir, en cada intercambio de mensajes entre distintos servicios debe evitarse la manipulación de valores atómicos y tratar de actuar sobre unidades completas. [Conallen, 02]

Acoplamiento:

El carácter dinámico de los negocios exige gran flexibilidad en el diseño de aplicaciones. Además, la mayoría de sistemas de información son desarrollados sobre un conjunto de requerimientos incompleto el cual al ir “evolucionando” provoca cambios constantes en la estructura de los mismos. Estas situaciones exigen que los componentes de dicha estructura sean fácilmente actualizables e intercambiables. Para lograr esto, es necesario reducir al mínimo posible las relaciones –invocaciones- entre los mismos. Esto es, construir sistemas con un bajo nivel de acoplamiento. Los Servicios Web son una excelente estructura de construcción para este tipo de sistemas debido a su característica de publicación y descubrimiento “en línea”.

Caché de datos:

Debido a la práctica recomendada en los “Web Services” de trabajar con grandes volúmenes de información se hace necesario manejar el concepto de caché de datos. Un caché de datos es una copia del estado de un objeto (“value object”) obtenida desde el proveedor. Este caché debe ser “refrescado” periódicamente (dependiendo de la volatilidad de los datos) con el fin de trabajar con los valores más recientes.

Comportamiento de las interfaces:

El diseño orientado a servicios puede favorecer el establecimiento del comportamiento de las interfaces de un componente lo cual favorecería el mapeo de procesos de negocios de manera casi transparente en una arquitectura de software. A este proceso se le llama “choreography”. [Service-Architecture]


Servicios Web 18

SECCION 1.3: Descripción de componentes del Stack de Servicios Web En el modelo de capas para servicios Web y la arquitectura orientada a servicios se menciono cuales son los componentes que intervienen cuando se realiza una llamada a un servicio Web, ahora se procede a dar una visión mas completa de cada uno de esos componentes: 1.3.1 Universal Description, Discovery, and Integration (UDDI) 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 pueden 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 elección de software basado en Servicios Web. Historia de los UDDI Buscar servicios y descubrirlos es algo que ha estado presente en la red desde sus inicios. Al comienzo en forma incipiente y estática, pero con el tiempo ha evolucionado a algo más dinámico, a su vez se ha cambiado de esquemas simples de búsqueda a esquemas de alta complejidad y funcionamiento. Los UDDI nacen como una necesidad de unificar la información de los servicios que estaban apareciendo en la red y que ya no correspondían a simples transacciones electrónicas o páginas Web. En otras palabras, se vio la necesidad de construir un “Register” o un DNS para estos nuevos servicios. Es un estándar creado por la UDDI.org, que unió la opinión de varios de los principales líderes de la industria del software. El proyecto de estandarización busca incrementar la interoperabilidad y la adopción de los Servicios Web. Estos estándares se basan en especificaciones para el servicio, la descripción y el descubrimiento del mismo.


Servicios Web 19

Algunos de los participantes en el proyecto son:

Proyecto Participante Accenture Ariba Commerce One Microsoft Compaq Fujitsu Hewlett-Packard i2

Intel IBM Microsoft Oracle SAP Sun Verisign

Tabla 1.1: Fundadores del UDDI

Fueron más de 750 miembros de más de 300 compañías los que participaron en el proceso de generación de los estándares. Los UDDI en resumen son registros de los Servicios Web que ayudan a encontrar el servicio y su descripción (generada mediante el WSDL). Las búsquedas, como se explicará más adelante, se pueden hacer por negocio y por tipo de servicio. Importancia de UDDI

Capacita a las empresas a publicar el modo en que quieren llevar sus negocios en la Web, potenciando de este modo el crecimiento del comercio electrónico.

Beneficia a los negocios de cualquier tamaño creando una arquitectura global

independiente de la plataforma para describir servicios y negocios e integrar los negocios por medio del Internet.

Características de UDDI

El UDDI provee dos categorías de API:

1. El API de Publicación: provee el mecanismo para que los proveedores de servicios se registren ellos mismos y sus servicios en el Registro UDDI.

2. El API de Consulta: permite a los subscriptores de servicios buscar los servicios disponibles. El API de consulta provee dos tipos de llamados, un mecanismo de búsqueda y un mecanismo de obtención, cuando ya se tiene disponible toda la información referente a la disponibilidad de un servicio.


Servicios Web 20

¿Qué se almacena en los registros? Podemos clasificar lo que se almacena en dos grandes grupos:

Cuerpos estándar, que incluye toda la información registrada por negocios y programadores sobre los servicios que ofrecen, incluyendo especificaciones y taxonomías.

Registro público de información y servicios que ofrece el negocio. ¿Cómo se registra la información pública del negocio? Los UDDI poseen tres formas de registrar y por ende acceder a la información, y su manejo es similar al de los directorios telefónicos. Paginas Blanca (“White Pages”) es muy similar a la información que aparece en el directorio telefónico, que incluye nombre, teléfono, y dirección. El registro y la búsqueda es por identificación. Este registro posee Información sobre el negocio (Nombre del negocio, Descripción o descripciones en texto), Información de contacto (Nombre, dirección, teléfono, fax, sitios Web), Identificadores (Lista de Identificadores). Paginas Amarilla (“Yellow Pages”) es muy similar a su equivalente telefónico, e incluyen categorías de catalogación industrial tradicionales, ubicación geográfica, etc. Mediante el uso de códigos y claves predeterminadas, los negocios se pueden registrar y así facilitar a otros servicios la búsqueda usando estos índices de clasificación. El registro y la búsqueda es por categorías. Paginas Verde (“Green Pages”) contiene la información técnica acerca de los servicios ofrecidos por los negocios. Se incluyen referencias de especificaciones de Servicios Web así como también información complementaria para los mecanismos diversos de búsqueda basados en URL. El registro y la búsqueda es por servicios.


Servicios Web 21

¿Cómo es el modelo de datos de los UDDI? En la siguiente figura (Figura 1.6) se presenta la arquitectura del modelo de datos de los UDDI.

Figura 1.6: Modelo de Datos UDDI (Data Model) Una entrada a un UDDI comienza con una businessEntity cuyos elementos modelan la información sobre un negocio, incluyendo información básica del negocio, por ejemplo cuál es el nombre del negocio y la información de contacto. Información de categorización como por ejemplo qué tipo de negocio es y por último información de identificación.

Un businessEntity posee un conjunto de elementos businessService, uno para cada Web Service que el negocio haya publicado. Cada elemento businessService posee información técnica y descriptiva sobre los elementos businessEntity del Web Service.

Un businessService contiene una colección de bindingTemplate (plantillas de enlace), que describen el acceso a la información y como el businessService utiliza varias especificaciones técnicas.

El tModel es una representación del negocio que se quiere exponer remotamente. ¿Cómo se publica el servicio? La publicación en UDDI es un proceso relativamente sencillo. El primer paso consiste en determinar información básica sobre cómo definir la empresa y los servicios en UDDI. El siguiente paso, una vez determinada esta información, consiste en llevar a cabo el registro, ya sea mediante programación o a través de una interfaz de usuario basada en el Web. Por último, se debe probar la entrada para asegurar que se registró correctamente y que aparece tal y como se esperaba en diferentes tipos de búsquedas y herramientas.


Servicios Web 22

Los pasos para el registro son: Primer paso: Definir la entrada de UDDI

Partiendo del modelo de datos descrito anteriormente, se debe recopilar cierta información importante antes de establecer una entrada de UDDI.

Determinar los tModels (archivos WSDL) que utilizan las implementaciones del

servicio Web.

El servicio Web se ha desarrollado a partir de una interfaz existente o de una interfaz de diseño propio. En el caso de un servicio Web basado en una interfaz WSDL existente, deberá determinar si el archivo WSDL se ha registrado en UDDI. Si es así, deberá comprobar su nombre y tModelKey, que es el identificador GUID (identificador único global) que generó UDDI cuando se produjo el registro. Por el contrario, si el servicio Web se basa en un archivo WSDL que no se ha registrado en UDDI, deberá crear un nuevo tModel para representar esta interfaz. El nombre de este tModel debería tener un formato URI (identificador de recursos uniforme), como MyCompany-com: SampleWebService-interface:v1, y señalar a la ubicación del archivo WSDL.

Determinar el nombre de la empresa y una breve descripción de la misma en varios

idiomas, si es necesario, así como los contactos principales para los Servicios Web que ofrece.

UDDI es compatible con el espacio de nombre xml:lang, lo que permite a las empresas ofrecer su descripción en varios idiomas. Asimismo, UDDI permite enumerar los contactos, incluyendo datos como el correo electrónico, el teléfono y la dirección. Esta lista de contactos muestra los recursos de una empresa con los que se puede poner en contacto en relación con los Servicios Web ofrecidos. Por ejemplo, si un usuario desea comenzar a utilizar el servicio Web deberá ponerse en contacto con el responsable de relaciones comerciales correspondiente pero, ¿Cómo puede llegar a saber quién es? ¿Existe algún contacto para obtener asistencia técnica a la hora de utilizar los Servicios Web de la empresa? ¿También se debería incluir en la lista a esta persona?

Determinar las categorías e identificaciones adecuadas para la empresa.

Podrá explorar los sistemas taxonómicos compatibles con UDDI actualmente en el nodo Microsoft UDDI (http://uddi.microsoft.com/ default.aspx). Estos sistemas son por el momento, North American Industry Classification System (NAICS), Universal Standard Products and Services Codes (UNSPSC), ISO 3166, Standard Industry Classification (SIC) y GeoWeb Geographic Classification. Seleccione las categorías que representan de forma más acertada a su empresa.


Servicios Web 23

Determinar los Servicios Web que la empresa ofrece a través de UDDI.

A continuación, se debe determinar los Servicios Web que desea registrar la empresa en el nodo público UDDI. ¿Existen varios puntos de acceso para este servicio? ¿Es preciso que los clientes conozcan otros parámetros y otra información para utilizar el servicio Web? Resulta importante destacar que no todo el mundo puede obtener acceso a un servicio Web porque éste se haya registrado en UDDI. A una entrada de registro UDDI le pueden acompañar medidas de seguridad, autorización y autenticación. No basta que el usuario sepa que existe un servicio Web para que pueda invocarlo. Puede existir una comunicación fuera de línea entre empresas antes de permitir el acceso a un servicio Web.

Determinar las categorías adecuadas para los servicios.

Los Servicios Web se pueden categorizar del mismo modo que las empresas. No obstante, una empresa se debe categorizar a nivel empresarial, como por ejemplo NAICS: Software Publisher (51121), y el servicio Web (de reserva hotelera, en este caso) se debería categorizar en el nivel de servicios, como NAICS: Hotels and Motels (72111).

Segundo paso: Registrar la entrada de UDDI

Una vez finalizada la tarea de definición, el siguiente paso consiste en registrar la empresa. Deberá obtener una cuenta con un registro UDDI. Esta operación no se puede realizar mediante programación, ya que deberá mostrar su conformidad con una declaración de condiciones de uso. En este punto se puede utilizar la interfaz de usuario Web del nodo o realizar el registro mediante programación dirigiendo al propio nodo las llamadas a API de SOAP. Si no piensa modificar la entrada o ésta es relativamente simple, bastará con la interfaz de usuario Web. No obstante, si pretende actualizar la entrada con frecuencia, ésta es más compleja, resulta recomendable realizar el proceso de registro con secuencias de comandos, utilizando el SDK de Microsoft UDDI.


Servicios Web 24

1.3.2 Simple Object Access Protocol (SOAP) Existe una tendencia muy marcada en las empresas por el desarrollo de aplicaciones que puedan trabajar sobre Internet, principalmente por la ventaja de la distribución global de la información. Las tecnologías más usadas para el desarrollo de estas aplicaciones, han sido CORBA (OMG, Object Management Group), COM (Microsoft) y EJB (Sun Microsistems). Cada una proporciona un marco de trabajo para la activación de objetos remotos, mediante la solicitud a un servidor de aplicaciones (o mediante un servidor Web) para la ejecución de servicios de aplicación. Estas tecnologías han probado ser efectivas para el establecimiento de sitios Web corporativos; sin embargo, presentan algunas desventajas como la falta de interoperabilidad, la dependencia a la arquitectura de trabajo (COM está muy ligado a Windows, mientras que CORBA tiene muchas implementaciones de diversos fabricantes), así como el lenguaje de programación. Esto ha llevado a la industria a considerar un nuevo modelo de computación distribuida de objetos, sin tener la dependencia de plataformas, modelos de desarrollo y lenguajes de programación usados. SOAP es un protocolo liviano para intercambio de información en una ambiente descentralizado o distribuido basado en XML. Historia de SOAP Las tecnologías de los Servicios Web se basan en protocolos XML. Estos protocolos manejan la forma en que se hace la comunicación y se manejan los datos. Los protocolos XML se dividen en dos generaciones. La primera generación de protocolos se basa en XML 1.0, la segunda generación toma ventaja de la aparición de XML name y XML scheme, SOAP es un protocolo XML de segunda generación.

Protocolos de primera generación Esta primera generación fue poco soportada por los vendedores de tecnología y por tanto fue poco aceptada entre los mismos. Dentro de los protocolos de esta generación se encuentra: WDDX (Web Distributed Data Exchange) que provee un mecanismo de lenguaje y plataforma neutral para hacer intercambio de datos entre aplicaciones y XML-RPC que es un protocolo RPC que soporta un conjunto de datos similar a los soportados por WDDX y usa HTTP. Esta primera generación presentó algunos problemas dentro de los cuales se destaca la poca extensibilidad de los protocolos, situación que es superada en la segunda generación cuando se hace una optimización de los XML namespace.


Servicios Web 25

Protocolos de segunda generación Microsoft comenzó a pensar en la computación distribuida en 1996. El objetivo era lograr habilitar las aplicaciones para comunicarse vía Remote Procedure Calls (RPC) y correr sobre HTTP. DevelopMentor y Userlad se unieron a la discusión y a principios de 1998 se da a conocer SOAP. El 13 de Septiembre de 1999, mientras Microsoft trabajaba en su versión de XML Écheme (XML data) y adicionaba soporte a los XML namespace, aparece la primera versión (0.9) de SOAP. La versión 1.0 de SOAP se libera en Diciembre del mismo año. SOAP 1.1 es sometida a verificación y el W3C la toma como estándar en Mayo 8 de 2000. SOAP 1.0 se ha construido con base en una segunda generación del protocolo XTML, y se enfoca en todos los aspectos comunes de los escenarios de computación distribuida. Características de SOAP

Un mecanismo para definir la unidad de comunicación. En SOAP toda la información es empaquetada en un SOAP message claramente identificado. Este mensaje es hecho por el SOAP envelope que encierra toda la demás información. Un mensaje puede tener un cuerpo body, escrito en XML. Se cuenta también con un número de encabezados headers, que encapsulan la información fuera del cuerpo del mensaje.

Un mecanismo de manejo de errores, que permite identificar la fuente y la causa del error, y envía un diagnóstico del error a todos los participantes. Este manejo se hace mediante la concepción de SOAP fault.

Hace un nuevo manejo del namespace permitiendo mayor extensibilidad y flexibilidad. Esta extensibilidad se hace por medio de los SOAP header y puede ser usado para construir protocolos más complejos sobre SOAP.

Un mecanismo flexible para representación de datos que permita el intercambio de datos siempre serializados, en algún formato (texto, XML, otros), o bien como una convención que represente una estructura de datos abstracta como se hace con los tipos de datos de los lenguajes de programación en un formato XML.

Una convención para presentar “Remote Procedures Calls” (RPC’s) y respuestas a mensajes SOAP ya que RPC es un tipo más común de computación distribuida.

Permite modelos de intercambios de datos más naturales para las interacciones entre negocios.

Un mecanismo de búsqueda de mensajes SOAP sobre HTTP, debido a que HTTP es un protocolo de comunicación común en Internet.


Servicios Web 26

Se pretende que SOAP sea “ubiquitous XML distributed computing infrastructure”, es decir, que sea una infraestructura basada en XML que permita la ubicuidad y la computación distribuida. En donde: Computación Distribuida: implica que SOAP pueda ser usado para habilitar la interoperabilidad de aplicaciones remotas, Sin embargo, los mínimos requeridos para una ambiente de transacciones distribuidas son: la pila de protocolo usado para la comunicación, administración de la conexión, seguridad, soporte de transacciones, marshalling y un-marshalling de datos, administración de versiones, manejo de errores, auditoria de las transacciones, entre otros. Es claro entonces que no todo tipo de aplicación requiere todos los aspectos mencionados, pues no es lo mismo un proceso de administración de inventarios que el pago de servicios o el pago de una compra, donde el tipo de seguridad y confiabilidad de las transacciones es obligatorio. Infraestructura: Implica que SOAP está orientado a desarrolladores de sistemas distribuidos bajo nivel. No para desarrolladores de aplicaciones de lógica del negocio o usuarios de negocios. Ubicuidad: Significa omnipresencia o universalidad. A pesar de ser lo más importante de esta definición, esta parte está aún inmadura en el proceso de evolución de SOAP, ya que se requeriría que SOAP fuese altamente abstracto y tecnológicamente flexible. Más abstracción generaría más riesgos al momento de trabajar la interoperabilidad de las aplicaciones. SOAP consta de tres partes

El SOAP envelope (sobre) define un marco de referencia para expresar que va en el mensaje; quién debe tratar con él y si es opcional u obligatorio.

El SOAP encoding rules o reglas de codificación, define el mecanismo de serialización que puede ser usado para intercambiar instancias de tipos de datos de aplicaciones definidas.

La representación SOAP RPC define una convención que puede ser usada para representar llamadas y respuestas a procedimientos remotos.

Una de las grandes ventajas de los Servicios Web, es que no es necesario saber XML para construirlos o consumir el servicio. Esto valida a SOAP como una infraestructura tecnológica. El mecanismo que permite que esto ocurra tiene múltiples capas de abstracción:

Proveedores y solicitantes usan servicios como los API’s de Java. Invocar un Servicio Web, requiere de una o más invocaciones de métodos Java.


Servicios Web 27

Implementar un Servicio Web requiere de un Backend de Java (una clase o un EJB). La vista de un Servicio Web es un mensaje SOAP que será intercambiado entre el

solicitante y el proveedor del servicio. Las vistas de desarrollo de los Servicios Web son vistas lógicas. La única vista real

es el wire-level, donde los paquetes HTTP contienen mensajes que son intercambiados entre la aplicación del solicitante y el Servicio Web del proveedor. La figura 1.7 presenta las capas de la invocación de un Servicio Web.

Figura 1.7: Vistas de las capas en la invocación de un Servicio Web

Aunque las especificaciones de SOAP se usan para la búsqueda HTTP, los Servicios Web pueden ir más allá del límite establecido en el HTTP y manejar otros empaquetamientos y esquemas de protocolos como: paquetes MIME para soportar documentos adjuntos, SMTP para manejar mensajes asimétricos sin necesidad de una capa intermedia, entre otros. La siguiente gráfica (Figura 1.8) presenta la forma en que se envía un mensaje XML para la solicitud de un servicio usando SOAP.

Figura 1.8: Mensaje XML usando SOAP


Servicios Web 28

Ventajas de SOAP El protocolo SOAP tiene diversas ventajas sobre otras maneras de llamar funciones de manera remota como DCOM, CORBA o directamente en TCP/IP:

Es sencillo de implementar, probar y usar. Es un estándar de la industria, creado por un consorcio del cual Microsoft forma

parte, adoptado por W3C y por varias otras empresas. Utiliza los mismos estándares de la Web para casi todo: la comunicación se hace

mediante HTTP con paquetes virtualmente idénticos; los protocolos de autenticación y encriptación son los mismos; el mantenimiento de estado se hace de la misma forma; se implementa normalmente por el propio Servidor Web.

Atraviesa "firewalls" y “routers”, que "piensan" que es una comunicación HTTP. Tanto los datos como las funciones se describen en XML, lo que permite que el

protocolo no sólo sea más fácil de utilizar sino que también sea muy sólido. Es independiente del sistema operativo y procesador. Se puede utilizar tanto de forma anónima como con autenticación (nombre/clave).

¿Cómo se describe el servicio? Si se solicita el servicio; ¿Cómo debe hacer el cliente para saber que clase de mensaje debe enviar para invocar el servicio que quiere consumir? Con SOAP envelope tenemos el formato del sobre para enviar el mensaje, pero es necesario clarificar que tipo de mensaje se colocará en el sobre. Sería necesario entonces, que el cliente conociera bien XML para poder colocar el body o cuerpo del SOAP envelope. Y entender el formato de respuesta enviado por el proveedor del servicio. El cliente necesitaría también conocer el protocolo con el cual se enviaría el mensaje y la dirección de red para hacer el envío. Ahora bien, si siempre que se quisiera hacer uso de un Servicio Web se tuviese que hacer el análisis, diseño, decodificación y codificación de los mensajes, los Servicios Web no habrían tenido acogida. Se requiere, entonces, un mecanismo formal para describir el servicio. La descripción de un servicio está involucrada directamente con cada una de las tres operaciones de una Service Oriented Architecture (SOA), estas operaciones son: publicar, encontrar y encadenar-enlazar, estas operaciones se presentan en la figura 1.9.


Servicios Web 29

Figura 1.9: Arquitectura Orientada a Servicio (SOA)

El proveedor del servicio publica una descripción del servicio para uno o más service registers (registros de servicio). Esta publicación no es el código del Servicio Web sino una descripción del mismo. El proveedor del servicio usa una descripción del mismo para comunicar al solicitante del servicio lo que necesita conocer para poder invocar el Servicio Web. Esta publicación es clave para poder encontrar la operación que el solicitante del servicio requiere. Es por esto que se publica esta descripción del servicio ofrecido. El solicitante del servicio quiere encontrar la descripción del servicio, porque esta describe exactamente que se requiere para que ocurra la operación de encadenamiento. Capas del Service Description Stack: El Service Description Stack: puede ser dividido en dos grandes grupos la capa funcional y la capa no funcional. En la figura 3.5 se presentan los detalles en los cuales se fundamenta esta pila.


Servicios Web 30

Figura 1.10: Service Description Stack

Los tres primeros niveles XML scheme, WSDL (service implementation) y WDDL (services interface) son funcionales, ya que describen los detalles de cómo el Servicio Web es invocado y como es invocado. Las capas WSEL y WSFL/XLANG son no funcionales o no operacionales en su naturaleza, ya que no informan de manera directa los mecanismos de invocación. Descripción Funcional Las capas funcionales del Service Description Stack, definen la Interface Definition Language (IDL) que es equivalente a la descripción del servicio. La descripción del servicio en un Servicio Web es equivalente o tiene la misma función que el IDL en otras aproximaciones de la computación distribuida. Como todo en los Servicios Web, XML es la base de la descripción del servicio. XML describe los tipos de datos para los elementos que fluyen en el mensaje SOAP pero en particular con el SOAP payload (carga), el cual necesita ser formateado por el solicitante del servicio e interpretado por el proveedor del servicio. La definición de la implementación del servicio (service implementation definition) y la definición de la interfaz del servicio (service interface definition) usan el Web Services Description Language WSDL. La definición de la implementación del servicio describe dónde se localiza el servicio o más exactamente a cual dirección en la red debe enviarse el mensaje para invocar el Servicio Web.


Servicios Web 31

La definición de la interfaz del servicio describe qué mensaje necesita ser enviado y cómo usar los protocolos de mensajes estándar de Internet y los esquemas de codificación para tener un formato aceptado por el proveedor del servicio. Descripción no funcional Mientras que las capas funcionales describen donde enviar el mensaje, la sintaxis del mensaje y como usar los protocolos para esquemas de codificación, la descripción no funcional se orienta hacia el por qué un solicitante de servicio debe invocar un Servicio Web. Por ejemplo: qué función cumple el Servicio Web para el negocio y cómo influye en los procesos del mismo. La descripción no funcional da más información de quién es el proveedor del servicio. El WSEL (Web Services Endpoint Language) describe el ambiente o punto final en el cual se hospeda el Web. Las características de este ambiente de hospedaje deben contemplar las políticas de seguridad y los niveles de calidad del servicio que están disponibles para la invocación del Servicio Web, además de las políticas de privacidad que están obligados a cumplir los proveedores del servicio.


Servicios Web 32

1.3.3 Web Services Description Language (WSDL) El WSDL es un estándar propuesto para describir la sintaxis de invocación técnica de Servicios Web. El WSDL fue desarrollado por el W3C como estandarización de IBM, Microsoft y otros en Septiembre de 2000. Una descripción de servicio WSDL es un documento XML, no es una descripción completa del servicio, pero cubre los niveles bajos del “services description stack”, y es la descripción técnica pura de la interfaz del servicio. El WSDL es el IDL para los Servicios Web. En esencia un WSDL describe tres propiedades fundamentales de un Servicio Web:

• ¿Qué hace el servicio?, que indica el conjunto de operaciones (métodos) que el servicio provee.

• ¿Cómo se accede el servicio?, que indica el detalles de los formatos de datos y los protocolos necesarios para acceder a las operaciones del servicio.

• ¿Dónde está localizado el servicio? que muestra detalles del protocolo, direcciones de red específicas, tales como un URL.

Modelo de información del WSDL El modelo de información del WSDL toma ventaja de la separación entre las especificaciones abstractas y las implementaciones concretas de estas especificaciones. Esto refleja la división entre la definición de la interfaz del servicio (interfaz abstracta) y la definición de la implementación del servicio (punto final concreto). La descripción de las capacidades del punto final es la especificación de la interfaz abstracta representada en el WSDL por un portType (tipo de puerto). Un mecanismo de encadenamiento (binding) representados en el WSDL por un elemento de búsqueda que es usado para mapear la definición abstracta del Servicio Web para una implementación específica usando un protocolo de mensaje particular, un modelo de decodificación de datos y un protocolo de comunicación a bajo nivel. Cuando el enlace-búsqueda es combinado con una dirección donde la implementación pueda ser accedida, el punto final será un punto concreto que el solicitante del servicio puede invocar. Esa combinación es representada por un elemento WSDL port. Una interfaz abstracta puede soportar un gran número de operaciones. Una operación es definida por el conjunto de mensajes que definen sus patrones de interacción. Como todas las buenas aplicaciones de XML el esquema WSDL define varios elementos de alto nivel en el lenguaje: PortType: una definición de interfaz abstracta de Servicios Web donde cada elemento operación-hijo define una forma del método abstracto.


Servicios Web 33

Message: define un conjunto de parámetros referenciados por el método u operación. Types: define una colección de todos los tipos de datos usados en el Servicio Web y que son referenciados por varios elementos que son parte del mensaje (tipos de datos base). Binding: contiene los detalles de cómo los elementos en una interfaz abstracta (portType) son convertidos en una representación concreta, en una combinación particular de formatos de datos y protocolos (ejemplo: esquema de codificación de SOAP sobre HTTP). Port: expresa como un enlace (binding) es desplegado en un punto final particular de la red (lugar donde se especifica el URL HTTP). Service: es un nombre o colección de nombres de puertos (ejemplo: los puertos asociados con los pasos en una transacción de negocios multipasos). En otras palabras es una colección de endpoints. El tipo de puerto portType (con detalles del mensaje y el tipo de elementos) describe el que del Web Services. El elemento binding describe el como y los elementos port y service describen el donde del Web service. Este modelo de información se puede observar con claridad en la figura 1.11

Figura 1.11: Modelo de Información del WSDL


Servicios Web 34

CAPITULO 2 Una vez que conocemos el mundo de los Servicios Web a nivel teórico, se procede a ver como aplicar dichos conceptos al caso del sistema de información de la empresa ISERVI. Para ello debemos tener más conocimientos sobre los requerimientos de dicho sistema. Cabe notar que el caso de ISERVI ha sido elegido no solo por su actualidad, ya que al igual que los Servicios Web el mundo de la arquitectura y remodelación es uno de los negocios que se encuentra en auge en ciudades modernas, sino por el nuevo enfoque que se pretende dar a este tipo de negocios, utilizando tecnología de punta como son los Servicios Web. Para llevar a cabo el diseño del sistema se hará uso de la metodología aprendida en Diseño de Aplicaciones Distribuidas, esta metodología consta de varias fases que se mencionan a continuación:

Requerimientos y Análisis funcional Diseño Tecnológico

o Diseño de la arquitectura del sistema o Diseño de la consistencia

Diseño de Administración Diseño de clientes Diseño de servicios

SECCION 2.1: Requerimientos del Sistema Se desea diseñar un sistema que permita manejar la información referente a los procesos de realización de presupuestos de la empresa ISERVI, empresa encargada de proyectos arquitectónicos, como mencionamos anteriormente. Para poder realizar dicho sistema es necesario saber el proceso de negociación de un presupuesto y/o licitación de la empresa. En un principio cada proyecto es realizado para un cliente determinado, y consta de obras, que es como se denominan las diversas localidades del proyecto. Para cada Obra se realiza un cómputo, es decir, se realizan mediciones con base en unidades métricas que son las que nos ayudan a calcular el costo de la partida a realizar. Una partida es una actividad específica realizada con determinados elementos que pueden ser factor humano o materiales. Las partidas son clasificables según el ámbito al que apliquen dentro de la construcción.

Una vez que se realizan las mediciones pertinentes o cómputos, se procede a añadir los precios de cada partida o elemento según el proveedor que aportará el elemento.

Es necesario señalar que cada elemento tiene unidades de medida de acuerdo a la partida a la cual corresponde.

Una demanda es una solicitud compuesta por una lista de elementos o partidas que pueden ser realizada o proporcionada por el proveedor, ya sea un industrial o una tienda, esta se realiza con los costos que ISERVI (el constructor) piensa son convenientes. Esta demanda


Servicios Web 35

es enviada al proveedor para que él mismo entregue una oferta en donde quedaría indicado cuales actividades puede realizar y cuál es su precio para dichas actividades, o bien una simple aceptación de la demanda.

Si la oferta del proveedor se acepta por parte de ISERVI se concede el trabajo al proveedor. El presupuesto que se le entrega al cliente (para el proceso de licitación) contiene el total del cómputo, con los precios resultado de la suma de todas las partidas y elementos con precio de proveedores más una ganancia sobre cada uno de ellos. La diferencia entre un presupuesto de costo y uno para cliente es entonces la ganancia que establece ISERVI.

La empresa pretende utilizar la base de datos del ITEC, que es una base de datos que contiene la información referente a partidas, elementos, materiales y precios relativos; esto es un condicionante, pues se desea que la estructura y clasificación de las partidas, elementos, etc., de la BD de ISERVI a diseñar siga la establecida en la BD del ITEC.

Objetivos específicos del Sistema

Permitir que las empresas constructoras realicen la publicación de demandas de trabajo para ser entregadas a los proveedores.

Permitir a los proveedores realizar la publicación de precios para partidas (ofertas)

de demandas enviadas a los mismos.

Permitir la generación automática de ofertas con base en los mejores precios disponibles para las partidas especificadas en las demandas de trabajo.


Servicios Web 36

SECCION 2.2: Análisis Funcional El análisis funcional es de suma importancia pues nos permite visualizar con claridad las funcionalidades que se desea formen parte del sistema, los datos asociados a ellas así como las posibles relaciones entre unas y otras. El análisis funcional presenta a nivel detallado las diversas partes, funciones y modos de interacción con el sistema; descripción de los datos, relaciones y estructura, entre otros. La metodología de diseño rápido de aplicaciones distribuidas no especifica el uso de una metodología de Análisis Funcional determinada; dejando a criterio del equipo de desarrollo la escogencia de aquella metodología que mejor se adapte a los conocimientos de los miembros de dicho equipo. En nuestro caso particular se ha decidido utilizar la metodología de casos de uso sugerida en el método Rational Unified Process. De dicha metodología de análisis se decidido utilizar los siguientes elementos de notación, fundamentados en UML: Escenarios, Casos de Uso, Diagramas de Secuencia, Modelo de Datos, Definición de Entidades y Modelo Relacional. Escenarios Los escenarios que se presentan a continuación engloban los diferentes casos de uso que incluye el sistema: Escenario 1: Este escenario permite visualizar los casos de uso en los cuales el actor principal es el constructor y donde se manejan las demandas.

Figura 2.1: Escenario Gestión de Demandas


Servicios Web 37

Escenario 2: Este escenario permite visualizar los casos de uso en los cuales el actor principal es el proveedor y donde se manejan las ofertas.

Figura 2.2: Escenario Gestión de Ofertas Escenario 3: Este escenario permite visualizar los casos de uso en los cuales el usuario del sistema es el actor principal y se manejan variables necesarias para el mismo, como lo son la existencia de registros con los datos de proveedores, de constructores y las posibilidades de consultar precios y partidas existentes.


Servicios Web 38

Figura 2.3: Escenario Gestión de Variables del Sistema Casos de Uso del Sistema Los casos de uso representan el modo en el cual el usuario o la aplicación interactúan con el sistema utilizando alguna de las funciones del servicio para obtener una respuesta. A continuación presentamos la descripción de los diferentes casos de uso ordenados según los diferentes escenarios expuestos: Escenario 1:

Caso de uso: Crear Demanda Actores: Constructor Propósito: Asignar a un proyecto las partidas y cómputos relacionados. Caso de uso: Editar Demanda Actores: Constructor Propósito: Modificar en un proyecto las partidas y sus cómputos relacionados. Caso de uso: Eliminar Demanda Actores: Constructor Propósito: Borrar las demanda seleccionada. Caso de uso: Publicar Demanda Actores: Constructor, Proveedor. Propósito: Permite que el constructor publique una demanda, es decir, que haga un pedido a proveedores incluyendo las partidas que desea y los precios que el mismo


Servicios Web 39

sugiere, siendo finalmente enviada una notificación a los proveedores elegidos por el constructor. Caso de uso: Consultar Ofertas Actores: Constructor Propósito: Permite al constructor observar las diferentes ofertas que le han sido enviadas por los diversos proveedores a quienes previamente se les había notificado de la existencia de la demanda.

Escenario 2:

Caso de uso: Crear Oferta Actores: Proveedores Propósito: Asignar los precios a las partidas pertenecientes a una demanda que pueden ser realizadas por un proveedor. Caso de uso: Editar Oferta Actores: Proveedores Propósito: Modifica los precios y/o partidas pertenecientes a una oferta existente. . Caso de uso: Eliminar Oferta Actores: Proveedores Propósito: Borrar la oferta seleccionada. Caso de uso: Publicar Oferta Actores: Constructor, Proveedor. Propósito: Permite al proveedor realizar una publicación de oferta, es decir, el proveedor obtiene una demanda cuya existencia se le había notificado, modifica los contenidos de la misma transformándola en una oferta, es decir, seleccionando las partidas que puede realizar y los precios que puede proveer y finalmente la guarda en el sistema. Una vez guardada la oferta se notifica al constructor y el mismo podrá aceptar, rechazar o replicar la oferta (donde replicar implica incluir algunas observaciones sobre la oferta). Caso de uso: Consultar Demandas Actores: Proveedor Propósito: Permite al proveedor observar las diferentes demandas que le han sido enviadas por diversos constructores. Caso de uso: Publicar Precios Actores: Proveedor Propósito: Permite que un proveedor realice una publicación de precios, es decir, obtener un conjunto de partidas de una demanda dada, asignarle sus precios y almacenarla en el sistema.


Servicios Web 40

Escenario 3: Caso de uso: Alta Constructor Actores: Constructor Propósito: Permite incluir o modificar en el sistema los datos de un nuevo constructor. Caso de uso: Alta Proveedor Actores: Proveedor Propósito: Permite incluir o modificar en el sistema los datos de un nuevo proveedor. Caso de uso: Consultar Precios Actores: Proveedor, Constructor. Propósito: Permite obtener los precios de las partidas para determinado proveedor. Caso de uso: Consultar Partidas Actores: Proveedor, Constructor. Propósito: Permite consultar en el sistema los datos las partidas existentes.


Servicios Web 41

Diagramas de Actividad Los diagramas de actividad muestran las operaciones necesarias para realizar o llevar acabo un caso de uso. Los siguientes diagramas corresponden a los casos de usos utilizados en el ejemplo práctico:

Figura 2.4: Diagrama de Actividad Publicar Demanda En la figura 2.4 se presentan las actividades que se llevan a cabo para que el constructor realice la publicación de una o varias demandas. En un principio se seleccionan las demandas a publicar, están son enviadas al servidor en el cual se lleva acabo el proceso de guardar, en caso de que durante el proceso de almacenamiento se produzca un error se realiza el reporte del mismo. Una vez guardadas las demandas o la demanda, se marca como publicada en el lado del cliente, se notifica al proveedor de la existencia de una o varias nuevas demandas y finaliza la publicación de demandas.


Servicios Web 42

Figura 2.5: Diagrama de Actividad Publicar Oferta

En la figura 2.5 se muestra el conjunto de actividades que se llevan a cabo para que el proveedor realice la publicación de una oferta, en primer lugar se seleccionan las ofertas a publicar, están son enviadas al servidor en el cual se lleva acabo el proceso de guardar, en caso de que durante el proceso de almacenamiento se produzca un error se realiza el reporte del mismo. Una vez guardada la oferta se notifica al constructor y finaliza la publicación de oferta.

Figura 2.6: Diagrama de Actividad Publicar Precios

En la figura 2.6 se muestra el conjunto de actividades que se llevan a cabo para que el proveedor realice la publicación de precios. Para iniciar se obtienen las partidas existentes en el sistema, (una vez que el proveedor haya realizado las modificaciones pertinentes) el nuevo precio de la partida o partidas seleccionadas, es enviado al servidor para ser almacenado y/o guardado. Existe la posibilidad de que se produzca un error al intentar


Servicios Web 43

guardarlo y en ese caso se realiza un reporte de error, sino, la operación Publicar Precio finaliza cuando el nuevo precio es almacenado. Diagramas de Secuencia Considerando las diversas funcionalidades que el sistema debe poseer procedemos entonces a mostrar los diagramas correspondientes a los casos de uso que forman parte del caso práctico. Estos han sido realizados con notación UML, la cual fue vista en los cursos de Diseño de Bases de Datos y Diseño Avanzado Orientado a Objetos. Los diagramas de secuencia determinan como interactúan en el tiempo diferentes clases con el fin de resolver determinado caso de uso.

Figura 2.7: Diagrama de Secuencia Caso de Uso Publicar Demanda


Servicios Web 44

Figura 2.8: Diagrama de Secuencia Caso de Uso Publicar Oferta

*Al replicar oferta se repite el proceso desde la publicación de la oferta por parte del proveedor

Figura 2.9: Diagrama de Secuencia Caso de Uso Publicar Precios


Servicios Web 45

Modelo de datos El modelo de datos presentado comprende el sistema en su totalidad siendo la parte resaltada aquella correspondiente al modulo implementado en el caso práctico. Definición de Entidades Luego de realizado la inspección visual de la descripción del problema se han identificado las siguientes entidades que participan en el dominio del sistema (Tabla 2.1): Entidad Descripción Cliente Persona o empresa para quien se realiza el

proyecto. Proyecto Trabajo total realizado para un cliente en

determinado lapso de tiempo que puede incluir diversas obras.

Obra Cada uno de los macro-elementos constructivos en los que se divide un proyecto.

EstructuraComputo Conjunto de cómputos que corresponden una obra. Computo Cada una de las mediciones según las que se

presupuesta cada obra de un proyecto. Ambiente Cada uno de los espacios en que se divide una

obra AmbienteEstructura Contiene los ambientes asociados a una estructura

de cómputo. Tipologia Estructura jerárquica de los ambientes. AmbienteTipologia Contiene los ambientes que conforman una

tipología arquitectónica establecida Demanda Agrupación de cómputos enviados a uno o varios

proveedores con el fin de que estos envíen ofertas de trabajo.

ComputoDemanda Cómputos incorporados en una demanda de trabajo.

Oferta Respuesta de los proveedores a una demanda de trabajo.

ComputoOferta Cómputos incorporados en una oferta entregada por un proveedor en respuesta a una demanda de trabajo.

Presupuesto Conjunto de cómputos con su costo respectivo creado con base en las ofertas recibidas.

ComputoPresupuesto Cómputos incorporados en el presupuesto final entregado al cliente del proyecto. Todos los cómputos de un presupuesto deben corresponder a los incluidos en las ofertas recibidas de los proveedores.

Capitulo Agrupación de partidas según su tipo.


Servicios Web 46

Partida Conjunto de elementos que configuran una unidad de obra y que es realizada por un mismo grupo de especialistas. Por ejemplo: metro cuadrado de enyesado reglado de pared.

Elemento Materiales, mano de obra o maquinaria requerimiento básico al momento de realizar cualquier partida de obra. Por ejemplo un kilo de cemento, una hora de alquiler de una bomba hidráulica, una hora de un paleta.

PartidaElemento Conjunto de elementos que corresponden a determinada partida.

Proveedor Persona y o empresa que aporta los elementos o partidas necesarias de acuerdo a su campo.

EnvioDemanda Registro de los envíos de las demandas a los proveedores.

Tabla 2.1: Definición de Entidades

Del mismo proceso de inspección visual mencionado anteriormente se han obtenido las siguientes relaciones: �� !�� !��"��#��!�$��#�� $�� !��"�� !�� "� ��

��$��!��$�� !��"��%�$��!��$�� &�� !��"��!�� !��$��'��!��$�� !��$��!�� !��"��$��!�� (�� !��!�� (�$��$�� !�$��)��!�� !�� "� �%�$��

��*��!�$��$�� !��"��$��

��$��$��#�� *�� $��$��

!��$�� $�� !��"�$��!��$�� $�� "��$'��!��$�� !��"��

Tabla 2.2: Definición de relaciones entre entidades


Servicios Web 47

Al integrar el conjunto de entidades y relaciones mostrado anteriormente se obtiene el siguiente modelo conceptual, el cual se representa utilizando la notación sugerida por UML en su diagrama de clases.

Figura 2.10: Modelo Entidad Relación (Datos)


Servicios Web 48

SECCION 2.3: Diseño Tecnológico Modelo del entorno general Una vez realizado el análisis funcional del sistema se procede a realizar el diseño distribuido, para lo cual se utiliza la metodología vista en el curso de Diseño de Aplicaciones Distribuidas7. A continuación se presenta el conjunto de módulos que componen la solución completa para el sistema ISERVI. Debido a la gran complejidad que involucra la implementación de la totalidad de los módulos para el caso práctico, se decidió implementar solamente el Modulo de Gestión de Ofertas por su sencillez a nivel funcional y mayores posibilidades de reutilización en el mundo de los negocios.

Figura 2.11: Modelo General del Sistema

7 Para consultar la notación de esta metodología referirse al Anexo 1


Servicios Web 49

Modelo del entorno para la gestión de ofertas A partir de este punto el diseño se centra en el modulo de gestión de ofertas, tal como se indicó en la sección anterior. La figura 2.15 muestra el diagrama de contexto para este modulo en el cual se observa la interacción con los agentes externos proveedor y constructor, al igual que con las entidades demandas, ofertas, partidas y precios asociadas a las mismas.

Figura 2.12: Modelo del Sistema de Gestión de Ofertas Las siguientes tablas describen cada uno de los componentes clasificándolos según sea su interacción con el sistema en entidades de entrada y salida.

Entidades de entrada �� )��

$�� )�� $�� +��$��,�

�� $�-'��*��$��)�� $�� +��%� ��$��#��%,�

�� $��


Servicios Web 50

��)�� $�� +��%� �� $��#�� %,�

�� +��$��*��+�� *�� $��$�� +�� $��#�� %,�

�� .��*��$��)��$��+��%��+��$��,�

Tabla 2.3: Entidades Entrada

Entidades de salida �� +��$��*��+��

�� *�� $��$�� +�� $��#�� %,� � �� $��,�

�� $��+��$��$��$��)��$�� $�� $�� $�� $��)��,�

�Tabla 2.4: Entidades Salida


Servicios Web 51

Sistemas de información Los sistemas de información externos son todas aquellas aplicaciones de software que intercambian información con el sistema que se diseña. Complementando la figura 2.12, la figura 2.13 muestra los subsistemas de información externos con los cuales interactúa el modulo de gestión. Estos a su vez son descritos en la tabla 2.6.

�

Figura 2.13: Sistema de Información Gestión de Ofertas �� /��%��$��)��

��$��)��#��$��*��$��+��%�� $�� %� �� *��+�,�

/��%�� $�-'��%,�

/��%��$�� .�� "�� $�� %� �� *�� $��#�� %,�

Tabla 2.5: Sistemas de Gestión


Servicios Web 52

Modelo de procesos Tal como ha sido la línea seguida hasta ahora en el diseño tecnológico, los siguientes diagramas de procesos corresponden al modulo de Gestión de Ofertas implementado en el caso práctico. Los modelos de procesos son una vista más profunda del sistema de información, se observa para cada funcionalidad del sistema las operaciones o procesos de transformación que intervienen con el fin de llevar a cabo el proceso general. Partiendo de las entidades de entrada y por medio de los procesos de transformación se pueden generar modificaciones en las entidades de salida. Crear demanda Para crear una demanda (figura 2.14) lo primero que debe indicarse son sus datos generales. Por datos generales entendemos aquellos que caracterizan a la demanda: su descripción, fecha de creación, fecha máxima de presentación de ofertas o fecha de vencimiento, entre otros. Una vez establecidos los datos generales el usuario procederá a agregar las partidas que conformarán la demanda. Después de indicar los datos generales el usuario en cualquier momento podrá proceder a guardar la demanda. ��

�

Figura 2.14: Proceso Crear Demanda ��


Servicios Web 53

Crear Oferta Para crear una oferta (figura 2.15) lo primero que debe hacerse es localizar la demanda, una vez obtenida se procede a asignar precios solo a aquellas partidas que el proveedor puede llevar a cabo, luego de realizar dicha asignación se guarda la nueva oferta y de esta forma finaliza el proceso. �

Figura 2.15: Proceso Crear Oferta

Crear Contra Oferta Para crear una Contra Oferta (figura 2.16) lo primero que debe hacerse es localizar la oferta, una vez obtenida se procede a ubicar el historial de replicas, luego se modifican los precios de aquellas partidas que se deseen cambiar en dicha oferta y por ultimo se guarda la nueva oferta.

�Figura 2.16: Proceso Crear Contra Oferta


Servicios Web 54

Resumen de procesos

Crear demanda o Establecer datos generales o Agregar partidas o Guardar demanda

Crear oferta

o Localizar demanda o Asignar precios o Guardar oferta

Crear Contra Oferta

o Localizar oferta o Obtener historial replicas o Modificar precios o Guardar replica

�Entidades Internas �� $�� $��

��,��$�� $��

�� $�� $��)�� $�� )��,�

��$�� )�� $�� $��)�� %��$��$��,�

��$��$�� $�� $��$��,�

Tabla 2.6: Entidades Internas


Servicios Web 55

Diseño de la arquitectura del sistema distribuido Análisis de datos �Se establecen 2 niveles lógicos en la aplicación:

� Clientes locales para la gestión “offline” de las ofertas y demandas � Servidor central para la publicación de las ofertas y las demandas

�Localización de datos En la siguiente tabla se observa la ubicación de los datos por entidad. Es decir, siendo cada entidad un conjunto de datos se almacenan en diferentes localidades como lo pueden ser el servidor, el cliente del constructor o el cliente del proveedor. ��

��

�� #��%�

�� $��$��

��$�� #��%�

�� $��$��

�� $��$��

��#��%�

��$�� $��$��

��#��%�

��$�� #��%�

��#��%�

��$��$�� #��%�

��#��%�

�� 0�� 0� ��$��

$��$��$��

�Tabla 2.7: Localización de Datos

De acuerdo a los datos encontrados en la tabla anterior se ha elegido un modelo de datos centralizado par a la publicación de las ofertas y demandas.


Servicios Web 56

Flujo de datos El flujo de datos representa el modo en que se actualiza la información que ha sido modificada, entre los clientes y el servidor. Como se observa en la figura 2.20, los elementos a ser modificados son las demandas, ofertas y contraofertas, que suelen ser editados en los procesos clientes y cuya actualización se realiza hacia el servidor en el momento en que se publican. En caso de que el cliente realice una actualización de sus elementos se recurre al servidor.

Figura 2.17: Flujo de Datos


Servicios Web 57

Procesos de actualización de datos A continuación se muestran los diagramas de flujo correspondientes a los procesos de actualización de datos de la fracción del sistema implementada en el caso práctico. Los procesos involucrados son Iniciar sesión, Publicar Demanda, Publica Oferta y Publicar Contra Oferta. Cada uno de estos presenta las entidades y procesos que los componen. ��Iniciar sesión�

Figura 2.18: Proceso Inicio de Sesión Publicar demanda

�

Figura 2.19: Proceso Publicar Demanda


Servicios Web 58

Publicar oferta �

�

Figura 2.20: Proceso Publicar Oferta �Publicar Contra Oferta

Figura 2.21: Proceso Publicar Contra Oferta


Servicios Web 59

Identificación de funciones �

Crear demanda o Establecer datos generales o Agregar partidas o Guardar demanda

Crear oferta o Localizar demanda o Asignar precios o Guardar oferta

Crear replica o Localizar oferta o Obtener historial replicas o Modificar precios o Guardar replica

Iniciar sesión o Validar usuario o Verificar nuevos elementos o Enviar nuevos elementos a cliente o Registrar sesión

Publicar demanda(s) o Enviar demanda(s) al servidor o Notificar a interesados

Publicar oferta(s) o Enviar oferta(s) al servidor o Notificar a interesados

Publicar replica o Enviar replica(s) al servidor o Notificar a interesados

Ubicación procesos


Servicios Web 60

Los diversos procesos que componen el sistema se encuentran ubicados en alguno de los niveles lógicos del sistema, que como se mencionó con anterioridad son los clientes de proveedor y constructor y el servidor central. La ubicación de estos procesos en alguno de los niveles lógicos se presenta a continuación (Tabla 2.9). �

�� 0� �� 0� �� 0� �1��%� � 0�� 0� 0�� 0� 0�� 0� 0�

�Tabla 2.8: Ubicación de Procesos

Identificación de servicios Los servicios identificados como parte del subsistema de gestión de ofertas se presentan en la Tabla 2.9, junto a una descripción de la función de cada uno de estos: ��

��)�� %��*��,�

��)��$�� (�� $�� $�� )��,�

��)�� (��)��)��2��,��

��)�� +��%�� $��)�� $��%� �� )�� *�� $��'��,�

��)�� !��$��)��$��)'��+��%��,�

��)�� (��)3��$��#��)��$��)��,�

Tabla 2.9: Descripción de Servicios


Servicios Web 61

Como puede observar en la figura 2.22, Modulo de Gestión de ofertas, el subsistema constará de 4 servicios básicos, el de publicación de precios, el de publicación de demandas, de generación de ofertas y el gestor de la base de datos.

Figura 2.22: Modulo Gestión de Ofertas

Figura 2.23: Modelo del Sistema Gestión de Ofertas


Servicios Web 62

Interfaces Las interfaces son el conjunto de instrucciones que permiten que un servicio pueda acceder a determinadas funciones o métodos prestados por otro servicio. Haciendo referencia a la figura 2.1 donde se presenta un diagrama de la arquitectura básica del sistema así como también a los casos de uso anteriores, podemos observar que el mismo consta de diversos gestores, entiéndase mecanismos de manipulación de la información. En este caso los gestores serían los siguientes:

Gestor de Bases de Datos Gestor de Ofertas Gestor de Demandas Gestor de Proveedores Gestor de partidas Gestor de Constructores

Cada uno de los gestores que constituirán el sistema deberán implementar las siguientes funciones o métodos:

��

�� )��

��

$�� $�� $��

��

��)�� $��

��

$��

��

��

Tabla 2.10: Interfaces


Servicios Web 63

Arquitectura Cliente Servidor Una vez identificados los servicios, es posible completar la construcción de la arquitectura cliente servidor. Los siguientes diagramas permiten observar la interacción C/S, donde los servicios son los mencionados anteriormente y los clientes se visualizan como agentes externos; se presenta el medio de comunicación, que se basa (en el caso específico de este proyecto) en diversos Servicios Web; así como también la relación entre servicios. Iniciar sesión �

Constructor Identificaciónusuario

Servidor desesiones

Servidor de datos

Usuario

Sesión

Solicitarnuevos

elementos

[Autentifiacióncorrecta]

Servidor deactualizaciones

Obtenernuevos

elementos

Solicitudesnuevos

elementos

Respuestassolicitudes

Servidor de datos

Ofertas

Contraofertas

Ofertas ContraOfertas�

�Figura 2.24: Proceso Iniciar Sesión


Servicios Web 64

Publicar demanda

�Figura 2.25: Proceso Publicar Demanda

�Enviar notificaciones �

��

Figura 2.26: Proceso Enviar Notificaciones


Servicios Web 65

“Map to reality” El “Map to Reality” menciona la manera en la cual se implementará el sistema. Las diferentes tecnologías a utilizar, que se encuentran en el mercado actualmente, para el desarrollo del sistema serán las siguientes: Infraestructura del sistema �

��)��o 4��5��)��o .��67��)��o 1��1��)�� 11��

� ��)��

o (2��)��

.��5��o .��.��6��

� ��

o 4��5��80��o 9��o .��&��


Servicios Web 66

SECCION 2.4: Diseño de la consistencia �El diseño de consistencia permite hacer a las aplicaciones distribuidas robustas, es decir, resistentes a fallos y caídas. Este diseño se realizará en este proyecto mediante el estudio de la semántica de servicios para recuperación de caídas y situación o trabajo en emergencia. 2.4.1 Semántica de servicios �En la Tabla 2.11 se clasifican los servicios identificados de acuerdo a su comportamiento en caso de caídas. �� )�� :&��;� ��)��$�� :&��;� ��)�� :&��;� ��)�� :&��;� ��)�� :&��;� ��)�� :(2��#��;� �

Tabla 2.11: Semántica de Servicios

�En donde: “At least once”: es una semántica que garantiza que, si el servidor ha sido llamado, el servicio se ha ejecutado, esto es que el servidor es de ejecución segura. “At most once”: en este caso el servidor es capaz de saber si el servicio ya se ha solicitado, garantiza que el servicio no ha quedado sin acabar y que si hay una nueva petición del mismo servicio, se recupera el estado anterior y se transmite al cliente. “Exactly once”: semántica que garantiza la fiabilidad total, en donde el cliente no necesita controlar la ejecución del servicio. Es el servidor ideal ya que garantiza la ejecución única en cualquier circunstancia. 2.4.2 Diseño de la Situación de emergencia �En el caso de que los servicios no puedan recuperarse se deben tomar en cuenta las consideraciones mostradas en la siguiente tabla: ��


Servicios Web 67

�� )�� )��'��

��$��"�$��)��#��$�� '� $��"� �� $��+�� $��$��,�

��)��$�� 7�� $��"� $��)��$�� $��$��,�

��)�� 7��$��"��)��$�� $�� $��,�

��)�� )�� "��'��$��%��"� �� *�� "��)�� )�� )��,�

��)�� 7�� $��"� $�� )�� $�� $��$��,�

��)�� (��)��:��;,�

Tabla 2.12: Diseño Situación de Emergencia

��


Servicios Web 68

CAPITULO 3 CONCLUSIONES Una vez realizado el marco teórico e implementado el caso práctico el grupo desea destacar las siguientes conclusiones: Actualmente la información existente sobre el tema de los Servicios Web es ampliamente dispersa y difusa, es decir, complicada de abstraer e integrar en una sola investigación. Los Servicios Web son una tecnología que aun no alcanza su nivel de consolidación. Muchos trabajos de investigación y desarrollo están siendo realizados por las diferentes organizaciones involucradas en la difusión y puesta en práctica de ésta tecnología.

Los Servicios Web, no son una idea nueva, sin embargo, si son una oportunidad de lograr la interoperabilidad de los sistemas actuales y de que cada empresa se concentre en su negocio. Los Servicios Web permitirán que se sigan usando los sistemas legados de las empresas y que éstas se conecten a la vez con sus aliados de negocios, haciendo uso de Internet como canal de comunicación. Esto no excluye la posibilidad de crear Servicios Web al interior de las organizaciones (intranet) y con algunos aliados particulares (extranet), para lograr así la optimización de procesos y operaciones. Los Servicios Web son una oportunidad de negocio no sólo para las empresas que desarrollen y publiquen sus servicios, sino también para las empresas consumidoras de servicios y para los vendedores de hardware y software que necesitarán hacer cambios radicales en la forma de orientar sus ventas, además de desarrollar nuevos productos que permitan manejar Servicios Web. El concepto de programación orientada a objetos facilita el entendimiento del proceso de desarrollo de los Servicios Web, así como su fundamentación básica en el concepto de encapsulamento. Aun cuando a nivel técnico se ha alcanzado un adecuado nivel de estandarización que permite la interconexión de sistemas independientes utilizando servicios Web, queda mucho trabajo por hacer en cuanto a la definición de dialectos de XML propios de cada tipo de negocio que faciliten el entendimiento entre dichos sistemas La diferencia fundamental entre los servicios Web y los componentes actuales se encuentra en la granularidad de los datos, es decir los servicios Web ejecutan funciones discretas sobre grandes volúmenes de datos mientras que los componentes son unidades complejas que actúan sobre unidades de datos atómicas. Los servicios Web surgen gracias a la madurez alcanzada con la programación orientada a componentes, la consolidación de Internet como herramienta de interconexión remota y la necesidad de acercar el lenguaje informático al lenguaje de los negocios.


Servicios Web 69

ANEXO 1: Notación del Diseño de Sistemas Distribuidos La siguiente tabla contiene los símbolos utilizados para presentar diagramas de flujo (modificados) o procesos de transformación del modo visto en la asignatura de Diseño de Aplicaciones Distribuidas. Cada elemento se presenta con una breve descripción de lo que representa y el icono correspondiente.

Elemento Descripción Icono Agente Externo Elemento que proporciona o

recibe información del sistema.

Entidad Agrupación de datos que representa una unidad de información.

Proceso Proceso de Transformación.

BB.DD. Entidad representada sobre la base de datos.

Servidor Proceso de transformación.

Flecha Gruesa Para indicar el los diagramas la secuencia en la que se ejecutan procesos.

Servicio Web Servicio Web

Página ASP.NET Página ASP implementada

con Visual Studio .NET

�� Servicio Gestor Servicio Gestor

Tabla Anexo 1: Notación de los Diagramas


Servicios Web 70

Anexo 2: Implementación Ejemplo Práctico Mapas conceptuales de navegación a) Cliente constructor �

Login.aspx

Principal.aspx

Pedidos.aspx

Pedido.aspx

Computo.aspx

menu.html

(Pedidos)

Related Pages

Autenticación Ok

(Nuevo)(Editar)

(Publicar)

(Guardar)

(Nuevo computo)

(Editar computo)

(Borrar computos)

(Guardar computos)

GestorPedidos

Pedido

Application

Session

PublicarPedidos

ServicioPublicacion

�Figura Anexos 2.1: Diagrama de navegación del cliente constructor�

�La figura anterior muestra el esquema conceptual (con énfasis en el sistema de enlaces y navegación) del cliente utilizado por los constructores para crear y publicar demandas de trabajo. El cliente Constructor se implementó como una aplicación Web utilizando la plataforma Visual Studio .NET. Esta aplicación consta de un conjunto de páginas Web y 2 clases que implementan la lógica de negocios para la gestión de demandas y la comunicación con el Servicio Web de publicación.


Servicios Web 71

La tabla siguiente muestra el conjunto de componentes que constituyen el cliente Constructor. �� 7��,�$2� �"��&��,<(9� �"��%��$��,�$2� �"��&��,<(9� �"��$��$��,�$2� �"��&��,<(9� �"��,�$2� �"��&��,<(9� �"��$��$��

��%��$�� )��

��$��,�$2� �"��&��,<(9� �"��$��$��%��$��$�� )��

/��,)�� *��$��%��%��#��%��)��4��$��%�

��,)�� *��$��%��$��%�#��%��$��,�

Tabla Anexos 2.1: Componentes cliente constructor �

b) Cliente proveedor

Figura Anexos 2.2: Diagrama de navegación del cliente proveedor �La figura anterior muestra el esquema conceptual (con énfasis en el sistema de enlaces y navegación) del cliente utilizado por los proveedores para obtener los demandas de trabajo


Servicios Web 72

publicados por los constructores y contestar a estos en forma de ofertas (función no implementada en el ejemplo práctico). El cliente Constructor se implementó como una aplicación Web utilizando la plataforma Visual Studio .NET. Esta aplicación consta de un conjunto de páginas Web y 2 clases que implementan la lógica de negocios para la gestión de demandas y la comunicación con el Servicio Web de actualización. La tabla siguiente muestra el conjunto de componentes que conforman el cliente proveedor. �� 7��,�$2� �"��&��,<(9� �"��%��$��,�$2� �"��&��,<(9� �"��$��$��,�$2� �"��&��,<(9� �"��

$��,�$2� �"��&��,<(9� �"��$��$��

��%��$�� )��

/��,)�� *��$��%��%��#��%��)��4��%�

��,)�� *��$��%��$��)��%��$��,�

�Tabla Anexos 2.2: Componentes cliente proveedor


Servicios Web 73

Los servicios �En esta sección se presentan los archivos de descripción, los mensajes SOAP y la implementación particular que hace el Visual Studio .NET de la invocación de los servicios Web. �a) Archivos de descripción (WSDL) �

a.1) Servicio de publicación Como puede notarse un archivo de descripción contiene 5 secciones: �� :�#$�;� (��%��$��

�$��$��$��)��,�(� �� $�� +��$�� $�� )�� $��"�� :�=��+��;� �$�� *��:��,2�;� �� 4��7� �� >��:��$��$��;,�

:��;� (�� %� :��;� �� +�� *��$�� )�� $�� )��,� � ?"��"�� +�� $�� )��@��$�� )��%� �� +�� $1�� #� �� $�� $�� $��,�(��$��+��$��$��+��:��$1;�#�:��$��;�

:$��#$�;� (� �� %� �� $�� )��%��+��$��,�� *�� 2�� "�� A� �3�� )��%@��&��:/��;�#�:��;�

:��;� (��%�:��;��$��$��$��)��%,� �� :/��;�#� :��;��3��)��%�� )�� *��$��&�� $��$��$�� "��B��)��$��%C��$��:��$;�,�

:��)��;� (�� %�*��$��$�� )��,� ��$��)��+��$��$�"��)��%��)��4��"��$��$��+��3��$��)��%�$��$��%� ��$�� $�� )��%��$��C:$��;C��%��%��)��Tabla Anexos 2.3: Secciones archivo de descripción.


Servicios Web 74

Descripción del Servicio de Publicación �� -��

��

��

��

��

��

��

��

��

��

�� ! �� ! �

��"��#��!��

-��"��-�� #��$��$� ��

��

�� !��

-�� %�! ��-��%"��

-��&�� -�� '��'��

��&�!'��-��%"��

-��&�� "�

��

��!�� !��&��

��!��%"�� !��

��!��&�� !��%"��

��!�� -�� %�! ��(��

��%"��!�� !��

��!�� !�"��-�� %�! ��)��

�� %�! ��!��

��!��-�� %�! ��*��

�� %�! ��(��!��

��!��


Servicios Web 75

-��%"�� %�! ��-�� %�! ��

�� %�! ��)��!�� %�! ��*��!��

��!�� !��%"�� %"�� %�! ��+��,��!�� %"�� %�! ��+��%��!��-��(� �� %�! ��

�"�� %�! �� (� ��

��

�"��!��-�� %�! ��

�� )�� %�! ��

�"��!��-��

��(��"�� !�� !� ��-��

��(��"�� !�� !��

��!�� !(� �� -��(� �� %�! ��+��,��

�"�� %�! ��+��,�� (� �� (��,-.��!��

��!(� �� -��(� �� %�! ��+��%��

�"�� %�! ��+��%�� (� �� (��%*�.��!��

��!(� �� -�� %�! ��

-�� %�! ��(� �� %�! ��

�� ! ��

��! ��!�� !��-�� %�! ��+��,��

(� �� %�! ��+��,��

�� ! ��

��! ��!�� !��-�� %�! ��+��%��

(� �� %�! ��+��%��


Servicios Web 76

�� ! ��

��! ��!�� !��

��!�� !�� a.2) Servicio de actualización �Para la lectura del siguiente archivo de definición refiérase a la explicación correspondiente al equivalente para el Servicio de Publicación. � �� -��

��

��

��

��

��

��

��

��

��

�� /�� 0�� /��

� �0��"��#��!��

-��"��-�� #��$��$� ��

��

��!��

-�� *!��-��%"��

-��&�� '��'��

��&��1��"��!�� !��&��

��!��%"�� !�� -�� *!��(��

-��%"��-��&��

-�� '��'�� *!��(��

-��%"��-��&��

�� "� ��

��!�� !��&��


Servicios Web 77

��!��%"�� !��

��!��&�� !��%"��

��!�� -�� (��

-��%"��-��&��

�� "� ��

��!��

��!��&�� !��%"��

��!�� !��

��!�"��-�� *!��)��

�� *!��!��

��!��-�� *!��*��

�� *!��(��!��

��!��-�� *!��+��,��)��

�� &��1��"��!�� !��-�� *!��+��,��*��

�� 2��3�� !�� !��-�� *!��+��%��)��

�� &��1��"��!�� !��-�� *!��+��%��*��

�� 2��3�� !�� !��-��%"�� /�� 0��

-�� *!�� *!��)��!�� *!��*��!��

��!�� !��%"��-��%"�� /�� 0��+��,��

-�� *!�� *!��+��,��)��!�� *!��+��,��*��

!�� !��

��!��%"��-��%"�� /�� 0��+��%��


Servicios Web 78

-�� *!�� *!��+��%��)��!�� *!��+��%��*��

!��

��!�� !��%"��-��(� �� /�� 0��

�"�� /�� 0�� (� ��

��

�"��!��

-�� *!��

��)�� *!��

�"��!��-��

��(��"�� !�� !� ��-��

��(��"�� !�� !��

��!�� !(� �� -��(� �� /�� 0��+��,��

�"�� /�� 0��+��,�� (� �� (��,-.��!��-�� *!��

�� *!��!��-��

��* ��!�� !� ��-��

��+��2��3��!�� !��

��!�� !(� �� -��(� �� /�� 0��+��%��

�"�� /�� 0��+��%�� (� �� (��%*�.��!��-�� *!��

�� *!��!��-��

�� "�� 4��4��4�� !��

��!� ��-��

��+��2��3��!�� !��

��!�� !(� ��


Servicios Web 79

-�� /�� 0��-�� /�� 0��

(� �� /�� 0��

�� /�� 0��

� ��/�� 0��!�� !��-�� /�� 0��+��,��

(� �� /�� 0��+��,��

�� /�� 0��

� ��/�� 0��!�� !��-�� /�� 0��+��%��

(� �� /�� 0��+��%��

�� /�� 0��

� ��/�� 0��!��

��!�� !��

��!�� b) Invocación de las operaciones del Servicio �A continuación se muestran los mensajes que se envían y reciben del servicio de actualización implementado en el ejemplo práctico. Como puede observarse ambos mensajes se “empaquetan” en un elemento de tipo “Envelope” según el estándar SOAP. En el cuerpo del mensaje se indica la operación que se desea acceder (en el caso de la invocación) o bien se recibe el resultado de dicha operación (como podrá verse en el mensaje de respuesta que se muestra más abajo) �

b.1) Servicio de actualización �.3��:��;@��%��

�� !!� ��!��!� ��!��

�� !!"""�"#��!$��!%&'(� ��

�� !!"""�"#��!$��!%&'(� ��

��)��*��

��+,�� -�� +,�� -�� +,�� -�� +,�� -�� !!��!��

��.�/��0�� !�.�/��

��!+,�� -��

��!��)��*��

�!�� !�� !�� !��

�.3��:��;@��$��


Servicios Web 80

Un aspecto importante a destacar en el mensaje de respuesta es la presencia de la definición del esquema XML utilizado por el servicio para enviar los datos solicitados. Este hecho favorece la interpretación de los mismos por cualquier componente independientemente de la plataforma en que haya sido implementado. ��1�� 2��$��3+45�

(��&��66(!7��

-��(� 8�$9�:� �$��#��##�$9�;&<�

2�� 2� ��8��

2� �� <*��!��=�� >�

2� �� '� �� #?>#�

��

�� !!� ��!��!� ��!��

�� !!"""�"#��!$��!%&'(� ��

�� !!"""�"#��!$��!%&'(� ��

��)��*��

��+,�� -�� 1�� +,�� -�� 1�� +,�� -�� 1�� +,�� -�� 1�� !!��!��

��+,�� -�� 1��+,�� -�� 1��+,�� -�� 1��+,�� -�� 1��

�� -�� -�� -�� -�� @�� !!��!-��

�� !!��!-��

�� !!��!-��

�� !!"""�"#��!$��!%&'(� ��

��,��A��-��B�� A��-��B��

�� -�� 6-��(��

�� 2� �� A��

��<*��<*��<*��<*��

�� +�� ,��

�� -�� -�� -�� -��

��<*��<*��<*��<*��

��B�� B�� B�� B��

�� 6--�� *�� !�� 6--�� *�� !�� 6--�� *�� !�� 6--�� *�� !��

�� 6-/��*�� !�� 6-/��*�� !�� 6-/��*�� !�� 6-/��*�� !��

�� -�� -�� *�� +�� -�� -�� *�� +�� -�� -�� *�� +�� -�� -�� *�� +��

!�!�!�!��

�� A�� -�� *��<�� +��!�� A�� -�� *��<�� +��!�� A�� -�� *��<�� +��!�� A�� -�� *��<�� +��!��

�� @��,�/��*�� !�� @��,�/��*�� !�� @��,�/��*�� !�� @��,�/��*�� !��

�� '�� /��*�� +�� '�� /��*�� +�� '�� /��*�� +�� '�� /��*�� +��!��!��!��!��

��!��B�� !��B�� !��B�� !��B��

��!��<*��!��<*��!��<*��!��<*��

��!�� !�� !�� !��

�� 2��-�� 2��-�� 2��-�� 2��-��

��<*��<*��<*��<*��

��B�� B�� B�� B��

�� 6--�� *�� !�� 6--�� *�� !�� 6--�� *�� !�� 6--�� *�� !��

�� 6-/��*�� !�� 6-/��*�� !�� 6-/��*�� !�� 6-/��*�� !��

(��*��0.7��>��)��"��$��3��:��;,�


Servicios Web 81

�� @��2��*�� !�� @��2��*�� !�� @��2��*�� !�� @��2��*�� !��

�� 2��C��*�� 2��C��*�� 2��C��*�� 2��C��*�� +��!�� +��!�� +��!�� +��!��

�� 2� ��2��*��,�� +��!�� 2� ��2��*��,�� +��!�� 2� ��2��*��,�� +��!�� 2� ��2��*��,�� +��!��

��!��B�� !��B�� !��B�� !��B��

��!��<*��!��<*��!��<*��!��<*��

��!��

��!��

��!��<*��

�� B�� -�� 4�*��C��*4�*��

�� !!�� -�� !��

�� 6--�� !��

�� 6-/��!��

��!�� B��

�� B�� -�� 4�*$��

�� !!�� -�� !��

�� 6-/��!��

��!�� B��

�� B�� D�*��

�� !!�� -�� !��

�� 6--�� !��

��!�� B��

�� B�� -�� 4�*#��C��*4�*��

�� !!�� 2��-�� !��

�� 6--�� !��

�� 6-/��!��

�� @��2��!��

��!�� B��

��D�*�� -�� 2��-�� D�*��

�� !!�� 2��-�� !��

�� 6--�� !��

��!��D�*��

��!��

��!��

��

��

��-�� !!��!-�� -�� !!��!-�� -�� !!��!-�� -�� !!��!-��

��-�� -�� "+��-�� -�� "+��-�� -�� "+��-�� -�� "+��

��6--�� $�!6--�� 6--�� $�!6--�� 6--�� $�!6--�� 6--�� $�!6--��

��6-/��0�� !6-/��6-/��0�� !6-/��6-/��0�� !6-/��6-/��0�� !6-/��

��-�� -��-�� -��-�� -��-�� -�� -�� C��,��!-�� -�� -�� C��,��!-�� -�� -�� C��,��!-�� -�� -�� C��,��!-�� -��

��A�� -�� $��#��A�� -�� $��#��A�� -�� $��#��A�� -�� $��#��$$<�#�?��#��E��F�$��!A�� -�� $$<�#�?��#��E��F�$��!A�� -�� $$<�#�?��#��E��F�$��!A�� -�� $$<�#�?��#��E��F�$��!A�� -��

��@��,�/��:� � �!@��,�/��@��,�/��:� � �!@��,�/��@��,�/��:� � �!@��,�/��@��,�/��:� � �!@��,�/��

��'�� /��0�� !'�� /��'�� /��0�� !'�� /��'�� /��0�� !'�� /��'�� /��0�� !'�� /��

��!-�� !-�� !-�� !-��

��2��-�� 2��-�� "+��2��-�� 2��-�� "+��2��-�� 2��-�� "+��2��-�� 2��-�� "+��

��6--�� $�!6--�� 6--�� $�!6--�� 6--�� $�!6--�� 6--�� $�!6--��

��6-/��0�� !6-/��6-/��0�� !6-/��6-/��0�� !6-/��6-/��0�� !6-/��

(��>��*��0.7��


Servicios Web 82

��@��2��!@��2��@��2��!@��2��@��2��!@��2��@��2��!@��2��

��2��C��$�!2��C��2��C��$�!2��C��2��C��$�!2��C��2��C��$�!2��C��

��2� ��2��!2� ��2��2� ��2��!2� ��2��2� ��2��!2� ��2��2� ��2��!2� ��2��

��!2��-�� !2��-�� !2��-�� !2��-��

��2��-�� 2��-�� $��"+��2��-�� 2��-�� $��"+��2��-�� 2��-�� $��"+��2��-�� 2��-�� $��"+��

��6--�� $�!6--�� 6--�� $�!6--�� 6--�� $�!6--�� 6--�� $�!6--��

��6-/��0�� !6-/��6-/��0�� !6-/��6-/��0�� !6-/��6-/��0�� !6-/��

��@��2��$�!@��2��@��2��$�!@��2��@��2��$�!@��2��@��2��$�!@��2��

��2��C��!2��C��2��C��!2��C��2��C��!2��C��2��C��!2��C��

��2� ��2��$7�!2� ��2��2� ��2��$7�!2� ��2��2� ��2��$7�!2� ��2��2� ��2��$7�!2� ��2��

��!2��-�� !2��-�� !2��-�� !2��-��

��!-�� !-�� !-�� !-��

��!��

��!+,�� -�� 1��

��!+,�� -�� 1��

��!��)��*��

�!��

�

El enlace con los clientes Los objetos “proxy” �Debido a que la implementación de los servicios WEB se encuentra por lo general en un nodo diferente al del cliente que le invoca, se hace necesario crear una “imagen virtual” del mismo que permita hacer referencia directa a las operaciones proveídas por el servicio. �En el caso particular de .NET esto se logra a través de la creación de una clase que herede de “System.Web.Services.Protocols.SoapHttpClientProtocol” (cuando se desee utilizar “http” como protocolo de comunicación –existen otras alternativas según se mencionó en el marco teórico-). Por cada operación del Servicio Web se crearán los métodos para la invocación de los métodos “Request” y “Response” según lo especifica el protocolo SOAP. Estos métodos tendrán el mismo nombre que las operaciones implementadas por el servicio. A estos objetos que permiten crear una imagen de un objeto remoto se conocen con el término inglés de “proxies” o “stubs”. A continuación se muestra el objeto “proxy” que facilita la comunicación del cliente proveedor con el Servicio de Actualización del ejemplo práctico. G(*��2�� &��-�� 2��*H��,��3��5I�

G(*��J�,�(��J�,(��)� �� H��,��3@��(��H��K�� (��8�

@�� !!��!�5I�

��,��(��H��K�� (*��J�,�(��C��(��L��2�� C��M�

��

��!!!��D!��

��,��(��H��K�� 35�M�

�� /�� !!�� !(��H��K�� !(��H��K�� =�


Servicios Web 83

��N�

��!!!��D!��

��G(*��J�,�(��C��(��-�� &�� H��,��3� ��!!��!+,�� -�� 8�

1�B��@�� !!��!�8�1�� @�� !!��!�8�

/��(*��J�,�(��-�� (��)� �� /��'��8�

C��(�*��(*��J�,�(��C��(��C��(�*��J��5I�

��,��(*��%��%�� +,�� -�� 3�� .�/��5�M�

��,0��GI�� 6 ��D�3�+,�� -�� 8� �"��,0��GI�M�

��.�/��N5=�

�� 33(*��%��%�� 53��G�I55=�

��N�

��

��!!!��D!��

��,��(*��6H* �1��)�� +,�� -�� 3�� .�/��8�(*��H* �2��,��D��,��D8�

�,0��* �(��5�M�

�� )�� 6 ��D�3�+,�� -�� 8� �"��,0��GI�M�

��.�/��N8��,��D8��* �(��5=�

��N�

��!!!��D!��

��,��(*��%��%�� +,�� -�� 3(*��6H* �1��* �1��5�M�

��,0��GI�� 6 ��D�3�* �1��5=�

�� 33(*��%��%�� 53��G�I55=�

��N�

N�

Un aspecto importante a tomar en cuenta, es que en el caso correspondiente a Visual Studio .NET, cuando el enlace al servicio Web se hace en tiempo de diseño la creación de estos “proxies” es “transparente” al implementador, el cual define las instancias del Servicio Web e invoca sus métodos como si de una “clase normal” se tratara. �


Servicios Web 84

Bibliografía [Uche, 02] Uche Ogbuji, “The Past, Present and Future of Web Services, part 1”, http://www.webservices.org/index.php/article/articleview/663/4/61/, Fecha de Publicación: 28.09.2002 21:22

[Uche, 02] Uche Ogbuji, “The Past, Present and Future of Web Services, part 2”, http://www.webservices.org/index.php/article/articleview/663/4/61/, Fecha de Publicación: 07.10.2002 21:01

[Castro, 02] Enrrique Castro Leon , Intel. “A perspectiva on Web Services”, http://www.webservices.org/index.php/article/articleview/113/3/61/, Fecha de Publicación: 18.02.2002 13:58

[Manoj, 02] Manoj Chandran , ”Web services is not just about interoperability”,http://www.ciol.com/content/web_services/features/102100801.asp, Fecha de Publicación: Martes, Octubre 08, 2002

[Sutor, 02] Bob Sutor ,“Perspective: The five biggest myths about Web services”, http://news.com.com/2010-1071-971149.html Fecha de Publicación: Noviembre 26, 2002, 4:00 AM PT

[Kotok, 02] Alan Kotok, “Web services standards are good, but a Web services vision is better”, http://www.webservices.org/index.php/article/articleview/826/ , Fecha de Publicación: 30.12.2002 10:24

[SlRo, 02] Brent Sleeper and Bill Robins, “Defining Web Services”, http://www.stencilgroup.com, Documento: ideas_scope_200106wsdefined.pdf Fecha de Publicación: Junio 2001

[W3C, 02] “Web Services Architecture, W3C Working Draft” http://www.w3.org/TR/2002/WD-ws-arch-20021114/ , Fecha de Publicación: 14 November 2002

[Service-Architecture] Alan Brown, Simon Johnston, Kevin Kelly. “Using Service-Oriented Architecture and Component-Based Development to Build Web Service Applications”, Rational software white paper for IBM.

��


Servicios Web 85

Glosario Acronimos ADS: Advertisement and Discovery of Services API: Application Program Interface BPEL4WS: (description language) COM: Common object model, Component Object Model Command. CORBA: Common Object Request Broker Architecture COBOL: Common Business oriented Language DCE: Distributed Computer Environment HTTP: Hyper Text Transfer Protocol. IDL: Interface Definition Language. JMS: Java Message Service. MEP: Message Exchange Pattern. NASSL: Network Accesible Service Specification Language OAG: Open Aplication Group OMG: Object Management Group. PO: Purchase Order QOS: Quality of Service RFQ: Request for Quote RPC: Remote Procedure Call RDF: Radio Direction Finding SSL: Secure Sockets Layer, Synthesizer Specification Language SOA: Service Oriented Architecture SOAP: Simple Object Access Protocol TCP/IP: Transmission Control Protocol / Internet Protocol URI: Uniform Resource Identifier UDP: User Datagram Protocol, Usenet Death Penalty UDDI: Universal Description, Discovery and Integration. UN/CEFACT: United Nations Center for Trade Facilitation and Electronic Business VANs: Value Added Networks WSDL: Web Services Description Language. WSFL: Web Services Flow Language WSIL: Simple Inspection Technology HTTP GET mechanism to relieve WS

descriptions from a URL. WDDX: Web Distributed Data Exchange. XML: Extensible Markup Language.

Documents

Diseño de Software Orientado a “SERVICIOS WEB”