ENTERPRISE SOA

ARQUITECTURA AVANZADA 2011

PROFESOR: J.J. Muoz Bussi

ALUMNO: Nicols Berruezo

1. SOA

1.1. DEFINICION DE SOA:

La arquitectura orientada a servicios de cliente (en ingls Service Oriented Architecture), es un concepto de arquitectura de software que define la utilizacin de servicios para dar soporte a los requisitos del negocio.

Permite la creacin de sistemas de informacin altamente escalables que reflejan el negocio de la organizacin, a su vez brinda una forma bien definida de exposicin e invocacin de servicios (comnmente pero no exclusivamente servicios web), lo cual facilita la interaccin entre diferentes sistemas propios o de terceros.

Es una coleccin de principios de diseo, utilizada en las fases de diseo, desarrollo e integracin.

Un sistema basado en SOA expone toda su funcionalidad como una suite de servicios interoperables que pueden ser usados entre multiples sistemas alojados en distintos dominios de negocio.

SOA es un marco de trabajo conceptual que permite a las organizaciones unir los objetivos de negocio con la infraestructura de TI integrando los datos y la lgica de negocio de sus sistemas separado

Desarrollada a finales de los 90, SOA establece un marco de trabajo para servicios de red o tareas comunes de negocios para identificar el uno al otro y comunicarlo.

La necesidad de tal marco se deriva de la evolucin del software de negocio. En los comienzos, los desarrollos de aplicaciones de negocio se concentraban en necesidades especficas: contabilidad, compras, nmina de sueldos, transporte. Cada aplicacin fue desarrollada sin consideracin de otros sistemas en la empresa y como comunicarse con ellos. Porque las aplicaciones eran auto suficientes, la informacin comn a toda la empresa (como por ejemplo: la direccin del cliente) y funciones especficas de negocios (como por ejemplo: buscar un nombre) aparecan en todas partes y requeran un cdigo complejo para, todos o muchos de los sistemas independientes.

Por consiguiente, los diversos sistemas de TI de la mayora de las empresas hoy no pueden acceder o procesar los datos desde el uno al otro. Un simple proceso de negocio (como una venta para un pedido a un depsito enviado a una cuenta por cobrar) que tomara segundos si los sistemas se podran comunicar, ahora puede tomar semanas.

Qu puede hacer una empresa? Debera tener inversiones masivas en hardware, software y perfiles de individuos involucrados en la ejecucin de cada una de las aplicaciones separadas? Con SOA, una empresa puede mantener sus inversiones en los sistemas legacy y la gente necesaria para mantenerlos. Esto evita continuos y costosos proyectos "de integracin", como las mejoras a cualquier aplicacin son transparentes a todas las otras. La informacin de negocio es siempre "hasta el ltimo minuto", permitiendo mejores decisiones de negocio y mejorar las relaciones entre clientes y partners.

A menudo, SOA es una solucin prometedora para los problemas de integracin. El desafo es cmo llegar ah.

1.2. DEFINICION DE SOA:

El desarrollo de un ambiente SOA involucra un nmero de pasos. El primer paso es asegurar que todo el software nuevo que se instale sea compatible con SOA. El segundo paso es identificar las funciones dentro de los sistemas legacy que desean integrar y publicarlas como servicios. Por supuesto, esto no es tan fcil como suena. El desarrollo de estos servicios puede requerir de perfiles que no existen en la empresa. Y las herramientas necesarias para examinar los desarrollos y las etapas de despliegue pueden venir de diferentes proveedores, cada uno con su propia instalacin, entrenamiento y temas de comunicacin.

El Desarrollo de Aplicaciones Orientadas a Servicios (SODA) est diseado para vencer muchos de los problemas de lenguajes de software inherentes en los sistemas legacy. SODA permite reutilizar aplicaciones existentes y proveer un camino para construir nuevas, basadas en estndares, con interfaces flexibles.

Esta adopcin habilita un alto nivel de abstraccin tecnolgica. Es decir, SODA encapsula y abstrae tecnologas tales como bases de datos, J2EE, .NET y CORBA de modo que los desarrolladores no afronten la complejidad tcnica de la interaccin con aplicaciones heterogneas y sistemas de infraestructura. SODA as reduce significativamente el esfuerzo requerido para traducir nuevos desafos de negocios dentro de aplicaciones funcionales.

1.3. PRINCIPIOS CLAVE DE SOA:

Abstraccin (de los detalles tcnicos de la implementacin).

Modularizacin (descartar la complejidad y crear piezas atmicas y reutilizables).

Conectividad estandarizada (lograr la composicin de servicios para resolver

Procesos de negocio).

