[servicemix-dev] Components and Service Units

[Philip Dodds]

There has been some discussion around the current components and POJO client classes and how they would work in a standard JBI deployment.   The current components implement the JBI interfaces of Component and LifeCycle, and their configuration is driven through the Spring JBI wrapper, such that the class is created by Spring and configured through getters/setters.   Dynamic destinations are covered in this approach using Spring, this makes configuring the JBI components much easier, and provides an excellent IoC architecture for JBI allowing for re-use of components and easy extensibility.   However, it is unclear from the spec whether a component should implement a ServiceUnitManager which is actually performing the work, and while this may be purposefully vague we should balance the arguments for making our components function in the Component Lifecycle (start/stop etc) or at the Service Unit Manager (start/stop).  The SUM approach provides the ability to leverage the connections metadata in the jbi.xml and also provides the artifact-zip which might be important to components like transformation engines.   Here are some of the point that have been brought up so far:   Currently the Spring infrastructure creates and configured a class for the JBI component/lifecycle, in a standard JBI deployment the container would create the component class, how would we configure the instance?  There is a BootStrap for the component, however I haven’t been able to see how you can get a class over to the component, in fact the Bootstrap and Component appear not to share a context, unless implemented through a singleton or maybe thread local? Under the spec and within ServiceMix we have the concept of an install directory,  this would contain components which in turn contain their libraries,  under this model you might assume that you can deploy components (code) and then reference them in Service Assemblies in the deploy directory?  This might get around the class path problems we have had on Win2k? If we are able to constructor installable JBI components for the ServiceMix BC’s then we would be able to move them out of the base project.  In fact whatever we do we should look at how we can separate the components from the container implementation? If you use Spring to configure the destinations to allow you to bind components together using the spring descriptor, how does this map to the connections/connection that exists in the JBI spec?  I checked in an example dummy component and assembly to show this type of connecting in src/test/assemblies and src/test/components Would it be possible to allow someone to work in Spring mode and then generate a JBI deployment?  Does this mean that the spring configuration would be mapping into the component installation descriptor (available in the Bootstrap) or as a artifact which is available in the service assembly?   I suppose I have been imagining a deployment architecture whereby components could be deployed and made available, and I suppose would exist a bit like a factory with instances of the component being created and managed by the SUM?  This would allow for code deployment and then descriptor/artifact deployments making use of them.  However, is it really important to have this model for Binding Components (which is most of the components in ServiceMix currently) or is it OK having each one as a separate component?   Anyway I just wanted to start the discussion moving since I think this affect the user community, having a roadmap from quickly getting going on ServiceMix through the servicemix.xml and Spring infrastructure and being able to migrate up to a standard JBI deployment unit.   Cheers   P