Software Design and

Architecture

SOA and Web Services

Service-Oriented Systems

 The shift to service-oriented systems is being driven by the need to

integrate both applications and the business systems they support.
 This integration has traditionally been handled through the exchange
of paper documents such as quotes, invoices and orders.
 These traditional documents are still used today. The task of
integrating these business systems has changed little, but still
commonly done by sending these paper documents by post or fax,
and then re-keying their data once they arrive.
 The cost savings and efficiencies that come from getting rid of paper
and directly integrating computer-based business systems have been
obvious (and attractive) for many years, but have proved difficult to
attain for just about as long
Service-Oriented Systems

 The advent of the Internet and Web services has totally changed this
picture.
 The Internet now potentially connects every computer system in one
global network, letting businesses send documents electronically to
their partners and customers anywhere in the world, quickly and at
low cost.
 Web services provide application integration standards that are
implemented by every major vendor and are integral part of all
server platforms. The result of these developments is that business-
level integration has become relatively easy, inexpensive and
commonplace.
Service-Oriented Systems

 Figure shows an example of service oriented system.

 Customers see a single application that lets them place orders and
make payments. In reality this application consists of just a small
core of business logic provided by the retailer augmented by services
provided by business partners, and all running on a diverse mix of
platforms and middleware.
 Customers can access this application using the Web or they can run
client applications to use back-end services provided by the retailer’s
core application.
 These services can be used to support out-sourced order fulfillment
services provided to specialized retailers, letting them operate their
own on-line shop fronts and rely on the retailer for services such as
handling orders and accepting payments.
Principles of SOA

Boundaries are Explicit

 Services are independent applications, not just code that is bound into
program that can be called at almost no cost. Accessing a service requires
crossing over the boundaries that separate processes, and probably
traversing networks and doing user authentication.
 Every one of these boundaries (process, machine, trust) that has to be
crossed reduces performance, adds complexity and increases the chances
of failure. Importantly, they have to be consciously recognized and handled
within the design process.
 To address the concern, focus on simplicity, both in the specification of
services and in the supporting Web services standards. Good services have
simple interfaces and share as few abstractions and assumptions as possible
with their clients. This makes it easier for them to be understood.
Principles of SOA

Services are Autonomous

 Services are deployed onto a network, where they can be easily integrated
into any application that finds them useful. Services need know nothing
about client applications, and may accept incoming service requests from
anywhere, just as long as the request messages are correctly formatted and
meet specified security requirements.
 Services can be deployed and managed entirely independently of other
services and any possible client applications, and the owners of these
services can change their implementations or requirements at any time.
 All that clients know about a service is what messages that it will accept
and return, and this is the only dependency that exists between a client and
a service. Owners of services can change the implementation of a service
at will, just as long as currently valid messages are still accepted.
 Principles of SOA

Share Schemas and Contracts, not Implementations

 Services aren’t remote objects with inheritance, methods, or
components that support events, properties and stateful method calls.
 Services are just applications that receive and send messages. Clients
and services share nothing other than the definitions of these
messages, and certainly don’t share method code.
 All that an application needs to know about a service is its contract:
the structure (schema) of the messages it will accept and return, and
whether they have to be sent in any particular order.
 Client applications can use such a contract to build request messages
to send to a service, and services can use their schemas to validate
incoming messages and make sure they are correctly formatted.
Principles of SOA

Service Compatibility is Based on Policy

 Clients have to be completely compatible with the services they want
to use.
 Compatibility means not simply that clients are following the
specified message formats and exchange patterns, but also that they
comply with other important requirements, such as whether
messages should be encrypted or need to be tracked to ensure that
none have been lost in transit.
Web Services

 Web services are emerging to provide a systematic and extensible

framework for application-to-application interaction, built on top of
existing Web protocols and based on open XML standards.

 Say, for example, that you want to purchase a vacation package

using an online travel agent. To locate the best prices on airline
tickets, hotels, and rental cars, the agency will have to poll multiple
companies, each of which likely uses different, incompatible
applications for pricing and reservations.

 Web services aim to simplify this process by defining a standardized

