You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Bryan Kearney <bk...@redhat.com> on 2009/03/27 20:47:05 UTC

Version of WSRM

Just wanted to follow up from an earlier conversation. Is 2005/08 
support for wsrm in CXF yet? If not, is it on the roadmap?

Thanks!

-- bk

Re: Version of WSRM

Posted by Eoghan Glynn <eo...@gmail.com>.
2009/3/31 Bryan Kearney <bk...@redhat.com>

> Daniel Kulp wrote:
>
>> On Tue March 31 2009 5:03:59 am Eoghan Glynn wrote:
>>
>>> Now we could follow WCF's example and allow WS-RM 1.0 to be used with the
>>> 2005/08 version of WS-A. While I don't think this is correct from a spec
>>> point of view, we could just be pragmatic and allow it for reasons of
>>> interop.
>>>
>>
>> I would think this is something we would definitely want to do.
>>
>>  It would take a bit of change in the WS-RM layer to make this a
>>> reality though.
>>>
>>
>> Any idea how much work?  Maybe some pointers to Bryan as to where to look
>> to get started?
>>
>> Dan
>>
> I scanned the code, and there is alot of hardcoding of the endpoint type.
> If you can suggest where to start the branching, or why the various
> org.apache.cxf.ws.addressing.ObjectFactorys do not inherit from a common
> superclass that would help.
>
> -- bk
>

The reason for the separate hierarchies for the WS-A types of different
versions is that these types are generated from two separate standard
schemas, and there are enough differences between the two schemas to make
things awkward (the newer one isn't just a straight extension of the older
one).

So the approach followed by WS-A is to use the 2005/08 version as the native
representation throughout the stack. Whereas the 2004/08 version is
transformed to if necessary just before being marshalled to the wire
payload.(or transformed from just after unmarshalling from the wire
payload).

Now in the case of WS-A, this incoming transformation is quite
straight-forward to do, as we're just talking about individual headers. So
we can peek at the namespace of each header and determine the required
version from that, and use an appropriate JAXBContext. However, things would
get a tad more awkward for RM, as the WS-A type were embedded /within/ a
larger request body, in particular the endpoint reference type used as the
<wsrm:AcksTo> part of a <wsrm:CreateSequence> request.

One approach I had in mind was to generate two separate JAXB class
hierarchies for WS-RM, identical in all respects except for the package name
and the type of embedded WS-A types. Actually, only the CreateSequenceType
really needs to be different, as this is the only one embedding a WS-A type,
if memory serves.

