1. El Futuro de los Servicios Web
Mesa Redonda en JSWEB 2005
Granada, Septiembre 2005
Antonio Vallecillo – Universidad de Málaga
2. Antes del Futuro, el Presente
• ¿Sabemos qué son los servicios web?
• ¿Entendemos para qué sirven?
• ¿Quién los usa?
• ¿Para qué se están usando?
Fuentes:
• Revistas especializadas (cientificas y divulgativas)
• Pags web de los principales desarrolladores de software
• Listas de distribución (nacional e internacionales)
(Ultimos 3-5 meses)
3. 1) ¿Sabemos qué son los Servicios Web?
• Aun se discute sobre su verdadera identidad
– ¿Cuál es su definición exacta?
– ¿Cuál es su relación con otros conceptos como objeto,
componente software, o servicio?
– ¿Es necesario usar SOAP? ¿Y si uso ASN.1? ¿e IIOP?
• Hasta el W3C cambió el año pasado su definición
"A Web service is a software system designed to support interoperable
machine-to-machine interaction over a network. It has an interface described
in a machine-processable format (specifically WSDL). Other systems interact
with the Web service in a manner prescribed by its description using SOAP-
messages, typically conveyed using HTTP with an XML serialization in
conjunction with other Web-related standards."
http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/
• Otros vendedores proponen definiciones alternativas!
4. 2) ¿Entendemos para qué sirven?
• En teoría, los Servicios Web proporcionan una
tecnología para “soportar las interacciones entre
máquinas en una red” (definición de W3C)
• Otros opinan que sirven fundamentalmente para
implementar SOA
• Otros opinan que sirven para desarrollar
aplicaciones distribuidas en general, mejorando y
reemplazando a las tecnologías anteriores (CORBA)
5. 2) ¿Entendemos para qué sirven? (II)
• Sí, los Servicios proporcionan una tecnología muy
válida para describir servicios e invocarlos a través de
Internet, logrando ubicuidad e interoperabilidad.
• Pero...
– Es que no son seguros...
– Es que no tienen estado...
– Es que no tienen resueltos temas básicos como los attachments o las
transacciones...
– Es que sólo describen la signatura de sus operaciones, pero no su
semántica (coreografía, significado, ...)
– Es que son ineficientes en cuanto a prestaciones (no puedo hacer
computación científica distribuida!)
– Es que no puedo aplicarles fácilmente “aspectos” (login, ...)
– ....
– Es que no me dejan la ropa muy blanca
– Es que no me llevan los niños al colegio
¿Realmente entendemos para qué sirven y para qué no?
6. 3) ¿Quién los usa?
• Las compañias de desarrollo software
– IBM, Sun, Microsoft, Oracle, ...todas hacen ahora Servicios Web
– Es muy curioso ver ahora sus paginas web sobre estos temas
• Las organizaciones de estandarización (W3C,...)
• Los grupos de investigación
– Revistas especializadas, Listas de Distribución, Charlas,
Congresos ;-), …
• Las compañías de negocio
– Financial (VISA, AMEX),
– Travel agencies (TerminalA),
– E-shops (Amazon),
– Document handling (Adobe)
7. 4) ¿Para qué se usan?
• Las compañias de desarrollo software (IBM, Sun, MS, ...)
– Ahora todo son Servicios Web!
• Los grupos de investigación
– Vuelven a atacar los problemas difíciles “de siempre”: la
semántica, la QoS, context-awareness, adaptación dinámica,...
– Incluso tienen que volver a resolver otros ya resueltos:
transacciones, mensajería fiable, trading, addressing, ...
– “WS+aspectos”, “Modelado de WS”...
– ¿Veremos pronto ”Genetic WS”? ¿Y que tal ”Fuzzy WS”? :-)
• Las organizaciones de estandarización (ISO, W3C,...)
– Tienen más cosas que estandarizar, en un nuevo contexto
8. 4) ¿Para qué se usan? (II)
• Las compañías de negocio
– Posiblemente, los mayores beneficiados de esta historia!
– Pueden vender “servicios”, algo que no habian logrado con la
programación estructurada, los objetos, los componentes,…
• Sin embargo...
– Las cifras de uso de Internet no acompañan todavía
– Ojo con la “guerra de estándares”, que puede dañar mucho las
inversiones e ilusiones de muchas empresas privadas
• WS-CDL vs. BPEL4WS (una vez que WSCI ha muerto)
• WS-Coordination y WS-Transaction vs. WS-CF y WS-CAF
• WS-Reliability vs. WS-ReliableMessaging
• OWL-S vs. WSMO vs. SWSL
• SOAP vs. ASN.1 vs. IIOP vs. RSS/Atom vs. ....
• ...
9. Algunos comentarios que se han hecho
• “Los servicios Web no hacen más que reinventar la rueda, pero
esta vez usando XML”
• “No aportan nada nuevo que no tuvieramos ya en CORBA”
• “Los Servicios Web proporcionan las facilidades del Nivel 4 por
encima del Nivel 7, dando un paso atrás tanto en eficiencia como
en funcionalidad (seguridad, mensajería fiable, etc.)”
• “Los servicios Web no permiten resolver ninguno de los problemas
realmente difíciles de los sistemas distribuidos, como la
interoperabilidad semántica, los repartos de cargas, la fiabilidad, o
la escalabilidad”
• “Cómo RSS/Atom va a reemplazar a los Servicios Web”
• “Los servicios Web van a suponer un cambio radical en la forma en
la que construimos aplicaciones distribuidas hoy en día”
• “Managing IT with Web Services” (ACMqueue, Jul/Ago 2005)
10. El Futuro de los Servicios Web
Mesa Redonda en JSWEB 2005
Granada, Septiembre 2005
Antonio Vallecillo – Universidad de Málaga
11. Destornilladores
El Futuro de los Servicios Web
Mesa Redonda en DSWEB 1005
Granada, Septiembre 1005
Antonio Vallecillo – Universidad de Málaga
12. Algunos comentarios que se han hecho
• “Los servicios Web no hacen más que reinventar la rueda, pero
esta vez usando XML”
– “Los destornilladores no hacen más que reinventar la
rueda, pero esta vez usando tornillos en vez de clavos”
• “No aportan nada nuevo que no tuvieramos ya en CORBA”
– “No aportan nada nuevo que no tuvieramos ya con los
martillos y las puntas”
• “Los Servicios Web proporcionan las facilidades del Nivel 4 por
encima del Nivel 7, dando un paso atrás tanto en eficiencia
como en funcionalidad (seguridad, mensajería fiable, etc.)”
– A la hora de clavar puntas, los destornilladores suponen
un paso atrás tanto en eficiencia como en funcionalidad
13. Más comentarios que se han hecho
• “Los servicios Web no permiten resolver ninguno de los
problemas realmente difíciles de los sistemas distribuidos, como
la interoperabilidad semántica, los repartos de cargas, la
fiabilidad, o la escalabilidad”
– Los destornilladores no permiten resolver ninguno de los
problemas realmente difíciles de las catedrales, como la
seguridad, estabilidad, cimentación, …
• “Cómo RSS/Atom va a reemplazar a los Servicios Web”
– Cómo los alicates van a reemplazar a los destornilladores
14. Más comentarios que se han hecho
• “Los servicios Web van a suponer un cambio radical en la
forma en la que construimos aplicaciones distribuidas hoy en
día”
– Los destornilladores van a suponer un cambio radical en la
forma en la que construimos catedrales hoy en día.
• “Managing IT with Web Services”
– La gestión de las Catedrales con destornilladores
15. Conclusiones
• Los Servicios Web están aquí...
– Y han venido para quedarse!
• Aunque no van a arreglar todos los problemas de las
aplicaciones distribuidas
– Pero aportan soluciones válidas a ciertos problemas importantes,
como la ubicuidad (pervasiveness) y la interoperabilidad
– Posibilitan las arquitecturas SOA y P2P
• Su objetivo no es sustituir a las tecnologías existentes,
sino complementarlas
– “Note, however, that all this does not mean that your CORBA objects
and EJBs have suddenly become superfluous. On the contrary: they
supply the implementations for your web services. Without them, you
have no web services” [Steve Vinoski]
– “A robust public marketplace for components hasn’t emerged. Web
Services represent a new revenue stream essential for the future health
of the [hardware and software] business” [Grady Booch]
16. Algunos trabajos que hacer
• A corto plazo
– Terminar de definir su identidad
– Perfilar su campo de aplicación (encontrar su “nicho”)
– Completar los “flecos” que aun presentan (y que tiene
sentido solucionar en un tiempo razonable!)
– Aclarar el campo al inversor, tratando de eliminar la “guerra
de estandares” que tanto daño hace a los inversores
• Futuro...¿?
18. Algunos “flecos” todavía sueltos
• Mensajería fiable
• Seguridad
• Acuerdos en cuanto a estándares para transacciones y coreografía
• Asincronía, latencia, fragmentación, transparencia frente a fallos
en nodos y comunicaciones, degradación de prestaciones, poca
escalabilidad (cuellos de botella)... Vamos, los problemas propios
de los sistemas distribuidos
• ¿Interoperabilidad semántica?
• ¿Contratos?
• ¿Calidad de servicio? (definición, monitorización,...)
• ¿Métricas de calidad?
• ¿Negociación automática?
• ¿Tarificación? (licencias, acuerdos de uso, re-venta, etc.)
• ¿Legislación?
• Marketing: ¿Es el software un producto, o un servicio?
19. Cifras uso de Internet (Agosto 2005)
Españ Europ
% Empresas...
a a
...que compran a través de
9% 32%
Internet
...que venden a través de Internet 2% 11%
20. Objetos, Componentes y Servicios Web
Objetos Componentes Servicios Web
Perspectiva Elementos internos Elementos internos de un Elementos que se ven
arquitectónica de un componente sistema desde fuera del sistema
Modelo de Junto con la Despliegue “físico” El software “existe” en
despliegue aplicación o el (install-and-use) algún lado
componente (connect-and-use)
Niveles de Mayoritariamente Mayoritariamente dentro Mayoritariamente entre
intercambio de dentro de un de la empresa varias empresas
información componente software
Niveles de Fuerte Débil Muy débil
acoplamiento
Comunicación Directa Middleware Web-based
(eg. IIOP) (SOAP/XML sobre http)
Granularidad Pequeña Media-grande Media-grande
Notas del editor
Decir que esto se basa en las pags web de los mayores “jugadores” de los servicios web (IBM, Sun, MS, ...), las revistas especializadas sobre estos temas, y las listas de distribución
En el 2002, la W3C dijo que un Servicio Web era: “A software application identified by an URI, whose interfaces and binding are capable of being identified, described and discovered by XML artifacts and supports direct interactions with other software applications using XML based messages via Internet-based protocols” Eso dejaba la puerta abierta a un monton de posibilidades, pues lo unico que fijaba era que de deberia usar XML como lenguaje para describir cosas, y que cualquier protocolo para Interner valía. Fantastico! Yo me alegre mucho, porque permitia un monton de combinaciones (independientemente de que al final todo el mundo usara WSDL para describir servicios, SOAP sobre http para invocarlos, etc.) Pero por ejemplo, permitia definir en un momento bridges entre Web services con CORBA/IOOP, etc. Haciendo uso de su costumbre de desdecirse y cambiar sus estandares el primer miercoles de cada mes, el WS Architecture group cambio hace poco la definicion, y ahora un servicio Web es: "A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards." http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/ La W3C tambien ha definido lo que es un "servicio": A service is an abstract resource that represents a capability of performing tasks that represents a coherent functionality from the point of view of provider entities and requester entities. To be used, a service must be realized by a concrete provider agent. Con esto, hasta la siguiente version de la definicion (el proximo primer miercoles de mes :-), hace falta describir los WS con WDSL, e interactuar con ellos usando SOAP. El uso de HTTP y serializacion de XML no es (todavia) imprescindible. De todas formas, mi experiencia con W3C es que cambian con demasiada frecuencia sus bases y conceptos fundamentales, dependiendo de las tendencias del mercado, o del exito de sus estandares (por ejemplo, WSCI duro menos que el programa del Gran Wyoming en la 1 -- siento que el chiste no sea comprensible para los que no ven la tele en España). Lo que si es cierto es que hay una gran actividad, especialmente en la OMG para definir bridges de interoperabilidad entre sus estandares y los de W3C. Por ejemplo, estan ya definidos los siguientes documentos en la OMG: formal/05-02-01: CORBA to WSDL/SOAP formal/03-11-02: CORBA to WSDL/SOAP Interworking Specification How RSS/Atom Is Replacing Web Services
WS-Reliability vs WS-ReliableMessaging WS-Coordination y WS-Transaction vs. WS-CF y WS-CAF WS-CDL vs. BPEL4WS (una vez que WSCI ha muerto) Los Fast Web Services de Sun usan mensajes codificados con ASN1 en vez de SOAPComo he comentado en alguna ocasión, en el ambito del proyecto morfeo http://www.morfeo-project.org se ha desarrollado un contendor capaz de, dado un servicio definido en WSDL, acceder al mismo vía IIOP.
Portada de la revista ACM queue , Jul 2005 (“architecting tomorrow’s computing”)