Tracking change and innovation in the enterprise software development community
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Free Book Offer
SOA Demystified
$40 Value
Posted by Jean-Jacques Dubray on Jun 06, 2008
Ksenia (Ryndina) Wahler, Jochen Kuester and Aurelien Monot have released on AlphaWorks an experimental Eclipse plugin dubbed "Object Lifecycle Explorer" for IBM WebSphere Business Modeler (for which a trial version is available [1]). Object Life Cycle Explorer for WebSphere Business Modeler implements several techniques for the integration of process and object life cycle modeling developed at the IBM Zurich Research Laboratory.
The concept of Object Lifecycle (a.k.a State Machine) is emerging both in terms of methodology and programming concept. For instance the Praxeme Enterprise Methodology relies heavily on this concept, while both IBM Process Server and Microsoft's Workflow Foundation offer a state machine formalism that can be transformed into orchestrations.
Ksenia notes:
As part of achieving a business goal, a business process typically manipulates several business objects, transforming their states as the process progresses.
Understanding the complete state evolution of a single business object is often required for monitoring, governance, and compliance purposes, but eliciting such object life cycle information correctly from complex process models can be challenging.
She and her colleagues developed the Object Lifecycle Explorer based on the IBM Business State Machine metamodel to:
In particular they establish a deterministic relationship between object lifecycles and business processes:
The object life cycle extraction is then performed by applying transformation rules, which map activities in process models to state transitions in object life cycles and identify initial and final states for each life cycle.
In this paper published last year, Jochen Kuester and his colleagues report:
Our experiments with IAA [IBM Insurance Application Architecture] have shown the viability of the approach for sizeable reference models. Overall, our solution can be seen as a contribution to bridging the gap between process and object modeling.
The state machine formalism is still new to most developers and generally not used. Today, all states and transitions - intrinsic to a business object- are somehow hard-coded using ad hoc formalisms or no formalism at all. In particular, there is no attempt to link the actions of a controller with the states of a model in a formal way when using the Model-View-Controller pattern. We can expect that tools such as the Object Lifecycle Explorer will help relay both the importance and simplicity of this formalism.
[1] The plug-in installs readily in WBM trial's version and comes with a full tutorial.
Architectures Behind Facebook, Skype, Sky.com, Bwin, League of Legends @ QConLondon
Right Collaboration Architecture Drives Business Transformation
Understand and Align BPM, SOA, and Lean Six Sigma: 43 page IBM Redguide
Visit SOA Appliance Comparison Site
*Video Usage Model Tutorials
*Comparison to IBM DataPower X150
*Performance Benchmarks/Webinars
*Replace DataPower Program
FREE 1:1 Swap & Migration Services
Thanks as ever Jean-Jacques, do you have any references for Mr Average Joe Developer (like me) who might want to consider whether this is a pattern to use in an application or not (FSMs that is). Your previous article was incredibly thorough but might be too deep for newbies like me. Glad you're demonstrating this pattern; I think very few of us like to have blind spots to good solutions, although historically we tend to :-)
All the best
Neil
Neil:
thanks :-). In many ways you are using this pattern today, you have no choice. Every (business) "thing" (Purchase Order, Invoice,...) has states and allowed transitions between these states. These are embedded in everybody's code.
The questions to ask are:
a) since one of the primary goals of my information systems it to manage these states and transitions (because they are intrinsic, they are not a programming concept) should I make them explicit across the SDLC (requirements, specs, design, implementation, unit tests, operations)
b) how can I make them explicit? (state, transition, action) metamodels abound. UML has one (but for some reason never really used), you can build your own.
c) how can I implement these models? Architecture vary widely (embedded, distributed), persistence (or no persistence) model, scalability/failover...
My suggested quick ramp up path is:
1) look at UML state machine diagram
2) create a simple class model in your favorite OO language based on a state, transition, action model (you will see how simple that is)
3) now explore how BPEL (say Apache ODE) can be used to implement a particular state machine since the main problems you will have if you expand your state machine model will be persistence, activation, scalability...(you really want someone to solve these problems for you) An implementation tip for BPEL, just create a variable called "state" and use the assign activity to assign it to the appropriate values during the lifecycle, you can then graft send/receive and invoke activities in between the states. They correspond to actions invocations to the state machine.
4) look at how SCA can be used for assembling these object lifecycles together
5) explore the role of events in this model (an event is the occurrence of a state)
I think if you take these 5 steps you will realize how often you hard coded this over and over and never looked back.
The real driver behind using such an approach is that fact that this code is hard to write, very hard to debug and very hard to change. I would argue that 60% of a project is focused on getting states and transition work correctly.
It would certainly make a very interesting article to write !
Indeed, I've recently become interested in treating implicit states as actual mini state machines, purely as a Java pattern, not using a framework (yet). That was prompted by reading one of your articles actually.
Scale is the aspect that really interests me, because with highly distributed systems which are often message based, the state
travels with a message between systems to avoid the scaling bottleneck of a single authoritative source.
This is the basis of document centric messaging of course as opposed to RPC style messaging which mostly communicates state changes, (update, remove, add etc.) .
So in my experience in document centric system the ad-hoc state machine is usually a set of content-based-routing rules combined with enrichments etc. Are any of the State Machine frameworks designed to support the actual messages containing the state. Or do we need to always consider a single authoritative source?
Thanks for your help and advice, this is an area I am very unfamiliar with at the moment, but quite interested in.
I will check out Apache ODE - and go back and look at jBPM again I think
Thanks
Neil
That's got me thinking about implementation in Einstein actually, the state machine could travel with the message in a message centric system, there's no reason why you cannot say (using JXPath, XPath or whatever) that this part of the message is the state to which this state machine applies so something like
state STOCK_ITEM "xpath://body/orderStatus" {
Ordered => Invoiced : { write to "http://myserver.com/InvoicingSystem" }
Invoiced => Dispatch : { ..... }
}
then as a message is processed in the system one can explicity associate a state machine
read from "jms://myExternalQueue";
apply STOCK_ITEM;
...
then later when the message is processed on this machine or another
transition Invoiced;
will trigger the action associated with the transition
transition Dispatched;
I'm sure this has all been done elsewhere, I've obviously got some reading to do as well, so if anyone could point me in the right direction I can see how best to apply this to Einstein .
I'll take another look at your ideas in Wsper also.
All the best
Neil
Neil: Your sample is right on, I can see (pre/post) actions being invoked. as you enter/exit a state. I can see a read that waits on a message. I did not see a reply. This is the kind of design decision you need to make on top of a pure FSM formalism. If you were to take BPEL as an implementation language you would obviously focus more on the messages (interactions) than the states, but nevertheless this is a perfectly good way to implement these state machines. You would get free persistence, correlation, exception handling... IBM and Microsoft have developed a transformation from State Machine definitions to orchestration languages such as BPEL.
thanks for your comments, I want to emphasize that the traditional state machine formalism is not linked to any kind of message passing. These formalisms were established for single process systems and for instance in UML an activity diagram can be formally transformed into a state machine diagram and vice versa (if I recall correctly).
Pi-calculus did represent a big step forward for "inter-acting" state machines, but as far as I can tell Robin Milner never went back and augmented the state machine formalism to handle message passing (I may be wrong).
This means that all bets are off to create a metamodel that enables state machines to receive messages. Passing the state machine instance around is good as long as the interactions are serialized, so it is not always possible to do that. There will be often the case when agents interact simultaneously with the same state machine. Some particular problem might be solved that way, but I am not sure this is a general design.
UML an activity diagram can be formally transformed into a state machine diagram and vice versa (if I recall correctly)
yep they are interchangeable.pi-calculus did represent a big step forward for "inter-acting" state machines, but as far as I can tell Robin Milner never went back and augmented the state machine formalism to handle message passing (I may be wrong).
I'm glad you can follow PI calculus, I never finished my Computer Science degree so it still remains a tad impenetrable to me, I have a nice book on it full of squirly symbols - I'm hoping one day I'll understand what it all means.Passing the state machine instance around is good as long as the interactions are serialized, so it is not always possible to do that.
Einstein follows some of Erlangs design decisions (not all, but that's a long story) so a message is never shared and therefore since the message is holding the state, the state is never shared. So when it's state transitions you would actually be getting a new message, so if two different execution threads tried to update a message they'd produce two new messages rather than mutating a single message. Again this is Erlangs's immutability principle to avoid concurrency issues. Of course this makes sense, you would never want to have two simultaneous state transitions for a message - unless you like crazily non deterministic systems. IBM and Microsoft have developed a transformation from State Machine definitions to orchestration languages such as BPEL.
That's interesting in itself and something I'll look for. So it sounds like BPEL is the most message oriented, great I'll focus some more time there. It's way too XML centric for me to use verbatim, and Einstein is designed to understand any data type whether XML, CSV, Object, String etc. but I can at least learn from it's design.
Thanks as ever Jean-Jacques you're a great help.
Neil
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
6 comments
Watch Thread Reply