camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <>
Subject Re: Components setting data on OUT
Date Mon, 26 Jan 2009 22:34:23 GMT

On Jan 26, 2009, at 4:17 PM, William Tam wrote:

> On Mon, Jan 26, 2009 at 1:37 PM, Hadrian Zbarcea  
> <> wrote:
>> I don't disagree, I was just suggesting that they should then  
>> travel as
>> properties.
> Why shouldn't they (protocol headers) travel as headers (to avoids
> unnecessary copying between exchange properties and protocol headers)?
There should be no unnecessary copying, I agree.  If a header (such as  
username/password) has broadly known and accepted semantics, the  
endpoint or associated policy could set it as a property from start.   
Similarly, an endpoint should look at both properties and headers when  
sending a message.

>> Whatever we name them, and whatever mechanism we decide to use,
>> as pointed out before, we need to distinguish between headers that  
>> are
>> endpoint/protocol specific and have no semantics outside the  
>> endpoint and
>> headers (which we called properties and didn't use consistently)  
>> that must
>> be carried over the lifetime of the Exchange.
> Custom protocol header fits into "no semantics outside the endpoint"
> (or else it won't get propagated) and so it goes to the exchange
> properties.   How does the next component (in the pipeline) know what
> one of the properties are intended to be sent in protocol header?
> Wouldn't it be better to let protocol headers travel as headers so
> only the "header candidates" will be potentially be sent?

Not sure I understand your question, but I think we should use  
policies for handling custom headers.

>> Hadrian
>> On Jan 26, 2009, at 1:07 PM, William Tam wrote:
>>> On Mon, Jan 26, 2009 at 10:35 AM, Hadrian Zbarcea < 
>>> >
>>> wrote:
>>>> Hi,
>>>> This headers business is a bit of a tricky one.  I hit it last  
>>>> year in
>>>> the
>>>> context of security.
>>>> I agree with the view that headers should only exist in the  
>>>> context of an
>>>> endpoint.  I think outside of that there is no guarantee that the
>>>> semantics
>>>> of a header is preserved.  I am not sure if headers should be  
>>>> propagated
>>>> from one endpoint to another at all.
>>> There are certainly use cases that protocol headers DO need to be
>>> propagated between endpoints.  If users want to integrate with some
>>> management and/or security tools like Actional, users are required  
>>> to
>>> include custom headers in protocol headers.  These custom headers
>>> travel with messages to allow trust zone enforcement and message
>>> correlation.  They need to be preserved and propagated across hops
>>> which are potentially over different transport protocols.
>>>> Properties should be used instead.
>>>> Coming back to security, if http is used for instance there are  
>>>> several
>>>> ways
>>>> of handling that.  If basic auth is used for instance one gets a
>>>> user/pass,
>>>> but that may need to be translated to something else at endpoint
>>>> boundaries.
>>>> I don't think that the "Authorization" header should exist  
>>>> outside the
>>>> http
>>>> endpoint for instance.
>>>> Yes, we do propagate properties today, no issue there.  But then  
>>>> some
>>>> policies need to be defined per endpoint to deal with known
>>>> headers/properties, and camel specific properties should be  
>>>> defined to
>>>> deal
>>>> with know headers.  Even better, endpoints should set protocol  
>>>> specific
>>>> headers that are known as required to propagate (such as the auth  
>>>> stuff)
>>>> as
>>>> properties from start.
>>>> My $0.02
>>>> Hadrian
>>>> On Jan 26, 2009, at 9:44 AM, Claus Ibsen wrote:
>>>>> On Mon, Jan 26, 2009 at 3:37 PM, Roman Kalukiewicz
>>>>> <> wrote:
>>>>>> Why don't we talk about exchange properties here? My feeling  
>>>>>> here is
>>>>>> that properties should be used as user-headers, while headers are
>>>>>> always protocol headers. In fact it works this way right now:  
>>>>>> If I
>>>>>> want to keep some value through the whole flow I put it into
>>>>>> properties.
>>>>>> By current convention if I put something on a header it is sent 

>>>>>> as
>>>>>> protocol-specific header (JMS property, HTTP header), and out  
>>>>>> headers
>>>>>> are filled also with protocol headers (JSM properties of out  
>>>>>> emssage,
>>>>>> HTTP response headers). In this case headers shouldn't be  
>>>>>> propagated,
>>>>>> as there is no way to distinguish things propagated, from things
>>>>>> retrieved. And out headers ARE different than in headers.
>>>>>> It is a matter of naming, but currently headers are (what you  
>>>>>> call)
>>>>>> protocol/system headers, while properties are user-headers  
>>>>>> (work as
>>>>>> variables). Do we really need to extend it further? If someone  
>>>>>> mix
>>>>>> those two concepts then it is problem of documentation, but not 

>>>>>> lack
>>>>>> of functionality. I would just extend DSL a little to be able to
>>>>>> retrieve a property (instead using header()).
>>>>>> What do you think, guys? Maybe we should clearly communicate what
>>>>>> things are for and what are the consequences of using one or  
>>>>>> another.
>>>>>> Roman
>>>>>> PS. Pipeline should propagate all headers of course, but I  
>>>>>> believe an
>>>>>> endpoint is a place where we shouldn't guarantee that headers  
>>>>>> will be
>>>>>> propagated by stating it clearly.
>>>>> Properties have just lived in the dark and end users does not  
>>>>> really
>>>>> know they exists. We have some builder methods to set/get  
>>>>> properties.
>>>>> I guess we need to document and maybe make sure the Spring DSL  
>>>>> also
>>>>> has support for accessing properties as well.
>>>>> To my knowledge properties is always preserved so I doubt we  
>>>>> have an
>>>>> issue there.
>>>>> So users should just start learn using properties as well :)
>>>>> However then we have the ProducerTemplate that has one liners for
>>>>> sending an Exchange. We dont have a sendBodyAndProperties  
>>>>> method. But
>>>>> yet again it has too many methods already. They can just use
>>>>> send("xxx", Exchange) and have exchange populated with the  
>>>>> properties
>>>>> of choice.
>>>>>> 2009/1/26 Claus Ibsen <>:
>>>>>>> On Sat, Jan 24, 2009 at 9:08 PM, William Tam <

>>>>>>> >
>>>>>>> wrote:
>>>>>>>>> What we have stored in Headers today in Camel is both:
>>>>>>>>> - user headers
>>>>>>>>> - and system headers (added by Camel itself).
>>>>>>>>> I am starting to be more and more convinced that we should
>>>>>>>>> separate
>>>>>>>>> the two.
>>>>>>>>> So any headers that a users has enforced to be set should
>>>>>>>>> kept in
>>>>>>>>> one Map and the others that the components set internally
>>>>>>>>> (such as
>>>>>>>>> SQL
>>>>>>>>> number of rows returned, or whatnot we have, there are
>>>>>>>>> in
>>>>>>>>> another Map.
>>>>>>>> It means that a component would have to look for header in
>>>>>>>> more than
>>>>>>>> one place.   Besides, the distinction of user vs system 

>>>>>>>> header is not
>>>>>>>> always clear.  For example, the operation name header for
>>>>>>>> endpoint
>>>>>>>> can be set by user but it is also created by cxf component.
>>>>>>>> I am
>>>>>>>> sure there are many more examples.  There is another header
>>>>>>>> category:
>>>>>>>> protocol headers.  A protocol header is not really a user
>>>>>>>> system
>>>>>>>> header.  Protocol headers are header propagated from protocol
>>>>>>>> like
>>>>>>>> HTTP, which we do want to preserve in message header.
>>>>>>>>> The user headers is always preserved and copied along
in the
>>>>>>>>> routing.
>>>>>>>>> User can always clear/remove unwanted headers.
>>>>>>>>> The system headers should be short lived as they are
>>>>>>>>> really
>>>>>>>>> useable. So they are "alive" in the next step (process)
in the
>>>>>>>>> route,
>>>>>>>>> and when the pipeline invokes next route thereafter these
>>>>>>>>> information
>>>>>>>>> is cleared.
>>>>>>>>> Separating these will also make the routing/tracing a
>>>>>>>>> easier as
>>>>>>>>> Users can recognize their own headers instead its mixed
>>>>>>>>> all the
>>>>>>>>> noise the Camel components add.
>>>>>>>> I wonder we can leverage/extend the HeaderFilterStrategy
>>>>>>>> mechanism.
>>>>>>>> Currently, it is only used for filtering unwanted headers
>>>>>>>> both
>>>>>>>> request and response direction) when we propagate headers
>>>>>>>> between
>>>>>>>> Camel and external messages (like HTTP).    
>>>>>>>> HeaderFilterStrategy is
>>>>>>>> (or
>>>>>>>> will be) associated with an endpoint.  We could make
>>>>>>>> HeaderFilterStrategy available to the exchange object.  So,
>>>>>>>> when an
>>>>>>>> endpoint creates an exchange, the exchange gets a header
>>>>>>>> strategy.  Then, pipeline can do something like this to filter
>>>>>>>> unwanted header: message.filterHeaders().   The header filter
>>>>>>>> strategy
>>>>>>>> is highly customizable for each endpoint (can have a  
>>>>>>>> component wide
>>>>>>>> default) and it can be looked up from registry.
>>>>>>> Good pointers William.
>>>>>>> Yeah we can revist it after you have moved the header filters
>>>>>>> to the
>>>>>>> endpoint.
>>>>>>> Then we can check up upon how to leverage it as you suggest.
>>>>>>> --
>>>>>>> Claus Ibsen
>>>>>>> Apache Camel Committer
>>>>>>> Open Source Integration:
>>>>>>> Blog:
>>>>> --
>>>>> Claus Ibsen
>>>>> Apache Camel Committer
>>>>> Open Source Integration:
>>>>> Blog:

View raw message