Browse DevX
Sign up for e-mail newsletters from DevX


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

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.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

Listening for SOAP Calls
After developing the wrapper, you need to deploy it as a SOAP service running in an application server. Usually application servers have tools that help in packaging the Web service wrapper and deploying it as a SOAP service. The application server then handles the details of listening for incoming requests and invoking the wrapper appropriately.

Message Preparation
The billing application needs an XML document to process, which calling applications send via RMI. This model works fine as long as the calling applications are inside the intranet, but without opening a port through the firewall, external applications don't have access to the application. However, after creating the Web service wrapper, external applications can also access the billing application. For many clients, it would be asking a lot to get them to build external calling applications that construct appropriate XML documents for the billing application and send those to the Web service wrapper. This is where the wrapper proves its effectiveness.

Rather than relying on client applications to construct appropriate XML billing messages, you can simply expose wrapper methods that let clients pass appropriate parameters. The wrapper uses the parameter values to construct appropriate XML documents and send those to the billing application. That simplifies the external interface considerably. Using this architecture, external calling applications can call the billing application methods with the appropriate parameters and the wrapper internally constructs the XML.

XML Schema to Method Mapping
To simplify the invocation of the Web service, so that clients need only pass the required values as parameters to the method rather than a complete XML document, you need to design the wrapper carefully, identifying the methods and parameters to be exposed in such a way that they're flexible and easy for external calling applications to use.

The easiest way to achieve this is to identify the methods and the parameters from the XML schema of the billing application's input XML. The XML Schema defines all the information about the billing application's XML document input. It contains details such as the element names, sequences, and default values. So, if the wrapper creates the input XML based on the schema, it is guaranteed to be in functional compliance with the billing application. Using the schema helps in defining the methods for the wrapper. Inside these methods the wrapper constructs input XML and passes that to the billing application. Using the simple schema shown below for the billing application's XML input, here's how you might define methods for the wrapper.

<?xml version="1.0"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.BillingApplication.org" xmlns="http://www.BillingApplication.org" elementFormDefault="qualified"> <xsd:element name="BillingInfo"> <xsd:complexType> <xsd:sequence> <xsd:element name="userId" type="xsd:string"/> <xsd:element name="userCategory" type="xsd:string" minOccurs="0" /> <xsd:element name="date" type="xsd:string" minOccurs="0" /> <xsd:element name="charge" type="xsd:string" /> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema>

The XML schema defines four elements, of which two (<userCategory> and <date>) are optional (minOccurs=0). Note that all the elements must follow the sequence specified in the schema. Based on this information, the wrapper can have the following method definitions.

makeBillWithUserCategoryAndDate(String userId, String userCategory,String date,String charge) makeBillWithDate(String userId,String date,String charge) makeBillWithUserCategory(String userId,String userCategory,String charge) makeBill(String userId,String charge) makeBillWithXML(String XML)

The parameters of these methods reflect the fact that some of the elements in the XML Schema are optional. By creating several methods with different parameters, users are not forced to send values for the optional date and userCategory elements. In other words, an external calling application that doesn't need a date or userCategory value in the billing record can use the makeBill(String userId,String charge) method, which doesn't require the optional values.

One version of the methods listed above takes a single XML input parameter—makeBillWithXML(String XML). This method has been included to allow backward compatibility.

After creating the method definitions, the next step is to write the code that creates the appropriate input XML. The pseudo code below shows the XML creation process for two of the defined method versions.

makeBillWithUserCategoryAndDate(String userId, String userCategory,String date,String charge) { String inputXml= "<?xml version='1.0' ?> <BillingInfo> " inputXml=inputXml + "<userId>" + userId + "</userId>" inputXml = inputXml + "<userCategory>" + userCategory + "</userCategory>" inputXml = inputXml + "<date>" + date+ "</date>" inputXml = inputXml + "<charge>" + charge+ "</charge>" inputXml = inputXml + "</BillingInfo>" //send this XML to the Billing Application }

Note that the code maintains the sequence of the elements as required by the schema.

makeBill(String userId,String charge) { String inputXml= "<?xml version='1.0' ?> <BillingInfo> " inputXml=inputXml + "<userId>" + userId + "</userId>" inputXml = inputXml + "<charge>" + charge+ "</charge>" inputXml = inputXml + "</BillingInfo>" //send this XML to the Billing Application }

Now, the XML is ready to be sent to the billing application.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



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