1. Lecture 24 Enterprise Systems Development ( CSC447 ) COMSATS Islamabad Muhammad Usman, Assistant Professor

2. Service Orientation

3. 3 Overview  Services, service description, service communication  Service-Oriented Architecture (SOA)  Web services  SOSE: Service-Oriented Software Engineering

4. 4 Italian restaurant analogy  Restaurant provides food: a service  After the order is taken, food is produced, served, …: service may consist of other services  The menu indicates the service provided: a service description  The order is written down, or yelled at, the cook: services communicate through messages

5. 5 Main ingredients  Services  Service descriptions  Messages  Implementation: through web services

6. 6 Other example  Citizen looking for a house:  Check personal data  System X  Check tax history  System Y  Check credit history  System Z  Search rental agencies  System A,B ……

7. 7 What’s a service  Platform-independent computational entity that can be used in a platform-independent way  Callable entities or application functionalities accessed via exchange of messages  Component capable of performing a task  Often just used in connection with something else: SOA, Web services, …

8. 8 What’s a service, cnt’d  Shift from producing software to using software  You need not host the software  Or keep track of versions, releases  Need not make sure it evolves  Etc  Software is “somewhere”, deployed on as-needed basis  SaaS: Software as a Service

9. 9 Key aspects  Services can be discovered  Services can be composed to form larger services  Services adhere to a service contract  Services are loosely coupled  Services are stateless  Services are autonomous  Services hide their logic  Services are reusable  Services use open standards  Services facilitate interoperability

10. 10 Service discovery Service registry Service provider Service requestor lookup bind publish

11. 11 Service discovery Rental agency 1 Rental agency 2 Municipality system Apartment (immediate, cheap) publish Agency 1 Apartment? Rental agreement Rental agency 1

12. 12 Service discovery  Discovery is dynamic, each invocation may select a different one  Primary criterion in selection: contract  Selection may be based on workload, complexity of the question, etc  optimize compute resources  If answer fails, or takes too long  select another service  more fault-tolerance

13. 13 Is discovery really new?  Many design patterns loosen coupling between classes  Factory pattern: creates object without specifying the exact class of the object.

14. 14 Services can be composed  Service can be a building block for larger services  Not different from CBSE and other approaches

15. 15 Services adhere to a contract  Request to registry should contain everything needed, not just functionality  For “normal” components, much is implicit:  Platform characteristics  Quality information  Tacit design decisions  Trust promises?  Quality of Services (QoC), levels thereof  Service Level Agreement (SLA)

16. 16 Service discovery Rental agency 1 Rental agency 2 Rental agency 1 Municipality system Apartment (immediate, cheap) Agency 1 Apartment? Rental agreement

17. 17 Services are loosely coupled  Rental agencies come and go  No assumptions possible  Stronger than CBSE loose coupling

18. 18 Services are stateless  Rental agency cannot retain information: it doesn’t know if and when it will be invoked again, and by whom

19. 19 Services are autonomous, hide their logic  Rental agency has its own rules on how to structure its process  Its logic does not depend on the municipality service it is invoked by  This works two ways: outside doesn’t know the inside, and vice versa

20. 20 Services are reusable  Service models a business process:  Not very fine grained  Collecting debt status from one credit company is not a service, checking credit status is  Deciding on proper granularity raises lots of debate

21. 21 Service use open standards  Proprietary standards  vendor lockin  There are lots of open standards:  How services are described  How services communicate  How services exchange data  etc

22. 22 Services facilitate interoperability  Because of open standards, explicit contracts and loose coupling  Classical CBSE solutions pose problems:  Proprietary formats  Platform differences  Etc  Interoperability within an organization (EAI) and between (B2B)

23. 23 Overview  Services, service description, service communication  Service-Oriented Architecture (SOA)  Web services  SOSE: Service-Oriented Software Engineering

24. 24 Service-Oriented Architecture  Architecture:  the fundamental organization of a system in its components, their relationships to each other and to the environment and the principles guiding its design and evolution  SOA: Any system made out of services?

25. 25 What is SOA? Infrastructure service layer Orchestration/coordination layer Business services layer service bus service logical physical

26. 26 Service bus  Event-based messaging engine  Origin: EAI, solve integration problems  Often takes care of:  Mediation: protocol translation, data transformation, etc  Quality of Service issues: security, reliable delivery of messages, etc  Management issues: logging, audit info, etc.  Service discovery  Can be central (broker, hub), or decentral (smart endpoints)

27. 27 Service coordination  Orchestration: central control  Choreography: decentral control

28. 28 Overview  Services, service description, service communication  Service-Oriented Architecture (SOA)  Web services  SOSE: Service-Oriented Software Engineering

29. 29 Web services  Implementation means to realize services  Based on open standards:  XML  SOAP: Simple Object Access Protocol  WSDL: Web Services Description Language  UDDI: Universal Description, Discovery and Integration  BPEL4WS: Business Process Execution Language for Web Services  Main standardization bodies: OASIS, W3C

30. 30 Coordination of Web services BPEL4WS WSDL Java WSDL Java WSDL Java

31. 31 Web services stack BPEL4WS WSDLUDDI HTTP, FTP, … SOAP composition description messages network discovery

