Semantic Web Services Initiative Architecture Committee SWSA

1
Semantic Web Services InitiativeArchitecture
Committee (SWSA)

• Co-chairs
• Mark Burstein (burstein_at_bbn.com)BBN
  Technologies,
• Cambridge, MA

Christoph Bussler (chris.bussler_at_deri.ie)Digital
Enterprise Research Institute (DERI) Galway,
Ireland
http//www.daml.org/services/swsa/ Public mailing
list public-sws-ig_at_w3c.org
2
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

3
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.

4
Key Objectives

• 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.
• 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.

5
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

6
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.

7
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

8
Identify Key Functionalities in Each Environment
9
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.

10
Wheres 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.

11
WSA WG Report

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

12
WSA ArchitectureService-oriented Model
13
What is Needed Semantic Representations of the
Environment at all Levels
USC INFORMATION SCIENCES INSTITUTE
Yolanda Gil
14
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

Courtesy of Mike Uschold, Boeing
15
Wanted SWS Use Cases for any functional
perspective or relevant working
environmentemail to burstein_at_bbn.com or
chris.bussler_at_deri.iehttp//www.daml.org/service
s/swsa
16
(No Transcript)
17
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)

18
Tasks

• (0) Identify common functionalities required to
  support semantic web services.
• Develop use cases in different operational
  environments that identify protocol
  requirements and alternative software
  architectures for distributing the support
  functions described in (0).
• Develop abstract protocols for the identified
  support functions. Work with the SWSL committee
  to represent these protocols in the language(s)
  they develop.
• Determine the feasibility of implementing these
  service support functions as extensions of the
  W3C WS reference architecture.
• Develop small exploratory prototypes to validate
  the concepts developed.

19
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