23. Service-Oriented Architectures

Transcription

1 23. Service-Oriented Architectures Slide 1

2 Acknowledgements: Material on Service-Oriented Architectures Based on a tutorial by Grace Lewis et al. + Slides by Michael Brodie (with minor adaptations) Slide 2

3 SOA Objective Business Processes Payroll Retail Manf. ERP CRM Enterprise Workplace (Interaction Platform) Infrastructure/Mgmt./ Infrastructure/Mgmt./ Security Security Business Services (Integration Suite) Servers Infrastructure/Mgmt./ Security Database Storage Trans. proc. Information Services (Information Fabric) Web host. File/print Infrastructure Platform Slide 3

4 The Age of Integration Slide 4

5 Landscape: Islands of Automation Dataflow flowto touser user Data Human Resources Dataflow flowto touser user Data Manufacturing Dataflow flowto touser user Data Financial Dataflow flowto touser user Data Sales Dataflow flowto touser user Data Purchasing Purchasing Purchasing system system Sales Salestracking tracking system system Financial Financial systems systems Inventory Inventory&& manufacturing manufacturing systems systems Human HumanResources Resources systems systems Slide 5

6 The Business Integration Imperative Integration across enterprise applications and databases can create significant opportunities for enterprises to provide a single unified face to the customer and stimulate efficient end-to-end processes. Applications in Service Providers Autonomous Divisions New Applications Purchased Packages Legacy Applications End-User Development Applications in Trading Partners Applications From Mergers and Acquisitions Outsourced Applications Slide 6

7 Interoperability The ability of two or more applications to share data and services (Lack of) Interoperability is a serious impediment to developing cross-enterprise (e.g., e-business) applications As interoperability needs increase, the complexity of building and maintaining application programming interfaces (APIs) & shared services between enterprise applications that cross enterprise boundaries increase substantially ( e.g., virtual organizations) Interoperability mechanisms are often classified into Syntactic applications use the same format for data, processes Semantic data and processes actually have the same meaning Slide 7

8 Interoperability Woes Business implementations automate only a small portion of BPs For example, ordering & distribution of goods may be fast, but the supporting accounting & inventory info., payment & funds transfer lag as there is no communication between BPs and legacy data This decoupling of accounting & payment info. from the ordering & delivery of goods & services, increases transaction credit risks & introduces discrepancies between the various information sources, requiring expensive and time-consuming reconciliation Today's business must be based on a common set of protocols that ensure interoperability Slide 8

9 Integration: the Big Picture Fundamental Change for Integration: X Y Pre-SOA: outside, after development Post-SOA: inside, integral part of development / computational model Consequences How should integration be done? Innovation and experimentation Integration-in-context: Competition, expansion, consolidation Conclusions Opportunity: Re-thinking integration Basic research Near-term chaos SOA + ecosystem time line: (not quite done yet) Slide 9

10 The History of Integration : Integration = develop then integrate 1950s-1970s: Simple, manual integration 1970s-1980s: Distributed Computing Applications (interoperation) Databases (integrate) 1990s: Business-Driven Integration concepts, technologies, and tools increased automation, internet-based computing Concepts: Workflows, Business Processes, Web, Integration solutions blossom & diverge: ETL, EAI, BPM, 2000: SOA Emerges 2000: Web services 2003: Integration solution evolution accelerates, vendor chaos ensues 2005: Growth in all integration categories : Integration = dominant programming model : Wrapping : Re-Engineering : Consolidation : Emergence of SOA Platforms and Solutions : Problem Solving Era: IT/integration relegated to low level function F. Dalpiaz J. Mylopoulos -- OIS Michael & Brodie Slide 10

11 The Challenge Maurits Cornelis Escher Slide 11

12 The SOA Vision SOA consists of an intra-/inter-organizational environment where any service can invoke any other (possibly remote) service What is a service? A service is a function delivered by one actor to another Service = contract + terms + QoS For example, food service (trattoria) vs food service at the mensa Making food at home (not a service!) Many types of services Business services Data services Infrastructure services Slide 12

13 Services A service consists of: Contract what does the service do (optionally) Terms define properties on the service, such as atomicity, isolation, security protection, transparency, what happens if the service fails Quality-of-Service (QoS) these are conditions on the delivery of the service and may relate to performance, reliability, timing, You can think of a service as a generalized procedure (as in Programming Languages), but it is delivered by one party to another and this raises all sorts of what-if questions Slide 13

