Wolf's Witterings

SOA AS THE ÜBER-CONTAINER PART II

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

View entire article

SOA as the Uber-Container?

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

see full article

Where'd the Service go? (or why I'm tempted to short DirecTV's stock)

Companies thrive or die based on V-C. By V I mean the Value they provide to the customer, by C I mean their Costs in delivering this Value. Now the company doesn't determine the Value, only the customer can do that (just how badly did you want that new iThingy?). What the Company gets to determine is P or the Price, which will lie somewhere between V and C. The difference between V and P is called Customer Surplus and it is what you and I use to decide which particular Thingy to buy. Not just the one with the most whatever it is that we value, but the one that gives us the most of that for the buck. The difference between P and C represents the Profit that the Company makes on the sale of its product or service. Clearly the bigger V-C, the bigger both V-P and P-C can be - hence happy customers and profitable companies.

That all sounds good, but what if you are in an industry where almost every company's Vs and Cs are the same? Think of the Cell Phone world. We can talk about a better network, less dropped calls etc. etc., but after a while the whole thing settles down to 4 or 5 major players who's networks are frankly identical from the consumers' point of view. If that is the case then what stops all the customers from company A from switching to company B or vice versa? Well there are two more factors to consider. Firstly when they have an advantage that gives us a Value edge, the company wants to protect it so their competitors can not copy it. They might do this via Patent protections or perhaps via trade secrets (what is Coca-Cola's secret recipe?), but they will try to do it one way or another.

What if there aren't any real technology differences here, again think of cell phones. Well then they will try to focus on Customer Retention processes. One way to do this is through providing excellent service to your customer. If they are getting what they want, when they want it, at the same price they could get it elsewhere, why would they bother switching? This introduces another key point, switching costs. Have you ever changed your bank? If you have I am willing to bet it was an extremely painful process. So many people need your account info (your employer perhaps being the most important), and you have to notify each and every one of them. Ultimately some one gets forgotten, a bill doesn't get paid and there are nasty phone calls or worse to deal with. Hence we don't switch banks unless ours gets truly awful and the switching costs, however onerous, don't seem as high as the cost of staying. Many industries benefit from naturally high switching costs, Microsoft being one of them.

It is worth underlining the fact that high switching costs will not protect a poor company for ever, but they do give you a grace window in which to restore your customers' happiness before they desert you. There are no necessary switching costs with cell phones (at least since number portability) so the cell phone folks have created one. They give you the ability to lower your entry costs by basically selling you the cell phone device on credit terms. If you leave early, your entire cell phone purchase becomes due at that time and hence you have an incentive to work your issues out with them rather than just leave. How do customers react to this kind of barrier? It isn't too bad because after all you are getting a service for your money (the easy credit arrangement) and these days most phones will work on most networks so you can still move your service if you want to - other than a minor hit to your cash flow there isn't really a penalty. Further more, if you don't like the deal, you can still buy your own phone and go month to month (ie no early termination) instead.

So what is different with DirecTV? Firstly we should understand that the Satellite TV business is not a very safe one right now. The cable companies and your Telephone providers (collectively Network Service Providers - NSP's) are already in a deep battle for who will be the provider of choice for TV service (powered by the increase in bandwidth and much better compression ratios making IPTV commercially viable). These two both have a huge advantage over the Satellite folks. They can support Video on Demand and Internet connectivity and satellite can not (or at least not at the same value point as the NSP's). The switch is already beginning and I am sure that execs at the satellite companies all have nightmare full of Ross Perot style sucking noises as the see the customers leaving taking their profits with them in a swirling vortex down the proverbial drain.

