Your SlideShare is downloading. ×
0
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Eser2 B
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Eser2 B

1,218

Published on

Published in: Business, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,218
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
10
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. E-Services Posgrado en E-Business Management Universidad del Salvador - Argentina Geogetown University - U.S.A. Período 2007 2 . Arquitectura técnica general y estándares (segunda parte)
  • 2. <ul><li>Estándares para componer transacciones y procesos </li></ul><ul><li>El estándar ebXML de la OASIS </li></ul><ul><li>La seguridad en los web services </li></ul><ul><li>El concepto de “Grid Services”. </li></ul><ul><li>Conclusiones sobre estándares de Web Services </li></ul>Agenda de temas
  • 3. <ul><li>Faltan : </li></ul><ul><li>Mecanismos para otorgar confiabilidad a la mensajería SOAP </li></ul><ul><li>Mecanismos para coordinar la interacción de múltiples web services y componer transacciones y procesos de negocios </li></ul><ul><li>Mecanismos para proveer capacidades de autenticación y autorización de las partes </li></ul>Lo que falta en el modelo de los Web Services “básicos”
  • 4. Estándares para componer procesos con Web Services
  • 5. Iniciativas para una mensajería confiable con Web Services <ul><li>WS-ReliableMessaging / WS-Addressing: </li></ul><ul><ul><li>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. </li></ul></ul><ul><ul><li>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. </li></ul></ul><ul><ul><li>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. </li></ul></ul>
  • 6. <ul><li>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”. </li></ul><ul><li>Su meta es coordinar la ocurrencia de actividades, transacciones y eventos, a través de las fronteras intraorganizacionales e interorganizacionales, conformando flujos de procesos. </li></ul><ul><li>En la orquestación , el proceso es siempre controlado o dirigido desde la óptica de una sola de las partes intervinientes . </li></ul><ul><li>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” . </li></ul>El concepto de “ orquestación ” y “ coreografía ” de Web Services
  • 7. El concepto de “orquestación ” y “ coreografía ” de Web Services (Fuente: www.webservices.org) Orquestación
  • 8. <ul><ul><li>Business Process Execution Languaje (WS-BPEL) </li></ul></ul><ul><ul><li>Web Services Choreography Interface (WSCI) </li></ul></ul>Especificaciones para orquestar y coreografiar web services
  • 9. <ul><li>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. </li></ul><ul><li>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. </li></ul><ul><li>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). </li></ul><ul><li>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. </li></ul>WS-BPEL
  • 10. BPEL por dentro Step 1 Step 2 Step 3c Step 3b Step 3a Manejo de excepciones y transacciones Roles y Partners del proceso Persistencia y Container de datos W S D L W S D L 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. <ul><li>BPEL fue diseñado apuntando a las interacciones “sistema-a-sistema”, y en esencia no define mecanismos para interactuar con personas. </li></ul><ul><li>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”. </li></ul><ul><li>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 . </li></ul>BPEL for People
  • 12. <ul><li>Web Services Choreography Interface es una especificación desarrollada por varias firmas, entre ellas Sun y SAP. </li></ul><ul><li>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. </li></ul><ul><li>En otras palabras, WSCI describe y visualiza el intercambio general de mensajes entre servicios web que interactúan. </li></ul><ul><li>WSCI trabaja en conjunción con WSDL. </li></ul>WSCI
  • 13. <ul><li>Desarrollada en el ámbito de la OASIS, WS-Transaction 1.1 fue aprobada como estándar en mayo de 2007. </li></ul><ul><li>Básicamente proporciona un marco para coordinar de manera confiable las acciones de aplicaciones distribuidas, que involucren servicios web de distintos participantes. </li></ul><ul><li>WS-Transaction está integrada en realidad por un grupo de 3 especificaciones: WS-Coordination , WS-AtomicTransaction y WS-BusinessActivity . </li></ul><ul><li>En conjunto, estos protocolos habilitan el procesamiento de transacciones y workflows intercompañías, posibilitando que distintos sistemas operen en un ambiente heterogéneo. </li></ul>Coordinación de aplicaciones distribuídas: WS-Transaction
  • 14. Hacia los Web Services dinámicos
  • 15. <ul><li>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. </li></ul><ul><li>Para desplegar todo el potencial de los web services , los estándares deben apuntar a un modelo de interacciones completamente flexibles y dinámicas . </li></ul><ul><li>Una de las iniciativas en ese sentido es un estándar propuesto por IBM, denominado Conversation Support for Web Services (CS-WS). </li></ul><ul><li>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. </li></ul>Hacia un modelo “dinámico” de Web Services
  • 16. <ul><li>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). </li></ul><ul><li>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. </li></ul><ul><li>Este mecanismo “multicast” de WS-Discovery para localización dinámica es útil tanto en escenarios corporativos como hogareños. </li></ul><ul><li>WS-Discovery es un complemento de UDDI , y trabajará con otras especificaciones tales como WS-Eventing, WS-Addresing, WS-Security y WS-ReliableMessaging. </li></ul>Localización dinámica de servicios: WS-Discovery
  • 17. El estándar ebXML de OASIS
  • 18. <ul><li>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 . </li></ul><ul><li>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. </li></ul><ul><li>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). </li></ul><ul><li>ebXML fue adoptado como estándar por la CEFACT en mayo de 2001. No hay cargos o regalias asociados a su uso. </li></ul>e lectronic b usiness XML
  • 19. <ul><li>Proceso de negocios: </li></ul><ul><li>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). </li></ul><ul><li>Perfil de negocios: </li></ul><ul><li>La descripción de las capacidades y limitaciones de una compañía, asi como de sus escenarios comerciales. </li></ul><ul><li>Documento de negocios: </li></ul><ul><li>Un grupo de componentes de información que se intercambian como parte de un proceso de negocios (por ej.: una Orden de Compra). </li></ul>ebXML: tres conceptos básicos
  • 20. A 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 ebXML (Fuente: “Developing Web Services with ebXML and SOAP: An Overview”, www.webservices.org) Un repositorio ebXML puede definirse y registrarse en UDDI
  • 22. <ul><li>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. </li></ul><ul><li>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. </li></ul><ul><li>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 . </li></ul><ul><li>Al igual que para los servicios web, ebXML utiliza mensajería SOAP. </li></ul>ebXML vs. Web Services: ¿opuestos o complementarios?
  • 23. <ul><li>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. </li></ul><ul><li>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). </li></ul>ebXML vs. Web Services: ¿opuestos o complementarios?
  • 24. <ul><li>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). </li></ul><ul><li>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. </li></ul><ul><li>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 . </li></ul><ul><li>En ese sentido, una de las implementaciones exitosas de ebXML ha sido “Steel 24-7” , marketplace europeo del negocio del acero. </li></ul>Las tendencias en la adopción de ebXML
  • 25. <ul><li>Desde abril del 2004, en el ámbito de la OASIS hay planes para desarrollar la denominada Electronic Business Service Oriented Architecture (EbSOA). </li></ul><ul><li>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 . </li></ul><ul><li>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). </li></ul>ebXML + SOA = “ebSOA”
  • 26. Seguridad y Web Services
  • 27. <ul><li>Desde el punto de vista del Proveedor del Servicio : </li></ul><ul><ul><li>¿ Quién está utilizando mi servicio web? ¿Lo está utilizando con mi permiso ? </li></ul></ul><ul><ul><li>¿Cómo puede probar que usted es realmente quien dice ser? </li></ul></ul><ul><li>Desde el punto de vista del Consumidor del Servicio : </li></ul><ul><ul><li>¿De quién es el servicio web que yo utilizo? ¿Estoy autorizado a utilizarlo? </li></ul></ul><ul><ul><li>¿Cómo puedo probar que yo soy realmente quien digo ser? </li></ul></ul>Seguridad y Web Services: cuestiones fundamentales
  • 28. <ul><li>SAML </li></ul><ul><li>WS-Security </li></ul><ul><li>Liberty Alliance </li></ul><ul><li>Ws-Federation </li></ul>Seguridad y Web Services
  • 29. <ul><li>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. </li></ul><ul><li>Su propósito es definir la manera en que diferentes sistemas pueden comunicarse entre sí datos sobre seguridad . </li></ul><ul><li>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. </li></ul><ul><li>SAML es estándar oficial de la OASIS desde noviembre de 2002. </li></ul>SAML (Security Assertion Markup Languaje)
  • 30. <ul><li>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. </li></ul><ul><li>Básicamente, WS-Securiry define “extensiones” para SOAP, mediante headers de encriptado y firmas, para lograr un intercambio seguro de mensajes. </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul>WS-Security
  • 31. El proyecto Liberty Alliance y la identidad del usuario en la Web <ul><li>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 . </li></ul><ul><li>S u 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 . </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul>
  • 32. Identidad federada de Red: un 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. La labor de Liberty Alliance <ul><li>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. </li></ul><ul><li>Entre las funcionalidades que provee esa primera especificación de Liberty Alliance, están las siguientes: </li></ul><ul><ul><ul><li>Los usuarios pueden enlazar cuentas que tengan con diferentes Services Providers, formando “círculos de confianza”. </li></ul></ul></ul><ul><ul><ul><li>“ Sign-on” simplificado de cuentas enlazadas: el usuario puede navegar en otra cuenta sin necesidad de otro “log-in”, ni reautenticarse. </li></ul></ul></ul><ul><ul><ul><li>“ 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”. </li></ul></ul></ul><ul><li>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. </li></ul>
  • 34. La labor de Liberty Alliance <ul><li>A fines del 2003, Liberty anunció un programa de C ertificación de interoperabilidad para aquellos productos y servicios que demuestren compatibilidad con sus especificaciones. </li></ul><ul><li>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 . </li></ul><ul><li>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. </li></ul><ul><li>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 . </li></ul>
  • 35. ID-SAFE: Autenticación fuerte <ul><li>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. </li></ul><ul><li>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. </li></ul><ul><li>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). </li></ul><ul><li>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. </li></ul>
  • 36. Un “rival” para Liberty Alliance: WS-Federation <ul><li>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. </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul>
  • 37. Web Services y Grid Services
  • 38. ¿Qué es una “Grid”? <ul><li>“ 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. </li></ul><ul><li>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. </li></ul><ul><li>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 ”. </li></ul><ul><li>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. </li></ul>
  • 39. ¿Qué es una “Grid”? (Fuente: “Fundamentals of Grid Computing”, IBM Corp., www.ibm.com/redbooks)
  • 40. O pen G rid S ervices A rquitecture <ul><li>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). </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul>
  • 41. ¿Qué son las “instancias” de Grid Services? <ul><li>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). </li></ul><ul><li>En la arquitectura OGSA, la creación y destrucción de instanciaciones de Grid Services es dinámica. </li></ul><ul><li>OGSA también también hace posible distinguir entre distintas instanciaciones dinámicas de un mismo Grid Service. </li></ul><ul><li>En contraste con los Web Services básicos, los Grid Services son dinámicos y “stateful”. </li></ul>
  • 42. La convergencia Web Services - Grid Services <ul><li>Aunque los Web Services y los Grid services existían en mundos separados, su armonización parece tornarse inevitable. </li></ul><ul><li>En ese sentido, ya a principios del 2004 se conocieron dos estándares “competidores”. </li></ul><ul><li>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”. </li></ul><ul><li>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. </li></ul>
  • 43. Estándares Web Services: conclusiones
  • 44. ¿Cuáles son las especificaciones más utilizadas? Fuente: Webservices.Org Survey 2005 <ul><li>SOAP 90,8 % </li></ul><ul><li>WSDL 81,6 % </li></ul><ul><li>UDDI 37,5 % </li></ul><ul><li>WS-Security 34 ,7 % </li></ul><ul><li>REST (XML sobre HTTP) 32,2 % </li></ul><ul><li>BPEL 28,0 % </li></ul><ul><li>WS-Basic Profile 20,2 % </li></ul><ul><li>WS-Reliable Messaging 12,2 % </li></ul><ul><li>EbXML 12,1 % </li></ul><ul><li>SAML 11,4 % </li></ul>
  • 45. <ul><li>Finalidad. El estándar adoptado debe ayudar a integrar o interactuar con clientes, proveedores, partners o con otros sistemas propios de la compañía . </li></ul><ul><li>Relevancia de negocios. El estándar adoptado debe ser relevante para apuntalar la calidad del servicio y los factores críticos del negocio. </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul><ul><li>Un punto de partida . Comenzar con los mayormente adoptados (SOAP - WSDL) y apoyarse en los “Basic Profile” del WS-I. </li></ul>Adoptando un estándar: algunas pautas básicas

×