BT

Object Lifecycle Explorer Released on AlphaWorks

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:

  • enable modeling and visualization
  • extract object lifecycle from business process models
  • check the consistency of process models against the object lifecycles to detect non-conformant state changes
  • generate a process model from an object lifecycle

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.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

References by Neil Ellis

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

Re: References by Jean-Jacques Dubray

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 !

Re: References by Neil Ellis

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

Re: References by Neil Ellis

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

Re: References by Jean-Jacques Dubray

Neil:



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.


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.

Re: References by Neil Ellis

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

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

6 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT