outsider looking in I find the implementation hard to follow and its taking us some time to walk through it. Here is where we could use some help ( i.e. sequence diagrams - etc .. ):
Yes, I understand that, we'll have to document this to make it easier to grasp. The style of programming is a bit different but once you understand how it works, it becomes quite easy.
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, it's the abstraction level that implements the calculus model. It basically defines Abstraction (a process in calculus), Channel (for process communication), ML (sort of interfaces implemented by channels) and Reaction (basically a new process invocation). The soup also defines the whole environment in which this executes. Anyway what you'd probably be more interested in and could help you understanding how jacob works is its bpel implementation, the bpel-runtime module. If you have a look there all ACTIVITY implementations are abstractions (process in calculus). And their OModel representations are always passed to them upon creation. So the basic model walking occurs by having the structured activities trigger the execution of the activities they contain. Check the SEQUENCE activity. The self() method starts by creating a its first child activity. Then it creates an ACTIVE abstraction that just monitors children completion (an other events like termination or compensation). When a child completes, the completed method will be invoked, thanks to jacob, using the channels passed when the child ActivityInfo has been created. So when a child completes, our SEQUENCE.ACTIVE abstraction just instantiates a new SEQUENCE process. Which in turn executes the next child and an ACTIVE that will monitor this child. And so on... That's basically how the model is walked. But there's on trick left! BPEL's beloved links. So the trick here is that, if you check the createChild method used by SEQUENCE (line 42), it doesn't really create the child activity abstraction, it first creates a ACTIVITYGUARD abstraction. This guy is responsible for checking links. If there are no links, execution is strictly containment-based, so it just creates (line 59) the real child activity abstraction that was requested (btw it uses the ActivityTemplateFactory to match OActivity with ACTIVITY). If there are links, then these are computed and followed appropriately.
2) How are messages/events correlated to an instance?
Check com.fs.pxe.bpel.runtime.BpelProcess.java:261 (PartnerLinkMyRoleImpl:inputMsgRcvd()). That's where the instance resolution happens. There's one thing that you'll need to know. It doesn't look for receive/pick activities. It looks for correlator. For performance reasons, before a receive/pick starts waiting for a message it creates a correlator, a simple data structure saying who is waiting for what. So the algorithm is to compute the correlation of the incoming message, find a correlator and you're done. Plus some additional createInstance logic.
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. Cheers, Matthieu.
Thanks, Lance On 5/10/06, Matthieu Riou < [EMAIL PROTECTED] > wrote: > Hi, > > In the process of building Ode block by block, I'd like to propose the > import of the Jacob "virtual machine" in Ode's trunk. > > We've had a pretty long discussion about the different possible models > (petri net vs pi-calculus) and even if probably both models are valid, > we already have a very good implementation of a pi-calculus that we > can use. As an example of its advantages, I've recently been able to > implement the forEach BPEL 2.0 activity in less than a week (including > testing and with only a bit more than a day spent on runtime). > > What do you think? > > Matthieu. >
