“SOA” doesn’t really exist, does it?

In the past months I’ve been throwing ideas back and forth with some of my friends and we’re slowly realizing that “Service Oriented Architecture” doesn’t really exist.

The term “Service Oriented Architecture” implies that there is something special about architecture when it comes to service orientation, Web services, XML, loose coupling and all the wonderful blessings of the past 5 years in this wave. But if you look at it, there really isn’t much special about the good, old, proven architectural principles once you throw services into the picture.

I’ll try to explain what I mean. There are five pillars of software architecture (this deserves more elaboration, but I will keep it short for now):

·        Edges: Everything that talks about how the network edge of a software system is shaped, designed, and implemented. SOAP, WSDL, WS-*, IIOP, RMI, DCOM are at home here, along with API and message design and ideas about coupling, versioning, and interoperability.

·        Protocols: Which information do you exchange between two layers of a system or between systems and how is that communication shaped? What are the communication patterns, what are the rules of communication? There are low-level protocols that are technically motivated, there are high-level protocols that are about punting business documents around. Whether you render a security token as a binary thing in DCOM or as an angle brackets thing is an edge concern. The fact that you do and when and in which context is a protocol thing. Each protocol can theoretically be implemented on any type of edge. If you were completely insane, you could implement TCP on top of SOAP and WS-Addressing and some other transport.

·        Runtimes: How do you implement a protocol? You pick an appropriate runtime, existing class or function libraries, and a programming language. That’s an architectural decision, really. There are good reasons why people pick C#, Java, Visual Basic, or FORTRAN, and not all of them are purely technical. Technically, the choice of a runtime and language is orthogonal to the choice of a protocol and the edge technology/design. That’s why I list it as another pillar. You could choose to do everything in Itanium assembly language and start from scratch. Theoretically, nothing stops you from doing that, it’s just not very pragmatic.

·        Control Flow: For a protocol to work and really for any program to work, you need concepts like uni- and bidirectional communication and their flavors such as datagrams, sockets, and queues, which support communication styles such as monologues, dialogues, multicast, or broadcast. You need to ideas like parallelization and synchronization, and iterations and sequences. All of these are abstract ideas. You can implement those on any runtime. They are not dependent on a special edge. They support protocols, but don’t require them. Another pillar.

·        State: This is why we write software (most of it, at least). We write software to transform a system from one state to the next. Press the trigger button and a monster in Halo turns into a meatloaf, and you score. Send a message to a banking system and $100.000 change owners. Keeping track of state, keeping it isolated, current, and consistent or things to consider. Is it ok to have it far away or do you need it close by? Do you cache, and replicate it for the purpose? Is it reference data or business data? Consolidated, preprocessed, or raw? How many concurrent clients have access to the data and how do you deal with the concurrency? All these are questions that have to do with state, and only state. None of this is depends on having a special technology that is being talked through way up above at the edge.

Service orientation only speaks about the edge. Its tenets are about loose coupling, about independent evolution and versioning of contracts, and about technology-agnostic metadata exchange. All this is important to make systems interoperate better and to create systems where the effects of changes to one of its parts to any other part are minimized.

But none of the SO tenets really speaks about architecture [Sidenote: The “autonomy” is about autonomous development teams and not about autonomous computing]. When you look at what’s being advertised as “serviced oriented architecture”, you see either the marketing-glorified repackaging of Ethernet, TCP/IP, and LDAP (“Enterprise Service Bus”), or architectural blueprints that looks strikingly similar to things that people have been doing for a long time with DCE, CORBA, J2EE, COM, or mainframe technologies. What’s different now is that it is easier, cheaper and likely more productive to create bridges between systems. And even that comes at a significant price at this point. Realistically, the (web) services stacks yet have to catch up with these “proprietary” stacks in terms of reliability, security, and performance.

There is Service Orientation – and that’s good. There is appropriate architecture for a problem solution – and that’s good too. These are two things. Combining the two is excellent. But “Service Oriented Architecture” is not an isolated practice. I’ve started to use “SO/A” to make clear that I mean architecture that benefits from service orientation.

I understand that there is an additional architectural tier of “service orientation” that sits at the business/technology boundary. On that meta-level, there could indeed be something like “service oriented architecture” along the lines of the service convergence that Rafal, Pat and myself were discussing on stage at TechEd Europe last year. But when I see or hear SOA discussed, people speak mostly about technology and software architecture. In that context, selling “SOA” as a completely new software architecture school does not (no longer) make sense to me.

Or am I missing something?