CARRERA TITULO DEL TRABAJO CURSO

Transcripción

1 CARRERA Ingeniería Informática TITULO DEL TRABAJO SOA CURSO Tópicos de Ingeniería del Software CÉSAR ESTRADA CONDORI MAYRA GOMEZ QUEVEDO LUIS MUǸOS ESCAPA ALAN A. ROJAS MARROQUIN SEMESTRE IX 2010 Los alumnos declaran haber realizado el presente trabajo de acuerdo a las normas de la universidad Católica San Pablo FIRMA FIRMA FIRMA FIRMA

2 Arquitectura Orientada a Servicios SOA 1. Definición Una arquitectura orientada a servicios es esencialmente un conjunto de servicios, entre los que la comunicación implica el paso simple de datos o la coordinación de dos o más servicios, que requieren medios de comunicación entre si. La primera arquitectura orientada a servicios ene l pasado era con el uso de objetos de DCOM o Object Request Brokers (ORBs) basado en la especificación CORBA. Para entender la arquitectura orientada a servicios se debe comenzar con una clara comprensión de la palabra servicio. Un servicio es una función que está bien definida, en sí misma, y no depende del contexto o el estado de otros servicios. La tecnología de servicios Web es la tecnología de conexión más usada de arquitecturas orientadas a servicios. Los servicios Web utilizan fundamentalmente XML para crear una conexión robusta. La figura 1 muestra una arquitectura orientada a servicios básicos. Muestra un consumidor de servicios a la derecha que envia un mensaje de solicitud de servicio a un proveedor de servicios que se encuentra a la izquierda. El proveedor de servicios devuelve un mensaje de respuesta al consumidor de servicios. La solicitud y respuesta de las conexiones posteriores son definidas de alguna manera que sea comprensible tanto para el consumidor de servicios y proveedor de servicios. Un proveedor de servicios también puede ser un consumidor de servicios. figura. 1 Básico Arquitectura Orientada a Servicios Como un modelo de software distribuido, una SOA por lo general consta de tres partes principales: Productor (de servicios), consumidor (de servicios), directorio (de servicios), como se muestra en la figura 2. Servicios Web son considerados un ejemplo de arquitectura orientada a servicios. Las redes de servicios asumen las propiedades de una SOA.

3 figura. 2 Componentes básicos de la Arquitectura Orientada a Servicios El modelo de la Arquitectura Orientada a Servicios según IBM, está compuesto por tres participantes y tres operaciones fundamentales, con independencia de su aplicación. figura. 3 El modelo de SOA Proveedor de servicios: es un nodo de la red que proporciona una interfaz de servicios para un software que gestiona un conjunto específico de tareas. Un proveedor de servicios puede representar los servicios de una entidad de negocios o simplemente puede representar el servicio de interfaz para un subsistema reutilizables. Solicitante del servicio: es un nodo de la red que descubre e invoca otros servicios de software para proporcionar una solución de negocio. El solicitante del servicio representa un componente de aplicación de negocios que realiza llamadas a procedimiento remoto a un objeto distribuido, que es el proveedor de servicios.

4 En algunos casos, el nodo proveedor pueden residir localmente dentro de una intranet o en otros casos podría residir de forma remota a través de Internet. El concepto natural de SOA sale de la red, los protocolos de transporte, y los detalles de seguridad para la aplicación específica. El agente de servicio: es un nodo de red que actúa como un repositorio, páginas amarillas, o la cámara de compensación para las interfaces de software que son publicados por los proveedores de servicios. Una entidad de negocios o un operador independiente puede representar un corredor de servicio. Estos tres participantes de SOA interactúan a través de tres operaciones básicas: publicar, buscar, y unirse. Los proveedores de servicios publican servicios a un corredor de servicio. El solicitante de servicio encuentra los servicios necesarios con un corredor de servicio y se unen a ellos. Este es el proceso interactivo entre estos tres componentes, y las llamadas con las que interactúan.

