+

Search Tips   |   Advanced Search

WSIF usage scenarios

There are two main scenarios that illustrate the role WSIF plays in the emerging web services environment: Redevelopment and redeployment, and service flow composition.


Scenario: Redevelopment and redeployment

When we first implement a web service, we create a simple prototype. When we want to move a prototype web service into production, you often have to redevelop and redeploy it.

The Web Services Invocation Framework (WSIF) uses the same API calls irrespective of the underlying technologies, therefore if we use WSIF:


Scenario: Service flow composition

A service flow typically invokes a web service, then passes the response from one web service to the next web service, perhaps performing some transformation in the middle.

There are two key aspects to this flow that WSIF provides:

For example, imagine that you build a meta-service that uses a number of services to build a process. Initially, several of those services are simple Java bean prototypes that are written and exposed through SOAP, but we plan to reimplement some of them as EJB components, and to out-source others.

If we use SOAP, it ties up multiple threads for every onward invocation, because they pass through the web server and servlet engine and on to the SOAP router. If we use WSIF to call the beans directly, we get much better performance compared to SOAP and we do not lose access or location transparency. Using WSIF, we can replace the Java bean implementations with EJB implementations without changing the client code. To move some of the web services from local implementations to external SOAP services, we just update the WSDL.


Related:

  • WSIF architecture
  • WSIF and WSDL