GVJade - Revision history

A.capaldo: /* Examples of messaging through GVJADE */

2012-09-28T13:42:50Z

‎Examples of messaging through GVJADE

A.capaldo: /* Examples of messaging through GVJADE */

2012-09-28T13:42:16Z

‎Examples of messaging through GVJADE

A.capaldo: /* Examples of messaging through GVJADE */

2012-09-28T13:41:37Z

‎Examples of messaging through GVJADE

A.capaldo: /* Examples of messaging through GVJADE */

2012-09-28T13:40:58Z

‎Examples of messaging through GVJADE

A.capaldo: /* Examples of messaging through GVJADE */

2012-09-28T13:39:58Z

‎Examples of messaging through GVJADE

A.capaldo: /* Examples of messaging through GVJADE */

2012-09-28T13:39:24Z

‎Examples of messaging through GVJADE

A.capaldo: /* Description */

2012-09-28T13:15:23Z

‎Description

A.capaldo: /* Description */

2012-09-28T13:15:02Z

‎Description

A.capaldo at 09:46, 17 September 2012

2012-09-17T09:46:19Z

A.capaldo at 09:45, 17 September 2012

2012-09-17T09:45:46Z

← Older revision		Revision as of 13:42, 28 September 2012
Line 130:		Line 130:

	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.		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		*Applying scenario 3

← Older revision		Revision as of 13:42, 28 September 2012
Line 147:		Line 147:
	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.		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 ~~receiving~~ 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.	+	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.

@@ Line 146: / Line 146: @@
 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 receiving 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.

@@ Line 143: / Line 143: @@
      </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 like : ''gateway/bridging agent'' + ''http GV machine address'')
+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 receiving 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.

@@ Line 140: / Line 140: @@
 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><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>

← Older revision		Revision as of 13:39, 28 September 2012
Line 130:		Line 130:

	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.		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 like : ''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 receiving 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.

@@ Line 27: / Line 27: @@
 * 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

← Older revision		Revision as of 13:15, 28 September 2012
Line 26:		Line 26:
	* External application, waiting for the update, finds and uses it, also preparing a proper response in XML and sending it to another queue		* 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		* 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

@@ Line 38: / Line 38: @@
       <GCJADEAdapterConfiguration>
-	    <Engine main="true" local-port="1500" gui="false" dump-options="true" no-display="true" platform-id="Main_GV_Container" nomtp="false"/>
+	    <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"/>