1. A division of Data Access Technologies, Inc. 2 May 2007 Copyright © 2007 Data Access Technologies, Inc. Model Driven Service Oriented Architecture Ed Seidewitz

2. Page 2 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Goals of the Tutorial To understand how service oriented concepts can provide a common foundation for business, solution and technical architectures. To understand how to use modeling as the basis for creating successful service oriented architectures. To understand the relationship between service oriented solution models and Web Services solution implementation.

3. Page 3 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Agenda 1.Coming to Terms 2.Business Architecture 3.Solution Architecture 4.Technical Architecture

4. Page 4 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 1. Coming to Terms Model Driven Service Oriented Enterprise Architecture

5. Page 5 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Model Driven Model: A set of statements in some modeling language made in order to describe or specify some system. 1 Model Driven: Using models as primary artifacts to direct the course of understanding, design, construction, deployment, operation, maintenance and modification of a system. 2 Model Driven Architecture ™ : An (OMG) approach to system specification that separates (models for) the specification of functionality from the specification of the implementation of that functionality on a specific technology platform. 2 1 Ed Seidewitz, “What Models Mean,” IEEE Software, September/October 2003 2 Object Management Group, MDA Guide Version 1.0.1

6. Page 6 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Model Driven Architecture Computation Independent Model (CIM) –The business model Platform Independent Model (PIM) –Technology independent system specification –Conforms to the business model (CIM) Platform Specific Model (PSM) –Technology specific (e.g., middleware, application platform, etc.) system design –Conforms to the system specification (PIM) Object Management Group Terminology (as applied here)

7. Page 7 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Modeling Approach Models will be expressed in the Unified Modeling Language (UML) –Using a proposed UML Profile and Metamodel for Services (UPMS) 1 –Based on experience with service-oriented business modeling using the older Enterprise Distributed Object Computing (EDOC) Component Collaboration Architecture standard The models become primary artifacts –To the greatest extent possible, technology-specific products are generated from the models –Generated artifacts may be augmented, but not replaced, by hand- coded artifacts as necessary –No “round trip” engineering 1 Currently under development in response to an OMG RFP.

8. Page 8 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Service Oriented Service: A logical representation of a repeatable business activity that has a specified outcome, is self-contained and maybe composed of other services and is a black box to consumers of the service. 1 Service Oriented: A way of thinking in terms of services and service based development and the outcomes that services bring. 1 Service Oriented Architecture: An architectural style for a community of providers and consumers of services to achieve mutual value, that: 2 –Allows participants in the community to work together with minimal co- dependence or technology dependence –Specifies the contracts to which organizations, people and technologies must adhere in order to participate in the community –Provides for business value and business processes to be realized by the community –Allows for a variety of technologies to be used to facilitate interactions within the community 1 The Open Group, SOA Definition V 2 Object Management Group, SOA SIG, Draft SOA Definition, April 2006

9. Page 9 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Perspectives on “Service Oriented Architecture” SOA is: An enterprise and business architecture approach – a way to understand and integrate the enterprise in the context of its community and as a network of business services. “A SOA” at the business level is part of the enterprise architecture showing how this network of services delivers business value A system of systems solution architecture – a way to understand and integrate enterprise systems internally and externally as a network of technology services. “A SOA” at the systems of systems level is the solutions architecture showing how this network of systems works together to delivers business value. A system integration approach – a way to expose existing capabilities to integrate applications and create new composite solutions.

10. Page 10 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Enterprise Enterprise: A system of business endeavor within a particular business environment. 1 Enterprise Architecture: A design for the arrangement and interoperation of business components (e.g., policies, operations, infrastructure, information) that together make up the enterprise's means of operation. 1 1 Interoperability Clearinghouse Glossary, http://www.ichnet.org/glossary.htmhttp://www.ichnet.org/glossary.htm

11. Page 11 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Architecture Architecture: Design; the way components fit together. 1 Architecture: A framework or structure that portrays relationships among all the elements of the subject force, system, or activity. 2 These definitions miss the point! Architecture: A set of design artifacts, or descriptive representations, that are relevant for describing an object such that it can be produced to requirements (quality) as well as maintained over the period of its useful life (change). 3 This one is closer. 1 Interoperability Clearinghouse Glossary, http://www.ichnet.org/glossary.htmhttp://www.ichnet.org/glossary.htm 2 Department of Defense, DOD Dictionary of Military and Associated Terms, Joint Publication 1-02 3 John Zachman