5 2. Aplicabilidad de SOA SOA surge de la necesidad de hacer que los sistemas de negocios de IT sean más ágiles con respecto a los cambios en la empresa. Al permitir relaciones fuertemente definidas, si bien implementaciones específicas flexibles, los sistemas de IT pueden obtener las ventajas de los sistemas existentes y, no obstante, estar lista para cambios futuros en sus interacciones. Para comprender mejor los escenarios en los cuales se puede aplicar SOA, se plantea el siguiente problema: a) Escenario 1. Se tiene a disposición una organización minorista de vestiduras que posee una empresa de nivel internacional de 200 tiendas. Necesita cambiar frecuentemente sus diseños para mantenerlos a la moda. Esto podría significar no sólo cambios en estilos y colores, sino también en materiales, fabricación y entrega. Cambiar de un proveedor a otro puede ser un proceso de software complicado si los sistemas que hay entre el minorista y el fabricante son incompatibles. Solución La flexibilidad de una interfaz de WSDL para las operaciones puede permitir que cada compañía mantenga sus sistemas existentes tal como son. En vez de ello, pueden sólo hacer coincidir las interfaces de WSDL y establecer nuevos convenios de nivel de servicio en vez de reconstruir totalmente sus aplicaciones de software. Este es un cambio horizontal para la empresa, es decir, están cambiando asociados al tiempo que esencialmente todas las operaciones de negocios permanecen siendo las mismas en su mayoría. Las interfaces de negocios pueden cambiar de una manera mínima y las operaciones internas pueden permanecer sin cambios, al tiempo que las interfaces de negocios todavía pueden funcionar juntas externamente. b) Escenario 2 Otra forma es el cambio interno, en la que la organización minorista ahora decide que también alquilará espacio dentro de la cadena de tiendas minoristas a vendedores de boutiques, tal como el modelo de negocios de tienda a tienda. Aquí la mayoría de las operaciones de negocios de la compañía permanecen sin cambios, pero ahora se necesita un nuevo software interno para manejar ese convenio de alquiler. Solución Internamente, es posible que el sistema de software sea objeto de una revisión, pero necesita hacer esto sin afectar seriamente las interacciones con los sistemas existentes de sus proveedores.

6 El modelo SOA en este caso permanece intacto, al tiempo que la implementación interna cambia. Se pueden agregar nuevos aspectos al modelo SOA para agregar las nuevas responsabilidades de los acuerdos de alquiler, mientras que el sistema regular de administración minorista continúa siendo el usual. Para continuar aún más con la idea del cambio interno, puede que el gerente de IT encuentre que se puede usar la nueva configuración de otras maneras, tal como rentar también espacio de póster para publicidad. Aquí surge una nueva propuesta de negocios del modelo SOA flexible replicado en un nuevo diseño. Este es un nuevo resultado de un modelo SOA y una nueva oportunidad que podría no ser posible anteriormente. También son posibles los cambios verticales, donde el minorista pasa totalmente de vender sus propias ropas a alquilar exclusivamente espacio a través del modelo tienda en tienda. Si se toma completamente desde una base cero, un cambio vertical comprendería una reestructuración significativa del modelo SOA, tal vez con nuevos sistemas, software, procesos y relaciones. La ventaja del modelo SOA en este caso es que funciona desde la perspectiva de las operaciones y de los procesos de negocios, en vez de aplicaciones programas, permitiéndole a la administración de los negocios identificar claramente que necesidades deben ser agregadas, modificadas o eliminadas sobre la base del funcionamiento de la empresa. Luego se pueden estructurar los sistemas de software para ajustar los procesos de negocios, en vez de ser lo opuesto, según se ve comúnmente en muchas plataformas de software. Tal como se puede ver, el cambio y la capacidad del sistema SOA para adaptar a él son los elementos más importantes aquí. Para los desarrolladores, tales cambios pueden ocurrir dentro de su contexto de trabajo o fuera de él, según si hubiera cambios que son necesarios en cuanto a cómo las interfaces son definidas y cómo interactúan entre sí. En vez de ser el rol del desarrollador, es el del arquitecto engendrar la mayoría de los cambios en un modelo SOA. Esta división de trabajo, por la cual el desarrollador se concentra en crear unidades funcionales definidas como servicios, y el arquitecto y el modelador se concentran en la forma en que las unidades se ajustan entre sí, ha existido por más de una década, comúnmente representado en el Universal Modeling Language (UML) y descrito como un Model Driven Architecture (MDA). Los 8 escenarios de IBM IBM definió ocho situaciones cuyos patrones y características hacen que el uso de SOA sea útil. Se los denomina comúnmente, escenarios. Estos están organizados alrededor de cinco puntos de entrada distintos aunque interrelacionados, que ayudan a las empresas a arrancar y a tener éxito con SOA. Los puntos de entrada son conducidos tanto por necesidades de negocios como de IT y se clasifican basados en:

