Arquitectura Orientada a Servicios (SOA)

Transcripción

1 Arquitectura Orientada a Servicios (SOA) Francelis Konrad konrad.kols@hotmail.com

2 Objetivos Comprender el estilo de arquitectura más adecuado para soluciones de integración. Caracterizar SOA (una iniciativa de industria) en términos formales. Establecer relación con estilos arquitectónicos de mayor grado de semejanza. Analizar puntualmente la relación entre SOA y Web Services. SOA como arquitectura, WS como implementación. Identificar los recursos de estado de arte para la realización de esta arquitectura

3 Agenda INTRODUCCION Que es SOA? SOA COMO ESTILO DE ARQUITECTURA RELACION DE SOA CON LOS WEB SERVICES CUÁNDO NO ES APTO OPTAR POR UNA ARQUITECTURA SOA BENEFICIOS DE SOA CASO DE ESTUDIO CONCLUSIONES Y REFERENCIA

4 INTRODUCCION QUEREMOS: Diseños Fácilmente Adaptables Reutilización Sistemas con Módulos Altamente Desacoplados Sistemas de Fácil Mantenimiento

5 INTRODUCCION SOA facilita: La interoperabilidad La reutilización La integración entre aplicaciones La ágilidad en la aplicación de cambios

6 QUE ES SOA? W3C: Conjunto de componentes que pueden ser invocados, cuyas descripciones de interfaces se pueden publicar y descubrir SEI rechaza esa definición: Los componentes pueden no ser conjuntos La definición sólo considera los componentes y no la práctica o el arte de construir la arquitectura SEI : Estilo resultante de políticas, prácticas y frameworks que permiten que la funcionalidad de una aplicación se pueda proveer y consumir como conjuntos de servicios, con una granularidad relevante para el consumidor. Los servicios pueden invocarse, publicarse y descubrirse y están abstraídos de su implementación utilizando una sola forma estándar de interface

7 QUE ES SOA? (IBM): Una arquitectura de aplicación en la cual todas las funciones se definen como servicios independientes con interfaces invocables bien definidas, que pueden ser llamadas en secuencias definidas para formar procesos de negocios (IBM). Gartner: SOA es una arquitectura de software que comienza con una definición de interface y construye toda la topología de la aplicación como una topología de interfaces, implementaciones y llamados a interfaces. Sería mejor llamada arquitectura orientada a interfaces. SOA es una relación de servicios y consumidores de servicios, ambos suficientemente amplios para representar una función de negocios completa.

8 QUE ES SOA? Francelis: SOA es un paradigma arquitectural que favorece la creación de aplicaciones vía la orquestación de los servicios que interactúan a través de una variedad de interfaces basados en estándares. SOA no se deriva de una propuesta académica Service-oriented architecture fue descripta por primera vez por Gartner en 1996 SSA Research Note SPA , 12 de abril, Service Oriented Architectures, Part 1 y SSA Research Note SPA , 12 de abril, Service Oriented Architectures, Part 2

9 QUE ES SOA? MITRE: Una aplicación SOA es una colección de servicios Un servicio es la unidad atómica de una SOA Los servicios encapsulan procesos de negocios Los proveedores de servicios se registran solos Las instancias más conocidas son los web services

10 SOA: Como Arquitectura Estilos de Flujo de Datos Tubería y filtros Estilos Centrados en Datos Arquitecturas de Pizarra o Repositorio Estilos de Llamada y Retorno Model-View-Controller (MVC) Arquitecturas en Capas Arquitecturas Orientadas a Objetos Arquitecturas Basadas en Componentes Estilo de Estilos de Código Móvil Arquitectura de Máquinas Virtuales Estilos heterogéneos Sistemas de control de procesos Arquitecturas Basadas en Atributos Estilos Peer-to-Peer Arquitecturas Basadas en Eventos Arquitecturas Orientadas a Servicios Arquitecturas Basadas en Recursos

11 SOA: Como Arquitectura Estilo de Componente: Servicio Conectores: Antes, RPC Ahora, paso de mensajes Configuración: Distribuido Constraint: Bajo acoplamiento, independencia de modelo de programación, independencia de plataforma, transporte y protocolo por acuerdo de industria.

12 SOA: Como Arquitectura Estilo de Capa de Acceso Capa de Process Capa de Servicio Capa de Recursos Evolución de aplicaciones monolíticas y cerradas a arquitectura de servicios reutilizables en red distribuidos en capas

13 SOA como Estilo de Arquitectura

14 SOA Como Arquitectura Estilo de

15 Implementacion de SOA

