In continuation of this jot the service bus being XML based is a bad idea for multiple reasons. It should be in Java. The Oracle Service Bus sits atop a J2EE server; so do the routing, assignments, pipelines and service calls in Java. The engineers that will be working on the orchestration and aggregation through the service bus will be middleware engineers anyway, so developing and loading a jar into weblogic to the service bus functions is not a big deal. It is a skill that exists on the team already so there is no ramp up time for the developers to get used to the XML based services, proxies, wsdls, schemas, xpath, xquery etc.

The second reason is that the service bus is very difficult to debug and refactor. There are numerous tools to debug and refactor Java classes, and eclipse is rife with them. To debug a service bus proxy you cannot track the message flow directly at each point of the pipeline, assign, replace, etc. You pump it in, debug at the webservice level and then look at the XML output. If it was java based existing tools would enable the orchestration and aggregation be debugged directly at each step.

Thirdly a lot of the XML tools were fashionable ten years ago when these technologies were created. Which is great. XML has a place and is very useful in several problem domains. The service bus is not one of them. Most project teams are resource deficient anyway, and having developers that can navigate the path from back-end, to middleware and front-end are rare as it is. Throwing another difficult to debug impediment that uses non standard tools (XPath instead of Regex) is a massive drain on feature output, and hence project schedule.

I would like ten cents for every time I have made a change in a WSDL and then had to regenerate the Proxy, the XSD and then go in and fix the bindings by hand. It is frustrating and the namespaces are a pain to keep in order at the XSD and WSDL level. Working with the OSB is a frustrating experience, especially when you have the java middleware and backend debugged, tested with junit and soapUI only to see the OSB dump null and 0 variables on your service.

I think the service buses should be done in Java and kept within the same skillset domain as the J2EE backend. This isn't an old dog not wanting to learn new tricks, rather a grizzled developer with tight project schedules seeing a weak point in the technology stack that is difficult to dampen and a source of blockers, bugs, and wtfs.

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.