The American comedian and actor Steven Wright once said, "It doesn't make a difference what temperature a room is, it's always room temperature." Words are wonderful that way. They can give you a little blast of pleasure when used cleverly, but like everything else they are subject to fashion. For example, I was speaking at a technical conference recently when I overheard a person whom I know, who is well-respected in this field, say something along these lines: "You have to know how well your SOA is running. Knowing the overall health and responsiveness of your SOA is very important. You've got to get a handle on your governance." The goal was laudable, but the wording was off target.

I've heard the word governance fall from people's lips with increasing frequency recently, which is a good thing. Lately though, it seems to me that there has been an unfortunate blurring of the usage and definition of the word governance with another important word that also ought to be on the tip of the tongues of most people involved with SOA today, and that word is management. Monitoring and controlling the overall health and responsiveness of your SOA is largely a function of management, not governance.

The person whom I mentioned above probably knows this, at least in his better moments, but fashion is a powerful force. Trust me on this. You may consider yourself an up-to-date person both technically and in your style of language and dress, but I assure you, fashions change. Many years from now, photos of you wearing cloths that were once considered the height of fashion may cause your very own children to turn on you. There is no defense against the younger generation when they sense vulnerability any more than you can convince a shark in the midst of a feeding frenzy to try tofu. Speaking from a theoretical perspective, naturally, my advice is to be prepared for the likes of "Gee, Dad, how could you have possibly gone out in public dressed that way?"

A good response is to flash your progeny a peace sign and beat a hasty retreat.

Similarly, in order to spare our dear readers the potential embarrassment of explaining to future generations of telepathic IT people what an SOA was and why we even cared about it, it seems prudent to review and solidify our own architectural understanding. Let us consider the functional elements of an SOA starting with those elements responsible for the actual creation and execution of services. Later, we will focus on other essential elements such as management, governance, and security, and we'll examine their role in the SOA and their relationship with the rest of the IT infrastructure upon which the SOA depends, as well.

Creation and Execution of Services
Many well-known types of enterprise software such as application servers, integration servers, and large business systems have evolved to provide the essential elements needed to create and run services in an SOA. Most often these are Web services based on protocols such as SOAP, but can include other types of services based on technologies such as CORBA or Java RMI as well. These newly evolved entities are often called service platforms. Service platforms minimally provide a service runtime environment for the execution of services, but are often bundled with tools that provide many other capabilities. Most commonly, they include development tools that provide the ability to develop and deploy services to that same runtime environment. Therefore, it is no surprise that most application servers and their associated development environments have been transformed and remarketed as service platforms.

SOA is also about breaking down the barriers between previously isolated legacy application silos and reusing these capabilities in new, more flexible ways. Therefore, both integration servers and messaging middleware vendors, which often have more specialized mechanisms in order to work with legacy systems, have joined the service platform game as well. In fact, a wide range of diverse platforms and technologies are transforming themselves into services platforms. For example, many application vendors such as SAP are also offering service platforms that provide the added benefit of leveraging the business application itself.

Many of these service platforms feature embellished tools that are helpful in designing and creating a modern SOA, including support for many Web services standards. These platforms are usually capable of composing simple Web services into more complex composite ones, and frequently provide orchestration engines so you can more easily create high-level business processes out of these services. They are designed to aid reusability by making it easy find new services via discovery mechanisms (typically UDDI registries), another element of SOA, which they often include as part of a complete service platform package.

Despite their architectural, technical, and functional diversity, one thing that many service platforms have in common these days is that they increasingly follow the current fashion of calling themselves an Enterprise Service Bus or ESB (a previously fashionable word was "fabric," but that has now fallen into disfavor). In my opinion, this was a smart move from the marketing perspective because it creates the impression of an indivisible and essential component. After all, what computer can operate without its bus?

However, unlike a computer bus, elements of an SOA related to the service-oriented applications themselves such as development, runtime, orchestration, transformation, guaranteed message delivery, or registry can also be provided by more specialized stand-alone products, depending on the needs of the organization. As these capabilities become increasingly mature and commoditized (a challenge that J2EE application servers started to face a few years ago), many organizations have already found that they have multiple ESBs and point-products with overlapping capabilities.

Service Platform Limitations
For many organizations, the success of the SOA may ultimately be more dependent upon other SOA elements, such as operations management and security management. As different types of service platforms proliferate, the management and security challenges become more difficult. Why can't service platforms easily provide these capabilities in an SOA? They often promote themselves as "all you ever need to build an SOA." In fact many service platforms do provide limited management and security capabilities. However many service platforms are quite rightly focused on maximizing the benefits of their own technology stack, rather than leveraging and increasing the value and utility of all service platforms that participate in an SOA. Indeed, the service platform vendor may have limited experience or incentive to leverage the management and security capabilities of any platform but its own.