The SOA generation gap: Enterprise Service Bus products

An interesting phenomenon is becoming apparent in the service-oriented architecture products space, and it is related to the growing gap between longtime vendors such as Tibco and Oracle and newer entrants such as Infravio and Reactivity. I’ve spent the last two months talking to vendors in preparation for an SOA landscape paper and what is becoming increasingly apparent is that the two groups are diverging.

The Oracle and Tibco Enterprise Service Bus (ESB) products, along with those of most other ESB vendors, evolved from the Enterprise Application Integration (EAI) space. This evolution has been a boon for ESB vendors as well as for the industry. Once Web services and SOA became viable, these platforms already included much of the intelligence required for interoperability, including adapters, security and messaging.

This functionality enabled SOA to become practical much earlier than would have been possible otherwise. Today, most production-grade SOA implementations run over ESBs.

During the late 1990s and early 2000s however, Web services began to mature and to drive a new set of solutions. Unlike established solutions that evolved over time, these were smaller, modular products that were standards-based and designed for specific functionality. Instead of building one-stop SOA monoliths, the vendors of this new generation concentrated on doing specific functionality extremely well, and relied on other companies to fill the gaps. For these vendors, standards are in the DNA and partners are of vital importance – without both, SOA implementations aren’t possible.

Infravio, founded in 1999, produces XRegistry, an SOA registry and repository. Infravio senior management has been heavily involved in standards development and an Infravio executive is the chair of the OASIS SOA Adoption Blueprints Technical Committee. Reactivity, founded in 1998, produces an XML Message Gateway, among other products. Reactivity is co-author of WS-Security, WS-Trust, WS-Federation and many other standards. The lists of the standards these two vendors support and the products they interoperate with are extensive.

For the new generation of SOA vendors, standards, integration and partnerships are a foundation, not an afterthought. These are key concepts that are architected into the products from day one. This is a luxury that most veteran ESB vendors did not enjoy. Most now have enormous code bases that make it difficult for them to respond with agility to today’s very fluid IT landscape. Adding new capabilities is a challenge. Supporting a capability as fundamental as an architecture change, such as SOA brings to the table, is an even bigger one.

Are we approaching a time when there will be multiple choices for building enterprise grade SOA? Instead of running as part of a code-heavy enterprise service bus, the SOA implementations of the future could very possibly consist of a lightweight SOA framework populated with Web services based, plug-and-play snap-ins for registry, repository, orchestration, security and other SOA functionality. In addition, there are ESB vendors out there that have adapted SOA principles to their own products and become more flexible as a result. The functional and architectural aspects of these diverging solution sets are intriguing and will be the subject of the next article in this series.