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 Wed, 01 Aug 2007 10:30:17 GMT
Yes, I think I am kind of hoping that the different protocol versions will
be similar enough that a common MethodFactory interface can be used:

interface MethodFactory
{
   public createQueueDeclareMethod(String queueName);
}

interface MethodFactory_v0_8 extends MethodFactory
{
}

interface MethodFactory_v1_0 extends MethodFactory
{
}

Then the method creation is identical accross protocol versions, although
the underlying framing may differ.

If a method does differ accross versions, could do:

{
  // Connection and negotiate version.
  ...
  int version = ...
}

public void someJmsMethodImplementationThatNeedsTheMethodFactory()
{
  SessionInvoker sessionInvoker = ...
  AMQPSession session = ...

  MethodFactory methodFactory = ...
  Method methodToCall;

  if (version = 8)
  {
     MethodFactory_v8 v8Factory = (MethodFactory_v8)methodFactory;

     methodToCall = v8Factory.createSomeV8SpecificMethod(...);

  }
  else if (version = 10)
  {
      methodToCall = MethodFactory_v10 v10Factory =
(MethodFactory_v10)methodFactory;

     v10Factory.createSomeV10SpecificMethod(...);
  }

  sessionInvoker.sessionMethodX(session, methodToCall);
}

So for methods that remain the same, call the common factory, for
methods/classes that differ across protocol versions, will have to write the
JMS layer to adapt to the version being used by casting down to reveal the
version specifics.

On 01/08/07, Robert Godfrey <rob.j.godfrey@gmail.com> wrote:
>
> For me, I would be hiding the version of the protocol as much as possible
> (since this is essentially only "discovered" in the negotiation between
> client and server when a connection is initiated - not at coding time).
> Therefore you need to be programming against an API which is (reasonably)
> version agnostic.  How would I know whether to call the 0-10 or the 0-11
> createQueueDeclare( ... ) method?
>
> We have to assume a certain level of commonality between protocol versions
> for any true multi-version spport to be possible.
>
> For this to work, I would think interface MethodFactory_v0_11 must extend
> MethodFactory_v0_10 ... so that I, as a programmer could be given a method
> factory and rely on it having the createQueueDeclare method which takes
> the
> 0-10 arguments...
>
> Not sure I'm making sense... just back from vacation :-)
>
> -- Rob
>
>
>
>
> On 01/08/07, Rupert Smith <rupertlssmith@googlemail.com> wrote:
> >
> > Roughly:
> >
> > interface MethodFactory_v0_8
> > {
> >    QueueDeclare createQueueDeclareMethod(v8 args...);
> >    ... more
> > }
> >
> > interface MethodFactory_v1_0
> > {
> >    QueueDeclare createQueueDeclareMethod(v10 args...);
> >    ... more
> > }
> >
> > interface QueueInvoker
> > {
> >    queueDeclare(AMQPSession context, QueueDeclare qd);
> > }
> >
> > interface QueueDeclare
> > {
> >    // Fully opaque interface.
> >
> >    // Or expose args that we are sure will be common amongst all
> versions,
> > e.g.
> >    String getQueueName();
> > }
> >
> > class QueueDeclare_v10 implements QueueDeclare, Struct
> > { ... }
> >
> > class QueueDeclare_v8 implements QueueDeclare
> > { ... }
> >
> > class QueueInvoker_v8 implements QueueInvoker
> > {
> >    queueDeclare(AMQPSession context, QueueDeclare qd)
> >    {
> >       // Ensure context and command are v8
> >       if (!(context instanceof AMQPSession_v8) || !(qd instanceof
> > QueueDeclare_v8))
> >       {
> >           throw new IllegalArgumentException();
> >       }
> >    }
> > }
> >
> > Similarly for QueueInvoker_v10
> >
> >
> >
> > On 01/08/07, Rupert Smith <rupertlssmith@googlemail.com> wrote:
> > >
> > > I think it would be best not to 'reveal' Struct in the API itself.
> > > Partially or fully opaque method wrappers and a versioned factories
> for
> > > creating the method calls would hide the version specific
> > implementations. I
> > > think I will have to post an example to explain what I mean by that...
> > >
> > > On 01/08/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