Hi Aki, I understand your point and agree that things didn't get simpler. But I suppose that's often the case .
Currently I am working on a governmental standard where reliable messaging is an important subject that we need to address within the webservice domain. The general idea is that WS-RM is now mature/widely supported enough to be taken in the standard. To support this we are working on a pilot project where we use the CXF implementation. If the standard is accepted, the webservices implementation that require reliability will follow this standard using different products/frameworks. That's why interoperability it a very important topic. I will report issues on wsrm when I find them and will definitely try to work on a patch for it. It will be the first time that I participate in supplying patches so I probably will need some help to do it on the right way. With uploading your code, you mean it will be available in maven as snapshot-2.8.0? or do need to get the code somewhere else? Thanks! Regards, John On Thu, Feb 28, 2013 at 1:47 PM, Aki Yoshida <[email protected]> wrote: > 2013/2/28 John Li <[email protected]>: > > Hi Aki, > > > > Thanks for your response! > > Great to hear that you have a fix for this issue. It would be great if > you > > can upload it so I can maybe help with testing it? > > Currently we are working with a client/server implementation of both CXF > so > > there is no direct problem with the missing terminate response. But since > > WS-RM is getting more attention now and RSP 1.0 has been out for a while, > > it would be great that an important framework as CXF can support at least > > the WSRM part of this profile to 'ensure' interoperability. On difference > > of 1.0 and 1.1 we have found a list on the net that might help maybe? ( > > > http://metro.java.net/nonav/1.2/guide/Using_WS_ReliableMessaging_v1_1.html > ) > > > > If could also share your thoughts on the usage of this EP element in > offer > > that would be of great help for me as well! > > Many thanks in advance > > Hi John, > there are some useful things in 1.1 which fix some limitations of 1.0. > On the other hand, 1.0 was already complex and 1.1 didn't make the > protocol simpler. That's kind of its own limitation and reflected in > the usage. > > Which system will you be integrating with using WS-RM? > > In any case, if you find some issues, please report them and if you > can work on a patch, that would be also great. > > I'll upload the 1.1 terminate sequence stuff today. If you can verify > it, that would be great. > > regards, aki > > > > > Regards, > > John > > > > > > > > > > On Thu, Feb 28, 2013 at 11:37 AM, Aki Yoshida <[email protected]> wrote: > > > >> 2013/2/21 John Li <[email protected]>: > >> > 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? > >> > >> Hi John, > >> I don;t know about 1.2, but for the terminateSeqeunceResponse for 1.1, > >> I have a fix and I can upload it. The missing ep element stuff that > >> you mentioned, I have to look at it. don't know. > >> > >> regards, aki > >> > >> > > >> > 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 > >> >> > >>>>>> > >> >> > >>>>> > >> >> > >> >
