GVJade

Introduction

This Java application provides a direct JADE platform integration, which allows GreenVulcano to transparently interact with an inner set of JADE agents, using a direct 1-1 message transposition (internal ACL message to external XML, and viceversa). The JADE technology could introduce a lighter and smarter way to interconnect between multiple legacy services and/or different GV instances.

Description

ATM, GVJADE allows to run different flow scenarios, involving internal (JADEd, using ACL messages) and external (GV's, using JMS queues) contexts. These scenarios are a direct proof of true bridging between a JADE platform and GV context:

Scenario 1 : Messaging communication started from an external service/application (simulation of an external request to the inner agent):

• Through a simple JMS queue an external context may send an XML message, containing usual ACL message components such as: sender, receivers, action and content. (See section Example of messaging through JADE for a viable example)
• A bridging agent will receive the message and re-routes it to the infiltrated agent in ACL format
• Once the message is opened and used by the agent it prepares a proper response (following its internal logic) which will be sent back again to the bridging agent
• Bridging agent translates (this time the way around) the message in the exit format (XML) to the exit queue
• External context can now read response to its original message

Scenario 2 : Messaging communication started from inside the JADE platform agent (simulation of an inner update to deliver to the external context):

• An internal business agent, with a system update ready to be posted to the external application, sends it to the bridging agent
• The agent enroutes it to a proper queue, translated in XML code
• External application, waiting for the update, finds and uses it, also preparing a proper response in XML and sending it to another queue
• Bridging agent pops the message from the queue and sends it back to originating business agent, in ACL format

Scenario 3 : GV messaging service running on a ditributed GV cluster

• With an XML registration message, a GV service can register through the proxy agent, which is meant to centralize communications
• Once the service registration appliance is accepted, the GV "route" is stored and the service can be reached from others GV instances/services simply contacting the proxy agent

Usual default service actions are also available, such as: Start, Update configuration, Shutdown are triggerable from the GV console.

GVJADE service configuration

First, extract "GVJADEAdapter-Configuration.xml" file (provided into the package zip file) into the \GreenV\xmlconfig\ path. The XML file states JADE platform configuration as follows:

    <GCJADEAdapterConfiguration>

<Engine main="true" local-port="1500" gui="false" dump-options="true" no-display="true" platform-id="Main_GV_Container" nomtp="false"></Engine> <Agents> <Agent name="PingAgent" class="examples.PingAgent.PingAgent"/> </Agents>

    </GCJADEAdapterConfiguration>

Attributes optional to be changed are

• "local-port", which needs to be different from any used by GV, since its a hosting port)
• "gui", which allows to run other agents, such as Sniffer, useful to monitor communication between platforms and agents
• "Agent name", in order to add any other eventual agent class

Other attributes are not to be edited.

To add GVJADE service to GV enumeration edit and add the following:

   <generic-initializer class="main.java.test.jmx.RegisterGVJADEAdapter" target="$Template:Jboss.server.name" type="initializer"/>                     

to \GreenV\xmlconfig\gv-jmx.xml file, under the "Initializers" tag.

Also add

   <mbean code="org.jboss.jms.server.destination.QueueService"
          name="jboss.messaging.destination:service=Queue,name=JADE_GV_Request_Queue"
          xmbean-dd="xmdesc/Queue-xmbean.xml">
      <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
      <depends>jboss.messaging:service=PostOffice</depends>
      <attribute name="JNDIName">gvesb/jms/queue/JADE_GV_Request_Queue</attribute>
      <attribute name="RedeliveryDelay">60000</attribute>
      <attribute name="MaxDeliveryAttempts">100</attribute>
   </mbean>
   <mbean code="org.jboss.jms.server.destination.QueueService"
          name="jboss.messaging.destination:service=Queue,name=JADE_GV_Response_Queue"
          xmbean-dd="xmdesc/Queue-xmbean.xml">
      <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
      <depends>jboss.messaging:service=PostOffice</depends>
      <attribute name="JNDIName">gvesb/jms/queue/JADE_GV_Response_Queue</attribute>
      <attribute name="RedeliveryDelay">60000</attribute>
      <attribute name="MaxDeliveryAttempts">100</attribute>
   </mbean>
   
   <mbean code="org.jboss.jms.server.destination.QueueService"
          name="jboss.messaging.destination:service=Queue,name=GV_JADE_Request_Queue"
          xmbean-dd="xmdesc/Queue-xmbean.xml">
      <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
      <depends>jboss.messaging:service=PostOffice</depends>
      <attribute name="JNDIName">gvesb/jms/queue/GV_JADE_Request_Queue</attribute>
      <attribute name="RedeliveryDelay">60000</attribute>
      <attribute name="MaxDeliveryAttempts">100</attribute>
   </mbean>
   <mbean code="org.jboss.jms.server.destination.QueueService"
          name="jboss.messaging.destination:service=Queue,name=GV_JADE_Response_Queue"
          xmbean-dd="xmdesc/Queue-xmbean.xml">
      <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
      <depends>jboss.messaging:service=PostOffice</depends>
      <attribute name="JNDIName">gvesb/jms/queue/GV_JADE_Response_Queue</attribute>
      <attribute name="RedeliveryDelay">60000</attribute>
      <attribute name="MaxDeliveryAttempts">100</attribute>
   </mbean>

