El Nacimiento

De Los Web
Services
TL;DR: Estamos en la tercera generación de aplicaciones
distribuídas. Curiosamente hoy priorizamos la simplicidad para
poder crear arquitecturas complejas de verdad.
✣ (expandir) RSS para podcatcher
alojado en archive.org
Disclaimer: no me digas que este post es largo, que luego bien
que coges la jotdown y la lees de arriba abajo. Pero vamos, que
vas a necesitar buscar un rato en el que nadie te agobie para
poder dedicarle un cuartito de hora. Y recuerda: en estas
primeras entradas estamos montando un framework mental. No
hace falta que te quedes con todos los detalles pero sí que
reflexiones sobre cómo hemos llegado hasta aquí.
Hoy en programar.cloud tenemos una historia de poder,
dinero, bromance, revoluciones tecnológicas y peleas a cara de
perro entre egos. Y todo empieza con un adolescente llamado
Marc que programaba con un Atari.
El amigo Marc siempre había tenido lo que ahora definiríamos
como un espíritu emprendedor. Ya sabes, quería hacer cosas y
quería ganar dinero con ellas. En los 80 (con 16 años)
programaba juegos para ordenadores de 8 bits. No es que fuesen
los juegos más sofisticados de la década, pero hey, 16 años ¡y sin
internet! En aquellos tiempos los ordenadores no se hablaban
demasiado entre ellos y casi todas las aplicaciones se limitaban a
guardar datos localmente o como mucho en el servidor de la
oficina.
En aquellos tiempos los ordenadores no se hablaban demasiado
entre ellos.
Pasaron los años y al terminar los estudios Marc se metió en una
gran empresa: Oracle. Mejor dicho, en una empresa grande. Allí
fue dirigiéndose hacia posiciones más orientadas a negocio que a
la parte técnica pero seguro que el chiquito seguía en contacto
con los programadores que fabricaban los productos. Con 23 o
24 años el amigo se convirtió en el vicepresidente más joven
que había tenido la compañía. Pasta gansa (entre trescientos
mil y un millón de dólares de la época al año, según las fuentes) y
una visión global de negocio que tendrá bastante que ver con lo
que más adelante te cuento. Además se hizo íntimo amigo de
Larry, el dueño de la compañía. Llegó a considerarlo su tutor.

Las Primeras Aplicaciones Web

Como todas las corporaciones de los 90 y por motivos que darían

para otro post-culebrón en Oracle apostaron por Java. Habían
comprado Orion (un servidor de aplicaciones sueco,
aparentemente los suecos hacían estas cosas) y con esa facilidad
característica suya para bautizar épicamente sus productos lo
renombraron como “OC4J”. Claro que sí.

En cualquier caso la idea detrás de este software era que los

desarrolladores pudiesen crear aplicaciones web que fuesen
capaces de escalar (crecer) según la carga de trabajo: si el hierro
se quedaba corto en lugar de conseguir una máquina más grande
lo que podías hacer es añadir más máquinas y crear una
aplicación distribuída en un clúster.
Umh… luego volvemos con Marc pero déjame que te aclare un
poco la idea de aplicación distribuída porque quizá a ti esa época
te pille muy lejos. Se trataba de unir los recursos de distintas
máquinas de forma más o menos transparente para ejecutar lo
que a nivel lógico (desde el punto de vista del programador)
debería parecer un único programa. Es decir, puedes tener una
variable miCarritoDeLaCompraen el ordenador A y el objeto apuntado
por ella puede encontrarse físicamente en la máquina B. Así
puedes usar los recursos locales de B desde A y distribuir el
trabajo entre ambas. Espera, mejor con un dibujo:

Obviamente entre dos máquinas no compartes ni RAM ni

