=Paper=
{{Paper
|id=Vol-223/paper-37
|storemode=property
|title=A Planner for Implementing Semantic Service Agents based on Semantic Web Services Initiative Architecture
|pdfUrl=https://ceur-ws.org/Vol-223/39.pdf
|volume=Vol-223
|authors=Önder Gürcan (Ege University),Geylani Kardas (Ege University),Özgür Gümüs (Ege University),Erdem Eser Ekinci (Ege University),Oguz Dikenelli (Ege University)
|dblpUrl=https://dblp.org/rec/conf/eumas/GurcanKGED06
}}
==A Planner for Implementing Semantic Service Agents based on Semantic Web Services Initiative Architecture==
https://ceur-ws.org/Vol-223/39.pdf
A Planner for Implementing Semantic Service Agents based
on Semantic Web Services Initiative Architecture
1 2
Önder Gürcan , Geylani Kardas , Özgür Gümüs ,
1
1
Erdem Eser Ekinci , and Oguz Dikenelli
1
1
Ege University, Department of Computer Engineering,
35100 Bornova, Izmir, Turkey
{onder.gurcan,ozgur.gumus,oguz.dikenelli}@ege.edu.tr
erdemeserekinci@gmail.com
2
Ege University, International Computer Institute,
35100 Bornova,Izmir
geylani.kardas@ege.edu.tr
Abstract. The Semantic Web Services Initiative Architecture (SWSA) describes the overall
process of discovering and interacting with Semantic Web services in three phases and de nes
a conceptual model to accomplish the speci ed requirements of these phases. This conceptual
model is based on semantic service agents that provide and consume semantic web services
1
and includes architectural and protocol abstractions. In this paper , a software platform
is de ned which ful lls fundamental requirements of SWSA's conceptual model including
all its sub-processes. Based on this software platform, requirements of the planner module
are identi ed 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 prede ned 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 Introduction
The Semantic Web Services Initiative Architecture (SWSA) committee, which has been contributed
2
by the Semantic Markup for Services (OWL-S) , Web Service Modeling Ontology (WSMO)
3 and
4
Managing End-to-End Operations-Semantics (METEOR-S) working groups, has created a set
of architectural and protocol abstractions that serve as a foundation for Semantic Web service
technologies[1]. The proposed SWSA framework builds on the W3C Web Services Architecture
working group recommendation
5 and attempts to address all requirements of semantic service
agents: dynamic service discovery, service engagement, service process enactment and management,
community support services, and quality of service (QoS). This architecture is based on the multi-
agent system (MAS) infrastructure because the speci ed requirements can be accomplished with
asynchronous interactions based on prede ned protocols and using goal oriented software agents.
The SWSA framework describes the overall process of discovering and interacting with a Seman-
tic Web service in three consecutive phases: (1) candidate service discovery, (2) service engagement,
(3) service enactment. The SWSA framework also determines the actors of each phase, functional
requirements of each phase and the required architectural elements to accomplish these require-
ments in terms of abstract protocols. Although it de nes a detailed conceptual model based on
MAS infrastructure and semantic web standards, it does not de ne the software architecture to
1
This work is supported in part by the Scienti c and Technical Research Council of Turkey, Project
Number: 106E008.
2
The OWL Services Coalition: Semantic Markup for Web Services (OWL-S), 2004,
http://www.daml.org/services/owl-s/1.1/
3
Web Service Modeling Ontology (WSMO) Working Group, http://www.wsmo.org/
4
Managing End-to-End Operations-Semantics (METEOR-S) Working Group,
http://lsdis.cs.uga.edu/projects/meteor-s/
5
W3C Web Services Architecture Working Group, Web Services Architecture Recommendation, 11 Febru-
ary 2004, http://www.w3.org/TR/ws-arch/
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 [2] can generate agent ontologies and agent codes from a WSDL
input le to create a wrapper agent that can use external web services. WSDL2Agent [3] describes
an agent based method for migrating web services to the semantic web service environment by
deriving the skeletons of the elements of the Web Service Modeling Framework (WSMF) [4] from a
WSDL input le with human interaction. WSIG (Web Services Integration Gateway) [5] supports
bi-directional integration of web services and Jade agents. WS2JADE [6] allows deployment of
web services as Jade agents' services at run time to make web services visible to FIPA-compliant
agents through proxy agents. But these tools only deal with the integration of agents and external
web services and do not provide any mechanism to realize the entire architectural and protocol
abstractions addressed by the SWSA framework. It's clear that there must be environments which
will simplify the development of SWSA-based software systems for ordinary developers.
The main contribution of this paper is to de ne a software platform which ful lls 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 contribu-
tion 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:
De nition of reusable template plans that includes abstract task structures for SWSA's sub-
processes 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 Semantic Service Platform Architecture
It is apparent that SWSA describes the architecture extensively in a conceptual base. However
it doesn't de ne 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 ful lled.
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 prede ned execution
protocols.
The External Service Agent converts either WSDL or OWL-S de ned external services into
agents that are able to execute SWSA's de ned 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 prede ned SWSA sub-processes.
Semantic Service Kernel External Service Agent
Service Layer Service Layer
External
Monitoring Service
Service
Ontology Server WSDL2OWLS
Plan Generator
Match Maker Ontology Mapping &
Translation Service Monitoring Service
Planning Layer Planning Layer
Plan Library Plan Library
Domain Plans Domain Plans
Service Architecture External Service Plan
Kernel Plan Interfaces Interfaces
Semantic Semantic
Knowledge Knowledge
Manager Planning Module Manager Planning Module
Goal Matcher Goal Matcher
Plan Executer Plan Executer
Communication Layer Communication Channel Communication Layer Communication Channel
HTTP - IIOP
Fig. 1. The software architecture of the Semantic Service Platform: Two main models are Semantic Service
Kernel and External Service Agent. The kernel provides architectural components for an agent to execute
sub-processes of SWSA. On the other hand, External Service Agent provides integration of external services
(either purely de ned in WSDL or OWL-S) into the agent platform. Communication takes place via the
well-known HTTP - IIOP (Internet Inter-ORB Protocol).
2.1 Realization of service discovery process
In order to realize semantic service discovery, the platform services should be registered to a match-
maker 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 pro les. As previously implemented in SEAGENT
6 environment [7],
the capability matching of the requested and registered service advertisements herein, is also based
on the algorithm given in [8] and deals with semantic distances between input/output parameter
concepts of related services. The details of the implemented capability matching may be found
in [9] and [10]. However, in addition to the above mentioned matching algorithm, Matchmaker
service of our proposed platform also supports semantic match only on types of services (exclud-
ing input/output parameter match). Therefore, a client may indicate his/her preferred capability
matching approach to the matchmaker and matchmaker performs capability matching upon this
client's preference.
Based on domain knowledge of the related application, the Semantic Service Platform provides a
meta-pro le de nition 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 prede ned meta-pro les 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 pro le model than platform's meta-de nitions. 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-pro le 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 de ned 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 pro le to the matchmaker service and receives advertisement pro les of
semantically appropriate services. The suitable communication protocol and content language for
the client has already been designed and implemented for OWL-S services [9].
6
http://seagent.ege.edu.tr/
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 pro les 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 engage-
ment 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.) de ned in various studies [11,12]
which address this issue. When both sides (client and service) agree on the quality metrics, the rst
stage of the process is nished.
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 de ned 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, certi cation, 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 de nition 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 be-
tween 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 prede ned 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 de ned in his enactment plan.
In the following, we rst brie y 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 SEAGENT Planner
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 decom-
position 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[13,14], and the formal
underpinnings were developed in the mid-90s[15]. In an HTN planning system, the objective is to
accomplish a partially-ordered set of given tasks (plan) and a plan is correct if it is executable, and
it accomplishes the given tasks. That is, the main focus of an HTN planner is to perform tasks,
while a traditional planner focuses on achieving a desired state.
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[16] and DECAF architecture[17].
As a requirement of HTN, tasks might be either complex (called behaviours) or primitive (called
actions). Each plan consists of a complex root task consisting of sub-tasks to achieve a prede ned
goal. Behaviours hold a 'reduction schema' knowledge that de nes the decomposition of the com-
plex task to the sub-tasks and the information ow between these sub-tasks and their parent task.
The information ow mechanism is as follows: each task represents its information need by a set
of provisions and the execution of a task produces outcomes, and there are links that represents
the information ows between tasks using these provision and outcome slots. Actions are primitive
tasks that can be executed directly by the planner. Also, each task produces an outcome state after
its execution. Default outcome state is OK and usually it is not shown explicitly. The outcome
states are used to route the information ow between tasks.
<>
*
Task Outcome
* #defineName() -name
ProvisionLink #defineProvision() +getValue()
-senderTaskClassName #defineOutcome()
-senderTaskOutcomeName +isAllProvisionsAreSet()
-targetTaskClassName *
-targetTaskOutcomeName Provision
-name
+isSet()
*
InheritanceLink
-senderProvisionName
<> <>
-targetTaskClassName
-targetProvisionName Behaviour Action
#defineSubtask() +do()
* #defineProvisionLink()
DisinheritanceLink #defineInheritanceLink()
-senderTaskClassName #defineDisinheritanceLink()
-senderOutcomeName -reduct()
-targetOutcomeName
Fig. 2. Components of SEAGENT plan structure
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 re-
execution 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 prede ned HTN based plan. In the following, we brie y explain
responsibilities of each module during plan execution.
Planner
Execution Unit
Plan Library
Waiting task
<>
queue
Dispatching
Plan
Scheduler Executor Knowledge base
<>
Goal Matching
Plan
Ready action
queue
Fig. 3. Overall structure of SEAGENT planner
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 mes-
sages 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-de ned 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 brie y explain the details each planning module, and their responsibilities. The execu-
tion 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. Sched-
uler'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-de ned plan by
querying the plan library which is constructed using plan ontology and match ontology. This plan
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 Planning Requirements of SWSA
As mentioned in Sect. 2, the Semantic Service Kernel includes the required infrastructure and archi-
tectural components for an agent to execute subprocesses of SWSA. Such an environment simpli es
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 pro les of candidate services after its execution completes. Then these service pro les 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.
provisions outcomes
inheritance disinheritance
link link
abstract characteriaztions output list
of candidate service
Execute Service
sub-task
relations
abstract characteriaztions candidate candidate selected output list
service provider
of candidate service sevices sevices service provider
Discover Engage with Enact Service
Candidate Sevices a Service
service service
agreement agreement
provision links
Fig. 4. HTN plan for SWSA based Semantic Service Execution
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:
De nition of reusable template plans that includes abstract task structures for SWSA's sub-
processes and usage of these templates for generating agent's real plans by specializing these
abstract tasks.
abstract characteriaztions candidate
of candidate service sevices
Discover
Candidate Sevices
abstract characteriaztions query candidate
message conversation id conversation id
of candidate service message sevices
Form a Query for Send Message Select Service(s)
Service Discovery
Fig. 5. Decomposed view of the task for service discovery. The answer for the sent message contains service
pro les.
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 speci c domains. Such a template plan must include abstract tasks which can be spec-
i ed based on the domain requirements. So, the plan structure must provide mechanisms
to de ne and specify such abstract task constructs for developers. Without such a planning
mechanism, it is impossible to de ne reusable plan templates for executing SWSA processes.
For example, in service discovery, the client agent, rst forms a query using the required
service's pro le and sends it to the matchmaker service, then receives advertisement pro les
of semantically appropriate services and nally applies a service selection policy to return
a collection of suitable pro les. The abstract plan for this service discovery process is il-
lustrated 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.
candidate selected
sevices service provider
Engage with
a Service
service
agreement
OK
service candidate candidate candidate candidate selected
profiles sevice sevice sevice sevice service provider
service
Negotitate with agreement
Select a Service Assure on Parameters
Candidate Service
unselected unselected unselected
OK unselected unselected
sevices sevices sevices sevices sevices
fail fail
candidate selected
sevices service provider
Engage with
a Service
service
agreement
Fig. 6. Decomposed view of the task for service engagement. Engage with a Service task contains itself
as a subtask.
Reserve Hotel
preference info preference info hotel info hotel info reservation reservation
Take User Preferences Find a Hotel Make Hotel Reservation Show Reservation Result
hotel info room room reservation
Find a Room Make Room Reservation
Fig. 7. Hotel reservation plan. Find a Hotel, Find a Room and Make Room Reservation sub-tasks of
the plan are concrete realizations of Execute Service task.
4.1 SWSA Support in Planning Level
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 satis ed 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 de ned in reusable template plan can be extended (by rede nition of abstract tasks)
to concrete plans. The important point here is the con iction of the speci cations of the abstract
task to be extended (provision and outcome de nitions) and speci cations of the extended concrete
task. To implement a template plan, construct the plan as a normal plan but use abstract task
de nitions where you want to make abstract tasks.
In SEAGENT, to de ne sub-tasks, defineSubtask() method is used by giving the class name
of the sub-task as a parameter. If we want to de ne 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 de ned
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 de ning 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 in nite loop
arises and our agent crashes.
Constitution of Composite Services support Constitution of composite services is simple in
SEAGENT, because there are prede ned 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 Conclusion
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 de ned, not implemented. In this paper, a new MAS
software platform, which aims to concretely ful ll 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 prede ned HTN
plans. We have also discussed necessary properties of an agent planner which can execute those
de ned 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 discov-
ery 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
de nition 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.
References
1. Burstein, M., Bussler, C., Zaremba, M., Finin, T., Huhns, M., Paolucci, M., Sheth, A., Williams, S.: A
semantic web services architecture. IEEE Internet Computing Volume 9 Issue 5 (2005) 72 81
2. Varga, L.Z., Ákos Hajnal, Werner, Z. In: Engineering Web Service Invocations from Agent Systems.
Volume 2691. Lecture Notes in Computer Science (2003) 626 635
3. Varga, L.Z., Ákos Hajnal, Werner, Z. In: An Agent Based Approach for Migrating Web Services to
Semantic Web Services. Volume 3192. Lecture Notes in Computer Science (2004) 381 390
4. Fensel, D., Bussler, C.: The web service modeling framework wsmf. Electronic Commerce Research
and Applications 1 (2002) 113137
5. Greenwood, D., Calisti, M.: Engineering web service - agent integration. In: SMC (2), IEEE (2004)
19181925
6. Nguyen, T.X., Kowalczyk, R.: Ws2jade: Integrating web service with jade agents. In: AAMAS'05
Workshop on Service-Oriented Computing and Agent-Based Engineering (SOCABE'2005). (2005)
7. Dikenelli, O., Erdur, R.C., Özgür Gümüs, Ekinci, E.E., Önder Gürcan, Kardas, G., Seylan, I., Tiryaki,
A.M.: Seagent: A platform for developing semantic web based multi agent systems. In: AAMAS, ACM
(2005) 12711272
8. Paolucci, M., Kawmura, T., Payne, T., Sycara, K.: Semantic matching of web services capabilities. In:
First Int. Semantic Web Conf. (2002)
9. Dikenelli, O., Gümüs, Ö., Tiryaki, A., Kardas, G.: Engineering a multi agent platform with dynamic
semantic service discovery and invocation capability. In Eymann, T., Klügl, F., Lamersdorf, W., Klusch,
M., Huhns, M.N., eds.: MATES. Volume 3550 of Lecture Notes in Computer Science., Springer (2005)
141152
10. Kardas, G., Gümüs, Ö., Dikenelli, O.: Applying semantic capability matching into directory service
structures of multi agent systems. In: ISCIS. Volume 3733 of Lecture Notes in Computer Science.,
Springer (2005) 452461
11. Zeng, L., Benatallah, B., Dumas, M., Kalagnanam, J., Sheng, Q.Z.: Quality driven web services com-
position. In: WWW '03: Proceedings of the 12th international conference on World Wide Web, New
York, NY, USA, ACM Press (2003) 411421
12. Cardoso, J., Sheth, A.P., Miller, J.A., Arnold, J., Kochut, K.: Quality of service for work ows and web
service processes. J. Web Sem. 1 (2004) 281308
13. Sacerdoti, E.: The nonlinear nature of plans. In: International Joint Conference on Arti cial Intelligence.
(1975)
14. Tate, A.: Generation project networks. In: International Joint Conference on Arti cial Intelligence.
(1977) 888 893
15. Erol, K., Hendler, J.A., Nau, D.S.: Complexity results for htn planning. Ann. Math. Artif. Intell. 18
(1996) 6993
16. Sycara, K., Williamson, M., Decker, K.: Uni ed information and control ow in hierarchical task
networks. In: Working Notes of the AAAI-96 workshop 'Theories of Action, Planning, and Control'.
(1996)
17. Graham, J.R., Decker, K., Mersic, M.: Decaf - a exible multi agent system architecture. Autonomous
Agents and Multi-Agent Systems 7 (2003) 727