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
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
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
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
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.
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.
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.
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.
En la figura 1, se puede observar la evolución de los Servicios Web desde el año 1998 hasta el 2002.
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
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.
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.
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.
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.
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
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
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:
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.
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
¿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
¿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?
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.
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.
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.
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.
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.
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.
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.
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:
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 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.
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
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
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.
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.
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.
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
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
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
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.
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
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
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.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
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.
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:
! ! " #
! $ # $ ! "
! "
$
! $ ! " % $
! $ & ! "
! ! $ '
! $ ! $
! ! " $
! ( !
! ( $ $ ! $ )
! ! " % $
*
! $ $ ! " $
$
$ # *
$ $
! $ $ ! " $
! $ $ " $'
! $ ! "
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
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
)
$ ) $
) $
+ % $ #
%,
+ $ * +
* $
$ + $ #
%,
. * $ )
$ + %
+ $ ,
Tabla 2.3: Entidades Entrada
Entidades de salida
+ $ * +
* $
$ + $ #
%, $
,
$ +
$ $ $ )
$
$ $ $
$ ) ,
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
/ % $ )
$ ) # $
* $ + %
$ % *
+ ,
/ %
$-' %,
/ % $ . "
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.
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
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
$ $
,
$ $
$
$ ) $
) ,
$ ) $
$ )
% $
$ ,
$ $ $
$
$ ,
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
