Yeah, but I'm a bit afraid to make the scheduling part of the engine, given the availability of this functionality on the app server through J2EE WorkManager and stand-alone via Quartz. -mbs
On Mon, 2006-06-05 at 21:08 +0200, Guillaume Nodet wrote: > One of the problem is that it will once more create the need for the IL to > have a persistence framework, which duplicates the one the engine will > use internally. > > Cheers, > Guillaume Nodet > > cory wrote: > > > Hi Maciej, > > > > In the scheduleJob methods there is a "when" parameter which would be > > the deadline-valued or duration-valued expression of the time based > > activity and the "jobDetail" parameter would contain the needed > > information for the Scheduler to call back to the process that > > scheduled that time based event. If the IL is implementing the > > Scheduler what is the contract between the BPEL engine and the IL with > > regards to what the BPEL engine puts in the Map<String,Object>? > > > > Thanks. > > > > -cory > > > > On 6/5/06, Maciej Szefler <[EMAIL PROTECTED]> wrote: > > > >> Lance, > >> > >> On Mon, 2006-06-05 at 09:44 -0600, Lance Waterman wrote: > >> > Maciej, > >> > > >> > So what I hear you saying is that sometimes > >> > PartnerRoleMessageExchange.reply(Message) behaves as a "setter" and > >> > sometimes it behaves identical to > >> > MyRoleMessageExchange.invoke(Message). And this behavior is predicated > >> > on what order the client calls the .replyXXX() methods. > >> This characterization is in line with my expectation of the > >> implementation, however I would not go so far as to say that this is an > >> absolute requirement. For example, in the asynchronous response case, it > >> is possible for the engine to implement replyXXX() as simply setting > >> some fields in the db and scheduling a separate thread to execute the > >> process, and immediately returning to the IL. > >> > >> > In either case it appears to me that the IL controls thread resources > >> > and I don't see the engine doing any type of thread acquisition. > >> > Given an IL thread, the engine simply executes a process instance > >> > until there is nothing left to do for that given thread/message. > >> > That's not to say more than one IL thread may be required to complete > >> > the process. Is this your understanding? > >> The IL controls thread resources, but the Scheduler interface allows the > >> BPEL engine to create threads indirectly. So it is not necessary that > >> processing of the instance occur only in the .invoke > >> and .replyXXX methods (in fact things like <wait> and timeouts preclude > >> this). However, in all cases the threads that do the processing are > >> created by the IL. > >> > >> -maciej > >> > >> > >> > Lance > >> > > >> > On 6/1/06, Maciej Szefler <[EMAIL PROTECTED]> wrote: > >> > To the engine replyAsync means: > >> > "Integration layer here, I know you (Bpel engine) asked me to > >> > invoke a > >> > two way (sychronous) operation on the partner, but as it > >> > happens, I > >> > can't get the answer from him just this moment, but I will > >> > provide it to > >> > you as soon as I have it --- trust me -- and don't wait up it > >> > may be a > >> > while, I don't want to leave you (or your transaction) > >> > hanging. When I > >> > do get it, I'll tell you about it by calling the > >> > PartnerRoleMessageExchange.replyXXX (...) method. > >> > > >> > As Assaf points out the idea of synchronous operations is a > >> > bit > >> > slippery. If you have request/response operations mapped on > >> > any sort of > >> > reliable transport (such as JMS or WS-RM) you need a way to > >> > break up the > >> > invocation into two phases. > >> > > >> > -mbs > >> > > >> > On Thu, 2006-06-01 at 13:24 -0600, Lance Waterman wrote: > >> > > I agree the problem is confusing and I understand the > >> > distinctions. What I'm > >> > > trying to understand is what this "hint" means to the > >> > engine. For the case > >> > > we are talking about it appears that a logical service > >> > interface is > >> > > advertising the fact that it is a request/response ( an > >> > <invoke>, however > >> > > this "hint" seems to imply the engine should really treat > >> > this as a ( > >> > > oneway <invoke> with <receive> ) and hence my questions > >> > about what the API > >> > > is doing. ( Is the engine polling for the response? Why not > >> > just block for > >> > > the response? ). > >> > > > >> > > Lance > >> > > > >> > > On 6/1/06, Assaf Arkin <[EMAIL PROTECTED]> wrote: > >> > > > > >> > > > This is probably the most confusing part of messaging. > >> > > > > >> > > > When you're doing a synchronous (request/response) > >> > operation using an > >> > > > asynchronous (JMS) API, that communicates on a synchronous > >> > (TCP) > >> > > > protocol which passes packes on an asynchronous (IP) > >> > protocol. > >> > > > > >> > > > Is it synchronous or asynchronous? > >> > > > > >> > > > Turns out it's never "synchronous all the way down" (or > >> > > > asynchronous). It depends on which layer of the stack > >> > you're looking > >> > > > for. > >> > > > > >> > > > In BPEL you distinguish between a two-way operation > >> > (invoke, or > >> > > > receive/reply) and two separate one-way operations > >> > (invoke/receive, or > >> > > > receive/invoke). > >> > > > > >> > > > The bus (going back to our favorite topic) is where the > >> > one-way > >> > > > operation gets carried by a synchronous protocol, or the > >> > two-way > >> > > > operation by an asynchronous protocol, or any other > >> > combination. > >> > > > > >> > > > The only requirement on the engine is that it can support > >> > the two > >> > > > operation MEPs, without imposing a protocol selection on > >> > the bus, to > >> > > > allow for reasonable combinations. > >> > > > > >> > > > Assaf > >> > > > > >> > > > > >> > > > On 6/1/06, Lance Waterman <[EMAIL PROTECTED]> > >> > wrote: > >> > > > > So the "hint" means the engine needs to poll the > >> > MessageExchange to find > >> > > > out > >> > > > > when the response is there? > >> > > > > > >> > > > > When does the burden of modeling an async pattern fall > >> > to the process > >> > > > > designer and/or service designer? Where BPEL allows for > >> > this to be > >> > > > > explicitly modeled as ( oneway <invoke> plus > >> > <receive> )? > >> > > > > > >> > > > > Lance > >> > > > > > >> > > > > > >> > > > > On 6/1/06, Maciej Szefler <[EMAIL PROTECTED]> wrote: > >> > > > > > > >> > > > > > These are "setters". The engine will expect one of > >> > them to be called. > >> > > > > > replyAsync is a "hint" for the engine that is used in > >> > the case when a > >> > > > > > synchronous operation is implemented by the > >> > integration layer in such > >> > > > a > >> > > > > > way such a way that the response is not immediately > >> > available. This > >> > > > > > would happen in at least two scenarios: > >> > > > > > 1) request / reply are delivered using a transactional > >> > transport such > >> > > > as > >> > > > > > JMS. > >> > > > > > 2) integration layer is an asynchronous bus. > >> > > > > > -mbs > >> > > > > > > >> > > > > > On Thu, 2006-06-01 at 09:09 -0600, Lance Waterman > >> > wrote: > >> > > > > > > So should the the .reply*() methods on > >> > PartnerRoleMessageExchange be > >> > > > > > viewed > >> > > > > > > as setters or callbacks? Is the expectation that the > >> > engine calls > >> > > > > > > MessageExchangeContext.invokePartner() the call > >> > returns and then the > >> > > > > > engine > >> > > > > > > checks status PartnerRoleMessageExchange.getStatus() > >> > for a response? > >> > > > Or > >> > > > > > is > >> > > > > > > the expectation that > >> > PartnerRoleMessageExchange.reply (Message) is > >> > > > > > > implemented as a callback such that it has hooks > >> > into the process > >> > > > engine > >> > > > > > to > >> > > > > > > start "phase 2 invoke" and anything after? > >> > > > > > > > >> > > > > > > Thanks, > >> > > > > > > > >> > > > > > > Lance > >> > > > > > > > >> > > > > > > On 5/31/06, Guillaume Nodet > >> > <[EMAIL PROTECTED]> wrote: > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > Lance Waterman wrote: > >> > > > > > > > > >> > > > > > > > > Thanks guys, I like this API. A couple of > >> > questions: > >> > > > > > > > > > >> > > > > > > > > 1) Not quite sure I follow how " > >> > > > > > PartnerRoleMessageExchange.replyAsync()" > >> > > > > > > > > works? This seems to imply the partner is > >> > dynamically changing > >> > > > the > >> > > > > > > > > signature > >> > > > > > > > > of the service interface. > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > I guess it does not mean that the response will be > >> > provided with a > >> > > > > > > > callback, but rather > >> > > > > > > > that the underlying transport is asynchronous and > >> > that the > >> > > > response is > >> > > > > > > > not available at the > >> > > > > > > > moment. This may happen when using JMS for > >> > example. If using > >> > > > JMS, > >> > > > > > > > synchronous > >> > > > > > > > transactional request / response is not possible, > >> > because the > >> > > > request > >> > > > > > > > can only be received > >> > > > > > > > when the transaction is commited. > >> > > > > > > > From my understanding, when the BPEL engine > >> > invokes a partner, you > >> > > > > > have > >> > > > > > > > to call one > >> > > > > > > > of the method defined on > >> > PartnerRoleMessageExchange. If you call > >> > > > > > > > replyAsync, it > >> > > > > > > > just means that you will have to call another > >> > method later when > >> > > > the > >> > > > > > > > response is received. > >> > > > > > > > > >> > > > > > > > > 2) MyRoleMessageExchange.setClientData() - is > >> > this used to set > >> > > > > > > > > "out-of-band"/partnerLink data ( i.e. EPR,JMS > >> > properties, etc ... > >> > > > )? > >> > > > > > I > >> > > > > > > > can > >> > > > > > > > > get to this data from within a BPEL process > >> > using partnerLink in > >> > > > a > >> > > > > > > > <from> > >> > > > > > > > > clause - correct? > >> > > > > > > > > >> > > > > > > > I think this was one of my concern. If the > >> > integration layer > >> > > > receives > >> > > > > > a > >> > > > > > > > request from jms for example, > >> > > > > > > > it may need to store the replyTo jms destination > >> > in a reliable way > >> > > > so > >> > > > > > > > that when the process response > >> > > > > > > > is available, the integration layer can retrieve > >> > it to send the > >> > > > > > response > >> > > > > > > > (this would also be the case > >> > > > > > > > for JBI). I thought it would be easier to put > >> > the burden of > >> > > > storing > >> > > > > > > > this data to the bpel engine rather > >> > > > > > > > than on the integration layer, because the bpel > >> > engine already > >> > > > needs > >> > > > > > to > >> > > > > > > > store data, so it's just > >> > > > > > > > another field to store. > >> > > > > > > > > >> > > > > > > > > 3) I'm trying to correlate how an EPR fits into > >> > deployment. I'm > >> > > > > > assuming > >> > > > > > > > > that the EPR required for > >> > BpelEngine.createMessageExchange() is > >> > > > > > > > > produced/queried by deploying a BPEL document. > >> > The deployment > >> > > > API > >> > > > > > > > > produces > >> > > > > > > > > an EPR for each registered BPEL <process> > >> > definition. In your > >> > > > API it > >> > > > > > > > > looks > >> > > > > > > > > like you have a stub for deployment > >> > "BpelServer.deploy()" that > >> > > > > > returns a > >> > > > > > > > > QName. Is the assumption that the client > >> > translates the QName > >> > > > into > >> > > > > > an > >> > > > > > > > > EPR? > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > Maybe one thing missing / implied, is that the > >> > deployment API is > >> > > > > > > > reponsible for > >> > > > > > > > creating EPR for all receive operations (my role) > >> > and invoke > >> > > > > > operations. > >> > > > > > > > Else I do not really see how the BPEL engine could > >> > know the EPR to > >> > > > use > >> > > > > > > > when invoking a partner, how to process the > >> > > > > > BpelEngine.isMyRoleEndpoint > >> > > > > > > > or how to route the message to the right BPEL > >> > process when using > >> > > > the > >> > > > > > > > BpelEngine.createMessageExchange. > >> > > > > > > > > >> > > > > > > > And I still do not understand why the operation > >> > name is the only > >> > > > > > > > attribute available > >> > > > > > > > on message exchange. Either put all attributes in > >> > the EPR or put > >> > > > all > >> > > > > > > > available > >> > > > > > > > attributes on the exchange (imho we should at > >> > least have the > >> > > > PortType > >> > > > > > > > QName). > >> > > > > > > > > >> > > > > > > > Cheers, > >> > > > > > > > Guillaume Nodet > >> > > > > > > > > >> > > > > > > > > > >> > > > > > > > > Lance > >> > > > > > > > > > >> > > > > > > > > On 5/25/06, Matthieu Riou > >> > <[EMAIL PROTECTED]> wrote: > >> > > > > > > > > > >> > > > > > > > >> > >> > > > > > > > >> Hi all, > >> > > > > > > > >> > >> > > > > > > > >> I've just imported the revised version of the > >> > integration API > >> > > > > > > > >> specified by Maciej (if somebody with the > >> > necessary karma reads > >> > > > > > this, > >> > > > > > > > >> Maciej's CLA has been received but he's the > >> > last one without an > >> > > > > > > > >> account) for review. He also brushed up the > >> > javadoc. > >> > > > > > > > >> > >> > > > > > > > >> Comments are welcome (even just to say "Good > >> > job Maciej!" :-) > >> > > > ). > >> > > > > > > > >> > >> > > > > > > > >> Cheers, > >> > > > > > > > >> > >> > > > > > > > >> Matthieu. > >> > > > > > > > >> > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > >> > > > > > > >> > > > > > >> > > > > > >> > > > > >> > > > > >> > > > -- > >> > > > CTO, Intalio > >> > > > http://www.intalio.com > >> > > > > >> > > >> > > >> > >> > > > >
