Web Services Invocation Framework
Encyclopedia
The Web Services Invocation Framework (WSIF) supports a simple Java API for invoking Web services, no matter how or where the services are provided. The framework allows maximum flexibility for the invocation of any WSDL
-described service.
The official version of WSIF can be found on the Apache web site since IBM has donated WSIF to Apache Software Foundation.
In the WSDL specification, Web service binding descriptions are extensions to the specification. So the SOAP binding, for example, is one way to expose the abstract functionality (and there could be others). Since WSIF mirrors WSDL very closely, it also views SOAP as just one of several ways you might wish to expose your software's functionality. WSDL thus becomes a normalized description of software, and WSIF is the natural client programming model.
The WSIF API allows clients to invoke services focusing on the abstract service description - the portion of WSDL that covers the port types, operations and message exchanges without referring to real protocols. The abstract invocations work because they are backed up by protocol-specific pieces of code called providers. A provider is what conducts the actual message exchanges according to the specifics of a particular protocol - for example, the SOAP provider that is packaged with WSIF uses a specific SOAP engine like Axis to do the real work.
The decoupling of the abstract invocation from the real provider that does the work results in a flexible programming model that allows dynamic invocation, late binding, clients being unaware of large scale changes to services - such as service migration, change of protocols, etc. WSIF also allows new providers to be registered dynamically, so you could enhance your client's capability without ever having to recompile its code or redeploy it.
Using WSIF, WSDL can become the centerpiece of an integration framework for accessing software running on diverse platforms and using widely varying protocols. The only precondition is that you need to describe your software using WSDL, and include in its description a binding that your client's WSIF framework has a provider for. WSIF defines and comes packaged with providers for local java, EJB, JMS
, and JCA
protocols. That means you can define an EJB or a JMS-accessible service directly as a WSDL binding and access it transparently using WSIF, using the same API you would for a SOAP service or even a local java class.
WSDL allows there to be 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 for example, SOAP and IIOP.
WSIF provides an API to allow the same client code to access any available binding. As the client code can then be written to the PortType it can be a deployment or configuration setting (or a code choice) which port and binding it uses.
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 then utilize any new implementations and can 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.
, local java classes, software accessible over message queues using the 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 allow transparent invocation of such software given the corresponding WSDL description.
WSIF allows stubless or completely dynamic invocation of a Web service, based upon examination of the meta-data about the service at runtime. It also allows updated implementations of a binding to be plugged into WSIF at runtime, and it allows the calling service to defer choosing a binding until runtime.
Finally, WSIF is closely based upon WSDL, so it can invoke any service that can be described in WSDL.
What does all this enable? Imagine your complicated Enterprise software system consisting of various pieces of software, developed over a period of tens of years - EJBs, legacy apps accessed using Java's connector architecture, SOAP services hosted on external servers, old code accessed through messaging middleware. You need to write software applications that use all these pieces to do useful things; yet the differences in protocols, mobility of software, etc. comes in the way.
The software you use moves to a different server, so your code breaks. The SOAP libraries you use change - say for example you moved from using Apache SOAP to Apache Axis - so your code breaks since it uses a now deprecated SOAP API. Something that was previously accessible as an EJB is now available through messaging middleware via JMS - again, you need to fix the code that uses the software. Or let's suppose you have an EJB which is offered as a SOAP service to external clients. Using SOAP obviously results in a performance penalty as compared to accessing the EJB directly. Of course, SOAP is a great baseline protocol for platform and language independence, but shouldn't java clients be able to take advantage of the fact that the software they are accessing is really an EJB? So your java customers pay a performance penalty since you have to use SOAP for to accommodate you non-java clients.
WSIF fixes these problems by letting you use WSDL as a normalized description of disparate software, and allows you to access this software in a manner that is independent of protocol or location. So whether it is SOAP, an EJB, JMS (or potentially .NET and other software frameworks), you have an API centered around WSDL which you use to access the functionality. This lets you write code that adapts to changes easily. The separation of the API from the actual protocol also means you have flexibility - you can switch protocols, location, etc. without having to even recompile your client code. So if your an externally available SOAP service becomes available as an EJB, you can switch to using RMI/IIOP by just changing the service description (the WSDL), without having to make any modification in applications that use the service. You can exploit WSDL's extensibility, its capability to offer multiple bindings for the same service, deciding on a binding at runtime, etc.
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 in fact 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.
Web Services Description Language
The Web Services Description Language is an XML-based language that is used for describing the functionality offered by a Web service. A WSDL description of a web service provides a machine-readable description of how the service can be called, what parameters it expects and what data structures...
-described service.
The official version of WSIF can be found on the Apache web site since IBM has donated WSIF to Apache Software Foundation.
In the WSDL specification, Web service binding descriptions are extensions to the specification. So the SOAP binding, for example, is one way to expose the abstract functionality (and there could be others). Since WSIF mirrors WSDL very closely, it also views SOAP as just one of several ways you might wish to expose your software's functionality. WSDL thus becomes a normalized description of software, and WSIF is the natural client programming model.
The WSIF API allows clients to invoke services focusing on the abstract service description - the portion of WSDL that covers the port types, operations and message exchanges without referring to real protocols. The abstract invocations work because they are backed up by protocol-specific pieces of code called providers. A provider is what conducts the actual message exchanges according to the specifics of a particular protocol - for example, the SOAP provider that is packaged with WSIF uses a specific SOAP engine like Axis to do the real work.
The decoupling of the abstract invocation from the real provider that does the work results in a flexible programming model that allows dynamic invocation, late binding, clients being unaware of large scale changes to services - such as service migration, change of protocols, etc. WSIF also allows new providers to be registered dynamically, so you could enhance your client's capability without ever having to recompile its code or redeploy it.
Using WSIF, WSDL can become the centerpiece of an integration framework for accessing software running on diverse platforms and using widely varying protocols. The only precondition is that you need to describe your software using WSDL, and include in its description a binding that your client's WSIF framework has a provider for. WSIF defines and comes packaged with providers for local java, EJB, JMS
JMS
- Buildings :*EverBank Field, a sports stadium in Jacksonville, Florida, home of the Jacksonville Jaguars. Formerly known as Jacksonville Municipal Stadium...
, and JCA
JCA
- Organizations :* Josephite Community Aid, Australian charity founded in 1986* Jewish Colonization Association, created in 1891 to facilitate the mass emigration of Jews from Russia and other Eastern European countries* Joint Church Aid...
protocols. That means you can define an EJB or a JMS-accessible service directly as a WSDL binding and access it transparently using WSIF, using the same API you would for a SOAP service or even a local java class.
WSIF Structure
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 there to be 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 for example, SOAP and IIOP.
WSIF provides an API to allow the same client code to access any available binding. As the client code can then be written to the PortType it can be a deployment or configuration setting (or a code choice) which port and binding it uses.
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 then utilize any new implementations and can 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.
WSDL bindings for EJBs, JMS, JCA...
WSIF defines additional binding extensions so that EJBsEnterprise JavaBean
Enterprise JavaBeans is a managed, server-side component architecture for modular construction of enterprise applications.The EJB specification is one of several Java APIs in the Java EE specification. EJB is a server-side model that encapsulates the business logic of an application...
, local java classes, software accessible over message queues using the JMS
JMS
- Buildings :*EverBank Field, a sports stadium in Jacksonville, Florida, home of the Jacksonville Jaguars. Formerly known as Jacksonville Municipal Stadium...
API and software that can be invoked using the Java Connector architecture
Java EE Connector Architecture
Java EE Connector Architecture is a Java-based technology solution for connecting application servers and enterprise information systems as part of enterprise application integration solutions. While JDBC is specifically used to connect Java EE applications to databases, JCA is a more generic...
can also be described in WSDL. WSIF is packaged with providers that allow transparent invocation of such software given the corresponding WSDL description.
Description of WSIF
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 meta-data about the service at runtime. It also allows updated implementations of a binding to be plugged into WSIF at runtime, and it allows the calling service to defer choosing a binding until runtime.
Finally, WSIF is closely based upon WSDL, so it can invoke any service that can be described in WSDL.
What does all this enable? Imagine your complicated Enterprise software system consisting of various pieces of software, developed over a period of tens of years - EJBs, legacy apps accessed using Java's connector architecture, SOAP services hosted on external servers, old code accessed through messaging middleware. You need to write software applications that use all these pieces to do useful things; yet the differences in protocols, mobility of software, etc. comes in the way.
The software you use moves to a different server, so your code breaks. The SOAP libraries you use change - say for example you moved from using Apache SOAP to Apache Axis - so your code breaks since it uses a now deprecated SOAP API. Something that was previously accessible as an EJB is now available through messaging middleware via JMS - again, you need to fix the code that uses the software. Or let's suppose you have an EJB which is offered as a SOAP service to external clients. Using SOAP obviously results in a performance penalty as compared to accessing the EJB directly. Of course, SOAP is a great baseline protocol for platform and language independence, but shouldn't java clients be able to take advantage of the fact that the software they are accessing is really an EJB? So your java customers pay a performance penalty since you have to use SOAP for to accommodate you non-java clients.
WSIF fixes these problems by letting you use WSDL as a normalized description of disparate software, and allows you to access this software in a manner that is independent of protocol or location. So whether it is SOAP, an EJB, JMS (or potentially .NET and other software frameworks), you have an API centered around WSDL which you use to access the functionality. This lets you write code that adapts to changes easily. The separation of the API from the actual protocol also means you have flexibility - you can switch protocols, location, etc. without having to even recompile your client code. So if your an externally available SOAP service becomes available as an EJB, you can switch to using RMI/IIOP by just changing the service description (the WSDL), without having to make any modification in applications that use the service. You can exploit WSDL's extensibility, its capability to offer multiple bindings for the same service, deciding on a binding at runtime, etc.
Differences between WSIF and Axis
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 in fact 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.