RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Design Guidelines: Building Web Service Wrappers for an XML-based System

Giving external—or internal—clients direct access to existing applications isn't always practical, secure, or flexible. Instead, it's often better to provide Web service wrapper around existing applications. Such wrappers let you safely expose existing systems to both internal and external customers and can work with a variety of communication methods via configurable protocols.

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.
   <?xml version="1.0"?>

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:

  1. Listen for incoming SOAP calls.
  2. Prepare messages before invoking the billing application
  3. Invoke the billing application.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date