ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <ar...@intalio.com>
Subject Re: Integration API
Date Fri, 02 Jun 2006 05:29:14 GMT
On 6/1/06, cory <cory.harper@gmail.com> wrote:
> On 6/1/06, Assaf Arkin <arkin@intalio.com> wrote:
> > On 6/1/06, Lance Waterman <lance.waterman@gmail.com> 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? ).
> >
> > On top of the sync/async multi-layer protocol stack we have the actual
> > application API. This one can be synchronous, asynchronous or both. A
> > modern service bus would offer you both.
> >
> > The synchronous API is easier to code for, so the default option if
> > you're writing a lot of code. You can always optimize it better. But
> > when you're designing a process you don't have that level of control
> > to optimize it later, so the engine needs to decide. And it needs to
> > consider management and performance.
>
> Sorry, I don't quite understand.  What is the engine deciding here?

When you have two ways of performing a two-way operations:
synchronously, or asynchronously, the process engine decides which way
to go. Or more specifically, whoever writes the process engine.

> > Separating a limited pool of process engine threads that only block
> > for local resources (CPU, memory, database) and an unlimited pool of
> > messaging threads that block for external resources (services you
> > invoke, possibly out there on separate machines) gives you better
> > performance and the right amount of control to tune the engine. It
> > also means that when one process invokes the other, only one process
> > engine thread is actually busy doing any work. If you have three
> > processes in that chain, it's still only one active process engine
> > thread.
>
> These threads are managed by the bus and not the BPEL engine right?

If you have decoupling between the process engine and bus threads,
then the process engine manages its own threads, and the bus manages
its own thread.

Mime
View raw message