ervice Oriented Architecture (SOA) is an increasingly common buzzword in today's industry. The benefits of a Web services-oriented framework are well appreciated, but not always well-understood. Enterprises planning to convert their conventional backend applications into Web services often plan to achieve the conversion by creating a Web service wrapper around the conventional backend application. The wrapper acts as an intermediary for the conventional application by exposing a Web service interface to the client. This article discusses design considerations for such wrappers that can make them both extensible and flexible, concentrating on conventional applications that take XML as input.
Introducing a Sample Application
To illustrate, consider a simple XML-based billing application as a sample scenario. This application is the conventional application for which the Web service wrapper needs to be developed. It takes XML as input. The sample XML input for the billing application is:
|Figure 1. Sample Billing Application: The initial sample billing application accepts XML via Java RMI calls, and creates a billing record.|
Using this input, the billing application creates a billing record. You can assume that the billing application is hosted on the company's intranet. Currently, the applications that use this billing application do so by making a Java RMI call, passing the XML string as an input parameter. Figure 1
shows the structure of the billing application before adding the Web service wrapper.
A Web Service Wrapper for the Application
Because the billing application is a JAVA RMI application, it's difficult to expose the application outside the intranet without raising security concerns. Exposing the billing application as a Web service makes it available to clients outside the intranet using standard Protocols such as HTTP and SOAP.
|Figure 2. Sample Billing Application with Web Service Wrapper: Adding the Web services wrapper affects the external and potentially the internal calling applications by exposing billing application functionality through standard SOAP calls.|
The function of the Web service wrapper at a very high level is to listen for Simple Object Access Protocol (SOAP) calls and then call the billing application with the appropriate input XML. Figure 2
shows how the Web service wrapper fits into the application architecture.
Functions of the Wrapper
The basic functions of the wrapper are to:
- Listen for incoming SOAP calls.
- Prepare messages before invoking the billing application
- Invoke the billing application.