Perdida de acoplamiento (los componentes evolucionan por separado sin

romper ninguno de los puntos de integracin).

Diseo incremental (permitir cambios de composicin y configuracin sin afectar

a los dems componentes).

Existe una percepcin errnea y comn que si no se logra globalmente la estandarizacin del diseo a travs de toda la empresa, SOA no tendr xito. Aunque la estandarizacin de diseo sea un factor de xito crtico para los proyectos SOA que se logra idealmente a lo ancho de toda una empresa, slo se requiere que sea realizada en una medida significativa para que la orientacin a servicios resulte en beneficios estratgicos.

Por ejemplo, la orientacin a servicios enfatiza la necesidad de estandarizar los modelos de datos de los servicios para evitar la transformacin de datos innecesaria y otros temas problemticos que pueden poner en peligro la interoperabilidad. El grado en el cual se logra la estandarizacin de modelos de datos determina el grado en el cual estos problemas sern evitados.

La meta no es siempre de eliminar los problemas enteramente porque esto pudiera ser un objetivo irrealista, particularmente en las grandes organizaciones. Por lo tanto, la meta es a veces solamente de minimizar los problemas, tomando en cuenta consideraciones especiales durante el diseo del servicio.

En apoyo a este enfoque, existen patrones de diseo para organizar la divisin de una empresa en dominios ms manejables. La estandarizacin de los datos es generalmente ms fcilmente alcanzada dentro de cada dominio, y la transformacin se requiere entonces solamente cuando se intercambien datos entre estos dominios. Aunque esto no logre la globalizacin del modelo de dato, an as puede ayudar a establecer un nivel muy significativo de interoperabilidad.

2. ENTERPRISE SOA

2.1. QU ES ENTERPRISE SOA?:

SOA es un patron de arquitectura el cual requiere exponer toda la funcionalidad

como interfaces de servicio independientemente de la plataforma sobre la que se

esta implementando.

ESOA es SOA a nivel empresarial, para esto es necesario que:

todas las interfaces de servicio deben estar definidas de forma clara y ser

estables.

se deben utilizar Global Data Types.

la comunicacin debe estar definida claramente y se deben utilizar patrones de

comportamiento.

se debe definir el sincronismo o asincronismo de los servicios.

se debe definir el manejo de excepciones.

En el mundo de ESOA y de la orientacin a servicios, el trmino "servicio" no es genrico. Tiene connotaciones especficas que se refieren a una combinacin nica de caractersticas de diseo. Cuando la lgica resolutiva es consistentemente construida como servicio y cuando los servicios son tambin consistentemente diseados con estas caractersticas comunes, la orientacin a servicios se logra exitosamente a travs de su entorno.

Por ejemplo, una de las primeras caractersticas de diseo de servicio explorado como parte de este estudio, es la reutilizabilidad. Un fuerte nfasis sobre la generacin de lgica resolutiva en la forma de servicios que son definidos como recursos de la organizacin altamente genricos y reutilizables, ejecuta gradualmente la transicin de una organizacin a un estado donde ms y ms de su lgica resolutiva se vuelve menos dependiente de, y ms agnstica hacia, cualquier proceso o propsito institucional. El impulsar en forma repetida esta caracterstica dentro de los servicios tiene como resultado final un potencial de reutilizacin generalizada.

La realizacin de manera consistente de caractersticas especficas de diseo requiere de un conjunto de principios guas. De esto trata todo el paradigma de diseo orientado a servicios.

Cuando se habla de los servicios es importante recordar que un nico servicio puede proveer una coleccin de capacidades. Estn agrupadas juntas porque se relacionan con un contexto funcional establecido por el servicio. El contexto funcional del servicio ilustrado en la ilustracin siguiente, por ejemplo, es la de un "despacho. Por lo tanto, este servicio en particular provee un conjunto de capacidades asociadas con el procesamiento de despachos.

Un servicio puede esencialmente actuar como un contenedor de capacidades relacionadas. Est comprendido de un cuerpo de lgica diseada para llevar a cabo estas capacidades y un contrato de servicio que expresa cules de estas capacidades son puestas a disposicin para invocacin pblica.

Ntese que cuando hacemos referencia a las capacidades del servicio en este sitio, estamos especficamente enfocados en aquellas que son definidas en el contrato de servicio. Cuando los servicios son implementados como componentes, estas capacidades son tpicamente diseadas como "mtodos," y cuando son expresadas como parte de un contrato de servicio web, son llamadas "operaciones."

Lo ms importante cada servicio debe estar definido sobre un objeto de negocio en particular, por lo tanto cada proceso de negocio ser un conjunto de interacciones entre diferentes objetos de negocio.

