Thanks for your input! What are your experiences from this kind of design? How well does it work in practice? Do you actually get enough practical benefits to off-weight the extra cost (added complexity of creating OSGi bundles) that you pay?
It surprises me how little content there exists for this question. jchurch wrote > I will be following this post with interest. The pattern we have more or > less adopted relies on Karaf features (Fabric profiles hopefully soon) to > deploy a set of related bundles. We OSGi-register a datasource for all > bundles. We separate bundles into Controller and Model to borrow > terminology from MVC. One kind of bundle receives Rest or ActiveMq > messages, and using Camel and beans, they transform and validate, making > calls on service interfaces which are Java or Scala. The second kind of > bundle defines the service interface, implements it, and implements data > access. This service bundle normally has no routing in it. In one case > we have a feature with sufficiently complex business rules so we have > justified a third kind of bundle (with routing) that executes business > logic. The idea is that the consumer interfaces might change over time or > additional consumer interfaces might be created, and the business logic is > sufficiently complex that we don't want to replicate it or move it around > more than necessary. Ours is a home-grown pattern - if there's better > ways of doing things, we want to know. -- View this message in context: http://servicemix.396122.n5.nabble.com/Advice-for-ServiceMix-bundle-design-tp5716937p5716983.html Sent from the ServiceMix - User mailing list archive at Nabble.com.
