Comparison of Web Services, Java-RMI, and CORBA service

implementations

N.A.B. Gray
School of Information Technology & Computer Science,
University of Wollongong
[email protected]

Abstract The client-stub approach results in code that is very

similar to Java-RMI or CORBA clients.
This paper reports on comparisons of Web The analogous mechanisms for generating client
Service, Java RMI, and CORBA solutions for and server components for Web-Services, Java-RMI,
example applications. Performance problems, and CORBA are illustrated in Figure 1. When auto-
identified in earlier studies of Web Services, have generated client-side stubs are used for Web
been significantly reduced in the current Services, the development processes and the code
implementations. The newer Web Service APIs complexity for both client- and server-side are
realize a model that has significant overlaps with virtually identical for Web Service, Java-RMI, and
distributed object technologies, allowing in some CORBA solutions. Typically one starts with an
cases for the use of a common code base in either a interface definition for the service. A client-side stub
readily deployed Web Service or in a higher- is auto-generated from this interface. On the server-
performance distributed object style implementation. side, the interface is processed to yield a base class
for the implementation class that must be written by
1. Introduction the developer. With the mechanisms and costs of
development being very similar, other factors will
Web Services [1] present another alternative determine the choice of a technical solution. Systems
distributed computing infrastructure; an alternative developers will have to choose between
that is being strongly promoted as preferable to the interoperability where Web Services have
use of distributed object middleware such as Java advantages, and performance that will favor Java
RMI [2] or CORBA [3]. RMI or CORBA.
Web Services differ from the distributed object Java RMI and CORBA use optimized connection-
technologies in that they have reverted to an earlier oriented communications protocols that are either
“remote service” model similar to that in DCE. language specific, or have detailed rules defining
There is no concept of an object reference; instead a how data-structures and interfaces should be realized.
service is defined simply by an end-point that In contrast, Web Services (application-to-application)
supports various operations. In terms of Java-RMI or are based on the ubiquitous technologies that have
CORBA, a Web Service is like a singleton server grown up to support WWW-services (human-via
object. The singleton server character of a Web browser-to-application). Communications use
Service means that a stateless-server architecture is HTTP. HTTP is universally supported, and HTTP-
preferred; though there are mechanisms permitting traffic can normally pass through firewalls. Tiresome
the implementation of stateful-servers. practical details like common data representations are
Web Service implementations support different avoided through the use of textual representations.
client-side application programmer interfaces; client All numeric and other data are converted to text.
code may work by constructing “call” objects that are Meta-data, defining structure, are provided in situ as
dispatched to the server, or may use a higher level XML mark-up tags. XML parsers allow client and
interface that hides the communications level entirely server implementations to construct their distinct but
through the use of client-side stub objects with an equivalent representations of any data structures
operational interface that mimics that of the server.
 Web Service CORBA Java-RMI

WSDL IDL Java

--- --- remote
--- --- ---

wsdl processing
idl compiler
Server (base)- Implementation
class
or interface client POA
stub skeleton
rmic
client
stub
client
stub
Implementation Implementation

Figure 1 Generation of client and server components from interface for Web Services, CORBA,
and Java-RMI.

implementations, finding a degradation factor of up

