CSE298 CSE300 OV-1.1 CSE300 Distributed Object Computing using XML-SOAP Kevin White James Kebinger Fall 2000

CSE298 CSE300 OV-1.2 CSE300 Introduction to XML  XML it s a text-based markup language that is becoming a standard to store data  XML tags tell you what the data means, rather than how to display it.  Elements are the holding blocks for data in an XML object.

CSE298 CSE300 OV-1.3 CSE300 XML Example  The following is a XML example of a pizza item: The Texan barbeque brisket dill pickles onions mozzarella cheese tomato sauce Put the lone in lone star state!

CSE298 CSE300 OV-1.4 CSE300 What is XML?  XML objects can also consist of the following items: Elements: holding blocks for data Attributes: Name-value pairs that occur inside start-tags after the element name. Entity references: Created to allow entity to be created and used in places where multiple instances of the same text will be use in many places. Processing instructions: used to provide information specific to applications. Comments: User comments CDATA: A section of character data that will not be interpreted by the XML parser.

CSE298 CSE300 OV-1.5 CSE300 Why is XML important?  Plain Text  XML is it stored as plain ASCII text  Allows for viewing and editing the XML data with any text editor  Data Identification  Tag names relate to the data it holds  Produces easily parable data with reference to tag names

CSE298 CSE300 OV-1.6 CSE300 Why is XML important?  Display styles  XML is only a way to store data. A separate file can be created to display this data  XSL  Hierarchical  XML documents benefit from their hierarchical structure  Like stepping through a table of contents

CSE298 CSE300 OV-1.7 CSE300 Present Distributed Object Models  Java RMI for Java applications  DCOM for Windows applications  CORBA for cross platform applications  Each have overhead and large scale interoperability issues  Answer: SOAP = Simple Object Access Protocol

CSE298 CSE300 OV-1.8 CSE300 Java RMI  Design goal for the RMI architecture was to create a Java distributed object model  RMI works in 3 layers  The first layer intercepts method calls made by the client and redirects these calls to a remote RMI service.  This second layer understands how to interpret and manage references made from clients to the remote service objects.  The final layer is the transport layer and is based on TCP/IP connections between machines in a network.  Java RMI works for Java applications only

CSE298 CSE300 OV-1.9 CSE300DCOM  DCOM: Distributed Component Object Model  Microsoft’s solution for distributed computing  Allows one client application to remotely start a DCOM server object on another machine and invoke its methods  DCOM provides the ability to use and reuse components dynamically, without recompiling, on any platform, from any language, at any time

CSE298 CSE300 OV-1.10 CSE300CORBA  CORBA: Common Object Request Broker Architecture  CORBA is platform and language independents  CORBA Object Request Broker (ORB) provides a way to connect a client application with an object that it needs  When creating CORBA applications, two main classes, a stub and a skeleton, are created along with several helper classes  The ORB is the glue that connects the stubs and skeletons.

CSE298 CSE300 OV-1.11 CSE300 The SOAP Protocol  SOAP stands for Simple Object Access Protocol  SOAP doesn't care what operating system, programming language, or object model is being used on either the server side or the client side  SOAP is a cross-platform way to make remote method calls, serialize and de-serialize objects using XML

CSE298 CSE300 OV-1.12 CSE300 The SOAP Protocol  For a protocol it commonly uses HTTP, which is simple to implement and used universally  SOAP works over many protocols, not limited to HTTP  Using HTTP for transport gives SOAP an advantage over other previous middleware solutions because it does not require changes be made to network routers and proxy servers  An inherent advantage of SOAP being able to use HTTP is that it is a universally deployed protocol

CSE298 CSE300 OV-1.13 CSE300 SOAP Process  SOAP request would be processed in the following steps: 1. Get a request on the listen port. 2. Parse the request for the method id to call. 3. Consult a configuration file for what class/function to call to handle the request. 4. De-serialize the parameters for the method call. 5. Call the function with the given de-serialized parameters 6. Serialize the return value from the function and send it back to the requestor  SOAP is not rocket-science. SOAP is simple to understand, implement and deploy.

CSE298 CSE300 OV-1.14 CSE300 Basic SOAP Sample  Here is a SOAP request: POST /StockQuote HTTP/1.1 Host: Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI" DIS POST /StockQuote HTTP/1.1 Host: Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI" DIS

CSE298 CSE300 OV-1.15 CSE300 Basic SOAP Sample  And the matching response is: HTTP/ OK Content-Type: text/xml; charset="utf-8" Content-Length: nnnn 34.5 HTTP/ OK Content-Type: text/xml; charset="utf-8" Content-Length: nnnn 34.5

CSE298 CSE300 OV-1.16 CSE300 Apache SOAP  Used Apache SOAP v 2.0 for implementation.  Java library for both client and server  Application need not parse nor create XML  Server implemented as a servlet  Server application programmed without regard to SOAP  Client SOAP calls easy to construct using API

CSE298 CSE300 OV-1.17 CSE300 SOAP National Bank Prototype client-server application Supports basic banking tasks:   Balance inquiries   Deposits/withdrawals   Transfers   View transaction history

CSE298 CSE300 OV-1.18 CSE300 Use Cases

CSE298 CSE300 OV-1.19 CSE300 Class Diagram

CSE298 CSE300 OV-1.20 CSE300 System Architecture

CSE298 CSE300 OV-1.21 CSE300 System Implementation  Client and Server written in Java v 1.22  Client GUI uses Java Swing API  Server uses JDBC to connect to MS Access DB  Client and Server communicate using Apache’s Java SOAP library

CSE298 CSE300 OV-1.22 CSE300Screenshot

CSE298 CSE300 OV-1.23 CSE300 Bank System Conclusions  System successful, all functions work  Implementation fairly painless once we learned SOAP API  Only major snag was learning how to configure the SOAP servlet  Application rather slow: what causes slowness?  MS Access calls  SOAP itself

CSE298 CSE300 OV-1.24 CSE300 SOAP Benchmarking  Compare RMI to SOAP  Build a small client-server system to exchange the current data and time  As a java.util.Date object  As a java.lang.String object  Different objects will compare efficiency and scalability of serialization

CSE298 CSE300 OV-1.25 CSE300 SOAP Serialization Example String Thu Nov 23 17:24:46 EST 2000 Thu Nov 23 17:24:46 EST 2000</return> Date </return>

CSE298 CSE300 OV-1.26 CSE300 Benchmark Setup  250 Remote Calls per trial  Took average of 3 trials for final results  Tests run on Pentium Laptop with 288 Megs of RAM  Tests run locally, therefore do not reflect cost of network time.

CSE298 CSE300 OV-1.27 CSE300 SOAP Serialization

CSE298 CSE300 OV-1.28 CSE300 RMI Serialization

CSE298 CSE300 OV-1.29 CSE300 RMI v. SOAP

CSE298 CSE300 OV-1.30 CSE300 Benchmark Conclusions  RMI about ten times faster than SOAP  Agrees with published results from Indiana University  RMI Serialization may scale better than SOAP  SOAP using possibly inefficient generic serializer in test

CSE298 CSE300 OV-1.31 CSE300 SOAP Conclusions  SOAP could use an automatic stub generator like RMI  Would have sped up development greatly  Lots of people using SOAP  IBM, Microsoft, Compaq etc.  SOAP not a standard yet  Could change a lot before settling down

CSE298 CSE300 OV-1.32 CSE300 SOAP Conclusions  SOAP very usable today  Some questions concerning interoperability between SOAP implementation  SLOW  May be OK for some web apps  Not for high performance computing  Would recommend use for small systems