-This paper presents and discusses a first complete example of the use of JADEL. JADEL is a novel agent-oriented domain-specific programming language built on top of JADE, the well-known agent platform which provides solid agent technology and several tools for the creation of agents and multi-agent systems. The purpose of JADEL is to make the development of JADE agents and multi-agent systems easier and clearer by means of specific abstractions and a lighter syntax. In order to understand, and properly assess, the actual advantages of using JADEL, a well-known JADE demo that uses JADEspecific features like ontologies and interaction protocols has been rewritten in JADEL. This paper first briefly presents the main features of JADEL, then it discusses the rewritten demo and compares it with original JADE code.
JADEL (JADE Language) [
JADE allows users to make appropriate design choices for their specific application domains, without forcing them to rely on a specific agent model. Such flexibility and adaptability makes it a very powerful instrument that can be applied to several domains. The disadvantage of such an approach is that the agent-oriented features have been used in many different ways, resulting in a loss of transparency of the agent model.
Finally, the AOP (Agent-Oriented Programming) paradigm
is inherently different from the OOP (Object-Oriented
Programming) one. As a matter of fact, agents are
characterized by mental states and they exchange specific types of
messages, responding to them in a truthful and consistent
way. To this extent, agents are viewed as specialization of
objects [
deal with the chosen domain. These languages have a lighter syntax and help avoiding repetitive tasks, workaround and unclear technicalities.
In summary, the main problems in developing agent-based applications and multi-agent systems in JADE today can be listed as follows. First, the complexity of the framework requires not only expertise in management of distributed multiagent systems but also a deep understanding of JADE mechanisms. Second, the lack of a fixed agent model sometimes causes unclear or incorrect utilizations of the available agent agents, while expressions are used, for instance, to create technologies. Finally, some procedures and patterns become agent behaviours. In Section II-B such features are described repetitive or verbose, hence not clear in terms of AOP, due to in detail. the gap between the AOP and OOP paradigms. The above listed criteria must not be seen as a limitation. On
The solution proposed to address these problems is JADEL, the contrary, they represent a tentative of making JADEL code
which was first presented in [
This feature makes also possible the embedding of JADE native code. As a consequence, the use of JADEL is quite straightforward for Java and JADE users. JADEL is still under development and an evaluation of its capabilities, usability and effectiveness is necessary. This paper presents a JADEL translation of the Meeting Scheduler demo, a well-known example of JADE that comes together with JADE distribution.
The structure of the paper is as follows. In Section II, JADEL main ideas and abstraction are presented, together with a brief explanation of its syntax. Then, Section III introduces the Meeting Scheduler example in JADEL and its comparison with the JADE implementation. Finally, Section IV concludes the paper with a discussion of the results and future developments and improvements.
II. THE JADEL PROGRAMMING LANGUAGE IN BRIEF
As previously explained, the scope of JADEL is to simplify the creation of JADE agents and multi-agent systems and to make the agent model clearly visible, avoiding technical and implementation details as much as possible. JADE APIs consist in a large amount of classes that have various purposes, such as the representation of core abstractions and the management of message passing among agents, from interaction protocols to agent communication languages. Hence, the choice of the primary features, among those provided by JADE classes, is fundamental in the development of a JADE DSL.
In particular, two criteria for the selection of JADEL features are considered, namely (i) the significance of such features in agent creation and life-cycle and (ii) the FIPA compliance and the help they give to manage message passing. According to the previously listed criteria, JADEL core abstractions are the agent, the behaviour and the communication ontology. These abstraction are explained in detail in Section II-A.
Features of such entities are designed as domain-specific constructs and expressions, whose purpose is to shorten the most repetitive tasks and to focus on the agent life-cycle and behaviour action. Constructs are meant to handle events, e.g., the reception of a messages and creation or destruction of
In terms of syntax, all JADEL abstractions are declared in a similar way, namely with a keyword that identifies the abstraction, followed by the name of the entity and its relations with other declared entities. After the declaration, a block of code contains the description of its main features, by means of specific constructs.
The first entity that we discuss is the communication ontology. In detail, communication ontologies contain the definitions of propositions, composite concepts and predicates. From a theoretical point of view, propositions are first-order logic well-formed formulas. In JADEL they are declared simply by means of the keyword proposition followed by a name.
Basic (or atomic) concepts are simple terms that can be used in JADEL, but they do not have to be declared, because they are provided directly by JADEL. Composite concepts are defined by means of other basic or composite concepts. According to JADEL syntax, composite concepts can be declared by using the keyword concept followed by the name of the concept and by a list of parameters. Such parameters identify the other concepts that compose the one that is being declared.
Predicates have a similar syntax and their parameters can be basic or composite concepts. Predicates do not state a fact nor describe an entity, but they make relations among concepts, as in the semantics of logic predicates.
The second entity is the behaviour. In JADEL, behaviours are used to define actions that can be performed by agents and they can be cyclic or oneshot. The difference between cyclic and oneshot behaviours is that cyclic ones remain in the agent behaviours list for the entire life of an agent, while oneshot behaviours are removed after a single execution. Both of them can be associated with a specific agent class. A special consideration is given to those behaviours that are roles of an interaction protocol. Roles are behaviours defined by means of a FIPA protocol name and the role of the agent in such protocol. In the body of a role, each step of the protocol is handled individually as a particular event caused by the reception of different types of messages.
Finally, agents are the most important JADEL entities. In their declarations and setup, they put together all the ontologies and behaviours that will be used in their life cycles, thus making explicit relations among the various entities. Agents are multitask single-threaded entities that manage their actions by means of an internal scheduler. An agent life cycle is composed of: (i) a start-up phase, during which the agent initializes, (ii) a loop, where actions are performed, and (iii) a final phase of take-down, in which the agent performs cleanup tasks. In JADEL, creation and destruction of an agent are events, so they are managed with specific constructs, whose syntax is coherent with the one of the behaviour events.
Particular expressions are used to manage events, message passing and domain-specific tasks, such as the behaviours registration in the agent list.
Events are managed by means of the keyword on, followed by the type of event. Events can be the creation and the destruction of an agent, the change of state of a participant in an interaction protocol, and the reception of a message. Notably, the JADEL construct on − when − do is used in a behaviour body to define an action. In detail, an action can be simple, i.e., it does not need an event to be triggered. In such a case, only the keyword do is used, followed by a block of code that describes the action. Otherwise, an action can be triggered by an event, and the keyword on specifies such event. The keyword when is optional and it can be used to set conditions on the event nature.
Communication among agents consists in message passing, which can be managed with ontologies and/or with interaction protocols. Interaction protocols provide a scenario with, at least, two different roles, initiator and participant, and establish the types of messages exchanged among agents that are in such roles. JADEL encourages the usage of such technologies by providing expressions that allow messages to be viewed as special data structures and by means of specific constructs that permit creating and sending messages, and extracting message contents. These expressions and constructs are exactly the same for each type of message, regardless of their content, which can be a string, a sequence of bytes, a concept, a proposition or a predicate.
The simple example below shows syntax and usage of some domain-specific expressions. agent Ping { on c r e a t e { var a i d L i s t = # [ newAID ( ‘ pong ’ ) ] a c t i v a t e behaviour SendPing ( a i d L i s t ) }
The Meeting Scheduler demo launches two (or more) agents, with their own GUI that consists in a calendar where the user can fix and view his/her appointments, invite known users to an appointment, and receive other users invitations. The agent is responsible for the management of the calendar, so the user does not have to bother about the overlap of two appointments. As a matter of fact, the agent schedules the appointments correctly by messaging with other agents.
The JADE source code of the demo consists in (i) a Meeting Scheduler agent, (ii) a set of classes that manage the GUI, (iii) three behaviours, and (iv) an ontology that defines two composite concepts. Regarding the behaviours, two of them are implementations of the initiator and responder roles of the FIPA Contract Net interaction protocol and the third deals with the cancellation of an appointment.
The first entity implemented in JADEL is the communication ontology, with the concept Person and Appointment, whose sub-concepts are declared as parameters. The keyword many identifies a list. Declaration of MSOntology is selfcontained and it does not need any other classes to define its two concepts, as in JADE. package demo . m e e t i n g s c h e d u l e r . o n t o l o g i e s o n t o l o g y MSOntology { concept P e r s o n ( s t r i n g name , a i d AID , a i d DFName ) concept Appointment ( a i d i n v i t e r , s t r i n g d e s c r i p t i o n , d a t e s t a r t i n g O n , d a t e endingWith , d a t e FixedDate , many P e r s o n i n v i t e d P e r s o n s , many d a t e p o s s i b l e D a t e s ) e x t e n d s C l o n e a b l e }
Then, the agent is declared as a JadelGuiAgent, an extension of the JADE class GuiAgent that provides some built-in functionalities, e.g., log(String) function, used to manage the logging for the agent. Classes that build the GUI are coded in Java, exactly as in the original demo. It is possible to refer to those classes into the agent body, thanks to the close integration that Xtext and Xtend provide with the underlying JVM.
First, some variables are declared in the MeetingSchedulerAgent entity. These will be translated into fields of the agent class. According to Xtend syntax, the keyword val denotes a private final field, while var stands for a mutable private field. agent M e e t i n g S c h e d u l e r A g e n t u s e s o n t o l o g y MSOntology e x t e n d s J a d e l G u i A g e n t { var S t r i n g userName var Vector<AID> knownDF = new V e c t o r ( ) var HashMap<S t r i n g , Person> knownPersons = newHashMap ( ) var HashMap<S t r i n g , Appointment> a p p o i n t m e n t s =
newHashMap ( ) var mainFrame mf v a l i n t STARTTASKS = 2 v a l i n t FIXAPPOINTMENT = 3 v a l i n t REGISTERWITHDF = 4 v a l i n t CANCELAPPOINTMENT = 5 v a l i n t SEARCHWITHDF = 6 v a l S t r i n g NAME = ‘ A p p o i n t m e n t S c h e d u l i n g ’ v a l S t r i n g TYPE = ‘ p e r s o n a l −a g e n t ’ v a l S t r i n g PROTOCOL = ‘ f i p a −r e q u e s t f i p a −C o n t r a c t −Net ’ Then, a setup method is used only to start the GUI, as follows. on c r e a t e { var p a s s w o r d D i a l o g = new P a s s w o r d D i a l o g ( t h i s ,
t h i s . localName ) p a s s w o r d D i a l o g . v i s i b l e = t r u e Finally, all needed methods of the agent are defined similarly to those in JADE implementation, with some difference regarding domain-specific expressions. In the following, two of such methods are shown.
v o i d s t a r t T a s k s ( S t r i n g name ) { userName = name mf = new mainFrame ( t h i s , userName +
‘− Appointment S c h e d u l e r ’ ) mf . v i s i b l e = t r u e t r y {
DFService . r e g i s t e r ( t h i s , g e t D F A g e n t D e s c r i p t i o n (NAME, TYPE , MSOntology : : NAME, userName , PROTOCOL) ) knownDF += d e f a u l t D F addKnownPerson ( new P e r s o n ( userName , AID , d e f a u l t D F ) ) } c a t c h ( FIPAException e ) { e . p r i n t S t a c k T r a c e ( ) mf . showErrorMessage ( e . getMessage ( ) ) l o g ( e . getMessage ( ) , Logger .WARNING) } take r o l e m y F i p a C o n t r a c t N e t R e s p o n d e r B e h a v i o u r ( t h i s ) a c t i v a t e behaviour C a n c e l A p p o i n t m e n t B e h a v i o u r ( t h i s ) v o i d c a n c e l A p p o i n t m e n t ( Date d ) { var Appointment a p p o i n t m e n t = getMyAppointment ( d ) i f ( a p p o i n t m e n t == n u l l ) { mf . showErrorMessage ( ‘ Nothing t o c a n c e l : no
a p p o i n t m e n t was f i x e d on ’ + d ) l o g ( ‘ Nothing t o c a n c e l : no a p p o i n t m e n t was f i x e d on ’ + d , Logger .WARNING) return } i f ( ! a p p o i n t m e n t . i n v i t e d P e r s o n s . empty ) { var A c t i o n a c t i o n = new A c t i o n ( ) a c t i o n . a c t o r = AID a c t i o n . a c t i o n = a p p o i n t m e n t var r e c e i v e r s L i s t = # [ ] f o r ( p : a p p o i n t m e n t . i n v i t e d P e r s o n s )
r e c e i v e r s L i s t . add ( p . AID ) send message { p e r f o r m a t i v e i s CANCEL o n t o l o g y i s MSOntology r e c e i v e r s are r e c e i v e r s L i s t c o n t e n t i s a c t i o n } } removeMyAppointment ( a p p o i n t m e n t )
The roles are completely listed below and all the details required to define roles are given. Their declarations indicate } } } the owner agent, protocol name and protocol role. As for the agent, a list of variables can be specified and the role creation is an event that can be handled as follows. r o l e m y F i p a C o n t r a c t N e t I n i t i a t o r B e h a v i o u r ( Appointment a p p o i n t m e n t , L i s t <AID> group ) f o r M e e t i n g S c h e d u l e r A g e n t as FIPA CONTRACT NET : I n i t i a t o r { var Appointment pendingApp var a c c e p t a b l e D a t e s = newArrayList<Date >() var a c c e p t e d D a t e s = newArrayList<Date >() on c r e a t e { var a c t i o n = new A c t i o n ( ) a c t i o n . s e t A c t o r ( t h e A g e n t . AID ) a c t i o n . s e t A c t i o n ( a p p o i n t m e n t ) c r e a t e message cfpMsg { p e r f o r m a t i v e i s CFP o n t o l o g y i s MSOntology r e c e i v e r s are group c o n t e n t i s a c t i o n } pendingApp = a p p o i n t m e n t p r i n t l n ( ‘ I n i t i a t o r msg : ’ + cfpMsg ) Roles are finite-state machine behaviours that change state when a new message with a certain performative is received. As explained in FIPA Contract Net specification, the initiator sends CFP messages to a group of agents and it has to handle their responses. In the following, negative responses are handled.
on REFUSE msg {
p r i n t l n ( ‘ I n i t i a t o r r e c e i v e d Refuse : ’ + msg . t o S t r i n g ) on NOT UNDERSTOOD msg { p r i n t l n ( ‘ I n i t i a t o r h a n d l e NotUnderstood : ’ + msg .
t o S t r i n g ) on FAILURE msg {
p r i n t l n ( ‘ I n i t i a t o r r e c e i v e d F a i l u r e : ’ + msg . t o S t r i n g ) In case of acceptance of the CFP by the responder, initiator handles the propose message, as follows.
on PROPOSE msg { var C a l e n d a r c = C a l e n d a r . i n s t a n c e f o r ( d : pendingApp . p o s s i b l e D a t e s ) { c . t i m e = d a c c e p t a b l e D a t e s . add ( new I n t e g e r ( c . g e t ( c . DATE) ) ) e x t r a c t p r o p o s a l as A c t i o n from msg var a p p o i n t m e n t = p r o p o s a l . a c t i o n as Appointment f o r ( d : a p p o i n t m e n t . p o s s i b l e D a t e s ) { c . t i m e = d var day = new I n t e g e r ( c . g e t ( c . DATE) ) i f ( a c c e p t a b l e D a t e s . c o n t a i n s ( day ) )
a c c e p t e d D a t e s . add ( day ) a c c e p t a b l e D a t e s = a c c e p t e d D a t e s . c l o n e i f ( ! a c c e p t a b l e D a t e s . empty ) { var d = new Date ( ) var i n t dateNumber =
( ( I n t e g e r ) a c c e p t a b l e D a t e s . g e t ( 0 ) ) . i n t V a l u e ( ) c . s e t ( c . DATE , dateNumber ) pendingApp . s e t F i x e d D a t e ( c . t i m e ) var a c t i o n = new A c t i o n ( ) a c t i o n . s e t A c t o r ( t h e A g e n t . AID ( ) ) a c t i o n . s e t A c t i o n ( pendingApp ) c r e a t e message replyMsg { o n t o l o g y i s MSOntology pe rf orm at ive i s ACCEPT PROPOSAL r e c e i v e r s are #[ msg . s e n d e r ] c o n t e n t i s a c t i o n } } e l s e { c r e a t e message replyMsg { pe rf orm at ive i s REJECT PROPOSAL r e c e i v e r s are #[ msg . s e n d e r ] c o n t e n t i s ‘No d a t e a v a i l a b l e ’ Finally, if the proposal is accepted and the responder succeeds in fixing the appointment, a final message that informs the initiator is sent. Here the handling of the reception of such message is shown.
on INFORM msg { var P e r s o n p = t h e A g e n t . getPersonByAgentName (
msg . s e n d e r ) pendingApp . i n v i t e d P e r s o n s . c l e a r i f ( p == n u l l )
p = new P e r s o n ( msg . s e n d e r . name , n u l l , n u l l ) pendingApp . g e t I n v i t e d P e r s o n s ( ) . add ( p ) t h e A g e n t . addMyAppointment ( pendingApp ) }
Below, the source code of the responder behaviour is listed. In case the responder receives a CFP, it will decide to accept it or not. r o l e m y F i p a C o n t r a c t N e t R e s p o n d e r B e h a v i o u r f o r
M e e t i n g S c h e d u l e r A g e n t as FIPA CONTRACT NET : Responder { on CFP msg { e x t r a c t c f p as A c t i o n from msg var a p p o i n t m e n t = c f p . a c t i o n as Appointment var p r o p o s a l = a p p o i n t m e n t p r o p o s a l . p o s s i b l e D a t e s . c l e a r ( ) f o r ( d : p r o p o s a l . p o s s i b l e D a t e s ) i f ( t h e A g e n t . i s F r e e ( ) )
p r o p o s a l . p o s s i b l e D a t e s . add ( d ) i f ( ! p r o p o s a l . p o s s i b l e D a t e s . empty ) { var a = new A c t i o n ( ) a . a c t o r = t h e A g e n t . AID a . a c t i o n = p r o p o s a l c r e a t e message r e p l y { pe rf orm at ive i s PROPOSE o n t o l o g y i s MSOntology r e c e i v e r s are #[ msg . s e n d e r ] c o n t e n t i s a } } e l s e { c r e a t e message r e p l y { pe rf orm at ive i s REFUSE r e c e i v e r s are #[ msg . s e n d e r ] c o n t e n t i s ‘No a v a i l a b l e d a t e ’ } }
} } }
} The initiator can decide to accept or reject a proposal and, in both cases, it sends a notification message to the responder. on ACCEPT PROPOSAL msg { e x t r a c t a as A c t i o n from msg var a p p o i n t m e n t = a . a c t i o n as Appointment i f ( t h e A g e n t . i s F r e e ( a p p o i n t m e n t . f i x e d D a t e ) ) { t h e A g e n t . addMyAppointment ( a p p o i n t m e n t ) c r e a t e message r e p l y {
pe rf orm at ive i s INFORM } } e l s e { c r e a t e message r e p l y { pe rf orm at ive i s FAILURE } } } on REJECT PROPOSAL msg {
p r i n t l n ( ‘ Responder r e c e i v e d Refuse : ’ + msg . t o S t r i n g ( ) ) Finally, the CancelAppointmentBehaviour is shown in the following. c y c l i c behaviour C a n c e l A p p o i n t m e n t B e h a v i o u r f o r
M e e t i n g S c h e d u l e r A g e n t { on message msg when {
pe rf orm ati ve i s CANCEL } do { e x t r a c t con as Appointment i f ( con . i n v i t e r == t h e A g e n t . AID )
t h e A g e n t . c a n c e l A p p o i n t m e n t ( con . f i x e d D a t e ) e l s e
t h e A g e n t . removeMyAppointment ( con )
As shown in the previous section, JADEL implementation of the Meeting Scheduler demo is composed by the same entities of the JADE version, but it is characterized by specific syntax for agent-oriented features. Moreover, the operations and methods have the same semantics of those in JADE, but some parts are much shorter than the original ones. Beside the original demo and the JADEL implementation shown above, we obtained a third Java implementation directly by JADEL code generator. The generated code is more redundant than the original JADE demo source code, but it does not introduce significant overhead and the number of messages exchanged by the agents are the same. Hence, there is not a notable performance loss.
The scope of JADEL is mainly to simplify the use of JADE and to make clear and transparent the agent model. In order to evaluate the actual advantages in use of JADEL, we compare the original JADE implementation with our JADEL translation, by using two measures based on Lines Of Code (LOC). First, we consider the total number of non-comment and non-blank LOC of the agent, of the ontology, and of the behaviours. Then, we emphasize the fraction of domain-specific features and expressions over the total number of lines. In JADEL, such domain-specific features are those presented in Section II: entity declaration, event handler, message related expressions, and behaviours/role activation. For example, in the previously shown listing of CancelAppointmentBehaviour, there are 12 non-blank LOC and 6 lines of domain-specific features. In particular, those lines are the first, namely, the entity declaration, the event handling with the on − when − do construct, and the extraction of the received message. Thus, the fraction of domain-specific features is the 50% of the LOC. In JADE, we consider as domain-specific all the actual call to the APIs, including the lines that identify the base class, i.e., the entity.
From the Table I, we can see that JADEL implementation is shorter than JADE one. This is particularly evident when considering the ontology, that consists in only eight non-blank LOC, in JADEL. Instead, 175 lines are required by the JADE ontology, which includes also the declaration of two more classes that define concepts. Also JADEL behaviours seem to be simpler than JADE ones, with a little advantage in focusing
MSAgent 264 20 305 23
MSOntology 8 75 175 11 on the domain-specific tasks. The number of LOC of JADEL agent, instead, is only slightly smaller than that of JADE agent and domain-specific features are approximately the same. This is due to the point-to-point translation that has been made, in order to reproduce precisely the original demo. As a matter of fact, we have chosen not to change the demo specification, in order to make a fair comparison between the two versions. We argue that a revisited and original JADEL implementation of the Meeting Scheduler demo may be more focused on behaviours rather than on agent methods, thus improving the readability of the agent code and reducing its size.
However, LOC and domain-specific fraction of those lines are only indicators of size and density of JADEL code, but they cannot fully describe qualitative factors, such as the readability of the code, nor how much the code is reusable and maintainable.
This paper presents a complete example of JADEL usage, related to the well-known Meeting Scheduler demo of JADE. Scope and motivations of JADEL development are briefly explained, then main abstractions, domain-specific features and expressions are introduced. The example is presented by showing JADEL source code of the Meeting Scheduler ontology, notable parts of the agent, and all the behaviours. A comparison between JADE and JADEL implementations of such a demo is made by counting non-comment and nonblank LOC and by measuring the rate of domain-specific agent-oriented features over the total number of LOC. These indicators are useful in a first approximation to enlighten some JADEL advantages, namely, its lighter syntax and the conciseness in the definition of ontologies. Nevertheless, other aspects are difficult to be precisely evaluated, due to their qualitative nature. For instance, some constructs and expressions are meant to reduce the complexity of the framework and to improve readability rather than to reduce the amount of code written. As illustrative examples, the on − when − do and the extract − as are specifically designed to clarify message reception, while the corresponding JADE patterns are repetitive and full of implementation details.
In summary, JADEL is shown to be sufficiently expressive to fully reproduce the Meeting Scheduler demo and the best results with respect to JADE are obtained in the ontology implementation. Also roles and behaviours are shorter and clearer, due to the frequent use of domain-specific constructs, especially for message passing. Moreover, the entire code of the GUI was reused, thanks to the tight integration of JADEL entities into Java type-system.
As previously said, numbers of LOCs and the percentage of DS-LOCs are not sufficient to measure the actual advantage in the use of JADEL. For this reason, future works will address the problems of language evaluation and testing. Such an evaluation could be done by scheduling the development of an application by a team of several users. Users could have different experiences in the use of JADE, from beginners to experts. Moreover, making an application that deals with a real-world problem is a good strategy for testing.
JADEL was not yet released, because it is still under development and its quality, in terms of readability and reusability, still have to be assessed. Anyway, the compiler, related documentation and examples are freely available open source upon request to authors.