Hi Robbin, Your use case is a perfect example of CEP, an event driven architecture targeted at analyzing, aggregating, correlating and handling of events based on rules. Take a look at, for example, the Esper[1] project for which there exist a Camel component as well [2]. In this case, camel could take care of the actual infrastructure integration of streaming events to Esper. A great book to read up on event processing theories is "Event Processing in Action" [3].
[1] http://esper.codehaus.org/ [2] http://code.google.com/a/apache-extras.org/p/camel-extra/ [3] http://www.manning.com/etzion/ Regards B On Sat, Jul 16, 2011 at 5:46 PM, Robbin <[email protected]> wrote: > I want to monitor my heat. I can raise and lower my thermostats via computer > and read the temperature in the room as well as on the hot water radiator > pipes. > > I want to write a system that: > 1. For a number of thermometers, send temperature readings to message > queue/topic > 2. For a number of thermostats, send thermostat change events to message > queue/topic > 3. Dequeue readings and events and send them to a sql database > 4. Dequeue and maintain the state of all thermometers and thermostats for > analysis > 5. Execute rules based on the state of the system and trigger actions as > appropriate > 6. Allow the state to be queried by a browser or a web service > 7. Allow the triggered actions to be queried by a browser or web service > 8. Allow the devices to be set/cleared via browser or web service > > A rule frozen pipe rule could be: > if [hot water temperature on the pipe going to my radiator is rising] > and > [hot water temperature on the return pipe is still cold] and [radiator's > room temperature is cold and not rising] then trigger a message to tell me > my pipe might be frozen. > > A triggered message could be an email or SMS or phone call. > > I think ServiceMix allows all these things to be relatively independent. > > I think ServiceMix allows me to add rules, actions, inputs and queries as > time goes on without changing ones that work already. > > I used to have a single Java program that did everything but rules. Most of > the code was handling exceptions and recovering from problems. Every new > exceptional condition caused a rewrite or at least a new recovery. It isn't > as stable as I wished and took too much effort to make stable. > > Now I have little programs (#1 & #2 above). The temperature reader doesn't > worry if the sql insert failed. The sql logger (#3) doesn't worry if the > thermometer didn't read. Either of them can put a message on another queue > that there is a problem and I can address that as a separate concern. Camel > is the glue that makes them work together. > > I wonder if keeping my state (#4) would be done well in an EJB that listens > for messages or is there a EIP for this I'm not aware of? > > I wonder if rules (#5) can be easily incorporated into ServiceMix? DROOLS > and ODE come to mind. I'd have to make a rule that this thermostat, this > room temperature, these pipe temperatures must all trend together. And when > an action is to be taken (maybe by sending a message to a queue/topic), > another component that does the notification. Camel would glue them > together. > > I'd like to write a web app or an Android app (#6) to see my state and maybe > turn on and off the heat (#7) from my phone or computer. > > Eventually I'd like to monitor more than just my house. Maybe my neighbors > would like the same thing. This is another dimension to the problem – it > would be good if it generalizes. I'd need a hierarchy of the devices that > trend together that based on which house it is. > > In summary: > > Is this architecturally sound? > Is an EJB a good choice to maintain state or is there a better way? > Is ServiceMix a good choice to publish web pages or web services for > querying the state? > Eventually I'd need to sign the messages so I know they are authentic, is > this possible? > > -- > View this message in context: > http://servicemix.396122.n5.nabble.com/Archectural-Advice-tp4594154p4594154.html > Sent from the ServiceMix - User mailing list archive at Nabble.com. >
