netzooid

There has been some more good discussion on the need for a WS-QueuedMessaging spec. James responded to my post with:

But there is a need for some kinda WS-QueueMessaging specification so that durability and the full quality of service metadata can be specified - such as to ensure that a message is written to disk before it is acknowledged etc. Even something so apparently simple as writing to disk - you may want to also wait until the disk buffer is really flushed to the disk itself before assuming its written to disk (most disk writes in an operating system go into a RAM buffer that asynchronously gets flushed to disk).

Paul Fremantle also comments:

…WS-RM was never designed to talk about the implementation. RM is a protocol and as such it only talks about the messages and state machines at each end. Talking about the implementations would be a mistake because it would violate the concept of loose-coupling inherent in the Web Services designs. And from what I can tell of the OpenWire spec, it is just the same. The durability of the messages is a function of the JMS servers, not the wire protocol.

Agreed. While I ragged on spec making in my last post, I do believe more support for this type of thing in the WS-* stack would be a good thing. As James said, putting this stuff in policy/metdata would be helpful to specify the QoS.

Paul also does a little SOAP/JMS bashing:

RM also layers much more cleanly with SOAP (and therefore with a wider variety of programming models) than JMS does. For example, at the present, there is no standard definition of a SOAP/JMS binding. Another example is that using WS-RM doesn’t require any further configuration than “turning it on”. Using SOAP/JMS means defining queues, queue connection factories, and all sorts of JMS config.

Not quite sure I agree here. The point about JMS, is that if you are looking at using it, you most likely control both endpoints, so a standard format won’t do you that much good. I don’t think JMS is quite that hard. Or WS-RM that easy.

If JMS is an option, I believe the performance benefits outweigh the “lack of standards” and configuration issues. My order of preference based soley on performance would look like so:

1. JMS< ->JMS
2. OpenWire (Java/C/.NET < -> Java/C/.NET)
3. WS-RM with a durable store

So to answer the title of my post - do we need WS-RM and WS-QueuedMessaging. Yes. There are a lot of situations where we need a standard, reliable protocol. Its just not the right fit for everything.

(Now I’m wondering if I’m like one of those people who won’t give up assembly programming… Am I not embracing the future for “performance reasons”? Or am I being realistic? Or should I get some sleep? Yes sleep…)

Update: James expands on what should go into a WS-QM spec and when JMS does/doesn’t fit. Good stuff. So I wonder who is going to start this spec…

This entry was posted on Wednesday, March 1st, 2006 at 9:32 pm and is filed under Javercising, Web Services.