1 Interoperability Concerns in the Growth of Service Sciences: Ontological Implications of Service Oriented Architectures (SOA) Ontolog Forum Panel -- 30 June 2005 Panelists: • William E. McCarthy -– Michigan State University • George Brown -- IT Research, Intel Corporation • Michael Gruninger -- NIST/Institute for Systems Research & University of Maryland
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
1
Interoperability Concerns in the Growth of Service Sciences: Ontological Implications
of Service Oriented Architectures (SOA)
Ontolog Forum Panel -- 30 June 2005
Panelists:• William E. McCarthy -– Michigan State University• George Brown -- IT Research, Intel Corporation• Michael Gruninger -- NIST/Institute for Systems Research & University of Maryland• Duane Nickull – Adobe Systems
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 "Center for Services Sciences" at U.C. Berkeley. A good of overview of such trends is the brief article by Henry Chesbrough:
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)
• 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 - http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm
(Contractual Coarse Grain elements, IMS, SOI artifact utilization, Fine Grain Services)
Service-Oriented Application
and InfrastructureManagement
(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
www.value-chain.org
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
Federation Server
Gateway
Collaborative Services
Event Management
Agent Framework
Portal
Cho
reog
raph
y A
dmin
istr
atio
n
federatedadministrators
federatedsystems
federatedusers
Federation Server
Gateway
Collaborative Services
Event Management
Agent Framework
Portal
Cho
reog
raph
y A
dmin
istr
atio
n
Federation Server
Gateway
Collaborative Services
Event Management
Agent Framework
Portal
Cho
reog
raph
y A
dmin
istr
atio
n
federatedadministrators
federatedsystems
federatedusers
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
A1 A2
A3 D1 A4
E2
E3
E1
process definition documentsCPID, CPP, CPA, …
Federation Server Solution for deployment
BPM model with FERA content, context and associations
17
Model for Mapping SOA to SOIContext-awareness and Ontology Replenishment
SOI
Mapping Engine
Service Service Service Service Service
Resource
Resource
Resource Resource
Resource
Resource
Resource
Resource
Resource
Service CharacteristicsOntology
Process Pattern Ontology
Context Agent
Examines
Replenishes
SOI
SOA
Historical Performance Repository
Maps to
Uses
Uses
Replenishes
Context Agent
Examines
Produces
Uses
Context AgentExamines
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)
• 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