Get SOAphisticated with Web Services

Jim Webber
SOA Practice Lead
ThoughtWorks
ThoughtWorks Overview

• Enterprise systems consultancy serving Global 1000

companies
• ~700 employees
• Growing at 50% per year
• Seven countries
• USA, UK, India, Canada, Australia, China
• Specialists in Agile software methods, enterprise systems
• .Net
• J2EE
• “esoteric stuff”

2
Roadmap

• Historical Perspective
• What is a Web Service?
• Evolution of Web Services
• Message-Orientation: The MEST Architectural Style
• Architecture
• Protocol
• Implementation
• Enterprise Issues
• Scalability
• Dependability
• Consistency
• Moving to SOA
• Summary
• Q&A
3
What is a Web Service?

• A service is piece of
application logic exposing
message-oriented
interface.
• Any scale from inter-process
to Internet
• A Web Service is a system
which exposes a message Application
oriented-interface whose
messages are in SOAP
format. SOAP message
• SOAP is the critical processor

differentiator.
• It is what differentiates a
Web Service from other SOAP Messages
kinds of services (e.g. OS
services).
• SOAP is the lowest point in
the WS stack. Network

4
In the Beginning...

• In the old days we used SOAP-RPC

• RPC style SOAP plus encoding rules for serialising and
deserialising application-level objects into messages.
• A kind of XML RPC
• Similar to RMI etc but without all the good stuff like
garbage collection, security, and performance.

This is not SOA

Remote object method

invocations
5
Network
RPC with Documents

• The community learned that SOAP RPC was pretty

awful for interoperability
• Different implementations interpreted the encoding rules
differently.
• Document-oriented SOAP (doc/literal) solved (or at
least moved) interoperability problems.
• But left the inappropriate object-like model in place.
• RPC with documents is the mainstream of Web
Services today.
• It is not the future of Web Services, just a point on
the learning curve.

6
The RESTifarian Jihad

• Seeing that the Web was good and that RPC was bad, the
RESTifarians waged war on the Web Services community.
• REST-ful services have a uniform API and exchange
messages using that API.
• The API is HTTP-like and allows messages to be sent
(POST) and responses to be solicited (GET)
• Along with PUT and DELETE etc.
• Unfortunately RESTful semantics aren’t always mappable
onto protocols other than HTTP.
• What’s SMTP GET?
• Imposing an API – even a uniform API – is too constraining.
• But the notion of exchanging messages is correct.

7
Web Service Architecture

• Today’s Web Services architecture is based on the

notion of:
• Services, which exchange
• SOAP Messages, which are constrained in form and
exchange pattern by
• WSDL, which may also advertise
• Or SSDL!
• Quality of Service Protocols, defined by the
• WS-* specifications

8
Message-Orientation

• The action taken in response to receiving a

message is up to the recipient
• At the highest architectural level, a message exchange is
simply a transfer of information from sender to receiver.
• The business semantics of a message exchange are
service-specific.

• Transfer of messages is transport protocol

independent
• The means of transporting a message carries no
semantics
• I.e. POSTing or GETting does not change the semantics of a
message.
9
A Web Services Application

Purchase order
system Purchase order
application

SOAP message SOAP message

processor processor

SOAP Messages
Example: ServiceA sends ServiceB a MessageX.
ServiceB responds with a MessageY or a
MessageZ depending on the content of the
10
Architectural Tenets

• Boundaries are explicit

• The boundaries of a service are well-defined when they
are incorporated into a distributed application. Other
services do not see the internal workings,
implementation details, or resource representations of a
service.
• Services are autonomous
• Service implementations are developed and evolve
independently from one another.
• Services share schema and contract, not
classes
• In service-oriented architectures, no single set of
abstractions (classes) spans an entire application.
Services share schemas (contracts) that define the
structure of the information that they exchange, not
information about their underlying type systems.
11
More Architectural Tenets

• Policies determine service compatibility

• Services interact with one another only after it has been
determined – based on policy assertions – that they can
meaningfully exchange information.

