You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Martin Ritchie <ma...@jpmorgan.com> on 2006/09/25 11:02:40 UTC
Qpid URL Formats [ was Re: A question for the ActiveMQ chaps on the list...]
We currently have a URI format that is in use in the Java implementation.
I have created a wiki page that describes this format.
http://wiki.apache.org/qpid/URLFormats
Comments and feedback would be great. If we can come to an agreement on the
format then we can suggest it to the AMQP WG as they do not currently have
a defined format. Such a format will be required for interoperability.
--
Martin
|---------+---------------------------->
| | "John O'Hara" |
| | <john.r.ohara@gma|
| | il.com> |
| | |
| | 2006-09-22 20:49 |
| | Please respond to|
| | qpid-dev |
|---------+---------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
| |
| To: qpid-dev@incubator.apache.org |
| cc: |
| Subject: Re: A question for the ActiveMQ chaps on the list... |
>------------------------------------------------------------------------------------------------------------------------------|
So basically we could use a URI which defines the exchanges, bindings and
queues.
A bit nasty, but there is something attractive about it in the same way
ODBC
connection strings undeniably work :-)
John
On 22/09/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
>
> On 9/22/06, Gordon Sim <gs...@redhat.com> wrote:
> > James Strachan wrote:
> > > On 9/22/06, John O'Hara <jo...@gmail.com> wrote:
> > >> When James spent some time with us back on the early early days of
> the
> > >> AMQP I got the impression that he held the view that you could plug
> the
> > >> command verbs onto ActiveMQ and it would just work.
> > >
> > > Assuming there is indeed a well defined mapping of AMQP commands to
> > > JMS/MQSeries semantics then yes it should.
> >
> > I think a well defined mapping of JMS semantics onto AMQP commands is
> > possible and desirable. I'm not as sure that there is a mapping of AMQP
> > commands onto JMS semantics.
> >
> > For example, in AMQP there is a bind command for attaching a queue to
an
> > exchange. What concept in JMS would this command be mapped onto?
> >
>
> All the binding information can be contained in the destination name.
>
> > I'm certainly not saying that a given JMS broker could not be made to
> > support AMQP. Individual implementations may well have the necessary
> > concepts in which to express AMQP semantics, but as far as I can JMS as
> > a specification does not so I'm not clear how a generic mapping would
be
> > specified.
> >
> >
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
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 URL Formats [ was Re: A question for the ActiveMQ chaps on the list...]
Posted by John O'Hara <jo...@gmail.com>.
If AMQP should be thee answer to users; they shouldn't have to think "in VM
or TCP". Much like HTTP, the only option is encrypted or not.
As I said, I accept it can be useful for testing, but I really don't want to
water down the message of "one standard".
The same goes for transport bindings, as raised on the protocol discussion
list. We should architect and prove it can be done (say to bind to SCTP),
but lets not confuse prospective users.
We're selling simplicity -- if thats possible!
John
On 27/09/06, Robert Greig <ro...@gmail.com> wrote:
>
> On 27/09/06, John O'Hara <jo...@gmail.com> wrote:
> > For testing I understand.
> > But what are we testing at that point?
>
> It is extremely useful to be able to test without the latency
> introduced by the network. We have found a number of timing-related
> bugs this way. It is also useful to know that the higher layers in the
> broker and client are not intimately bound to TCP/IP.
>
> > You should be able to run one test harness against both the C++ and Java
> > servers... that would be real leverage; and that would use IP.
>
> Of course and nobody is suggesting that we should not be able to do this.
>
> > I think popping out the notion of a VM transport sends a bad message to
> > prospective users.
>
> I don't follow. What bad message?
>
> RG
>
Re: Qpid URL Formats [ was Re: A question for the ActiveMQ chaps on the list...]
Posted by Robert Greig <ro...@gmail.com>.
On 27/09/06, John O'Hara <jo...@gmail.com> wrote:
> For testing I understand.
> But what are we testing at that point?
It is extremely useful to be able to test without the latency
introduced by the network. We have found a number of timing-related
bugs this way. It is also useful to know that the higher layers in the
broker and client are not intimately bound to TCP/IP.
> You should be able to run one test harness against both the C++ and Java
> servers... that would be real leverage; and that would use IP.
Of course and nobody is suggesting that we should not be able to do this.
> I think popping out the notion of a VM transport sends a bad message to
> prospective users.
I don't follow. What bad message?
RG
Re: Qpid URL Formats [ was Re: A question for the ActiveMQ chaps on the list...]
Posted by John O'Hara <jo...@gmail.com>.
For testing I understand.
But what are we testing at that point?
You should be able to run one test harness against both the C++ and Java
servers... that would be real leverage; and that would use IP.
I think popping out the notion of a VM transport sends a bad message to
prospective users.
Does the HTTPD team test that with a loopback of sorts or the Samba team? I
suspect not.
Just my 2c
John
On 26/09/06, Robert Greig <ro...@jpmorgan.com> wrote:
>
> The in-VM transport enables you to run a client and broker in the same
> JVM.
> This is extremely useful for testing purposes.
>
> RG
>
>
> |---------+---------------------------->
> | | "John O'Hara" |
> | | <john.r.ohara@gma|
> | | il.com> |
> | | |
> | | 25/09/2006 23:57 |
> | | Please respond to|
> | | qpid-dev |
> |---------+---------------------------->
>
> >------------------------------------------------------------------------------------------------------------------------------|
>
> | |
> | To: qpid-dev@incubator.apache.org
> |
> |
> cc: |
> | Subject: Re: Qpid URL Formats [ was Re: A question for the
> ActiveMQ chaps on the list...] |
>
> >------------------------------------------------------------------------------------------------------------------------------|
>
>
>
>
> Also, what's this VM transport in the suggested URL scheme!!!!
>
> I don't think that's terribly portable.... how about we stick to TCP until
> its all working.
> Same as NFS, HTTP etc. they are socket bound.
>
> Theres is also the SSL discussion, whether to negotiate on the same port,
> or
> use a different port.
> The W3C standard on URI's would suggest this is a more correct
> representation of either approach:
> amqp://
> amqp+tls:// <- recommended way of adding transport optionality
> amqps:// <- no choice, essentially a different protocol
>
> Looks like its going to be an interesting session in Boston!
>
> Cheers
> John
>
>
>
>
> On 25/09/06, Alan Conway <ac...@redhat.com> wrote:
> >
> > The URL format involves nested single quoted strings. How on earth do
> > you parse that?
> >
> > If nested values are needed then I thing some sort of bracket character
> > is in order, but it begs the question are we trying to stuff too much
> > info into a URL here?
> >
> >
> > On Mon, 2006-09-25 at 10:02 +0100, Martin Ritchie wrote:
> > > We currently have a URI format that is in use in the Java
> > implementation.
> > >
> > > I have created a wiki page that describes this format.
> > >
> > > http://wiki.apache.org/qpid/URLFormats
> > >
> > > Comments and feedback would be great. If we can come to an agreement
> on
> > the
> > > format then we can suggest it to the AMQP WG as they do not currently
> > have
> > > a defined format. Such a format will be required for interoperability.
> > >
> > > --
> > > Martin
> > >
> > >
> > >
> > >
> > > |---------+---------------------------->
> > > | | "John O'Hara" |
> > > | | <john.r.ohara@gma|
> > > | | il.com> |
> > > | | |
> > > | | 2006-09-22 20:49 |
> > > | | Please respond to|
> > > | | qpid-dev |
> > > |---------+---------------------------->
> > >
> >
>
> >------------------------------------------------------------------------------------------------------------------------------|
>
> > >
> > |
> |
> > > | To: qpid-dev@incubator.apache.org
> >
> |
> > > |
> > cc:
> |
> > > | Subject: Re: A question for the ActiveMQ chaps on the
> > list... |
> > >
> >
>
> >------------------------------------------------------------------------------------------------------------------------------|
>
> > >
> > >
> > >
> > >
> > > So basically we could use a URI which defines the exchanges, bindings
> > and
> > > queues.
> > > A bit nasty, but there is something attractive about it in the same
> way
> > > ODBC
> > > connection strings undeniably work :-)
> > >
> > > John
> > >
> > > On 22/09/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > > >
> > > > On 9/22/06, Gordon Sim <gs...@redhat.com> wrote:
> > > > > James Strachan wrote:
> > > > > > On 9/22/06, John O'Hara <jo...@gmail.com> wrote:
> > > > > >> When James spent some time with us back on the early early days
> > of
> > > > the
> > > > > >> AMQP I got the impression that he held the view that you could
> > plug
> > > > the
> > > > > >> command verbs onto ActiveMQ and it would just work.
> > > > > >
> > > > > > Assuming there is indeed a well defined mapping of AMQP commands
> > to
> > > > > > JMS/MQSeries semantics then yes it should.
> > > > >
> > > > > I think a well defined mapping of JMS semantics onto AMQP commands
> > is
> > > > > possible and desirable. I'm not as sure that there is a mapping of
> > AMQP
> > > > > commands onto JMS semantics.
> > > > >
> > > > > For example, in AMQP there is a bind command for attaching a queue
> > to
> > > an
> > > > > exchange. What concept in JMS would this command be mapped onto?
> > > > >
> > > >
> > > > All the binding information can be contained in the destination
> name.
> > > >
> > > > > I'm certainly not saying that a given JMS broker could not be made
> > to
> > > > > support AMQP. Individual implementations may well have the
> necessary
> > > > > concepts in which to express AMQP semantics, but as far as I can
> JMS
> > as
> > > > > a specification does not so I'm not clear how a generic mapping
> > would
> > > be
> > > > > specified.
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Regards,
> > > > Hiram
> > > >
> > > > Blog: http://hiramchirino.com
> > > >
> > >
> > >
> > >
> > >
> > > 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.
> > >
> >
> >
>
>
>
>
> 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 URL Formats [ was Re: A question for the ActiveMQ chaps on the
list...]
Posted by Robert Greig <ro...@jpmorgan.com>.
The in-VM transport enables you to run a client and broker in the same JVM.
This is extremely useful for testing purposes.
RG
|---------+---------------------------->
| | "John O'Hara" |
| | <john.r.ohara@gma|
| | il.com> |
| | |
| | 25/09/2006 23:57 |
| | Please respond to|
| | qpid-dev |
|---------+---------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
| |
| To: qpid-dev@incubator.apache.org |
| cc: |
| Subject: Re: Qpid URL Formats [ was Re: A question for the ActiveMQ chaps on the list...] |
>------------------------------------------------------------------------------------------------------------------------------|
Also, what's this VM transport in the suggested URL scheme!!!!
I don't think that's terribly portable.... how about we stick to TCP until
its all working.
Same as NFS, HTTP etc. they are socket bound.
Theres is also the SSL discussion, whether to negotiate on the same port,
or
use a different port.
The W3C standard on URI's would suggest this is a more correct
representation of either approach:
amqp://
amqp+tls:// <- recommended way of adding transport optionality
amqps:// <- no choice, essentially a different protocol
Looks like its going to be an interesting session in Boston!
Cheers
John
On 25/09/06, Alan Conway <ac...@redhat.com> wrote:
>
> The URL format involves nested single quoted strings. How on earth do
> you parse that?
>
> If nested values are needed then I thing some sort of bracket character
> is in order, but it begs the question are we trying to stuff too much
> info into a URL here?
>
>
> On Mon, 2006-09-25 at 10:02 +0100, Martin Ritchie wrote:
> > We currently have a URI format that is in use in the Java
> implementation.
> >
> > I have created a wiki page that describes this format.
> >
> > http://wiki.apache.org/qpid/URLFormats
> >
> > Comments and feedback would be great. If we can come to an agreement on
> the
> > format then we can suggest it to the AMQP WG as they do not currently
> have
> > a defined format. Such a format will be required for interoperability.
> >
> > --
> > Martin
> >
> >
> >
> >
> > |---------+---------------------------->
> > | | "John O'Hara" |
> > | | <john.r.ohara@gma|
> > | | il.com> |
> > | | |
> > | | 2006-09-22 20:49 |
> > | | Please respond to|
> > | | qpid-dev |
> > |---------+---------------------------->
> >
>
>------------------------------------------------------------------------------------------------------------------------------|
> >
> |
|
> > | To: qpid-dev@incubator.apache.org
>
|
> > |
> cc:
|
> > | Subject: Re: A question for the ActiveMQ chaps on the
> list... |
> >
>
>------------------------------------------------------------------------------------------------------------------------------|
> >
> >
> >
> >
> > So basically we could use a URI which defines the exchanges, bindings
> and
> > queues.
> > A bit nasty, but there is something attractive about it in the same way
> > ODBC
> > connection strings undeniably work :-)
> >
> > John
> >
> > On 22/09/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > >
> > > On 9/22/06, Gordon Sim <gs...@redhat.com> wrote:
> > > > James Strachan wrote:
> > > > > On 9/22/06, John O'Hara <jo...@gmail.com> wrote:
> > > > >> When James spent some time with us back on the early early days
> of
> > > the
> > > > >> AMQP I got the impression that he held the view that you could
> plug
> > > the
> > > > >> command verbs onto ActiveMQ and it would just work.
> > > > >
> > > > > Assuming there is indeed a well defined mapping of AMQP commands
> to
> > > > > JMS/MQSeries semantics then yes it should.
> > > >
> > > > I think a well defined mapping of JMS semantics onto AMQP commands
> is
> > > > possible and desirable. I'm not as sure that there is a mapping of
> AMQP
> > > > commands onto JMS semantics.
> > > >
> > > > For example, in AMQP there is a bind command for attaching a queue
> to
> > an
> > > > exchange. What concept in JMS would this command be mapped onto?
> > > >
> > >
> > > All the binding information can be contained in the destination name.
> > >
> > > > I'm certainly not saying that a given JMS broker could not be made
> to
> > > > support AMQP. Individual implementations may well have the
necessary
> > > > concepts in which to express AMQP semantics, but as far as I can
JMS
> as
> > > > a specification does not so I'm not clear how a generic mapping
> would
> > be
> > > > specified.
> > > >
> > > >
> > >
> > >
> > > --
> > > Regards,
> > > Hiram
> > >
> > > Blog: http://hiramchirino.com
> > >
> >
> >
> >
> >
> > 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.
> >
>
>
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 URL Formats [ was Re: A question for the ActiveMQ chaps on the list...]
Posted by Steven Shaw <st...@gmail.com>.
On 25/09/06, John O'Hara <jo...@gmail.com> wrote:
> Also, what's this VM transport in the suggested URL scheme!!!!
I don't think it's anything to be concerned about. There should be do
mandate for all implementations to provide it. Perhaps you are
thinking that VM stands for Virtual Memory? and think it perhaps
refers to some kind of shared memory transport?
In this case 'vm' stands for Virtual Machine and means connect clients
to brokers within the same (Java) VM. It's just an optimisation for
clients and brokers sharing the same operating system process, a way
of transferring the "protocol objects" without encoding/decoding or
sending over the network. The letters 'vm' aren't as meaningful on all
those platforms though.
Re: Qpid URL Formats [ was Re: A question for the ActiveMQ chaps on the list...]
Posted by John O'Hara <jo...@gmail.com>.
Also, what's this VM transport in the suggested URL scheme!!!!
I don't think that's terribly portable.... how about we stick to TCP until
its all working.
Same as NFS, HTTP etc. they are socket bound.
Theres is also the SSL discussion, whether to negotiate on the same port, or
use a different port.
The W3C standard on URI's would suggest this is a more correct
representation of either approach:
amqp://
amqp+tls:// <- recommended way of adding transport optionality
amqps:// <- no choice, essentially a different protocol
Looks like its going to be an interesting session in Boston!
Cheers
John
On 25/09/06, Alan Conway <ac...@redhat.com> wrote:
>
> The URL format involves nested single quoted strings. How on earth do
> you parse that?
>
> If nested values are needed then I thing some sort of bracket character
> is in order, but it begs the question are we trying to stuff too much
> info into a URL here?
>
>
> On Mon, 2006-09-25 at 10:02 +0100, Martin Ritchie wrote:
> > We currently have a URI format that is in use in the Java
> implementation.
> >
> > I have created a wiki page that describes this format.
> >
> > http://wiki.apache.org/qpid/URLFormats
> >
> > Comments and feedback would be great. If we can come to an agreement on
> the
> > format then we can suggest it to the AMQP WG as they do not currently
> have
> > a defined format. Such a format will be required for interoperability.
> >
> > --
> > Martin
> >
> >
> >
> >
> > |---------+---------------------------->
> > | | "John O'Hara" |
> > | | <john.r.ohara@gma|
> > | | il.com> |
> > | | |
> > | | 2006-09-22 20:49 |
> > | | Please respond to|
> > | | qpid-dev |
> > |---------+---------------------------->
> >
> >------------------------------------------------------------------------------------------------------------------------------|
> >
> | |
> > | To: qpid-dev@incubator.apache.org
> |
> > |
> cc: |
> > | Subject: Re: A question for the ActiveMQ chaps on the
> list... |
> >
> >------------------------------------------------------------------------------------------------------------------------------|
> >
> >
> >
> >
> > So basically we could use a URI which defines the exchanges, bindings
> and
> > queues.
> > A bit nasty, but there is something attractive about it in the same way
> > ODBC
> > connection strings undeniably work :-)
> >
> > John
> >
> > On 22/09/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > >
> > > On 9/22/06, Gordon Sim <gs...@redhat.com> wrote:
> > > > James Strachan wrote:
> > > > > On 9/22/06, John O'Hara <jo...@gmail.com> wrote:
> > > > >> When James spent some time with us back on the early early days
> of
> > > the
> > > > >> AMQP I got the impression that he held the view that you could
> plug
> > > the
> > > > >> command verbs onto ActiveMQ and it would just work.
> > > > >
> > > > > Assuming there is indeed a well defined mapping of AMQP commands
> to
> > > > > JMS/MQSeries semantics then yes it should.
> > > >
> > > > I think a well defined mapping of JMS semantics onto AMQP commands
> is
> > > > possible and desirable. I'm not as sure that there is a mapping of
> AMQP
> > > > commands onto JMS semantics.
> > > >
> > > > For example, in AMQP there is a bind command for attaching a queue
> to
> > an
> > > > exchange. What concept in JMS would this command be mapped onto?
> > > >
> > >
> > > All the binding information can be contained in the destination name.
> > >
> > > > I'm certainly not saying that a given JMS broker could not be made
> to
> > > > support AMQP. Individual implementations may well have the necessary
> > > > concepts in which to express AMQP semantics, but as far as I can JMS
> as
> > > > a specification does not so I'm not clear how a generic mapping
> would
> > be
> > > > specified.
> > > >
> > > >
> > >
> > >
> > > --
> > > Regards,
> > > Hiram
> > >
> > > Blog: http://hiramchirino.com
> > >
> >
> >
> >
> >
> > 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 URL Formats [ was Re: A question for the ActiveMQ chaps
on the list...]
Posted by Alan Conway <ac...@redhat.com>.
The URL format involves nested single quoted strings. How on earth do
you parse that?
If nested values are needed then I thing some sort of bracket character
is in order, but it begs the question are we trying to stuff too much
info into a URL here?
On Mon, 2006-09-25 at 10:02 +0100, Martin Ritchie wrote:
> We currently have a URI format that is in use in the Java implementation.
>
> I have created a wiki page that describes this format.
>
> http://wiki.apache.org/qpid/URLFormats
>
> Comments and feedback would be great. If we can come to an agreement on the
> format then we can suggest it to the AMQP WG as they do not currently have
> a defined format. Such a format will be required for interoperability.
>
> --
> Martin
>
>
>
>
> |---------+---------------------------->
> | | "John O'Hara" |
> | | <john.r.ohara@gma|
> | | il.com> |
> | | |
> | | 2006-09-22 20:49 |
> | | Please respond to|
> | | qpid-dev |
> |---------+---------------------------->
> >------------------------------------------------------------------------------------------------------------------------------|
> | |
> | To: qpid-dev@incubator.apache.org |
> | cc: |
> | Subject: Re: A question for the ActiveMQ chaps on the list... |
> >------------------------------------------------------------------------------------------------------------------------------|
>
>
>
>
> So basically we could use a URI which defines the exchanges, bindings and
> queues.
> A bit nasty, but there is something attractive about it in the same way
> ODBC
> connection strings undeniably work :-)
>
> John
>
> On 22/09/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> >
> > On 9/22/06, Gordon Sim <gs...@redhat.com> wrote:
> > > James Strachan wrote:
> > > > On 9/22/06, John O'Hara <jo...@gmail.com> wrote:
> > > >> When James spent some time with us back on the early early days of
> > the
> > > >> AMQP I got the impression that he held the view that you could plug
> > the
> > > >> command verbs onto ActiveMQ and it would just work.
> > > >
> > > > Assuming there is indeed a well defined mapping of AMQP commands to
> > > > JMS/MQSeries semantics then yes it should.
> > >
> > > I think a well defined mapping of JMS semantics onto AMQP commands is
> > > possible and desirable. I'm not as sure that there is a mapping of AMQP
> > > commands onto JMS semantics.
> > >
> > > For example, in AMQP there is a bind command for attaching a queue to
> an
> > > exchange. What concept in JMS would this command be mapped onto?
> > >
> >
> > All the binding information can be contained in the destination name.
> >
> > > I'm certainly not saying that a given JMS broker could not be made to
> > > support AMQP. Individual implementations may well have the necessary
> > > concepts in which to express AMQP semantics, but as far as I can JMS as
> > > a specification does not so I'm not clear how a generic mapping would
> be
> > > specified.
> > >
> > >
> >
> >
> > --
> > Regards,
> > Hiram
> >
> > Blog: http://hiramchirino.com
> >
>
>
>
>
> 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 URL Formats [ was Re: A question for the ActiveMQ chaps on the list...]
Posted by Steven Shaw <st...@gmail.com>.
On 25/09/06, Alan Conway <ac...@redhat.com> wrote:
> +1. Also the format uses nested single-quoted strings. Even if you can
> parse it (I have no idea how) it seems very error prone. If we need
> nesting then some bracket character is in order, but I think the need
> for nesting is evidence of trying to stuff too much into a
Alan, I was only agreeing with Gordon about having two fields to
contain the reply-to information where currently some form of encoding
is required. The BindingUrlFormat could be used for this but I think
it makes more sense to simply have the 'reply-to exchange name' and
'reply-to routing-key' as separate fields. This gives just enough
information to do a basic.publish. The exchange-type which is included
in the BindingUrlFormat format is not required.
Note that using the 'getJMSReplyTo' Destination for consuming should
cause an InvalidDestinationException as there is not sufficient
information to consume from this Destination (you could make some
assumptions about the routing-key being a queue name but this could be
wrong - certainly for the topic exchange). I checked the JMS spec and
api documentation. This would seem to be a valid implemementation. It
would certainly be an oddball application design that takes the
reply-to destination and *consumes* from it :).
Steve.
Re: Qpid URL Formats [ was Re: A question for the ActiveMQ chaps on the
list...]
Posted by Martin Ritchie <ma...@jpmorgan.com>.
I agree that the URLs can be viewed as tied to each implementation and is
simply a short cut for creating configuration but why should we limit
ourselves to being unable to share this 'configuration' between clients.
The parsing was very straight forward. Just count the number of tested
quotes. The parsing class gives very accurate output of what is wrong with
the url when parsed. The ConnectionURLTest class demonstrates the parsing
while if you look at URLHelper.parseOptions you can see how I parsed the
url.
The reason for nesting was to allow the same parser to work for the main
amqp url and the broker details that are contained therein.
True there is a lot of 'stuff' to put in the URL but to be able to use the
simplest form of JNDI you need a way of representing the connection factory
as a string. The use of other option makers such as brackets could be used
but I think that would be more confusing as you need to remember when to
use which marker style.
No one had any other suggestions for the Connection URL (other than using
brackets for nested options) so I went ahead with what I thought was best.
The URL parsing works just now but we can come up with another syntax that
captures the required information in a cleaner way.
Cheers
--
Martin Ritchie
Alan Conway
<aconway@redhat.c
om> To
qpid-dev@incubator.apache.org
2006-09-25 14:31 cc
Subject
Please respond to Re: Qpid URL Formats [ was Re: A
qpid-dev@incubato question for the ActiveMQ chaps
r.apache.org on the list...]
On Mon, 2006-09-25 at 12:58 +0100, Steven Shaw wrote:
> On 25/09/06, Gordon Sim <gs...@redhat.com> wrote:
> > In general in AMQP the only information used in sending would be the
> > exchange name and the routing key. Perhaps two fields in the headers
> > 'reply exchange' and 'reply routing key' would be better long term
> > approach than trying to encode the information in a single string.
> > Certainly I don't think the queue name (or any of its properties)
should
> > be included.
>
> I agree.
+1. Also the format uses nested single-quoted strings. Even if you can
parse it (I have no idea how) it seems very error prone. If we need
nesting then some bracket character is in order, but I think the need
for nesting is evidence of trying to stuff too much into a
Cheers,
Alan.
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 URL Formats [ was Re: A question for the ActiveMQ chaps
on the list...]
Posted by Alan Conway <ac...@redhat.com>.
On Mon, 2006-09-25 at 12:58 +0100, Steven Shaw wrote:
> On 25/09/06, Gordon Sim <gs...@redhat.com> wrote:
> > In general in AMQP the only information used in sending would be the
> > exchange name and the routing key. Perhaps two fields in the headers
> > 'reply exchange' and 'reply routing key' would be better long term
> > approach than trying to encode the information in a single string.
> > Certainly I don't think the queue name (or any of its properties) should
> > be included.
>
> I agree.
+1. Also the format uses nested single-quoted strings. Even if you can
parse it (I have no idea how) it seems very error prone. If we need
nesting then some bracket character is in order, but I think the need
for nesting is evidence of trying to stuff too much into a
Cheers,
Alan.
Re: Qpid URL Formats [ was Re: A question for the ActiveMQ chaps on the list...]
Posted by Steven Shaw <st...@gmail.com>.
On 25/09/06, Gordon Sim <gs...@redhat.com> wrote:
> In general in AMQP the only information used in sending would be the
> exchange name and the routing key. Perhaps two fields in the headers
> 'reply exchange' and 'reply routing key' would be better long term
> approach than trying to encode the information in a single string.
> Certainly I don't think the queue name (or any of its properties) should
> be included.
I agree.
Re: Qpid URL Formats [ was Re: A question for the ActiveMQ chaps
on the list...]
Posted by Gordon Sim <gs...@redhat.com>.
Robert Greig wrote:
> The interop case that I was thinking about was the replyto field currently
> in the basic content class.
>
> If clients don't have a common understand of how that field is encoded then
> I don't think that field is very useful?
Yes, good point. The reply to field is underspecified and the 'binding
url' as defined in the wiki link could be used for that.
In general in AMQP the only information used in sending would be the
exchange name and the routing key. Perhaps two fields in the headers
'reply exchange' and 'reply routing key' would be better long term
approach than trying to encode the information in a single string.
Certainly I don't think the queue name (or any of its properties) should
be included.
Re: Qpid URL Formats [ was Re: A question for the ActiveMQ chaps on the
list...]
Posted by Robert Greig <ro...@jpmorgan.com>.
The interop case that I was thinking about was the replyto field currently
in the basic content class.
If clients don't have a common understand of how that field is encoded then
I don't think that field is very useful?
RG
|---------+---------------------------->
| | Gordon Sim |
| | <gs...@redhat.com>|
| | |
| | 25/09/2006 11:38 |
| | Please respond to|
| | qpid-dev |
|---------+---------------------------->
>--------------------------------------------------------------------------------------------------------------------------------|
| |
| To: qpid-dev@incubator.apache.org |
| cc: |
| Subject: Re: Qpid URL Formats [ was Re: A question for the ActiveMQ chaps on the list...] |
>--------------------------------------------------------------------------------------------------------------------------------|
Martin Ritchie wrote:
> We currently have a URI format that is in use in the Java implementation.
>
> I have created a wiki page that describes this format.
>
> http://wiki.apache.org/qpid/URLFormats
>
> Comments and feedback would be great. If we can come to an agreement on
the
> format then we can suggest it to the AMQP WG as they do not currently
have
> a defined format. Such a format will be required for interoperability.
I disagree. Such a URL format seems relevant only to the API in use. It
is only required for interoperability between different
implementations of that same API and even then merely allows you to
leave your configuration unchanged between implementations.
It is currently only used in the JMS adaptors API. As the format is not
standard across JMS implementations, an application using the JMS APIs
in conjunction with qpid would still need to revise their configuration
if they move to (or from) an alternative JMS implementation.
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 URL Formats [ was Re: A question for the ActiveMQ chaps
on the list...]
Posted by Gordon Sim <gs...@redhat.com>.
Martin Ritchie wrote:
> We currently have a URI format that is in use in the Java implementation.
>
> I have created a wiki page that describes this format.
>
> http://wiki.apache.org/qpid/URLFormats
>
> Comments and feedback would be great. If we can come to an agreement on the
> format then we can suggest it to the AMQP WG as they do not currently have
> a defined format. Such a format will be required for interoperability.
I disagree. Such a URL format seems relevant only to the API in use. It
is only required for interoperability between different
implementations of that same API and even then merely allows you to
leave your configuration unchanged between implementations.
It is currently only used in the JMS adaptors API. As the format is not
standard across JMS implementations, an application using the JMS APIs
in conjunction with qpid would still need to revise their configuration
if they move to (or from) an alternative JMS implementation.