SOA, Stacks, and Standards

For the past week there's been a great deal of grumbling surrounding the idea of finding a "standard SOA Stack".

Rich Seeley did some digging into the issue, and raised the ire of David Linthicum, who claims that anyone searching for the illusive SOA stack just doesn't get it. Bradley F. Shimmin, principal analyst of application infrastructure at Current Analysis LLC. agreed that standardization on a single Web services stack is unlikely given competing stacks from different vendors and the heterogeneous environments of most customers. "I don't think that will ever happen. I don't see how it could happen. It's like assuming that software will never get versioned."

It appears that there is a disjunct across industries regarding the definition of a "stack". Anyone who's grown up in the networking industry understands the term "stack" to generally refer to the implementation of a network architecture designed in layers, like TCP/IP and the OSI model. Hence the use of the term "layer X" to describe a variety of network products, such as Layer 4 load balancing, and Layer 7 switching.

There are many implementations of the TCP/IP stack, and certainly no "standard" stack to which customers flock to when considering a network deployment. In fact, many companies make it their business to build and tweak and tune its product's TCP/IP stack until it's screaming fast, and bank (literally) on the performance of that custom TCP/IP stack. As long as they comply with the appropriate RFCs and, more importantly, actually interoperate with other vendors' implementations, all is good.

The problem with a "standard" SOA stack is, in a nutshell, that the well-defined and accepted "layers" associated with TCP/IP and OSI don't exist. There have been multiple attempts to define a SOA stack, but thus far there is no consensus regarding what layers should be included. While it's generally accepted that there's a transport (HTTP, FTP, SMTP, JMS) layer, a messaging layer (SOAP), a description layer (WSDL), and a discovery layer (UDDI, but increasingly vendors are demanding something more robust), there are a ton of other "layers" that potentially could be included: AAA, transaction management, coordination, and orchestration are just a few possibilities. Once you leave the relatively safe "core" layers of the SOA stack, you begin to limit the ability to compose an architecture from different products and potentially from different vendors. That's the danger of taking the idea of a SOA stack too far, and one of the reasons David Linthicum (rightly) sounds vehemently opposed to the concept.

It's a relatively safe assumption that no single vendor's "stack" will be adopted, and that's okay. History tells us that as long as competing stacks are interoperable, that's a good thing. It would also be dangerous to start defining a SOA stack that goes behind the core layers necessary to provide connectivity and interoperable integration. Doing so limits the flexibility and interoperability of a SOA, and that's exactly the opposite of what a SOA is intended to provide. 

Even if we grant that there should be (and is) a core SOA stack comprised of the transport, messaging, description, and delivery layers, still there is no reason to expect or even want a "standard" stack from a single vendor. The definition of a SOA is fluid and unique to each organization, so there's really no way to define a standard stack above and beyond the core layers for SOA that meets everyone's needs and goals.

Imbibing: Water (yeah, you read that right. Got a problem with that?)