Tracking the Elusive SOA Platform

ZapThink fears no loaded hype-word, and in this ZapFlash, we take on one of the gnarliest: platform. While there are many definitions of this term, the one that we focus on here is the notion of a runtime execution infrastructure that allows compiled and/or uncompiled code to run. However, this definition is tricky because Service-Oriented Architecture (SOA) is not about the code, but rather the composition of Services into flexible processes. Naturally, there must exist some runtime infrastructure for Services to actually run, only now, we mean something different by the word “run.” SOA, after all, is enterprise architecture that leverages heterogeneity, so an SOA platform would have to be inherently platform-neutral. Furthermore, SOA is more concerned with the Service interface and above (including composition metadata, security policy, and dynamic binding information), more so than what sits beneath the abstraction of the Service interface.

Maybe you picked up on the fundamental paradox in the last paragraph: how can there be a such thing as an SOA platform if platform neutrality is a core requirement for SOA? Does it make any sense for a platform to be platform-neutral? The reason we have a paradox at all is because we’re extending the meaning for the word platform. We defined a platform as a runtime execution infrastructure, but SOA requires a different kind of platform, because runtime execution has different meanings within SOA. As we explained in a previous ZapFlash, the goal of SOA is to enable business users and business process architects to compose Services into processes, and then manage and evolve those processes, in a declarative fashion. Runtime execution of such processes is therefore a metadata-centric operation of a different kind of platform — a Service-oriented composite application platform.

Application Infrastructure vs. Service Infrastructure

The confusion over the different senses of the word platform arises from the fact that composite application platforms are a part of the declarative Service infrastructure, while the underlying runtime execution platforms are essentially a part of the programmatic application infrastructure. Composite application platforms essentially abstract the underlying technical implementation details and provide a runtime execution infrastructure for building and running composite applications that are Service-oriented processes.

There are two important points we’d like to make here. First, composite application platforms require an underlying runtime execution platform for them to run on — after all, they’re written in code, and that code needs a place to run. However, the runtime platform is not where SOA’s value lies. Rather, the runtime platform simply makes the system work in much the same way that computer chips still operate on a binary level, but we’ve stopped coding at the binary level a long time ago. Secondly, it’s critical to understand that composite application platforms and runtime execution platforms are different creatures altogether, and composite application platforms are better suited for SOA than runtime execution platforms alone are. Composite application platforms make no assumptions about the runtime environment and focus instead on the metadata that describes and governs the interactions between Services, while runtime execution environments are mostly concerned about how a given Service is implemented and executed.

Building the SOA Platform from the Ground Up
Let’s take a look at the two leading runtime execution platforms: J2EE and Microsoft Windows/.NET. While both of these runtime platforms make excellent underpinnings to enable Service execution, they aren’t in and of themselves an SOA platform. To understand why neither of these platforms is fundamentally an SOA platform, think about what an SOA platform might look like if you set out to build one from the ground up.

Let’s take a look at Java 2 Enterprise Edition (J2EE) first. Now, you can build perfectly good SOA implementations on J2EE — in fact, you can build fine SOA implementations on many different platforms and products, as we explained in a previous ZapFlash. Many of the SOA implementations in production today depend on their J2EE-based runtime infrastructure. In fact, Java is many things — an object-oriented programming language, a virtual machine infrastructure, and the J2EE flavor of Java is specifically a framework for implementing n-tier architectures. Unfortunately, none of these facets of Java, or any other virtual machine-based, object-oriented runtime environment for that matter, are ideally suited as a platform for SOA. Object orientation (OO) creates object instances through instantiation, and these instances maintain state within the execution environment. Services, however, maintain state through metadata. From the OO perspective, a Service and a Service instance are the same thing. The whole notion of an object instance as an individual thing provides little value in SOA.

Furthermore, the virtual machine (VM) was not crafted with SOA in mind, and as such is not particularly suited for SOA either. The goal of the virtual machine is to provide for code portability, while in SOA, interoperability is far more important, as we explained in another ZapFlash. Why go through all that trouble to build portable code, when in SOA, you want to leave the code where it is? Fundamentally, the virtual machine approach to distributed computing is through the serialization of objects leading to remote method invocation, while SOA runs on the exchange of messages between Services with contracted interfaces. You can use Java to exchange messages between contracted interfaces as well, to be sure, but the only reason you are doing so is because you’re already using Java — not because Java would have been your choice if you had crafted a platform that was Service-oriented to begin with.

