Wednesday, June 3, 2009

JavaOne 2009: Lessons Learned in ESB

Andreas Egloff and Frank Kleviet: ESB Lessons Learned
Both speakers work now at Sun in the OpenESB project and come from a big vendor that sold EE products.

  • ESB as a product comes with risks like, for instance, architecture concerns (good or bad for SOA?), more middleware, over-reliance on one provider

  • Light weight non functional requirements: enterprise scale integration, change happens (decouple configuration), long term commitments (today's hot stuff is tomorrow's legacy)

  • Accomodate large teams: enterprises like to scale by adding people and this makes things harder: easy-to-learn is critical, provide tooling (automated testing & integration) and keep the solution simple

  • Tooling is great, but don't let it get in the way!

  • In their words: "Consultants tend to think that copying and pasting code make them more productive. And this is not true.!: Prefer convetion and configuration over coding! Support Patterns as first class citizens!

  • Frameworks are poweful to reduce code duplication, but sometimes constrain flexibility: Interceptors are a powerful way to add flexibility

  • Developers spend a lot of time waiting. It is necessary to shorten the change-build-deploy-test cycle, by reducing build time, deploy time with smapper deployables or in-place editing; increase testability and debuggability with built-in tests and support automation

  • Modulartiy improves startuptime and performance by only loading what's necessary when it's needed. Modularity can help control complexity.

  • Reduce the artifacts per solution or make managing large numbers of artifats possible.

  • Connectivity Configuration: configuration belongs to run-time and not design or development time; deployables are used in different environments

  • Message-based services more robust in face of change so avoid rebuilding the world for small business logic changes: use scripting languages, externalize business logic (e.g. CBR), consider evolution, versions in handling messages, externalize cross-cutting concerns (e.g. Aspects)

  • Patch Management! OSBi allows to declare a dependency on a specific version of a component, and this way it is not necessary to test the whole enterprise application because you need to upgrade one library

  • JMS if often a bottleneck - component-component message-passing can also be done without JMS; in-memory message exchange allows performance improvement. Just use JMS if it is really necessary

  • JMS has a proprietary wire protocol, requires yet more infrastructure; HTTP provides proven scalability and interoperability;

  • Avoid depending on one vendor only so stick with open standards, open-source: portability of skills of developers

No comments: