I'll try to add some bits here: > > 1) How does the Jacob engine walk the OModel? > > Well, it doesn't really 'walk' the OModel, it's more like a > peer-to-peer interaction. First, the Jacob engine doesn't do anything, Matthieu covers a lot of low-level ground here, so I'll try to give a higher level picture: The O-model is just a normalized, static description of the process, much like the original BPEL document (for differences see next question). It contains no execution logic. All execution logic is contained in the bpel-runtime classes (the ones that are named in all caps). The runtime classes (such as PROCESS/SEQUENCE/FLOW, etc..) encapsulate the BPEL behavior and are implemented in terms of JACOB primitives. They are parameterized by the O-model objects (e.g. the PROCESS is parameterized by an OProcess object). The 'walking' of the object model is best demonstrated by an examples.
The SCOPE class implements the behavior of a BPEL <scope> which is (roughly speaking) to execute the one activity. The SCOPE class consults the OScope object it was instantiated with to find what the activity is. Lets say it was a <flow>: this means that OScope contains a reference to an OFlow object, so the SCOPE class creates a new FLOW class parameterized with an OFLow object. This is how the 'walking' is done. > > > 3) When you moved the parser/BOM into the trunk I asked as couple of > > questions and I think they may have fallen out of view. In particular I > > would like to understand the purpose of the BOM ( i.e. why not parse > > directly into the OModel )? > > Not sure about that, there might be historical reasons that I'm not > aware of. I'll try to see this with Maciej and will give you an > answer. The BOM is naive representation of the BPEL document. The use cases are BPEL Designer and pre-compilation. The O-model represents a valid process the use case is validation and execution. There are also structural difference between the two due to things like default compensation handlers, implicit scopes, differences between BPEL 1.1 and 2.0, various syntactic sugars. Also the O-Model "understands" BPEL scoping rules and reference resolution. The BOM was a necessary evil. BOM and bpel-parser do the job of XmlBeans. We did not use XmlBeans for only one reason: we wanted to support both the Bpel11 and Bpel20 schemas using the same object hierarchy. -mbs
