Right now we can mark a method as @MessageDriven in the bean integration...
http://activemq.apache.org/camel/bean-integration.html
public class Foo {
@MessageDriven(uri="activemq:cheese")
public void onCheese(String name) {
...
}
}
we can also mark methods has having a message exchange pattern (i.e.
to mark methods as being InOnly - for one ways as apposed to
request/reply).
http://cwiki.apache.org/CAMEL/using-exchange-pattern-annotations.html
so having the produce side would make sense to avoid coupling the POJO
to camel interfaces to help hide all the middleware APIs....
http://activemq.apache.org/camel/hiding-middleware.html
There's a JIRA for this...
https://issues.apache.org/activemq/browse/CAMEL-816
I've just checked in a first spike at a first implementation of this...
http://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-spring/src/test/java/org/apache/camel/spring/produce/
There's the producer interface, MyListener, an implementation and a
test case that has the producer injected using @Produce which also
binds it to an endpoint - then the implementation of the interface
binds it to an endpoint.
Under the covers this is using the same infrastructure as the spring
remoting really.
So after this long ramble am wondering...
* should we rename @MessageDriven to @Consume (keeping it around until
2.0 and deprecating @MessageDriven for now)?
* is @Produce a good name of an annotation; in some ways is more like
@Proxy - as it can do both a one-way send or a request/reply?
* if we supported @Consume on a class level rather than just a method
level like @MessageDriven; should we call it @Export (like the spring
remoting proxy and export sides) rather than Produce and Consume
* so maybe we should separate the remoting stuff from the send message
/ consume message stuff? So support @Proxy / @Export for spring
remoting style stuff; and a separate method level @Produce (where the
payload is just the parameter value(s)) and @Consume on a method
level? i.e. in spring remoting the payload is a BeanInvocation bean
which contains the the arguments and the MethodBean (details of the
type, the parameter types and method name etc). Sometimes we just
wanna send - say a JMS TextMessage so we might wanna miss that stuff
out and just send the single parameter value of a method as the
payload
There's a number of ways of slicing and dicing this - just thought I'd
start a little bit of brainstorming
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://open.iona.com
