Contemporary Architectural and Development Practices in Web

www.neresc.ac.ukwww.neresc.ac.uk

Architecting Secure, Reliable, and Transacted Service Oriented Architecture using Web Services

Architecting Secure, Reliable, and Transacted Service Oriented Architecture using Web Services

Dr. Jim Webberhttp://jim.webber.name

[email protected]

Dr. Jim Webberhttp://jim.webber.name

[email protected]


UK E-Science Programme

‘e-Science is about global collaboration in key areas of science and the next generation of infrastructure that will enable it.’

• £250 (~AU$600) million, 5 year programme• Split between application areas and infrastructure

• Bioinformatics, astronomy,etc• “Grid” computing, Internet-scale computing, etc

• My involvement: Web Services standards, architecture, and development


Roadmap

• Historical Perspective• What is a Web Service?• Evolution of Web Service

• Message-Orientation• Architecture• Protocol• Implementation

• Enterprise Issues• Scalability• Dependability• Consistency

• Summary• Q&A


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 oriented-interface whose messages are in SOAP format.

• SOAP is the critical differentiator.• It is what differentiates a Web

Service from other kinds of services (e.g. OS services).

• SOAP is the lowest point in the WS stack.

SOAP Messages

Network

SOAP message processor

Application


Remote object method invocations

Network

Client Application

Client application objects and proxies Server objects and

stubs

Serverapplication

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.

Some otherwise brightpeople still think

of Web Services in this way


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.


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.


A Message-Oriented Architectural Style

• 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• Quality of Service Protocols, defined by the• WS-* specifications

• 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.


Canonical Web Services-based Application

Message requests (and perhaps responses) that do not relate to a specific object


Purchase ordersystem Purchase order

application


Purchase order

service

WSDL

Contract about

the form

at of

messages that

c

an be exchanged

Example: ServiceA sends ServiceB a MessageX. ServiceB responds with a MessageY or a MessageZ depending on the content of the MessageX it received.


Architecture

• 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

Service

Ad

min

istr

ativ

e

do

ma

in

Service

Service

Service

Administrative domain

Service

Service Ad

min

istrative

d

om

ain

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

Not validated

WSDL contract


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 part of 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.


SOAP + WS-Addressing

http tcp jms

logical point-to-point SOAP message transfer

intermediate intermediate

Web Service

transport

Web Service

transport


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.


Deriving Contracts

• Protocol is supported by contracts• Form and pattern of messages

exchanged by a Web Service• Note: contracts rather than interfaces

• Interface is an overloaded term that implies type information

• No type information in Web Services, only schema

• Derive contract by examining SOAP messages

• WSDL contract describes messages and message exchanges that the service will participate in.

<wsdl:definitions> <wsdl:types> ... </wsdl: types> <wsdl: interfaces> ... </wsdl: interfaces> <wsdl:binding> ... </wsdl:binding> <wsdl:service> ... </wsdl:service></wsdl:definitions>

Pro

toco

lC

ontr

act


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

2. 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


WSDL Contracts are 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 is retired.• Remember WSDL is immutable

• 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.


Protocol: Key WS-* Specs

• In addition to the architecture specs:• Metadata

• WSDL, WS-Policy, WS-MetadataExchange

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

• Reliable Messaging• WS-ReliableMessaging

• Transactions• WS-AT/BA or WS-TransactionManagement

Mes

sagi

ngQ

ualit

y of

ser

vice

Tra

nsfe

r

Addressing, notification, enumeration, etc.(WS-Addressing, WS-MessageDelivery, WS-Eventing, WS-

Notification, WS-Enumeration)

Met

adat

a(W

SD

L, P

olic

y)

Sec

urity

(WS

-Sec

urity

, WS

-Tru

st, W

S-

Sec

ureC

onve

rsat

ion

)

Rel

iabl

e m

essa

ging

(WS

-Rel

iabl

eMes

sagi

ng)