mechanism to describe, locate, and communicate with online
applications.
Web Services

 The Web services framework is divided into three areas —

communication protocols, service descriptions, and service
discovery — and specifications are being developed for each.

 Discovery: UDDI, Universal Description, Discovery, and

Integration directory
 Description: WSDL, Web Services Description Language
 Communication: SOAP, Simple Object Access Protocol
 Security/Reliability/Transaction: WS-* standards
Communication: SOAP

 Given the Web’s intrinsically distributed and heterogeneous nature,

communication mechanisms must be platform-independent,
international, and secure.
 XML is now firmly established as the lingua franca for information
and data encoding for platform independence and
internationalization.
 Building a communication protocol using XML is thus a natural
answer for Web services
 SOAP is an XML-based protocol for messaging and remote
procedure calls (RPCs). It works on existing transports, such as
HTTP and SMTP.
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.

HTTP Client Server

SOAP   XML XML  
XML
Stub Skeleton
  SOAP SOAP  
POST…

Protocols HTTP HTTP

HTTP 1.1 200 OK
Folding client server
SOAP basic
mechanism
Description: WSDL

 For Web services, SOAP offers basic communication, but it does not
tell us what messages must be exchanged to successfully interact
with a service.
 That role is filled by WSDL, an XML format developed by IBM and
Microsoft to describe Web services as collections of communication
end points that can exchange certain messages.
 In other words, a WSDL document describes a Web service’s
interface and provides users with a point of contact.
Description: WSDL

A WSDL document is composed by two sections:

• An abstract interface section: it defines the vocabulary, the
message, and the interaction: data types of input/output data and
the operations supported at the end points.

• A deployment section -> it defines the service location and the

supported transport protocols
• what communication protocol to use (such as SOAP over
HTTP),
• how to accomplish individual service interactions over this
protocol, and
• where to terminate communication (the network address).
Discovery: UDDI

 The Universal Description, Discovery, and Integration specifications

offer users a systematic way to find service providers through a
centralized registry of services that is roughly equivalent to an
automated online “phone directory” of Web services.

 UDDI encodes three types of information about Web services:

 “white pages” information includes name and contact details;

 “yellow pages” information provides a categorization based on
business and service types; and
 “green pages” information includes technical data about the services.
WS-Security

Describes how to attach signature and encryption headers to

SOAP messages; how to attach security tokens such as X.509
certificates and Kerberos tickets

WS-Secure
Conversation WS-Federation WS-Authorization

WS-Policy WS-Trust WS-Privacy

WS-Security
SOAP
WS-Policy

Describes the capabilities and constraints of the security

and business policies on intermediaries and endpoints

WS-Secure
Conversation WS-Federation WS-Authorization

WS-Policy WS-Trust WS-Privacy

WS-Security
SOAP
WS-Trust

Framework for trust models that enables web services to

interoperate securely.

WS-Secure
Conversation WS-Federation WS-Authorization

WS-Policy WS-Trust WS-Privacy

WS-Security
SOAP
WS-Privacy

Model for how web services and requesters state privacy

preferences and organizational privacy practice statements

WS-Secure
Conversation WS-Federation WS-Authorization

WS-Policy WS-Trust WS-Privacy

WS-Security
SOAP
WS-SecureConversation

Manage and authenticate message exchanges between parties,

including security context exchange and establishing and deriving
session keys

WS-Secure
Conversation WS-Federation WS-Authorization

WS-Policy WS-Trust WS-Privacy

WS-Security
SOAP
WS-Federation

Manage and broker trust relationships in a heterogeneous

federated environment, including support for federated identities.

WS-Secure
Conversation WS-Federation WS-Authorization

WS-Policy WS-Trust WS-Privacy

WS-Security
SOAP
WS-Authorization

Manage authorization data and authorization policy.

WS-Secure
Conversation WS-Federation WS-Authorization

WS-Policy WS-Trust WS-Privacy

WS-Security
SOAP