Wolf’s Whitterings

SOA as a Simplifying Force?

Mon, 21 Jul 2008 17:07:46 -0500

I was reading Joe McKendric’s blog entry on the rising cost of debugging and the blame falling on SOA and I particularly noticed his concluding remarks...”Hmmm. The purpose of SOA — and Web 2.0 for that matter — is to simplify things” - I couldn’t disagree more. I have been thinking long and hard about what really is the goal of SOA and I have to say I have never thought this was one of them. SOA isn’t about making it simpler, it is about making it more manageable which is absolutely not the same thing. Take car engines today as an example. They are much more efficient at delivering power for much less fuel burn, smoothly and reliably, but are they simpler? To use, yes, but not to design, build and “debug”. I used to be able to fix my old VW’s engine in an afternoon with a hand full of tools from the local autoparts store - today’s engines can’t even be diagnosed with out specialist computerized equipment. SOA is young and thus the toolset to support SOA is young too - it will catch up and debugging will ultimately become easier than it is today but that was never the actual goal.

I will make time soon to write a longer blog on what I think SOA is actually all about, but for now let me go on record as saying it isn’t “simplifying” anything.

SOA as the Uber-container - part II

Tue, 22 Apr 2008 17:27:09 -0500

In my last blog entry I posited that an intuitive way to think of SOA was as the über-container; an Enterprise Wide, virtual container, in which all our business applications run. This über-container would provide infrastructure services to provide for all the housekeeping necessities that are not actually related to the business purpose at hand: from managing security requirements (authorization, authentication, encryption etc.) through reporting on performance and availability characteristics – all the things we would expect to be able to leverage from a well written local container (like the .NET CLR or the J2EE environment) but applied universally across the enterprise without regard to platform or language.

Assuming for a moment that you buy into this concept, what can we infer about this über-container’s capabilities? Well, for a start communication is a prime example. Without ubiquitous communication across the disparate stacks, we can’t expect to achieve much at all. Clearly, in the past 20 years, IP route-ability has made the ability to transfer a packet, the basic message, from point A to point B a given. There are however, at least three higher order problems with communication at this stage:

1) We are likely to need so level of logical indirection to control the point of delivery for the message. It is possible to hardcode the endpoint of course, but this quickly cases issues even before we get as far as new versions. We can assume that what ever “services” we are going to develop will need to travel through the Test, Stage and perhaps User Acceptance environments before reaching production – even this one version will have multiple endpoints on its way through this development process. Furthermore, it is also possible that we will want the ability to scale out the service, thus there may be many physical endpoints that serve one logical one.

This problem has been solved before of course, DNS for machine names and perhaps more applicably the infamous “Registry” that translates CLSID’s into DLL’s under Windows. This über-container will need some logical name to physical name mapping service (let us call this the Repository for now and just assume it exists somehow, somewhere – we will revisit this concept in detail later).

2) Even if we deliver it to the right place, we need to make sure that the receiver can read the message that the sender wrote. We have two fundamental choices here: a common language or an interpretation system. If we insist on a common language (imagine the UN declaring English is the only acceptable language for discussion), then we have really just moved the interpretation problem to someone else’s plate (or more precisely everyone else’s plate). Furthermore, we will spend forever agreeing which language will be the official one (there is obviously a huge advantage to ensuring it is your own “native” language). It is tempting to say that XML has become the definitive solution to this problem so everyone should just accept that (we can ignore the encoding issue to keep things simple), but XML is fairly standard because it is pretty much the lowest common denominator. Does this make sense in an environment where Java to Java or .NET to .NET communication could be so much faster and so much more bandwidth efficient?

In my view the container needs to allow native to native communication where ever possible and only get involved in translation issues if it absolutely needs to. Again, if we fall back on this concept of a Repository then we can add to our endpoint address information that can tell the container what language (or languages) it can accept and it can translate if necessary.

3) Having defined where to send the message, and what language to send it in, the remaining obstacle is to understand what content is required in this message. I can send a check to the billing department all day and I can even send it in English if required, but if I don’t tell them which account I am trying to pay it probable won’t help! Again, this seems like something we would want to store in our Repository.

So if we create a system that allows us to define a logical to physical endpoint mapping, provide enough information to allow translation to occur as and when required and defines the overall content of our messages, have we built the über-container? No, definitely not…but it’s a good start. In my next blog entry I will try to continue this thought process to cover some more of the missing functionality...

SOA as the Uber-Container?

Thu, 17 Apr 2008 11:48:49 -0500

Almost since the beginning of computer programming, there have been containers. I grant you that the very first programmer’s had the entire machine to themselves and their “programs” sat right on top of the hardware its self; but very quickly, as computing power grew, computers became general purpose systems that would run more than one program at a time an the container was born – the very first being the operating system. In later years, the container evolved through mainframe Transaction Process Manager’s like CICS and TPF on into the JVM powered App-Servers of the Unix/Java world. Somewhat late to the game came Microsoft’s .NET runtime - the CLR, which when paired with Servers like IIS or BizTalk, can provide a very rich environment indeed.

