You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by William Tam <em...@gmail.com> on 2008/06/23 22:40:20 UTC
[PROPOSAL] ProtocolMessage
Hi all,
I may be totally off but, it seems that Camel Message headers are
being used too liberally. Some headers are added by components for
doing their jobs with no intention to send them as protocol headers.
Some headers are objects/non-string and are not suitable to be sent as
headers anyway. When an app reads headers from a message, it does not
really know whether a header is actually a protocol header or
something that gets added by Camel. Likewise, when an app needs to
set some protocol headers, Message.setHeader() does not seem to
provide that kind of semantics. So, I am proposing creating a
ProtocolMessage class that extends DefaultMessage with these methods:
/**
* Get protocol header.
*/
public List<String> getProtocolHeader(String name) {
}
/**
* Set protocol header
*/
public void setProtocolHeader(String name, List<String> value) {
}
For example, CxfMessage will extend ProtocolMessage. If I call
CxfMessage.getProtocolHeader(), I get the protocol headers in a CXF
message not the ones that are added by CxfComponent.
CxfMessage.getHeader() is unaffected. Other message types may need to
be updated as well.
So, what do you think?
Thanks,
William
Re: [PROPOSAL] ProtocolMessage
Posted by William Tam <em...@gmail.com>.
> I guess the tricky thing is - what is a 'protocol header'?
>
> e.g. take HTTP and JMS as examples; you can specify your own headers
> which a receiver may or may not understand. You can do the same with
> SOAP. What constitutes a 'protocol header' in the general sense?
>
> Since its such a grey area I'd always kinda thought it was up to an
> endpoint to decide what headers it considered part of the protocol.
>
Protocol headers in my mind get transmitted as part of the message
over the wire. They can be user-defined if the protocol supports it.
I agree that an endpoint (ultimately) gets to decide what they headers
are. For example an endpoint can reject headers that are not
appropriate to be included before sending it out. There are many
occasions that objects are added to Message.setHeader() but they are
not meant to be protocol headers.
> We could certainly add some kinda header letting folks describe which
> headers are expected to be part of the protocol? Or maybe configure -
> say - the CXF endpoint to exclude headers of certain
> names/shapes/types etc
>
>
> Another option I guess is to reserve message headers only for protocol
> related stuff; and use Exchange properties for anything else?
I like the last option. Can we restrict the value type to String
(i.e. String getHeader(String key)) and deprecate the old methods?
Thanks,
William
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://open.iona.com
>
Re: [PROPOSAL] ProtocolMessage
Posted by William Tam <em...@gmail.com>.
>
> Another option I guess is to reserve message headers only for protocol
> related stuff; and use Exchange properties for anything else?
>
We could be setting headers in any of the three (in, out, fault)
messages. Using Exchange properties may lose the info regarding which
message the property is assocated with. See the PipelineTest for an
illustration, "copy-counter" can be set in fault and out message and
can hold different values. (Also, can't deprecate a method and add
new method only different by return type). I'd probably leave the
set/getHeader alone and expermient with adding set/getProtocolHeader.
Maybe I'll shoot myself down :-)
Re: [PROPOSAL] ProtocolMessage
Posted by James Strachan <ja...@gmail.com>.
2008/6/23 William Tam <em...@gmail.com>:
> Hi all,
>
> I may be totally off but, it seems that Camel Message headers are
> being used too liberally. Some headers are added by components for
> doing their jobs with no intention to send them as protocol headers.
> Some headers are objects/non-string and are not suitable to be sent as
> headers anyway. When an app reads headers from a message, it does not
> really know whether a header is actually a protocol header or
> something that gets added by Camel. Likewise, when an app needs to
> set some protocol headers, Message.setHeader() does not seem to
> provide that kind of semantics. So, I am proposing creating a
> ProtocolMessage class that extends DefaultMessage with these methods:
>
> /**
> * Get protocol header.
> */
> public List<String> getProtocolHeader(String name) {
> }
>
>
> /**
> * Set protocol header
> */
> public void setProtocolHeader(String name, List<String> value) {
> }
>
> For example, CxfMessage will extend ProtocolMessage. If I call
> CxfMessage.getProtocolHeader(), I get the protocol headers in a CXF
> message not the ones that are added by CxfComponent.
> CxfMessage.getHeader() is unaffected. Other message types may need to
> be updated as well.
>
> So, what do you think?
I guess the tricky thing is - what is a 'protocol header'?
e.g. take HTTP and JMS as examples; you can specify your own headers
which a receiver may or may not understand. You can do the same with
SOAP. What constitutes a 'protocol header' in the general sense?
Since its such a grey area I'd always kinda thought it was up to an
endpoint to decide what headers it considered part of the protocol.
We could certainly add some kinda header letting folks describe which
headers are expected to be part of the protocol? Or maybe configure -
say - the CXF endpoint to exclude headers of certain
names/shapes/types etc
Another option I guess is to reserve message headers only for protocol
related stuff; and use Exchange properties for anything else?
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://open.iona.com
Re: [PROPOSAL] ProtocolMessage
Posted by William Tam <em...@gmail.com>.
>
> I just checked that CXF also puts the protocol header as a Object with the
> key Message.PROTOCOL_HEADERS in the CXF message[1]. If you want to get the
> protocol headers of the CXF message, you can retrieve it from CxfMessage's
> getHeader with the Message.PROTOCOL_HEADERS.
Yes, I aware of that but I want to avoid special-casing CxfMessage in
my client code. I.e. can't do something this. I can't even import
cxf module in that module.
if (message instanceof CxfMessage) {
Map<String, List<String>> headers =
message.getHeaders(Message.PROTOCOL_HEADERS);
...
}
Re: [PROPOSAL] ProtocolMessage
Posted by Willem Jiang <wi...@gmail.com>.
Hi William,
I just checked that CXF also puts the protocol header as a Object with
the key Message.PROTOCOL_HEADERS in the CXF message[1]. If you want to
get the protocol headers of the CXF message, you can retrieve it from
CxfMessage's getHeader with the Message.PROTOCOL_HEADERS.
There is a shortcoming in your proposal, if the protocol message is
cased to the default message for some components or processors, the
{get|set}ProtocolHeader method will never be called.
[1]
https://svn.apache.org/repos/asf/cxf/trunk/rt/transports/http/src/main/java/org/apache/cxf/transport/http/HTTPConduit.java
's method getSetProtocolHeaders
Just my two cents,
Willem
William Tam wrote:
> Hi all,
>
> I may be totally off but, it seems that Camel Message headers are
> being used too liberally. Some headers are added by components for
> doing their jobs with no intention to send them as protocol headers.
> Some headers are objects/non-string and are not suitable to be sent as
> headers anyway. When an app reads headers from a message, it does not
> really know whether a header is actually a protocol header or
> something that gets added by Camel. Likewise, when an app needs to
> set some protocol headers, Message.setHeader() does not seem to
> provide that kind of semantics. So, I am proposing creating a
> ProtocolMessage class that extends DefaultMessage with these methods:
>
> /**
> * Get protocol header.
> */
> public List<String> getProtocolHeader(String name) {
> }
>
>
> /**
> * Set protocol header
> */
> public void setProtocolHeader(String name, List<String> value) {
> }
>
> For example, CxfMessage will extend ProtocolMessage. If I call
> CxfMessage.getProtocolHeader(), I get the protocol headers in a CXF
> message not the ones that are added by CxfComponent.
> CxfMessage.getHeader() is unaffected. Other message types may need to
> be updated as well.
>
> So, what do you think?
>
> Thanks,
> William
>
>