Related Topics: Java EE Journal

J2EE Journal: Article

Making Them Work Together

Making Them Work Together

Another platform battle is brewing in the industry, or at least that's what the journals would have you believe. Will it be Microsoft's .NET platform, or J2EE supported by Sun, IBM, HP, and others? We don't know, but the more important question is: "Who cares?" Presumably, Microsoft and Sun care, but for the rest of us, the battle of the Web services platforms misses the entire point of Web services. Web services are everywhere (or will be in the near future), and Web services provides interoperability between platforms, languages, and applications. So in terms of interoperability and integration, we don't have to care about what platform we, or our partners, choose.

There will, of course, be valid reasons to choose a platform - enterprise scalability and reliability, tools support, ease-of-use, deployment, and so on, are all good reasons for choosing one platform over another. What we must do is compare the characteristics of the platforms against our requirements. When we do this, we typically find that one platform is better for certain types of applications and the other is better for other types. Generally, enterprises have many different applications requirements and end up with many application platforms. Web services enables us to choose the best platform for our particular application without having to worry about how it will interoperate with applications built on other platforms.

What Is Interoperability?
In the context of .NET and J2EE platforms, we can think of two different types of interoperability, shown in Figure 1. With client/server interoperability, either a .NET client is trying to make use of a Web service provided by a J2EE server application (scenario 1), or a J2EE client is trying to use a Web service provided by .NET (scenario 2). This may be a J2EE client or a J2ME client, such as a mobile device. We assume that a .NET client can use .NET services and a J2EE client can use J2EE services.

With peer-to-peer interoperability (scenario 3), one service uses another as part of its implementation. In reality, this is a special case of scenarios 1 or 2 because, for example, client code to access the J2EE service is actually embedded in the .NET service. Peer-to-peer scenarios typically have added requirements for interoperability of security, transactions, and other services that may not be present in client/server scenarios.

Figure 1 illustrates logical interoperability, or the combination of roles and platforms that have to interoperate. What does this interoperation imply? It could mean the ability to:

 
  • Discover Web services
  • Connect and exchange messages
  • Share or participate in common platform services (security, transactions, etc.)
  • Cooperate in extended business applications
These issues illustrate another important dimension of the problem we'll call functional interoperability, or how two applications actually interact. Figure 2 shows the various layers of technology where interoperation must occur for complete application functional interoperability.

 
  • Transport: At the lowest layer, the transport level, the two applications must agree on a common transport. With Web services, this is most often HTTP or HTTP/S (the secure version), although Web services support other transports as well.
  • Messaging: The next level of agreement must be around the format and encoding of messages sent over the transport. In addition, many applications require an added degree of message-delivery guarantee, so some form of reliable messaging protocol needs to be shared between the sender and receiver.
  • Platform services: Many applications, especially those used to conduct business, will require shared context around security and transactions. Interoperability at this level requires that the platforms share a common set of information for security and transactions, that they agree on how that information is represented, and that it's processed in a similar manner.
  • Application-level services: In addition to security and transactions, some applications will require agreement on application-level services such as licensing and billing.
  • Application semantics: Finally, once all of the transport, messaging, and service layers have been crossed, the applications have to agree on what the actual content of the exchanged messages means. For example, if they're automating a purchasing process, they must agree on what the fields in the message are, the syntax of those fields, and what the fields mean in terms of the purchase order process.

    These layers are involved with the exchange of messages between a client and a service, or between applications. Before the exchange can take place, the client must locate the service. This is a two-part process, the first part being the description of the service and registration by the service provider, and the second being discovery and selection of the service provider by the client.

  • Description: The platforms must agree on the format and schema associated with the Web service description, i.e., what and how it's described and the information required to associate a provider with a specific service. Web services cleverly separates these concepts so, for example, services can be described by industry-standards groups and providers can independently offer competitive versions of those services. In Web services, WSDL describes the messages and operations of a Web service, as well as its binding to specific providers' ports and transports.
  • Discovery: The Web service provider needs a place to publish the information, and the client needs a place to look that information up. In Web services, this is in a UDDI repository, which allows lookup either by service name (white pages model) or by category (yellow pages model). Not only do the client and provider need to agree on the repository and the schema for storage, they also need to agree on the categories or other information used to search for or select a particular service or provider.
Today, Web services software vendors are concentrating on interoperability at the messaging layer and around description and discovery. (Interoperability around HTTP is already established.) The industry and standards community are working hard on security and transactions, but there aren't any agreed-upon specifications or implementations yet. Less activity is taking place around application services. Finally, some industry groups, like AIGI for the automotive industry and HL7 for healthcare, are working on providing XML Schema and definitions at the application semantics levels. Many of these activities are focused on using ebXML, sponsored by the United Nations and OASIS (see www.ebxml.org), to provide a framework for the lower levels of interoperability.

Interoperability at the SOAP Level
SOAP (Simple Object Access Protocol) is used to describe the Web services messages exchanged between a client and a service provider. Unfortunately, SOAP isn't quite that simple; SOAP isn't always SOAP. There are four different encoding and use styles that can be applied to SOAP messages:

  • RPC/Encoded (common)
  • RPC/Literal
  • Document/Encoded
  • Document/Literal (more robust with XML schemas)
These types identify whether the Web service is being used in an RPC-style exchange or a document-style exchange and how data is encoded.

In an RPC-style Web service, the input parameters are specified and provided separately (much like a typical object-method signature). In a document-style Web service, the input data is assembled in an XML document that is then passed as a single parameter to the Web service. In the early use of Web services (where they are used to expose simple J2EE or COM objects), and with simple Web services, the RPC style is quite common. However, as Web services are applied to more-complex and higher-value business services, a different interface style is being adopted. This conveniently corresponds to the evolution of XML from the use of DTDs to the more semantically powerful use of XML schemas. Moving forward, we expect to see Web services using XML schemas to describe their data exchange and to use the document style of encoding to pass that data.

Most SOAP implementations don't support all four of the encoding styles, so for interoperability at the SOAP level, it's important to have two implementations that support an encoding in common. This is true whether it's two different J2EE-based products, or J2EE and .NET. In the latter case, .NET supports the RPC/ Encoded and the Document/Literal formats, so it's important to choose a J2EE product that supports at least these two formats as well.

Interoperability and Discovery
Discovery of Web services takes place at two different but equally important times. Most often, we talk about discovery at runtime and a client looking up a Web service in a UDDI repository. We also need to find a Web service during development time so we can include it in our own client or service program.

Visual Studio .NET (VS. NET) uses Web Services Inspection Language (WSIL) to make external Web services available to a project. WSIL allows a server to describe all of the different Web services offered on that server, and to point to the appropriate WSDL for each one. When a developer provides VS .NET with the URL to the server, it can then inquire about the services offered and dynamically build a list of services that can be included into a VS .NET project (from a drop-down list). The metadata about those services (interfaces, types, etc.) is also available from the WSDL information referenced by WSIL.

If your interoperability scenario includes using J2EE Web services from .NET (which will be fairly common), then it's important that the J2EE platform support both types of discovery mechanisms, UDDI and WSIL.

Interoperability Testing and WS-I
How can you determine the capabilities of a particular product or platform? Web services vendors understand the importance of standards and interoperability. They recognize that the real value of Web services is that they are everywhere and they work together (much like an underpinning of the Web is that any browser can access any Web page). To this end, a lot of testing has already been done to demonstrate interoperability.

A group called SOAPBuilders began informal testing between different SOAP implementations in late 2001. Several sets of tests were performed around SOAP messages and data types, verifying interoperability for simple data types, constructed data types, and headers. The first round of testing measured interoperability between 27 different SOAP implementations. The second round measured interoperability based on WSDL definitions of the messages. The results of these tests (and all the gory details) can be found at
www.xmethods.net/ilab
. To learn about the most recent interoperability event, see www.xmlbus.com/interop.

One of the outcomes of this effort seems almost obvious in retrospect: all parties need to agree on the same set of specifications. To promote these and other interoperability issues, a new industry-wide organization called the WS-I, or Web Services Interoperability Organization (www.ws-i.org), was formed in early 2002. The group's official charter is to "promote Web services interoperability across platforms, operating systems, and programming languages." An important aspect of this work is the specification of Web services profiles, which are a set of interoperable specification versions. Through the use of profiles, the number of combinations of technologies that need to work together can be reduced to a manageable level. The first profile, WS-I Basic, specifies:

  • XML Schema v1.0
  • SOAP v1.1
  • WSDL v1.1
  • UDDI v1.0
