Web Services versus Distributed Objects

A further difference between web services and traditional distributed object middleware lies in the design approach of the two types of system. Web services are best thought of as "top-down", aiming first to identify the business process to be modelled, while distributed model architectures can be thought of as "bottom-up" in their emphasis on technical details at a low level. Legacy system integration can also be considered a "bottom up" approach in that it can start from an existing low-level application. In a pure "top-down" approach, WSDL is supposed to be the starting point of a web service, although many web-service toolkit vendors, anxious to pre-empt the learning curve that WSDL requires, ignore this requirement and attempt to generate the WSDL for each service from the code written for it. The problems caused by this approach are discussed in Chapters 4 and 7.

5 See www.cs.washington.edu/woogle.

With object-oriented languages such as Java, C# and, more recently, PHP, objects form the base of the coding and creation of a web service, but web-service programming objects are not passed between the client and the service. Only public methods are exposed in a service interface and only a data representation of the public fields may be exchanged. An object has state, but web-service messaging is stateless (there is no way of defining state in WSDL). Objects have traditionally been serialized in a binary encoding, while web services serialize data in XML.

Recent technology may make both these approaches available to web services, although whether such methods are counter to the interoperability objectives of web services remains to be seen.

The original developers of XML certainly thought so [Bray, 2001], at least in terms of message transmission between PCs, though it would be contrary to the principles of interoperability to think only in terms of one platform, particularly when there is currently a great expansion of possible platforms across multiple devices.

Vogels is in no doubt about the differences between web services and distributed object systems, itemizing his reasons as follows:

Web services share none of the distributed object systems’ characteristics. They include no notion of objects, object references, factories, or life cycles. Web services do not feature interfaces with methods, data-structure serialization, or reference garbage

collection. They deal solely with XML documents and document encapsulation [Vogels, 2003].

Of interest in this context is that JAX-WS has removed the need for web services to create an interface, relying now wholly on the implementation class and thereby possibly acknowledging that WSDL is a sufficient interface.

2.4.2.5.1 Comparisons Between Web Services, CORBA and RMI

In contrast to Vogels, Gray's comparative study of web services, CORBA and Java-RMI [2004]

makes a convincing argument that there are more than superficial similarities between distributed object systems and the static stub client model for web services (discussed in Chapter 4). His diagram in Figure 2-4 illustrates the similarities by showing how a client-side stub can be

generated from an interface definition in web services, in CORBA and in Java-RMI. The similarity between Java-RMI and web services is particularly significant in that the J2EE 1.4 implementation of web services is built upon the earlier technology of servlets and RMI.

All three approaches here are shown by Gray to start with a type of interface from which a client stub may be produced – although the interface type differs between Java-RMI, where it is an interface in code, and web services which ideally should start not with code but with a WSDL definition, the focus of section 4.3.3 in Chapter 4.

Web Service CORBA Java-RMI

Java Remote Interface

WSDL IDL

Figure 2-4: Generation of Client and Server Components from Interface for Web Services, CORBA and Java-RMI [adapted from Gray, 2004]

Burner emphasizes a similar difference between web services and CORBA when he explains:

"Making the messages and the service contracts the design centre of web services is the fundamental difference between the web-services architecture and CORBA" [Burner, 2003].

Gray offloads the blame for ignoring this architectural ideal onto the JAX-RPC and .NET

development environments, which not only permit but also encourage the model to be developed in reverse, and adds: "This bottom-up approach is easier for most developers" [2004]. He also dismisses the differences between a WSDL file and a remote interface definition with the comment that: "The inclusion of the service end point's URI⁶ is really the only major semantic

difference from an IDL or java.rmi.Remote interface declaration", making light of the significance of the encoding and the focus on message passing crucial to web services.

Technology Total Latency Total Packets Total data transferred in bytes

WS 0.11s 16 3338

CORBA 0.48s 8 1111

CORBA & name server

0.86s 24 3340

Java RMI 0.32s 48 7670

Table 2-1: Gray's results for a single (simple) exchange

Further differences between the three approaches begin to appear in the communication process.

While all three employ connection-oriented protocols, CORBA and Java-RMI use tightly-coupled methods that require state to be maintained, while web services need statelessness in order to be loosely coupled.

Gray's comparative findings on speed and efficiency vary, depending on the complexity of the data transferred in the examples he uses. For a single exchange with simple data, the web-services technology was both faster and more efficient, unless CORBA was run without a name server, as Table 2-1 above illustrates.

Gray pinpointed a significant difference in the payload size for his web-services example as opposed to that for CORBA and Java-RMI. Web services can be and frequently are used for the transmission of much more data than is usual in the other two technologies, and the transmission of text with XML tags further increases the size of the data to be transmitted. He found that the number of packets transmitted was much greater for web services in all cases, as can be seen from his statistics in Table 2-2.

Gray's simple "Calculator" example, with four arithmetic methods accepting and returning integers, transferred only numerical data. His "iterator" example repeatedly invoked the service inside a loop. The "data" service returned a data structure, while the "large data" example modeled the retrieval of potentially much more complex data from a database.

Even with the use of a Serial API for XML (SAX) parser, which does not have the considerable memory overhead of a Document Object Model (DOM) parser, there was still significantly greater system-resource usage for the web-services "data" and "large data" examples. Gray found the average memory usage for the "large data" example were (for web services) 4.75MB, (for Java-RMI) 2.6MB and (for CORBA) 2.0MB. With the "iterator example", however, the web-service system performed at a level closer to CORBA (~2.1MB), when it was adapted to become a hybrid of web services and CORBA. This greater economy was achieved by a sacrifice of statelessness and loose coupling, both necessary features in web services.

Packets transmitted for the different technologies

"Calculator" "Calculator" "Calculator" "data" "data" "data" "large data" "large data" "large data" "iterator" "iterator"

Thousands

Technology with example

Number of packets transmitted

Table 2-2: Packet Numbers for the Different Technologies [Jeckle et al., 2004]

With a package size of nil, similar results were initially demonstrated in a DaimlerChrysler presentation, illustrated in Table 2-3, which aimed to compare Java-RMI, CORBA and SOAP [Jeckle et al., 2004]. Jeckle et al., however, found that, with large payload sizes, the package size differences virtually disappeared, with CORBA ultimately displaying the heaviest package size. They came to the conclusion that "package size scales linear with payload size", but that response times grew exponentially with package size, almost evening out the higher cost of the HTTP overhead for SOAP. Larger payload sizes produced a better performance for SOAP sent

directly over TCP rather than over HTTP. They reached the conclusions that the SPEC 2000⁷ value of the server correlated well with web-service performance; that HTTP, rather than SOAP, was the performance bottleneck; and that there was plenty of room for optimizing web services to increase their performance further.

Table 2-3:Package sizes with a payload first of 0 bytes and then with a payload of 10,000 bytes [Jeckle et al., 2004]

In other sections of his investigation [2004], Gray tossed aside the central question of data representation in web services with a casual: "Tiresome practical details like common data representations are avoided through the use of textual representations." His major concerns were comparative message transmission times, CPU and memory usage, and his testing was all local and Java-based. His study raised interesting questions about the usefulness of session state, a feature of both CORBA and Java-RMI, and he produced helpful data on both latency and system resource consumption, but his omission of the interoperability and data representation issues made his study significantly incomplete. RMI works properly only when there is a JVM on both the web server client and the server machines. Because the central issue of web services is interoperability, RMI is an inappropriate tool for making web-service calls.