This page last changed on Jul 31, 2007 by rajith.

Proposed Architecture

The following diagram depicts the architecture for the client and broker.
The idea is to auto generate and share as much code as possible between the broker and the client.

______________________________________________
 JMS for Client       |  Broker Logic
______________________|_______________________
  Qpid Client API     |  
                      |
  Qpid Layer Client   |  Qpid Layer Broker
______________________|_______________________  
           Invoker  -- For out going
           Delegate -- For incomming
         
          Connection, Session, Channel

              Communication Layer
______________________________________________
  • The communication layer will be common to both client and broker.
  • The Qpid Layer contains handlers that are both common to client and broker as well as Client and Server specific classes.
  • The 3rd Layer is where the message processing logic will be implemented.
  • For Client there will be a thin wrapper called Qpid API to mask around the Invoker and expose methods by class. The client will use the Delegate to handle incomming events.
    • This can be used to implement JMS on top.
    • Or application logic directly on top of the Qpid API.
  • The Broker will build it's logic around the Invoker and Delegate.

Invoker and Delegate

Invoker and Delegate are generated classes that contains all the methods in the spec.
To call a method you use the Invoker and to handle a method you use the Delegate.

Multi Version Support

To tackle multi version support the following stratergy is used.
Struct interfaces are defined with a union of methods from different versions. And version specific struct factories will produce concrete structs for each version. All these classes are auto generated from the spec.
Ex:

   interface Struct_A
   {
      public getX(String s);  // AMQP 0-10
      public getX(String s, int i);  // AMQP 0-11

      public getY();  // AMQP 0-10
      public getZ();  // AMQP 0-11
   }
   Struct_A_v0_10 implements Struct_A
   {      
      public getX(String s){.... } 
      public getY(){.... } 
   }
   Struct_A_v0_11 implements Struct_A
   {
      public getX(String s){.... } 
      public getX(String s,int i){.... } 
      public getY(){.... } 
      public getZ(){.... } 
   }

Client code can still use v0-10 methods with a v0-11 library and compile as the Interface and existing methods have not changed. Changes are handled by adding the new or modified methods. Note this strategy is only envisaged for incremental changes. A major change in spec would need substantial code changes.

Qpid Client API

Is a thin wrapper around the Invoker plus a few convinence methods.
For example lets look at the Session class.

Invoker
{
  // All the spec methods
}
CommonSession extends Invoker
{
  // convinience methods for messaging
  header(Header h);
  data(byte[] src);
  endData();
  messageTransfer(String destination,Message msg);
}
ClientSession extends CommonSession implements Session
{
  // no implementation for 90% of the methods
  // Acts as a Mask for Session 'class' so only session specific methods are visible to the user.
}

Communication Layer

Frame Dispatch Tree

The following diagram depicts how an AMQP frame gets handled.

Content Handler Flow

Method Handler Flow


AMQ Frame handling (text/xml)
DispatchTree.jpg (image/jpeg)
ContentHandlerTree.jpg (image/jpeg)
MethodHandlerTree.jpg (image/jpeg)
Document generated by Confluence on May 26, 2010 10:31