You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Colin Crist <co...@hermesjms.com> on 2006/09/13 23:15:08 UTC
QPID/HermesJMS
Great to see a Wiki. I've (very) quickly put this together:
http://wiki.apache.org/qpid/HermesJMS
Now, its very draft and needs more detail so comments welcome, I'll also do
a flash tutorial as per other providers but in the meantime anyone got any
comments?
Regards,
Colin.
http://hermesjms.com <http://hermesjms.com/>
Re: QPID/HermesJMS
Posted by Rob Davies <ra...@gmail.com>.
You can always create your own ServerSessionPool with a
ConnectionConsumer in JMS to get control over session level
dispatching with any JMS provider - there's usually a standard way to
do most things you need using the vanilla JMS API.
cheers,
Rob
On 20 Sep 2006, at 17:44, Colin Crist wrote:
>
> James,
>
> Yeah, I'm sure it would be straightforward for a good JMS provider to
> support.
>
> My original point was just about how the JMS spec has some
> limitations and
> threading is one of them. Control is the thing here, in high
> performant apps
> I really want complete control over threading - I want to create
> dispatch
> threads, not the provider, and choose which threads handle which
> subscriptions from which transports. In fact I want total control
> over all
> the components I build systems with, not an unreasonable
> requirement I'm
> sure we'd all agree.
>
> JMS has implicit threading in its model, I just don't believe this
> is a good
> thing for everyone all the time.
>
> Regards,
>
> Colin.
> http://hermesjms.com
>
>
>
>
>> -----Original Message-----
>> From: James Strachan [mailto:james.strachan@gmail.com]
>> Sent: 20 September 2006 17:13
>> To: qpid-dev@incubator.apache.org
>> Subject: Re: QPID/HermesJMS
>>
>> On 9/19/06, Colin Crist <co...@hermesjms.com> wrote:
>>>>> One commonly cited one is threading, if anyone has used RV for
>>>>> example, its model of having dispatch queues (not to be
>>>> confused with
>>>>> transport queues) onto which messages are placed by
>> listeners (i.e.
>>>>> subscriptions) totally decouples the subscription from
>> the final
>>>>> message callback. This model is very flexible letting
>> you dispatch
>>>>> messages from timers as well as transports.
>>>>
>>>> I don't quite follow. Whats to stop a JMS provider dispatching
>>>> messages from N transports and M timers to a single JMS
>> session and
>>>> using a single thread or a thread pool to execute the
>>>> MessageListener's on the consumers?
>>>
>>> Nothing, but its not in the spec so there are no
>> implementations (that
>>> I know of) that let you.
>>
>> FWIW it would be trivial to write a little timer Transport
>> implementation for ActiveMQ which could act as a filter to
>> any other transport but fire timer events to consumers
>> whenever it wished to do just what you need etc.
>>
>>
>> --
>>
>> James
>> -------
>> http://radio.weblogs.com/0112098/
>>
>>
>>
>
>
RE: QPID/HermesJMS
Posted by Colin Crist <co...@hermesjms.com>.
James,
Yeah, I'm sure it would be straightforward for a good JMS provider to
support.
My original point was just about how the JMS spec has some limitations and
threading is one of them. Control is the thing here, in high performant apps
I really want complete control over threading - I want to create dispatch
threads, not the provider, and choose which threads handle which
subscriptions from which transports. In fact I want total control over all
the components I build systems with, not an unreasonable requirement I'm
sure we'd all agree.
JMS has implicit threading in its model, I just don't believe this is a good
thing for everyone all the time.
Regards,
Colin.
http://hermesjms.com
> -----Original Message-----
> From: James Strachan [mailto:james.strachan@gmail.com]
> Sent: 20 September 2006 17:13
> To: qpid-dev@incubator.apache.org
> Subject: Re: QPID/HermesJMS
>
> On 9/19/06, Colin Crist <co...@hermesjms.com> wrote:
> > > > One commonly cited one is threading, if anyone has used RV for
> > > > example, its model of having dispatch queues (not to be
> > > confused with
> > > > transport queues) onto which messages are placed by
> listeners (i.e.
> > > > subscriptions) totally decouples the subscription from
> the final
> > > > message callback. This model is very flexible letting
> you dispatch
> > > > messages from timers as well as transports.
> > >
> > > I don't quite follow. Whats to stop a JMS provider dispatching
> > > messages from N transports and M timers to a single JMS
> session and
> > > using a single thread or a thread pool to execute the
> > > MessageListener's on the consumers?
> >
> > Nothing, but its not in the spec so there are no
> implementations (that
> > I know of) that let you.
>
> FWIW it would be trivial to write a little timer Transport
> implementation for ActiveMQ which could act as a filter to
> any other transport but fire timer events to consumers
> whenever it wished to do just what you need etc.
>
>
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
>
>
Re: QPID/HermesJMS
Posted by James Strachan <ja...@gmail.com>.
On 9/19/06, Colin Crist <co...@hermesjms.com> wrote:
> > > One commonly cited one is threading, if anyone has used RV for
> > > example, its model of having dispatch queues (not to be
> > confused with
> > > transport queues) onto which messages are placed by listeners (i.e.
> > > subscriptions) totally decouples the subscription from the final
> > > message callback. This model is very flexible letting you dispatch
> > > messages from timers as well as transports.
> >
> > I don't quite follow. Whats to stop a JMS provider
> > dispatching messages from N transports and M timers to a
> > single JMS session and using a single thread or a thread pool
> > to execute the MessageListener's on the consumers?
>
> Nothing, but its not in the spec so there are no implementations (that I
> know of) that let you.
FWIW it would be trivial to write a little timer Transport
implementation for ActiveMQ which could act as a filter to any other
transport but fire timer events to consumers whenever it wished to do
just what you need etc.
--
James
-------
http://radio.weblogs.com/0112098/
RE: QPID/HermesJMS
Posted by Colin Crist <co...@hermesjms.com>.
> >
> > One commonly cited one is threading, if anyone has used RV for
> > example, its model of having dispatch queues (not to be
> confused with
> > transport queues) onto which messages are placed by listeners (i.e.
> > subscriptions) totally decouples the subscription from the final
> > message callback. This model is very flexible letting you dispatch
> > messages from timers as well as transports.
>
> I don't quite follow. Whats to stop a JMS provider
> dispatching messages from N transports and M timers to a
> single JMS session and using a single thread or a thread pool
> to execute the MessageListener's on the consumers?
>
Nothing, but its not in the spec so there are no implementations (that I
know of) that let you.
Colin.
http://hermesjms.com
Re: QPID/HermesJMS
Posted by James Strachan <ja...@gmail.com>.
On 9/15/06, Colin Crist <co...@hermesjms.com> wrote:
>
> One benefit of having a more AMQP friendly API that the JMS layer uses is
> that you can avoid being bound into some of the shortcomings JMS imposes.
>
> One commonly cited one is threading, if anyone has used RV for example, its
> model of having dispatch queues (not to be confused with transport queues)
> onto which messages are placed by listeners (i.e. subscriptions) totally
> decouples the subscription from the final message callback. This model is
> very flexible letting you dispatch messages from timers as well as
> transports.
I don't quite follow. Whats to stop a JMS provider dispatching
messages from N transports and M timers to a single JMS session and
using a single thread or a thread pool to execute the
MessageListener's on the consumers?
--
James
-------
http://radio.weblogs.com/0112098/
RE: QPID/HermesJMS
Posted by Colin Crist <co...@hermesjms.com>.
> > I'd say it's lower level than JMS as the threading and
> dispatching is
> > handled within a JMS provider.
>
> What I meant was that handling messages from different
> sources should be unified at a higher level than the
> messaging middleware transport.
Not sure I agree as I don't believe you get this in a good way from JMS but
no worries.
> > I guess in my ideal provider I'd see:
> >
> > 1. A clean simple JMS implementation.
>
> What do you mean by "clean" and "simple" in this case? Do you
> mean not providing any functionality beyond that described by
> the Sun JMS specification.
I really just mean one that works out of the box without any strange
configuration options or knowledge of AMQP needed to get going. One that
works in an a standalone app, J2EE container and can interop with non-JMS
AMQP clients.
> > I've seen several mails on the merits of a public AMPQ API
> on top of
> > which a JMS API is layered. One benefit of this I've not seen
> > mentioned is that it localises the mapping between AMPQ and
> JMS semantics in one place, e.g.
> > concepts of queues, topics and messages. This could be a real
> > maintenance benefit as well as making the codebase clearer.
>
> I think that the issue of codebase structure is separate from APIs.
> Publishing APIs means supporting and documenting ways of
> writing applications using our software. Making our software
> maintainable is extremely important but can be done without
> creating additional APIs that we encourage people to code against.
My point here is localising the semantic gap between AMPQ and JMS and
keeping this in one layer rather than unnecesarily complicating many
codepaths in your provider. You'll mostly likely have a layer to do this
anyway, you may as well specify the AMPQ layer - even if only internally to
start with as, at least in my view, it helps the quality and maintainability
of the end product.
I've been involved in the mapping of a couple of messaging products to JMS
(TIBCO RV and WebMethods Enterprise - hugely different products) and it can
be a bit fiddly, hence my feeling that the semantic gap is good to bridge
clearly and in a well defined place. FWIW, RV was good but WebMethods did
not work at all at the time. I know you'll ask why so if you're in London
soon we can have a beer and can write something up!
Regards,
Colin.
Re: QPID/HermesJMS
Posted by Robert Greig <ro...@gmail.com>.
> > We could add some feature like this to our extended JMS API
> > although as you mention I am not sure how acknowledge modes
> > and transactions would fit with this. It appears to be
> > slightly higher level than JMS?
>
> I'd say it's lower level than JMS as the threading and dispatching is
> handled within a JMS provider.
What I meant was that handling messages from different sources should
be unified at a higher level than the messaging middleware transport.
> > We have extended the JMS message model. In AMQP, the message
> OK, cool. Would this be portable to other AMQP server side implementations?
Yes, it should be. It's certainly not rocket science.
> I guess in my ideal provider I'd see:
>
> 1. A clean simple JMS implementation.
What do you mean by "clean" and "simple" in this case? Do you mean not
providing any functionality beyond that described by the Sun JMS
specification.
> I've seen several mails on the merits of a public AMPQ API on top of which a
> JMS API is layered. One benefit of this I've not seen mentioned is that it
> localises the mapping between AMPQ and JMS semantics in one place, e.g.
> concepts of queues, topics and messages. This could be a real maintenance
> benefit as well as making the codebase clearer.
I think that the issue of codebase structure is separate from APIs.
Publishing APIs means supporting and documenting ways of writing
applications using our software. Making our software maintainable is
extremely important but can be done without creating additional APIs
that we encourage people to code against.
RG
Re: QPID/HermesJMS
Posted by Robert Greig <ro...@gmail.com>.
On 15/09/06, Rajith Attapattu <ra...@gmail.com> wrote:
> >
> [RA] As AMQP evolves we *may* have functionality in AMQP that cannot be
> trivially expressed using a JMS client.
> So to make the full use of it we may need an AMQP API.
>
> I really don't see what harm it would cause if we have a seperate AMQP API?
> (other than the confusing factor which I dont' buy)
> Clear documentation is all we need to get rid of the confusion this might
> cause.
The problem is that you a forcing people to make a choice if you have
different levels of functionality in each API.
Let's say someone writes an application using JMS (or migrates an
existing application from another JMS provider - a very common
scenario if the JPMC use cases we have seen so far are typical). That
works fine, so they develop the next version of their application and
want to use an AMQP-only feature (such as the immediate flag in the
current implementation).
Do we have to say to those users that they have to change all their
existing application to use our other API?
Using an extended JMS API would mean they only have to change some
imports and maybe alter some code but most of it would remain the
same.
> [RA] Not at all. I was saying that JMS might be too simple to make use of
> the full power of AMQP.
> Or rather JMS might not expose the full power of AMQP as expected.
Yes, JMS definitely does not allow you to expose the full power of
AMQP. As far as I am aware every JMS provider has their own
extensions.
> If what people need is just JMS then it's fine, but if they need to go more
> deep into the protocol level how are we going to cater to them??
We can extend the JMS API, as we have done currently.
> > Can you expand on this point? I don't know much about SCA.
>
> [RA] SCA - Service Component Architecture.
> Bindings define how the the invocations are mapped from there native format
> to that expected by the SCA runtime and the target component.
> For example the native format might be a JMS message , AMQP message, SOAP
> message, JSON RPC, RMI ..etc
>
> We are trying to provide a AMQP binding for SCA (there is already a JMS
> binding). So we need to utilise the full power of AMQP to differentiate it
> from the JMS binding. So having a AMQP client API is going to make things
> very easy.
OK, I understand now (roughly). I presume the JMS binding does not
allow any use of properietary extensions. In that case, why not create
an AMQP binding but make it a JMS-AMQP binding that can use our
"extended JMS" API. That might be easier anyway since you could use
some of the existing SCA/JMS code?
> [RA] Exactly, but why can't we have a clear seperation? Why can't we have a
> well defined AMQP client API and then implement JMS on top of it? Are there
> any technical reasons for not doing so?
> Can we achive a clear seperation?
I think the usage issues are a stronger argument than technical issue
but I am not sure whether a completely clean separation could be
achieved.
It certainly would not be *more* efficient, and there may be
requirements to "leak" implementation details from the AMQP layer to
the JMS layer which may be less elegant.
> [RA] Robert why an extended JMS API?
> Why not we have our own client API which is much more natural to implement
> than trying to shape it upto the JMS messaging model.
> Why can't we write a JMS adapter on top of the AMQP API.
An extended JMS API gives a clear "upgrade" path for users and reduces
the testing and documentation requirements (two APIs means two sets of
documentation and testing). By being seen to be fully behind JMS
rather than viewing it as a poor cousin of another API we give our
users confidence that we are fully behind JMS.
My vision for the future is that as AMQP becomes more widely
established and therefore that other messaging providers adopt it and
want to expose the functionality the protocol offers, that our
extensions get added to the JMS specification and API.
> Right now AMQP and JMS are mixed to gether and this much more confusing than
> having a clear seperation?
The intention was that people know only know JMS could use that API
quite happily without really having to know very much about AMQP, but
that as they became more familiar with AMQP they could use that
functionality.
Are there any specific aspects of the extended API that you think is confusing?
RG
Re: QPID/HermesJMS
Posted by Rajith Attapattu <ra...@gmail.com>.
Robert,
comments inline and appreciate your interest.
Regards,
Rajith
On 9/15/06, Robert Greig <ro...@gmail.com> wrote:
>
> > I totaly agree that JMS is "the messaging API" for Java.
> > However the goal of AMQP is not be another JMS implementation. We have a
> > much more ambitious goal. Don't we ???
>
> Yes, AMQP is not just "another JMS implementation". However I don't
> see how other goals of the project such as wide interoperability imply
> that we have two Java APIs.
[RA] As AMQP evolves we *may* have functionality in AMQP that cannot be
trivially expressed using a JMS client.
So to make the full use of it we may need an AMQP API.
I really don't see what harm it would cause if we have a seperate AMQP API?
(other than the confusing factor which I dont' buy)
Clear documentation is all we need to get rid of the confusion this might
cause.
> If somebody is interested in working with AMQP (without being bothered
> with
> > JMS, now I maybe too optimistic here ) then they should be able to do it
> > easily.
>
> Why would anyone be "bothered" with JMS? Are you arguing that JMS is
> too complex? I thought the problem was that JMS is too much of a
> common denominator and we want to expose more advanced functionality
> that AMQP supports?
[RA] Not at all. I was saying that JMS might be too simple to make use of
the full power of AMQP.
Or rather JMS might not expose the full power of AMQP as expected.
If what people need is just JMS then it's fine, but if they need to go more
deep into the protocol level how are we going to cater to them??
> Besdies we are pushing for a SCA/AMQP binding. There is also a SCA/JMS
> > binding. So where is differentiation factor if just only have a JMS
> client?
>
> Can you expand on this point? I don't know much about SCA.
[RA] SCA - Service Component Architecture.
Bindings define how the the invocations are mapped from there native format
to that expected by the SCA runtime and the target component.
For example the native format might be a JMS message , AMQP message, SOAP
message, JSON RPC, RMI ..etc
We are trying to provide a AMQP binding for SCA (there is already a JMS
binding). So we need to utilise the full power of AMQP to differentiate it
from the JMS binding. So having a AMQP client API is going to make things
very easy.
> I don't buy the argument that users are going to get confused. This is how
> I
> > would position it.
> >
> > AMQP is a messaging protocol, JMS is not, it's just and API. Since JMS
> is
> > "the messaging API" for java we have implemented JMS using AMQP. But
> that
> > doesn't mean that AMQP doesn't deserve to have a client API of it's own.
>
> We have gone well beyond JMS in our implementation. I don't think the
> question is whether we should not implement any functionality not
> defined in the JMS specification, but how we go about exposing that
> functionality.
[RA] Exactly, but why can't we have a clear seperation? Why can't we have a
well defined AMQP client API and then implement JMS on top of it? Are there
any technical reasons for not doing so?
Can we achive a clear seperation?
> Remember, AMQP is not just java, any language can implement it, so if
> there
> > is a c++ client that publish a message, we should have a java client
> that
> > can fully utilise the power of AMQP without being limited to JMS simply
> bcos
> > thats how we choose to expose it.
>
> I fully agree. As I said above, we should not limit ourselves to JMS.
>
> My question for you is: what functionality do you think we cannot
> expose over an "extended JMS" API?
[RA] Robert why an extended JMS API?
Why not we have our own client API which is much more natural to implement
than trying to shape it upto the JMS messaging model.
Why can't we write a JMS adapter on top of the AMQP API.
Right now AMQP and JMS are mixed to gether and this much more confusing than
having a clear seperation?
Do u see any technical barriers as to why we can't have that kind of clear
seperation?
RG
>
Re: QPID/HermesJMS
Posted by Robert Greig <ro...@gmail.com>.
> I totaly agree that JMS is "the messaging API" for Java.
> However the goal of AMQP is not be another JMS implementation. We have a
> much more ambitious goal. Don't we ???
Yes, AMQP is not just "another JMS implementation". However I don't
see how other goals of the project such as wide interoperability imply
that we have two Java APIs.
> If somebody is interested in working with AMQP (without being bothered with
> JMS, now I maybe too optimistic here ) then they should be able to do it
> easily.
Why would anyone be "bothered" with JMS? Are you arguing that JMS is
too complex? I thought the problem was that JMS is too much of a
common denominator and we want to expose more advanced functionality
that AMQP supports?
> Besdies we are pushing for a SCA/AMQP binding. There is also a SCA/JMS
> binding. So where is differentiation factor if just only have a JMS client?
Can you expand on this point? I don't know much about SCA.
> I don't buy the argument that users are going to get confused. This is how I
> would position it.
>
> AMQP is a messaging protocol, JMS is not, it's just and API. Since JMS is
> "the messaging API" for java we have implemented JMS using AMQP. But that
> doesn't mean that AMQP doesn't deserve to have a client API of it's own.
We have gone well beyond JMS in our implementation. I don't think the
question is whether we should not implement any functionality not
defined in the JMS specification, but how we go about exposing that
functionality.
> Remember, AMQP is not just java, any language can implement it, so if there
> is a c++ client that publish a message, we should have a java client that
> can fully utilise the power of AMQP without being limited to JMS simply bcos
> thats how we choose to expose it.
I fully agree. As I said above, we should not limit ourselves to JMS.
My question for you is: what functionality do you think we cannot
expose over an "extended JMS" API?
RG
Re: QPID/HermesJMS
Posted by Rajith Attapattu <ra...@gmail.com>.
Hi All,
Here's my perspective (and motivation) behind the proposal.
I totaly agree that JMS is "the messaging API" for Java.
However the goal of AMQP is not be another JMS implementation. We have a
much more ambitious goal. Don't we ???
If somebody is interested in working with AMQP (without being bothered with
JMS, now I maybe too optimistic here ) then they should be able to do it
easily.
Besdies we are pushing for a SCA/AMQP binding. There is also a SCA/JMS
binding. So where is differentiation factor if just only have a JMS client?
I don't buy the argument that users are going to get confused. This is how I
would position it.
AMQP is a messaging protocol, JMS is not, it's just and API. Since JMS is
"the messaging API" for java we have implemented JMS using AMQP. But that
doesn't mean that AMQP doesn't deserve to have a client API of it's own.
Remember, AMQP is not just java, any language can implement it, so if there
is a c++ client that publish a message, we should have a java client that
can fully utilise the power of AMQP without being limited to JMS simply bcos
thats how we choose to expose it.
I think AMQP fully deserves to have it's own client API. It's a protocol on
it's own right and it shoudn't live under the JMS banner. JMS is one way of
using it, not just the only way.
Comments are most welcomed.
Regards,
Rajith
On 9/15/06, Robert Greig <ro...@gmail.com> wrote:
>
> On 15/09/06, Colin Crist <co...@hermesjms.com> wrote:
> >
> > One benefit of having a more AMQP friendly API that the JMS layer uses
> is
> > that you can avoid being bound into some of the shortcomings JMS
> imposes.
>
> I certainly agree with the view that JMS has shortcomings (and also
> things that are simply left up to implementations to define) but my
> general point is that I am not convinced we need to have a completely
> new API to address these issues. For the cases I have seen so far,
> extensions to the existing JMS concepts are reasonable ways of dealing
> with these issues.
>
> > One commonly cited one is threading, if anyone has used RV for example,
> its
> > model of having dispatch queues (not to be confused with transport
> queues)
> > onto which messages are placed by listeners (i.e. subscriptions) totally
> > decouples the subscription from the final message callback. This model
> is
> > very flexible letting you dispatch messages from timers as well as
> > transports. Its semantics would need some enhancements in a
> transactional
> > environment but it's a good example of where JMS ain't so great.
>
> I am not terribly familiar with RV at the API level. If I understand
> you correctly, RV provides a general message delivery API that can be
> used to deliver messages via the equivalent of a MessageConsumer even
> though those messages did not originate from the messaging transport?
>
> We could add some feature like this to our extended JMS API although
> as you mention I am not sure how acknowledge modes and transactions
> would fit with this. It appears to be slightly higher level than JMS?
>
> > In JMS a session has some similarity to a dispatch queue (its often got
> one
> > inside it) so I guess some of this flexibility could still be exposed if
> > there really was a queue underneath.
>
> Yes there is a dispatch queue in our implementation although the
> current implementation is quite tightly bound to our transport, for
> things like acknowledgements and transactions.
>
> > The JMS message model is also limiting, notably in its flat MapMessage
> but
> > you can work around this by either casing into a TreeMessage or exposing
> the
> > tree via an object in an ObjectMessage. I once worked on an RV JMS
> provider
> > at a bank and we put a pluggable marshalling layer to convert the RV
> message
> > to and from a JMS message, you'd certainly need to support this as there
> is
> > no guarantee your client code is talking to the QPID AMQ server and
> hence no
> > agreement on how the JMS message is mapped to and from the transport.
>
> We have extended the JMS message model. In AMQP, the message header
> contains mime type and encoding fields, and we allow the registration
> of mime type handlers (all the JMS message types are handled like this
> under the covers). If you want to introduce a TreeMessage you can just
> register some classes with the MessageFactoryRegistry, with some
> suitable mime type of your choosing.
>
> > I'm not convinced about a JMS Session also being a ManagementSession, it
> > feels more natural to me to mirror the JMS pattern in a
> > ManagementConnectionFactory/ManagementConnection/ManagementSession set
> of
> > interfaces separately - it could make the code simpler to manage and
> better
> > match the different security policies between regular messaging, broker
> > management and monitoring.
>
> I'm not sure what you are referring to? What is a ManagementSession?
>
> > Interesting converstation, hope you don't mind my $0.02..
>
> Absolutely, your feedback is very useful.
>
> RG
>
RE: QPID/HermesJMS
Posted by Colin Crist <co...@hermesjms.com>.
Hi,
> > One commonly cited one is threading, if anyone has used RV for
> > example, its model of having dispatch queues (not to be
> confused with
> > transport queues) onto which messages are placed by listeners (i.e.
> > subscriptions) totally decouples the subscription from the final
> > message callback. This model is very flexible letting you dispatch
> > messages from timers as well as transports. Its semantics
> would need
> > some enhancements in a transactional environment but it's a
> good example of where JMS ain't so great.
>
> I am not terribly familiar with RV at the API level. If I
> understand you correctly, RV provides a general message
> delivery API that can be used to deliver messages via the
> equivalent of a MessageConsumer even though those messages
> did not originate from the messaging transport?
You can push messages and timer events to the same dispatch queue, the
messages can come from more than one transport, i.e. in RV a multicast/port
combination. The point here is that the dispatch and threading is under your
own control where in JMS it is not.
> We could add some feature like this to our extended JMS API
> although as you mention I am not sure how acknowledge modes
> and transactions would fit with this. It appears to be
> slightly higher level than JMS?
I'd say it's lower level than JMS as the threading and dispatching is
handled within a JMS provider.
> > The JMS message model is also limiting, notably in its flat
> MapMessage
> > but you can work around this by either casing into a TreeMessage or
> > exposing the tree via an object in an ObjectMessage. I once
> worked on
> > an RV JMS provider at a bank and we put a pluggable
> marshalling layer
> > to convert the RV message to and from a JMS message, you'd
> certainly
> > need to support this as there is no guarantee your client code is
> > talking to the QPID AMQ server and hence no agreement on
> how the JMS message is mapped to and from the transport.
>
> We have extended the JMS message model. In AMQP, the message
> header contains mime type and encoding fields, and we allow
> the registration of mime type handlers (all the JMS message
> types are handled like this under the covers). If you want to
> introduce a TreeMessage you can just register some classes
> with the MessageFactoryRegistry, with some suitable mime type
> of your choosing.
OK, cool. Would this be portable to other AMQP server side implementations?
> > I'm not convinced about a JMS Session also being a
> ManagementSession,
> > it feels more natural to me to mirror the JMS pattern in a
> >
> ManagementConnectionFactory/ManagementConnection/ManagementSes
> sion set
> > of interfaces separately - it could make the code simpler to manage
> > and better match the different security policies between regular
> > messaging, broker management and monitoring.
>
> I'm not sure what you are referring to? What is a ManagementSession?
I should have made myself clearer - these ManagementXXX interfaces are made
up to highlight a difference in functionality between management/monitoring
and core messaging, many JMS providers give broker access via a quite
separate API (e.g. Tibco EMS has a TibjmsAdmin). Some provide JMX too.
I guess in my ideal provider I'd see:
1. A clean simple JMS implementation.
2. A more functional API that maps to semantics of the provider with
messaging and admin.
3. A JMX provider that reuses the transport via the admin API (this means
you end up delivering a JMS and a JMX provider...)
I've seen several mails on the merits of a public AMPQ API on top of which a
JMS API is layered. One benefit of this I've not seen mentioned is that it
localises the mapping between AMPQ and JMS semantics in one place, e.g.
concepts of queues, topics and messages. This could be a real maintenance
benefit as well as making the codebase clearer.
Regards,
Colin.
http://hermesjms.com
Re: QPID/HermesJMS
Posted by Robert Greig <ro...@gmail.com>.
On 15/09/06, Colin Crist <co...@hermesjms.com> wrote:
>
> One benefit of having a more AMQP friendly API that the JMS layer uses is
> that you can avoid being bound into some of the shortcomings JMS imposes.
I certainly agree with the view that JMS has shortcomings (and also
things that are simply left up to implementations to define) but my
general point is that I am not convinced we need to have a completely
new API to address these issues. For the cases I have seen so far,
extensions to the existing JMS concepts are reasonable ways of dealing
with these issues.
> One commonly cited one is threading, if anyone has used RV for example, its
> model of having dispatch queues (not to be confused with transport queues)
> onto which messages are placed by listeners (i.e. subscriptions) totally
> decouples the subscription from the final message callback. This model is
> very flexible letting you dispatch messages from timers as well as
> transports. Its semantics would need some enhancements in a transactional
> environment but it's a good example of where JMS ain't so great.
I am not terribly familiar with RV at the API level. If I understand
you correctly, RV provides a general message delivery API that can be
used to deliver messages via the equivalent of a MessageConsumer even
though those messages did not originate from the messaging transport?
We could add some feature like this to our extended JMS API although
as you mention I am not sure how acknowledge modes and transactions
would fit with this. It appears to be slightly higher level than JMS?
> In JMS a session has some similarity to a dispatch queue (its often got one
> inside it) so I guess some of this flexibility could still be exposed if
> there really was a queue underneath.
Yes there is a dispatch queue in our implementation although the
current implementation is quite tightly bound to our transport, for
things like acknowledgements and transactions.
> The JMS message model is also limiting, notably in its flat MapMessage but
> you can work around this by either casing into a TreeMessage or exposing the
> tree via an object in an ObjectMessage. I once worked on an RV JMS provider
> at a bank and we put a pluggable marshalling layer to convert the RV message
> to and from a JMS message, you'd certainly need to support this as there is
> no guarantee your client code is talking to the QPID AMQ server and hence no
> agreement on how the JMS message is mapped to and from the transport.
We have extended the JMS message model. In AMQP, the message header
contains mime type and encoding fields, and we allow the registration
of mime type handlers (all the JMS message types are handled like this
under the covers). If you want to introduce a TreeMessage you can just
register some classes with the MessageFactoryRegistry, with some
suitable mime type of your choosing.
> I'm not convinced about a JMS Session also being a ManagementSession, it
> feels more natural to me to mirror the JMS pattern in a
> ManagementConnectionFactory/ManagementConnection/ManagementSession set of
> interfaces separately - it could make the code simpler to manage and better
> match the different security policies between regular messaging, broker
> management and monitoring.
I'm not sure what you are referring to? What is a ManagementSession?
> Interesting converstation, hope you don't mind my $0.02..
Absolutely, your feedback is very useful.
RG
RE: QPID/HermesJMS
Posted by st...@jpmorgan.com.
Hi Colin!
> One benefit of having a more AMQP friendly API that the JMS layer uses
is
> that you can avoid being bound into some of the shortcomings JMS
imposes.
>
> One commonly cited one is threading, if anyone has used RV for example,
its
> model of having dispatch queues (not to be confused with transport
queues)
> onto which messages are placed by listeners (i.e. subscriptions) totally
> decouples the subscription from the final message callback. This model
is
> very flexible letting you dispatch messages from timers as well as
> transports. Its semantics would need some enhancements in a
transactional
> environment but it's a good example of where JMS ain't so great.
I've not heard about the threading problems of JMS. I wonder is that often
cited in the Tibco/RV world?
The application programming model you are describing that you use with RV
sounds
like that used in Erlang to some degree (which has roots in Carl Hewitt's
Actors).
http://tunes.org/wiki/Actor
Recently this programming model has become available on the Java platform
via the Scala programming language. Really interesting stuff:
http://lambda-the-ultimate.org/node/1615
> The JMS message model is also limiting, notably in its flat MapMessage
but
> you can work around this by either casing into a TreeMessage or exposing
the
> tree via an object in an ObjectMessage. I once worked on an RV JMS
provider
> at a bank and we put a pluggable marshalling layer to convert the RV
message
> to and from a JMS message, you'd certainly need to support this as there
is
> no guarantee your client code is talking to the QPID AMQ server and
hence no
> agreement on how the JMS message is mapped to and from the transport.
What to you mean by casing into a TreeMessage? What is a TreeMessage?
Is that a Tibco extension?
It sounds like you are referring to a feature added to activemq in release
4.1
http://www.activemq.org/site/structured-message-properties-and-mapmessages.html
This is likely inspired by AMQP as a FieldTable allows for nested maps.
Having a
list/array type is a nice addition. The AMQP working group ought to
consider lists/arrays
as a type when the field-table types are reviewed soon. It would be
possible to use
a FieldTable as a message body. This would reuse the encoding/decoding
already
present for a FieldTable.
In a past life I worked on a telecoms rating/billing system that used only
IIRC
int, long, float, double, list and map as types in it's "service" layer.
Services could be implemented
in C, C++, Java or a proprietary scripting language. It was surprising to
see what could
be done with on such a humble base.
> I'm not convinced about a JMS Session also being a ManagementSession, it
> feels more natural to me to mirror the JMS pattern in a
> ManagementConnectionFactory/ManagementConnection/ManagementSession set
of
> interfaces separately - it could make the code simpler to manage and
better
> match the different security policies between regular messaging, broker
> management and monitoring.
I think Robert has already asked what a ManagementSession is. Is it
another RV extension?
> hope you don't mind my $0.02..
Not at all. I think it's great to hear about other messaging products. I
am not familiar with RV.
I think it would be great to do a survey of messaging products out there
and see how
Qpid and AMQP compare.
Steve.
This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates.
This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
RE: QPID/HermesJMS
Posted by Colin Crist <co...@hermesjms.com>.
One benefit of having a more AMQP friendly API that the JMS layer uses is
that you can avoid being bound into some of the shortcomings JMS imposes.
One commonly cited one is threading, if anyone has used RV for example, its
model of having dispatch queues (not to be confused with transport queues)
onto which messages are placed by listeners (i.e. subscriptions) totally
decouples the subscription from the final message callback. This model is
very flexible letting you dispatch messages from timers as well as
transports. Its semantics would need some enhancements in a transactional
environment but it's a good example of where JMS ain't so great.
In JMS a session has some similarity to a dispatch queue (its often got one
inside it) so I guess some of this flexibility could still be exposed if
there really was a queue underneath.
The JMS message model is also limiting, notably in its flat MapMessage but
you can work around this by either casing into a TreeMessage or exposing the
tree via an object in an ObjectMessage. I once worked on an RV JMS provider
at a bank and we put a pluggable marshalling layer to convert the RV message
to and from a JMS message, you'd certainly need to support this as there is
no guarantee your client code is talking to the QPID AMQ server and hence no
agreement on how the JMS message is mapped to and from the transport.
I'm not convinced about a JMS Session also being a ManagementSession, it
feels more natural to me to mirror the JMS pattern in a
ManagementConnectionFactory/ManagementConnection/ManagementSession set of
interfaces separately - it could make the code simpler to manage and better
match the different security policies between regular messaging, broker
management and monitoring.
Interesting converstation, hope you don't mind my $0.02..
Regards,
Colin.
http:/hermesjms.com
-----Original Message-----
From: Robert Greig [mailto:robert.j.greig@gmail.com]
Sent: 15 September 2006 13:34
To: qpid-dev@incubator.apache.org
Subject: Re: QPID/HermesJMS
On 14/09/06, Rajith Attapattu <ra...@gmail.com> wrote:
> I am planning a refactoring of the java client to create an AMQP
> client API and then build the JMS layer on top of it.
> So people who are interested can directly access AMQP specific features.
The approach we had taken before was to have an "extended JMS" API that
exposed additional methods and potentially interfaces, e.g.
org.apache.qpid.jms.Session extends javax.jms.Session.
I would be interested to understand what kind of features you would like to
expose? Do you think the existing approach is not adequate for your needs,
i.e. do you want to create a completely un-JMS-like API?
My initial thought is that I don't like the general idea of have two APIs -
two is one too many unless there is a good functional or historical reason
for it. It asks users to make a choice they may not feel comfortable making
(are you saying to users that to get the "full power" of AMQP you need to
use our proprietary API?).
JMS is by its nature a compromise of an API, hence why we wanted to extend
it like most JMS implementations, and some AMQP concepts are relatively
tricky to map (the Destination concept in JMS being the most obvious
example). Maybe we can do better here, although I think that Martin's great
work on the URIs helps a lot in making it easier for the users.
In other languages, where there is no standard messaging API we have freedom
to create whatever API feels best for that language but for Java I believe
JMS will for the time being be the primary API. Maybe if AMQP takes off with
other messaging vendors we would be able to get some of our extensions added
to a future version of JMS.
> Since Robert seem to be back I am going to talk with him and settle on
> the direction.
I'm still just checking mail sporadically but will be back full time from
Monday.
RG
Re: QPID/HermesJMS
Posted by Robert Greig <ro...@gmail.com>.
On 18/09/06, Gordon Sim <gs...@redhat.com> wrote:
> Steven Shaw wrote:
> > On 15/09/06, Robert Greig <ro...@gmail.com> wrote:
> >> I think we agree that we need to expose functionality that goes beyond
> >> JMS. The question is whether we can do this though extension points to
> >> JMS or whether we need a separate API.
> >
> > Perhaps both.
>
> Support at the 'protocol' level makes it easier for the full flexibility
> of AMQP to be exploited in perhaps unanticipated ways.
I can see the utility of providing a way of accessing the protocol at
the lowest level, i.e. sending and receiving protocol frames. I
thought (perhaps incorrectly?) that what was being put forward was an
alternative API that duplicated some functionality already possible
via JMS.
> As an example, pulled out the air, imagine a particular use case wants
> to set up a single queue with several bindings. Rather that trying to
> anticipate all these sorts of usage patterns from the start a more
> directly exposed protocol layer would make these easy to compose from
> the protocols own building blocks.
Yes, the impossibility of pre-empting every possible use case is a
very fair point. However once a use case is established, adding it
into "extended JMS" would seem feasible to me. (i.e. we have a
protocol level API but only "extended JMS" as the higher level API for
general application developer use).
Is that what you were thinking of?
RG
Re: QPID/HermesJMS
Posted by Robert Greig <ro...@gmail.com>.
> Two more use cases
> --------------------------------
> I want to do a SCA/AMQP Binding for Tuscany and I would want to leverage the
> protocol artifacts using a more intutive API and not JMS or an extended JMS.
> There is also a JMS binding and if use the same interface then were is the
> differentiation factor?
The differentiation would be that there is an "extended JMS" API for
AMQ. So that API does not duplicate existing JMS concepts but adds
AMQP concepts to it - for example, the immediate flag.
> I also want to use AMQP as a protocol for Axis2. Now I really haven't though
> about this, but some of the unique features that AMQP offers maybe useful if
> they can be accessed using a more natural API than through JMS.
The idea is not that you would be limited to JMS "lowest common
denominator" functionality but that you could exploit AMQP where
appropriate but via the extra methods and classes exposed in
conjunction with JMS.
Or do you actually want to work at the protocol level? If so, we need
to understand why the JMS API is deficient.
RG
Re: QPID/HermesJMS
Posted by Rajith Attapattu <ra...@gmail.com>.
small correction
I am definitely not saying that JMS is the majority of the use cases
should be changed as
I am definitely not saying that JMS is *not* the majority of the use cases
-Rajith
On 9/18/06, Rajith Attapattu <ra...@gmail.com> wrote:
>
> +1 to Gordons comments.
>
> We definitely need as API that reflects the protocol more easily for
> people who need that kind of functionality.
>
> Two more use cases
> --------------------------------
> I want to do a SCA/AMQP Binding for Tuscany and I would want to leverage
> the protocol artifacts using a more intutive API and not JMS or an extended
> JMS. There is also a JMS binding and if use the same interface then were is
> the differentiation factor?
>
> I also want to use AMQP as a protocol for Axis2. Now I really haven't
> though about this, but some of the unique features that AMQP offers maybe
> useful if they can be accessed using a more natural API than through JMS.
>
> I am definitely not saying that JMS is the majority of the use cases. What
> I want is that we cater to the use cases where people need to deal with the
> protocol directly. If somebody has a need for that, then they will jolly
> well make it their business to learn the API :-)
>
> Regards,
>
> Rajith
>
>
> On 9/18/06, Gordon Sim <gs...@redhat.com> wrote:
> >
> > Alan Conway wrote:
> > > It seems to me that regardless what happens there *will* be a JMS API
> > > and there *will* be a Qpid API. The JMS layer has to call on
> > something!
> >
> > Currently there is no accessible AMQP API as I understand that term.
> >
> > > The question is whether there is real value in documenting multiple
> > > ways for users to do the same thing in Qpid. I don't know the answer,
> > > but I'd like to see some concrete examples of where people feel the
> > JMS
> > > API is inadequate,
> >
> > How about setting up a single queue with several bindings?
> >
> > > inefficient or just repulsive, and how we could do
> > > such a better job in Qpid that people would find it worth their while
> > to
> > > learn a new API and write code they'll never be able to port to
> > another
> > > JMS implementation. I'm not saying it can't be the case! I'm just
> > > curious about the innovations people have in mind for Qpid's API.
> >
> > Those innovations may come from other people and having the basics of
> > the protocol directly available makes it possible for them to do that.
> > We don't have to anticipate every innovation.
> >
> > The point of the AMQP API is not that it is more efficient or less
> > repulsive but that it more directly reflects the protocol. JMS has its
> > model, which will be what the majority will be familiar with and use.
> > AMQP has its own model so why not have an API that reflects that model
> > more naturally?
> >
>
>
Re: QPID/HermesJMS
Posted by Gordon Sim <gs...@redhat.com>.
Rajith Attapattu wrote:
> I want to do a SCA/AMQP Binding for Tuscany and I would want to leverage
> the
> protocol artifacts using a more intutive API and not JMS or an extended
> JMS.
> There is also a JMS binding and if use the same interface then were is the
> differentiation factor?
I don't know enough about the details of how a binding for SCA would be
specified, but a key aspect of an AMQP binding (as opposed to a JMS one)
is its support for different languages.
As I understand it SCA is primarily focused on Java and C++. Do you
think other languages will be supported (or are they already?).
Re: QPID/HermesJMS
Posted by Rajith Attapattu <ra...@gmail.com>.
+1 to Gordons comments.
We definitely need as API that reflects the protocol more easily for people
who need that kind of functionality.
Two more use cases
--------------------------------
I want to do a SCA/AMQP Binding for Tuscany and I would want to leverage the
protocol artifacts using a more intutive API and not JMS or an extended JMS.
There is also a JMS binding and if use the same interface then were is the
differentiation factor?
I also want to use AMQP as a protocol for Axis2. Now I really haven't though
about this, but some of the unique features that AMQP offers maybe useful if
they can be accessed using a more natural API than through JMS.
I am definitely not saying that JMS is the majority of the use cases. What I
want is that we cater to the use cases where people need to deal with the
protocol directly. If somebody has a need for that, then they will jolly
well make it their business to learn the API :-)
Regards,
Rajith
On 9/18/06, Gordon Sim <gs...@redhat.com> wrote:
>
> Alan Conway wrote:
> > It seems to me that regardless what happens there *will* be a JMS API
> > and there *will* be a Qpid API. The JMS layer has to call on something!
>
> Currently there is no accessible AMQP API as I understand that term.
>
> > The question is whether there is real value in documenting multiple
> > ways for users to do the same thing in Qpid. I don't know the answer,
> > but I'd like to see some concrete examples of where people feel the JMS
> > API is inadequate,
>
> How about setting up a single queue with several bindings?
>
> > inefficient or just repulsive, and how we could do
> > such a better job in Qpid that people would find it worth their while to
> > learn a new API and write code they'll never be able to port to another
> > JMS implementation. I'm not saying it can't be the case! I'm just
> > curious about the innovations people have in mind for Qpid's API.
>
> Those innovations may come from other people and having the basics of
> the protocol directly available makes it possible for them to do that.
> We don't have to anticipate every innovation.
>
> The point of the AMQP API is not that it is more efficient or less
> repulsive but that it more directly reflects the protocol. JMS has its
> model, which will be what the majority will be familiar with and use.
> AMQP has its own model so why not have an API that reflects that model
> more naturally?
>
Re: QPID/HermesJMS
Posted by Robert Greig <ro...@gmail.com>.
On 18/09/06, Alan Conway <ac...@redhat.com> wrote:
> There's no doubt that Qpid for java will include JMS + Qpid specific
> stuff because qpid has features that JMS doesn't. The principal point of
> debate is: will the qpid specific stuff provide alternative ways to do
> what JMS does already, or not?
This is what I thought that Rajith was implying, i.e. the "Qpid API"
would offer alternative high-level ways of doing what was possible in
the "extended JMS API".
However, I may have got that wrong since from reading Gordon's
comments I think what is being proposed is an alternative
protocol-level API.
Is that accurate?
RG
Re: QPID/HermesJMS
Posted by Gordon Sim <gs...@redhat.com>.
Alan Conway wrote:
> On Mon, 2006-09-18 at 16:39 +0100, Gordon Sim wrote:
>> The point of the AMQP API is not that it is more efficient or less
>> repulsive but that it more directly reflects the protocol. JMS has its
>> model, which will be what the majority will be familiar with and use.
>> AMQP has its own model so why not have an API that reflects that model
>> more naturally?
>
> I don't see "reflecting the protocol" as a goal for an API. I see
> "making it easy for users to what they want" as the main goal.
Agreed, but if what they want to do is use the protocol, then the API
should allow them to do that without forcing them to learn how that API
is mapped to the protocol concepts, it should be obvious.
Re: QPID/HermesJMS
Posted by Alan Conway <ac...@redhat.com>.
On Mon, 2006-09-18 at 16:39 +0100, Gordon Sim wrote:
> The point of the AMQP API is not that it is more efficient or less
> repulsive but that it more directly reflects the protocol. JMS has its
> model, which will be what the majority will be familiar with and use.
> AMQP has its own model so why not have an API that reflects that model
> more naturally?
I don't see "reflecting the protocol" as a goal for an API. I see
"making it easy for users to what they want" as the main goal.
There's no doubt that Qpid for java will include JMS + Qpid specific
stuff because qpid has features that JMS doesn't. The principal point of
debate is: will the qpid specific stuff provide alternative ways to do
what JMS does already, or not?
I'm not saying it shouldn't. I'm asking: Why should it? What would be
different and better (for the user) about a native Qpid equivalent of
JMS? I have some experience with the cost of testing, maintaining and
supporting duplicate APIs, I'm trying to understand what is the benefit
that outweighs it.
Cheers,
Alan.
Re: QPID/HermesJMS
Posted by Gordon Sim <gs...@redhat.com>.
Alan Conway wrote:
> It seems to me that regardless what happens there *will* be a JMS API
> and there *will* be a Qpid API. The JMS layer has to call on something!
Currently there is no accessible AMQP API as I understand that term.
> The question is whether there is real value in documenting multiple
> ways for users to do the same thing in Qpid. I don't know the answer,
> but I'd like to see some concrete examples of where people feel the JMS
> API is inadequate,
How about setting up a single queue with several bindings?
> inefficient or just repulsive, and how we could do
> such a better job in Qpid that people would find it worth their while to
> learn a new API and write code they'll never be able to port to another
> JMS implementation. I'm not saying it can't be the case! I'm just
> curious about the innovations people have in mind for Qpid's API.
Those innovations may come from other people and having the basics of
the protocol directly available makes it possible for them to do that.
We don't have to anticipate every innovation.
The point of the AMQP API is not that it is more efficient or less
repulsive but that it more directly reflects the protocol. JMS has its
model, which will be what the majority will be familiar with and use.
AMQP has its own model so why not have an API that reflects that model
more naturally?
Re: QPID/HermesJMS
Posted by Alan Conway <ac...@redhat.com>.
It seems to me that regardless what happens there *will* be a JMS API
and there *will* be a Qpid API. The JMS layer has to call on something!
The question is whether there is real value in documenting multiple
ways for users to do the same thing in Qpid. I don't know the answer,
but I'd like to see some concrete examples of where people feel the JMS
API is inadequate, inefficient or just repulsive, and how we could do
such a better job in Qpid that people would find it worth their while to
learn a new API and write code they'll never be able to port to another
JMS implementation. I'm not saying it can't be the case! I'm just
curious about the innovations people have in mind for Qpid's API.
Cheers,
Alan.
On Mon, 2006-09-18 at 11:06 +0100, Gordon Sim wrote:
> Steven Shaw wrote:
> > On 15/09/06, Robert Greig <ro...@gmail.com> wrote:
> >> I think we agree that we need to expose functionality that goes beyond
> >> JMS. The question is whether we can do this though extension points to
> >> JMS or whether we need a separate API.
> >
> > Perhaps both.
>
> I agree with this view. The different ways of exposing functionality
> need not be mutually exclusive.
>
> Support at the 'protocol' level makes it easier for the full flexibility
> of AMQP to be exploited in perhaps unanticipated ways.
>
> As an example, pulled out the air, imagine a particular use case wants
> to set up a single queue with several bindings. Rather that trying to
> anticipate all these sorts of usage patterns from the start a more
> directly exposed protocol layer would make these easy to compose from
> the protocols own building blocks.
>
> However JMS is clearly the first choice for the vast majority of
> messaging based systems written in java, so allowing these system to
> exploit the protocol through API extensions or configurable semantics or
> mappings is also going to be important.
Re: QPID/HermesJMS
Posted by Gordon Sim <gs...@redhat.com>.
Steven Shaw wrote:
> On 15/09/06, Robert Greig <ro...@gmail.com> wrote:
>> I think we agree that we need to expose functionality that goes beyond
>> JMS. The question is whether we can do this though extension points to
>> JMS or whether we need a separate API.
>
> Perhaps both.
I agree with this view. The different ways of exposing functionality
need not be mutually exclusive.
Support at the 'protocol' level makes it easier for the full flexibility
of AMQP to be exploited in perhaps unanticipated ways.
As an example, pulled out the air, imagine a particular use case wants
to set up a single queue with several bindings. Rather that trying to
anticipate all these sorts of usage patterns from the start a more
directly exposed protocol layer would make these easy to compose from
the protocols own building blocks.
However JMS is clearly the first choice for the vast majority of
messaging based systems written in java, so allowing these system to
exploit the protocol through API extensions or configurable semantics or
mappings is also going to be important.
Re: QPID/HermesJMS
Posted by Steven Shaw <st...@gmail.com>.
On 15/09/06, Robert Greig <ro...@gmail.com> wrote:
> I'm just not convinced of that, at least I think I would need to see a
> detailed proposal to make that decision. I would also like to
> understand if it would have any impact on efficiency.
I'd rather see the code running on a branch if someone is prepared to do that.
> > This
> > AMQP-level API may be useful for direct use by other implementors (not
> > generally end-users) who are building adapters for other middleware
> > such as SCA or a middleware api adapter at JPMC that I am aware of.
>
> Why would it be more useful than an extended JMS API?
I guess if you extend the JMS extentions to cover all the gaps then it
will be the same usefulness. However, it may start to look like you
have an AMQP API sticking out in your extensions. These extensions may
only be used by a select few "middleware" developers (as opposed to
application developers). But this is all speculation!
What it comes down to for me is that I think it *could* be more
elegant to have a amqp api on which to build the jms client.
> Would we support it for end users and have to make guarantees about
> backward compatibility for it?
Maintenance is certainly a downside. I hope the OP is aware of the commitment :)
I don't think it would be necessary to guarantee backward
compatibility with the amqp api. I see as a layer to build the jms
client on, for experiments/tests and for direct middleware adapters.
It depends how much of a burden you want it to be.
Cheers,
Steve.
Re: QPID/HermesJMS
Posted by Robert Greig <ro...@gmail.com>.
> > For the latter case I have proposed and had agreement in principal to
> > add another method to the protocol to determine whether a given
> > routing key is routable by an exchange thereby allowing us to throw an
> > exception on creation of the producer.
>
> That's not sufficient as it may (for instance) be a temporary queue
> which gets auto deleted during the lifetime of the MessageProducer. In
> this case send() should starting throwing InvalidDestinationException
> - at least my my reading of the JMS API docs.
Ah yes, that's true. We could use an option to make the send
asynchronous, as I mentioned in the other case.
> > For the former case, we can block by default (which is nasty but
> > required for strict compliance) or provide an option allowing it to be
> > done asynchronously since I imagine some users will not want to take
> > the hit of the block. We should certainly discuss this issue
> > separately.
>
> We cannot block at the moment as there is no way in the protocol to do
> so.
Sorry I should have mentioned that we have discussed (and had
agreement in principle) for a version of the Send call that returns a
response. That was motivated by the use case where you are using
persistence but not transactions, and you need a response to know that
the broker has actually committed to message to a store.
It hasn't been implemented yet because we were waiting for some
resolution on the somewhat thorny nowait issue.
> Using transactions closes the channel on error and in any case
> doesn't seem to cover all use cases.
Yes, saying "use transactions" (which is what we used to say) is too
restricting.
> I just mean that it needn't be encoded in a JMS-compliant way. Perhaps
> with extensions to the field table types this problem may go away.
Ah ok I see what you mean.
> Don't misunderstand me, I absolutely think that JMS (an extended JMS)
> should be the primary API what we push. I just think that it could be
> elegant to have a AMQP API layer that the JMS layer uses.
I'm just not convinced of that, at least I think I would need to see a
detailed proposal to make that decision. I would also like to
understand if it would have any impact on efficiency.
> This
> AMQP-level API may be useful for direct use by other implementors (not
> generally end-users) who are building adapters for other middleware
> such as SCA or a middleware api adapter at JPMC that I am aware of.
Why would it be more useful than an extended JMS API?
> > I think we agree that we need to expose functionality that goes beyond
> > JMS. The question is whether we can do this though extension points to
> > JMS or whether we need a separate API.
>
> Perhaps both. Application developers use JMS in order to remain
> somewhat independant of the provider. For other uses that isn't a
> requirement.
Would we support it for end users and have to make guarantees about
backward compatibility for it?
RG
Re: QPID/HermesJMS
Posted by Steven Shaw <st...@gmail.com>.
On 15/09/06, Robert Greig <ro...@gmail.com> wrote:
> > Advantages:
> > * Clearer structure for the JMS client code.
>
> This may or may not be true. Depending on what we need to expose for
> JMS, there may not be as clean a separation between the layers as you
> might hope.
That's true. I think it's worth a look and see.
> > * Ability to write tests for the broker that are rendered impossible via
> > the JMS API.
> > I guess we are using the Python client API for that though. I took a
> > brief look
> > at the Python client a while ago and I think it's excellent btw!
>
> Yes, you can't work at the protocol level even with our extended JMS
> API. But I would argue if we need to work at the protocol level for
> test purposes we can do that in other ways (such as with the python
> client).
Yes, I mentioned the Python client for testing. It's not a strong
advantage however it could have come in handy last week (as when I
fixed a bug in the client code I was no longer able to reproduce the
bug in the broker).
> > * You can asynchronously send without having to worry about the send
> > semantics
> > in JMS. Specifically it appears that there is a need to block to
> > detect and throw
> > an InvalidDestinationException. In general you don't have to worry
> > about JMS
> > semantics which is nice.
>
> Is this for the case where you specify a Destination in the send call,
> as opposed to passing in the Destination when you create the producer?
Both.
> For the latter case I have proposed and had agreement in principal to
> add another method to the protocol to determine whether a given
> routing key is routable by an exchange thereby allowing us to throw an
> exception on creation of the producer.
That's not sufficient as it may (for instance) be a temporary queue
which gets auto deleted during the lifetime of the MessageProducer. In
this case send() should starting throwing InvalidDestinationException
- at least my my reading of the JMS API docs.
> For the former case, we can block by default (which is nasty but
> required for strict compliance) or provide an option allowing it to be
> done asynchronously since I imagine some users will not want to take
> the hit of the block. We should certainly discuss this issue
> separately.
We cannot block at the moment as there is no way in the protocol to do
so. Using transactions closes the channel on error and in any case
doesn't seem to cover all use cases. I wonder what other JMS providers
do. I looked at ActiveMQ pages and found they have an option to turn
on AsyncSend but there is no discussion of
InvalidDestinationException.
> > * You could directly supply headers as a field table.
>
> We support this already in the extended JMS API?
I just mean that it needn't be encoded in a JMS-compliant way. Perhaps
with extensions to the field table types this problem may go away.
> Yes, JMS suffers from being a lowest common denominator but it does
> have widespread adoption.
Don't misunderstand me, I absolutely think that JMS (an extended JMS)
should be the primary API what we push. I just think that it could be
elegant to have a AMQP API layer that the JMS layer uses. This
AMQP-level API may be useful for direct use by other implementors (not
generally end-users) who are building adapters for other middleware
such as SCA or a middleware api adapter at JPMC that I am aware of.
> I think we agree that we need to expose functionality that goes beyond
> JMS. The question is whether we can do this though extension points to
> JMS or whether we need a separate API.
Perhaps both. Application developers use JMS in order to remain
somewhat independant of the provider. For other uses that isn't a
requirement.
Steve.
Re: QPID/HermesJMS
Posted by Robert Greig <ro...@gmail.com>.
> Advantages:
> * Clearer structure for the JMS client code.
This may or may not be true. Depending on what we need to expose for
JMS, there may not be as clean a separation between the layers as you
might hope.
> * Ability to write tests for the broker that are rendered impossible via
> the JMS API.
> I guess we are using the Python client API for that though. I took a
> brief look
> at the Python client a while ago and I think it's excellent btw!
Yes, you can't work at the protocol level even with our extended JMS
API. But I would argue if we need to work at the protocol level for
test purposes we can do that in other ways (such as with the python
client).
> * You can asynchronously send without having to worry about the send
> semantics
> in JMS. Specifically it appears that there is a need to block to
> detect and throw
> an InvalidDestinationException. In general you don't have to worry
> about JMS
> semantics which is nice.
Is this for the case where you specify a Destination in the send call,
as opposed to passing in the Destination when you create the producer?
For the latter case I have proposed and had agreement in principal to
add another method to the protocol to determine whether a given
routing key is routable by an exchange thereby allowing us to throw an
exception on creation of the producer.
For the former case, we can block by default (which is nasty but
required for strict compliance) or provide an option allowing it to be
done asynchronously since I imagine some users will not want to take
the hit of the block. We should certainly discuss this issue
separately.
> * You can declare exchanges queues and bindings directly. Perhaps allowing
> things that are not available through JMS.
I think we should extend JMS to allow this; we already support an
admittedly limited form of dynamic declaration and binding.
> * You could directly supply headers as a field table.
We support this already in the extended JMS API?
> Disadvantages:
> * the perception problem of having two APIs from a user's point of view
> * maintenance could be a burden
> * now is probably not the time to do it.
I think if we were wanting to make any kind of "radical" change it is
better done sooner or later although I do take your point about
stability which is obviously extremely important given we have people
running this in production today.
We definitely need to get as much feedback as possible on whatever API
we use to expose more advanced features since changing APIs later on
always upsets users.
> The JMS API does surprisingly suck quite a bit as it's
> a lowest common denominator kind of
> API (but also for small things like JMSException's linkedException
> presumably because it was designed
> prior to Java 1.4). One odd thing about the JMS API is a number of setter
> methods on Message that should only
> be called by a JMS provider (like setJMSDestination). Unfortunately
> neither of the two gripes to the JMS API
> really call for an AMQP API, just some tweaks to JMS or, as is likely, a
> better understanding of the JMS requirements.
Yes, JMS suffers from being a lowest common denominator but it does
have widespread adoption.
I think we agree that we need to expose functionality that goes beyond
JMS. The question is whether we can do this though extension points to
JMS or whether we need a separate API.
RG
Re: QPID/HermesJMS
Posted by st...@jpmorgan.com.
> On 14/09/06, Rajith Attapattu <ra...@gmail.com> wrote:
> > I am planning a refactoring of the java client to create an AMQP
client API
> > and then build the JMS layer on top of it.
> > So people who are interested can directly access AMQP specific
features.
Hi Rajith,
I've been thinking the same thing myself lately.
I kinda like the idea of an AMQP API underneath the JMS API. This still
requires
JMS extensions for AMQP features not accessibly otherwise. However, it's
possible that
one of those extensions - immediate send - will be replaced with a new
mechanism
soon.
I wanted to start a list of pros and cons to address some of the things
that Robert was
talking about. I feel I haven't done a very good job but here it is:
Advantages:
* Clearer structure for the JMS client code.
* Ability to write tests for the broker that are rendered impossible via
the JMS API.
I guess we are using the Python client API for that though. I took a
brief look
at the Python client a while ago and I think it's excellent btw!
* You can asynchronously send without having to worry about the send
semantics
in JMS. Specifically it appears that there is a need to block to
detect and throw
an InvalidDestinationException. In general you don't have to worry
about JMS
semantics which is nice.
* You can declare exchanges queues and bindings directly. Perhaps allowing
things that are not available through JMS.
* You could directly supply headers as a field table.
* Perhaps later when the managment commands are available in the protocol,
you will
be able to do more command-and-control type of operations.
Disadvantages:
* the perception problem of having two APIs from a user's point of view
* maintenance could be a burden
* now is probably not the time to do it.
* stability
In order to get around the disadvantages of having 2 APIs to choose from,
we
should perhaps should not promote it as an alternative to the JMS API. It
could be useful for internal
use in testing etc. The JMS API does surprisingly suck quite a bit as it's
a lowest common denominator kind of
API (but also for small things like JMSException's linkedException
presumably because it was designed
prior to Java 1.4). One odd thing about the JMS API is a number of setter
methods on Message that should only
be called by a JMS provider (like setJMSDestination). Unfortunately
neither of the two gripes to the JMS API
really call for an AMQP API, just some tweaks to JMS or, as is likely, a
better understanding of the JMS requirements.
Hopefully work on JMS extensions and any future AMQP specific Java API
will feed into JMS specifications down the track.
For now I think it would be interesting to see an AMQP API - at least one
just the the JMS client to use. My biggest concern
is that this kind of refactoring is possibly an unstabilalising for the
current code base. However that concern can curbed by
using a branch for such a refactoring.
Cheers,
Steve.
This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates.
This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
Re: QPID/HermesJMS
Posted by Robert Greig <ro...@gmail.com>.
On 14/09/06, Rajith Attapattu <ra...@gmail.com> wrote:
> I am planning a refactoring of the java client to create an AMQP client API
> and then build the JMS layer on top of it.
> So people who are interested can directly access AMQP specific features.
The approach we had taken before was to have an "extended JMS" API
that exposed additional methods and potentially interfaces, e.g.
org.apache.qpid.jms.Session extends javax.jms.Session.
I would be interested to understand what kind of features you would
like to expose? Do you think the existing approach is not adequate for
your needs, i.e. do you want to create a completely un-JMS-like API?
My initial thought is that I don't like the general idea of have two
APIs - two is one too many unless there is a good functional or
historical reason for it. It asks users to make a choice they may not
feel comfortable making (are you saying to users that to get the "full
power" of AMQP you need to use our proprietary API?).
JMS is by its nature a compromise of an API, hence why we wanted to
extend it like most JMS implementations, and some AMQP concepts are
relatively tricky to map (the Destination concept in JMS being the
most obvious example). Maybe we can do better here, although I think
that Martin's great work on the URIs helps a lot in making it easier
for the users.
In other languages, where there is no standard messaging API we have
freedom to create whatever API feels best for that language but for
Java I believe JMS will for the time being be the primary API. Maybe
if AMQP takes off with other messaging vendors we would be able to get
some of our extensions added to a future version of JMS.
> Since Robert seem to be back I am going to talk with him and settle on the
> direction.
I'm still just checking mail sporadically but will be back full time
from Monday.
RG
Re: QPID/HermesJMS
Posted by Rajith Attapattu <ra...@gmail.com>.
Colin and Gordon,
I am planning a refactoring of the java client to create an AMQP client API
and then build the JMS layer on top of it.
So people who are interested can directly access AMQP specific features.
Since Robert seem to be back I am going to talk with him and settle on the
direction.
I hope to publish some details mid next week.
Regards,
Rajith
On 9/14/06, Gordon Sim <gs...@redhat.com> wrote:
>
> Colin Crist wrote:
> > Actually, one of the reasons for me looking into QPID and testing the
> JMS
> > side of things out with Hermes is with a view to supporting AMQP
> directly,
> > i.e. connecting to brokers, viewing exchanges and configuring them,
> > manipulating queues etc. There is quite a lot of code in Hermes that can
> be
> > reused after a little work to abstract away some of its JMS-ness.
>
> That would be very interesting!
>
> > How do you plan to support such AMQP functionality in a Java client? I
> see a
> > org.apache.qpid.management.jmx package but haven't had time to
> investigate
> > yet.
>
> There is some work planned on management (some being done already), but
> those involved can give more detail than me. Rajith is also thinking
> about how to expose the AMQP functionality through java, or have an AMQP
> layer that is accessible beneath the JMS layer.
>
Re: QPID/HermesJMS
Posted by Gordon Sim <gs...@redhat.com>.
Colin Crist wrote:
> Actually, one of the reasons for me looking into QPID and testing the JMS
> side of things out with Hermes is with a view to supporting AMQP directly,
> i.e. connecting to brokers, viewing exchanges and configuring them,
> manipulating queues etc. There is quite a lot of code in Hermes that can be
> reused after a little work to abstract away some of its JMS-ness.
That would be very interesting!
> How do you plan to support such AMQP functionality in a Java client? I see a
> org.apache.qpid.management.jmx package but haven't had time to investigate
> yet.
There is some work planned on management (some being done already), but
those involved can give more detail than me. Rajith is also thinking
about how to expose the AMQP functionality through java, or have an AMQP
layer that is accessible beneath the JMS layer.
RE: QPID/HermesJMS
Posted by Colin Crist <co...@hermesjms.com>.
There is a plugin but it's still focused on JMS things such as getting
depth, browsing messages waiting for a durable subcriber and so on.
Actually, one of the reasons for me looking into QPID and testing the JMS
side of things out with Hermes is with a view to supporting AMQP directly,
i.e. connecting to brokers, viewing exchanges and configuring them,
manipulating queues etc. There is quite a lot of code in Hermes that can be
reused after a little work to abstract away some of its JMS-ness.
How do you plan to support such AMQP functionality in a Java client? I see a
org.apache.qpid.management.jmx package but haven't had time to investigate
yet.
Colin.
http://hermesjms.com
-----Original Message-----
From: Gordon Sim [mailto:gsim@redhat.com]
Sent: 14 September 2006 09:03
To: qpid-dev@incubator.apache.org
Subject: Re: QPID/HermesJMS
Colin Crist wrote:
> http://wiki.apache.org/qpid/HermesJMS
>
> Now, its very draft and needs more detail so comments welcome, I'll
> also do a flash tutorial as per other providers but in the meantime
> anyone got any comments?
Looks good. Once we get jira set up we can add in the issues you raised
earlier and hopefully allow you to phase out any workarounds as we fix them.
I appreciate the focus for hermes is jms, but out of curiousity is there any
mechanism for exposing extensions or non-standard features? i.e.
could someone write a plugin of some sort to see exchanges and queues in the
amqp sense?
Re: QPID/HermesJMS
Posted by Gordon Sim <gs...@redhat.com>.
Colin Crist wrote:
> http://wiki.apache.org/qpid/HermesJMS
>
> Now, its very draft and needs more detail so comments welcome, I'll also do
> a flash tutorial as per other providers but in the meantime anyone got any
> comments?
Looks good. Once we get jira set up we can add in the issues you raised
earlier and hopefully allow you to phase out any workarounds as we fix them.
I appreciate the focus for hermes is jms, but out of curiousity is there
any mechanism for exposing extensions or non-standard features? i.e.
could someone write a plugin of some sort to see exchanges and queues in
the amqp sense?