Sergio Zambrano Andrs Salazar

Antecedentes Protocolo RPC CORBA y DCOM Arquitectura SOAP Fundamento y definiciones SOA Caractersticas Ciclo del proceso BPM Plataforma tecnolgica SOA Modelo de madurez para arquitecturas SOA Ventajas y Desventajas

Uno de los puntos fuertes de IBM en su estrategia de ventas era proporcionar recursos de comunicacin entre ordenadores

La comunicacin se haca inicialmente a travs de cintas

A medida que transcurra el tiempo la comunicacin en tiempo real se haca cada vez ms necesaria

Aparecen los protocolos NFS (network file system) y FTP (file transfer protocol)

Se crea el protocolo RPC (Llamadas a procedimientos remotos)

CORBA

DCOM

Common Object Request Broker Architecture

Distributed Computing Object Model

Aparece en 1991 como intento de estandarizar la ejecucin distribuida de las funciones de programacin

Tecnologa de Microsoft como respuesta a la aparicin de CORBA. Aparece por primera vez en 1993.

Simple object access protocol

Se convirti en la panacea gracias a su compatibilidad con XML Se vea como una alternativa con filosofa RPC a CORBA y a DCOM Se convirti en el modelo dominante de la computacin distribuida

Utilizaba XML formato de facilitaba interoperabilidad lenguajes

como datos, la entre

Las RPC basadas en SOAP fueron una mejora respecto a las RPC anteriores

Necesitaban una red predecible

Como respuesta a los problemas RPC, los fundadores de SOAP crean los mensajes SOAP estilo documento

Se deja el paradigma de comunicacin nicamente para sistemas altamente acoplados

SUN fue el primer interesado en utilizar el estilo basado en documentos

Se contemplan los servicios web como medio para facilitar la interaccin entre sistemas

Problemas con RPC

Sistemas altamente acoplados

Msj. Soap estilo documento

Pensado ms como mtodo de comunicacin entre aplicaciones

Sistemas menos acoplados

Sistemas menos acoplados para transferencia de documentos y de datos

SUN utiliza el estilo basado en documentos

Lanza la interfaz de programacin API para servicios web

Servicios web
Se crea la arquitectura SOA

Si se publican las aplicaciones empresariales (funcionalidades de negocio) como servicios basados en el protocolo SOAP, tendremos las bases para utilizar nuestros servicios de forma sencilla y combinar estos servicios para crear procesos de negocio.

Applied SOA. Michael Rossen La arquitectura SOA es una representacin abierta, gil, extensible y combinada constituida por servicios autnomos, capaces de gestionar una calidad de servicio, posiblemente de proveedores, interoperables entre ellos y potencialmente reutilizables, implementados todos ellos como servicios web.

SOA: Open source. Davis Jeff La arquitectura orientada a servicios es una estratgia TIC que convierte las funciones discretas contenidas en aplicaciones empresariales en servicios basados en estndares y totalmente inoperativos que pueden combinarse y reutilizarse rpidamente para cumplir las necesidades de negocio de una organizacin.

CORBA Y DCOM

SOA en los

Estn basados en tecnologas RPC. Predica con insistencia Lo que quiere decir que introducen servicios poco acoplados. soluciones estrechamente acopladas en cuanto a usar objetos distribuidos.

Son plataformas especficas y por Los servicios web basados en SOA tanto no aceptan la fueron diseados teniendo claro interoperabilidad. que la clave estaba en la interoperabilidad. Eran tecnologas complicadas que, Puede utilizarse empleando a menudo, requeran de productos multitud de tenologas de software comerciales. libre independientes. No usan XML. Basada en XML representacin de datos. como

Consiste en la especificacin completa de un servicio entre un proveedor de servicios y un cliente. Tiene los siguientes componentes: Header o encabezado: Nombre del servicio Versin del servicio Propietario: La persona o el equipo encargado del servicio. Asignacin de responsabilidades: Responsable: Persona o equipo en cargado de entregar el servicio. Accountable: El que toma la decisin final en trminos del servicio. Consultor: A quien hay que consultar antes de ejecutar una accin. Tipo: Especifica el tipo de servicio a implementar.

Funcionales: Requerimientos funcionales: Especifica que es lo que exactamente el servicio va a lograr. Operaciones del servicio: Especifica mtodos y acciones que se toman para implementar el servicio. Invocacin: Indica cmo invocar el servicio. Incluye la URL, la interfaz, etc. No funcionales: Restricciones de seguridad. Calidad del servicio. Semntica. Descripcin del proceso.

Habilidad para invocar un servicio sin preocuparse donde se encuentra el punto final dentro de la red

Inmantenible y quebradiza. Haciendo algo tan sencillo como cambiar una URL, se puede conseguir que muchas aplicaciones dejen de funcionar.