See: D. Box, Service-Oriented Architecture and Programming (SOAP)

http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20030827SOAPDB/manifest

http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20030902SOAPDB/manifest

12
SOA and Web Services Aims

• Integration
• Reuse
• Agility
• Lower cost of development/ownership for applications

• No such thing as a free lunch

• Have to architect and implement to achieve these features

13
High Level Architecture

Administrative
domain

Service

Service
Administrative

Service

Administrative
domain

domain
Service

Service
Service

<wsdl>
<types /> Not validated
<definitions>
...
</definitions>
<interface>
…
</interface>
</wsdl>

WSDL contract
14
High Level Architecture Tasks

• Standard enterprise architecture

• Tool support: Whiteboard, PowerPoint, and coffee
• Identify functional and non-functional requirements
• Identify existing Web Services as candidates for
inclusion in the system
• Those that satisfy the functional and non-functional
requirements
• Identify what functionality you need to deploy
yourself.
• Identify the interactions between Web Services

15
Architecture: Key WS-* Specs

• SOAP
• The lowest part of the Web Services stack.
• Consider messages in terms of:
• Content for functional requirements;
• Content for non-functional requirements.
• SOAP provides a transfer mechanism that combines both:
• SOAP body for transferring information pertinent to the functional
requirements;
• SOAP headers for transferring out-of-band information to address non-
functional requirements.

• WS-Addressing
• Remember - SOAP is the lowest layer in the WS stack!
• It is the transfer mechanism for Web Services
• Everything else is transport.
• WS-Addressing allows SOAP messages to be routed round a
system irrespective of the underlying transport.

16
SOAP + WS-Addressing

Web Service logical point-to-point SOAP message transfer Web Service

http tcp jms transport

transport
intermediate intermediate

17
Protocol

• Each Web Service we develop has to deal with message

exchanges
• Those that it requires to expose its own functionality;
• Those that the Web Services it uses to interact with other Web
Services;
• Message exchanges pertaining to the QoS protocols it supports.

• Protocol demolishes the idea of Web Services as entities

which are “invoked.”
• If you insist on having an operation to invoke, then “invoke” the
ProcessMessage operation.

• ProcessMessage is abstract, semantics:

• A transfer of a message from sender to receiver; and
• A request to process the received message.

• The MEST architectural style

18
Deriving Contracts

• Protocol is supported by contracts

• Form and pattern of messages exchanged
by a Web Service

Protocol
• Note: contracts rather than interfaces
• Interface is an overloaded term that implies
type information
• No type information in Web Services, only
schematised messages

• Derive contract by examining SOAP <wsdl:definitions >

message exchanges <wsdl:types>

...
</wsdl:types>
<wsdl:interfaces>

Contract
...
</wsdl:interfaces>
<wsdl:binding>

• WSDL contract describes messages ...

</wsdl:binding>

and message exchanges that the

<wsdl:service>
...
</wsdl:service>

service will participate in. </wsdl:definitions >

• SSDL a better alternative?

19
Contract and Policy

• Contracts are binding and immutable

• The associated service cannot violate the terms it sets out in the contract.
• Consumers’ only information about the service is its contract.

• Serves two purposes:

1. Facilitates interoperability with other services;
• Advertises message exchanges, and possibly QoS support/requirements
1. Decouples service implementation from consumers.
• Hides the implementation of a service behind a message-oriented façade.

• Policy declarations determine the QoS protocols used for an interaction.

• Policies can be determined statically or dynamically
• Static policies can be attached to the service contract
• Dynamically created policies communicated to service consumers during
interactions with the service

20
WSDL is not Object IDL

• WSDL contracts should not “leak” information about their

services.
Anything in declared a WSDL contract
must be preserved until the associated
• Web Service
Remember isimmutable
WSDL is retired.
• Service implementations are not
• They will be subject to maintenance, bug fixes etc
• Use WSDL to shield your service implementation from its
consumers.
• Expose only messages and message exchanges.
• WSDL isn’t Object IDL.
• A WSDL contract betrays no type information and must not expose the
type system of the underlying implementation.
21
Protocol: Key WS-* Specs