The use of HTTP, and XML text documents, to 400 in performance; performance was improved
supports increased interoperability but also represents by modifications of drivers and parsers [4]. Davis
a significant increase in run-time cost for Web and Parashar compared several Web Service
Service solutions as compared with Java-RMI or implementations (Java, Perl, .Net) with Java-RMI
CORBA solutions. The stateless hypertext transfer and CORBA [5]; they were qualified in their
protocol was devised originally for downloading conclusions but tended to prefer Java-RMI until
individual files and is not ideally suited to SOAP-based Web Service technology had further
applications where multiple requests and responses improved. Both groups identified specific issues
may be need to be exchanged. The XML formatted with XML parsers and the HTTP transport protocol.
documents are inherently more voluminous than the This work uses more recent implementations of
binary data traffic of the other approaches. More the Java Web Service components. These offer a
data have to be exchanged across the network, and higher-level client-side API, and achieve better use of
more control packets are required. Conversion to HTTP. Earlier studies have mainly looked at
text format and parsing of XML documents is examples where the defined service returned either
inherently more costly than the alternative single data elements or data arrays of primitive types
mechanisms used to convert data to a common data such as integers, reals, or strings. The examples here
representation for the network. The additional include those more representative of intranet
communications and processing costs are frequently applications that involve multiple queries and queries
perceived as a potential barrier to the use of Web that yield large amounts of data. If Web Services are
Services technologies. to replace CORBA and Java RMI, they must handle
The work reported in this paper extends that in such queries effectively.
earlier studies on the costs associated with Web The Middleware Technology Evaluation project,
Service SOAP communications. Elfwing et al. hosted by the CSIRO division of Mathematical and
compared Web Services to CORBA both as Java Information Sciences, has demonstrated the
practicality and value of comparative performance presented here are for situations where the server was
studies on commercial implementations of lightly loaded by small numbers of concurrent clients
middleware [6]. Limits on resources restricted this and still had idle CPU time. Each client machine ran
study to the use of the Sun reference implementations only a single copy of a client process so that
of Java-RMI, CORBA, and WebServices. The contention was not an issue on the clients.
coding of these reference implementations is A small part of the study focused on the cost of a
expected to be of similar quality, so that the results single request from client to server. These single
should fairly represent the intrinsic merits of the request tests provide comparative costs for the
different technologies. establishment of a connection. Most of the reported
results are from tests where several thousand requests
2. Scope of study are handled in the course of a client-server session.
In these tests, set-up costs are amortized over many
2.1. Technologies and measures requests giving a better measure of the actual request
handling costs. Typically tests involved 5000
The technologies used in this study were: requests; where the processing time was still short,
• JAXRPC from Sun's Java Web Services runs of as many as 50,000 requests were used. The
Development kit (JWSDP) [7]; results presented are averages from ten or more test
• Tomcat 5 (as incorporated in JWSDP) [8]; runs. With the tightly controlled conditions,
variations in execution and run-times were small.
• Java RMI from Java 1.4 SDK [2];
Some of the tests involve pseudo-randomly
• Java CORBA from Java 1.4 SDK [9];
generated data sets that vary in size. For these tests,
• Ethereal network traffic analysis program [10]. identical sequences of seeds were used for the
Tests were performed on a network system with a random number generators when running the same
100Mb/sec Ethernet backbone. Performance tests test with different technologies. Naturally, time
utilized a Sun v480 (1030MHz) server and a group of variations of successive runs were greater, up to
SunBlade 150s (650MHz) running client 10%, reflecting the varying sizes of datasets
applications. Network traffic analysis was conducted generated and transmitted across the network.
using the Ethereal tool to capture packets transferred The Ethereal tool provided the data on packet
over the 100Mb/sec Ethernet between a SunBlade and byte counts. It also permits detailed analysis of
100 server and a client 2GHz Dell Optiplex GX260 the packet sequences generated by the different
machine running Win2000. technologies. The technologies do vary in the
The machine groups were workstations in a efficiency of their use of the underlying TCP/IP
teaching laboratory and a new server. The study was communications.
conducted out of academic session when these
machines had no other users, so timing measurements
2.2. Example services
were not distorted by process switching etc. The
network carried some other light traffic, but was not
Three example services were implemented. They
approaching saturation so network latencies should
differ mainly in the type and amount of response
not be distorted.
data; one of the efficiency issues being how well the
Measures include:
technologies handle significant data volumes.
• memory usage in the client,
The first service, “calculator”, actually involves a
• CPU-times for both client and server, stateful server (issues of state maintenance in Web
• overall latency time for a single request and for Service applications are discussed in section 3.5
sequences of requests, below). The service defined a simple four-function
• total byte transfers, calculator with operations that each required an
• packet counts. integer input argument and generated an integer
Memory usage was estimated using differences response. Clearly, such limited data should involve
in “total memory” and “free memory” as measured minimal overheads.
using calls to java.lang.Runtime in the client The second service, “data”, involved a string
code. input argument and a returned structure with integer,
Preliminary tests had involved running the server string array, and double array fields. Here, the XML
with increasing number of concurrent clients to encoding has to include some more significant
determine the loads at which the server became fully structural meta-data.
utilized and service times increased. The results
 The final service, “large data”, models a real- priceType price;
