I think saying that sping/hibernate/tomcat disproved EJB is nearer the mark. I think spring/hibernate sold themselves on their intuitive API's.
As for JMS, yes things can change, but personally, if I were trying out a new an as yet unproved technology (Qpid), I would program to JMS, just to be sure I keep my options open, so I could switch easily to a different JMS provider if need be. I think your API copies too much from JMS and is not low-level enough. The API that the comm layer exposes, gets it just about right IMO. On 16/08/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > > > > > > > 1. Methods as classes, rather than exposed arguments. > > > > > > > > > [RA] On a general note, as an API user I like to use arguments rather > > than > > > classes. > > > I think that's what a majority of users would prefer as it looks more > > > natural. YMMV > > > > > > > > > Yes, but two points: > > > > Most users will use JMS, not the low-level API. The low-level is to > > implement JMS on top of, and to provide extra capabilities in some > > scenarioes. > > > [RA] Well as AMQP gets more popular people may want to use AMQP directly. > Rabbit already has a no JMS java client. > Synapse is interested in using AMQP without JMS > We already have a customer who doesn't care about JMS but a java client. > > I am not discounting JMS. But let the users take what they want. > Nothing is forever. EJB proved that beyond dobut. > > Can provide the exposed argument forms as convenience methods on top of > the > > method-as-class/factory style. > > >