7 Gente: Habilitan la interacción entre los humanos y los procesos. Procesos: Habilitan y permiten una gran eficacia y eficiencia a través de la innovación del modelo de negocios. Información: Distribuye información confiable para habilitar los procesos de negocios. Conectividad: Mejora la flexibilidad de demanda al conectar los sistemas de software y los servicios. Reuso: Minimiza la complejidad de la adopción de SOA y de la implementación a partir de la reutilización de activos empresarios de alto valor. Los escenarios, entonces, caen en una de estas dos categorías: funcional o de soporte. Los primeros mapean directamente con uno o más de los puntos de entrada a SOA. Los de soporte, por su parte, hacen un corte a través de todos ellos. Escenarios funcionales: Creación de un servicio. Conectividad de un servicio. Servicios de interacción y colaboración. Business Process Management. La información como un servicio. Escenarios de soporte: Diseño SOA. Gobernancia SOA. Seguridad y administración SOA.

8 3. Ventajas y Desventajas Existen ventajas y desventajas a tomar en cuenta cuando se va a desarrollar la arquitectura SOA en una empresa, entre las ventajas presenta factores importantes que aumentan el interés del equipo ejecutivo y sobre todo, de los responsables de desarrollo, por la arquitectura SOA: A. Ventajas a) La arquitectura SOA ayuda a mejorar la agilidad y flexibilidad de las organizaciones: Las empresas deben ser capaces de crear y producir nuevos productos y servicios para unos clientes y ciudadanos que son cada vez más exigentes. El aumento de la colaboración con los clientes y proveedores, y la mayor capacidad para interpretar los datos de los clientes, proporcionan a las organizaciones los medios necesarios para interpretar los cambios del mercado de una forma más precisa y rápida. Lo que necesitan es conseguir que sus procesos de negocio sean capaces de ser adaptados al menos al mismo ritmo. Este dinamismo exige un nuevo conjunto de capacidades tecnológicas que permitan adaptar rápidamente los sistemas informáticos. El pensamiento tecnológico tradicional, que normalmente intentaba crear una aplicación nueva para cada proceso nuevo, nunca ha sido capaz de generar tal agilidad. Por el contrario, la arquitectura SOA se centra en las capacidades, no en las aplicaciones. SOA contempla la arquitectura de toda la empresa, incluidos los procesos de negocio y las tecnologías de la información. Además, el alto nivel de desacoplamiento e interoperabilidad proporcionado por la arquitectura SOA permite un alto grado de reutilización (interno y externo) y de parametrización. Todo ello redunda en una mayor facilidad y flexibilidad para adaptar y mejorar los procesos de las organizaciones según los cambios de prioridad del negocio. b) La arquitectura SOA permite una personalización masiva de las tecnologías de la información. La personalización masiva es un concepto donde al combinar de distinta manera los módulos estándar, se puede dar forma a un producto individualizado dentro de la infraestructura masiva de producción. La arquitectura SOA permite acelerar el proceso de creación e integración de nuevos servicios, y abaratar sus costes, permitiendo desarrollar complejas políticas de precios y contratación mejor adaptadas a segmentos específicos de clientes. La información necesaria para desarrollar nuevos servicios o productos ya existe dentro de los sistemas de la organización, y la arquitectura SOA crea una forma más fácil y rápida, menos costosa, de acceder a ella que en el pasado, y de utilizarla en la unidad que gestiona los clientes.