Now in order to properly unmarshall incoming CreateSequence requests of
either type, I think (but I'm not 100% sure) the it'd be sufficient to just
add /both/ packages to the JAXBContext.newInstance() underpinning the
speciailized JAXBDataBinding instance used for the out-of-band RM protocol
messages (this context is created in RMEndpoint.createService()).

If so, then all should be good on the destination side.

If not, then one approach would be to assume that the WS-A version in the
headers is always the same as the WS-A version in the types embedded in the
WS-RM out-of-band protocol requests. I think this is a reasonable
assumption, and will always be true for CXF. In this case, the WS-A MAPCodec
would run before the WS-RM in interceptor, so the former could just mark the
message context with an indication of the /original/ WS-A version used in
the wire payload (the AddressingProperties would already be transformed to
the canonical 2005/08 version before the RM layers sees them). Then in the
RM layer a switcheroo would be required in the data-binding used to
unmarshall the incoming message. This could lead to a race condition, but
would only be required for the CreateSequence request as this is the only
one that uses an WS-A type IIRC.

On the source side, you'll need some form of configuration to control which
WS-A version to use, and then specify this via
AddressingPropertiesImpl.exposeAs(). This is currently hard-coded to the
2004/08 version, via RMContextUtils.ensureExposedVersion(). Also
Proxy.createSequnce() will need to be made tolerant of multiple versions of
CreateSequenceType.

Does that brain-dump make sense?

Cheers,
Eoghan

Re: Version of WSRM

Posted by Bryan Kearney <bk...@redhat.com>.
Daniel Kulp wrote:
> On Tue March 31 2009 5:03:59 am Eoghan Glynn wrote:
>> Well, WS-Addressing version 2005/08 is already supported by CXF, and is
>> default version used on the wire and the native version used internally in
>> the stack.
>> Its only in the special case of WS-A used in conjunction with WS-RM that we
>> fallback to the older WS-A version 2004/08. This is because the WS-RM 1.0
>> spec requires usage of the WS-A version 2004/08 (in fact that requirement
>> was the whole motivation for implementing multi-version WS-A support in
>> CXF).
>>
>> Now we could follow WCF's example and allow WS-RM 1.0 to be used with the
>> 2005/08 version of WS-A. While I don't think this is correct from a spec
>> point of view, we could just be pragmatic and allow it for reasons of
>> interop.
> 
> I would think this is something we would definitely want to do.
> 
>> It would take a bit of change in the WS-RM layer to make this a
>> reality though.
> 
> Any idea how much work?  Maybe some pointers to Bryan as to where to look to 
> get started?
> 
> Dan
I scanned the code, and there is alot of hardcoding of the endpoint 
type. If you can suggest where to start the branching, or why the 
various org.apache.cxf.ws.addressing.ObjectFactorys do not inherit from 
a common superclass that would help.

-- bk

Re: Version of WSRM

Posted by Daniel Kulp <dk...@apache.org>.
On Tue March 31 2009 5:03:59 am Eoghan Glynn wrote:
> Well, WS-Addressing version 2005/08 is already supported by CXF, and is
> default version used on the wire and the native version used internally in
> the stack.
> Its only in the special case of WS-A used in conjunction with WS-RM that we
> fallback to the older WS-A version 2004/08. This is because the WS-RM 1.0
> spec requires usage of the WS-A version 2004/08 (in fact that requirement
> was the whole motivation for implementing multi-version WS-A support in
> CXF).
>
> Now we could follow WCF's example and allow WS-RM 1.0 to be used with the
> 2005/08 version of WS-A. While I don't think this is correct from a spec
> point of view, we could just be pragmatic and allow it for reasons of
> interop.

I would think this is something we would definitely want to do.

> It would take a bit of change in the WS-RM layer to make this a
> reality though.

Any idea how much work?  Maybe some pointers to Bryan as to where to look to 
get started?

Dan



>
> Cheers,
> Eoghan
>
>
> 2009/3/30 Bryan Kearney <bk...@redhat.com>
>
> > Eoghan Glynn wrote:
> >> Hi Bryan,
> >>
> >> Did you mean the 2006/08 version (as opposed to 2005)? Otherwise known
> >> as WS-RM 1.1.
> >>
> >>  Sorry... wsAddressing. I dont know the relationship between addressing
> >
> > ans WSRm.I was playing with WCF wsDualHttp binding.. and it is sending
> >
> > http://www.w3.org/2005/08/addressing
> >
> > headers. Is that something which is supported?
> >
> > -- bk

-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog

Re: Version of WSRM

Posted by Eoghan Glynn <eo...@gmail.com>.
Well, WS-Addressing version 2005/08 is already supported by CXF, and is
default version used on the wire and the native version used internally in
the stack.
Its only in the special case of WS-A used in conjunction with WS-RM that we
fallback to the older WS-A version 2004/08. This is because the WS-RM 1.0
spec requires usage of the WS-A version 2004/08 (in fact that requirement
was the whole motivation for implementing multi-version WS-A support in
CXF).

Now we could follow WCF's example and allow WS-RM 1.0 to be used with the
2005/08 version of WS-A. While I don't think this is correct from a spec
point of view, we could just be pragmatic and allow it for reasons of
interop. It would take a bit of change in the WS-RM layer to make this a
reality though.

Cheers,
Eoghan


2009/3/30 Bryan Kearney <bk...@redhat.com>

> Eoghan Glynn wrote:
>
>> Hi Bryan,
>>
>> Did you mean the 2006/08 version (as opposed to 2005)? Otherwise known as
>> WS-RM 1.1.
>>
>>  Sorry... wsAddressing. I dont know the relationship between addressing
> ans WSRm.I was playing with WCF wsDualHttp binding.. and it is sending
>
> http://www.w3.org/2005/08/addressing
>
> headers. Is that something which is supported?
>
> -- bk
>
>

Re: Version of WSRM

Posted by Bryan Kearney <bk...@redhat.com>.
Eoghan Glynn wrote:
> Hi Bryan,
> 
> Did you mean the 2006/08 version (as opposed to 2005)? Otherwise known as
> WS-RM 1.1.
> 
Sorry... wsAddressing. I dont know the relationship between addressing 
ans WSRm.I was playing with WCF wsDualHttp binding.. and it is sending

http://www.w3.org/2005/08/addressing

headers. Is that something which is supported?

-- bk


Re: Version of WSRM

Posted by Eoghan Glynn <eo...@gmail.com>.
Hi Bryan,

Did you mean the 2006/08 version (as opposed to 2005)? Otherwise known as
WS-RM 1.1.

No concrete plans that I know of.

Now there is some good stuff in the 1.1 spec, in particular the
MakeConnection mechanism that gets around a lot of potential issues with
deferred ACKs and server-originated resends. So if there was interest in the
community, its certainly something that we could consider. I haven't really
got the sense of a big push for it as yet though.

Cheers,
Eoghan


2009/3/27 Bryan Kearney <bk...@redhat.com>

> Just wanted to follow up from an earlier conversation. Is 2005/08 support
> for wsrm in CXF yet? If not, is it on the roadmap?
>
> Thanks!
>
> -- bk
>