Soap and the Future of
Distributed Processing on the
Internet
Mohammed El-Affendi
Dept of Computer Science, CCIS, PSU
Topics Covered







What is a distributed application?
Evolution of distributed applications.
The famous RPC.
Architectures of distributed systems and
applications.
CORBA and COM: interoperability.
XML and SOAP.
WEB services
What is a distributed
application?


A distributed application is an
application that runs on several
interconnected machines, but appears
to its user as if it were running on a
single machine.
This is called a true distributed
application.
Network Applications?



In network applications, the network is
transparent.
The user knows that he is using a
network.
Transparency is the major difference
between distributed and network
applications.
Architecture of distributed
systems and applications:


Distributed systems may be based on
existing OS’s and protocols or built from
scratch. (Distributed Unix versus
Amoeba).
They may be based on monolithic or
thin kernels.
Function Calls in Distributed
Systems: The Famous RPC:

Remote Procedure Calls (RPC’s):
Client
Program
Client Calls
Functions
Server
Program
Stub
Marshall
Transport
1 0 1 0 1
unmarshall
Transport
The CORBA Standard and
Distributed Objects:


The OMG designed CORBA as a
standard for interoperability between
distributed objects.
The main motivation is to allow
applications to call functions
implemented by other distributed
applications using a standard interface
specification.
COM and DCOM:


Microsoft introduced a similar de facto
standard commonly known as COM.
The main motivation behind COM is to
allow binaries to interoperate through
exported interface specifications, in a
manner independent of the
programming language and platform.
COM and DCOM:




Another motivation is to allow applications to
control each other easily.
COM assumes that the interoperating
applications are on the same machine.
DCOM is an extension of COM across
networks and the Internet.
DCOM clients may call procedures and
functions implemented by DCOM servers on
other machines.
DCOM Clients and Servers:

The user should not worry about
communication details:
Client
Server
Problems with COM and
CORBA:


One problem with COM and CORBA is
that they are competing standards
which are not compatible.
Another problem is that in many cases
they may not be able to cross firewall
boundaries.
Enter SOAP:




Due to the above problems, people
have been looking for a more versatile
solution acceptable by all.
The answer has been “SOAP”.
SOAP stands for “Simple Object Access
Protocol”
In one sentence: SOAP=XML + HTTP.
SOAP:



The main idea behind SOAP is to utilize two
widely accepted standards to facilitate
interoperability across the Internet.
The first of these is the XML standard for
describing data (I will explain shortly).
The other standard is nothing but the widely
accepted WEB protocol: the famous HTTP.
SOAP:


In what follows, I will briefly describe
XML and the HTTP and then come back
to SOAP.
However, one point to remember is that
the HTTP is one of the very few
protocols that can cross firewalls.
XML:

XML is all about structured, selfdescribing data


Data which must be structured are the
method calls and return data
Many implementations available to
process XML
What is XML





XML stands for “eXtensible Markup Language”
XML Language is a text-based format that lets
developers describe, deliver and exchange
structured data between a range of applications
and clients for local display and manipulation.
XML also facilitates the transfer of structured data
between servers themselves.
XML resembles and complements HTML.
XML describes data, while HTML defines tags
that describe how the data should be displayed.
XML:


XML, however, allows developers to
define an unlimited set of tags, bringing
great flexibility to authors, who can
decide which data to use and determine
its appropriate standard or custom tags.
HTML uses a frozen set of tags that are
difficult to extend.
XML example:









The following simple example shows how
XML is used to describe a weather report:
<weather-report>
<date>16, Sept, 2001</date>
<time>12:45</time>
<area>
<city> Sharjah </city>
<region> North. Reg</region>
<country> UAE </country>
</area>
XML Example:











<measurements>
<skies>partly cloudy</skies>
<temperature>46</temperature>
<wind>
<direction>SW</direction>
<windspeed>6</windspeed>
</wind>
<humidity>40</humidity>
<visibility>10</visibility>
</measurements>
</weather-report>
Why XML

XML is simple


Open, Standards Based




Text-based and human readable
Much like TCP/IP, HTTP, HTML
XML makes data more important than code and
is good for describing data
XML enables powerful Web applications and is
available on (almost) all platforms
XML will be the format and the data model for
all information flowing across applications, via
messages, and through the web
Namespaces


Solves the “naming” and “sharing” problems
Makes XML very extensible

