The creation and popularity of Web Services are growing rapidly in every industry. With this continued growth, more and more programmers find themselves writing code that, even if it's not currently packaged as a Web Service, will eventually be exposed as one.

As more enterprises move toward an e-business strategy, communication and integration of existing information systems is key. When integrating existing information systems with Web Services, enterprises will usually face one of the following two scenarios:

• The enterprise information system is comprised of legacy systems. To offer services and share data with business partners, customers, and other information systems, businesses must update these legacy systems with current technology and expose them as Web Services.
• The enterprise information system may have middleware already in place, but this middleware needs to be exposed as Web Services.

However, despite Java's strengths, the devil is in the details - there will always be a number of drawbacks that developers must face when building and deploying Web Services, regardless of architecture. This article will discuss the strengths that Java has over .NET and address some of the pitfalls that developers should be wary of when exposing legacy systems and middleware as Web Services.

Exposing Legacy Systems as Web Services
Many of today's large businesses have existing legacy systems written in different languages, such as COBOL and C++. These companies have spent enormous sums of money and have collected huge amounts of data maintaining these legacy systems. Therefore, it's crucial that companies find a quick and efficient way to preserve and reuse these legacy systems to integrate and expose them as Web Services. This legacy integration is often one of the greatest challenges to tackle when building a Web Service. However, Java provides a relatively simple solution for legacy integration.

The J2EE Connector Architecture (JCA) can be used to integrate legacy systems. The JCA is a specification for creating resource adapters that understand how to communicate with existing legacy systems, such as those written in COBOL, C++, etc. These resource adapters are reusable in any container that supports JCA. Currently there are a large number of major vendors in the marketplace that produce adapters and support JCA.

.NET also offers legacy integration through the Host Integration Server 2000. However, there's limited connectivity to legacy systems through the Host Integration Server because there's little other support for it besides Microsoft. Since so many vendors already support JCA and offer resource adapters, integration with legacy systems becomes much easier.

Java's portability plays a large role in developing Web Services too. The programs created in Java are portable in a network and can run on various platforms and operating systems such as Win32, Unix, and mainframe systems. This is a big advantage since most e-businesses have clients and customers that exist on a variety of platforms.

On the other hand, .NET's portability is at best limited since it only runs on Windows machines. Although the Mono project is attempting to create an Open Source implementation of .NET, the status of the project is still uncertain. For example, Microsoft has recently applied for a patent on the .NET Framework classes. Regardless of Microsoft's true intentions, the question still remains - how much of the .NET Framework will Microsoft allow to be supplied on other platforms?

Exposing Middleware as Web Services
Besides the integration of legacy systems, another scenario that an enterprise may face is the integration of middleware as a Web Service. The intermingling of Web Services and Java is only natural, since services communicate with other services via middleware applications and most enterprise systems today already have middleware written in Java. If this is the case, then the exposure of Java middleware as Web Services is relatively easy with the use of any Java library.

A number of third-party libraries (such as Apache Axis) are readily available to accelerate the development of Web Services. These libraries store object-oriented routines and class definitions that can be "called" instead of having to write new code or make any modifications to the original legacy environment - a process that can cause innumerable complications.

Although companies can tap the strengths of Java without having to reinvent all of their existing systems, Java isn't the cure-all it may seem. Using Java to expose legacy systems and middleware as Web Services isn't difficult to do, but it is difficult to do right.

Issues of Concern
Despite the seemingly simple process of converting Java classes into XML for Web Services, it's still more difficult than developers realize. Regardless of architecture, be it Java or .NET, there will always be a number of details that developers must consider when building and deploying Web Services. And as said before, the devil is in the details. The following illustrates some examples of these details.

SOAP Message Structure
If you're trying to integrate systems of disparate backgrounds, you must resolve the mismatches of the SOAP message structures in both systems. For example, if you're integrating a Java implementation with a .NET implementation, the Java implementation may use a RPC style with SOAP encoding, while the .NET implementation may use a document style with literal encoding.

This difference has to be resolved to ensure interoperability. Using literal XML (no encoding) instead of SOAP encoding may be of greater benefit since SOAP encoding interferes with schema validation. Indications that the industry is abandoning SOAP encoding can be seen from its omission from the WS-I basic profile.

The question of RPC versus document style isn't as clear-cut. Microsoft's .NET prefers document style and most other toolkits prefer RPC. From a schema validation standpoint, document style is superior. Furthermore, by abandoning SOAP encoding, some of the benefits of RPC style are diminished. However, RPC is common enough that integration projects will often involve some RPC services. Keep in mind that RPC messages have an additional "wrapper" element that's the name of the operation.

Also, although the message declarations in the WSDL are, in theory, not specific to a particular binding and don't commit to RPC versus document style, in practice there's a strong correlation between the way messages are declared and the bindings that are used. A common pattern is that messages with parts that are declared in terms of elements are intended to be used bound to a document style while those with parts declared in terms of types are intended to be used by the RPC style.

Example message declaration (intended for document style):

<message name="echoStringSoapIn">
     <part name="parameters" element="s0:echoString" />
   </message>
     Example message declaration (intended for rpc style)
   <message name="echoStringSoapIn">
     <part name="parameters" type="xsd:string" />
</message>

Serializing and Deserializing
Serializing and deserializing is the process by which data is converted from programming language-specific data structures (such as Java classes) to and from SOAP-compliant XML. For different machines to understand the serializer/deserializer translations, you must decide how to lay out the Java objects in each machine. The meaning an object has in one machine may not necessarily have the same meaning in another machine. Dealing with primitive types is rather simple; however, when dealing with more complex types, serialization becomes more of an issue.

For example, a complex class may have several strings. If two of these strings are identical, you must decide whether to treat these strings as two references to one string, or to treat them as two separate strings. This decision ultimately affects how the strings are translated on either side of the Web Service.

Note that the reference/value distinction is only available in SOAP encoding. A common practice in Java is to form Bean classes, where accessor methods follow a simple pattern. This allows reuse of a common serializer/deserializer pair, decreasing the amount of extra code to be maintained. An example of this is the following simple class for an employee data structure:

public class Employee {
    private String first;
    private String last;
    private int number;
    public Employee() {
    }
    public Employee(String first, String last, int number) {
       this.first = first;
       this.last = last;
       this.number = number;
    }
    public String getFirst() {
       return first;
    }
    public void setFirst(String first) {
       this.first = first;
    }
    public String getLast() {
       return last;
    }
    public void setLast(String last) {
       this.last = last;
    }
    public void setNumber(int number) {
       this.number = number;
    }
    public int getNumber() {
       return number;
    }
}

Note that the accessor methods follow a get/set naming convention that lets the bean serializer/deserializer recognize them automatically. Also, a public no argument constructor must be available for deserialization even though, in this case, the class would be better off without it from a type safety point-of-view. Keep in mind that you will either need to maintain some bean classes like this for structured data to serialize or write custom serializers and deserializers.

Conclusion The future of e-business undoubtedly lies in Web Services. For organizations that are building and developing Web Services, or are preparing for a future of Web Services, their underlying architecture must have strong Web Services support. Java provides this support with its J2EE Connector Architecture, portability, and extensive class libraries - all of which allow for translating to Web Services without any major rewrites. Organizations building and developing Web Services will do well by moving forward in this direction, while avoiding the pitfalls that inevitably arise when working with new technologies.