procesador por lo que debe de existir alguna magia intermedia
para crear la ilusión de
que miCarritoDeLaCompra.obtenerImporteTotal() se ejecute
transparentemente y esta magia pasa por transmitir datos a través
de la red.
Este tipo de tecnología floreció en la segunda mitad de los 90 y
de alguna manera prometían mejorar la arquitectura de
aplicaciones síncronas (alguien pedía algo y se le contestaba
inmediatamente) que solían utilizar variaciones de RPC porque
(de nuevo, en teoría) se adaptaban mejor a la orientación a
objetos y casi no tendríamos que hacer cambios en el código para
incorporarlas. Si llevas un tiempo en el negocio te sonarán
productos como RMI, DCOM o CORBA. En este último caso se
trataba de magia negra de la peor calaña y motivo suficiente para
pedir la cuenta y buscar otra empresa. En serio, no quieres usar
CORBA.

En cualquier caso en esta primera generación de aplicaciones

web corporativas se utilizaba HTTP para presentar las pantallas
HTML a los usuarios pero internamente los nodos que componían
el clúster servidor se comunicaban entre ellos usando referencias
remotas.
Si no te queda muy claro no te preocupes, he montado un
pequeño screencast con una demo de RMI . No es que crea que
vayas a utilizar mucho esta tecnología pero si te interesa Java
necesitas conocerla por cultura general. Además sé que estás
deseando coger el teclado y poder empezar a picar como si el
mundo se terminase mañana así que cuando acabes de leer este
post revisa el siguiente en el que incluyo el vídeo.
No parece tan malo ¿no? O sea… ¿qué problema tienen las
aplicaciones distribuídas? Bueno, Muchos. Además de las
incompatibilidades que había entre algunas implementaciones de
la misma tecnología (helloooo CORBA, estoy mirándote a ti)
también te encontrabas conque el despliegue de este tipo era
complicado: un nodo con una versión incorrecta del código o una
regla en un firewall cortando el tráfico y tu sistema empezaba
a lanzar excepciones como si el mundo se terminase. A nivel
de diseño de alguna manera el modelo de programación
favorecía (gracias a su potencia) el acoplamiento entre
componentes… algo que a esta alturas ya tenemos claro que solo
trae problemas ¿verdad?. ¿VERDAD? Con una cerveza te cuento
historias para no dormir sobre este tema.

La Llegada Del Service Oriented Architecture

En fin, en cualquier caso en algún momento los problemas de

