You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Dan Diephouse <da...@mulesource.com> on 2007/09/06 17:56:10 UTC
WS-Addressing Issues
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="http://schemas.xmlsoap.org/soap/envelope/"><soap:Header><MessageID xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:9bd2e4c4-cca0-478d-bc81-a57e92b9c1c4</MessageID><To xmlns="http://www.w3.org/2005/08/addressing">http://localhost:9000/SoapContext/SoapPort</To><ReplyTo xmlns="http://www.w3.org/2005/08/addressing"><Address>http://localhost:9990/decoupled_endpoint</Address></ReplyTo><FaultTo xmlns="http://www.w3.org/2005/08/addressing"><Address>http://localhost:9990/decoupled_endpoint</Address></FaultTo></soap:Header><soap:Body><sayHi xmlns="http://apache.org/hello_world_soap_http/types"/></soap:Body></soap:Envelope>
--------------------------------------
...
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]}
Message:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Header><MessageID xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:d15fa093-3951-47f5-86ac-bd616f8d57d7</MessageID><To xmlns="http://www.w3.org/2005/08/addressing">http://www.w3.org/2005/08/addressing/anonymous</To><ReplyTo xmlns="http://www.w3.org/2005/08/addressing"><Address>http://www.w3.org/2005/08/addressing/none</Address></ReplyTo></soap:Header><soap:Body /></soap:Envelope>
--------------------------------------
...
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], Accept=[*]}
Message:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Header><MessageID xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:9e2a0281-dcea-42b5-b5a9-a89e265d40de</MessageID><To xmlns="http://www.w3.org/2005/08/addressing">http://localhost:9990/decoupled_endpoint</To><RelatesTo xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:9bd2e4c4-cca0-478d-bc81-a57e92b9c1c4</RelatesTo></soap:Header><soap:Body><sayHiResponse xmlns="http://apache.org/hello_world_soap_http/types"><responseType>Bonjour</responseType></sayHiResponse></soap:Body></soap:Envelope>
--------------------------------------
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?
Regards,
- Dan
--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog
Re: WS-Addressing Issues
Posted by Daniel Kulp <dk...@apache.org>.
The quick executive summary is:
1) It's not a problem. The implementation is OK to do this. It's not
optimal, but OK. Issue created:
https://issues.apache.org/jira/browse/CXF-981
That was the point of the discussion. We were trying to figure out if
the issue is enough to warrant delaying 2.0.2. The answer is no.
2) For code first cases (no wsdl policy extensors) adding the
feature/interceptors should be enough to enable WS-A. (Usability
issue) However, the user then takes on the responsibility of making
sure the server will actually be OK with WS-A. Any more thoughts on
this?
Dan
On Friday 07 September 2007, Glynn, Eoghan wrote:
> FYI sorted out on IRC, see http://dev.rectang.com/logs/codehaus/%23cxf
>
> Cheers,
> Eoghan
>
> > -----Original Message-----
> > From: Dan Diephouse [mailto:dan.diephouse@mulesource.com]
> > Sent: 06 September 2007 16:56
> > To: cxf-dev@incubator.apache.org
> > Subject: WS-Addressing Issues
> >
> > 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="http://schemas.xmlsoap.org/soap/envelope/"><soap:H
> > eader><MessageID
> > xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:9bd2e4c4
> > -cca0-478d-bc81-a57e92b9c1c4</MessageID><To
> > xmlns="http://www.w3.org/2005/08/addressing">http://localhost:
> > 9000/SoapContext/SoapPort</To><ReplyTo
> > xmlns="http://www.w3.org/2005/08/addressing"><Address>http://l
> > ocalhost:9990/decoupled_endpoint</Address></ReplyTo><FaultTo
> > xmlns="http://www.w3.org/2005/08/addressing"><Address>http://l
> > ocalhost:9990/decoupled_endpoint</Address></FaultTo></soap:Hea
> > der><soap:Body><sayHi
> > xmlns="http://apache.org/hello_world_soap_http/types"/></soap:
> > Body></soap:Envelope>
> > --------------------------------------
> > ...
> > 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]}
> > Message:
> > <soap:Envelope
> > xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:H
> > eader><MessageID
> > xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:d15fa093
> > -3951-47f5-86ac-bd616f8d57d7</MessageID><To
> > xmlns="http://www.w3.org/2005/08/addressing">http://www.w3.org
> > /2005/08/addressing/anonymous</To><ReplyTo
> > xmlns="http://www.w3.org/2005/08/addressing"><Address>http://w
> > ww.w3.org/2005/08/addressing/none</Address></ReplyTo></soap:He
> > ader><soap:Body /></soap:Envelope>
> > --------------------------------------
> > ...Eoghan
> -----Original Message-----
> From: Dan Diephouse [mailto:dan.diephouse@mulesource.com]
> Sent: 06 September 2007 16:56
> To: cxf-dev@incubator.apache.org
> Subject: WS-Addressing Issues
>
> I'm having some issues getting WS-A to work for me.
>
> > 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], Accept=[*]}
> > Message:
> > <soap:Envelope
> > xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:H
> > eader><MessageID
> > xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:9e2a0281
> > -dcea-42b5-b5a9-a89e265d40de</MessageID><To
> > xmlns="http://www.w3.org/2005/08/addressing">http://localhost:
> > 9990/decoupled_endpoint</To><RelatesTo
> > xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:9bd2e4c4
> > -cca0-478d-bc81-a57e92b9c1c4</RelatesTo></soap:Header><soap:Bo
> > dy><sayHiResponse
> > xmlns="http://apache.org/hello_world_soap_http/types"><respons
> > eType>Bonjour</responseType></sayHiResponse></soap:Body></soap
> >
> > :Envelope>
> >
> > --------------------------------------
> >
> >
> > 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?
> >
> > Regards,
> > - Dan
> >
> > --
> > Dan Diephouse
> > MuleSource
> > http://mulesource.com | http://netzooid.com/blog
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
> Ireland
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
RE: WS-Addressing Issues
Posted by "Glynn, Eoghan" <eo...@iona.com>.
FYI sorted out on IRC, see http://dev.rectang.com/logs/codehaus/%23cxf
Cheers,
Eoghan
> -----Original Message-----
> From: Dan Diephouse [mailto:dan.diephouse@mulesource.com]
> Sent: 06 September 2007 16:56
> To: cxf-dev@incubator.apache.org
> Subject: WS-Addressing Issues
>
> 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="http://schemas.xmlsoap.org/soap/envelope/"><soap:H
> eader><MessageID
> xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:9bd2e4c4
> -cca0-478d-bc81-a57e92b9c1c4</MessageID><To
> xmlns="http://www.w3.org/2005/08/addressing">http://localhost:
> 9000/SoapContext/SoapPort</To><ReplyTo
> xmlns="http://www.w3.org/2005/08/addressing"><Address>http://l
> ocalhost:9990/decoupled_endpoint</Address></ReplyTo><FaultTo
> xmlns="http://www.w3.org/2005/08/addressing"><Address>http://l
> ocalhost:9990/decoupled_endpoint</Address></FaultTo></soap:Hea
> der><soap:Body><sayHi
> xmlns="http://apache.org/hello_world_soap_http/types"/></soap:
> Body></soap:Envelope>
> --------------------------------------
> ...
> 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]}
> Message:
> <soap:Envelope
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:H
> eader><MessageID
> xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:d15fa093
> -3951-47f5-86ac-bd616f8d57d7</MessageID><To
> xmlns="http://www.w3.org/2005/08/addressing">http://www.w3.org
> /2005/08/addressing/anonymous</To><ReplyTo
> xmlns="http://www.w3.org/2005/08/addressing"><Address>http://w
> ww.w3.org/2005/08/addressing/none</Address></ReplyTo></soap:He
> ader><soap:Body /></soap:Envelope>
> --------------------------------------
> ...
> 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], Accept=[*]}
> Message:
> <soap:Envelope
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:H
> eader><MessageID
> xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:9e2a0281
> -dcea-42b5-b5a9-a89e265d40de</MessageID><To
> xmlns="http://www.w3.org/2005/08/addressing">http://localhost:
> 9990/decoupled_endpoint</To><RelatesTo
> xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:9bd2e4c4
> -cca0-478d-bc81-a57e92b9c1c4</RelatesTo></soap:Header><soap:Bo
> dy><sayHiResponse
> xmlns="http://apache.org/hello_world_soap_http/types"><respons
> eType>Bonjour</responseType></sayHiResponse></soap:Body></soap
> :Envelope>
> --------------------------------------
>
>
> 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?
>
> Regards,
> - Dan
>
> --
> Dan Diephouse
> MuleSource
> http://mulesource.com | http://netzooid.com/blog
>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland