Q
Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Data services for ESBs

Larry Fulton discusses how it is inevitable that access to the many data related capabilities emerging in support of SOA be equally accessible via an ESB.

Some ESBs are adding MDM/data services capabilities (e.g. Sun, WSO2). Do you think that's something an ESB should be doing or is this functionality that's best handled outside a service bus?

ESBs are evolving to provide more and more of the glue and tooling needed to connect to and manage business services, whether the services in question are hosted by the ESB, hosted outside the ESB, a function of an "external" capability (like a business rules engine, BPEL, or complex even processing), or a composite service constructed using ESB flows, JBI, or SCA (or a combination).

It is both desirable and inevitable that access to the many data related capabilities emerging in support of SOA be equally accessible via an ESB. I would add that this should ideally be true whether the capability in question comes from the ESB vendor or someone else, which means that I'd like to see vendors continue to provide the means to extend ESB functionality to provide seamless integration for this kind of thing.

Vendors are increasingly supporting "hot pluggability" so you can add, upgrade, or remove capabilities as needed, and it would be great if these vendors would make that capability available to third parties, so other capabilities, like those supporting MDM and data services, could be hot pluggable, too.

The issues organizations will have to wrestle with will be these:

1) How to deal with organizational issues when one group owns the ESB capabilities and another group owns the data integration capabilities. In the long term, common ownership at some level will probably be necessary, because the artificial separation of these two areas is not likely to make things any easier.

2) How to deal with independent evolutionary paths of ESB and data facilities, both internally and in the products themselves. You will want to take advantage of developments that are useful to you, regardless of which vendor makes them available.

3) How to federate all of these capabilities. Most organizations have (or will have) multiple ESBs, from multiple vendors. This happens because of decisions made at the project, department, or division level, or because specific products will fill specific roles like B2B gateways, or because purchased applications will include an ESB as part of its integration and customization capabilities. Federation of ESBs is maturing, but not quite where it needs to be. When you add less standard capabilities, like those emerging in the MDM/data space, making these capabilities available across the enterprise's multiple ESBs will be its own challenge.

This was last published in June 2008

Dig Deeper on Service-oriented architecture (SOA)

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide.com

SearchWinDevelopment

DevOpsAgenda

Close