este enfoque se hicieron tan evidentes que las empresas que
marcaban la innovación (porque amigos y amigas, antes la
innovación en software la dirigían las grandes corporaciones)
decidieron que había llegado la hora de crear una alternativa.
Algo más modernito. Que no diese problemas con el maldito
firewall. Basado en eso que lo estaba petando, ya sabes, *la
web*.
La idea era separar completamente las máquinas entre sí: nada
de conexiones permanentes entre clientes y servidores, nada
comunicación directa entre los nodos servidores. Cada producto
publicaría aquello que podía hacer a través de direcciones web y
solo se comunicarían mediante peticiones HTTP para
intercambiar documentos.
Inicialmente este cambio añadía latencia a todo el procesamiento
así que se modificó la granularidad con la que se manipalaban los
datos: dejó de diseñarse alrededor de la invocación de rutinas
(como se hacía en aplicaciones distribuídas) y se empezaron a
intercambiar documentos completos.
Siguiendo el ejemplo anterior, obtenerImporteTotal() retornaba
simplemente un número con el dinero que gastaría el cliente. En
cambio una llamada a la operación ObtenerCarritoDeLaCompra del
webservice correspondiente devolvería todos los datos del carrito
(que probablemente ibas a necesitar igualmente) para reducir el
número de veces que era necesario ejecutar la petición al
servidor.
Además un documento es independiente de la plataforma en la
que se genera o se consume por lo que sistemas desarrollados
en .net, java, cobol o pon_aquí_tu_veneno_favorito podrían
integrarse mucho más fácilmente. En teoría.
Los de marketing se pusieron a trabajar y hey, esta gente cumplió:
acuñaron el término web services.
Los de marketing se pusieron a trabajar y hey, esta gente
cumplió: acuñaron el término web services. Hasta la basura más
grande podría venderse bien con un nombre tan bueno como ese
y de hecho eso es exactamente lo que pasó. Porque como se
hacía todo en esos momentos en lugar de crear un producto y
probar su viabilidad en batalla se decidió que había que
montar un comité para escribir una especificación. ¿Qué
podía salir mal? Como siempre, todo el mundo intentó meter
cucharada: IBM, Microsoft, Verisign… el resultado fue una sopa
de siglas y tecnologías (SOAP, UDDI, WSDL y un sinfín de ws-*)
realmente complejas cuyas implentaciones fueron
desquiciantemente incompatibles durante años. Y XML. XML
everywhere, maldita sea.
Hasta la basura más grande podría venderse bien con un nombre
tan bueno como ese, y de hecho eso es exactamente lo que pasó.
Pero al menos esa primera generación de web services trajo algo
muy bueno. Como he dicho antes surgieron una serie de
patrones de arquitectura que se basaban en interconectar
aplicaciones independientes, no componentes de una única
aplicación.
En aquella época se llamó a este patrón Service Oriented
Architecture y con el tiempo demostró ser la forma más eficiente
de abrir los sistemas de información al exterior. Habían nacido
las web APIs tal y como las conocemos: un conjunto coherente de
operaciones invocables mediante HTTP.
¡Pero volvamos a la historia de Marc! Está claro que aunque no
se dedicase ya a programar nunca dejó de llevar un techie dentro
y que estaba muy al tanto de cómo se organizaba la arquitectura
de un software complejo. Quería montar su propio negocio y
quería hacerlo como una empresa diseñada desde el principio
para operar en internet, con lo que pidió pasta a un grupo de
amigos (incluyendo al inefable Larry, que aportó unos cuantos
millones de su propio bolsillo) y arrancó su aventura.
Estábamos en 1999, en plena burbuja .com y aunque supongo
que sabes cómo terminó todo (o si quieres, un día te lo cuento) en
retrospectiva está claro que algunas de las personas que se
encontraban detrás de las empresas que protagonizaron esa
bacanal tenían una visión muy clara de hacia dónde iba a
evolucionar el mundo de la tecnología. De alguna manera eran
pioneros en un territorio nuevo en el que el acceso a internet se
había democratizado. Y sí, creo que Marc se encontraba entre
ese grupo de personas.

El Inicio Del Software As A Service

A Marc no le gustaba el software que se utilizaba para gestionar

el perfil de los clientes por parte de los comerciales, el llamado
CRM. En esos años el movimiento Open Source no tenía la
fuerza ideológica de hoy en día y muchas empresas buscaban la
fidelización del cliente básicamente atándolo a su tecnología
(Oracle sigue haciéndolo hoy en día, pero hey, esa es historia
para otro momento). En cualquier caso debido a esta táctica de
secuestro resultaba que integrar un Customer Relationship
Manager con el workflow natural de la empresa era muy
complicado cuando, si te lo paras a pensarlo, resulta que es una
parte esencial del mismo: una acción comercial puede necesitar
programar reuniones (en el calendario) que se celebrarán en
salas (que deben de estar libres), enviar avisos al resto de
miembros involucrados (usando correo o mensajería), requerir la
aprobación de condiciones de venta (por parte del responsable
correspondiente), etc, etc.
Nuestro protagonista decidió montar una alternativa basada en
web que se pagase por suscripción. Solo esto ya fue una
revolución y en cierto sentido dio el impulso definitivo al primer
tipo de cloud público que se popularizó: el Software as a
Serviceen el que te cobran por uso. Como modelo de negocio se
había aplicado al correo electrónico y poco más pero ahora
estábamos hablando de un producto de software clásico, una
aplicación que englobaba mucho más que una funcionalidad
concreta.
Pero la killer feature de su producto fue la facilidad que aportaba
para enlazarlo con cualquier otro sistema que tuviese la
empresa: a principios del año 2000 anunciaron la publicación
de su Application Program Interface, es decir, la lista y
especificación de los web services soportados. Mediante ellos
cualquier programa que fuese capaz de invocar HTTP podía
interactuar con este sistema intercambiando datos y ejecutando
acciones sin tener que instalar nada en el código del CRM.
Rápidamente surgió un ecosistema de funcionalidades creadas
por terceros que enriqueció las que la criatura de Marc
implementaba. El resto es eso, historia: se me había olvidado
comentarte que el nombre de la empresa es Salesforce y que hoy
en día tiene un valor de 49.000 millones de euros. No los pillo
todos los días. Aquí tienes una foto reciente del bueno de Marc
sacada de la Wikipedia:

Muy poco tiempo después le siguieron eBay, Amazon, Yahoo,

Google, Facebook, Flickr, Twitter y otras empresas. En pocos
años internet se convirtió en territorio API y nunca dejes de visitar
de vez en cuando programmableweb.com para maravillarte con
perlas como la que te permite conocer mejor a Chuck Norris o (si
tu estómago lo admite) pedir una pizza en Domino’s. Tampoco
están tan malas. Si hace días que no comes.
Así que de alguna manera Salesforce ha impulsado tanto como
Google con Gmail o Amazon con AWS la tecnología cloud
aunque por el camino Marc y Larry tuvieron algunos problemillas
con su amistad. Nada que no se pueda solucionar comprando
otro coche o pasando una semana en el yate, pero bueno,
tuvimos algunos episodios divertidos cuando Marc se enteró de
que Larry estaba creando su propio CRM en Oracle y lo echó del
consejo directivo de Salesforce o cuando Larry canceló

Un servicio web (en inglés, web service o web services) es una

tecnología que utiliza un conjunto de protocolos y estándares que
sirven para intercambiar datos entre aplicaciones. Distintas
aplicaciones de software desarrolladas en lenguajes de programación
diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar los
servicios web para intercambiar datos en redes de
ordenadores como Internet. La interoperabilidad se consigue mediante
la adopción de estándares abiertos. Las
organizaciones OASIS y W3C son los comités responsables de la
arquitectura y reglamentación de los servicios Web.
El W3C define un servicio web como:
Un servicio web es un sistema software diseñado para soportar la interacción
máquina-a-máquina, a través de una red, de forma interoperable. Cuenta con una
interfaz descrita en un formato procesable por un equipo informático
(específicamente en WSDL), a través de la que es posible interactuar con el
mismo mediante el intercambio de mensajes SOAP, típicamente transmitidos
usando serialización XML sobre HTTP conjuntamente con otros estándares web.
W3C1
Para mejorar la interoperabilidad entre distintas implementaciones de
servicios Web se ha creado el organismo WS-I, encargado de
desarrollar diversos perfiles para definir de manera más exhaustiva
estos estándares. Es una máquina que atiende las peticiones de los
clientes web y les envía los recursos solicitados.

Una historia muy corta de servicios web

Los servicios web evolucionaron a partir del mecanismo RPC (Remote Procedure
Call) en DCE (Distributed Computing Environment), un marco para el desarrollo
de software desde principios de la década de 1990. DCE incluye un sistema de
archivos distribuido (DCE / DFS) y un sistema de autenticación basado en
Kerberos. Aunque DCE tiene sus orígenes en el mundo Unix, Microsoft realizó
rápidamente su propia implementación conocida como MSRPC, que a su vez sirvió
como infraestructura para la comunicación entre procesos en Windows. Las
tecnologías y servicios COM / OLE (Modelo de objetos comunes / Vinculación e
incrustación de objetos) de Microsoft se crearon sobre una base DCE / RPC. Hay
ironía aquí. DCE diseñó RPC como una forma de hacer computación distribuida (es
decir, computación en distintos dispositivos físicos), y Microsoft adaptó
inteligentemente RPC para soportar la comunicación entre procesos, en forma de
infraestructura COM,

Los frameworks de primera generación para sistemas de objetos distribuidos,

