Powerpoint Slides

Independent Guidance for Service Architecture and Engineering

www.cbdiforum.com

Everware-CBDIMeta Model for SOAby John Dodd

Code Generation Conference

Cambridge, May 19th, 2007

© 2007 Everware-CBDI Inc2

Everware-CBDI Meta ModelAgenda

1. A word about SOA2. Purpose of Meta Model3. Format of Meta Model4. Special Features5. Development Process6. Manifestations of Service in Model7. Packages and their Content8. SOA Reference Models compared9. OMG’s UPMS Initiative


A Recently Merged Company

Specialist firm providing actionable guidance and support- Enabling structured, enterprise-level SOA- Guiding SOA Excellence and Adoption- Facilitating SOA standards- Publishing Research based best practices to 20,000 subscribers world-wide


Enables: access to existing resources, when exposed as services services new processes assembled from pre-existing services choice of services provider reuse and sharing of capabilities

A word about SOA

Service Oriented Architecture (SOA) is an architectural style that enables the assembly of systems from distributed, federated resources

Service

Service

Service

Service

Service

Payment

Inventory

ManufacturingLogistics

Ordering

Resource Resource Resource

Ticket Sales

Service

Service

Ticket Collection

Service

Service Service

Availability


Purpose of our Meta Model

Twin objectives to improve the quality of our own offerings to move the industry thinking around SOA forwards

A well-defined meta model provides a solid foundation for

Service Architecture & Engineering Knowledge Base

Consultancy Engagements CBDI Journal Articles Repository Design for tools

supporting SOA process

By getting our own ideas clear, we can better contribute to SOA standardization efforts

by placing our own meta model in the public domain after consultation with our client base

seeking wider industry approval for the model and definitions, probably by integrating it at some level with the efforts of standards groups


Format of Meta Model

Concept Diagrams drawn in UML Class Diagram notation represents SOA concepts plus relationships & attributes defines each concept attributes incomplete rules (invariants) not yet defined organized into dependent packages not a UML Profile

DEPLOYMENT AND RUNTIME PACKAGE

Deployment

Endpoint

+ name : string+ networkAddress : string+ WSDL binding name : string

accessed through alternative

*

1

Endpoint Operation

+ name : stringsupports

1..*

1

Internal Location

+ networkAddress : string

resides at

1..*

1

handles messages of

1..*

1

Service Instance

+ identifier : string

manages

*

1

Noderesidence for

*

hosts

*

1

hosts executing

*

*

Operation Specification

bound to

1..*

1

Technical Interface

access point for

*

1

Technical Operation

implemented by

*

1

offers

1..*

1


Special Features of our Meta Model

Services are linked to Business Modeling

Services are linked Solution Modeling / IT designs

Policies, the raw material for SOA governance, are covered by model

Service orientation is not limited to software

Recognizes the service concept is not confined to software services “a collection of functionality by which the needs of potential consumers

are satisfied by a provider according to a contract”

Less normalized and less opaque than UML & its profiles

A Service Architecture is modeled at three levels of abstraction …


Features of a Service Architecture

Defined at three Levels Specification Architecture Implementation Architecture Deployment Architecture

Organizes Services into Layers

Specification Architecture

(for consuming developers)

Deployment Architecture

(for operations)Implementation Architecture

(for service developers)


Service Architecture -- Specification Level

Process Services(orchestration layer)

ProductLifecycleServices

Core Business Services(“backbone” layer)

Customers Service

OrdersService

Products Service

Sales Process Services

Solution Layer(UI, dialog

management)

Utility Services(high reuse layer)Address Formatting Service

Underlying Services(not so easy to use)

Products inManufacturing

SystemProducts in

Inventory System

OrderingSystem

BillingApplication

Product LifeCycle System


Service Architecture -- Implementation Level

Process Services(orchestration layer)

ProductLifecycleServices

Core Business Services(the backbone layer)

Products Service

Sales Process Services

Solution Layer(UI, dialog

management)

«script»Products Life

Cycle Component

«script»Sales Process

Component

