[prev in list] [next in list] [prev in thread] [next in thread] 

List:       activemq-dev
Subject:    OpenWire status
From:       James Strachan <james.strachan () gmail ! com>
Date:       2006-02-24 18:51:26
Message-ID: FE4B57A8-6077-46A4-8E4D-EAB5E173F07D () gmail ! com
[Download RAW message or body]

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/


[prev in list] [next in list] [prev in thread] [next in thread]