cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <elak...@gmail.com>
Subject Re: Usage of WS-RM 1.1 in the client configuration
Date Thu, 28 Feb 2013 10:37:14 GMT
2013/2/21 John Li <john@mycubes.nl>:
> 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, <dms@sosnoski.com> 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: john@mycubes.nl
>> > *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 <dms@sosnoski.com>
>> 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<elakito@gmail.com>
>>  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<john@mycubes.nl>:
>> > >>>
>> > >>>> 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<elakito@gmail.com>
>>  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<john@mycubes.nl>:
>> > >>>>>
>> > >>>>>> 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
>> > >>>>>>
>> > >>>>>
>>

Mime
View raw message