Arquitectura de Integración de Servicios                                      1



                                       ...
Arquitectura de Integración de Servicios                                    2


Pero los servicios Web han alterado signif...
Arquitectura de Integración de Servicios                                          3




                 Historia de las A...
Arquitectura de Integración de Servicios                                     4


       Proveer mayor retorno de inversión...
Arquitectura de Integración de Servicios                                      5




       Aumento de escalabilidad y disp...
Arquitectura de Integración de Servicios                                           6




                                 ...
Arquitectura de Integración de Servicios                                       7


Comienza con los requerimientos del neg...
Arquitectura de Integración de Servicios                                       8


eventos del negocio y respuestas requer...
Arquitectura de Integración de Servicios                                       9


       7.5.4 Eventos del negocio.

    ...
Arquitectura de Integración de Servicios                                           10




                                ...
Arquitectura de Integración de Servicios                                   11




       7.5.5 Servicios.

       Las resp...
Arquitectura de Integración de Servicios                                     12


       optimice su reutilización. Una co...
Arquitectura de Integración de Servicios                    13




                                           Integración ...
Arquitectura de Integración de Servicios                                       14


       Tabla de Definición de Servicio...
Arquitectura de Integración de Servicios                                     15




       Tabla de interfaz de Servicios
...
Arquitectura de Integración de Servicios                                       16




       La meta de definir interfaces...
Arquitectura de Integración de Servicios                                      17


       actores envía un estimulo partic...
Arquitectura de Integración de Servicios                                   18




       La Especificación de Casos de Uso...
Arquitectura de Integración de Servicios                    19




                                           Integración ...
Arquitectura de Integración de Servicios                                   20


       7.5.7 Conclusiones y Comentarios.

...
Arquitectura de Integración de Servicios                                     21


       comenzar con un proyecto que teng...
Arquitectura de Integración de Servicios                                           22




                                ...
Arquitectura de Integración de Servicios                                 23


administrar y medir la reutilización, requie...
Arquitectura de Integración de Servicios                    24




                                           Integración ...
Upcoming SlideShare
Loading in …5
×

CapíTulo 7

1,105 views

Published on

Published in: Travel, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,105
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
12
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

