Resending as this mail seemed to vanish en-route.
Begin forwarded message:
From: James Strachan <[EMAIL PROTECTED]>
Date: 24 February 2006 18:51:26 GMT
To: [email protected]
Subject: OpenWire status
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/
