After reading this article on composite db software here

it seems to me that the composite db software is not exactly a databse store like Oracle which physically stores the data. It is more like a adapter that connects to different sources in the back end and provides a single point of data access to the client. is this correct?

If the above is correct, then how is it different from an ESB which can act as a single point for the clients to access data? ESB can fetch data from a variety of cources and present ot the client and client dont have to know here or how the data is stored.


Consider data virtualization solutions like Composite to be one level below the ESB in an enterprise architecture. A virtual view in Composite can bridge n data sources transparently to the code in any given service. So while you COULD implement all that multi-source joining at the ESB level, it would be much more complex, probably slower, and ultimately tightly couple your services to your data stores. DV provides an abstraction layer so that you properly separate concerns in your architecture and allow your ESB to encapsulate business logic without getting into the dirty details of data storage locations.

  • Thanks. I understand your explanation. But why would it be slower to use ESB?
    – Victor
    Oct 18 '13 at 20:35
  • The DV tools actually implement query optimizers. They collect information (statistics) about the data sources that allows them to make interesting decisions about where to do joins and such. So they can intelligently determine when to 'push' joins down to the source DBMS or to do the join itself. They can also cache the data returned by the views where appropriate. Oct 18 '13 at 20:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.