Bruce Lowery - 2004-12-03

In the current JEgg implementation an active object, or egg, is composed mostly of "handle"  methods that the framework uses to deliver messages to the object. 

It's easy to view each message as an event, or stimulus, that triggers a transition in the egg's state machine.  However, like all classes coded in Java (or C++, etc) the class' state machine is completely buried in the code. 

Although we have all learned to live with this, those of us who have been fortunate enough to develop serious software using tools that support state machine based development realize that it can be very effective.

For a while I've been thinking about a way to effectively represent an egg's state machine to the framework.  This would do two things:  (1) allow the framework to enforce the state machine, and (2) make explicit an egg's logic which would facilitate maintenance and further development.

An important consequence of (1) is that potentially a lot of error handling code could be avoided for each egg since the framework would disallow incoming messages when the egg is in the wrong state - the egg wouldn't have to have code protect against this. 

Unfortunately, there aren't a lot of ways to tackle this problem.  Some of the approaches I've ruled out:

(a)  Invent a FSM language and generate Java using a code generator.

(b)  Invent a graphical tool for use in designing the state machine, and let the tool generate the Java.

(c)  Represent the state machine directly in Java using special constructs and/or classes, etc.

The approach I am considering, though is:

For each egg, represent it's state machine in XML and let the framework use the XML-based description to build an internal representation of the egg's state machine.

For instance:

<egg name="portManager">
   <state name="TOP">

      <state name="INIT">
         <transition event="Port"/>
         <transition event="LocalAddress" to="OPEN" />
      </state>

      <state name="OPEN">
         <onEntry> openNewPort </onEntry>
         <transition event="AcceptClient" />
         <transition event="ClosePort" to="INIT" />
      </state>

   </state>
</egg>

The only things that correspond to actual Java classes that you'd write as part of your egg are the values of the event attributes in the transitions.  These are the names of the Java classes for which the specified egg (named 'portManager' above) has 'handle' methods.

This is a very simple example but it illustrates the idea.  Using the XML description, the framework would internally build a state machine internally for the "portManager" egg and use that state machine to decide whether or not a given message is allowed to be delivered to the egg.

There are things that I don't like about what I've outlined above. 

For instance, both the state machine description and the Java implementation of the egg are necessary in order to understand how the egg functions, but they are maintained in separate files, of different types, so getting out-of-sync over time could be a real danger.

JEgg already makes use of reflection (which is obviously slower than otherwise) to deliver messages, and reflection would also be necessary to "execute" the egg's state machine for an egg.

However, despite its short comings, this is the most painless mechanism I've yet considered for representing an egg's state chart and integrating it with the JEgg framework without requiring special tools like code generators, preprocessors or GUI designers.

I'm not aiming for something every elaborate - I believe this is a case where a little bit can go a long way.  But, I would like to hear opinions or other suggestions.  I'm not interested in putting effort into something that can be shown to be likely to be a dead end, and there are surely approaches that I haven't considered

Please feel free to comment.

--bruce