Content deleted Content added
Added supporting reference, tidied up one IBM reference (added title for it) |
m Disambiguated: JMS → Java Message Service (2), JCA → Java EE Connector Architecture |
||
Line 1:
{{multiple issues
| lead too long=May 2008
| abbreviations=March 2012
}}
{{Infobox software
| name = Apache WSIF
Line 24 ⟶ 27:
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 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 ==
Line 39 ⟶ 42:
== WSDL bindings for EJBs, JMS, JCA... ==
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 EE Connector Architecture|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.
== Description of WSIF ==
| |||