[bpel-dev] Recipe for "BPEL Model maintaining DOM Tree"

[Simon D Moser <SMOSER@xxxxxxxxxx>]

Hi all

first of all, I'd like to state that today we checked in a model and editor
code today that now supports "If-Else" instead of "Switch" !! Yipiee, one
step closer to 2.0 compliance ;-)

Besides, in the last call, I promised to provide a recipe on how to
maintain the DOM Tree in the BPEL model, since most likely me and my team
won't be able to do that ourselves.
Note that this is not intended as a step-by-step instruction, but rather as
a conceptual guideline.

The way it works now (where the DOM Tree isn't maintained in the BPEL
model)

1. BPELReader asks Xerces to parse the bpel file into a DOM tree.
2. BPELReader walks that DOM tree and at each node, constructs the
appropriate BPEL EMF model objects.
3. BPEL reader then throws the DOM tree away and returns the BPEL EMF model
objects
4. BPELWriter receives the BPEL EMF model obects, and creates a dOM tree by
walking the BPEL model and constructing the appropriate nodes, and writes
them to disk.

As we all know, this approach has problems:
a.) What if the user has formatted his bpel file? Inserted XML comments?
Right now, we lose all of that information when we re-write it, since we
didn't keep around the DOM tree, which had all that information.
b.) It means that writing *can* be expensive, in theory, since we have to
walk the whole model and reconstruct DOM elements. In practice this isn't a
big deal.

The alternative approach, which is how the WSDL model works, is as follows:

5. BPELReader asks Xerces to parse the bpel file into a DOM tree.
6. BPELReader walks that DOM tree and at each node, constructs the
appropriate BPEL EMF model objects AND stores the DOM node with that BPEL
EMF object. This means each BPEL model object has a slot for a DOMElement.
See the class WSDLElement in the wsdl model for how they do this.
7. BPELReader then returns the BPEL EMF model objects, but the DOM hasn't
been thrown away.
8. The user makes some changes to the BPEL file. This may involve calling,
for example, Activity.setName(). When this happens, we do two things: We
set the name slot in the activity (which is what we do today), but we also
cause the DOM element to get updated. In this case, the DOM element's
"name" attribute should get its value changed.
9. BPELWriter receives the BPEL EMF model objects. To save it, we already
have the DOM element, so it's as simple as dumping the DOM tree to disk.
Done.

In practice, what this means is the following. In BPELReader and BPELWriter
there are pairs of methods. For example, xml2Receive in BPELReader, and
receive2XML in BPELWriter. Those two methods will get removed from
BPELReader and BPELWriter, and inserted into e.g. ReceiveImpl.

That means e.g. ReceiveImpl now knows how to do two things:
1. React to changes to its EMF state by updating the DOM, and
2. React to changes to the DOM by updating its EMF state. Basically, we've
pushed the reader and writer functionality into the nodes.

Actually, the more I think about statement 6 above, it might not be fully
true:  When maintaining the DOM tree, the BPELReader won't really walk the
DOM tree at all - he just takes the first DOM element, which is a <process>
element, and creates a ProcessImpl from it, and passes the DOM node to the
ProcessImpl. Then the process impl handles everything else, since all the
code that used to be in xml2Process now lives in ProcessImpl.

In other words, this is just a large refactoring, and basically doesn't
involve much new code, because it already exists in BPELReader and
BPELWriter, spreading the work out across all the impl objects.
So we need to introduce a new field in whatever the supertype is for all
these BPEL objects, to store the DOM element, move all the methods onto the
objects and make sure you call them whenever the DOM or the EMF state
changes.
BPELReader and BPELWriter will become very small.

HTH - talk to you tonight!

Cheers
/Simon
--------------------------------------------------
Simon Daniel Moser, M.Eng.
Business Process Solutions Development 1
IBM Boeblingen Laboratory
Schoenaicherstr. 220, 01/086
D - 71032 Boeblingen
Tel.: +49 - 7031 - 164304
IP Telephone Number (ITN): 39204304
email: smoser@xxxxxxxxxx

Rule of thumb #3459835478: when you find yourself typing/copying the same
thing more than twice in a row, redesign or re-implement. No excuse
possible.