Thanks for all the feedback - this is great stuff! I've put some comments inline below,
P On 8/18/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
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.
I agree that some of the inject stuff is great but the spring additions can make it more powerful, I'm interested as to whether we could look at the SCA inject process and compare it a little with pitchfork - though the idea of a spring context around somewhere to make stuff available is definiately a good basis for a number of things.
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.
I have been thinking so far that the POJO approach wouldn't use XBean however I have been wondering if convention over configuration should kick in - it if you have an xbean.xml then it will look simply process that - therefore you could override POJO's annotations in there and also do spring injection etc. However if the XBeanDeployer doesn't find an xbean.xml then it creates an Endpoint for each of the annotated POJO's it finds in the direct classpath. I have been wondering if the same could be applied to the JSR181 - if you don't have a xbean.xml then it can look for annotations? Also for a BPEL if there isn't an xbean.xml then we look for bpel processes? Its just a thought but could simplify the Service Units.
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).
Maybe we should look at cross engine annotations? I'm not sure about the SCA threading model but i have been starting to go through the tuscany project a little more closely so I'll have a dig around :)
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.
I wonder if the continuations approach that has been bounced around might be useful here? Or the SCA callback approach?
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).
I still need to get my head around beanflow use cases ;)
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 ...
I like the idea of a simple POJO orchestration engine and I like the idea that URI's might play into that integration!
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
