Web Services Invocation Framework: Difference between revisions

Revision as of 18:17, 17 November 2014

Revision as of 23:28, 10 December 2014

Line 2:

{{cleanup-rewrite|date=July 2008}}

{{technical|date=September 2014}}

{{lead too long|date=May 2008}}

{{abbreviations|date=March 2012}}

{{no footnotes|date=November 2014}}

{{inappropriate person}}

{{advert}}

}}

{{Infobox software

Line 20 ⟶ 21:

}}

The '''Web Services Invocation Framework''' (WSIF) supports a simple [[Java (programming language)|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 [[Web Services Description Language|WSDL]]-described service.

The official version of WSIF can be found on the Apache web site since [[IBM]] has donated WSIF to the [[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 [[Apache 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]], [[Java Message Service|JMS]], and [[Java EE Connector Architecture|JCA]] protocols. That means you can define an [[Enterprise JavaBeans]] or a [[Java Message Service]]-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.