SOA version mangement

I was looking for a way to not write this whole report, and fortunately, Google found this report for me. Yay! I didn't really want to write this stuff, so I'm glad I don't have to, now.

The title of "Best Practices for Artifact Versioning in Service-Oriented Systems" is pretty accurate. For the TIBCO geeks, this is required knowledge for the (deprecated) TIBCO SOA Architect qualification.

http://www.sei.cmu.edu/library/abstracts/reports/11tn009.cfm

Virtualisation and Service Oriented Architecture

I was reading over at the TIBCOmmunity site regarding the impact of virtualisation on architecture
( http://www.tibcommunity.com/blogs/soa-architecture/2009/07/24/virtualization-and-its-affect-on-architecture ). There's some handy information here, but it feels a bit lost under a heading of "SOA architecture"; so I thought I'd have a go, under the heading of "I think...".

Virtualisation is the capability to encapsulate arbitrarily complex environments (by adding yet another layer of abstraction, naturally). Virtualisation is a means of utilising commodity hardware in ways that were previously the preserve of esoteric, expensive, proprietary systems.

What does this mean in the context of SOA?

I think the eventual result is that services can/will be built as software appliances. The moves around OSGi are heading in this direction, allowing a more 'focussed' environment to be built. I'll expand on my view of a software appliance life cycle in a later post.

I do believe that the eventual goal around a SOA (at a technical level) should be something like an AMI virtual machine (the lingua franca of the cloud), with defined "production", and management,  services. This could/should be hosted in some cloud (public/private), or combination of clouds. The services/VMs may depend on other defined services (provided in a SaaS, or other, manner). Some overarching management environment will be required to manage the relationships between services (and I believe that this is where VMware is heading, fast).

SOA monitoring and discovery system

SOA is a great idea, taking chunks from EAI lessons learned, and generalising them. It occurs to me that tools for building maps of service invocations is necessary and "good". The question becomes, fairly quickly, "how?".

Asking developers and designers to be good citizens and update spreadsheets (or more sophisticated tools) doesn't work, because over a little time, the manual update system breaks down for lots of reasons (not least laziness). I suggest the only real option is to automate discovery of service invocations by watching the service interfaces themselves.

Point-to-point transports (usually TCP-based, like HTTP) make capturing traffic quite awkward, but the content can usually be extracted as it will pass through so many network elements (including the service's host machine) where a wire tap can be taken. If the communication is encrypted in-flight (as is expected for sensitive data), then an application level wiretap will be required.

BEA's AquaLogic took a very active role in this monitoring when I grappled with it; essentially as a proxy in the whole process. Maybe they made less intrusive options available in version 3... My first outing with AquaLogic didn't encourage a second try. All-in-all AquaLogic just seemed an order of magnitude too big and clunky.

I favour a distributed system of agents suitable for capturing each service invocation. Each agent could feed (largely unprocessed) data back to a cluster of analysis machines. At the end, I'd hope to see a bunch of query/display/integration tools to leverage (what would be in my experience) the only up-to-the-minute source of information about how the organisation actually hangs together.

A JMS wiretap (vendor specific, or fall-back to browsing the queues), could be implemented easily enough. For HTTP snooping, tcpdump's ok. For HTTPS, web server modules would be required (Apache, IIS?, ligHTTP?).

The analysis? Another day...