2.2. REPOSITORIO ESOA:

En un sistema integrado basado en ESOA, es necesario contar con un repositorio de servicios empresariales, donde cada uno de los sistemas involucrados publique las definiciones de las interfaces que expone y los detalles tcnicos de como esta implementada cada una de ellas. Tambin pueden exponerse en dicho repositorio los detalles de los distintos objetos de negocio involucrados a lo largo de todo el landscape del sistema.

De esta manera es fcil para un desarrollador o un arquitecto consultar los servicios existentes y poder construir aplicaciones con ellos.

En el repositorio adems se publican las medidas de seguridad con las que se implemento cada uno de los servicios all publicados.

La reutilizacin es fuertemente enfatizada dentro de la orientacin a servicios, hasta tal punto que se vuelve una parte central de los procesos tpicos de anlisis y diseo de servicio, y tambin forma la base para modelos de servicios claves. La irrupcin de una tecnologa de servicios madura y no-propietaria ha ofrecido la oportunidad de maximizar el potencial de reutilizacin de la lgica multi-propsito a un nivel sin precedentes.

El principio de Reutilizacin de Servicios enfatiza la ubicacin de los servicios como recursos de la empresa con contextos funcionales agnsticos. Se presentan numerosas consideraciones de diseo para asegurar que las capacidades individuales de los servicios sean adecuadamente definidas en relacin con un contexto de servicio agnstico, y para garantizar que puedan facilitar los requerimientos de reuso necesarios.

3. PROYECTOS ESOA

3.1. Landscape

ESOA no solo facilita la construccin de aplicaciones en las fases de desarrollo y de diseo de un proyecto, si no que adems ayuda a organizar las fases de relevamiento de requerimientos, de anlisis y de modelado funcional.

Algunas de las empresas ms importantes del mundo como SAP, Oracle, IBM y Microsoft, definieron en conjunto los estndares para la construccin de sistemas integrados basados en ESOA, de esta manera es muy fcil construir un landscape de integracin en el que se encuentran involucrados sistemas de distintos fabricantes.

En cada interaccin entre sistemas habr un proveedor y uno o varios consumidores.

Se pueden desarrollar los servicios en un lenguaje diferente para cada sistema del landscape, pero cada interfaz se expone al exterior en un lenguaje que todos puedan interpretar (por lo general XML).

Los sistemas propietarios basados en ESOA (sistemas de SAP, Oracle, IBM y otras)

proveen servicios estndar que ya vienen definidos de fbrica, los cuales pueden extenderse por medio de cdigo custom y tambin pueden desarrollarse nuevos servicios que reemplacen a estos.

Los servicios expresan sus propsitos y capacidades por medio de un contrato de servicio. El principio de diseo de la Estandarizacin de los Contratos de Servicios es quizs la parte la ms fundamental de la orientacin a servicios, en la medida que requiere esencialmente que se tomen en cuenta consideraciones especficas, cuando se disea la interfaz tcnica pblica de un servicio y se evala la naturaleza y la cantidad del contenido que ser publicado como parte del contrato oficial del servicio.

Se pone un nfasis especial sobre aspectos especficos del diseo del contrato, incluyendo la manera en la cual los servicios expresan sus funcionalidades, cmo se definen los tipos de datos y los modelos de datos, y cmo las polticas son impuestas y amarradas. Existe un foco constante en asegurar que los contratos de servicios son a la vez, optimizados, con la granularidad apropiada, y estandarizados de manera a garantizar que los puntos de conexin establecidos por los servicios sean consistentes, confiables y gobernables.

3.2. BPM

La gestin de procesos de negocio (BPM) como tecnologa, provee a las organizaciones la capacidad de mediante una serie de herramientas, componer, modelar, desplegar, ejecutar y monitorear procesos de negocio que incluyan tareas humanas y de sistemas.

Enterprise SOA es la evolucin necesaria para que la tecnologa BPM pueda llevarse a cabo con bajo riesgo. Provee la sustentabilidad arquitectnica para la transformacin de la red de negocio, es decir que marca el camino para que los actores de los procesos y los mismos procesos puedan comunicarse entre ellos.

De esta manera al utilizar una herramienta BPM sobre una plataforma diseada con arquitectura ESOA es sencillo definir procesos de negocio mediante la combinacin de distintos servicios empresariales.

A medida que la sofisticacin de las soluciones orientadas a servicios sigue creciendo, as crece la complejidad de las configuraciones de las composiciones de servicios subyacentes. La habilidad para componer efectivamente servicios es un requerimiento crtico para lograr algunos de los objetivos ms fundamentales en la computacin orientada a servicios.

