Best way to implement rule check while communicating with GPS device

We are developing a vehicle tracking system. Like every VTS, we have GPS devices fitted into the vehicles开发者_如何学运维 which keep sending location information to the server. On server, our TCP communicator process keeps reading that data and saves it into the database Now, we need to check for some set of rule to trigger alerts for the vehicles, e.g We need alert when vehicle reaches to a particular location, if vehicle crosses specific speed-limit,etc. Can you please suggest the best way to implement it? We have thought of some ways to implement it, 1. Our TCP communicator, when receives the location, should check for the alerts. 2. There will be a process which will keep running every 15 minutes and check the location details in that 15 minutes for alerts.

I am looking for the suggestions to implement it, logic-wise as well as technology-wise. e.g. Whether we should use Drools or not?, etc.

Somebody from FedEx actually presented something like this in a JavaOne conference I attended a couple of years back.

Basically, the idea was, yes, using Drools Expert + Fusion to perform CEP (complex events processing) on vehicle location data.

As far as I can recall, a vehicle would periodically (every couple of seconds even) send its GPS coordinates to the engine (an event) which would then be digested by the rules engine, and depending on the rules could trigger certain actions such as raising alerts ("vehicle is stalled" or "out of course") or sending notifications ("vehicle will arrive at destination in ~15 minutes").

(Google for "drools fusion cep vehicle tracking" uncovers this presentation which should give you few more details or at least provide some insight.)

the way Drools work, is that you fill in alot of objects into the "Working Memory" of Drools. While you fill in the objects, Drools will find out which rules "fires" on the objects and stores the objects in a Rete-Tree. When you are finished putting the objects in the memory and you fire all rules, Drools will process the code you wrote corresponding to the rule.

I would suggest, that you make an object with all the data recieved from the vehicle necessary for your rules and put it in the working memory.

In Drools you should make many small rules, each just checking one thing and acting on the result.

It is not a good practice to let Drools get data needed for evaluation, but I can't see any problems in letting Drools trigger some events, that send messages to a vehicle or some other system. (I guess that should happen async, so that you don't slow down Drools) In fact, Drools offers you to hook up an eventlistener.

There's no reason to run every 15 minutes. That will introduce delay in the triggers and also result in bursts of load every 15 minutes followed be periods of no load.

You can have a flag in your database for new alert rules and new location data. When you scan for events, you can use a two-pass approach. Check all new rules against all location data and mark them no longer new. Then check all new location data against existing rules and mark them no longer new.

You can run this as often as you like. Ideally, you wouldn't wait that long because the longer you wait, the more work you accumulate.

As for having the TCP communicator check for relevant alerts over the scan the database periodically approach, the main advantage would be alerts would be immediate. The disadvantage would be that alert processing would slow down the TCP communicator path and you would be locked into a "one update means one check for alerts" model.

In the "scan the database" approach, if load gets too high, you can wind up checking for alerts only on every so many updates from high-frequency update sources. This naturally deals with load by reducing the amount of work needed, but it could result in a missed alert.

I think all the approaches you're considering will work fine.