Hi John, ODE compiles BPEL into an internal object model which is then serialized into the cbp-file. This has two reasons: a) the compiled model is immutable, thus ODE can be sure that the model has not changed since the deployment, b) loading the serialized form is faster then re-parsing the XML. In addition, the compiler adds some optimizations, for instance the receive activity is translated to a pick with a single onMessage element, which is semantically equivalent. Thus, the runtime does not need to provide a special treatment for the receive activity.
If you want to dive into the code, then have a look at the bpel-compiler module, which contains the BPEL parser, a version agnostic object model and the compiler which provides the translation logic. The bpel-obj module contains the so called OModel. The compiler produces instances of that OModel and serializes it to cbp files. HTH, Tammo On Sun, Mar 30, 2014 at 4:31 PM, 聶 佳 <qynn...@gmail.com> wrote: > Good Morning Sir, > > I am a student in PKU and I’m topic researching is about > requirement traceability, Now I’m focusing on the trace on bpel. I choose > the Ode as the engine, I wanna know about more details about both how .cbp > file be compiled and be used at runtime, I just can’t understand the .cbp > byte code. This will be great help for my researching and I’m looking for > some help. Thank you all the way. > > — > best regards, > John > > -- Tammo van Lessen - http://www.taval.de
