Semantic Web Services
Language Requirements
http://www.daml.org/services/swsl/requirements/
Presenter: Emilia Cimpian
16/11/2003
1
Overview of Topics
• Introduction
• Formalization (General Requirements)
• Functional Requirements
16/11/2003
2
Introduction
• SWSI Language Committee
– to develop computer language technology that will
provide a firm, long-term foundation for the future
of Web services on the Internet
– formal language that allows for rich declarative
specification of a wide variety of information about
Web services
– starting point – OWL-S
16/11/2003
3
Introduction
• Requirements (SWSL):
– Formalization
– Functional
16/11/2003
4
General Requirements
• General Language Properties
• Expressive Power
• Meta Properties
16/11/2003
5
General Requirements
- General Language Properties -
• Declarative semantics
• Compositional
• Extensible
16/11/2003
6
General Requirements
- Expressive Power • Interface description
• Functional & behavioral specification on component
software
• Simple workflow description
• Incomplete service specification
• Constraints & temporal constraints satisfaction
• Exceptions
• Plans and planning domains
• Scheduling
• Policies
• Hypothetical scenarios
• Composition of sub-activities
16/11/2003
7
General Requirements
- Meta Properties -
• Understandable
• Easy to be written by a broad range of
practitioners
• Possibility of integration
• Address aspects of the web services
• Interoperable with automated reasoning
techniques
• Extendable annotation mechanism
16/11/2003
8
General Requirements
- Meta Properties -
• Capable of:
– Linking the remote service specifications
– Supporting analyses
– Interoperating with programs that can execute a
process model
– Multi-party activities across organizational
boundaries
– Lifecycle management and process control
– Specification of taxonomies of services and
service descriptions
– Importing external ontologies
16/11/2003
9
Functional Requirements
•
•
•
•
16/11/2003
Advertising and Matching
Negotiation and Contracting
Process Modeling
Process Enactment
10
Functional Requirements
- Advertising and Matching -
• The language must support:
– Description of the functionality of the core
component service
• Knowledge state
• Data interfaces
–
–
–
–
16/11/2003
Description of a wide range of characteristics
Relaxation of certain properties
Definition of service request
Ordering, ranking and filtering of matches
11
Functional Requirements
- Advertising and Matching • The definition of service description must consider
issues like scale and distributed discovery
• No assumption should be made on the architecture
of discovery services that utilize or mediate service
descriptions and service requests
• One must be able to determine how a service
request relates to matching service descriptions
• “No Eyeballs Always Required”
• Consistency between advertise service descriptions
and their process descriptions
16/11/2003
12
Functional Requirements
- Advertising and Matching -
• Objectives:
– Possibility to identify cases where service
descriptions deviate a valid representation of the
service
– Sufficient accessible information for a human
intervention
– Easy for people to read, write and understand
service descriptions
16/11/2003
13
Functional Requirements
- Contracting and Negotiation -
• The language must support
–
–
–
–
–
–
–
–
–
16/11/2003
Wide variety of attributes/aspects of a deal
Committed/proposed contractual agreements
Partial/complete contracts or contract proposals
Representation of business partner qualification
Communication between contracting parties
Modification of proposed/committed deals
Execution of contract provisions
Monitoring of execution of committed deals
Hypothetical reasoning about the
contract/proposal
14
Functional Requirements
- Contracting and Negotiation -
• Objectives
– Complement development of standard/common
ontologies for frequently needed contract
characteristics
– Complement other emerging standard efforts
– Should seek to represent commitments in such a
way as to mesh well all methods of dispute
resolution and recourse
– Should seek to be compatible with the contract
aspects of the existing industry standards for web
services
16/11/2003
15
Functional Requirements
- Process Modeling -
•
•
•
•
16/11/2003
Ordering and temporal constraints
State constraints
Resource constraints
Composition
16
Functional Requirements
- Process Modeling -
• Objectives
– Compatibility with existing process modeling
standards
– Support mappings from existing process modeling
software tools.
16/11/2003
17
Functional Requirements
- Enactment • Describe and allow for the invocation of services via
service endpoints
• Recognize and handle exceptions
• Constraint checking
• Security aspects
• Policy aspects
• "Make it so" elements to link to the environment
• Dealing with the status of services, resource levels,
epistemic states of actors
• Logging, metering, billing, auditing, notification
16/11/2003
18
Functional Requirements
- Enactment •
•
•
•
•
•
•
Services metrics, Quality of Service guarantees
Dispute Resolution and Compliance
Explanation
Health checks and debugging aids
Redundancy and Robustness
Resource allocation and load balancing
Allowance for dynamic runtime aspects of discovery,
composition and negotiation of services on-the-fly
• Version update while services are live
16/11/2003
19
Functional Requirements
- Enactment -
•
Objectives
–
–
16/11/2003
complement well other emerging standards
efforts relevant to enactment and execution
significant enhancement to existing or emerging
web service enactment protocols
20