On 11 Feb 2011, at 15:24, Rajith Attapattu wrote:
On Thu, Feb 10, 2011 at 2:11 PM, Gordon Sim <[email protected]> wrote:
On 02/10/2011 02:54 PM, Rajith Attapattu wrote:
The above is not a formal authoritative document that describes
what our
Common API is.
If by authoritative you mean '100% accurate and complete' then I
accept it
is not there yet.
Actually by authoritative I didn't really mean accuracy and
completeness,
rather I was expecting a document in a different form.
Perhaps something similar to the JMS spec. I believe you and I have a
different vision about how this document should look like.
Perhaps that is where the disconnect is. As time permits I will try
to work
out a document and post it to provide a more complete picture of
what I was
envisaging.
*Please* don't repeat the mistakes the JMS specification made! I
really feel it's too vague and wooly for a formal specification,
whereas it ought to be precise and informative. There are too many
situations where I have checked the JMS specification, only to find
it describes behaviour that could be interpreted in several different
ways, or worse is simply undefined or up to the provider. This style
is more suitable for a programmer's guide describing the common API,
covering the technical terms of reference, design philosophy,
illustrating common use cases and giving concrete examples of code.
This type of document was (the first) 2. on your list and 4. on mine,
assuming your list to be describing six different types of document.
I still think UML is a concise and reasonable way to model the AMQP
common API in a language agnostic fashion. This is document 1. in
both our lists, and it MUST have a well-defined correlation with the
official AMQP specification(s).
Take a look at Enterprise Architect (very good, I used it a lot at
Yell for data modelling) or the Eclipse modelling tools (never used
in anger) for UML design tools. To be hones, I think UML is probably
too powerful when it comes to describing AMQPs data structures and
commands, but that should make the task easier. It has the benefit
that any competent programmer can mentally translate between UML and
$FAVOURITE_LANGUAGE, and there are tools to automatically create HTML
documentation or Java, C++ or whatever code templates.
Andrew.
--
-- andrew d kennedy ? do not fold, bend, spindle, or mutilate ;
-- http://grkvlt.blogspot.com/ ? edinburgh : +44 7582 293 255 ;
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
