An overview of incompatibility issues
Most interoperability issues arise not from the base Web services specification (which is quite mature and stable), but rather from the various WS-* Web services extensions, such as WS-Security. As these standards evolve, vendors must choose which draft specifications to support, and developers occasionally need to cope with incompatibility issues between different specifications.
The WS-Security standard provides mechanisms for applying authentication, integrity, and confidentiality to SOAP messages. These capabilities are often required for the adoption of Web services and Services-Oriented Architecture (SOA) within the enterprise. IBM® middleware began providing support for WS-Security with IBM WebSphere® Application Server V5.0.2. This implementation of WS-Security was based on the OASIS working draft 13 specification. WebSphere Application Server V5.1 and other IBM middleware based on the Java™ 2 Platform, Enterprise Edition (J2EE) 1.3 run times (such as IBM WebSphere Portal Server V5 and IBM WebSphere Business Integration Server Foundation V5) also contain WS-Security implementations based on the draft 13 specification. With the J2EE 1.4 run time included in WebSphere Application Server V6.0, IBM provided a WS-Security implementation based on the WS-Security 1.0 specification. IBM WebSphere Process Server and other IBM middleware using J2EE 1.4 run times contain WS-Security implementations based on the version 1.0 specification.
Unfortunately, due to changes in the wire format of the WS-Security SOAP header specification, Web service consumer applications and target Web services that conform to the draft 13 specification can't interact with consumer applications and target services that conform to the version 1.0 specification. For example, a J2EE 1.3 Web service consumer application running in WebSphere Portal Server V5.1 can't use WS-Security to communicate with a J2EE 1.4 service provider application running in WebSphere Application Server V6.0. And the problem isn't limited to the IBM middleware software stack. For example, the Microsoft® .NET Web Services Enhancements (WSE) 1.0 is also based on a draft version of the WS-Security specification, and the same interoperability problems occur when trying to communicate between this stack and any other that's based on the WS-Security 1.0 specification.
Figure 1. WS-Security specification level incompatibility problem
If confronted by this incompatibility, you have a few options to get around the problem. The remainder of this article describes these options and provides some guidance toward choosing an appropriate solution based on your business requirements and technical constraints.
For the sake of simplicity, let's assume that the Web service consumer application uses the WS-Security draft 13 specification, and the Web service provider application uses the WS-Security 1.0 specification. Note: The workarounds suggested here can also be applied to the reverse scenario in which the Web service consumer uses the WS-Security 1.0 specification, and the Web service provider uses the draft 13 specification.
Workaround 1: Upgrade Web service consumer applications to J2EE 1.4
The simplest way to avoid the problem altogether is to ensure that your Web service consumer applications are using the same WS-Security specification version as your Web service provider applications. This requires upgrading your Web service consumer application to J2EE 1.4, and possibly also upgrading your middleware to a version that supports J2EE 1.4 applications.
Upgrading J2EE 1.3 Web service consumer applications to J2EE 1.4 is a development exercise. IBM Rational® Application Developer provides a J2EE migration wizard that's capable of migrating Enterprise JavaBeans (EJB) projects, Web projects, J2EE Connector Architecture (JCA) Connector projects, and Web services from the J2EE 1.3 specification level to the J2EE 1.4 specification level.
To use the J2EE migration wizard to migrate a J2EE 1.3 application to J2EE 1.4, simply right-click the Enterprise Application project in the Project Explorer view of the J2EE Perspective, then select Migrate > J2EE Migration Wizard from the pop-up menu. After the wizard completes, you can configure the WS-Security client bindings. These bindings aren't automatically migrated by the wizard, and they must be manually configured as a post-migration task.
Next you need to ensure that the application server to which your Web service consumer application is deployed is capable of supporting J2EE 1.4 applications. For enterprise applications, WebSphere Application Server V6.0 is capable of running J2EE 1.4 applications. And for portlets, WebSphere Portal Server V18.104.22.168 is capable of running a Web project that's been migrated to J2EE 1.4. If you have these or later versions, then your migrated Web service consumer applications should run without problems. Otherwise, you may need to upgrade your middleware.
Figure 2. Upgrade Web service consumer application(s) to J2EE 1.4
Table 1. Roles and tasks for upgrading Web service consumer applications to J2EE 1.4
|Application developer||Migrate Web service consumer applications to J2EE 1.4|
|Deployer||Set up the J2EE 1.4 operating environment for Web service consumer applications|
|Test engineer||Verify that the migrated Web service consumer works as expected|
Migrating your applications and (if necessary) your middleware to J2EE 1.4 is the preferred way to avoid the WS-Security specification level interoperability problem. It eliminates the problem altogether and provides the strategic benefits of being at the latest middleware code levels.
However, depending on your applications and your middleware environment, it may be inconvenient or difficult to migrate your Web service consumer applications to J2EE 1.4. Furthermore, the effort required to implement this approach increases linearly with each additional Web service consumer application using the WS-Security draft 13 specification that must be migrated.
Workaround 2: Use a Web Services Gateway
The Web Services Gateway is a software component of IBM WebSphere Application Server Network Deployment, which can be optionally configured after product installation. IBM WebSphere DataPower SOA Appliances are purpose-built, easy-to-deploy network devices. Both Web Services Gateway and WebSphere DataPower SOA Appliances are intended to help simplify and secure the deployment of Web services in the enterprise. WebSphere DataPower SOA Appliances can also be used to improve the performance of Web services applications.
Either the Web Services Gateway or a DataPower appliance can be used to address the WS-Security specification level interoperability problem. As shown in Figure 3, both of these solutions have the capability to proxy a Web service that uses the WS-Security 1.0 specification and make this service available to all Web service consumers that use the WS-Security draft 13 specification.
Note: In the remainder of this article, this workaround is referred to as the middleware proxy approach.
Figure 3. Use a Web Services Gateway or DataPower appliance
Table 2. Roles and tasks for using the middleware proxy approach
|Deployer||Install the Web Services Gateway or DataPower appliance|
Configure the J2EE 1.4 service on the Web Services Gateway or DataPower appliance
|Test engineer||Verify that the Web service consumer works as expected|
One advantage to the middleware proxy approach is that no application development tasks are required. The Web services provider and consumer applications can interoperate through the middleware proxy without changes. For this reason, the middleware proxy scales well when there are many Web service consumers using the WS-Security draft 13 specification that need to be integrated with a Web service provider using the WS-Security 1.0 specification. After the middleware proxy has been installed and configured with a provider service, it can be used to integrate any number of Web service consumers with no additional effort.
Another advantage to this approach is that you gain all of the benefits of using either the Web Services Gateway or the DataPower appliance. These components can simplify deployment and management of Web services in the enterprise and, in doing so, improve the return on investment for your Web services applications and infrastructure. Furthermore, if you choose to use a DataPower appliance, the capabilities in the device can actually improve performance of your Web services applications. For more information on the benefits of the Web Services Gateway and WebSphere DataPower SOA Appliances, see the links in the Resources section at the end of this article.
A disadvantage to the middleware proxy approach is that it introduces a nontrivial set of operations and administration tasks. You must install, configure, and manage the middleware proxy component as any other critical infrastructure component. If you've purchased the WebSphere Application Server Network Deployment Edition, then you already have the Web Services Gateway component, and no additional purchase is necessary. On the other hand, if you choose to use a DataPower appliance, there may be costs associated with acquiring this network device.
Another drawback is that this approach might break the trust model between the Web service consumer and Web service provider. This is because, depending on the security being applied, the middleware proxy may need to verify and decrypt the inbound SOAP message sent from the consumer to the proxy and then reapply security on the outbound SOAP message that's sent from the proxy to the provider. This can have serious implications to your security architecture.
Workaround 3: Use an EJB proxy
If you're looking for a lightweight, low-cost alternative to the middleware proxy approach, using an EJB proxy might be suitable. In this approach, a new J2EE 1.4 EJB application is developed and deployed to the front-end middleware tier, which also hosts the Web services consumer application. This approach requires the front-end middleware tier to contain WebSphere Application Server V6.0 or later, or another J2EE application server capable of supporting J2EE 1.4 applications.
Figure 4 shows how the EJB proxy approach is used to allow a J2EE 1.3 portal application to communicate with a J2EE 1.4 Web service provider. The Portal application communicates with the EJB proxy using the EJB's Remote Method Invocation (RMI) interface, and the EJB passes the request to the Web service provider using the WS-Security 1.0 specification.
Figure 4. Use an EJB proxy
Table 3. Roles and tasks for using the EJB proxy approach
|Application developer||Create the EJB proxy application|
Integrate the Web services consumer with the EJB proxy application
|Deployer||Deploy and manage the EJB proxy application|
|Test engineer||Verify that the Web service consumer works as expected|
The effort required to implement the EJB proxy approach is primarily application-development work, although this workaround does introduce another application that must be deployed, secured, and managed by the operations team.
The EJB proxy approach is best suited to sandbox, test, or proof-of-concept situations in which upgrading Web services consumer applications to J2EE 1.4 is not an option and in which the cost of setting up a middleware proxy is prohibitive. A drawback of this approach is that it doesn't scale well when there are a lot of Web service consumers using the WS-Security draft 13 specification that need to be integrated with a Web service provider that uses the WS-Security version 1.0 specification. In this case, each Web service consumer application must be separately integrated with the EJB proxy, which can make the necessary development effort become large.
Workaround 4: Add a new provider endpoint
In this last approach, you add a J2EE 1.3 Web service endpoint to the J2EE 1.4 provider application. Depending on how your J2EE 1.4 Web service provider application is implemented, it may be a simple exercise to add an additional Web project based on the Java Servlet 2.2 (J2EE 1.3) specification and package this with the provider application. Your provider application will then contain two Web service endpoints as shown in Figure 5.
Figure 5. Add a new provider endpoint
Table 4. Roles and tasks for using the new provider endpoint approach
|Application developer||Create a new Web service endpoint in a new Java Servlet 2.2 Web
Package the new Web project in the J2EE 1.4 EAR file
|Deployer||Deploy and manage the Web service provider application|
|Test engineer||Verify that the Web service consumer works as expected|
This approach scales well when there are many Web service consumer applications. After the Web service provider application is modified so that it provides a J2EE 1.3-compatible Web service endpoint, any number of Web service consumer applications can use this new endpoint. And unlike either the EJB proxy approach or the middleware proxy approach, this approach has no performance impact.
As with the EJB proxy approach, this workaround is primarily an application development exercise and introduces another Web service endpoint that must be managed and secured.
This approach is best used when the Web service implementation classes are simple JavaBeans components or EJB components. If the Web service implementation logic is contained in a servlet, in a Service Component Architecture (SCA) component, or in an Enterprise Service Bus (ESB) mediation module, then it will likely be difficult to create the Java Servlet 2.2 (J2EE 1.3) Web project and package it with the Web service provider application.
Table 4 outlines the relative benefits and drawbacks of the three workarounds described in this article to help you to determine the best workaround approach for your situation.
Table 4. Comparison of workaround benefits and drawbacks
|Upgrade Web service consumer applications to J2EE 1.4||When the number of consumer applications is small and especially when the consumer-side middleware environment is already capable of supporting J2EE 1.4 applications|
|Use a middleware proxy||When there's a large number of consumer applications or when the consumer applications can't be modified|
|Use an EJB proxy||When you need a lightweight, low-cost solution for sandbox, test, or proof-of-concept situations|
|Add a new provider endpoint||When looking for a lightweight solution and when the Web service implementation logic is a JavaBeans or EJB component|
Stay tuned for subsequent articles in this series, which will provide details and examples that show you how to implement the middleware proxy and EJB proxy workarounds.
I'd like to thank the following individuals for their comments and contributions to this article:
- Hyen Chung, architect and lead developer of Web services security on the WebSphere platform
- Billy Lo, senior IT architect, IBM Global Business Services
- Learn more about the Web Services Security specification (developerWorks, March 2004), including an overview of WS-Security, links to the current specification, and related topics.
- Learn more about IBM WebSphere DataPower SOA Appliances.
- IBM Redbooks: "WebSphere Version 6 Web Services Handbook Development and Deployment" describes the concepts of Web services from various perspectives. It presents the major building blocks on which Web services rely. Here, well-defined standards and new concepts are presented and discussed.
- The SOA and Web services zone on IBM developerWorks hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
- The IBM SOA Web site offers an overview of SOA and how IBM can help you get there.
- Visit the developerWorks Architecture area for the resources you need to advance your skills in the architecture arena.
- Stay current with developerWorks technical events and webcasts.
- Browse for books on these and other technical topics at the Safari bookstore.
- Get an RSS feed for this series. (Find out more about RSS.)
Get products and technologies
- Innovate your next development project with IBM trial software, available for download or on DVD.
- Participate in the discussion forum.
- Check out developerWorks blogs, and get involved in the developerWorks community.