On Jan 26, 2009, at 4:17 PM, William Tam wrote:
On Mon, Jan 26, 2009 at 1:37 PM, Hadrian Zbarcea
<hzbar...@gmail.com> 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 <hzbar...@gmail.com
>
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
<roman.kalukiew...@gmail.com> 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 <claus.ib...@gmail.com>:
On Sat, Jan 24, 2009 at 9:08 PM, William Tam <email.w...@gmail.com
>
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 be
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 many)
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 cxf
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 or
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 not
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 bit
easier as
Users can recognize their own headers instead its mixed with
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 (in
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 filter
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: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
