Cory, As far as the IL is concerned, the Map data is completely opaque. The data in the map is interpreted only by the BPEL engine. The BPEL engine will only place native Java types like String/Number in the map.
-Maciej On Mon, 2006-06-05 at 12:54 -0600, 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 > > > > > > > > > > > > > > >
