What makes a Service a good Service - OPITZ CONSULTING - Torsten Winterberg

814 views

Published on

In seiner Präsentation geht Torsten Winterberg, Direktor Strategie & Innovation darauf ein, was einen guten Service ausmacht und welche Ziele mithilfe eines guten Service erreicht werden.

Published in: Technology
  • Be the first to comment

What makes a Service a good Service - OPITZ CONSULTING - Torsten Winterberg

  1. 1. Torsten Winterberg<br />OPITZ CONSULTING GmbH<br />ODTUG 2010<br />What Makes a Service a Good Service?<br />
  2. 2. Aboutme…<br />torsten.winterberg@opitz-consulting.com<br />Position@OPITZ CONSULTING<br />DirectorStrategyand Innovation<br />Head of Competence Center SOA <br />Community<br />Speaker: Jax, W-Jax, OOP, DOAG, OOW, SOA Symposium,…<br />Author of several SOA/BPM relatedarticlesandbooks<br />Head of SOA Special Interest Group (SIG) of the German Oracle User Group (DOAG) (togetherwith Hajo Normann)<br />Oracle AceDirector<br />Background<br />Java EE developer, coachandarchitect<br />Startedfirst Oracle BPEL PM project in 2004<br />
  3. 3. The team: Masons-of-SOA<br />www.soa-community.com<br /><ul><li>Bernd Trops (Sopera)
  4. 4. Berthold Maier (Oracle Consulting)
  5. 5. Clemens Utschig-Utschig (Oracle Corp.)
  6. 6. Hajo Normann (HP Enterprise Services)
  7. 7. Torsten Winterberg (OPITZ CONSULTING)
  8. 8. Jürgen Kress (Oracle Corp.)</li></ul>www.soa-spezial.de<br />
  9. 9. Agenda<br />Service Orientation<br />„Good Service“ – Business aspects<br />„Good Service“– Technical aspects<br />
  10. 10. 1<br />Service Orientation<br />
  11. 11. It’s all about architecture…<br />
  12. 12. Buildingtheenterprise: Vision<br />Processoptimization<br />Processcontrolling<br />Processdesign<br />Process Management<br />Process Monitoring<br />Process Implementation<br />Workflow/BPM/BAM<br />ESB/EDA/BRE<br />Services<br />Applications<br />Service<br />Delivery<br />Service<br />Request<br />Middleware<br />Database<br />Storage<br />Infrastructure (The „Grid“)<br />
  13. 13. The Paradigm: Service OrientationThe eight service orientation design principles<br />
  14. 14. Service – A definition<br />A serviceis a unit of solutionlogictowhichservice orientationhasbeenappliedto a meaningfulextend.<br /> (Thomas Erl)<br />Purchase Order<br /><ul><li>SubmitOrder
  15. 15. CheckOrderStatus
  16. 16. ChangeOrder
  17. 17. CancelOrder</li></li></ul><li>„Goodservice“<br />Use an existingone<br />Buildit on yourown<br />
  18. 18. Contextof a project<br />
  19. 19. Service usage scope<br />Scope<br />Typical WS-Attributes: <br />Document style, industry standard data formats <br />Organisations<br />Document style, enterprise data formats <br />Company<br />Document or RPC style, LOB<br />data representations <br />Department <br />Function call, RPC or RMI<br />Application internal<br />Granularity<br />loose<br />tight<br />degree of coupling<br />Copyright Oracle Corp.<br />
  20. 20. „Good“ services: businessandtechnicalview<br />Public/private aspect<br />Loose couplingandvisibility<br />We have been applying service orientation to help organizations<br />consistently deliver sustainable business value, with increased agility<br />and cost effectiveness, in line with changing business needs.<br />
  21. 21. 3<br />Business aspects<br />
  22. 22. Business aspectsof a „good“ service:<br />Service classification<br /><ul><li>Servicedesign
  23. 23. Errorhandling</li></li></ul><li>Business aspectsof a „good“ service:Service design<br />Functionalitymatchesrequirements<br />Requirementsmanagement<br />Whatthe User reallyget<br />What‘swritten in theconcept<br />Whattheusersreallyneed<br />Verify that services satisfy business requirements and goals. <br />
  24. 24. Business aspectsof a „good“ service:Domain decomposition<br />
  25. 25. Produktion<br />Verkauf<br />F&E<br />Rohstoffeingang<br />Produktgenehmigung<br />Domäne<br />Top-Down<br />Service<br />Service<br />Service<br />Service<br />Service<br />Service<br />API<br />Komponenten<br />DB<br />Dateien<br />Anwendungen<br />Business aspectsof a „good“ service:Options forfinding a service<br />Bottom-Up<br />
  26. 26. Erl – Cutting of a serviceisimportant, but canbechanged!<br />Compatible Change<br />The existing capability is not renamed. Instead, a new capability with a new name is added alongside the original capability, thereby preserving compatibility with both consumers A and B.<br />
  27. 27. Erl – cuttingof a serviceisimportant, but canbechanged!<br />Servicedecomposition<br />The original, coarse-grained invoice service is decomposed into three separate services, one of which remains associated with general invoice processing but only encapsulates a subset of the original capabilities.<br />
  28. 28. Erl – Cutting of a serviceisimportant, but canbechanged!<br />Proxy capability<br />By preserving the existing capability and allowing it to act as a proxy for the relocated capability logic, existing consumers will be less impacted.<br />
  29. 29. Erl – Cutting of a serviceisimportant, but canbechanged!<br />Terminationnotification<br />The service contract includes a standardized statement that communicates when it is scheduled for termination. As a result, the consumer does not attempt to invoke it after the contract has been terminated.<br />
  30. 30. Business aspectsof a „good“ service:Service design<br />Findabilityandusagethroughnamingconventionsanddescriptions<br />Strong businessfunctionallitynameoftheservice<br />Principle: Service discoverability<br />
  31. 31. Business aspectsof a „good“ service:Service design<br />Understandabilitythroughgoodcoherence<br />
  32. 32. Business aspectsof a „good“ service:Servicedesign<br />Usageofcanonicaldataformats<br />
  33. 33. Business aspectsof a „good“ service:Servicedesign<br />An ESB canbeusedas a translator<br />ESB<br />APP 1<br />Business EntityService<br />PrivaterEntityService<br />EBS<br />APP 2<br />Enrich<br />Transform<br />Validate<br />APP 3<br />GenerierterService Kontrakt (WSDL)<br />Validate Enrich Transform and Operate UmwandlungderDatenvom Common Modell in das Proprietäre – visa versa<br />ÖffentlicherService Kontrakt (WSDL)<br />Data Sources<br />
  34. 34. Business aspectsof a „good“ service:Servicedesign<br />BOM als semantisches Datenmodell<br />Einheitlicher Sprachgebrauch<br />Vermeidung von Missverständnissen und Redundanzen<br />Vereinfachte Kommunikation<br />(Technisch) einheitliche Datenformate<br />Definition von nicht strukturierten Datentypen<br />Extern-definierte Datentypen (BLZ, KontoNr)<br />Stabile Datentypen eines Datenmasters (KundenNr, VertragsNr)<br />Klärung von Verantwortung<br />Zuordnung von Daten zu Domänen zu Rollen/Systemen/…(Datenmaster)<br />
  35. 35. Business aspectsof a „good“ service:Service classification<br />Service categorization<br />
  36. 36. Executable<br />business processes<br />and <br />business rules<br />Business process models<br />Business Rule Service<br />(Entscheidung)<br /><Rule Engine, Java><br />Business Process<br />Service <br /><BPEL, BPMN 2.0><br />Business Process<br />(flow of a process)<br />EPC or BPMN<br />in BPA Suite<br />Business Rule Service<br />(Validierung)<br /><Rule Engine, Java, Schematron><br />Business Activity<br />Service<br /><BPEL, BPMN 2.0, ESB><br />Business process step (activity)<br />(what happens here)<br />EPC , BPMN or UML<br />Business <br />Objects<br />Business Entity<br />Service<br /><BPEL, BPMN 2.0, ESB><br />Implementation of a<br />Process step (activity)<br />(how is this done)<br />EPC, BPMN or UML<br />Integration<br />Integration Process<br /><BPEL, BPMN 2.0, ESB><br />Public Services (registered in Registry)<br />X<br />Adapter<br /><ESB><br />Adapter<br /><ESB><br />Private Services<br />X<br />Systeme<br />Service A<br />System A<br />System B<br />
  37. 37. CarRentalBPS<br />Farben und Linienals Kopiervorlage<br />A<br />Start<br />aggregateCustomerDataBAS<br />ReadCustomerData<br />CustomerBES<br />readCustomerDatau.a.<br />A<br />ReadCustomerData<br />Private Integration Service<br />A<br />CRM 1<br />readCustomerFromCRM1<br />Private Service<br />A<br />Car-<br />Rental<br />readCustomerFromCarR.<br />Private Service<br />A<br />„Good“ Customer?<br />A<br />readRentalHistoryBAS<br />Details obmittedhere<br />CarsAndPrices<br />A<br />ConfirmationCust? <br />calculateIf<br />GoodCustomerBAS<br />DecidesaboutimplementationasRuleorSub-Prozess<br />WriteCrmInfos<br />or<br />Rule<br />Engine<br />calculateIfGoodCustomerBRS<br />WriteInvoice<br />calculateIfGoodCustomerBPS<br />Workflow<br />Service<br />MessageToCustomer<br />End<br />
  38. 38. Business Service<br /><ul><li> Rein fachlich motivierte Schnittstelle
  39. 39. Fassade auf Implementierung (Private Services)</li></ul>Public Business Services sind eine Enterprise-SOA Governance-Dimension, d.h. sie motivieren applikationsübergrei-fende Richtlinien bezüglich Life Cycle und Schnittstellen-Design: Tausche Daten nur im kanonischen Format aus etc.<br />Public Service<br />Technische Querschnitssfunktionalität, die global eingesetzt wird. <br />Beispiele: Zentrale Logging-, Print-, oder Security-Services<br />Utility Service<br />Keine Zuordnung <br />zu Business und <br />Utility-Logik<br />Lokale / Applikations-bezogene Governance-Dimension<br />Public Services werden mit Private Services implementiert. Dies sind private, lokale „Klumpen an Funktionalität“: Es ist aus Sicht der Public Services egal, in welcher Sprache, mit welchen Applikationsarchitekturen und Design Pattern sie realisiert sind. Ihre Beschreibung im Interface ist nicht notwendigerweise standardisiert. Sie weisen entweder keine oder lokal begrenzte Governance im Lifecycle auf. <br />Beispiele: „Right-Klick-Java-Service“, Controller-EJB, SIEBEL_Customer_Service.<br />Private<br /> Service<br />
  40. 40. Business aspectsof a „good“ service:Errorhandling<br />Description ofbusinessexceptions<br />Therecanbemorethanone<br />Theynormallydon‘tleadtotermination<br />Replycanbetheservicereplyincludingthebusiness fault<br />Make a testsuiteavailableforbusinessfaults<br />Usecase Name<br />Result / Goal<br />Actor<br />Pre-condition<br />Normal applicationflow<br />1<br />2<br />3<br />Exceptions<br />1a<br />1b<br />2a<br />Post-condition<br />
  41. 41. Business aspectsof a „good“ service:Summary<br />Servicedesign:<br />Functionalitymatchesrequirements<br />Findability and usage through naming conventions and descriptions<br />Understandabilitythroughgoodcoherence<br />Usage of canonical data formats<br />Service classification:<br />Service categorization<br />Error handling:<br />Description ofbusinessexceptions<br />Make a testsuite available for business faults<br />
  42. 42. 4<br />Technical aspects<br />
  43. 43. Technical aspectsof a „good“ service:<br />Technical compliance<br />Interoperability<br />Communication<br />Errorhandling<br />
  44. 44. Technical aspectsof a „good“ service:Adherenceoftechnicalcompliance<br />Degreeofstatelessness<br />
  45. 45. Technical aspectsof a „good“ service:Adherenceoftechnicalcompliance<br />Participation in compensations<br />
  46. 46. Technical aspectsof a „good“ service:Adherenceoftechnicalcompliance<br />Existenceofversioningconcepts<br />
  47. 47. Technical aspectsof a „good“ service:Adherenceoftechnicalcompliance<br />Characteristicofidempotency<br />
  48. 48. Technical aspectsof a „good“ service:Adherenceoftechnicalcompliance<br />Structurellassemblyof a WSDL-file<br />Checklist in magazineand www.soapark.tv<br />
  49. 49. Technical aspectsof a „good“ service:Adherenceoftechnicalcompliance<br />Adherencetoprojectstandards<br />Checklists<br />4-eyes<br />CI<br />…<br />
  50. 50. Technical aspectsof a „good“ service:Adherenceoftechnicalcompliance<br />Adherenceto WS-* Standards (whereuseful!!)<br />
  51. 51. Technical aspectsof a „good“ service:Interoperability<br />WS-I conformity<br />Always check!!!!<br />
  52. 52. Technical aspectsof a „good“ service:Interoperability<br />Service canbeused in different securityconcepts<br />
  53. 53. Technical aspectsof a „good“ service:Interoperability<br />Noexpositionofinternalgenerics<br />
  54. 54. Technical aspectsof a „good“ service:Communication<br />Decouplingfromcommunicationprotocol<br />
  55. 55. Technical aspectsof a „good“ service:Communication<br />Asynchronouscommunicationpattern<br />Collect Data<br />P<br />P<br />P<br />P<br />P<br />P<br />P<br />Process (withoutuserinteraction)<br />reply<br />Start process<br />A<br />A<br />A<br />A<br />A<br />A<br />A<br />A<br />minutestoweeks 1..10 seconds<br />Process Runtime:<br />asyncsync/ fast async<br />MEP:<br />
  56. 56. Technical aspectsof a „good“ service:Errorhandling<br />Description oftechnicalexceptions<br />There can be more than one<br />Leads always to termination<br />Reply can be the service reply or the technical fault<br />Universally valid range of numbers for standard faults and special ranges for each service<br />Make a technical testsuite available<br />
  57. 57. Technical aspectsof a „good“ service:Summary 1/2<br />Technical compliance:<br />Degreeofstatelessness<br />Participation in compensations<br />Existenceofversioningconcepts<br />Characteristicofidempotency<br />Structurell assembly of a WSDL-file<br />Adherencetoprojectstandards<br />Adherenceto WS-* Standards<br />Interoperability:<br />WS-I conformity<br />Being integrable in different security concepts<br />No exposition of internal generics<br />
  58. 58. Technical aspectsof a „good“ service:Summary 2/2<br />Communication:<br />Decouplingfromcommunicationprotocol<br />Ifuseful: Asynchronouscommunicationpattern<br />Errorhandling:<br />Description oftechnicalexceptions<br />Make a technical testsuite available<br />
  59. 59. 5<br />Conclusion<br />
  60. 60. Conclusion<br />Identificationof a „good“ publicserviceto:<br />Askforrework<br />Deliverhighqualitywork<br />Goal: <br />Elimination ofuncertainty<br />Increasethequalityour SOA landscapes<br />Further reading<br />Checklists in videosection on: www.soapark.tv<br />SOA-Spezial: http://it-republik.de/jaxenter/news/SOA-Spezial-Ready-For-Change-051440.html<br />
  61. 61. Contact:<br />Torsten Winterberg<br />DirectorStrategy & Innovation Head of Competence Center SOAOracle ACE Director<br />OPITZ CONSULTING GmbHKirchstr. 6, 51647 Gummersbach, GermanyPhone: +49 2261 6001 0torsten.winterberg@opitz-consulting.com<br />

×