ServLog: A Unifying Logical Framework for Service Modeling and Contracting

Tracking #: 1421-2633

Authors: 
Dumitru Roman
Michael Kifer

Responsible editor: 
Axel Polleres

Submission type: 
Full Paper
Abstract: 
Implementing semantics-aware services, which includes semantic Web services, requires novel techniques for modeling and analysis. The problems include automated support for service discovery, selection, negotiation, and composition. In addition, support for automated service contracting and contract execution is crucial for any large scale service environment where multiple clients and service providers interact. Many problems in this area involve reasoning, and a number of logic-based methods to handle these problems have emerged in the field of Semantic Web Services. In this paper, we lay down theoretical foundations for service modeling, contracting, and reasoning, which we call ServLog, by developing novel techniques for modeling and reasoning about service contracts with the help of Concurrent Transaction Logic. With this framework, we significantly extend the modeling power of the previous work by allowing expressive data constraints and iterative processes in the specification of services. This approach not only captures typical procedural constructs found in established business process languages, but also greatly extends their functionality, enables declarative specification and reasoning about services, and opens a way for automatic generation of executable business processes from service contracts.
Full PDF Version: 
Tags: 
Reviewed

Decision/Status: 
Accept

Solicited Reviews:
Click to Expand/Collapse
Review #1
Anonymous submitted on 15/Aug/2016
Suggestion:
Accept
Review Comment:

I see my comments addressed and recommend the paper for publication.

To give some more details:

Connection to the Semantic Web:
The connection to the Semantic Web and especially RDF could be stronger in the paper, but the authors convinced me with their remark that the agreement for the kind of service descriptions in such a way as presented still needs to be made (and it is not even sure that the agreement will involve RDF). Therefore, I am looking forward to seeing my open questions solved by future contributions.

Description of tasks:
With my comment about the functionality I referred to the sentence

"A contract specification has to describe the functionality of a service, values to be exchanged, procedures, and guarantees."

which is in the second paragraph of the introduction. I understood that part as the "promises" the authors make about their framework and therefore especially checked the paper for these. I did not find explicit descriptions of the functionalities of services, but as the other "promises" are hold, I just add this comment here to clarify.

I thank the authors for their patience answering all my questions.


Comments