So what to do? Well if you aren't very bright, you might think "let's put up the switching costs just like the cell phone companies do". So imagine that you "sell" the set top box to the customer, and while you are at it make it a DVR to help offset the "appointment TV" restriction of your service. So far not so bad, but here's the rub...when a customer does want to leave is the box that you are now going to make them pay for any use to them? No, the satellite folks created the own independent standards to increase switching costs between each other, thinking that their biggest competitors were each other. You can't use your DirecTV box anywhere else, even though it has a nice DVR in it. But DirecTV goes even one stage further...they require you to send the box back when you leave, they are not even actually selling it to you (although the customer service rep may not be too upfront about this). So what is the money in the early termination fee for? Perhaps it is to defray the installation costs - nope, it even exists with self-installs too. A fee to represent the loss of use of the box - nope, the can and do send these boxes back out to new customers and the one I got was already "reconditioned". So what will customers really resent, IMHO it is charges that represent "bad blood" stingers if you wish to stop doing business with the company. There is no reason for this charge other than to hurt the customer for wanting to leave. Can a company survive with this attitude to customers, I believe not (hence the stock shorting idea).

So are the satellite companies just doomed? Should they put onerous charges on everyone as they leave and milk every penny they can get before the inevitable end? Believe it or not DirecTV appears to think so, in fact they think that they can make such agreements effective whether the customer signs up for them or not. According to their "Customer Service" personnel they can write these terms on the back of your bill (which we don't get because the encourage eBills) and then if you pay that month's bill you have, in their opinion, legally agreed to the enforcement of the contract.

My advice to DirecTV, understand that is the quality (or otherwise) of your service which is the only real way you can save your company....it's all about V-C and if your VP of Marketing doesn't understand that then I suggest you interview for one that does. If you have a great service at a great price, you don't need to abuse the customers that leave because most of them won't and those that do will probably return. If on the other hand you abuse your customers there is no chance they will return what ever you do and they will probably share there experience with a very large number of people. You have advantages in the fight with the NSP's in that you have a broadcast system that can reach a vast number of people with out the kind of house to house infrastructure that the likes of Verizon and AT&T have to build. Focus on great TV delivery, get a Customer Service department that actually values customers and use your potentially lower costs to protect yourselves with a larger V-C even if your V is actually lower. Work together with your industry to develop common standards to make it easier for customers to move if they want to (and thus easier to come back too) and your future will still be bright. Continue to forget that it is your customer that pays for your comfortable executive dining room and you won't have to worry about it for long.

The Revenge of the Typewriter

I haven’t written anything for my blog for sometime now, other matters have been taking my full attention, but I decided it was about time I restarted it so here goes…

I recently had a conversation with a colleague that started an interesting thought process.  He asked me to look at some code he had written to see why it wouldn’t compile.  It was a fairly simple ASMX Web Service Provider/Consumer example.  He had started by defining a single object that was to be the message (let’s name the type “Message”) that would be passed back to the consumer from the call and he had implemented a single “Get” method on the provider.  When he receives the response in the consumer code, the compiler complains that he can’t cast the type “Message” to the type “Message”.  He was somewhat confused.

The explanation is simple if you understand two things, Namespaces and type equality.  To clarify the namespace issue first, let’s assume that the original Message object was defined in a separate DLL (so that it could easily be shared by the consumer and producer without sharing the “code”).  The namespace of this DLL we shall call “Common”.  The namespace of the producer code we shall call “Producer” and the namespace of the consumer code we shall call “Consumer”.  Given the following code in the producer:

Using Common;

…

[WebService]

public class MessageSvc : WebService {

                [WebMethod]

                public Message getMessage() {

                                return this._message;

                }

}

It should be clear that the type being “sent” is Common.Message, but given the following consumer code, what is the type of the object being “received”:

Using Common;

…

MessageSvc messageSvc = new MessageSvcHost.MessageSvc();

Message message = messageSvc.getMessage();

Clearly the intent here is that we should receive the message into an object of type Common.Message, which seems quite logical as that is what was “sent”.  In fact it will not work, you will get a compiler error complaining that you can not cast MessageSvcHost.Message to Common.Message – why?

The answer is in understanding the code that has been generated for you by Visual Studio (remember the super duper advance word processor that made all the typewriters irrelevant?).  VS works its magic to make all this “complicated” Web Services stuff appear to be just a remote method call on an object.  VS generates a proxy class (MessageSvc in this example) that wraps all the code needed to translate from object calls into SOAP messages across the wire and back again.  Now an interesting thing is going on here – the major advances in 3GL languages that have made them so much better for writing good code in has been the move to ever stronger typing.  In C#, even an enum which is based on an int can’t even be cast directly to a int without a specific action – it is clearly not intended to be an int after all that is why we declared it as an enum.  Strong typing stops us from “blurring” the differences in the types.  In XML WebServices on the other hand a type “isa” some other type if it has the same shape (or in fact even enough of the same shape to meaningfully map it).  It is in fact this “loose” type definition that makes the whole portability thing possible.

What happens for you it that VS generates code to define an class with the same name as the XML message root that has a shape compatible with the shape of the XML message.  The fact that it has the same name is irrelevant from a type safety point of view.  Further more it will also be in a new namespace (that of the proxy code which will be MessageSvcHost in our example), further removing any possibility of confusion.  It is into an object of this type that the proxy code will pour the received XML data and thus the received type will be MessageSvcHost.Message, even though the type sent was Common.Message!

Is this a major flaw with the whole system?  No, not when you understand what happened and why.  Why doesn’t VS map the type correctly, after all the definition of Common.Message is available to the consumer code in our example?  To understand that we must understand that whereas we do have namespaces in XML (although this is an add-on) and the real message being sent on the wire will be marked as being of a known “type” (ie. name + namespace) it is an XML type name (ie. name + schema reference).  There is no hard mapping between XML Schemas and .NET runtime types – and neither should there be – if there was, what would happen to portability?  Visual Studio does in fact have access to a type that would be of the correct shape but that is only so in this example, “normally” we would not expect that to be the case so it generates one automatically for us.

In the Whidbey release of Visual Studio, there will be a feature that will allow you to make this example work as was originally intended by my colleague (by suppressing the automatic definition of a suitable type by Visual Studio and allowing you to supply your own), but before we get too excited about that, let’s see if that is the great idea that it appears to be.

Firstly let’s “correct” the consumer code so that it will compile and work:

 Using MessageSvcHost;

…

MessageSvc messageSvc = new MessageSvcHost.MessageSvc();

Message message = messageSvc.getMessage();

The actual class names already match, so we need only add a “Using” statement for the MessageSvcHost namespace and delete the “Using” statement for the Common namespace and all will work as the Visual Studio designers’ intended.  So what is the downside?  Well if Common.Message has any real code in it (such as convenient non-default constructors or property accessors etc.) we will not be able to use them.  MessageSvcHost.Message as defined for us by Visual Studio will not include this code (indeed it has no way to know such code exists, because it is not included in the WSDL from which this class definition was derived).

Remember Tenet 3 from the four tenets of SO as suggested by Don Box, “Services Share Schema and Contract, not Class”?  To do as my colleague actually intended would be to violate this principle.  Service Orientation can dramatically increase the reach and reuse of your applications, but it does come at a cost.  The cost is understanding that code is presumed never to be portable across boundaries and that means sometimes we have to live without the “niceties” that come with sharing code.  That sounds like a very “purist” attitude I know, after all what is the issue with sharing code on the same platform when we have gone to the trouble to separate out “data code” from “action code”?  I mean providing nice constructors is not a bad thing is it?  No, done carefully and with restraint it isn’t.  You can easily duplicate this “Common” message library to cover another platform because after all as long as the type shares the same “shape” with the XML document it will work across the wire just fine.  The temptation is to add more and more “convenience” code to the type library however and soon you are right back where you were with a portability nightmare and you can’t understand how you got there when Service Orientation was supposed to eliminate this condition.

Using fancy word processors to remove the boring repetitive effort that is the world of typewriters is no bad thing – it is the path to much greater productivity.  Unfortunately, when you do not understand what the word processor is doing for you, you can end up in a world of pain very quickly.

Beware of the “Revenge of the Typewriter”!

A Chance to Meet the Guru’s!

A friend of mine alerted me to a course being put on in Redmond by PluralSight.  For those of you who don’t know them, it is a small company founded by some of the top talent from DevelopMentor with a vision of creating a community within the .NET world where developers can find help, guidance and training.  Collectively the members of PluralSight have published some of the leading works on all areas of .NET development and architecture.  The course that they are putting on “.NET Campsight, Server Edition”, is a 5 day, 10 hour per day deep dive into just about everything you could want to know about developing on the .NET platform.  The instructors will be: Don Box (as if Don needs an introduction, he is Microsoft’s principle Architect behind the Indigo effort), Aaron Skonard (Web-services and XML Guru), Fritz Onion (Author of Essential ASP.NET, probably the best book ever written on the subject) and Keith Brown (Mr. Security).  50 hours of communing with these super heroes?  You bet I signed up for that one.  If you want more info, check it out @ http://www.pluralsight.com/events/campsight_server/default.aspx and maybe I will see you there too?

A Comparison of Service Oriented Architecture (SOA) and Event Driven Architecture (EDA)

I was in a conversation with one of my clients the other day when he casually asked me, “So what are your thoughts on the question of SOA vs. EDA?”.  My blank, uncomprehending stare caused him to continue by explaining that representatives from a large “research and advise” firm that I shall not name had been talking to them about their enterprise architecture and seemed to think that they needed to strive for an EDA capable platform, not “just” SOA.  He referred me to a document that had been written by a couple of fine fellows from this firm, which I read and was the inspiration for this blog.

Asking which is better or even which is better under which circumstances, seems to me to be like asking which is better: a) Democracy or b) Capitalism?  Neither has anything to do with the other.  About the only similarities that I could argue that SOA has with EDA are that a) they are both badly named (although I will definitely agree the SOA is a much less informative name than EDA) and b) they are not architectures but rather design paradigms.  They are intended to address totally different parts of the problem space and both, either or neither can be used simultaneously in any given “System”.

