As a webframework on top of smx/karaf might be interesting for you is pax-wicket [1] which gives you Wicket playing nicely in the OSGi container. For EIP (messaging patterns) a VERY good read may also be [2] (which is my personal favorite). You can build those patterns based on AMQ alone, based on SMX-Camel or directly with the SMX-EIP component.
Kind regards, Andreas [1] http://team.ops4j.org/wiki/display/paxwicket/Pax+Wicket [2] http://www.eaipatterns.com/ 2011/7/17 Björn Bength <[email protected]> > Forgot to add that servicemix/camel is a great container where > webservices can live > and expose (through CXF) services that query the database for your state. > It's not the best web application framework though. > Message integrity through signing is also available[1]. > > [1] http://camel.apache.org/crypto-digital-signatures.html > > Regards > Björn > > > 2011/7/17 Björn Bength <[email protected]>: > > 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. > >> > > >
