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-tp5716937p5716975.html Sent from the ServiceMix - User mailing list archive at Nabble.com.