14 Services... at the system level Slide 14

15 Services and Cost Efficiency Slide 15

16 Services and Agility Slide 16

17 Services and Adaptability Slide 17

18 Services and Legacy Leverage Slide 18

19 Components of a SOA-based system Slide 19

20 Services (IBM WebSphere) Connectivity services Event services Transport services Mediation services Business logic services Partner services Community services Document services Protocol services Business application services Component services Core services Interface services Application and information access Event detection services On-ramp services Control services Interaction services Delivery services Experience services Resource services Process services Choreography services Transaction services Staff services Information services Federation services Replication services Transformation services Search services Development Services Model Services Design Services Implementation Services Test services Slide 20

21 Example: Event Services IBM's version: www6.software.ibm.com/software/developer/ library/autonomic/books/cbepractice One of the critical first principles required for common management of applications is that each component and subsystem represents its states and events in a common way The Web Services Distributed Management (WSDM) standard offers one set of instrumentation to manage resources As part of the WSDM standard, the WSDM Event Format (WEF), defines a common format for defining and representing events The Common Base Event is IBM's initial implementation of WEF Slide 21

22 Services: in Summary Slide 22

23 Myths about SOA Slide 23

24 Myth #1: Easy Transition Slide 24

25 Myth #2: Standards Slide 25

26 Myth #3: XML/WSDL Panacea Slide 26

27 Myth #3 Illustrated Chunk of a WSDL service description: <service name="stockquoteservice"> <documentation>my first service</documentation> <port name="stockquoteport" binding="tns:stockquotesoapbinding"> <soap:address location=" </port> </service> Syntax is defined but where is semantics? I.e. can a machine univocally interpret what service StockQuoteService is for? Slide 27

28 Myth #4: It's all about technology Slide 28

29 Myth #4 & Governance According to an IBM white paper, SOA governance relies on: An Enterprise Service Bus (ESB), a flexible infrastructure that connects services and enables interoperability Registries to allow organizations track/search its services as well as knowing who is using them and how Reuse of services to avoid duplicate efforts SOA governance defines through policies and rules who s in charge An SOA lifecycle defines the methodology for SOA services from BP modelling to service development and composition Wohl associates. SOA Governance: an IBM white paper. October 18, 2006 Slide 29

30 Myth #5: Easy Development Slide 30

31 Myth #6: Self-composition Slide 31

32 Myth #7: Testing a Black-Box Slide 32

33 Myths: Summary Slide 33

34 A Closer Look at SOA Slide 34

35 The Old Days: No-Network Slide 35

36 The New Days: Distributed Network Slide 36

37 The Newer Days: SOA Slide 37

38 The 3 Basic SOA Operations Slide 38

39 Static vs. Dynamic Slide 39

40 Service Discovery Slide 40

41 Service Registry Slide 41

42 Service Composition Slide 42

43 Service Invocation Slide 43

44 Requirements for successful SOA SOA environments constitute a natural path of evolution for many systems In order to take full advantage of a SOA environment, services should have the following characteristics: Reusable Have a discoverable contract Loosely coupled Stateless Slide 44

45 Behind the Interface New Service Wrapped Service Service Consumer Composite Service Service interface Service implementation The consumer perceives no difference! Non-SOA applications Gartner Research Service-Oriented Architecture Under the Magnifying Glass by Yefim Natis, Application Integration & Web Service, Summit 2005, April 18-20, 2005 Slide 45

46 Building a SOA-based system See Myth #4 Necessary, but not sufficient For more SOA, take the following Laboratory of Service Design and Engineering Laboratory of Business Process Management and integration Slide 46

47 Service Choreography A choreography model describes a collaboration between a collection of services in order to achieve a common goal. It captures the interactions in which the participating services engage And the dependencies between these interactions, including control-flow dependencies, data-flow dependencies, message correlations, time constraints, transactional dependencies, etc. Does not describe any internal action that occurs within a participating service that does not directly result in an externally visible effect Captures interactions from a global perspective, meaning that all participating services are treated equally Slide 47

48 Service Orchestration An orchestration model (known as executable model in BPEL) describes both communication actions and internal actions within a service Internal actions include data transformations and invocations to internal modules Orchestrations are executable processes that can be executed by an orchestration engine (the orchestrator) Slide 48