I find myself in agreement again with Dan on the topic of WS-RM and WS-QueuedMessaging. BTW a real minor nit...
My order of preference based soley on performance would look like so:
- JMS< ->JMS
- OpenWire (Java/C/.NET < -> Java/C/.NET)
- WS-RM with a durable store
1 and 2 are actually the same from the on-the-wire perspective and JMS server perspective. The Apache ActiveMQ
JMS client uses OpenWire on the wire as does the .Net client and the
OpenWire C / C++ clients too. So on the wire they are all identical -
they all use a fast, small, asynchronous binary protocol which is super fast to
parse & write and is designed to work great with NIO & AIO
efficiently. Though the OpenWire clients themselves may have slightly
different performance characteristics due to their different languages
and slightly different implementations, they should be roughly
equivalent - the ActiveMQ server doesn't really know any difference
between them.
But back onto the MOM v WS-RM thing. If you control both ends of the wire, using a JMS/MOM/MSMQ provider
will generally always be faster than WS-RM for various reasons - MOMs are
connection based, no pointy brackets parsing, messaging is a well
understood problem that vendors have been implementing well for many
years etc. As an added benefit the MOMs work well with the legacy
non-WS applications you have in your organisation (most organisations
have a ton of MOM applications running today).
However the main purpose of WS-RM is to be able to bridge different
messaging systems like WCF and another JMS/WS/ESB stacks - so it doesn't
have to be better than an established MOM to be useful; its got a
different design goal, its about interoperabiily between messaging
systems, not about being the best messaging system.
I just wanted to respond to a few things Paul said as I don't think the folks talking about WS-RM were ragging on it - more highlighting what it was and where it falls short
There have been a rash of blog entries discussing the durability of WS-Reliable Messaging (for example, Dan's blog).
The blogs correctly point out that WS-RM doesn't require that the
endpoints persist the messages. Unfortunately most of these blogs then
go on to draw an incorrect conclusion - that WS-RM isn't as reliable as
JMS.
Certainly you can get a WS-RM implementation to use a database and
persist messages. That does not imply that WS-RM is equilvalent to the
world of MOM/JMS/MSMQ and that WS-RM is all we need.
The second point that's pretty key is that 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.
The various Qualities of Service
(QoS) which are available in the MOM worlds are not an implementation
detail inside the JMS server; they are a policy which the endpoint
sending or receiving messages specifies. These are the semantics of the
message exchange itself, the SLA with the messaging provider - not some
artbirary implementation detail in a server.
In JMS/OpenWire/MOMs there is a way to specify the exact QoS of each
message exchange. WS-RM mostly only really deals with message acknowledgement
(& ordering & whether dups are OK) - there is still a need for some kind of WS-* specification where the
other various QoS which are available in the MOM worlds can be specified as a
policy for use with a WS-RM provider.
Just a slight diversion in SOAP over JMS for a second...
For example, at the present, there is no standard definition of a
SOAP/JMS binding.
Agreed - though thats a problem of the WS-* specs and not with JMS per se.
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.
This is completely provider specific. e.g. with Apache ActiveMQ
it just means specifying a URL (rather like HTTP) and you're good to go
- no other configuration is required to "turn it on"; there is no need
to setup JNDI or queues or connection factories etc. So there's no real
reason why the standard SOAP/JMS binding can't be just a URL. But I
agree some JMS providers are a huge pain to setup - but then you can
always switch your provider to a better one :)
So in summary here's a few things which could go into
WS-QueuedMessaging (or whatever its called) which would probably sit on
top of WS-RM and just be a policy/metadata extension
- specify the durability of the message (is it written to disk or
not - or is it guarrenteed to really be on N disks by the time the ack
is received)
- specify the message expiration (how long does it live for etc)
- message priority
- lifetime of endpoints (do they stay around forever or can they disappear after an inactivity timeout etc)
- maybe its worth integrating WS-Notification so that queue and
topic semantics can be united together with the various things it adds
to the table (like pull versus push delivery, subscription management,
subscription filters, suspending/resuming subscriptions, working with
the broker etc. All of these features are equally valid for topic
semantics (all consumers interested get a copy of the message) and to
queue semantics (one consumer gets the message and messages are load
balanced across consumers) - so why not unify WS-RM and
WS-Notification. Folks need durable topics too
- browsing of queues
- redelivery count on messages. While this might not seem very
useful at first, this is a very useful optimisation header which can be
used to avoid slow and expensive XA transactions when working with messages and another transactional resource like a database
So I'm all for some more WS-* effort in the MOM space and WS-RM and
WS-Notification are a good start but we need a little more. If one of
the aims of WS-RM is to be able to bridge messaging systems, then we
also need to be able to send along the QoS semantics which are already
in all MOMs today - merely acknowledging receipt of messages is not
enough - but its a good start
9:29:04 AM
|
|