Service buses are intended to be a layer between all the different applications in a large organization; such as billing, customer service managements, salesforce, etc etc so that it is the one layer of integration between all these and reduces the tight couples of client interfaces to each of the applications. The arguments for the service bus are many; that it reduces coupling, it hides the location of the client applications behind the service bus, it hides the many to many relationship of client applications and transformation of

Pros

1. Service Aggregration
2. Service Mediation
3. Service Transparency

Service aggregation means that data from multiple endpoint can be condensed together in the service bus and through XSLT combined together to present as one XSD or DTO to the outside world. For instance you may pull in product catalog information from a billing system and salesforce to combine together before presenting that information to your customers as one XSD or DTO.

Service mediation means that business logic can be performed on a service as it comes into the service bus and before it is presented to the outside world. For instance something coming from the billing system can be checked in the service bus to make sure the data is what it says it is; such as a credit card number and validated as such before the service bus lets it out of the system.

Service transparency means that the services can be anywhere in the system and the outside world, or client, that is asking the service bus for information doesn't need to know where they are, they only need to know where the service bus is. Of course, the client needs to be configured to hit the service bus as an endpoint, but this is less hassle than configuring for multiple endpoints when doing aggregation.

Cons

1. XML and XSLT based
2. No unit testing tool
3. No continuous integration compatibility
4. Poor tools to develop with
5. You can do it in java code anyway

One of the big problems, in particular with the Oracle Service Bus, is that it is XML and XSLT based. Readability is horrible in the different stages and transformations. Trying to work out what the $body is certain situations is a nightmare. Even with dumping logging all over the place trying to work out what is going on is difficult. It is far easier to manipulate data in a language and environment like java or any other code form than XML.

The service bus does not have unit testing tools. These days you cannot guarantee quality and avoid regressions without unit testing. Consequently the service bus becomes a service liability in the software system. Since the service bus is often the final endpoint between the wider software application system and the outside world it is doubly important that quality be high, and without unit testing it will be up to QA engineers toiling over end to end testing with each change.

The service bus cannot be integrated into continuous integration. My experience is with the Oracle Service Bus and one of our engineers toiled with trying to create an sbconfig.jar from a check out and then deploy it to our different environments. We ran out of time in recreating the idiosyncratic Oracle form of jar that the service bus needed and there was no out of the box tool to create it. The only way we could build the sbconfig.jar was to export it from eclipse. Which is horrible. It is not in the least way reproducible like that in continuous integration.

Eclipse is at the time of writing on 3.6 Helios which is far beyond the eclipse that BEA/Oracle give out for their Workshop for Weblogic. When doing java in that old environment it is less pleasant than in Helios. Worse, Workshop for weblogic is not available for OSX. We ended up doing OSB development in 3.3 Europa and Java development in 3.6 Helios. Plug in development has stalled and is not being updated. The tools that come with Workshop for weblogic are poor anyway. They are difficult to work with, they crash often, they don't give you much idea of what is going on. It is an unproductive and unpleasant experience.

Summary

While the idea of a central service bus to aggregate all the services together and offer one endpoint to the outside world is a good theoretical idea, the implementation of the service buses themselves is poor. They usually sit on top of EJB systems which have all the advantages of support for JUnit, support for continuous integration, support for kick ass IDEs like eclipse, support for aggregation via remote interfaces and other EARs.

Our experience with the OSB was a poor one. We mainly use it as a pass-through other than a couple of projects which were coded up when the push to use the OSB more heavily was on. Those projects no-one likes working on as the tools are poor, it is difficult to work out what is going on, there is no strong typing, no unit tests so you never know what you are breaking by changing things. It is an all round bad experience.

I would not recommend people use a service bus. Java developers are easier to come across and their skills are more translatable. People experienced in Service Buses and XML/XSLT are rarer and if they are leave are likely to leave behind projects that no-one wants to touch, update or bug fix. The tools are terrible and the Service Bus itself does not fit into a form that can guarantee quality.