Transcript Web Services, Java RMI, and CORBA

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
WSDL
-----
IDL
-----
wsdl processing
Java-RMI
Java
remote
---
idl compiler
Server (base)class
or interface
Implementation
client
stub
POA
skeleton
client
stub
Implementation
Implementation
rmic
client
stub
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” –



“small data”


Stateful!
Minimal data transfers – one integer argument, one integer
response
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 with
name 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
Calculator
Data struct
Large data
Packets
Bytes
Ratio
WS
48,931
10,360,814
10.2
CORBA
10,007
1,400,851
1.4
Java-RMI
10,098
1,017,477
1
WS
55,617
16,053,312
7.2
CORBA
10,007
2,236,661
1
Java-RMI
10,050
2,451,790
1.1
1,143,608 1,134,974,047
3.3
WS
CORBA
JAVA-RMI
475,235
344,363,683
1
1,354,377
449,330,931
1.3
Extra costs : time
Calculator
Technology
WS
Client
Data
Large data
Server Client Server
Client
Server
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
clients
time
data
Ops/s
clients
time
Large data
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
4 >12,500
>10
8 >6,000
2
45
22
JavaRMI
>10
Some tradeoffs
 Server throughput


Java RMI can be up to 10x greater than a webservice 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 POAlocator


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