WS-RM Prototype Ready for Preview

[ropalka]

Hi Team/Community,

WS-RM Prototype is ready and available for preview. The WS-RM test suite is executed against real endpoints and combinations with WS-Security are covered as well.
For documentation take a look here:
http://jbws.dyndns.org/mediawiki/index.php?title=WS_Reliable_Messaging
To execute the test suite, just type: ./build.sh -Dtest=jaxws/wsrm test on commandline.
Please review the tests provided in the test suite and provide your feedback, comments, criticism to this forum.

[thomas.diesler]

Thanks Richard, well done.

[ropalka]

Hi Folks,

I'm refactoring current WS-RM code base to remove proprietary user API completely.
However there is the problem with closing the sequences. How to detect when to close the sequences? The only reasonable point for me is to register the JVM shutdown hook, However this won't work in our test suites (because deployed webservices are undeployed from server before JUnit test exit).
I see that Sun's metro uses proprietary api too to close the sequences. See:

http://blogs.sun.com/enterprisetechtips/entry/testing_interoperability_between_metro_and

Other possible option that comes in my mind is to don't close sequences at all, because this step isn't required by RM protocol. Closing the sequence is optional protocol operation.

[thomas.diesler]

Other possible option that comes in my mind is to don't close sequences at all, because this step isn't required by RM protocol. Closing the sequence is optional protocol operation.

This seems reasonable, with the option to use proprietary API when needed.

[thomas.diesler]

Hi Richard,

while working with the RM implementation I was wondering about the Quality of Service (QoS) aspect of WS-RM. In my understanding the RM Sender/Receiver must be high available (HA) components such that the Client can (always) communicate with the RM Sender and likewise the RM Sender can always communicate with the RM Receiver.

Client <--> RM Sender <-------> RM Receiver <--> Endpoint
 QoS QoS

On the contrary, if the RM Sender is coupled with the client proxy or the RM Receiver is coupled with the Endpoint, it would in my opinion defeat the purpose of RM. In other words, if the RM Receiver is only available if the Endpoint is available, the client might as well talk to the Endpoint directly.

Using your implementation, would it (eventually) be possible to deploy the RM Sender/Receiver as separate HA components (i.e. on dedicated boxes)?

[ropalka]

On the contrary, if the RM Sender is coupled with the client proxy or the RM Receiver is coupled with the Endpoint, it would in my opinion defeat the purpose of RM. In other words, if the RM Receiver is only available if the Endpoint is available, the client might as well talk to the Endpoint directly.

Using your implementation, would it (eventually) be possible to deploy the RM Sender/Receiver as separate HA components (i.e. on dedicated boxes)?

Hi Thomas,

you're absolutely right. The fact that both RM Sender / Receiver are coupled with client proxy/endpoint defeat the purpose of RM.
The reason I decided to provide the initial prototype this way was to support WS-Security as well.
If we will want to support WS-Security and decouple both RM Sender / Receiver we need to move WS-Security one level lower (that is to move it from handler to transport marshallers).
Other option is to forget about WS-RM + WS-Security combination and to decouple the RM Sender/Receiver.

[ropalka]

Using your implementation, would it (eventually) be possible to deploy the RM Sender/Receiver as separate HA components (i.e. on dedicated boxes)?

No with the current version of prototype :-(

[thomas.diesler]

Thanks.

I propose to get the initial implementation going first. Then we investigate the pros/cons of a standalone decoupled RM implementation.

After all, if a RM implementation cannot provide reliable messaging (because of its coupling) - it is pointless to use it from the customer point of view ;-)

[ropalka]

I propose to get the initial implementation going first. Then we investigate the pros/cons of a standalone decoupled RM implementation.

IMO RM Sender/Receiver must be decoupled from client proxy/endpoint. However I was following just three goals when writing this first RM prototype:

* finish it till the end of this year
* provide the functional test suite covering all scenarios from Microsoft interop
* cover the WS-Security combinations too

After all, if a RM implementation cannot provide reliable messaging (because of its coupling) - it is pointless to use it from the customer point of view ;-)

Again, you're absolutely right and I'm happy you're diving into RM dilemma too because our communication about it becomes meaningful ;-) I'm figuring out this pointless RM implementation, but it's not final solution. It's just first prototype that works. But there's still a lot of work to make it better and more meaningful not only from customer point of view.

[asoldano]

Hi Richard,
finally found some time to take a look at your RM code. Well done, for sure.
Soon I'll comment about what you and Thomas are discussing now (the HA etc.), I need to investigate a bit more before.
Speaking of the efforts aimed at simplifying the RM use, I think you might evaluate (if you have not done this yet ;-) ) whether it is possible to install the RM handler through the RMPolicyAssertionDeployer. This would eventually remove the requirement for a custom endpoint configuration (of course eventual security still requires configuration)

[ropalka]

Hi Richard,

while working with the RM implementation I was wondering about the Quality of Service (QoS) aspect of WS-RM. In my understanding the RM Sender/Receiver must be high available (HA) components such that the Client can (always) communicate with the RM Sender and likewise the RM Sender can always communicate with the RM Receiver.

Client <--> RM Sender <-------> RM Receiver <--> Endpoint
 QoS QoS

Using your implementation, would it (eventually) be possible to deploy the RM Sender/Receiver as separate HA components (i.e. on dedicated boxes)?

I created a bug

http://jira.jboss.org/jira/browse/JBWS-1976

and investigation results + identified issues will be accumulated in the following jbossws-dev forum topic:

http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4126102#4126102