I have been a developer for quite some time, with most of my coding experience in client/server applications.

When I first saw the concepts of ESB's I was excited. After all, I don't believe standards will ever unify communication enough to be able to soli rely on them. Companies tend to love finding an excuse to have to extend the standard in a propriatary way, this way they can claim to sell something nobody else can do, and gets you locked in once you start using their spiffy features. Ok enough of the tangant, so what I liked about this concept, is once you write an adaptor for the propriatary communication protocol, then you can have anything talk to it.

Now, reality seems to be setting in. These tools which are suppose to be making it easier, seem to actually make it harder. For example, it may make perfect sense to make it so all the grocery stores can talk back and forth; but what if you create a stock end point. How would you convert the stocks to something a grocery store could understand?

I threw WFC up there even though I knew WFC encompassed more than just what the ESB's do, because I know it also has the ability to set stuff up similar.

I was sitting, looking at random posts thinking about my last project at work (ya my life is really that exciting ) and I came to the conclusion that these concepts while interesting represent more of a design pattern than something that is really worth the time to use a generic solution which would require as much time to add the custom protocol code to, and configure; as to writing a new solution from scratch using things like xfire, wfc, jave mail api, etc, etc ... for thing existing protocols.

Anyways after that long monolog, if you had to write an application which needed to talk to only one protocol (you get to pick) on one side, and n different protocols (all custom) on the other side which technique would you choose to attack the problem with?

Salindor