In researching EnterpriseServiceBus, the thought comes to mind "Great, but why just for the large enterprise?"  Wouldn't it be great if we could employ a similar light-weight arhitecture to integrate software components on a LAN or even on a stand-alone system.  For instance, let's say I want to create a custom business application, but use the contact management features of GoldMine and the accounting features of QuickBooks, yet not couple tightly with either of these products.  GoldMine exposes database files, and QuickBooks exposes an API via COM or XML, so one could feasibly write simple adapters to integrate them with a simple messaging bus.

Of course, some significant challenges do appear.  For instance, if coupling is loose, then how does our application format an address block for printing on an invoice based on multiple fields in GoldMine?  I'm supposing the answer is a message translator component on the bus, so the message translator responds to the request for an address block by making the appropriate requests from GoldMine.  If the GoldMine component were ever replaced, the adapter would also need to be rewritten, but we would know that the only place we have to make changes is in that translator component.

I'm curious if anyone here has successfully implemented a ComponentBus application along the lines of the example above, or has any other examples of ComponentBus implementations. ''Any information from the community to share on the question asked?''

----
Isn't the PipesAndFilters of the UnixShell a classic example of a ComponentBus?

''PipesAndFilters fail to meet requirement three of a ComponentBus, "Components need be dynamically added to and removed from the system at runtime." Shell pipelines are fixed in layout once they're created; you can't slap another process into the middle of a pipeline after the fact, for instance.''

Indeed, PipesAndFilters are, by design, more of a point-to-point topology than a bus.  Much better examples of a component bus include:
* AmigaOs's "input.device" input event processing.
* COM and CORBA technologies.
* QNX Photon microGUI event handling.

----
Once upon a time Lotus had a product for Java called InfoBus. It was almost exactly what you are describing above. I don't know what ever became of it. It seemed like an idea before its time (back in about '96-'97).

Your description also brings to mind Jini - a Java product and API from Sun.

The Java Telnet Application also has an event bus within it that could be considered similar (as does JEdit, I believe). 

The main issue with all of the above is that there needs to be some sort of agreement on the format of the messages being sent. Other than that everything else about the systems could be very abstract.
''If we're talking about writing adapters, the adapters are what agree on the message format, and those interact with the individual applications on their own terms.''

-- PeterSumskas.

----
There is one ComponentBus based framework being developed for web applications. It presents every characteristic mentioned here, only server-side. It will probably be opensourced once finished, it's about 1 month from completion (and not avaiable until then).

----
See also ComponentBus, EnterpriseServiceBus