Lessions Learned - Service Oriented Architecture

Lessions learned

Experiences from yearsof SOA evolution

Helge Olav Aarstein

Introduction

• Who am I?

– ”Batchelors” degree from HiST 1993

– 1 of 40 that founded Kantega in 2003

– Distributed systems most of the time

– Worked with banking systems since 1995

Internet banking from 2000

– Web services since 2005

– ESB since 2006

Content

• Introduction to SOA

• Defining good interfaces

• Domain modelling

• Governance

• Versioning

• Testing

• Vendors and products

• Summary

Introduction to SOA

SOA

SOA can be defined as an architectural style promoting the concept of business-aligned enterprise service as the fundamental unit of designing, building, and composing enterprise business solutions.

Boris Lublinsky

SOA

SOA is a software system structuring principle, based on the concept of services, which are offered (and described) by service providers. Service consumers read service descriptions, and using ONLY those descriptions, can interact with service provider, getting access to whatever functions it provides.

Ron Ten-Hove(Oracle)

Why SOA?

• Reuse and flexibilty

Motivated by cost and time to market

– Building services incrementally from existing systems

– Changing the system in small pieces whith a limited, and

controllable number of side-effects

– Building new systems and solutions based on existing

services

WS WS WS WS

WebApp WebAppWebApp WebApp

BPBP

WS WS WS WS

WebApp WebApp

Service oriented?

WebApp

AppServer

WebApp

Application oriented or service oriented

Service oriented?

• Standardized Service Contracts: services within the same service inventory are in compliance with the same contract design standards.

• Service Abstraction: service contracts only contain essential information and information about services is limited to what is published in service contracts.

Thomas Earl(2007)

Service oriented?

• Service Reusability: services contain and express agnostic logic and can be positioned as reusable enterprise resources.

• Service Loose Coupling: service contracts impose low consumer coupling requirements and are themselves decoupled from their surrounding environment.

• Service Autonomy: services exercise a high level of control over their underlying runtime execution environment.

Thomas Earl(2007)

WS WS WS WS

WebApp WebApp

Service oriented?

Increasing Service Autonomy

BusinessService BusinessServiceBusinessService

WS WS WS WS

WebApp WebApp WebApp

Warehouse

BusinessService BusinessServiceBusinessService

WS WS WS WS

WebApp WebApp WebApp

Service Integration Maturity Model

The Open Group, 2007

Service oriented?

• Evolving from monolitic systems to services

Gigantic leap to get out of level 2 over higher levels

– Monolitic silos were never designed for reuse and

collaborating with each other

– Need focus on processes and services instead of

applications to succeed

Spørsmål 1

Spørsmål 2

Spørsmål 3

Spørsmål 4

Designing Interfaces

Value in the interface

SOA is a software system structuring principle, based on the concept of services, which are offered (and described) by

service providers. Service consumers read service descriptions, and

using ONLY those descriptions, can

interact with service provider, getting access to whatever functions it provides.

Ron Ten-Hove(Oracle)


Defining and documenting good interfaces

has great value

• Don’t do Headless Web Service implementations

• Poor or missing interfaces will cause stall-pipe

implementations and prevent reuse

• Consumers will implement their own business logic

– Spaghetti integration causes loss of control

”Hold your breath – we are changing the database”

– System maintenance must be performed on entire system

”Big Bang once a year according to SLA”


Bottom-up ”anti-pattern”

DatabaseDatabase

WS

Business need

EJB EJB EJB

Proc Proc Proc

Legacy Legacy Legacy

WS WS

Our old ejb’s are services… are’nt they?

SOAP is just another protocol…

Once upon a time there was a database

… that got service oriented decades ago

services got new interfaces


Define your interfaces!

• Contract First (not implementation first)

• Focus on functionallity

• Standardize elements used

• Think Stability (few changes over time)

• Tighten your contract – don’t allow any input

(remember: Garbage in gives garbage out)

• A tight contract can easily be read, compiled and validated


Standards enforce interoperability

• SOAP helps, but alone is not enough

• WS-I Basic Profile

• WS-Security


Good documentation helps

• Integrators can be self serviced

• Architects can easily build systems based on

your services.

• Document as close to the contract as possible

• Well documented WSDL’s and XMLschemas are a good start

• Generate human readable documentation to PDF or HTML

• Supply with more prosaic documentation where needed


Spørsmål 5

Spørsmål 6

Spørsmål 7

Domain Modelling

Need of a Domain Model

Establish a Domain Model as early as possible.

