Arquitectura Orientada a Servicios SOA Billy Reynoso Universidad

Arquitectura Orientada a Servicios (SOA) Billy Reynoso Universidad de Buenos Aires billyr@microsoft. com. ar

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 Suministrar referencias de utilidad académica

Agenda SOA en la industria - Muestreo Definiciones Contexto de situación y antecedentes Principales conceptos SOA como Estilo de Arquitectura Relaciones de SOA con Web Services Diferencias con Objetos o Componentes distribuidos Distintas concepciones: IBM, Rational, Sun, Microsoft, REST Perspectivas: SOA & Grid Computing - SOA & Semantic Web Recursos de SOA Conclusiones, referencias y recursos

SOA en la industria - Muestreo “La recompensa potencial [de SOA] es enorme para las empresas que entiendan esta evolución y se muevan hacia estas arquitecturas. . La tecnología de computación distribuida promete ser lo suficientemente flexible y elegante para responder a las necesidades de negocios y proporcionar la agilidad de negocios que las compañías han anhelado tanto tiempo, pero siempre ha estado fuera de alcance”. [The Rational Edge, 2004] “La mejor solución a la integración de negocios. . . ” [Annraí O’Toole, Cape Clear] “SOA ha surgido como la mejor manera de afrontar el desafío de hacer más con menos recursos. Promete hacer la re-utilización y la integración mucho más fáciles, ayudando a reducir el tiempo de desarrollo y aumentando la agilidad organizacional. No sorprendentemente, el 80% de las organizaciones de IT están implementando aplicaciones usando SOA con web services subyacentes. SOA proporciona mayor flexibilidad para afrontar los cambios tanto en el ambiente de negocios como en la infraestructura tecnológica”. [M 7 Corporation]

SOA en la industria - Muestreo “SOA es la próxima ola de desarrollo de aplicaciones. Es más rápida, mejor y más barata” [Michael Pallos, 2001] “Comprender el rol y el significado de SOA, más allá del hype simplista, es imperativo para cualquier arquitecto de software empresarial. . Hacia 2008, SOA y Web Services serán implementados juntos en más del 75% de los proyectos que utilicen SOA y Web Services (probabilidad 0. 7)” [Gartner, 2003] “Hacia 2008, más del 75% de los paquetes de aplicación de ese entonces serán nativamente SOA o expondrán interfaces SOA a través de una capa de envoltura de interfaces (probabilidad 0. 8)” [Gartner, 2003] “Hacia 2008, SOA será la práctica prevalente de ingeniería de software, acabando con los 40 años de dominación de las arquitecturas monolíticas (probabilidad 0. 7)” [Gartner, 2003] “Giga recomienda a los arquitectos considerar SOA como la prioridad número uno en sus esfuerzos de planeamiento arquitectónico” [Giga IT Trends 2003: Application architecture and design]

Contexto de situación y antecedentes Evolución de la arquitectura: Servicios Componentes Objetos distribuidos 3 -Tier, N-Tier Abstracción Web Services Ecosistema Horizontal Client/Server Estructurado Monolítico Vertical

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

Historia SOA no se deriva de una propuesta académica No hay technical reports de SOA en SEI Service-oriented architecture fue descripta por primera vez por Gartner en 1996 SSA Research Note SPA-401 -068, 12 de abril, “‘Service Oriented’ Architectures, Part 1” y SSA Research Note SPA-401 -069, 12 de abril, “‘Service Oriented’ Architectures, Part 2” Web Services surgen con mayor fuerza hacia el 2000.

Historia XML Web Services® SOA = XML+SOAP+WSDL+UDDI+Bus SOAP 1. 0 - Específico de MS+Developmentor XML + HTTP SOAP 1. 1 - MS+IBM+Lotus Bindings de transporte para no-HTTP SOAP 1. 2 - W 3 C. org (ya no es más acrónimo)

SOA - Definiciones W 3 C: “Conjunto de componentes que pueden ser invocados, cuyas descripciones de interfaces se pueden publicar y descubrir” CBDI 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 CBDI: “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”

SOA - Definiciones “Infraestructura de alto nivel basada en best practices y patrones para crear soluciones basadas en servicios, de alta cohesión y bajo acoplamiento” (Geniant®). “Estilo arquitectónico apto para implementar bajo acoplamiento entre agentes. Los agentes son proveedores y consumidores de servicios, que son la unidad de trabajo”. (Hao He). “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).

SOA - Definiciones 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 Un servicio involucra: Find, Bind, Execute Las instancias más conocidas son los web services 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”.

SOA como Estilo de 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 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

SOA como Estilo de Arquitectura 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

Principales conceptos CBDI - Perspectivas arquitectónicas Aplicación - Servicio - Componente

Implementaciones RPC • WS no requiere despliegue • WS no requiere clientes específicos, ni drivers • SOA se redefine como paso de mensajes, no RPC

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.

Demo & Drilldown

