1 Interoperability Concerns in the Growth of Service Sciences: Ontological Implications of Service Oriented Architectures (SOA) Ontolog Forum Panel June 2005 Panelists: William E. McCarthy -– Michigan State UniversityMichigan State University George Brown -- IT Research, Intel Corporation Michael Gruninger -- NIST/Institute for Systems Research & University of Maryland Duane Nickull – Adobe Systems

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 detre 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 "Center for Services Sciences" at U.C. Berkeley. A good of overview of such trends is the brief article by Henry Chesbrough: 07e3-11d e2511c8.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 Duane Nickull Adobe ® Service Oriented Architecture Reference Model (SOA RM)

4 Before anyone talks about SOA… We need to define SOA. SOA is an architectural paradigm (model). SOA does not specifically mean Web Services although it is the popular implementation. OASIS Service Oriented Architecture Reference Model Technical Committee (SOA RM TC): –Reference Model to captures core tenets, axioms of SOA –To be used as template for architecture

5 Is SOA more than just architecture?

6 Concept Map - SOA Reference Model DRAFT – subject to change

7 Core Concepts of SOA 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. Service Description: Technical parameters, constraints, policies that come together to define terms of invocation. Discovery, Presence, Availability: Services must somehow communicate the fact they exist and other details about them to all potential consumers on a fabric.

8 Core Concepts of SOA Data Model: The specification and constraints imposed on instance data within a Service Oriented Architecture environment. Policy: A set/range of constraints imposed on any entity when invoking a service. If ignored, the invocation request may be denied! 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.

9 References OASIS SOA RM TC - open.org/committees/tc_home.php?wg_a bbrev=soa-rmhttp:// open.org/committees/tc_home.php?wg_a bbrev=soa-rm Thank you – Duane Nickull,

10 George Brown IT Research, Intel Corporation

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) Shared Services Management and Security Standards-based Connectivity Shared Application and Business Services

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 Business is represented by business processes defined in terms of value chain reference models An architectural representation that allows mapping collaborative process models to components of the conceptual architecture and to required resources 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 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 Defines use cases and collaborative process patterns for FERA mapping

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 Collaborative Semantics Business semantics –Using terminology applicable to describing process flows in practice –Has to be widely applicable (sequential transactions as well as iterative decision based flows) Technology semantics –Complete set of instructions for run-time execution –Component functions and interfaces definition ebSOA IM and ebSOA semantics is a FERA based standard proposal to OASIS

16 FERA IM in BPM Meta-schema Automating Generation of CP A1A2 A3 D1 A4 E2 E3 E1 process definition documents CPID, CPP, CPA, … Federation ServerSolution for deployment BPM model with FERA content, context and associations

17 Model for Mapping SOA to SOI Context-awareness and Ontology Replenishment SOI Mapping Engine Service Resource Service Characteristics Ontology Process Pattern Ontology Context Agent Examines Replenishes S O I SOASOA Historical Performance Repository Maps to Uses Replenishes Context Agent Examines Produces Uses Context Agent Examines

18 Ontological Implications of Service-Oriented Architecture Michael Gruninger NIST / Institute for Systems Research University of Maryland

19 Tasks Service discovery Find web services that achieve F, and where if B occurs then it occurs before A. e.g., my credit card is charged only after the book leaves the warehouse Service composition

20 Semantic Web Service Ontologies Specify the semantics of the process model underlying services, together with a notion of messages and dataflow. Axiomatize this semantics within some logical language (OWL, Common Logic) Existing ontologies OWL-S SWSF (Semantc Web Services Framework) WSMO (Web Service Modelling Ontology)

21 SWSF FLOWS-core –Service, AtomicProcess, composedOf, message, channel Control Constraints –Split, Sequence, Unordered, Choice, IfThenElse, Iterate, RepeatUntil Ordering Constraints –OrderedActivity Occurrence Constraints –OccActivity State Constraints –TriggeredActivity Exception Constraints –Exception

22 Ontologies for Semantic Web Services The software applications within services will typically be using different ontologies, and any service-oriented architecture must support the semantic integration of these ontologies Required Capabilities Advertise/publish application ontologies Automatically generate semantic mappings between ontologies used by different services. Twenty Questions Semantic Mapping Tool and Process Information Exchange protocols