world data retrieval application. Intranet use of Java- priceType listPrice;
string publisher;
RMI and CORBA frequently has a client running in long publicationYear;
one departmental system that uses a middle-layer long publicationMonth;
server to access a database in some other strings keyWords;
departmental system. It is this kind of application string isbn;
long starRating;
that Web Services will have to take on if they are to string url;
establish themselves as a preferred technology for };
intranet systems. The demonstration service was a typedef sequence<Data2> Data2Seq;
reduced version of an application used to retrieve interface Demo {
data on books from a database. The demonstration // Simulated method corresponding to
// find books with keyword like ...
implementation has only a single function that Data2Seq search(
effectively simulated the application query “get in string request);
books that include keywords ...”. Database };
performance issues were avoided by having the
service pseudo-randomly generate and populate The java.rmi.Remote interfaces are closely
anything from a few dozen to several hundred similar, mainly involving substitution of arrays for
records in response to each request. IDL sequences.
The IDL interfaces for these services are: The developer of a Web Service can start by
composing the Web Service Description Language
“Calculator” (minimal complexity data transfers of (WSDL) description of the service. However, both
integers): the JAXRPC and the .Net development environments
interface Demo { permit a developer to start by defining a service
long long clear(); interface in terms of a programming language class
long long add(in long long val);
... (C#, VB etc) or interface (Java) and using a helper
// quit - in JAXRPC version will release tool to generate the WSDL document. This bottom-
// session storage; in JAVARMI version up approach is easier for most developers. This
// will do nothing (rely on garbage study used the same java.rmi.Remote interfaces as
// collector); in CORBA version will do the starting points for both Java RMI and JAXRPC
// a deactivate object
void quit(); Web Service implementations. Client-side stubs are
}; auto-generated from the WSDL service definition.
// Factory component only relevant in A WSDL document (an XML file), either
// RMI and CORBA implementations composed manually or generated from a
interface DemoFactory { programming language class or interface, will define
Demo createDemo();
}; “messages” (input messages are essentially function
signatures, output messages are responses), “port-
“data” (transfer of simple record structure): types” (a service interface or class) with “operations”
typedef sequence<string> strings; that are defined in terms of their input and output
typedef sequence<double> doubles; messages, “binding(s)” - specifications of a transfer
struct Data { protocol, typically HTTP, an encoding scheme
long long _d1;
strings _d2; (choice among SOAP encoding styles), and finally
doubles _d3; the service definition(s) with end-point URI(s). The
}; inclusion of the service end point's URI is really the
interface Demo { only major semantic difference from an IDL or
Data f1(in string key); java.rmi.Remote interface declaration.
};

“large data” (transfer of potentially large data 2.3. Service implementations and deployment
structure):
typedef sequence<string> strings; A JAXRPC servant can be instantiated inside a
typedef double priceType; servlet-container such as Tomcat, or can be
// Record defining a book implemented as a stateless EJB session bean. If the
struct Data2 { servlet model is used, the developer defines a class
string title;
strings authors; that implements the java.rmi.Remote interface
declaration; an EJB session bean defines an interface A Java-RMI servant class normally extends the
with equivalent operations. This study used the class java.rmi.server.UnicastRemoteObject
Tomcat-hosted servlet style. The developer must and implements the defined remote service
provide effective implementations for all defined definition; e.g. public class DemoImpl
operations, together with any life-cycle methods that extends UnicastRemoteObject implements
are required by the servlet- or EJB- container. Demo { ... }.
In a servlet-based implementation, system The Java-RMI deployment is the most elaborate,
supplied servlets take configuration data that define and most fragile. A server system will comprise at
the Web Service classes that they manage. The least the actual server process, the rmiregistry
servlet code deals with the HTTP data traffic, and (equivalent to a CORBA name-service), and a HTTP-
invokes XML parsing to prepare arguments, and then server from which a would-be client can download
invokes the service operations. The actual JAXRPC the “.class” files of client-side stubs. An rmiregistry
servant can be given access to its servlet-container by does not maintain persistent data so all records of
having its class implement the optional javx.xml. registered servers are lost on system restart. Further,
rpc.server.ServiceLifecycle interface. The the registry must be restarted if there are changes in
context can include resources shared with other the implementation of any one of the services
servlets such as in-memory data structures or registered with it. The developer of a Java-RMI
database connections. The context can also manage system has to take careful account of rules regarding
session state for a stateful service. access to .class files by server process, HTTP-server,
XML deployment files for the servlets and their and rmiregistry, and must also compose security
configuration data are all generated automatically. policy constraint files. The rmid daemon process can
WWW-servers like Tomcat are designed for easy be employed to support on-demand services; but
administration; services can be added or existing rmid again does not use persistent data storage
services replaced in a running server. The control making the system fragile in regard to system
data for the hosted services are persistent. A system restarts. The use of rmid also necessitates the use of
restart will require minimal or no action by an extra setup programs. There are mechanisms for
administrator. The server for WWW and Web integrating Java-RMI with Jini technology that
Service applications should simply re-initialize itself. provide for more stable deployments; but these
A CORBA developer has the choice of extending require skill sets and knowledge that are uncommon.
the auto-generated “POA” class, or of using an
instance of a generated POATie class that works with 2.4 Client-side stub and client coding
a servant that is an instance of a class implementing
the operational interface but which is otherwise The WSDL for a Web Service must be made
independent of the CORBA class system. available to the developer of the client-side code. If a
The complexity of CORBA implementations is UDDI registry were being used, the client developer
often overrated. In these demonstration applications, might be able to download the WSDL from the
the server-side consisted of single server process. registry. The Tomcat server configuration for a
This initializes its ORB, instantiates the JAXRPC implementation can act as an alternative
implementation class, activates this instantiated source of the WSDL. Both .Net and JAXRPC
servant via the default POA, and publishes an IOR in development systems include helper applications that
a file. A more typical server system would involve a can generate a client-side stub class, and other helper
CORBA name service (or trader) and a CORBA classes, from a downloaded WSDL definition.
daemon process. The server process would utilize a A CORBA developer has to obtain a copy of the
POA that supports persistent references; the servant IDL interface definition (this too could come from a
identifier would be published in the name service. UDDI registry for these are not restricted to handling
The CORBA daemon process would deal with issues only WSDL defined services). The developer then
like restarting a server process as needed. The name- generates a client stub in the required implementation
service and CORBA daemon should both use language via an IDL compiler.
persistent data stores and be capable of surviving The developer of a Java-RMI client works solely
system restarts. In the Sun Java 1.4 implementation, with the remote interface. The client-side stub class
the “orbd” process takes on both the role of a has to be downloaded at run-time from a HTTP
persistent naming service and of the CORBA daemon server co-located with the actual RMI server and the
that can launch server processes. rmiregistry name-server process.
 Each test client had code that established a
connection and then in a loop repeatedly invoked Technology Total Total Total data
service operations. Such tightly coded loops result in Latency Packets transferred
client behavior that is much more demanding than a in bytes
typical real-world application. WS 0.11s 16 3338
Client application code is essentially identical for CORBA 0.48s 8 1111
all technologies. All implementations will work with CORBA & 0.86s 24 3340
an object reference of the interface type; most of the name server
code will simply invoke operations via this reference. Java RMI 0.32s 48 7670
The codes differ in the half dozen lines needed to Table 1. Costs of single shot request using
create the stub object associated with this reference. various technologies.
The JAXRPC code utilizes an instance of an auto-
generated helper-class to create a stub object (an Any remote-connection incurs the establishment
instance of an application-specific subclass of a costs of a TCP/IP connection. A Web Service
generic Stub class). The end-point URL should be implementation, using a static stub previously
encoded in the generated stub, but can be generated from WSDL, incurs the cost of only one
overwritten. There is no further requirement to connection. Subsequent exchanges using HTTP may
invoke a naming service or other helper. be non-optimal. A request is sent in two parts (HTTP
A Java-RMI implementation will require a headers in the first message, SOAP “envelope” with
principal server-side object whose identity is request in second part), and these parts are
published via the rmiregistry naming service. This acknowledged. A response is again multipart, a first
could be the singleton object in a singleton stateless part with the HTTP response header and subsequent
server, or a factory object for a stateful service. The continuation parts containing the XML response
client obtains a reference via a lookup operation on document. Despite the relative inefficiency of
the naming service. The underlying Java-RMI HTTP, the JAXRPC solution performs best.
runtime arranges to download the stub class code A simple CORBA solution, using an endpoint
from an HTTP server as part of the lookup process. address read as a stringified IOR taken from a file, is
A CORBA client might obtain a reference to the comparable in complexity with the JAXRPC
service for its stub from a CosNaming name service, solution. It represents the most efficient solution in
or from a trader, or from a stringified IOR in a file in terms of network traffic (in this case, half of the
a shared file space. packet traffic being that needed to establish and
terminate a TCP-IP connection) but is relatively
3. Results slow. There are significant delays between the
establishment of the connection and the issue of the
3.1. Costs associated directly with first request by the client, and between the
communications protocols acknowledgment of the request and generation of the
response on the servers.
The typical illustrative Web Service application A more realistic CORBA solution has the client
has a client connect to a service, submit a single contact a name service to obtain a reference to its
request for data, and terminate. Such applications are server. This entails an extra TCP/IP connection and
unlikely to put any great demands on either a server several exchanges resulting in a significant further
host's CPU, or a communications network; decrease in performance.
consequently, performance issues are not that The Java-RMI solution has the most complex
important. In any case, for such applications, Web mechanism; establishment of a connection to the
Services technologies perform well in comparison rmiregistry and submission of lookup request,
with the distributed object systems. establishment of a connection to an HTTP server and
The data shown in Table 1 show relative posting of a request to download a class file, and
performances for four implementations of the “data” finally exchanges with the actual server. The RMI
application with a request for a single data structure protocol entails a certain amount of additional data
retrieved according to an argument key. (Here, times traffic even in this short example with RMI “ping”
are measured from first to last packet of TCP/IP operations etc that are used to keep open leases on
communications. The services were all fully server-side structures. Despite the overheads of the
initialized having handled previous clients.)
extra connections and additional traffic, the Java- closedown sequence. Both Davis et al. and Elfwing
RMI solution appears better than CORBA. et al. identified other problems with delayed
Intranet style applications will more typically acknowledgements of the request header.
involve a client that submits numerous requests to a These problems are significantly reduced in the
server. Here, the additional set-up overheads of the current HTTP 1.1 implementations. Firstly, HTTP
object technologies (contacts with name services, 1.1 incorporates the “keep alive” feature as standard.
download of stubs) are amortized over many requests The time-out on the server-side defaults to about 60
and so count for less. seconds in the JAXRPC configured Tomcat; so if a
The earlier studies of Elfwing et al. and Davis et client process submits a subsequent request within
al. looked at applications involving multiple requests, this time there is no need to close the original and
comparing average times for requests as obtained establish a new TCP/IP connection. The closedown
from a series of requests (and excluding sequence has in any case been changed; the client
establishment costs for the object technologies) [4, issues a TCP/RST and shuts down communications;
5]. In both those studies, the Web Service (SOAP- there is no longer any need to modify low level
communication) solutions performed poorly relative java.net socket code.
to alternatives. A significant factor was the use of Another significant change that comes with
HTTP 1.0 in the implementations studied. There HTTP 1.1 is the use of a “chunked” response format.
were really two problems. Firstly, the HTTP 1.0 A HTTP 1.0 response should contain a
connections were not persistent; secondly, there were Content_Length header; this necessitates buffering
specific issues relating to delays in the pattern of of an entire response in the server, which could be
requests and acknowledgements for the various parts problematic for applications such as the “large data”
of messages. application (the book records in that example exceed
The original version of HTTP was intended for 1000 bytes and a response can have as many as 600
the download of individual documents; a client records). With “chunked” encoding, the server can
connects, the server returns a document and closes send chunks with length component, data, and a
the connection. When documents ceased to be purely separator. The chunked XML data can be processed
textual and started to require supplementary data on the receiving side because SAX style parsers are
such a style-sheets or image data, the protocol was used rather than DOM parsers.
seen to be inefficient as each supplementary file Earlier studies looked mainly at simple operations
transfer required re-establishment of a TCP/IP where the responses were single integers or strings.
connection. A “keep-alive” feature was introduced Such small responses can often be fitted into single
on the connections. The server would keep the packets. More realistic applications will have large
connection open for a short (configurable) time after responses that must be split into separate packets.
returning an initial document; a client could submit The HTTP 1.1 implementation tries to use relatively
supplementary requests over this open connection. large sizes (1460 bytes data, this is about the largest
This feature was not formally part of the HTTP 1.0 data packet that can be transmitted as a single unit
protocol and was only implemented on an ad hoc and over typical Ethernet connections). If a CORBA
frequently inconsistent manner. The HTTP 1.0 used response is too large to be sent as a single unit, it is
with earlier implementations of SOAP also fragmented (IIOP fragments); the Sun Java 1.4
communications did not exploit the “keep-alive” implementation of CORBA uses a fragment size of
feature. Consequently, each request in a sequence 1024 bytes. A Java-RMI implementation returns
involves establishment and shut down of a TCP-IP large structures with RMI-continuation messages that
link. are of apparently arbitrary size (with the “large data”
Elfwing et al. studied delays associated with the demo, successive RMI-continuation messages in a
closure of the TCP/IP connection after each HTTP response had sizes such as 338, 242, 497, 409, ...).
1.0 request. The protocol used a “graceful” The results from this examination of protocol
closedown with a TCP/FIN message from server to imply that the concerns raised by Elfwing et al. and
client, a client TCP/ACK and then TCP/FIN, and Davis et al. have been largely addressed with the
final TCP/ACK from the server. The problem was adoption of HTTP 1.1. The actual data traffic
not in the exchange of TCP/IP handshake messages between client and server is reasonably efficient; it is
but in an initial delay of ~0.4 seconds prior to the simply that there is a lot more data to be transferred
server initiating the closedown. One of the changes for Web Service implementations as compared with
made by Elfwing et al. was to modify the java.net the object technologies.
code to allow the client to initiate the graceful
3.2. Costs of document transfer bandwidths should be high, and local switched
Ethernet systems should reduce contention. If the
Table 2 shows results of traffic analysis for each application requires encryption of data traffic (not yet
of the technologies. These data show the total byte standardized for Web Services) then the larger
transfers and total number of packets and are amounts of data will incur additional processing costs
averages of repeated tests. (The “iterator” variants for encryption; however, with intranet usage,
are discussed in section 3.5.2.) encryption may not be vital.
The image of large XML documents replete with
textual data, mark-up tags, and data type specifiers 3.3. Costs of XML generation and parsing
had lead to an expectation of even poorer
performance from the JAXRPC solutions. The There are time and space costs associated with the
relative performance is poor with the simpler data use of XML encoding. Table 3 shows the measured
transfers, as in the calculator example, but the CPU times for applications on both client (SunBlade,
difference is less marked where the data volume is 650MHz) and server (Sun v480 1030MHz) as
greater (the “large data” example includes numerous measured by Unix “time” command. The server
string elements, some quite lengthy; here mark-up required ~115s to generate 5000 large data records
and related overheads count for less). The JAXRPC without any output of these records (same for all
solutions require from three to five times as many technologies). In this case, the data in the table
data packets as the alternatives, and from three to ten include overall time and estimated time for
times as many bytes. (There are proposals relating to technology-specific communications.
the use of text compression for SOAP data transfers, In terms of CPU usage, Java-RMI is generally the
but nothing is yet standardized.) best. However, the test with large data example
The CORBA implementation performed best with shows poor performance on the client-side (the Java-
the large data transfer example. Generally, Java-RMI RMI solution requires something like 2.8 times as
has a superior performance [11, 12]. Here CORBA many packets as the CORBA solution and this seems
has an advantage over Java-RMI primarily because to be impacting client-side performance more than
of its use of an 8-bit character encoding for data server-side performance). The JAXRPC solutions
transfers as opposed to Java-RMI's 16-bit coding. A require up to six times as much CPU power on the
secondary factor is Java-RMI's inclusion of some server; the client-side parsing of the large data
class meta-data in responses that include class documents has an even higher cost. The Java-RMI
instances such as strings. The Java-RMI solution solution was consistently the best in terms of overall
performed relatively poorly in terms of total number runtimes (actual elapsed time for the client to
of packets in the large data case; this relates to its complete its sequence of requests); the CORBA
selection of a small size for continuation messages. solutions take about 10% longer. This is despite the
The five-fold or so increase in data transfer costs fact that RMI exchanges many more messages than
for Web Service style implementations may be CORBA does in the “large data” case.
tolerable for an intranet application. Local

Example Technology Packets Total data

transferred
"Calculator" WebServices 48,931 10,360,814
CORBA 10,007 1,400,851
Java-RMI 10,098 1,017,477
"data" WebServices 55,617 16,053,312
CORBA 10,007 2,236,661
Java-RMI 10,050 2,451,790
"large data" WebServices 1,143,608 1,134,974,047
CORBA 475,235 344,363,683
Java-RMI 1,354,377 449,330,931
"iterator" CORBA 501,266 348,321,700
WebServices 1,257,678 1,157,156,203
Table 2: Traffic analysis for illustrative applications with different technologies
Application “calculator” “data” “large data”
Technology Client CPU Server Client CPU Server Client CPU Server CPU
CPU CPU
WS 15.0s 6s 22.8s 8.4s 1087s 551s (436s)
Java-RMI 2.3s 0.8s 4s 1.1s 148s 212s (97s)
CORBA 3.2s 1.9s 3.6s 2.1s 54.2s 250s (136s)
Table 3: Measured CPU times for client and server with varying technologies and applications.

The other resource used is memory space in client in Java-RMI. Developers of a JAXRPC style servlet
and server. The current use of chunked responses based service will naturally tend to want to take
with HTTP 1.1 eliminates one major space advantage of services offered by the servlet
requirement on the server-side - the buffering of a container.
complete response prior to its transmission.
Significant memory may still be used for XML 3.5. State
parsing on both client and server. (All parsers are
SAX-style, so there is never any need to build a The traditional design for a stateful service, as in
complete parse tree as for a DOM parser; such a tree- CORBA and RMI, involves two classes; there is a
structure would incur much larger memory costs.) In factory class, and a stateful server class. The factory
this study, approximate memory measures were class is a singleton class, an instance of the factory is
recorded and only on the client-side. created when the server process starts and it is the
Memory usage was averaged over a series of tests identity of this factory object that is published in
runs on the “large data demo. Average memory naming services. Clients establish initial contact with
usage for the systems were: JAXRPC 4.75Mbyte, the factory object and use a “create” method to
Java-RMI 2.6Mbyte, CORBA 2.0Mbyte. “Iterator” instantiate a session-server object; the create method
based models (where large collections a returned in returns an object-reference that the client builds into
blocks whose size is client-selected) reduce memory a stub. It is this object that is subsequently used via
usage. The mechanisms are discussed below in the client's stub and, hopefully, is neatly disposed of
section 3.5.2. The difference in memory usage is when the client's session is completed. The typical
small in the CORBA implementation; the JAXRPC tutorial example has a “calculator-factory” and
memory usage was reduced to ~2.1Mbyte. “calculators” for the individual clients. The state
data for a calculator will be the contents of its
3.4. Common implementation for Web register(s).
Service and Java RMI It is not possible to build a stateful server of this
type within the Web Services model because this
If a service has heavy internal use on an intranet, model does not support the concept of a returnable
and also some external Internet users, then one object reference. Archetypical Web Services are
possible approach is to use a common stateless; and developers are encouraged to think
implementation for both JAXRPC and Java RMI only in terms of stateless services [13]. However, if
services. really required, stateful services can be implemented
The typical Java-RMI server extends using mechanisms similar to those employed for
java.rmi.server.UnicastRemoteOject; a WWW-services that maintain things such as
JAXRPC implementation class does not. However, a “shopping carts”.
Java-RMI server can use the implementation created When WWW services grew beyond the simple
for the JAXRPC system; it simply has to connect the download of static pages, state became an issue and
server object to the Java-RMI runtime system and “hacks” had to be developed to permit state
register it with the rmigrestry naming service. maintenance. Solutions involving the server sending
A dual technology solution might be expedient in existing state data back to the client as part of an
some situations where the lower performance of a intermediate response have limited application. The
JAXRPC server was perceived as problematic. typical solution has state data maintained in the
However, it is unlikely to prove a long-term solution. server (in memory, file, or database) with simply a
There would be pressures for divergent client identifier key sent back to the client. This key
implementations to evolve. State has to be hacked in can be held in a “cookie” that will be returned to the
Web Service models, while being handled naturally server or may be embedded in the path of all URLs.
Either way, the key gets returned as part of work to an independent implementation class. If this
subsequent invocations. These WWW-hacks can be model is used for something like a JAXRPC
adapted to Web Services that use HTTP. calculator service, one would have a Calculator
Details vary but the major implementations of class and a java.rmi.Remote class (“Demo”) that
SOAP/HTTP servers and clients all support state via ties in with the servlet container. The Calculator
cookies (or if necessary via URL-rewriting, though class would use data members to store state in a
this appears poorly supported in the .Net natural way. The tie-class, Demo, would create an
implementation [14]). With JAXRPC, the server- instance of this Calculator class as its state data
side defaults to having session support; with .NET saved in the system provided session hash map.
and Apache-SOAP, server-side support can be Code for the tie-class would be something like the
enabled via configuration variables. The client-side following:
must also enable session handling, and may need to public class DemoImplementation
allocate and register structures to hold cookie data. implements Demo,
javax.xml.rpc.server.ServiceLifecycle
{
3.5.1. Implementing a stateful service. Service private final String
containers, such as Tomcat or the .Net system, myKey = "DemosCalculator";
typically support in-memory session state via some private ServletEndpointContext
endPointContext;
form of hash-map. The container hides all the detail
of dealing with the cookie or re-written URL, public void init(Object cntxt) {
supplying instead an operation that the service object endPointContext =
can use to retrieve the hash map with the session data (ServletEndpointContext) cntxt;
appropriate to the current client. }
Direct use of data in the hash map results in public void destroy() { }
somewhat unnatural code. For example, a stateful
JAXRPC calculator service would have to store its public long add(long val) {
register value in a java.lang.Integer variable in return getCalculator().add(val);
this session hash map. The code would be something }
like the following: ...
public long add(long val) {
int result = 0; private Calculator getCalculator() {
// First get session for client // Retrieve real object from session
HttpSession session = null; // (or create it if necessary)
try{ // code, as above, to get session
session = endPointContext. ...
getHttpSession(); if(session!=null) {
} if(session.isNew()) {
if(session!=null) {
Calculator c =
// If existing Session, get state data
// variable with current value new Calculator();
if(!session.isNew()) { session.setAttribute(
Integer cVal = myKey, c);
(Integer) session. return c;
getAttribute("myRegister"); }
result = cVal.intValue(); else return (Calculator)
} session.getAttribute(myKey);
} }
result += val; // problem - no session
if(session!=null) session. ...
setAttribute("myRegister", }
new Integer(result)); }
return result;
} 3.5.2. A stateful iterator. Although often
CORBA's POATie mechanism offers a model for discouraged [13], a stateful Web Service may be of
a more natural implementation of a stateful service. advantage in cases where large quantities of data
The POATie mechanism has two classes that must be returned. In CORBA, it has been traditional
implement the same operations interface as defined to define search operations that may result in large
for the service; the POATie class deals with issues of amounts of response data as yielding references to
integration with the ORB and delegates all actual stateful iterators rather than sequences of records.
On the server-side, the stateful iterator is created with such as the "large data" application than in toys like
ownership of a collection of those records that are to the "calculator" application.
be returned, and a counter that identifies the subset of The substantial commonality of code base for the
records that will be returned in the next request. The various technologies makes dual deployments
client gets a stub that allows it to use such an iterator possible - a Web Service implementation for external
to retrieve data segments of specified size. The users and an alternative higher performance variant
server-side iterator and its data collection are of internal use. Some problems associated with very
discarded when all data have been returned. large responses from a Web Service can be alleviated
This model can be adapted to Web Services. Of through the use of a stateful iterator approach.
course, a search operation cannot return a reference The example applications did not involve any
to an iterator object. It can instead create the iterator, sophisticated features such as encryption and
and make this an element in the client's session-data transactions. Currently, there are competing
record. An additional method can then be provided proposals for Web Service transaction management,
that retrieves records from this iterator. The “large and there is an elaborate network of related
data” example was adapted to use a very simple investigations into security frameworks. However,
stateful iterator. The revised service definition is: these features are still at prototype stage. If such
features are required, developers will have to look to
public interface Demo extends Remote { commercial CORBA implementations. (There are
public Data2[]
getMoreRecords(int blksize) transaction managers and security systems for
throws RemoteException; freeware CORBA but a lot of work is needed to
public int search(String request) develop an application that uses these in a reliable
throws RemoteException; manner.)
}
The implementation of the search function finds the
required records and stores them in an in-memory References
collection. When the search is complete, the search
[1] W3C Organizations Web Services definitions, http://
function creates an instance of an Iterator, giving www.w3.org/2002/ws/
it the collection and storing it as a state variable in
the client's session. The getMoreRecords method [2] Java: Remote Method Invocation; http://java.sun.com/
retrieves this state variable and invokes a method that j2se/1.4.2/docs/guide/rmi/index.html
returns the next block of records.
A naive implementation of an Iterator class [3] CORBA: Common Object Request Broker
requires less than twenty lines of Java. Architecture, http://www.omg.org.
The client application was modified to use this
[4] Elfwing, R., Paulsson, U., and Lundberg, L,
iterator-based service, requesting result records to be
Performance of SOAP in Web Service Environment
returned in blocks of at most fifty. Test results of this Compared to CORBA, In Proceedings of the Ninth Asia-
version of the application showed a 10% increase in Pacific Software Engineering Conference, IEEE, 2002
the total number of packets transmitted, and only
about 2% increase in byte transfers. It does however [5] Davis, D., and Parashar, M., Latency Performance of
lead to considerably less memory usage in the client; SOAP Implementations, In Proceedings of 2nd IEEE/ACM
this version of the client having an apparent International Symposium on Cluster Computing and the
maximum memory footprint of 2.1Mbyte instead of Grid, IEEE, 2002.
the 4.6Mbyte for the standard implementation.
[6] Gorton, I., Liu, A., and Brebner, P., “Rigorous
evaluation of COTS middleware technology”, Computer,
4. Conclusions IEEE, March 2003, pp. 50-55.

Improvements in implementations of SOAP [7] JWSDP Java Web Services Developer Pack http://
communications have significantly reduced the java.sun.com/webservices/jwsdp/index.jsp
performance failings noted in earlier studies. While a
Web Service solution will still be slower, consume [8] Tomcat server: http://jakarta.apache.org/tomcat/
more memory, more network bandwidth, and more index.html
CPU cycles than an alternative solution, the [9] Java 1.4 CORBA implementation; http://java.sun.com/
differences are less marked in realistic applications j2se/1.4.2/docs/guide/corba/index.html
[10] “Ethereal: a free network protocol analyzer”, http://
www.ethereal.com

[11] Juric, M.B., Rozman, I., and Hericko, M.,

Performance Comparison of CORBA and RMI, Information
and Software Technology 42, pp 915-933, 2000.

[12] Juric, M.B, Rozman, I., Stevens, A.P., Hericko, M.

and Nash, S., Java 2 Distributed Object Models
Performance, Analysis, Comparison, and Optimization, In
Proceedings of 7th International Conference on Parallel
and Distributed System, IEEE, 2000.

[13] Zimmermann, O., Tomlinson, M., and Peuser, S.,

Perspectives on Web Services, Springer-Verlag, Berlin,
2003.

[14] Powell, M., Using ASP.NET Session State in a Web

Service, as http://msdn.microsoft.com/library/
default.asp?url=/library/enus/dnservice/html/
service08062002.asp