Tra

nsac

tions

(WS

-AT

/BA

, WS

-T

rans

actio

nMan

agem

ent)

SOAP


Implementation

• The internal architecture of a service is relatively mundane.

• The layering of messaging, logic, and state is similar to the classic N-tiered architecture.

• The message processing layer is interesting though... B

PE

L, J

ava,

.NE

T

serv

ice

logi

c

Databases

Humans

ProgramsComputational resources

Devices

reso

urce

s

<env:Envelope> <env:Header> ... </env:header> <env:Body> ... </env:Body></env:Envelope>

mes

sage

pro

cess

ing

SO

AP

, WS

DL,

and

ot

her

WS

-* p

roto

cols

pr

oces

sing

tran

spor

t

SOAP messages

TCP, UDP, HTTP, SMTP, JMS, etc.


Message Processing Layer

• Deals with the conversion of messages on the wire (in SOAP format) to programmatic abstractions.

• Does not try to abstract message exchanges into RPC

• Presents a truthful picture of the underlying message exchanges to the service logic• Allows the service logic to be

tolerant of the underlying messaging infrastructure

• Latent, lossy, asynchronous etc

• Messages are the abstraction that the service logic binds to, not other services• Loose coupling!

mes

sage

pro

cess

ing

tran

spor

tbody

head

er

SO

AP

Env

elop

e <wsdl> <interface> … </interface></wsdl>

<wsdl> <interface> … </interface></wsdl> bo

dyhe

ader

SO

AP

Env

elop

e <wsdl> <interface> … </interface></wsdl>

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

incoming SOAP message

outgoing SOAP message

serv

ice

logi

c

messageobject

messageobject

Network

Client Application

Client application objects and proxies Server objects and

stubs

Serverapplication

WSDL


Today’s SOAP API

public class GameServiceStub

{

public void StartGame(){...}

public GridPos Move(GridPos gp)

{...}

// Other remote methods omitted for brevity

}


Typical Message-Oriented API

public interface IMessage{...}

public class StartGameMessage : IMessage{...}

// Other messages omitted for brevity

public class GameMessagingLayer{

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

/* Inbound messages */

public event MoveMessageReceivedDelegate MoveMessageArrived;public event StartGameMessageReceivedDelegate StartGameMessageArrived;

// Other messaging events omitted for brevity}


Service Logic

• The arrival of a message at a service causes some processing to occur• From the ProcessMessage 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, message integrity) are out of scope for service implementation• They are administrative tasks (mostly!).


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.


Enterprise Issues: 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

http tcp jms

logical point-to-point SOAP message transfer

resources

message processing

Web Service logic

transport

resources

message processing

Web Service logic

transport

intermediate intermediate


Enterprise Issues: 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


Enterprise Issues: Reliable Messaging

• The underlying protocols still have to be exposed to our Web Service implementations• Implementations have to be architected to deal with failures

in messaging

• Should all processes should be idempotent?• Dependability characteristics of the Web Service

• Mission critical – every operation has to be idempotent.• At some point RM will fail. Without idempotent operations you are in a

world of pain

• Somewhat critical – take a chance?• Make common or particularly important routines idempotent

• Uncritical• Leave it to the underlying RM protocol!

ComplexBig $$$

investmentSomewhat complex

Lower $$$Easy (if nothing goes wrong)

Cheap!


Enterprise Issues: Scalability

• Stateless services scale easily.

• Add more hardware, deploy services.

• Leave state management to underlying enterprise-grade Database.• DB guys know how to

manage state in a dependable manner

Server Farm

Data Tier


Enterprise Issues: 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!


Server Farm

State Sucks

Unknown Conversation

Multi-Protocol Session-Affinity Aware Router$$$


Server Farm

State Still Sucks, but it’s the DBA’s Problem

Data Tier

El-Cheapo Round-Robin Router


Enterprise Issues: 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


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


Got Question

s?

Got Question

s?