Los servicios web son estándares definidos para el intercambio de datos a través de la Web. Esto no quiere decir que los servicios web estarán expuestos a Internet, sólo que existe un conjunto acordado de "estándares web" que muchos productos admiten. Al decidir qué norma adoptar, lo más importante a considerar suele ser el asesoramiento del personal técnico.
Es posible que le recomienden, en orden, un estándar que sea más fácil de implementar, que tenga el soporte técnico más amplio para el producto y que tenga más probabilidades de funcionar bien en su entorno. Para tener una implementación SOA exitosa que resista la prueba del tiempo y continúe escalando en el futuro, estos tres factores son extremadamente importantes.
WS-I
La Organización de Interoperabilidad de Servicios Web (WS-I) se especializa en desarrollar mejores prácticas para estándares web para garantizar la interoperabilidad entre diferentes sistemas operativos, plataformas o lenguajes de programación. WS-I es responsable de definir documentos de mejores prácticas, como la seguridad de los servicios web y las especificaciones técnicas de procesamiento de servicios web. Esta documentación ayuda a los desarrolladores y las empresas a cumplir con las prácticas que otros utilizan para garantizar la operatividad del usuario.
WS-I también publica especificaciones técnicas, conjuntos de pruebas y ejemplos sobre cómo implementar estos protocolos. De hecho, WS-I es un organismo rector formado por muchas organizaciones como Microsoft e IBM, y su misión es promover servicios web interoperables.
Acuerdo de uso
Los servicios web se basan en protocolos para garantizar que la comunicación sea significativa. El contenido de los datos enviados entre servicios debe acordarse previamente para garantizar que ambas partes sepan qué contenido se recibe. SOAP es un ejemplo del protocolo más utilizado a la hora de intercambiar datos. SOAP utiliza el lenguaje de programación XML, lo que permite a ambas partes decodificar lo que se envía y formatear la información enviada de un lado a otro.
ilustrar
Pronto cubriremos algo de arquitectura y también nos referiremos a algunos protocolos de servicios web. Es importante no confundir estas dos cosas. Entonces, presentémoslo brevemente a continuación.
Las arquitecturas de software como REST y RPC no son protocolos. Son métodos que especifican cómo se va a implementar el acuerdo.
WSDL (lenguaje de descripción de servicios web) es un lenguaje que se utiliza para describir un servicio web específico de forma formateada para que las aplicaciones puedan analizar el servicio. El WSDL en sí no proporciona ninguna funcionalidad en forma de interacciones de servicios web.
Los propios protocolos, como SOAP, XML-RPC o DCOM, definen exactamente cómo se entregan los mensajes y cómo un programa entiende los datos que recibe.
Hay dos tipos principales de arquitecturas en SOA: la familia de protocolos RPC y el enfoque de Transferencia de Estado Representacional (REST).
RPC
El método de llamada a procedimiento remoto (RPC) permite a los programadores llamar a recursos de un sistema remoto de la misma manera que "llaman" a recursos locales cuando programan en un sistema. La desventaja de los servicios de estilo RPC es que las personas tienden a usarlos como si estuvieran familiarizados con el lenguaje de programación de la plataforma específica. Incluso es fácil llamar a un procedimiento remoto si es el mismo que el procedimiento local.
Esta lógica viola el concepto de "acoplamiento flojo". El concepto de acoplamiento flexible en realidad significa que el proceso remoto no debe depender de ningún sistema operativo o lenguaje de programación específico.
SOAP es el protocolo sucesor de XML-RPC y es solo una llamada a procedimiento remoto que contiene su información en XML. SOAP utiliza el protocolo HTTP para enviar datos, lo cual es agradable y simple, sin embargo, tiene algunas desventajas. A pesar de esto, la mayoría de los servicios web hoy en día todavía utilizan el protocolo HTTP para la comunicación, ya que están construidos utilizando el protocolo SOAP.
DESCANSAR
El enfoque de transferencia de estado representacional (REST) es fundamentalmente diferente de las llamadas a procedimientos remotos porque funciona en un nivel diferente. Una llamada REST se parece a cualquier otra solicitud web a través del protocolo HTTP, mientras que una llamada RPC parece una llamada de función estándar. El objetivo de REST es operar con recursos estables en lugar de mensajes individuales, lo que da como resultado una forma de interacción más estándar y ampliamente entendida, muy parecida al propio protocolo HTTP. REST se encarga de transferir fragmentos de datos simples, mientras que RPC transfiere procesos complejos.
¿Debería utilizarse REST o RPC?
La cuestión de si se debe utilizar REST es ciertamente buena. Parece el camino del futuro. Sin embargo, su SOA debe integrarse en cada pieza de software que utiliza actualmente. La adopción de REST ha sido lenta, principalmente debido al soporte de servicios web. Aunque un sistema REST puede usar WSDL para describir un mensaje SOAP a través de HTTP, no hay suficiente soporte para usarlo. Por ejemplo, Apache ni siquiera admite los métodos necesarios para utilizar REST sin instalar el módulo complementario.
Existen otros estándares que no forman parte de la familia de servicios web. Pero, como era de esperar, estos estándares no cuentan con un apoyo generalizado. Jini, WCF y CORBA son algunos ejemplos. Cuando un proveedor le ofrece un producto que sólo admite una de las tecnologías anteriores, usted quiere huir, no marcharse. Los servicios web ahora cuentan con un amplio soporte. El uso de servicios web no hará más que crecer. Se dice que la propia SOA es nueva, inestable y arriesgada. Sin embargo, estos riesgos pueden mitigarse en gran medida si se elige un estándar de servicios web adecuado que cuente con un amplio soporte técnico.
Finalmente, apegarse al SOAP de la vieja escuela en lugar de algún tipo de sistema estilo RPC es actualmente un mecanismo viable para construir SOA utilizando servicios web. Si hace esto, reducirá significativamente sus posibilidades de depender de un proveedor.