1 / 42

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.

jersey
Télécharger la présentation

Web Services, Java RMI, and CORBA

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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?

  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

  4. Web Service CORBA Java-RMI WSDL --- --- IDL --- --- Java remote --- wsdl processing idl compiler Server (base)- class or interface Implementation client stub POA skeleton rmic client stub client stub Implementation Implementation Development

  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

  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.

  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

  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

  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

  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.

  11. 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); }; IDL – see the printed version

  12. HTTP – surely not

  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

  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

  15. 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 Web Services the winner

  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

  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

  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

  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

  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)

  21. Extra costs : data

  22. Extra costs : time

  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 doesn’t create a parse tree)

  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 • Shouldn’t really be an issue

  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

  26. Throughputs

  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

  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

  29. State

  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

  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 Tomcat’s servlet session variables

  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

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

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

  35. Deployment

  36. Deployment and stability • Not initially one of aspects to explore • Possibly the best reason to swap to a Web Service style implementation!

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

  38. CORBA – 2nd • CORBA daemon (e.g. orbd) • Persistent name service • Restarts servers when required • Relatively easy to use • Less likely to have experienced administrator

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

  40. Conclusions

  41. 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”

  42. Tradeoffs: deployment • For many organizations, most important factor likely to be greater stability and ease of deployment of Web Service solution

More Related