2008/8/13 Claus Ibsen <[EMAIL PROTECTED]>: > 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. Thanks! > Now if only the annotations was a javax.xxx 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 guess. 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!!! :) -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://open.iona.com
