WEB SERVICES – SERVICE ORIENTED ARCHITECTURE

Dr.Saranya K G,
Assistant Professor (S.Gr),
Dept.of CSE,
PSG College of Technology,
Coimbatore.
What is a Web Service
• A web service is a network accessible interface to
application functionality, built using standard
Internet technologies.
• Clients of web services do NOT need to know how
it is implemented.

Application Application
Network Web
client Service code
Web Service Technology Stack
shopping web service?
Discovery Web Service UDDI
WSDL URIs
Client

Description Web Service

WSDL
WSDL
SOAP pkg request
Packaging Proxy
SOAP pkg response

Transport

Network
Step1. Write Web Service Method
shopping web service?
Discovery Web Service UDDI
WSDL URIs
Client

Description Web Service

WSDL
WSDL
SOAP pkg request
Packaging Proxy
SOAP pkg response

Transport

Network
Step2. Describe Web Service using WSDL
shopping web service?
Discovery Web Service UDDI
WSDL URIs
Client

Description Web Service

WSDL
WSDL
SOAP pkg request
Packaging Proxy
SOAP pkg response

Transport

Network
Step3. Write Proxy to Access Web Service
shopping web service?
Discovery Web Service UDDI
WSDL URIs
Client

Description Web Service

WSDL
WSDL
SOAP pkg request
Packaging Proxy
SOAP pkg response

Transport

Network
Step4. Write Client to Invoke Proxy
shopping web service?
Discovery Web Service UDDI
WSDL URIs
Client

Description Web Service

WSDL
WSDL
SOAP pkg request
Packaging Proxy
SOAP pkg response

Transport

Network
Web Services - Definition from W3C
“ A Web service is a software system identified by a URI, whose public
interfaces and bindings are defined and described using XML. Its
definition can be discovered by other software systems. These
systems may then interact with the Web service in a manner
prescribed by its definition, using XML based messages conveyed by
internet protocols.”
Service Oriented Architectures

Role Technologies capable of:

•Exchanging messages
service
•Describing Web services
requestor •Publishing and discovering Web
retrieves a service descriptions
service A service publishes its
Operation
description description

One-way, Component
conversational, many-
to-many
Web Services –
Architectural Extensions
• Incorporates additional features and functionality by extending
technologies and components defined within the basic architecture, such
as:
• Asynchronous messaging
• Attachment – typical usage : associating binary data with SOAP messages.
• Caching
• Message exchange pattern (MEP) - Describes a generalized pattern of message
exchange between two services. e.g. : one-way, request/response,
publish/subscribe, and broadcast.
• Reliable message - implementation of Reliable Messaging one MEP is a series
of requests between two nodes with an acknowledgement SOAP Module.
• Message confidentiality – Can transmit the message via SSL or TLS, or have a
SOAP Module provides for encryption and decryption.
• Message integrity – Can have a SOAP Module use digital signature.
• Session
The Complete Web Services "Stack"

More
mature
technologie
s
The Wire Stack
•Transport: HTTP is
the de facto, other
may be supported.
•Packaging: SOAP is
the de facto standard
for XML messaging.
•Extensions :
Additional information
attached to web
services messages.
The Description Stack
It is actually a stack of description
documents defined using XML
Schema.

Not fully
specified
facts, or assertions, and
rules that apply to a
particular Web service
Input/
Output
rendering
minimum service description
necessary to support Satisfied
interoperable Web services. by WSDL
The Discovery Stack
WSIL : de-centralized
service discovery method

 Service can be published using a variety of mechanisms:

 Direct publish: description sent directly to requestor;

 WSIL : HTTP GET retrieves descriptions from URL;

 Universal Description, Discovery and Integration (UDDI) registries: a

Web-based distributed directory.
 Service requestors can retrieve a service description at design time
(search by interface) or runtime (by communication and QoS) from a Web
page (URL), a service description repository, a simple service registry or a
UDDI registry. Discovery depends on how services are published;
The technology so far
The WS technology is completely based on XML.
Therefore, both the data format and the
interaction protocols are XML-based:
 customized XML -> data format
 SOAP -> communication protocol
 WSDL -> the Interface definition language
 WSIL/UDDI -> standards for services discovery

The lowest-level layers (the transport layer)

should exploit some existing Internet
protocols, like HTTP or SMTP
What is XML
XML is a simple tag-based language for
describing information in a structured way.
Basic elements:
 Tags
 Attributes
LastName Allen
 Text

StartTag Attributes Text EndTag

