Maciej,
Thanks for clearing things up however, I'm still a bit confused by #1. Let
me ask the question in another way. Looking at the following method in
BpelRuntimeContextImpl ...
private void initVPU() {
vpu = new JacobVPU();
vpu.registerExtension(BpelRuntimeContext.class, this);
soup = new FastSoupImpl(null);
soup.setReplacementMap(_bpelProcess._replacementMap);
vpu.setContext(soup);
}
Why does the BpelRuntimeContext need to register itself with the VPU ( "
vpu.registerExtension(BpelRuntimeContext.class, this);")?
Lance
On 6/29/06, Maciej Szefler <[EMAIL PROTECTED]> wrote:
On Thu, 2006-06-29 at 09:07 -0600, Lance Waterman wrote:
> Yes, I found the the documentation very helpful. I would like to ask a
> couple of detail questions around persistence.
>
> 1) I would like to understand the purpose of the following method found
in
> the "BpelAbstraction" class:
>
> protected BpelRuntimeContext getBpelRuntimeContext() {
> BpelRuntimeContext nativeApi = (BpelRuntimeContext)
> JacobVPU.activeJacobThread().getExtension(BpelRuntimeContext.class);
> assert nativeApi != null;
> return nativeApi;
> }
>
Jacob knows nothing about BPEL. This is a mechanism to obtain an
interface that allows the instance to interact with the BPEL engine
facilities (such as external communication and data access).
> and then from the JacobThread interface ...
>
> /**
> * DOCUMENTME
> *
> * @param extensionClass DOCUMENTME
> *
> * @return DOCUMENTME
> */
> public Object getExtension(Class extensionClass);
>
> Does registering the process context with the VPU tie the process
context to
> the Soup frame ( i.e. FastSoupImpl.ChannelFrame ) in some way or is this
> just utilizing the JacobVPU singleton?
> 2) For a BPEL process, will there ever be a case where reactions remain
in
> the Soup queue at the time Soup.write() is called? If I am thinking
about
> this correctly there should only be objects in the channel frame and
object
> frame?
Your understanding is mostly correct. The only time this happens in the
PXE engine right now is if the processing of an instance takes
inordinately long. This will happen if the process has an endless loop
in it (typically a <While> with a bad condition).
>
> 3) Why are outstanding BPEL requests persisted into the Soup ( i.e.
> soup.setGlobalData(_outstandingRequests); )? These seem to be BPEL
> correlation specific artifacts and I don't understand why they need to
be
> part of the VPU?
This is a bit of hack to allow global instance-level data to be stored
without extending the DAO layer. The VPU does not actually interpret the
outstandingRequest object it just stores it along with the rest of the
execution state.
> Alex - I would like to walk through the code that hooks the JACOB engine
> into the iapi and then after that perhaps we can have an IRC around what
the
> build should look like for the ODE trunk? On a side note - I'd like to
post
> some deployment documents to the Wiki and check in some code to the
scratch
> area. I believe I have an Apache user account but I have not seen
anything
> about a password - do you know how to acquire a password?
>
> Thanks,
>
> Lance
>
>
>
>
> On 6/28/06, Alex Boisvert <[EMAIL PROTECTED]> wrote:
> >
> >
> > Oh and by the way, was the Jacob documentation helpful? What's the
next
> > step there?
> >
> > alex
> >
> >
> > Lance Waterman wrote:
> > > Alex,
> > >
> > > I have been reading through the JACOB documentation on the Wiki and
I
> > > think
> > > I'm at the point where #3 would be helpful. Could you move this into
the
> > > scratch area where we can begin to walk through it?
> > >
> > > Thanks,
> > >
> > > Lance
> > >
> > > On 6/15/06, Alex Boisvert <[EMAIL PROTECTED]> wrote:
> > >>
> > >>
> > >> Speaking of status, here's my understanding of ongoing work:
> > >>
> > >> 1) Maciej is working on providing detailed description for the
> > scenarios
> > >> identified by Cory. This is a necessary step to continue the
> > discussion
> > >> on the Jacob module.
> > >>
> > >> 2) Lance, Paul and Zubin are working on the Deployment API and
> > >> relationship to the proposed Integration API.
> > >>
> > >> 3) There's ongoing work for retooling PXE with the proposed
Integration
> > >> API, which provides validation of its semantics and real-world use,
as
> > >> well as tangible progress towards our roadmap. This has happened
> > >> outside of the incubator initially because of access rights issue
which
> > >> I think are now resolved. So I'd like to know if there's interest
for
> > >> moving this into the incubator now.
> > >>
> > >> Anything else that I'm missing? It would be good to hear from
people
> > to
> > >> know what's going on on a more regular basis <nudge! nudge!>
> > >>
> > >> It think we should have our next IRC session as soon as we have #1
from
> > >> Maciej above.
> > >>
> > >> alex
> > >>
> > >>
> > >> Matthieu Riou wrote:
> > >> > Perfect! I've just added a short sentence to reflect the
undergoing
> > >> > effort
> > >> > from Maciej and others to document PXE.
> > >> >
> > >> > On 6/14/06, Paul R Brown <[EMAIL PROTECTED]> wrote:
> > >> >>
> > >> >>
> > >> >> > Can someone please step up and help?
> > >> >>
> > >> >> Either I stepped up or everyone else stepped back... I put a
couple
> > >> >> of lines into the wiki about the work with the integration and
> > >> >> deployment APIs.
> > >> >>
> > >> >> ---
> > >> >> Paul R Brown
> > >> >> [EMAIL PROTECTED]
> > >> >> http://mult.ifario.us/
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >
> > >>
> > >>
> > >
> >
> >
> > --
> > Intalio :: The Business Process Management Company
> >
> >
> >
