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

2 May 2007

Copyright © 2007 Data Access Technologies, Inc.

A division of Data Access Technologies, Inc.

Model Driven Service Oriented Architecture

Ed Seidewitz

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.


Agenda

1. Coming to Terms

2. Business Architecture

3. Solution Architecture

4. Technical Architecture


1. Coming to Terms

• Model Driven

• Service Oriented

• Enterprise

• Architecture


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

1Ed Seidewitz, “What Models Mean,” IEEE Software, September/October 2003

2Object Management Group, MDA Guide Version 1.0.1


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)


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

1Currently under development in response to an OMG RFP.


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

1The Open Group, SOA Definition V

2Object Management Group, SOA SIG, Draft SOA Definition, April 2006


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.


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

1Interoperability Clearinghouse Glossary, http://www.ichnet.org/glossary.htm


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.

1Interoperability Clearinghouse Glossary, http://www.ichnet.org/glossary.htm

2Department of Defense, DOD Dictionary of Military and Associated Terms, Joint Publication 1-02

3John Zachman


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.

Architecture provides the bridge between desires of the client and the capabilities of available technology.


2. Business Architecture

• Example: Financial Management Enterprise Architecture

• The business context

• Service-oriented business architecture

• How to model business processes

• How to model information


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.


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).


Financial Management Business Context

External ParticipantExternal Participant

FocusProvided service

Provided service

Consumed 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


Composite Billing Service Contract

Service providerService provider

Service consumerService

consumer

Nested serviceNested service


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…

First the submitter submits a bill to the receiver…

…then either the bill is successfully delivered or it is returned.

…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.

Note that, while one Participant requests the service and the other

responds, information may flow both ways during the interaction.


Financial Management Enterprise Context

Other enterprise level participants

Other enterprise level participants

• The service-oriented business architecture of an enterprise is modeled as a Collaboration of enterprise-level Participants.

• The service-oriented business architecture of an enterprise is modeled as a Collaboration of enterprise-level Participants.


Financial Management Business ArchitectureService representing delegated responsibility for interaction with

an external participant.

Service representing delegated responsibility for interaction with

an external participant.

Service representing interaction with another participant within

Financial Management.

Service representing interaction with another participant within



Realizing a Composite Service Contract (1)

Financial Management is responsible for providing a number of Acquisition

Accounting services.

Financial Management is responsible for providing a number of Acquisition

Accounting services.


Realizing a Composite Service Contract (2)

Acquisition is an External Consumer relative to


Acquisition is an External Consumer relative to


The Acquisition Accounting Services are delegated to a number of different

Participants within Financial Management.

The Acquisition Accounting Services are delegated to a number of different

Participants within Financial Management.


Receivables Accounting Business ArchitectureParticipants at this level

could roughly be individual people or system functions.

Participants at this level could roughly be individual people or system functions.

Internal interactions needed to carry out the

required business services.

Internal interactions needed to carry out the

required business services.

Business service provided and consumed by

Receivables Accounting.

Business service provided and consumed by

Receivables Accounting.


Receivables Management Activities

• Workflow is modeled using UML Activities.

• Workflow is modeled using UML Activities.

Received eventReceived event

ActivityActivity Sent eventSent event

Information flowInformation flow


Establish Unfilled Customer Order Subactivities

SubactivitySubactivity

Input parameters

Input parameters

Output parameter

Output parameter

Internal information flow

Internal information flow

• Complicated activities may be decomposed into subactivities.

• Complicated activities may be decomposed into subactivities.


Record Unfilled Customer Order Behavior

Control flowControl flow

• Ultimately, behavior can be specified using basic UML Activity Diagrams.

• Ultimately, behavior can be specified using basic UML Activity Diagrams.


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.

• Detailed requirements and business rules can be documented for activities separately from the process flow.


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.

A term in the vocabulary represents a class of things to be described.

Attributes specify descriptive information having simple types.

Attributes specify descriptive information having simple types.

Entities may be described as having a unique identity.

Entities may be described as having a unique identity.

A relation between terms is described by an association between classes.

A relation between terms is described by an association between classes.

A class may be specialized into sub-classifications.

A class may be specialized into sub-classifications.

An un-shaded class is not detailed on this diagram.


Information Model: What Is It For?

Business transaction Business transaction

The information model details the vocabulary of the business entities and transactions used in the process model.

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.

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


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 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.

A business entity represents the current state of information that may change over time.


3. Solution Architecture

• Example: Core Financial Management System • Service-oriented component architecture • How to model components • How to specify functionality • How to model data


From Business Architecture to System Architecture

Financial Management Discipline

Protocols

Enterprise RolesWork Roles

Activities

Information ModelClasses

Financial Management Discipline

Protocols

Enterprise RolesWork Roles

Activities

Information ModelClasses

Core Financial System Specification

Service Interfaces

Work ComponentsService Manager Components

Behavioral Specifications

Message SpecificationsData Manager Components

Persistent Data Specifications


Service Interfaces





Business Architecture Logical System Architecture


Three-Tier Component Architecture

Presentation Components provide user access to application services.

Presentation Components provide user access to application services.

Service Components provide transactional implementation of application services.

Service Components provide transactional implementation of application services.

Data Components persist data between application transactions.

Data Components persist data between application transactions.

• System architecture is modeled using UML Components.

• System architecture is modeled using UML Components.

Component

Port

Connector allowing bidirectional communication

Simple unidirectional usage dependency


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.

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.

The operations defined on Service Interfaces provide the basis for bidirectional service interactions.


Port Types from Service Contracts

