Web Services, Java RMI, and CORBA

N.A.B. Gray

University of Wollongong

Motivation for study

Increasingly seeing WebServices extolled as replacement for distributed object systems.

? ! RPC reincarnated; message oriented API. Images of inefficient protocols and large text transfers. Reports from previous studies indicating performance hits as

great as 400:1 partially ameliorated by hacking java.net But wait --- there are new releases! Have the newer implementations of WS made things

better?

Web Service APIs

Earlier Java (Apache SOAP) implementation rather unattractive

Construct Message objects Dispatch Message objects Unpack results

Current JAXRPC (similar now to .Net) works with auto-generated client stubs

Program development process and programming style now very similar for WS, RMI, or CORBA

Web Service ~ stateless server singleton in RMI/CORBA

Development

Web Service CORBA Java-RMI

WSDL --- ---

IDL --- ---

Java remote ---

Server (base)- classor interface

clientstub

Implementation

clientstub

POAskeleton

Implementation

Implementation

clientstub

rmic

idl compilerwsdl processing

Coding

Very similar for WS (JAXRPC), Java-RMI, CORBA (at least for stateless singleton server)

Client Obtains proxy stub for remote service

~6 lines of code, differing for implementation Invokes operations via stub

Server Implementation class Instantiated in some “container”

Servlet engine, RMI-process, CORBA/POA framework

Tradeoffs

Development mechanism, and code complexity essentially the same for all.

Expected Tradeoffs Supposed higher performance for RMI/CORBA Greater interoperability for WebService

WebServices might have advantages when clients and servers in differing organizations, but can they handle intranet apps.

Scope of study

Freeware only Sun reference implementations Ethereal traffic analysis

Hardware Numerous Sun-5 workstations for concurrent

clients Sun v480 server 100Mb ethernet

Conditions

Preliminary experiments Increase number of concurrent clients until see

server saturated and degradation of performance

Run actual trials at much lighter loads where server still has significant idle time

Aspects

HTTP Problems of using a hypertext file transfer protocol instead of some

more optimized network protocol Additional costs

Message traffic Processing time Memory Overall performance

Programming paradigms What about state?

Deployment – an emergent aspect

My tests …

Three “services” “calculator” –

Stateful! Minimal data transfers – one integer argument, one integer

response “small data”

Stateless server, string argument – small struct as result “large data”

Simplified model of typical RMI or CORBA intranet application with client using middleware to access database

Simple requests, variable sometimes large responses.

IDL – see the printed version

interface Demo {

long long clear();

long long add(

in long long val);

…

};// Factory component only

// relevant in RMI and

// CORBA implementations

interface DemoFactory {

Demo createDemo();

};

typedef sequence<string> strings;

…struct Data2 {

string title;strings authors; …

};typedef sequence<Data2>

Data2Seq; interface Demo {

Data2Seq search(in string request);

};

HTTP – surely not

HTTP protocol

Advantages Ubiquitous Tunnels through firewalls

Disadvantages Stateless TCP/IP connect; a request; a response; disconnect Text Need to buffer messages HTTP header and message body in different packets REAL BAD performance in previous studies

First though – a preliminary check

Main interest is in performance where client making many requests on service.

But often Web Service examples framed around a single request

Single shot request similar in all technologies Establish TCP/IP connection Submit request Get response

Web Services the winner

Technology

Time (seconds)

Total Packets

Total data transfer bytes

JAXRPC 0.11 16 3338

CORBA 0.48 8 1111

CORBA withname server

0.86 24 3340

Java RMI 0.32 48 7670

Single requests

WebService Single TCP/IP connection Data transfers not wildly efficient

CORBA With “stringified IOR” – single TCP/IP connection, efficient, but

slow handling of request With NameService – extra TCP/IP connection

RMI Extra connection to rmiregistry Extra connection to class file server Stub download cost

Real applications

Remainder of study used clients that Connect Submit large numbers of requests (5,000 or

50,000)

Set up costs amortised over many business requests

HTTP-1.0 (earlier WebService)Major Problems

Studies by Elfwing, R et al. & Davis, D., et al. WebService implementations with HTTP-1.0 not

using “keep-alive” – every invocation required establishment and tear-down of TCP/IP connection

Disconnect by server – with significant time delay HTTP-1.0 requires Content-length header in

responses => buffering of complete response in server

HTTP 1.1 – fixed it!

Current implementations use HTTP 1.1 Fix many of problems reported earlier

Gains Keep-alive:

Provided client submits follow up request within designated period (default 60s) the TCP/IP connection is kept open and reused

Client “reset” closedown – no need to hack java.net Chunked response – no need to buffer entire response

just to send a HTTP 1.0 Content-length: header

Multipart responses

Needed whenever response too large for one message

WebService – maximally efficient 1460 byte continuation parts

CORBA – IIOP segmented message (1024 byte segments)

