El marco de invocación de servicios web (WSIF) admite una API de Java (interfaz de programación de aplicaciones) simple y flexible para invocar cualquier servicio descrito en el lenguaje de descripción de servicios web (WSDL).
Con WSIF, WSDL puede convertirse en la pieza central de un marco de integración para acceder a software que se ejecuta en diversas plataformas que utilizan diferentes protocolos. El software debe describirse mediante WSDL y debe incluir un enlace en su descripción [ aclaración necesaria ] , para el cual el marco WSIF del cliente tiene un proveedor. WSIF define y viene empaquetado con proveedores para protocolos locales Java, Enterprise JavaBeans (EJB), Java Message Service (JMS) y Java EE Connector Architecture (JCA), lo que significa que un cliente puede definir un servicio accesible a través de EJB o Java Message Service directamente como un enlace WSDL y acceder a él de forma transparente mediante WSIF, utilizando la misma API que se usaría para un servicio SOAP o una clase Java local.
En WSDL, un enlace define cómo realizar la correspondencia entre el PortType abstracto y un formato y protocolo de servicio real. Por ejemplo, el enlace SOAP define el estilo de codificación, el encabezado SOAPAction , el espacio de nombres del cuerpo (el targetURI), etc.
WSDL permite múltiples implementaciones para un servicio web y múltiples puertos que comparten el mismo PortType. En otras palabras, WSDL permite que la misma interfaz tenga enlaces a servicios como SOAP e IIOP .
WSIF proporciona una API para permitir que el mismo código de cliente acceda a cualquier enlace disponible. Dado que el código de cliente se puede escribir en PortType, la elección del puerto y el enlace que utiliza se puede determinar mediante la implementación, los ajustes de configuración o el código.
El WSIF utiliza proveedores para admitir estos múltiples enlaces WSDL. Un proveedor es un fragmento de código que admite una extensión WSDL y permite la invocación del servicio a través de esa implementación en particular. Los proveedores WSIF utilizan la especificación del proveedor de servicios JAR de J2SE, lo que los hace detectables en tiempo de ejecución .
Los clientes pueden utilizar nuevas implementaciones y delegar la elección del puerto a la infraestructura y al tiempo de ejecución, lo que permite elegir la implementación en función de las características de calidad del servicio o la política comercial.
WSIF define extensiones de enlace adicionales para que los Enterprise JavaBean (EJB), las clases Java locales, el software accesible a través de colas de mensajes mediante la API de Java Message Service (JMS) y el software que se puede invocar mediante la arquitectura de Java Connector también se puedan describir en WSDL. WSIF incluye proveedores que permiten la invocación transparente en función de la descripción WSDL correspondiente.
WSIF permite a los desarrolladores interactuar con representaciones abstractas de servicios web a través de sus descripciones WSDL en lugar de trabajar directamente con las API del Protocolo simple de acceso a objetos (SOAP), que es el modelo de programación habitual. Con WSIF, los desarrolladores pueden trabajar con el mismo modelo de programación independientemente de cómo se implemente y acceda al servicio web.
WSIF permite la invocación sin stubs o completamente dinámica de un servicio web, basándose en el examen de los metadatos sobre el servicio en tiempo de ejecución. También permite que las implementaciones actualizadas de un enlace se conecten a WSIF en tiempo de ejecución, lo que permite que el servicio que realiza la llamada posponga la elección de un enlace hasta el tiempo de ejecución.
Se basa estrechamente en WSDL, lo que le permite invocar cualquier servicio que pueda describirse en el lenguaje.
Si un sistema de software empresarial complicado consta de varias piezas de software, desarrolladas durante un período de décadas (EJB, aplicaciones heredadas a las que se accede mediante la arquitectura de conector de Java, servicios SOAP alojados en servidores externos, código antiguo al que se accede mediante middleware de mensajería), es necesario escribir aplicaciones de software que utilicen todas estas piezas para hacer cosas útiles, donde las diferencias en los protocolos y la movilidad del software entran en conflicto entre sí.
Si el software se traslada a un servidor diferente, el código se rompe. Las bibliotecas SOAP utilizadas cambian (por ejemplo, al pasar de usar Apache SOAP a Apache Axis, ya que emplea una API SOAP ahora obsoleta). Algo que antes era accesible como un EJB ahora está disponible a través de middleware de mensajería mediante JMS; nuevamente, el código que utiliza el software debe repararse, o si uno tiene un EJB que se ofrece como un servicio SOAP a clientes externos. El uso de SOAP da como resultado una pérdida de rendimiento en comparación con el acceso directo al EJB.
WSIF resuelve estos problemas al permitir que WSDL sirva como una descripción normalizada de software dispar y que los usuarios accedan a este software sin depender de un protocolo o ubicación específicos. La separación de la API del protocolo real también significa que hay flexibilidad: se pueden cambiar los protocolos, la ubicación, etc. sin tener que volver a compilar el código del cliente. Si un servicio SOAP disponible externamente se vuelve disponible como un EJB, los usuarios pueden usar RMI/IIOP cambiando la descripción del servicio (el WSDL), sin realizar ninguna modificación en las aplicaciones que usan el servicio. Se puede explotar la extensibilidad de WSDL, su capacidad para ofrecer múltiples enlaces para el mismo servicio, decidir sobre un enlace en tiempo de ejecución, etc.
Axis es una implementación de SOAP. Incluye una infraestructura del lado del servidor para implementar implementaciones de servicios web y luego enrutar mensajes SOAP entre los clientes y esas implementaciones. También implementa la especificación JAX-RPC para invocar servicios SOAP.
WSIF es similar a la parte cliente de Axis, en el sentido de que se utiliza para invocar servicios. Sin embargo, la API de WSIF está controlada por WSDL y es independiente del protocolo; permite que se conecten códigos específicos del protocolo ("proveedores"). Para invocar servicios SOAP, WSIF se incluye con un proveedor de Axis, que utiliza las API de Axis (es decir, JAX-RPC) para realizar la invocación. Por lo tanto, WSIF funciona a un nivel más abstracto que Axis.
JAX-RPC es una API para invocar servicios RPC basados en XML; el alcance actual se limita a la invocación de servicios SOAP. WSIF es una API para invocar servicios descritos en WSDL, ya sean servicios SOAP o no (por ejemplo, WSIF define enlaces WSDL para que los EJB, el software empresarial accesible mediante JMS o la arquitectura Java Connector, así como las clases Java locales, puedan describirse como servicios WSDL de primera clase y luego invocarse mediante la misma API WSIF independiente del protocolo ).