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 12:47:08 GMT
2013/2/28 John Li <john@mycubes.nl>:
> 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 <elakito@gmail.com> wrote:
>
>> 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