cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <>
Subject WS-Addressing Issues
Date Thu, 06 Sep 2007 15:56:10 GMT
I'm having some issues getting WS-A to work for me.

First, it seems that adding the WSAddressingFeature isn't enough to get 
WS-A to be turned on. You have to set the "usingAddressingAdvisory" 
property which is cryptic at best. Why isn't adding the interceptors to 
the client enough for it to start sending WS-A headers? Why would we 
want it turned off by default?

Second, I'm running the WS-A sample and it appears to be sending two 
soap messages to the client - one partial response and one decoupled 
message. From the logs:

INFO: Outbound Message 
<soap:Envelope xmlns:soap=""><soap:Header><MessageID
INFO: Inbound Message
Headers: {null=[HTTP/1.1 202 Accepted], connection=[close], SOAPAction=[""], Server=[Jetty(6.1.5)],
content-type=[text/xml; charset=utf-8]}
<soap:Envelope xmlns:soap=""><soap:Header><MessageID
INFO: Inbound Message
Encoding: UTF-8
Headers: {Host=[localhost:9990], User-Agent=[Java/1.5.0_10], connection=[keep-alive], SOAPAction=[""],
transfer-encoding=[chunked], Pragma=[no-cache], content-type=[text/xml; charset=UTF-8], Cache-Control=[no-cache],
<soap:Envelope xmlns:soap=""><soap:Header><MessageID

Is this correct? I thought the first http response should be empty and 
we should only be sending the second message.

Last, I'm trying to write a different HTTP conduit and destination. I.e. 
one that uses Mule. I think this issue applies to our JBI transport as 
well. In both the JBI & Mule cases (or any other ESB), you want to send 
messages to the bus instead of to our transport layer. The bus can then 
send out the messages via it's transport layer. The issue is this - our 
decoupled endpoint stuff is baked into the transport, which it needs to 
be rebaked into the Mule/JBI transports as well. Its not exactly trivial 
to do either, I'm still struggling to figure it out. But to expand my 
previous points on why decoupling in the transport is a BAD thing here 
are some other reasons:
- Setting up a decoupled endpoint for CXF will be completely different 
depending on whether or not your in an ESB environment or not. In one 
case I have to use <http:conduit> to set the DecoupledEndpoint, in 
another <mule:conduit>, in another <jbi:conduit> (which doesn't support 
decoupled interactions right now), etc. It'd be much much better to have 
this configuration associated with the client.
- Now any ESB transport needs to take care of setting the appropriate 
HTTP statuses on the messages.
- I have to copy the InteroposedMessageObserver & decoupled Destination 
logic to my conduit
- I'm probably going to end up with a bunch of if(http) logic in my 
transport to handle back channel stuff.
Am I missing something here? This seems way harder than it should be... 
Have any of the servicemix people looked at this yet?

- Dan

Dan Diephouse
MuleSource |

View raw message