Next Up For SOA: Convergence And Consolidation - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Software // Enterprise Applications
11:30 AM
Andy Dornan
Andy Dornan

Next Up For SOA: Convergence And Consolidation

A look at the future direction of SOA intermediary products and related market categories, including Web 2.0, business process management, and application front ends.

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.

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.

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
1 of 3
Comment  | 
Print  | 
More Insights
InformationWeek Is Getting an Upgrade!

Find out more about our plans to improve the look, functionality, and performance of the InformationWeek site in the coming months.

Remote Work Tops SF, NYC for Most High-Paying Job Openings
Jessica Davis, Senior Editor, Enterprise Apps,  7/20/2021
Blockchain Gets Real Across Industries
Lisa Morgan, Freelance Writer,  7/22/2021
Seeking a Competitive Edge vs. Chasing Savings in the Cloud
Joao-Pierre S. Ruth, Senior Writer,  7/19/2021
White Papers
Register for InformationWeek Newsletters
Current Issue
Monitoring Critical Cloud Workloads Report
In this report, our experts will discuss how to advance your ability to monitor critical workloads as they move about the various cloud platforms in your company.
Flash Poll