Ontolog Soa Combined Panelists

396 views

Published on

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
396
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Ontolog Soa Combined Panelists

    1. 1. Interoperability Concerns in the Growth of Service Sciences: Ontological Implications of Service Oriented Architectures (SOA) Ontolog Forum Panel -- 30 June 2005 <ul><li>Panelists: </li></ul><ul><li>William E. McCarthy -– Michigan State University </li></ul><ul><li>George Brown -- IT Research, Intel Corporation </li></ul><ul><li>Michael Gruninger -- NIST/Institute for Systems Research & University of Maryland </li></ul><ul><li>Duane Nickull – Adobe Systems </li></ul>
    2. 2. Interoperability Concerns in the Growth of Service Sciences: Ontological Implications of SOA Traditionally, trading partners -- both within and between firms – trafficked in bundled tangible products like consumer goods or partially assembled finished goods. Many early e-commerce standards assumed implicitly product-based exchanges. Increasingly however, the growth in exchange and bundling of Services in the US and in other economies has supplanted tangible goods as the raison d’etre of international and domestic commerce. Estimates of the percentage of the gross domestic product of the US due to services (as opposed to goods) range as high as 80%. This trend has led to increased interest in services and the establishment of new research centers like the proposed &quot;Center for Services Sciences&quot; at U.C. Berkeley. A good of overview of such trends is the brief article by Henry Chesbrough: http://news.ft.com/cms/s/9b743b2a-0e0b-11d9-97d3-00000e2511c8,dwp_uuid=6f0b3526-07e3-11d9-9673-00000e2511c8.html In e-commerce, this growth in service provision has been mirrored by the advent of Service-Oriented Architectures which support integration and creation of composite solutions (bundles of services) from loosely-coupled components assembled both within an enterprise (outputs from legacy applications) and outside of the enterprise (typically XML-based Web services). Whether or not the integrated services originate from incompatible operations inside the firm or from incompatible vendor interfaces from outside the firms, semantic inconsistencies, redundancies, and discrepancies make the vision of integrated services an ontological problem. The purpose of this panel is to explore the ontological implications of Service Sciences in general and of Service-Oriented Architectures in particular. We will start our Ontolog session with some general comments from notable practitioners in the SOA and ontology areas. We will then open up the discussion to more general comments and critiques.
    3. 3. Duane Nickull Adobe ® S ervice Oriented A rchitecture Reference Model (SOA RM) [email_address]
    4. 4. Before anyone talks about SOA… <ul><li>We need to define SOA. </li></ul><ul><li>SOA is an architectural paradigm (model). </li></ul><ul><li>SOA does not specifically mean Web Services although it is the popular implementation. </li></ul><ul><li>OASIS Service Oriented Architecture Reference Model Technical Committee (SOA RM TC): </li></ul><ul><ul><li>Reference Model to captures core tenets, axioms of SOA </li></ul></ul><ul><ul><li>To be used as template for architecture </li></ul></ul>
    5. 5. Is SOA more than just architecture?
    6. 6. Concept Map - SOA Reference Model DRAFT – subject to change
    7. 7. Core Concepts of SOA <ul><li>Service: A service is a contractually defined behavior that can be implemented and provided by a component for use by any component based on the contract. </li></ul><ul><li>Service Description: Technical parameters, constraints, policies that come together to define terms of invocation. </li></ul><ul><li>Discovery, Presence, Availability: Services must somehow communicate the fact they exist and other details about them to all potential consumers on a fabric. </li></ul>
    8. 8. Core Concepts of SOA <ul><li>Data Model: The specification and constraints imposed on instance data within a Service Oriented Architecture environment. </li></ul><ul><li>Policy: A set/range of constraints imposed on any entity when invoking a service. If ignored, the invocation request may be denied! </li></ul><ul><li>Contract: The implicit or explicit bi-lateral or multi-lateral agreement between the owners or agents of a service and those who use the service. </li></ul>
    9. 9. References <ul><li>OASIS SOA RM TC - http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm </li></ul><ul><li>Thank you – Duane Nickull, [email_address] </li></ul>
    10. 10. George Brown IT Research, Intel Corporation
    11. 11. Mapping BP Requirements to the SOI Service-Oriented Infrastructure (Server, Client, Network, Storage, Sensors, etc) Service-Oriented Business and Applications as Services (ERP, CRM, Collaboration, Biz Process, Workflow Reporting, etc) Msg Service Federated Enterprise (Global Business Collaboration , Cross-Domain Assertion Mapping, etc ) Composite Systems (Contractual Coarse Grain elements, IMS, SOI artifact utilization, Fine Grain Services ) Service-Oriented Application and Infrastructure Management (Security, SLA, Workload, CMDB, Policy Mgmt, etc) Service-Oriented Enterprise Shared Services Management and Security Standards-based Connectivity Shared Application and Business Services
    12. 12. VCOR and FERA are the Key Parts of the Integrated Process and Technology Framework BPM (business process modeling): - reference models (VCOR) - benchmarking and requirements analysis - simulation and use case analysis Conceptual Architecture: - information model - deployment framework (FERA) - integration modes <ul><li>Business is represented by business processes defined in terms of value chain reference models </li></ul><ul><li>An architectural representation that allows mapping collaborative process models to components of the conceptual architecture and to required resources </li></ul>Two independent but reconciled process representations that facilitate the mapping of business process to core collaboration capabilities for accurate, fast and flexible implementations of the process models in a federation
    13. 13. Tier 1: Unified and broadly adopted, open standard business process framework for value chain management and implementation. The Value Chain Operations Reference-model (VCOR) is the cornerstone model of the Value Chain Group Supports value chain management for multiple centers of excellence www.value-chain.org Defines use cases and collaborative process patterns for FERA mapping
    14. 14. Tier 2: An architectural framework that defines principles and provides guidelines for implementing service-oriented solutions for essential value chain collaborations Enables accurate, fast and flexible implementations of in SOA environment ebSOA Is the basis for new standards for SOA that drive convergence Thanks to Collaborative Product Development Associates and ebXMLsoft for their contribution to this research.
    15. 15. Collaborative Semantics <ul><li>Business semantics </li></ul><ul><ul><li>Using terminology applicable to describing process flows in practice </li></ul></ul><ul><ul><li>Has to be widely applicable (sequential transactions as well as iterative decision based flows) </li></ul></ul><ul><li>Technology semantics </li></ul><ul><ul><li>Complete set of instructions for run-time execution </li></ul></ul><ul><ul><li>Component functions and interfaces definition </li></ul></ul><ul><li>ebSOA IM and ebSOA semantics is a FERA based standard proposal to OASIS </li></ul>
    16. 16. Automating Generation of CP FERA IM in BPM Meta-schema process definition documents CPID, CPP, CPA, … Federation Server Solution for deployment BPM model with FERA content, context and associations A1 A2 A3 D1 A4 E2 E3 E1
    17. 17. Model for Mapping SOA to SOI Context-awareness and Ontology Replenishment SOI Mapping Engine Service Service Service Service Service Resource Resource Resource Resource Resource Resource Resource Resource Resource Service Characteristics Ontology Process Pattern Ontology Context Agent Examines Replenishes S O I SOA Historical Performance Repository Maps to Uses Uses Replenishes Context Agent Examines Produces Uses Context Agent Examines
    18. 18. Ontological Implications of Service-Oriented Architecture Michael Gruninger NIST / Institute for Systems Research University of Maryland
    19. 19. Tasks <ul><ul><li>Service discovery </li></ul></ul><ul><ul><ul><li>Find web services that achieve F, and where if B occurs then it occurs before A. </li></ul></ul></ul><ul><ul><ul><ul><li>e.g., my credit card is charged only after the book leaves the warehouse </li></ul></ul></ul></ul><ul><ul><li>Service composition </li></ul></ul>
    20. 20. Semantic Web Service Ontologies <ul><ul><li>Specify the semantics of the process model underlying services, together with a notion of messages and dataflow. </li></ul></ul><ul><ul><li>Axiomatize this semantics within some logical language (OWL, Common Logic) </li></ul></ul><ul><ul><li>Existing ontologies </li></ul></ul><ul><ul><ul><li>OWL-S </li></ul></ul></ul><ul><ul><ul><li>SWSF (Semantc Web Services Framework) </li></ul></ul></ul><ul><ul><ul><li>WSMO (Web Service Modelling Ontology) </li></ul></ul></ul>
    21. 21. SWSF <ul><li>FLOWS-core </li></ul><ul><ul><li>Service, AtomicProcess, composedOf, message, channel </li></ul></ul><ul><li>Control Constraints </li></ul><ul><ul><li>Split, Sequence, Unordered, Choice, IfThenElse, Iterate, RepeatUntil </li></ul></ul><ul><li>Ordering Constraints </li></ul><ul><ul><li>OrderedActivity </li></ul></ul><ul><li>Occurrence Constraints </li></ul><ul><ul><li>OccActivity </li></ul></ul><ul><li>State Constraints </li></ul><ul><ul><li>TriggeredActivity </li></ul></ul><ul><li>Exception Constraints </li></ul><ul><ul><li>Exception </li></ul></ul>
    22. 22. Ontologies for Semantic Web Services <ul><ul><li>The software applications within services will typically be using different ontologies, and any service-oriented architecture must support the semantic integration of these ontologies </li></ul></ul><ul><ul><li>Required Capabilities </li></ul></ul><ul><ul><ul><li>Advertise/publish application ontologies </li></ul></ul></ul><ul><ul><ul><li>Automatically generate semantic mappings between ontologies used by different services. </li></ul></ul></ul><ul><ul><ul><ul><li>Twenty Questions Semantic Mapping Tool and Process Information Exchange protocols </li></ul></ul></ul></ul>

    ×