CORBA (Common Object Request Broker Architecture) y DCOM (Distributed
COM) de Microsoft, están anclados en el marco de procedimientos DCE /
RPC. Java RMI (Invocación de método remoto) también se deriva de DCE / RPC, y
las llamadas a métodos en Java EE (Enterprise Edition), específicamente en
Session y Entity EJB (Enterprise Java Bean), son llamadas Java RMI. Java EE
(anteriormente J2EE) y DotNet de Microsoft son marcos de segunda generación
para sistemas de objetos distribuidos, y estos marcos, como CORBA y DCOM antes
que ellos, rastrean su ascendencia hasta DCE / RPC. Por cierto, DCE / RPC no está
muerto. Varias utilidades populares del sistema (por ejemplo, el archivo Samba y el
servicio de impresión para clientes Windows) usan DCE / RPC.
De DCE / RPC a XML-RPC
DCE / RPC tiene la arquitectura familiar de cliente / servidor en la que un cliente
invoca un procedimiento que se ejecuta en el servidor. Los argumentos se pueden
pasar del cliente al servidor y los valores de retorno se pueden pasar del servidor al
cliente. El marco es neutral en cuanto a plataforma y lenguaje en principio, aunque
fuertemente inclinado hacia C en la práctica. DCE / RPC incluye utilidades para
generar artefactos de cliente y servidor (stubs y esqueletos, respectivamente). DCE
/ RPC también proporciona bibliotecas de software que ocultan los detalles del
transporte. De interés ahora es el documento IDL (lenguaje de definición de
interfaz) que actúa como el contrato de servicio y es una entrada a las utilidades
que generan artefactos en apoyo de las llamadas DCE / RPC. Un documento IDL
puede ser breve e ir al grano (ver Ejemplo 1-1 ).

Ejemplo 1-1. Un documento IDL de muestra que declara la echofunción

/* echo.idl */
[uuid(2d6ead46-05e3-11ca-7dd1-426909beabcd), version(1.0)]
interface echo {
const long int ECHO_SIZE = 512;
void echo(
[in] handle_t h,
[in, string] idl_char from_client[ ],
[out, string] idl_char from_server[ECHO_SIZE]
);
}

La interfaz IDL llamado echo, identificado con un UUID generado por máquina
(identificador único universal), declara una única función con el mismo
nombre, echo. Los nombres son arbitrarios y no necesitan ser los
mismos. La echofunción espera tres argumentos, dos de los cuales
soninparámetros (es decir, entradas en el procedimiento remoto) y uno de los
cuales es un outparámetro (es decir, una salida del procedimiento remoto). El
primer argumento, de tipo incorporado handle_t, es obligatorio y apunta a una
estructura de datos RPC. La función echopodría pero no devuelve un valor, porque
la cadena con eco se devuelve como un outparámetro. El IDL especifica la sintaxis
de invocación paraechofunción, que es la única operación en el servicio. Excepto
por las anotaciones entre corchetes a la izquierda de los tres echoparámetros, la
sintaxis del IDL es esencialmente la sintaxis C. El documento IDL es un precursor
del documento WSDL (lenguaje de descripción de servicio web) que proporciona
una especificación formal de un servicio web y sus operaciones. El documento
WSDL se trata en detalle en el Capítulo 4sobre servicios basados en SOAP.

También hay un giro de Microsoft en la historia de IDL. Un control ActiveX en

Windows es una DLL (Biblioteca de enlaces dinámicos) con una biblioteca de
tipos incrustada , que a su vez es un archivo IDL compilado. Por ejemplo, suponga
que un control ActiveX de calendario está conectado a un navegador. El navegador
puede leer el typelib , que contiene la sintaxis de invocación para cada operación
(por ejemplo, mostrar el mes siguiente) en el control. Un control ActiveX es, por lo
tanto, una porción de software que incorpora su propia interfaz. Este es otro uso
local inspirado de una tecnología diseñada para la informática distribuida.

A fines de la década de 1990, Dave Winer, de UserLand Software, desarrolló XML-