Enables developers to mix data described by multiple
schemas in one XML instance


Schema components are reusable in other schemas
Qualifies data elements uniquely


<B:Title>Learning XML</B:Title>
<C:Title>Dr.</C:Title>
Namespaces


URI’s are used for Scoping.
Uniform Resource Identifiers (URIs)

Uniform Resource Name (URN)


Location Independent, need not equate to anything.
Uniform Resource Locator (URL)

Location hints are embedded in identifier
Using Namespaces

To define a namespace for an
element:

Define the xmlns attribute and assign
it a Uniform Resource Identifier (URI)
<root>
<bk:BOOK
xmlns:bk="urn:BookStore.org:BookInfo"
xmlns:money="urn:Finance:Money">
<bk:TITLE>A Suitable Boy</bk:TITLE>
<bk:PRICE>22.95</bk:PRICE>
HTTP

Internet’s Request/Response Protocol




Ubiquitous cross-platform/language support
Highly scalable server-side implementations
are available
Simple and Extensible protocol
Typically the only thing allowed through
firewalls
A basic HTTP scenario

User-Agent establishes TCP connection to
Server




Typically over port 80
User-Agent sends HTTP request message to
Server
Server processes request and sends back
HTTP response message
An HTTP endpoint is identified by a Uniform
Resource Locator (URL):
http://www.affendi.net/test/mmm.asp
HTTP operations

HTTP 1.1 supports several built-in
methods



GET and POST most common
POST requests typically contain a body
used to pass information along with
request
GET can only pass information using a
Query String
HTTP messages

HTTP request and response messages have
headers & optional body





Headers contain method (GET/POST), URL and HTTP
version.
Headers are text-based name:value pairs
Headers are CRLF delimited
Body starts after CRLFCRLF sequence
Content-Length/-Type headers indicate size and MIME
type
Sample HTTP messages
GET /test/mmm.asp HTTP/1.1
Host: WWW.affendi.NET
POST /test/display.asp HTTP/1.1
Host: WWW.affendi.NET
Content-Length: 12
Content-Type: text/plain
Hello, World
HTTP responses

HTTP responses begin with a status line
containing a numeric code and description




2xx: Success
4xx: User-Agent Error – Request contains bad
syntax or cannot be fulfilled
5xx: Server Error – The server failed to fulfill an
apparently valid request
HTTP/1.1 200 OK
Also 1xx and 3xx codes.
Content-Length: 12
Content-Type: text/plain
Hello, World
Back to SOAP:

Now Back to SOAP.
SOAP version 1.1

Specifies a simple and lightweight XML
messaging protocol for exchanging
structured and typed information.


Bindable to many transports


Designed as an RPC mechanism
HTTP is currently the primary transport
Extensible

Based upon its envelope structure
SOAP Spec consists of 4 parts

An extensible envelope (XML) expressing



A set of encoding rules for data


Defines how data is represented in XML.
A convention for representing Remote
Procedure Calls


what is the message and what are its features
whether the features are optional or mandatory.
Defines how calls and returns are packaged in
XML.
A protocol binding to HTTP

What SOAP messages over HTTP look like
SOAP HTTP Message Structure
SOAP Message
The complete SOAP Message
HTTP Headers
Standard HTTP and SOAP HTTP Headers
SOAP Envelope
<Envelope> encloses payload
SOAP Header
Headers
SOAP Body
Message Name & Data
<Header> encloses headers
Individual headers
<Body> contains SOAP
Message Name & Data
XML Encoded SOAP
Message Name & Data
A Simple Request Example:


<SOAP:Envelope xmlns:SOAP="urn:schemasxmlsoap-org:soap.v1">
<SOAP:Header></SOAP:Header>
<SOAP:Body>
<m:GetSalesTax
xmlns:m="urn:myserver/soap:TaxCalc">
<SalesTotal>100</SalesTotal>
</m:GetSalesTax>
</SOAP:Body>
</SOAP:Envelope
A Simple Response Example:



<SOAP:Envelope
xmlns:SOAP="urn:schemas-xmlsoaporg:soap.v1">
<SOAP:Header></SOAP:Header>
<SOAP:Body>
<m:GetSalesTaxResponse
xmlns:m=
"urn:myserver/soap:TaxCalc">
<SalesTax>4</SalesTax>
</m:GetSalesTaxResponse>
</SOAP:Body>
</SOAP:Envelope>
Sample SOAP (HTTP) Message
POST /sample/soapdemo.asp HTTP/1.1
Host: www.ctmsdev.net
Content-type: text/xml
Content-length: nnn
SOAPAction: Some-uri#MethodName
<SOAP-ENV:Envelope
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/
SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/>
<SOAP-ENV:Header>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
SOAP Headers

Headers are optional


Open-ended set of header entries



Associate special processing instructions with the
request
Can be used for security, transactions, etc…
Or any other special information that applies to
processing this message
Individual header entry can be
optional/mandatory

mustUnderstand=“1” indicates the recipient must
understand this instruction and obey it or fail
processing.
Sample SOAP Message -Header
<SOAP-ENV:Envelope
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/
SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/>
<SOAP-ENV:Header>
<mynms:CurrIndex xmlns:myns=“My-uri”
SOAP-ENV:mustUnderstand=“1”>3</myns:CurrIndex>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
…
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
SOAP Body


Always mandatory
This is where the method call and
response are encoded

Errors can be reported on the response
Sample SOAP Request
<SOAP-ENV:Envelope
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/
SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/>
<SOAP-ENV:Header>
…
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<m:MethodName xmlns:m=“Some-uri”>
<x>3</x>
<y>4</y>
</m:MethodName>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Sample SOAP Response
HTTP/1.1 200 OK
Content-Type: text/xml
Content-Length: nnn
<SOAP-ENV:Envelope
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/>
<SOAP-ENV:Body xmlns;m=“Some-uri”>
<m:MethodNameResponse>
<return>24</return>
</m:MethodNameResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
SOAP Types

SOAP specification specifies Simple as well as
Compound Types

Simple types are defined in the section of “Built-in
data types” of “XML Schema Part 2: Datatypes”


String, int, boolean,float, etc…
Compound Types are either Structs or Arrays


In Structs, the element names distinguish the different
elements
In Arrays, the Ordinal postion serves to distinguish
among the elements
WEB Services:



SOAP made it possible to implement
RPC’s across the Internet.
Using SAOP, an application may
transparently call a function
implemented in server somewhere on
the Internet.
Companies are now utilizing this feature
to provide “WEB Services”.
WEB Services:


A WEB service is simply a WEB
application or method callable across
the Internet.
The vehicle is of course SOAP.
What is the Significance of
this?


The main significance of this is that the
Internet is being transformed from a network
system into a huge global distributed system
that may host a wide variety of distributed
applications.
Users may now build distributed applications
that consists of components that reside on
other machines and platforms.
What is the Significance of
this?




Software may now be provided as a
subscription service.
You license an application for a period of time
rather than buying it.
Users may be able to control their
environments and do a wide range of things
that were not possible before.
A huge amount of services will shortly be
available across the Internet.
Current web applications
Browsers
App Code
Internet
Browsers
Web app developers took
advantage of these local
services and used HTML to
“project” the UI to lots of
clients.
OS,
Core Services
and Data
Historically, most
development efforts have
been directed toward
building apps using rich local
services.
The Web Services View
Vertical and Portal
Services
App Code
OS and
Local
Services
Internet
Application Specific
Web Services
Building Block
Web Services
Web Services are building blocks
that enable developers to build and
aggregate applications and services
from local and remote resources for
a range of clients.
Browsers
Devices
What are Web Services?

A web-addressable resource that provide
data and functions for programmatic
access.
WEB Services:
UDDI DISCO
Client
Program
Server
Program
WSDL
Proxy
Transport
Stub
SOAP
1 0 1 0 1
Transport
Building Block Standards

XML



Standard way to represent information
Used to build all other protocols
HTTP


Transport Layer
Scalable
Web Service Protocols

Simple Object Access Protocol (SOAP)


Web Services Description Language (WSDL)


Remote Procedure Calls
Describe Web Services
Discovery Protocols

DISCO


Tied to a particular URL
UDDI


Universal Description Discovery and Integration
Building Web Service catalogs and finding Web Services
from central repositories
Web Service Infrastructure
Reliability
Security
Routing
Process
Orchestration
(XLANG)
Directory (UDDI)
SOAP
(XML Protocols)
Service
Description
(WSDL)
XML
XML Schemas
XML
HTTP
XML
Communication
Description
Packaging
Disco
Discovery
What are Web Services?