(WS-Security, WS-Trust, WS-

• In addition to the architecture specs:

TransactionManagement)
(WS-ReliableMessaging)
SecureConversation)

Reliable messaging
• Metadata

Quality of service
(WS-AT/BA, WS-
Transactions
• WSDL, WS-Policy, WS-MetadataExchange
Security
(WSDL, Policy)

• Security
Metadata

• WS-Security, WS-Trust, WS-SecureConversation

• Reliable Messaging
• WS-ReliableMessaging
• Transactions

Messaging
Addressing, notification, enumeration, etc.
• WS-AT/BA or WS-TransactionManagement
(WS-Addressing, WS-MessageDelivery, WS-Eventing, WS-
Notification, WS-Enumeration)

Transfer
SOAP

22
Implementation

Devices

resources
• The internal architecture Humans

of a service is relatively Programs

mundane. Databases Computational resources

• The layering of

BPEL, Java, .NET

service logic
messaging, logic, and
state is similar to the
classic N-tiered
architecture.

other WS-* protocols

message processing
SOAP, WSDL, and
<env:Envelope>

• The message processing <env:Header>

processing
...
</env:header>
layer is interesting <env:Body>
...

though... </env:Body>
</env:Envelope>

SOAP messages

sport
23
Message Processing Layer

• Deals with the conversion of

messages on the wire (in
SOAP format) to
programmatic abstractions.
• Does not try to abstract message
object
message
object
message exchanges into
RPC
• Presents a truthful picture of Client Application

the underlying message outgoing SOAP message

Server objects and

exchanges to the service stubs

logic
• Allows the service logic to be incoming SOAP message
W SD L

tolerant of the underlying

messaging infrastructure <wsdl> <wsdl>

header

header
SOAP Envelope

SOAP Envelope
<interface> <interface>

• Latent, lossy, asynchronous

… …
Network
</interface> </interface>

etc
</wsdl> </wsdl>

• Messages are the <wsdl> <wsdl>

body

body
<interface> <interface>
… …

abstraction that the service </interface>

</wsdl>
</interface>
</wsdl>

logic binds to, not other

services
• Loose coupling!
24
Today’s SOAP API

public class GameServiceStub

{
public void StartGame()
{...}
public GridPos Move(GridPos gp)
{...}

// Other remote methods omitted for brevity

}

25
A Message-Oriented API

public interface IMessage

{...}

public class StartGameMessage : IMessage

{...}

// Other messages omitted for brevity

public class GameMessagingLayer

{
/* Outbound messages */
public void SendMessage(IMessage msg)
{...}

/* Inbound messages */

public event MoveMessageReceivedDelegate MoveMessageArrived;

public event StartGameMessageReceivedDelegate
StartGameMessageArrived;

// Other messaging events omitted for brevity

}

26
Service Logic

• The arrival of a message at a service causes some

processing to occur
• From the MEST architectural style
• Service implementation is stateless
• All the information it needs to perform a specific task is
contained with the message that initiates that task, is
computed, or is contained in the persistent data storage
tier.
• c.f. architecture of the web.
• Non-functional requirements (e.g. security,
transactions) set context for message processing
• But are orthogonal to the business logic
27
Implementation: Some Key WS-
* Specs
• Some WS-* specs are designed to be driven by service
implementations directly:
• WS-Eventing
• multicast
• WS-Enumeration
• Streaming/data cursor
• WS-Transfer
• CRUD semantics

• WS-BPEL is an alternative means of implementing services

• Workflow expressed in terms of Web Services and messages

• If these make Web Service development easier, use them

• If not, then ignore them

28
Enterprise Issues

• Web Services are not an enterprise platform in the

traditional sense
• Though an individual Web Service will usually be deployed onto
such a platform (J2EE app server, .Net)

• Just a collection of specs and implementations

• messages, message exchange patterns, and semantics

• Cannot rely on the infrastructure to manage dependability

characteristics
• Security, reliable message transfer, transactionality, scalability etc

• Need to understand how the WS-* specs can help

• And how then cannot help.

29
Security

• WS-Security does not make your Web Services secure!

• It can help with message-level security

• Privacy
• Integrity
• Non-repudiation

• HTTPS is not sufficient

• Messages traverse arbitrary networks
• Point to point mechanisms are difficult to scale

• WS-Security elements are embedded within the message

• And easily traverse arbitrary networks

30
Secure Message Transfer

resources resources

Web Service logic Web Service logic

message processing logical point -to-point SOAP message transfer message processing

http tcp jms

transport transport
intermediate intermediate

31
Reliable Messaging

• In theory, reliable messaging is transparent to the

architecture

• Reliable messaging gives us at most once/exactly once

notification of delivery of messages
• No indication whatsoever of whether a message was processed

• Messages can go missing or be duplicated, the protocol will

detect that
• Not in a catastrophic failure case

• Can rely on the underlying protocol to smooth out the lumps

in a large-scale Web Service networks
• No such thing as a free lunch
• The lumps will always be there, RM can only reduce their frequency
and size

32
Reliable Messaging

• The underlying protocols still have to be exposed to

our Web Service implementations
• Implementations
Complex have to be architected to deal with
failures in messaging
Big $$$
• Should all processes should be idempotent?
investment
Somewhat
• Dependability characteristics of the Web Service
• MissionEasy complex
critical
(if –nothing
every operation has to be idempotent.
• At someLower
point RM$$$
will fail. Without idempotent operations you
goes wrong)
are in a world of pain
Cheap!
• Somewhat critical – take a chance?
• Make common or particularly important routines idempotent
• Uncritical
• Leave it to the underlying RM protocol!

33
Scalability

Data Tier

• Stateless services scale

easily. Server Farm

• Add more hardware,

deploy services.
• Leave state management
to underlying enterprise-
grade Database.
• DB guys know how to
manage state in a
dependable manner

34
Dependability

• Statelessness makes failover fault tolerance trivial

• Well mostly...

• If it can be detected that a Web Service or a host server has

crashed, simply route messages to live Web Services on
live hosts
• Standard systems management stuff for the hardware
• WS-Management may help for Web Services

• Stateful services will cause you pain

• Do you really want to have to build state migration capabilities into
your WS code?
• Avoid WS-RF and dependent toolkits/specs.

35
State Sucks

Server Farm

Unknown Conversation

$$$ Multi-Protocol Session-Affinity Aware Router

36
State is the DBA’s Problem!

Data Tier

Server Farm

Inexpensive Round-Robin Router

37
Consistency

• Never expose lockable resources outside your administrative

domain
• Denial of service attacks possible otherwise
• Cannot have consistent data all the time.
• Have to be satisfied with snapshots of data
• Only the administrative domain that owns the data has the most up-to-
date information
• Web Services transactions don’t help
• They just keep logical processing of messages in sync.
• Design applications with the understanding of the “age” of the
data in mind
• See: Pat Helland’s “Data on the Inside vs. Data on the Outside” for in-
depth analysis
• http://msdn.microsoft.com/architecture/overview/default.aspx?
pull=/library/en-us/dnbda/html/dataoutsideinside.asp
38
SOA Today

• Applications, objects, frameworks

• Best practice – encapsulate and expose as service
• Non-invasive

39
Tomorrow

• Individual applications are internally

service-oriented
• Indigo
• Design individual applications to
expose useful services
• Factor applications to facilitate
replacement or outsourcing of
functional units

40
The Future

• Networks of services are the norm

• Applications are software entities which orchestrate service
interactions
• With complex dependability requirements...
• Applications are services too!

41
Summary

• Web Services are about document exchanges, not APIs or interfaces

• Messages are the source of truth, use them to decouple your service
from its consumers

• Be careful what you advertise in WSDL, you’ll have to carry it forever

• Three architectural views:

• Global architecture (Service-Oriented)
• Protocol (Message-Oriented)
• Implementation (Event driven)

• Web Service interactions are stateless

• WS-* can only get you so far

42
Questions?