I personally would get started with WS-PO and WS-POA and get an initial (basic) implementation working that supports the requirements of WS-RM. In that way I would not have to duplicate the configuration effort.
OK, we're reading ws-policy too. May be we could talk togheter in future, as soon as we've analyzed these specs, in order to better understand how to proceed and start contributing on this issue.
Ok, please ping me when you're done with studingthe three specs
I'm studying the specs to, mainly the ws-rm at the moment. At the same time, I'm thinking about ways to implement it, high level that is. Since the sequences etc do need some kind of persistency and there is some kind of flow, I'm thinking of using jBPM (jpdl?) for this. Especially since I will eventually need ebMS 3.0 as well, which uses ws-rm. Any thoughts on this?
IMO JBPM is the wrong approach. Try to keep it simple and external dependencies to a minimum. RM sequence management is really simple and actually only knows a few conditions. RM source and RM destination just figure out the delta and make the source resubmit the missing messages.
Looking at the overall picture (like for instance the way a RM destination treats incomplete sequence termination) I agree that it might be regarded as a state machine or could be desinged as such. But IMO this is an implementation detail and JBPM probably adds too much overhead for too little gain. You could probably come up with a simple state machine yourself.
Regarding the persistence:
I think the only relevant bit to this is the need for a pluggable persistence mechanism. In the beginning some JDBC persistence manager might be sufficient. You may want to take alook at JBossMQ for instance, how they designed it.
Reading the specs I tend to agree. They are so limited. No things like:
- number of retries
- retry interval
What other specs are those in? I am starting to hate the ws-hell (no offence to you guys) and long back to the x.400 or the best, ebXML-MS specs... those were 'clean'.
If these other parts come in, it becomes a REAL messaging system. JMS implementations lack a lot of functionality to on this part, regarding retries sequences etc... but for the basic ws-rm (rx) it might be sufficient IF all other AS' support the same subset as JBossMQ/Messaging
To be continued