Lessions Learned - Service Oriented Architecture
Upcoming SlideShare
Loading in...5
×
 

Lessions Learned - Service Oriented Architecture

on

  • 104 views

Gjesteforelesningspresentasjon gitt til NTNU TDT4140 Programvareutvikling

Gjesteforelesningspresentasjon gitt til NTNU TDT4140 Programvareutvikling

Statistics

Views

Total Views
104
Views on SlideShare
104
Embed Views
0

Actions

Likes
0
Downloads
3
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Lessions Learned - Service Oriented Architecture Lessions Learned - Service Oriented Architecture Presentation Transcript

  • 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 View slide
  • Introduction to SOA View slide
  • 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
  • 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)
  • 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” 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
  • 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
  • Value in the interface
  • 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
  • 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” Object rel. diagram I pay Electricity bill Use case Pay bill
  • 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. Bill pay(Bill) pay Payer Payee Money Account Implementation details But… what about cross border payment? Currency differences?
  • Need of a Domain Model Modelling a service • Going from Computation Independent to Plattform Independent inherit Payer PaymentService • pay(Bill) Bill DomesticAccount Account SWIFTAccount Payee Amount Currency Amount
  • 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
  • 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”
  • Define your level of governance 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!
  • 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 Polite consumers upgrade when told ConsumerA Service v1.0 Service v1.1 ConsumerB
  • Versioning all elements … 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?
  • 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 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!
  • Versioning all elements 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
  • 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 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 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?
  • 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 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
  • 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 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…
  • Vendors and plattforms • 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.
  • 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 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 <?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… 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 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 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 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 …>
  • 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 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
  • 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