12. Page 12 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Architecture – as a practice Architecture: The practice of finding creative design solutions that meet the needs of the client, fit the environment in which they are to be deployed, and are feasible to implement. Architecture provides the bridge between desires of the client and the capabilities of available technology.

13. Page 13 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 2. Business Architecture Example: Financial Management Enterprise Architecture The business context Service-oriented business architecture How to model business processes How to model information

14. Page 14 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Example: Financial Management Enterprise Architecture A simplified Financial Management Enterprise Architecture for a Federal Government agency (also largely applicable to commercial financial management) Consistent with the Federal Financial Management Line of Business architecture Based on work done for the General Services Administration (GSA) that delivered: –A target business architecture for consistent and comprehensive financial management supporting all GSA services and staff offices. –A logical system architecture for a cohesive financial management suite supporting the business architecture, particularly in areas in which a transition needed to be made off legacy systems. –A set of interface definitions to act as the basis for a standard GSA financial management service-oriented architecture.

15. Page 15 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Fundamental Concepts Participant: A specification of the responsibility to perform specific functions in the context of a business process. Collaboration: A set of two or more participants interacting to carry out a business process to achieve some joint purpose. Service Contract: A collaboration that defines a conversation in which a service or services is provided to consumers by providers. This conversation may be extended over time (i.e., responses of one participant to the other may not be immediate).

16. Page 16 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Financial Management Business Context External Participant Focus Provided service Consumed service A Service Contract is modeled as a UML Collaboration. An interaction between participants conforming to a contract is modeled as a UML Collaboration Use. A Collaboration via Service Contracts defines an SOA Business Model. A Service Contract is modeled as a UML Collaboration. An interaction between participants conforming to a contract is modeled as a UML Collaboration Use. A Collaboration via Service Contracts defines an SOA Business Model. Role binding Collaboration Use Role

17. Page 17 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Composite Billing Service Contract Service provider Service consumer Nested service

18. Page 18 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Simple Bill Submission Service Contract A service contract is modeled as a UML Collaboration. The required conversation may be specified using an Owned Behavior (e.g., Interaction or Activity) A service contract is modeled as a UML Collaboration. The required conversation may be specified using an Owned Behavior (e.g., Interaction or Activity) Indicates ownership First the submitter submits a bill to the receiver… …then either the bill is successfully delivered or it is returned. Note that, while one Participant requests the service and the other responds, information may flow both ways during the interaction.

19. Page 19 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Financial Management Enterprise Context Other enterprise level participants The service-oriented business architecture of an enterprise is modeled as a Collaboration of enterprise-level Participants.

20. Page 20 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Financial Management Business Architecture Service representing delegated responsibility for interaction with an external participant. Service representing interaction with another participant within Financial Management.

21. Page 21 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Realizing a Composite Service Contract (1) Financial Management is responsible for providing a number of Acquisition Accounting services.

22. Page 22 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Realizing a Composite Service Contract (2) Acquisition is an External Consumer relative to Financial Management. The Acquisition Accounting Services are delegated to a number of different Participants within Financial Management.

23. Page 23 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Receivables Accounting Business Architecture Participants at this level could roughly be individual people or system functions. Internal interactions needed to carry out the required business services. Business service provided and consumed by Receivables Accounting.

24. Page 24 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Receivables Management Activities Workflow is modeled using UML Activities. Received event Activity Sent event Information flow

25. Page 25 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Establish Unfilled Customer Order Subactivities Subactivity Input parameters Output parameter Internal information flow Complicated activities may be decomposed into subactivities.

26. Page 26 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Record Unfilled Customer Order Behavior Control flow Ultimately, behavior can be specified using basic UML Activity Diagrams.

