Integration across the board

So I've come to a point where I have Windows services reading from ActiveMQ = AMQ (it's MOM software) and feeding a system via a COM connector. The COM connector seems to be holding up really well. Last night I was tossing messages at AMQ at a rate of 10 per second. These messages are about 150-200 characters in size. I tested 360010 message going through. The messages finally ended up in a database. This morning I checked and 360010 messages where in the table! Also the software I use to track the status of the AMQ showed that 360010 messages had been put on a queue, and the same amount read off. So things are looking up.

I used Ruby to send the messages onto AMQ. I think I have mentioned before that there is a simple messaging protocol called STOMP, which I used to connect to AMQ from Ruby. AMQ has a snappy transport connector which allows you to do this. AMQ also allows you to write your own transport connector, so if you don't like a protocol write your own :)

I'm testing changes I made to the STOMP Ruby client. I made it much easier to use the client to send messages that get marshalled in the AMQ STOMP transport connector. The client as it came did not make it possible to send what would be a JMS TextMessage in AMQ. Messages that came from the basic client came into AMQ and got marshalled into the JMS BinaryMessage type. The AMQ transport allows for marshalling to BinaryMessage or TextMessage, depending on STOMP header settings. With some simple Ruby coding I have a modified client that now has an extra method 'sendTextMessage'. When using this method the message in AMQ will be marshalled as a TextMessage! TextMessage fits our current purposes better than BinaryMessage.

So back to the testing. I have 4 producers spitting 20 messages a second onto a queue, and one consumer reading messages off of the queue as fast as it can. I'm up near 200k messages sent/received and counting. I'll see if things can break at some point :) I also have the Windows service coming on and off to take messages from this queue. This tests how well things are handled with consumers going down and coming online on the fly.

So the big picture is to be able to easily integrate a M$ product into a ESB using the AMQ messaging system. Rather than have to handle the problem of the M$ product dying and data being dropped we will have a scenario where messages are kept and fed over when the product comes back online. We should also have an easy time reusing bizz logic components in the ESB.