All,
I am looking for a rules engine that can be used on top of a very large
database but can also be crunched down for execution in a thin client. To
put the term "thin client" into perspective, it could run about 100k of C
for example. The alternative is J2ME on a mobile phone. Since mobility is
an issue, anything supporting geofencing would be a definite advantage.

Thanks,
Mitch

 

Mitch,
A few questions:
-Could you describe the project more specifically (nodes, response time, data, etc)?
-How much programming expertise do you have?
-Describe the geofencing requirement. How does this go beyond GIS support?
-Why does the rules engine need to run client side?
-What's behind the 100k of C example for the client "weight".

Dealing with large database - shouldn't be a problem for most vendors (or custom programs). I'm not following why you seem to have such an "all or nothing" approach. It would typically make sense to do necessary heavy computing on the server side, allow some amount of computing with the workstations, and less on the cell phones.

----
Nathan Boeger
http://www.inductiveautomation.com
"Design Simplicity Cures Engineered Complexity"

 

Hey Mitch .. check out MobiKEY at route1.com .. not QUITE sure what youre looking for but ....

Cheers from: Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline.com

Control Design www[.]controldesignmag.com
Manufacturing Automation www[.]automationmag.com

3 Red Pine Court, RR# 2 Shanty Bay, Ontario L0L 2L0
705.739.7155 Cell # 705.725.3579

 

Nathan,

Thanks for the interest. Yes, it makes sense to run a lot of this server side, particularly the geofencing but we have instances where the opposite makes more sense.

In short, we are dealing with mobile asset tracking where the assets include sensors. It is NOT a telamatics solution but that is the closest analogy. Since there is cellular backhaul, it is important to be able to run certain rules locally to improve dependability and reduce network traffic. For example, things will happen often but we will be looking for those rare instances where things DON'T happen. In other instances we will be looking at the location of certain devices to make sure they are in sensible places and not missrouted hence the geofencing. In other instances, we don't want to know anything from the device provided it hasn't move. If it moves we want it to scream bloody murder. This is another instance where we could be told often that something didn't move or once that it did. On top of all this, the sensors will tell us about the health of the object. We want to have a record of any abuse and we may wish to take action due to that abuse.

Respose time is not particularly fast. We are not doing real time process control. We could even do store-and-forward for a lot of it. There could be millions of nodes. We have as much programming expertise as you need. We have seen a device that we could use on the mobile side which has support for 100k of C at the application layer. It wouldn't be unreasonable for us to provide a J2ME core with up to 1Gig of Flash if needed but that is starting to get a bit heavy.

Thanks,
Mitch

The future is here. It just isn't widely available.