Semantic Web Services InitiativeArchitecture Committee (SWSA)

Co-chairs:Mark Burstein (burstein@bbn.com)BBN Technologies,

Cambridge, MA

Christoph Bussler (chris.bussler@deri.ie)

Digital Enterprise Research Institute (DERI) Galway, Ireland

http://www.daml.org/services/swsa/Public mailing list: public-sws-ig@w3c.org

Current Committee Members• Bob Balzer, Teknowledge, Inc. (Los Angeles) • Boualem Benatallah, University of South Wales, Australia • Fabio Casati, HP Labs (Palo Alto) • Mike Dean, BBN Technologies• Andreas Eberhart, AIFB, Univ. of Karlsruhe• Tim Finin, University of Maryland, Baltimore County • Carole Goble, University of Manchester, UK • Michael Huhns, University of South Carolina • Anatas Kiryakov, Sirma Ltd., Bulgaria• Juan Miguel, DERI, Innsbruck• Enrico Motta, Open University, UK • John Mylopolous, University of Toronto • Massimo Paolucci, Carnegie Mellon University• Norman Sadeh, Carnegie Mellon University• Amit Sheth, LSDIS Lab, Univ. of Georgia• Stuart Williams, HP Labs (Bristol, UK)• Michal Zaremba, DERI, Galway

SWSA Mission Statement

The mission of the SWSI Architecture Committee (SWSA) is to develop architectural and protocol abstractions forming a reference architecture to support Semantic Web Service technologies.

• Develop use cases to demonstrate the benefits of using machine interpretable semantics to facilitate dynamic interoperability, composability, and substitutability among web services and for agent-based services in other distributed environments.

• Identify needed functionalities and classes of protocols to support semantic interoperability across a wide variety of functional domains and agent environments.

• Promote the development of standards, methodological and theoretical underpinnings through discussions, publications, reference implementations and coordination with standards bodies.

Key Objectives

1. Identify, through use case analysis, a set of key functional elements needed to enable semantic web service capabilities, such as dynamic interoperability and compositionality, and to enumerate requirements for the implementation of these functions in different architectural environments.

2. Develop abstract protocols for interaction with the middleware functions delineated in (1) to support semantic web services. These protocols should be realizable in the specification language(s) developed by the SWSI Language committee.

Diverse Set of Usage Scenarios to Capture Variability in Requirements

• Coverage of five major areas of potential use of semantic web services:– B2B and Enterprise Integration Systems– Grid Computing– Ubiquitous Computing– B2C and End User (personal agent) Web

Services– Agent-based Systems in large organizations

Classes of Semantically Enabled Functions

• Dynamic Service Discovery: The capability of a software agent, through interaction with other agents, to identify candidate services for particular objectives.

• Negotiation and Contracting: The capability of two agents to mutually formulate a shared agreement on the terms of performance of a service to be provided by one agent for the other.

• Service Description Interpretation, Process Enactment and Management: The capability to dynamically interact with and, if necessary, compose services to achieve some objective. This includes formulating service requests satisfying all semantically described criteria for acceptance, interpreting all messages from service providers, monitoring and the status of service execution and completion criteria contractually agreed upon. Where defined, a capability to interpret and enact associated cancellation, failure recovery and compensation mechanisms.

• Semantic Web Service Community Support Services: Capabilities associated with sharing semantic descriptions, ontologies and ontology mappings, and service catalogs within and across communities. Support for managing community membership, privacy and authority relationships, and shared computational and informational resources.

• Service Lifecycle Support Services: Capabilities associated with the instantiation, restarting, and shutdown of service processes. Includes the notions of service factories and may be tied in with resource management functions.

Use Cases Under Development

• Discovery and Invocation for B2C Web Services • Discovery and Security/Privacy Policies in

Ubiquitious Computing • Semantics for Composition, Service Resource

Management in Grid Computing • Contract Negotiation and Ontology, Ontology Map

Management for Interoperability maintenance in B2B

Identify Key Functionalities in Each Environment

Function B2B B2CUbiquitous Computing Grid Services Web/Info Service

Advertising of Service Descriptions

Candidate Service Discovery (Matchmaking)

Candidate Service Selection

Service request formation and response interpretation

Choreography interpretation and execution

Dynamic Service Composition

Request and Response Translation