«component»Products

Component

Customers Service

OrdersService

«component»

Sales

Component

Underlying Services(not so easy to use)

Products InManufacturing Sys

Products InInventory Sys

«legacy»Manufacturing

System

«wrapper»ProductsAPI2

Wrapper«legacy»InventorySystem

Utility Services(high reuse layer)

AddressFormatting Service

«external»

Undefined

indicates an embedded data store

«application» Product Life

Cycle System

«application» Ordering System

«application» Billing

Application


Deployment Level

a: Client PC

Internet Explorer

SOAP over HTTP

an: ExternalHost

Address Formatting Service

SOAP over JMS

HTTP

RMI

Application Server

EJB Container

Oracle DBMS

JDBC

Sales ComponentProducts Component

InventoryDBSales DB

Mainframe

TP Monitor

DB2 DBMS

Manufacturing

System

Manufacturing DB

Orchestration Server

BPEL Engine

ProductsLife Cycle ComptSalesProcess Component

a: Web Server{opSys = WindowsNT}{webSvr = Apache}{nrDeployed = 4}

Servlet EngineOrdering and Billing AppsProduct LC System

SOAP EngineProducts LC ServiceSales Process ServiceProducts ServiceOrders ServiceCustomers ServiceProductsFromManufProductsFromInvnty

Protocol Adapter

Inventory System

Shows where Automation

Units are installed

“Proxies” since main

logic is elsewhere

“Proxies” accessing

logic hosted elsewhere

Wrapper logic runs

under SOAP Engine


Development Process for the Everware-CBDI meta model

Initial Meta Model published in October 2006 CBDI Journal Built to express concepts in SAE™ (Service Architecture & Engineering) Influenced by UML, less by UML Profile from IBM and OASIS-RM

Review with our client-base has just been completed Fortnightly teleconferences to discuss a MM View Web site for registering client issues Building version 2 meta model Then intend to place meta model in public domain

Participating in a group responding to OMG request for a “UML Profile & Meta Model for SOA”

to influence this response and to be influenced by response

Generally, to encourage convergence of SOA reference and meta models


Manifestations of Service within the Meta Model

ServiceSpecification

ServiceEndpoint

(Service)Deployment

Service Instance(at runtime)

Conceptual) Service

described in detail by1

*

1..*

*realized by

1..*defines capability available from

1..*

installed as

1..*

1..*

1

1..*

1..?

provides access to1..*

manages

Service Automation

Unit

realized by

*

*


Definition of these Service Manifestations

(Conceptual) Service

A collection of functionality by which the needs of potential consumers are satisfied by a provider according to a contract

Service Specification

A thorough description of what a service does, which does not define how it is realized or deployed. This includes operation behavior and quality constraints.

Service Automation Unit

The actual or planned implementation of a Software Specification. A collection of files containing executable code or scripts.

(The source code and the internal architectural design are not represented in this model).

Service Endpoint A network address at which a particular service is available. The message requesting a specific operation of a Service must be sent to the Endpoint appropriate to the transmission Protocol being used.

Deployment The installation of a Service Automation Unit on a Node. The node must support the programming languages or scripts used to construct the Automation Unit.

Service Instance A runtime instance of a deployed service, which can have a different state from other runtime instances of exactly the same service. Consuming software needs a means to select the appropriate service instance.


Meta Model Version 1 was divided into overlapping “Views”

Version 1 Model was limited to

software services, which might or might not be Web services

Business Modeling

Business Modeling

Solution

Modeling

Solution

Modeling

Service

Specification

Architecture

Service

Specification

Architecture

Service

Implementation

Architecture

Service

Implementation

Architecture

Service

Deployment

Architecture

Service

Deployment

Architecture

Runtime

Service

View

Runtime

Service

View

Service Specificatio

n Detail

Service Specificatio

n Detail

Planning & Provisioning

Policy

Planning & Provisioning

Policy


IMPLEMENTA- TION PACKAGE

DEPLOYMENT AND RUNTIME

SPECIFICATION PACKAGE

SERVICE PACKAGE

