1 / 32

Understanding Distributed Object Computing with XML and SOAP

This article introduces the fundamental concepts of XML as a text-based markup language for data storage and the significance of XML in structuring data. It illustrates XML elements, attributes, and their importance in data representation. Additionally, it covers the basics of distributed computing using protocols like Java RMI, DCOM, and CORBA, highlighting the advantages of SOAP (Simple Object Access Protocol) as a cross-platform solution for remote method invocation. The process of utilizing SOAP for handling requests and responses in distributed systems is explained, demonstrating its simplicity and effectiveness.

senta
Télécharger la présentation

Understanding Distributed Object Computing with XML and SOAP

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. Distributed Object Computing using XML-SOAP Kevin White James Kebinger Fall 2000

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

  3. XML Example • The following is a XML example of a pizza item: <pizza> <name>The Texan</name> <toppings> <topping>barbeque brisket</topping> <topping>dill pickles</topping> <topping>onions</topping> <topping>mozzarella cheese</topping> <topping>tomato sauce</topping> </toppings> <description>Put the lone in lone star state!</description> </pizza>

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

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

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

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

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

  9. DCOM • 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

  10. CORBA • 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.

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

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

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

  14. Basic SOAP Sample • Here is a SOAP request: POST /StockQuote HTTP/1.1Host: www.stockquoteserver.comContent-Type: text/xml; charset="utf-8"Content-Length: nnnnSOAPAction: "Some-URI"<SOAP-ENV:Envelope  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">   <SOAP-ENV:Body>       <m:GetLastTradePrice xmlns:m="Some-URI">           <symbol>DIS</symbol>       </m:GetLastTradePrice>   </SOAP-ENV:Body></SOAP-ENV:Envelope>

  15. Basic SOAP Sample • And the matching response is: HTTP/1.1 200 OKContent-Type: text/xml; charset="utf-8"Content-Length: nnnn<SOAP-ENV:Envelope  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>   <SOAP-ENV:Body>       <m:GetLastTradePriceResponse xmlns:m="Some-URI">           <Price>34.5</Price>       </m:GetLastTradePriceResponse>   </SOAP-ENV:Body></SOAP-ENV:Envelope>

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

  17. SOAP National Bank Prototype client-server application Supports basic banking tasks: • Balance inquiries • Deposits/withdrawals • Transfers • View transaction history

  18. Use Cases

  19. Class Diagram

  20. System Architecture

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

  22. Screenshot

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

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

  25. String <return xsi:type="xsd:string">Thu Nov 23 17:24:46 EST 2000 </return> Date <return xsi:type="ns1:date"> <time xsi:type="xsd:long">975013920065</time> <minutes xsi:type="xsd:int">12</minutes> <seconds xsi:type="xsd:int">0</seconds> <date xsi:type="xsd:int">23</date> <day xsi:type="xsd:int">4</day> <hours xsi:type="xsd:int">16</hours> <year xsi:type="xsd:int">100</year> <timezoneOffset xsi:type="xsd:int">300</timezoneOffset> <month xsi:type="xsd:int">10</month> </return> SOAP Serialization Example

  26. Benchmark Setup • 250 Remote Calls per trial • Took average of 3 trials for final results • Tests run on Pentium 2 266 Laptop with 288 Megs of RAM • Tests run locally, therefore do not reflect cost of network time.

  27. SOAP Serialization

  28. RMI Serialization

  29. RMI v. SOAP

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

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

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

More Related