qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rupert Smith" <rupertlssm...@googlemail.com>
Subject Re: Qpid Java Design [ was Re: Proposed QPID API Discussion]
Date Thu, 02 Aug 2007 09:07:48 GMT
Hi,

I have thought of another reason why I think the AMQP methods as interfaces
approach may be useful. As already mentioned the delegate/invoker interfaces
are symmetric opposites viewed from the client and broker sides. This means
that the routing/delivery layer of the broker will implemented the invoker
interface for incoming method calls, and the client will implement it for
outgoing method calls.

Quick example:

interface MessageInvoker
{
   public void messageTransfer(Session context, MessageTransfer mt);
   ... more
}

class ClientMessageImpl implements MessageInvoker { ... }

class BrokerDeliveryEngine implements MessageInvoker { ... }

In a situation where we want to have a client and broker on the same
machine, with using an in-VM transport, we can weld the client directly onto
the broker delivery engine, completely bypassing the network transport and
comm layers, simply by providing the client with a BrokerDeliveryEngine as
the implementation to call against, rather that a ClientMessageImpl. For
this reason, we should think of the low-level API not just as a client API
but also potentially as part of the brokers internal SPI.

The fact that the MessageTransfer is in the API as an interface, permitting
multiple implementations, will allow the broker delivery engine to be
written to that interface, regardless of implementation. We might have two
implementations, one that uses Java fields, and another that references a
byte buffer:

interface MessageTransfer
{
   public String getRoutingKey();
   ... more
}

class MessageTransferWireLevel implements MessageTransfer
{
   ByteBuffer buffer();
   // or possibly byte[] buffer;

   public String getRoutingKey() { //fetch and decode the routing key from
the byte buffer, cache result. }
}

class MessageTransferInVm implements MessageTransfer
{
   String routingKey;

   public String getRoutingKey() { return routingKey; }
}

Although, these two could be combined into a single class with different
constructors.

We might perhaps even do:

class MessageTransferNative implements MessageTransfer
{
   public native String getRoutingKey();
}

Which keeps two more interesting possibilities open: native
framing/deframing for Java client, or ability to weld a Java client directly
onto a C++ broker through JNI. Not saying that we should be doing these
things, but I do like interfaces that keep implementation possibilities
open.

Hopefully over the weeks ahead I may find time to go back over all
discussions relating to this API, and try and pull together either a set of
requirements or a design in UML format, that brings together everyone's
opinions. In the mean time, please keep the ideas coming.

Rupert


On 01/08/07, Rajith Attapattu <rajith77@gmail.com> wrote:
>
> Robert,
>
> Yes and I will add that to the document to be clear.
>
> Rajith
>
> On 8/1/07, Robert Godfrey <rob.j.godfrey@gmail.com> wrote:
> >
> > Just to be clear... the multi version support and references to
> "structs"
> > is
> > about 0-10 and onwards... This design is based on the new protocol
> > features
> > that are evolving as part of 0-10 (e.g. tracks/sub-channels).  Backward
> > compatability with versions prior to 0-10 will be have to be achieved
> some
> > other way... yes?
> >
> > -- Rob
> >
> > On 31/07/07, Rajith Attapattu <rajith77@gmail.com> wrote:
> > >
> > > Hi Folks,
> > >
> > > The following link contains the design concepts behind the new client
> > (and
> > > the java broker)
> > >
> > >
> >
> http://cwiki.apache.org/confluence/display/qpid/Restructuring+Java+Broker+and+Client+Design
> > > This is an evolving document and is intended as useful base to start
> > work.
> > >
> > > Hopefully this will help everybody during the discussions.
> > >
> > > Regards,
> > >
> > > Rajith
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message