Design Guidelines: Building Web Service Wrappers for an XML-based System : Page 4
Giving externalor internalclients 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.
by S.Srivatsa Sivan
Apr 19, 2005
Page 4 of 4
Advantages of this Framework
The Web service wrapper is extensible in terms of the variety of transport Protocols that can be supported.
The Web service wrapper is extensible in terms of the number of methods as its methods are based on the cardinality of the XML Schema.
This approach clearly separates the domain of application developers (such as the billing application developers) from that of Web service experts, so that they can work independently of each other.
After deployment, the organization can exploit all the standard features of Web services, such as Web service security, publishing the WSDL in a UDDI registry, or using tools to generate client side stub code, etc.
Figure 4. Three Distinct Wrapper Parts: The first part maps schema to methods. The second prepares XML for the application, and the third invokes the actual application using a protocol handler.
The greatest advantage of this design comes from its extensibility and flexibility. Dissecting the Web service wrapper, you can see in Figure 4 that it contains three distinct pieces. The first piece is the one that maps schema to methods. The second prepares XML for the application, and the third talks to the actual application using a protocol handler.
In the future, some generic or third-party tools are likely to emerge that you you'll be able to use to map XML schema directly to methods. When that happens, you'll be able to plug these tools into the system easily in the place of the custom "Schema to Method Mapping" functionality described in this article. Because the pieces of the wrapper are isolated, the rest of the system will be undisturbed by such changes.
The framework design is extensible because it's independent from the number or type of transport protocols that can be supported. New protocol handlers can be integrated with the system as required without too much effort.
Finally, because the design is based on Services Oriented Architecture (SOA) principles, you can integrate other functionality such as security into the system with ease.
S. Srivatsa Sivan
currently works as a Software Engineer for Hewlett-Packard. He did Post-Graduate work at IIIT-B. He has about 4 years of industry experience. His areas of interest include Web services, EAI, and Security.