Independent Guidance for Service Architecture and Engineering Everware-CBDI Meta Model for SOA by John Dodd Code Generation Conference Cambridge, May 19 th, 2007

© 2007 Everware-CBDI Inc 2 Everware-CBDI Meta Model Agenda 1. A word about SOA 2. Purpose of Meta Model 3. Format of Meta Model 4. Special Features 5. Development Process 6. Manifestations of Service in Model 7. Packages and their Content 8. SOA Reference Models compared 9. OMG’s UPMS Initiative

© 2007 Everware-CBDI Inc 3 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 Inc 4 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 Payment Inventory Manufacturing Logistics Ordering Resource Ticket Sales Service Ticket Collection Service Availability

© 2007 Everware-CBDI Inc 5 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 Inc 6 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

© 2007 Everware-CBDI Inc 7 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 Inc 8 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 Inc 9 Service Architecture -- Specification Level Process Services (orchestration layer) Product Lifecycle Services Core Business Services (“backbone” layer) Customers Service Orders Service 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 in Manufacturing System Products in Inventory System Ordering System Billing Application Product Life Cycle System

© 2007 Everware-CBDI Inc 10 Service Architecture -- Implementation Level Process Services (orchestration layer) Product Lifecycle Services 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 Orders Service «component» Sales Component Underlying Services (not so easy to use) Products In Manufacturing Sys Products In Inventory Sys «legacy» Manufacturing System «wrapper» ProductsAPI2 Wrapper «legacy» Inventory System Utility Services (high reuse layer) Address Formatting Service «external» Undefined indicates an embedded data store « application» Product Life Cycle System « application» Ordering System « application» Billing Application

© 2007 Everware-CBDI Inc 11 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 Component Products Component InventoryDB Sales DB Mainframe TP Monitor DB2 DBMS Manufacturing System Manufacturing DB Orchestration Server BPEL Engine ProductsLife Cycle Compt SalesProcess Component a: Web Server {opSys = WindowsNT} {webSvr = Apache} {nrDeployed = 4} Servlet Engine Ordering and Billing Apps Product LC System SOAP Engine Products LC Service Sales Process Service Products Service Orders Service Customers Service ProductsFromManuf ProductsFromInvnty 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 Inc 12 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 Inc 13 Manifestations of Service within the Meta Model Service Specification Service Endpoint (Service) Deployment Service Instance (at runtime) Conceptual) Service described in detail by 1 * 1..* * realized by 1..* defines capability available from 1..* installed as 1..* 1 1..? provides access to 1..* manages Service Automation Unit realized by * *

© 2007 Everware-CBDI Inc 14 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 Inc 15 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 Solution Modeling Solution Modeling Service Specificatio n Architecture Service Specificatio n Architecture Service Implementatio n Architecture Service Implementatio n Architecture Service Deployment Architecture Service Deployment Architecture Runtime Service View Runtime Service View Service Specificatio n Detail Planning & Provisioning Policy

© 2007 Everware-CBDI Inc 16 IMPLEMENTA- TION PACKAGE DEPLOYMENT AND RUNTIME SPECIFICATION PACKAGE SERVICE PACKAGE BUSINESS MODELING SOFTWARE MODELING ORGANIZATION PACKAGE POLICY PACKAGE TECHNOLOGY PACKAGE «import» Meta Model (version 2) organized into dependent Packages Version 2 Model incorporates nonsoftware services, and conceptual services within business models

© 2007 Everware-CBDI Inc 17 Concepts in each Package IMPLEMENTATION Automation Unit Auto. Unit Dependency Provided Behavior Required Behavior Technical Interface Technical Operation DEPLOYMENT & RUNTIME Deployment Endpoint Endpoint Operation Internal Location Service Instance SPECIFICATION Service Spec. Spec. Dependency Service State Interface (Port Type) Operation Spec. Pre- & Postcondition S. Information Model Information Type Message Spec. Message Sequence Policy Deviation Item S. Level Agreement SERVICE Service Nonsoftware Service Service Classification Classification Group Proposed Operation BUSINESS MODELING Business Service Business Domain Business Capability Business Type Process Business Event Business Rule Outcome, Policy Outcome Business Objective/Goal SOFTWARE MODELING Software Service Software Service Spec. Application Specification Use Case Actor Use Case Step ORGANIZATION PartyParty Role Organization UnitPersonPost POLICY Policy Policy Type Policy Scope Policy Subject Policy Alternative Policy Assertion Policy Relationship Service Domain Architecture Layer and Rules TECHNOLOGY Node Communication Path Protocol Processor Software Execution Environment Enterprise Service Bus

© 2007 Everware-CBDI Inc 18 ‘Reference Model’ Scope Comparison Based on research carried out December 2006; published in CBDI Journal January 2007

© 2007 Everware-CBDI Inc 19 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 Inc 20 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 Inc 21 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 Inc 22 Independent Guidance for Service Architecture and Engineering