Web Services Invocation Framework: Difference between revisions

Revision as of 20:54, 18 January 2008

Latest revision as of 20:04, 8 August 2024

(34 intermediate revisions by 27 users not shown)

Line 1:

{{multiple issues|

{{Infobox_Software

{{technical|date=September 2014}}

| name = Apache WSIF

{{abbreviations|date=March 2012}}

| logo =

{{no footnotes|date=November 2014}}

| screenshot =

{{advert|date=December 2014}}

| caption =

}}

| developer = [[Apache Software Foundation]]

{{Infobox software

| name = = Apache WSIF

| logo = =

| screenshot = =

| caption = =

| developer = = [[Apache Software Foundation]]

| latest_release_version = 2.0

| latest_release_date = [[January 27]], [[2003]]

| operating_system = = [[Cross-platform]]

| genre = [[Web Servicesservices]]

| license = [[Apache License|Apache]] 2.0 Licence]]

| website = {{URL|http://ws.apache.org/wsif/}}

}}

The '''Web Services Invocation Framework''' (WSIF) supports a simple Javaand APIflexible for[[Java invoking(programming Weblanguage)|Java]] services,API no(Application matterProgramming how or where the services are provided. The framework allows maximum flexibilityInterface) for the invocation ofinvoking any [[Web Services Description Language|WSDL]] (WSDL)-described service.

Using WSIF, WSDL can become the centerpiece of an integration framework for accessing software running on diverse platforms andwhich usinguse widely varyingdifferent protocols. The onlysoftware preconditionneeds isto thatbe described using WSDL and have a binding included in its description{{Clarify|reason=The preceding youstatement needrefers to describethe yourWSDL (Web Services Description Language) and establishes a connection to it by categorizing it as "software." usingHowever, it highlights the absence of a detailed explanation or reference to WSDL within the article. Consequently, andthere includeis ina itsrequirement descriptionfor a bindinglink that yourprovides a description of WSDL to supplement the information presented.|date=July 2020}} ,that the client's WSIF framework has a provider for. WSIF defines and comes packaged with providers for local javaJava, [[Enterprise JavaBeans]] (EJB), Java Message Service (JMS), and [[Java EE Connector Architecture]] (JCA) protocols., Thatwhich means youthat a client can define an EJB or a JMS[[Java Message Service]]-accessible service directly as a WSDL binding and access it transparently using WSIF, using the same API youone would use for a [[SOAP|SOAP service]] or even a local javaJava class.

The official version of WSIF can be found on the Apache web site since IBM has donated WSIF to Apache Software Foundation.

== WSIF Structure ==

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.

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,service and multiple Portsports that share the same PortType. In other words, WSDL allows the same interface to have bindings to forservices example,such as SOAP and [[General Inter-ORB Protocol|IIOP]].

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.

WSIF provides an API to allow the same client code to access any available binding. AsSince the client code can then be written to the PortType, itthe canchoice beof awhich deploymentport orand configurationbinding settingit (oruses acan codebe choice)determined whichby portdeployment, andconfiguration bindingsettings, itor uses.code

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.

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 [[Run time (program lifecycle phase)|runtime]].

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.

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 bindingsBindings for EJBs, JMS, and JCA... ==

== WSIF Structure ==

WSIF defines additional binding extensions so that [[Enterprise JavaBean]] (EJBs), local javaJava classes, software accessible over [[message queuesqueue]]s 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 allowenable transparent invocation ofbased such software givenon the corresponding WSDL description..

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.

== Description ==

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 EJBs, 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.

== Why should I use 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-datametadata about the service at runtime. It also allows updated implementations of a binding to be plugged into WSIF at runtime, and it allowsallowing the calling service to defer choosing a binding until runtime.

Finally, WSIFIt is closely based uponon WSDL, soenabling it canto invoke any service that can be described in WSDLthe language.

WhatIf does all this enable? Imagine youra complicated Enterpriseenterprise software system consistingconsists of various pieces of software, developed over a period of tens of years - EJBsdecades—EJBs, legacy apps accessed using Java's connector architecture, SOAP services hosted on external servers, old code accessed through messaging middleware.middleware—it Youis neednecessary to write software applications that use all these pieces to do useful things;, yet thewhere differences in protocols, and mobility of software, etc.conflict comes inwith theeach wayother.

TheIf the software youis use movesmoved to a different server, so yourthe code breaks. The SOAP libraries youused use change - say forchange—for example, youwhen movedtransitioning from using Apache SOAP to Apache Axis, - so your code breaks sinceas it usesemploys a now -deprecated SOAP API. Something that was previously accessible as an EJB is now available through messaging middleware via JMS - againJMS—again, you need to fix the code that uses the software. Ormust be fixed, letsor supposeif youone havehas 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 fixesresolves these problemsissues by lettingenabling youWSDL useto WSDLserve as a normalized description of disparate software, and allowsallowing youusers to access this software inwithout adepending manneron thata is independent ofspecific 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 youthere haveis flexibility - you can switch protocolsflexibility—protocols, ___location, etc. can be switched without having to even recompile your client code. So if yourIf an externally available SOAP service becomes available as an EJB, youusers can switch to usinguse RMI/IIOP by just changing the service description (the WSDL), without having to makemaking 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. can be exploited.

== Differences between WSIF and Axis ==

Line 57 ⟶ 53:

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.

== Differences between WSIF and JAX-RPC ==

JAX-RPC is an API for invoking XML-based RPC services -– essentially itsthe 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).

== See also ==

* [[Apache Web ServicesXML]]

*[[Apache XML]]

== External links ==

* [http://ws.apache.org/wsif/ Web Services Invocation Framework documentation]

* [http://publib.boulder.ibm.com/infocenter/ws51help/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/cwsf_wsdl.html WSIF and WSDL]

* [http://www.s-cube-network.eu/km/terms/s/service-binding Service Binding]

{{Apache Software Foundation}}

{{Apache}}

[[Category:Web service specifications]]

[[Category:Web services]]

[[es:WSIF]]

[[pt:WSIF]]