ESBs Finding Their Place in the Mix

Some recent Iona Technologies announcements point up the growing practice of multiple ESBs within enterprises, often associated in a federated manner, and sometimes using ESBs tasked with specific types of integration duties.

Iona is taking a “hybrid” approach to ESB offerings, with a coordinated open source and commercial strategy. [Disclosure: Iona has been a sponsor of BriefingsDirect podcasts.] Iona Technical Director Jim Strachan addresses some of the open source issues here. Iona has also upgraded its Artix ESB, and has partnered to bring a management dashboard benefit to the mix.

Innovative Implementation

These moves reflect how enterprises and service providers are using ESBs in innovative ways, in effect creating distributed ESBs to support SOA, SaaS and guerrilla SOA — while building a path to holistic SOA that follows a crawl, walk, run ramp-up.

Indeed, some new use traits are emerging on how ESBs are actually being used in the market. One is that multiple ESBs are often used, or come into play, rather than one honking ESB swallowing everything up. Sometimes such varied ESB use comes from different SOA projects that evolved using different means to access and integrate resources. Sometimes it’s from separate organizations or departments that merged or became partners. SaaS also encourages ESBs at the edge and internally, so there’s likely a mix there too.

I’m also seeing instances of ESBs that are tuned or dedicated to specific types of integration, or integration that is “pointed,” if you will, in a specific direction. By that I mean integration for data services, unstructured content, or integration for management feeds, or integration from outside partners of supply chains.

Flexible Integration

An ESB for various flavors of integration makes a ton of sense to me. Deciding later whether to consolidate ESBs, while learning what works best on a more granular level, follows how IT often evolves. It certainly aligns with open source infrastructure use adoption patterns.

Given these scenarios, rather than force an architect to pick or choose one ESB and make it dominant, we just as often now see federation of several ESBs. Due to their nature, this makes sense — many integration points. So hybrid ESB use makes sense and is reflective of what’s going on in actual use. Another aspect is that ESBs are not just federated on equal footing. An ESB can be used in master and slave configurations, where various architectural topologies are likely given the many possible ways that these SOAs emerge. Old and new can play well based on many types of integration means. Think of it as distributed integration.

In this environment, Iona is offering a logical hybrid solution set. On one hand, Fuse allows for the benefits of open source and community development to make ESBs inclusive and standards-based. The community provides a great way for many connectors and modules to well-up to bring even more assets and resources into play with the ESB. This makes it far easier for esoteric applications and content to play in an SOA, and those connectors are made openly available.

More Participants, More Value

In this open source role for an ESB, Metcalfe’s Law (value of network grows with number of participants on it) applies too. The value of the ESB increases with the number and diversity of assets and resources that can attach to it. FUSE aims to exploit this, as well as provide a low-cost and simpler way for developers to enter into ESB use.

On the other hand, in legacy-rich and CORBA (common object request broker architecture) environments, the Iona Artix offering binds and integrates core and more traditional messaging and ORB-based assets and resources. So you have a backward-facing and legacy-compatible ESB offering, one that scales to large transactional demands in Artix. And you have the new kids on the block, Web services and SOA greenfield services that can be accessed and organized via Fuse and the Apache community.

Putting Fuse and Artix 5.1 into a federated yet managed configuration then offers the best of many worlds, and gives organizations variety of choices on how to enter and manage the expansion of SOAs, based on their specific situations. And this also mitigates future risk by making unknown scenarios — including more SaaS use — easier to meld into the architecture.

Iona’s partnering with Hyperic for Fuse HQ broadens the management into mature consoles-based delivery, while also expanding the scope of what is managed. So that makes sense. All in all, an approach to the market that makes market adoption and inclusion more in tune with guerrilla SOA than master plan SOA based on one vendor or one product set.

Protecting Identity

In other SOA news — again with an open source angle — WSO2 announced an open source approach to help users pass consistent identity data across networks, while protecting them from such things as phishing and other identity attacks in Web applications.

Web services middleware provider WSO2, based in Colombo, Sri Lanka and Mountain View, Calif., recognizes that as SOA becomes more prevalent and more complex — linking data, applications and service both inside and outside the enterprise — that security and authentication become prime concerns. [Disclosure: WSO2 has been a sponsor of BriefingsDirect podcasts.]

The WSO2 Identity Solution (IS) is based on Microsoft’s CardSpace technology, which is built on the open standards Security Assertion Markup Language (SAML) and WS-Trust. WSO2 IS will operate with CardSpace components from multiple vendors.

It also works with current enterprise identity directories, such as those based on the Lightweight Directory Access Protocol (LDAP) and Microsoft Active Directory.

Two Parts

WSO2 IS has two primary components: Identity Provider and Relying Party Component Set. Identity Provider allows users to issue “cards,” both managed information cards and self-issued cards that allow users to log into any Web application that supports CardSpace. Web sites that rely on this authentication don’t need to store any passwords or other personal details.

Key features of Identity Provider include:

• User store support for the most common directories that offer standard LDAP or Java Database Connectivity interfaces. It also includes a built-in user store for smaller companies.
• Claim support for standard and custom claims, so users can keep full control over what personal information is shared.
• Statistics, reporting, and an audit trail, which let administrators monitor user accounts and issuances of information cards.
• Revoking mechanism, which allows administrators to revoke user cards and block them from being used for authentication.

The Relying Party Component, built around the Apache HTTPD module (mod_cspace), plugs into the most common Web site servers to add support for CardSpace authentication requests. The module is independent of any server-side Web framework, and it can set up CardSpace authentication with any Web framework running on Apache 2, including PHP, Python, and Perl applications.

Key features of the Relying Party Component include:

• Access control for static content in Apache HTTPD
• An integration interface for developers
• Support for leading content management frameworks, such as Drupal and MediaWiki
• A Java servlet filter to provide an integration point for J2EE-based Web applications.

WSO2 also recently upgraded its open source ESB.