So what’s the point of container based programming? Simply the recognition that there are many functions that programs need to perform in order simply to exist, but that these functions have nothing to do with the algorithmic work of supporting the business functionality (the reason they were written in the first place). Jobs like memory management can be done in each program of course, but the are quite simply better done by the container – for two reasons: firstly, not every programmer has the same level of skill at many “infrastructure” problems, like memory management or perhaps more obviously credential management. It is not only unlikely that every company that needs to engage in program production could master these things, but it is in any case wasteful of resources. Much better then is to rely on the experts within the manufacturer of your favorite container, and leverage this service across all your applications – think about it, many of you could do a decent job of writing a basic operating system, but how would that actually payback in terms of the job your company needs you to do; better then to rely on one of the OS commercially available (however imperfect they may seem).

Secondly, and this is an argument that we fought long and hard when transitioning C++ programmers to C#, it is quite true that a very skilled programmer with intimate knowledge of their application can probably manage their resources more efficiently than the container can, but: that matters if you are a game programmer, not so much if you write Enterprise applications. The enterprise programmer’s code will run side by side with many other applications - which will all compete for constrained resources. If every programmer is allowed to optimize resource use based solely on their own code’s needs, the system as a whole will suffer. Only the container can have the holistic view necessary to optimize system wide – after all, that is the very principle behind the ultimate container – the OS.

What has all this to do with SOA? Well it turns out that it is a useful metaphor to better understand SOA - consider it in terms of being an enterprise wide container. Instead of optimizing resources local to a machine, we are attempting to do this for the entire IT infrastructure. Likewise, we are attempting to promote the use of “infrastructure services” in place of writing infrastructure code in every application. To complicate matters, this must be done in a platform neutral manner so that any application can benefit from the federal services without regard to the language in which the application is expressed, or the OS or hardware upon which it is run. Easily said, not so easily done. More thoughts on this “uber-container” later…

Why I use an Apple Mac

Thu, 18 Oct 2007 15:04:14 -0500

You know working for Microsoft but carrying an Apple Mac can earn you some strange looks. People are often asking me why I use the Mac (and others how I get away with it!). I thought I’d explain here on my blog because there are several good reasons. Firstly let me start by saying this beast runs Windows Vista better than any other laptop (or desktop come to that) that I have ever owned. From a hardware point of view, it is phenomenally well design and is just blazingly fast (a Windows Experience Index of 5.9!) - so even if I was only ever interested in running Windows, I think I’d still want this machine. However, I do also run OS X on this box. There are two driving reasons for this, the first being that we should always be prepared to learn from people that can do things better than we can. Apple *really* get usability. Mac OS X quite simply can not do everything that Windows does, and these areas are of primary concern to Enterprise users, but what it does do it does with such fluidity, such grace, that it is a pure pleasure to use. At Microsoft we need to be humble and learn that it can be done better - and if it can be done better it should be done better.

Secondly, consider what I do for a living. My focus is in Service Oriented Architecture. Principally this is about making IT services available for consumption by other IT services in an open manner, without regard to the platform that the service is written on or the platform on which it is to be consumed. When we live and work in a homogeneous world it is easy to assume away the details and just declare yourself compatible by virtue of following “open standards”. However, when we work daily with heterogeneous systems we are continually reminded that it is the little details, so often overlooked, that make this goal so difficult. I use my Mac like a character in one of my favorite books (the Chronicles of Thomas Covenant the Unbeliever) uses a cut-throat razor blade. Thomas Covenant was a leper. Apparently what kills lepers is not so much the disease itself, but the injuries that they sustain (which they can not feel and therefore do not correctly tend to). Thomas Covenant shaved every morning with a cut-throat razor to remind himself of how his life depended on vigilance. My Mac reminds me every day that Great is not Good Enough if it can be Better and that my job is to break down barriers, not to erect them. I do not want to “win” because Windows has a stranglehold via unpublished API’s or de facto standards. If the Windows platform is selected by a customer over any other, I only consider it a “win” if it is because we just flat out provide a better value proposition on our own merits.

Some at Microsoft would agree with me here and some would not. To the latter I say “go in peace my friends, go in peace”.

Setting up a new site...

Thu, 18 Oct 2007 15:02:58 -0500

My main blog site has been hosted at MSDN for the past few years (not that I’ve done that much blogging to date). Now that I am trying to exercise my creative side I am setting up this new site for it. I haven’t decided whether I will cross post for a while, just copy my old posts here and carry on or keep the two sites going independently. I guess I’ll figure that out later - the most important part of blogging is actually just getting on with it, and as I haven’t done so well on that yet it seems where I post to is rather less important than getting in the habit of actually doing it.