27. Page 27 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Record Unfilled Customer Order Requirements Record Unfilled Customer Order Description Record a new unfilled customer order, as established via a specific sales agreement. Requirements 1.Generate general ledger transactions to increase Unfilled Customer Orders and decrease Anticipated Reimbursements. 2.If the Customer Order is against a Sales Agreement that requires recurring payments, establish a recurring receivable. 3.… Record Unfilled Customer Order Description Record a new unfilled customer order, as established via a specific sales agreement. Requirements 1.Generate general ledger transactions to increase Unfilled Customer Orders and decrease Anticipated Reimbursements. 2.If the Customer Order is against a Sales Agreement that requires recurring payments, establish a recurring receivable. 3.… Detailed requirements and business rules can be documented for activities separately from the process flow.

28. Page 28 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Information Model This means “zero or more” This means “one or more” This indicates a compositional (as opposed to referential) association. This is a constraint that defines the sub-classification. A term in the vocabulary represents a class of things to be described. Attributes specify descriptive information having simple types. Entities may be described as having a unique identity. A relation between terms is described by an association between classes. A class may be specialized into sub- classifications. An un-shaded class is not detailed on this diagram.

29. Page 29 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Information Model: What Is It For? Business transaction The information model details the vocabulary of the business entities and transactions used in the process model. The process model describes how business activities are (or are to be) carried out. State changes due to the activities Workflow Activities Implicit memory of business information

30. Page 30 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Information Model: Entities and Transactions For example, the billing address for a party being billed may change over time, but the billing address used for a specific bill submission always stays the same. Note the use of composition associations A business transaction represents a snapshot of the information required to carry out a business action. A business entity represents the current state of information that may change over time.

31. Page 31 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 3. Solution Architecture Example: Core Financial Management System Service-oriented component architecture How to model components How to specify functionality How to model data

32. Page 32 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 From Business Architecture to System Architecture Financial Management Discipline Protocols Enterprise Roles Work Roles Activities Information Model Classes Financial Management Discipline Protocols Enterprise Roles Work Roles Activities Information Model Classes Core Financial System Specification Service Interfaces Work Components Service Manager Components Behavioral Specifications Message Specifications Data Manager Components Persistent Data Specifications Core Financial System Specification Service Interfaces Work Components Service Manager Components Behavioral Specifications Message Specifications Data Manager Components Persistent Data Specifications Business Architecture Logical System Architecture

33. Page 33 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Three-Tier Component Architecture Presentation Components provide user access to application services. Service Components provide transactional implementation of application services. Data Components persist data between application transactions. System architecture is modeled using UML Components. Component Port Connector allowing bidirectional communication Simple unidirectional usage dependency

34. Page 34 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Provided and Required Interfaces Provided interfaceRequired interface RealizationUsage dependency Ports with “conjugate” interfaces may be interconnected. Ports are typed by Port Types that realize and use service interfaces. The operations defined on Service Interfaces provide the basis for bidirectional service interactions.

35. Page 35 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Port Types from Service Contracts The Participant Types act as the Service Interfaces.

36. Page 36 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Port Types for Composite Service Contracts Participant Types get ports corresponding to the roles they play in each of the nested services. To have ports, the Participant Types need to be classes rather than interfaces. The types of the ports are the Port Types defined for the nested services.

37. Page 37 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Service Components from Service Architectures The Plays Role dependency specifies the interfaces of a service component by declaring how it is to participate in the business architecture. The Service Component gets a port corresponding to each roles played by the indicated participant.

38. Page 38 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Complete Financial Management Component

39. Page 39 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Financial Management Business Architecture (from Business Model)

40. Page 40 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Financial Management Component Architecture Delegation of a provided service to an internal part. Internal service connection A composite service can be delegated piecewise to multiple internal parts. Delegation of a consumed service by an internal part.

41. Page 41 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Receivables Accounting Business Architecture (from Business Model)

42. Page 42 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Receivables Accounting Component Architecture User of a consumed service by multiple internal parts.

43. Page 43 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Receivables Management Activities (from Business Model) Related to Customer Orders Related to Receivables

44. Page 44 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Receivables Management Component Architecture Explicit component for scheduling triggers Explicit cross- transactional coupling via the data tier Implements the Establish Customer Order activity. Implements the Generate Recurring Receivable and Establish and Accrue Revenue activities.

