Seguro que muchos sabreis que últimamente hay un fuerte debate en InfoQ entre dos estilos para construir servicios web: REST y SOAP (o los llamados estándares WS-*)
Sin embargo parece que REST está ganando la batalla de la opinión. Hay una razón de peso muy importante en contra del mundo WS-* : al parecer apenas existen servicios que se puedan acceder desde fuera del firewall, es decir desde fuera de la empresa, organización etc. Esto no quiere decir que no se usen los WS-* sin embargo si se constata su fracaso respecto a su gran promesa: interconectar aplicaciones entre lugares distantes y tecnológicamente heterogéneos en el mundo.
Más aún, en InfoQ se hacen en eco de un testimonio demoledor:
"In my experience very few enterprises really need SOAP for what they are doing -- it was put either put in by consultants as a checklist item, or the tool used SOAP by default. The majority of SOAP use appears to be simply driven by inertia, not any belief in its superiority in doing the job."
¿Son usados los servicios web para lo que en teoría se necesitan los servicios web?
¿Estamos en una crisis de los Web Services a lo SOAP?
Si es así ¿qué hacemos con las toneladas de software desarrollado en torno a los estándares WS-*?
¿Es REST verdaderamente la alternativa?
¿Cual es el grado de implantación de sistemas basados en servicios web en general?
Etiquetas: xml, rest, webservices, soap
SOAP? Es fàcil, si no quieres saber nada del protocolo HTTP (aunque lo use), eso sí, necesitas un IDE que te genere lo necesario tanto para el servidor como para los clientes, sino la facilidad se convierte en ofuscación. Enviamos los datos en formato XML, muy usado, conocido por todos... pero si sólo quiero enviar "Hola Mundo"!
REST? Fàcil, directo, sin complicaciones. Así se definio en buen principio...
Hay una razón de peso muy importante en contra del mundo WS-* : al parecer apenas existen servicios que se puedan acceder desde fuera del firewall.
¿A que te refieres? Por que si es por lo que dice en el artículo relacionado, la traducción es bastante inexacta.
A mi francamente me parece un debate esteril, el si SOAP es un fracso. Todo el mundo sabía que en torno a SOAP se montó una de las operaciones de hype más gordas, y ahora resulta que no a va a poder cumplir todas esas promesas imposibles... que sorpresa. Pero claro, la maquina de hype no se puede parar, así que no cumplir promesas imposibles se convierte en un fracaso rotundo y cojemos otra cosa que ya se usaba, le damos una vuelta de tuerca, le ponemos un nombre "guay" y volvemos a la rueda de las promesas imposibles. Eso se llama "huir hacia adelante" y entrar a debatir esas modas y sus promesas es como discutir sobre el sexo de los ángeles, sólo que en este caso hay todo un negocio montado detrás, en forma de consultorías, libros, congresos, productos de soporte...
En cuanto a SOAP vs REST, la mayoría de opiniones tratan el tema de forma bastante banal y he visto pocas opiniones "razonadas", así todavía que se hace difícil tener una idea clara.
yo tampoco entiendo a que te refieres con:
"al parecer apenas existen servicios que se puedan acceder desde fuera del firewall"
nosotros hemos desarrollado y accedido de forma remota a numerosos servicios web de proveedores y si, claro, hemos tenido que configurar los respectivos firewall, eso debería ser un problema?
además en muchísimos casos el objetivo de los WS es de tipo corporativo, para la interoperabilidad entre sistemas heterogéneos o remotos dentro de un dominio, con lo que teóricamente no habría que atravesar firewalls.
en realidad no se si entiendo eso de la crisis SOA...
Señores,
Lo de que SOAP es un hype y que ha fracasado me parece un tanto atrevido... REST es una tecnología usable para ciertos tipologías de aplicación, pero que se queda corto cuando empezamos a afrontar problemas "serios" como la seguridad, transaccionalidad, etc.
En entorno empresarial una de las pocas formas de interacción entre aplicaciones es el uso de WS (con SOAP). Jamás he visto una aplicación que use REST fuera del mundo opensource (seguramente hay alguna, pero yo nunca la ví). Sin embargo he visto un montón de aplicaciones que usan servicios web con SOAP, en casi todos los ámbitos (administración pública, banca, seguros, telcos...).
Que SOAP no ha cumplido todas las promesas que se hacían en "la cresta de la ola del hype", seguro, pero... qué tecnología lo ha hecho?
SOA != SOAP
Así que yo tampoco entiendo lo de:
¿Estamos en una crisis de los Web Services a lo SOA?
He corregido la noticia un poco.
Ciertamente "¿Estamos en una crisis de los Web Services a lo SOA?" quería decir SOAP pero tuve un lapsus mental.
Respecto a lo del firewall me refiero a fuera de la organización, de la empresa. En la noticia me hago eco de lo que se cuenta en InfoQ que a su vez recoge testimonios de foros, blogs etc.
Siguiendo con la reflexión sobre servicios web "fuera del firewall" sobre todo me refiero a *aplicaciones*. Un RSS puede considerarse un servicio web pero en su nivel más pobre o menos interactivo, una web que validando a través de un navegador un usuario y una password te devuelve un XML con un catálogo de productos es un servicio web ciertamente pero muy pobre, aunque dicha petición pudiera ponerse en un URL.
Lo que quiero sondearos es la existencia de aplicaciones basados en servicios web con *interactividad*, es decir si un proveedor por ejemplo ofrece un servicio web no sólo de consulta de catálogo sino también de compra de tal manera que todo el proceso se pueda hacer de forma automatizada sin intervención humana (es decir no es una web).
Os puedo poner el ejemplo de uno de los grandes distribuidores de electrónica e informática de España, lo máximo "automatizado" que ofrece son sus catálogos en XML via FTP.
Sería interesante conocer si la casi inexistencia de estos servicios está más basada en problemas técnicos, ignorancia técnica o simplemente una cuestión cultural (mi caaasa, mis daaatos).
en mi opinión creo que es más por lo segundo que comentas: "ignorancia técnica o simplemente una cuestión cultural", porque al menos en el sector turismo, y mira que es tradicional, se utilizan los sistemas SOAP con mucha frecuencia y de forma exitosa para transacciones, compras y demas procesos somplejos.
y esto es así porque en este sector es completamente imprescindible integrar servicios de otros proveedores dentro de tus flujos, lo que no necesariamente es requerido en otros modelos de negocio.
yo quizá añadiría un tercer motivo del poco uso: los requerimientos pocas veces obligan al uso de WS.
en mi caso he desarrollado mucho y muy variado y sólo en 2 ocasiones he tenido que desarrollar WS.
M4RC0: porque al menos en el sector turismo, y mira que es tradicional, se utilizan los sistemas SOAP con mucha frecuencia y de forma exitosa para transacciones, compras y demas procesos somplejos y esto es así porque en este sector es completamente imprescindible integrar servicios de otros proveedores dentro de tus flujos, lo que no necesariamente es requerido en otros modelos de negocio.
Quiero creerte pero en alguna de mis experiencias como cliente he visto más de una pantalla negra consultando el host "viejuno" del mayorista via terminal, pero vamos es una anécdota :)
Ciertamente en ese sector hay mucho revendedor y de otra manera no existirían webs como viajar.com, rumbo.com etc.
He actualizado la noticiacon con la siguiente reflexión:
Más aún, en InfoQ se hacen en eco de un testimonio demoledor:
"In my experience very few enterprises really need SOAP for what they are doing -- it was put either put in by consultants as a checklist item, or the tool used SOAP by default. The majority of SOAP use appears to be simply driven by inertia, not any belief in its superiority in doing the job."
¿Son usados los servicios web para lo que en teoría se necesitan los servicios web?
Como no creo que nuestros clientes pasen por javaHispano, es interesante reflexionar hasta que punto creemos en la propia tecnología que proporcionamos y si la aplicamos correctamente.
Como mencionar M4RC0, yo los casos de uso que conozco de WS fuera de la propia empresa es en el sector turistico y similares para integrar catalogos y realizar reservas en sistemas remotos a través de una interfaz común.
Yo creo que el problema no es tanto WS-*/SOAP como lo que la gente se ha imaginado/le han vendido para que servia.
Y pensar que como no se usa mucho fuera del firewall es un fracaso es como decir que como los coches de carreras apenas se usan fuera de los circuitos, entonces son un fracaso. Cada cosa para lo que es... y el hype para todo :D.
jaja, buena anecdota la del terminal... pero si, personalmente creo que el sector turismo sobre plataforma internet ha crecido y evolucionado muchisimo (demanda+competencia), ahora casi todos los operadores, revendedores y mayoristas trabajan con tecnología WS.
con respecto a la cita que has incluido estoy de acuerdo con la primera parte (pocas empresas necesitan SOAP), pero al final, y si no he entendido mal, parece que habla de que somos los técnicos los que elegimos WS como tecnología porque "es lo que toca". y aquí me pregunto, ¿realmente es posible que alguien use WS sin que sea necesario? O_o, y siendo necesario: ¿es que realmente hay otra opción mejor?
M4RC0: ¿realmente es posible que alguien use WS sin que sea necesario? O_o, y siendo necesario: ¿es que realmente hay otra opción mejor?
Es incuestionable la necesidad de webservices para integrar sistemas heterogéneos entre sí (aunque CORBA sería una solución seguramente más fiable e integrada en sus respectivos lenguajes pero en fin, ya no está de moda), pero frecuentemente cuando leo cosas sobre SOA no puedo evitar el pensamiento de que lo que se pretende es convertir sistemas monolíticos en sistemas dispersos integrados via WebServices y gestionados a través de algún tipo de herramienta de coordinación de los mismos.
Y la verdad es que a priori suena bien, pero cuando lo piensas un poco más y piensas en tu sistema de 3000 clases y te dicen que porque no lo partes en trozos, conviertes los trozos en servicios y llevas parte de la lógica en forma de BPM o similares movidas, pues no es difícil pensar en que si bien el resultado parece más flexible y desacoplado por otra parte es mucho más débil, seguramente más lento, indepurable e incontrolable.
No nos engañemos, un sistema de clases puede estar muy bien modularizado y es infinitamente más controlable y fiable que el mismo sistema distribuido.
Yo creo que hay que aplicar particiones/distribuir, por varias razones:
1) Cuando el sistema ya estaba dividido y surge la necesidad de integrarlos: rehacer una aplicación hecha en Visual Basic para integrarla en el nuevo sistema Java no es la solución más rápida (aunque seguramente es la mejor).
2) Cuando el sistema monolítico se hace enormemente grande complicado: esto es muy opinable, los de NetBeans y Eclipse, aplicaciones terriblemente complicadas y grandes, apuestan por la modularidad interna pero no conozco ningún planteamiento de futuro de particionarlos funcionando en varias máquinas virtuales.
3) Cuando se necesita mayor rendimiento: esta si que es una razón de peso, sobre todo si hay múltiples hilos por medio (si todo es monohilo y los procesos son claramente secuenciales no se gana gran cosa, es más irá todo más lento).
4) Cuando se necesita más memoria: un mismo sistema puede estar replicado en varias instancias que se reparten el trabajo y comunicarse entre sí o algún servidor común via webservices.
Necesitar lo que es necesitar, ninguna empresa necesita WS...Siempre se puede integrar de otra forma. El tema es el de siempre, hay cosas que el stack de WS te da prácticamente resuelto, y es difícil de conseguir de otra forma.
Pero, ¿cuando es conveniente usar WS? pues a priori cuando queremos ofrecer/consumir un servicio de una forma interoperable.
Para ejercer un poco de abogado del diablo, yo diría que prácticamente toda empresa u organización grande tiene necesidades de integración entre sus propios sistemas, y muchas también deben integrarse con el mundo exterior.
Bueno, yo comparto la opinión con greeneyed. Yo la única experiencia ha sido en el sector bancario y siempre se han desestimado (en el departamento donde estuve) los WS (SOAP) por rendimiento. En su lugar hacíamos lo que ahora se ha catalogado como REST. Mucho más eficiente y rápido. Así que en mi experiencia personal, SOAP es algo que interesa vender a cuatro compañías. Eso si a costa de aumentar recursos e invertir mucho más dinero. Yo prefiero seguir la regla KISS (Keep It Simple and Stupid).
Yo creo que soap ha "fracasado" porque se vendio como algo que iba a permitir interoperar a clientes de cualquier sitio con servicios de cualquier sitio, porque lo cierto es que soap lo permite. Lo unico necesario es poner a todo el mundo de acuerdo en el interfaz...
Si todos los institutos meteorologicos se ponen de acuerdo en una wsdl, podremos consultar el tiempo eligiendo la fuente. Si todos los bancos se ponen de acuerdo, podremos hacer transferencias y ver extractos con el mismo programa, etc.
Para que soap cumpla con lo que se esperaba de el, solo hace falta poner a todo el mundo de acuerdo en todo.
Mientras eso no ocurra, los servicios soap estaran disponibles dentro del firewall, porque despues de quince agotadoras reuniones, la delegacion de Barcelona se puso de acuerdo con la de Madrid en la definicion del interfaz...
Nilojg,
No podemos pedir a la tecnología que altere las políticas internas de las organizaciones.
Esa es precisamente la parte de SOA (que no SOAP) que ha fracasado. La parte "organizativa" o "política" es la difícil de cambiar, la tecnológica es una barrera que siempre se puede saltar.
Volviendo al tema de "donde se usan los WS (con SOAP)", algunos ejemplos que he visto, para los incrédulos:
¿Estamos en una crisis de los Web Services a lo SOAP?
Sinceramente creo que no. Me parece bastante atrevido decir cosas como esta. ¿Acaso se cuenta todos los desarrollos que se hacen? Yo precisamente trabajo con servicios Web utilizando SOAP y me parece que para montar una arquitectura SOA esta muy bien. Hay que tener un poco de cuidado con ciertos titulares amarillistas y efectivistas.
Otra cosa es, por supuesto, debatir ventajas de una y otra forma de trabajar. Desde luego, todo tiene sus ventajas y sus incovenientes y determinadas herramientas son muy útiles en un entorno y en otro no. La verdad es que estos debates sobre tecnologías son estúpidos. Realmente hay que conocerlos y seleccionar en cada momento lo más idóneo para utilizar.
Saludos
En cuanto al uso de SOAP, ¿que tiene que ver el firewall?. Con acceso http/https es suficiente. Vamos, exactamente igual que con cualquier aplicación web. Exactamente igual que REST.
Los WS han tenido un exito razonable, a pesar de que algunas de las herramientas mas populares para desarrollarlos hayan sido muy mediocres (especialmente las de Sun para jaxrpc). El unico fracaso total y completo de WS ha sido UDDI.
Por otra parte la difusión de REST es mas reciente, con lo que es lógico que haya poco uso. Y ya sabemos que el mundo empresarial es lento a la hora de adoptar nuevas soluciones. Con razones lógicas, por otra parte.
Yo creo que hay que aplicar particiones/distribuir, por varias razones:
Creo que de los que has expuesto, ninguno es un buen caso de uso para WS-/SOAP.
Ese es en gran parte la causa del supuesto fracaso de SOAP, es que la gente lo ha intentado usar para lo que no era y claro, no le ha ido muy bien.
Otra gran parte de culpa es como dicen la cuestion organizativa... y esa se la va a tragar REST de igual forma.
Ya veremos como evoluciona REST, a medida que intente solucionar problemas más complejos. Si intentan solapar sus casos de uso con los de WS-*/SOAP, acabaremos teniendo otra version igual de compleja.
javier.jr sería interesante que dieras algunos enlaces a páginas en donde se describieran como son dichos servicios.
Por ejemplo una búsqueda por Google con: "servicio web" SOAP ministerio
o bien con: WSDL SOAP ministerio
da algunos resultados de servicios reales pero en general las resultados son blah blah blah.
He trabajado con web services SOAP que integran aplicaciones Java con aplicaciones en .Net y si no fuera por Eclipse (o Netbeans) o Visual Studio, cada uno con sus respectivos Wizards, me sería muy complicado crear un simple ws-soap. Crear un ws-rest es, por el contrario, extremadamente simple y no requiero de un wizard para hacerlo. Además no existe nada que pueda hacer con soap que no pueda hacer utilizando un enfoque REST. No pasa lo mismo en el caso contrario (enviar archivos binarios utilizando soap por ejemplo). Desde mi punto de vista creo que la solución REST es mucho más elegante.
Ahora la única razón por la que utilicé Soap en mis proyectos anteriores fue porque era lo único que conocía. Estoy seguro de que a la mayoría le pasa lo mismo.
Al final creo que un enfoque REST va a terminar reemplazando a Soap, tal como lo hicieron los ws (soap o xml) con Corba o Dcom. La razón siempre será la misma: simpleza.
Saludos
Lo siento, pero hablar de un supuesto fracaso de la tecnología de Webservices (no confundamos SOAP, SOA, servicios disponibles por web, etc.) me parece una grave inconsciencia.
La noticia de InfoQ, en mi opinión, es de las peores que he leido en ese portal, son sólo copy/paste de partes de opiniones, sin conexión y con la palabra SOAP por enmedio. Si hasta resucitan a EDI! Se nota que ellos también están en agosto... Sólo hay que leer los comentarios, nada que ver con el nivel que suelen tener alli.
Los Webservices sí son una tecnología que funciona para interoperar Sistemas dispares y distantes y de forma independiente a la tecnologia subyacente de cada uno. Pero sobretodo suponen un estándar. Ya no tengo que usar FTP para interoperar con la aplicacion de personal, JMS para la de finanzas, SMTP para la de auditoria, HTTP para la de compras, etc, etc. Por no hablar de la codificación del mensaje (XML, json, codificacion de la casa, fichero separado por comas, etc.).
Ahora voy a usar Webservices para todas (bueno demosle un poco más de tiempo porque los sistemas que funcionan no se cambian en 1 mes ni en 1 año). Y por debajo, en el stack de Webservices estará SOAP o JMS o TCP, me va a ser indiferente. Pero además podré usar (si me hace falta) seguridad a nivel de aplicacion (WS-Secutrity) y no sólo de canal (https), transacciones, mensajes asincronos, mensajes confiables y todo serán estándares con su implementación en Java, Grails, .Net, Erlang,...
Los casos de uso que ha aportado Javier son totalmente válidos. Raro es el Sistema de una Administración o Telco que no usa un cliente o servicio Webservices. Y los que aun usan otras formas de interoperabilidad ya tienen planificada su migración.
Yo añadiria el área de la Salud. Ultimamente ha salido en las noticias lo del Historial Clínico Digital. Ahi estan los estándares de HL7 para intercambiar información médica.
También podeis fijaros en nuestras propias herramientas de gestión de proyectos, como JIRA, Trac, etc. Al menos JIRA tiene una buena serie de servicios Webservices para integrarse con el resto de Sistemas de la organización.
Otro caso, si conoceis alguna organización que utilice SAP, adivinad como va la interoperabilidad con el resto de Sistemas... Yo ahora precisamente estoy trabajando en eso.
En serio, la implantación de WS es mucho mayor de la que creeis a raiz de vuestros comentarios. ¿Por qué no hay más servicios públicos? Por un lado los servicios que se usan no son públicos, mínimo necesitan un usuario/password o certificado digital. Por otro lado, es normal que primero se quiera probar una nueva tecnologia de puertas para dentro antes de exponer un servicio al público.
Pero no comparemos los Servicios usados en WS con un RSS de noticias... Otra cosa, que no tiene nada que ver con las bondades y defectos de los WS, es el nivel de los expertos que forman parte de los equipos de trabajo de las consultoras... Existen proyectos con WS que han fracasado, pero ha sido por culpa única y exclusiva de la tecnología?
Y qué me decis de más hype que el de REST? Por favor, él que conozca un proyecto contratado con dinero de por medio que use REST en España (o pais hispanoparlante) que me saque de mi ignorancia. Aunque no quita que REST sea una alternativa factible para determinados casos de interoperabilidad, como lo siguen siendo otras tecnologias.
Yo no creo que el fracaso sea de "SOAP" sino de "SOA".
Al pensar en "SOAP", erroneamente se piensa en una aplicación distribuida separada en servicios, es decir "SOA" y como ya habeis comentado algunos, es bastante complejo hacer aplicaciones de este modo y no siempre es necesario o deseable.Así que yo creo que ese es el tipo de proyectos han sido candidatos al fracaso.
Lo que creo que no ha fracasado es integrar distintas aplicaciones mediante SOAP debido entre otras a las venjatas que ha comentado jcesarpere.
Si es así ¿qué hacemos con las toneladas de software desarrollado en torno a los estándares WS-*?
Lo mismo que hice yo con todo lo que tenia escrito para CORBA
jcesarperez: Y qué me decis de más hype que el de REST? Por favor, él que conozca un proyecto contratado con dinero de por medio que use REST en España (o pais hispanoparlante) que me saque de mi ignorancia. Aunque no quita que REST sea una alternativa factible para determinados casosde interoperabilidad, como lo siguen siendo otras tecnologias.
Yo pienso cambiar todos mis proyectos de web services (en SAP Portal) a REST y de paso solucionar muchos de los problemas que hoy tenemos con soap. Ja.
Hay que entender que internet está construida sobre el concepto REST, y eso incluye ws-soap. De ahi que todo lo que puedes hacer con ws-soap lo puedes hacer ws-rest, pero de forma más simple y, desde mi punto de vista, elegante.
Creo que al igual que Ajax, Rest va a ser la próxima moda nos guste o no.
pd: jcesarperez. Por error quise ver que hacía el icono que aparecía abajo y viendo el link descubrí que dice user-unaprove comment... Así que no creas que desapruebo tu comentario. De todas formas no estaría mal que apareciera el texto alternativo para explicar que hace el icono para los que son nuevos.
Saludos
jcesarperez alguno hay XD, a mi me ha tocado trabajar alguna vez con casi REST(sólo con GET y POST) y en otras ocasiones con SOAP.
SOAP para integraciones internas del tipo ERPs con portales, intranets,etc. o en proyectos para AAPP; mientras que casi REST en un par de ocasiones para integraciones con servicios de fuera, por ejemplo una integración de un portal de viajes con un servicio de reserva de vuelos.
También tengo que decir que yo he trabajado y trabajo más con aplicaciones de internet que puramente empresariales y ahí, por mi experiencia, es bastante común hacer integraciones tipo REST.
Efrigerio no estás al día (no había en la farmacia con marca CORBA, pero esta es la mejor):
jmarranz,
Como ya he comentado los WS de los que hablo son casi siempre internos (esto es, no son accesibles desde internet).
En el caso concreto de la administración pública te puedo decir que estos se usan para ofrecer funcionalidades comunes en los llamados servicios telemáticos. Si no quieres creerme allá tu, pero como referencia puedes buscar en google algo así como "administracion electrónica servicios telematicos", y comprobarás que todas las comunidades tienen iniciativas al respecto de este tipo de servicios al ciudadano, y casi todas ellas (esto quizá no lo encuentres tan fácil, quizá en alguna presentación del tecnimap) usan WS para la implementación de la lógica de negocio
Por si te quedan dudas te puedo decir que he estado trabajando más de un año en el área de arquitectura de aplicaciones de la comunidad de madrid, también he participado en la nueva arquitectura Java del gobierno de navarra, y conozco bastante el tipo de interación de estas organizaciones con otras administraciones, empresas y ciudadanos.
Hola de nuevo.
¿Podriais dar un poco más de información sobre esos proyectos que usan REST? No hace falta que deis nombres ni detalles, con algo de información generica nos podriamos hacer una idea más clara del alcance de REST. Algo tipo: equipo de N personas, proyecto de X meses, cliente del sector Y y tamaño Z.
Luego sí hay una cosa con la que no estoy de acuerdo y es que REST sea mucho más sencillo y elegante que WS(soap).
Hacer un servicio Webservices (estrategia contract-first) es:
1) Diseñar el interfaz del servicio (entrada y salida) a nivel de XML. Este paso es común a WS y REST. Y siempre saber lo que quieres hacer es lo más dificil.
2) Generar el skeleton del servicio encargado de procesar las peticiones. Este paso esta automatizado con una herramienta wsdl2java y es ejecutar un Wizard, una linea de comandos o añadir unas lineas a tu build.xml de ANT o pom.xml de Maven. No deberia ser un problema para el lider técnico del proyecto. Ademas que se hace una vez y ya está. Mientras no cambie el interfaz no hay que volver a hacerlo.
* Opcionalmente también se pueden generar clases Java que representen los mensajes de entrada y salida con un mapeador XML-Java y nos olvidamos de usar apis de XML a pelo.
3) Implementar la lógica del servicio en Java. Tenemos una clase Java con un metodo vacio que tiene como parametro la entrada y como return la salida del servicio (o bien en XML o bien POJOs, segun *). Y esto tambien es común a REST.
4) Empaquetado y despliegue. Estamos hartos de hacerlo...
Hacer un cliente Webservices todavia es mas sencillo. Dejo un par de enlaces de ambos clientes en Axis2:
REST -> http://ws.apache.org/axis2/0_94/rest-ws.html
Webservices (sin wsdl2java) -> http://wso2.org/library/290
El de REST tiene mas lineas pero porque procesa el XML. En realidad esas lineas serian comunes. Son los primeros enlaces que devuelve Google, no ha sido aposta. El mecanismo para ambos casos es igual de sencillo y elegante, al menos para mi.
Aunque si la entrada y salida con complejas, no una simple lista de 2-3 parametros, yo prefiero usar wsdl2java para hacer tambien el cliente y me olvido del XML.
Mampuero, imagino que no te voy a convencer, pero si que queria hacer un resumen de la complejidad que implica trabajar con Webservices. Y en realidad yo veo a REST como una opcion a tener en cuenta para integraciones sencillas a nivel de información de entrada o con una clara funcionalidad CRUD. Danilat, yo tambien he visto y hecho mis cositas a nivel de POST y GET con servlets y REST supone un salto hacia delante en este nivel está claro.
Pero en mi opinión, no veo a REST sustituyendo a Webservices. Están a niveles diferentes. Haria una estupida comparación con Java y otro(s) lenguajes, pero me ahorro el trolly-trolly :p
jmarranz, si quieres algo concreto puedes buscar con sustitucion de certificados en soporte papel. Yo trabaje hace tres años en ello. Y el map tenia una web para bajarse una especie de framework con wsdl y todo. No se en que estado estará...
No tengo demasiada experiencia con Web Services, pero si llevo muchos años realizando acciones de interoperabilidad entre empresas. En mi opinión la tecnologia en si es bastante buena, con muchas posibilidades. Hablo en principio de servicios web basados en WS o RPC. Desde que llevo integrandome con otras empreasa hasta el día de hoy, los servicios web han tenido una presencia en aumento, casi diría exponencial. Anteriormente todo eran reuniones y decisiones para coordinar una comunicación con algunas tecnologías no muy diseñadas tan especificamente para eso. El resultado final solía ser regular de media. Generalmente una de las empresas impone su voluntad o es muy obtusa. En este marco la comunicación crea muchos problemas a la hora de intercambiar datos. Este es quizás el problema de base que se puede encontrar los Servicios Web. Intentar formalizar cualquier posible comunicación entre empresas teniendo en cuenta la arquitectura existente en ambas, las ganas de hacer algo más(quizás lo mas importante) o los medios para poder hacerlo(también puede ser por intentar abarcar demasiado. que típico no?). Por eso pienso que los problemas son mas propios de las empresas que de otra cosa.
A parte de esto, los servicios web que claro esta suelen funcionar muy bien son los que proveen empresas para dar información, tipo google, flickr o lo que sea. Es cierto lo que comentaban por ahí. Estaría bien que los servicios de un mismo tipo tuviesen una interfaz común para poder elegir una fuente u otra según convenga, incluso en tiempo de ejecución. Bueno es muy interesante. Supongo que es será el canino futuro. Pero las cosas en informática de organizacion de informacion, corporativa, etc no se hace en tan poco tiempo. Hay tantas cosas en informática que nos gustaría que fueran de tal o cual forma... Pero pasan los años y se ve un avance lento.
En definitiva, no creo que sea el fin de una tecnología. En mi experiencia en el mundo web y sms de telefonía, las integraciones con operadoras y empresas de telecomunicaciones esta siendo casi exclusivamente por servicios Web. Las empresas que nos proveen información de tipo deportes, etc para usarlo en nuestros portales estan empezando a pasar a servicios web también(algunas incluso llevan años. Me he encontrado mas de un servicio web basado en rpc). Por esto creo que no es el fin ni nada por el estilo.
Como he dicho no conozco mucho de WS y nada de REST. Si es cierto que es tan simple pero limitado. Bueno podria ser que laa industría pasase por ahí, pero esas limitaciones tendrían que suplirse y volveríamos a un pseudo WS SOAP. No se... el time lo dirá.
javier.rj, el hecho de que la Administración Pública de España utilice WSs-SOAP, no es un buen argumento para defender esta tecnología, sino más bien al contrario. Ten en cuenta que la Administración suele utilizar las tecnologías más complejas y costosas existentes, debido a que los proyectos suelen ser dirigidos por empresas de servicios, que están muy interesadas en proyectos grandes y costosos. Ojo, con esto no estoy diciendo que los WSs-SOAP sean malos; lo que digo, simplemente, es que no se puede defender esta tecnología diciendo que la usa la Administración Pública.
A mí, personalmente, siempre me ha gustado la idea de utilizar "http para todo", pero pienso que la tecnología de los WSs es demasiado "gorda" y supone matar moscas a cañonazos. De todas formas, afortunadamente, el hecho de que Sun haya incluido JAX-WS en las nuevas versiónes del JDK está facilitando muchísimo el trabajo con WSs, a base de ocultarnos la complejidad subyacente.
Juan
javier.jr: Si no quieres creerme allá tu
Que si te creo, yo mismo he encontrado alguna especificación del interfaz WSDL a usar en algún ministerio español, pero mi impresión es que interfaces SOAP públicas poquitas, poquitas, poquitas.
Nota: javaHispano abarca todo el mundo hispano, estaría bien aclarar cuando hablamos de la administración española.
jmarranz,
efectivamente, hay pocas interfaces públicas. En ese sentido estamos frente al problema organizativo (e incluso legal) que supone la interoperatividad entre empresas/organizaciones/administraciones...
Pero creo que ese ya no es nuestro problema, sino de nuestros queridos políticos ;)
Al Anónimo del 22/08/2008 08:58.
1. Stream
2. Serialization
3. RMI
4. Corba
5. MQ-Series
6. EJB
7. JMS
8. WS
Por mas lubricante que le pongas, hay un problema de espacio.
Pero bueno.
Hablando en serio, personalmente y como comente en su momento
SOAP / WS posee todas las desventajas de CORBA y ninguna de sus ventajas como era el modelo de eventos por citar alguno.
Además como bien habéis marcado algunos, el problema de la orientación a servicios esta en poder delinear claramente que es lo que tienes que publicar, y para quien.
Saludos cordiales,
Jua, jua, estoy de acuerdo con Juan. Trabajo como programador en una empresa y algunas veces acompaño a los comerciales a reuniones con informáticos de la Admón.: la estrategia de los comerciales es muy simple, y consiste en nombrar todas las siglas más modernas y esotéricas sobre TIC. Los informáticos de la Admón. tragan porque se sienten muy modernos al utilizar todas esas siglas tan modernas. Y nosotros, los programadores de las empresas, tenemos que aprender rápidamente a usar esas tecnologías correspondientes a las "modernas siglas". Aún recuerdo cuando, hace unos cuantos años, teníamos que usar EJBs porque esas siglas eran "lo más de lo más". Ahora, en cambio, NADIE quiere EJBs, porque los EJBs han dejado de ser "modernos".
jcesarperez:"Mampuero, imagino que no te voy a convencer"
Hombre, pero claro que me puedes convencer. Con una buena argumentación te juro que me olvido de Rest ;-).
Lo que pasa es que he tenido que construir unos web services que se ejecutan en Sap Portal, tienen conexión con Documentum (un sistema gestor documental) y son consumidos desde aplicaciones .Net., para una empresa mediana (con alcance global). De haberlo realizado siguiendo la filosofía Rest me hubiese ahorrado un 80% del tiempo que perdí solucionando las limitaciones de Soap para trabajar con archivos binarios (entre otras cosas tan "especiales" de Sap). Ahora, no es que generar un web service haya sido algo complicado, pues el wizard lo hacía casi todo. El problema es cuando veo el código que genera y pienso lo complicado que sería que yo mismo lo escribiera. Y de ahi que diga que la solución no es elegante. Estoy seguro que un sistema no tendrá problema en entender el wsdl y el xml de los mensajes soap, pero como soy humano prefiero el código entendible por los humanos. Y en eso creo que Rest es superior.
Como ejemplo te pongo una comparación entre un cliente Soap y un cliente Rest:
Soap
12345
Rest
http://www.acme.com/phonebook/UserDetails/12345
Como yo lo veo, encuentro mucho más simple el modelo Rest.
Ahora no concuerdo con tu apreciación de que Rest es algo diferente a web services. Desde mi punto de vista web services no significa soap. De ahi que tengamos web services xml, jason, rest, etc. Es sólo una convención más para lograr lo mismo.
Tampoco concuerdo que Rest sea más limitado que Soap, de hecho es exactamente lo contrario. La única "limitación" de Rest sobre Soap es que sólo puede ser enviado por http. Y eso, al menos en mi caso, no es algo que sirva de mucho (.... mejor no escupo al cielo ...o puedo terminar programando ws por ftp. Ja).
Bueno saludos a todos. Y para los que deseen entender un poco más de rest sigan este link:
http://learn-rest.blogspot.com
No funcionó pegar el xml del mensaje soap. Así que por favor revisar el link.
Que si SOAP, que si REST, ¿es que nadie a echado un vistazo a la Internet Communications Engine, de la mano de algunos de los creadores de CORBA? Veamos cómo se compara con SOAP, o con CORBA. Disponible para varios lenguajes y sistemas operativos.
Yo trabajo en unqa empresa de seguros y te puedo asegurar que SOAP es el pan nuestro de cada día. No sólo en mi empresa, sino en las empresas con las que interactuamos. Tenemos servicios web tanto internos como externos y la práctica totalidad de nuestro backoffice es accesible vía servicios web, lo que nos da un nivel tremendo de integración. Mi empresa es multinacional y puedo aseguraros que se usan servicios a nivel mundial.
No estoy muy seguro de en qué punto estamos en España, pero fuera la cosa está bastante clara:
Amazon apostando por REST en lugar de SOAP (2003, casi antes del boom del SOA):
Google abandonando su API SOAP (2006, poco después empezó oficialmente a empujar REST a saco):
Actualmente el soporte REST es oficialmente lo más interesante a incluir en la release 3.0 de Spring, y ya lo tienen otros como RoR. Curiosamente, es un tema que ha empezado a eliminarse de la capa de integración y se ha mezclado con la de presentación, porque los frameworks de capa de presentación están bastante más maduros y con un mínimo esfuerzo pueden resolver los problemas de REST.
Que ya existen servicios SOAP, no lo dudo. Pero en mi cabeza, está en el mismo cajón que CORBA.
icoloma, lo siento pero los enlaces que indicas no tienen nada que ver con una supuesta tendencia de que REST este sustituyendo a SOAP. Puedes consultar InfoQ y buscar presentaciones sobre las arquitecturas de Google y Amazon para ver que siguen usando SOAP. Lo mismo que los ejemplos de Spring y RoR que antes han tenido SOAP que REST y no es que vayan a deprecar SOAP precisamente.
Eso sí, los enlaces son 2 ejemplos de que hasta Google y Amazon se equivocan y hacen sobreingenieria de vez en cuando. Por qué? Pues claramente son 2 servicios para poner en una página, como tu dices a nivel de presentacion, no son más que un gadget, algo como el embed de youtube o de googlemaps. En estos casos, hacer que el navegador del cliente use algo mas que HTTP es sobreingenieria y mas si tenemos en cuenta la funcionalidad que es una simple consulta con 1 parametro. Usar SOAP fue un error desde el principio, con o sin REST.
Para estos casos de uso, de llamadas sencillas en la entrada desde el navegador a un servicio, es donde los servicios REST más AJAX vienen perfectos. Al fin y al cabo REST no es más (ni menos) que una forma de usar HTTP para realizar CRUD que tambien viene muy bien para integraciones entre aplicaciones con mensajes sencillos y sin necesidades de seguridad mas allá de https, firma digital, llamadas asíncronas, transacciones, mensajes confiables y attachments que sean estándares implementados en la plataforma/lenguaje de turno.
Mampuero, es un buen enlace, aunque se echa de menos un ejemplo o dos de construccion de un servicio. Por cierto, a mi tambien me toco sufrir con los adjuntos binarios en su dia...
En cuanto a los que comparan la complejidad de SOAP con Corba, o bien conocen una forma de usar CORBA muy sencilla o bien usan SOAP de una forma extremedamente compleja porque si no, no me lo explico. Y esto sin entrar en que ORB gratuito y que funcione en todas las versiones Java apartir de la 1.4 usan o de como se saltan los firewalls o de como tratan de forma transparente con el servicio de nombrado o de como les parece mas sencillo el IDL de Corba que un XML. Y sí, SOAP ya tiene su especificación para eventos...
Totalmente de acuerdo contigo!!!
"
Para estos casos de uso, de llamadas sencillas en la entrada desde el navegador a un servicio, es donde los servicios REST más AJAX vienen perfectos. Al fin y al cabo REST no es más (ni menos) que una forma de usar HTTP para realizar CRUD que tambien viene muy bien para integraciones entre aplicaciones con mensajes sencillos y sin necesidades de seguridad mas allá de https, firma digital, llamadas asíncronas, transacciones, mensajes confiables y attachments que sean estándares implementados en la plataforma/lenguaje de turno.
"
Para usar AJAX , lo mejor es convinarlo con REST por la sencilles tecnológica, para hacer GUI's. Pero acceder a componentes remotos con cierta complejidad necesaria como la que mencionas lo mejor es SOAP con WS-*.
Lo que pasa es que ante nuevas tecnologías siempre aparecen los talibanes radicales causantes de los "hypes", dicendo que son la panacea y creando falsas expectativas(lo mismo paso con soap en su momento). Menos mal que al final todo las tecnologias tiene su hypes pero tambien su madurez, que es cuando se colocan en "su lugar".
Hace dos años asisti a una conferencia sobre SOA, parecia que todo el mundo iba hacia esa tecnologia pero a modo de BIG-BANG todo de un dia para otro iba a ser WebService, nosotros solo teniamos 8 webservices y poco a poco ibamos poniendo mas, nuestro sistema va mas por ir paso a paso.
Ahora, son pocas las instituciones que proveen webservices para trabajar con ellas, seguramente sera un problema del Gobierno ya que tenia que haber apostado por una tecnologia abierta, las instituciones tienen ya mecanismos para interrelacionarse pero, son propietarios, caros y cerrados, una apuesta clara desde el Gobierno, ya sea autonomico o central podria mover todo a WebServices, pero antes hay que dar una solucion general y estandar a temas como la seguridad, asi como establecer un marco legal.
Ademas, deberia ser importante establecer unos tiempos maximos de respuesta ya que sino las aplicaciones se quedaran esperando eternamente el servicio web de terceros.
Escribe tu comentario