This is a great idea ! While the jsr181 component is really helpfull to hide all jbi / xml stuff, the only other solution is to use the lwcontainer or to create a new component from scratch. So i'm all in favor for a new pojo component more related to jbi.
A few thoughts ... 1) Annotation drive injection is imho a great tool, but i'm not sure it will give all the features that spring brings like transaction proxies, jndi lookups, etc... Well, i guess it could, but it may be a lot of work. I was thinking about using annotations on the jsr181 component to support EJB via pitchfork. 2) Classpath problem. As the SU will contain java code, you have to be able to create a classloader for this SU. Xbean already does this, but we can find other ways. We could state that the /classes and /lib directories inside a SU would be used to create a classloader. This could also be done for all xbean based components and would avoid the need to write / generate the <classpath /> tag. 3) Threading model. On the jsr181 component, the threading model is the servlet model: a single thread-safe instance if used to process all requests. However, using spring aop features, you can easily configure pooling or thread based pojos. Should we define a new annotation set for that ? We could also take a look at how SCA defines that: you can define the scope of a bean (per request, session, application, if i recall). 4) JBI related features. While the jsr181 component can only handle synchronous request / response calls, we should aim to provide a clean support for asynchonous request / response patterns. A consumer should be able to send an InOut exchange asynchronously and a way to provide a callback which would be called when the answer is received. 5) Support for beanflow. I think this component would be a better candidate than the jsr181 one to provide built-in support for beanflow. This could be very usefull on top of #4 (async messages). 6) Use of the client api (or a simplified version), support for URIs ... James had worked some time ago on a cleaner client api, but setepped back to keep compatibility. The javadocs is still online :( See http://incubator.apache.org/servicemix/maven/servicemix-core/apidocs/org/apache/servicemix/client/Client.html and http://incubator.apache.org/servicemix/maven/servicemix-core/apidocs/org/apache/servicemix/client/Destination.html I think by providing built-in support for beanflow in this component, we could easily implement a pojo based orchestration engine. When an exchange is received by the component, it create a pojo and start the flow. This flow will first receive the exchange, could send an async request / response, each response would call a given method on the pojo, etc ... Sorry for this long email ;) On 8/18/06, Philip Dodds <[EMAIL PROTECTED]> wrote:
I have knocked up some thoughts on a JBI POJO engine that could be used to provide a mechanism for annotating POJO specifically for more messaging level operations that the JSR181 service engine is aimed for. The idea is to provide a simple framework to replace the Spring Client Toolkit that is now defunt. Have a look at the idea - http://goopen.org/confluence/display/SM/JBI+Pojo+Service+Engine And all comments/thoughts are welcome!! P
-- Cheers, Guillaume Nodet
