Sergio Zambrano Andrés Salazar

Antecedentes ◦ Protocolo RPC ◦ CORBA y DCOM ◦ Arquitectura SOAP  Fundamento y definiciones SOA  Características  Ciclo del proceso  BPM  Plataforma tecnológica 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 comunicación entre ordenadores

La comunicación se hacía inicialmente a través de cintas

A medida que transcurría el tiempo la comunicación en tiempo real se hacía cada vez más 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 ejecución distribuida de las funciones de programación Tecnología de Microsoft como respuesta a la aparición de CORBA. . Aparece por primera vez en 1993.

Simple object access protocol Se convirtió en la panacea gracias a su compatibilidad con XML Se veía como una alternativa con filosofía RPC a CORBA y a DCOM Se convirtió en el modelo dominante de la computación 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 .

Soap estilo documento Pensado más como método de comunicación 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 programación API para servicios web Servicios web Se crea la arquitectura SOA .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 comunicación ú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 interacción entre sistemas Problemas con RPC Sistemas altamente acoplados Msj.

posiblemente de proveedores.Si se publican las aplicaciones empresariales (funcionalidades de negocio) como servicios basados en el protocolo SOAP. . interoperables entre ellos y potencialmente reutilizables. Applied SOA. implementados todos ellos como servicios web. capaces de gestionar una calidad de servicio. extensible y combinada constituida por servicios autónomos. Davis Jeff La arquitectura orientada a servicios es una estratégia TIC que convierte las funciones discretas contenidas en aplicaciones empresariales en servicios basados en estándares y totalmente inoperativos que pueden combinarse y reutilizarse rápidamente para cumplir las necesidades de negocio de una organización. SOA: Open source. tendremos las bases para utilizar nuestros servicios de forma sencilla y combinar estos servicios para crear procesos de negocio. ágil. Michael Rossen La arquitectura SOA es una representación abierta.

soluciones estrechamente acopladas en cuanto a usar objetos distribuidos. Eran tecnologías complicadas que. No usan XML. como . que la clave estaba en la interoperabilidad. Basada en XML representación de datos. libre independientes. requerían de productos multitud de tenologías de software comerciales. Son plataformas específicas y por Los servicios web basados en SOA tanto no aceptan la fueron diseñados teniendo claro interoperabilidad. Puede utilizarse empleando a menudo. Predica con insistencia Lo que quiere decir que introducen servicios poco acoplados.CORBA Y DCOM SOA en los Están basados en tecnologías RPC.

Consiste en la especificación completa de un servicio entre un proveedor de servicios y un cliente. . Accountable: El que toma la decisión final en términos del servicio. Tipo: Especifica el tipo de servicio a implementar. Consultor: A quien hay que consultar antes de ejecutar una acción. Asignación de responsabilidades: Responsable: Persona o equipo en cargado de entregar el servicio. Tiene los siguientes componentes: •Header o encabezado: Nombre del servicio Versión del servicio Propietario: La persona o el equipo encargado del servicio.

Incluye la URL. Invocación: Indica cómo invocar el servicio. Semántica. Operaciones del servicio: Especifica métodos y acciones que se toman para implementar el servicio. Calidad del servicio.•Funcionales: Requerimientos funcionales: Especifica que es lo que exactamente el servicio va a lograr. •No funcionales: Restricciones de seguridad. etc. Habilidad para invocar un servicio sin preocuparse donde se encuentra el punto final dentro de la red . la interfaz. Descripción del proceso.

Inmantenible y quebradiza. . El usuario ya no tendrá que indicar de forma explícita la ubicación del punto final específico para un servicio determinado. En su lugar. todas las llamadas al servicio se direccionan a través del proxy. se puede conseguir que muchas aplicaciones dejen de funcionar. el cual reenviará el mensaje al punto final adecuado. Haciendo algo tan sencillo como cambiar una URL.

Figura 1.es Los servicios de bajo nivel (también denominados de grado fino) se encuentran en la capa superior de las aplicaciones y sistemas de negocio de la empresa. La capa de composición de servicios representa servicios de grano más grueso que las anteriores y consiste en dos o más componentes individuales. http://www. .sicuma.uma. Estos servicios pueden ser invocados por orquestaciones de servicios de más alto nivel.

Bases de datos Catálogos de servicios En herramientas tipo wiki .UDDI Plataforma estandar para el registro de servicios web.

.

Son las actividades que tienen como objetivo el análisis. ejecución y monitorización de los procesos de negocio. . a estos sistemas se les conocía como motores de procesamiento de flujos de trabajo (workflow).  Un proceso de negocio es un conjunto de actividades que generan un valor para la empresa. diseño. Por lo tanto debe: ◦ Permitir gestionar el ciclo de vida de los servicios ◦ Simular procesos de negocio ◦ Agilizar el cambio de los procesos  Antiguamente.

Gestión de procesos de negocio Intermediario entre aplicación aplicación .

Middleware: Un middleware proporciona un conjunto de primitivas de comunicación de alto nivel que son requeridas para el desarrollo de aplicaciones distribuidas en red Servicio: Es una pieza discreta de código y/ó estructuras de datos que representa una funcionalidad de negocio bien definida. WebService: Es un método de comunicación entre dos dispositivos electrónicos sobre la web. Utiliza una interfaz descrita en el formato WSDL. aunque también permite la comunicación usando mensajes SOAP. Provee una estructura y una metodología de trabajo la cual extiende o utiliza las aplicaciones del dominio. Acepta entradas y devuelve salidas a través de una interfaz bien definida.    Framework: Un framework representa una arquitectura de software que modela las relaciones generales de las entidades del dominio. .

.

La orientación SOA permite modelar un proceso como una composición de servicios. Web Service es la tecnología mas popular para publicar e implementar la arquitectura SOA BPM permite la gestión de procesos de negocio usando una arquitectura SOA .

.

Service broker: Tipo específico de service provider que puede pasar requerimientos de servicios a otros service providers. Tradicionalmente se lo llama “cliente”. Servicios: Entidades lógicas .     . Service locator: Tipo específico de service provider que actúa como registry y permite buscar interfaces de service providers y sus ubicaciones. Service consumer (o requestor): Entidad de software que llama a un service provider. Service provider: Entidad de software que implementa una especificación de servicio.Contratos definidos por una o más interfaces públicas. Puede ser una aplicación final u otro servicio.

.

.

. tales como el proyecto Sahana. Visión: Ofrecer la única plataforma completa de middleware de código abierto. WSO2 también ha participado en proyectos de bienestar.Equipo de WSO2 está formado por expertos en sus respectivos ámbitos.

.

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

 Existen cinco factores importantes que aumentan el interés 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 “personalización masiva” de las tecnologías de la información ◦ La arquitectura SOA permite preparar mejor a los sistemas frente a los cambios generados por otras partes de la organización (protección de las inversiones realizadas) ◦ La arquitectura SOA permite alinear y acercar las áreas de tecnología y negocio ◦ Facilidad para la integración de tecnologías disímiles.

parte de la problemática anterior. Con lo cual cada que se requiera efectuar una actualización en dicho servicio.  . de los diferentes servicios y las aplicaciones se perdería. si el bus llegase a fallar. la comunicación (integración). Sin embargo. deberá evaluarse previamente el impacto y tener mucho cuidado con su implementación. se convierte en un factor critico. En la medida en que un servicio de negocio. La implementación de un bus de servicios empresarial BES. colapsando el sistema basado en servicios. puede ser solventada en virtud a un buen diseño del servicio. vaya siendo incorporado en la definición de los procesos de negocio. dicho servicio aumentara su nivel .

.

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