LESSIONS FROM THE BIOCREATIVE PROTEIN- PROTEIN INTERACTION (PPI) TASK RegCreative Jamboree ,
Lessions Learned - Service Oriented Architecture
-
Upload
helge-olav-aarstein -
Category
Education
-
view
77 -
download
2
Transcript of Lessions Learned - Service Oriented Architecture
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
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 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)
Value in the interface
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”
Value in the interface
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
Value in the interface
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
Value in the interface
Standards enforce interoperability
• SOAP helps, but alone is not enough
• WS-I Basic Profile
• WS-Security
Value in the interface
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
Need of a Domain Model
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
Need of a Domain Model
”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?
Need of a Domain Model
PaymentService
• pay(Bill) Bill
Payer
Payee
Amount
Account
Currency
Amount
inherit
Modelling a service
• Going from Computation Independent to
Plattform Independent
DomesticAccount
SWIFTAccount
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
Define your level of governance
• 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 level of governance
• 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?
Define your level of governance
• Apply the policies at design time.
– It’s hard to apply them when the services are built
• Monitor and enforce during development and runtime
Define your level of governance
• 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”
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!
Versioning all elements
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!
Versioning all elements
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
Versioning all elements
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?
Versioning all elements
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
Versioning all elements
Service v2.0
Service v1.1
Service v1.0ConsumerA
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
Versioning all elements
Service v2.0
Service v1.1
Service v1.0ConsumerA
ConsumerB
CA_Service
CB_Service
Service v2.1
Control your consumers
ConsumerA: System halted!Service v2.2
Versioning all elements
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 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?
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
Vendors and plattforms
• 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…
Vendors and plattforms
• 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.
Vendors and plattforms
• 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
<?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: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
<?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>
<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
HTTP/1.1 Host: www.example.org
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
HTTP/1.1 Host: www.example.org
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
GET /tickers/IBM?from=2014-02-01&to=2014-02-18
Content-Type: application/jpg; charset=utf-8
GET /tickers/IBM?from=2014-02-01&to=2014-02-18
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 xmlns:h=http://www.examle.org/header>
<h:TraceId>1234-1111-9876</h:TraceId>
</h:StockMetaData>
</soap:Header>
GET /tickers/IBM?TraceId=1234-1111-9876
HTTP/1.1 Host: www.example.org
Content-Type: plain; charset=utf-8 Content-Length: xxx
TraceId: 1234-1111-9876
Price: 34,5
GET /tickers/IBM
HTTP/1.1 Host: www.example.org
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