SOAP:Simple Object Access Protocol
XML-RPC
Ganapathy Raman
GRA-Netsolve Group
ICL
SOAP: Introduction
•
•
•
•
•
•
•
XML - last week talk
MathML, SMIL, VML
Distributed Computing is here to stay
Computation thro Communication
Resource Heterogenity
Common Language for Data exchange
Leverages XML to solve the above problem
SOAP:Is this Hype?
•
•
•
•
•
•
•
•
Lack of standard - Hurts Interoperability
In-memory representation
On-the-wire representation
DCOM - DCE/NDR
CORBA - IIOP/CDR
JAVA - RMI/JRMP
Netsolve - XDR
Tied to a single middleware (Monopoly?)
SOAP:Is this Hype?
•
•
•
•
•
Security Issues
Firewalls allow only specific ports
HTTP,FTP
Most middleware dynamically assign ports
This is a real problem for internet
applications
Possible solutions
• Use Ascii
–
–
–
–
fprintf/fscanf instead of fwrite/fread
flat stream of data
not rich enough to represent structure
producer and consumer forced to ‘know’ each
other
• Use CGI
– http + ascii
XML to the rescue
• XML is not about content
• XML is about structure of content
• XML + DTD provides a standard way for
anyone to understand data using the same
set of tools
• Producer and consumer can be ‘strangers’
SOAP in a Nutshell
1. XML for encoding data
– LANGUAGE OF COMMUNICATION
2. HTTP as transport
– MEDIUM OF COMMUNICATION
•
•
•
•
Do not let Microsoft Hype fool you!!
“Simplicity over Complexity”
Surely a step in the right direction
Deserves a detailed look
An example
• www.weather.com
• float CurrentTemp(zip_code)
• The process
Application
Middleware
SOAP
HTTP
icl.cs.utk.edu
Request
Reply
Error
Application
Middleware
SOAP
HTTP
www.weather.com
REQUEST Example
POST /Temperature HTTP/1.1
Http
Host: www.weather.com
Content-Type: text/xml
Content-Length: <whatever>
SOAPMethodName: <some-URI>#CurrentTemp
Header
Soap Extensions
<SOAP:Envelope xmlns:SOAP="urn:schemas-xmlsoaporg:soap.v1">
<SOAP:Body>
<m:CurrentTemp xmlns:m="some-URI">
<zip_code>37919</zip_code>
<m:CurrentTemp>
</SOAP:BODY>
<SOAP:Envelope>
URI- Uniform Resource Identifier
some-URI -> www.netsolve.com or www.globus.com
Xml Payload
RESPONSE Example
HTTP/1.1 200 OK
Content-Type: text/xml
Content-Length: <whatever>
Http Header
<SOAP:Envelope xmlns:SOAP="urn:schemas-xmlsoaporg:soap.v1">
<SOAP:Header>
<t:Transaction xmlns:t="some-URI">
5
</t:Transaction>
</SOAP:Header>
<SOAP:Body>
<m:CurrentTempResponse xmlns:m="some-URI">
<return>42</return>
</m:CurrentTempResponse>
</SOAP:Body>
</SOAP:Envelope>
Xml Payload
SOAP: What it’s NOT
• Object Activation
– who invokes CurrentTemp function?
• Bi-directional Communications
• Distributed Garbage Collection
• Language Bindings unspecified
– good for interoperability
– Perl,C,java
– Source of xml-rpc payload is immaterial
SOAP: Analysis
•
•
•
•
Size of Messages
Latency is key, not Bandwidth
High factors of Compression
Ascii + repetitive Tags
Client
Client
100 bytes
1000 bytes Server No compression
100 bytes
Server
200 bytes
Compression
SOAP:Analysis
In-memory
encode
xml-rpc
decode
In-memory
• Strings - no conversion needed
• Floating Point - sprintf,sscanf
• “e-commerce” applications --- GOOD
– text + integers
• “grid” applications --- BAD
– numeric intensive
• There is always a tradeoff involved
SOAP: What the Grid needs
• A standard that can find a balance between
performance and inter-operability
• XDR,NDR,CDR - possible candidates
• Ability to represent structure is key
• Maybe an extension to xml-rpc
• Will enable grid infrastructures to interoperate
SOAP: Analysis
•
•
•
•
•
Stateless Nature - Independent transactions
Most distributed applications are stateful
Programming model is different
State info with every transaction
Size of state info need
– “A cookie may not satisfy hunger”!!
• Good for scalability
SOAP: Analysis
•
•
•
•
•
Programming complexity
Standards are in flux
Maturity of tools
Need open-source xml parsers
xml.apache.org
– xerces : parsers in xml,perl,c++
• A minor obstacle at best
SOAP: Birds-eye-view
JAVA
OTHER
DCOM
CORBA
Islands of in-compatibility interconnected by SOAP bridges
Philosophy of “Do one thing and do it well”
Focus on Interoperability
SOAP: What can it teach us?
• Use XML for data exchange
– can define our own xml-rpc if needed
– the idea of encoding is what is important
– can use TCP as transport
• HTTP tunneling
• Would be a short-sight on our part to ignore
because of Microsoft tag
SOAP: Summary
•
•
•
•
•
•
Its not something path-breaking
“Right mix of technology at the right time”
Structure more important than content
XML - ASCII of the future
Holds lot of promise
Step in the right direction
SOAP: Resources
• www.cs.utk.edu/~raman/soap/soap.html
– links to whitepapers, spec, articles etc
– link to this presentation
• Questions???
• Thank you