in \GreenV\application\deploy\gvesb-mq-destinations-service.xml, under the "server" tag.

Examples of messaging through GVJADE

• Applying scenario 1

Configure a process to send a JMS message to the "GV_JADE_Response_Queue" queue, serviced under GV, with the following XML code:

   <XMLMessage><sender>GVapp1</sender><receivers><receiver><name>PingAgent@Main_GV_Container</name></receiver></receivers><comm action="REQUEST"/><content>ping</content></XMLMessage>

This, as previously shown in case scenario 1, will trigger GVJADE processing the message to the inner JADE agent ("PingAgent"). The expected result to the REQUEST:"ping" message can be received through the "GV_JADE_Request_Queue" queue, which will be an INFORM:"pong" action.

• Applying scenario 2

In order to trigger scenario 2 shown above a JADE platform must be run (via terminal console or IDE such as Eclipse). Through the platform run a simple agent with send/response capabilities (such as default DummyAgent). Prepare a message to send with:

- address to reach as the GVJADE address/agent (address is the platform one readable from the GVJADE output, while the agent name is the bridging one: "JadeToGvAgent")

- communicative act configured as REQUEST

- content edited a simple "ping" (a simple content to update the internal status to the outside world)

Then press to send the message.

An INFORM:"pong" message will be received from the original sender agent, reporting sort of a "course of action" to follow about the initial update.

• Applying scenario 3

In order to gain accessibility to cluster based messaging between different GV instances a REGISTRATION kind of message needs to be sent to the ingoing queue from a certain GVserv1 service:

   <XMLMessage><sender><name>GVserv1</name></sender><receivers><receiver><name>ProxyAgent@Proxy_GV_Container</name></receiver></receivers><comm action="REQUEST"/><content>[REGISTRATION]</content>     
   </XMLMessage>

Once its registration process is done, GVserv1 will be reachable through the GV clustering. For instance, a GVserv2 (which has been previously been registered) can message GVserv1 by sending a simple XML message, formatted as before:

   <XMLMessage><sender><name>GVserv2</name></sender><receivers><receiver><name>GVserv1</name></receiver></receivers><comm action="REQUEST"/><content>Hi, im a service like you. Pleased to meet you. :-)</content>     
   </XMLMessage>

The Proxy agent will recognize the receiver name previously registered, and will be able to use it with the properly stored route (which is a simple pair : gateway/bridging agent + http GV machine address). Once received, GVserv1 will be able to respond simply sending a message formatted with "GVserv2" as receiver, which has been registered on the proxy. The gateway/bridging agent stated before is an hybrid bordering agent, capable of "speaking" 2 different languages (XML and ACL Fipa): each GV instance/route owns one of these, and its crossed through the messaging phase.

Each messaging phase is meant to cross 2 bridging agents: in the case pictured above message will go from GVserv2 to one bridging agent (owned by the GVserv2 context), then to the Proxy Agent (which will "query" the receiver into its routing map). Proxy agent will "query" receiver name into its routing map and then reroutes message to the proper second bridging agent (owned by the GVserv1 context), down to the GVserv1.