Web Services Invocation Framework

This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages) This article may be too technical for most readers to understand. Please help improve it to make it understandable to non-experts, without removing the technical details. (September 2014) (Learn how and when to remove this message) This article may have confusing or ambiguous abbreviations. Please review the Manual of Style, help improve this article, and discuss this issue on the talk page. (March 2012) (Learn how and when to remove this message) This article includes a list of references, related reading, or external links, but its sources remain unclear because it lacks inline citations. Please help improve this article by introducing more precise citations. (November 2014) (Learn how and when to remove this message) This article contains promotional content. Please help improve it by removing promotional language and inappropriate external links, and by adding encyclopedic text written from a neutral point of view. (December 2014) (Learn how and when to remove this message) (Learn how and when to remove this message)

The Web Services Invocation Framework (WSIF) supports a simple and flexible Java API (Application Programming Interface) for invoking any Web Services Description Language (WSDL)-described service.

Using WSIF, WSDL can become the centerpiece of an integration framework for accessing software running on diverse platforms which use different protocols. The software needs to be described using WSDL and have a binding included in its description^{[clarification needed]} ,that the client's WSIF framework has a provider for. WSIF defines and comes packaged with providers for local Java, Enterprise JavaBeans (EJB), Java Message Service (JMS), and Java EE Connector Architecture (JCA) protocols, which means that a client can define an EJB or a Java Message Service-accessible service directly as a WSDL binding and access it transparently using WSIF, using the same API one would use for a SOAP service or a local Java class.

In WSDL, a binding defines how to map between the abstract PortType and a real service format and protocol. For example, the SOAP binding defines the encoding style, the SOAPAction header, the namespace of the body (the targetURI), and so forth.

WSDL allows multiple implementations for a Web service and multiple ports that share the same PortType. In other words, WSDL allows the same interface to have bindings to services such as SOAP and IIOP.

WSIF provides an API to allow the same client code to access any available binding. Since the client code can be written to the PortType, the choice of which port and binding it uses can be determined by deployment, configuration settings, or code

The WSIF uses providers to support these multiple WSDL bindings. A provider is a piece of code that supports a WSDL extension and allows invocation of the service through that particular implementation. WSIF providers use the J2SE JAR service provider specification, making them discoverable at runtime.

Clients can utilize new implementations and delegate the choice of port to the infrastructure and runtime, which allows the implementation to be chosen on the basis of quality of service characteristics or business policy.

WSIF defines additional binding extensions so that Enterprise JavaBean (EJBs), local Java classes, software accessible over message queues using the Java Message Service (JMS) API, and software that can be invoked using the Java Connector architecture can also be described in WSDL. WSIF is packaged with providers that enable transparent invocation based on the corresponding WSDL description..

WSIF enables developers to interact with abstract representations of Web services through their WSDL descriptions instead of working directly with the Simple Object Access Protocol (SOAP) APIs, which is the usual programming model. With WSIF, developers can work with the same programming model regardless of how the Web service is implemented and accessed.

WSIF allows stubless or completely dynamic invocation of a Web service, based upon examination of the metadata about the service at runtime. It also allows updated implementations of a binding to be plugged into WSIF at runtime, allowing the calling service to defer choosing a binding until runtime.

It is closely based on WSDL enabling it to invoke any service that can be described in the language.

If a complicated enterprise software system consists of various pieces of software, developed over a period of decades—EJBs, legacy apps accessed using Java's connector architecture, SOAP services hosted on external servers, old code accessed through messaging middleware—it is necessary to write software applications that use all these pieces to do useful things, where differences in protocols and mobility of software conflict with each other.

If the software is moved to a different server, the code breaks. The SOAP libraries used change—for example, when transitioning from using Apache SOAP to Apache Axis, as it employs a now-deprecated SOAP API. Something that was previously accessible as an EJB is now available through messaging middleware via JMS—again, the code that uses the software must be fixed, or if one has an EJB which is offered as a SOAP service to external clients. Using SOAP results in a performance penalty compared to accessing the EJB directly.

WSIF resolves these issues by enabling WSDL to serve as a normalized description of disparate software and allowing users to access this software without depending on a specific protocol or location. The separation of the API from the actual protocol also means there is flexibility—protocols, location, etc. can be switched without having to recompile client code. If an externally available SOAP service becomes available as an EJB, users can use RMI/IIOP by changing the service description (the WSDL), without making any modification in applications that use the service. WSDL's extensibility, its capability to offer multiple bindings for the same service, deciding on a binding at runtime, etc. can be exploited.

Axis is an implementation of SOAP. It includes on the server-side infrastructure for deploying web service implementations and then routing SOAP messages between clients and those implementations. It also implements the JAX-RPC specification for invoking SOAP services.

WSIF is similar to the client piece of Axis, in that it is used for invoking services. However, WSIF's API is WSDL-driven and protocol independent; it allows protocol-specific code ("providers") to be plugged in. For invoking SOAP services, WSIF is packaged with an Axis provider, that uses Axis APIs (i.e. JAX-RPC) to do the invocation. So WSIF operates at a more abstract level than Axis.

JAX-RPC is an API for invoking XML-based RPC services – the current scope is limited to invocation of SOAP services. WSIF is an API for invoking WSDL-described services, whether they happen to be SOAP services or not (for example, WSIF defines WSDL bindings so that EJBs, enterprise software accessible using JMS or the Java Connector architecture as well as local Java classes can all be described as first-class WSDL services and then invoked using the same, protocol-independent WSIF API).

• Apache XML

• Web Services Invocation Framework documentation
• WSIF and WSDL
• Service Binding