Don’t start implementing services first!

• Representation of the business architecture

• Vocabulary used when modelling business strategy and

functional requirements

• Model the known truths and dependences within the domain

• Define and manage Master Data

• Services are described as relations and interactions(activities)

between business objects


Model the different perspectives of the model

• Computation Independent Model

Focus on endities and behaviour – not structural

dependencies.

”I want to pay my electricity bill”

I Electricity billpay

Object rel. diagram

Pay bill

Use case


”Our business is to let users pay their bills”

Paying a bill is a relation between a payer and a payee which involves an amount of money.

Money

Bill

Payer Payeepay

Account

pay(Bill)

Implementationdetails

But… what about cross border payment? Currency differences?


PaymentService

• pay(Bill) Bill

Payer

Payee

Amount

Account

Currency

Amount

inherit

Modelling a service

• Going from Computation Independent to

Plattform Independent

DomesticAccount

SWIFTAccount

SOA Governance

Define your level of governance

In a nutshell SOA Governance is about making sure that

the enterprise builds the right things, builds them

right, and makes sure that what it has built is behaving

right.

• “non-functional” requirements over time

• You would need different levels of governance

– If you build aeroplanes

– If you run a home-page


• The governance process should fit your needs

– A too complex process will not be realistic to follow up

(unless it’s extremely critical). Too many short-cuts will

be made

– A too simple process will not add value and cause

divergence between implementations

– A governance tool does not necessary fit your needs


• Define your governance processes by defining what policies

you want to apply (3 P:s in SOA Governance)

– People: Know owners and other stakeholders that has

interest in services

– Process: Know the business processes depending on

your services. Define the lifecycle for your services and

how to follow-up the policies.

– Policies: What do you want to control? .. and How?


• Apply the policies at design time.

– It’s hard to apply them when the services are built

• Monitor and enforce during development and runtime


• A policy has no value if it cannot be measured

– ”All messages should be encrypted”

– ”All consumers should be authenticated”

– ”All services should have documentation following

company guidlines”

– ”All requests to a service should be logged in the service

access log”


A policy has no value if it is not monitored

Spørsmål 8

Versioning Services

Versioning all elements

Plan how to upgrade your services. That implies a good

strategy for versioning services and interfaces

• Every element needs to be versioned

– Services

– WSDL files

– XML Schema files

– XML Namespaces

• Define when and how to change the version number

• Do not forget what changes to theese elements may cause of

changes to the consumers!


Different strategies

• Any change gives a new version of the web service– The consumer must change, at least the service endpoint

The consumer will not change anything until forced!

• No change gives a new version of the web service– Disallows changes to the contract

Risk of major breakdown in a critical consumer

• Only major changes gives a new version– Need to define a major change

Flexibility at a risk!


ConsumerA

ConsumerB

Service v1.0ConsumerA

ConsumerB

Service v1.0

Service v1.1

ConsumerA

ConsumerB

Service v1.0

Service v1.1

ConsumerA

ConsumerB

Service v1.0

Polite consumers upgrade when told


Service v1.0

Service v1.1

ConsumerA

ConsumerB

Service v1.0

Service v1.1

ConsumerA

ConsumerBService v2.0

Service v1.1

ConsumerA

ConsumerB

Service v2.1

Service v2.0

Service v1.0

Service v1.1

ConsumerA

ConsumerB Service v2.0

Service v1.0

Service v1.1

ConsumerA

ConsumerBService v2.0

Service v1.0

Service v1.1

ConsumerA

ConsumerB

Service v1.0

How will this evolve?

With hundreds of services?

… and multiple consumers?

… but do they exist?


Control your consumers – promote your services

• The consumers will not update until forced

• YOU do not want the blame if something breaks

• You will not succeed in defining a ”major change”

An extra layer of indirection

• Maintain consumer – service mapping

• Any change gives a new service version

• Consumers should only be concerned on major changes

• Promote services to low-risk consumers first


Service v2.0

Service v1.1


ConsumerB

Service v1implements

Service v2

Service v2.1

ConsumerA: System halted!

ConsumerB: System halted!

An extra layer…

Service endpoint: https://myhost/example/ServiceV1.0Visible service endpoint: https://myhost/example/ServiceV1

https://myhost/example/ServiceV2


Service v2.0

Service v1.1


ConsumerB

CA_Service

CB_Service

Service v2.1

Control your consumers

ConsumerA: System halted!Service v2.2


Summary

• Taking control

– Reduced number of concurrent versions

– Increased management

– Increased responsibility

