I've spent a while working on the C# client (openwire-dotnet module)
and we've a working client that can create connections, sessions,
producers, consumers and send, receive and acknowledge messages using
the underlying OpenWire transport. Yay!
I've started a page to document it further here...
http://docs.codehaus.org/display/ACTIVEMQ/OpenWire+dotNet
As part of this effort I refactored the Groovy scripts somewhat to
really simplify them down to basic templates with all the clever
logic in a Java class (to make it easier to edit & test etc). I'm
pretty happy with the OpenWire infrastructure, it appears to work
very well. (I still need to refactor the scripts to generate the
JUnit/NUnit tests but the classes & marshalling code is all done now).
I just thought I'd brain dump here the things which are not 100%
ideal though all are quite easy to live with...
* dealing with errors.
You can enable stack traces in the WireFormatInfo. (BTW I refactored
WireFormatInfo to avoid bitwise flags going into an int - which are
hard to keep in sync across languages - to use boolean flags
instead). If you enable stack traces then you get nested exceptions
with full stack trace information. Right now I had to manually write
the marshalling for this type in C# (I added BrokerError and
StackTraceElement as types). Ideally these would be commands in
OpenWire that just fall out for free along with all the other code
generation.
* knowing what commands are auto-generated versus what are manually
created.
In the C++ and C# OpenWire bindings the scripts auto-created all the
commands but then a bunch of them were hand coded after that (the
destinations and message classes which derive from Message). Its not
a major big deal, as the manually edited classes never change and
don't have much data in them (a base class has the data) but it would
be nice to separate out the auto-generated classes from the ones-that-
must-be-editted in a slightly cleaner way. Not a big deal this one
though :)
* client testing
We've started creating some .Net NUnit tests to try out the
OpenWire.Net client against an ActiveMQ broker. The Java unit test
cases don't clearly split up the tests of just the client versus
tests which test everything; it'd be good to come up with a good
suite of tests that we need to create for each language that really
test out the behaviour of the client. We can test out the broker in
Java-land; we don't need to retest it in C# and C++ as well; we
mostly just need to test that the on-the-wire commands work. Over
time I'm sure we'll come up with a good list of features to test in a
client (e.g. standard JMS headers, custom headers, durable/non-
durable messaging, create/stop consumers, test selectors work, sync v
async consumption, transactions etc).
All in all I'm very impressed with the OpenWire infrastructure (good
job Hiram!:), while at first its way more complex than Stomp (which
is ideal for writing clients quickly), its looking like OpenWire will
support full JMS clients in other languages with minimal work. I'm
impressed with how clean and simple the .Net client turned out to be
- here's hoping the C++ client is just as simple - yet powerful.
James
-------
http://radio.weblogs.com/0112098/
