OSB, lessons learned and best practices

if someone asked me: "tell me, quick, what is your message to posterity about OSB?",
I would probably say:

- from day 1, start automated deployment of your project to a development and integration server, automated tests with SOAPUI and continuous performance monitoring again with SOAPUI. Use customization files to do the property filtering for the target environment, this will force to identify from day 1 all the environment-dependent values. You should NEVER, EVER deploy something somewhere manually. NEVER. Was I clear? NEVER.


- learn XQuery, there is a lot you can do with XQuery without resorting to convoluted cascades of message processing actions (replace, rename, assign....). Remember, your message flow should stay ESSENTIAL, all the message processing should be hidden somewhere else

- learn about XmlObject and XmlCursor in Java Callout and custom Java XPaths, they can bring the entire power of countless Java libraries to your message processing needs.

- generate WSDL automatically, with Groovy or anything you like. They are a pain in the neck to be hacked manually. The same can be said about XQuery transformations. There is a debate on whether also Proxy Services could be generated automatically, and whether the ActionId is an obstacle or not...if you find yourself doing a lot of copying and pasting, this might be an option for you.

- publish WSDL and XSDs externally, to an Apache server or any form of Registry. If you feel that keeping your resources inside OSB is cool, feel twice.

- wrap BS with a Local Transport PS, abstraction is good when it comes with a low performance cost

- make sure your Application Specific Business Model doesn't creep into your "Canonical Data Model", that's one of the main reasons people use a ESB anyway. Anyway, domain modeling is not something that should be left solely to the developer, make sure the Business too is involved.

- EJBs proxies can be tempting - they map XML to Java for you - but they are expensive from a maintenance and performance perspective. If you need interfacing to the Java world, verify that you cannot replace them with a Java Callout.


Fabio adds these lessons:

- Enable Monitoring for BSP and PS with interval of 10-15 minutes

- Enable SLA Alerts for errors avg and max response times. Aggregation interval+15 minutes

- For every BSP, set a timeout

- Create 1 or more Workmanagers and associate the PS to it.

- enforce consistent Exception (fault) handling and logging across all services

- Auditing - trace the service, operation, response time, response code, originating username/system, ipaddress... logging this information with log4j (rotation time 1 minute) and having an independent process parse the files and store this information asynchronously to a DB . This proves to be a more efficient way of auditing than using the ReportingMDB. ReportingMDB should be used only for infrequent events like SLA violations.