The Participant Types act as the Service Interfaces.The Participant Types act as the Service Interfaces.


Port Types for Composite Service Contracts

Participant Types get ports corresponding to the roles they play in each of the nested services.

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.

The types of the ports are the Port Types defined for the nested services.


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 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.

The Service Component gets a port corresponding to each roles played by the indicated participant.


Complete Financial Management Component


Financial Management Business Architecture(from Business Model)


Financial Management Component Architecture

Delegation of a provided service to an internal part.

Delegation of a provided service to an internal part.

Internal service connectionInternal service connection

A composite service can be delegated piecewise to multiple internal parts.

A composite service can be delegated piecewise to multiple internal parts.

Delegation of a consumed service by an internal part.

Delegation of a consumed service by an internal part.


Receivables Accounting Business Architecture(from Business Model)


Receivables Accounting Component Architecture

User of a consumed service by multiple internal parts.

User of a consumed service by multiple internal parts.


Receivables Management Activities (from Business Model)

Related to Customer Orders

Related to Receivables


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 Establish Customer Order activity.

Implements the Generate Recurring Receivable and Establish and Accrue Revenue activities.

Implements the Generate Recurring Receivable and Establish and Accrue Revenue activities.


Establish Unfilled Customer Order Activities (from Business Model)


Record Unfilled Customer Order Behavior(from Business Model)


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


Billing Component Architecture

Human interaction is integral to the discrepancy resolution process

Note that data managers may be shared across component architectures.

Note that data managers may be shared across component architectures.


Bill Discrepancy Management Service

The behavior of this service defines required human work flow as part of the implementation of the business process.

The behavior of this service defines required human work flow as part of the implementation of the business process.


Handle Billing Discrepancy Process

Required human interaction


Data Models

• Message Model

• Persistence Model


Example Transaction Information Model (from Business Model)

Business Transaction

Business Entity


Example Transaction Message Model

Message

Namesake• Messages can be modeled by “marking up” the information model.

• Messages can be modeled by “marking up” the information model.

Messages are based on business transactions and constructed from namesakes of business entities.

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.

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

Restricted realization allows for explicit inclusion and exclusion of attributes and associations


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.

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.


Example Persistence ModelIndicates a reference to an entity persisted elsewhere.

Indicates an entity persisted in this data manager.

Indicates a separately persisted relation.


4. Technical Architecture

• Example: Core Financial System Implementation

• Web Services



Service Interfaces






Service Interfaces





From System Architecture to System Implementation

Core Financial System Implementation

Web Services

System ComponentsSystem Functions

XML SchemasData Bases

Data Base Schemas

Core Financial System Implementation

Web Services

System ComponentsSystem Functions

XML SchemasData Bases

Data Base Schemas

System ImplementationLogical System Architecture


Example Implementation Architecture

Infrastructure

Legacy Client

System(s)

AdapterD

ata T

ier

Adapter

FunctionT

ier

FM

EA

Data

Tier

FM

EA

A

pplication T

ier

Mom

entum

Integration

Tier

Back EndEnterpriseSystems

FM

EA

P

resentation T

ier

LegacyAdapters

Core Financial Management

System

Back EndIntegration

Legacy Client Interface

Legacy Client Interface

Provided Service Interface

Provided Service Interface

Consumed Service Interface

Consumed Service Interface

Back End System 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

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


From Service Model to Web Service Implementation

Logical View

Physical View

A single bidirectional connection between consumer and provider service ports.

A single bidirectional connection between consumer and provider service ports.

The consumer requests services via the provider’s port.The consumer requests services via the provider’s port.

The provider “calls back” via the consumer’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.

For synchronous services, an alternative is to map “call back” operations into return types.

Web services port

Web services port type


Example Web Services Generation

<wsdl:portType name=“BillSubmission.BillSubmissionReceiverInterface"> <wsdl:operation name=“submitBill"> <wsdl:input message="tns:BillSubmissionCluster“ name=“billSubmission"> </wsdl:input> </wsdl:operation> </wsdl:portType>

<wsdl:portType name=“BillSubmission.BillSubmissionSubmitterInterface"> <wsdl:operation name=“notifyBillDelivered"> <wsdl:input message="tns:BillDeliveredCluster“ name=“billDelivered"> </wsdl:input> </wsdl:operation> <wsdl:operation name=“notifyBillReturned"> <wsdl:input message="tns:BillReturnedCluster“ name=“billReturned"> </wsdl:input> </wsdl:operation> </wsdl:portType>


Example Transaction Message XML Document<BillSubmissionCluster>

<BusinessTransaction><transactionID> … </transactionID>

</BusinessTransaction><BillSubmission>

<bill><Bill>

<billID> … </billID><principleAmount> … </principleAmount>…

<payer><Party>

<partyID> … </customerID></Party>

</payer>…

<lineItems> … </lineItems>

</Bill> </bill>

<billingAddress><BillingAddressCluster>

<Address> … </Address><BillingAddress> … </BillingAddress>

</BillingAddressCluster><billingAddress>

</BillSubmission></BillSubmissionCluster>

<BillSubmissionCluster><BusinessTransaction>

<transactionID> … </transactionID></BusinessTransaction><BillSubmission>

<bill><Bill>

<billID> … </billID><principleAmount> … </principleAmount>…

<payer><Party>

<partyID> … </customerID></Party>

</payer>…

<lineItems> … </lineItems>

</Bill> </bill>

<billingAddress><BillingAddressCluster>

<Address> … </Address><BillingAddress> … </BillingAddress>

</BillingAddressCluster><billingAddress>

</BillSubmission></BillSubmissionCluster>

Documents

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