16 Estándares OASIS ( Universal Description, Discovery and Integration (UDDI) Web Services Business Process Execution Language (BPEL) Web Services Security (WS-Security) WS-SecureConversation WS-Trust Web Services for Remote Portlets (WSRP) extensible Access Control Markup Language (XACML) WS-Reliability / WSReliableMessaging

17 Estándares W3C ( SOAP,WSDL XML Signature / Encryption, XKMS Semantic Web Services XML-binary Optimized Packaging (XOP) Message Transmission Optimization Mechanism (MTOM) Resource Representation SOAP Header Block (RRSHB) Web Services Choreography Description Language (WS-CDL) WS-Policy WS-Addressing WS-Eventing

18 Propiedades de SOA Programación Estructurada Objetos Componentes Servicios Granularidad Muy fina Fina Intermedia Gruesa Contrato Definido Privado/Publico Publico Publicado Reusabilidad Baja Baja Intermedia Alta Acoplamiento Fuerte Fuerte Débil Muy débil Dependencias Tiempo de Compilación Tiempo de Compilación Tiempo de Compilación Run-Time Ámbito de Comunicación IntraAplicación IntraAplicación InterAplicaciones Inter-Empresas

19 Implementaciones RPC SOA Puede ser implementado utilizando un amplio rango de tecnologías, incluyendo RPC, DCOM, CORBA o Web Services DCOM CORBA JAVA RMI WS Protocolo RPC RPC IIOP IIOP o JRMP SOAP Formato mensaje NDR CDR Java Serialization Format XML 1.0 Namespaces Descripción IDL OMG IDL Java WSDL Descubrimiento Registry Naming Service RMI Registry o JNDI UDDI Marshalling Type Library Marshaller Serialization WS no requiere despliegue WS no requiere clientes específicos, ni drivers SOA se redefine como paso de mensajes, no RPC

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

21 RELACION DE SOA CON LOS WEB SERVICE Arquitectura Las especificaciones de un servicio web son modulares. Incluyen: Protocolo de comunicación Lenguaje de descripción de servicios Protocolo de publicación y descubrimiento de metadatos Normalmente osoap ( Simple Object Access Protocol) o WSDL ( Web Services Description Language) o UDDI (Universal Description Discovery and Integration )

22 RELACION DE SOA CON LOS WEB SERVICE UDDI: define un modelo de datos para almacenar información de servicios y negocios. SOAP(1998, IBM & W3C): Especificación que describe mecanismos y un formato de mensaje (basado en XML) para intercambiar información entre aplicaciones, en un ambiente distribuido y descentralizado WSDL: Lenguaje basado en XML que permite describir la interfaz y otras características de un Web Service

23 RELACION DE SOA CON LOS WEB SERVICE Metamodelo WSDL 2.4 Fuente: Red de Revista Científicas de América Latina, el Caribe, Portugal y España, 2008.

24 CUÁNDO NO ES APTO OPTAR POR UNA ARQUITECTURA SOA Cuando se tiene un ambiente de homogéneos Cuando ocurre en tiempo real rendimiento es crítico Cuando las cosas no cambian TI el

25 CASO DE ESTUDIO Se basa en la integración de dos aplicaciones: Un Sistema de multas de transito y un sistema de expedientes electrónicos. El sistema de multas de tránsito consiste en un webservice que permite el ingreso y consulta de multas por conductor o vehículo. A su vez el sistema de expedientes está compuesto de un Webservice, que permite la creación y consulta de expedientes.

26 CASO Entorno DE ESTUDIO: Definido

27 CASO Entorno DE ESTUDIO: Definido

28 CASO DE ESTUDIO : Entorno Definido Tooling BPEL Editor (Business Process Execution Language)

29 CASO DE ESTUDIO: Entorno Definido OpenESB Features Tooling IEP Editor (Intelligent Event Processing)

30 CASO DE ESTUDIO OpenESB Features Tooling Visual Service Assembly editor Composite Application Service Assembly

31 CASO DE ESTUDIO: Solucion

32 CASO DE ESTUDIO: Solucion

33 Conclusiones SOA El estilo de arquitectura más importante del momento, en desarrollo simultáneo en la academia y la industria Cambio histórico en modelo de diseño, de programación y de despliegue Propiedad del código, control de la facturación por su uso en ambientes de prueba y producción Cambios sustanciales en modelo de negocios Empresas ofrecen servicios a sus competidores ISV ofrecen servicios a otros ISVs Implementación posible de diversos modelos de computación distribuida (Pizarra, agentes ) Elaboración académica todavía pendiente

34 Recursos

35

36

37

38

39

40

41

42

43

44

45 Referencias

46 Referencias

47 Referencias

48 Referencias Jason Bloomberg - The role of the serviceoriented architect. The Rational Edge, mberg.jsp Marc Brooks (MITRE) - Service Oriented Architecture and Grid Computing. Ian Foster, Carl Kesselman, Jeffrey Nick, Steven Tuecke. Physiology of the grid. Brian Randell, Rockford Lhotka - Bridge the gap between development and operation with Whitehorse. MSDN Magazine, Julio de 2004

49 Referencias Werner Vogels - Web services are not distributed objects. tributed/archives/ html Luis Felipe Cabrera, Christopher Kurt, Don Box. An introduction to the Web Service Architecture and its specifications. MSDN Library, Setiembre 2004

50

51

52

53 Referencias Roy Thomas Fielding. Architectural styles and the design of network-based software architectures. Tesis doctoral, University of California, Irvine, Kevin Mitchell. A matter of style: Web Services architectural patterns. XML Conference & Exposition 2002, Baltimore, 8 al 13 de diciembre de Billy Reynoso - Documentos de arquitectura en arquitectura

54

55 Preguntas? Gracias!!!

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98 Perspectiva académica : SOA vs Objetos y Componentes distribuidos Werner Vogels (Cornell University): Web Services y SOA no son objetos distribuidos. Los web services no requieren tecnología de objetos distribuidos El intercambio de documentos es un concepto muy distinto a la instanciación de un objeto, la invocación de un método de una instancia, la recepción del resultado de la invocación y la liberación final de la instancia. Otros errores: El debugging de web services es imposible...

99 Perspectiva académica : SOA vs Objetos y Componentes distribuidos Werner Vogels - Otros errores: Web services son sólo RPC para Internet En SOAP 1.2 RPC/encoded es opcional, y se favorece document/literal La interacción sincrónica en wide area no es escalable, la coordinación de versiones será siempre complicadísima Se requiere HTTP para tener servicios Soporte de protocolos diversos desde WSE y en.net Framework 2

100 Perspectiva Académica : SOA vs Objetos y Componentes Distribuidos Werner Vogels (cont.) Se requieren servidores de web para tener web services Web debería haberse excluido, dejando simplemente services Hay herramientas que no requieren servidores de web: Simon Fell s PocketSoap, Systinet s WASP, IBM s Emerging Technologies Toolkit, Microsoft s Web Services Enhancements (WSE). Sistemas de integración de empresas como Artix y DocSOAP proporcionan desarrollo de web services que no requieren web servers

101 SOA & Grid Computing Grid: Modelo de resolución de problemas usando gran número de computadoras heterogéneas organizadas en clusters 2003: alguna convergencia con web services Open Grid Service Architecture (OGSA) implementa fundamentalmente WSDL y SOAP (Globus Toolkit 3 framework) Textos de Grid mencionan SOA como antecedente Alchemi Framework para Grid Computing en.net, utilizando.net Remoting y web services

102 Agregar Restricciones a Diagrama Lógico

103 Diseño con VS 2005 Class Designer Sincronización de diagrama y código Soporta diagramas similares a Class Diagram de UML, pero con acceso a métodos, propiedades, etc Agregar diagrama de clase Ver Class Details para ver y modificar interface de la clase También se pueden tratar clases de otros assemblies referenciados

104 Recursos de SOA en Visual Studio 2005 Team System Engine de modelado y herramientas de framework SOA en Visual Studio 2005 Resuelve el problema de roundtrip engineering Incluye Distributed System Designers Application Connection Designer Class Designer Logical Datacenter Designer...

105 Desarrollo de SOA en Team System Application Connection Designer Drag ExternalDatabase - Setear propiedades Exponer los datos via Web Service Interface (Web Service Endpoint) Drag ASP.NET web application para generar interface visual Listo...

106 Deployment de SOA Logical Datacenter Designer Definir IIS en Zone Desmilitarizada (DMZ) En la zona interior, un IIS llamado AppServer y una máquina que corre SQL Server Conectar mediante Connection Tool

107 SOA vs Objetos y Componentes Distribuidos Los componentes ofrecían reutilización, pero también acoplamiento relativamente alto. Las tecnologías seguían siendo propietarias. Aún cuando CORBA era un esfuerzo ostensiblemente basado en estándares, en la práctica se debía trabajar con una única implementación comercial de la especificación [The Rational Edge] El mercado de componentes no se desarrolló como se había previsto

108 SOA vs Objetos y Componentes Distribuidos Servicios APIs Pocas interacciones, de Muchas interacciones, grano grueso de grano fino Cada interacción es la misma Cada interacción es diferente Cada interacción es un paso en un proceso de negocios. No hay procesos o estados de más bajo nivel. Muchas interacciones para completar un proceso de negocios. Muchos procesos o estados intermedios. Beneficios Se requiere menos comunicación y hay menos sobrecarga Más fácil de implementar y cambiar Menos complejidad cuando el consumidor o el proveedor deben cambiar. Sólo se requiere acordar procesos o estados a nivel de negocios.