Post on 20-Jan-2016
description
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
© 2007 Everware-CBDI Inc3
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
© 2007 Everware-CBDI Inc4
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
© 2007 Everware-CBDI Inc5
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
© 2007 Everware-CBDI Inc6
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
© 2007 Everware-CBDI Inc7
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 …
© 2007 Everware-CBDI Inc8
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)
© 2007 Everware-CBDI Inc9
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
© 2007 Everware-CBDI Inc10
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
© 2007 Everware-CBDI Inc11
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
© 2007 Everware-CBDI Inc12
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
© 2007 Everware-CBDI Inc13
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
*
*
© 2007 Everware-CBDI Inc14
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.
© 2007 Everware-CBDI Inc15
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
© 2007 Everware-CBDI Inc16
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
© 2007 Everware-CBDI Inc17
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
© 2007 Everware-CBDI Inc18
‘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
© 2007 Everware-CBDI Inc19
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
© 2007 Everware-CBDI Inc20
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
© 2007 Everware-CBDI Inc21
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
© 2007 Everware-CBDI Inc22
Independent Guidance for Service Architecture and Engineering
www.cbdiforum.com
www.everware-cbdi.com