<<Over the past month or so, I've attended two Microsoft events. At the MMS event, discussion focused on an approach to virtualisation that showed a greater appreciation of the problems than I would have expected from Microsoft at this stage of its embryonic Hyper-V play. The approach was well beyond what the company has shown to date with Virtual PC and Virtual Server.
Then, there was an analyst event held alongside TechEd, where Microsoft's approach to service-orientated architecture (SOA) was discussedwhich left me cold. The problem is that both subjects can be closely linked, and suffer essentially from the same problems. For Microsoft to get one so right and the other seemingly so wrong just doesn't make sense. Let's start with virtualisation. A key part of virtualisation is in managing the provision of applications to virtual servers. Here, the general approach is to create a complete stack made up of the operating system, application server and application alongside any dependent software, and use management tools to provision this image as and when required. The problem is you soon end up with many images of different applications and different application versions. Each of these images has its own copy of an operating systemyet the operating system will require continuous changes through the application of patches and upgrades, as will the application itself. Patching hundreds or thousands of images becomes a major problem, and managing a virtual environment can become an unexpected nightmare. Microsoft's approach is to use a modelling capability, currently still under a project code-name of Oslo. The idea is that physical images are not actually heldinstead, a model or a description of an image is held. This model will state that the real image needs this operating system, this application server and this application, plus any other dependent functions, and will create this dynamically, on the fly. Therefore, in theory, you only need to hold one master image of an operating system. As you patch this one master copy, all the models that require an operating system will pick up the new patched version automatically as the stack is created dynamically. All very much common sense and workable. Now, let's move to the SOA side. The messages about Microsoft's first forays into SOA were a little muddled but at least there was promise through the support of web standards and standard repository technologies. Microsoft has had some time to refine its message and ensure that it is at the forefront of the subject. What we were presented with at the analyst event was a sorry tale of how SOA was great for knitting together existing applications. And there was me believing that SOA was all about creating discrete pieces of reusable functions that could be put together as composite applications. Now Microsoft tells me it is a replacement for the old enterprise application integration approach. Now I know that Microsoft does understand the composite application approach to SOA but it doesn't seem to get the importance of it, nor how to get this across. The thing is that a composite application needs to be constructed dynamically, based on a set of criteria that needs to be held within a model. Is this beginning to sound a little familiar? Project Oslo provides the basic characteristics to manage this. Through referring to Microsoft's functional repositoryits own version of a Universal Description Discovery and Integration enginea model can easily be constructed that defines the functions that a composite application will need, as well as the "contract" data that the functions will need. What do I mean by the "contract" data? Well, an SOA function in itself has little knowledge of what loads are going to be put on it. During its design and development stage, the developers will have allowed for the function to be able to cope with a certain workload, and possibly for the function to expand this workload to an extent if more virtual resources, such as CPU or memory, are thrown at it. Problems arise if the composite application needs more than the function can provide. The model needs to be able to negotiate a contract, based on identifying functions that can be scaled to meet its needs, or to see if multiple instances of a function can be provisioned to meet the need through load-balancing. This approach needs a complex modelling capability that is flexible and understands the context of the business process it is serving. And this is where I believe Oslo comes in. By bringing SOA and virtualisation together through Oslo, Microsoft can tie together two of the most important technologies happening in IT at the moment. Surely this is what organisations are looking fora means of creating dynamic composite application stacks, based on SOA functions, which can then be provisioned on dynamic application server stacks based on dynamic virtual images? For Microsoft, the problem seems to be in getting different teams to talk adequately to each other. The Oslo team needs to expand its remit somewhat, and the virtualisation and SOA teams need to be co-located to reap the benefits of the synergies that underlie the two approaches. With this combined approach, Microsoft will still not conquer the world, but will make life for .NET developers far easier. It may even make some J2EE devotees think twice, as they see the benefits of a single approach. Interestingly, another area that was covered at MMS was Microsoft's first true foray into supporting heterogeneity, through the launch of its Cross-Platform Extensions (CPE). If this can be extended to provide greater support for Java/J2EE SOA functions, then we could be looking at a real sea change in how Microsoft could be viewed in the SOA/virtualisation world.>> You can read this at: http://www.it-director.com/business/content.php?cid=10586 Gervas