<xhtml:table><xhtml:tr>
<xhtml:td width="40%">LastName</xhtml:td>
<xhtml:td width="60%">Allen</xhtml:td>
</xhtml:tr></xhtml:table>
How to work on XML
The tree-like structure of XML makes developers
life hard.
In practice there is not a standard way for
editing and analyzing, but the best method
depends on your need. Just choose among:
 SAX -> callback-based parser
 DOM -> tree representation
 XSLT -> “XML to XML” conversion
 XPATH -> queries
 XML Binding -> transparent conversion to
objects
Simple Object Access Protocol
SOAP is a technology to support the exchange of
XML-coded messages over a transport protocol,
such as HTTP and SMTP. (wire stack)

HTTP Client Server

SOAP   XML XML  
XML
Stub Skeleton

  SOAP SOAP  
POST…
HTTP client HTTP server
Protocols Folding HTTP 1.1 200 OK

SOAP basic mechanism

SOAP
• Actually used to communicate with the Web Service

• Both the request and the response are SOAP messages

• The body of the message (whose grammar is defined by the WSDL) is contained
within a SOAP “envelope”

• “Binds” the client to the web service

WSDL
• Describes the Web Service and defines the functions that are exposed
in the Web Service

• Defines the XML grammar to be used in the messages

• Uses the W3C Schema language
UDDI
• UDDI is used to register and look up services with a central registry

• Service Providers can publish information about their business and the services
that they offer

• Service consumers can look up services that are available by

• Business
• Service category
• Specific service
SOAP
SOAP I: Intro and Message
Formats
SOAP and Web Services
• The actual communications are
encoded with SOAP. Client
• Transported by HTTP
WSDL

SOAP SOAP
Request Response

WSDL

Service
Beyond Client-Server
• SOAP assumes messages have
an originator, one or more Originator Recipient
ultimate receivers, and zero or
more intermediaries.
• The reason is to support
distributed message processing.
Intermediary
• Implementing this message
routing is out of scope for SOAP.
• Assume each node is a Tomcat
server or JMS broker.
• That is, we can go beyond client- Intermediary
server messaging.
Intermediary
 SOAP
• SOAP is just a message format.
• Must transport with HTTP, TCP, etc.
• SOAP is independent of but can be connected to
WSDL.
• SOAP provides rules for processing the message as it
passes through multiple steps.
• SOAP payloads
• SOAP carries arbitrary XML payloads as a body.
• SOAP headers contain any additional information
• These are encoded using optional conventions
Web Service Messaging Infrastructure Requirements?
• Define a message format
• Define a messaging XML schema
• Allow the message to contain arbitrary XML from other schemas.
• Keep It Simple and Extensible
• Messages may require advanced features like security, reliability, conversational
state, etc.
• KISS, so don’t design these but do design a place where this sort of advanced
information can go.
• Add these capabilities in further specifications: WS-Security, WS-ReliableMessaging, etc.
• Tell the message originator is something goes wrong.
• Define data encodings
• That is, you need to tell the message recipient the types of each piece of data.
• Define some RPC conventions that match WSDL
• Your service will need to process the message, so you need to provide some simple
conventions for matching the message content to the WSDL service.
• Decide how to transport the message.
• Generalize it, since messages may pass through many entities.
• Decide what to do about non-XML payloads (movies, images, arbitrary
documents).
SOAP
• SOAP Messages:
• Headers and body elements with examples.
• SOAP Encoding:
• Rules for encoding data.
• Focus on SOAP for RPC
• SOAP Routing and Processing
• SOAP Over HTTP:
• How SOAP gets sent over the wire.
SOAP Messaging
SOAP Basics
• SOAP is often thought of as a protocol extension for doing Remote Procedure
Calls (RPC) over HTTP.
• This is how it is often used.
• This is not accurate: SOAP is an XML message format for exchanging structured,
typed data.
• It may be used for RPC in client-server applications
• May be used to send XML documents
• Also suitable for messaging systems (like JMS) that follow one-to-many (or publish-subscribe)
models.
• SOAP is not a transport protocol. You must attach your message to a transport
mechanism like HTTP.
What Does SOAP Look Like?
• The next two slides shows examples of SOAP
message from our Echo service.
• It’s just XML
• First slide is an example message that might be
sent from a client to the echo service.
• Second slide is an example response.
• I have highlighted the actual message payload.
 SOAP Request
<?xml version=‘1.0’ ?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd=http://www.w3.org/2001/XMLSchema
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<ns1:echo
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:ns1="http://.../axis/services/EchoService">
<in0 xsi:type="xsd:string">Hollow World</in0>
</ns1:echo>
</soapenv:Body>
</soapenv:Envelope>
 SOAP Response
