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'.
>
> 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";
> 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";
> />
> <property name="RMNamespace" value="
> 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. 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
