INTE 462

WEB BASED INFORMATION SYSTEMS

Lecture 7: Web Services and Service Oriented

Architecture

Prof S Karume
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
description Operatio
n description

One-way, Component
conversational,
many-to-many
 Service Oriented Architectures:
Components
The Service: Whereas a web service is an interface described by a
service description, its implementation is the service. A service is a
software module deployed on network accessible platforms provided by
the service provider. It exists to be invoked by or to interact with a service
requestor. It may also function as a requestor, using other web services in
its implementation.
The Service Description: The service description contains the details of
the interface and implementation of the service. This includes its data
types, operations, binding information, and network location. It could also
include categorization and other meta data to facilitate discovery and
utilization by requestors. The complete description may be realized as a
set of XML description documents. The service description may be
published to a requestor directly or to a discovery agency.
 Service Oriented Architectures:
Components
Publish: In order to be accessible, a service needs to publish its
description such that the requestor can subsequently find it. Where it
is published can vary depending upon the requirements of the
application (see Service Publication Stack discussion for more
details)
Find: In the find operation, the service requestor retrieves a service
description directly or queries the registry for the type of service
required (see Service Discovery for more details). The find operation
may be involved in two different lifecycle phases for the service
requestor: at design time in order to retrieve the service's interface
description for program development, and at runtime in order to
retrieve the service's binding and location description for invocation.
 Service Oriented Architectures:
Components
Interact: Eventually, a service needs to be invoked. In the interact
operation the service requestor invokes or initiates an interaction
with the service at runtime using the binding details in the service
description to locate, contact, and invoke the service. Examples of
the interaction include: single message one way, broadcast from
requester to many services, a multi message conversation, or a
business process. Any of these types of interactions can be
synchronous or asynchronous.
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
technologies
 The Complete Web Services "Stack"

Independent stacks assembled into a single stack where

each additional layer builds upon the capabilities provided
by those below it. The vertical towers represent the variety
of over arching concerns that must be addressed at every
level of each of the stacks.
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 Wire Stack
Transport : Because of its ubiquity, HTTP is the de facto standard network
protocol for Internet-available web services. Other Internet protocols may be
supported including SMTP and FTP.

Packaging : Packaging, represents the technologies that may be used to

package information being exchanged.

XML has been broadly adopted as the basis for Web service message packaging
protocols and SOAP is currently the de facto standard for XML messaging.

Extensions : Provides a framework that allows additional information to be

attached to Web service messages representing a variety of additional concerns;
such as context, routing, policy, etc. SOAP defines a mechanism to incorporate
orthogonal extensions (also known as features) to the message in the form of
headers and encoding rules.
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 Description Stack
WSDL is an XML document format for describing Web
services as a set of endpoints operating on messages
containing either document-oriented or procedure-
oriented (RPC) messages. The operations and
messages are described abstractly, and then bound to a
concrete network protocol and message format to define
an endpoint. Related concrete endpoints may be
combined into services.
Interface Description maps to the Abstract interface in
WSDL, explained later.
Implementation Description maps to the Deployment
section in WSDL, explained later.
 The Description Stack
Policy would be used to describe or point to
documents describing the owning business,
associated products, keywords, taxonomies for the
service, security policies, quality of service attributes,
etc. Policy may be used by the over-arching
concerns: security, quality of service, and
management; as well as higher layers of the
description stack.
The composition and orchestration layers describe
how service-to-service communications,
collaborations, and flows are performed.
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

Simple Object Access
Protocol
A SOAP runtime engine basically adds a XML
envelope to an existing XML document

SOAP Envelope <soap:Envelope>

<soap:Header>
SOAP Header <axis:SessionKey>
SDHH37TYEW7R7
Communicatio </axis:SessionKey>
n Info </soap:Header>
Example <soap:Body>
<GetPrice>
SOAP Body <Item>Apples</Item>
</GetPrice>
</soap:Body>
XML </soap:Envelope>
Document

Document Container Session, Authentication,

Routing, Security
SOAP Encoding
Dealing directly with XML messages is not easy.
Therefore, SOAP provides a “RPC emulation”
technology
The result: developers work with web services like
with traditional RPC (e.g. CORBA,DCOM,DCE)

The “RPC emulation” is named SOAP encoding.

Fundamentally it is a set of rules to map a

procedure invocation to a XML document.
SOAP Encoding
The rules:
 method name -> first level element in the
