camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james.strac...@gmail.com>
Subject thoughts new naming convention & new annotation for producer / consumer in POJO mode
Date Tue, 12 Aug 2008 17:34:50 GMT
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

Mime
View raw message