ServLog: A Unifying Logical Framework for Service Modeling and Contracting

Tracking #: 1315-2527

Dumitru Roman
Michael Kifer

Responsible editor: 
Axel Polleres

Submission type: 
Full Paper
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: 

Minor Revision

Solicited Reviews:
Click to Expand/Collapse
Review #1
By Audun Stolpe submitted on 21/Mar/2016
Review Comment:

The authors have addressed all my comments to my satisfaction and I have nothing further to add.
This is an accept for me.

Review #2
Anonymous submitted on 25/May/2016
Minor Revision
Review Comment:

I see most of my comments considered and especially appreciate that the initialization of variables (connection to the database) and the description of primitive tasks is made more explicit. To go through the points in more detail:

1. Connection to the Semantic Web: My concern was mainly that I don't see how the approach could possibly interact with the rest of the semantic web. Many concepts which are very strong from the formal point of view (such as the presented one) ignore the fact that the semantic web is meant as a joint effort. Nothing is gained if everyone uses his own isolated logic. I do not believe that ServLog really is as isolated as it looks like in the paper. Therefore a part (or at least a citation) how ServLog can be combined with existing standards would be helpful. Is it possible to easily use other semantic data (possibly but of course not necessary in rdf) of the web? Maybe you could explain the complementary relation to WSMO and OWL-S in more detail. Can I use WSMO or OWL-S together with ServLog?

Or can you explain some more practical aspects: do you expect every service provider to have ServLog service constraints available? Then ServLog could become the standard for that? Where would I find that data in the web?

2. Motivational example: The example is now explained in a better way. Section 2 starts with a high level overview of the order placement scenario which indeed makes it easier to understand the concrete example. The example itself got simplified and it is made more clear how the variables get instantiated.

3. Description of tasks: I think it is an improvement that the authors now give examples for primitive tasks. I am still not really convinced that they describe the “functionality” of the services since they refer to other services and tasks the primitive task is composed of, instead of describing how the execution of the task changes the data or the state of the world. But I also see that you do not really need this aspect for your approach. So I would simply either not claim that you describe functionalities or add this aspect somewhere. But that is a minor remark.

More detailed comments and typos

- On page 5, figure 2, you have the constraint ~itemAvailable(Order#, Producer, Item) while you speak on page 12 of itemUnavailable(Order#, Producer, Item), I guess those two are the same?

- On page 6 you state:

In case of data-passing through a shared database, data can be consumable or non-consumable. It is consumable when each query to the databases is followed by deletion of the queried data item. It is non-consumable data if such deletion is not implied. In our example, *all data items are consumable*.

I guess that is not intended as it is not all „data passing“, but I first understood that part as if in the whole example process any item which is retrieved by a database query is deleted in the database afterwards. It could be helpful for the reader if you'd also say something about simple database queries just to make the difference to the „passing case“ clear.

- Figure 4: I think producer(?Item, ?Producer) is also a database query? It is not indicated in the comment.

- Page 2 (and also later), you sometimes write “Logic Programming” and sometimes “logic programming”.

The only thing which currently stops me from recommending the paper for publication (after fixing minor remarks) is the fact that I would like to see the framework to be better connected to the Semantic Web (Point 1). But I agree that this might be debatable.