I have said previously that the purpose of SOA is to enable the Manageability of System Complexity; as far as the definition of SOA I think the closest we can get is the generally accepted “Four Tenets of SOA” as proposed by Don Box:

1. Boundaries are Explicit
2. Services are Autonomous
3. Services share Schema and Contract, not Class
4. Compatibility is based upon Policy

You will notice that nothing what so ever in the above refers to RPC, calls out the cardinality of the Message passing nor defines any responsibility for determining message routing at either the client or the “service”.  It says nothing about either the holding of state nor the delivery of messages.  All that we are saying is that the boundaries between sub-parts of the system are clearly defined and loosely coupled, the definition is entirely in terms of the Message that is passed across the boundary.  There is no dependency between components other than compliance with the Message format and Contract that defines the exchange.  Any component (either in existence at the time of the creation of the system or subsequently built) that will supply and/or consume such messages in accordance with the explicit policy will be able to function in the system as a whole.  There is absolutely no requirement here for SOAP, XML, RPC or any “predefined” Message routing – these certainly MAY be defined by the Policies and enforced in the Contracts but they would represent one possible implementation of Service Orientation, not Service Orientation itself.

EDA is all about Message routing, part of the system that SOA says nothing what so ever about.  There are basically two methods of defining message routing; it can be predetermined – flow based – such as you might see in a traditional, client server type application, a “new age” BizTalk Orchestration or even a “prehistoric” Mainframe JCL job.  If it is not predetermined then it must be evaluated at runtime based on the content of the message or events that occur during the system operation, you might see this in an Email System, a Pub-Sub architecture or Windows itself.  The later is required in EDA.  You could think of Windows programming as the classic Event Driven Architecture – you have lots of subsystems all sitting around doing “nothing” waiting for messages to get dropped into their message loops after which the spring into action to do “something” and may then post messages to other message loops based on what was in the message they received.  It is of course quite possible (even perhaps quite normal) to see systems that are hybrids of these two.  So flows are predetermined because they can be, where as others are not.