<?xml version=‘1.0’ ?>
<soapenv:Envelope
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/
xmlns:xsd=http://www.w3.org/2001/XMLSchema
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<ns1:echoResponse

soapenv:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/

xmlns:ns1="http://../axis/services/echoService">
<echoReturn xsi:type=“String“>
Hollow World
</echoReturn>
</ns1:echoResponse>
</soapenv:Body>
</soapenv:Envelope>
 SOAP Structure
Envelope
• SOAP structure is very simple.
• 0 or 1 header elements
• 1 body element Header
• Envelop that wraps it all.
• Body contains XML payload.
• Headers are structured the same
way. Body
• Can contain additional payloads of
“metadata”
• Security information, quality of service, Message
etc. Payload
SOAP Schema Notes
• All of this is expressed formally in the SOAP <xs:complexType name="Envelope">
schema.
<xs:sequence>
• Which in turn derives from the SOAP Infoset
  <xs:element ref="tns:Header"
• XML on the right is taken directly from the minOccurs="0" />
SOAP schema.
  <xs:element ref="tns:Body"
• This just encodes the previously stated rules. minOccurs="1" />
• Also, note that the SOAP envelope can </xs:sequence>
contain other attributes.
• <anyAttribute> tag is the wildcard   <xs:anyAttribute namespace="##other"
processContents="lax" />
</xs:complexType>
SOAP Envelop
• The envelop is the root container of the SOAP message.
• Things to put in the envelop:
• Namespaces you will need.
• http://schemas.xmlsoap.org/soap/envelope is required, so that the recipient knows it has gotten
a SOAP message.
• Others as necessary
• Encoding rules (optional)
• Specific rules for deserializing the encoded SOAP data.
• More later on this.
• Header and body elements.
• Headers are optional, body is mandatory.
• Headers come first in the message, but we will look at the body first.
Brief Aside:WS-* is WS-<any>
• We’ll next look at the structure of the header and body.
• SOAP and many other web services use the <any> tag for
extensibility.
• And they use “lax” processing assertions.
• Allows for skipping over the SOAP payload.
• Needed in distributed messaging environments
 Options on <xsd:any/>
• The <xsd:any/> element takes the usual optional maxOccurs,
minOccurs attributes.
• Allows a namespace attribute taking one of the values:
• ##any (the default),
• ##other (any namespace except the target namespace),
• List of namespace names, optionally including either
##targetNamespace or ##local.
Controls what elements the wildcard matches, according to
namespace.
• It also allows a processContents attribute taking one of the values
strict, skip, lax (default strict), controlling the extent to which the
contents of the matched element are validated.
• SOAP is lax.
Lax
• “If the item, or any items among its children if it's an element
information item, has a uniquely determined declaration available, it
must be ·valid· with respect to that definition.”
• That is, ·validate· message payloads when you can, don't worry when
you can't.
SOAP Headers
• SOAP Body elements contain the primary message
contents.
• Headers are really just extension points where you can
include elements from other namespaces.
• i.e., headers can contain arbitrary XML.
• Headers may be processed independently of the body.
• Headers may optionally define encodingStyle.
• Headers may optionally have a “role” attribute
• Header entries may optionally have a “mustUnderstand”
attribute.
• mustUnderstand=1 means the message recipient must process
the header element.
• If mustUnderstand=0 or is missing, the header element is optional.
• Headers may also have a “relay” attribute.
Header Definition From SOAP Schema
<xs:element name="Header" type="tns:Header" />
<xs:complexType name="Header">
<xs:annotation>
<xs:documentation>Elements replacing the wildcard MUST be
namespace qualified, but can be in the
targetNamespace</xs:documentation>
  </xs:annotation>
<xs:sequence>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded" />
</xs:sequence>
  <xs:anyAttribute namespace="##other"
processContents="lax" />
  </xs:complexType>
