You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ode.apache.org by cory <co...@gmail.com> on 2006/06/01 00:34:38 UTC
Re: Integration API
Hello All,
See my comments below.
Cheers,
-cory
On 5/31/06, Guillaume Nodet <gu...@worldonline.fr> 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.
>
Is the PartnerRoleMessageExchange.replyAsync() call back needed? Is
it just a hint to the process that the transaction is going to be
committed in the middle of an out-in <invoke>?
What is driving the need for the MessageExchange stuff in the BPEL
engine API? Is it just the ability to implement synchronous
request/response operations asynchronously. We did spend sometime
thinking about this when building the BPE. We eventually decided that
this was provide for by a one-way <invoke> and a <recieve>. It feels
like some bus like functionality is creeping into the engine.
> > 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 <ma...@gmail.com> 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.
> >>
> >
>
Re: Integration API
Posted by cory <co...@gmail.com>.
Thanks for the replies and clearing this up for me. While looking at
the APIs, for some reason I started worrying about Ode becoming a bus,
sorry about that.
-cory
On 6/1/06, Assaf Arkin <ar...@intalio.com> wrote:
> On 6/1/06, cory <co...@gmail.com> wrote:
> > Hi Assaf,
> >
> > I think I understand what you are saying. BPEL is for orchestrating
> > web services, and it seems natural for a BPEL engine to take on the
> > responsibility of managing the MEPs. So a BPEL engine is a bus?
>
> If I receive a request, do something with it, and then send back a
> response, I'm "managing" the MEP lifecycle. I get to decide when the
> MEP ends and how to end it.
>
> I think managing that part of the MEP lifecycle is the responsibility
> of engines deployed on the bus, but is not itself a bus. A bus moves
> messages from one place to another, it allows you to deploy multiple
> engines.
>
> When you get to deploying engines, connectors, transports, etc you
> have a bus. If you just get to do very basic MEP lifecycle management,
> you can pick and choose a lot of different buses, since all you're
> asking them is to move messages around.
>
> > What I'm trying to get at is a question to everyone: Will Ode be a
> > bus? My assumption so far, which could be wrong, is that Ode is not
> > going to be a bus and would be pretty helpless stand alone.
>
> The requirements as far as I understand them:
> * We don't want to develop yet another bus, that's too much wasted effort.
> * We don't want to pick one bus, there's tradeoffs and it's easier if
> we let users pick and choose.
> * An engine is a barrier to entry, you need something you can download
> and run standalone with some bus before you can decide if you want to
> change buses.
>
> So it sounds like what we want is an API so we can build quick and
> simple adapters to different buses, and include one in the standalone
> download.
>
> Assaf
>
> >
> > -cory
> >
> > On 5/31/06, Assaf Arkin <ar...@intalio.com> wrote:
> > > A good bus is stateless and stupid, it just moves messages in and out.
> > >
> > > Since we already have persistence in the BPEL engine, we should use
> > > that instead of pushing it to the bus. There's an advantage to storing
> > > messages and MEPs in one place and only once.
> > >
> > > Having said that, I don't consider all possible MEP combinations to be
> > > interesting just because they can be done.
> > >
> > > JMS for reliable messaging (transactions, persistence) is best done as
> > > two separate one-way operations.
> > >
> > > There are some cases where JMS -- more specifically, some MOMs and
> > > backend combinations -- are used for synchronous operations because
> > > the MOM is used as the message bus and protocol abstraction.
> > >
> > > But these operations are synchronous, they don't occur in separate
> > > transactions (in fact, they don't use transactions are all), messages
> > > are not persisted, they only wait for the response so long and they
> > > fail like all other synchronous operations.
> > >
> > > Some practical restrictions are good in keeping to reasonable complexity.
> > >
> > > Assaf
> > >
> > >
> > > On 5/31/06, cory <co...@gmail.com> wrote:
> > > > Hello All,
> > > >
> > > > See my comments below.
> > > >
> > > > Cheers,
> > > >
> > > > -cory
> > > >
> > > > On 5/31/06, Guillaume Nodet <gu...@worldonline.fr> 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.
> > > > >
> > > >
> > > > Is the PartnerRoleMessageExchange.replyAsync() call back needed? Is
> > > > it just a hint to the process that the transaction is going to be
> > > > committed in the middle of an out-in <invoke>?
> > > >
> > > > What is driving the need for the MessageExchange stuff in the BPEL
> > > > engine API? Is it just the ability to implement synchronous
> > > > request/response operations asynchronously. We did spend sometime
> > > > thinking about this when building the BPE. We eventually decided that
> > > > this was provide for by a one-way <invoke> and a <recieve>. It feels
> > > > like some bus like functionality is creeping into the engine.
> > > >
> > > >
> > > > > > 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 <ma...@gmail.com> 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
> > >
> >
>
>
> --
> CTO, Intalio
> http://www.intalio.com
>
Re: Integration API
Posted by Assaf Arkin <ar...@intalio.com>.
On 6/1/06, cory <co...@gmail.com> wrote:
> Hi Assaf,
>
> I think I understand what you are saying. BPEL is for orchestrating
> web services, and it seems natural for a BPEL engine to take on the
> responsibility of managing the MEPs. So a BPEL engine is a bus?
If I receive a request, do something with it, and then send back a
response, I'm "managing" the MEP lifecycle. I get to decide when the
MEP ends and how to end it.
I think managing that part of the MEP lifecycle is the responsibility
of engines deployed on the bus, but is not itself a bus. A bus moves
messages from one place to another, it allows you to deploy multiple
engines.
When you get to deploying engines, connectors, transports, etc you
have a bus. If you just get to do very basic MEP lifecycle management,
you can pick and choose a lot of different buses, since all you're
asking them is to move messages around.
> What I'm trying to get at is a question to everyone: Will Ode be a
> bus? My assumption so far, which could be wrong, is that Ode is not
> going to be a bus and would be pretty helpless stand alone.
The requirements as far as I understand them:
* We don't want to develop yet another bus, that's too much wasted effort.
* We don't want to pick one bus, there's tradeoffs and it's easier if
we let users pick and choose.
* An engine is a barrier to entry, you need something you can download
and run standalone with some bus before you can decide if you want to
change buses.
So it sounds like what we want is an API so we can build quick and
simple adapters to different buses, and include one in the standalone
download.
Assaf
>
> -cory
>
> On 5/31/06, Assaf Arkin <ar...@intalio.com> wrote:
> > A good bus is stateless and stupid, it just moves messages in and out.
> >
> > Since we already have persistence in the BPEL engine, we should use
> > that instead of pushing it to the bus. There's an advantage to storing
> > messages and MEPs in one place and only once.
> >
> > Having said that, I don't consider all possible MEP combinations to be
> > interesting just because they can be done.
> >
> > JMS for reliable messaging (transactions, persistence) is best done as
> > two separate one-way operations.
> >
> > There are some cases where JMS -- more specifically, some MOMs and
> > backend combinations -- are used for synchronous operations because
> > the MOM is used as the message bus and protocol abstraction.
> >
> > But these operations are synchronous, they don't occur in separate
> > transactions (in fact, they don't use transactions are all), messages
> > are not persisted, they only wait for the response so long and they
> > fail like all other synchronous operations.
> >
> > Some practical restrictions are good in keeping to reasonable complexity.
> >
> > Assaf
> >
> >
> > On 5/31/06, cory <co...@gmail.com> wrote:
> > > Hello All,
> > >
> > > See my comments below.
> > >
> > > Cheers,
> > >
> > > -cory
> > >
> > > On 5/31/06, Guillaume Nodet <gu...@worldonline.fr> 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.
> > > >
> > >
> > > Is the PartnerRoleMessageExchange.replyAsync() call back needed? Is
> > > it just a hint to the process that the transaction is going to be
> > > committed in the middle of an out-in <invoke>?
> > >
> > > What is driving the need for the MessageExchange stuff in the BPEL
> > > engine API? Is it just the ability to implement synchronous
> > > request/response operations asynchronously. We did spend sometime
> > > thinking about this when building the BPE. We eventually decided that
> > > this was provide for by a one-way <invoke> and a <recieve>. It feels
> > > like some bus like functionality is creeping into the engine.
> > >
> > >
> > > > > 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 <ma...@gmail.com> 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
> >
>
--
CTO, Intalio
http://www.intalio.com
Re: Integration API
Posted by Zubin Wadia <zw...@gmail.com>.
+1, a Slipn'Slide is needed to complement Ode. ;).
On 6/1/06, Alex Boisvert <bo...@intalio.com> wrote:
>
> cory wrote:
>
> > What I'm trying to get at is a question to everyone: Will Ode be a
> > bus? My assumption so far, which could be wrong, is that Ode is not
> > going to be a bus and would be pretty helpless stand alone.
>
> Our roadmap (http://wiki.apache.org/ode/RoadMap) says that we want to
> "... avoid introducing any external dependencies to any bus architecture
> or external protocols so that the core engine can be used by as many
> external projects as possible while avoiding unnecessary dependencies."
>
> I believe our goal with the Integration API (iapi) proposal is to enable
> integration with a bus (e.g. JBI) or directly to a single
> transport/binding component (e.g. JMS or SOAP/HTTP), or to a full-blown
> web service stack (e.g. Axis2), or to a component framework (e.g. SCA).
> For this to happen, the BPEL engine needs to be aware of MEPs and a few
> other integration details such as EPR resolution. If there is
> resemblance to any existing bus framework, it's because there's only so
> many ways you can abstract web services -- despite many attempts to the
> contrary ;)
>
> When I look at the iapi today, I do not see a way to directly connect
> Ode to multiple components. That would require a bus implementation to
> route messages to and from components back to Ode. So based on my
> understanding of the current iapi proposal, Ode would not be a bus.
>
> alex
>
>
>
>
Re: Integration API
Posted by Alex Boisvert <bo...@intalio.com>.
cory wrote:
> What I'm trying to get at is a question to everyone: Will Ode be a
> bus? My assumption so far, which could be wrong, is that Ode is not
> going to be a bus and would be pretty helpless stand alone.
Our roadmap (http://wiki.apache.org/ode/RoadMap) says that we want to
"... avoid introducing any external dependencies to any bus architecture
or external protocols so that the core engine can be used by as many
external projects as possible while avoiding unnecessary dependencies."
I believe our goal with the Integration API (iapi) proposal is to enable
integration with a bus (e.g. JBI) or directly to a single
transport/binding component (e.g. JMS or SOAP/HTTP), or to a full-blown
web service stack (e.g. Axis2), or to a component framework (e.g. SCA).
For this to happen, the BPEL engine needs to be aware of MEPs and a few
other integration details such as EPR resolution. If there is
resemblance to any existing bus framework, it's because there's only so
many ways you can abstract web services -- despite many attempts to the
contrary ;)
When I look at the iapi today, I do not see a way to directly connect
Ode to multiple components. That would require a bus implementation to
route messages to and from components back to Ode. So based on my
understanding of the current iapi proposal, Ode would not be a bus.
alex
Re: Integration API
Posted by Zubin Wadia <zw...@gmail.com>.
Cory,
I think Assaf is alluding to the Bus as still being required, but as a
pipeline. Let ODE be the enforcer as to what process-related messaging runs
through the bus. However, ODE is not the Bus itself.
Zubin.
On 6/1/06, cory <co...@gmail.com> wrote:
>
> Hi Assaf,
>
> I think I understand what you are saying. BPEL is for orchestrating
> web services, and it seems natural for a BPEL engine to take on the
> responsibility of managing the MEPs. So a BPEL engine is a bus?
>
> The MEP stuff in the proposed APIs kind of feels like JBI. Could Ode
> use the JBI APIs?
>
> If, for example, Ode with the proposed APIs is plugged into a JBI bus
> and ODE calls another service engine within the JBI bus, it could
> manage the MEPs between ODE and the service engine, but could not
> manage any other MEPs that that service engine was involved in?
>
> What I'm trying to get at is a question to everyone: Will Ode be a
> bus? My assumption so far, which could be wrong, is that Ode is not
> going to be a bus and would be pretty helpless stand alone.
>
> -cory
>
> On 5/31/06, Assaf Arkin <ar...@intalio.com> wrote:
> > A good bus is stateless and stupid, it just moves messages in and out.
> >
> > Since we already have persistence in the BPEL engine, we should use
> > that instead of pushing it to the bus. There's an advantage to storing
> > messages and MEPs in one place and only once.
> >
> > Having said that, I don't consider all possible MEP combinations to be
> > interesting just because they can be done.
> >
> > JMS for reliable messaging (transactions, persistence) is best done as
> > two separate one-way operations.
> >
> > There are some cases where JMS -- more specifically, some MOMs and
> > backend combinations -- are used for synchronous operations because
> > the MOM is used as the message bus and protocol abstraction.
> >
> > But these operations are synchronous, they don't occur in separate
> > transactions (in fact, they don't use transactions are all), messages
> > are not persisted, they only wait for the response so long and they
> > fail like all other synchronous operations.
> >
> > Some practical restrictions are good in keeping to reasonable
> complexity.
> >
> > Assaf
> >
> >
> > On 5/31/06, cory <co...@gmail.com> wrote:
> > > Hello All,
> > >
> > > See my comments below.
> > >
> > > Cheers,
> > >
> > > -cory
> > >
> > > On 5/31/06, Guillaume Nodet <gu...@worldonline.fr> 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.
> > > >
> > >
> > > Is the PartnerRoleMessageExchange.replyAsync() call back needed? Is
> > > it just a hint to the process that the transaction is going to be
> > > committed in the middle of an out-in <invoke>?
> > >
> > > What is driving the need for the MessageExchange stuff in the BPEL
> > > engine API? Is it just the ability to implement synchronous
> > > request/response operations asynchronously. We did spend sometime
> > > thinking about this when building the BPE. We eventually decided that
> > > this was provide for by a one-way <invoke> and a <recieve>. It feels
> > > like some bus like functionality is creeping into the engine.
> > >
> > >
> > > > > 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 <ma...@gmail.com> 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
> >
>
Re: Integration API
Posted by cory <co...@gmail.com>.
Hi Assaf,
I think I understand what you are saying. BPEL is for orchestrating
web services, and it seems natural for a BPEL engine to take on the
responsibility of managing the MEPs. So a BPEL engine is a bus?
The MEP stuff in the proposed APIs kind of feels like JBI. Could Ode
use the JBI APIs?
If, for example, Ode with the proposed APIs is plugged into a JBI bus
and ODE calls another service engine within the JBI bus, it could
manage the MEPs between ODE and the service engine, but could not
manage any other MEPs that that service engine was involved in?
What I'm trying to get at is a question to everyone: Will Ode be a
bus? My assumption so far, which could be wrong, is that Ode is not
going to be a bus and would be pretty helpless stand alone.
-cory
On 5/31/06, Assaf Arkin <ar...@intalio.com> wrote:
> A good bus is stateless and stupid, it just moves messages in and out.
>
> Since we already have persistence in the BPEL engine, we should use
> that instead of pushing it to the bus. There's an advantage to storing
> messages and MEPs in one place and only once.
>
> Having said that, I don't consider all possible MEP combinations to be
> interesting just because they can be done.
>
> JMS for reliable messaging (transactions, persistence) is best done as
> two separate one-way operations.
>
> There are some cases where JMS -- more specifically, some MOMs and
> backend combinations -- are used for synchronous operations because
> the MOM is used as the message bus and protocol abstraction.
>
> But these operations are synchronous, they don't occur in separate
> transactions (in fact, they don't use transactions are all), messages
> are not persisted, they only wait for the response so long and they
> fail like all other synchronous operations.
>
> Some practical restrictions are good in keeping to reasonable complexity.
>
> Assaf
>
>
> On 5/31/06, cory <co...@gmail.com> wrote:
> > Hello All,
> >
> > See my comments below.
> >
> > Cheers,
> >
> > -cory
> >
> > On 5/31/06, Guillaume Nodet <gu...@worldonline.fr> 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.
> > >
> >
> > Is the PartnerRoleMessageExchange.replyAsync() call back needed? Is
> > it just a hint to the process that the transaction is going to be
> > committed in the middle of an out-in <invoke>?
> >
> > What is driving the need for the MessageExchange stuff in the BPEL
> > engine API? Is it just the ability to implement synchronous
> > request/response operations asynchronously. We did spend sometime
> > thinking about this when building the BPE. We eventually decided that
> > this was provide for by a one-way <invoke> and a <recieve>. It feels
> > like some bus like functionality is creeping into the engine.
> >
> >
> > > > 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 <ma...@gmail.com> 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
>
Re: Integration API
Posted by Assaf Arkin <ar...@intalio.com>.
A good bus is stateless and stupid, it just moves messages in and out.
Since we already have persistence in the BPEL engine, we should use
that instead of pushing it to the bus. There's an advantage to storing
messages and MEPs in one place and only once.
Having said that, I don't consider all possible MEP combinations to be
interesting just because they can be done.
JMS for reliable messaging (transactions, persistence) is best done as
two separate one-way operations.
There are some cases where JMS -- more specifically, some MOMs and
backend combinations -- are used for synchronous operations because
the MOM is used as the message bus and protocol abstraction.
But these operations are synchronous, they don't occur in separate
transactions (in fact, they don't use transactions are all), messages
are not persisted, they only wait for the response so long and they
fail like all other synchronous operations.
Some practical restrictions are good in keeping to reasonable complexity.
Assaf
On 5/31/06, cory <co...@gmail.com> wrote:
> Hello All,
>
> See my comments below.
>
> Cheers,
>
> -cory
>
> On 5/31/06, Guillaume Nodet <gu...@worldonline.fr> 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.
> >
>
> Is the PartnerRoleMessageExchange.replyAsync() call back needed? Is
> it just a hint to the process that the transaction is going to be
> committed in the middle of an out-in <invoke>?
>
> What is driving the need for the MessageExchange stuff in the BPEL
> engine API? Is it just the ability to implement synchronous
> request/response operations asynchronously. We did spend sometime
> thinking about this when building the BPE. We eventually decided that
> this was provide for by a one-way <invoke> and a <recieve>. It feels
> like some bus like functionality is creeping into the engine.
>
>
> > > 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 <ma...@gmail.com> 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