Cory,
Looks like BpelEngine is missing the following method:
/**
* Call-back to the engine used by the [EMAIL PROTECTED] Scheduler}
implementation
* for executing scheduled jobs.
* @param jobId job identifier returned by the [EMAIL PROTECTED]
Scheduler}.scheduleXXX
* methods.
* @param jobDetail job details as passed in to the
* [EMAIL PROTECTED] Scheduler}.scheduleXXX methods
*/
void onScheduledJob(String jobId, Map<String, Object> jobDetail);
On Mon, 2006-06-05 at 13:12 -0600, cory wrote:
> Okay that makes sense, so the BPEL engine calls scheduleJob with he
> opaque data. When the IL Scheduler implementation fires a job what
> does the IL call to pass the opaque data back into the BPEL engine?
>
> Thanks.
>
> -cory
>
> On 6/5/06, Maciej Szefler <[EMAIL PROTECTED]> wrote:
> > 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
> > > > > > >
> > > > >
> > > > >
> > > >
> > > >
> >
> >
