I went down to the London Realtime event event today. In part, it was to learn more about realtime programming and partially because RabbitMQ were going to be there and it would be a good chance to talk to somebody about the message queueing (MQ).
I did manage to bend somebody’s ear (sorry if I went on a bit!) and started work on a prototype for a presence system. As there were people building cool things like games and a drum/sound machine using Pusher and Twilio amongst other things, it seemed tame. I guess enterprise systems are really not sexy but I managed to build the skeleton of a UI and how it interacts with the underlying registry which also gives me the shape of the registry.
However the conversation go me thinking about Rabbit and coalesced a while series of thoughts that I’ve been having about discoverability and registers using messaging systems.
Distributed computing is all well and good, as are distributed services in Service Oriented Architecture (SOA). However how does any system ever know what is alive? How do they know what might have been moved if the platform becomes used across businesses? If a dataset is uploaded to a remote service, how can it be found and its download details ascertained? Trial and error? Asking the developer, architect , support or operations team?
How do we know that friends are on Facebook? The presence system which informs us if they are online or offline. Systems become similar in distributed computing. They have end points, methods and parameters? Using different transport types means that the traditional UDDI requirement for knowing the endpoint is great but it relies on the endpoint being a web service and tending towards SOAP. Most of the time this is fine but I would suggest that in the new world of message queuing and competing standards from JMS to AMQP to STOMP and onwards, the requirement for the user to know the protocol used is a must as well as the correct port to use since not every one will use the standard ones on ActiveMQ and RabbitMQ. Also the queue name is a must and what type of queue or topic requires the message.
This also affects us when we use the cloud to store data. Where is it? How can I get it as well as how large is it? Easy questions but we might also need to consider failover protocols if it is available via more than way of getting hold of it. Discovery is not about merely finding material in an ordered fashion but also helping to stumble upon data.
But first things first. Finish the presence system, taking ideas from XMPP rosters and other similar systems. The to look at exploring expanding them. I have also been continuing expanding this into the Drupal world and have something in very early stages of being a set of modules which may just work!
I am sure more questions will need to be asked and answered found in the design and building. The initial build looks like being based around RabbitMQ and Redis but it out to have some way of being portable to ActiveMQ.
More on that anon…
No Comments