One of the most common inquiries that we get here at ZapThink is what exactly is the best way to implement SOA. Specifically, people often wonder: what precisely are the differences among the various approaches currently on the market?

	express delivery
	• print  • comment
	While developers often focus on the system-to-system aspects of SOA, the business audience is more concerned about the larger business agility, cost of ownership, and governance benefits. Ronald Schmelzer is senior analyst at ZapThink, an IT advisory and analysis firm that provides trusted advice and insight on the movement to SOA. Sign up today for ZapThink's thought-provoking and influential monthly ZapForum webcast series on topical SOA issues.
	Glossary terms: ESB, SOA, business process, integration, metadata, lookup tool Sponsored links: your text link here

It turns out that these two questions are easy to ask, but challenging to answer for a variety of reasons. First, there are very few established best practices in the market, and few SOA implementations with sufficient longevity to anoint a particular runtime infrastructure as being the "best" approach. Second, many vendors are still in the land grab phase of market growth, jockeying for the right product niche, and as such, many are using market confusion around terminology and features to help sell their product until the market solidifies around an accepted approach.

Fortunately, as companies discover the benefits of SOA, they are increasingly looking for specific features and capabilities that set apart the latest generation of runtime infrastructure technologies from their less SOA-capable predecessors, and as such are realizing the core aspects of functionality that these platforms require. As a result, despite the various names and three-letter acronyms vendors are labeling their products with, the market will likely settle on an accepted set of capabilities for these platforms soon. However, in the meantime, confusion reigns.

ESBs, fabrics, or something else?

One of the points of confusion centers on the term Enterprise Service Bus. Many vendors are using this term, each one in a different way to describe the capabilities of their various products. Other vendors use the term SOA Fabric to describe an overlapping set of features and functionality. In order to clarify this confusion, ZapThink will present a special one-hour online webcast that will delineate these two approaches and offer insights from experts in their use. Running on Wednesday May 4, 2005 at 10:00AM PDT / 1:00PM EDT / 6:00PM BST, "The Great Debate: ESBs, Fabrics, or Something Else?” will aim to give the chief proponents of each approach the forum they need to show whether or not ESBs and Fabrics are indeed different offerings, or just different aspects of the same general approach. You don’t have to just sit and back and listen. Register at www.zapthink.com/zapforum.html to attend, and take this opportunity to voice your opinion on this unique call-in format show.

ZapThink analysts will explain how ESB and Fabric approaches to implementing SOA are counterpoints to the application server and integration broker methods of exposing and connecting distributed, remote systems. Whereas an application server aims to centralize capabilities within a single server or among a cluster of servers to provide reliable, secured, distributed computing capability, ESBs and Fabrics leverage messaging technology and fully distributed container approaches to expose services throughout the enterprise.

You can also expect to hear how to best integrate systems to achieve loose coupling. While developers often focus on the system-to-system aspects of SOA, the business audience is more concerned about the larger business agility, cost of ownership, and governance benefits that SOA must return to justify the investment in architectural change. As such, the discussion of SOA must rise above the technical details to explore the complexities of business process definition, composite service development, service contract negotiation, metadata management, dynamic service discovery, and governance — rather than the relatively simplistic discussion of how services communicate.

When does implementation matter?

The important question is not which method of implementation for SOA is the best, but rather when enterprises should discuss the specifics of SOA implementation. The answer lies in who is asking the question. In the SOA world, there is a clear and distinct delineation between the responsibility of developers and architects. Architects are responsible in part for translating business requirements into a set of evolving, reusable, and composite services that companies can implement in any number of ways. Developers, then, are responsible for translating these service definitions into a specific implementation tailored for the particular corporate IT environment.

Ideally, the architect and developer interactions should themselves be loosely coupled from each other. Specifically, architects should be able to freely make changes to the service definitions, compositions, business processes, policies, and governance aspects of the services under their management without having to communicate those changes directly to the development organization. Likewise, developers should be able to change the implementation specifics of a Service without having to first coordinate with the architects. In this regard, the architects will be more concerned with the metadata that describes the services and their interaction, while the developers will be more concerned with their implementation specifics.

More on this topic