200 likes | 271 Views
Semantic Web Services Language Requirements. Presenter: Emilia Cimpian. http://www.daml.org/services/swsl/requirements/. Overview of Topics. Introduction Formalization (General Requirements) Functional Requirements. Introduction. SWSI Language Committee
E N D
Semantic Web Services Language Requirements Presenter: Emilia Cimpian http://www.daml.org/services/swsl/requirements/
Overview of Topics • Introduction • Formalization (General Requirements) • Functional Requirements
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
Introduction • Requirements (SWSL): • Formalization • Functional
General Requirements • General Language Properties • Expressive Power • Meta Properties
General Requirements- General Language Properties - • Declarative semantics • Compositional • Extensible
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
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
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
Functional Requirements • Advertising and Matching • Negotiation and Contracting • Process Modeling • Process Enactment
Functional Requirements- Advertising and Matching - • The language must support: • Description of the functionality of the core component service • Knowledge state • Data interfaces • Description of a wide range of characteristics • Relaxation of certain properties • Definition of service request • Ordering, ranking and filtering of matches
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
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
Functional Requirements- Contracting and Negotiation - • The language must support • 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
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
Functional Requirements- Process Modeling - • Ordering and temporal constraints • State constraints • Resource constraints • Composition
Functional Requirements- Process Modeling - • Objectives • Compatibility with existing process modeling standards • Support mappings from existing process modeling software tools.
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
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
Functional Requirements- Enactment - • Objectives • complement well other emerging standards efforts relevant to enactment and execution • significant enhancement to existing or emerging web service enactment protocols