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

TIBCO fiddles

In brief:

1. When fiddling with TIBCO Software, use an OpenSUSE virtual machine, it hurts less.
2. Oracle XE is very handy for fiddling with TIBCO software - Here's a great web page explaining how to set it up on OpenSUSE - http://forums.opensuse.org/install-boot-login/414654-how-install-oraclexe-opensuse-11-1-a.html
3. Give your VM about 2GB RAM, or more.
4. Create a different Unix user for each 'build' (ActiveMatrix v2 suite, ActiveMatrix v3 suite, BusinessWorks/Administrator suite, etc.). Don't let them read/write to each other's files, ever.
5. Do not install gcj, OpenJDK, or anything remotely like Java and not made by Sun and/or Oracle.

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).