Governing REST-style SOA

Benjamin Carlyle

Overview

The Open Group Governance Reference Model

The REST Architectural Style / REST-Style SOA

Governing a REST-style SOA Technology, Processes, and Organisation

Governance Walk-through

SOA Governance Reference Model

Processes

Organisational Structures

Enabling Technologies

Where does REST fit?Does REST fit?

The Open Group – SOA Governance Framework – C093

REST-style SOA

Full compliance with SOA Principles

Full compliance with REST constraints

Impacts: Major Impact on Technology

Impact on Processes

Some Organisational Impact

REST Technology Impact

Uniform Contract and Stateless Constraints

Uniform Contract ConstraintService-specific Contract

Split into fine-grained Uniform Contract endpoints

Transition from design time to runtime discovery

Service<<service>>

+getInvoice(invoice id): InvoiceType+getCustomer(customer id): CustomerType

Contract

+getInvoice(invoice id): InvoiceType+getCustomer(customer id): CustomerType

Consumer

Service<<service>>

+getInvoice(invoice id): InvoiceType+getCustomer(customer id): CustomerTypecustomer/ {customer-id}

+get(acceptable types): Representation

Consumerinvoice/ {invoice-id}

+get(acceptable types): Representation

Stateless Constraint

Stateless between requests State deferred back to service consumer

No publish/subscribe No pessimistic lock or transaction over multiple

requests

Effective scaling and fault recovery at cost of useful communication patterns

Possible reduced service composability

REST Process Impact

New and modified processes

SOA Governance Framework Processes – Major Processes

• Service Portfolio Management• Configuration Control of inventory

• Service Lifecycle• Configuration Control for each service

• Solution Portfolio Management• Configuration Control of SOA-based solution set

• Solution Lifecycle• Configuration Control of each solution

SOA Governance Framework Service Portfolio Sub-processes

• New Process• Uniform Contract Change Management

• Unaffected• Service Portfolio Planning• Service Identification and Business Justification• Service Ownership, Service Funding

• Impacted by split of service-specific contract• Service Change Management

REST Organisational Impact

Uniform Contract Governance within your organization

Bodies to Control Uniform Contract

New standards bodies to support Uniform Contract … or reuse existing contract guidelines bodies

Control shifted from service contract owners to owners of Uniform Contract

Bodies consist of service contract owners as well as centralised governance representatives

Uniform Contract Change Management

Objectives, overview, and walkthrough

REST Constraints

Client/Server → Consumer/Service

Services are stateless between requests

Cache – Implicit or Explicit in responses

Uniform Interface → Uniform Contract

Layered → Virtualised (indirection)

Code on Demand – Consumer-executed Logic

Uniform Contract Methods and Media Types

Change Management Walk-through

Canonical Methods and Communication Patterns

Method Definition

Start with communication pattern

Subject patterns to relevant REST Constraints Client/Server, Stateless, Cache, Layered System

• Future-proof Methods– Negotiate Media Type– Support Redirection– Recover from lost messages

• Reuse methods from elsewhere before invention

HTTP GET –Not quite a simple fetch

REST Constraints Stateless: Leaves no consumer-specific state with the

service at the end of the request Cache: Response indicates cacheability Layered System: Keeps resource identifier intact

Future-proof Negotiated media type Redirection through 3xx responses Retry if response is lost Reuse from Web architecture

Publish/Subscribe

Breaches Stateless Constraint Leaves consumer-specific subscription state with

service at the end of request A single user operating multiple service consumers

would result in multiple subscription records

Alternative: Poll for updates at a reasonable rate Be aware: Scalability and service upgrade reduced Be pragmatic: Real-time systems need pub/sub

Pessimistic transactions and locks are also stateful!

Change Management Walk-through

Canonical Media Types, Data Models and Schemas

Media Types (Schemas)

Enumerate and define encoding for each kind of information to communicate

Subject to REST Constraints Self-Description, Hypermedia, Code on Demand

Future-proof Media Types Include extension points (e.g. must-ignore) Apply principle of least power

Reuse types from elsewhere before invention

HTML

REST Constraints Self-Description: Specific MIME type, easy to find

specification Hypermedia: Used in links and image tags Code on Demand: ECMAscript and applets

Future-proof Evolution via Must-ignore semantics Least Power: Paragraphs, lists and tables Reuse from Web architecture Abstract and reusable for many purposes

Semantic SpectrumSemantic Spectrum

Level of Abstraction / Reusability

Le

vel o

f S

em

an

tic

s /

Ja

rgo

n

Customer Record

Invoice

Address e.g. vCard

News Feed e.g. Atom

Human-readable e.g. HTML

Types with higher level semantics usually contain more jargon, and have narrower applicability

Service Change Management

Service Description and Service Capability Metadata

Service Capability Metadata

Resource Identifiers (Service-specific) Method (Centralised) Media Types (Centralised) CacheDocumentation and Exceptions

/{invoice-id} GET application/vnd.com.example.invoice+xml

Must-revalidate

Retrieve Invoice for invoice-id

application/vnd.com.visa.invoice+xml

PUT application/vnd.com.example.invoice+xml

No cache Update Invoice for invoice-id to match specified state

• Service Endpoint + Method = Service Capability– Media Type is negotiated

• Check Uniform Contract usage is correct• Apply remaining REST Constraints• Apply SOA Principles

Take-home Messages

Governance even more important in REST-style SOA

REST doesn’t permit everything you want to do: Be pragmatic, but aware of implications

REST is just as much about integration maturity as it is about scalability and performance

Give Project Teams some space to experiment, but clamp down where required