commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <Joe.Tol...@barclayscapital.com>
Subject RE: [SCXML] Usecases (WAS: [VOTE] Promote SCXML to Proper)
Date Tue, 17 Jan 2006 09:12:43 GMT
A real application...

We're very keen to build a solution for a trade workflow and documentation system which does
exactly what you describe people don't want.

Controlling state in our current application is a nightmare - it can't be visualised, we have
states which are meaningless, states which are dead ends etc etc.

We want to have a run time to drive state - our processing is split between automatic state
movement and manual movement - background processes or users raise events which in turn force
state movement, traders to be notified, documents to be sent and generated, electronic messages
communicated to other banks.

We want to be able to provide out business owners with a quick overview of where all his trades
are, so that he move them around, escallate to new users.

The SCXML model is the only thing that we have found which is rich enough, tightly enough
specified, and offers the real chance of putting state at the centre of our application.



-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com] 
Sent: 17 January 2006 05:13
To: Jakarta Commons Developers List
Subject: [SCXML] Usecases (WAS: [VOTE] Promote SCXML to Proper)


On 1/13/06, Martin van den Bemt <mllist@mvdb.net> wrote:
> >
> > In the mean time, if you have browsed through Commons SCXML and have 
> > suggestions for improvement, let me know. Careful, that might risk 
> > making you a believer though ;-)
>
> I'll see if I can free up some time to dig into it, but currently 
> lacking a use case for myself though..
>
<snip/>

Yup, that is a somewhat common theme. Commons SCXML is probably looked at as having esoteric
usage patterns. In all fairness, finding usecases isn't very easy because most hardly think
of writing a state machine as a document for the runtime. The state machine gets visualized,
called things such as "lifecycles", drawn as block diagrams with arrows, or even modeled as
a "real" state chart diagram, but rarely tied in directly with the runtime. What Commons SCXML
gives us is this ability to use the behavior modeling layer right into the runtime, as depicted
in this picture [1]. Some of the newer "frameworks" are starting to pick this up, the existing
SCXML usecases on the website are examples.

The Commons user list also has atleast a couple of examples where folks have used SCXML in
innovative ways. While it sounds extremely clich├ęd ;-) the usecases for Commons SCXML are
limited only by our imaginations. Really. As the size of the "reactive system" grows, the
benefits of Commons SCXML become more apparent.

A BZ ticket [2] has been recently filed for adding a new usecase that is simpler (not involving
prior knowledge of any framework -- couple of good candidates there already).

Finally, a good general read on this topic is the book "Modeling Reactive Systems with Statecharts"
[3] by Harel and Politi (the book is now a free download). SCXML uses concepts from Harel
State Tables (as mentioned in the spec). Not implying anyone should read the book, just saying
if you happen to be interested, you'll probably consider this worth your time :-)

-Rahul

[1] http://people.apache.org/~rahul/CommonsSCXML.pdf (see page 2) [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=38274
[3] http://www.wisdom.weizmann.ac.il/~dharel/reactive_systems.html

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org



------------------------------------------------------------------------
For more information about Barclays Capital, please
visit our web site at http://www.barcap.com.


Internet communications are not secure and therefore the Barclays 
Group does not accept legal responsibility for the contents of this 
message.  Although the Barclays Group operates anti-virus programmes, 
it does not accept responsibility for any damage whatsoever that is 
caused by viruses being passed.  Any views or opinions presented are 
solely those of the author and do not necessarily represent those of the 
Barclays Group.  Replies to this email may be monitored by the Barclays 
Group for operational or business reasons.

------------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message