If you have a system that respects the above tenets but uses only predefined message flows then you have SOA but do not have EDA.  If you have a system that does not respect the above tenets but “reacts” to messages that are sent in response to “events” and may be routed in different paths depending on their content, then you have EDA but not SOA.  If you have a system that reacts to events in order to send messages in non-predetermined paths in a manner that respects the above Tenets then you have SOA and EDA.  If non-of this applies then you have neither SOA nor EDA.  It really is that simple!

I once designed an Order Management System that would was both Event Driven and Service Oriented.  Basically a collection of “Services” sat on the perimeter of a communications hub.  As each Service acted on the Order (perhaps by pre-authorizing the billing, or by checking available Inventory), if it altered the state of the order in any way it would raise an event that would say so.  Any service could subscribe to this event and supply a filter which would be applied against all changed orders.  If an order had changed such that the given filter recognized it as “interesting” to that service, then the service would be notified, it may then act on the order itself and may or may not change the order, repeating the whole process.  Why design a system this way?  Well by respecting the rules of SOA we gain the manageability of what will fast become a very complex system.  Sub-parts can be added, removed, changed or moved quickly and easily.  By making the system Event Driven we completely decouple each “service” from each other – each acts upon the Order(s) when it determines that it needs to.  Thus when the business process changes there is no complex altering of Routing and trying to squeeze in new “services” or eliminate existing ones (perhaps under only certain circumstances).  The system is both Flexible and Manageable.

