Web Services, Java RMI, and CORBA

insidiousbehaviorΑσφάλεια

3 Νοε 2013 (πριν από 3 χρόνια και 11 μήνες)

74 εμφανίσεις

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)
-

class

or interface

client

stub

Implementation

client

stub

POA

skeleton

Implementation

Implementation

client

stub

rmic

idl compiler

wsdl 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 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


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
-
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