This is an interesting issue. I used to believe it shouldn't at all in normal usage, because I want to be able to turn on or off WSRM without having to change my application code.He then goes on to describe how WS-RM is exposed to the application in Apache's open source WSRM implementation, Sandeesha by the use of a SequenceKey.
But there are some aspects that require some interaction with the application. The first one is knowing how to associate messages with a particular reliable sequence. For example, I may have multiple stubs running in an application server on behalf of multiple clients. I could aggregate all the requests into a single sequence, which will be more efficient in terms of the protocol, and the overhead of managing large numbers of sequences. But if the endpoint is doing ordered delivery, it now may end up holding up messages from one client while messages for another are delivered, which might not be the desired behaviour.
Certainly, this is one way to associate a reliable messaging sequence with specific aspects of the application. However, my personal take is that this exposure of the underlying reliable messaging infrastructure, even though somewhat abstracted, is misguided.
I believe that Paul's initial position, that WS-RM should NOT be exposed via the API, but rather through deployment configuration of the application component, is the preferred approach.
The same abstraction that Paul describes, of associating specific messages with a sequence can be achieved through other means than exposure via the API, such as through the deployment descriptor.
Paul continues with the following:
The same applies to the idea of a LastMessage. Sandesha lets you mark a message as being the last in a sequence. This is something that generally only the application designer can know, so again I think it would be great to promote this onto the standard API.While the recently adopted Committee Drafts of the OASIS WS-RM spec still retains the
Paul's post continues:
The final issue is letting the application know how the RM delivery is getting on. In general we would like to trust that every message is delivered successfully, but things happen. There will be occasions where timeliness is also important. I see two potential approaches for this. The first is to expose via a management interface a view of the whole sequence. So in Java, we could make the sequence manageable via JMX. And if we make the SequenceKey part of that management, then the application could use it to help map from the application logic into the underlying sequence.I think that this is an orthogonal issue to the API issue. Exposing a management interface into the state of a Sequence isn't really the same as exposing reliable messaging to the application. Frankly, I think that there is an important separation of concerns at play here. The application shouldn't be managing the Sequence state. It should be oblivious. Reasonable people may disagree on this point, but I firmly believe that the application should leave the underlying specifics of reliable messaging to the infrastructure.