Sep 29, 2007 (08:09 PM EDT)
Next Up For SOA: Convergence And Consolidation

Read the Original Article at InformationWeek

1   2   3  
The SOA Intermediary market is going through rapid consolidation as startups seek to expand beyond their niches and larger players offer suites that claim to cover all of a business' service integration needs. The consolidation is driven partly by the inherent overlapping functionality of traditional SOA intermediary products and partly by the extension of vendors from other market categories into the SOA arena.

There are four main types of SOA products: Enterprise Service Bus, design-time governance, runtime management, and security gateway. The functionality of all four has always overlapped somewhat, though each still has certain unique characteristics not found in the others.

The most mature is ESB, which shuttles data between services. The least mature is governance, a combination of a catalog and a source code management system. Both are almost always provided as software. SOA management systems and security gateways are the equivalent of network management frameworks and firewalls, respectively, and can be provided as either hardware or software, sometimes from the same vendor.

In addition, the growing importance of SOA is encouraging vendors from other market categories to enter the field. On the software side, business process management has always been closely related to SOA, as is the emerging field of complex event processing (CEP). The rich Internet applications (RIAs) of Web 2.0 are driving interest in Web services. On the hardware side, networking players are also moving into SOA, particularly in the areas of management and security, usually through application front ends (AFEs), hardware that can accelerate important functions of all four product categories.

chart: How It All Fits Together -- The different SOA intermediary product groups include a lot of overlapping functionality.  Many features can also be offloaded to application front ends.

ENABLE AND ORCHESTRATE
The ESB has two core functions, both of which have been critical to application integration: service enablement and service orchestration. Service enablement happens at the lower level. It means a collection of interfaces that translates the different APIs of mainframes, ERP systems, CRM servers, and other devices and applications into a common language so that they can talk to each other. At a higher level, the ESB can combine the newly exposed services into new applications, known as composite applications.

Multiple standards mean that service enablement is usually still necessary even as application platform vendors adopt native Web services interfaces, though it can sometimes be avoided in a single-vendor environment. In addition to ESBs, service enablement is also available in some design-time governance products, as well as specialized integration packages. Orchestration overlaps somewhat with BPM, and many vendors offer integrated products, though so far there's little standardized communications between BPM suites and ESBs.

Between the two core ESB functions are translation features, required by most SOAs that link together applications running on multiple platforms or from multiple vendors. These also can be provided by runtime management suites and fall into two main categories: XML transformation and protocol mediation. Both involve converting between data formats and protocols, XML transformation at the application layer and protocol mediation lower down the stack. For example, many enterprises use Java Message Service internally, which must be converted to Web services when traversing the public Internet.

In addition, ESBs generally include content-based routing, which refers to routing based on XML elements or other application data rather than network addresses. This is also offered by runtime management and can be accelerated by the dedicated XML hardware and software within security gateways. Increasingly, AFE vendors are offering content-based routing, seeing it as a natural extension of load balancing.

Because SOA is such a major undertaking, early ESBs were used only by very large enterprises. They're now becoming commoditized thanks to open source options and their incorporation within other products. An ESB is already a standard offering from application platform vendors and is likely to become one within BPM suites. To address this, ESB vendors are moving higher up the stack to BPM, CEP, and RIAs.