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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
> > > > >
> > > >
> > >
> > >
> >
>