RPC, una innovación tecnológica que tiene un reclamo tan bueno como cualquier
otro para marcar el nacimiento de los servicios web. XML-RPC es un sistema RPC
muy liviano con soporte para tipos de datos elementales (básicamente, los tipos C
integrados junto con booleanun datetimetipo y) y algunos comandos simples. La
especificación original tiene aproximadamente siete páginas de longitud. Las dos
características clave son el uso de la clasificación / descomposición de XML para
lograr la neutralidad del lenguaje y la confianza en HTTP (y, más tarde, SMTP)
para el transporte. El término cálculo de referencias se refiere a la conversión de un
objeto en memoria (por ejemplo, un Employeeobjeto en Java) a algún otro formato
(por ejemplo, un documento XML); desordenar se refiere al proceso inverso de
generar un objeto en memoria a partir de, en este ejemplo, un documento XML. La
distinción mariscal / unmarshal está en algún lugar entre cercana e idéntica a la
distinción serializar / deserializar. Mi costumbre es usar las distinciones
 indistintamente. En cualquier caso, el servicio O'Reilly Meerkat de cable abierto y
la plataforma de publicación de WordPress se basan en XML-RPC.

Dos diferencias clave separan XML-RPC, por un lado, de DCE / RPC y sus retoños,
por otro lado:

o Las cargas útiles de XML-RPC son texto, mientras que las cargas de DCE / RPC son binarias. El
texto es relativamente fácil de inspeccionar y procesar con herramientas estándar y fácilmente
disponibles, como editores y analizadores.
o El transporte XML-RPC utiliza HTTP en lugar de un sistema propietario. Para admitir XML-RPC,
un lenguaje de programación requiere solo una biblioteca HTTP estándar junto con bibliotecas para
generar, analizar, transformar y procesar XML.

Como tecnología RPC, XML-RPC admite el patrón de solicitud / respuesta. Aquí

está la solicitud XML para invocar, en una máquina remota, la función Fibonacci
con un argumento de 11. Este argumento se pasa como un entero de 4 bytes,
como <i4>indica la etiqueta de inicio XML:

<?xml version="1.0">
<methodCall>
<methodName>fib<methodName>
<params>
<param><value><i4>11</i4></value></param>
</params>
</methodCall>

El número entero 11 aparece en el mensaje XML-RPC como texto. Una biblioteca

XML-RPC en el extremo receptor necesita extraer 11 como texto y luego convertir el
texto en un entero de 4 bytes en el lenguaje receptor como Go o Java. Incluso este
breve ejemplo ilustra la idea de tener XML, en particular los tipos de datos
expresados en XML, que sirven como mecanismo de nivelación entre dos lenguajes
diferentes involucrados en un intercambio XML-RPC.
XML-RPC es deliberadamente bajo y liviano. SOAP, un dialecto XML derivado
directamente de XML-RPC, es considerablemente más pesado en peso. Desde el
inicio, XML-RPC se enfrentó a la competencia de los sistemas DOA de segunda
generación, como Java EE (J2EE) y AspNet. La siguiente sección considera los
desafíos inherentes a los sistemas DOA. Estos desafíos mantuvieron y
eventualmente intensificaron el interés en enfoques más livianos para la
informática distribuida: servicios web modernos.

Arquitectura de objetos distribuidos: un ejemplo de

Java
¿Qué ventajas tienen los servicios web sobre las tecnologías DOA como Java
RMI? Esta sección aborda la pregunta con un ejemplo. Java RMI (incluidas las
construcciones EJB de sesión y entidad construidas en Java RMI) y DotNet
Remoting son ejemplos de sistemas de objetos distribuidos de segunda
generación. Considere lo que requiere un cliente Java RMI para invocar un método
declarado en una interfaz de servicio como este:

import java.util.List;
public interface BenefitsService extends java.rmi.Remote {
public List<Benefit> getBenefits(Emp emp) throws RemoteException;
}

La interfaz parece engañosamente simple, ya que declara solo el método

nombrado getBenefits, pero la interfaz también sugiere lo que hace que una
arquitectura de objetos distribuidos sea tan complicada. Un cliente en contra de
esto BenefitsServicerequiere un stub Java RMI, una instancia de una clase que
implementa la BenefitsServiceinterfaz. El código auxiliar se descarga
automáticamente del servidor al cliente como parte de la configuración de Java
RMI (consulte la Figura 1-3 ).
 Figura 1-3. Descargar un trozo en Java RMI