CapíTulo 7

  1. 1. Arquitectura de Integración de Servicios 1 Capítulo 7. Arquitectura de Integración de Servicios. 7.1 Revisión ejecutiva. La Arquitectura de Integración de Servicios define las aplicaciones de negocios como reutilizables, componentes fáciles de cambiar en las funcionalidades del negocio y cómo estos componentes se interrelacionan. Este es el concepto de una arquitectura orientada a servicios (SOA). Mientras SOA ha sido considerado como mejor práctica en las últimas dos décadas, hasta la actualidad, muy pocas compañías estaban interesadas en ella. Ahora, de repente SOA es un tema de moda en las TI, y al centro de muchas iniciativas, esperando el incremento de la agilidad del negocio. En este punto, si su compañía no está al menos investigando SOA, debería hacerlo. En una SOA, las discretas funciones o procesos de negocios son creados como componentes independientes con interfaces estándar que pueden ser accedidas por otras aplicaciones, servicios y procesos de negocios, sin importar la plataforma o lenguaje de programación. Estos servicios pueden ser combinados flexiblemente para soportar diferentes o cambiantes funciones y procesos de negocio. Soporta la creación de aplicaciones modulares, las cuales son rápidamente ensambladas desde servicios nuevos o existentes. En el pasado, las compañías tenían que apostar en CORBA, J2EE o .NET para crear SOA. Pero la mayoría de las grandes compañías utilizan todos ellos. Los riesgos y costos de estandarizar a uno sólo, pesaba en los beneficios potenciales de SOA. Esto conto para el poco porcentaje de adopción. Integración Empresarial
  2. 2. Arquitectura de Integración de Servicios 2 Pero los servicios Web han alterado significativamente la ecuación de valor de los SOAs, Los servicios Web son finalmente universalmente el estándar aceptado porque todos los principales vendedores pueden, en teoría, soportarla. Trabajan en .NET, J2EE, y CORBA (mientras que todos se apeguen a la misma versión del estándar). A pesar de que algunas áreas del estándar siguen inmaduras, los servicios Web y XML han eliminado significativamente las barreras de riesgo de adoptar SOA, haciendo los beneficios mucho mayores que los riesgos. Las aplicaciones de misión críticas actualmente existentes en los mainframes y otras plataformas, pueden ser empaquetadas en interfaces de servicios Web y accedidas desde otras aplicaciones o buscadores Web. Esto permite a los negocios el crear servicios de negocio desde los sistemas existentes, e implementar e integrar rápidamente nuevas funcionalidades. Con la utilización de los servicios Web, las compañías pueden comenzar a crear SOAs, encaminando las inversiones existentes y añadiendo crecientemente nuevas funcionalidades. SOA es la arquitectura que mejor permitirá la agilidad del negocio a largo plazo porque soporta la reutilización y el rápido despliegue de nuevas soluciones. Integración Empresarial
  3. 3. Arquitectura de Integración de Servicios 3 Historia de las Arquitecturas Orientadas a Servicios. El concepto de SOA comenzó a principio de los 80s y fue tomada por las comunidades de redes y programación orientada a objetos. En 1983 el Modelo de Referencia OSI fue adoptado por la Organización Internacional de Estándares (ISO) como una referencia común para el desarrollo de estándares de comunicación de datos. Este define las funciones de comunicación de datos en siete capas. Cada capa define servicios de comunicación y cada servicio tiene un intercambio claro y definido con la capa superior e inferior. Este SOA ha pasado la prueba del tiempo. Mientras la tecnología y capacidades de cada capa han cambiado automáticamente, la arquitectura en sí se mantiene. Mientras las interfaces entre servicios continúen igual, los servicios mismos podrán ser cambiados. La Fundación de Software Abierto (OSF), el grupo responsable por los estándares de UNIX, desarrollaron el Ambiente Computacional Distribuido (DCE) basado en una arquitectura orientada a servicios. La DCE provee una infraestructura de servicios para computación distribuida, incluyendo la autentificación de los servicios de seguridad (Kerberos), directorio de servicios, procedimientos remotos y servicios de archivos y administración. CORBA es una arquitectura e infraestructura de vendedor independiente definida por el Object Management Group (OMG) que permite conectar aplicaciones para que trabajen juntas entre la red, utilizando protocolos de estándares IIOP. CORBA permite la interoperabilidad entre plataformas. Las aplicaciones de CORBA son basadas en componentes. Las tecnologías de componentes más actuales son J2EE y .NET, que son plataformas basadas en componentes que administran infraestructuras distribuidas y soportan los servicios Web para permitir aplicaciones de negocios interoperables. Es actualmente el modelo de componentes más desplegado. .NET es la implementación de la arquitectura de servicios Web de Microsoft, la cual permite a las legiones de programadores de Microsoft, crear servicios Web en los lenguajes de programación con que están más familiarizados. Esto preserva una gran inversión en el conjunto de habilidades existentes. Los programadores de J2EE son usualmente más costosos que los programadores de Microsoft. 7.2 Beneficios de la Arquitectura Orientada a Servicios (SOA). Permitir agilidad del negocio. SOA es la mejor manera de permitir la agilidad del negocio. Maximiza el encaminamiento de recursos existentes mientras minimiza el tiempo y costo de desarrollar nuevas aplicaciones. En lugar de desarrollar aplicaciones de la nada, las compañías pueden utilizar las funciones existentes y crear nuevas soluciones mediante en ensamble de componentes de las aplicaciones de funcionalidades existentes o nuevas. Esto permite el rápido desarrollo de nuevas soluciones. Integración Empresarial
  4. 4. Arquitectura de Integración de Servicios 4 Proveer mayor retorno de inversión. Las compañías que definen servicios de reutilización en el negocio y crean o empaquetan funcionalidades de negocios como servicios estándar, maximizarán sus inversiones de TI mediante la reutilización y encaminamiento de características existentes. Permitir agilidad de las TI. Las definiciones de servicios estándar pueden proveer una capa de abstracción para los servicios del negocio. Un servicio pude correr y ser accesado desde cualquier lugar. Por lo tanto las compañías pueden fácilmente cambiar la localización o tecnología del código resaltado. Reducir costos de entrenamiento. Los servicios de negocio pueden ser encapsulados y abstraídos de forma que sean fáciles de utilizar y ensamblar a componentes de aplicaciones con la mínima programación. Las compañías pueden utilizar programadores con más habilidades para crear la funcionalidad resaltada y las definiciones de servicios, lo que puede ser reutilizado por programadores menos técnicos y aplicaciones visuales de ensamble. Reducir el costo de pruebas y corrección de gusanos. Cada servicio es como una caja negra que realiza una función específica y tiene una interface publicada que acepta entradas definidas y produce salidas definidas. Cada servicio puede ser probado individualmente, y luego reutilizado una y otra vez. Las pruebas de interfaces son muy directas y pueden ser automatizadas utilizando herramientas de prueba. Soporte de múltiples tipos de clientes y plataformas. La SOA ofrece una capa de abstracción de determinadas plataformas. Esto hace posible tener muchos dispositivos de usuario final, incluyendo buscadores y dispositivos móviles como celulares, PDAs y otros dispositivos especializados para utilizar las mimas funcionalidades del negocio y tienen información comunicada a diferentes dispositivos. Esta independencia de plataformas provee un gran ahorro para las grandes compañías que tienen millones de tecnologías en uso. Rápido tiempo de desarrollo a través de desarrollo paralelo. Los diferentes programadores pueden trabajar independientemente en diferentes servicios, porque cada uno de éstos, está contenido en sí mismo y no depende del estado de otro servicio. Mientras las interfaces de servicios se encuentren bien definidas desde el principio del proyecto y lo programadores sepan que esperar de los otros servicios, ellos pueden fácilmente definir y crear servicios independientemente. Es comúnmente dicho que pasado un cierto tiempo, el añadir más programadores al proyecto aumenta el tiempo de desarrollo. Esto no es verdad con SOA. Integración Empresarial
  5. 5. Arquitectura de Integración de Servicios 5 Aumento de escalabilidad y disponibilidad. Gracias a que SOA ofrece transparencia de localización, está el potencial de aumentar escalabilidad al añadir múltiples instancias de un servicio. La tecnología de balanceo podría dinámicamente encontrar y enrutar los pedidos de las instancias de servicios apropiadas. De la misma forma, si hubiera múltiples instancias de un servicio en la red, y una está disponible, la transparencia de software puede enrutar el pedido a otra instancia, y con esto proveer mayor disponibilidad. Esto es más el caso de nuevos servicios construidos en servicios de aplicaciones, y no funcionalidad de herencia que ha sido empacada en interfaces de servicios Web. Lo que hace que SOA sea tan convincente es que puede ser aplicada a grande y pequeña escala con los mismos beneficios. La Universidad de Texas A&M fue capaz de demostrar esos principios con el desarrollo de si sistema de registro de clases en línea, descrito en el Caso de estudio 7.1 (Software AG n.d.). Esta aplicación fue un pequeño paso en la aplicación de SOA a gran impacto. Finalmente, las SOAs se convertirán en la forma en que las organizaciones construirán sus infraestructuras de TI, porque es la mejor y única forma comprobada de proveer agilidad a largo plazo. Sin embargo, tomará algún tiempo e inversión llegar a eso. Hasta la fecha, la mayoría de los enfoques de las industrias ha sido resolver los problemas considerables de conectividad técnica. Sin embargo, los grandes esfuerzos de permitir realmente la agilidad del negocio a través de SOA están en la definición, construcción y administración de servicios de negocio reutilizables. Integración Empresarial
  6. 6. Arquitectura de Integración de Servicios 6 Caso 7.1 Mejorando el Servicio a Estudiantes en Texas A&M. La Universidad de Texas A&M ha sido un líder real en la aplicación de tecnologías para mantener la misión de la universidad. Como una de las más grandes instituciones educativas, el mejorar los servicios a los estudiantes, especialmente durante el registro, continua siendo prioritario. Una arquitectura orientada a servicios utilizando servicios Web es bien encajada para mejorar el registro y los servicios de asistencia a los estudiantes que esperaban más servicios electrónicos y menos tiempo de esperar en las filas. La decisión fue implementar un servicio en línea. El departamento de TI desarrolló su sistema de registro de clases utilizando servicios web y dos personas y fue capaz de entregar un sistema en tres meses. La mayor parte de los servicios eran provistos por Cobol y programas Naturales que corrían en el mainframe. Estaban vinculados con los servicios Web utilizando EntireX Communicator. Estaba estimada que el uso de este enfoque y tecnología era un ahorro del 50% del tiempo de desarrollo comparado con esfuerzos previos similares en el departamento. Durante el registro, miles de estudiantes fueron atendidos simultánea y eficientemente. El impacto a la universidad fue un mayor nivel de satisfacción de los estudiantes y una reducción de llamadas telefónicas por el personal de la Universidad. 7.3 Definición de Servicios. De abajo hacia arriba o de arriba hacia abajo. Hasta la fecha, la mayoría de los enfoques de SOA y servicios Web han sido en los detalles tecnológicos de definir las interfaces. Mientras la definición de estándares de interfaces es el punto crítico que hace posible el sistema, un enfoque de abajo hacia arriba tiene sus limitaciones. Si el enfoque es solamente en la especificación de la interfaz, y no en cómo definir que funcionalidades exponer como servicio, las compañías no arrancaran completamente los beneficios de la SOA. El incremento de la agilidad del negocio y disminución de costos dependen de servicios bien definidos, bien administrados y reutilizables que son más rápida y fácilmente accedidos. Desafortunadamente no hay teorías matemáticas o metodología que pueda decir a un desarrollador si e componente o servicio está en el nivel de granularidad correcto para maximizar su reutilización. El método más comúnmente utilizado es el de crear servicios de negocios con un enfoque de prueba y error. Este significa la definición de servicios en el contexto de un proceso de negocios particular, luego la revisión de reutilización en la siguiente solución. Un enfoque de negocios para definir servicios de arriba hacia abajo permitirá a las compañías satisfacer las necesidades actuales y futuras del negocio. Integración Empresarial
  7. 7. Arquitectura de Integración de Servicios 7 Comienza con los requerimientos del negocio. Cada servicio deberá proveer la funcionalidad de satisfacer uno o más requerimientos, y un conjunto de funcionalidades deben estar cercanamente relacionadas. Esto es llamado cohesión de funcionalidad. Sin embargo, los servicios deberán estar ligeramente acoplados. El procesamiento entre un servicio no debe depender del estado de procesamiento de otro. Un servicio abstrae la funcionalidad de la tecnología destacada. En realidad, para realizar el trabajo, los dos métodos don necesarios. El enfoque de arriba hacia abajo produce un nivel de abstracción necesario para crear la agilidad del negocio. Sin embargo, en cierto punto el modelo necesita satisfacer las necesidades de tecnología y los servicios necesarios para implementar como componentes o colecciones de componentes. Las compañías continuarán construyendo componentes de abajo hacia arriba para encapsular los servicios del negocio. La clave es hacer una cohesión de la funcionalidad de esos componentes para evitar traslape de funcionalidades y acoplarlos ligeramente para permitir el cambio rápido y maximizar el impacto del cambio. 7.4 Diseño de Servicios Dirigidos a Eventos En este capítulo ofrecemos un método dirigido a eventos para definir servicios de negocios discretos que pueden ser utilizados en base a proyecto o al total de la empresa. La definición de requerimientos de negocio en términos de eventos de negocio ofrece un número de ventajas. Primero, la arquitectura de servicios orientada a eventos provee los sistemas más ágiles. En el ebizQ webinar, “Creando la Nueva Agilidad Empresarial: Orientado a Servicios y Dirigido a Eventos” (http://www.ebizq.net/expoq/events/evennt 39.html), Roy Schulte, VP Gartner declaró que la “agilidad generalmente involucra practicas de negocios dirigidas a eventos, facilitados por arquitecturas orientadas a servicios”. El utilizó la analogía se los trenes y camiones para describir la agilidad de SOA. “Cambiar la dirección de un camión es más fácil que hacer que el tren vaya donde no hay carriles. Si quieres que el tren se mueva sobre un pie, tienes que hacer un enorme esfuerzo reconstruyendo y reestructurando los carriles”, dijo Schulte. “Por otra parte, todo lo que necesitas para cambiar a un camión más ágil es mover el volante”. SOA es la arquitectura que provee los volantes para la empresa ágil. Segundo, los eventos del negocio son una buena forma de diseñar servicios porque para los usuarios son fáciles de entender, identificar y verificar en un diseño. Representan las actividades esenciales del negocio. Una de las mejores formas de asegurar la máxima reutilización de un servicio es tener una revisión del diseño de la interfaz, para que todos los inversionistas puedan evaluar si el servicio cumplirá sus necesidades. Este es el proceso utilizado por OASIS para desarrollar estándares, Cuando las compañías adoptan esta práctica, los servicios comúnmente satisfacen un mayor rango de necesidades. Los inversionistas del negocio son más capaces de definir r y verificar los Integración Empresarial
  8. 8. Arquitectura de Integración de Servicios 8 eventos del negocio y respuestas requeridas por los sistemas, que interfaces técnicas. Las respuestas de eventos definan los requerimientos para el diseño de interfaces. Finalmente, la definición de los eventos del negocio que el sistema capturará y responderá claramente, define los límites del sistema. Esto es esencial para asegurar implementaciones rápidas y exitosas. Las respuestas de eventos son después descompuestas en conjuntos de respuestas de sistemas funcionalmente cohesionadas. Estas respuestas pueden ser provistas por sistemas existentes o nuevo desarrollo. El servicio puede ser una interface integrada a una serie de respuestas entregadas por diferentes sistemas que necesitan ser coordinados. Un servicio puede proveer por sí mismo diferentes niveles de abstracción El servicio puede ser una sola función provista por un componente o aplicación. El enfocarse en eventos del negocio y respuestas requeridas provee un enfoque orientado a la definición de SOA. Este método es descrito en la Especificación de Servicios de Integración. 7.5 Especificación de la Arquitectura de Integración de Servicios. Algunos han llamado a los procesos de crear servicios de negocio reutilizables algo similar a cocinar waffles. Necesitan tirar el primero y se vuelve mejor con el tiempo. Mientras es ciertamente un proceso iterativo, esta especificación provee una guía para crear servicios reutilizables. 7.5.1 Introducción. Esta especificación de SOA provee la arquitectura y el diseño guía para aplicar el enfoque se arquitectura orientado a servicios en la integración. Este documento define los eventos, servicios y componente. Es el diseño de la arquitectura de especificación para el desarrollo de los servicios y componentes. 7.5.2 Alcances. El alcance de esta especificación es definida por el alcance del proyecto. Documenta la arquitectura y diseño del enfoque de una SOA hacia una solución de integración. El alcance de esta especificación debe describir el alcance de la aplicación o sistema que está siendo diseñado. 7.5.3 Participantes clave. Esta sección debe definir los inversionistas que pueden verificar los eventos del negocio, servicios e interfaces: el equipo de desarrollo que ejecutará la implementación del diseño; y el equipo responsable para la arquitectura y diseño. Cualquier otro participante o inversionista debe ser identificado, incluyendo sus roles. Integración Empresarial
  9. 9. Arquitectura de Integración de Servicios 9 7.5.4 Eventos del negocio. La sección de eventos del negocio define las actividades que el sistema debe soportar. Un evento del negocio es algo que: Ocurre en el ambiente del negocio. Ocurre en un determinado punto en el tiempo. Debe ser respondido por el sistema. La tabla de eventos describe las actividades relevantes que suceden en los negocios y las respuestas de los sistemas requeridas. Hay dos tipos de eventos: eventos de negocio y eventos temporales. Los eventos del negocio son actividades dentro del alcance del sistema. Los eventos temporales suceden en un punto de tiempo predeterminado. Los eventos temporales existen porque las políticas del negocio demandad que ciertas actividades del sistema ocurran en cierto tiempo o porque el sistema produce sus salidas en base a un tiempo. El Caso de estudio 7.2 describe cómo se administraron eficientemente los eventos del negocio en Delta Airlines puede tener un impacto significativo en su negocio (Tillett and Schwartz 2001). Los requerimientos del negocio son definidos en la Declaración de Propuestas (Capítulo 2). De esa lista, hay que crear una lista de eventos de negocio dentro del alcance del sistema, y definir las propuestas a cada evento (ver Figura 7-1). En la columna de Descripción de Eventos se incluye como el evento es iniciado, o detectado. Cuando se definan las Respuestas, se deben dar nombres descriptivos que definan no ambiguamente lo que la respuesta del sistema es, como “Verificación de cliente existente”, “Alta de Nuevo Cliente”, “Verificación de Crédito”. Integración Empresarial
  10. 10. Arquitectura de Integración de Servicios 10 Caso 7.2 Delta Airlines. Administración de Eventos del Negocio a través del Sistema Delta Nervous. El Sistema Delta Nervous (DNS) representa una inversión de $1 billón, para entregar datos a tiempo a los clientes, empleados y socios. Sin embargo, no es la entrega de la información, sino el uso de esos datos en el manojo de los eventos del negocio, el mayor beneficio de DNS. Por ejemplo, una aplicación inicial del sistema es requerida por manejadores de equipaje y asegura que tengan una imagen precisa de los cambios de sala y retrasos de vuelos para que puedan planear el movimiento del equipaje arriba y debajo de los aviones. El cambio del estatus de un vuelo es un evento del negocio que repercute a través de todo el sistema de la aerolínea. Cuando un evento ocurre, el cambio en el estatus puede ser actuado si se le provee a los participantes claves del evento la información y servicios para reaccionar ante esos cambios. El DNS está cambiando a Delta en una empresa de tiempo real con la habilidad de servir mejor a los clientes. Además, también implica una enorme generación de ingreso y disminución de costos. Por ejemplo, tener información en tiempo real permite a Delta aumentar el número de vuelos diarios moviendo a los aviones adentro y afuera más rápido. El tiempo de la tripulación ociosa en tierra puede ser reducido a través de mejor planeación. Los costos asociados con el mal manejo del equipaje pueden ser eliminados. Mientras el enfoque es en hacer la información disponible, el valor estará en la identificación de eventos significativos y tomar acciones apropiadas como resultado de esos eventos. No es necesario para un negocio crear una nueva fuente de información. En vez de eso, es importante crear una arquitectura capaz de actuar en eventos del negocio y hacer que fluyan eficientemente a través del sistema como servicio. Delta ha puesto este sistema a andar con su DNS, Integración Empresarial
  11. 11. Arquitectura de Integración de Servicios 11 7.5.5 Servicios. Las respuestas del sistema definidas en la Tabla de Eventos son utilizadas para determinar los servicios esenciales que debe proveer el sistema. Algunos de estos servicios o funciones ya existen en otros sistemas, y otras funcionalidades serán nuevas y deberán ser desarrolladas e integradas. Las descripciones del servicio definen el alcance de la funcionalidad requerida para realizar un servicio de negocio específico. Para maximizar la agilidad del negocio y las inversiones de TI, los servicios de negocio deberán ser definidos al nivel de granularidad que Integración Empresarial
  12. 12. Arquitectura de Integración de Servicios 12 optimice su reutilización. Una cohesión que agrupe las funciones cercanamente relacionadas en los servicios del negocio y acople ligeramente los servicios, son las métricas de diseño que llevarán a un diseño más reutilizable. Tres partes de la especificación definen completamente cada servicio: la Tabla de Categoría de Servicios, la Tabla de Definición de Servicios y la Tabla de Interfaz de Servicios. Este nivel de descripción es suficiente para desarrollar un nuevo servicio Web o empacar las funcionalidades existentes como servicio de negocio. Tabla de Categoría de Servicios La Tabla de Categoría de Servicios enlista tolas las respuestas requeridas ante eventos del negocio, y define si la funcionalidad ya existe en uno o más sistemas o si es una nueva. El servicio en este punto es una suposición primaria de la definición de los servicios y será redefinida ampliamente en el siguiente paso. Cuando se definen los servicios, se debe pensar en módulos dentro de una aplicación que puedan realizar el servicio o componentes de módulos para desarrollo (ver Figura 7-2). Integración Empresarial
  13. 13. Arquitectura de Integración de Servicios 13 Integración Empresarial
  14. 14. Arquitectura de Integración de Servicios 14 Tabla de Definición de Servicios La Tabla de Definición de Servicios describe completamente cada servicio en un nivel suficiente para crear servicios Web u otras interfaces de integración. Cada servicio deberá ser descrito en términos de su funcionalidad y sistemas utilizados para crearlo. Al crear esta tabla, se deben agrupar todas las funcionalidades y respuestas para formar un módulo cohesionado. Por ejemplo, el servició deberá administrar un conjunto de datos particular, como información del cliente o información del producto, o deberá realizar un servicio especifico que puede ser utilizado en otras aplicaciones, como revisión de crédito o precios. Debe haber un ligero acoplamiento entre los servicios. Cada servicio deberá interactuar con cualquier otro servicio a través de la interfaz definida. Los cambios en alguno de los servicios no deberán impactar la funcionalidad de los otros. La descripción define cómo el servicio será implementado, como servicio Web, adaptador de aplicación o interfaz de módulo de aplicación (Figura 7-3). Este es el lugar en la especificación que proporciona un diseño completo al nivel de especificación de tecnología. Integración Empresarial
  15. 15. Arquitectura de Integración de Servicios 15 Tabla de interfaz de Servicios Mientas los estándares de Servicios Web definen cómo especificar una interfaz, no definen los datos y funcionalidades que la interfaz necesita contener. La Especificación de Servicios de Interfaz provee la información necesaria para crear servicios web u otras aplicaciones o componentes de interfaces. Utilizar la Tabla de Definición de Servicios, enlista las entradas, salidas y métodos que la interfaz necesita soportar, y determina cómo ésta será implementada (Figura 7-4). Integración Empresarial
  16. 16. Arquitectura de Integración de Servicios 16 La meta de definir interfaces estándar es maximizar la agilidad del negocio. Las interfaces estandarizadas, permiten construir a las aplicaciones y servicios en diferentes plataformas con diferentes lenguajes y tecnología para interoperar. Permiten también a los servicios el cambiar la funcionalidad interna y reglas o resaltar tecnología sin impactar a otras aplicaciones o componentes, mientras la interfaz continúe igual. Por lo tanto, el tener una buena interfaz es necesario para maximizar la reutilización y agilidad. Es recomendado que las compañías sigan las mejores prácticas de los comités de estándares cuando definan sus interfaces, teniendo revisiones de diseño que incluyan a los inversionistas. También es recomendado que se cree un glosario de terminología que es significativa y consistente a través de los inversionistas. El propósito de la Especificación de la Interfaz, es permitir estas revisiones de diseño y describir por completo la interfaz para que pueda ser correctamente y óptimamente implementada. 7.5.6 Diagrama de Caso de Uso y Especificación. Un diagrama de caso de uso puede ser utilizado para mostrar las relaciones entre usuarios, eventos y servicios. Es la pieza final del rompecabezas para la especificación e integra toda la información de las secciones anteriores. Los casos de uso definen a los actores y cómo van a interactuar con los servicios del sistema. Los actores representan un papel, y pueden ser humanos, otras computadoras o piezas de hardware, e incluso otros sistemas de software. Estos deben dar estímulos o iniciar el evento en turno que requiere una respuesta del sistema o servicio. Los casos de uso describen el comportamiento del sistema cuando uno de estos Integración Empresarial
  17. 17. Arquitectura de Integración de Servicios 17 actores envía un estimulo particular y muestra los eventos del negocio y respuestas de los sistemas en términos de estímulos de eventos que llevan al caso de uso, las entradas de y las salidas a otros actores, y el comportamiento que convierte las entradas en salidas. Los componentes básicos de un diagrama de caso de uso son el actor, el caso de uso y la asociación (ver Figura 7-5), Un actor es mostrado utilizando una figura de palitos y el rol del usuario es escrito debajo del icono. Los actores pueden ser humanos, otras computadoras, piezas de hardware e incluso otros sistemas de software. Un caso de uso es mostrado con una elipse, y el nombre es escrito adentro. Las asociaciones son líneas entre actores y casos de uso, y ésto indica que un actor participa en el caso de uso. Para soportar el análisis de los requerimientos no funcionales (ej. Confiabilidad, mantenimiento y funcionamiento), se utilizan casos de uso que deben ser creados para soportar los escenarios en que éstos requerimientos no funcionales serán probados. Algunos ejemplos incluyen: 1) creación de un caso de uso que pruebe el funcionamiento entre interfaces de componentes distribuidos, y 2) creación de casos de uso que prueben la adaptabilidad de un componente mediante la extenderlo (añadir clases) o examinarlo para definir si mantiene los principios de diseño arquitectónico. Estos casos de uso a nivel de sistema pueden ser implementados en un estilo de hacerlo solos donde una parte de la arquitectura está siendo probada independientemente del dominio de funcionalidad que necesitará soportar. Para crear los casos de uso, primero se deben identificar a los actores primarios del sistema. Después, priorizar los servicios que serán implementados. Se recomienda la creación de casos de uso para cada servicio propuesto. Un ejemplo es la figura 7-6. Integración Empresarial
  18. 18. Arquitectura de Integración de Servicios 18 La Especificación de Casos de Uso contiene el texto que describe ampliamente el caso de uso (ver Figura 7-7). La especificación escrita usualmente describe todo lo que puede ir mal en el curso del comportamiento de la especificación, y cuál es la acción que el sistema realizará para remediarlo. Esta especificación puede ser personalizada o expandida para manejar asuntos particulares en la implementación o la organización. Integración Empresarial
  19. 19. Arquitectura de Integración de Servicios 19 Integración Empresarial
  20. 20. Arquitectura de Integración de Servicios 20 7.5.7 Conclusiones y Comentarios. Esta sección debe incluir cualquier comentario final del sistema, el diseño o el uso del sistema. Debe incluir también los problemas conocidos, restricciones o factores extenuantes que contribuyan a las decisiones o que pueden afectar al sistema en el futuro. 7.6 Mejores Prácticas en la Arquitectura de Integración de Servicios. Una arquitectura orientada a servicios exitosa permite e las compañías implementar rápidamente nuevas soluciones de negocio o cambiar las existentes y puede entregar un ROI sustancial. Sin embargo, SOA no es necesariamente fácil de lograr. Las siguientes mejores prácticas ayudarán a obtener los beneficios completos de SOA. Proveer estructura organizacional y soporte de algo nivel. El éxito de SOA requiere el compromiso e inversión continuos por parte de la empresa. SOA no puede ser lograda con un simple proyecto, necesita contar con un grupo de expertos, como un centro de competencia, que se enfoquen en la definición, crecimiento y reutilización de SOA. Debe haber procesos organizacionales y políticas que gobiernan la integración empresarial. Como la integración cruza barreras organizacionales, puede causar disputas territoriales. Las compañías necesitan procesos y políticas para manejar esas disputas (descritos más detalladamente en la sección 4.4, Estructura Organizacional y Arquitectura de Gobierno). Implementar arquitectura basada en estándares. Los estándares ayudan a asegurar tanto la interoperabilidad como la portabilidad. Previenen el estanque de la tecnología, y ayudan a preservar el valor en las inversiones de TI. Los estándares de servicios Web están permitiendo la adopción universal de SOA, a pesar de que ha sido conocida como la mejor práctica de arquitectura por más de tres décadas. XML permite a los sistemas estandarizar el formato de trasporte, administración y almacenamiento para los datos estructurados y contenido no estructurado en las organizaciones. Implementar un enfoque basado en estándares. Es recomendable seguir el ejemplo de los comités de estándares que tienen una larga experiencia creando procesos que son exitosos en la creación de estándares interoperables. Realizar revisiones de diseño para las interfaces de los servicios, e incluir a los inversionistas. Los inversionistas pueden ser identificados a través de los casos de uso. Pensar en grande, comenzar en pequeño. Cuando se plañera la implementación de SOA, se debe considerar un impacto a lo largo de la empresa para maximizar la reutilización y agilidad. Pero se debe Integración Empresarial
  21. 21. Arquitectura de Integración de Servicios 21 comenzar con un proyecto que tengo alcance limitado y alta probabilidad de éxito. Nada es más exitoso que el éxito. Se aprende bastante de cada implementación, así que hay que esperar a tener varias pequeñas implementaciones antes de comenzar con los retos más difíciles. Invertir en entrenamiento. Se tendrá una mayor probabilidad de éxito si los empleados saben lo que hacen. Pocos diseñadores y programadores tienen experiencia con SOA construida bajo estándares como servicios Web y XML. Es todo nuevo para ellos también. Todos los inversionistas, incluyendo los administradores de TI, arquitectos, diseñadores, programadores y personal de soporte operativo necesitan entender todos los conceptos de SOA y cuál será su papel en el proceso. Los arquitectos y diseñadores necesitan comprender los parámetros del diseño y las mejores prácticas para crear sistemas ágiles y reutilizables. Los programadores necesitan comprender las nuevas tecnologías y cómo implementar la infraestructura de los servicios y componentes. El personal de soporte operativo necesita comprender las implicaciones de administrar una SOA distribuida. Uso de herramientas para ahorrar tiempo y dinero. No se debe tratar de realizar manualmente todo. Hay una gran variedad de herramientas disponibles y pueden reducir el tiempo y serie de habilidades requeridas para implementar la solución. Las ventajas de invertir en herramientas pesan más que los costos. El Grupo de Vanguardia es un caso de estudio interesante donde cada una de las mejores prácticas es llevada a cabo (Caso de estudio 7.3) (Dragoon 2003). Integración Empresarial
  22. 22. Arquitectura de Integración de Servicios 22 Caso 7.3 La “Brillantemente Simple Solución” del Grupo de Vanguardia. Se ha descrito como una solución brillantemente simple cuando el Grupo de Vanguardia tomó una decisión a finales de los 90s para alinear a los clientes del portal Web con su sistema de servicio a clientes. En retrospectiva, es sorprendente que más organizaciones no hayan llegado al a misma conclusión, porque los beneficios parecen aparentes: La paridad entre los canales de interfaz del cliente en funcionalidad. La reducción de la complejidad en el mantenimiento de múltiples sistemas. Una arquitectura que puede ser llevada a la reutilización para otros propósitos. Los resultados actuales han sido impresionantes. El entrenamiento de empleados internos fue reducido significativamente, eliminando virtualmente de 4 a 6 semanas de entrenamiento. El retirar un gran número de bases de datos y aplicaciones redujo la complejidad de la arquitectura resaltada. Casi el 10% menos de personal fue requerido para mantener los sistemas. Los tiempos de respuesta de los usuarios fueron reducidos del 60% al 70%, incrementando la eficiencia del personal. Además, la arquitectura soportó el desarrollo de aplicaciones que mejoraron varios procesos de negocio claves, resultando en procesamiento de transacciones directas. Los ahorros de éstos cambios fueron esperados por $30 millones anuales. La inversión para alcanzar esto fue significativa, pero el ROI esperado es un índice interno de retorno del 20%. Mientras las inversiones en arquitectura frecuentemente lanzan costos que no tienen beneficio aparente, Vanguardia demostró que la implementación de una arquitectura que soporta la reutilización puede ser un impacto significativo en el negocio. Una arquitectura orientada a servicios bien diseñada es la clave de alcanzar estos beneficios. Los servicios Web no son requeridos, como vemos lo que Vanguardia alcanzó, pero deberá ayudar a bajar los costos que nacieron en el proyecto mediante la reducción de la cantidad de trabajo de personalización de la infraestructura que es provista ahora a través de la tecnología de servicios Web. 7.7 Siguientes Pasos. Los servicios están construyendo bloques para aplicaciones modulares e integración por procesos. Definir servicios empresariales reutilizables, así como Integración Empresarial
  23. 23. Arquitectura de Integración de Servicios 23 administrar y medir la reutilización, requieren una inversión y compromiso continuo. EL éxito con SOA es un asunto de administración como lo es de tecnología. Las compañías interesadas en lograr agilidad del negocio a largo plazo invertirán en todos los aspectos de la arquitectura de integración empresarial, incluyendo una arquitectura de integración de información y procesos (Capítulo 8 y Capítulo 9, respectivamente), Las compañías enfocadas en resolver necesidades tácticas, definirán solo lo que es absolutamente necesario para moverse hacia la implementación (Parte III). Ver figura 7-8. Integración Empresarial
  24. 24. Arquitectura de Integración de Servicios 24 Integración Empresarial

×