camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: thoughts new naming convention & new annotation for producer / consumer in POJO mode
Date Wed, 13 Aug 2008 08:00:44 GMT
2008/8/13 Claus Ibsen <>:
> James Innovation Inc. Strikes again !!!

Bless you :)

> I love you example. Programming against interfaces and still having all the EIP, routing
and ESB stuff doing the work. That is truly hiding the middleware.


> Now if only the annotations was a standard ;) But then again we must wait XXX
years for anything innovative to happen and then James will be miles ahead. So we stay with
org.apache ;)

Yeah :) I've been through a phase of really wanting standard
annotations for everything; but given annotations are totally optional
things  - you can use your business logic whether the Camel or Spring
or Guice or whatever annotation classes are on the classpath - I don't
mind so much about annotations being kinda framework specific & having
their own exact (though often similar) semantics.

Am sure one of these days folks will figure out how to do a neat kinda
AOP thing; where folks can replace @MyThingy with @Transaction from
Spring and @Inject from Guice and @Produce from Camel or whatever.
i.e. so folks can use their own kinda metadata (reminds me of typedef
in the old c/c++ days where you wanted to alias things). e.g. in most
business applications you probably only have 2 or 3 kinds of method,
so why not add your own annotation denote the kinds rather than having
to add specific annotations for synchrony, transactions, concurrency
and whatnot.

> +1 to @deprecated the MessageDriven but sadly its also a good name for "classic developers"
that has been stuck in EJB land to long. MessageDriven is a MDB and interface they know. The
consume/produce names is new words for them. But hey the world is moving and you need to catch
up sometimes. So get Hopes book and start reading!

Yeah - am still not sure if we should keep @MessageDriven - as its
kinda like the JMS/MDB thing.

> I was wondering if @Consumer and @Producer are better names than @Consume, @Produce.
Just as a non English reader for the first time would have though they were named ending with
...r. Well that is what you read all the time in Hopes book - consume_r_ and produce_r_

The main reason I used the non-r ending word is to be more verb like
rather than noun - but mostly since Consumer and Producer are already
interfaces in org.apache.camel :) And I couldn't think of a better
name so far :)

> The last part about mixing with spring remoting Export/Proxy. Well my initial thought
is to separate it, but I think we need more time to experiment and see what feels most natural
and best. And we can consider Camel 1.5 the first shot and then we have community feedback
from early adapters and we have time to adjust it in Camel 2.0.

Good idea. I think we need to tinker with this a bit to see what feels right.

On the producer side; we mostly just need to differentiate between
sending a BeanInvocation as the message body - or just send the
arguments. But that could just be a flag on the @Produce annotation I

On the consumer side; I guess there's a difference between binding a
single method to an endpoint (like the @MessageDriven today) and doing
an @Export(uri="something", serviceInterface=MyListener.class) on a
class which exports all the methods on the MyListener interface.

So I guess the main differences are; where the endpoint definition
goes (class annotation or method annotation) and whether messages are
exposed by annotation versus picking an interface to expose - then
finally whether the payload is just the parameters; or the
BeanInvocation etc.

I suppose we just need more folks tinkering with this stuff to see
what works best for most common use cases.

> I think its important that the annotations approach cater for both simple usages and
the more advanced. The sample now is simple and possible to explain and introduce to a bunch
of "classic developers".
> Beware this is written without my first cup of coffee really kicking in!!!



Open Source Integration

View raw message