Sounds a good start. Just wondering about how to handle InOut exchanges, and beans that act as consumers ...
On 10/8/06, James Strachan <[EMAIL PROTECTED]> wrote:
OK here's a quick overview of servicemix-bean so far. The idea wasn't to reproduce what servicemix-jsr181 does, doing the whole jax-ws / jsr 181 thing - but instead just a simple way of users plugging in POJOs to process specific message exchanges in the same kinda way you might use a POJO to process a JMS message. Its slightly tricky as there are so many different use cases - but my general thinking was if you were writing business logic, you'd go the jax-ws route using a business interface and end up using the servicemix-jsr181 route. However if you just want to do some lower level integration - processing messages from a CSV / file system / message queue, you might just want to write a simple POJO to process the messages / XML directly. So servicemix-bean was born initially as an experiment to see what was possible. To start with here's a few example POJOs which are used in the tests to process different message exchanges.... http://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-bean/src/test/java/org/apache/servicemix/bean/beans/ I was kinda thinking there were 3 main kinds of POJOs to support * ones that implement some kind of typesafe JBI / ServiceMix API. So far I've done ExchangeProcessor and MessageExchangeListener (am wondering if we need both BTW) * uses simple reflection using methods with parameters which map nicely, by type, to JBI - e.g. methods taking a MessageExchange, NormalizedMessage, Source etc as arguments * annotations used to mark the methods to expose on the bean and how those methods map to operations, MEPs etc I generally figured, the bean should be configured by spring/xbean for its dependency injection; then the servicemix-bean just focusses on how to bind the message exchange to the POJO. Its still pretty simplistic so far - the annotation-to-method mapping is not done yet, still work in progress. Incidentally I added a dynamic URI resolver using bean:foo where foo == the name in Spring to use for the bean. So you can create a single <bean:component/> element then just send messages to an endpoint called bean:foo and it'll spin up an endpoint taking the bean from the ApplicationContext that the component is spun up in and using it to resolve the bean name. Have added elementary URI query support so you could customize the bean further using a URI query bean:foo?timeout=1234 Though bad things would work if the beans are not singletons :) I experimented with some annotations on method parameters to help bind them to the message exchange - so @Property, @XPath can be used (see the example POJOs above for simpler examples). I'm sure we can come up with some other kinds of mappings from JBI to POJOs Thoughts? -- James ------- http://radio.weblogs.com/0112098/
-- Cheers, Guillaume Nodet
