Last night was odd. Walking home from the gas station (around midnight), a door on Hinkson opened and a black dog rushed out at me. Growling, snarling, and making a bee-line for me! I did my best "bad dog, shoo" mean yell (which stops most dogs) but it continued right at me. Fortunately, stealth was not its strong-point, so dodging it's first attempt at biting me was really easy. It's second bite was aimed at my ankle, and I (not entirely deliberately, in all honesty) ended up kicking the beast as it bit at my steel toe-cap. It yelped, and a man ran out of the house, restrained the dog, and started yelling at me. I politely asked him to desist and left. Noone hurt, but it sucked.
SOA
I've been reading a lot about Service Oriented Architecture in trade journals lately. This got me thinking about what, exactly, SOA is. Like most buzzwords, it seems to represent a number of things. Most important are loosely-coupled components (something programmers have aimed to achieve for decades). These seem to have to be remotely invocable, probably via SOAP (although this seems to be more the lingua franca of the moment than a necessity). Most SOA discussions refer to using business rule engines/orchestration engines to abstract connecting code together - almost abstracting it out of the programmer domain altogether, and into manager-level "join the dots". (This is a good thing: business types can focus on business logic, programmers on implementation.) Finally, there seems to be a requirement to invest in a Message Bus.
Message Busses
So the question that comes up is "what the heck is a message bus?", and how does it differ from message queues, remoting, object brokerages, WSDL, sockets, and every other method of passing messages? The answer is both that it doesn't, and that it is more formalized while being more loosely coupled. Huh? More formalized and more loosely coupled? That makes no sense!
Sadly, it does. By sticking to a formal message format (in theory transport-agnostic, but they all seem to be XML-HTTP-SOAP right now), and serialized objects, the message bus can offer MQ-like guaranteed delivery, broker services, and asynch. processing of messages without any understanding of the content. Routing, priority, and similar become a purely messaging problem, while each component worries about working with the nicely de-serialized objects.
Revalation
And then it struck me, in a blinding flash of incorrect grammar: I've been doing this for a while. The entire Thoth architecture is based on format-agnostic message passing (with routing, guarantees, etc.), componentized business logic (with some scripting, but not quite as much), and the capacity to scale each component section to different servers if necessary. I made an SOA without knowing what one was!
Mood: tired
Music: All About Eve - More Than This Hour