• Giving control

– Loosing control of service lifecycle

– Fragmented responsibility

– Higher cost?

• Decide what degree of control that fits you!

Testing Web Services

Testing services

How would you test something without a user interface?

• Plan it – of course!

– No real differences in testing a web service and testing a web application

– The problem lies in understanding the response when it is not graphical

• Requires higher skilled testers

• Model what to test and what to expect

– When the response is not human readable, why use a human to verify it? Automate!

– Continous testing – continous integration

Testing services

What happends to testing when delivering services

• Breaking down the problem should imply easier tests?

• Yes, but…

– You also have to test the whole

– What about crosscutting concerns/governance?

• Logging and security

• Transactions

Testing services

Advantages with loose coupling

• You can more easily detach your services from theirdependencies

• Gives the possibilities to emulate and mock behaviour from backend systems

• If you know what your service is supposed to do – it maybe easier to verify that it actually behaves as expected ifyou can emulate the backends?

Spørsmål 9

Spørsmål 10

Vendors and Products

Vendors and plattforms

• Started with BEA AquaLogic ServiceBus in 2006(Oracle)

– At the time: Great tool helping to standardize service contracts and isolating backend specialities

– A good beginners tool with a limited degree of freedomthat forced the developer to do things ”right”

• The ServiceBus product is mostly the same now as in 2006

– Some limitations has become obstacles

– Some bugs are annoying

– Ineffective development environment

– Long round trip from development to test

• The newer SOA Suite has BPM support for ”long lived” business processes.

• Support issues is byreaucraticly handled and takes time to solve


• All the big vendors has their SOA Suite or SOA Plattform

– But are a SOA product required for a successful SOA?

• Commercial products come with support, but when theproduct evolves, you’re required to upgrade to get the most out of support

• Web Services are just Web Applications that can be deployed in any Web Container

• Some Web Containers just need one second to start…


• Testing and development capabilities is essential for thesuccess of the plattform.

– Short round-trip may give more happy developers

– Fewer bugs

– Better control of cross-cutting concerns and governanceissues (unless the product has a strong focus ongovernance)

• If you are increasing the degrees of fredom for thedevelopers – by allowing them to write code – they maywrite more bugous code

– If you own the source-code – it may be easier to findand correct bugs.


• Governance tools will be needed

– Service registry and repository

– Governance policies

– Testing tools

• The suites rarely have perfect fit on all aspects with a SOA

– You may need to add other tools as well

SOAP

• Fra ”Simple Object Access Protocol” til ”SOA Protocol”

– Utviklet for Microsoft i 1998

– W3C Anbefaling fra 2003 (v1.2)

• XML-basert

• Kan transporteres over flere nettverksprotokoller

– JMS,SMTP og HTTP

– http mest brukt …

SOAP eller REST

SOAP-Melding

POST /StockService

HTTP/1.1 Host: www.example.org

Content-Type: application/soap+xml; charset=utf-8 Content-Length: 299

SOAPAction: ”http://example.org/StockService/getStockPrice”

<?xml version="1.0"?>

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">

<soap:Header>

<h:StockMetaData xmlns:h=http://www.examle.org/header>

<h:TraceId>1234-1111-9876</h:TraceId>

</h:StockMetaData>

</soap:Header>

<soap:Body>

<m:GetStockPrice xmlns:m="http://www.example.org/stock">

<m:StockName>IBM</m:StockName>

</m:GetStockPrice>

</soap:Body>

</soap:Envelope>

SOAP-Respons

HTTP/1.1 200 OK

Content-Type: application/soap+xml; charset=utf-8 Content-Length: xxx



<soap:Header>



</h:StockMetaData>

</soap:Header>

<soap:Body>

<m:GetStockPriceResponse xmlns:m="http://www.example.org/stock">

<m:Price>34.5</m:Price>

</m:GetStockPriceResponse>

</soap:Body>

</soap:Envelope>

SOAP-Feil

HTTP/1.1 404 Not found

Content-Type: application/soap+xml; charset=utf-8 Content-Length: xxx



<soap:Header>



</h:StockMetaData>

</soap:Header>

<soap:Body>

<soap:Fault>

<faultcode>soap:Client</faultcode>

<faultstring>Ticker not found</faultstring>

<detail>

<m:StockFault xmlns:m="http://www.example.org/stock"><m:Reason>Ticker ’IBM’ not found at NYSE</m:Reason>

</m:StockFault>

</detail>

</soap:Fault>

</soap:Body>

</soap:Envelope>

