Easy response to ws-security specification interoperability challenges, part 1th

Easy response to ws-security specification interoperability challenges, part 1th: Overview of issues and four available solutions

Overview of Interoperability issues

Most interoperability issues do not originate from the underlying Web service specification, which is already fairly mature and stable, but are caused by a variety of ws-* Web service extension specifications, such as ws-security. As these standards evolve, vendors must choose which version of the specification to support, and sometimes developers will need to deal with incompatibilities between different specifications.

The Ws-security standard provides a mechanism for applying authentication, integrity, and confidentiality to SOAP messages. These features are often required for use in the Enterprise for WEB services and service-oriented architectures (services-oriented Architecture,soa). Starting with IBM websphere®application Server V5.0.2, IBM® Middleware is beginning to provide support for ws-security. This implementation of Ws-security is based on the 13 specification of the OASIS work. WebSphere application Server V5.1 and other IBM middleware based on Java™2 Platform Enterprise Edition (Java) 1.3 (such as IBM WebSphere Portal Se RVer V5 and IBM WebSphere Business integration Server Foundation V5) also contain ws-security implementations based on the draft 13 specification. With the Java EE 1.4 Runtime contained in WebSphere application Server V6.0, IBM provides ws-security implementations based on the Ws-security 1.0 specification. IBM WebSphere Process Server and other IBM middleware using the Java EE 1.4 Runtime include ws-security implementations based on the version 1.0 specification.

Unfortunately, because of the change in the connection format of the ws-security SOAP Header specification, Web service consumer applications and target Web services that conform to the draft 13 specification cannot interact with consumer applications and target services that conform to the version 1.0 specification. For example, the Java 1.3 Web service consumer application that runs in the WebSphere Portal server V5.1 cannot use ws-security with J that runs in the WebSphere application server V6.0 2EE 1.4 Service Provider application for communication. This problem is not limited to the IBM middleware software stack. For example, Microsoft®.net Web Services Enhancements (WSE) 1.0 is also based on a draft version of the Ws-security specification, and when attempting to enter between this stack and any other stack based on the Ws-security 1.0 specification The same problem occurs when the line communicates.

Figure 1. Ws-security Specification Level incompatibility issues

If you encounter this incompatibility, you can resolve this problem in a number of ways. The remainder of this article describes these options and provides guidance on how to choose the right solution based on business requirements and technical constraints.

For simplicity's sake, let's assume that the Web service consumer application uses the Ws-security Draft 13 specification, while the Web service provider application uses the Ws-security 1.0 specification. Note: The suggested workaround here can also be applied to the opposite scenario, where the Web service consumer uses the Ws-security 1.0 specification, while the Web service provider uses the draft 13 specification.

Workaround 1: Upgrade the WEB service consumer application to Java EE 1.4

The easiest way to completely avoid this problem is to make sure that your Web service consumer application uses the same ws-security specification version as your Web service provider application. This requires upgrading your WEB service consumer application to Java EE 1.4 and, if possible, upgrading your middleware to a version that supports the Java EE 1.4 application.

One development approach is to upgrade the Java 1.3 Web service consumer application to Java EE 1.4. IBM rational®application Developer provides the Java EE Migration Wizard, which enables Enterprise JavaBeans (EJB) projects, Web projects, Java EE Connector architecture (JCA) Connector Projects and Web services migrate from the Java EE 1.3 specification level to the Java EE 1.4 specification level.

To migrate the Java EE 1.3 application to Java EE 1.4 using the Java EE Migration Wizard, right-click the Enterprise application project in Project Explorer view of Java EE Perspective, and then from the pop-up menu Single Select Migrate > Java migration Wizard. After the wizard completes, you can configure the Ws-security client bindings. The wizard does not migrate these bindings automatically, and must be manually configured after the migration is complete.

Next, you need to make sure that the application server that the WEB service consumer application deploys to can support Java EE 1.4 applications. For enterprise applications, WebSphere application Server V6.0 can run Java EE 1.4 applications. For Portlet,websphere Portal Server V5.1.0.4, you can run a WEB project that migrates to Java EE 1.4. If these or newer versions are used, the migrated Web service consumer application should work correctly without any problems. Otherwise, you may need to upgrade the middleware.

Figure 2. Upgrading a WEB service consumer application to Java EE 1.4

Table 1. Roles and tasks involved in upgrading Web service consumer applications to Java EE 1.4

Role	Task
Application Development Staff	Migrating Web service consumer applications to Java EE 1.4
Development staff	Setting up the Java 1.4 Operating environment for WEB service consumer applications
Test Engineer	Verify that the migrated Web service consumers work as expected

migrating applications and, if necessary, middleware to Java EE 1.4 is the preferred way to avoid ws-security specification-level interoperability issues. It eliminates the problem completely and provides a strategic advantage in the latest middleware code levels.

However, depending on your application and the middleware environment, it may be inconvenient or difficult to migrate your Web service consumer applications to Java EE 1.4. Also, as the number of WEB service consumer applications that must be migrated using the Ws-security Draft 13 specification increases, the amount of work required to implement this method increases linearly.