How to Support Web Services in Products
by Thomas Bayer
Software providing Web Services interfaces for business functions can be easily integrated with other applications, i.e. Web Shops or Customer Relationship Management software. Instead of having islands consisting of different systems, Web Services-enabled systems form a service-oriented architecture. This article explains how support for Web Services can be incorporated into "out-of-the-box" standard software and into individual software.
Exposing the functions of a software product as Web Services will dramatically facilitate integration with other systems. Software vendors offering Web Services and XML support for their products will have an advantage- especially when selling to customers who want to use a service-oriented integration strategy. Today, the market requires software vendors to support Web Services.
This article describes different ways to expose Web Services interfaces for individual and standard software. Different strategies for users and software vendors are also discussed.
1 Providing Web Services Interfaces
There are several ways to expose a Web Services interface as listed below. The best way depends on the number of installations and whether the software to be Web Services-enabled is standard software or individual software. The options include:
- bundling a Web Services engine with the product
- using a standalone third-party SOAP engine
- relaying through a Web Services gateway
- using an EAI or ESB product
1.1 Individual Software
To move toward a service-oriented architecture, existing applications have to be extended with Web Services interfaces. In most companies you can find a variety of individual applications built with different technologies like CORBA, COBOL or Visual Basic. Software for enterprise application integration addresses this variety. An Enterprise Service Bus (ESB) is a special kind of EAI software that is based on Web Services. Sometimes an ESB is too overloaded with features and a slimmer solution may be more appropriate.
1.2 Standard Software
Selecting the right method depends on whether you are a user or a software vendor.
1.2.1 Software Users
The need to integrate software with other systems, or to offer interfaces to external business partners, motivates users to make standard software via Web Services accessible.
Typically, the software that should expose a Web Services interface is a server, thus in most companies only one or a few installations are concerned. The small number of installations makes it possible to use certain alternatives like a Web Services gateway even if it is expensive or requires additional hardware. Although the license fee for a Web Services gateway is high, it might be less expensive than modifying existing software. If the source code for existing software is not available or not documented, a Web Services gateway or adaptor is the only solution.
1.2.2 Software Vendors
Solutions that are appropriate for users may not be appropriate for vendors. For example, bundling a software product with a Web Services gateway or SOAP engine might be too expensive if the number of installations is high even if there are substantial discounts for the gateway. In addition, it is better to sell a seamless, integrated product that comes from one source instead of a smorgasbord of different pieces.
2 Bundling Web Services Support
There are several ways to incorporate Web Services support into a product.
2.1 Using SOAP Engines
A SOAP engine is a server or a library that transforms SOAP messages into invocations and vice versa. An example of a SOAP engine is the open source project Apache Axis or Cape Clear from Cape Clear Software. SOAP engines can be used to add Web Services support to a software product. The SOAP engine can be bundled with the product or the product manuals can describe how to install the software with a third-party SOAP engine. It is more convenient to bundle a SOAP engine with the product so that the SOAP engine and its details are concealed from the client.
2.1.1 Writing Your Own SOAP Engine
SOAP messages are simple XML documents so why not write a SOAP engine on your own instead of using third-party software? It is not easy to write and test an interoperable SOAP engine. A SOAP engine has to do more than process SOAP messages. For example, WSDL documents have to be created, requests must be dispatched and the lifecycle of service objects has to be managed. It gets even more complicated because new standards and requirements also apply. It is better to concentrate on the application and its value to the client instead of wasting time implementing a SOAP engine- even if implementing a SOAP engine is more fun than writing business code. Writing a SOAP engine might still be an alternative for a major software vendor.
2.1.2 Using a Commercial SOAP Engine
A software developer seeking to enable an indivudal software for a Web Services environment might benefit from a commercial SOAP engine. Some products are well documented, easy to use and have excellent support.
However, before bundling a commercial SOAP engine with a product there are some obstacles to overcome. First, the license of the SOAP engine must allow the bundling. Reviewing and negotiationg licenses from multiple vendors can be time-consuming. Finally, depending on the license and the number of installations, fees can be substantial. Aside from the economic issues, the commercial engine has to be integrated into the software product. The integration has to be supported by the vendor with manuals, programming interfaces or even with the source code of the SOAP engine. For the majority of commercial SOAP engines, the source code is not available so a blackbox has to be integrated leaving some potential risks.
2.1.3 Using an Open Source SOAP Engine
The source code of an open source SOAP engine facilitates integration with the software product. The availability of the source code and the whole build-system makes it possible to modify the SOAP engine according to the needs of the software product. For example, it is possible to remove unused parts and reduce the footprint of the software.
Before bundling an open source software with a commercial product, the open source license has to be evaluated. Not every open source license allows the bundling- some licenses even require the disclosure of the product's source code if the product depends on open source code.
Using an open source SOAP engine could be a viable option for both users and software vendors. The large user communities of some open source projects are a valuable source of support, documentation and bug-fixing.
2.2 SOAP Adaptors
Some SOAP engines can be extended with an adaptor to support Web Services for a backend. For instance, vendors of ERP software can ship adaptors for different SOAP engines with their products. Before writing an adaptor, the vendor of the backend system should be consulted to see if there is already an adaptor available. Third-party companies may also offer adaptors.
Backend adaptors for Apache Axis are called providers. A provider can be packaged into a jar-archive and easily deployed. An example of a provider is SProvider which exposes stored procedures as SOAP Web Services.
2.3 Using a Web Services Gateway
Web Services Gateways expose the functionality of legacy systems as Web Services. Modifications to the legacy systems are not necessary. Because the legacy systems are wrapped into a Web Services interface. A gateway is also referred to as a Web Services Wrapper. Gateways can also provide security features like authentication or Single Sign-on.
3 Web Services and J2EE Applications
The Java 2 Enterprise Edition supports Web Services. The interfaces of Enterprise JavaBeans can be exposed as Web Services without programming. But it is not as easy as application server advertisements promise. The exposure of arbitrary interfaces can lead to poorly designed Web Services which are neither interoperable nor understandable. It can be necessary to redesign the interfaces or to use the facade pattern.
IT professionals become more concerned about security when Web Services are involved. For example, many CORBA, DCOM and J2EE based applications do not communicate in a secure way. Today, there are only a few federations and centralized security management solutions in use. Before deploying a sophisticated and complicated Web Services security solution, see whether or not a simpler solution can provide the necessary security. Web Services specifications, like WSS or SAML, also support elaborate security scenarios.
If a Service-Oriented Architecure is only composed of unsecured Web Services and security does not matter, everything is much easier. This is the case, for example, if:
- the services are located inside a secure network and no further protection is needed
- the services are secured with a firewall
- a virtual private network is used for communication
- end-to-end security using SSL/TLS is enough
4.1 Using a Web Services Firewall
Web Services that do not support security can be secured using a Web Services firewall managing authentication and authorization. It is even possible to configure single sign-on without changing the actual Web Services.
There are firewalls providing support for Web Services Security, aka WS-Security. Messages to and from an unsecure Web Service can be encrypted or signed by an intermediary firewall as shown in the figure below.
There are several ways to expose product functions as Web Services. The costs of an additional SOAP interface are negligible compared to the total development costs of a software product. The benefits of an additional SOAP interface easily exceed the costs. Benefits include broadening the client base and the interoperability of the product with other Web Services-enabled software.