RMI – weird, multipart response with smallish arbitrary sized parts (~350 bytes)

Extra costs : data

Example Technology Packets Bytes RatioCalculator WS 48,931 10,360,814 10.2

CORBA 10,007 1,400,851 1.4

Java-RMI 10,098 1,017,477 1

Data struct WS 55,617 16,053,312 7.2

CORBA 10,007 2,236,661 1

Java-RMI 10,050 2,451,790 1.1

Large data WS 1,143,608 1,134,974,047 3.3

CORBA 475,235 344,363,683 1

JAVA-RMI 1,354,377 449,330,931 1.3

Extra costs : time

Calculator Data Large dataTechnology Client Server Client Server Client Server

WS 15.0 6 22.8 8.4 1087 551 (436)

CORBA 3 1.9 3.6 2.1 54.2 250 (136)

Java-RMI 2 0.8 4 1.1 148 212 (97)

Extra costs: space

Measured (approximately) only for client Java system calls to get estimate of memory

usage Large data example:

CORBA: just under 2Mbyte Java-RMI: ~2.1Mbyte WS: 4.6Mbyte (Sax parser so doesn’t create a

parse tree)

Extra costs

Data traffic WS can generate as much as 10x traffic But on more realistic examples differences less marked Traffic may not be too great an issue for intranet applications where have

high bandwidth local connections

Processing Client-side: maybe 6x cost of Java-RMI client; but client process probably

lightweight thing dominated by GUI and network wait times. Server side: similar excess cost, but difference less marked in realistic

application

Memory Shouldn’t really be an issue

Server Throughput

Server impacted 7 x CPU load 6 x traffic

Limit number of concurrent clients handled on particular hardware

Brief study using increasing numbers of clients, measuring point where server “fully loaded” Number of clients Approximate number of requests per second

Throughputs

calculator data Large data

clients time Ops/s clients time Ops/s clients time Ops/s

WS ~6 32 940 ~5 39 640 3 208 7

CORBA ~7 6.5 >5,000 ~6 7.8 >3,500 2 50 20

Java-RMI

>10 4 >12,500 >10 8 >6,000 2 45 22

Some tradeoffs

Server throughput Java RMI can be up to 10x greater than a web-

service implementation in Tomcat Difference declines with more realistic

application involving significant data transfers

Dual solution?

Java-RMI, and JAXRPC/Tomcat (WS)

Server code essentially identical Java class implementing Remote interface

Develop once, two deployments WebService in Tomcat for internet clients Java-RMI for intranet clients

State

WS; State; HTTP-cookies

WWW-services needed state support for their shopping carts etc

Netscape hacked stateless HTTP protocol via introduction of “cookies” Normal use: cookie is identifier key, state held in

a “session” storage object on server side Same hack works for WS deployed using

HTTP as communications protocol

Configuring stateful service

Deployment switches for .Net, Apache SOAP, and JAXRPC systems – both client and server side.

With JAXRPC server in Tomcat Implementation class supports second interface

which has hook functions allowing access to Tomcat’s servlet session variables

Stateful web service

Session context provides hash-map like structure for storing named data objects

“Calculator” illustrative example in paper Code

Ugly if actually store state variable in “session context” Cleaner if actual implementation object (and its internal

state) are stored as session state for a Web Service object that acts as a proxy

Analogies

WS implementation like CORBA “tie” class

Possibly better analogy with CORBA POA-locator Session key (from cookie) acting as object-id WS class locates instances of corresponding

business object and invokes method

Stateful iterator

Typical CORBA usage wouldn’t return large sequence like that needed for “large data” example – instead would have reference to stateful iterator returned.

Easy to implement a WS analogy with simple stateful iterator as session variable

One practical effect – WS client no longer more memory demanding than CORBA client

Deployment

Deployment and stability

Not initially one of aspects to explore

Possibly the best reason to swap to a Web Service style implementation!

Web Service

Service packaged as servlet to run in Tomcat or similar Auto-generation of all web.xml deployment files

Tomcat Easy to administer Persistent configuration and deployment data Auto-restart Hot substitution and addition of code Lots of experienced administrators

CORBA – 2nd

CORBA daemon (e.g. orbd) Persistent name service Restarts servers when required

Relatively easy to use Less likely to have experienced administrator

Java RMI

Server side: rmiregistry HTTP server handling class file distribution Services must be pre-launched

Alternatively, even more complexity with rmid No persistent configuration data Fragile Complicated (rules regarding location of .class files etc)

Conclusions

Web Services viable

Processing time and data traffic costs are significantly higher

But: Buy a faster CPU, it is cheaper than employing a

programmer and systems administrator capable of handling RMI

Intranet style applications – likely to have adequate bandwidth

Performance differences less marked for more realistic applications than for toys like “calculator”

Tradeoffs: deployment

For many organizations, most important factor likely to be greater stability and ease of deployment of Web Service solution