Hi Balaji,
I believe Gary is planning to write up a how-to on the CXF wiki. But in the meantime, you could have a look at the CXF code, specifcally: - MultiplexDestination.java: basic API for generation of fine-grained EPRs adorned with uniqueID - AbstractMultiplexDestination.java: example transport-neutral mechanism - AbstractHTTPDestination.java: example transport-specific mechanism for HTTP - rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/ServiceImpl.java: JAX-WS 2.1 style extension to Service.getPort() to allow for binding on application-supplied EPR - systests/src/test/java/org/apache/cxf/systest/factory_pattern: system test tying it all together All available in the CXF repo from revision 530804. Cheers, Eoghan > -----Original Message----- > From: Mosur Ravi, Balaji [mailto:[EMAIL PROTECTED] > Sent: 20 April 2007 15:45 > To: yoko-dev@incubator.apache.org > Subject: RE: WS-Addressing support in Yoko > > Thanks Eoghan... > > I would like to encode the WS-A properties in the > ServiceContext, so that we can take advantage of the > transport neutral way of doing this. > But I would also like to understand the other transport > specific way of passing in the information. > > Is there a wiki where these things are documented? Or can you > point me to a piece of code that I can take a look at? > > Thanks > > Balaji > > -----Original Message----- > From: Glynn, Eoghan [mailto:[EMAIL PROTECTED] > Sent: Friday, April 20, 2007 10:21 AM > To: yoko-dev@incubator.apache.org > Subject: RE: WS-Addressing support in Yoko > > > > > > -----Original Message----- > > From: Mosur Ravi, Balaji [mailto:[EMAIL PROTECTED] > > Sent: 20 April 2007 14:57 > > To: yoko-dev@incubator.apache.org > > Subject: RE: WS-Addressing support in Yoko > > > > Hi, > > > > Currently, the ws-addressing support in yoko is limited. It > > is just using EndpointReferenceType. But we might think of > > extending it to include the other WS-A properties. Can you > > describe briefly what you mean by wsam:Addressing policy? > > <wsam:Addressing> is a WS-Policy that can be used to enable > WS-Addressing for a particular subject in the WSDL (e.g. a port, or > service, or binding). > > It can also be used to assert various requirements and capabilities > related to WS-A, e.g. that the presence of WS-A properties in incoming > messages is mandatory, or that non-anonymous responses are supported. > > CXF can consume these policy assertions and auto-magically include the > corresponding interceptors into the client-side interceptor chain. > > Now if a server was to expose *both* SOAP and CORBA bindings via the > same <wsdl:service>, then asserting the policy at the service level > would obviously be inappropriate as Yoko couldn't match the > requirement > with the corresponding capability. Hence it would only make sense to > attach the Addressing policy to the SOAP binding. Which is fine. > > My main interest in this currently is figuring out which > policies would > realistically tend to be asserted for a specific binding, but > would also > have a "logical" component that could stand on its own if the binding > were by-passed completely, as would be the case for an optimized > colocated dispatch. Addressing seemingly falls into this category. > > Would it make sense to extend Yoko to encode WS-A properties in > IOP::ServiceContexts? Well one obvious use-case is a default-servant > type pattern where the individual fine-grained targets are > distinguished > via a uniqueID or marker passed via WS-A reference parameters. This is > the default transport-neutral way of doing this in CXF (which I just > committed today on behalf of Gary Tully). > > However CXF also allows a transport-specific alternative > mechanism to be > supported, e.g. buring the uniqueID into a URI for HTTP. And > for CORBA, > the obvious approach would be to burn it into the object key. > So I guess > the point is that support for WS-A reference parameters wouldn't be > required to make the CXF version of the default-servant > pattern work for > Yoko. > > > Also, what type of policy assertions are you planning for the > > soap cases? > > Other examples that typically only make sense in the SOAP > case would be > policies to enable WS-RM (currently supported by CXF), MTOM (not yet > supported but easy to do) and WS-SecurityPolicy (not yet supported but > harder to do, partly due the way WS-Security is implemented in CXF, > partly due to its intrinsic complexity). > > Cheers, > Eoghan > > > > - Balaji > > > > > > > > -----Original Message----- > > From: Glynn, Eoghan [mailto:[EMAIL PROTECTED] > > Sent: Friday, April 20, 2007 9:36 AM > > To: yoko-dev@incubator.apache.org > > Subject: WS-Addressing support in Yoko > > > > > > > > Folks, > > > > I'm curious about the extent of WS-Addressing support in Yoko. This > > relates to a scenario in CXF whereby a policy might be > > usefully asserted > > in the WSDL for one binding but not another. The canonical > > example I had > > in mind was the <wsam:Addressing> policy being asserted for the SOAP > > binding but not the CORBA binding. The assumption being that > > there's no > > standard way of encoding the WS-A message addressing > > properties (wsa:To, > > wsa:ReplyTo, wsa:MessageID, wsa:isReferenceParamater etc.) as > > part of a > > CORBA payload, so it would only make sense to aggregate these > > properties > > in the SOAP case. > > > > However I was interested to see that Yoko includes a > > bank_ws_addressing > > demo. A quick look at the code suggests that the extent of > > WS-A support > > is really just the usage of the EndpointReferenceType, and not the > > encoding of the WS-A properties on the wire. I'd be happy to be > > corrected on this point though, for example if the WS-A > > properties were > > encoded by Yoko as as an IOP::ServiceContext or some-such. > > > > Cheers, > > Eoghan Glynn > > [CXF committer] > > > > >
