Hi Richard, further comments in-line ... > IMHO WS-RM 1.1 is the right way to do WS-RM, because this spec. > addresses unacknowledged anonymous messages use case (see WS-MakeConnection) > This usecase wasn't addressed in WS-RM 1.0 and so I consider > this old RM spec. broken.
Absolutely, the MakeConnection mechanism is the biggest motivation for moving to 1.1. > I don't see the relevant source code for CXF bus integration? Well the "bus integration" is just the addition of the RM interceptors to the Bus-level interceptor chains as opposed to the per-endpoint chains. > Could you give me the pointer to impl or test? The interceptors can be added explicitly to the Bus-level chains a la: http://svn.apache.org/viewvc/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/ws/rm/rminterceptors.xml?revision=773965 or implicitly by setting the <wsrm-mgr:reliableMessaging> feature on the Bus instance, e.g.: http://svn.apache.org/viewvc/cxf/trunk/distribution/src/main/release/samples/ws_rm/src/demo/ws_rm/server/ws_rm.xml?view=co > And how is the integration with other WS-* technologies? Well WS-RM requires WS-Addressing, so these will always be working together. What other specific WS-* services did you have in mind? > I mean do CXF WS-RM support e.g. WS-RM with WS-Security? I don't believe we've done any specific testing of WS-Security with WS-RM. Dan may have a better sense of this, but off the top of my head there *may* be issues with re-transmitted messages (e.g. replay detection may get in the way, though I guess if the message went un-acknowledged in the first place, the original message may never have been seen by the WS-Sec layer). > If I have two RM responses comming from the server (I mean RM responses with real SOAP response). > How this is handled? User should take care of that there can be more than just one async SOAP response? > What if client will use synchronous JAX-WS api? There is no problem with a client having multiple outstanding requests to the same server/endpoint. WS-Addressing message correlation will ensure that each response is correlated to the corresponding request (requests contain a <wsa:MessageID> header which is then referenced in the response's <wsa:RelatesTo> header). This is true whether the request is made via JAX-WS async (a purely client-side thread-based mchanism) and/or is decoupled (in which case the server sends the response over a *separate* server->client connection). Similarly it would also be true when the WS-RM 1.1 MakeConnection mechanism is supported. > Well this should be addressed in JAX-WS spec otherwise this would leave to proprietary client side API > for manipulating the client RM store. Let's see what will come out with next metro release. AFAIK > the Sun folks are working on RM 1.1 at the moment there. Yes, it would have to be proprietary if the JAX-WS spec doesn't address this issue. But when you say "should be addressed in the JAX-WS spec", do you mean in 2.3? I haven't heard that JAX-WS 2.2 will address this. Cheers, Eoghan 2009/6/18 Richard Opalka <ropa...@redhat.com> > Hi Eoghan, > > see in lined comments below: > > Richard > > Eoghan Glynn wrote: > >> Hi Richard, >> >> Apologies for the delay in replying. >> > NP > >> Please see my comments in-line. >> >> 2009/6/15 Richard Opalka <ropa...@redhat.com>: >> >> >>> what's the current state of CXF WS-RM? >>> >>> >> >> See below. >> >> >> >>> I'm asking because we'd like to integrate probably >>> WS-RM in our JBossWS CXF integration. >>> >>> >> >> Great that you're thinking of using CXF WS-RM. >> >> >> >>> The main questions are: >>> * Which WS-RM specs are supported now (I know about 1.0, is 1.1 supported >>> already)? >>> >>> >> >> Only WS-RM 1.0 (2005/02) is supported as yet. This was the current >> version of the spec when the original RM implementation was done as >> part of the Celtix project (the precursor to CXF). >> >> We've had some interest in WS-RM 1.1 and I intend to do a costing on >> the implementation effort soon, and hopefully will get the time to >> implement support for it in the CXF 2.3 timeframe. >> >> > IMHO WS-RM 1.1 is the right way to do WS-RM, because this spec. > addresses unacknowledged anonymous messages use case (see > WS-MakeConnection) > This usecase wasn't addressed in WS-RM 1.0 and so I consider > this old RM spec. broken. > >> >> >>> * Is QoS (Quality of Service) ensured in CXF WS-RM implementation? >>> >>> >> >> Well yes, in so far as the qualities of service envisaged by the WS-RM >> spec as concerned. So for example the policy with regard to ordering >> and duplicates may be asserted via the >> /ws-rm-policy:RMAssertion/ws-rm:deliveryAssurance element in config >> (see schema[1]). >> >> However other QoS typically available in the MOM world, such as >> message expiration/TTL and priority, are not part of WS-RM. >> >> > I'm asking about 2.4 Delivery Assurances (see WS-RX 1.1 specification) > Thus I consider you respond "yes" from this point of view ;) > >> >> >>> * Is current CXF WS-RM implementation tightly coupled with Endpoint? >>> >>> >> >> Well, CXF WS-RM can be configured on a per-endpoint basis, or for the >> entire Bus. >> >> > I don't see the relevant source code for CXF bus integration? > Could you give me the pointer to impl or test? > >> However, internally the WS-RM layer creates an RMEndpoint for each >> org.apache.cxf.endpoint.Endpoint with which a reliable exchange >> occurs. >> >> So that sense there is a certain one-to-one-ness going on. Is that >> what you meant by being tightly coupled? >> >> Or were you more thinking of using WS-RM to mediate message exchanges >> with something other than CXF endpoints? >> >> > And how is the integration with other WS-* technologies? > I mean do CXF WS-RM support e.g. WS-RM with WS-Security? > > >> >>> * Is there some API for client side when receiving undelivered messages? >>> >>> >> >> By undelivered messages, do you mean un-acknowledged messages that >> have been resent? >> >> If the original client is still running, then the retransmitted >> response message will be delivered to the application in the normal >> way (either by virtue of the invoking client thread being blocked, or >> via a callback or pollable for an asynchronous invocation). >> >> > If I have two RM responses comming from the server (I mean RM responses > with real SOAP response). > How this is handled? User should take care of that there can be more than > just one async SOAP response? > What if client will use synchronous JAX-WS api? > >> However, if the client application has been restarted since the >> original request was sent, then there is no way currently for the >> resent message to rendez-vous with the application logic. This >> deficiency was clear to us when the original RM implementation was >> done, and we had at the back of our mind the intention to do something >> about it, via some sort of persistent callback mechanism. Any ideas >> you might have in this regard would be welcome. >> >> > Well this should be addressed in JAX-WS spec otherwise this would leave to > proprietary client side API > for manipulating the client RM store. Let's see what will come out with > next metro release. AFAIK > the Sun folks are working on RM 1.1 at the moment there. > >> >> >>> Where I could find it? >>> * Is there some detailed architecture documentation about CXF WS-RM? >>> >>> >> >> No, unfortunately. >> >> > Hmm :( > >> Hope this helps, >> Eoghan >> >> [1] >> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/rm/src/main/resources/schemas/configuration/wsrm-manager-types.xsd >> >> > > > -- > Richard Opalka > JBoss Software Engineer > > Mail: ropa...@redhat.com > Mobile: +420 731 186 942 > >
