The Semantic Web Services Initiative Architecture (SWSA) describes the overall process of discovering and interacting with Semantic Web services in three phases and denes a conceptual model to accomplish the specied requirements of these phases. This conceptual model is based on semantic service agents that provide and consume semantic web services and includes architectural and protocol abstractions. In this paper 1, a software platform is dened which fullls fundamental requirements of SWSA's conceptual model including all its sub-processes. Based on this software platform, requirements of the planner module are identied and such a planner has been implemented. The developed planner has the capability of executing plans consisting of special tasks for semantic service agents in a way that described in SWSA. These special tasks are predened to accomplish the requirements of SWSA's sub-processes and they can be reused in real plans of semantic service agents both as is and as specialized according to domain requirements.
1,
realize this conceptual model and does not include the theoretical and implementation details of the required software architecture.
There have been a few partial implementations to integrate web services and FIPA compliant
agent platforms. WSDL2Jade [
The main contribution of this paper is to dene a software platform which fullls fundamental requirements of SWSA’s conceptual model including all its sub-processes. Then, these sub-processes are modeled as reusable plans for development of semantic service agents. And the second contribution of this paper is to develop a planner that has the capability of executing these kinds of plans. So, the developed planner has the innovative features listed below:
Denition of reusable template plans that includes abstract task structures for SWSA’s subprocesses and usage of these templates for generating agents’ real plans by specializing these abstract tasks Support for recursion on the plan structure
Constitution of composite services by using reusable semantic service agent plans The paper is organized as follows: in Sect. 2, the proposed architecture of the Software Platform for the SWSA framework is given. Section 3 introduces the planner component of the platform. Planning requirements of SWSA and our solution are discussed in Sect. 4. Conclusion and future work are given in Sect. 5. 2
It is apparent that SWSA describes the architecture extensively in a conceptual base. However it doesn’t dene required details and theoretical infrastructure to realize the architecture. Hence, we propose a new software platform in which above mentioned fundamental requirements of all SWSA’s sub-processes (service discovery, engagement and enactment) are concretely fullled.
The software architecture of the proposed Semantic Service Platform is given in Fig. 1. The platform is composed of two main modules called Semantic Service Kernel and External Service Agent.
The Semantic Service Kernel includes the required infrastructure and architectural components for an agent to execute sub-processes of SWSA. The agent’s actions, to be used in semantic service discovery, engagement and enactment, are modeled as reusable plans and will be executed in a composite fashion by a planner. The sub-tasks, which compose the plan, will execute SWSA’s sub-processes by invoking the related services. Invocation will be realized via predened execution protocols.
The External Service Agent converts either WSDL or OWL-S dened external services into agents that are able to execute SWSA’s dened processes. This module includes inner services like WSDL to OWL-S Converter, Ontology Mapper and Translator -that provides mapping of services into the platform’s ontologies, stores those mapping ontologies and serves ontology translation- and Monitor service that monitors quality of service parameters. Planner component of the External Service Agent realizes registration of the related service into the platform and executes interaction plans concerning service engagement and enactment. Those plans are formed automatically during the creation phase of the External Service Agent and stored in the plan library as domain plans.
In the following subsections, we discuss details of how our proposed semantic service platform meets the requirements of the SWSA taking into consideration predened SWSA sub-processes.
Semantic Service Kernel Service Layer
Monitoring Service
Match Maker Planning Layer
Semantic Knowledge Manager
Ontology Server Plan Library Domain Plans Service Architecture Kernel Plan Interfaces Planning Module Goal Matcher Plan Executer
External Service Agent Service Layer WSDL2OWLS Ontology Mapping & Translation Service Planning Layer
Semantic Knowledge Manager
External Service
Plan Generator Monitoring Service Plan Library Domain Plans External Service Plan Interfaces Planning Module Goal Matcher
Plan Executer Communication Layer
Communication Channel
Communication Layer
Communication Channel
HTTP - IIOP In order to realize semantic service discovery, the platform services should be registered to a matchmaker and service clients should query on this matchmaker and have ability to interpret resultant service advertisements.
The Matchmaker service of the Semantic Service Platform stores capability advertisements of
registered services as OWL-S proles. As previously implemented in SEAGENT 6 environment [
Based on domain knowledge of the related application, the Semantic Service Platform provides a meta-prole denition for platform services those to be registered, discovered and invoked within the platform. Hence, in this approach, Semantic Service Kernel plans, which include client invocation codes, may be prepared easily by only using those predened meta-proles of services. However this naturally exposes an ontology mapping requirement when an outer service, which is needed to be included in the platform, has a dierent prole model than platform’s meta-denitions. It is aimed to bring a solution to this problem by using capabilities of the ontology mapping and translation service of the External Service Agent. So, advertisement plan of the External Service Agent supports platform administrators to be able to map platform’s meta-prole with the related external service’s ontology by using mapping service via a user interface.
It should be noted that discovery process of the client, has already been dened as a reusable
plan template in the Semantic Service Kernel. So, the content of this plan template is determined
during domain based application development and this creates the application dependent plan
of the discovery process. The client agent, which uses the related created discovery plan, rst
sends the required service’s prole to the matchmaker service and receives advertisement proles of
semantically appropriate services. The suitable communication protocol and content language for
the client has already been designed and implemented for OWL-S services [
Another important task of the discovery process is the service selection policy of the requester client. The Matchmaker of the platform may return a collection of suitable service proles for the client’s requests in many cases and client should apply a policy into the result collection to select the service(s) for further engagement and enactment processes. The Semantic Service Platform provides extensible service selection policy structures for plan designers to add various selection criteria into the service user agent plans. 2.2
Realization of service engagement process After completion of the service selection, the client-service engagement process begins. The engagement process has 2 stages: (1) negotiation on quality of service metrics between client and service agents and (2) agreement settlement.
The rst stage of the engagement process includes determination of the exact service according
to quality of service (QoS) metrics. Currently, there exists no standard for the service quality
metrics. However, during the exact service determination, our proposed service platform utilizes
some QoS parameters (like service cost, run-time, location, etc.) dened in various studies [
The engagement process is completed after determined service’s OWL-S process ontology and QoS parameters are sent to the Monitoring Service for being monitored during service execution. 2.3
Realization of service enactment process Conceptually, enactment can be dened as the invocation of the engaged service by the client agent. However, enactment includes more than just invocation and it should take into consideration monitoring, certication, trust and security requirements of service calls.
Execution of composite semantic services (which are modeled using OWL-S) is maintained in the platform by means of a planning approach. The approach herein, provides denition of service templates for each atomic service of the composite service and realizes composition of the service by linking those atomic subprocesses.
Service execution also requires monitoring of the invocation according to the engagement between client agent and the server. Monitoring services of the Semantic Service Kernel and External Service Agent both monitor execution of services and check whether current interaction conforms to the predened QoS metrics and engagement protocol or not. Hence, the Monitoring service of the External Service Agent informs the platform’s monitoring service about the produced values of the quality metrics during service execution. According to the state of the ongoing interaction, the informed client agent may change his task execution behavior as dened in his enactment plan.
In the following, we rst briey explain the details of our planning module, and its mechanism. Then we explain the planning requirements of SWSA and how these requirements are accomplished in our planning mechanism. 3
Since planning systems that are knowledge-based and hand tailor-able are the most promising
ones to solve the real-world planning problems, the planner of our MAS development framework,
called SEAGENT, is based on the Hierarchical Task Networking (HTN) planning formalism. HTN
Planning is an AI planning methodology that creates plans by task decomposition. This
decomposition process continues until the planning system nds primitive tasks that can be performed
directly. The basic idea of HTN planning was propounded in the mid-70s[
A plan is a representation of future behaviour, hence, in our platform, all behaviours of agents (even planning) are plans. To provide such a mechanism we use a task execution unit whose only job is to execute and schedule executable entities. Initially, a planning unit should provide two basic mechanisms: dispatching and goal matching. By dispatching we mean sending outgoing messages, fetching incoming messages and creating objectives from that messages when required. By a goal matching we mean matching the objectives to suitable plans. 3.1
Plan Structure
Our framework is similar to the frameworks presented by Sycara et. al[
-senderTaskClassName -senderTaskOutcomeName -targetTaskClassName -targetTaskOutcomeName
-senderProvisionName -targetTaskClassName -targetProvisionName
DisinheritanceLink -senderTaskClassName -senderOutcomeName -targetOutcomeName * * * <<abstract>>
Task #defineName() #defineProvision() #defineOutcome() +isAllProvisionsAreSet() <<abstract>>
Behaviour #defineSubtask() #defineProvisionLink() #defineInheritanceLink() #defineDisinheritanceLink() -reduct() <<abstract>>
Action +do() *
-name +getValue() * Provision -name +isSet()
Components of our plan structure are shown in Fig. 2. Tasks have a name describing what they are supposed to do and have zero or more provisions (information needs) and outcomes (execution results). The provision information is supplied dynamically during plan execution. Tasks are ready, and thus eligible for execution, when there is a value for each of its provisions and this is checked via isAllProvisionsAreSet() method. A task that has no provisions is always ready. Upon execution, a task consumes its provisions and produces outcomes if any. Tasks may be designated by the developers as periodic (cyclic). A periodic task is rescheduled upon execution for sub-sequent reexecution according to its associated period. Unlike other HTN frameworks mentioned above, we do not support external provisions. The reason for that is, in our platform agents that are resident on the same machine are attached to an Agent Communication Channel (ACC) which carries out all of the messaging of this agents. Agents’ are just responsible for fetching their messages from that ACC and/or giving messages to that ACC (described in Sect. 3.2). Then ACC makes all the job (physical transfer of messages over HTTP - IIOP etc.). That’s why all provisions are internal provisions whose value’s are internally set within the plan. This means, the value of a provision is determined by an outcome of another task.
As described above, actions are directly executable tasks (using Do() method), while behaviours are complex tasks whose execution depends on the execution of all its sub-tasks. Behaviours’ role is to control the execution of its subtasks. Behaviours hold a ’reduction schema’ knowledge that describes which sub-tasks it is composed of and the information ow relationships between them.
Propagation of output values of the executed task to other dependent task(s) is handled by the owner behaviour since it is the only construct that knows the relationships. 3.2 Internal Architecture The overall structure of our planner’s architecture (Fig. 3) is designed to execute HTN structure(s). In order a plan to be executed, the complex root task must be opened using the ’reduction schema’ knowledge, and this reduction continues until the actions are found, and then the execution unit executes these actions. The planner basically is composed of the following functional modules: an execution unit, a periodic dispatching plan, and a periodic goal matching plan. All together, they match the goal extracted from the incoming FIPA-ACL message to an agent plan, schedule and execute the plan following the predened HTN based plan. In the following, we briey explain responsibilities of each module during plan execution.
Execution Unit
Waiting task
queue Scheduler
Executor Ready action queue <<cyclic>> Dispatching
Plan <<cyclic>> Goal Matching
Plan
Knowledge base
Plan Library
The planner is responsible for processing incoming and outgoing messages, goal matching, scheduling and executing tasks. The mechanism of the planner is as follows: New FIPA-ACL messages are fetched by the Dispatching plan. Then the Dispatching plan parses these messages and checks whether they are part of an ongoing conversation or not. In latter case, it puts the message to the knowledge-base as an incoming message. In former case, where the incoming message is not part of an ongoing conversation, it creates a new objective, and puts it to the knowledge-base as a new objective knowledge. The Goal Matching plan continuously checks the knowledge-base whether there are new objectives or not. When it nds one, the Goal Matching plan matches it to a pre-dened plan by the querying the plan library which is resident on knowledge-base. If this match process succeeds, this plan creates an instance of the matched plan and gives it to the execution unit for execution. After all, how this plan will be carried out is handled by the plan itself.
Now, we briey explain the details each planning module, and their responsibilities. The execution unit is responsible for executing and scheduling submitted executable tasks. The task executor is composed of a scheduler and an executor module. Each module runs concurrently in a separate Java thread and uses the common data structures such as waiting queue and ready queue. Scheduler’s role is to determine the execution time of each task. If a task is ready (all its provisions are set) and it is time to execute it, Scheduler removes it from the waiting queue and puts it to the ready queue. Executor, on the other hand, executes the ready tasks by invoking their execute() method and puts periodic tasks to the waiting queue for re-execution.
Dispatching plan is a cyclic plan which is responsible for incoming and outgoing messages and creating objectives for agents. It periodically checks ACC for incoming messages and fetches them (by putting them to the knowledge-base) if there is any. It also periodically checks knowledge-base for outgoing messages. Because when the agent intends to send a message, it simply puts it to the knowledge-base.
Goal Matching plan is responsible for matching the incoming objective to a pre-dened plan by querying the plan library which is constructed using plan ontology and match ontology. This plan inheritance link provisions sub-task relations periodically checks knowledge-base whether a new objective is occurred or not. When there is a new objective, it tries match a plan from the plan library for that objective. If the match process succeeds, Goal Matching plan creates an instance of the plan and submits it to the execution unit for execution.
Here after, the responsibility of the execution of the plan is belonged to the root task of the plan. Because a behaviour is said to be accomplished when all its subtasks are performed. So, the life cycle of a plan is as follows: It rst reducts itself to its subtasks, and submits them to the execution unit for execution. Then it checks them until they all are executed. 4
As mentioned in Sect. 2, the Semantic Service Kernel includes the required infrastructure and architectural components for an agent to execute subprocesses of SWSA. Such an environment simplies the overall process of executing semantic web services for ordinary developers. Client agent(s) in this environment, must provide plans to be used in semantic service discovery, engagement and enactment. Hence, in our platform, we modeled these plans as reusable plans.
Figure 4 shows the task tree of the HTN plan for service execution of client agents. Execute Service task represents the service execution process which was proposed by SWSA and is the root task of the plan that needs abstract characterizations of candidate services in order to be executed. It is composed of three sub-tasks: Discover Candidate Services, Engage with a Service and Enact Service (decomposition of these tasks are not shown in this gure). Discover Candidate Services task inherits the abstract characterization of candidate services from its parent task and produces service proles of candidate services after its execution completes. Then these service proles are passed to Engage with a Service task via a provision link and then the execution of this task begins. Engage with a Service task nishes by producing two outcomes: selected service provider and service agreement. These outcomes are consumed by Enact Service task in order to complete the nal part of the plan. This task executes the selected service and passes the output list of its execution to its parent task.
As discussed above, SWSA processes are controlled and monitored by Semantic Service Kernel. The planner is at the heart of the architecture which controls the work-ows of the SWSA processes. Each of these processes are modeled as reusable plans and the developed planner must have the innovative features in order to have the capability of executing these kind of plans. These features are listed below: Denition of reusable template plans that includes abstract task structures for SWSA’s subprocesses and usage of these templates for generating agent’s real plans by specializing these abstract tasks.
Some parts of processes introduced by SWSA is abstract because, they change according to domain. Hence, it must be possible to generate a template plan for SWSA and realize it on specic domains. Such a template plan must include abstract tasks which can be specied based on the domain requirements. So, the plan structure must provide mechanisms to dene and specify such abstract task constructs for developers. Without such a planning mechanism, it is impossible to dene reusable plan templates for executing SWSA processes. For example, in service discovery, the client agent, rst forms a query using the required service’s prole and sends it to the matchmaker service, then receives advertisement proles of semantically appropriate services and nally applies a service selection policy to return a collection of suitable proles. The abstract plan for this service discovery process is illustrated in Fig. 5. As shown in the gure, Form a Query for Service Discovery task and Select Service(s) task are abstract. Former is abstract because the query could be formed either according to service type or input/output parameter types or etc. Latter is abstract because developers should be able to use various service selection criteria.
Support for recursion on the plan structure.
By a recursion we mean a situation where one instance of a task is an ancestor in the task network of another instance of the same task. Consider the engagement process of the client agent given in Sect. 2.2. At rst, one of the candidate services are chosen and then completeness of all service invocation parameters is assured. After the assurance, negotiation on QoS metrics and agreement settlement are performed. If either assurance or negotiation tasks fail, the engagement process will be restarted for unselected services (Fig. 6). To provide this iteration the plan structure must have support for recursion. Such a support needs the ability for a task to contain itself as a sub-task (in Fig. 6, Engage with a Service contains itself as a sub-task).
Constitution of composite services by using semantic service execution plans in agent’s real plans.
To generate domain dependent service execution plans, developers must realize Execute Service template plan shown in Fig. 4. Consider the HTN plan for reserving a hotel room shown in Fig. 7. Reserving a hotel is as follows: rst user preferences are taken, and according to these preferences a hotel is found, then it is tried to make a reservation with that hotel and nally results are shown to the user. In this plan, Find a Hotel, Find a Room and Make Room Reservation sub-tasks of the plan are concrete realizations of Execute Service task. They are connected with their provisions and outcome slots, and because they are domain dependent plans they know what input parameters they will take. service profiles candidate sevice unselected sevices candidate sevice unselected sevices Select a Service
Assure on Parameters
Negotitate with
Candidate Service Engage with a Service candidate sevice unselected OK sevices fail service agreement candidate sevice unselected sevices
selected service provider service agreement unselected sevices
fail
OK Engage with a Service the plan are concrete realizations of Execute Service task. As mentioned in Sect. 3, SEAGENT planner has innovative features to handle the work-ows of the SWSA processes. This section shows how these features are satised by SEAGENT planner. The built-in support makes implementing overall processes of SWSA easier for developers. Template plan support In SEAGENT it is possible to create template (generic) plans. The basic idea resembles abstract class logic in object orientation. That is, to construct a generic plan, describe the main characteristics of a plan leaving the variable parts (tasks) unimplemented. So that in the future they may be specialized and used (remember the service discovery plan in Fig. 5). The tasks dened in reusable template plan can be extended (by redenition of abstract tasks) to concrete plans. The important point here is the coniction of the specications of the abstract task to be extended (provision and outcome denitions) and specications of the extended concrete task. To implement a template plan, construct the plan as a normal plan but use abstract task denitions where you want to make abstract tasks.
In SEAGENT, to dene sub-tasks, defineSubtask() method is used by giving the class name of the sub-task as a parameter. If we want to dene an abstract sub-task, all we need to do is to give the name of the abstract sub-task indirectly. This can be done by using an abstract method that returns the name of the sub-task, and passing this abstract method as parameter to defineSubtask() method. For example, Select Service(s) abstract task in Fig. 5 can be dened in Discover Candidate Services parent task by using getSelectServicesTaskName() abstract method ( defineSubtask( getSelectServicesTaskName() ) . Concrete realization of this plan is made by extending this plan and implementing the abstract methods that return the class names of the concrete tasks.
Recursion support Recursion is another capability of SEAGENT planner. By a recursion we mean a situation where one instance of a task is an ancestor in the planning tree of another instance of the same task. This is usually used when we cannot satisfy something in a task and want to execute this task again but with dierent provisions until reaching the goal. Since there is no restriction on dening sub-tasks, a task may contains itself as a sub-task. But the important point here is that the decomposition of the successor task must be in control, just like in recursive methods in traditional programming. In SEAGENT, the decomposition of a task is checked via its provision’s state, that is, if all provisions are set or there is no provision then the task decomposes. So, in a recursive HTN plan, recursion tasks must contain at least one provision and the value of this provision must be dierent from its ancestor’s value (see Fig. 6). Otherwise an innite loop arises and our agent crashes.
Constitution of Composite Services support Constitution of composite services is simple in SEAGENT, because there are predened reusable template plans for service execution (see Fig. 4) in plan library and, developers can use these plans to construct their own domain dependent service execution plans and compose them just as building an ordinary plan (see Fig. 7). The important point here is the satisfaction of input/output compatibility and this is easily handled by the correct concrete realizations of the abstract tasks. 5
The SWSA is currently a working group recommendation and describes abstract infrastructures and related processes for semantic web services and agents interaction in a conceptual base. We believe that this architecture brings a comprehensive model of software agents which utilize and provide semantic web services. However this architecture is a product of an initiative study and most of its components are only theoretically dened, not implemented. In this paper, a new MAS software platform, which aims to concretely fulll fundamental requirements of the SWSA, has been introduced. We have modeled subprocesses of SWSA as reusable plans by HTN approach and provided a framework in which those plans can be executed in a composite fashion by agent planners. Hence, platform agents can accomplish execution of discovery, engagement and enactment processes for semantic web service interaction by employing those reusable and predened HTN plans. We have also discussed necessary properties of an agent planner which can execute those dened plans. Such a planner has been implemented based on the SEAGENT platform.
In the paper we focused on the requirements of the planner for execution of SWSA subprocesses. But we are also working on the other parts of the software architecture. For example, service discovery mechanisms for the platform are fully operational. Semantic capability matching of services has already been implemented and platform agents are currently able to invoke semantic web services in proper to OWL-S standards.
Perhaps our major weakness, considering both the software and reusable agent plans, is seen in denition and design of the service engagement sub-process. QoS topics are currently being studied and they weren’t addressed in detail by the service oriented computing community. Hence our QoS support during the engagement process is extremely primitive and only composes monitoring service. That support is also in its initial state. Security and trust mechanisms have not been considered yet in our implementation.