Una vez que se realiza la configuración del código auxiliar, el getBenefitsmétodo

se ejecuta como un método de código auxiliar; es decir, el código auxiliar actúa
como el objeto del lado del cliente que realiza una llamada de método remoto a
través de uno de los métodos encapsulados del código auxiliar. La llamada tiene la
siguiente sintaxis:

Emp fred = new Emp();

//...
List<Benefit> benefits = rmiStub.getBenefits(fred); // rmiStub =
reference

Invocar el getBenefitsmétodo requiere que los códigos de bytes para varias clases
Java, estándar y definidos por el programador, estén disponibles en la máquina del
cliente. Para comenzar, el cliente necesita la clase Emp, el tipo de argumento para
el getBenefitsmétodo y la clase Benefit, el tipo de miembro para
el Listque getBenefitsdevuelve el método . Supongamos que la clase Empcomienza
así:

public class Emp {

private Department department;
private List<BusinessCertification> certifications;
private List<ClientAccount> accounts;
private Map<String, Contact> contacts;
...
}

Los tipos estándar de Java como Listy Mapya están disponibles en el lado del
cliente porque el cliente es, por supuesto, una aplicación Java. El reto consiste en
los tipos adicionales, definidos por el programador, tales
como Department,BusinessCertification, ClientAccount, y Contactque son
necesarios para apoyar la invocación del lado del cliente de un método de ejecutar
remotamente. La configuración en el lado del cliente para habilitar una llamada
remota como:

Emp fred = new Emp();

// set properties, etc.
List<EmpBenefits> fredBenefits = rmiStub.getBenefits(fred);

es significativo, con muchos y muchos bytes necesarios para pasar del servidor al
cliente solo para la configuración. Cualquier cosa así de complicada es, por
supuesto, propensa a problemas tales como problemas de versiones y errores
directos en las llamadas a métodos remotos.

Java RMI utiliza el transporte de propiedad / desensamblado y el transporte de

propiedad, y DotNet hace lo mismo. Hay bibliotecas de terceros para la
interoperabilidad entre los dos marcos. Sin embargo, se puede esperar que un
servicio Java RMI tenga principalmente clientes Java, y un servicio DotNet
Remoting puede tener principalmente clientes DotNet. Los servicios web
representan un movimiento hacia la estandarización, la simplicidad y la
interoperabilidad.

Servicios web al rescate

Los servicios web simplifican las cosas en informática distribuida. Por un lado, el
cliente y el servicio normalmente intercambian XML o documentos equivalentes,
es decir, texto . Si es necesario, se pueden intercambiar bytes que no sean de texto,
pero las cargas útiles preferidas son texto. El texto intercambiado puede
inspeccionarse, validarse, transformarse, persistirse y procesarse de otro modo
utilizando herramientas fácilmente disponibles, no propietarias y, a menudo,
gratuitas. Cada lado, cliente y servicio, simplemente necesita una biblioteca de
software local que vincule tipos específicos de idioma, como
el Stringesquema Java a XML o tipos comparables, en este caso xsd:string. (En el
nombre calificado xsd:string, xsdes una abreviatura de espacio de nombres
y stringes un nombre local. De interés aquí es quexsd:stringes un tipo XML en
lugar de un tipo Java.) Dados estos enlaces Java / XML, los módulos de biblioteca
relativamente sencillos pueden convertirse de uno a otro, de Java a XML o de XML
a Java (consulte la Figura 1-4 ).

Figura 1-4. Conversiones Java / XML

El procesamiento en el lado del cliente, como en el lado del servicio, solo requiere
bibliotecas y utilidades disponibles localmente. Las complejidades, por lo tanto,
pueden aislarse en los puntos finales (el servicio y las aplicaciones del cliente junto
con sus bibliotecas de soporte) y no necesitan filtrarse en los mensajes
intercambiados. Finalmente, los servicios web están disponibles a través de HTTP,
un protocolo sin propiedad que se ha convertido en una infraestructura estándar y
ubicua; HTTP en particular viene con una extensión de seguridad, HTTPS, que
proporciona servicios de seguridad multifacéticos.

