Figure 1: Diagram of executable phylogenetic analysis workflow
We are conducting research and development on pervasive computing, grid computing and enterprise software development based on the Semantic Web technologies. Task Computing (TC) is a user-oriented framework that lets end-users accomplish complex tasks in environments rich with applications, devices, and services. Task Computing provides many ways for users to interact with these ubiquitous environments and applies the Semantic Web technologies, such as OWL and OWL-S as its core enablers. Also in grid computing and enterprise software development projects, we strive to let end-users to accomplish complex tasks using services by utilizing OWL and OWL-S extensively.
Initially we did not have to resort much to rules, but as we proceed to add higher functionalities, it has become clear that the rules would play a major role and that the rules have to be shared. In this position paper, we list present and future requirements and use cases of rules in terms as concrete as possible. Some of them may be implemented without resorting to rules, but we tried to make the list as inclusive as possible.
Here we list the requirements for rule languages. They will be linked in the next use cases section.
As for [R-3], it should be possible to provide user interface to let end-users create rules basically in all of our applications. Logics and its expression or syntaxes can be somewhat (but, not too much) complex as long as the user interface is easy and reasonable and the results of rule applications are expectable for the users.
Unlike Web Services on the public Internet where the services are accessible from anywhere, service compositions of service instances are less useful in pervasive environments. In pervasive environments, the services (which are provided often from devices) are accessible only within a sub-network in many cases.
In order to enable meaningful service compositions even in pervasive environments, it is necessary to specify each service in the composition by some kind of rules, which the end-user can create on his/her own.
For example, one can compose and execute a service composition in Task Computing from two services, "My File" and "View on Projector". "My File" on your computer lets you select a file from your computer and expose it. "View on Projector" on the network shows on the projector the file given to it and let the user control the presentation. Combining them into a composition and executing it, the user can do a presentation without connecting the VGA cable to the projector.
Saving the service composition (in OWL-S) of those service instances is useful only as long as the user is on the same sub-network. But as soon as the user leaves the sub-network, the service composition becomes useless if the sub-network is inaccessible from the outside (for example, if it is behind a proxy). Even if the similar projector services is available in some other place, the service composition becomes non-executable.
But if the user can save the service composition, "Do the Presentation", something like the following set of conditions for the two consecutive services, it can be used in other environments.
|
Currently in Task Computing, service compositions are driven by semantic matching of input and output of the services. It can match the services when the output of the first service is a subclass of input of the next service.
Many of the matching are described using such a scheme using ontologies, but some of the conditions does not fit well and are done better as execution time input checking.
For example, we have "Route from FLA to" service which accepts an address as an input and displays the map from FLA to the given address. We might want to check the integrity of the address and limit the address to those of the mainland US. We might want to add, in its OWL-S, rules to check if the input address is in US and its state is not Hawaii.
|
Here we list rules necessary for semantic service descriptions and composition rules in enterprise system development and grid computing.
In enterprise systems, database accesses are essential. We need to capture the effect/result of database read action as something like "After the database read action, it is known that the book is checked out or that the book is not checked out". We assume that we need K- (epistemic) operator to express this.
We also need to express semantic level conditionals for loops and branches based on input, output, and errors the services.
|
Figure 1: Diagram of executable phylogenetic analysis workflow
In case of bioinformatics grid applications, rules can be used to help the user narrow down the options for applications to use for each workflow step. Figure 1 shows a diagram of executable phylogenetic analysis workflow with list of service fulfilling each required function. The application options for each step can be reduced by the user-specified rules. Example rules can be as follows:
|
Other general rules to determine which services to use include:
|
We have implemented prototypical policy-based access control for Task Computing. It uses Rei policy engine from UMBC.
In this schema, the credential is checked against its digital signature first. Then, the expiration date/time of the credential is compared against the current date/time to check if it is not expired. Finally, the content (fact assertions) of the credential, ontology, policy rules, and delegation rules are combined to determine if the person has the right. They are something like the following:
From those statements, the system determines that Visitor-A can print or that Employee-B can print. Or without delegation rules, the system determines that Visitor-A can not print.
|