BUSINESS MODELING

SOFTWARE MODELING

ORGANIZATION PACKAGE

POLICY PACKAGE

TECHNOLOGY PACKAGE

«import»

«import»

«import»

«import»

«import»

«import»

«import»

«import»«import»

Meta Model (version 2) organized into dependent Packages

Version 2 Model incorporates nonsoftware services, and conceptual services within business models


Concepts in each Package

IMPLEMENTATIONAutomation UnitAuto. Unit DependencyProvided BehaviorRequired BehaviorTechnical InterfaceTechnical Operation

DEPLOYMENT & RUNTIMEDeploymentEndpointEndpoint OperationInternal LocationService Instance

SPECIFICATIONService Spec.Spec. Dependency

Service StateInterface (Port Type)Operation Spec.Pre- & Postcondition S. Information ModelInformation Type Message Spec.Message SequencePolicy Deviation ItemS. Level Agreement

SERVICE ServiceNonsoftware ServiceService ClassificationClassification GroupProposed Operation

BUSINESS MODELINGBusiness ServiceBusiness DomainBusiness CapabilityBusiness TypeProcessBusiness EventBusiness Rule Outcome, Policy OutcomeBusiness Objective/Goal

SOFTWARE MODELINGSoftware ServiceSoftware Service Spec.Application SpecificationUse CaseActor Use Case Step

ORGANIZATIONParty Party RoleOrganization Unit Person Post

POLICYPolicyPolicy TypePolicy ScopePolicy SubjectPolicy AlternativePolicy AssertionPolicy RelationshipService DomainArchitecture Layer and Rules

TECHNOLOGYNodeCommunication PathProtocolProcessorSoftware Execution

EnvironmentEnterprise Service

Bus


‘Reference Model’ Scope Comparison

Based on research carried out December 2006; published in CBDI Journal January 2007

++Security

++++Non-service software links

+++Solution Modeling links

+++Business Modeling links

++(Runtime) Management

+++++++++Policy for SOA

++Services at Runtime

+++Service Deployment

++++++Service Implementation

++++Reachability

++++++++Messages

+++++++++++++Service Desc. or Specification

++++Service Discovery

ECIMM for SAE

MODM3

Open GOntology

IBM UML

ProfileOASISRM-SOA

W3CWSA

Reference Model RM Area ↓

work in progress


UML Profile and Meta Model for SOA - RFP

A “Request for Proposal” issued by OMG in September 2006, asking for submissions by June 2007

Must extend standard UML, to cover “modeling and integrating services within and across the enterprise”

Aims: establish a common vocabulary to unify service definitions “support a service contract describing the collaboration between participating

service consumers and providers using mechanisms that clearly separate requirements and specification from realization”

integrate with and complement standards developed by other organizations

While avoiding: any particular methodology governance deployment and runtime dynamic binding service discovery end-user experience


UML Profile and Meta Model for SOA - Progess

Everware-CBDI involved in submission led by IBM

Proposal is more narrowly scoped than Everware-CBDI meta model

High focus on the idea that services collaborate to achieve anything

Started out with viewpoint: A Service is a kind of Port (interaction point) of a Component (the

“provider” software) A Service conforms to a Service Interface (= Type or Specification of

the Service) which defines a “protocol” for service interactions Business requirements can be expressed by a “service contract” which

defines the roles Providers must play to deliver the required business behavior

This is work in progress, involves heated debate, and it remains to be seen what emerges


Closing Comments

The meta model is an important asset for Everware-CBDI it is still undergoing change it underpins the SOA KnowledgeBase product we are developing we intend to make it public domain and offer to other organizations

The model is not currently detailed enough for code generation That has not been our goal It could be extended to generate code

signatures of operations messages logic derived from pre and post conditions

Any questions


Independent Guidance for Service Architecture and Engineering

www.cbdiforum.com

www.everware-cbdi.com

Date post:	15-Nov-2014
Category:	Documents
Upload:	zubin67
View:	654 times
Download:	3 times

Powerpoint Slides

Documents