Transcript ppt97 presentation

Distributed Object Computing using XML-SOAP
CSE298
CSE300
CSE300
Kevin White
James Kebinger
Fall 2000
OV-1.1
Introduction to XML
CSE298
CSE300

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.
CSE300
OV-1.2
XML Example
CSE298
CSE300

The following is a XML example of a pizza item:
CSE300
<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>
OV-1.3
What is XML?
CSE298

CSE300
CSE300
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.
OV-1.4
Why is XML important?
CSE298
CSE300 
CSE300

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
OV-1.5
Why is XML important?
CSE298
CSE300 
CSE300

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
OV-1.6
Present Distributed Object Models
CSE298
CSE300

CSE300


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
OV-1.7
Java RMI
CSE298
CSE300 
Design goal for the RMI architecture was to create
a Java distributed object model
CSE300


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
OV-1.8
DCOM
CSE298
CSE300 
DCOM: Distributed Component Object Model
CSE300

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
OV-1.9
CORBA
CSE298
CSE300 

CSE300
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.
OV-1.10
The SOAP Protocol
CSE298
CSE300 
CSE300
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
OV-1.11
The SOAP Protocol
CSE298
CSE300 
For a protocol it commonly uses HTTP, which is
simple to implement and used universally
CSE300

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
OV-1.12
SOAP Process
CSE298
CSE300 
CSE300
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.
OV-1.13
Basic SOAP Sample
CSE298
CSE300 
CSE300
Here is a SOAP request:
POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "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>
OV-1.14
Basic SOAP Sample
CSE298
CSE300 
CSE300
And the matching response is:
HTTP/1.1 200 OK
Content-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>
OV-1.15
Apache SOAP
CSE298
CSE300 
Used Apache SOAP v 2.0 for implementation.
CSE300

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
OV-1.16
SOAP National Bank
CSE298
CSE300
Prototype client-server application
CSE300
Supports basic banking tasks:




Balance inquiries
Deposits/withdrawals
Transfers
View transaction history
OV-1.17
Use Cases
CSE298
CSE300
Check Balance (s)
CSE300
<<include>>
Transfer Funds
<<include>>
<<include>>
Customer
Deposit/Withdraw
Login to Account
<<include>>
<<include>>
Close Account
Create New Account
Transaction History
OV-1.18
Class Diagram
CSE298
CSE300
CSE300
OV-1.19
System Architecture
CSE298
CSE300
CSE300
Access
DB
JDBC
DBAccess
Server
GUI
SOAP
Client
Servlet
Runner
OV-1.20
System Implementation
CSE298
CSE300 

CSE300


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
OV-1.21
Screenshot
CSE298
CSE300
CSE300
OV-1.22
Bank System Conclusions
CSE298
CSE300 

CSE300


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
OV-1.23
SOAP Benchmarking
CSE298
CSE300 

CSE300

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
OV-1.24
SOAP Serialization Example
CSE298
String
CSE300 <return xsi:type="xsd:string">Thu Nov 23 17:24:46
EST 2000
CSE300 </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>
OV-1.25
Benchmark Setup
CSE298
CSE300 

CSE300


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.
OV-1.26
SOAP Serialization
CSE298
CSE300
SOAP Serialization Tim es
CSE300
1.14
1.12
1.1
1.08
1.06
1.04
1.02
1
0.98
0.96
0.94
0.92
Date
String
OV-1.27
RMI Serialization
CSE298
CSE300
RMI Serialization Tim es
CSE300
1.06
1.05
1.04
1.03
1.02
1.01
1
0.99
0.98
0.97
Date
String
OV-1.28
RMI v. SOAP
CSE298
CSE300
SOAP v. RMI
Ti me P e r C a l l
CSE300
160
140
120
100
ms 80
60
40
20
0
SOAP-Dat e
SOAP-St ring
RMI-Dat e
RMI-St ring
OV-1.29
Benchmark Conclusions
CSE298
CSE300 
CSE300

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
OV-1.30
SOAP Conclusions
CSE298
CSE300 
CSE300


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
OV-1.31
SOAP Conclusions
CSE298
CSE300 
CSE300
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
OV-1.32