WEB SERVICE ARCHITECTURE

Document Sample
WEB SERVICE ARCHITECTURE Powered By Docstoc
					Semantic Web Services Initiative Architecture Committee
co-chaired by Mark Burstein
BBN Technologies

Christoph Bussler
Digital Enterprise Research Institute (DERI)

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?

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.

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

2.

Tasks
(0) (1) 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.

(2)

(3)

(4)

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

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

Within Scenarios, Use Cases to Cover a Range of Applicable Core Functions
a) Service request planning and

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)

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

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 Important Functionalities in Each Environment
B2B UC x x X p WS Grid Agents a) Service invocation message formulation and response interpretation b) Choreography (protocol) interpretation and execution c) Semantic translation/mediation (e.g., of message content, process descriptions or advertisments) d) Candidate service discovery via broker or referral e ) Service Selection (by negotiation with candidate services) f) Automated Process composition g) Process mediation and delegation h) Service process status tracking 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)

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.

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.

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.

Overall Agenda
• 9:00 - 9:10 Opening Remarks (Katia) 9:10 - 9:40 Language Committee Report (Kifer/Martin) 9:40 -10:10 Architecture Report (Burstein/Bussler) 10:10 - 10:20 Industrial Board (Davies/Grosof/Uschold) 10:20 - 10:45 Break 10:45 - 12:30 Parallel Working Sessions for the two committees SWSA – Presentation and Discussion of Use Cases

12:30 - 13:30 Lunch 13:30 - 15:30 Parallel Working Sessions for the two committees SWSA – Discussion of Candidate Requirements
• 15:30 - 16:00 Break 16:00 - 17:00 Parallel Working Sessions for the two committees SWSA – Outlining of Requirements Document and Assignments 17:00 - 17:30 Out brief of the two committees (15 minutes each) 17:30 - 18:00 Management Session --determining the action items and plans for the future

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.

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/services/use-cases/architecture

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)

Refined List of Functions
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) a) -

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

Matrix of Requirements to Use Cases
Function
Ubiquitous B2B B2C Computing Dynamic Service Discovery and Selection Grid Services Web/Info Service 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


				
DOCUMENT INFO
Shared By:
Tags:
Stats:
views:87
posted:8/10/2009
language:English
pages:20