Don't most timer services have their own persistence mechanism? Not sure how to get away from the duplication problem.
Lance On 6/5/06, Guillaume Nodet <[EMAIL PROTECTED]> 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 >> > > > >> > >> > >> >> > >
