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 : Page 3

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.

Invoking the Billing Application
After creating the required XML, the wrapper must send it to the billing application. Currently the billing application is a Java-RMI application, so the wrapper needs to make a Java-RMI call with the constructed input XML. But in the future, you might want to change the RMI-based billing application to a JMS-based billing application. If not designed carefully, this change would necessitate code changes in the Web service wrapper. Because the wrapper accepts data from multiple—and potentially external—clients, you should avoid changing it, if possible. So, it's advisable to use an approach that uses a configurable transportation protocol handler. To achieve a configurable transportation protocol handler, you'll need:

  • A configuration file
  • A protocol interface
  • A protocol handler factory class
  • Several interface implementations
These implementations will work as different protocol handlers such as RMIProtocolHandler and JMSProtocolHandler.

High Level Design for a Configurable Protocol Handler
Figure 3 shows the architectural relationship of wrapper, the billing application, and the items listed above

Figure 3. Action Sequence: The figure shows the logical sequence of actions to achieve a configurable method for handling various transportation protocols.
Each of the components shown in Figure 3 is discussed below.

Configuration File

The configuration file contains the information about the protocol handler to be used along with other configuration information. For example, here's a sample protocol handler entry:

      <protocolHandler> RMIHandler </protocolHandler> 
Protocol Handler Interface
The protocol handler interface defines a method. In this case, the interface needs only an invoke() method that accepts the XML created by the wrapper as an input parameter.

   invoke(String inputXml)
Protocol Handler classes
Each protocol handler class implements the ProtocolHandlerInterface thereby implementing the invoke(String inputXml) method. For example, here's the basic level pseudo code for the RMIProtocolHandler and the JMSProtocolHandler:

   // Please note that exception handling in the code has 
   // been left out for clarity.

RMIProtocolHandler implements ProtocolHandlerInterface
      invoke (String inputXML)
         // "registryLocation" is the RMI Registry location containing the 
         // remote Billing service object
         obj = Naming.lookup(registryLocation); 
   JMSProtocolHandler implements ProtocolHandlerInterface
      invoke (String inputXML)
         connectionFactory = (ConnectionFactory) 
         //"destName" is the JNDI binding name for the Billing service
         dest = (Queue) jndiContext.lookup(destName);
         connection = connectionFactory.createConnection();
         session = connection.createSession(false,Session.AUTO_ACKNOWLEDGE);
         producer = session.createProducer(dest);
         message = session.createTextMessage(); 
Protocol Handler Factory
This factory class has a getProtocolHandler(String protocolName) method that returns an instance of the ProtocolHandler class as a ProtocolHandlerInterface object depending on what protocol was passed to it as parameter.

The basic level pseudo code for the method is listed below:

   ProtocolHandlerInterface getProtocolHandler(String protocolName)
         return new RMIProtocolHandler();
   else if (protocolName.equals("JMSHandler")
         return new JMSProtocolHandler();
When the interface and handler classes are ready, you can use them in the Web service wrapper to invoke the billing application as shown in the following pseudo code.

After the XML is created,

      // XML Creation
      String  protocol = readValueOf("<protocolHandler>");
      ProtocolHandlerInterface phi = 
Having the ProtocolHandlerFactory.getProtocolHandler() method return a Handler class into a ProtocolHandlerInterface variable helps to decouple the wrapper class from the Handler implementation class—in other words, the wrapper doesn't need to know or care whether the Handler is an RMI Handler or a JMS Handler. This also makes it easier to extend the Web service wrapper to support other protocol mechanisms. For example, you could add a JNDI Handler or a SOAP Handler in the future, if the need arises by simply creating another protocol handler class and modifying the configuration file and ProtocolHandlerFactory class.

To summarize, the action sequence to invoke the billing application is:

  1. The Web service wrapper reads the config file to get a protocol object to use.
  2. The wrapper then calls the Protocol Handler Factory to get the appropriate protocol handler.
  3. The wrapper calls the invoke(String inputXML) method on the interface, passing the XML document constructed from the calling application's parameter values.
  4. The protocol handler class prepares the transport appropriately and calls the billing application.
Using the architecture shown in this article, a Web service wrapper can construct the required XML and can make use of the appropriate transport protocol to talk to the application. The only remaining step is to deploy your Web service wrapper to an application server as a SOAP service, and you're ready to expose internal applications to the world as Web services.

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