Lessions Learned - Service Oriented Architecture

Lessions learned
Experiences from years
of 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

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

Service oriented?
Application oriented or service oriented

WebApp

WS

BP

WebApp

WS
AppServer WS

WS

BP

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)

Service oriented?
Increasing Service Autonomy
BusinessService

BusinessService

BusinessService

WebApp
WebAppWebApp
WebApp WebApp

WS
WS

WS
WS

WS
WS

Warehouse

WS
WS

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

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”
Business need

SOAP is just another protocol…

WS

WS

WS

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

EJB

EJB

EJB

Legacy

Legacy

Legacy

Proc

Proc

Proc

services got new interfaces
… that got service oriented decades ago
Once upon a time there was a database

Database
Database

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

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”
Object rel. diagram
I

pay

Electricity bill

Use case
Pay bill

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

Bill
pay(Bill)
pay

Payer

Payee

Money
Account
Implementation
details
But… what about cross border payment? Currency differences?

Modelling a service
• Going from Computation Independent to
Plattform Independent

inherit
Payer

PaymentService
• pay(Bill)

Bill

DomesticAccount
Account
SWIFTAccount

Payee
Amount

Currency
Amount

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

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!

Polite consumers upgrade when told

ConsumerA

Service v1.0
Service v1.1

ConsumerB

… but do they exist?

ConsumerA

Service v1.0
Service v1.1

ConsumerB

Service v2.0
Service v2.1

How will this evolve?
With hundreds of services?
… and multiple consumers?

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

An extra layer…
Visible endpoint: https://myhost/example/ServiceV1.0
Serviceservice endpoint: https://myhost/example/ServiceV1
implements

ConsumerA

Service v1

Service v1.0

https://myhost/example/ServiceV2

Service v1.1

ConsumerB

Service v2.0

Service v2

Service v2.1
ConsumerA: System halted!
ConsumerB: System halted!

Control your consumers

ConsumerA

CA_Service

Service v1.0
Service v1.1

ConsumerB

CB_Service

Service v2.0
Service v2.1

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 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 their
dependencies
• Gives the possibilities to emulate and mock behaviour from
backend systems
• If you know what your service is supposed to do – it may
be easier to verify that it actually behaves as expected if
you can emulate the backends?

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 freedom
that 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 the
product 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 the
success of the plattform.
– Short round-trip may give more happy developers
– Fewer bugs
– Better control of cross-cutting concerns and governance
issues (unless the product has a strong focus on
governance)
• If you are increasing the degrees of fredom for the
developers – by allowing them to write code – they may
write more bugous code
– If you own the source-code – it may be easier to find
and 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-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…
PaymentService
OrderService
•createOrder
•readOrder
•updateOrder
•deleteOrder

•createPayment
•readPayment
•updatePayment
•deletePayment

CustomerService
•createCustomer
•readCustomer
•updateCustomer
•deleteCustomer

Service

Gjentakende design av ”CRUD-operasjoner”

•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

Respons fra tjenesten

OK, du får det du spør etter

HTTP-protokollen
• POST

• CREATE

• GET

• READ

• PUT

• UPDATE

• DELETE

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

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)
Uniformt grensesnitt
• Respons kan caches fra kall til kall – ikke operasjoner
• Identifiserer ressurser
GET /tickers/IBM
• Lagdelt system
• Manipulasjon av ressurser

• Code on demand (optional)
POST /tickers/IBM
• Selvbeskrivende meldinger
DELETE /tickers/IBM

• Hypermedia as the engine of application
GET /tickers/IBM

state 200 SUCCESS
(HATEOAS)
Price: 34,5

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;
/tickers/IBM?from=2014-02-01&to=2014-02-18:
:

Content-Type

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

{{”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”}}

GET /tickers/IBM?from=2014-02-01&to=2014-02-18
Content-Type: application/json; charset=utf-8

GET /tickers/IBM?from=2014-02-01&to=2014-02-18
Content-Type: application/jpg; charset=utf-8

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

SOAP eller REST?
SOAP

REST

•

Historikk fra remote access

•

Utganspunkt i HTTP

•

Standardisering kommet

•

Frihet, men under ansvar

langt (WS-I, WS-Sec …)

•

Fjerner en del overhead i

•

Godt fotfeste i store

protokollen ved å bruke

organisasjoner med fokus

ferdigdefinerte operasjoner

på formalisme

og feilkoder
•

Mye brukt i mobilløsinger/apper.

• Helge.olav.aarstein@kantega.no
• http://kantega.no

Lessions Learned - Service Oriented Architecture

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Lessions Learned - Service Oriented Architecture

Similar to Lessions Learned - Service Oriented Architecture (20)

Recently uploaded

Recently uploaded (20)

Lessions Learned - Service Oriented Architecture