Is there a down side?  Well complying with SOA in this case makes certain efficiencies harder to incorporate.  Because each of the services had distinct and well respected boundaries, one service can not leverage the internal state or another in its decision making except by caching already known results.  Adding the caching provided the performance required, but definitely added to the development complexity (I have said before that SOA does not reduce complexity, it merely strives to make it manageable).  Making it Event Driven made it tremendously flexible, message routing was determined entirely at runtime and could be customized for each individual order.  The downside is that there is no easy way to predict any given message flow so it adds to the testing burden.

I really think that the confusion over what is and what is not Service Oriented stems from people’s preconceptions of what is meant by the extremely overloaded term “Service”.  I have said many times in the past that Service Oriented Architecture is an extremely poor name because it is really not at all descriptive of what it really is all about.  I can’t do anything about the flavor, if you don’t like it you won’t like it, but I hope this blog may have made the Alphabet Soup just a little less murky.

What Lessons Can An Old Typewriter Teach Us?

It was a bright sunny afternoon in early January, the sun was shining in a blue sky with just the occasional puffy white cloud, the temperature was in the mid 70’s and all was well in my little world.  I was on a back road to a little airstrip from which I like to fly listening to the radio as is my wont and they were talking amiable non-sense about art in the work place made from paperclips and post-it notes.  One of the studio guests was commenting on the sound of a “real” typewriter that had been in a previous report and how that brought back memories of times gone by and the smell of carbon paper that they had used to make copies of typed memos before the age of the photocopier.  She spoke about the difficulty in correcting mistakes made on the typewriter because although they had a “state of the art” IBM model that could “lift” the incorrect type from the page with a single button press, it would not correct the copy on the carbon paper below.  This they would “painstakingly” fix with correction fluid – liquid paper that would cover the mistake and allow them to write the correct letter in place of the one that had been mistyped.

My mind lingered on this long after the panel had moved on to more interesting subjects such as the “little boy in the candy store” feeling when standing alone in the office supply room…I remembered doing this myself (correcting mistakes on a typewriter that is, not standing in awe at the sight of neatly arranged stacks of notebooks and pens).  It occurred to me that we did make mistakes - it felt like we made a lot of them at the time because of the huge effort needed to correct each one - but I remember a “mistake” was typing the wrong letter, hardly ever the wrong word.  I pondered next the fact that when typing up an article even as short as this I delete whole sentences, sometimes even paragraphs at a time and what would we do with out that little squiggly red line that appears ever too frequently to show us just how bad our spelling has become.

The reason, I postulated, was the lack of planning for each such authoring event, combined with the lack of training in the correct methods (such as grammar and spelling).  To be fair now the fact that the typing pool could type up memos so fast and so accurately was in part because they were typing up a hand-written note prepared for them by someone who had already structured the content for them; now in the age when every one at every level has their own “typewriter” these two actions are combined.  This in turn leads to much larger corrections, some not “mistakes” in the classic sense but rather word choices that are later revised.  The number of crossings out and rewordings on those hand written memos attests to this without knowing how many copies hit the trash before ever making it to the typing pool.  Even so the thought occurs that a difference has been made here and we should at least question if it is entirely for the positive.  Why should it matter that the medium for final deliverable and the intermediate scratch pad on which our thoughts are incubated have been combined?  Perhaps it matters because the scratty hand written note would never have been delivered to the world of paying customers, or bosses or employees, it would have been typed up and then reviewed before being blessed for dissemination to its intended audience.  Just how much review and preening is built into the system now that thought and action have been combined into a single operation?

