ppt97 presentation
Download
Report
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