PI   laBitácora.net                   Mirror Cd por nevrlndtink1

« PreviousNext »

Tecnologías de intercambio en la red

8 Junio 2005

Básicamente Internet es una red de redes de ordenadores sobre la que corren distintas aplicaciones informáticas. Y si algo tiene visos de crecer es la interoperatividad entre las distintas aplicaciones que se ejecutan en los múltiples ordenadores que sostienen Internet. Aprovechando que la red ya está montada y que la información que se encuentra en ella es ingente, que mejor que usarla para distribuir los costes computacionales.

Las tecnologías que actualmente se imponen para realizar el intercambiando de información entre las distintas aplicaciones que se ejecutan en la web son REST y SOAP.

Los puntos fuertes que les veo yo a cada una son:

REST (REpresentational State Transfer)
Con este sistema todo el intercambio se realiza sobre el protocolo http. Y debido a ello se consigue:

SOAP (Simple Object Access Protocol)
Es un protocolo creado por el W3C que se sustenta sobre http y que permite pueden comunicarse a las aplicaciones web a través del intercambio de datos XML.

Posted in Tecnología, webs, Internet | Trackback | del.icio.us | Top Of Page

    4 Responses to “Tecnologías de intercambio en la red”

  1. ACid Says:

    Bueno, SOAP como dices es un estándar del W3C, así que no me ha gustado mucho la frase en laa que dices que está “apadrinado” por Microsoft y Sun. No digo que sea falsa, pero me parece incompleta y que puede inducir a confusión.
    En la web de la W3C dice que SOAP es una recomendación del W3C producida por el XML Protocol Working Group:
    http://www.w3.org/2000/xp/Group/
    Y en la página de ese grupo se ve que son 15 miembros de 9 organizaciones: hay gente de Microsoft, Sun, Oracle, BEA, SAP, Canon… Estas 6 empresas participan con dos personas cada una y luego hay otras con uno sólo: IBM, IONA Technologies, SeeBeyond.
    Luego también hay un miembro del W3C y un ‘chair’ (¿presidente?) que es de Nokia.

    Quizá la frase quede mejor si decimos que SOAP esta apoyado por las principales empresas de software, incluyendo Microsoft, Sun, Oracle, BEA, IBM…

    También creo que las características que citas de REST no son muy definitorias. Igual se pueden aplicar a SOAP:
    SOAP suele usar HTTP como protocolo de transporte (aunque no es una exigencia), así que eso le da todas las ventajas que tiene REST por usar HTTP. Pero tiene una ventaja añadida: no necesita HTTP (REST está atado a HTTP). Imagina que tienes un sistema antiguo basado en CORBA y que acepta operaciones/mensajes mediante IIOP…
    Por lo que he leido, creo que lo definitorio de REST es que se basa totalmente en HTTP y usa las facilidades que ya tiene HTTP (POST, GET, PUT, DELETE), y una filosofía basada en “recursos”, definidos por URLs. Eso le da una ventaja en eficiencia y flexibilidad: no está obligado a usar XML. He visto que puede usar HTML. Y me imagino que también puede enviar texto plano directamente. De esta forma el procesamiento puede ser más rápido y con menor consumo de ancho de banda.
    De todas formas, salvo casos excepcionales yo diría que los tiros van más por XML y SOAP es una buena forma de hacerlo. Otra forma es XML-RPC… pero prefiero las tecnologías estándar. Es muy bueno que varias partes de la industria se pongan de acuerdo.
    ¿Diremos pronto “REST In Peace”? ¿o diremos que “SOAP is better than the REST”? ;)

  2. sim0n Says:

    Creo que en la práctica el hecho de estar ligado a http no es ningún handicap.
    La característica que para mi hace superior a SOAP respecto a REST, es la posibilidad de describir el servicio web a través de WSDL (Web Services Description Language), esto nos da una descripción perfectamente los objetos y métodos disponibles del servicio web. REST y SOAP, sin usar WSDL exige un conocimiento sobre la información que se comparte y de que tipo es esa información. Pero esa ventaja tiene el inconveniente de añadir más complejidad al uso y desarrollo de los servicios web y ahí es donde tiene su campo REST, en la mayoría de los casos consigue los mismos resultados con un coste menor.
    En muchos de los frentes abiertos en el mundo del desarrollo del software, tenemos esas mismas tendencias, por un lado una línea más estructurada y de mayor definición pero más compleja a la hora de desarrollar y por otro lado una línea menos rígida y más sencilla desde el punto de vista de la implementación.

  3. ACid Says:

    Sí, lo bueno es conocer las posibilidades que hay y elegir la mejor para cada necesidad. Pero creo que la tendencia favorece cada vez más a la flexibilidad de cara al futuro y a la rapidez de desarrollo. La razón de esto es la imparable ley de Moore: los costes en rapidez (CPU) y ancho de banda disminuyen a pasos agigantados, mientras que los costes de mantenimiento y desarrollo de aplicaciones apenas cambian. El XML da la flexibilidad de que si un servicio tiene que meter un dato añadido, simplemente se mete una etiqueta nueva (en terminología XML se llama “Elemento”) o bien un atributo nuevo y las aplicaciones anteriores pueden seguir funcionando (ignorando esos Elementos y Atributos). Y una buena prueba de esto es el HTML, que empezó con pocas etiquetas / atributos y se ha ido extendiendo… y los navegadores antiguos ignoran las etiquetas nuevas (y muchas cosas funcionan). Luego, como dices, tienes WSDL… y también en los Web Services tienes otras cosas interesantes como UDDI
    En SOAP se podría decir que trabajas una capa por encima. Y creo que esa capa es importante, así que en la mayoría de los casos conviene usarla.
    Una analogía sería programar sobre capa IP ó sobre capa HTTP. Para hablar por Internet te conviene tener el mínimo consumo de ancho de banda y la máxima rapidez de respuesta, así que programas sobre IP y tienes VoIP. Pero para cientos de aplicaciones de Internet, blogs, etc… no se meten en IP sino que van sobre HTTP o capas superiores.
    Otra analogía es Java vs C/C++ . Un sistema operativo de uso masivo debe aprovechar al máximo los recursos y convendrá hacerlo en C/C++ pero montones de aplicaciones más que apurar al límite los recursos, lo apropiado es que sean más fáciles de mantener, más flexibles…
    Si haces un edifico público u obra pública que usan miles de personas y que rara vez va a cambiar en muchos años pues quizá te convengan unas técnicas de construcción caracterizadas por la sobriedad, funcionalidad… Pero muchas casas particulares, usarán otras técnicas muy diferentes. En una casa tendrás camas plegables, sillones convertibles, mesas extensibles… pero no se ven mesas extensibles en un parque. Millones de coches particulares son cambiantes (asientos reclinables, elevalunas, …), pero la carretera no cambia. La carretera es importante que permita ir rápido por ella pero el coche no siempre se compra pensando sólo en su rapidez: también se mira lo cómodo que es, el precio, que no se averíe. Imaginemos que tenemos un coche muy barato de hacer, que si el año que viene queremos uno diferente se puede transformar fácilmente, que es muy cómodo… y que si va lento puede por peajes que están tirados de precio. Eso es el Java, XML y SOAP. Ahora tenemos otra opción que es un Fórmula 1 que vale una pasta, no lo podemos cambiar y su comodidad es cuestionable.

Leave a Reply




Estadísticas
Licencia Creative Commons