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:
Post a Comment