Model-Driven
Agents
Design
of
Interoperable
Klaus Fischer* — Brian Elvesæter** — Arne-Jørgen Berre** —
Christian Hahn* — Cristián Madrigal-Mora* — Ingo Zinnikus*
* DFKI GmbH, Stuhlsatzenhausweg 3 (Bau 43), D-66123 Saarbrücken, Germany.
klaus.fischer@dfki.de
christian.hahn@dfki.de
cristian.madrigal-mora@dfki.de
ingo.zinnikus@dfki.de
** SINTEF ICT, P. O. Box 124 Blindern, N-0314 Oslo, Norway
brian.elvesater@sintef.no
arne.j.berre@sintef.no
This paper presents a model-driven approach to designing interoperable agents in
a service-oriented architecture (SOA). The approach provides a foundation for how to
incorporate autonomous agents into a SOA using principles of model-driven development
(MDD). It presents a metamodel (AgentMM) for an agent architecture for a specific style of
agents, i.e. BDI agents, and relates AgentMM to a platform-independent model for SOAs
(PIM4SOA). The paper argues that this mapping allows to design interoperable agents in the
context of SOAs. In the discussion of the two metamodels strengths and weaknesses of both
metamodels are discussed and extensions how each of them might be improved are presented.
ABSTRACT:
KEY WORDS:
Modelling, Metamodels, Agents, Model-Driven Development, Service-Oriented
Architectures.
Model-Driven Design of Interoperable Agents. Volume X – No. X/2006, pages 1 to n
2
Model-Driven Design of Interoperable Agents. Volume X – No. X/2006
1. Introduction
Model-driven development (MDD) is emerging as the state of practice for
developing modern enterprise applications and software systems. MDD frameworks
define a model-driven approach to software development in which visual modelling
languages are used to integrate the huge diversity of technologies used in the
development of software systems. As such the MDD paradigm provides us with a
better way of addressing and solving interoperability issues compared to earlier nonmodelling approaches (D'Souza 2001).
The current state of the art in MDD is much influenced by the ongoing
standardisation activities around the OMG Model Driven Architecture (MDA)
(OMG 2003). MDA defines three main abstraction levels of a system that supports a
business-driven approach to software development. From a top-down perspective it
starts with a computation independent model (CIM) describing the business context
and business requirements of the software system. The CIM is refined to a platform
independent model (PIM) which specifies software services and interfaces required
by the business independent of software technology platforms. The PIM is further
refined to a set of platform specific models (PSMs) which describes the realisation
of the software systems with respect to the chosen software technology platforms 1 .
An important aspect of defining a MDD framework is to develop metamodels
and model transformations. A metamodel describes the concepts and their
relationships for the purpose of building and interpreting models. Metamodels can
be developed for describing different business domains (e.g. eProcurement and
Telecom) and different software technology platforms (e.g. Web services and agent
systems). The OMG MDA specifies two core technologies for developing
metamodels and model transformations. The Meta Object Facility (MOF) (OMG
2004) is the common foundation that provides the standard modelling and
interchange
constructs
for
defining
metamodels.
The
MOF
Query/View/Transformation (QVT) (OMG 2005) provides a standard specification
of a language suitable for querying and transforming models which are represented
according to a MOF metamodel.
The focus of this paper is on PIM to PSM development. The basic idea is to
present a PIM for service-oriented architecture (PIM4SOA) (Benguria et al. 2006)
and compare it to a metamodel for a specific agent architecture (AgentMM). If a
mapping between the two is feasible, meaning that PIM4SOA models can actually
be translated into agent models, it is on the one hand possible to derive interoperable
agents when the design is started from PIM4SOA models and, on the other hand, to
clearly define under which circumstances given agent models are interoperable
according to the PIM4SOA.
1. The terms PIM and PSM are relative to the defined software platform.
Model-Driven Design of Interoperable Agents
3
The paper is structured as follows: In Section 2 we present the PIM4SOA
metamodel. In Section 3 we present the metamodel for a specific agent architecture.
In Section 4 we compare the two metamodels and discuss in Section 5 the
application of MDD for designing interoperable agents in a SOA. Conclusions and
future work is presented in Section 6.
2. Metamodel for Service-Oriented Architecture
The metamodel for service-oriented architectures (SOAs) addresses the
conceptual and technological interoperability barrier. It aims to define platform
independent modelling language constructs that can be used to design, re-architect
and integrate ICT infrastructure technologies supporting SOA. The concept of SOA
has growing its importance during these last years. Enterprises typically view SOA
as an IT solution and often the focus is on the technologies involved. The PIM4SOA
has the following goals:
– The PIM4SOA model should bridge the gap between the business analysts and
the IT developers and support mapping and alignment between enterprise and IT
models.
– The PIM4SOA model should define a platform independent abstraction that
can be used to integrate and define mappings to Web services, agent, peer-to-peer
(P2P) and Grid execution platforms.
PIM4SOA
Metamodel
Symbols
PIM
Metamodel
Concept
Relationship
PSMs
Correspondence
Web Services
Metamodel
Agent Metamodel
(AgentMM)
P2P
Metamodel
Grid
Metamodel
Figure 1. Mapping metamodel concepts between the PIM and PSMs
4
Model-Driven Design of Interoperable Agents. Volume X – No. X/2006
One challenge in defining the PIM4SOA metamodel is to decide which concepts
to include and abstract from the target execution platforms (PSMs) that support the
architectural style of service-orientation. The current version of the PIM4SOA
metamodel has a strong focus on supporting the Web services technology stack, as
this is the main enabling technology for implementing SOAs. Benguria et al.
(Benguria et al. 2006) describes the use of the PIM4SOA metamodel for defining
model transformations to specific Web service artefacts such as XML Schema
Definition (XSD), Web Service Definition Language (WSDL) and Business Process
Execution Language (BPEL) documents.
Future revisions of the PIM4SOA metamodel need to incorporate more of the
adaptive and dynamic concepts from the agent, P2P and Grid platforms. The
benefits of introducing agents, P2P and Grid concepts will enable us to design SOAs
that are more adaptable and flexible, and thus better able to cope with changes over
time – which is important for supporting interoperability. Figure 1 illustrates the
mapping of metamodel concepts between the PIM4SOA and the targets PSMs.
Concepts defined in the PIM4SOA metamodel should ideally map to at least two of
the target platforms.
In order to support an evolution of the PIM4SOA metamodel in which new
concepts from agent, P2P and Grid platforms can be incorporated, the PIM4SOA
metamodels is structured around a small core with extensions, each focusing on a
specific aspect of a SOA. Grouping modelling concepts in this manner allows for
metamodel evolution by adding new modelling concepts in the defined aspects,
extending existing modelling concepts in the defined aspects, or defining new
modelling concepts for describing additional aspects of SOAs (e.g. security).
The current version of the PIM4SOA metamodel defines modelling concepts that
can be used to model four different aspects of SOAs; services, information,
processes and non-functional aspects. The definition of these aspects has been
influenced by ongoing standardization initiatives in the area of Web services and
SOAs. Usage of already well-defined and standardized metamodels is promoted
where applicable.
1.
Services: Services are an abstraction and an encapsulation of the functionality
provided by an autonomous entity. Service architectures are composed of
functions provided by a system or a set of systems to achieve a shared goal. The
service concepts of the PIM4SOA metamodel have been heavily based on the
Web Services Architecture as proposed by W3C (W3C 2004).
2.
Information: Information is related to the messages or structures exchanged,
processed and stored by software systems or software components. The
information concepts of the PIM4SOA metamodel have been based on the
structural constructs for class modelling in UML 2.0 (OMG 2003).
3.
Processes: Processes describe sequencing of work in terms of actions, control
flows, information flows, interactions, protocols, etc. The process concepts of
Model-Driven Design of Interoperable Agents
5
the PIM4SOA metamodel have been founded on ongoing standardization work
for the Business Process Definition Metamodel (BPDM) (IBM et al. 2004).
4.
Non-functional aspects: Extra-functional qualities that can be applied to
services, information and processes. Concepts for describing non-functional
aspects of SOAs have been based on the UML Profile for Modeling Quality of
Service and Fault Tolerance Characteristics and Mechanisms (OMG 2004).
In addition to the standards mentioned above, the work on defining the
PIM4SOA metamodel has also been influenced by the UML Profile for Enterprise
Distributed Object Computing (OMG 2002).
In this paper we will focus on the service concepts of the PIM4SOA metamodel.
Figure 2 shows a partial subset of the PIM4SOA metamodel describing how services
are modelled as collaborations. They specify a pattern of interaction between
participating roles. It specifies the involved roles and their responsibilities within the
collaboration. A collaboration use specifies the application of a collaboration in a
specific context and includes the binding of roles to entities in that context.
Collaborations are composable and a composite collaboration specifies the use of
collaborations. The responsibilities of roles in a composite collaboration are defined
through the bindings to roles of its used collaborations. Binary collaborations have
two roles — a requester and a provider. The requester provides the input parameters
and the provider the output parameters.
Figure 2. Service concepts of the PIM4SOA metamodel
In the PIM4SOA metamodel a service is viewed as a collaboration of a set of
roles (ATHENA A6 2006). Therefore, when referring to a service in the following it
should be understood as a service collaboration. Non-composite binary
6
Model-Driven Design of Interoperable Agents. Volume X – No. X/2006
collaborations are the basic building blocks for composite collaborations. Composite
services are specified by composite service collaborations. Thus composition of
service collaborations is used to specify more sophisticated service definitions. Note
that a service is a service definition, not the realisation or an actual instantiation.
Roles represent how a partner participates in the collaboration by providing
services and parameters and using services provided by other partners in its service
collaboration. Asymmetry may be introduced in service collaborations through
defining the role types of the requester and provider.
We constrain that only roles in service collaborations may provide parameters. It
needs further evaluation of lifting this restriction.
For comparison BPEL (Andrews et al. 2003) has introduced the concept of a
partner link type (PLT) between two roles which are typed through WSDL port
types (W3C 2001). PLTs introduce the symmetry on top of the basic asymmetrical
concept. It was also partially, because it allowed “degenerated” PLTs with a single
role. It does not support the nested composition of PLTs. However, when used in
partner links, a process may define a set of partner links grouped into a partner.
Service collaborations are elementary symmetrical and composable and
asymmetry is introduced optionally. Composite services and composite
collaborations are defined using the exactly same mechanism – composition of
collaborations.
Collaboration can have a behaviour that specifies the rules for how the roles
interact. We refer to this as the collaboration protocol. The collaboration protocol is
specified from a global view point. Constraints on the expected behaviour of a role
can be deduced. Obviously the collaboration protocol of the service collaboration is
a service protocol.
3. Metamodel for BDI Agents
As already suggested in Figure 1 there are several alternatives when it comes to
transforming PIM4SOA models into models that can actually be executed. Agent
technologies are an interesting option to choose because they allow a flexible and
adaptive execution of such models. PIM4SOA does not directly ask for this
flexibility. However, there are well-known examples like for example the contract
net protocol (Davis et al. 1983) that can be adopted for the service supplier selection
when the number of suppliers is not know at design time. This kind of service
selection can be nicely described with agent technologies while a straightforward
model for the PIM4SOA is not available. To integrate agent technologies with
PIM4SOA is therefore a worthwhile enterprise.
For the design of agents with rational and flexible problem solving behaviour,
the BDI agent architecture has been proven successful during the last decade (Rao et
Model-Driven Design of Interoperable Agents
7
al. 1991, Rao et al. 1995). Three mental attitudes (beliefs, desires, and intentions)
allow an agent to act in and to reason about its environment in an effective manner.
It is therefore of no surprise that a vast number of tools and methodologies have
been developed to foster the software-based development of BDI agents and multiagent systems. Rather than inventing our own agent metamodel, we took a bottomup approach in which we extracted the metamodel (AgentMM) from one of the most
sophisticated tools for the design of BDI agents (i.e. JACK™ Intelligent Agents
(AOS)). Figure 3 presents the most interesting part of this metamodel for the
discussion that we want to do in this paper.
Figure 3. Partial metamodel for BDI agents
We start with a neural description of the concepts that are included in AgentMM
and discuss the relation between PIM4SOA and AgentMM in the next section.
The most important concept in AgentMM is the concept of a team. Teams are
either atomic, in which case we can refer to them as agents, or consist of a set of
roles that all together form the team. It is important to note that even in the most
simple case where all roles of a team are meant to be filled by an individual atomic
agent it is not the case that all members of the teams need to be involved in all the
tasks the team is able to work on. Rather for each individual task a set of individuals
(we do not want to call them agents because they can be teams, too) from the team
members are selected to actually work on the task. Tasks a team is able to work on,
8
Model-Driven Design of Interoperable Agents. Volume X – No. X/2006
are defined by the roles the team is able to perform. The roles a team requires to be
filled by individuals are role containers where the team definition specifies how
many individuals are needed at minimum as a role filler and how many individuals
are allowed at maximum where both numbers can be set to 0 or any (which of
course means any finite number).
Role definitions are the second important concept for the definition of teams. A
role defines which messages (in Jack these messages are rather events that teams
send to each other, however, we do not want to go into the details of the discussion
of these concepts) the role fillers are able to react to and which messages they are
likely to send.
Although it is possible to design models where types for teams and roles are so
specific that only individual instances of these types are possible at run-time.
However, the real idea behind these concepts is of course to keep the types as
general as possible and to leave the decision of which concrete instances are actually
created or selected for the execution of a specific task to the runtime execution. It is
also important to note that it is not necessarily the case that the complete team is
formed to work on an incoming top-level request (which is most probably the
service the team offers to the outside environment) at the time the request arrives at
the team. Rather creation of sub-teams can be left open, taking into account the
success or failure of the execution of team plans by individual sub-teams.
How a team actually goes about to react on an incoming request is specified by a
set of team plans. Each team plan has an explicitly defined objective (incoming
message or event internal to the team) that the team plan is responsible to deal with.
When the so-called triggering event is raised and all additional criteria are valid, a
specific team plan is executed by creating an instance of this team plan. As a
consequence a concrete team to actually execute the team plan is established. In this
case both is possible, that the team to execute the team plan is already known or that
it has to be newly established. In the latter case, the establish() method can be used
to describe which members from the role containers of the team are selected to
perform the team plan. This means that for any specific task to work on a new subteam can be dynamically formed from the set of team members that actually work
on the task. The separation of the team members into different role containers that
correspond to different role types helps with respect to selecting adequate agents.
Although message events can be posted to teams, it is in the current version of
AgentMM rather difficult to describe the interaction among teams. This is due to the
fact that there seems to be no straightforward way to specify the reaction of the
sender to replies from individual team members of a sub-team when a message
event is sent to a role container that holds more than one member. It is probably
possible to map the replies to the synthesis of belief sets but, on the one hand, this
means that in the protocol description the answers will not be visible as messages
but rather as changes to belief sets. On the other hand, it seems to be not possible to
react to these belief set changes in the team plan that actually sends the message (at
Model-Driven Design of Interoperable Agents
9
least not in a straightforward manner). This disadvantage is not a general problem of
agent technologies but rather is a result from the decision to derive AgentMM from
the Jack BDI development environment. However, the best way to describe
interactions from a centralised point of view for the whole interaction is far from
obvious.
4. Comparison of the Metamodels for PIM4SOA and BDI Agents
Although the concepts PIM4SOA and AgentMM differ quite significantly a
mapping of PIM4SOA models to AgentMM model seems to be feasible because
AgentMM is more expressive. Therefore, a transformation of PIM4SAO models to
AgentMM is our main aim.
The first element we inspect is the ServiceProvider. At first glance an agent
seems to be the best match, but since a ServiceProvider references roles, it is
recommended to assign it to a team. The name of the ServiceProvider coincides with
the name of the team and its roles are the roles the team performs.
While a ServiceProvider is supposed to represent an atomic team, i.e. a team that
consists of an individual agent, a Collaboration is mapped onto a team that may
consist of any number of agents. However, because collaborations do not specify
any cardinalities for roles, we assume that a collaboration asks for exactly one filler
for each of the required roles. Therefore we suggest to map collaborations to a team
structure where the required roles have a min-max requirement of exactly one role
filler. Additionally a generic team plan is created that represents the collaborations
behaviour as a body and requires all roles that are specified in the collaboration.
Each collaboration use then is an additional team plan where the generic team plan
of the collaboration is used and extended by a renaming of roles (in AgentMM this
is done by a “uses role1 as role2” specification).
The most severe difference between PIM4SOA and AgentMM is the manner in
which the interaction protocol among the members of a Collaboration (team) is
described. In PIM4SOA this interaction protocol is specified from a centralised
point of view for both parties involved. Such a description is in AgentMM in its
current form not directly available. When one wants to transform the PIM4SOA
interaction protocol into AgentMM models it is necessary to extract from the
centralized description of the PIM4SOA model the projections of the behaviour for
the individual parties of the interaction. Because it is clear who initiates the
interaction it is clear that for the initiator it is possible to provide a team plan that
reflects its behaviour of the initiator and to provide a set of plans that describe the
reaction to the incoming messages on the server’s side. It needs to be investigated in
how far the protocol descriptions in the PIM4SOA models can be automatically
transformed into the models that need to be executed by the individual parties in
AgentMM.
10
Model-Driven Design of Interoperable Agents. Volume X – No. X/2006
5. Discussion
There are quite a number of similarities between PIM4SOA and AgentMM. The
concepts ServiceProvider, Collaboration, and CollaborationUse on the one hand
and team, role, and team plan on the other hand correspond quite nicely as we could
see in the last section. The difference in actually describing interactions on the one
hand is a challenge when one wants to transform the models from PIM4SOA to
AgentMM. On the other hand, it also provides chances to actually improve the
AgentMM with additional models that are possibly more compact and easier to read.
The idea of allowing more than one role filler for specific roles in a team in
AgentMM is more general than the idea of roles in collaborations of PIM4SOA
models. However, it also complicates the description of the interaction among these
roles. Even if we restrict ourselves to the case of two roles interacting with each
other we need to have quite powerful concepts available to express how messages
should be exchanged among these groups. Let us assume that we have two role
containers of type role1 and role2, respectively, and that each of these containers
has more than one role fillers. If we allowed to write “role1 → role2” meaning that a
message is sent from role1 to role2, what should this actually mean? That every
member of the role container role1 would send this message to every member of
role container role2? It would be possible to constrain the selection of senders and
receivers but it is open how an elegant way of describing these constraints could
look like. Additionally, one should realise that sending messages is one thing but it
is also necessary that it should be possible to describe the handling of replies in an
intuitive manner.
However, even if we restrict ourselves to the situation where messages have to
be exchanged between individuals (teams or agents), AgentMM already provides
advantages over PIM4SOA because it allows the intuitive description of more
complex protocols. The contract net protocol (where a manager selects the best offer
from a set of bidders (Davis et al. 1983)) is a good example for such a situation. In
the contract net protocol the number of bidders that will be approached is not known
at the design time of the protocol. Still the contract net protocol has a clear initiator
for each of the interactions (the manager) and all other parties involved (bidders)
need only to reply to incoming messages. The restriction that applies to the models
that can be easily described in AgentMM is as follows: The protocol needs an
individual initiator that can interact with any number of roles where for each of these
roles any number of role fillers can be dynamically assigned at run-time where the
interaction between the initiator and the participating roles are pure request-response
patterns. We do not say that it is impossible to design more complicated protocols in
AgentMM, However, in its current version there is at least no straightforward design
pattern available to describe such protocols.
PIM4SOA, however, provides in the end at least a concrete proposal for how to
describe the message interchange between two interacting parties from a centralised
Model-Driven Design of Interoperable Agents
11
point of view and therefore could be included in AgentMM to at least deal with
describing the interaction between two parties in specific cases.
6. Conclusions and Future Work
The paper presented a metamodel for SOAs (PIM4SOA) and a metamodel for a
specific class of agents (AgentMM). The similarities between the two metamodels
are high enough to allow a mapping of PIM4SOA to AgentMM to a large degree.
Therefore the idea of designing interoperable agents by using PIM4SOA models and
transforming them into AgentMM models seems to be feasible. The extension that
AgentMM provides on the one hand gives the chance to introduce greater flexibility
and adaptiveness into SOAs. For concepts that prove to be particularly useful in this
context there is even the chance that they might be included into the PIM4SOA in
the long run. The major part of future work that needs to be done is in the
comparison of the process models of the two metamodels.
The work published in this paper is partly funded by the European Commission
through the ATHENA IP (Advanced Technologies for interoperability of
Heterogeneous Enterprise Networks and their Applications Integrated Project) (IST507849). The work does not represent the view of the European Commission or the
ATHENA consortium, and the authors are solely responsible for the paper’s content.
7. References
AOS, "JACK Intelligent Agents", The Agent Oriented Software Group (AOS).
http://www.agent-software.com/shared/home/
T. Andrews, F. Curbera, H. Dholakia, Y. Goland, J. Klein, F. Leymann, K. Liu, D. Roller, D.
Smith, S. Thatte, I. Trickovic, and S. Weerawarana, "Business Process Execution
Language
for
Web
Services
Version
1.1",
May
2003.
ftp://www6.software.ibm.com/software/developer/library/ws-bpel.pdf
Gorka Benguria, Xabier Larrucea, Brian Elvesæter, Tor Neple, Anthony Beardsmore,
Michael Friess, “A Platform Independent Model for Service Oriented Architectures”,
paper to be presented at the I-ESA’2006 conference, Bordeaux, France, March 2006.
R. Davis and R. G. Smith, “Negotiation as a metaphor for distributed problem solving”,
Artificial Intelligence, vol. 20, 1983, pp. 63 – 109.
D. D'Souza, "Model-Driven Architecture and Integration - Opportunities and Challenges,
Version 1.1", Kineticum, 2001. http://www.catalysis.org/publications/papers/2001-mdareqs-desmond-6.pdf
IBM, Adaptive, Borland, Data Access Technologies, EDS, and 88 Solutions, "Business
Process Definition Metamodel - Revised Submission to BEI RFP bei/2003-01-06", Object
12
Model-Driven Design of Interoperable Agents. Volume X – No. X/2006
Management
Group
(OMG),
Document
http://www.omg.org/docs/bei/04-08-03.pdf
bei/04-08-03,
August
2004.
OMG, "UML Profile for Enterprise Distributed Object Computing Specification", Object
Management
Group
(OMG),
Document
ptc/02-02-05,
2002.
http://www.omg.org/technology/documents/formal/edoc.htm
OMG, "MDA Guide Version 1.0.1", Object Management Group (OMG), Document omg/0306-01, June 2003. http://www.omg.org/docs/omg/03-06-01.pdf
OMG, "UML 2.0 Superstructure Specification", Object Management Group (OMG),
Document ptc/03-08-02, August 2003. http://www.omg.org/docs/ptc/03-08-02.pdf
OMG, "UML Profile for Modeling Quality of Service and Fault Tolerance Characteristics and
Mechanisms", Object Management Group (OMG), Document ptc/04-09-01, September
2004. http://www.omg.org/docs/ptc/04-09-01.pdf
OMG, "Meta Object Facility (MOF) 2.0 Core Specification", Object Management Group
(OMG), Document ptc/04-10-15, October 2004. http://www.omg.org/docs/ptc/04-1015.pdf
OMG, "Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification", Object
Management
Group
(OMG),
Document
ptc/05-11-01,
November
2005.
http://www.omg.org/docs/ptc/05-11-01.pdf
A. S. Rao and M. P. Georgeff, “Modeling Agents within a BDI-Architecture”, R. Fikes and E.
Sandewall (Eds.), Proc. of the 2rd International Conference on Principles of Knowledge
Representation and Reasoning (KR'91), Morgan Kaufmann, Cambridge, Mass. April,
1991, pp. 473-484.
A. S. Rao and M. P. Georgeff, “BDI-Agents: from theory to practice”, Victor Lesser (Ed.),
Proceedings of the First Intl. Conference on Multiagent Systems, San Francisco, AAAI
Press/The MIT Press, 1995.
W3C, "Web Services Description Language (WSDL) 1.1", World Wide Web Consortium
(W3C), W3C Note, 15 March 2001. http://www.w3.org/TR/2001/NOTE-wsdl-20010315
W3C, "Web Services Architecture", World Wide Web Consortium (W3C), W3C Working
Group Note, 11 February 2004. http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/