Web Services, Java RMI, and CORBA N.A.B. Gray University of Wollongong

Click here to load reader

download Web Services, Java RMI, and CORBA N.A.B. Gray University of Wollongong

of 42

  • date post

  • Category


  • view

  • download


Embed Size (px)

Transcript of Web Services, Java RMI, and CORBA N.A.B. Gray University of Wollongong

  • Slide 1
  • Web Services, Java RMI, and CORBA N.A.B. Gray University of Wollongong
  • Slide 2
  • 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?
  • Slide 3
  • 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
  • Slide 4
  • Development Web ServiceCORBAJava-RMI WSDL --- IDL --- Java remote --- Server (base)- class or interface client stub Implementation client stub POA skeleton Implementation client stub rmic idl compiler wsdl processing
  • Slide 5
  • 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
  • Slide 6
  • 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.
  • Slide 7
  • Scope of study Freeware only Sun reference implementations Ethereal traffic analysis Hardware Numerous Sun-5 workstations for concurrent clients Sun v480 server 100Mb ethernet
  • Slide 8
  • 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
  • Slide 9
  • 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
  • Slide 10
  • 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.
  • Slide 11
  • 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 strings; struct Data2 { stringtitle; stringsauthors; }; typedef sequence Data2Seq; interface Demo { Data2Seq search( in string request); };
  • Slide 12
  • HTTP surely not
  • Slide 13
  • 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
  • Slide 14
  • 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
  • Slide 15
  • Web Services the winner TechnologyTime (seconds)Total PacketsTotal data transfer bytes JAXRPC0.11163338 CORBA0.4881111 CORBA with name server 0.86243340 Java RMI0.32487670
  • Slide 16
  • 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
  • Slide 17
  • 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
  • Slide 18
  • 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
  • Slide 19
  • 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
  • Slide 20
  • 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)
  • Slide 21
  • Extra costs : data ExampleTechnologyPacketsBytesRatio CalculatorWS48,93110,360,81410.2 CORBA10,0071,400,8511.4 Java-RMI10,0981,017,4771 Data structWS55,61716,053,3127.2 CORBA10,0072,236,6611 Java-RMI10,0502,451,7901.1 Large dataWS1,143,6081,134,974,0473.3 CORBA475,235344,363,6831 JAVA-RMI1,354,377449,330,9311.3
  • Slide 22
  • Extra costs : time CalculatorDataLarge data TechnologyClientServerClientServerClientServer WS15.0622.88.41087551 (436) CORBA31. (136) Java-RMI20.841.1148212 (97)
  • Slide 23
  • 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 doesnt create a parse tree)
  • Slide 24
  • 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 Shouldnt really be an issue
  • Slide 25
  • 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
  • Slide 26
  • Throughputs calculatordataLarge data clientstimeOps/sclientstimeOps/sclientstimeOps/s WS ~632940~53964032087 CORBA ~76.5>5,000~67.8>3,50025020 Java- RMI >104>12,500>108>6,00024522
  • Slide 27
  • 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
  • Slide 28
  • 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
  • Slide 29
  • State
  • Slide 30
  • 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
  • Slide 31
  • 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 Tomcats servlet session variables
  • Slide 32
  • 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
  • Slide 33
  • Analogies WS implementation like CORBA tie class Possibly better analogy with CORBA POA- locator Ses