Mailing-List: contact camel-user-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: camel-user@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of hzbarcea@gmail.com designates
 64.233.170.188 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer;
        b=QoVIqL8I+4/Y/MgNGa3dOGS1xYHSQ4vfw7EmXvndldrN5E8NAFRLtbS1z/GDzeYtUqOKNs66BPr+yhXW3IfQruB4dbhSDA5KDYwopr6IoXrtPFjB26vR8txpTdWeiZg/X9RSwHtgzR/p1mLFvonR659ko6fn3Ukx/8GxAorynw8=
Message-Id: <4751B74B-BD39-4F97-92A9-DD62EAC330E7@gmail.com>
From: Hadrian Zbarcea <hzbarcea@gmail.com>
To: camel-user@activemq.apache.org
In-Reply-To: <f1c427510801310248u75080918p24309226fc4fe427@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: in/out/fault messages discussion
Date: Thu, 31 Jan 2008 11:17:47 -0500
References: <f1c427510712050335j22a73fb1u619bbd258a06b30c@mail.gmail.com>
 <1D64AF3E-A69A-44DE-9DAB-F0EB238A8326@intalgent.com>
 <EBFEEEDA-E7B7-495C-803A-C1E169708DBE@gmail.com>
 <f1c427510801301052s26fd9441l1f51f77eb282812f@mail.gmail.com>
 <9A5229FD-DEA0-4F13-B201-E6866C572D38@gmail.com>
 <f1c427510801310205n1c935e95v9f212911237538b7@mail.gmail.com>
 <f1c427510801310248u75080918p24309226fc4fe427@mail.gmail.com>

Actually to Guillaume's point, I am strongly in favor of keeping the  
input.  And to be honest, I like the model the way it is, for many  
reasons.  One is that the model is very intuitive for people familiar  
with certain standards, myself included, and the emtpy chairs don't  
bother me.  If I understand correctly you are not claiming that there  
are features that the current model (vs yours) cannot support, just  
that your proposal will make it clearer.

Well, de gustibus non est disputandum.  If you really feel strongly  
about that, a vote is the way to settle it :).

Cheers,
Hadrian


On Jan 31, 2008, at 5:48 AM, Roman Kalukiewicz wrote:

> 2008/1/31, Guillaume Nodet <gnodet@gmail.com>:
>> How would you handle SOAP processing like WS-Addressing, WS-RM where
>> the creation of the ouput message needs some information about the
>> input message ?
>> We can't really rely on our users to set all those informations on  
>> the
>> output message ...
>
> To be clear - I don't know those standards, so don't beat me if I say
> something stupid ;)
>
> But to answer your question - I believe that good old institution of
> local variable in your processor/endpoint is enough. You can remember
> your current message in local variable and create a new one you will
> respond with.
>
> I imagine this model to be composed of:
> * something similar to Exchange (I'll stick with this name for now) -
> it contains one message, and a set of properties - those properties
> contain business specific data, that we want to be available through
> the flow like transaction ID
> * Message - that contains body in the way it is now, and headers that
> contain some metadata, that are used in endpoints as protocol specific
> data (headers in HTTP, properties in JMS, METHOD_NAME to invoke in
> bean, ...)
>
> When you process the 'Exchange' (in endpoint/processor) you are free
> to change the message itself (like operation on 'in' message) or
> simply put a new one as a response (like operation on 'out' message).
> If you need both during your processing - simply keep the old one as
> your variable.
>
> It is like requiring a java function to return its own parameters. If
> you need them, just keep them. You just send the message (parameters
> and function name) to the object, and receive a message (the response)
> that doesn't have original parameters by default (but you can return
> them like when you return your original 'in' message)
>
> So (I believe) you are able to do it if you need, but this is
> processor specific need, and don't have to be exposed to general API.
>
> Roman