Semantic Web Services Initiative Architecture Committee - PowerPoint PPT Presentation

1 / 20
About This Presentation
Title:

Semantic Web Services Initiative Architecture Committee

Description:

Boualem Benatallah, University of South Wales, Australia. Fabio Casati, ... Michael Huhns, University of South Carolina. Atanas Kiryakov, Sirma Ltd., Bulgaria ... – PowerPoint PPT presentation

Number of Views:29
Avg rating:3.0/5.0
Slides: 21
Provided by: burs7
Learn more at: http://www.daml.org
Category:

less

Transcript and Presenter's Notes

Title: Semantic Web Services Initiative Architecture Committee


1
Semantic Web Services InitiativeArchitecture
Committee
  • co-chaired by
  • Mark BursteinBBN Technologies
  • Christoph Bussler Digital Enterprise Research
    Institute (DERI)

2
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
  • Tim Finin, University of Maryland, Baltimore
    County
  • Carole Goble, University of Manchester, UK
  • Michael Huhns, University of South Carolina
  • Atanas Kiryakov, Sirma Ltd., Bulgaria
  • Enrico Motta, Open University, UK
  • John Mylopolous, University of Toronto
  • Massimo Paolucci, Carnegie Mellon University
  • Norman Sadeh, Carnegie Mellon University (new)
  • Dan Weld, University of Washington (withdrawn)
  • Stuart Williams, HP Labs (Bristol, UK)
  • Others?

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.
  • Promote the development of standards,
    methodological and theoretical underpinnings
    through discussions, publications, reference
    implementations and coordination with standards
    bodies.

4
Objectives
  1. To 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. To 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
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.

6
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

7
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

8
Within Scenarios, Use Cases 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)

9
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

10
Identify Important Functionalities in Each
Environment
11
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 interation. Authorization
    and use policies.

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

13
Goals for the Meeting Today
  • Discuss each of the Use Cases currently under
    development
  • What are the architectural issues involved?
  • What (abstract) protocols should be standardized?
  • Are there requirements on languages that arise
    from this?
  • Develop draft list of requirements
  • Do we want to assume particular underlying
    architectural layers?
  • Develop outline and writing assignments for
    Requirements Document draft.

14
Overall Agenda
  • 900 - 910 Opening Remarks (Katia)910 -
    940 Language Committee Report
    (Kifer/Martin)940 -1010 Architecture
    Report (Burstein/Bussler)1010 - 1020
    Industrial Board (Davies/Grosof/Uschold)1020 -
    1045 Break1045 - 1230 Parallel Working
    Sessions for the two committeesSWSA
    Presentation and Discussion of Use Cases1230 -
    1330 Lunch1330 - 1530 Parallel Working
    Sessions for the two committeesSWSA Discussion
    of Candidate Requirements
  • 1530 - 1600 Break1600 - 1700 Parallel
    Working Sessions for the two committeesSWSA
    Outlining of Requirements Document and
    Assignments1700 - 1730 Out brief of the two
    committees (15 minutes each)1730 - 1800
    Management Session              --determining
    the action items and plans for the future

15
What we did during this F2F
  • Reviewed mapping of SWS environments against key
    functions, developed matrix identifying where
    each was critical, likely to be required, or not.
  • Refined list of functions, refined definition of
    each functional area, with examples.
  • Developed outline for use cases
  • Postponed finalizing outline for requirements
    document to next telecon after ISWC.

16
Use Cases Under Development
  • Discovery and Invocation for B2C Web Services
    -Massimo
  • Discovery and Security/Privacy Policies in
    Ubiquitious Computing Tim, Stuart, Norman
  • Semantics for Composition, Service Resource
    Management in Grid Computing - Carol
  • Contract Negotiation and Ontology, Ontology Map
    Management for Interoperability maintenance in
    B2B - Chris
  • use case repository at http//www.daml.org/ser
    vices/use-cases/architecture

17
Reviewed Range of 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 identification
    (matchmaking) and selection
  • e)   Automated Process composition
  • f)    Process mediation and delegation
  • g)   Service process status tracking
  • h)   Ontology management and access
  • i)    Security (including identification,
    authentication, delegation and policy-based
    authorization)
  • j)    Reputation services
  • k)   Service failure handling and compensation
  • l)    Negotiation and contracting
  • m)  Server executable process management (service
    factories, instantiation, migration)

18
Refined List of Functions
  • a)       Service invocation message formulation
    and response interpretation
  • -          Atomic parameterized grounded
    invocation of a service operation from a services
    description
  • E.g. Identification of required input
    values for a P.O. message to SAP, execution of
    the grounding
  • b)       Choreography (protocol) interpretation
    and execution
  • -          Execution of the interaction protocol
    of one service. Attribution of semantics to set
    of temporally related messages.
  • -          E.g. protocol descriptions could be
    described by UML sequence diagrams
  • -          E.g. Request, Acknowledgement of a PO
  • Choreography interpretation of multi-service
    interactions
  • c)      Semantic translation/mediation (e.g., of
    message content, process descriptions or
    advertisements)
  • d)      Candidate service discovery via
    directory, broker or referral
  • -         In U.C. find a printer when you walk
    into a room (referral by broker or peer)
  • e)      Service Selection (by negotiation
    directly with candidate services)
  • -         Refining requirements
  • -         eg auctions
  • f)        Automated Process composition
    (planning, creation of a choreography, writing of
    a program)
  • g)      Process mediation and delegation
  • -         mediating between two service
    descriptions or choreographies
  • h)     

19
Continued
  • SeService process status tracking/monitoring vs
    event notification
  • i)        Ontology management and access
  • j)        Security (including identification,
    authentication, delegation and 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,
    liveness)
  • o)     
  • NEW
  • Resource Allocation/Provisioning
  • p)      Dispute Resolution and Compliance
  • q)      Privacy and Confidentiality
  • r)       Usability (by humans) - includes HCI
  • s)       Non-Repudiation/ Audit
    Tracking/Explanation

20
Matrix of Requirements to Use Cases
Write a Comment
User Comments (0)
About PowerShow.com