You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Jonathan Robie <jo...@redhat.com> on 2009/09/11 21:06:11 UTC
New messaging API - base on AMQP 1.0, or on Java JMS?
In another message, I suggest separating out the configuration API from
the messaging API.
In this message, I wonder whether we should consider using either AMQP
1.0 or Java JMS as the model for the new messaging API, rather than
create a third model that nevertheless needs to bridge both Java JMS and
AMQP. If we separate out configuration, I would think either model would
cover everyday messaging operations quite well.
Making the new API more like Java JMS would have the advantage that is
the best known messaging API. Making it more like the AMQP 1.0 model
would allow more direct support of AMQP concepts. Is there an advantage
to having a third programming model that is not based on either?
Jonathan
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: New messaging API - base on AMQP 1.0, or on Java JMS?
Posted by Aidan Skinner <ai...@gmail.com>.
On Mon, Sep 14, 2009 at 11:31 AM, Martin Ritchie <ri...@apache.org> wrote:
> Are you suggesting writting a new Configuration API for the Java client?
>
> Have you thought how the configuration can still be performed via JNDI?
I think it's important that we offer both. Being able to do this via
configuration is neat, particularly if you're into IoC.
> If we start having vendor specific APIs in the Java space we totally
> devalue the AMQP offering IMHO. Sure it is nice to give people options
> but Java users should be encoraged to stick to the JMS API, that is
> until AMQP define a API which can then be adopted across all AMQP
Having an AMQP API would be really good, but is probably Some Way Off
for 1-0, and I don't think it will ever happen for versions before 1-0
(because nobody will put in the effort).
I also think it's important for people to be able to set up their
wiring through API - it's clearer what's going on and more
discoverable for a start.
- Aidan
--
Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org
"A witty saying proves nothing" - Voltaire
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: New messaging API - base on AMQP 1.0, or on Java JMS?
Posted by Rafael Schloming <ra...@redhat.com>.
Martin Ritchie wrote:
> Jonathan,
>
> Are you suggesting writting a new Configuration API for the Java client?
>
> Have you thought how the configuration can still be performed via JNDI?
>
> I have mentioned this before on the list so will be brief (well that
> was the aim). I really don't see any advantage to adding new a API (of
> any sort) on the java side. Allowing 100% compliant JMS code to just
> work with JNDI configuration changes for Qpid is the best thing we can
> do for our users. If they have spent the time to write to the JMS API
> and stay away from vendor locks then we should reward them by just
> working. Asking them to rewrite some of their code when moving to a
> product that is based on AMQP, which is attempting to fight against
> the vendor lock ins in the messaging world, sends the wrong message.
>
> If we start having vendor specific APIs in the Java space we totally
> devalue the AMQP offering IMHO. Sure it is nice to give people options
> but Java users should be encoraged to stick to the JMS API, that is
> until AMQP define a API which can then be adopted across all AMQP
> clients. I think the work that is being done to standardise the APIs
> of the other language clients is to be commended and will surely be of
> a great benefit to clients writing in those languages. However, I have
> yet to hear a compelling reason to have non JMS API code on the java
> side, even if it is just for configuration. That said, as long as you
> can do everthing via JNDI that you can do via the new API then user
> migration from other JMS products will not require code changes which
> in the end is how we are going to win migrating Java users. If they
> have to rewrite parts of their app then what happened is the open and
> compatble standard messaging story we are trying to sell?
I think the specter of vendor specific APIs is being a bit misused here.
Your traditional vendor specific API has extra functionality that locks
the client into that vendor's broker. An API that allows access to AMQP
functionality that doesn't fit well into the JMS API (e.g. the
management aspects of AMQP) really isn't a "vendor specific API" and I
don't see how it devalues/defeats the purpose of AMQP.
Also, nobody is suggesting providing a competing way to do things that
can already be done through vanilla JMS. For example, the JMS API simply
doesn't address how to manage and/or configure brokers, and so anyone
migrating existing JMS code won't have to change anything regardless of
what we provide in this area.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: New messaging API - base on AMQP 1.0, or on Java JMS?
Posted by Jonathan Robie <jo...@redhat.com>.
Gordon Sim wrote:
> On 09/15/2009 10:42 PM, Andrew Wright wrote:
>> The main need we've run across for a lower level java api comes from
>> performing administrative functions from code - a standardised admin api
>> would certainly be useful (cf. MQSeries PCF). I'm not sure there would
>> be much benefit from shoehorning this into either JMS or a messaging api
>> though.
>
> The c++ broker uses the 'qpid management framework' (QMF) which
> involves sending formatted messages representing various management
> requests to a special exchange in the broker. The client can also get
> results, and details/stats of managed entities sent back as formatted
> messages.
>
> At present creation and deletion of queues and exchanges isn't a
> actually supported over that interface, but I think it could be added
> fairly easily. That would give a uniform mechanism for all kinds of
> configuration and stats gathering.
>
> QMF has its own API. Ideally, in the future, it will also be easy to
> perform operations using the messaging APIs simply by sending to (and
> receiving from) a special address, using a defined message schema.
+1
Jonathan
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: New messaging API - base on AMQP 1.0, or on Java JMS?
Posted by Gordon Sim <gs...@redhat.com>.
On 09/15/2009 10:42 PM, Andrew Wright wrote:
> The main need we've run across for a lower level java api comes from
> performing administrative functions from code - a standardised admin api
> would certainly be useful (cf. MQSeries PCF). I'm not sure there would
> be much benefit from shoehorning this into either JMS or a messaging api
> though.
The c++ broker uses the 'qpid management framework' (QMF) which involves
sending formatted messages representing various management requests to a
special exchange in the broker. The client can also get results, and
details/stats of managed entities sent back as formatted messages.
At present creation and deletion of queues and exchanges isn't a
actually supported over that interface, but I think it could be added
fairly easily. That would give a uniform mechanism for all kinds of
configuration and stats gathering.
QMF has its own API. Ideally, in the future, it will also be easy to
perform operations using the messaging APIs simply by sending to (and
receiving from) a special address, using a defined message schema.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: New messaging API - base on AMQP 1.0, or on Java JMS?
Posted by Andrew Wright <at...@mac.com>.
On 15 Sep 2009, at 21:57, James Mansion wrote:
> Jonathan Robie wrote:
>> In the languages besides Java, there is no standard messaging API
>> to fall behind. I'll say something more on Java in a separate
>> message.
> If its market share of deployed MOM components that lie strangely
> unused, its MSMQ.
>
> If market share of paid-for MOM matters, isn't MQSeries effectively
> a de-facto standard?
>
> But as I've said before, last time I checked the MQSeries API really
> only worked in threaded clients.
>
> James
>
From an MQSeries point of view it seems like IBM have been moving
towards a more JMS-like API for their non-java clients, particularly
as of version 7.
From a pure layman's perspective on JMS, we've successfully been
using JMS clients with qpid for both basic (pub/sub, point to point)
and more advanced (LVQ) operations. This would appear to bode well for
its flexibility from a messaging point of view.
The main need we've run across for a lower level java api comes from
performing administrative functions from code - a standardised admin
api would certainly be useful (cf. MQSeries PCF). I'm not sure there
would be much benefit from shoehorning this into either JMS or a
messaging api though.
Cheers,
Andrew
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: New messaging API - base on AMQP 1.0, or on Java JMS?
Posted by James Mansion <ja...@mansionfamily.plus.com>.
Jonathan Robie wrote:
> In the languages besides Java, there is no standard messaging API to
> fall behind. I'll say something more on Java in a separate message.
If its market share of deployed MOM components that lie strangely
unused, its MSMQ.
If market share of paid-for MOM matters, isn't MQSeries effectively a
de-facto standard?
But as I've said before, last time I checked the MQSeries API really
only worked in threaded clients.
James
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: New messaging API - base on AMQP 1.0, or on Java JMS?
Posted by Aidan Skinner <ai...@gmail.com>.
On Mon, Sep 14, 2009 at 3:11 PM, Jonathan Robie
<jo...@redhat.com> wrote:
> Rafael Schloming wrote:
>>
>> FWIW, the way gsim and I have discussed dealing with configuration is to
>> provide a reasonable text based syntax for specifying an address/destination
>> that is just a name plus additional sender/producer or consumer/receiver
>> options. This should permit some consistency in client configuration across
>> languages and be usable via JNDI from Java.
>
> I like this approach.
+1
- Aidan
--
Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org
"A witty saying proves nothing" - Voltaire
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: New messaging API - base on AMQP 1.0, or on Java JMS?
Posted by Jonathan Robie <jo...@redhat.com>.
Rafael Schloming wrote:
> FWIW, the way gsim and I have discussed dealing with configuration is
> to provide a reasonable text based syntax for specifying an
> address/destination that is just a name plus additional
> sender/producer or consumer/receiver options. This should permit some
> consistency in client configuration across languages and be usable via
> JNDI from Java.
I like this approach.
Jonathan
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: New messaging API - base on AMQP 1.0, or on Java JMS?
Posted by Rafael Schloming <ra...@redhat.com>.
Jonathan Robie wrote:
> Martin Ritchie wrote:
>> Are you suggesting writting a new Configuration API for the Java client?
>>
>
> No - Java JMS is the high level API for the Java client. Note that one
> of the possible directions I suggested is to provide a way for other
> languages to support the Java JMS properties files. The other route I
> suggested is a configuration API.
I should point out the properties files that JMS uses are not part of
the JMS standard and the syntax of the entries is quite qpid specific.
FWIW, the way gsim and I have discussed dealing with configuration is to
provide a reasonable text based syntax for specifying an
address/destination that is just a name plus additional sender/producer
or consumer/receiver options. This should permit some consistency in
client configuration across languages and be usable via JNDI from Java.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: New messaging API - base on AMQP 1.0, or on Java JMS?
Posted by Jonathan Robie <jo...@redhat.com>.
Martin Ritchie wrote:
> Are you suggesting writting a new Configuration API for the Java client?
>
No - Java JMS is the high level API for the Java client. Note that one
of the possible directions I suggested is to provide a way for other
languages to support the Java JMS properties files. The other route I
suggested is a configuration API.
In the languages besides Java, there is no standard messaging API to
fall behind. I'll say something more on Java in a separate message.
Jonathan
Jonathan Robie wrote:
> The new messaging client API is designed to hide the details of
> specific AMQP versions. This causes a certain impedance mismatch with
> the maangement tools and the existing APIs, which are centered around
> the AMQP 0-10 model, with exchanges, bindings, queues, etc. To use the
> new API, a programmer need not think of exchanges at all, but anyone
> who uses the management tools sees these exchanges and needs to
> understand the mappings.
>
> This made me think about the way we use Java JMS with AMQP 0-10, even
> though the models are quite different.
>
> Should the new API be used in the same way as the Java JMS client? We
> could provide a way to use an existing Java JMS properties file in the
> client for each language (I assume other languages would ignore the
> java.naming.factory.initial ).
>
> Or should we provide a separate configuration API for each version of
> AMQP that we support, since the semantics used for configuration are
> significantly different, at least between 0-10 and 1.0? The new API
> could provide a set of messaging semantics that covers everything
> except for configuration and is independent of the AMQP version, and
> there could be a separate API for configuring the plumbing in each
> version of AMQP.
>
> Obviously, we could do both. And of course, people will also use the
> management tools to configure their brokers.
>
> If we separate configuration from messaging per se, the high level API
> can be nicely independent of the bumps and wrinkles of a given AMQP
> version, and the configuration APIs can give full control. I think
> that's what we should want.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: New messaging API - base on AMQP 1.0, or on Java JMS?
Posted by Ted Ross <tr...@redhat.com>.
Martin Ritchie wrote:
> Jonathan,
>
> Are you suggesting writting a new Configuration API for the Java client?
>
> Have you thought how the configuration can still be performed via JNDI?
>
If I'm not mistaken, Jonathan was referring to the emerging C++ and
Python messaging APIs, not the Java APIs.
-Ted
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: New messaging API - base on AMQP 1.0, or on Java JMS?
Posted by Rafael Schloming <ra...@redhat.com>.
Bill Whiting wrote:
> I think it would be more worthwhile to try to synchronize the APIs
> between the languages.
> i.e. make the python/C++ APIs look more alike. Obviously there are
> language differences, so they won't be identical. I think it would be
> beneficial if you could expect that the class structure would be similar
> and methods found in the Java AMQP native API would be present in C++
> and Python.
This has definitely been a goal as well. Gordon and I regularly sync up
to make sure we're going in the same directions with things between
python and C++.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: New messaging API - base on AMQP 1.0, or on Java JMS?
Posted by Bill Whiting <te...@bellsouth.net>.
I think it would be more worthwhile to try to synchronize the APIs
between the languages.
i.e. make the python/C++ APIs look more alike. Obviously there are
language differences, so they won't be identical. I think it would be
beneficial if you could expect that the class structure would be similar
and methods found in the Java AMQP native API would be present in C++
and Python.
//Bill
On 09/14/2009 02:23 PM, Rafael Schloming wrote:
> Jonathan Robie wrote:
>> Do we want the new messaging API to be useful for other messaging
>> systems that are not based on AMQP, or is that a non-goal?
>
> So far the primary goal has been to be useful to applications, which
> means the API inevitably includes support for functionality that isn't
> necessarily present in the lowest common denominator messaging
> systems. However this doesn't mean you couldn't use the API with other
> messaging systems if you avoided depending on those features. For
> example you could implement an SMTP/POP based backend, but you would
> need to throw an exception if someone tried to create a transactional
> session.
>
> --Rafael
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: New messaging API - base on AMQP 1.0, or on Java JMS?
Posted by Rafael Schloming <ra...@redhat.com>.
Jonathan Robie wrote:
> Do we want the new messaging API to be useful for other messaging
> systems that are not based on AMQP, or is that a non-goal?
So far the primary goal has been to be useful to applications, which
means the API inevitably includes support for functionality that isn't
necessarily present in the lowest common denominator messaging systems.
However this doesn't mean you couldn't use the API with other messaging
systems if you avoided depending on those features. For example you
could implement an SMTP/POP based backend, but you would need to throw
an exception if someone tried to create a transactional session.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: New messaging API - base on AMQP 1.0, or on Java JMS?
Posted by Jonathan Robie <jo...@redhat.com>.
Do we want the new messaging API to be useful for other messaging
systems that are not based on AMQP, or is that a non-goal?
Jonathan
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: New messaging API - base on AMQP 1.0, or on Java JMS?
Posted by Rafael Schloming <ra...@redhat.com>.
Jonathan Robie wrote:
> That's how the examples in other languages work - there is a separate
> program that sets up the configuration, a publisher that sends messages,
> and a consumer that reads messages from a queue.
>
> Private queues (exclusive + autodelete) are treated differently, the
> client configures these queues and the associated bindings, even though
> the queues live on the broker. And these queues rather belong to the
> client - I assume we want to make sure the client can configure them. In
> other languages, I imagine they just use the configuration API for this.
> What's the best way to handle this in Java JMS?
It depends what the private queues are used for. If they're for topic
subscriptions then that is done under the covers for both JMS and the
other clients and so wouldn't need to explicitly be part of the API. If
they're for temporary queues then JMS has a specific API for creating
temporary queues and temporary topics.
The other APIs will probably do temporary queues as part of the options
associated with an address/destination. This would permit some more
flexible configuration in Java via JNDI, which is ok in this particular
case since the lifecycle of the queue is tied to the lifecycle of the
client, so there is a reasonable way to delete these, and the queues are
also owned by a single client so there isn't the race condition issue.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: New messaging API - base on AMQP 1.0, or on Java JMS?
Posted by Jonathan Robie <jo...@redhat.com>.
Rafael Schloming wrote:
> Jonathan Robie wrote:
>> Rafael Schloming wrote:
>>> There really are two separate configuration topics here:
>>> configuration of the client (which is reasonable to do via JNDI) and
>>> configuration of the broker (which nobody in their right mind would
>>> ever consider doing via JNDI). It would probably be helpful clarify
>>> which one you mean in a given context.
>>
>> The Java JMS examples we use configure the broker - they set up
>> queues and bindings in the broker. What's our story here - is this
>> something that nobody in their right mind would actually do? If so,
>> we might want to change this in our examples once we provide better
>> alternatives ....
>
> Yes, this is pretty much insane since you need to separately specify
> your broker schema for each client that connects, and if they don't
> all match (e.g. one has a typo) then who knows what you'll end up
> getting. It's a race where the first client to connect wins.
>
> Not to mention it's woefully incomplete as a mechanism to configure
> the broker, e.g. there is no way to delete the queues and bindings you
> create this way.
>
> In general you should have a single well documented schema for the
> broker that is maintained separately from all the clients, and the
> clients should be configured with the minimal information required to
> connect to this schema, i.e. just the relevant queue or topic name.
That's how the examples in other languages work - there is a separate
program that sets up the configuration, a publisher that sends messages,
and a consumer that reads messages from a queue.
Private queues (exclusive + autodelete) are treated differently, the
client configures these queues and the associated bindings, even though
the queues live on the broker. And these queues rather belong to the
client - I assume we want to make sure the client can configure them. In
other languages, I imagine they just use the configuration API for this.
What's the best way to handle this in Java JMS?
Jonathan
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: New messaging API - base on AMQP 1.0, or on Java JMS?
Posted by Rajith Attapattu <ra...@gmail.com>.
Rafi,
Below is the link for a proposal that you helped me put together.
http://cwiki.apache.org/confluence/display/qpid/Proposal+for+a+new+JMS+Destination+configuration2
I think it captures most of the concepts you have talked about in this thread.
Perhaps we could use that as a basis for a proposal to be used across
all languages.
regards,
Rajith
On Mon, Sep 14, 2009 at 10:38 AM, Rafael Schloming <ra...@redhat.com> wrote:
> Jonathan Robie wrote:
>>
>> Rafael Schloming wrote:
>>>
>>> There really are two separate configuration topics here: configuration of
>>> the client (which is reasonable to do via JNDI) and configuration of the
>>> broker (which nobody in their right mind would ever consider doing via
>>> JNDI). It would probably be helpful clarify which one you mean in a given
>>> context.
>>
>> The Java JMS examples we use configure the broker - they set up queues and
>> bindings in the broker. What's our story here - is this something that
>> nobody in their right mind would actually do? If so, we might want to
>> change this in our examples once we provide better alternatives ....
>
> Yes, this is pretty much insane since you need to separately specify your
> broker schema for each client that connects, and if they don't all match
> (e.g. one has a typo) then who knows what you'll end up getting. It's a race
> where the first client to connect wins.
>
> Not to mention it's woefully incomplete as a mechanism to configure the
> broker, e.g. there is no way to delete the queues and bindings you create
> this way.
>
> In general you should have a single well documented schema for the broker
> that is maintained separately from all the clients, and the clients should
> be configured with the minimal information required to connect to this
> schema, i.e. just the relevant queue or topic name.
>
> --Rafael
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: New messaging API - base on AMQP 1.0, or on Java JMS?
Posted by Rafael Schloming <ra...@redhat.com>.
Jonathan Robie wrote:
> Rafael Schloming wrote:
>> There really are two separate configuration topics here: configuration
>> of the client (which is reasonable to do via JNDI) and configuration
>> of the broker (which nobody in their right mind would ever consider
>> doing via JNDI). It would probably be helpful clarify which one you
>> mean in a given context.
>
> The Java JMS examples we use configure the broker - they set up queues
> and bindings in the broker. What's our story here - is this something
> that nobody in their right mind would actually do? If so, we might want
> to change this in our examples once we provide better alternatives ....
Yes, this is pretty much insane since you need to separately specify
your broker schema for each client that connects, and if they don't all
match (e.g. one has a typo) then who knows what you'll end up getting.
It's a race where the first client to connect wins.
Not to mention it's woefully incomplete as a mechanism to configure the
broker, e.g. there is no way to delete the queues and bindings you
create this way.
In general you should have a single well documented schema for the
broker that is maintained separately from all the clients, and the
clients should be configured with the minimal information required to
connect to this schema, i.e. just the relevant queue or topic name.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: New messaging API - base on AMQP 1.0, or on Java JMS?
Posted by Jonathan Robie <jo...@redhat.com>.
Rafael Schloming wrote:
> There really are two separate configuration topics here: configuration
> of the client (which is reasonable to do via JNDI) and configuration
> of the broker (which nobody in their right mind would ever consider
> doing via JNDI). It would probably be helpful clarify which one you
> mean in a given context.
The Java JMS examples we use configure the broker - they set up queues
and bindings in the broker. What's our story here - is this something
that nobody in their right mind would actually do? If so, we might want
to change this in our examples once we provide better alternatives ....
Jonathan
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: New messaging API - base on AMQP 1.0, or on Java JMS?
Posted by Rafael Schloming <ra...@redhat.com>.
Jonathan Robie wrote:
> Martin Ritchie wrote:
>> Have you thought how the configuration can still be performed via JNDI?
>>
>> I have mentioned this before on the list so will be brief (well that
>> was the aim). I really don't see any advantage to adding new a API (of
>> any sort) on the java side. Allowing 100% compliant JMS code to just
>> work with JNDI configuration changes for Qpid is the best thing we can
>> do for our users. If they have spent the time to write to the JMS API
>> and stay away from vendor locks then we should reward them by just
>> working. Asking them to rewrite some of their code when moving to a
>> product that is based on AMQP, which is attempting to fight against
>> the vendor lock ins in the messaging world, sends the wrong message.
>>
>
> I agree that there's an advantage to this approach.
>
> I don't think of AMQP as a vendor, and I don't think of an AMQP
> configuration API as a vendor lock, especially if we create it together.
> Ideally, if we can create sufficiently good high level and configuration
> APIs, I'd like to see them become a standard.
>
> Java is the one language with a well-established messaging API, and I
> don't think we should compete with Java JMS, but we do need a good story
> for configuring systems used with Java JMS. I'm agnostic whether JNDI is
> going to be sufficient in the long run. If we see users configure their
> systems using other languages that have APIs for this, or using tools
> written in these languages, it might be worth asking whether a
> configuration API for Java also makes sense. But I think we can also sit
> back and see if that need evolves.
>
> Suppose we see that need. How is an AMQP-specific configuration API
> worse than AMQP-specific JNDI configuration? Neither one gives interop
> for configuring non-AMQP systems. (I really do mean this as a question,
> it's quite likely that there are advantages I don't yet see.)
There really are two separate configuration topics here: configuration
of the client (which is reasonable to do via JNDI) and configuration of
the broker (which nobody in their right mind would ever consider doing
via JNDI). It would probably be helpful clarify which one you mean in a
given context.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: New messaging API - base on AMQP 1.0, or on Java JMS?
Posted by Martin Ritchie <ri...@apache.org>.
2009/9/14 Jonathan Robie <jo...@redhat.com>:
> Martin Ritchie wrote:
>>
>> Have you thought how the configuration can still be performed via JNDI?
>>
>> I have mentioned this before on the list so will be brief (well that
>> was the aim). I really don't see any advantage to adding new a API (of
>> any sort) on the java side. Allowing 100% compliant JMS code to just
>> work with JNDI configuration changes for Qpid is the best thing we can
>> do for our users. If they have spent the time to write to the JMS API
>> and stay away from vendor locks then we should reward them by just
>> working. Asking them to rewrite some of their code when moving to a
>> product that is based on AMQP, which is attempting to fight against
>> the vendor lock ins in the messaging world, sends the wrong message.
>>
>
> I agree that there's an advantage to this approach.
>
> I don't think of AMQP as a vendor, and I don't think of an AMQP
> configuration API as a vendor lock, especially if we create it together.
> Ideally, if we can create sufficiently good high level and configuration
> APIs, I'd like to see them become a standard.
>
> Java is the one language with a well-established messaging API, and I don't
> think we should compete with Java JMS, but we do need a good story for
> configuring systems used with Java JMS. I'm agnostic whether JNDI is going
> to be sufficient in the long run. If we see users configure their systems
> using other languages that have APIs for this, or using tools written in
> these languages, it might be worth asking whether a configuration API for
> Java also makes sense. But I think we can also sit back and see if that need
> evolves.
>
> Suppose we see that need. How is an AMQP-specific configuration API worse
> than AMQP-specific JNDI configuration? Neither one gives interop for
> configuring non-AMQP systems. (I really do mean this as a question, it's
> quite likely that there are advantages I don't yet see.)
>
> Jonathan
I guess I aways saw code changes as a bigger issue than configuration
file changes. Arguable having a compile time error when you change
client libraries is better than randomly having a runtime error when
the JNDI configuration doesn't work. It may be worse if it just works
but the routing sematics introduce a subtile change that isn't easily
detectable.
As has been pointed out this is AMQP which is not a vendor so swapping
Brokers will still work just fine. The issue I was thinking of was
swapping client libraries. If we have Qpid APIs then a developer can't
swap client libraries as easily. Hence my 'vendor lock in' concern
where Qpid is the vendor. That said, when/if AMQP specifies an API for
configuration then org.amqp.configuration classes will be portable so
that issue goes away.
Having a consistent story across all the Qpid components would go a
long way to valiating any API/approach which could be adopted by
others.
I'd be interested in knowing more about what Rafi/Gordon had in mind
for reasonable text based syntax. Sounds like a good a approach. Have
you/Could you put your thoughts up on the wiki?
Cheers
Martin
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Martin Ritchie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: New messaging API - base on AMQP 1.0, or on Java JMS?
Posted by Jonathan Robie <jo...@redhat.com>.
Martin Ritchie wrote:
> Have you thought how the configuration can still be performed via JNDI?
>
> I have mentioned this before on the list so will be brief (well that
> was the aim). I really don't see any advantage to adding new a API (of
> any sort) on the java side. Allowing 100% compliant JMS code to just
> work with JNDI configuration changes for Qpid is the best thing we can
> do for our users. If they have spent the time to write to the JMS API
> and stay away from vendor locks then we should reward them by just
> working. Asking them to rewrite some of their code when moving to a
> product that is based on AMQP, which is attempting to fight against
> the vendor lock ins in the messaging world, sends the wrong message.
>
I agree that there's an advantage to this approach.
I don't think of AMQP as a vendor, and I don't think of an AMQP
configuration API as a vendor lock, especially if we create it together.
Ideally, if we can create sufficiently good high level and configuration
APIs, I'd like to see them become a standard.
Java is the one language with a well-established messaging API, and I
don't think we should compete with Java JMS, but we do need a good story
for configuring systems used with Java JMS. I'm agnostic whether JNDI is
going to be sufficient in the long run. If we see users configure their
systems using other languages that have APIs for this, or using tools
written in these languages, it might be worth asking whether a
configuration API for Java also makes sense. But I think we can also sit
back and see if that need evolves.
Suppose we see that need. How is an AMQP-specific configuration API
worse than AMQP-specific JNDI configuration? Neither one gives interop
for configuring non-AMQP systems. (I really do mean this as a question,
it's quite likely that there are advantages I don't yet see.)
Jonathan
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: New messaging API - base on AMQP 1.0, or on Java JMS?
Posted by Martin Ritchie <ri...@apache.org>.
Jonathan,
Are you suggesting writting a new Configuration API for the Java client?
Have you thought how the configuration can still be performed via JNDI?
I have mentioned this before on the list so will be brief (well that
was the aim). I really don't see any advantage to adding new a API (of
any sort) on the java side. Allowing 100% compliant JMS code to just
work with JNDI configuration changes for Qpid is the best thing we can
do for our users. If they have spent the time to write to the JMS API
and stay away from vendor locks then we should reward them by just
working. Asking them to rewrite some of their code when moving to a
product that is based on AMQP, which is attempting to fight against
the vendor lock ins in the messaging world, sends the wrong message.
If we start having vendor specific APIs in the Java space we totally
devalue the AMQP offering IMHO. Sure it is nice to give people options
but Java users should be encoraged to stick to the JMS API, that is
until AMQP define a API which can then be adopted across all AMQP
clients. I think the work that is being done to standardise the APIs
of the other language clients is to be commended and will surely be of
a great benefit to clients writing in those languages. However, I have
yet to hear a compelling reason to have non JMS API code on the java
side, even if it is just for configuration. That said, as long as you
can do everthing via JNDI that you can do via the new API then user
migration from other JMS products will not require code changes which
in the end is how we are going to win migrating Java users. If they
have to rewrite parts of their app then what happened is the open and
compatble standard messaging story we are trying to sell?
Regards
Martin
2009/9/11 Jonathan Robie <jo...@redhat.com>:
> Rafael Schloming wrote:
>>
>> Rafael Schloming wrote:
>>>
>>> The upshot is you can sort of look at these as providing a JMS-like API
>>> plus some critically missing bits minus some extra cruft.
>>
>> One thing I should say before someone accuses me of bashing our JMS client
>> too much is that most of the critically missing bits of functionality are
>> actually also available in our JMS client, just not via the JMS API. They're
>> usually accessible via some system property or other.
>
> OK, I get it now. But the naming is more AMQP-like than JMS-like, it seems.
> Which is good.
>
> As long as we separate out the configuration APIs from the messaging APIs,
> this approach makes sense to me.
>
> Jonathan
>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Martin Ritchie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: New messaging API - base on AMQP 1.0, or on Java JMS?
Posted by Jonathan Robie <jo...@redhat.com>.
Rafael Schloming wrote:
> Rafael Schloming wrote:
>>
>> The upshot is you can sort of look at these as providing a JMS-like
>> API plus some critically missing bits minus some extra cruft.
>
> One thing I should say before someone accuses me of bashing our JMS
> client too much is that most of the critically missing bits of
> functionality are actually also available in our JMS client, just not
> via the JMS API. They're usually accessible via some system property
> or other.
OK, I get it now. But the naming is more AMQP-like than JMS-like, it
seems. Which is good.
As long as we separate out the configuration APIs from the messaging
APIs, this approach makes sense to me.
Jonathan
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: New messaging API - base on AMQP 1.0, or on Java JMS?
Posted by Rafael Schloming <ra...@redhat.com>.
Rafael Schloming wrote:
> Jonathan Robie wrote:
>> In another message, I suggest separating out the configuration API
>> from the messaging API.
>>
>> In this message, I wonder whether we should consider using either AMQP
>> 1.0 or Java JMS as the model for the new messaging API, rather than
>> create a third model that nevertheless needs to bridge both Java JMS
>> and AMQP. If we separate out configuration, I would think either model
>> would cover everyday messaging operations quite well.
>>
>> Making the new API more like Java JMS would have the advantage that is
>> the best known messaging API. Making it more like the AMQP 1.0 model
>> would allow more direct support of AMQP concepts. Is there an
>> advantage to having a third programming model that is not based on
>> either?
>
> It's probably worth distinguishing between the messaging model and the
> programming model. If you look at the messaging model alone then AMQP,
> the new APIs, and JMS aren't a million miles apart. The major difference
> is that AMQP describes the messaging model in more abstract terms and
> from a global perspective. You have "nodes" that store messages, and
> "links" that shuttle messages between nodes, and "addresses" that
> identify nodes.
>
> With the JMS API the messaging model is understandably described more
> from the perspective of a client application. You have destinations,
> producers, and consumers. A JMS destination is just a name for something
> that you can send messages to or get messages from (in AMQP terms it's
> an address). A producer is just an outgoing link, and a consumer is just
> an incoming link.
>
> Similarly the new APIs take a somewhat more client centric approach to
> terminology, but without some of the slightly confusing choices made in
> the JMS API. The new APIs are defined in terms of addresses, senders,
> and receivers. Where the term address is pretty much synonymous with the
> AMQP usage of the term, and the term sender and receiver can be thought
> of as the API for the two ends of a link, as in "a link connects two
> nodes, a sender and a receiver."
>
>
> Now as for the programming model, AMQP is really intentionally agnostic
> on that subject since it's just a protocol. For JMS the only really well
> supported programming model is for threads in the client library to
> dispatch out to message listeners supplied by the application. For
> example if the application wants to call into the library to get its
> messages, then you really need to go around the API to configure
> prefetch appropriately in order for this to work in a safe and practical
> (or at least in a performant) way.
>
> As for the new APIs, while the basic concepts are quite analogous to JMS:
>
> MessageProducer.send(...) vs Sender.send()
> MessageConsumer.receive(...) vs Receiver.fetch(...)
>
> They provide additional features intended to support a wider variety of
> programming models, such as explicit control over blocking vs non
> blocking behavior, access to asynchronous send/ack confirmation,
> explicit control over prefetch and flow control, etc. Additionally there
> are a few choices made for consistency and simplicity, e.g. rather than
> having a separate API for queue browsers like JMS does, you simply use a
> non destructive receiver.
>
> The upshot is you can sort of look at these as providing a JMS-like API
> plus some critically missing bits minus some extra cruft.
One thing I should say before someone accuses me of bashing our JMS
client too much is that most of the critically missing bits of
functionality are actually also available in our JMS client, just not
via the JMS API. They're usually accessible via some system property or
other.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: New messaging API - base on AMQP 1.0, or on Java JMS?
Posted by Rafael Schloming <ra...@redhat.com>.
Jonathan Robie wrote:
> In another message, I suggest separating out the configuration API from
> the messaging API.
>
> In this message, I wonder whether we should consider using either AMQP
> 1.0 or Java JMS as the model for the new messaging API, rather than
> create a third model that nevertheless needs to bridge both Java JMS and
> AMQP. If we separate out configuration, I would think either model would
> cover everyday messaging operations quite well.
>
> Making the new API more like Java JMS would have the advantage that is
> the best known messaging API. Making it more like the AMQP 1.0 model
> would allow more direct support of AMQP concepts. Is there an advantage
> to having a third programming model that is not based on either?
It's probably worth distinguishing between the messaging model and the
programming model. If you look at the messaging model alone then AMQP,
the new APIs, and JMS aren't a million miles apart. The major difference
is that AMQP describes the messaging model in more abstract terms and
from a global perspective. You have "nodes" that store messages, and
"links" that shuttle messages between nodes, and "addresses" that
identify nodes.
With the JMS API the messaging model is understandably described more
from the perspective of a client application. You have destinations,
producers, and consumers. A JMS destination is just a name for something
that you can send messages to or get messages from (in AMQP terms it's
an address). A producer is just an outgoing link, and a consumer is just
an incoming link.
Similarly the new APIs take a somewhat more client centric approach to
terminology, but without some of the slightly confusing choices made in
the JMS API. The new APIs are defined in terms of addresses, senders,
and receivers. Where the term address is pretty much synonymous with the
AMQP usage of the term, and the term sender and receiver can be thought
of as the API for the two ends of a link, as in "a link connects two
nodes, a sender and a receiver."
Now as for the programming model, AMQP is really intentionally agnostic
on that subject since it's just a protocol. For JMS the only really well
supported programming model is for threads in the client library to
dispatch out to message listeners supplied by the application. For
example if the application wants to call into the library to get its
messages, then you really need to go around the API to configure
prefetch appropriately in order for this to work in a safe and practical
(or at least in a performant) way.
As for the new APIs, while the basic concepts are quite analogous to JMS:
MessageProducer.send(...) vs Sender.send()
MessageConsumer.receive(...) vs Receiver.fetch(...)
They provide additional features intended to support a wider variety of
programming models, such as explicit control over blocking vs non
blocking behavior, access to asynchronous send/ack confirmation,
explicit control over prefetch and flow control, etc. Additionally there
are a few choices made for consistency and simplicity, e.g. rather than
having a separate API for queue browsers like JMS does, you simply use a
non destructive receiver.
The upshot is you can sort of look at these as providing a JMS-like API
plus some critically missing bits minus some extra cruft.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org