Oracle Service Bus - the good, the bad and the ugly

Having worked for a while with the Oracle Service Bus 11g, I have found some things I like and some things I don't like. The main advantage of the OSB is probably it's integration with the Oracle SOA stack. We however only used the OSB as an ESB, and this is what I have commented on.
The good regarding low entry barrier due to the GUI based development I found ofsett by the need to spend considerable effort in setting up the build process.

I have used the service bus mainly for 3 usecases:
- Encapsulationg and exposing web services
- Simple file integrations moving files from one location to another
- Complex processing of file content including splitting, tranformations and rule based actions and service callouts.

The good:

• Relativly good xquery editor. For simple transformations the drag and drop GUI helps getting started, though usually you end up having to do some hand coding as well. The best about the tool is the capability of quickly testing the transformation providing the input parameters.
• Good with SOAP based integrations. I consider this the streangth of the OSB. Following the VETRO pattern, as long as the flow is not too complex, transforming messages and exposing services is fast.
• GUI based development allow low entry barrier and makes it easy to get started.

The bad:

• POX/REST services support is counter intuitive and complex. It is clear that the OSB is centered around SOAP and JMS, though POX services is supported.
• Xquery implementation lacks support for modules. This makes DRY principle harder and you either end up with more complicated workarounds or solutions, or you end up with copy paste.
• Lack of property handling/property stores.
• Customization files. Inflexible, verbous and complex to maintain. Not everything can be customized with the customization files, some like passwords are reasonable, but things like polling interval for file integration would be nice to be able to change between environments. Due to the complexity of the customization xml file, we ended up created a script to generate the customization files as managing files by hand became a nightmare. My biggest gripe is again how DRY was broken and you have to duplicate property values (same FTP server for various endpoints etc.). The other problem was the complexity and fragility, even valid XML containing new line broke the script (do not autoformat the XML!).
• Too much relience on GUI without any good plugin capability. Only option for doing anything with real code is through Java collaouts or implementing and publishing external services. Moving outside the standard tasks, thigns quickly get a bit messy and more complicated than it should. Old programmers are likely to miss the flexibility and power of a proper programing language.
• File integrations limited and not always very robust. File polling operations only support moving files, any integration where we had to periodically read a file without having it removed had to be performed by java callout accessing the file store. Errors on accessing file stores are not possible to capture and for frequent polling the log gets filled with crap.
• Difficult to adhere to DRY principle. The GUI based development is good for reducing entry barrier, and for simple flows gives a good overview. However complex flows gets confusing and difficult to follow andmakes re-use difficult. Many elements such as callout blocks, error handling, routing etc. tend to be copy-paste with minor modifications.
• Branch and merge difficulty. Since allmost all the code of the OSB is XML based configurations, merging different versions of the same file can be tricky if there are conflicts. It is therefore helpfull to try to avoid multiple developers changing the same file and branching should be discouraged whenever possible.

The ugly:

• Building projects. Overly complex and slow to automate and include in continous integration. To build OSB projects from code repository, you have to use eclipse headless. Apart from being non-trivial to set up, it is slow. Just building and deploying from our Jenkins server takes about 20 minutes. Out idea was to have build and deploy continous (as in continous integration), based on SVN checkins, but had to abandon the idea as the build process was simply to slow.

• SVN integration issues, builds from eclipse not trusted for external modifications. Though this does not happen very often, the fact that changes to a file (e.g. proxy service) retrieved from SVN is exported to the OSB without the changes is problematic. Time spendt trying to fix a problem when the file you are looking at is not the same as what is exportet is frustrating!

Some advices:

• Use well named stages to group the flow work. For example following the VETO pattern, have each element in a seperate stage. This makes reading the process easier and allows finer granularity on error handling. 
• For file based integrations, if there is any risk of illegal XML (non-escaped special characters such as '<' ), don't mark the proxy service as XML service. The xml parser will fail before you have any means of catching the exception and recovering the file may be difficult. Use instead text based messaging service and parse the xml file inline (you can use fn-bea:inlinedXML) in the message flow. This way you can handle the parsing exception.