qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tomas Restrepo" <tomas.restr...@devdeo.com>
Subject RE: on how to use the qpid java client
Date Mon, 04 Jun 2007 12:35:57 GMT
Rupert,


> Might it be an idea to hold/complete the discussion on uniformity
> accross
> clients, before solidifying the choices made into Java code?
> 
> It seems to me from the .Net API discussion that the following are the
> most
> favoured choices:
> 
> WCF -> Qpid AMQ API -> framing
> JMS -> Qpid AMQ API -> framing
> 
> I had some questions about possible efficiency issues around too much
> layering, but as the Qpid API maps so closely onto the AMQP protocol
> that
> the middle bit is perhaps little more than some convenience methods,
> that
> you might write anyway, to build and dispatch frames to/from the event
> framework and framing layer that needs to be there regardless of the
> API
> choice.
> 
> Do we need/want/have the will/time to expose a common Qpid AMQ API
> accross
> all clients? If we want uniformity, and some choices and changes are
> currently being made as to what the .Net API will look like, it would
> be
> prudent to reach a concensus first, or else we will just end up with
> two
> more non-uniform APIs.

I agree this is a valid question, but at least from my point of view,
uniformity of the API isn't such a big deal, for this kind of project in
particular. That said, if the API were to be that AMQP-compatible API, which
is certainly fairly low level, then by that virtue alone the API would be
fairly similar across implementations, simply because it would resemble the
AMQP class/method model fairly closely. I believe we'd likely still have
some differences for things async operations (which definitely have
different conventions across languages), but that wouldn't be that bad.

Personally, I think this is a good thing, and I'd vote +1 on creating this
lower level API. Seems like 0.10/0.11 might be a good time to do it given
the changes in sessions/channel and framing, but what do I know :)

Also, just for the record, from the .NET client side: Sure, it would be nice
to have a WCF channel for Qpid; in fact, it's something I've in mind for a
long time, and even made some initial implementation. However, having a
lower-level, alternative API would still be a good thing, for several
reasons:

1- Not all people will want to use WCF, for example, we might want to
provide native BizTalk adapters as an alternative.
2- WCF limits what the API can do, simply because the surface it exposes to
the application/service is limited to the messaging operations (i.e.
send/receive). There's really no clean way of exposing the other AMQP API's
to the application/service to do things like create a queue on demand, or
create an exchange.

In the initial WCF channel implementation I did, I worked around this by
using configuration properties that provide support for common operating
models. For example, it might be common for a message publisher to declare
the exchange it will publish messages to, so it could set a property on the
binding telling it to declare the exchange (alongside with the exchange name
and class properties) when the client channel is opened. Now, this is a good
compromise, I think, but it still is a compromise.

 
> Also, what are we to make of the new Java client? I'm a bit unclear as
> to
> why it is being written in a completely seperate module as a clean
> re-implementation. 

I can't really comment on this, but I do have an opinion regarding it. I've
become very familiar with the Java client code (as well as the .NET client
code) over the past few months, and in my very humble opinion, a lot of the
code is a mess. Not only is it complex, it is also hard to test and it has a
number of poor practices that make it even more complex: Classes too big
(just look at the connection or channel/session classes), very tight
coupling between classes at different layers and an arcane threading model
(i.e. MINA in the Java code, and unfortunately the original .NET code got
stuck with the same model, even though it doesn't have the MINA
restrictions). This not only means the code is harder to maintain (again,
imho), it is also more fragile and inefficient (and the multitude of threads
it creates here and there to work around the base threading model makes it
"steal" valuable resources from the application/service using the client).

Personally, if it were up to me, and we agreed on creating the new
lower-level API, at least for the .NET client I think the right choice would
be to rewrite a large part of the client code base. A lot of this will be
necessary anyway with the changes in 0.10/11, anyway. That said, the lowest
levels of the stack work pretty well, imho (i.e. things the model for the
lower level framing layer and coding/decoding and the transport layer).

Just to put it in context: I was pretty surprised (and not in a good way) to
realize that I was able to follow the C++ client code base much easier than
the java (or .net, for that matter) code base :)


Tomas Restrepo
http://www.winterdom.com/weblog/





Mime
View raw message