45. Page 45 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Establish Unfilled Customer Order Activities (from Business Model)

46. Page 46 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Record Unfilled Customer Order Behavior (from Business Model)

47. Page 47 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Record Unfilled Customer Order Functional Specification 1.Receive CustomerOrderEstablishment 2.Let newOrder = CreateCustomerOrder(CustomerOrderEstablishment.newOrder).data 3.Send GeneralLedgerTransaction to increase Unfilled Customer Orders and decrease Anticipated Reimbursements 4.Send newOrder as RecurrentCustomerOrder (Note: EstablishRecurringReceivables will check if there are actually any creation triggers.) 5.Send CustomerOrderEstablished 1.Receive CustomerOrderEstablishment 2.Let newOrder = CreateCustomerOrder(CustomerOrderEstablishment.newOrder).data 3.Send GeneralLedgerTransaction to increase Unfilled Customer Orders and decrease Anticipated Reimbursements 4.Send newOrder as RecurrentCustomerOrder (Note: EstablishRecurringReceivables will check if there are actually any creation triggers.) 5.Send CustomerOrderEstablished

48. Page 48 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Billing Component Architecture Human interaction is integral to the discrepancy resolution process Note that data managers may be shared across component architectures.

49. Page 49 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Bill Discrepancy Management Service The behavior of this service defines required human work flow as part of the implementation of the business process.

50. Page 50 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Handle Billing Discrepancy Process Required human interaction

51. Page 51 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Data Models Message Model Persistence Model

52. Page 52 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Example Transaction Information Model (from Business Model) Business Transaction Business Entity

53. Page 53 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Example Transaction Message Model Message Namesake Messages can be modeled by “marking up” the information model. Messages are based on business transactions and constructed from namesakes of business entities. Realization is used to “mark up” information model elements with message model elements. Restricted realization allows for explicit inclusion and exclusion of attributes and associations

54. Page 54 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Equivalent Message Structure This is the equivalent message structure resulting from the mark up of the information model. If this message structured was modeled independently, then it would have to be updated in parallel every time the corresponding information model elements where updated.

55. Page 55 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Example Persistence Model Indicates a reference to an entity persisted elsewhere. Indicates an entity persisted in this data manager. Indicates a separately persisted relation.

56. Page 56 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 4. Technical Architecture Example: Core Financial System Implementation Web Services

57. Page 57 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Core Financial System Specification Service Interfaces Work Components Service Manager Components Behavioral Specifications Message Specifications Data Manager Components Persistent Data Specifications Core Financial System Specification Service Interfaces Work Components Service Manager Components Behavioral Specifications Message Specifications Data Manager Components Persistent Data Specifications From System Architecture to System Implementation Core Financial System Implementation Web Services System Components System Functions XML Schemas Data Bases Data Base Schemas Core Financial System Implementation Web Services System Components System Functions XML Schemas Data Bases Data Base Schemas System ImplementationLogical System Architecture

58. Page 58 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Example Implementation Architecture Infrastructure Legacy Client System(s ) Adapter Data Tier Adapter Function Tier FMEA Data Tier FMEA Application Tier Momentum Integration Tier Back End Enterprise Systems FMEA Presentation Tier Legacy Adapters Core Financial Management System Back End Integration Legacy Client Interface Provided Service Interface Consumed Service Interface Back End System interface The “top down” solution architecture must be informed by what exists and existing capabilities should be exposed and integrated based on a system of systems architecture

59. Page 59 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 From Service Model to Web Service Implementation Logical View Physical View A single bidirectional connection between consumer and provider service ports. The consumer requests services via the provider’s port. The provider “calls back” via the consumer’s port. For synchronous services, an alternative is to map “call back” operations into return types. Web services port Web services port type

60. Page 60 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Example Web Services Generation <wsdl:input message="tns:BillSubmissionCluster“ name=“billSubmission"> <wsdl:input message="tns:BillDeliveredCluster“ name=“billDelivered"> <wsdl:input message="tns:BillReturnedCluster“ name=“billReturned">

61. Page 61 Copyright © 2007 Data Access Technologies, Inc. 2 May 2007 Example Transaction Message XML Document … … … … … … … … … … … …