32. 32 XML  Looks like HTML  Language/vocabulary defined in schema: collection of trees  Only syntax  Semantic Web, Web 2.0: semantics as well: OWL and descendants

33. 33 SOAP  Message inside an envelope  Envelop has optional header (~address), and mandatory body: actual container of data  SOAP message is unidirectional: it’s NOT a conversation

34. SOAP Message Structure  Request and Response messages  Request invokes a method on a remote object  Response returns result of running the method  SOAP specification defines an “envelop”  “envelop” wraps the message itself  Message is a different vocabulary  Namespace prefix is used to distinguish the two parts Application-specific message vocabulary SOAP Envelop vocabulary

35. SOAP Request Message <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> IBM SOAP Envelope Message SOAP Envelope Namespace Message Namespace

36. SOAP Response Message <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> 34.5 SOAP Envelope Message Result returned in Body

37. Why SOAP?  Other distributed technologies failed on the Internet  Unix RPC – requires binary-compatible Unix implementations at each endpoint  CORBA – requires compatible ORBs  RMI – requires Java at each endpoint  DCOM – requires Windows at each endpoint  SOAP is the platform-neutral choice  Simply an XML wire format  Places no restrictions on the endpoint implementation technology choices

38. 38 WSDL  Four parts:  Web service interfaces  Message definitions  Bindings: transport, format details  Services: endpoints for accessing service. Endpoint = (binding, network address)

39. 39 UDDI  Three (main) parts:  Info about organization that publishes the services  Descriptive info about each service  Technical info to link services to implementation

40. 40 UDDI (cnt’d)  Original dream: one global registry  Reality: many registries, with different levels of visibility  Mapping problems

41. 41 BPEL4WS  Three main parts:  Partnerlinks: dependencies between services: who sends what to whom  Global variables  Workflow model: “program”  BPEL4WS is an orchestration language; executable  WS-CDL (Web Services Choreography Description Language) is a choreography language; not executable

42. 42 Overview  Services, service description, service communication  Service-Oriented Architecture (SOA)  Web services  SOSE: Service-Oriented Software Engineering

43. 43 SOSE life cycle Service oriented analysis Service oriented design Service development Service testing Service deployment Service administration

44. 44 Terminology  service oriented environment (or service oriented ecosystem)  business process + supporting services  application (infrastructure) service  business service  Task-centric business service  Entity-centric business service  hybrid service

45. 45 Terminology order fulfilment service purchase order service send utility service wrapper service customer profile service hybrid services business services infrastructure services entity-centric verify PO service task-centric notification service hybrid services business services infrastructure services task centric entity centric

46. 46 Strategies for life cycle organization  Top-down strategy  Bottom-up strategy  Agile strategy

47. 47 Top-down strategy Service oriented analysis Service oriented design Service development Service testing Service deployment

48. 48 Top-down SO analysis Define enterprise business models Define enterprise service model Compose SOA Perform service oriented analysis Service oriented design.... step 1step 2 step 3step 4 step 1 step 4step 3 step 2

49. 49 Bottom-up strategy Model application services Design application service Develop application services Test services Deploy services application service = infrastructure service

50. 50 SO analysis SO design Develop services Test service operations Deploy services Revisit business (and process) services Top-down analysis on-going align with current state business models align with current state business models Agile strategy

51. 51 Service oriented analysis  The process of determining how business automation requirements can be represented through service orientation

52. 52 Goals of SO analysis Appropriateness for intended use Identify preliminary issues that may challenge required service autonomy Define known preliminary composition models Service operation candidates Service candidates (logical contexts)

53. 53 3 Analysis sub-steps Service oriented analysis Service oriented design Define analysis scope Identify automation systems Model candidate services step 3 step 2 step 1...

54. 54 Step 1: Define analysis scope  Mature and understood business requirements  S = ∑i Si, where smaller services may still be quite complex  Can lead to  process-agnostic services/service operations (generic service portfolio)  services delivering business-specific tasks  Models: UML use case or activity diagrams

55. 55 Order Fulfillment Process start receive PO validate PO PO valid Transform PO Import PO Send PO to queue stop Send notification yes no

56. 56 Step 2: Identify automation systems  What is already implemented?  encapsulate  replace  Models: UML deployment diagram, mapping tables

57. 57 Order Fulfillment Process start receive PO validate PO PO valid Transform PO Import PO Send PO to queue stop Send notification yes no already automated by Order fulfillment service same as previous same as previous (XML -> native format) (currently custom component) service candidate (into accounting sys.) service candidate (currently custom legacy) service candidate (to accounting clerk's work queue) same as previous

58. 58 Step 3: Model candidate services  How to compose services?  Service (candidates) conceptual model  operations + service contexts  SO principles  Focus on task- and entity-centred services  Models: BPM, UML use case or class diag.

59. 59 Example service operation candidates Receive PO document PO processing service Validate PO document (If PO document is invalid,) send rejection notification (and end process) Transform PO document into native electronic PO format >...

60. 60 Example business process logic  Not service operation candidates  if PO document is valid, proceed with the transform PO document step  if the PO document is invalid, end process

61. 61 Task- versus entity-centred services  Task-centred  (+) direct mapping of business requirements  (-) dependent on specific process  Entity-centred  (+) agility  (-) upfront analysis  (-) dependent on controllers

62. Reference  SE, Servic Orientation, Hans van Vliet 62