Powerpoint Slides


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Lets start by considering the vision for SOA. Firstly, we can look at the business opportunities. The provision of Services enables businesses to collaborate in real-time with business partners and customers – up and down the supply chain. Many businesses will already outsource commodity capability – such as logistics. SOA enables the services of 3 rd party providers to be integrated into the overall system as if they were internal resource – so there should be no loss of information flows when capability is outsourced. Secondly, in the example of the pricing service, services that are properly designed to be shareable can be reused in new scenarios. Not just shared by many customers, but if the service is more abstract and generalized it can also be reused in different processes and even different context. Finally, in the example of the flight availability service, information can be aggregated or selected from multiple providers of the same commodity service. Airlines differentiate on the price of their flights, the quality of their service, not on the way ticket prices are presented.
  • I expect that the proxies running under the SOAP engine will invoke their implementations on other processors using other than SOAP over JMS. Hence I think we need further communications links between a:WebServer and the Orchestration Server (this implements the ProductsLC Service and Sales Process Service using BPEL scripts) a:WebServer and the Mainframe (this implements the Products API Service somewhere within the Manufacturing System, perhaps as a CICS transaction?) The RMI link is used by the proxies of the Products, Customers and Orders service to invoke there implementations running in the EJB container.
  • Powerpoint Slides

    1. 1. Everware-CBDI Meta Model for SOA by John Dodd Code Generation Conference Cambridge, May 19 th , 2007
    2. 2. Everware-CBDI Meta Model Agenda <ul><li>A word about SOA </li></ul><ul><li>Purpose of Meta Model </li></ul><ul><li>Format of Meta Model </li></ul><ul><li>Special Features </li></ul><ul><li>Development Process </li></ul><ul><li>Manifestations of Service in Model </li></ul><ul><li>Packages and their Content </li></ul><ul><li>SOA Reference Models compared </li></ul><ul><li>OMG’s UPMS Initiative </li></ul>
    3. 3. A Recently Merged Company <ul><li>Specialist firm providing actionable guidance and support </li></ul><ul><ul><li>Enabling structured, enterprise-level SOA </li></ul></ul><ul><ul><li>Guiding SOA Excellence and Adoption </li></ul></ul><ul><ul><li>Facilitating SOA standards </li></ul></ul><ul><ul><li>Publishing Research based best practices to 20,000 subscribers world-wide </li></ul></ul>
    4. 4. A word about SOA <ul><li>Enables: </li></ul><ul><li>access to existing resources, when exposed as services services </li></ul><ul><li>new processes assembled from pre-existing services </li></ul><ul><li>choice of services provider </li></ul><ul><li>reuse and sharing of capabilities </li></ul>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 Manufacturing Logistics Ordering Resource Resource Resource Ticket Sales Service Service Ticket Collection Service Service Service Availability
    5. 5. Purpose of our Meta Model <ul><li>Twin objectives </li></ul><ul><ul><li>to improve the quality of our own offerings </li></ul></ul><ul><ul><li>to move the industry thinking around SOA forwards </li></ul></ul><ul><li>A well-defined meta model provides a solid foundation for </li></ul><ul><ul><li>Service Architecture & Engineering Knowledge Base </li></ul></ul><ul><ul><li>Consultancy Engagements </li></ul></ul><ul><ul><li>CBDI Journal Articles </li></ul></ul><ul><ul><li>Repository Design for tools supporting SOA process </li></ul></ul><ul><li>By getting our own ideas clear, we can better contribute to SOA standardization efforts </li></ul><ul><ul><li>by placing our own meta model in the public domain after consultation with our client base </li></ul></ul><ul><ul><li>seeking wider industry approval for the model and definitions, probably by integrating it at some level with the efforts of standards groups </li></ul></ul>
    6. 6. Format of Meta Model <ul><li>Concept Diagrams drawn in UML Class Diagram notation </li></ul><ul><ul><li>represents SOA concepts plus relationships & attributes </li></ul></ul><ul><ul><li>defines each concept </li></ul></ul><ul><ul><li>attributes incomplete </li></ul></ul><ul><ul><li>rules (invariants) not yet defined </li></ul></ul><ul><ul><li>organized into dependent packages </li></ul></ul><ul><ul><li>not a UML Profile </li></ul></ul>
    7. 7. Special Features of our Meta Model <ul><li>Services are linked to Business Modeling </li></ul><ul><li>Services are linked Solution Modeling / IT designs </li></ul><ul><li>Policies, the raw material for SOA governance, are covered by model </li></ul><ul><li>Service orientation is not limited to software </li></ul><ul><li>Recognizes the service concept is not confined to software services </li></ul><ul><ul><li>“a collection of functionality by which the needs of potential consumers are satisfied by a provider according to a contract” </li></ul></ul><ul><li>Less normalized and less opaque than UML & its profiles </li></ul><ul><li>A Service Architecture is modeled at three levels of abstraction … </li></ul>
    8. 8. Features of a Service Architecture <ul><li>Defined at three Levels </li></ul><ul><ul><li>Specification Architecture </li></ul></ul><ul><ul><li>Implementation Architecture </li></ul></ul><ul><ul><li>Deployment Architecture </li></ul></ul><ul><li>Organizes Services into Layers </li></ul>Specification Architecture (for consuming developers) Deployment Architecture (for operations) Implementation Architecture (for service developers)
    9. 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
    10. 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) Underlying Services (not so easy to use) Products In Manufacturing Sys Products In Inventory Sys Utility Services (high reuse layer) Address Formatting Service « application» Product Life Cycle System « application» Ordering System « application» Billing Application « script » Products Life Cycle Component « script » Sales Process Component « component » Products Component Customers Service Orders Service « component » Sales Component « legacy » Manufacturing System « wrapper » ProductsAPI2 Wrapper « legacy » Inventory System « external » Undefined indicates an embedded data store
    11. 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 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 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
    12. 12. Development Process for the Everware-CBDI meta model <ul><li>Initial Meta Model published in October 2006 CBDI Journal </li></ul><ul><ul><li>Built to express concepts in SAE ™ (Service Architecture & Engineering) </li></ul></ul><ul><ul><li>Influenced by UML, less by UML Profile from IBM and OASIS-RM </li></ul></ul><ul><li>Review with our client-base has just been completed </li></ul><ul><ul><li>Fortnightly teleconferences to discuss a MM View </li></ul></ul><ul><ul><li>Web site for registering client issues </li></ul></ul><ul><ul><li>Building version 2 meta model </li></ul></ul><ul><ul><li>Then intend to place meta model in public domain </li></ul></ul><ul><li>Participating in a group responding to OMG request for a “UML Profile & Meta Model for SOA” </li></ul><ul><ul><li>to influence this response </li></ul></ul><ul><ul><li>and to be influenced by response </li></ul></ul><ul><li>Generally, to encourage convergence of SOA reference and meta models </li></ul>
    13. 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 1..* 1..? provides access to 1..* manages Service Automation Unit realized by * *
    14. 14. Definition of these Service Manifestations 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. Service Instance 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. Deployment 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. Service Endpoint 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 Automation Unit 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 Specification A collection of functionality by which the needs of potential consumers are satisfied by a provider according to a contract (Conceptual) Service
    15. 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 Service Specification Architecture Service Implementation Architecture Service Deployment Architecture Runtime Service View Service Specification Detail Planning & Provisioning Policy
    16. 16. Meta Model (version 2) organized into dependent Packages Version 2 Model incorporates nonsoftware services, and conceptual services within business models 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»
    17. 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 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 TECHNOLOGY Node Communication Path Protocol Processor Software Execution Environment Enterprise Service Bus
    18. 18. ‘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 ECI MM for SAE MOD M3 Open G Ontology IBM UML Profile OASIS RM-SOA W3C WSA Reference Model  RM Area ↓ work in progress
    19. 19. UML Profile and Meta Model for SOA - RFP <ul><li>A “Request for Proposal” issued by OMG in September 2006, asking for submissions by June 2007 </li></ul><ul><li>Must extend standard UML, to cover “modeling and integrating services within and across the enterprise” </li></ul><ul><li>Aims: </li></ul><ul><ul><li>establish a common vocabulary to unify service definitions </li></ul></ul><ul><ul><li>“support a service contract describing the collaboration between participating service consumers and providers using mechanisms that clearly separate requirements and specification from realization” </li></ul></ul><ul><ul><li>integrate with and complement standards developed by other organizations </li></ul></ul><ul><li>While avoiding: </li></ul><ul><ul><li>any particular methodology </li></ul></ul><ul><ul><li>governance </li></ul></ul><ul><ul><li>deployment and runtime </li></ul></ul><ul><ul><li>dynamic binding </li></ul></ul><ul><ul><li>service discovery </li></ul></ul><ul><ul><li>end-user experience </li></ul></ul>
    20. 20. UML Profile and Meta Model for SOA - Progess <ul><li>Everware-CBDI involved in submission led by IBM </li></ul><ul><li>Proposal is more narrowly scoped than Everware-CBDI meta model </li></ul><ul><ul><li>High focus on the idea that services collaborate to achieve anything </li></ul></ul><ul><ul><li>Started out with viewpoint: </li></ul></ul><ul><ul><ul><li>A Service is a kind of Port (interaction point) of a Component (the “provider” software) </li></ul></ul></ul><ul><ul><ul><li>A Service conforms to a Service Interface (= Type or Specification of the Service) which defines a “protocol” for service interactions </li></ul></ul></ul><ul><ul><ul><li>Business requirements can be expressed by a “service contract” which defines the roles Providers must play to deliver the required business behavior </li></ul></ul></ul><ul><li>This is work in progress, involves heated debate, and it remains to be seen what emerges </li></ul>
    21. 21. Closing Comments <ul><li>The meta model is an important asset for Everware-CBDI </li></ul><ul><ul><li>it is still undergoing change </li></ul></ul><ul><ul><li>it underpins the SOA KnowledgeBase product we are developing </li></ul></ul><ul><ul><li>we intend to make it public domain and offer to other organizations </li></ul></ul><ul><li>The model is not currently detailed enough for code generation </li></ul><ul><ul><li>That has not been our goal </li></ul></ul><ul><ul><li>It could be extended to generate code </li></ul></ul><ul><ul><ul><li>signatures of operations </li></ul></ul></ul><ul><ul><ul><li>messages </li></ul></ul></ul><ul><ul><ul><li>logic derived from pre and post conditions </li></ul></ul></ul><ul><li>Any questions </li></ul>
    22. 22. Independent Guidance for Service Architecture and Engineering www.cbdiforum.com www.everware-cbdi.com