Unit-5

Technologies for SOA:

1
 Unit-5: Technologies for SOA
• XML: Namespaces, schemas, processing/passing models
• SOAP: messages, elements, attributes and processing
model, message exchange types ,HTTP binding
• WSDL: containment structure, elements of abstract
description, elements of the implementation part,
logical relationships, SOAP binding
• UDDI Registry: Basic data model, tmodel, categorization
and identification schemes, binding template, use of
WSDL in the UDDI registry

2
 SOAP
 XML itself is not enough for two parties to
communicate

 The service provider and service consumer must

be able to exchange messages according to an
agreed format.

 Simple Object Access Protocol (SOAP) is such a

protocol, providing a common message format
for services.
3
 SOAP

 SOAP is a text-based messaging format that uses an XML-

based data-encoding format.

 SOAP is independent of both the programming language,

vendors, platforms, and technologies.

 Its text format also makes SOAP a firewall-friendly protocol

 SOAP was originally designed to work only with HTTP, any

transport protocol or messaging middleware can be used
to carry a SOAP message.
4
 SOAP Message
 Namespace of SOAP elements
http://schemas.xmlsoap.org/soap/envelope/

 The SOAP message is a complete (or valid)

XML document, with the top element being
the envelope element.

 The envelope element contains a body

element and an optional header element.

 The body element usually carries the actual

message, which is consumed by the recipient.

 The header element is generally used for

advanced features for intermediate
processors.

5
 SOAP
 A simple but complete example of a SOAP
request for making a reservation request is
shown in Listing 12-1.

6
7
8
 SOAP Elements
 Envelop
 Header
 Body
 Fault

Name Space:
http://schemas.xmlsoap.org/soap/envelope/

9
 SOAP
 The header element is optional, but when it is
present it should be the first immediate child of
the envelope element

 The body element must be present in all SOAP

messages and must follow the header element if
it is present

 The body usually contains the specification of the

actual message

10
 SOAP Header
<env:header xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'>
<!—extensions go here -->
</env:header>

 A SOAP header is an extension mechanism to pass "control" information

in SOAP messages

 The child elements of the Header element are called header blocks

 Headers targeted individually at SOAP nodes encountered along the

message path from the sender to the ultimate receiver

 Can be used for extension services such as

 transaction support
 authentication 11
 SOAP Body
<env:body xmlns:env='http://schemas.xmlsoap.org/soap/
envelope/'>
<!—extensions go here -->
</env:body>

 Carries Payload of the message

 Payload (a request to be performed by a service, optionally

with a return value)

 Elements of body
 Must be qualified with a namespace
 Should not be 'http://schemas.xmlsoap.org/soap/ envelope/’ 12
SOAP Fault

13
14
 SOAP Attributes and Processing Model

SOAP Messages flows through a number of SOAP

Nodes starting from a sender to a target node

Attributes that control how a SOAP Node process

a header block

Role
mustUnderstand
Relay

15
 SOAP Attribute: role
SOAP Nodes assume one or more roles
How this is done is not defined in SOAP specification

SOAP defines three standard values of the role attribute:

none
next
ultimateReceiver

16
17
 SOAP Attribute: role
As shown in Listing 12-3.

Header Block1 the role is set to the URI

http://myCompany.com/Log.
Any node that assumes this application-defined role must log the
message.

Header Block2 the role is set to next

The header block is expected to be examined and (possibly)

processed by every SOAP Node except the Sender along the path

If the attribute role is missing (as in Block3)

it is targeted at the node that assumes the ultimate receiver node.
18
 SOAP Attribute: mustUnderstand
mustUnderstand possible values true or false

To ensure SOAP Nodes do not ignore a specific header block

True value - referred to as a mandatory header block.

A mustUnderstand value of "true" means that the SOAP node must process the header
with the semantics described in that header's specification, or else generate a SOAP fault
and returned.

Processing the header appropriately may include

removing the header from any generated SOAP message, reinserting the header with the same or
an altered value, or inserting a new header.

19
 SOAP Attribute: relay
relay Attribute is of type Boolean
Possible values :("true" or "false“).

When a SOAP intermediary node processes a header block, the SOAP

intermediary node removes the header block from the SOAP message

By default, the SOAP intermediary node also removes all header
blocks with the mustUnderstand value as false.

However, when the relay attribute is specified with a value of true, the
SOAP intermediary node retains the unprocessed header block in the
message.

Example: header blocks that carry information expected to persist

along a SOAP message path. 20
21
 SOAP Message Exchange Types
A SOAP message is fundamentally a one-way
transmission from a SOAP sender to a SOAP
receiver

SOAP messages can be combined to support

interaction pattern such as RPC-type
request/response

Remote Procedure Call (RPC)

22
 RPC
To make an RPC request for invocation, the following steps are needed:

The address of the targeted node that will ultimately process the request

The name of the method/procedure you want to invoke

The required parameters' names and values to invoke the method/ procedure,
including any output parameter and return value

Optionally, data that may be carried as a part of SOAP header blocks

Address information the target of the RPC equivalent to a node that adopts the
role of ultimate Receiver.

The target URI is made available depends on the underlying protocol binding.
the URI identification information can be carried in a SOAP header block.
URI information outside the SOAP message. (as HTTP header) 23
an example of an RPC request for credit card
payment. The travel reservation application
provides credit card information
On successful completion the card being charged
and a reservation code returned.
This reserve-and-charge interaction between the
travel reservation application and the travel
service application is modeled as a SOAP RPC.

24
25
The response is also returned as a SOAP message.
the response has two output parameters
reference to the reservation code
URL where the details of the reservation can be viewed.

26
27
 SOAP HTTP Binding
SOAP messages may be exchanged using a variety of
"underlying" protocols. One ex: HTTP

SOAP binding The specification for how SOAP messages may

be passed from one SOAP node to another using an
underlying protocol

SOAP defines a standard binding to only HTTP

In HTTP, the client specifies a server by a URL and

connects to it by using the TCP/IP network.
issues an HTTP request message and
receives an HTTP response message over the same TCP connection.
28
 SOAP HTTP Binding
Request-URI used identify the SOAP node that serves the request

The HTTP binding to SOAP restricts to:

POST
GET.

Allows two ways to exchange SOAP messages.

HTTP POST method is used to convey SOAP messages in the bodies of HTTP
request and response messages (request/response message-exchange
Pattern)

HTTP GET method in an HTTP request is used to return a SOAP message in

the body of an HTTP response (response exchange pattern)
for retrieval of information only
No change in the state of the server (idempotent operations) 29
HTTP GET Usage

30
31
32
 HTTP POST Usage
The SOAP request/response message-exchange pattern is
restricted to the HTTP POST method if HTTP binding is used.
This pattern is available to all applications.
It can be used for general exchange of XML data or RPCs
An example of an RPC exchange
the server is at myCompany .example.com
the SOAP request is sent in the body of an HTTP POST request.
the request is directed at the method chargeReservation.
The HTTP POST response

33
34
35
 Conclusion
• SOAP is an XML based message format to
exchange structural information between
applications
• SOAP can be transported on any protocol
• SOAP defines HTTP specific binding
• SOAP supports a number of message
exchange patterns, including remote
procedure calls.

36