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

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 "Center for Services Sciences" 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

Duane Nickull

Adobe®

Service Oriented Architecture Reference Model (SOA RM)

dnickull@adobe.com

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 - http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm

• Thank you – Duane Nickull, dnickull@adobe.com

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 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)

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