Transcript Semantic Web Services Initiative Architecture Committee

Semantic Web Services Initiative
Architecture Committee (SWSA)
Co-chairs:
Mark Burstein
Christoph Bussler
([email protected])
BBN Technologies,
Cambridge, MA
([email protected])
Digital Enterprise Research Institute (DERI)
Galway, Ireland
http://www.daml.org/services/swsa/
Public mailing list: [email protected]
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
Ubiquitous
B2B
B2C
Computing
Dynamic Service Discovery and Selection
Grid Services
Advertising of Service Descriptions
Candidate Service Discovery (Matchmaking)
Candidate Service Selection
Service Description Interpretation, Process Enactment and Process Management
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
Negotiation and Contracting
Service contract negotiation
Dispute Resolution and Compliance
Non-Repudiation/Audit Tracking/Explanation
Semantic Community Support Services
Ontology Management and Mapping Services
Security (identification, authorization, delegation)
Privacy Services
Reputation Services
Membership and Authority Services
Policy and Protocol Management Services
Service Lifecycle Support
Executable process management services
Resource Allocation and Provisioning services
Web/Info Service
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 Architecture
Service-oriented Model
What is Needed: Semantic Representations of the
Environment at all Levels
User and VO policy
models
Application Component
Models
Semantics for
File-based data
Users and Applications
High-level
Request
descriptions
Current Request Status, Results,
Provenance Information
Intelligent Reasoners (matchmaking, refinement, repair, coordination, negotiation…)
Refined Workflow
Policy Knowledgebases
Provenance and
Monitoring
Resource Knowledgebases
Higher-Level Service (Virtual Data Tools, Resource Brokers)
Tasks
Monitoring, Resources
knowledge
Resource Policy
Descriptions
Semantic Resource
Descriptions
Basic Grid Middleware (Globus Toolkit, Condor-G, DAGMan)
Grid Resources (Compute, Data, Network)
USC INFORMATION SCIENCES INSTITUTE
Yolanda Gil
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
Wanted:
SWS Use Cases
for any functional perspective
or relevant working environment
email to: [email protected]
or: [email protected]
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)
(1)
(2)
(3)
(4)
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.
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