You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by Robbin <se...@churchilllake.com> on 2011/07/16 17:46:22 UTC
Archectural Advice
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.
Re: Archectural Advice
Posted by Andreas Pieber <an...@gmail.com>.
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 <bj...@gmail.com>
> 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 <bj...@gmail.com>:
> > 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 <se...@churchilllake.com>
> 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.
> >>
> >
>
Re: Archectural Advice
Posted by Björn Bength <bj...@gmail.com>.
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 <bj...@gmail.com>:
> 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 <se...@churchilllake.com> 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.
>>
>
Re: Archectural Advice
Posted by Björn Bength <bj...@gmail.com>.
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 <se...@churchilllake.com> 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.
>