By now many of you are wondering why I am driveling on about life in the typing pool some 20 years ago vs. the “modern” age of word processing software on each desk.  The point is this…we have done a wonderful thing in lowering the cost of mistakes.  No longer must we manually correct each letter mistyped, painstakingly examine each word for spelling mistakes, and risk the complete re-work of the entire page if a larger mistake has been made with only the hope that it will be done correctly the second time.  In so doing, we have made mistakes more tolerable and lowered the barrier of entry for those who wish to be able to produce such neatly typed output, but what have we lost in the bargain?

By no longer requiring people to have to know how to spell each and every word, we have lowered the effort that they put into learning (ask yourself how many times you type the same word wrong the same way these days, even though your desktop application brings it to your attention each and every time).  By allowing editing “on the fly” with little or no penalty, we have encouraged the writing of documents whose structure is not thought out in advance and the result is often not the clarity of reading we might otherwise hope for.  By correcting spelling on the fly we have encouraged the lack of proof reading that would catch correctly spelled but incorrectly “sensed” words that change the whole meaning of text that we have written.

This phenomenon is not restricted typing the written word.  It plagues us in software development too.  We have done much to lower the cost of mistakes.  We have made it easier for very laudable reasons.  We have created new languages that encapsulate complex ideas and abstract them away into the plumbing.  We encourage prototyping to develop new ideas in order to quickly “see” the product, to better shape it to real needs.  We design our architectures for maximum flexibility in post developmental reconfiguration …SOA could be said to be the state of the art in that matter.  A well design Service Oriented system can be reconfigured on the fly to meet changing needs.  Ergo, if the needs in the minds of the system implementers are in fact completely different from the needs in reality we can leverage this flexibility to accommodate the difference (to undo the mistake).  Does this mean that there is no value in the Software Engineering principles that we used to rely on when we couldn’t afford to fix mistakes later?  Hardly!

I think about how tempting it is even for such a “dinosaur” as me to forget all about rigors of software design as I was taught them so long ago…  It seems so much easier to leap in to code, build some “prototype” screens in the editor and by mid-afternoon have a “working” system.  We can change the badly thought out bits later, we probably never will though…  Many of my colleagues have also lived through the development of Software Engineering through the past quarter century and more; though none of us are immune to the skills atrophy process, at least we were taught how to use process, planning and forethought to avoid the mistakes in the first place.  Some of us are so old that we “desk checked” every line of code before ever running the compiler because computer time was so much more expensive than human time.  The result was that tremendous amounts of thought and planning when into our work.  What of the younger generation?  Much as the mathematics skills of the school kids of today has been found somewhat lacking because of the ubiquitous nature of the calculator, are we building a pit for the next generation of “Software Engineers” to fall into? 

What am I suggesting?  That we should forget about Prototyping and Service Orientation?  Dismiss “Managed” languages as heresy?  Go back to the waterfall method of building monolithic code, but do it carefully?  Abandon our Word Processors and recreate the old typing pools?  Smash the Spinning Jennies?  Luddites of the world unite!  No, I think not; instead I believe that we should be grateful for the tools that allow us recover from mistakes more cheaply but that we should fight continuously against the natural tendency that such tools have to atrophy the skills we used to use to avoid those mistakes in the first place.  Use the tools we have to augment the skills we have, not to replace them.  The new tools can make us so much more productive, allow us to deliver so much more quickly, but we must never allow them to be used as a substitute for thinking the problem through.

Service Oriented Architecture (SOA) - what’s the point?

Of all the questions I get asked these days, the most often asked and most difficult to answer is perhaps “What is SOA?”.  There are many reasons for this, principle amongst them being that Service Oriented Architecture is such a bad name.  It isn’t really an Architecture, Oriented means online “Aligned with” so doesn’t tell us much and Service is such an overloaded term that no two people really ever have the same understanding of what it does mean.  I will expand on this issue at another time however, at the moment I wish to write about what I think ought to be the most asked question, which is “Why should I care what SOA is?”.