9 c) La arquitectura SOA permite la simplificación del desarrollo de soluciones mediante la utilización de estándares de la industria y capacidades comunes de industrialización. La arquitectura SOA desacopla los tres componentes de una aplicación: presentación, orquestación de procesos y lógica de negocio, a la vez que estandariza la comunicación entre cada una de las capas, favoreciendo a que el proceso de construcción se pueda dividir y por lo tanto industrializar más fácilmente. Además, las empresas se pueden focalizar en los componentes de mayor valor como los procesos y externalizar o comprar el resto de componentes. d) La arquitectura SOA permite aislar mejor a los sistemas frente a los cambios generados por otras partes de la organización (protección de las inversiones realizadas). Al organizar los sistemas en módulos más pequeños (servicios) se reduce notablemente el impacto de los cambios. A través de la creación de un modelo flexible que pueda reconfigurarse en función de las necesidades del negocio, la arquitectura SOA reutiliza, de un modo efectivo, los distintos sistemas tecnológicos actuales, por ejemplo, identificando la funcionalidad bajo los sistemas tecnológicos actuales y encapsulándolos en servicios que pueden ser utilizados por diferentes aplicaciones y procesos. e) La arquitectura SOA permite alinear y acercar las áreas de tecnología y negocio. SOA cubre la brecha entre la visión del negocio y la de sistemas, estableciendo un marco de diálogo con un lenguaje común: los procesos de negocio. Las áreas de negocio se centran en la definición de los procesos de acuerdo a la estrategia y el modelo de negocio de la compañía. El área de tecnología implementa los procesos a partir de la utilización de servicios existentes y la creación de nuevos cuando es necesario. Cuando el negocio requiere cambios en los procesos existentes, éstos se realizan de forma flexible y ágil, pues están implementados mediante tecnología estándar y servicios reutilizables. Además, por primera vez, hay una definición común de las aplicaciones: los procesos, que tanto el área de tecnología como el área de negocio comparten y entienden. f) Mejorar la productividad de los empleados. El acceso óptimo a los sistemas y la información y la posibilidad de mejorar los procesos permiten a las empresas aumentar la productividad individual de los empleados, en vez de aceptar las limitaciones y

10 restricciones impuestas por los sistemas de IT rígidos y monolíticos. g) Potenciar las relaciones con clientes y proveedores. Las ventajas de SOA van más allá de la organización. Los beneficios que ofrece SOA superan los límites de la propia organización. Los procesos de fusión y compra de empresas se hacen más rentables al ser más sencilla la integración de sistemas y aplicaciones diferentes. B. Desventajas a) La velocidad de intercambio de información entre sistemas es más lenta que una conexión directa, esto es debido a que si se desea intercambiar una gran cantidad de información este puede afectar el rendimiento del bus, con la posibilidad de crear congestionamiento, o perdida de alguna información importante. b) Aunque el SOA aporta grandes beneficios, no implica que sea útil para todas las empresas que deseen aplicar SOA en su arquitectura. c) El proceso de migración e adaptación a la arquitectura SOA suele ser lento, esto es debido a que se tiene que tener en cuenta el alcance, saber dónde y cómo aplicarla en los sistemas que presente la empresa.

