Service-Oriented Computing
Inter-Application Communication
• Conventional distributed applications use distributed communication technologies, e.g., CORBA, DCOM, Java-RMI, based on object RPC (ORPC) protocols that attempted to marry object orientation and network protocols.
•
Weaknesses
– Both ends of the communication link would need to be implemented under the same distributed object model (Java-RMI or CORBA-IIOP)
– Difficulty of getting these protocols to work over firewalls or proxy servers, e.g. most firewalls are configured to allow HTTP to pass across, but not IIOP.
• To address the problem of overcoming proprietary systems running on heterogeneous infrastructures, Web services rely on SOAP.
What is SOAP?
• SOAP is the standard messaging protocol used by Web
services, an XML-based communication protocol for
exchanging messages between computers regardless of their
operating systems, programming environment or object model
framework.
Service provider Service requestor Application object (client) Application object (service provider) SOAP-based middleware SOAP-based middleware SOAP messagesexchanged on top of, HTTP, SMTP, or other transport
Converts procedure calls to/from XML messages sent through HTTP or other protocols.
SOAP as a lightweight protocol
• SOAP is a lightweight protocol that allows applications to pass messages and data back and forth between disparate systems in a distributed environment enabling remote method invocation.
• By lightweight we mean that the SOAP protocol possesses only two fundamental properties. It can:
– send and receive HTTP (or other) transport protocol packets, and – process XML messages.
Service Broker
Basic SOAP Message Exchange
Service
Consumer ProviderService
http transport SOAP message WSDL describing service SOAP message http transport client service registry find publish DESCRIBE INVOKE
SOAP Sender SOAP Receiver
SOAP Message
SOAP Building Blocks
A SOAP message is an XML document with the following
elements
– A required
envelope element
Identifies XML document as a SOAP message
– An optional
header element
Contains header information– A required
body element
with call and response
information
– An optional
fault element
SOAP Envelope Element
Required field –
The SOAP Envelope element is the root element
of a SOAP message. This element defines the XML document as
a SOAP message.
EncodingStyle attribute
– used to define data types used in the
document.
<?xml version="1.0"?> <soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> ...
Message information goes here ...
SOAP Header Element
Optional field -
Contains application specific information (e.g.
authentication, payment, etc.) about the SOAP message.
If the Header element is present, it must be the first child of
the envelope element
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Header>
<m:Trans xmlns:m="http://www.w3schools.com/transaction/" soap:mustUnderstand="1">234
</m:Trans> </soap:Header> ...
...
SOAP Header Element
• SOAP defines three attributes in the default namespace
("http://www.w3.org/2001/12/soap-envelope"). These attributes are: mustUnderstand, actor, and encodingStyle.
The previous example contains:
A Trans element, which is an actor
mustUnderstand attribute of 1
A value of 234, which denotes an encoding style
actor attribute
Message may pass multiple nodes – we need to denote who needs to act on it
mustUnderstand
attribute
whether a header entry is mandatory or optional for the recipient to process
encodingStyle Attribute
<env:Envelope
xmlns:env=“http://www.w3.org/2003/05/soap-envelope”
env:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”> ……
</env:Envelope>
<env:Envelope
xmlns:env=“http://www.w3.org/2003/05/soap-envelope” > …
<env:Header>
<tx:transaction-id
xmlns:tx=”http://www.transaction.com/transaction” env:mustUnderstand=”true”> 512
</tx:transaction-id> </env:Header>
……… </env:Envelope>
Example of SOAP envelope element
Example of SOAP header element
SOAP Body Element
• Required field - contains the actual SOAP message intended for the ultimate endpoint of the message. It may contain a number of child elements, called body entries, but it may also be empty.
SOAP Request
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body>
<m:GetPrice xmlns:m="http://www.w3schools.com/prices"> <m:Item>
Apples </m:Item> </m:GetPrice> </soap:Body>
SOAP response
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body>
<m:GetPriceResponse xmlns:m="http://www.w3schools.com/prices"> <m:Price>
1.90
</m:Price>
</m:GetPriceResponse> </soap:Body>
</soap:Envelope>
SOAP Fault Element
Optional field
- The SOAP Fault element is used to indicate
error messages.
If a Fault element is present, it must appear as a child element
of the Body element. A Fault element can only appear once in
a SOAP message.
Has the following sub elements:
Sub Element Description
<faultcode> A code for identifying the fault
<faultstring> A human readable explanation of the fault
<faultactor> Information about who caused the fault to happen
SOAP Fault element Example
The following sample SOAP message contains Fault element that indicates an “Insufficient Funds” error occurred while processing the previous request:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body>
<soap:Fault>
<faultcode>soap:Server</faultcode>
<faultstring>Insufficient funds</faultstring> <detail>
<x:TransferError xmlns:x="urn:examples-org:banking"> <sourceAccount>22-342439</sourceAccount> <transferAmount>100.00</transferAmount>
<currentBalance>89.23</currentBalance> </x:TransferError>
</detail> </soap:Fault>
SOAP
messages
Standard SOAP message:
<?xml version=“1.0”?> <soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/e nvelope/>
<soap:Header> <!-- optional -->
<!-- header blocks go here... --> </soap:Header>
<soap:Body>
<!-- payload or Fault element goes here--> </soap:Body>
</soap:Envelope>
Envelope
Header: Contains requirements
specific to message
optional
Body: Information used by application (object data, error messages, return values)
Simple messaging scenario
• SOAP defines a processing model that outlines rules for processing a SOAP message as it travels from SOAP sender to a SOAP
Sophisticated SOAP messaging
Intermediaries nodes
• while processing a message, a SOAP node assumes one or more roles that influence how SOAP header is processed
• roles are given unique names (in the form of URIs), so they can be identified during processing
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Header>
<wsrp:path xmlns:wsrp="http://schemas.xmlsoap.org/rp" soap:actor="http://schemas.xmlsoap.org/soap/actor/next"
soap:mustUnderstand="1" >
SOAP 1.2 Roles
Remark: SOAP 1.1 defines only one role next. Every node must acts as next role
SOAP role name Description
http://www.w3.org/2002/06/soap-envelope/role/next
Each SOAP intermediary and the ultimate SOAP receiver MUST act in this role and MAY
additionally assume zero or more other SOAP roles
http://www.w3.org/2002/06/soap-envelope/role/none
SOAP nodes MUST NOT act in this role
http://www.w3.org/2002/06/soap-envelope/role/ultimateReceiver
To establish itself as an ultimate SOAP receiver, a SOAP node MUST act in this role. SOAP
The SOAP Communication Model
• SOAP supports two possible communication styles: – remote procedure call (RPC) and
– document (or message).
Request for quote Request for quote Quote document Quote document
Web Service Definitions
Business Process Flow Receive Check Send Database Request for quote Request for quote Quote document Quote document
Web Service Definitions
Business Process Flow Receive
Check
Send Send
Database
RPC-style SOAP Services
RPC-style web services are used as remote objects on the client application side.
Clients send their request as a method call. The method returns a response message
SOAP envelope SOAP body
Method name orderGoods
Input parameter 1 product item Input parameter 2 quantity
SOAP envelope SOAP body
<env:Envelope xmlns:SOAP=“http://www.w3.org/2003/05/soap-envelope” xmlns:m="http://www.plastics_supply.com/product-prices"> <env:Header> <tx:Transaction-id xmlns:t=”http://www.transaction.com/transactions” env:mustUnderstand='1'> 512 </tx:Transaction-id> </env:Header> <env:Body> <m:GetProductPrice> <product-id> 450R6OP </product-id > </m:GetProductPrice > </env:Body> </env:Envelope> <env:Envelope xmlns:SOAP=“http://www.w3.org/2003/05/soap-envelope” xmlns:m="http://www.plastics_supply.com/product-prices"> <env:Header>
<--! – Optional context information --> </env:Header>
<env:Body>
<m:GetProductPriceResponse> <product-price> 134.32 </product-price> </m:GetProductPriceResponse>
</env:Body> </env:Envelope>
Example of RPC-style SOAP request message
Example of RPC-style SOAP response message
Document (Message)-style SOAP Services
SOAP supports documents exchange for any kind of XML data. The client sends the whole document to the provider instead of sending a set of arguments
SOAP envelope SOAP body
PurchaseOrder document
-product item
-quantity
SOAP envelope SOAP body
Acknowledgement document
<env:Envelope xmlns:SOAP=“http://www.w3.org/2003/05/soap-envelope”> <env:Header> <tx:Transaction-id xmlns:t=”http://www.transaction.com/transactions” env:mustUnderstand='1'> 512 </env:Header> <env:Body> <po:PurchaseOrder oderDate=”2011-12-02” xmlns:m="http://www.plastics_supply.com/POs"> <po:from>
<po:accountName> RightPlastics </po:accountName> <po:accountNumber> PSC-0343-02 </po:accountNumber> </po:from>
<po:to>
<po:supplierName> Plastic Supplies Inc. </po:supplierName>
<po:supplierAddress> Yara Valley Melbourne </po:supplierAddress> </po:to>
<po:product>
<po:product-name> injection molder </po:product-name> <po:product-model> G-100T </po:product-model>
<po:quantity> 2 </po:quantity> </po:product>
</ po:PurchaseOrder > </env:Body>
</env:Envelope>
Example of document-style SOAP message
Protocol Bindings
• each intermediary could choose to use different communication protocol without affecting the SOAP message
• standard protocol binding is required to ensure high level of interoperability across SOAP applications and infrastructure
• a concrete protocol binding defines exactly how SOAP message should be transmitted with given protocol
SOAP HTTP Binding
A binding of SOAP to a transport protocol is a description of how a SOAP message is to be sent using that transport protocol.
The typical binding for SOAP is HTTP.
SOAP can use GET or POST. With GET, the request is not a SOAP message but the response is a SOAP message, with POST both request and response are SOAP
messages (in version 1.2, version 1.1 mainly considers the use of POST).
SOAP uses the same error and status
SOAP HTTP Binding Example
SOAP Response Message Pattern: HTTP GET
A Fault Response
SOAP Requet-Response Message Pattern: HTTP POST
Advantages and disadvantages of SOAP
•
Advantages of SOAP are:
Simplicity: SOAP is simple as it uses XML that is well structured and easy to parse.
Portability: SOAP is platform-independent and thus portable.
Firewall-friendliness: SOAP is capable of getting past firewalls which are totally blocking for other protocols. This is possible due to using the HTTP protocol.
Use of open standard: SOAP is based on the open Standard XML to format data. As a consequence, SOAP becomes easily extendable and well supported.
Interoperability: SOAP relies on open instead of vendor-specific technologies and thus enables distributed interoperability and loosely coupled applications.
•
Disadvantages of SOAP are:
Too much reliance on HTTP. This imposed a request/response architecture which did not suit all situations. As HTTP is relatively slow, the performance of SOAP was affected.
Statelessness