SWSA@BBN Preliminary Agenda. Agenda – August 16&17, 2004 9:00-1700 Each day: Make Progress Monday 16 August 8:30-9:00 Arrive, Coffee 9:00-10:00 Discuss.

SWSA@BBN

Preliminary Agenda

Agenda –August 16&17, 2004• 9:00-1700 Each day: Make ProgressMonday 16 August• 8:30-9:00 Arrive, Coffee• 9:00-10:00 Discuss goals for producing SWSA Note• 10:00-12:00 Topics to cover in Note, Develop Outline• 1:00-5:00 Issues discussion, Break into subgroups Tuesday 17 August• 8:30-9:00 Arrive, Coffee• 9:00-11:00 Subgroups• 11:00-1:00 Oasis overview and lunch• 1:00-4:00 Review subtopics and document plan• 4:00-5:00 Work plan assignments for Sept.• 5pm - adjourn

Schedule

• SWSA Requirements draft release June 1(done)• Requirements Note to W2C by Aug 1 (dropped)• Draft Architecture Note by Sept 30 (still the goal)• Final Architecture Note by October 30• Meeting Opportunities

– W3C Workshop 13-14 October – Redwood Shores, CA– Dagstuhl Sept 19-24. – ISWC in 7-11 November in Hiroshima, Japan– Next DAML PI meeting 20 Nov – 2 Dec (tentative)

Meeting Objectives

– List of protocols and ontologies to specify in next 6 weeks

– Determine approach to layering on existing standards

– Outline for Note

– Review status of use cases.

Architecture Note• Goal is Submission to SWS-IG

– What do we hope to achieve there? • SWS Working group?

– What would be most useful?• Vision of roadmap with realistic goals?• Key missing elements of WSA?• Complement to SWSL?

• Barriers to success:– We do not have the usual ‘experience base’ on which

standards are built. – Standards efforts are now a dime a dozen

Draft Roadmap• Dimensions/Issues: discovery, invocation, mapping, exception handling• Stage 1: Simple service invocation and response handling

– User directed manual discovery– User directed composition – Ensuring semantic interoperability during invocation and responses

exception handling– Mapping: predefined, lossless, simple translation engines

• Stage 2: SWS with Automated Discovery and Mapping– Goal characterization for matchmaker querying and service selection

reasoning– Mapping: add mapping infrastructure (registries), partial mapping

• Stage 3: Complex Discovery Models and Negotiation/Contracting– Proxy/Broker based interaction protocols

» Includes forwarding of QoS and Privacy requirements– Negotiation dialogs for refining discovery, establishing service

requirements

SWSA Functional Areas• Discovery

– Advertise and Match Query

• Process Enactment – Engage, Invoke, Status, Response, Exception

• Negotiation and Contracting (Engagement)• Community Services

– Membership, Authorization, Privacy, Trust

• Lifecycle– Resource relationship modeling, management– Life generation, status, resurrection, substitution– Version management (!)

Architectural Elements and Protocols Note• Non-protocol elements: Focus on layering, primitive elements and

capabilities:– Discovery mechanisms and associated protocols,– Kernel (bootstrapping) support

• Semantic community registry seed discovery and use protocols• For finding Service registries and ontology mapping registries

– Agent internal SWS support • for goal description, process model interpretation, invocation reasoning, response

interpretation, process monitoring

– Ontology mapping and alternative translation mechanisms (middleware and agent internal)

• Protocols to include support for • communication of security, privacy (information ownership), QoS, • Service Lifecycle • Ontology/Protocol Versioning

Which Protocols?

• Critical protocols for– Registration– Discovery: Advertising & Service Match Query– Invocation- Contract Negotiation & Enactment – Ontology and Mapping Lookup/Translation– Enactment/Management

Some Discovery Protocols• Register• Login• Query• Publish• Update• Retract• Subscribe to changes• Monitor Queries

Note Outline (first cut)– Discussion of Requirements (from existing doc)– Discussion of how we build on existing ‘standards’

