This is a work on progress on delivering a Prova EP implementation for the use case proposed by Opher Etzion and Peter Niblett for the upcoming book "Event Processing in Action".
The working project containing many more other tests can be checked out from https://mandarax.svn.sourceforge.net/svnroot/mandarax/mule-prova-agents2/trunk. The project relies on maven2 and the general instructions to get you up to speed are available here: http://www.prova.ws/downloads.php. You do not actually need the Prova project itself, just the project mentioned before. To run the test, find and run Prova3FlowerDeliveryTest.java.
The first part of the use case as a set of distributed agents using the Prova Mule ESB is available. This is a test Prova3FlowerDeliveryTest.java that it is possible to run by checking out the mule-prova-agents project in Prova Subversion. The implementation highlights that
- it is easy to distribute Prova agents using a variety of transports provided by the Mule ESB;
- the example will use JMS, both topics, for stores and drivers broadcasts, and queues, for direct communication and responding to senders;
- it is easy to run the whole application as a test with verifiable requirements;
- the Prova agents are not aware of the transports used and the latter could be changed (for example, from JMS to TCP if required);
- Prova is a practical rather than a purist language that allows one to fully use any Java libraries to complement and extend its functionality, for example, ws.prova.eventing.SortedAccumulator is used for accumulating and sorting the arriving records in real time (see the manual assignment mode for a flower store below);
- reaction groups can be used for modelling protocols with multiple choice and timeouts, as well as event pattern detection.
The conversation runs on conversation-id RequestId, which "pins" all the conversation to a single thread, so that no synchronization is required. See details in the async protocol in Concurrent reactive messaging.
So far there are two drivers and two stores. The agents are connected to the MuleESB with the following critical part of the configuration.
The test runs until the drivers get two assignments each, which is expected given the static data and sent orders. The test is heavily concurrent so that each agent runs in parallel, and processing for different orders inside each store is also fully concurrent at low level.
This is a rulebase included from each driver agent.
This is the code for driver1.
This is the code for driver2.
This is the common included rulebase for each store.
This is the code for store1.
This is the code for store1.
The actual Java test Prova3FlowerDeliveryTest.java initializes Mule, which starts a local ActiveMQ JMS and all the agents and awaits for four confirmations from the drivers.
This is the output trace from running the test. Note that the precise ordering may be different due to concurrency. Also observe that all four assignments go to driver1 that has the highest rank.