El usuario ya no tendr que indicar de forma explcita la ubicacin del punto final especfico para un servicio determinado. En su lugar, todas las llamadas al servicio se direccionan a travs del proxy, el cual reenviar el mensaje al punto final adecuado.

Figura 1. http://www.sicuma.uma.es

Los servicios de bajo nivel (tambin denominados de grado fino) se encuentran en la capa superior de las aplicaciones y sistemas de negocio de la empresa. La capa de composicin de servicios representa servicios de grano ms grueso que las anteriores y consiste en dos o ms componentes individuales. Estos servicios pueden ser invocados por orquestaciones de servicios de ms alto nivel.

UDDI Plataforma estandar para el registro de servicios web.

Bases de datos

Catlogos de servicios En herramientas tipo wiki

Un proceso de negocio es un conjunto de actividades que generan un valor para la empresa. Son las actividades que tienen como objetivo el anlisis, diseo, ejecucin y monitorizacin de los procesos de negocio. Por lo tanto debe:
Permitir gestionar el ciclo de vida de los servicios Simular procesos de negocio Agilizar el cambio de los procesos

Antiguamente, a estos sistemas se les conoca como motores de procesamiento de flujos de trabajo (workflow).

Gestin de procesos de negocio

Intermediario entre aplicacin aplicacin

Framework: Un framework representa una arquitectura de software que modela las relaciones generales de las entidades del dominio. Provee una estructura y una metodologa de trabajo la cual extiende o utiliza las aplicaciones del dominio. Middleware: Un middleware proporciona un conjunto de primitivas de comunicacin de alto nivel que son requeridas para el desarrollo de aplicaciones distribuidas en red Servicio: Es una pieza discreta de cdigo y/ estructuras de datos que representa una funcionalidad de negocio bien definida. Acepta entradas y devuelve salidas a travs de una interfaz bien definida. WebService: Es un mtodo de comunicacin entre dos dispositivos electrnicos sobre la web. Utiliza una interfaz descrita en el formato WSDL, aunque tambin permite la comunicacin usando mensajes SOAP.

La orientacin SOA permite modelar un proceso como una composicin de servicios.

Web Service es la tecnologa mas popular para publicar e implementar la arquitectura SOA

BPM permite la gestin de procesos de negocio usando una arquitectura SOA

Servicios: Entidades lgicas - Contratos definidos por una o ms interfaces pblicas. Service provider: Entidad de software que implementa una especificacin de servicio. Service consumer (o requestor): Entidad de software que llama a un service provider. Tradicionalmente se lo llama cliente. Puede ser una aplicacin final u otro servicio. Service locator: Tipo especfico de service provider que acta como registry y permite buscar interfaces de service providers y sus ubicaciones. Service broker: Tipo especfico de service provider que puede pasar requerimientos de servicios a otros service providers.

Equipo de WSO2 est formado por expertos en sus respectivos mbitos.

Visin: Ofrecer la nica plataforma completa de middleware de cdigo abierto.

WSO2 tambin ha participado en proyectos de bienestar, tales como el proyecto Sahana.

Permite sustituir componentes individuales sin que eso afecte a otros componentes. Todos los sistemas se conectan al bus de la misma forma, con lo que se gana homogeneidad. Facilidad en la operacin y mantenimiento Proporciona una arquitectura sencilla ,robusta y escalable.

Existen cinco factores importantes que aumentan el inters del equipo ejecutivo y sobre todo, de los responsables de desarrollo, por la arquitectura SOA:
La arquitectura SOA ayuda a mejorar la agilidad y flexibilidad de las organizaciones La arquitectura SOA permite una personalizacin masiva de las tecnologas de la informacin La arquitectura SOA permite preparar mejor a los sistemas frente a los cambios generados por otras partes de la organizacin (proteccin de las inversiones realizadas) La arquitectura SOA permite alinear y acercar las reas de tecnologa y negocio Facilidad para la integracin de tecnologas dismiles.

En la medida en que un servicio de negocio, vaya siendo incorporado en la definicin de los procesos de negocio, dicho servicio aumentara su nivel . Con lo cual cada que se requiera efectuar una actualizacin en dicho servicio, deber evaluarse previamente el impacto y tener mucho cuidado con su implementacin. Sin embargo, parte de la problemtica anterior, puede ser solventada en virtud a un buen diseo del servicio. La implementacin de un bus de servicios empresarial BES, se convierte en un factor critico, si el bus llegase a fallar, la comunicacin (integracin), de los diferentes servicios y las aplicaciones se perdera, colapsando el sistema basado en servicios.

ROSEN, Michael. Applied SOA. Wiley, First Edition. Indianapolis, 2008. JEFF, Davis. SOA:Open Source. Anaya multimedia, Primera edicin. Madrid, 2010. http://en.wikipedia.org/wiki/Serviceoriented_architecture http://en.wikipedia.org/wiki/Business_process_ management www.sicuma.uma.es www.acis.org.co WS02 Project: http://wso2.com/