Tuesday, February 28, 2006

Limitations of WS-* and the need for Queued Messaging Dan has a very interesting post on the limitations of WS-ReliableMessaging. I clearly agree with his conclusions that given cross-language support for MOM thanks to the OpenWire effort in a fast open source enterprise class messaging system like Apache ActiveMQ (currently we have clients for Java, C, C#, Perl, Python, Ruby with C++ on the way real soon) it is probably simpler to just use a real messaging system than use WS-* right now if you care about performance, durability and reliability. 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). Having spent a fair amount of time working on MOMs, in particular in areas of performance and reliability - even if we had some WS-QueueMessaging specification today I'd still recommend folks use OpenWire as its simpler, binary and much faster. Its also pretty trivial these days to bridge MOM providers using JMS. BTW congrats Dan on 1.0 of XFire. We use it on Apache ServiceMix, its good stuff :) 9:32:34 AM    comment []

Using JMS from .Net using a pure C# client Apache ActiveMQ now has support for OpenWire.Net to improve its .Net support. OpenWire.Net is a pure C# client for communicating with a network of Apache ActiveMQ brokers and supports the JMS semantics of connections, sessions, producers, consumers together with things like acknowledgement modes, persistence/non-persisitence, queues & topics, temporary destinations etc. See the example for details. Included in OpenWire.Net is a set of interfaces which mirror the JMS API but are a little simpler and use a .Net flavour (e.g. supporting IDisposable, properties, delegates, events and property indexers). Incidentally now we've a pure C# client for Apache ActiveMQ, I'm hoping we can provide clean integration into Indigo / WCF such that its invisible to end users - you should be able to switch from the standard WCF providers to OpenWire/Apache ActiveMQ with a minor config file change (and add a single DLL to your runtime). 8:40:04 AM    comment []