SOA y Web Services Web services: Diferentes definiciones en W 3 C Web Services Architecture Working Group W 3 C: “Una aplicación identificada por un URI, cuyas interfaces y binding se pueden definir, describir y descubrir mediante artefactos XML, que soporta interacciones usando mensajes basados en XML via protocolos de web” SOA es históricamente anterior (no por mucho) Un web service es SOA si: Las interfaces se basan en protocolos de web (HTTP, SMTP, FTP) A excepción de los attachments, los mensajes se basan en XML Dos estilos de web service: SOAP y REST es anti-RPC (más sobre esto luego) SOAP puede interpretarse en términos de mensajes o de RPC (Don Box)

SOA y Web Services CBDI: SOA es más amplio. Los web services son sólo una interface programática en conformidad con los protocolos WS-* Puede haber SOA sin WS (ej. REST) Los web services proporcionan independencia de plataforma, bajo acoplamiento, auto-descripción y descubrimiento Los web services no son parte obligatoria de SOA, pero son una implementación adecuada

Estándares primarios - WSDL XML que describe servicios Propuesto por Microsoft e IBM y presentado a W 3 C por 25 empresas (número máximo admitido) Define data types pasados en mensajes, operaciones a realizar y mapeado de los mensajes sobre transportes de red Puede haber algunas discrepancias entre diferentes implementaciones, debido a que es extensible

Estándares SOA & Web Services http: //WS-I. ORG

Framework de SOA BPEL 4 WS – Reemplaza a XLANG (MS) y a lenguajes de workflow de IBM

Estilo REST - REpresentational State Transfer (Roy Fielding, 2000) SOA sin Web Services, ni SOAP ni RPC Arquitectura con modelo de datos (recursos, URIs y representaciones XML) Composición de diversos estilos: repositorio replicado, cache, cliente-servidor, sistema en capas, sistema sin estado, máquina virtual, código a demanda e interfaz uniforme

Modelo REST Una aplicación REST transfiere representaciones entre componentes usando conectores Componentes: incluyen agentes de usuario (Mozilla, c. URL) y servidores de origen (Apache, IIS) Los componentes de REST obedecen estas restricciones: las interaciones son stateless los recursos se identifican mediante URIs no hay tal cosa como servicios ni objetos, sólo recursos no se permite el paso de cookies y se propone el reemplazo de MIME (Multipurpose Internet Mail Extensions) por su discrepancia arquitectónica con la semántica de HTTP hypermedia es la máquina de estado de la aplicación no hay necesidad de toolkits: sólo URIs y XML

SOAP versus REST Polémica sobre el estilo dominante en SOA. Abundancia de pullas: “Give SOAP a REST” - “Otra vez SOAP” - “REST could burst the SOAP bubble”, “Slippery SOAP” REST enfatiza el papel de los intermediarios: caches, proxies, gateways, etc REST es adecuado para transferencias y transformaciones simples. Transacciones complejas requieren sin duda SOAP. No hay herramientas para implementar REST rigurosamente; sí en cambio las hay para SOAP RPC. Idem en relación con middlewares

SOAP vs REST 80 implementaciones independientes de SOAP 1. 1 en 2002 – Centenares a fines de 2005 eb. XML adoptó SOAP como protocolo de base SOAP incorporó ideas de eb. XML a través de WS-* Integridad de mensajes, no-repudio, mensajería confiable, flujo de procesos de negocios, negociación de protocolos SOAP puede alcanzar mejor performance porque puede ser stateful y no tiene que trasmitir información de estado. A la larga el comité de WSA en W 3 C no optó entre REST y SOAP, sino que reformuló SOAP 1. 2 adoptando ideas de REST “Intercambio asincrónico de documentos” ha ganado mindshare a expensas de “RPC” “Web services como objetos distribuidos” tiene cada vez menos adeptos DTD y tecnologías similares han sido eliminadas

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

SOA vs Objetos y Componentes distribuidos

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. . .

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

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 Pocket. Soap, Systinet’s WASP, IBM’s Emerging Technologies Toolkit, Microsoft’s Web Services Enhancements (WSE). Sistemas de integración de empresas como Artix y Doc. SOAP proporcionan desarrollo de web services que no requieren web servers

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

SOA & Grid Computing SOA Standards WSDL UDDI BPEL WS-Profile WS-Security WS-Choreography Etcétera… Grid Standards OGSI Extensión de WSDL WS-Resource. Lifetime WS-Resource. Properties WS-Renewable. References WS-Service. Group WS-Base. Faults

SOA & Semantic Web (1/3) Semantic Web: Propuesta por Sir Tim Berners-Lee Creador del WWW en 1984 y el primer web site, 1991; fundador de W 3 C en el MIT. No royalties!! Semántica comprensible para máquinas y aplicaciones Hay una semántica actualmente, pero en realidad opera sobre correspondencias sintácticas (XML Schemas)

SOA & Semantic Web (2/3) Semantic web utiliza: XML Schema RDF (Resource Description Framework) Triplas de Sujeto + Predicado + Objeto RDF Schema - Semántica de generalización y jerarquía OWL (Web Ontology Language) Extensión de vocabulario de RDF Cardinalidad, características, equivalencias, relaciones