SOAP Body
 arguments identifiers -> second level
elements
 arguments values -> third level elements
 arguments types -> attribute xsi:type
ClockService.getTime(location="USA");
Service Request

<soap:Body>
<getTime>
<location xsi:type="xsd:string">USA</path>
</getTime>
</soap:Body>
Web Service Description
Language
WSDL is a standard format to describe a Web
Service (description stack)

A WSDL document is composed by two sections:

 An abstract interface section -> like in
traditional IDL, it defines the signatures of
procedures (RPC-style) or messages
(document-style)
 A deployment section -> it defines the service
location and the supported transport protocols

Fundamentally a client uses the WSDL to create

the stub or to dinamically decode messages.
Web Service Introspection
Language
WSIL and UDDI are the standard way to search
Web Services. (Discovery stack)
WSIL is the decentralized approach.

Fundamentally a WSIL document contains a

directory of the Web Services deployed on a
server.
It is anologous to the index.html document for
web pages.
In the future, specific crawlers will browse the
Internet looking for WSIL documents, like
Google does today for web pages.
Web Service Introspection
Language
<inspection>
<abstract>Acme Industries Public Web Services</abstract>
<service>
<name>Store Finder Service</name>
<abstract>
A service to perform a geographical search of Acme
stores.
</abstract>
<description
location="http://example.org/services/storefinder.wsdl"/>
</service>
<link location="http://example.org/services/ecommerce.wsil"/>
</inspection>

Service name
Link to an other WSIL page
Service location and description
UDDI
UDDI is a complimentary approach for searching
based on a centralized repository.

The repository is an “electronic yellow pages” for

firms that offer web services online. Besides the
names of services and their WSDL descriptors,
firms can add a description of their business,
phone numbers, addresses...

UDDI repositories are offered by many agencies -

e.g. IBM, Microsoft and HP.
References
J2EE: A platform of choice for Web Services.
http://www.sun.it/eventi/codecamps_2002/pdf/j2ee_a_platfo
rm_of_choice_for_web_services.pdf
XML in J2EE Platform.
http://www.sun.it/eventi/codecamps_2002/pdf/xml_in_j2ee_
platform.pdf
A Busy Developers Guide to WSDL 1.1
http://radio.weblogs.com/0101679/stories/2002/02/15/aBus
yDevelopersGuideToWsdl11.html
A Busy Developer's Guide to SOAP 1.1 .
http://www.soapware.org/bdg
A Young Person's Guide to The Simple Object Access Protocol.
http://msdn.microsoft.com/msdnmag/issues/0300/soap/soap
.asp
An XML Overview Towards Understanding SOAP.
http://msdn.microsoft.com/library/en-
us/dnwebsrv/html/xmloverchap2.asp
References
Deploying Web Services on Java 2, Enterprise Edition.
http://developer.java.sun.com/developer/technicalArticles/We
bServices/wsj2ee/
The Python Web services developer. http://www-
106.ibm.com/developerworks/webservices/library/ws-
pyth1.html
Understanding WSDL in a UDDI registry. http://www-
106.ibm.com/developerworks/webservices/library/ws-wsdl/
Dot-com builder overview of WSDL.
http://dcb.sun.com/practices/webservices/overviews/overvie
w_wsdl.jsp
Getting Started with JAX-RPC.
http://developer.java.sun.com/developer/technicalArticles/We
bServices/getstartjaxrpc/
Introduction to WSDL.
http://www.devxpert.com/tutors/wsdl/wsdl.asp
References
Integrating SOAP into ebXML.
http://www.itworld.com/AppDev/1472/ITW010404ebXML/
Top ten FAQs for Web Services.
http://www.oreillynet.com/pub/a/webservices/2002/02/12/we
bservicefaqs.html
Web Services Introduction.
http://www.perfectxml.com/WebSvc1.asp
SOAP archives. http://www.soap.org/archive.iphtml
SOAP Introduction.
http://www.w3schools.com/soap/soap_intro.asp
Web Services Description Language (WSDL) Explained.
http://msdn.microsoft.com/library/en-
us/dnwebsrv/html/wsdlexplained.asp
WSDL Interop Adventures.
http://www.byte.com/documents/s=7031/byt1015007393289
/0304_udell.html
Java Web Services Tutorial.
http://java.sun.com/webservices/docs/1.0/tutorial/doc/JavaW
STutorialTOC.html