Hi Dennis & others, How is the progress on the WSRM 1.2 implementation? Currently I working with a client on a pilot where we use the WSRM implementation of Apache CXF. Though functionaly it works fine with the new namespace, we do have seen inconsistencies with the WSRM 1.1/1.2 specification. For example we see in the createSequence offer element that the endpoint element is missing, while it is defined as required in the 1.1/1.2 specification. Also we just saw that the TerminateSequenceResponse is not sent when the server receives the terminate sequence call from the client. As we compare the 1.0 and the 1.1/1.2 specification also this response was not defined in 1.0. As I also didn't see any specific Jira issues on this, I was wondering if the new 1.2 implemetation already includes the missing elements.
Besides the above I do have a specific question regarding the usage of the offer/endpoint that is more related to the specification in general. I hope you can help me on this. Since the createSequence already has a acksTo where WSRM lifecycle management calls are sent to, what is the exact usage of the offer/endpoint element? According the specs it should be: An RM Source MUST include this element, of type wsa:EndpointReferenceType (as specified by WS-Addressing). This element specifies the endpoint reference to which Sequence Lifecycle Messages, Acknowledgement Requests, and fault messages related to the offered Sequence are to be sent. But if we are providing an WS-addressing anonymous url as acksTo, apache CXF is only using the back channel to response (according spec). So is the offer/endpoint element used for lifecycle response messages that is initiated from the RMS? Any comment/help is appreciated. With kind regards, John On Wed, Jan 30, 2013 at 2:51 AM, <[email protected]> wrote: > Thanks, John, I'll keep you posted. > > The big problem I had with the WS-RMP changes is that I couldn't see any > way of doing them incrementally. I had to pretty much tear out the existing > RM policy handling and change over to a new approach, which meant working > locally until everything was fixed - and with ongoing changes to the base > code it was hard to keep up. I think I can probably rework what I'd done > before to allow piece-by-piece replacement, which should be much smoother. > > - Dennis > > John Li wrote .. > > Hi Dennis, > > > > Great! I have managed to get my server and client working with the 1.2 > > policies added to the wsdl. It seems the assertions are now ignored by > > wsrm > > module. In the jaxws features I have disabled the policies and then > > manually added required wsrm features that I needed. Now when the wsdl > > is > > requested, the right policies are shown while internally the wsrm > behaviour > > is configured by the bean configuration. > > > > Initially I thought that the client was working fine with the policies > > but > > it appears when I have changed the WSRM version like how Aki suggested > > in > > the previous mail without adding the features manually in the xml > > configuration, the createSequence is sent by WSRM with the right > namespace > > but the soap headers are missing. > > > > I don't know where I can help you with anything but if you see something > > that I can help with. Let me know. I will be glad to help > > > > With kind regards, > > John > > > > > > > > *John Li* > > > > Mobiel: +31621513273 > > Email: [email protected] > > *My Cubes B.V.* > > Boeingavenue 215 > > 1119 PD, Schiphol-Rijk > > Nederland > > > > > > De inhoud van dit bericht is alleen bestemd voor de geadresseerde en kan > > vertrouwelijke of persoonlijke informatie bevatten. Als u dit bericht > > onbedoeld heeft ontvangen verzoeken wij u het te vernietigen en de > afzender > > te informeren. Het is niet toegestaan om een bericht dat niet voor u > > bestemd is te vermenigvuldigen dan wel te verspreiden. Aan dit bericht > > inclusief de bijlagen kunnen geen rechten ontleend worden, tenzij > > schriftelijk anders wordt overeengekomen. My Cubes B.V. aanvaardt geen > > enkele aansprakelijkheid voor schade en/of kosten die voortvloeien uit > > onvolledige en/of foutieve informatie in e-mailberichten. > > > > This message is intended for the exclusive use of the person(s) mentioned > > as recipient(s) and may contain personal and/or confidential information. > > If you have received this message in error, please notify the sender and > > delete this message from your system immediately. Directly or indirectly > > copying, disclosing, distributing, printing, publicising and/or in any > > way > > using this message or any part thereof by any means is strictly > prohibited > > if you are not the intended recipient(s). This message and any associated > > attachments cannot be deemed as legally binding under any circumstances > > without the express written consent from My Cubes B.V.. My Cubes B.V. is > > not responsible for any loss and/or damages arising from any errors > and/or > > omissions in its e-mail messages. > > > > > > On Tue, Jan 29, 2013 at 7:38 PM, Dennis Sosnoski <[email protected]> > wrote: > > > > > Hi John, > > > > > > I did most of the work required for WS-RMP support last year, when I > > > opened https://issues.apache.org/**jira/browse/CXF-4139< > https://issues.apache.org/jira/browse/CXF-4139>. > > > But I got distracted by other projects, and my work-in-progress was > > > outdated by other changes. It's coming up on the one year anniversary, > > so > > > probably time to give this another try. I'll look into putting the > pieces > > > back together next week. > > > > > > Regards, > > > > > > - Dennis > > > > > > > > > > > > On 01/22/2013 09:24 PM, John Li wrote: > > > > > >> Hello Aki, > > >> > > >> Thanks for your help. The settings work as expected. > > >> I wil contact Dennis about the latest status on this issue and > pointers > > to > > >> where I could possibly start with contributing to this. Meanwhile I > > setup > > >> the environment and get all the unit tests up and running so I can > start > > >> directly when I have some more information. > > >> > > >> With kind regards, > > >> John > > >> > > >> > > >> On Fri, Jan 18, 2013 at 11:00 AM, Aki Yoshida<[email protected]> > wrote: > > >> > > >> Hi John, > > >>> if you are using the sample Client from samples/ws_rm, you can set > > the > > >>> protocol as > > >>> > > >>> import org.apache.cxf.endpoint.**Client; > > >>> import org.apache.cxf.frontend.**ClientProxy; > > >>> ... > > >>> Client client = ClientProxy.getClient(port); > > >>> client.getRequestContext().**put(RMManager.WSRM_VERSION_** > > >>> PROPERTY, > > >>> RM11Constants.NAMESPACE_URI); > > >>> client.getRequestContext().**put(RMManager.WSRM_WSA_** > > >>> VERSION_PROPERTY, > > >>> Names.WSA_NAMESPACE_NAME); > > >>> > > >>> Regarding CXF-4139, as RMP 1.1 assertions are instantiated but > > >>> currently not used, as CXF's WS-RM uses 1.0 assertions internally to > > >>> read the configuration values like retransmission time etc. I added > > >>> some additional configuration properties in the manager schema > > >>> sometime ago to expose the options that are not defined in neither > > >>> policy versions or not in 1.1. Dennis mentioned me of this policy > > >>> unification ticket at that time. You can ping him and ask him if he > > >>> has some update. If you can look into it and contribute, that sounds > > >>> great. > > >>> > > >>> thanks. > > >>> regards, aki > > >>> > > >>> 2013/1/17 John Li<[email protected]>: > > >>> > > >>>> Hello Aki > > >>>> > > >>>> Thanks for your quick response! > > >>>> I am looking into your suggestion and I wanted to try this approach > > >>>> > > >>> before > > >>> > > >>>> I set set the bean property through Spring. But I saw in the > > >>>> org.apache.cxf.ws.rm.Proxy file that the client is always > instanciated > > >>>> in > > >>>> the 'invoke' method. So I am not sure how I can change this runtime > > >>>> > > >>> setting > > >>> > > >>>> without overriding the createClient method in the Proxy class. But > > I > > >>>> figured that shouldn't be the way to go so I went for the property > > >>>> configuration solution. Can you maybe point me to the place where > > I can > > >>>> access the client in the correct way? Thanks! > > >>>> > > >>>> Also having seen issue > > >>>> CXF-4139<https://issues.**apache.org/jira/browse/CXF-**4139< > https://issues.apache.org/jira/browse/CXF-4139>> > > >>>> it > > >>>> looks like this task has been defined for quite a while. Is there > > >>>> already > > >>>> some activity on this? Since I will be working on wsrm for a couple > > of > > >>>> months (at least), maybe I can help/contribute with anything on this > > >>>> > > >>> part? > > >>> > > >>>> Many thanks in advance! > > >>>> > > >>>> With kind regards, > > >>>> John > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> On Thu, Jan 17, 2013 at 3:52 PM, Aki Yoshida<[email protected]> > wrote: > > >>>> > > >>>> Hi John, > > >>>>> That generic property setting option was marked deprecated many > years > > >>>>> go, so it's not good to use it. The explicit WSA namespace setting > > in > > >>>>> the bean configuration was added when WS-RM 1.1 was added. But I > > think > > >>>>> it is confusing to set these namespace properties in the RM > > >>>>> feature/manager level, as the server side endpoint can accept both > > >>>>> versions. Maybe that is why Dennis who worked on RM1.1 > implementation > > >>>>> didn't add the RM namespace setting property to the bean > > >>>>> configuration. > > >>>>> > > >>>>> So how can you tell the client which WSRM version to use? You can > > >>>>> switch it by setting the appropriate runtime context properties. > > For > > >>>>> example, to use the standard WSRM11 and WSA combination, you can > > >>>>> write: > > >>>>> > > >>>>> client.getRequestContext().**put(RMManager.WSRM_VERSION_** > > >>>>> PROPERTY, > > >>>>> RM11Constants.NAMESPACE_URI); > > >>>>> > > >>>>> client.getRequestContext().**put(RMManager.WSRM_WSA_** > > >>> VERSION_PROPERTY, > > >>> > > >>>> Names.WSA_NAMESPACE_NAME); > > >>>>> > > >>>>> For the server side, both versions 1.0 and 1.1 are automatically > > >>>>> accepted. So you don't need to configure anything special. > > >>>>> > > >>>>> regards, aki > > >>>>> > > >>>>> 2013/1/17 John Li<[email protected]>: > > >>>>> > > >>>>>> Hello all, > > >>>>>> > > >>>>>> I am currently working on an assignment to implement a pilot > showing > > >>>>>> > > >>>>> the > > >>> > > >>>> interoperability of WSRM between different technologies. For the > > >>>>>> > > >>>>> reference > > >>>>> > > >>>>>> implementation I will be using Apache CXF to provide both a server > > for > > >>>>>> other clients to connect to and to provide a sample client > > >>>>>> > > >>>>> implementation > > >>> > > >>>> in Apache CXF. > > >>>>>> > > >>>>>> After downloading and getting the wsrm sample application up and > > >>>>>> > > >>>>> running > > >>> > > >>>> I > > >>>>> > > >>>>>> have seen in the SOAP messages that WSRM 1.0 is the default > protocol > > >>>>>> > > >>>>> since > > >>>>> > > >>>>>> the namespace is still ' > http://schemas.xmlsoap.org/**ws/2005/02/rm< > http://schemas.xmlsoap.org/ws/2005/02/rm> > > >>>>>> '. > > >>>>>> > > >>>>>> Actually the CXF website is not mentioning anything about the > > >>>>>> implementation of wsrm 1.1. After some research I found that from > > >>>>>> > > >>>>> version > > >>> > > >>>> 2.5.1 the wsrm 1.1/1.2 has been added to the release. My problem is > > >>>>>> > > >>>>> that > > >>> > > >>>> I > > >>>>> > > >>>>>> could not find how to activate the 1.1 protocol. Specifically I > > need > > >>>>>> > > >>>>> the > > >>> > > >>>> RMS to send out wsrm 1.1 messages out instead of 1.0 messages. The > > >>>>>> > > >>>>> RMD I > > >>> > > >>>> can see it will react based on the message that comes in so that > will > > >>>>>> automatically select the right protocol version. > > >>>>>> > > >>>>>> After looking through the source code of the WSRM implementation > > I > > >>>>>> > > >>>>> found > > >>> > > >>>> the required settings in the RMManager but based on the > > >>>>>> current reliableMessaging configurations the rmNamespace is not > > a > > >>>>>> configuration option. Although I can see in the wsrm-manager.xsd > > the > > >>>>>> following statement: > > >>>>>> > > >>>>>> <xs:any namespace="http://www.** > springframework.org/schema/**beans< > http://www.springframework.org/schema/beans> > > >>>>>> " > > >>>>>> processContents="lax" minOccurs="0" maxOccurs="unbounded"> > > >>>>>> <xs:annotation><xs:**documentation> > > >>>>>> Deprecated. To support the older spring:property element that is > > no > > >>>>>> > > >>>>> longer > > >>>>> > > >>>>>> used > > >>>>>> </xs:documentation></xs:**annotation> > > >>>>>> </xs:any> > > >>>>>> > > >>>>>> I could only change this configuration by using the spring > property > > >>>>>> element. So to make my client implementation sending out wsrm 1.1 > > >>>>>> > > >>>>> messages, > > >>>>> > > >>>>>> I have used the following two statements in the reliableMessaging > > >>>>>> configuration: > > >>>>>> > > >>>>>> <wsrm-mgr:**RM10AddressingNamespace uri=" > > >>>>>> > > >>>>> http://www.w3.org/2005/08/**addressing< > http://www.w3.org/2005/08/addressing> > > >>>>> " > > >>>>> > > >>>>>> /> > > >>>>>> <property name="RMNamespace" value=" > > >>>>>> http://docs.oasis-open.org/ws-**rx/wsrm/200702< > http://docs.oasis-open.org/ws-rx/wsrm/200702> > > >>>>>> "/> > > >>>>>> > > >>>>>> Though now it seems to work, the property element is deprecated > > so I > > >>>>>> > > >>>>> am > > >>> > > >>>> wondering if I am doing it on the correct way or is there a better > > >>>>>> > > >>>>> way to > > >>> > > >>>> do this? > > >>>>>> > > >>>>>> Also I see in the current implementation that the usage of wsrmp > > 1.0 > > >>>>>> settings is defined in the wsrm-manager.xsd and wsrmp 1.1/1.2 > elements > > >>>>>> > > >>>>> are > > >>>>> > > >>>>>> not supported. As it also is stated in issue > > >>>>>> https://issues.apache.org/**jira/browse/CXF-4139< > https://issues.apache.org/jira/browse/CXF-4139>. > > >>>>>> Though the wsrmp > > >>>>>> > > >>>>> 1.1/1.2 > > >>>>> > > >>>>>> has totally different elements, the most important delivery > assurance > > >>>>>> settings are already supported by Apache CXF wsrm-manager > > >>>>>> > > >>>>> configurations. > > >>> > > >>>> My question on this is: What is the impact for Apache CXF when a > WSDL > > >>>>>> > > >>>>> is > > >>> > > >>>> provided that uses the wsrmp 1.1/1.2 policy elements? Will they be > > >>>>>> > > >>>>> ignored > > >>>>> > > >>>>>> and you need to configure these settings manually through the > manager > > >>>>>> > > >>>>> or > > >>> > > >>>> does CXF automatically convert them to the internal manager > settings? > > >>>>>> > > >>>>>> I hope someone can help me with clarifying my questions. > > >>>>>> > > >>>>>> Many thanks in advance! > > >>>>>> > > >>>>>> John Li > > >>>>>> > > >>>>> >