Building blocks for constructing distributed
applications






Independent of platform, object model and
language
Based upon open Internet Standards
Internet or Intranet
Loosely coupled
Higher levels of application integration
Software as a service
The programmable web
Web Services
Commerce
Collaboration
Transact
business
Leverage your
experience
Access data
Publish
Transform the way you
conduct business
Integrate the Web with
business systems
Get your
information on
the Web
Security
Chasm
Business
Chasm
V
A
L
U
E
Illustrating the Idea:

A Simple LookUp Example:
Methods:
LookUp
•
FindPerson
•
GetPersonList
Web Service Specifications
HTTP – transport
 XML – packaging
 SOAP – method/response format
WSDL – services and types
 UDDI and DISCO

(Web) Services Description
Language

Need a way to describe Web Services



As documentation for the Web Service
For Tools / Platforms to automate the
details of communication
WSDL 1.0 is a new standard for doing
this.
A Service Description fragment
– Service Description
<serviceDescription xmlns:s0="http://tempuri.org/main.xsd" xmlns:s1="" name="WebService1"
targetNamespace="" xmlns="urn:schemas-xmlsoap-org:sdl.2000-01-25">
<soap xmlns="urn:schemas-xmlsoap-org:soap-sdl-2000-01-25">
<service>
<addresses>
<address uri="http://localhost/websx/webservice1.asmx"/>
</addresses>
<requestResponse name="FindPerson“ soapAction="http://tempuri.org/FindPerson">
<request ref="s0:FindPerson"/>
<response ref="s0:FindPersonResult"/>
</service>
</soap>
A Service Description fragment
-- Types
<schema targetNamespace="http://tempuri.org/main.xsd"
xmlns="http://www.w3.org/1999/XMLSchema">
<import namespace="http://www.w3.org/1999/XMLSchema"/>
<element name="FindPerson">
<complexType> <element name="strEmail" type="string" nullable="true"/> </complexType>
</element>
<element name="FindPersonResult">
<complexType> <element name="result" type="s0:Person"/> </complexType>
</element>
<complexType name="Person">
<element name="strEmail" type="string" nullable="true"/>
<element name="strFirstName" type="string" nullable="true"/>
<element name="strLastName" type="string" nullable="true"/>
</complexType>
Discovery


Used to locate a Web Service’s description
DISCO is targeted discovery



UDDI is a centralized services directory




Looking directly at a particular site
Web crawlers
Geared toward finding standard services from a
centralized registry
UDDI defines an API executed via SOAP
UDDI hold pointers to the details (WSDL or
DISCO)
Let’s look at DISCO a bit further
DISCO in practice
HTTP request
<discovery>
information about resource
</discovery>
http://resource
Sample DISCO Documents
<?xml version="1.0" ?>
<discovery xmlns="http://schemas.xmlsoap.org/disco/">
<contractRef ref="/calc/Calc.asmx?sdl" docRef="/calc/Calc.asmx"
xmlns="http://schemas.xmlsoap.org/disco/scl/" />
</discovery>
<?xml version="1.0" ?>- <discovery xmlns="http://schemas.xmlsoap.org/disco/">
<discoveryRef ref="/CPPWS/CPPWS.disco" />
<discoveryRef ref="/Calc/Calc.disco" />
<discoveryRef ref="/CalcForm/CalcForm.disco" />
<discoveryRef ref="/Calculator/Calculator.disco" />
<discoveryRef ref="/CPPWS/CPPWS.disco" />
<discoveryRef ref="/WA1/WA1.disco" />
<discoveryRef ref="/WS1/WS1.disco" />
<discoveryRef ref="/WS2/WS2.disco" />
</discovery>
App Code
Application Specific
Web Services
SDLASP
The Toolkit enables you to:
• Expose Web services by generating an
XML service description from a COM
component’s type library
• Consume Web services automatically in
VB by turning the contract into a
programmable proxy with a Remote
Object Proxy Engine (ROPE)
• Receive SOAP requests from a SOAP
client (e.g., the proxy) with an ASP or
ISAPI “listener”
Vertical and Portal
Services
SDLASP
ROPE
SOAP
SDLASP
Local
Services
The SOAP Toolkit
Building Block
Web Services
Browsers
Devices
Thanks


Thank you for attending and listening.
WaSalamu Alaikum Wa Rahmatu Allah.