You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Rahul Akolkar <ra...@gmail.com> on 2009/06/02 18:52:25 UTC
Re: SCXML Managing a large number of long-lived state machines.
Response below ...
On Tue, Jun 2, 2009 at 10:21 AM, JEFFREY Mark <Ma...@post.be> wrote:
> Hello,
>
>
>
> We are writing a Java application that uses a state machine and feel
> that scxml may be a good fit for us, although our use case is a little
> different from the ones presented in the docs.
>
>
>
> The logic is the following:
>
>
>
> * We receive an event for a "tracked item" though JMS (using a
> message driven bean which gives a separate thread for each event).
> * If the item does not exist we create it otherwise we retrieve it
> with the current state from the database.
> * Set the state and, based on the state, set attributes of the
> item (typically item attributes are copied from the attributes of the
> event but not always).
> * Save the item, the current state, and the event in the database.
>
>
>
> When we receive an event it is for any one of millions of items. I
> suppose we need to construct a new state machine for each event and
> (somehow) set the current state in the state machine.
>
>
>
> Some of the questions we have.
>
>
>
> When we receive an event we need to set the state machine to the current
> state. Is there a special mechanism for this? - I tried the following
> but it seems like a hack to me...
>
>
>
> public void setState( String stateString ) throws ModelException{
>
> State stateToSet = (State)
> getEngine().getStateMachine().getTargets().get(stateString);
>
>
>
> if(stateToSet == null){
>
> throw new IllegalArgumentException( "State was not found: "
> + stateString );
>
> }
>
> SCXML stateMachine = getEngine().getStateMachine();
>
> TransitionTarget initialTarget =
> stateMachine.getInitialTarget();
>
> stateMachine.setInitialTarget(stateToSet);
>
> getEngine().reset();
>
> stateMachine.setInitialTarget(initialTarget);
>
> }
>
<snip/>
Right, I wouldn't mutate the model itself (the 'stateMachine') since
it is meant to be shared across all executor instances of the same
state machine. In some cases, the status of the executor instance can
be adjusted instead, as desired here.
> Otherwise we could read in all the events (up to 20 per item) and apply
> them sequentially to the item to calculate the current state each time.
>
>
>
> How should we manage the state machine construction?
>
> Keep a pool of statemachines (or Threadlocals) and use reset(). I guess
> we would then need to replace any listeners.
>
> Construct a new statemachine each time (cost?).
>
<snap/>
We had a similar thread about pooling executor instances about a month
ago. I'll point to that here, please follow this link:
http://markmail.org/thread/7rzalbdmbtvhr4kq
-Rahul
>
>
> Thanks in advance,
>
> Mark Jeffrey
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [SCXML] BPEL vs SCXML
Posted by Rahul Akolkar <ra...@gmail.com>.
On Tue, Jun 9, 2009 at 5:25 AM, Alexander
Blotny<Al...@fokus.fraunhofer.de> wrote:
> Hi,
>
> in my institute we have an implementation using BPEL for orchestration of
> processes in our testbed of an IMS core. Which is an IP based
> telecommunication environment. We encountered some real time issues using
> BPEL due to several web service calls. Now I am searching for another
> solution for the orchestration. SCXML seems to be an interesting approach as
> an generic state machine language. In particular because of the
> implementation with the possibility to run java code in the states. I would
> like to ask if someone has experiences using SCXML for this purpose.
<snip/>
With limited information, its hard to say, but SCXML is designed for
control abstraction and orchestration. Some usecases are at the bottom
of the home page:
http://commons.apache.org/scxml/
Following those links will give some details on those.
The user guide in the LHS menu has more details about usage patterns etc.
> I am
> also interested in some opinions on a comparison of BPEL and SCXML because I
> am quite unsure if it is even possible to do that.
<snap/>
Starting with the obvious, BPEL is more geared towards business
processes, SCXML is generic (there is even a Mozilla plugin for
controlling behavior on the glass, so it spans all tiers). BPEL
provides more support for process concerns in the enterprise, SCXML
can be used for similar purposes but with more work (putting it
differently, SCXML begins as a much more lightweight engine out of the
box). BPEL is more for active systems, SCXML is more for reactive
systems (its the same difference that causes UML to differentiate
between Activity Diagrams and State Charts).
If you have any other questions about the library itself, let us know.
-Rahul
> Maybe someone knows some
> interesting links to that topic.
>
> Thanks.
>
> Greetings,
> Alex
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
[SCXML] BPEL vs SCXML
Posted by Alexander Blotny <Al...@fokus.fraunhofer.de>.
Hi,
in my institute we have an implementation using BPEL for orchestration of
processes in our testbed of an IMS core. Which is an IP based
telecommunication environment. We encountered some real time issues using
BPEL due to several web service calls. Now I am searching for another
solution for the orchestration. SCXML seems to be an interesting approach as
an generic state machine language. In particular because of the
implementation with the possibility to run java code in the states. I would
like to ask if someone has experiences using SCXML for this purpose. I am
also interested in some opinions on a comparison of BPEL and SCXML because I
am quite unsure if it is even possible to do that. Maybe someone knows some
interesting links to that topic.
Thanks.
Greetings,
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: SCXML Managing a large number of long-lived state machines.
Posted by Rahul Akolkar <ra...@gmail.com>.
On Tue, Jun 2, 2009 at 2:23 PM, Lee, Cheryl - ES/RDR -Gil
<Ch...@itt.com> wrote:
> Mark,
>
> We are using Rational Software Architect (RSA) to draw the UML state machines and "transform" them to SCXML (a plugin available for RSA).
<snip/>
Right, if using RSA, you can find the plugin here:
http://www.alphaworks.ibm.com/tech/scxml
-Rahul
> The SCXML output from RSA needs to be cleaned up a little to be compatible with Apache netcommons, but it's nothing a short script can't deal with.
>
> There may also be other tools that generate SCXML, but I'm not currently aware of any others.
>
> Good luck,
> Cheryl
>
> -----Original Message-----
> From: JEFFREY Mark [mailto:Mark.JEFFREY@post.be]
> Sent: Tuesday, June 02, 2009 11:07 AM
> To: Commons Users List
> Subject: RE: SCXML Managing a large number of long-lived state machines.
>
>
> Hi Rahul,
>
> Thanks for the fast response, it looks like exactly what I was after (searched the mailing list but didn't find that thread). I'll try it tommorow when I get in the office (I'm at home now).
>
> cheers,
> Mark
>
> p.s. do you know of any GUI's that can produce scxml as output?
>
>
> ________________________________
>
> From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
> Sent: Tue 02/06/2009 18:52
> To: Commons Users List
> Subject: Re: SCXML Managing a large number of long-lived state machines.
>
>
>
> Response below ...
>
> On Tue, Jun 2, 2009 at 10:21 AM, JEFFREY Mark <Ma...@post.be> wrote:
>> Hello,
>>
>>
>>
>> We are writing a Java application that uses a state machine and feel
>> that scxml may be a good fit for us, although our use case is a little
>> different from the ones presented in the docs.
>>
>>
>>
>> The logic is the following:
>>
>>
>>
>> * We receive an event for a "tracked item" though JMS (using a
>> message driven bean which gives a separate thread for each event).
>> * If the item does not exist we create it otherwise we retrieve it
>> with the current state from the database.
>> * Set the state and, based on the state, set attributes of the
>> item (typically item attributes are copied from the attributes of the
>> event but not always).
>> * Save the item, the current state, and the event in the database.
>>
>>
>>
>> When we receive an event it is for any one of millions of items. I
>> suppose we need to construct a new state machine for each event and
>> (somehow) set the current state in the state machine.
>>
>>
>>
>> Some of the questions we have.
>>
>>
>>
>> When we receive an event we need to set the state machine to the
>> current state. Is there a special mechanism for this? - I tried the
>> following but it seems like a hack to me...
>>
>>
>>
>> public void setState( String stateString ) throws ModelException{
>>
>> State stateToSet = (State)
>> getEngine().getStateMachine().getTargets().get(stateString);
>>
>>
>>
>> if(stateToSet == null){
>>
>> throw new IllegalArgumentException( "State was not found: "
>> + stateString );
>>
>> }
>>
>> SCXML stateMachine = getEngine().getStateMachine();
>>
>> TransitionTarget initialTarget =
>> stateMachine.getInitialTarget();
>>
>> stateMachine.setInitialTarget(stateToSet);
>>
>> getEngine().reset();
>>
>> stateMachine.setInitialTarget(initialTarget);
>>
>> }
>>
> <snip/>
>
> Right, I wouldn't mutate the model itself (the 'stateMachine') since it is meant to be shared across all executor instances of the same state machine. In some cases, the status of the executor instance can be adjusted instead, as desired here.
>
>
>> Otherwise we could read in all the events (up to 20 per item) and
>> apply them sequentially to the item to calculate the current state each time.
>>
>>
>>
>> How should we manage the state machine construction?
>>
>> Keep a pool of statemachines (or Threadlocals) and use reset(). I
>> guess we would then need to replace any listeners.
>>
>> Construct a new statemachine each time (cost?).
>>
> <snap/>
>
> We had a similar thread about pooling executor instances about a month ago. I'll point to that here, please follow this link:
>
> http://markmail.org/thread/7rzalbdmbtvhr4kq
>
> -Rahul
>
>
>>
>>
>> Thanks in advance,
>>
>> Mark Jeffrey
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
RE: SCXML Managing a large number of long-lived state machines.
Posted by "Lee, Cheryl - ES/RDR -Gil" <Ch...@itt.com>.
Mark,
We are using Rational Software Architect (RSA) to draw the UML state machines and "transform" them to SCXML (a plugin available for RSA). The SCXML output from RSA needs to be cleaned up a little to be compatible with Apache netcommons, but it's nothing a short script can't deal with.
There may also be other tools that generate SCXML, but I'm not currently aware of any others.
Good luck,
Cheryl
-----Original Message-----
From: JEFFREY Mark [mailto:Mark.JEFFREY@post.be]
Sent: Tuesday, June 02, 2009 11:07 AM
To: Commons Users List
Subject: RE: SCXML Managing a large number of long-lived state machines.
Hi Rahul,
Thanks for the fast response, it looks like exactly what I was after (searched the mailing list but didn't find that thread). I'll try it tommorow when I get in the office (I'm at home now).
cheers,
Mark
p.s. do you know of any GUI's that can produce scxml as output?
________________________________
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
Sent: Tue 02/06/2009 18:52
To: Commons Users List
Subject: Re: SCXML Managing a large number of long-lived state machines.
Response below ...
On Tue, Jun 2, 2009 at 10:21 AM, JEFFREY Mark <Ma...@post.be> wrote:
> Hello,
>
>
>
> We are writing a Java application that uses a state machine and feel
> that scxml may be a good fit for us, although our use case is a little
> different from the ones presented in the docs.
>
>
>
> The logic is the following:
>
>
>
> * We receive an event for a "tracked item" though JMS (using a
> message driven bean which gives a separate thread for each event).
> * If the item does not exist we create it otherwise we retrieve it
> with the current state from the database.
> * Set the state and, based on the state, set attributes of the
> item (typically item attributes are copied from the attributes of the
> event but not always).
> * Save the item, the current state, and the event in the database.
>
>
>
> When we receive an event it is for any one of millions of items. I
> suppose we need to construct a new state machine for each event and
> (somehow) set the current state in the state machine.
>
>
>
> Some of the questions we have.
>
>
>
> When we receive an event we need to set the state machine to the
> current state. Is there a special mechanism for this? - I tried the
> following but it seems like a hack to me...
>
>
>
> public void setState( String stateString ) throws ModelException{
>
> State stateToSet = (State)
> getEngine().getStateMachine().getTargets().get(stateString);
>
>
>
> if(stateToSet == null){
>
> throw new IllegalArgumentException( "State was not found: "
> + stateString );
>
> }
>
> SCXML stateMachine = getEngine().getStateMachine();
>
> TransitionTarget initialTarget =
> stateMachine.getInitialTarget();
>
> stateMachine.setInitialTarget(stateToSet);
>
> getEngine().reset();
>
> stateMachine.setInitialTarget(initialTarget);
>
> }
>
<snip/>
Right, I wouldn't mutate the model itself (the 'stateMachine') since it is meant to be shared across all executor instances of the same state machine. In some cases, the status of the executor instance can be adjusted instead, as desired here.
> Otherwise we could read in all the events (up to 20 per item) and
> apply them sequentially to the item to calculate the current state each time.
>
>
>
> How should we manage the state machine construction?
>
> Keep a pool of statemachines (or Threadlocals) and use reset(). I
> guess we would then need to replace any listeners.
>
> Construct a new statemachine each time (cost?).
>
<snap/>
We had a similar thread about pooling executor instances about a month ago. I'll point to that here, please follow this link:
http://markmail.org/thread/7rzalbdmbtvhr4kq
-Rahul
>
>
> Thanks in advance,
>
> Mark Jeffrey
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender.
Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Corporation. The recipient should check this e-mail and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mail.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
RE: SCXML Managing a large number of long-lived state machines.
Posted by JEFFREY Mark <Ma...@post.be>.
Hi Rahul,
Thanks for the fast response, it looks like exactly what I was after (searched the mailing list but didn't find that thread). I'll try it tommorow when I get in the office (I'm at home now).
cheers,
Mark
p.s. do you know of any GUI's that can produce scxml as output?
________________________________
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
Sent: Tue 02/06/2009 18:52
To: Commons Users List
Subject: Re: SCXML Managing a large number of long-lived state machines.
Response below ...
On Tue, Jun 2, 2009 at 10:21 AM, JEFFREY Mark <Ma...@post.be> wrote:
> Hello,
>
>
>
> We are writing a Java application that uses a state machine and feel
> that scxml may be a good fit for us, although our use case is a little
> different from the ones presented in the docs.
>
>
>
> The logic is the following:
>
>
>
> * We receive an event for a "tracked item" though JMS (using a
> message driven bean which gives a separate thread for each event).
> * If the item does not exist we create it otherwise we retrieve it
> with the current state from the database.
> * Set the state and, based on the state, set attributes of the
> item (typically item attributes are copied from the attributes of the
> event but not always).
> * Save the item, the current state, and the event in the database.
>
>
>
> When we receive an event it is for any one of millions of items. I
> suppose we need to construct a new state machine for each event and
> (somehow) set the current state in the state machine.
>
>
>
> Some of the questions we have.
>
>
>
> When we receive an event we need to set the state machine to the current
> state. Is there a special mechanism for this? - I tried the following
> but it seems like a hack to me...
>
>
>
> public void setState( String stateString ) throws ModelException{
>
> State stateToSet = (State)
> getEngine().getStateMachine().getTargets().get(stateString);
>
>
>
> if(stateToSet == null){
>
> throw new IllegalArgumentException( "State was not found: "
> + stateString );
>
> }
>
> SCXML stateMachine = getEngine().getStateMachine();
>
> TransitionTarget initialTarget =
> stateMachine.getInitialTarget();
>
> stateMachine.setInitialTarget(stateToSet);
>
> getEngine().reset();
>
> stateMachine.setInitialTarget(initialTarget);
>
> }
>
<snip/>
Right, I wouldn't mutate the model itself (the 'stateMachine') since
it is meant to be shared across all executor instances of the same
state machine. In some cases, the status of the executor instance can
be adjusted instead, as desired here.
> Otherwise we could read in all the events (up to 20 per item) and apply
> them sequentially to the item to calculate the current state each time.
>
>
>
> How should we manage the state machine construction?
>
> Keep a pool of statemachines (or Threadlocals) and use reset(). I guess
> we would then need to replace any listeners.
>
> Construct a new statemachine each time (cost?).
>
<snap/>
We had a similar thread about pooling executor instances about a month
ago. I'll point to that here, please follow this link:
http://markmail.org/thread/7rzalbdmbtvhr4kq
-Rahul
>
>
> Thanks in advance,
>
> Mark Jeffrey
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org