SOA & Semantic Web (3/3) En curso: Integración de estándares de industria con investigación académica Desarrollos en proceso DAML-S - (Darpa Agent Markup Language) Agrega definiciones, pre-condiciones, poscondiciones etc a estándares usuales SOA (Service Profile); también abstracciones de proceso (Service Model) y aspectos técnicos (Service Grounding) SWOBIS = UDDI + ontología

Recursos de SOA en. NET Framework 1. 0 (2000) XML Schema 1. 0, SOAP 1. 1, WSDL 1. 1, UDDI 1. 0 (idem: J 2 EE 1. 4) . NET Framework 1. 1 (2002) WS-Security, WS-Routing (HTTP, UDP, TCP), Direct Internet Message Encapsulation (DIME: soporte binario de cualquier tipo y tamaño en un solo mensaje), WS-Attachments (en formato DIME) Windows Server 2003 Device driver HTTP. SYS (modo kernel), UDDI Server (registrar y publicar web services)

Innovaciones tecnológicas de impacto arquitectónico: Web Services Enhancements

Web Services Enhancements No solamente web ni ASP. NET: Las aplicaciones se pueden hostear en múltiples ambientes ASP. NET, . exe, NT Service, Win. Forms, etc. Soporte para múltiples transportes in-process communication (para testing) TCP puro HTTP Soporte de operaciones prolongadas y complejas

Drilldown: Mejoras en seguridad Políticas de seguridad basadas en estándares de industria Trust Issuing Framework (WS-Trust) Secure Conversation (WSSecure. Conversation) Autorización basada en roles Policies de seguridad (WS-Security. Policy)

Trust Relaciones e identidad: tokens de seguridad con firma digital ¿Cómo pruebo quien soy? ¿Quién me puede avalar? ¿Cómo sabe usted que puede confiar en él? WS-Trust define un protocolo para emitir y obtener tokens de seguridad

Confianza (Trust) Token Issuer Diversos modelos para emitir tokens El cliente obtiene token de una fuente bien conocida El servicio obtiene un token para el cleinte Etc… Token Issuer 1 Issuer 2 Client Token Issuer Client Service

Conversación segura WS-Secure. Conversation detalla la forma de emitir un Security. Context. Token En WSE, este token de peso ligero reemplaza a los tokens que requieren proceso intensivo Requerimiento de SCT Cliente SCT emitido al cliente Series de mensajes firmados con el SCT emitido Emisor del Servicio y el Token

Creando conversaciones seguras Los servicios pueden emitir sus propios SCTs Ya no hay necesidad de desplegar emisor de SCT Hay que tocar un elemento de configuración <auto. Issue. SCT enabled=true />

Drilldown: Policy Driven Architecture Más allá de WSDL ¿qué más se requiere para describir un (web) service? Requisitos de seguridad Seguridades de mensaje confiable Manejo de versiones de protocolo Etc… Estos y otros atributos de un servicio se pueden describir con WS-Policy Lenguaje basado en XML Complejo: <Or>, <Exactly. One>, etc… WSE proporciona un Framework de Policy con soporte del lado del que envía y del que recibe

Facilidades adicionales Varios ejemplos Security Settings Wizard Standalone Config Editor X 509 Certificate Wizard para manejar los certificados propios Namespace Viejo: Microsoft. Web. Services Nuevo: Microsoft. Web. Service 2

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 . . .

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

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

Agregar Restricciones a diagrama lógico

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

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

Recursos

Referencias

Referencias Jason Bloomberg - “The role of the service-oriented architect”. The Rational Edge, http: //www. therationaledge. com/may_03/f_bloomberg. jsp Marc Brooks (MITRE) - “Service Oriented Architecture and Grid Computing”. http: //webservices. gov/Brooks 32404. ppt Ian Foster, Carl Kesselman, Jeffrey Nick, Steven Tuecke. “Physiology of the grid”. http: //www. globus. org/research/papers/ogsa. pdf Brian Randell, Rockford Lhotka - “Bridge the gap between development and operation with Whitehorse”. MSDN Magazine, Julio de 2004

Referencias Werner Vogels - “Web services are not distributed objects”. Http: //weblogs. cornell. edu/All. Things. Distribut ed/archives/000119. html - 2003 Luis Felipe Cabrera, Christopher Kurt, Don Box. “An introduction to the Web Service Architecture and its specifications”. MSDN Library, Setiembre 2004

Referencias Roy Thomas Fielding. “Architectural styles and the design of network-based software architectures”. Tesis doctoral, University of California, Irvine, 2000. Kevin Mitchell. “A matter of style: Web Services architectural patterns”. XML Conference & Exposition 2002, Baltimore, 8 al 13 de diciembre de 2002. Http: //www. ws-i. org Billy Reynoso - Documentos de arquitectura en http: //www. microsoft. com/spanish/msdn/ arquitectura

¿Preguntas? Billyr@microsoft. com. ar http: //www. microsoft. com/spanish/msdn/arquitectura