Get documents about "Web Services, Java RMI, and CORBA - PowerPoint
Document Sample
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
--- --- ---
wsdl processing
idl compiler
Server (base)- Implementation
class
or interface client POA
stub skeleton
rmic
client
stub
client
stub
Implementation Implementation
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 { typedef sequence<string>
long long clear(); strings;
…
long long add(
struct Data2 {
in long long val);
string title;
…
strings authors;
}; …
// Factory component only };
// relevant in RMI and typedef sequence<Data2>
// CORBA implementations Data2Seq;
interface DemoFactory { interface Demo {
Demo createDemo(); 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 0.86 24 3340
name server
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 Ratio
Calculator 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 data
Technology 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- >10 4 >12,500 >10 8 >6,000 2 45 22
RMI
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
