In thinking about the management challenges of utility computing (how do you manage 10,000 virtual machines anyway?) it was obvious that the right high level abstraction for management is the composite application. A composite application represents the collection of services (ala SOA) that are being brought together to perform some action. This then got me thinking about SOA in general and has led to a new project I'm working on in parallel to the utility computing work called SOA Lifecycle (SOAL). But, as with my utility computing priorities article, I like to know what my priorities are before I dive into a project. So below I explore what I believe the priorities are for SOA in the enterprise.
My priorities for building software to enable SOA in the Enterprise:
(Note: See here for my definition of SOA)
Re-Use: I start off with Re-Use because I believe that this is the fundamental value of SOA. At the risk of radically over simplifying, the single most important factor in the growth of an economy is productivity. Or, to put it more bluntly, the faster productivity goes up the faster we all get rich. I believe that SOA (read: networked code) will, if its potential is realized, provide an enormous productivity boost because of re-use. With SOA if someone, somewhere designs a process that does something well it suddenly becomes possible for everyone, everywhere (in theory anyway) to go re-use it. Furthermore this re-use can occur as easily within a company as across companies (again, in theory). Yes, I know, this is all kind of obvious. But in picking from the pot of obvious ideas about SOA I think this one is the most important. The more things we do to enable re-use the richer we will all be.
Manageability: SOA in the enterprise is, I believe, fundamentally about making it possible for machines to talk to other machines (as opposed to most Software as a Service use cases which typically involve machines talking to humans). The result being that the machines handle the day to day drudgery of running a business leaving the people to deal with more interesting issues. But the downside of a machine to machine environment is that machines are unspeakably stupid. If an interface changes in even the most trivial way it's quite likely that all of the other services that try to consume that interface will fail. Yes, I know, loose coupling (a.k.a. versioning) will solve all of our problems. But as I have discussed previously, nirvana isn't here quite yet. So in the meantime what we will have to have is management. Management tools will be crucial in order to enable administrators to monitor the services they depend on and to manage changes when they are required.
Simplicity: The Rube Goldbergesque fiasco that is WSDL, XML Schema and WS-* should, I hope, act as a useful reminder of a very old lesson – complexity is the enemy of reliability. Building a huge stack of specs and products and then saying to Enterprise developers "Go build on this peak" has been and will continue to be a recipe for failure. We must radically simplify the SOA infrastructure or it will never properly work. This means, for example, largely ignoring WSDL and eschewing XML Schema. This means pretty much automatically staying away from any spec that has a "WS" in front of it. Following these rules one would look at a nightmare like WSDM and run in the opposite direction. In any case the point is to start with the simplest infrastructure possible (XML+HTTP) and only add new infrastructure features when absolutely necessary.