Process mediation and delegation

Process status monitoring and event notification

Service failure handling and compensation

Service contract negotiation

Dispute Resolution and Compliance

Non-Repudiation/Audit Tracking/Explanation

Ontology Management and Mapping Services

Security (identification, authorization, delegation)

Privacy Services

Reputation Services

Membership and Authority Services

Policy and Protocol Management Services

Executable process management services

Resource Allocation and Provisioning services

Service Lifecycle Support

Dynamic Service Discovery and Selection

Service Description Interpretation, Process Enactment and Process Management

Negotiation and Contracting

Semantic Community Support Services

Example: GRID• The services to be delivered primarily relate to service executions, however may involve

hardware services in the future.• 1.1        Functional requirements for OGSA platform• This use case uses the following OGSA functionalities as described in [1]:• 1.     Discovery. • 2.     Workflow management. • 3.     Scheduling of service tasks. • 4.     Disaster Recovery. • 5.     Provisioning. • 6.     Brokering. • 7.     Load Balancing. • 8.     Fault Tolerance. • 9.     Transport Management. • 10.   Legacy Application Management. • 11.   Services Facilitating Brokering. • 12.   Application and Network-level Firewalls. • 13.   Agreement-based interaction. Authorization and use policies.

Where’s the Semantics?

• Identify the role that semantics could play in improving the capabilities of each functional area.

• Identify support elements required to provide that capability.

• Identify protocols and language requirements.

WSA WG Report

• Interoperability Architecture – multiple interacting views tied together primarily by usage models.– Message-oriented– Service-oriented– Resource-oriented– Policy

WSA ArchitectureService-oriented Model

USC INFORMATION SCIENCES INSTITUTE Yolanda Gil

Basic Grid Middleware (Globus Toolkit, Condor-G, DAGMan)

Higher-Level Service (Virtual Data Tools, Resource Brokers)

Intelligent Reasoners (matchmaking, refinement, repair, coordination, negotiation…)

Users and Applications

Semantic ResourceDescriptions

Resource Knowledge-bases

Application ComponentModels

Resource PolicyDescriptions

User and VO policymodels

Grid Resources (Compute, Data, Network)

Policy Knowledge-bases

Current Request Status, Results,Provenance Information

High-levelRequest

descriptions

Refined Workflow Provenance andMonitoring

TasksMonitoring, Resources

knowledge

Semantics forFile-based dataSemantics forFile-based data

What is Needed: Semantic Representations of the Environment at all Levels

Courtesy of Mike Uschold, Boeing

Community Ontologies

• Ontology designers generate alignment mappings between existing community ontologies

• Agent designers compose ontologies using these mappings• Agent-agent mappings generated automatically at agent

interaction time• Mediated via community ontologies

Wanted:

SWS Use Cases for any functional perspective

or relevant working environment

email to: burstein@bbn.com or: chris.bussler@deri.ie

http://www.daml.org/services/swsa

Develop Use Cases by Area to Cover a Range of Applicable Core Functions

a)   Service request planning and response interpretation (based on process descriptions)

b)   Choreography (protocol) interpretation and execution

c)   Semantic translation/mediation (e.g., of message content, process descriptions or advertisments)

d)   Candidate service discovery (mediated)

e) Candidate service selection (negotiated)

f)   Automated Process composition

g)    Process mediation and delegation

h)   Service process status tracking

i)   Ontology management and access

j)    Security (including identification, authentication, policy-based authorization)

k)    Reputation services

l)   Service failure handling and compensation

m)    Negotiation and contracting

n)  Server executable process management (service factories, instantiation, migration)

Tasks

(0) Identify common functionalities required to support semantic web services.

(1) Develop use cases in different operational environments that identify protocol requirements and alternative software architectures for distributing the support functions described in (0).

(2) Develop abstract protocols for the identified support functions. Work with the SWSL committee to represent these protocols in the language(s) they develop.

(3) Determine the feasibility of implementing these service support functions as extensions of the W3C WS reference architecture.

(4) Develop small exploratory prototypes to validate the concepts developed.

Milestones

1. Working draft of document covering requirements and 4 key Use Cases by November 2003.

2. Working draft of abstract protocols for SWS architectural support functions by June 2004.

3. Development of a coordinated SWSI submission to W3C by Q1, 2005