Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: pass (athena.apache.org: domain of james.strachan@gmail.com
 designates 209.85.213.45 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:from:date
         :x-google-sender-auth:message-id:subject:to:cc:content-type;
        b=LzTTk2Q5U4Y1zgXQ1UU1IofoOchLb9RE3OdvtuLYog2KpkZVG7KVdGDpDbJpyL/k5j
         Wn3D3i1veTicZ/SVQ/wLoT52fK/vv8y7+fJ9Vv9OxaCMmuNsTCmrAoBv78Un+i9PLNT7
         4KJZGeM4vZeD1tl5dpw29mKgJZhaxCzIhGjpE=
MIME-Version: 1.0
Sender: james.strachan@gmail.com
In-Reply-To: <1299578395931-3413734.post@n5.nabble.com>
References: <1299496369263-3412244.post@n5.nabble.com>
 <1299515156480-3412683.post@n5.nabble.com>
 <1299578395931-3413734.post@n5.nabble.com>
From: James Strachan <james@fusesource.com>
Date: Tue, 8 Mar 2011 10:21:40 +0000
Message-ID: <AANLkTi=awM-nYORdCThjnCUAms-3hTMp7uAkWM_qGCY4@mail.gmail.com>
Subject: Re: [EIP] Can you please help me choose a correct design pattern ?
To: users@camel.apache.org
Cc: Maxence Button <maxence.button@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On 8 March 2011 09:59, Maxence Button <maxence.button@gmail.com> wrote:
> Hi Claus !
>
> Thank you for welcoming me in the Camel community. I'm honored that you
> replied to my question .
>
> Yet, I'm afraid it's not that simple : as I wrote it earlier, I played with
> the Aggregator and I guess it's almost what I'm looking for. I came to that
> pattern thanks to your book and the other reference book about EIP.
> What I have doubts about is the completion criteria. The case I described
> was voluntarily simplified but my patterns are much more complex.
>
> For instance, I have a process that should be able to receive an
> undetermined number of messages (let's say of type "Item") and when a single
> message "EndOfOrder" is received, then the process sends another message on
> the message broker saying the order has been completed. And that message
> triggers another process and so on.

So the completion predicate is then an expression detecting the
EndOfOrder message.


> About the correlation, I had exactly the same "problem" with BPEL process
> manager : my messages have no correlation between them : they come from
> different routes linked to different partners who have nothing in common. I
> was forced to trick the system by asking all the partners to enter a fake
> property on which I could base my correlation. It's working but I'm not
> fully satisfied with it ...

So there is no concurrency in your system and all messages arrive in
the exact order, pre sorted into aggregation pairs right? OrderA,
Order B, EndOfOrder then OrderC, OrderD, EndOfOrder etc? Things never
get mixed up out of order on a route?

If there is no correlation at all between the messages, then all
messages correlate with each other. So just use a constant expression
for the correlation key, like "foo".


> What I'm looking for, is exactly the Oracle | BEA WLI message broker feature
> : channels with components listening for some messages, matching the
> criteria I've defined, that's all. No correlation needed.

If there's no correlation or aggregation and its just a filter, then
this sounds like a message filter?
http://camel.apache.org/message-filter.html

But your previous post sounded like you were trying to aggregate
messages together; that is that when you have completed a set of
messages you want to send a message (but only when a set is complete).
So its sounding like an Aggregator; the difference is that there's no
correlation required as everything arrives in order - and you don't
need to aggregate the messages together as you are sending a constant
message at the end. But other than that its sounding like an
aggregator where you either use a fixed batch size or a completion
predicate (detecting the EndOfOrder message)?

-- 
James
-------
FuseSource
Email: james@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan
Blog: http://macstrac.blogspot.com/

Open Source Integration