qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: on how to use the qpid java client
Date Fri, 08 Jun 2007 18:57:43 GMT
On Fri, 2007-06-08 at 13:30 -0400, Rajith Attapattu wrote:
> >Also as Rob points out there is only a certain amount of features that u can
> expose through an extended JMS API. So I don't want to force our customers
> to use JMS when they are willing to use something else.
> For example some people like to use the message.get functionality. This
> cannot be expressed in JMS as rob points out.

I disagree. I don't know JMS at all but I have extended Java APIs before
and the magic of casting can get around most any problem:

Here's some JMS code I cogged from the web:

        // Look up a JMS topic
        Topic chatTopic = (Topic)jndi.lookup(topicName);

        // Create a JMS publisher and subscriber
        TopicPublisher publisher = 
            pubSession.createPublisher(chatTopic);
        TopicSubscriber subscriber = 
            subSession.createSubscriber(chatTopic);

        // Set a JMS message listener
        subscriber.setMessageListener(this);

Here's an imaginary way of extending it to use Qpid features like get():

 	// Drill down to the Qpid layer:
	org.apache.qpid.Subscriber qsub = ((QpidSubscriber)subscriber)

	// Access the python-style AMQP-mapped API
 	qpid.amqp0-10.Channel ch = qsub.getChannel();

	// And use it:
	qpid.amqp.0-10.Message = ch.message.get(qsub.getTicket(),
gsub.getQueue(), gsub.getDestination(), false)


No doubt I've mangled the mapping but you get the idea:
 - provide a full AMQP-mapped, python like API.
 - build JMS on top of that API 
 - use casting to get to the Qpid implementation of JMS objects.
 - query the Qpid implementation for the AMQP API objects you need.
 - use the AMQP API to do anyting AMQP can do. 
 - go back to JMS programming whenever you feel like it.

It's not completely trivial but it is relatively straightforward.
Clearly if JSM objects are implemented in terms of AMQP objects, they
have access to those objects, so we can just pass that access on to the
user want to use JMS primarily but needs to "escape" from JMS for some
special AMQP feature.

This approach to defining our APIs is almost laughably easy: both our
APIs (JMS and AMQP) are _already defined_ by the standards (and the
python client:), we just have to implement them and link them together
properly.

Cheers,
Alan.


Mime
View raw message