Publicado un nuevo número del podcast de JavaHispano. En este número realizaremos una introducción a Arquitectura SOA y una introducción de Servicios Web concretando en SOAP y REST. En esta tertulia colaborarán Julio Cesar Perez autor del blog http://jcesarperez.blogspot.com/, Leonardo de Seta autor de http://www.dosideas.com, Alfredo Casado y Jorge Rubira.
Durante la entrevista hablaremos de buenas prácticas de diseño de Servicios Web y problemas que nos podemos encontrar en el proceso de integración. Además hablaremos de librerías y frameworks para desarrollo de estos tipos de Servicios Web.
Links de interés:
Al margén del tema principal del podcast y a proposito de la introducción, os invitamos a ver el siguiente divertido video promocional titulado "Si los programadores construyesen aviones".
Etiquetas: j2ee, Arquitectura, soa, servicios, web, soap, rest
Hola,
He detectado cierto sesgo hacia SOAP en contra de REST :-P Bueno, sólo hacer algunos comentarios.
Los servicios SOAP / wsdl prometieron ciertas cosas hace muchos años que han tardado mucho en conseguir (o no han conseguido realmente) y REST ha sido una respuesta racional.
Una de las promesas era la interoperabilidad de plataformas. Ello no se ha conseguido hasta que surgió el consorcio WS-I [1] con sus perfiles asociados (creo que deberíais haber hablado al respecto).
Otra de las promesas que se hacía con respecto a los WSDL y a los registros UDDI era la posibilidad de descubrimiento y generación de workflows automáticos. Yo he tenido la posibilidad de trabajar en proyectos de investigación relacionados con este objetivo y creo que no ha habido mucho éxito...
El WSDL al final "sólo" proporciona una manera de publicar signaturas y la orquestación de los servicios tiene que seguir haciéndose de manera muy manual (poco automatizable).
El sobre SOAP al final no se ha usado más que como contenedor del mensaje de negocio sin que las cabeceras proporcionen un valor añadido real. Todo lo que se sale de lo más típico tampoco está estandarizado con lo que yo pogo en duda la utilidad de SOAP...
Otro de los problemas de estos servicios es su coste. Sí que habéis comentado más o menos en profundidad su coste espacial pero creo que no habéis enfatizado el problema de su coste en rendimiento: para muchos servicios se está usando una proporción de tiempo mayor para parsear y generar los documentos XML que lo que tarda la operación de lógica de negocio, lo cual no parece razonable.
Puesto que al final la orquestación de los workflows la tiene que generar una mente humana, quizá toda la meta-información asociada a los servicios SOAP (que los hacen más costosos) no aporta tanto beneficio como el perjuicio en eficiencia que introduce. Orquestar servicios REST tendrá el mismo coste de análisis humano aunque la documentación no esté tan formalizada, pero aportará un mayor rendimiento.
Yo soy un convencido que en informática la respuesta a todo es "depende", pero es que me daba la sensación que transmitíais la idea de que SOAP era la solución profesional y REST la solución fácil y por eso hacía estos comentarios.
Por cierto la gran mayoría (creo que todos, pero no me atrevo a afirmarlo) de Google son REST y Amazon también migró hacia este modelo. Teniendo en cuenta que son algunos de los proveedores de Internet que más servicios web brindan, será por algo :-P (vale, acepto que para estos proveedores reducir el ancho de banda necesario es una prioridad, pero tampoco nadie se atreve a poner en duda que su modelo tecnológico funciona).
Un saludo,
Iván
[1] http://www.ws-i.org/
Estoy totalmente de acuerdo con ivanator. Nunca he apostado por SOAP, ni por XML, aunque sea una tecnología que se use y sea "cuasi-impuesta", me ha parecido siempre una forma de hacer las cosas poco prácticas. Se decía, entre muchas otras promesas, que debía ser leido por humanos, pero cuando un XML se vuelve algo complejo es muy dificil seguirlo sin contar con la complejidad de los analizadores. Se ha invertido mucho tiempo y dinero en todo lo que ha girado alrededor de XML y SOAP, pero han surgido soluciones, como por ejemplo JSON (REST para servicios), más sencillas y fáciles de leer tanto por humanos como por computadores, con una sintáxis más próxima a los lenguajes de programación actuales y con mucha menos sobre carga.
Creo que poco a poco se irán imponiendo frente a soluciones XML en general.
Siento que nos hayamos explicado tan mal en el podcast y que no os haya gustado. Pero en ningún momento hemos pretendido decir que SOAP es mejor que REST, ni al revés. SOAP y REST son 2 soluciones para un mismo problema, la integración de sistemas.
En mi opinión, SOAP encaja mejor en soluciones con un alcance de grande a enorme, tanto en número de servicios/operaciones, número de aplicaciones cliente, número de equipos de desarrollo implicados y complejidad de mensajes. Por supuesto también implica una curva de aprendizaje más elevada. A cambio ofrece una verdadera manera formal, estandar y automatizable de hacer las cosas. En mi experiencia, ésto no tiene precio.
@ivanator: El WSDL al final "sólo" proporciona una manera de publicar signaturas y la orquestación de los servicios tiene que seguir haciéndose de manera muy manual (poco automatizable)
Aquí discrepo yo contigo, y tranquilo que no me lo tomo como un ataque ni nada. Lo mejor de haber participado en el podcast fue tener un debate sano sobre tecnología.
Aunque no termino de pillar el sentido que le quieres dar a "sólo". Sin un lenguaje formal que defina el interfaz de un servicio no es posible ningún tipo de automatización y volvemos al pasado, donde ya se hacía integración con http, smtp, ftp, etc. Y no estoy hablando de orquestación, sólo de algo tan sencillo como validar mensajes o construir clientes en 2 clicks. Respecto a la orquestación, no es problema del WSDL, sino de las herramientas con las que tengas que orquestar. De todas formas, no sé cuando participarias en ese proyecto de investigación, pero en el cliente donde trabajo tienen montado una SOA con un ESB (Microsoft) por donde pasan decenas de miles de mensajes al día. Así que ciencia-ficción no es.
Sólo añadir que yo sí veo al WSDL como ese paso hacia lo que tu llamas"profesional". De hecho REST lo está copiando con su WADL. Y por ahí está el camino, sin duda para mi, para servicios con mensajes complejos y que soluciona muchos problemas entre los equipos de desarrollo. Lo siguiente será un estándar de seguridad más allá del https...
Lo de Amazon y Google, no es la primera vez que lo oigo, pero para mi es la gran prueba de que hasta los grandes se equivocan ¿Hace 4 años, llamar a un servicio web SOAP desde javascript en el cliente final para hacer una busqueda? Y sobretodo cuando podias hacer lo mismo con un get de http y luego parsear el html resultante... No creo que el problema estuviera en que Google quisiera mejorar el rendimiento de los servicios, sino en facilitar el uso desde el cliente.
Pero ya lo comentamos en el podcast, para servicios públicos sencillos, diseñados que vayan a ser ejecutados directamente en el navegador del cliente lo mejor hoy en dia es REST. Pero además que no tiene competencia, vamos SOAP no lo es ni lo será nunca. La única competencia en Java seria un servlet a pelo o, quizás, DWR.
Y que conste, a mi me gusta REST, le encuentro su utilidad y su hueco legítimo. Eso sí, observo muchos fanáticos y mucho más hype detrás para lo que es: una convención a la hora de usar http para hacer CRUD de recursos. No digo que tu lo seas.
@Anónimo: ¿De verdad alguna vez has comparado un XML de más de 20 lineas con un nivel de profundidad de 3 con su equivalente a JSON? Porque yo estoy cansado de hacerlo, en uno de los proyectos que llevo ahora mismo tenemos que llamar a servicios web SOAP y luego pasar al cliente practicamente la misma respuesta pero en JSON, y cuando tenemos un problema nos dejamos los ojos en el Firebug para descifrar el codigo JSON. Un ejemplo muy sencillito (7 líneas) en la wikipedia, apartado ejemplo de JSON. Imaginate un mensaje de +100 líneas, como los hay miles en cualquier SOA. Aun así lo bueno de REST es que puedes usar uno u otro, a tu gusto.
Para mí tampoco es un ataque (ni pretendía serlo mi mensaje tampoco) :-P Y no digo que no me haya gustado, digo que quizá habia cierta simpatía hacia SOAP :-P (de buen rollito :-D)
Yo también tengo bastante experiencia en integración de sistemas con servicios web. Me tiré tres años trabajando en un proyecto nacional que conectaba laboratorios científicos del mundo de la biotecnología, la genómica y la proteómica y nuestros queridos servicios SOAP nos dieron más problemas que alegrías :-P Como comentabais, se sufría todavía demasiado para integrar servicios generados en diferentes tecnologías aunque todos tuvieran sus bonitos wsdl's. A la hora de la verdad SOAP daba demasiadas posibilidades de formato (Document / Literal, RPC / Encoded y otras combinaciones más exóticas) con los que los servicios Perl se peleaban con los servicios Java y todos entre sí. Los perfiles WS-I pusieron cierto orden, pero desgraciadamente sigue habiendo por ahí mucho RPC/Encoded que machaca la tan querida integración (o te toca reimplementar una buena parte).
Discrepo en que no se pueda hacer un proyecto complejo en REST. Es otro modelo. Permite definir un sistema de navegación por los recursos que puede ser mucho más útil que SOAP en según qué proyectos.
Por supuesto que no es ciencia ficción que haya sistemas donde el throughput de servicios puede ser bestial. Nosotros lo conseguimos a nivel nacional y es un proyecto que está en pleno funcionamiento, pero también provocó una serie de problemas que comentaba y lo más triste, era que fallara en gestionar bien la integración cuando se supone que se crearon para eso.
Otro problema que era muy imporante para nosotros era que el tamaño de los mensajes era mucho más grande de lo normal y era bastante fácil reventar la memoria de los servidores al generar o parsear los mensajes y cuando conseguíamos generarlos su tamaño era descomunal para funcionar encima del protocolo HTTP... Cuando empezamos a enviar datos binarios para resolver algunos de estos problemas de tamaño también sufrimos bastante con este tema... ¿Comprimir los XML? Bueno, aunque quizá luego tengas más problemas de integración...
Que REST está copiando el WSDL... Bueno, habrá gente que querrá construir cosas alrededor, pero para mí REST es otra aproximación y no debe intentar seguir el camino de SOAP. Su gracia es su sencillez.
Seguro que SOAP aguantará muchos años (también estoy de acuerdo que hay volcados muchos intereses) y tampoco yo soy un talibán que quiera destruirlos :-P, aunque yo sigo pensando que muchas de las promesas que se oían en el pasado, no las ha satisfecho satisfactoriamente. Supongo que todo evolucionará.
Temas con los que sufrimos nosotros con SOAP (y no digo que REST los solucione):
- mensajes grandes (crear algún tipo de protocolo de streaming para mensajes webservices?)
- necesidad de asincronía (entiendo que esto ya es más bien un tema de arquitectura): tuvimos que implementar un protocolo propio
- problemas de integración de plataformas diferentes hasta que migramos a WS-I
Bueno, pues por el momento no se me ocurre más :-P
Un saludo!
Iván
Por cierto, que lo de las comillas en el "sólo" era un punto a favor de SOAP ;-) Publicar una interfaz es MUCHO aunque el WSDL quería ofrecer más que eso. Yo había leído artículos que prometían la aparición de potentes herramientas que gracias a los WSDL y UDDI podrían construir workflows de manera automática en función de los datos de origen que proporcionaba el usuario y los datos finales que pretendía obtener... Aún estoy esperando esas herramientas, aunque bueno, en el último año me he alejado un poco del tema webservices y quizá haya novedades revolucionarias :-P
Un saludo,
Iván
Ah! Y otro cosa, por si no quedaba claro, felicitaros por el esfuerzo de hacer el podcast para compartir vuestras experiencias y conocimiento. Yo personalmente valoro mucho este tipo de esfuerzos altruistas.
Mis mensajes sólo pretendían aportar otro punto de vista; como no podía participar en el podcast, me quedan estos comentarios para patalear.
De verdad, espero que no os lo hayáis tomado en absoluto como un ataque y, sí que me ha gustado el podcast, sólo que yo no tengo una opinión tan formada como vosotros en algunos temas y quería opinar :-P
Un saludo y felicidades de nuevo,
Iván
¡Así me gusta!, que cunda el buen rollito :).
Ivanator yo lo habia entendido como comentas, poner una aportación para complementar el podcast, ya que puede que tu experiencia sea otra y está bién ver otros puntos de vista.
Aun así, en resumen, creo que sobre temas de integración, Julio, Leonardo y Alfredo han dado con la clave en el podcast. Gran parte del problema, está en ponerse de acuerdo grupos de trabajo dispersos, y para ello lo importante más que la tecnología son las personas. Estas deben ser meticulosas en la elaboración del interface o contrato y deben ser también meticulosas en la lectura e interpretación de esta documentación. Desde mi punto de vista, da igual que tengas un WSDL o no, si eres desordenado y no piensas en que lo que vas a crear lo van a utilizar otras personas, la montarás "gorda" de todos modos (provocando molestias a los otros grupos de trabajo).
Saludos, Jorge
@ivanator: ok! No me sentí atacado ni nada, sólo decepcionado por si no habiamos cumplido tus expectativas.
Lo cierto es que hace 3+ años, SOAP estaba muy verde. A mi tb me tocó sufrir esos inicios integrando Axis1 con BEA! Me suena que de esto ya hemos hablado, no? Yo tb he sufrido problemas de rendimiento, bugs, adjuntos, usar RPC en lugar de Document e incluso simples arrays! Desde luego con PERL debio ser un infierno.
Por eso insistí tanto en usar el modelo Contract-First. Cuando tu tienes el control del interfaz, los cambios no son traumaticos y mi consejo es hacerlo lo mas sencillo posible, usando siempre strings como tipo de dato o int. Dejar la generación en manos de una herramienta es un suicidio y mas si, como bien dices, no cumple con el perfil basico de WS-I.
La verdad que habria sido muy interesante contar con tu presencia.
Y ya para todos, lo mejor es analizar, documentarse, pensar con calma y hacer las pruebas necesarias antes de elegir una tecnologia.
El podcast me parecio genial. Realmente estuvo muy "clara y concisa" la explicacion de la aplicacion de los mismos, tanto soap como rest, dejando bien claro tambien el concepto de soa. Como para dejar una opinion al respecto de estos conceptos, esta muy bueno que sea un estandar de integracion de sistemas, cosa que se pueda exponer una fachada de servicios sin importar la implementacion, como lo hace IDL con corba, pero de forma mas amigable y accesible. Coincido que soap esta avanzadisimo hoy dia, en su momento de axis a .net WS no te conectaba de una, habia que tocar varias cosas en parametros de headers y afines, lo cual hacia que esta integracion simple no lo sea. Pero hoy dia estan muy bien documentado e integrado y eso da ventajas de desarrollo indefectiblemente.
Algo que me gustaria exponer, es que los WS tanto soap o rest, sirven cuando son necesarios, ponerlos en el medio de un sistema, cuando no es necesaria la intancia remota por ejemplo, es bastante tedioso, en tiempos y performance. Y siguiendo por el tema performance, muchos hoy dias piensan que se soluciona con "memoria y fierros" pero sinceramente el parseo de texto mas serializacion/deserializacion es carisimo en sistemas altamente concurrentes.
Siempre que se pasa por otro protocolo, sea cual fuere, todo recae en el concepto de overhead, y siempre va a ser mas lento.
Un profesor en la UNI una vez nos comento el concepto KISS (Keep it simple stupid!) muy famoso en ingenieria, y la verdad que expone el concepto de no complicar las cosas por complicar.
Por eso coincido con la gente que participo en este podcast, en cuanto al contenido en general, y las realidades que van mas alla del Hola Mundo en SOA.
SOA es un estandar genial, cuando es necesario utilizarlo, y como bien se menciono, requiere un analisis adecuado para implementarlo.
Saludos y sigan asi
Juan Holder
Hola a todos y primero felicitaros por el podcast.
Pero quería dar mi opinión sobre todo ésto:
1º Distinguir entre "Integración de aplicaciones" y SOA
SOA es un paso más en la integración de aplicaciones. La integración de aplicaciones es la comunicación entre distintas aplicaciones mediante servicios. Que como ya habeis comentado en el podcast, se ha hecho toda la vida, mediante:Intercambio de ficheros FTP, enviando streams de datos por un socket, etc.Y ahora "lo moderno" es usar SOAP. Perdon, SOAP "era" lo moderno, lo moderno ahora es "REST". :-) Pero la filosofía sigue siendo la misma de integrar distintas aplicaciones llamando a los servicios que ofrecen dichas aplicaciones.
Un ejemplo son las aplicaciones de Ventas y Stock que es necesario integrar para que cuando se haga una venta se elimine del stock.
En una arquitectura SOA, ya no hay aplicaciones que integrar , lo que hay es una serie de servicios que SON INDEPENDIENTES de las aplicaciones. Y sobre dichos servicios alguien crea una aplicación.
El ejemplo anterior mediante SOA implicaría que se hacen una serie de Servicios de Ventas y otra serie de Servicios de Stock. Una vez realizados se hace una aplicación para el usuario que realiza ventas. Dicha aplicación llamará a los Servicios de Ventas y a los Servicios de Stock. Como es natural la aplicación de ventas llamará a más Servicios de Ventas que a servicios de Stock por eso la llamaremos la aplicación de ventas. Pero no hay una relación directa entre los servicios de ventas y la aplicación de ventas. Lo mismo se puede aplicar a los Servicios de Stock y a la aplicación de Stock.
Un diagrama que mas o menos lo explica es el siguiente:
2º REST vs XML Simple.
Me ha dado la impresión de que REST es como enviar un XML de forma sencilla en contraposición a la complejidad de SOAP. REST tiene una serie de reglas que deberemos de seguir, sobre todo en la URLs y el uso de métodos GET,POST, etc. Si lo que queremos es enviar un simple XML y que nos retorne otro XML eso no es REST. Y mirando un poco en la wikipedia he descubierto que eso se llama "POX/HTTP" (Plain Old XML over HTTP).
3º El WSDL es una pequeña solución
Le habéis dado mucha importancia al contrato que especifica WSDL, pero como ha dicho @ivanator eso es solo el principio del contrato del servicio. Luego está todo lo relativo a la semantica de todos los datos. Y eso es mucho mas complejo de implementar que crear el WSDL.Y ahí si que te toca tirar de documento Word para especificar lo que está permitido o no.
4º SOAP orientado a documentos.
Habeis dado mucha importancia a la comunicación SOAP estilo RPC. Y parece que llamar a un servicio es como llamar a un método Java remoto en el que cada dato es un parámetro del método (estilo RMI). Pero se puede usar un estilo orientado a documentos en el que se envía un documento XML en el que el consumidor del servicio es el encargado directamente de analizarlo. El usar SOAP orientado a documentos tiene las siguientes ventajas:
a) Se puede ampliar la funcionalidad del servicio sin perder la compatibilidad simplemente añadiendo mas tag (siempre y cuando sea optativos)
b) Evitar los problemas de incompatibilidad debido a Arrays, estructuras, etc que generan automáticamente los IDEs.
c) Facilidad en llamadas del tipo "Coarse-grained" ya que puedes definirte el XML todo lo complejo que necesites y sin perder la compatibilidad
d) Es fácil implementar llamadas masivas simplemente permitiendo la repetición de los datos.
¿Que desventaja veo en SOAP estilo documento? Que hay que analizar mas o menos a mano el XML y ahora es muy cómodo que el IDE te de ya la información "masticadita" como dato Java y sin mover un dedo.
5. Un servicio es sin estado.
¿Porque un servicio no puede tener estado? Y realmente si que tiene estado ya que de no tenerlo siempre retornaría los mismo valores. Lo que creo que queríais decir es que el servicio no debe guardar su estado en el servidor de aplicaciones. Y esa restricción solo la veo útil por temas de escalabilidad. Y personalmente veo mucho mas cómodo tener servicios con estado.
Con respecto al estado, hoy por hoy ninguna implementación de servicios nos da una solución estandarizada. Cuando necesitas guardar información de estado tienes que crearte un protocolo a medida para gestionar el concepto de "sesión" e identificar al cliente.
Una solucion habitual consiste en el intercambio de un token identificativo a lo largo de toda la conversación, pero, como decía, es una solución adhoc que "ensucia" la signatura del servicio con un concepto que no forma parte de la lógica de lo que quiere ofrecer el servicio. Además, tener que mantener la sesión en el lado del servidor tampoco es una tarea fácil: tendrías que desarrollar algo parecido a lo que hace un contenedor de servlets para gestionar una sesión HTTP con toda la casuística y complejidad que ello comporta (aún asi, es algo que yo me tuve que comer en su momento :-P).
Esa es una de las utilidades que a mí me parecía obvia que debía formar parte de nuestra querida y abandonada cabecera del sobre SOAP, pero se ve que no mucha más gente tuve esa necesidad / inquietud :-P
Mi consejo es que hay que intentar huir siempre del concepto de estado cuando estamos montando una arquitectura de este tipo (al final estamos corriendo sobre un protocolo sin estado como HTTP así que dependerá totalmente de nuestra implementación). De todos modos en general no nos hace falta.
A nosotros nos surgió esta necesidad cuando estábamos implementando otra característica que necesitábamos y que tampoco está solucionada (hay por ahí algunas especificaciones pero no están implementadas): la asincronía. Nuestro problema es que nuestros servicios lanzaban cálculos muy costosos que no tenían suficiente con los timeouts del protocolo HTTP (o, mejor dicho, de los servidores web) con lo que no nos quedó más remedio que montar un protocolo asíncrono en el que peticiones de larga duración se ejecutaban asíncronamente y el servicio devolvía automáticamente el control pasándonos un token que luego los clientes podían utilizar como identificador de otro dos servicios de gestión de nuestro procolo asíncrono: el que nos permitía hacer polling y el que nos permitía recuperar los resultados una vez la petición asíncrona había finalizado. El servicio de polling obviamente necesitaba gestionar el concepto de estado: identificaba al cliente, informaba de tiempos estimados de finalización de tarea, etc.
Iván
Hola ivanator,
si el cliente puede mantener las cookies y el servicio acceder a la sesión del Servlet entonces todo solucionado.
En el cliente con la clase HttpURLConnection y algo de código puedes mantener las cookies entre petición y petición.
Saludos.
Obviamente, pero eso también es una solución "propietaria" y a lo mejor no todos los clientes son tan agradecidos gestionando cookies de manera automática. Además, el protocolo SOAP no obliga el uso de HTTP como capa de transporte (aunque sea así el 99% de los casos), con lo que no puedes depender en características de HTTP si lo quieres hacer totalmente portable (existen implementaciones sobre SMTP, que tiene sentido para contextos donde la asincronía es relevante).
Iván
Tienes razón ivanator. Me he colado.
Pero es tema de que un servicio sea sin estado es por las restricciones:
a)Falta de estandarización, tal y como has indicado. (Aunque técnicamente es posible)
b)Escalabilidad.
Comento este tema porque muchas veces olvidamos (o ni nos preguntamos) el "porqué" de las cosas. Y me recuerda a La historia de los monos y los plátanos
Saludos.
La idea inicial de un Servicio Web a través de SOPA no es la que se estila ahora, y por eso no gestionan el estado, ya que no fueron pensados para eso. La idea inicial era que fueran peticiones autocontenidas y sin estado a nivel de protocolo, que de eso se tenia que encargar el cliente.
Igualito que HTTP que es sin estado, y el semi-estado lo mantiene el cliente (navegador) con un "mecanismo" implementado sobre el protocolo, pero no en el protocolo.
Pero al igual que HTTP, un protocolo sin estado para soportar mejor los problemas de Internet ha pasado de ser un protocolo de peticiones a ser usado como un protocolo de "conversaciones". El problema en este caso es que como no hay cliente estándar, no hay donde implementar de forma estandar el mecanismo para gestionar la conversación.
No es que sea "culpa" de SOAP o los que lo crearon, es "culpa nuestra" por usar SOAP para lo que no fue creado.
Por cierto, el "video promocional" no comienza diciendo que a alguna gente le gusta reclamar planos, sino que "some people like to climb mountains" o lo que es lo mismo, a alguna gente le gusta escalar montañas...
Para el anterior anonimo. ¡Pues es ver verdad! Tienes razón :). Entendí "Some people like to claim maps". Tendré que volver a la academia again. :) Gracias.
Hola
Podrían volver a subir el mp3 del podcast?
Saludos
Reconcha de tu madre nadie dice nada concreto
Buenas. Anonimo.
El MP3 se descarga ok. ¿Cual es el problema?
Saludos, Jorge
Hola.
Veo que estan hablando de SOA y quiero que me digan que hacer con el problema que tengo. Yo tengo un numero de aplicaciones corriendo en un lugar determinado, yo quiero exportar como servicio algunas de sus funcionalidad. Que me recomiendan ???
Escribe tu comentario