Additional profiles will be created as work in Web services specifications continues, not only in the existing specifications (SOAP v1.2, WSDL v1.2), but in the other areas of message extensibility, binary attachments, routing, correlation, guaranteed message exchange, signatures, encryption, transactions, process flow, inspection, discovery, and so on.

Web Services Need to Be Designed
Another issue deals with the type systems supported by .NET and J2EE and their translation into XML as described by WSDL. For example, should the following data structure be mapped to java.util. Vector, java.util.List, or a Java array of SOAPStruct Objects?

- <complexType name="SequenceOfSOAPStruct">
- <complexContent>
- <restriction base="SOAP-ENC:Array">
<attribute ref="SOAP-ENC:arrayType"
wsdl:arrayType="xsd1:SOAPStruct[]" />
</restriction>
</complexContent>
</complexType>
The problem is equally thorny when translating from certain Java or .NET types into XML. There are no simple answers, but when we look into the issue more deeply we see that it's not possible to simply take any existing Java or COM object and expose it as a Web service (despite what the marketing material may say). So, there are two important considerations. First, choose a Web services platform with a data type translation mechanism that is complete and flexible enough to support your requirements. More important, design Web services interfaces first and then map them to a specific implementation. There are several important reasons for this:
  • Web services interfaces should be independent of implementation platform.
  • We (or someone) may want to implement the same Web service on many different platforms.
  • Existing J2EE or COM objects are typically too low level (fine grained) for proper Web services invocation over the Internet.
  • The interaction style (lookup, creation, invocation) of J2EE or COM objects isn't appropriate for Web services (and shouldn't appear in the interface).
  • Passing object references and other common J2EE or COM constructs is not appropriate for Web services interfaces.
Many reasons not related to interoperability should encourage us to design Web services first, rather than simply map existing J2EE, COM, or other objects to WSDL. Well-designed Web services will provide high-level, loosely coupled interfaces that correctly expose external business functionality while simultaneously hiding internal information and processes from the users of those services. These interface characteristics will allow Web services implementations and functionality to evolve without breaking existing clients and will help to create more reusable services. Conveniently, they also help with interoperability.

Recommendations
The issues of interoperability are complex, and it will take the industry a while to address the different levels. Currently, the focus for interoperability is around the Web services technologies described by the WS-I Basic profile. At the same time, the Web services community is busy advancing the specifications to cover reliability, security, transactions, and application services. This doesn't mean we can't use Web services today. Many real business applications are using Web services to integrate .NET and J2EE platforms. From these applications, and our analysis of the problem, we can suggest a few basic guidelines to help achieve interoperability.

  • Use profiles: Stick to the profiles published by the WS-I to minimize dependencies between specification versions.
  • Design: Design your Web services first and then map their definitions to specific platform implementations (whether existing or new). This will not only increase interoperability, it will result in better, more reusable Web services.
  • Choose wisely: Carefully examine your application's requirements and choose a Web services platform that meets them. Evaluate scalability, reliability, skillsets, ease-of-use, tools, cross-platform tool integration, performance in interoperability tests, sophistication of data mapping, and so on. Don't get caught up in the hype about the battle for the platform.
Following these principles, you can begin to use Web services in your applications with the confidence that they'll be interoperable with other platform implementations, and with the knowledge that you'll be building sound, reusable Web services for today and the future.

More Stories By Ben Bernhard

Ben Bernhard is the IONA XMLBus Engineering Manager. He is responsible for the product's technical direction and implementation. The XMLBus includes a Web Services Builder that allows rapid construction of Web services from existing systems and the industry's first Web Services Container.

More Stories By Mike Rosen

Mike Rosen is Chief Enterprise Architect at IONA Technologies. He consults on the architecture and design of Web service and enterprise component applications for global corporations in Telecom, Insurance and Finance. Mike has over 20 years of experience in distributed technologies including J2EE, XML, CORBA, COM, DCE, transaction processing, and messaging. He speaks and writes frequently, including his book: Designing E-business Systems and Architectures: A Manager's Guide (2000).

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.