Example Uses of Headers
• Security: WS-Security and SAML place additional security information
(like digital signatures and public keys) in the header.
• Quality of Service: SOAP headers can be used if we want to negotiate
particular qualities of service such as reliable message delivery and
transactions.
• Session State Support: Many services require several steps and so
will require maintenance of session state.
• Equivalent to cookies in HTTP.
• Put session identifier in the header.
Example Header from SOAP Primer
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<m:reservation xmlns:m=“http://my.example.com/"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d
</m:reference>
<m:dateAndTime>2001-11-29T13:20:00.000-05:00
</m:dateAndTime>
</m:reservation>
<n:passenger xmlns:n=“…"
env:role="http://www.w3.org/2003/05/soap-envelope/role/
next" env:mustUnderstand="true">
<n:name>Åke Jógvan Øyvind</n:name>
</n:passenger>
</env:Header>
Explanation of Header Example
• In general, we can import tags into the header from name spaces outside of
soap.
• <reservation/>, <reference/>, <dataAndTime/>,<passenger/>
• SOAP doesn’t need to worry to much about these.
• It is the node’s job to process these things.
• In this particular case, we may imagine an ongoing transaction for making an
airline reservation.
• Involves several steps and messages, so client must remind the server of this state
information when sending a message.
• The actual header content all comes from other namespaces.
• The role and mustUnderstand attributes are from SOAP.
Header Processing
• SOAP messages are allowed to pass through many intermediaries before
reaching their destination.
• Intermediary=some unspecified routing application.
• Imagine SOAP messages being passed through many distinct nodes.
• The final destination processes the body of the message.
• Headers are allowed to be processed independently of the body.
• May be processed by intermediaries.
• This allows an intermediary application to determine if it can process the body,
provide the required security, session, or reliability requirements, etc.
Roles, Understanding, and
Relays
Yes Yes
must Process
Role? Header
Understand

No
No

Yes No
Forward Relay? Remove
Header Header
Header Roles
• SOAP nodes may be assigned role designations.
• SOAP headers then specify which role or roles
should process.
• Standard SOAP roles:
• None: SOAP nodes MUST NOT act in this role.
• Next: Each SOAP intermediary and the ultimate SOAP
receiver MUST act in this role.
• UltimateReceiver: The ultimate receiver MUST act in
this role.
• In our example, all nodes must process the header
entries.
SOAP Body
• Body entries are really just placeholders for XML
from some other namespace.
• The body contains the XML message that you are
transmitting.
• It may also define encodingStyle, just as the
envelop.
• The message format is not specified by SOAP.
• The <Body></Body> tag pairs are just a way to notify
the recipient that the actual XML message is contained
therein.
• The recipient decides what to do with the message.
SOAP Body Element Definition
<xs:element name="Body" type="tns:Body" />
<xs:complexType name="Body">
<xs:sequence>
<xs:any namespace="##any"
processContents="lax" minOccurs="0“
maxOccurs="unbounded" />
  </xs:sequence>
  <xs:anyAttribute namespace="##other"
processContents="lax" />
</xs:complexType>
SOAP Body Example
<soapenv:Body>
<ns1:echo soapenv:encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/"
xmlns:ns1=
"http://.../axis/services/EchoService">
<in0 xsi:type="xsd:string">Hollow
World</in0>
</ns1:echo>
</soapenv:Body.
Example SOAP Body Details
• The <Body> tag is extended to include elements defined in our Echo
Service WSDL schema.
• This particular style is called RPC.
• Maps WSDL bindings to SOAP body elements.
• Guidelines will be given in next lecture.
• xsi-type is used to specify that the <in0> element takes a string value.
• This is data encoding
• Data encoding rules will also be examined in next lectures.
 When Things Go Wrong
• One of the precepts of distributed • HTTP Error Messages
computing is that things will go 403 Forbidden
wrong in any operational system. 404 Not Found
• Servers will fail, networks will go 405 Method Not Allowed
down, services will change or go 406 Not Acceptable
away.
407 Proxy Authentication Required
• Need a way to communicate 408 Request Time-Out
failures back to message 409 Conflict
originators. 410 Gone
• Consider HTTP faults 411 Length Required
412 Precondition Failed
• SOAP provides its own fault 413 Request Entity Too Large
communication mechanism. 414 Request-URL Too Large
• These may be in addition to HTTP 415 Unsupported Media Type
errors when we use SOAP over 500 Server Error
HTTP. 501 Not Implemented
502 Bad Gateway
503 Out of Resources
504 Gateway Time-Out
505 HTTP Version not supported
SOAP Fault Scenarios
• HTTP errors will take precedence.
• Involve message transmission problems.
• SOAP errors occur during the processing of the message.
• Faults can occur when
• You sent an improperly formatted message that the service can’t process (an integer instead of a string,
for example).
• There is a SOAP version mismatch
• You sent SOAP 1.2 and I understand SOAP 1.0
• You have a “must understand” header that can’t be understood.
• You failed to meet some required quality of service specified by a header.
• The server fails to correctly process the message.
• Each of these corresponds to a named fault value.
• It’s env:Sender on the next page.
Sample SOAP Fault From SOAP Primer
<env:Body>
<env:Fault>
<env:Code>
<env:Value>env:Sender</env:Value>
<env:Subcode>
<env:Value>rpc:BadArguments</env:Value>
</env:Subcode>
</env:Code>
<env:Reason>
<env:Text xml:lang="en-US">Processing error</env:Text>
</env:Reason>
<env:Detail>
<e:myFaultDetails> ...</e:myFaultDetails>
</env:Detail>
</env:Fault>
</env:Body>
Fault Structure from SOAP Schema
<xs:element name="Fault" type="tns:Fault" />
• Fault messages are included in <xs:complexType name="Fault“ final="extension">
the <body>. <xs:sequence>
  <xs:element name="Code“