11 4. Herramienta SOA : Mule ESB MULE ESB es un marco de mensajería ligera basada en Java que permite la rápida conexión e intercambio de datos entre aplicaciones. MULE utiliza una arquitectura orientada a servicios, permitiendo una fácil integración de los sistemas existentes. Independientemente de las diferentes tecnologías, incluyendo JMS, Web Services, JDBC, HTTP y más. El marco de trabajo de Mule es altamente escalable, permitiendo un inicio en pequeña magnitud y luego conectar más aplicaciones. Mule maneja todas las interacciones entre aplicaciones y componentes de manera transparente, sin importar si es que ellas se encuentran en la misma máquina virtual o en Internet, y sin importar el protocolo de transporte usado. Mule se basa en ideas de las arquitecturas Enterprise Service Bus (ESB). La principal ventaja de un ESB es que permite que diferentes aplicaciones se comuniquen entre sí, actuando como un sistema de tránsito para transportar datos entre las aplicaciones dentro de su intranet o a través de Internet. En este momento hay varias implementaciones comerciales de ESB en el mercado. Sin embargo, muchos de estos proporcionan una funcionalidad limitada o se construyen en la cima de un servidor de aplicaciones existentes o mediante mensajes de servidor, lo cual nos bloquea a usar un proveedor específico. Mule es independiente del proveedor, las implementaciones de proveedores diferentes pueden conectarse a Mule. Nunca estamos encasillados en un proveedor específico cuando se utiliza Mule.

12 Marco de Mensajes Cuando se conectan a las aplicaciones, Mule lee los datos desde una aplicación, los transforma, según sea necesario para que pueda ser leído por la aplicación de destino, y los envía a dicha aplicación. Esto le permite integrar todo tipo de aplicaciones, incluso aquellas que no fueron construidas para ser integradas. Ejemplo Hola Mundo En este ejemplo se utiliza dos servicios para crear un "hola mundo". Cuando se inicia la aplicación, se le pedirá que escriba su nombre, que es recibido por el primer servicio. El componente de servicio agrega un poco de texto a la cadena antes de pasarlo al segundo servicio, el cual añade el texto antes de escribir los resultados de vuelta a la consola. Hay maneras más fáciles para lograr este mismo resultado, pero este ejemplo proporciona una buena demostración de cómo un flujo de mensajes en una aplicación de Mule.

13 Las Clases La clase Greeter, que utiliza un método de la clase LocalMessage para sacar la cadena "Hello" de las propiedades del archivo. El método greet() a continuación, agrega "Hello" al nombre de la persona. public class Greeter { private String greeting = ""; public Greeter() { greeting = LocaleMessage.getGreetingPart1(); public Object greet(namestring person) { Object payload = person; if (person.isvalid()) { else { person.setgreeting(greeting); payload = new Exception(LocaleMessage.getInvalidUserNameError()); return payload; La segunda clase ChitChatter, añade el how are you? al string. public class ChitChatter { private String chitchat = ""; public ChitChatter()

14 { chitchat = LocaleMessage.getGreetingPart2(); public void chat(chatstring string) { string.append(chitchat); Y tenemos los servicios: GreeterUMO <service name="greeterumo"> <inbound> <stdio:inbound endpoint system="in" transformerrefs="stdintonamestring"/> </inbound> <component class="org.mule.example.hello.greeter"/> <outbound> <filtering router> <vm:outbound endpoint path="chitchatter"/> <payload type filter expectedtype="org.mule.example.hello.namestring"/> </filtering router> <filtering router> <vm:outbound endpoint path="usererrorhandler"/> <payload type filter expectedtype="java.lang.exception"/> </filtering router> </outbound> <default service exception strategy> <vm:outbound endpoint path="systemerrorhandler"/> </default service exception strategy> </service> Y ChitChatUMO: <service name="chitchatumo"> <inbound>

15 <vm:inbound endpoint path="chitchatter" transformerrefs="namestringtochatstring"/> </inbound> <component class="org.mule.example.hello.chitchatter"/> <outbound> <pass through router> <stdio:outbound endpoint system="out" transformerrefs="chatstringtostring" /> </pass through router> </outbound> </service> El sistema finalmente muestra lo siguiente al ingresar Ross por teclado: Hello Ross, How are you? Please enter your name: