eser2 b
TRANSCRIPT
E-ServicesE-Services
2. Arquitectura técnica general y estándares (segunda parte)
Posgrado en E-Business ManagementPosgrado en E-Business Management
Universidad del Salvador - Argentina Universidad del Salvador - Argentina Geogetown University - U.S.A.Geogetown University - U.S.A.
Período 2007
2
Estándares para componer transacciones y procesos
El estándar ebXML de la OASIS
La seguridad en los web services
El concepto de “Grid Services”.
Conclusiones sobre estándares de Web Services
Agenda de temasAgenda de temas
3
Faltan:
• Mecanismos para otorgar confiabilidad a la mensajería SOAP
• Mecanismos para coordinar la interacción de múltiples web services y componer transacciones y procesos de negocios
• Mecanismos para proveer capacidades de autenticación y autorización de las partes
Lo que falta en el modelo Lo que falta en el modelo de los Web Services “básicos”de los Web Services “básicos”
4
Estándares para componer Estándares para componer procesos con Web Services procesos con Web Services
5
Iniciativas para una mensajería Iniciativas para una mensajería confiable con Web Servicesconfiable con Web Services
WS-ReliableMessaging / WS-Addressing:WS-ReliableMessaging / WS-Addressing:
Presentadas en marzo de 2003 por IBM, Microsoft, y otras compañías, estas especificaciones proveen en conjunto un mecanismo estándar para el intercambio seguro de mensajería de web services.
Entre otras cosas, permiten asegurar la recepción de los mensajes en el orden en que fueron enviados y la detección de mensajes no recibidos o duplicados.
WS-Addresing es “recomendación” del W3C desde mayo del 2006. Por su parte, WS-ReliableMessaging 1.1 está próxima a convertirse en estandar de la OASIS.
6
La “orquestación” describe la manera en que un grupo de servicios web interactúan unos con otros, incluyendo la lógica de negocios y el orden de ejecución de las interacciones, a efectos de crear un proceso de negocios “ejecutable”.
Su meta es coordinar la ocurrencia de actividades, transacciones y eventos, a través de las fronteras intraorganizacionales e interorganizacionales, conformando flujos de procesos.
En la orquestación, el proceso es siempre controlado o dirigido desde la óptica de una sola de las partes intervinientes.
Por otro lado, la “coreografía” es un concepto colaborativo, que en vez de que describir un proceso desde la óptica de una sola parte, apunta a describir el intercambio externo de mensajes entre los múltiples servicios web intervinientes, con óptica de “gran cuadro”.
El concepto de El concepto de ““orquestaciónorquestación”” y y ““coreografíacoreografía”” de Web Services de Web Services
7
El concepto de “orquestaciónEl concepto de “orquestación” ” y y ““coreografíacoreografía”” de Web Services de Web Services
(Fuente: www.webservices.org)
Orquestación
8
Business Process Execution Languaje (WS-BPEL)
Web Services Choreography Interface (WSCI)
Especificaciones para orquestar Especificaciones para orquestar y coreografiar web services y coreografiar web services
9
BPEL fue desarrollado inicialmente por IBM, Microsoft y BEA, y presentado en julio del 2002. Nace de la “fusión” de XLANG (Microsoft) y WSFL (IBM), dos especificaciones anteriores.
Basado en gramática XML, BPEL permite describir la lógica de control para coordinar servicios web que participan en un proceso de negocios. Esa gramática es interpretada y ejecutada por un “motor de orquestación”, controlado por una de las partes intervinientes en el proceso.
BPEL provee soporte tanto para procesos “abstractos” (describen el intercambio público o externo de mensajes entre las partes) como “ejecutables” (describen la conducta de las partes en una interacción o workflow privado).
Desde abril de 2007, WS-BPEL 2.0 es estándar de la OASIS, lo que puede considerarse un importante paso hacia el logro de la visión de los web services.
WS-BPELWS-BPEL
10
BPEL por dentro BPEL por dentro
Step 1
Step 2
Step 3c
Step 3b
Step 3a
Manejo de excepciones ytransacciones
Roles y Partners del
proceso
Persistencia y Container
de datos
WSDL
WSDL
Web Service
Web Service
Web Service
Web Service
invocar
invocar
recibir
recibir
responder
responder
Flujo secuencial
Flujo paralelo
(Fuente: Chris Peltz, “Web Services Orchestration”, Hewlett-Packard Company, enero 2003)
Cada proceso BPEL se expone como un web service usando WSDL
11
BPEL fue diseñado apuntando a las interacciones “sistema-a-sistema”, y en esencia no define mecanismos para interactuar con personas.
En ese sentido, IBM y SAP propusieron una extensión a BPEL denominada “BPEL4People”, cuyo objetivo es cubrir una variedad de escenarios que involucran interacciones con personas en workflows de procesos de negocios. BPEL4People se apoya en el concepto de “people activity”.
En su forma estándar, BPEL llama a una tarea humana invocando el servicio que gestiona esa tarea, mientras que el desafío de BPEL4People es la variedad de maneras en las cuales las tareas humanas se integran con los procesos BPEL.
BPEL for PeopleBPEL for People
12
Web Services Choreography Interface es una especificación desarrollada por varias firmas, entre ellas Sun y SAP.
Básicamente, WSCI describe la conducta observable de un servicio web en términos de las dependencias temporales y lógicas de los mensajes que intercambia con otros servicios, las reglas de secuenciación y el manejo de excepciones.
En otras palabras, WSCI describe y visualiza el intercambio general de mensajes entre servicios web que interactúan.
WSCI trabaja en conjunción con WSDL.
WSCIWSCI
13
Desarrollada en el ámbito de la OASIS, WS-Transaction 1.1 fue aprobada como estándar en mayo de 2007.
Básicamente proporciona un marco para coordinar de manera confiable las acciones de aplicaciones distribuidas, que involucren servicios web de distintos participantes.
WS-Transaction está integrada en realidad por un grupo de 3 especificaciones: WS-Coordination, WS-AtomicTransaction y WS-BusinessActivity.
En conjunto, estos protocolos habilitan el procesamiento de transacciones y workflows intercompañías, posibilitando que distintos sistemas operen en un ambiente heterogéneo.
Coordinación de aplicaciones Coordinación de aplicaciones distribuídas: WS-Transactiondistribuídas: WS-Transaction
14
Hacia los Web Services Hacia los Web Services dinámicosdinámicos
15
El modelo actual de web services permite la interacción de los servicios en un determinado proceso de negocios, pero dentro de una secuencia prefijada, no dinámica.
Para desplegar todo el potencial de los web services, los estándares deben apuntar a un modelo de interacciones completamente flexibles y dinámicas.
Una de las iniciativas en ese sentido es un estándar propuesto por IBM, denominado Conversation Support for Web Services (CS-WS).
Otra iniciativa es el envío al W3C del propuesto estándar WSMO (Web Services Modeling Ontology), con la finalidad última de crear un environment en el cual diferentes servicios web pueden descubrirse y cooperar entre si automáticamente.
Hacia un modelo “dinámico” Hacia un modelo “dinámico” de Web Servicesde Web Services
16
Publicada en febrero de 2004 por Microsoft, Intel y otros vendors, WS-Discovery es una especificación que define un protocolo “multicast” para el descubrimiento dinámico de servicios y dispositivos en general (por ej., impresoras).
WS-Discovery posibilita a un determinado servicio o dispositivo “anunciarle” a la red su disponibilidad y, a los restantes, “preguntarle” a la red sobre cuáles están disponibles y recibir la respuesta de aquellos que lo estén.
Este mecanismo “multicast” de WS-Discovery para localización dinámica es útil tanto en escenarios corporativos como hogareños.
WS-Discovery es un complemento de UDDI, y trabajará con otras especificaciones tales como WS-Eventing, WS-Addresing, WS-Security y WS-ReliableMessaging.
Localización dinámica de Localización dinámica de servicios: WS-Discoveryservicios: WS-Discovery
17
El estándar ebXML de OASISEl estándar ebXML de OASIS
18
ebXML es un conjunto de especificaciones para el e-business global, respaldado por oficina CEFACT (Centre for Trade Facilitation and Electronic Business) de las Naciones Unidas y el consorcio internacional OASIS.
ebXML provee un marco estándar que permite a las compañias definir y registrar sus procesos de negocios e interrelacionarse comercialmente en base a mensajes XML.
Se lo puede presentar como una alternativa al modelo de los Web Services. Sin embargo, está más enfocado al intercambio de información al estilo del “viejo” EDI (Electronic Data Interchange).
ebXML fue adoptado como estándar por la CEFACT en mayo de 2001. No hay cargos o regalias asociados a su uso.
eelectronic lectronic bbusiness usiness XMLXML
19
Proceso de negocios:La descripción de los medios por los cuales se llevan a cabo una o mas actividades durante la operación comercial de la compañía (por ej.: Proceso de Compras).
Perfil de negocios: La descripción de las capacidades y limitaciones de una compañía, asi como de sus escenarios comerciales.
Documento de negocios:Un grupo de componentes de información que se intercambian como parte de un proceso de negocios (por ej.: una Orden de Compra).
ebXML: tres conceptos básicosebXML: tres conceptos básicos
20
A la manera de ebXMLA la manera de ebXML
Compañía A
Compañía B
Repositorio ebXML
Transacciones(mensajes EbXML)
publicación publicación
Obtiene el perfil de B
Obtiene el perfil de A
Perfil de A
Perfil de B
Registro de Perfiles y Procesos de ´Negocios
Collaboration Protocol
Profile (CPP)
Collaboration Protocol
Profile (CPP)
Collaboration Protocol
Agreement (CPA)
21
La arquitectura de ebXMLLa arquitectura de ebXML
(Fuente: “Developing Web Services with ebXML and SOAP: An Overview”, www.webservices.org)
Un repositorio ebXML puede definirse y
registrarse en UDDI
22
Los servicios web están más orientados a funciones tipo input/output, sin semántica de negocios. EbXML requiere colaboración para acordar mutuamente formatos y semática de los documentos a intercambiar.
WSDL se utiliza para describir un servicio web. El CPP puede describir el mismo servicio, pero contiene más información, tal como el rol de la compañía en el contexto del servicio en particular.
La descripción de un servicio web se publica en UDDI, mientras que el CPP de una organización se publica en el repositorio ebXML, que además proporciona información sobre procesos, perfiles y documentos de negocios.
Al igual que para los servicios web, ebXML utiliza mensajería SOAP.
ebXML vs. Web Services:ebXML vs. Web Services:¿opuestos o complementarios?¿opuestos o complementarios?
23
Servicios web y ebXML se complementan, ya que los servicios web son apropiados para el intercambio de información e integración de funciones de negocios, pero no tanto para efectuar transacciones, que es el punto fuerte de ebXML.
De momento, no hay Vendors que puedan proveer una implementación completa de todas las etapas de la especificación EbXML (diseño, negociación y ejecución).
ebXML vs. Web Services:ebXML vs. Web Services:¿opuestos o complementarios?¿opuestos o complementarios?
24
ebXML tiene sus raíces conceptuales en los estándares EDI y RosettaNet (un estándar para colaboración vertical de empresas de alta tecnología).
Un factor clave para el éxito de ebXML será su adopción por parte de un amplio abanico de compañias, tanto pequeñas como grandes. Un hito importante es que las especificaciones ebXML alcanzaron la designación ISO 15000 en marzo de 2004.
El mayor interés en los proyectos ebXML parece apuntar a la implementación de mensajería entre partners, mas que a la implementación de un repositorio ebXML.
En ese sentido, una de las implementaciones exitosas de ebXML ha sido “Steel 24-7”, marketplace europeo del negocio del acero.
Las tendencias en la adopciónLas tendencias en la adopción de ebXML de ebXML
25
Desde abril del 2004, en el ámbito de la OASIS hay planes para desarrollar la denominada Electronic Business Service Oriented Architecture (EbSOA).
Este desarrollo tiene el propósito de actualizar la arquitectura técnica de ebXML, armonizándola con componentes propios del modelo de web services y de la cada vez más relevante SOA.
La visión detrás del desarrollo de ebSOA es un “set” completo de servicios modulares, más expansivo y con mayores funcionalidades que las contempladas en la arquitectura original de ebXML (cuando el término “web services” aún no había sido acuñado).
ebXML + SOA = “ebSOA”ebXML + SOA = “ebSOA”
26
Seguridad y Web ServicesSeguridad y Web Services
27
Desde el punto de vista del Proveedor del Servicio:
¿Quién está utilizando mi servicio web? ¿Lo está utilizando con mi permiso?
¿Cómo puede probar que usted es realmente quien dice ser?
Desde el punto de vista del Consumidor del Servicio:
¿De quién es el servicio web que yo utilizo? ¿Estoy autorizado
a utilizarlo?
¿Cómo puedo probar que yo soy realmente quien digo ser?
Seguridad y Web Services: Seguridad y Web Services: cuestiones fundamentalescuestiones fundamentales
28
SAML
WS-Security
Liberty Alliance
Ws-Federation
Seguridad y Web ServicesSeguridad y Web Services
29
SAML es un lenguaje, basado en XML, para el intercambio de información de autenticación y autorización. Es una iniciativa de la OASIS y en su desarrollo participaron las compañias IBM, Sun y HP, entre otras.
Su propósito es definir la manera en que diferentes sistemas pueden comunicarse entre sí datos sobre seguridad.
SAML permite el intercambio de información de autenticación y autorización entre distintos productos de software de seguridad y administracion de acceso a la web. Potencia a estándares como XML y SOAP.
SAML es estándar oficial de la OASIS desde noviembre de 2002.
SAML SAML (Security Assertion Markup Languaje)(Security Assertion Markup Languaje)
30
Anunciada en abril de 2002, WS-Security es una especificación desarrollada por Microsoft, IBM y Verisign, aunque también Sun se unió a esta iniciativa.
Básicamente, WS-Securiry define “extensiones” para SOAP, mediante headers de encriptado y firmas, para lograr un intercambio seguro de mensajes.
A fines del 2002 WS-Security se complementó con el anuncio de 6 nuevas especificaciones: WS-Trust, WS-Secure Conversation, WS-SecuriryPolicy, WS-Policy, WS-PolicyAttachment y WS-PolicyAssertions.
Aprobada como estándar por la OASIS en abril de 2004, se la considera (junto al protocolo SSL y a SAML) una de las piezas esenciales para la autenticación de las partes y la confidencialidad en los web services. La versión 1.1 está vigente desde febrero 2006.
WS-SecurityWS-Security
31
Formado en septiembre de 2001, Liberty Alliance es un consorcio global formado por importantes compañías y otras organizaciones que, con el liderazgo inicial de Sun, se nuclearon en www.projectliberty.org.
Su objetivo básico es desarrollar un estándar de identificación digital de usuario con autenticación distribuida y autorización abierta, operable desde cualquier dispositivo conectado a internet.
Liberty Alliance propone una solución “federada” para la identidad de un usuario en la Web, que posibilita un registro único y portable a través de diferentes compañías, sitios o aplicaciones autónomas, concepto que es clave para el e-commerce y los servicios basados en internet en general.
Entre las compañias que ya adoptaron las especificaciones de Liberty Alliance están American Express, Nokia, France Telecom, Hewlett-Packard y General Motors. Una lista mas extensa puede consultarse en el sitio http://projectliberty.org/liberty/adoption.
El proyecto Liberty Alliance y la El proyecto Liberty Alliance y la identidad del usuario en la Webidentidad del usuario en la Web
32
Identidad federada de Red:Identidad federada de Red:un escenario posibleun escenario posible
(Fuente: “Federated Identity: Seizing Business Opportunities by Sharing Trusted Electronic Identities”, reporte de RSA Security Inc.)
El “login” es posible desde
cualquier dispositivo
La identificación del usuario es “portable”
a través de diferentes compañías
33
A mediados del 2002, se anunció públicamente la disponibilidad de la especificación 1.0 de Liberty Alliance, lo que fue un importante paso hacia la concreción de los objetivos iniciales del proyecto.
Entre las funcionalidades que provee esa primera especificación de Liberty Alliance, están las siguientes:
Los usuarios pueden enlazar cuentas que tengan con diferentes Services Providers, formando “círculos de confianza”.
“Sign-on” simplificado de cuentas enlazadas: el usuario puede navegar en otra cuenta sin necesidad de otro “log-in”, ni reautenticarse.
“Log-out” global: si el usuario hace el “log-out” del site donde había efectuado el log-in inicial, puede automáticamente dar el log-out de todos los otros sites a los que estaba “enlazado”.
A principios del 2003, se liberó la especificación 1.1, que mejoraba la flexibilidad y clarificaba algunas ambiguedades de la versión 1.0.
La labor de Liberty AllianceLa labor de Liberty Alliance
34
A fines del 2003, Liberty anunció un programa de Certificación de interoperabilidad para aquellos productos y servicios que demuestren compatibilidad con sus especificaciones.
Por otra parte, ha publicado la versión final de sus especificaciones de “Fase 2”, que apuntan hacia el despliegue seguro de servicios web, y también ha emitido varios documentos de guia para el despliege de web services móviles.
En mayo de 2004, dió a conocer su documento Identity Web Services Framework (ID-WSF), que es una visión de cómo las compañías pueden adoptar un modelo federado de servicios web. En octubre de 2006 dió a conocer la versión 2.0 de ID-WSF.
En octubre del 2005, publicó sus “Normas Generales de Política y Empresa para el Despliegue” (Deployment Guidelines), desarrolladas como ayuda para las organizaciones en el despliegue a gran escala de soluciones de identidad federada.
La labor de Liberty AllianceLa labor de Liberty Alliance
35
La consultora Gartner predice que para el 2007, el 80 % de las organizaciones alcanzarán su “password breaking point” y necesitarán fortalecer sus métodos de autenticación de seguridad.
Un pronunciamiento similar, dado en octubre del 2005, por la US Federal Financial Institutions Examination Council (FFIEC), reconoce que las “passwords” son insuficientes como único medio de proteger online la cuenta bancaria de un cliente.
En noviembre del 2005, Liberty Alliance formó un grupo de expertos apuntado al desarrollo de especificaciones para “autenticación fuerte”, iniciativa denominada Identity Strong Authentication Framework (ID-SAFE).
La “autenticación fuerte” requiere al menos dos formas de autenticación de identidad para el acceso online. Se espera que la iniciativa ID-SAFE ofrecerá los estándares para implementar tal solución en las organizaciones.
ID-SAFE: Autenticación fuerteID-SAFE: Autenticación fuerte
36
Impulsado por Microsoft e IBM (entre otros), Web Services Federation Languaje, es una especificación con un propósito similar al de Liberty Alliance: crear un mecanismo para posibilitar la identidad federativa en la Web.
Los impulsores de WS-Federation afirman que se trata de una iniciativa de propósito más general que la de Liberty Aliance, apuntando a usuarios individuales y corporaciones.
A diferencia de las especificaciones de Liberty (que ya han sido adoptadas para aplicaciones en importantes compañías), WS-Federation está en sus primeros pasos en su camino de estándar.
Un “rival” para Liberty Alliance:Un “rival” para Liberty Alliance:WS-FederationWS-Federation
37
Web Services y Grid ServicesWeb Services y Grid Services
38
“Computación Grid” es una forma de trabajo en red que posibilita el uso compartido y coordinado de recursos computacionales heterogéneos y geográficamente dispersos, conformando agrupaciones u organizaciones “virtuales” dinámicas.
Las tecnologías Grid han evolucionando hacia la estandarización con la “Open Grid Service Arquitecture” (OGSA), iniciativa conocida a principios del 2002 y apoyada sobre estándares Web Services existentes.
OGSA es creación de la “Globus Alliance”, comunidad internacional de organizaciones e individuos avocados al desarrollo de las tecnologías “Grid”, uno de cuyos estandartes es su herramienta de software “Globus Toolkit”.
Por otro lado, en abril de 2004, se anunció la formación de la “Entreprise Grid Alliance” (EGA), comunidad formada por importantes proveedores globales, que apunta a resolver requerimientos de la implementación de entornos Grid comerciales.
¿Qué es una “Grid”?¿Qué es una “Grid”?
39
¿Qué es una “Grid”?¿Qué es una “Grid”?
(Fuente: “Fundamentals of Grid Computing”, IBM Corp., www.ibm.com/redbooks)
40
OGSA adopta una representación común para recursos computacionales (sean archivos, programas, etc). Todos son tratados como servicios (entidades que proveen capacidades a través del intercambio de mensajes).
OGSA define la semántica y los mecanismos para crear, nombrar y descubrir “Grid Services”, así como el acceso a las instanciaciones de esos servicios, a la vez que soporta integración con instalaciones de plataformas nativas.
OGSA continua su evolución en el ámbito del Global Grid Forum, una comunidad internacional en la cual participa, entre otras, la compañía IBM.
OOpen pen GGrid rid SServices ervices AArquitecturerquitecture
41
Dado un recurso que es tratado como un servicio (por ejemplo una Base de datos), una “instancia de Grid Service” es una solicitud perticular de ese servicio (por ej., la breve actividad de hacer un “query” sobre esa Base).
En la arquitectura OGSA, la creación y destrucción de instanciaciones de Grid Services es dinámica.
OGSA también también hace posible distinguir entre distintas instanciaciones dinámicas de un mismo Grid Service.
En contraste con los Web Services básicos, los Grid Services son dinámicos y “stateful”.
¿Qué son las “instancias” de ¿Qué son las “instancias” de Grid Services?Grid Services?
42
Aunque los Web Services y los Grid services existían en mundos separados, su armonización parece tornarse inevitable.
En ese sentido, ya a principios del 2004 se conocieron dos estándares “competidores”.
Uno proviene de la coalición Microsoft/BEA/TIBCO y se llama WS-Eventing. Es una especificación que permite a los web Services actuar como fuentes de eventos para “suscriptores”.
El otro proviene de la coalición IBM/HP/Globus Alliance (y otros), denominado WS-Notification junto a WS-Resource Framework (WSRF), con base en OGSA. Posibilita construir aplicaciones Grid utilizando especificaciones de Web Services.
La convergencia La convergencia Web Services - Grid ServicesWeb Services - Grid Services
43
Estándares Web Services: Estándares Web Services: conclusionesconclusiones
44
¿Cuáles son las ¿Cuáles son las especificaciones más utilizadas?especificaciones más utilizadas?
Fuente: Webservices.Org Survey 2005
• SOAP 90,8 %
• WSDL 81,6 %
• UDDI 37,5 %
• WS-Security 34,7 %
• REST (XML sobre HTTP) 32,2 %
• BPEL 28,0 %
• WS-Basic Profile 20,2 %
• WS-Reliable Messaging 12,2 %
• EbXML 12,1 %
• SAML 11,4 %
45
Finalidad. El estándar adoptado debe ayudar a integrar o interactuar con clientes, proveedores, partners o con otros sistemas propios de la compañía.
Relevancia de negocios. El estándar adoptado debe ser relevante para apuntalar la calidad del servicio y los factores críticos del negocio.
Apoyo de los Vendors. El apoyo de los grandes “Vendors” a un determinado estándar no garantiza que será adoptado por el mercado en general.
Visión, no versión. Permanecer centrado en el objetivo a lograr, evitando quedar atrapado en discusiones sobre números de versiones específicas de los estándares.
Un punto de partida. Comenzar con los mayormente adoptados (SOAP - WSDL) y apoyarse en los “Basic Profile” del WS-I.
Adoptando un estándar: Adoptando un estándar: algunas pautas básicasalgunas pautas básicas