• <Code> and <Reason> are type="tns:faultcode" />

required.   <xs:element name="Reason"

type="tns:faultreason" />
• <Node>,<Role>, and <Detail> are   <xs:element name="Node"

optional.  
type="xs:anyURI“ minOccurs="0" />
<xs:element name="Role"
type="xs:anyURI" minOccurs="0" />
  <xs:element name="Detail“
type="tns:detail" minOccurs="0" />
  </xs:sequence>
  </xs:complexType>
SOAP Fault Codes
• These are one of the required <xs:complexType
subelements of Faults. name="faultcode">
• They must contain one of the <xs:sequence>
standard fault code   <xs:element
enumerations (next slide).
name="Value"
• They may also contain subcodes.
• For more detailed error type="tns:faultcodeEnum" />
messages.   <xs:element name="Subcode"
type="tns:subcode"
minOccurs="0" />
  </xs:sequence>
</xs:complexType>
Enumerating Faults
• Fault codes must contain one of <xs:simpleType
the standard fault messages. name="faultcodeEnum">
• DataEncodingUnknown: you <xs:restriction
sent data encoded in some base="xs:QName">
format that I don’t understand.   <xs:enumeration
value="tns:DataEncodingUnkno
• MustUnderstand: I don’t wn" />
support this header.
  <xs:enumeration
• Receiver: message was correct, value="tns:MustUnderstand" />
but receiver could not process   <xs:enumeration
for some reason. value="tns:Receiver" />
• Sender: message was incorrectly   <xs:enumeration
formatted, or lacked required value="tns:Sender" />
additional information
• Couldn’t authenticate you   <xs:enumeration
value="tns:VersionMismatch" />
• VersionMismatch: I don’t   </xs:restriction>
support your version of SOAP.
</xs:simpleType>
Fault Subcodes
• Fault codes may <env:Code>
contain subcodes that <env:Value>env:Sender
refine the message.
</env:Value>
• Unlike Codes, subcodes
don’t have standard <env:Subcode>
values. <env:Value>rpc:Bad
• Instead, they can take Arguments
any QName value. </env:Value>
• This is an extensibility
</env:Subcode>
mechanism.
• Subcodes may contain </env:Code>
other subcodes.
 Fault Reasons
• This is intended to provide <xs:complexType name="faultreason">
human readable reasons for <xs:sequence>
the fault.   <xs:element name="Text"
type="tns:reasontext"
• The reason is just a simple minOccurs="1"
string determined by the maxOccurs="unbounded" />
implementer. </xs:sequence>
• For Axis, this is the Java </xs:complexType>
exception name. <xs:complexType name="reasontext">
• At least, for my version of <xs:simpleContent>
Axis. <xs:extension base="xs:string">
• We must also provide at least <xs:attribute ref="xml:lang"
one language. use="required" />
</xs:extension>
  </xs:simpleContent>
  </xs:complexType>
Optional Fault Elements
• Code and Reason are required.
“I Check
• Node, Role, and Detail are optional Source AuthZ”
• Node and Role are used in SOAP processing
steps that we have lightly covered.
• SOAP messages may go through several
Node 2
intermediaries.
• Nodes and roles are needed in case a fault
occurs in an intermediary.
• Return the URI of the node and role
• Details will be described. Node 1

“I Check
AuthN”
Dest.
Fault Detail
• A fault detail is just an extension element. <xs:complexType name="detail">
• Carries application specific information <xs:sequence>
• It can contain any number of elements of any   <xs:any namespace="##any"
type. processContents="lax" minOccurs="0"
• This is intended for the SOAP implementer to maxOccurs="unbounded" />
put in specific information.   </xs:sequence>
• You can define your own SOAP fault detail
schemas specific to your application.   <xs:anyAttribute namespace="##other"
processContents="lax" />
• Axis, for example, includes Java exception
stack traces. </xs:complexType>