Las composiciones ponen exigencias que deben ser anticipadas para evitar esfuerzos mayores de mantenimiento. Se espera de los servicios que sean capaces de participar como miembros efectivos de composiciones, independientemente de que si necesitan ser incorporados de inmediato en una composicin. El principio de Compuestabilidad de Servicios se enfoca a este requerimiento, asegurando que una cantidad de consideraciones sean tomadas en cuenta.

3.3. Provisin de servicios

Existen dos tipos de servicio que se construyen desde un sistema involucrado en un landscape de integracin, los servicios Inside-Out y los Outside-In. Los primeros son aquellos servicios que exponen funcionalidad propia del sistema en que fueron construidos, y los segundos son aquellos que son utilizados para que el sistema en el que fueron construidos obtenga informacin del exterior (es decir de otros sistemas, repositorios o bases de datos) necesaria para el proceso de negocio.

Los pasos para la construccin de un servicio son los siguientes:

Disear la interfaz del servicio y sus operaciones, disear el tipo de mensaje y disear

Los tipos de dato.

Definir el servicio en el entorno de desarrollo.

Publicar el servicio en el registro de servicios (ESB).

Objetos de Negocio:

Describen los datos de un area de negocio bien definida, es decir que todo el universo del negocio que un proyecto abarca se lo divide en areas de negocio y se le asigna un objeto de negocio a cada una que se encargara de describir los datos involucrados.

Componentes de Proceso:

Describen las partes contenidas en la cadena de valores de un proceso de negocio, es decir que agrupan varios objetos de negocio. Un objeto de negocio pertenece exactamente a un componente de proceso. Cada componente de proceso contiene datos y servicios para acceder a estos datos, lo que lo convierten en un modulo reutilizable entre distintos procesos de negocio. Es decir que los procesos de distintas aplicaciones pueden utilizar un mismo componente de proceso.

Deployment Unit:

Es un grupo de componentes de proceso que interactan entre s, y que deben ser instalados juntos en un sistema para que funcionen, definen los tipos de interaccin permitidos entre diferentes componentes de proceso.

La Orientacin a Servicios pone un nfasis sin precedente sobre la reutilizacin. Al establecer un inventario de servicios con un alto porcentaje de servicios reutilizables y agnsticos, estamos ubicando ahora estos servicios como los medios primarios (o nicos) con los cuales la lgica resolutiva que representan puede y debe ser accedida.

Como resultado, nos alejamos en forma deliberada de los silos en los cuales las aplicaciones existan anteriormente. Puesto que queremos compartir lgica resolutiva siempre que sea posible, automatizamos procesos institucionales existentes, nuevos y mejorados por medio de la composicin de servicios. Esto tiene como resultado un movimiento en la direccin de satisfacer ms y ms requerimientos del negocio, simplemente componiendo servicios existentes en nuevas configuraciones de composicin, en vez de construir o extender las aplicaciones existentes.

En este entorno, una aplicacin pierde su individualidad. Se podra argumentar que una aplicacin orientada a servicios en la prctica no existe porque no es ms, de hecho, que una de varias composiciones de servicios. Sin embargo, al acercarnos, podemos ver que algunos de los servicios efectivamente no son agnsticos en cuanto a procesos del negocio. El servicio de tarea, por ejemplo, representa intencionalmente lgica que se dedica a automatizar una tarea organizativa nica y es, por lo tanto, necesariamente reutilizable.

Lo que esto indica es que los servicios no agnsticos pueden seguir asocindose con la nocin de aplicacin. Sin embargo, dentro de la computacin orientada a servicios, el significado de este trmino puede cambiar para reflejar el hecho que una porcin potencialmente mayor de la lgica aplicativa ya no es exclusiva de la aplicacin.

Operaciones:

Son entidades que ejecutan diferentes tareas de un objeto de negocio. Una operacin es asignada a uno y solo un objeto de negocio.

Interfaces de Servicios:

Son grupos de operaciones. Una interfaz de servicio pertenece exactamente a un componente de proceso, y un componente de proceso puede contener varias interfaces de servicio. Las interfaces de servicio proveen funcionalidad al exterior por medio de servicios Inbound o usan funcionalidad del exterior por medio de servicios Outbound.

3.4. Consumo de servicios

Enterprise Service Workplace:

Las compaas de software pertenecientes a la comunidad ESOA, mantienen sus propios ES Workplaces, donde un usuario, un desarrollador o un diseador puede buscar no solo los servicios estndar, si no que tambin puede encontrar mapas de solucin, componentes de proceso, escenarios de integracin o paquetes de servicios empresariales.

