Objetivos de WSIF

WSIF tiene como objetivo ampliar la flexibilidad proporcionada por los servicios SOAP a un modelo general para invocar los servicios web, independientemente de los protocolos subyacentes de acceso o enlace.

Dado que los enlaces SOAP para servicios web forman parte de la especificación WSDL (Lenguaje de descripción de servicios web), cuando la mayoría de los desarrolladores piensan en utilizar un servicio web, piensan inmediatamente en ensamblar un mensaje SOAP y enviarlo a través de la red al punto final de servicio, utilizando una API de cliente SOAP. Por ejemplo: utilizando Apache SOAP, el cliente crea y cumplimenta un objeto de llamada que encapsula el punto final de servicio, la identificación de la operación SOAP a invocar, los parámetros a enviar, etc.

Por lo tanto, los objetivos de la Infraestructura de invocación de servicios Web (WSIF) son:

Los servicios Web son algo más que servicios SOAP

Puede desplegar como un servicio web cualquier aplicación que tenga una descripción basada en WSDL de sus aspectos funcionales y protocolos de acceso. Si utiliza el entorno Java™ Platform, Enterprise Edition (Java EE), la aplicación está disponible a través de varios transportes y protocolos.

Por ejemplo, puede tomar un procedimiento almacenado de base de datos, exponerlo como un bean de sesión sin estado y, a continuación, desplegarlo en un direccionador SOAP como un servicio SOAP. En cada fase, el servicio fundamental es el mismo. Todo lo que cambia es el mecanismo de acceso: de JDBC (Java DataBase Connectivity) a RMI-IIOP (Remote Method Invocation over Internet Inter-ORB Protocol) y luego a SOAP.

La especificación WSDL define un enlace SOAP para los servicios web, pero se pueden añadir extensiones de enlace al WSDL para que, por ejemplo, se pueda ofrecer un enterprise bean como un servicio web que utiliza RMI-IIOP como protocolo de acceso. Incluso puede tratar una clase Java individual como un servicio web, invocando un método Java de hebra interna como protocolo de acceso. Con esta definición más amplia de servicio web, es necesario un mecanismo independiente de los enlaces para invocar el servicio.

Enlazar el código de cliente a una implementación de protocolo determinada resulta limitante

Si para una implementación de protocolo determinada el código de cliente está enlazado fuertemente a la biblioteca del cliente, puede resultar difícil de mantener.

Por ejemplo, si se mueve de Apache SOAP a JMS (Java Message Service) o enterprise bean, el proceso puede tardar mucho tiempo y requerir mucho esfuerzo. Para evitar estos problemas, necesita un mecanismo independiente de la implementación del protocolo para invocar el servicio.

Incorporar nuevos enlaces al código de cliente resulta difícil

Si desea que una aplicación que utilice un protocolo personalizado funcione como un servicio web, puede añadir elementos de extensión a WSDL para definir nuevos enlaces. Pero alcanzar esta posibilidad es una tarea compleja.

Por ejemplo, debe diseñar las API de cliente para utilizar este protocolo. Si la aplicación utiliza sólo la interfaz abstracta del servicio web, debe escribir herramientas que generen los archivos stub que habiliten una capa de abstracción. Estas tareas requieren mucho tiempo y esfuerzo. Lo que necesita es un mecanismo de invocación de servicio que puede utilizar para actualizar los enlaces existentes y para añadir enlaces nuevos.

Se pueden utilizar varios enlaces de forma flexible

Para poder beneficiarse de los servicios web que ofrecen varios enlaces, necesita un mecanismo de invocación de servicio que puede conmutar entre los enlaces de servicio disponibles durante la ejecución, sin tener que generar o recompilar un archivo stub.

Imagine que ha desplegado correctamente una aplicación que utiliza un servicio web que ofrece varios enlaces. Por ejemplo, imagine que tiene un enlace SOAP para el servicio y un enlace Java local que le permite tratar la implementación de servicio local (una clase Java) como servicio web.

El enlace Java local para el servicio solamente se puede utilizar si el cliente se despliega en el mismo entorno que el servicio. En este caso, resulta más eficaz comunicarse con el servicio realizando llamadas Java directas que utilizando el enlace SOAP.

Si los clientes pueden conmutar el enlace utilizado basándose en la información de tiempo de ejecución, pueden elegir el enlace disponible más eficiente para cada situación.

Un entorno de servicios web más libre habilita los intermediarios

Los servicios Web ofrecen a los responsables de la integración de aplicaciones un paradigma de difícil asociación. En estos entornos, los intermediarios pueden resultar muy potentes.

Los intermediarios son aplicaciones que interceptan los mensajes que fluyen entre un solicitante de servicio y un servicio web de destino y realizan algunas tareas intermedias (por ejemplo registro, alta disponibilidad o transformación) antes de pasar el mensaje. La infraestructura de invocación de servicios Web (WSIF) se ha diseñado para crear intermediarios que sean al mismo tiempo sencillos y realizables. Utilizando WSIF, los intermediarios mejoran la invocación del servicio sin necesidad de programación específica del transporte.


Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwsf_goals
File name: cwsf_goals.html