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