Discovery Systems:

Los Discovery Systems, son repositorios internos incluidos en los sistemas propietarios basados en ESOA, que permiten explorar los servicios estndar del sistema en cuestin, as como tambin los servicios custom que se construyan en particular para la implementacin en cuestin.

Enterprise Services Repository:

Es un repositorio universal donde todas las compaas que pertenecen a la comunidad ESOA publican los servicios empresariales construidos para sus aplicaciones, adems se definen estndares para los objetos de negocio, componentes de proceso y deployment units.

Capa de Servicios:

Gracias a que varias aplicaciones desarrolladas en diferentes lenguajes utilizan los mismos estndares y principios de arquitectura, la construccin de los servicios siguen las mismas reglas y respetan los mismos estndares de exposicin, por lo que desde el punto de vista del consumo, para un usuario sera lo mismo consumir un servicio desarrollado en JAVA que un servicio desarrollado en ABAP, dado que la capa de servicios sera nica para todo el sistema de integracin.

Capa de Interfaz de Usuario:

A nivel de capa de interfaz de usuario, se consumirn funcionalidades de negocio que internamente consumirn los correspondientes servicios que resuelvan el caso de uso.

Capa de Proceso:

La sumatoria de varios casos de uso (es decir de varias funcionalidades de negocio) forman la capa de proceso. Un proceso de negocio sera expuesto como una serie de actividades en pos de un objetivo, es decir que internamente sera la sumatoria de la invocacin de varios servicios.

3.5. ESB

Un ESB es un middleware que se utiliza como intermediario entre sistemas que interactan en el mismo landscape de integracin, es decir que el uso ms comn es que todos aquellos sistemas expongan en l sus servicios y consuman los servicios expuestos por otro.

En conclusion el ESB provee una capa de abstraccin que contiene las caractersticas necesarias para poder implementar un sistema de integracin basado en ESOA. Es decir que es la infraestructura de comunicacin responsable de integrar los diferentes sistemas del landscape.

En el ESB se combinan los diferentes proveedores y los diferentes consumidores de servicios, adems de agrupar las funcionalidades de ejecucin de servicios, el mapeo entre mensajes de diferentes sistemas, el ruteo y funcionalidades de BPM, es decir que en esta capa se pueden construir los diferentes procesos de negocio a partir de los servicios de los distintos sistemas del landscape.

En informtica un bus de servicios de empresa (BSE) consiste en un combinado de arquitectura de software que proporciona servicios fundamentales para arquitecturas complejas a travs de un sistema de mensajes (el bus) basado en las normas y que responde a eventos. Los desarrolladores normalmente implementan un BSE utilizando tecnologas de productos de infraestructura de middleware que se basan en normas reconocidas.

Un BSE generalmente proporciona una capa de abstraccin construida sobre una implementacin de un sistema de mensajes de empresa que permita a los expertos en integracin explotar el valor del envo de mensajes sin tener que escribir cdigo. Al contrario que sucede con la clsica integracin de aplicaciones de empresa (IAE) que se basa en una pila monoltica sobre una arquitectura hub and spoke, un bus de servicio de empresa se construye sobre unas funciones base que se dividen en sus partes constituyentes, con una implantacin distribuida cuando se hace necesario, de modo que trabajen armoniosamente segn la demanda.

Un BSE no implementa en s mismo una arquitectura orientada a servicios (AOS), sino que proporciona las caractersticas mediante las cuales s se puede implementar. Un BSE debera basarse [citarequerida] en normas y proporcionar flexibilidad, dando cobertura a distintos medios de transporte que sean capaces de implementar tanto patrones de AOS tradicionales como arquitectura de negocios con una AOS 2.0 enriquecida. El BSE trata de aislar el acoplamiento entre el servicio solicitado y el medio de transporte. La mayora de los proveedores de BSE incorporan principios de AOS y permiten formatos de mensaje independientes.

Las caractersticas principales de un ESB son:

Soporte de mensajes sincrnicos y asincrnicos.

Capacidad de disear diferentes procesos de negocio a partir de los servicios expuestos.

Capacidad de mediar entre sistemas.

Patrones de enrutamiento, y mapeo y transformacin de mensajes.

Capacidad de responder ante grandes volmenes de concurrencia.

Interoperabilidad entre proveedores y consumidores que utilizan diferentes protocolos.

Capacidad de definir las polticas de seguridad para el nivel de mensajera y de transporte.

4. BIBLIOGRAFA

SAP ENTERPRISE SOA MANUALS

WIKIPEDIA

SOA PRINCIPLES