Developing XML Web services with WebSphere Studio Application Developer

Web services provide a distributed computing technology for integrating applications over the Internet. Such a technology has the potential to dramatically transform our information-based economy. However, there have been many distributed computing technologies in the past, for example, Common Object Request Broker Architecture ** (CORBA **), Microsoft DCOM **, and Java ** Remote Method Invocation (RMI), yet none has become widespread on the Internet. Although Web services technologies are described in detail in the other papers of this issue of the IBM Systems Journal, it is useful here to briefly compare Web services with the other distributed computing technologies so that we can understand what they have in common and what has changed. Application developers who are already familiar with a previous distributed computing technology will be able to immediately apply much of their knowledge and experience to Web services. An overview of Web services (1) as well as in-depth technical information (2) can be found on the Web.

All distributed computing technologies, including Web services, provide a mechanism for a client program, executing on a local host, to invoke a server function that executes on a remote host and to receive the result of the remote execution. The style used by the client program to invoke the server function depends on the distributed computing technology. For example, the client program may call a remote procedure, invoke a method on a remote object, or put messages on and get messages from a queue. These invocation styles are referred to as remote procedure call (RPC), Remote Method Invocation (RMI), and message queuing.

The programming interface supported by the remote server function is often specified using an interface definition language (IDL). The IDL typically specifies the operations provided by the remote server function, their input and output parameters, and their exceptions. Tools are provided to generate a client "stub," or proxy, and a server skeleton from the IDL. Although the terms stub and proxy are both used in practice, the term proxy is used in the following discussion. The client proxy gives the client program a convenient way to invoke the remote server function. The server skeleton provides a place to include the implementation of the remote server function. The proxy and skeleton hide the protocol details from the local client program and the remote server function implementation.

The local client program calls the client proxy through its programming language interface. The client proxy converts the programming language input parameters into a byte stream that can be sent to the remote server using some protocol and transport mechanism. The process of converting programming language parameters into a protocol-dependent byte stream is referred to as "marshaling." The remote host routes the invocation to the correct server skeleton, which converts the incoming byte stream back into programming language parameters. The processes of converting the protocol-dependent byte stream back into programming language parameters is referred to as "unmarshaling." Marshaling and unmarshaling may also be referred to as "serialization" and "deserialization." The client program and server skeleton may use different programming languages and operating systems. The server skeleton passes the input parameters to the function implementation for execution, receives the execution result, marshals it into a response, and sends it back to the client proxy. The client proxy unmarshals the response and returns the result to the local client program.

If Web services were simply another distributed computing technology, there would be little reason to get excited. However, there are some fundamental differences between Web services and its predecessors that make the technology very powerful. The main difference between Web services and the previous distributed computing technologies is that they are designed for the extremely heterogeneous environment of the Internet. The Internet is composed of a huge number of highly diverse computers, ranging from the simplest client devices to the most complex mainframe servers. In addition, these computers are not under the control of a single information technology department that can impose uniform software standards. Web services specifications are therefore completely independent of programming language, operating system, and hardware, and they enforce very loose coupling between the client and the server.

To see why the programming language and operating system independence of Web services is a major advance, consider the tight coupling present in CORBA, Microsoft DCOM, and Java RMI. CORBA couples the client and server with an underlying object model. In addition, the protocol used by CORBA, Internet Inter-ORB ** Protocol (IIOP **), was not initially specified tightly enough to guarantee interoperation between different vendors. More recent versions of IIOP seek to achieve vendor interoperability. DCOM couples the client and server through the Microsoft Windows ** operating system. Attempts to implement DCOM on other operating systems have not gained significant market acceptance. Finally, Java RMI couples the client and server through the Java programming language. In practice, successful use of Java RMI involves even tighter coupling, because Java object serialization is very sensitive to virtual machine levels and class versions. CORBA, DCOM, and Java RMI are important distributed programming technologies and will not be replaced by Web services in situations where tight coupling is both desirable and possible. However, in situations that require loose coupling, Web services will likely become the dominant technology.

Web services are designed for maximum interoperability across the Internet. Extensible Markup Language (XML) (3) plays a key role as the main data interchange format for Web services parameter marshaling. In comparison with the highly optimized binary formats used by other distributed computing technologies, Web services may appear inefficient, but those technologies entailed tight coupling between the client and server and would therefore never become dominant on the Internet. In addition, the continual improvements in network bandwidth, processor speed, and compression techniques make the more verbose nature of XML of less concern.

The use of XML in Web services is a major difference from other distributed computing technologies and has important application development consequences. In the other technologies, the IDL makes use of data structures that correspond closely with the supported programming languages, often involving certain assumptions about an underlying object model, and the data interchange format is a highly optimized binary stream that tightly couples the client and the server. In XML Web services, the data types are specified using XML Schema (XSD) (4) and the data interchange is in XML format. Although the Web services run-time environment can automatically encode programming language data structures as XML, this introduces coupling between the programming language and the Web service interface. Application developers will find it beneficial to design interfaces using XSD in order to give them greater implementation flexibility. As application developers begin to think in terms of XML rather than programming languages when defining Web services, they will begin to need tools for authoring XSD and Web Services Description Language (WSDL). (5)

As Web services are initially adopted, client proxies and server skeletons will normally be implemented in conventional programming languages, such as Java and JavaScript **. Tools for mapping between XML Schema and programming language data structures will be used to hide the XML details from the programmer. However, as XML becomes more familiar to programmers, its role may broaden to also include processing. Examples of XML processing technology include Extensible Stylesheet Language Transformations (XSLT), (6) XML support in databases such as IBM Database 2 * (DB2 *) Universal Database (UDB), (7) and XML Query (8) language. These technologies allow the programmer to specify processing natively in terms of XML as opposed to converting between XML and conventional programming languages. In many cases it may be more productive for programmers to specify simple processing using an XML technology, and to call out to conventional programming languages, such as Java, for more complex processing. Tools for editing and debugging XML processing technologies will become important.