Difference between revisions of "GVJade"

From GreenVulcano Wiki
Jump to: navigation, search
(Examples of messaging through GVJADE)
(Examples of messaging through GVJADE)
Line 120: Line 120:
 
- communicative act configured as ''REQUEST''
 
- communicative act configured as ''REQUEST''
  
- content edited a simple "''ping''"
+
- content edited a simple "''ping''" (a simple content to update the internal status to the outside world)
  
Then press to send the message, which will be replied from the outside context with a ''INFORM'':"''pong''"
+
Then press to send the message.
 +
An ''INFORM'':"''pong''" will be received from the original sender agent, simulating a "course of action" to follow about the initial update.

Revision as of 19:46, 16 September 2012

GVJADE, a JADE integration in GreenVulcano

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 an 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


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" will be received from the original sender agent, simulating a "course of action" to follow about the initial update.