The first time you sign into developerWorks, a profile is created for you. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. You may update your IBM account at any time.

All information submitted is secure.

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerworks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

All information submitted is secure.

My developerWorks:

My notifications:

Sign out

Select a language:

Tackle WS-Security specification interoperability challenges, Part 1: Problem overview and four available workarounds

David Leigh (dleigh@us.ibm.com), Senior Software Engineer, IBM

David Leigh is a Senior Software Engineer in IBM Software Group's Scenario Analysis Lab organization, located in Research Triangle Park, North Carolina. His areas of expertise include IBM WebSphere Process Choreographer, application and server security, high availability, monitoring, IBM AIX®, and Linux®.

Summary: Are you struggling with a WS-Security specification level interoperability problem? Web services are often promoted as the ideal solution to application interoperability, and they are effective at integrating applications regardless of platform, vendor, and programming language. But they're not immune from interoperability issues. Discover some common problems caused by incompatibilities between different versions of the WS-Security specification, and find the best way to deal with the issues in your environment. Be sure to check out the handy chart at the end of the article to compare the benefits and drawbacks of each solution.

View more content in this series

Date: 03 May 2007
Level: Intermediate
Also available in: Chinese Russian Portuguese Spanish

Activity: 7801 views
Comments:

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
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 V5.1.0.4 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
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

Role	Task
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
Use a Web Services Gateway or DataPower appliance

Table 2. Roles and tasks for using the middleware proxy approach

Role	Task
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

Role	Task
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
Add a new provider endpoint

Table 4. Roles and tasks for using the new provider endpoint approach

Role	Task
Application developer	Create a new Web service endpoint in a new Java Servlet 2.2 Web project 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.

Summary

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

Approach	Benefits	Drawbacks	Best used
Upgrade Web service consumer applications to J2EE 1.4	Being at the latest middleware and J2EE specification levels No performance impact	Not very scalable; each Web service consumer application must be migrated separately Middleware migration may also be required Some applications and middleware environments may be inconvenient and difficult to migrate	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	Very scalable; after configured, the proxy can support any number of consumer applications No changes needed to consumer or provider applications Ease of management benefits from the Web Services Gateway or DataPower appliance Performance benefits when using a DataPower appliance	Additional operations and administration tasks required to support a new critical infrastructure component Some performance impact when using the Web Services Gateway May break trust model if the proxy needs to verify and decrypt the inbound SOAP message and then reapply security on the outbound message	When there's a large number of consumer applications or when the consumer applications can't be modified
Use an EJB proxy	Implementation is a basic programming exercise, thus no extra infrastructure is required	Some performance impact Not very scalable; the EJB proxy must be integrated with each consumer application Introduces a new application that must be deployed, secured, and managed	When you need a lightweight, low-cost solution for sandbox, test, or proof-of-concept situations
Add a new provider endpoint	Implementation is a basic programming exercise, thus no extra infrastructure is required No performance impact Very scalable; after configured, the proxy can support any number of consumer applications	Not easily implemented when the Web service implementation logic is more complex than a simple JavaBeans or EJB component Introduces a new provider endpoint that must be secured and managed	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.

Acknowledgements

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

Resources

Learn

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.

Discuss

Participate in the discussion forum.
Check out developerWorks blogs, and get involved in the developerWorks community.

About the author

Close [x]

Report abuse help

Report abuse

Thank you. This entry has been flagged for moderator attention.

Close [x]

Report abuse help

Report abuse

Report abuse submission failed. Please try again later.

Close [x]

developerWorks: Sign in

All information submitted is secure.

Close [x]

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.