Designerkjennelsen…

OrderService

•createOrder•readOrder•updateOrder•deleteOrder

PaymentService

•createPayment•readPayment•updatePayment•deletePayment

CustomerService

•createCustomer•readCustomer•updateCustomer•deleteCustomer

Gjentakende design av ”CRUD-operasjoner”

Service

•create•read•update•delete

Hva om vi ikke brukte SOAP?

GET /tickers/IBM


Content-Type: plain; charset=utf-8 Content-Length: xx

wget http://example.com/tickers/IBM

HTTP request sent, awaiting response... 200 OK

Price: 34.5

Bruk HTTP Hent ticker IBM fra ”alle” tickers OK, du får det du spør etter

Respons fra tjenesten

HTTP-protokollen

• POST

• GET

• PUT

• DELETE

GET /tickers/IBM


Content-Type: application/soap+xml; charset=utf-8

Content-Length: 299

SOAPAction: "http://www.w3.org/2003/05/soap-envelope”

<?xml version="1.0"?><soap:Envelope …>

• CREATE

• READ

• UPDATE

• DELETE

Feilhåndtering uten SOAP Fault?wget http://example.com/tickers/NTNU

HTTP request sent, awaiting response... 404 Not Found

Ticker NTNU not found at NYSE

• Ferdig definerte statuskoder

– 1xx: Informasjon

– 2xx: Suksess

– 3xx: Omdirigert

– 4xx: Klientfeil

– 5xx: Serverfeil

POST /tickers/NTNU

HTTP request sent, awaiting

response... 201 Created

POST /tickers/NTNU

HTTP request sent, awaiting

response... 403 Forbidden

REST

• REpresentational State Transfer

– Arkitekturstil utviklet av W3C

• Basert på mekanismer i HTTP

– Standard operasjoner (POST, PUT, GET, …)

– Standard feilkoder (200=ok, 404=not found osv)

– Ingen binding på meldingsformat

• JSon og XML er mye brukt.

– Bruk av mediatype til å styre variasjon i respons

REST - prinsipper

• Klient adskilt fra server med et uniformt grensesnitt

• Tilstandsløse tjenester (ingen klientkontekst)

• Respons kan caches fra kall til kall

• Lagdelt system

• Code on demand (optional)

Uniformt grensesnitt

• Identifiserer ressurser – ikke operasjoner

• Manipulasjon av ressurser

• Selvbeskrivende meldinger

• Hypermedia as the engine of application

state (HATEOAS)

GET /tickers/IBM

POST /tickers/IBM

DELETE /tickers/IBM

GET /tickers/IBM

200 SUCCESS

Price: 34,5

Content-Type

GET /tickers/IBM?from=2014-02-01&to=2014-02-18

Content-Type: text/csv; charset=utf-8


Content-Type: application/jpg; charset=utf-8


Content-Type: application/json; charset=utf-8

2014-02-01;34.5;

2014-02-01;35.5;

2014-02-01;32.5;

2014-02-01;30.0;

2014-02-01;29.5;

2014-02-01;31.7;

: :

{{”date” : ”2014-02-01”, ”Price” : ”34.5”},

{”date” : ”2014-02-01”, ”Price” : ”35.5”},

{”date” : ”2014-02-01”, ”Price” : ”32.5”},

{”date” : ”2014-02-01”, ”Price” : ”30.0”},

{”date” : ”2014-02-01”, ”Price” : ”29.5”},

{”date” : ”2014-02-01”, ”Price” : ”31.7”}}

Metadata?<soap:Header>



</h:StockMetaData>

</soap:Header>

GET /tickers/IBM?TraceId=1234-1111-9876


Content-Type: plain; charset=utf-8 Content-Length: xxx

TraceId: 1234-1111-9876

Price: 34,5

GET /tickers/IBM


Content-Type: plain; charset=utf-8 Content-Length: xxx XX-TraceId=1234-1111-9876

Price: 34,5

• Historikk fra remote access

• Standardisering kommet

langt (WS-I, WS-Sec …)

• Godt fotfeste i store

organisasjoner med fokus

på formalisme

SOAP eller REST?

• Utganspunkt i HTTP

• Frihet, men under ansvar

• Fjerner en del overhead i

protokollen ved å bruke

ferdigdefinerte operasjoner

og feilkoder

• Mye brukt i mobil-

løsinger/apper.

SOAP REST

• [email protected]

• http://kantega.no

mailto:[email protected]



http://kantega.no/

Education

Lessions Learned - Service Oriented Architecture