• W3C WS Architecture & SWS Conceptual Architecture• WSMO&WSMF• OWL-S• Abstraction of UDDI-like registry support• GRID Architecture• Something for Ubiq. Comp?• Rosetta? EI?

– Roadmap to stages/degrees of SWS automation– Conceptual Model used to lay out protocol space– Abstract Protocols– Conclusions

What can we safely build on?

• WSA Note• WSDL• OWL, OWL-S, METEOR• WSMO• Semantic Grid• Security and Privacy Ontologies• How do we get ontology sharing and mediation

into this picture?

W3C Web Service Architecture

Figure 2.8: Service Oriented Model (from http://www.w3.org/TR/ws-arch/ )

Conceptual Model of Service Discovery for SWS

In “A conceptual model for semantic web services” Chris Priest, HP Labs,

requires publishes

Is a

RequestorAgent

Servicerequirementdescription

RequestorAgent

Requestor agent

Abstract ServiceRequirement

Abstract ServiceProvided

publishes provides

RequestorAgent

Provider agent

Is a

Service offerdescription

RequestorAgent

Abstract ServiceDescriptionAbstract Service

Is a

Is a

has semantics has semantics

Contract Agreement Model

ContractAgreement

Choreography

participates in participates in

about

specialisation of results in

contains Service ContractAgreed Service

Description

Abstract ServiceDescription

Provider Agent Requestor Agent

In “A conceptual model for semantic web services” Chris Priest, HP Labs,

Service Delivery Model

performs uses

has

part of part of

pertains to Service TaskPost-AgreementChoreography

Service Contract

Provider Agent Requestor Agent

Agreed Service Concrete Servicemember of

In “A conceptual model for semantic web services” Chris Priest, HP Labs,

Lifecycles

• Of service description (interface)

• Of ontologies supporting service interface

• Of service agent deployment

• Of the service discovery & enactment

– OASIS WS for WS Mgmt is a place to look for lifecycle issues

Lifecycle of Service Description

• Publish (at URI or in Registry)• Publish Update (new version)

– With diffs from old version?• Changes to messages

• Changes to choreography

• Changes to ontologies used?

• Retract

• Granularity of versioning is a big issue

Contract Negotiation• Call for proposal

– What is your interface? (at a URI)

– Will you perform Task T with Quality Q?• Will you sell X?

• Will you do Y?

– What requirements do you have to accept this request?

• Proposal

• Accept

• Revise/Counter

• Reject (w reason)

Results and Assignments

First Cut at Request Protocol (Engagement)

A

B

B

Request

A

Query

Inform

AConfirm Request

Accept Yes

A(Fail)

Refuse Request

Refuse Request

B

END

GO

Cancel

Revision by Mike Huhns

See EngagementStateDiagram.pdf

Outline of Short Version of Note• Intro

– Framing approach to Protocols, Object Model– Underlying assumptions, architectural layers, – Stages of semantics ‘uptake’– Protocols in 4 areas:

• Abstract Protocols– Discovery and selection– Engagement (Negotiation, Contracting)

• Include service model lookup here. May be a request to the service. – Enactment (Execution and Monitoring)– Lifecycle – Side Protocols

• Security/Authentication and Privacy• Message Interpretation (Semantic confirm receipt)

and Clarification

Protocols, Assignments• Intro (Framing of discussion)

– Bussler, Burstein, Williams– Areas are:

• Discovery (Advertise/Update, Query, Select)• Engagement (Interpret Service Model, Request, Negotiate, Contract)• Enactment (Execution Monitoring, Results, Failure Recovery & Compensation)

• Protocol sketching Assignments:– Christoph – Intro (framing object model)– Michal- Engagement & Enactment– Stuart - Framing & Enactment– Mike H - Contracting&Negot, Discovery– Tim F - Discovery, C&N– Massimo - Enactment, Discovery– Mark – Intro, Enactment

• Due Sept 19