I find it interesting that when I ask people, “What is the point of SOA; what are we trying to achieve with it?” the answers that I get are generally along the lines of better interoperability.  I couldn’t disagree more.  I have been told be many that should know better that SOA is a new thing and the Web Services are absolutely fundamental requirements for it.  Perhaps the prevalence of this point of view is what leads to the belief that it is all about interop.  If you subscribe to this point of view, I would like you to imagine an IT shop that is entirely Microsoft or entirely a specific flavor of Unix and does no electronic business with other companies.  There is absolutely no need for interop in such a mythical shop but would there still be a benefit to be reaped from SOA?  I believe so.

I think of SOA as a paradigm, a way of thinking about the interaction between component parts of a system, in the same manner as OO but with a completely different perspective.  Instead of imagining discrete bundles of both data and operations as “Objects” that know how to do things to themselves, we are breaking the solution down as a set of “Services” that know how to understand “Messages” and do something useful with them.  The separation of data from the operations performed on that data is key here and it is not new at all.  Let’s explore for a moment the “Four Tenets of SOA” as proposed by Don Box:

1. Boundaries are Explicit
2. Services are Autonomous
3. Services share Schema and Contract, not Class
4. Compatibility is based upon Policy

The first Tenet states that the author of the each service defines exactly what messages it will and will not react to and the only interfaces available to send or receive these messages are those defined by the author.  The second explains that these services are not subservient to other code, this is to say that a service reacts to a message – how that message was created and what will happen to any response the service creates is immaterial to the action that this service will take.  The third Tenet states simply only messages pass from service to service, code does not and that these messages are not random but a sequence of one or more that have been agreed upon.  Note that Schema mentioned in this Tenet does not necessarily imply XML Schema, merely that the message format is explicitly defined.  The fourth is interesting; we are saying that each Service has a set of Policies that it expects to operate under and it is not prepared to operate unless these Policies are satisfied (a policy might be: I will except messages from any source, but if the message is not from my subnet then it must be signed and the only signature I will accept is X509).  Of course this has always been true because systems are always designed such that individual parts work together under a set of policies, but usually these policies are implicit (I will do xyz for any component that calls my interface using C notation and send me two integers with in the range I can handle)  -  Tenet 4 implies, although doesn’t actually state, that this should be explicit and further more if it is both explicit and machine readable then truly great things can come of it, but that is for a future blog.

Many of us have built systems that comply with all of the above Tenets long before XML and Web Services where ever thought of so very clearly this is not a new thing.  All that said, I do think that Web Services, XML Data, XML Schema and the WS-* protocols bring an ideal environment in which SOA may flourish.  For whatever reason, XML has become the de facto standard for sharing data across system boundaries, XML Schema allows these “Messages” to be described in a language independent manner and the WS-* protocols provide an excellent opportunity to make Policy both explicit and machine readable - I think this is the driving force behind the resurgence of SOA.

So I have covered a lot of ground about what SOA is and what it isn’t, but I still haven’t said why I think it is important.  All this stems from what I believe is the actual goal of SOA. It isn’t interop; if that is all you want then sprinkle a few Web Service interfaces on your existing design and you will have opened up your application to all platforms - but you will not necessarily have benefited from SOA.  The whole reason for doing this in my opinion is to be able to Manage Complexity.  Note that I didn’t say reduce complexity.  Actually I believe a well designed Service Oriented system may well be more complex than it might otherwise be, but what it will be is manageable. 

Because of the Autonomous nature of the Services, because of their Explicit Boundaries and because the Message Flow is defined by Schema and Contract, component parts can be moved, augmented or even replaced as the needs of the organization change.  If the Policy is explicit then the impact of these changes can be readily assessed and indeed if it is machine readable then a toolset can be develop to ensure it is done consistently and correctly – that I do not mistakenly attempt to hookup a component to another that can not understand its messages, or run a component service in an environment under which it can not operate.

Lofty goals?  Perhaps, but achievable I think – at least they will be if we know what we are trying to achieve.