server side protocol variation handling in WS-RM again

[Aki Yoshida <el...@googlemail.com>]

Hi Dennis,

While ago, I mentioned the problem that I was having with the protocol
variations in WS-RM.

http://cxf.547215.n5.nabble.com/a-quesiton-on-CXF-2-5-WS-RM-s-protocol-variation-handling-td4710027.html

I would like to come back to this problem, as I am having a few
problems with server side sequence and message recoveries.

To begin with, I assume we can assign a specific protocol variation to
a particular sequence. In other words, we can assume each sequence has
a fixed protocol version that was used to create that sequence.

However, this assumption is broken at the RM endpoint recovery. For
the client endpoints, the sequences are assigned to the configured
static protocol variation. If you dynamically changed the protocol
variation, your sequence would be reassigned to the wrong protocol
variation. For the server endpoints, the sequences are replicated for
each protocol variation and simply assigned to their original protocol
variations. And this latter is causing an issue in several areas such
as
- the RM endpoint registration in JMX (because each endpoint gets
registered for three variations)
- each stored message gets recovered per each variation (this only
happens at the server side because the server side code is explicitly
starting each endpoint per protocol variant)..

To solve these issues, I would like to have one RM endpoint that can
support a different protocol variation per sequence. We must also
store the protocol variation in the RMStore so that the sequence and
message recoveries will find the correct protocol variations at
restart.

How do you think?

Thanks.

Regards, Aki

Re: server side protocol variation handling in WS-RM again

[Aki Yoshida <el...@googlemail.com>]

Hi Dennis, all,

In my local trunk, I modified the RM-endpoints et al so that we have
one RMEndpoint per an application endpoint which handles all three
protocol variations. This RMEndpoint has the information about the
three protocol variations so that we can pass the protocol variation
instance to some of its methods to have it behave specifically for
that protocol.

To get the protocol variation information later in many places, after
the protocol variation is determined, the message\s property is set
accordingly. In that way, we can get the protocol variation from the
message or from the sequence so that we have the protocol variation
whenever we need within various processing methods.

This change fixes the problems that I mentioned before and also
simplifies the managed entities. With this change, we can revert the
RMStore's getSequence method to the old one that had only the endpoint
identifier argument and not the protocol variation argument. This
protocol variation argument was not used to find the sequences of that
particular protocol variation but used to instantiate a sequence that
was read from the storage because the sequence's ctor needed the
protocol variation. By storing the protocol variation with the
sequence, we don't need this argument as we can fully recover the
original sequences without it.

All the ws-rm tests and systests are running fine. So, I think it is
working fine and I would like to submit this change into
2.6.0-SNAPSHOT. I was wondering if this is still okay because of the
shortly planned 2.6.0 release.

Any thought?

Thanks.
Regards, aki

2012/3/22 Aki Yoshida <el...@googlemail.com>:
> Hi Dennis,
>
> While ago, I mentioned the problem that I was having with the protocol
> variations in WS-RM.
>
> http://cxf.547215.n5.nabble.com/a-quesiton-on-CXF-2-5-WS-RM-s-protocol-variation-handling-td4710027.html
>
> I would like to come back to this problem, as I am having a few
> problems with server side sequence and message recoveries.
>
> To begin with, I assume we can assign a specific protocol variation to
> a particular sequence. In other words, we can assume each sequence has
> a fixed protocol version that was used to create that sequence.
>
> However, this assumption is broken at the RM endpoint recovery. For
> the client endpoints, the sequences are assigned to the configured
> static protocol variation. If you dynamically changed the protocol
> variation, your sequence would be reassigned to the wrong protocol
> variation. For the server endpoints, the sequences are replicated for
> each protocol variation and simply assigned to their original protocol
> variations. And this latter is causing an issue in several areas such
> as
> - the RM endpoint registration in JMX (because each endpoint gets
> registered for three variations)
> - each stored message gets recovered per each variation (this only
> happens at the server side because the server side code is explicitly
> starting each endpoint per protocol variant)..
>
> To solve these issues, I would like to have one RM endpoint that can
> support a different protocol variation per sequence. We must also
> store the protocol variation in the RMStore so that the sequence and
> message recoveries will find the correct protocol variations at
> restart.
>
> How do you think?
>
> Thanks.
>
> Regards, Aki