1 / 22

Everware-CBDI Meta Model for SOA by John Dodd

Everware-CBDI Meta Model for SOA by John Dodd. Code Generation Conference Cambridge, May 19 th , 2007. Everware-CBDI Meta Model Agenda. A word about SOA Purpose of Meta Model Format of Meta Model Special Features Development Process Manifestations of Service in Model

nowles
Download Presentation

Everware-CBDI Meta Model for SOA by John Dodd

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Everware-CBDIMeta Model for SOAby John Dodd Code Generation Conference Cambridge, May 19th, 2007

  2. Everware-CBDI Meta ModelAgenda • A word about SOA • Purpose of Meta Model • Format of Meta Model • Special Features • Development Process • Manifestations of Service in Model • Packages and their Content • SOA Reference Models compared • OMG’s UPMS Initiative

  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

  4. A word about SOA • 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 Service Oriented Architecture (SOA) is an architectural style that enables the assembly of systems from distributed, federated resources Payment Service Ticket Sales Service Service Ordering Service Inventory Service Service Service Service Service Availability Service Ticket Collection Logistics Manufacturing Resource Resource Resource

  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

  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

  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 …

  8. Features of a Service Architecture Specification Architecture (for consuming developers) • Defined at three Levels • Specification Architecture • Implementation Architecture • Deployment Architecture Deployment Architecture (for operations) Implementation Architecture (for service developers) • Organizes Services into Layers

  9. Service Architecture -- Specification Level Solution Layer (UI, dialog management) Billing Application Ordering System Product Life Cycle System Product Lifecycle Services Process Services (orchestration layer) Sales Process Services Core Business Services (“backbone” layer) Orders Service Customers Service Products Service Utility Services (high reuse layer) Address Formatting Service Products in Manufacturing System Underlying Services (not so easy to use) Products in Inventory System

  10. Service Architecture -- Implementation Level «legacy» Manufacturing System «wrapper» ProductsAPI2 Wrapper «component» Products Component «component» Sales Component «external» Undefined «legacy» Inventory System «script» Products Life Cycle Component «script» Sales Process Component Customers Service Orders Service indicates an embedded data store Solution Layer (UI, dialog management) «application» Product Life Cycle System «application» Ordering System «application» Billing Application Product Lifecycle Services Sales Process Services Process Services (orchestration layer) Products Service Core Business Services (the backbone layer) Utility Services (high reuse layer) Address Formatting Service Products In Inventory Sys Products In Manufacturing Sys Underlying Services (not so easy to use)

  11. Deployment Level a: Web Server {opSys = WindowsNT} {webSvr = Apache} {nrDeployed = 4} Protocol Adapter Servlet Engine Ordering and Billing Apps Product LC System Orchestration Server SOAP Engine Products LC Service Sales Process Service Products Service Orders Service Customers Service ProductsFromManuf ProductsFromInvnty BPEL Engine ProductsLife Cycle Compt SalesProcess Component a: Client PC an: ExternalHost Internet Explorer Address Formatting Service Shows where Automation Units are installed HTTP SOAP over HTTP Mainframe Application Server Inventory System TP Monitor EJB Container “Proxies” accessing logic hosted elsewhere “Proxies” since main logic is elsewhere Manufacturing System Sales Component Products Component RMI JDBC DB2 DBMS Oracle DBMS InventoryDB Sales DB Manufacturing DB Wrapper logic runs under SOAP Engine SOAP over JMS

  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

  13. Manifestations of Service within the Meta Model Conceptual) Service * 1 described in detail by * Service Specification realized by 1..* * realized by defines capability available from 1..* * 1..* Service Automation Unit Service Endpoint 1..* 1..* provides access to installed as 1..? 1..* (Service) Deployment 1 manages 1..* Service Instance (at runtime)

  14. Definition of these Service Manifestations

  15. Meta Model Version 1 was divided into overlapping “Views” Business Modeling Solution Modeling Version 1 Model was limited to software services, which might or might not be Web services Planning & Provisioning Policy Service Specification Architecture Service Specification Detail Service Implementation Architecture Runtime Service View Service Deployment Architecture

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

  17. Concepts in each Package ORGANIZATION Party Party Role Organization Unit Person Post POLICY Policy Policy Type Policy Scope Policy Subject Policy Alternative Policy Assertion Policy Relationship Service Domain Architecture Layer and Rules 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 TECHNOLOGY Node Communication Path Protocol Processor Software Execution Environment Enterprise Service Bus 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 IMPLEMENTATION Automation Unit Auto. Unit Dependency Provided Behavior Required Behavior Technical Interface Technical Operation DEPLOYMENT & RUNTIME Deployment Endpoint Endpoint Operation Internal Location Service Instance SOFTWARE MODELING Software Service Software Service Spec. Application Specification Use Case Actor Use Case Step

  18. ‘Reference Model’ Scope Comparison work in progress Reference Model  RM Area ↓ W3C WSA OASIS RM-SOA IBM UML Profile Open G Ontology MOD M3 ECI MM for SAE Service Discovery ++ + + Service Desc. or Specification ++ +++ ++ + + ++++ Messages +++ + ++ + + Reachability + + + + Service Implementation + ++ + ++ Service Deployment +++ Services at Runtime + + Policy for SOA +++ +++ + ++ (Runtime) Management ++ Business Modeling links + ++ Solution Modeling links + ++ Non-service software links + + ++ Security ++ Based on research carried out December 2006; published in CBDI Journal January 2007

  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

  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

  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

  22. www.cbdiforum.com Independent Guidance for Service Architecture and Engineering www.everware-cbdi.com

More Related