Finally, let’s take a look at the Enterprise JavaBeans/Servlet/Java Server Pages framework that J2EE provides. Clearly, J2EE focuses on providing a framework for scalable n-tier architectures like those that large, transactional Web sites require. However, if you were to set out to create an enterprise-class framework for SOA, you’d build something quite different — you’d build a framework centered on enabling and maintaining the Services abstraction layer so critical to SOA. So, while J2EE is well-suited for running platform-dependent Services, it is not Service infrastructure. J2EE wasn’t developed to be a Service-oriented platform, but rather, the best distributed, virtual machine-based, object-oriented platform around for runtime code execution. In an SOA, declarative, metadata-driven composition trumps portable code, and that’s just not what J2EE is ideally suited for.

Now, let’s take a look at the Windows/.NET platform, in particular, what Microsoft is doing with Windows/.NET in the Longhorn wave (the next major version of Windows) and its programming model code-named Indigo. Indigo essentially brings together Microsoft’s hodgepodge of existing programming models and application programming interfaces (APIs), including COM+, Enterprise COM, .NET Remoting, and others, into a single, Service-oriented programming model. From this core Windows/.NET/Indigo combination, Microsoft is building out their entire distributed computing infrastructure to be a loosely-coupled set of different runtime execution infrastructures, each abstracted by a Service interface. So, is Longhorn well-suited to be an SOA platform?

Even if Microsoft executes fully on their Service-oriented vision for Longhorn, it is still possible that it may not be well-suited as a platform for many SOA implementations, because Longhorn is, and always will be, a single-vendor platform. It’s true that Microsoft takes open standards and interoperability seriously, but the Microsoft platform participates in heterogeneous environments by promoting interoperability between everything running on the platform and everything running outside the platform. Inside the platform, homogeneity is vastly preferred over heterogeneity.

In other words, Microsoft basically offers a clear value proposition to people who have already bought into the .NET vision: build your SOA on our platform, and take advantage of the fact we built it ground-up for SOA. But for those organizations who work within the context of heterogeneity, the Microsoft value proposition (or any other single-vendor value proposition, for that matter) isn’t meant to be the sort of heterogeneous, declarative, SOA platform that abstracts the runtime environment in a way that SOA requires.

Platform for your Platform?

One Service-oriented composite application platform or another might be the best platform for SOA, but none of them can replace J2EE or Windows/.NET, of course, since every composite application platform needs its own underlying runtime execution platform to run on. Some run on J2EE, others on .NET, and there are many other platforms as well, including mainframe, script-based, and other proprietary and open source platforms. In other words, there are two different kinds of platforms here, ones that provide the execution environment for declarative composite applications, and others that offer the execution environment for the underlying programming code. Ideally, it won’t matter which underlying platform your composite application platform runs on, as long as the composite application platform satisfies the business requirements set out for it. Fundamentally, it is inappropriate to be thinking of runtime execution platforms as SOA platforms. The notion of the platform here is at a more abstracted level — a level in which we don’t emphasize the execution environment, even though we know that one, and most likely more, must exist.

There remains the question as to which underlying execution platform is the best one to build a composite application platform on top of, but it’s important to note that that question is actually irrelevant to the question at hand. Vendors who are building composite application platform products must decide whether to use Java or .NET (or something else), to be sure, but those vendors aren’t the ones implementing SOA — their customers are. If the choice of underlying platform a composite application platform vendor makes impacts their customers’ SOA implementations, then there’s something wrong with their product. Composite application platform products must truly abstract the underlying execution environment — in other words, they must be platform-independent SOA platforms. In essence, SOA platforms only deal with the Service abstraction and things that layer on top of that. What’s underneath should be a mystery to the composition platform.

The ZapThink Take
As the Service-oriented composite application platform market is only now beginning to get traction, most companies implementing SOA today are assembling their own custom platforms from pieces and parts — often using their existing middleware and platform infrastructure, with the addition of additional software that provide the capability of ESBs, SOA management, policy and governance tools, and the like. Yes, you can build perfectly good SOA implementations this way, on J2EE, Windows/.NET, or some other platform. Nevertheless, the fact still remains that taking the pieces-parts approach to implementing SOA means doing more work, and taking on more risk, than may be necessary. As the composite application platform market matures and the leading products in this space work their kinks out, there will gradually become a clear distinction between SOA platforms and runtime execution platforms.