How Do You Want Your Middleware – Hard or Soft?

As organizations buy and build ever more heavily into services oriented architectures (SOA), the notion and utility of enterprise services buses (ESBs) becomes more mainstream. Basically, the ability to provide a unified set of managed integration, transformation, and transaction services within a distributed environment becomes paramount in obtaining much of the cost savings and adaptability promised by SOA. By its nature, SOA is about development, specifically the ability to develop services or componentized programs/methods that can be reused to avoid redundant propagation and – given the proliferation of web services standards – that can speak to each other through various standardized protocols. However, lost in this burgeoning world of services are additional integration benefits. Despite open standards pervading the integration market, if an organization must still address integration issues differently for every domain of services it manages, then it hasn’t taken as much advantage of the technology as it could.

To address this shortcoming, as well as to help organizations unify their approach to integration, the notion of an ESB was united with XML-based web services standards over the past few years to describe a more holistic integration capability set. Essentially, an ESB offers core services as well as a more diverse set of “options” to provide for any integration need regardless of platform, communications requirements, etc. By centralizing integration facilities on an ESB, an organization can both reign in rogue costs (and rogue middleware) while implementing a capability with flexibility for future changes or additions.

Of course, the ESB angle is being approached by a wide variety of vendors. From application server vendors adding function (e.g., BEA, JBoss), to integration vendors evolving (e.g., Tibco, webMethods, IBM), to platform vendors branching beyond their applications (e.g., SAP, Oracle), this is becoming a crowded and fragmented market. However, there is another sect that seeks to differentiate through focus, performance and ease of implementation/maintenance. These are the integration appliance vendors, and while they are not ESB vendors per se, they offer numerous ESB-oriented capabilities. Also known as application routers (or XML accelerators, XML security appliances, etc.), they also form a somewhat fragmented lot (having come from XML performance enhancing appliances, security, networking, etc.), they are positioned to fill a need: provide a quick and easy way to deliver many of the advantages of an ESB in a high performance manner without locking the customer into a major software purchase and ensuing implementation.

Intel and IBM have apparently recognized the opportunity given their recent purchases of Sarvega and DataPower, respectively; Cisco and F5 also have products in the space; but largely, the market is comprised of small, privately held companies (see Figure 1). Their products and marketing messages attempt to address the “middleware sprawl” issues affecting most large organizations, not to mention the traditionally high cost of integration software (both in terms of licensing and deployment).

Essentially, the benefits of integration appliances are as follows:

• A “configure, not code” approach to middleware; graphically configure firmware to link to various databases, applications, and transport/transformation services;
• Deployed by plugging them in vs. code, test, integrate, etc. Basically, all the virtues that blade servers possess;
• Scale and provide redundant capabilities simply by adding another box;
• No software licenses for users to contend with; and
• Firmware upgrades vs. new installations (beneficial in XML security situations, for example, when new issues can crop up frequently).

Many of these benefits could also lead the appliance vendors to provide hosted integration services, potentially a “hub in a box” not unlike a PBX for voice. This could be beneficial in numerous B2B situations, particularly when integrating with channel partners via EDI, FTP, or other traditional data movement options. Of course, buyers would have to be willing to have their data hopping around the Internet, but they often do this already. Perhaps the reconfigured VANs (now integration companies themselves) such as Sterling Commerce and GXS would be interested in this technology.

But why would IBM be interested in an approach that risks commoditizing the WebSphere integration lineup? DataPower’s niche has been more in security and XML than in application connectivity per se, and it had prior partnership agreements with various parts of IBM related to these. Moreover, DataPower can reach customers that might not otherwise have been willing to commit to a WebSphere strategy (i.e., those that have deployed non-IBM application servers/integration stacks). Additionally, IBM has a tremendous interest in the SMB market, and the ability to deliver pluggable, easy to afford and manageable integration capabilities that will be in-line with IBM’s SOA strategies to that market was probably quite attractive. Similarly, we believe that the others on the above list can fill similar gaps in and around the integration, performance, security and greater application connectivity spaces. Indeed, numerous other data integration, transformation, and movement capabilities related both to traditional structured as well as unstructured data types could easily find their way to these devices.

Additionally, these developments – as much as the types of vendors taking part in them – denote the burgeoning change in what we’ll call the application infrastructure. Through the advent of web services and SOA implementations, not to mention the desire to diversify, application vendors like SAP, networking vendors like Cisco and others are simultaneously weaving infrastructure components more seamlessly to applications while also enabling key data and functions to be physically located where they can berun and be managed most expediently. This work will deliver several positive results for end users, including decreasing integration costs, adding flexibility to their infrastructure and applications, enabling partners to integrate or “onboard” more quickly and seamlessly, and generally enhancing their ability to adapt to changes in standards, providers, business conditions, etc.