En un servicio web, el cliente solicitante y el servicio no necesitan estar codificados

en el mismo idioma o incluso en el mismo estilo de idioma. Los clientes y servicios
pueden implementarse en estilos de lenguaje orientado a objetos, de
procedimiento, funcional y de otro tipo. Los idiomas en cualquiera de los extremos
se pueden escribir de forma estática (por ejemplo, Java y Go) o de forma dinámica
(por ejemplo, JavaScript y Ruby). Las complejidades de los trozos y esqueletos, la
serialización y deserialización de objetos codificados en algún formato propietario,
dan paso a representaciones de mensajes relativamente simples basadas en texto
intercambiados a través de transportes estándar como HTTP. Los mensajes
mismos son neutrales; no tienen prejuicios hacia un idioma en particular o incluso
una familia de idiomas.

El primer ejemplo de código en este capítulo, y todos los ejemplos de código en

el Capítulo 2 y el Capítulo 3 , involucran servicios de estilo REST. En consecuencia,
la siguiente sección analiza lo que significa REST y por qué el servicio de estilo
REST se ha vuelto tan popular. Desde una perspectiva histórica, los servicios de
estilo REST pueden verse como una reacción a la creciente complejidad de los
basados en SOAP.

http://www.jtech.ua.es/j2ee/publico/servc-web-2012-13/sesion01-apuntes.html

http://www.hipertexto.info/documentos/serv_web.htm

https://www.academia.edu/20231855/Funcionamiento_de_Web_Service?auto=download

 Acerca del blog

Web Services
Posted on junio 14, 2007. Filed under: Uncategorized |

Es una colección de protocolos y estándares que sirven para intercambiar datos entre
aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de
programación diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar los
servicios web para intercambiar datos en redes como Internet. La interoperabilidad se
consigue mediante la adopción de estándares abiertos y los responsables de esto son
OASIS y W3C.

Los estándares utilizados los web services son:

– Web Services Protocol Stack
– XML (Extensible Markup Language)
– SOAP (Simple Object Access Protocol) o XML-RPC (XML Remote Producer Call)
– HTTP, FTP o SMTP
– WSDL (Web Services Description Languages)
– UDDI (Universal Description, Discovery and Integration)
 – WS-Security (Web Service Security)
Ventajas de los Web Services:
– Aportan interoperabilidad entre aplicaciones de software independientemente de
sus propiedades o de las plataformas sobre las que se instalen.
– Los servicios Web fomentan los estándares y protocolos basados en texto, que
hacen más fácil acceder a su contenido y entender su funcionamiento.
– Al apoyarse en HTTP, los servicios Web pueden aprovecharse de los sistemas de
seguridad firewall sin necesidad de cambiar las reglas de filtrado.
Desventajas de los Web Services:
– Para realizar transacciones no pueden compararse con los estándares abiertos
de computación distribuida como CORBA(Common Object Request Broker
Architecture).
– Su rendimiento es bajo si se compara con otros modelos de computación
distribuida, como RMI (Remote Method Invocation), CORBA, o DCOM (Distributed
Component Object Model).
– Al apoyarse en HTTP, pueden esquivar medidas de seguridad basadas
en firewall cuyas reglas tratan de bloquear la comunicación entre programas.
– Existe poca información de servicios web para algunos lenguajes de
programación
Plataformas:
Los servidores de aplicaciones para servicios Web disponibles son:
– Axis y el servidor Jakarta Tomcat (de Apache)
– ColdFusion MX de Macromedia
– Java Web Services Development Pack (JWSDP) de Sun Microsystems (basado
en Jakarta Tomcat)
– JOnAS (parte de ObjectWeb una iniciativa de código abierto)
– Microsoft .NET
– Novell exteNd (basado en la plataforma J2EE)
– WebLogic
– WebSphere
– Zope es un servidor de aplicaciones Web orientado a objetos desarrollado en
el lenguaje de programación Python
– VERASTREAM de AttachmateWRQ para modernizar o integrar aplicaciones
host IBM y VT
– Mono