2009/3/31 Bryan Kearney <[email protected]> > 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
