Date post: | 25-Dec-2015 |
Category: |
Documents |
Upload: | clarissa-potter |
View: | 228 times |
Download: | 0 times |
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