cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Li <j...@mycubes.nl>
Subject Re: Usage of WS-RM 1.1 in the client configuration
Date Thu, 28 Feb 2013 12:11:20 GMT
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

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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message