You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by loctorp <bo...@logica.com> on 2008/12/19 15:18:53 UTC
actual status of activeMQ and AMQP
Hi everyone,
I was wondering about the current status of AMQP implementation into
acticeMQ. On the project page it states, that there is a sandbox version and
that developement has been paused.
As we are interested in using activeMQ together with AMQP we were wondering
if this status has changed and/or are interested in the up-to-date outlook.
Thanks,
regards,
b
--
View this message in context: http://www.nabble.com/actual-status-of-activeMQ-and-AMQP-tp21092034p21092034.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: actual status of activeMQ and AMQP
Posted by bwtaylor <br...@yahoo.com>.
I'd love to read more about the plans for ActiveMQ 6. The
http://activemq.apache.org/new-features-in-60.html page is kind of sparse.
bwtaylor wrote:
>
> Awesome! You guys are the bomb.
>
> I think all three of those (OSGI, AMQP, and true REST) will be very well
> received.
>
>
> rajdavies wrote:
>>
>> The Architecture for ActiveMQ 6 is designed to be flexible and
>> extensible. Its being built on an OSGI kernel -
>> http://servicemix.apache.org/SMX4KNL/index.html
>> .
>> With the input of SonicMQ architects - we are building out the
>> enterprise class features of ActiveMQ, but we will be accommodating
>> more wire formats - including AMQP -as well as true restful API.
>>
>>
>> On 8 Mar 2009, at 04:59, bwtaylor wrote:
>>
>>>
>>> There is more noise again around my shop regarding AMQP. The "AMPQ
>>> == RedHat"
>>> assertion doesn't play because you've got RabbitMQ and Qpid. Yes, QPid
>>> started as a Red Hat code drop, but everybody understands that
>>> Apache is
>>> robust to domination by any one vendor, a fact that ApacheMQ and
>>> Camel both
>>> demonstrate well. But even if what you say is true, if Red Hat is
>>> the only
>>> vendor that comes forward with a solution for them, that's not a
>>> good place
>>> for you to be. Nobody fears Red Hat lock in.
>>>
>>> I do not need AMQP per se: what I need is high quality cross platform
>>> messaging. So if you've changed your plans and aren't going to
>>> tackle AMQP
>>> because it isn't simple to implement for existing broker platforms,
>>> why not
>>> team up with the folks you mention and come up with something that
>>> is. I
>>> expect that the reason the AMQP spec writers didn't come up with a
>>> solution
>>> that could be bolted on to existing brokers is because they got the
>>> cold
>>> shoulder from the projects you listed.
>>>
>>> STOMP is not the answer. It's too simplistic and asking ruby and
>>> python apps
>>> to confine their messaging capabilities to what STOMP provides is
>>> met with
>>> the same enthusiasm you'd get asking java shops to give up JMS for
>>> it. The
>>> stomp python clients all have various states of disrepair. The ruby
>>> one
>>> works, but there's critical unresolved bugs related to activemq's
>>> stomp
>>> implementation anyhow: AMQ-2137, AMQ-1941, AMQ-1873, AMQ-1807. Also
>>> stomp
>>> won't have keep alive until v1.1 (AMQ-2019). We've seen this leak
>>> sockets to
>>> the point where we hit the ulimit max and our broker hangs.
>>>
>>>
>>> rajdavies wrote:
>>>>
>>>> The AMQP reality is that only new message brokers will implement it -
>>>> simply because you'd have to re-write the message broker to
>>>> accommodate it. Which is why you won't see any of the traditional
>>>> messaging platforms like Webshpere MQ, SonicMQ or Tibco EMS, RV
>>>> implementing any time soon. We would love to offer full support for
>>>> it
>>>> in ActiveMQ - but that's going to take lot of investment and a lot
>>>> of work.
>>>>
>>>> Its a shame the AMQP spec writers didn't concentrate on making AMQP
>>>> simple to use and implement for existing messaging platforms in the
>>>> same way STOMP did - which is why both OpenMQ and RabbitMQ support
>>>> STOMP - and SonicMQ will probably being doing the same in the future
>>>> too.
>>>>
>>>> The AMQP protocol is open argument kinda disappears up its own
>>>> backside once folks realize the cost of entry - that a vendor has to
>>>> start from scratch to implement it - so in reality AMQP == RedHat
>>>> currently for enterprises. Ironic - when the whole point of AMQP was
>>>> to try break vendor lock-in!
>>>>
>>>> cheers,
>>>>
>>>> Rob
>>>>
>>>> Rob Davies
>>>> http://fusesource.com
>>>> http://rajdavies.blogspot.com/
>>>>
>>>>
>>>>
>>>> On 26 Jan 2009, at 18:49, bwtaylor wrote:
>>>>
>>>>>
>>>>> I'll also express strong interest in AMQP and I'll take the liberty
>>>>> of saying
>>>>> that most people using stomp for cross platform integration with
>>>>> ActiveMQ
>>>>> should be expressing interest. With the influx of enterprise apps
>>>>> being
>>>>> written in dynamic languages, AMQP offers high end messaging
>>>>> features in a
>>>>> platform agnostic way.
>>>>>
>>>>> I would also caution against assuming that the people who want AMQP
>>>>> for
>>>>> messaging are likely to seek you out to express that interest. If
>>>>> I'm a ruby
>>>>> on rails or a django shop and I figure out I need a messaging
>>>>> solution for
>>>>> cross platform integration, I'll soon have an interest in AMQP.
>>>>> When I look
>>>>> for implementations I'll find RabbitMQ or Redhat Messaging, or
>>>>> AMQP in
>>>>> Fedora 10 and never think about ActiveMQ.
>>>>>
>>>>> In fact, if you don't support AMQP that will be a talking point
>>>>> against
>>>>> deploying ActiveMQ in an IT environment where ruby or python apps
>>>>> exist.
>>>>> I've already had that happen at my company and I've played down AMQP
>>>>> as
>>>>> still in development, not quite fully baked, but now with Fedora 10
>>>>> touting
>>>>> AMQP as a major new feature, that argument's lifespan is ending and
>>>>> people
>>>>> are becoming more aware of it.
>>>>>
>>>>>
>>>>>
>>>>> James.Strachan wrote:
>>>>>>
>>>>>> 2008/12/19 loctorp <bo...@logica.com>:
>>>>>>>
>>>>>>> Hi everyone,
>>>>>>> I was wondering about the current status of AMQP implementation
>>>>>>> into
>>>>>>> acticeMQ. On the project page it states, that there is a sandbox
>>>>>>> version
>>>>>>> and
>>>>>>> that developement has been paused.
>>>>>>>
>>>>>>> As we are interested in using activeMQ together with AMQP we were
>>>>>>> wondering
>>>>>>> if this status has changed and/or are interested in the up-to-date
>>>>>>> outlook.
>>>>>>
>>>>>> The status hasn't changed since that wiki page was written.
>>>>>> Welcome -
>>>>>> you're the first person ever to express any interest in AMQP with
>>>>>> ActiveMQ :)
>>>>>>
>>>>>> --
>>>>>> James
>>>>>> -------
>>>>>> http://macstrac.blogspot.com/
>>>>>>
>>>>>> Open Source Integration
>>>>>> http://fusesource.com/
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/actual-status-of-activeMQ-and-AMQP-tp21092034p21671180.html
>>>>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/actual-status-of-activeMQ-and-AMQP-tp21092034p22395001.html
>>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>>
>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/actual-status-of-activeMQ-and-AMQP-tp21092034p22403597.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: actual status of activeMQ and AMQP
Posted by bwtaylor <br...@yahoo.com>.
Awesome! You guys are the bomb.
I think all three of those (OSGI, AMQP, and true REST) will be very well
received.
rajdavies wrote:
>
> The Architecture for ActiveMQ 6 is designed to be flexible and
> extensible. Its being built on an OSGI kernel -
> http://servicemix.apache.org/SMX4KNL/index.html
> .
> With the input of SonicMQ architects - we are building out the
> enterprise class features of ActiveMQ, but we will be accommodating
> more wire formats - including AMQP -as well as true restful API.
>
>
> On 8 Mar 2009, at 04:59, bwtaylor wrote:
>
>>
>> There is more noise again around my shop regarding AMQP. The "AMPQ
>> == RedHat"
>> assertion doesn't play because you've got RabbitMQ and Qpid. Yes, QPid
>> started as a Red Hat code drop, but everybody understands that
>> Apache is
>> robust to domination by any one vendor, a fact that ApacheMQ and
>> Camel both
>> demonstrate well. But even if what you say is true, if Red Hat is
>> the only
>> vendor that comes forward with a solution for them, that's not a
>> good place
>> for you to be. Nobody fears Red Hat lock in.
>>
>> I do not need AMQP per se: what I need is high quality cross platform
>> messaging. So if you've changed your plans and aren't going to
>> tackle AMQP
>> because it isn't simple to implement for existing broker platforms,
>> why not
>> team up with the folks you mention and come up with something that
>> is. I
>> expect that the reason the AMQP spec writers didn't come up with a
>> solution
>> that could be bolted on to existing brokers is because they got the
>> cold
>> shoulder from the projects you listed.
>>
>> STOMP is not the answer. It's too simplistic and asking ruby and
>> python apps
>> to confine their messaging capabilities to what STOMP provides is
>> met with
>> the same enthusiasm you'd get asking java shops to give up JMS for
>> it. The
>> stomp python clients all have various states of disrepair. The ruby
>> one
>> works, but there's critical unresolved bugs related to activemq's
>> stomp
>> implementation anyhow: AMQ-2137, AMQ-1941, AMQ-1873, AMQ-1807. Also
>> stomp
>> won't have keep alive until v1.1 (AMQ-2019). We've seen this leak
>> sockets to
>> the point where we hit the ulimit max and our broker hangs.
>>
>>
>> rajdavies wrote:
>>>
>>> The AMQP reality is that only new message brokers will implement it -
>>> simply because you'd have to re-write the message broker to
>>> accommodate it. Which is why you won't see any of the traditional
>>> messaging platforms like Webshpere MQ, SonicMQ or Tibco EMS, RV
>>> implementing any time soon. We would love to offer full support for
>>> it
>>> in ActiveMQ - but that's going to take lot of investment and a lot
>>> of work.
>>>
>>> Its a shame the AMQP spec writers didn't concentrate on making AMQP
>>> simple to use and implement for existing messaging platforms in the
>>> same way STOMP did - which is why both OpenMQ and RabbitMQ support
>>> STOMP - and SonicMQ will probably being doing the same in the future
>>> too.
>>>
>>> The AMQP protocol is open argument kinda disappears up its own
>>> backside once folks realize the cost of entry - that a vendor has to
>>> start from scratch to implement it - so in reality AMQP == RedHat
>>> currently for enterprises. Ironic - when the whole point of AMQP was
>>> to try break vendor lock-in!
>>>
>>> cheers,
>>>
>>> Rob
>>>
>>> Rob Davies
>>> http://fusesource.com
>>> http://rajdavies.blogspot.com/
>>>
>>>
>>>
>>> On 26 Jan 2009, at 18:49, bwtaylor wrote:
>>>
>>>>
>>>> I'll also express strong interest in AMQP and I'll take the liberty
>>>> of saying
>>>> that most people using stomp for cross platform integration with
>>>> ActiveMQ
>>>> should be expressing interest. With the influx of enterprise apps
>>>> being
>>>> written in dynamic languages, AMQP offers high end messaging
>>>> features in a
>>>> platform agnostic way.
>>>>
>>>> I would also caution against assuming that the people who want AMQP
>>>> for
>>>> messaging are likely to seek you out to express that interest. If
>>>> I'm a ruby
>>>> on rails or a django shop and I figure out I need a messaging
>>>> solution for
>>>> cross platform integration, I'll soon have an interest in AMQP.
>>>> When I look
>>>> for implementations I'll find RabbitMQ or Redhat Messaging, or
>>>> AMQP in
>>>> Fedora 10 and never think about ActiveMQ.
>>>>
>>>> In fact, if you don't support AMQP that will be a talking point
>>>> against
>>>> deploying ActiveMQ in an IT environment where ruby or python apps
>>>> exist.
>>>> I've already had that happen at my company and I've played down AMQP
>>>> as
>>>> still in development, not quite fully baked, but now with Fedora 10
>>>> touting
>>>> AMQP as a major new feature, that argument's lifespan is ending and
>>>> people
>>>> are becoming more aware of it.
>>>>
>>>>
>>>>
>>>> James.Strachan wrote:
>>>>>
>>>>> 2008/12/19 loctorp <bo...@logica.com>:
>>>>>>
>>>>>> Hi everyone,
>>>>>> I was wondering about the current status of AMQP implementation
>>>>>> into
>>>>>> acticeMQ. On the project page it states, that there is a sandbox
>>>>>> version
>>>>>> and
>>>>>> that developement has been paused.
>>>>>>
>>>>>> As we are interested in using activeMQ together with AMQP we were
>>>>>> wondering
>>>>>> if this status has changed and/or are interested in the up-to-date
>>>>>> outlook.
>>>>>
>>>>> The status hasn't changed since that wiki page was written.
>>>>> Welcome -
>>>>> you're the first person ever to express any interest in AMQP with
>>>>> ActiveMQ :)
>>>>>
>>>>> --
>>>>> James
>>>>> -------
>>>>> http://macstrac.blogspot.com/
>>>>>
>>>>> Open Source Integration
>>>>> http://fusesource.com/
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/actual-status-of-activeMQ-and-AMQP-tp21092034p21671180.html
>>>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>>>
>>>
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/actual-status-of-activeMQ-and-AMQP-tp21092034p22395001.html
>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>
>
>
>
--
View this message in context: http://www.nabble.com/actual-status-of-activeMQ-and-AMQP-tp21092034p22402742.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: actual status of activeMQ and AMQP
Posted by mffrench <mf...@axway.com>.
Hello,
As you maybe know the future AMQP 1.0 release is out of the box soon
(http://jira.amqp.org/confluence/display/AMQP/Advanced+Message+Queuing+Protocol)...
And as you maybe notice too a famous IT enterprise work now on the AMQP
specification : Microsoft. So it's now more only a redhat businnes (in fact
as far I know it never was ...) .
I've some question on how AMQP will be implemented in ActiveMQ. As you said
the AMQP specification is particularly founding : I mean it's implementation
will have an eavy impact on the queuer core and so it's not only a wire
protocol. That's why I understand when you say "The AMQP reality is that
only new message brokers will implement it". So the question is : do you
plan to rewrite ActiveMQ core ? If not how do you plan to add this connector
?
About restful you maybe notice that there is some effort on AMQP to
integrate a restMS system (http://wiki.amqp.org/spec:7) into the protocol
... What do you think about ? Could it be a good solution for your restful
API ?
Finally I would be very interested to know the state of your osgi
implementation progress... I've already the trunk source code of ActiveMQ
but I didn't see anything for the moment related to OSGI. I would be very
interested to help you because it will be certainly a work I will have to do
for my firm... Is there any specification or documentation about it to get
me started ?
Thanks for all
rajdavies wrote:
>
> The Architecture for ActiveMQ 6 is designed to be flexible and
> extensible. Its being built on an OSGI kernel -
> http://servicemix.apache.org/SMX4KNL/index.html
> .
> With the input of SonicMQ architects - we are building out the
> enterprise class features of ActiveMQ, but we will be accommodating
> more wire formats - including AMQP -as well as true restful API.
>
>
> On 8 Mar 2009, at 04:59, bwtaylor wrote:
>
>>
>> There is more noise again around my shop regarding AMQP. The "AMPQ
>> == RedHat"
>> assertion doesn't play because you've got RabbitMQ and Qpid. Yes, QPid
>> started as a Red Hat code drop, but everybody understands that
>> Apache is
>> robust to domination by any one vendor, a fact that ApacheMQ and
>> Camel both
>> demonstrate well. But even if what you say is true, if Red Hat is
>> the only
>> vendor that comes forward with a solution for them, that's not a
>> good place
>> for you to be. Nobody fears Red Hat lock in.
>>
>> I do not need AMQP per se: what I need is high quality cross platform
>> messaging. So if you've changed your plans and aren't going to
>> tackle AMQP
>> because it isn't simple to implement for existing broker platforms,
>> why not
>> team up with the folks you mention and come up with something that
>> is. I
>> expect that the reason the AMQP spec writers didn't come up with a
>> solution
>> that could be bolted on to existing brokers is because they got the
>> cold
>> shoulder from the projects you listed.
>>
>> STOMP is not the answer. It's too simplistic and asking ruby and
>> python apps
>> to confine their messaging capabilities to what STOMP provides is
>> met with
>> the same enthusiasm you'd get asking java shops to give up JMS for
>> it. The
>> stomp python clients all have various states of disrepair. The ruby
>> one
>> works, but there's critical unresolved bugs related to activemq's
>> stomp
>> implementation anyhow: AMQ-2137, AMQ-1941, AMQ-1873, AMQ-1807. Also
>> stomp
>> won't have keep alive until v1.1 (AMQ-2019). We've seen this leak
>> sockets to
>> the point where we hit the ulimit max and our broker hangs.
>>
>>
>> rajdavies wrote:
>>>
>>> The AMQP reality is that only new message brokers will implement it -
>>> simply because you'd have to re-write the message broker to
>>> accommodate it. Which is why you won't see any of the traditional
>>> messaging platforms like Webshpere MQ, SonicMQ or Tibco EMS, RV
>>> implementing any time soon. We would love to offer full support for
>>> it
>>> in ActiveMQ - but that's going to take lot of investment and a lot
>>> of work.
>>>
>>> Its a shame the AMQP spec writers didn't concentrate on making AMQP
>>> simple to use and implement for existing messaging platforms in the
>>> same way STOMP did - which is why both OpenMQ and RabbitMQ support
>>> STOMP - and SonicMQ will probably being doing the same in the future
>>> too.
>>>
>>> The AMQP protocol is open argument kinda disappears up its own
>>> backside once folks realize the cost of entry - that a vendor has to
>>> start from scratch to implement it - so in reality AMQP == RedHat
>>> currently for enterprises. Ironic - when the whole point of AMQP was
>>> to try break vendor lock-in!
>>>
>>> cheers,
>>>
>>> Rob
>>>
>>> Rob Davies
>>> http://fusesource.com
>>> http://rajdavies.blogspot.com/
>>>
>>>
>>>
>>> On 26 Jan 2009, at 18:49, bwtaylor wrote:
>>>
>>>>
>>>> I'll also express strong interest in AMQP and I'll take the liberty
>>>> of saying
>>>> that most people using stomp for cross platform integration with
>>>> ActiveMQ
>>>> should be expressing interest. With the influx of enterprise apps
>>>> being
>>>> written in dynamic languages, AMQP offers high end messaging
>>>> features in a
>>>> platform agnostic way.
>>>>
>>>> I would also caution against assuming that the people who want AMQP
>>>> for
>>>> messaging are likely to seek you out to express that interest. If
>>>> I'm a ruby
>>>> on rails or a django shop and I figure out I need a messaging
>>>> solution for
>>>> cross platform integration, I'll soon have an interest in AMQP.
>>>> When I look
>>>> for implementations I'll find RabbitMQ or Redhat Messaging, or
>>>> AMQP in
>>>> Fedora 10 and never think about ActiveMQ.
>>>>
>>>> In fact, if you don't support AMQP that will be a talking point
>>>> against
>>>> deploying ActiveMQ in an IT environment where ruby or python apps
>>>> exist.
>>>> I've already had that happen at my company and I've played down AMQP
>>>> as
>>>> still in development, not quite fully baked, but now with Fedora 10
>>>> touting
>>>> AMQP as a major new feature, that argument's lifespan is ending and
>>>> people
>>>> are becoming more aware of it.
>>>>
>>>>
>>>>
>>>> James.Strachan wrote:
>>>>>
>>>>> 2008/12/19 loctorp <bo...@logica.com>:
>>>>>>
>>>>>> Hi everyone,
>>>>>> I was wondering about the current status of AMQP implementation
>>>>>> into
>>>>>> acticeMQ. On the project page it states, that there is a sandbox
>>>>>> version
>>>>>> and
>>>>>> that developement has been paused.
>>>>>>
>>>>>> As we are interested in using activeMQ together with AMQP we were
>>>>>> wondering
>>>>>> if this status has changed and/or are interested in the up-to-date
>>>>>> outlook.
>>>>>
>>>>> The status hasn't changed since that wiki page was written.
>>>>> Welcome -
>>>>> you're the first person ever to express any interest in AMQP with
>>>>> ActiveMQ :)
>>>>>
>>>>> --
>>>>> James
>>>>> -------
>>>>> http://macstrac.blogspot.com/
>>>>>
>>>>> Open Source Integration
>>>>> http://fusesource.com/
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/actual-status-of-activeMQ-and-AMQP-tp21092034p21671180.html
>>>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>>>
>>>
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/actual-status-of-activeMQ-and-AMQP-tp21092034p22395001.html
>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>
>
>
>
--
View this message in context: http://www.nabble.com/actual-status-of-activeMQ-and-AMQP-tp21092034p22664108.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: actual status of activeMQ and AMQP
Posted by Rob Davies <ra...@gmail.com>.
The Architecture for ActiveMQ 6 is designed to be flexible and
extensible. Its being built on an OSGI kernel - http://servicemix.apache.org/SMX4KNL/index.html
.
With the input of SonicMQ architects - we are building out the
enterprise class features of ActiveMQ, but we will be accommodating
more wire formats - including AMQP -as well as true restful API.
On 8 Mar 2009, at 04:59, bwtaylor wrote:
>
> There is more noise again around my shop regarding AMQP. The "AMPQ
> == RedHat"
> assertion doesn't play because you've got RabbitMQ and Qpid. Yes, QPid
> started as a Red Hat code drop, but everybody understands that
> Apache is
> robust to domination by any one vendor, a fact that ApacheMQ and
> Camel both
> demonstrate well. But even if what you say is true, if Red Hat is
> the only
> vendor that comes forward with a solution for them, that's not a
> good place
> for you to be. Nobody fears Red Hat lock in.
>
> I do not need AMQP per se: what I need is high quality cross platform
> messaging. So if you've changed your plans and aren't going to
> tackle AMQP
> because it isn't simple to implement for existing broker platforms,
> why not
> team up with the folks you mention and come up with something that
> is. I
> expect that the reason the AMQP spec writers didn't come up with a
> solution
> that could be bolted on to existing brokers is because they got the
> cold
> shoulder from the projects you listed.
>
> STOMP is not the answer. It's too simplistic and asking ruby and
> python apps
> to confine their messaging capabilities to what STOMP provides is
> met with
> the same enthusiasm you'd get asking java shops to give up JMS for
> it. The
> stomp python clients all have various states of disrepair. The ruby
> one
> works, but there's critical unresolved bugs related to activemq's
> stomp
> implementation anyhow: AMQ-2137, AMQ-1941, AMQ-1873, AMQ-1807. Also
> stomp
> won't have keep alive until v1.1 (AMQ-2019). We've seen this leak
> sockets to
> the point where we hit the ulimit max and our broker hangs.
>
>
> rajdavies wrote:
>>
>> The AMQP reality is that only new message brokers will implement it -
>> simply because you'd have to re-write the message broker to
>> accommodate it. Which is why you won't see any of the traditional
>> messaging platforms like Webshpere MQ, SonicMQ or Tibco EMS, RV
>> implementing any time soon. We would love to offer full support for
>> it
>> in ActiveMQ - but that's going to take lot of investment and a lot
>> of work.
>>
>> Its a shame the AMQP spec writers didn't concentrate on making AMQP
>> simple to use and implement for existing messaging platforms in the
>> same way STOMP did - which is why both OpenMQ and RabbitMQ support
>> STOMP - and SonicMQ will probably being doing the same in the future
>> too.
>>
>> The AMQP protocol is open argument kinda disappears up its own
>> backside once folks realize the cost of entry - that a vendor has to
>> start from scratch to implement it - so in reality AMQP == RedHat
>> currently for enterprises. Ironic - when the whole point of AMQP was
>> to try break vendor lock-in!
>>
>> cheers,
>>
>> Rob
>>
>> Rob Davies
>> http://fusesource.com
>> http://rajdavies.blogspot.com/
>>
>>
>>
>> On 26 Jan 2009, at 18:49, bwtaylor wrote:
>>
>>>
>>> I'll also express strong interest in AMQP and I'll take the liberty
>>> of saying
>>> that most people using stomp for cross platform integration with
>>> ActiveMQ
>>> should be expressing interest. With the influx of enterprise apps
>>> being
>>> written in dynamic languages, AMQP offers high end messaging
>>> features in a
>>> platform agnostic way.
>>>
>>> I would also caution against assuming that the people who want AMQP
>>> for
>>> messaging are likely to seek you out to express that interest. If
>>> I'm a ruby
>>> on rails or a django shop and I figure out I need a messaging
>>> solution for
>>> cross platform integration, I'll soon have an interest in AMQP.
>>> When I look
>>> for implementations I'll find RabbitMQ or Redhat Messaging, or
>>> AMQP in
>>> Fedora 10 and never think about ActiveMQ.
>>>
>>> In fact, if you don't support AMQP that will be a talking point
>>> against
>>> deploying ActiveMQ in an IT environment where ruby or python apps
>>> exist.
>>> I've already had that happen at my company and I've played down AMQP
>>> as
>>> still in development, not quite fully baked, but now with Fedora 10
>>> touting
>>> AMQP as a major new feature, that argument's lifespan is ending and
>>> people
>>> are becoming more aware of it.
>>>
>>>
>>>
>>> James.Strachan wrote:
>>>>
>>>> 2008/12/19 loctorp <bo...@logica.com>:
>>>>>
>>>>> Hi everyone,
>>>>> I was wondering about the current status of AMQP implementation
>>>>> into
>>>>> acticeMQ. On the project page it states, that there is a sandbox
>>>>> version
>>>>> and
>>>>> that developement has been paused.
>>>>>
>>>>> As we are interested in using activeMQ together with AMQP we were
>>>>> wondering
>>>>> if this status has changed and/or are interested in the up-to-date
>>>>> outlook.
>>>>
>>>> The status hasn't changed since that wiki page was written.
>>>> Welcome -
>>>> you're the first person ever to express any interest in AMQP with
>>>> ActiveMQ :)
>>>>
>>>> --
>>>> James
>>>> -------
>>>> http://macstrac.blogspot.com/
>>>>
>>>> Open Source Integration
>>>> http://fusesource.com/
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/actual-status-of-activeMQ-and-AMQP-tp21092034p21671180.html
>>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>>
>>
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/actual-status-of-activeMQ-and-AMQP-tp21092034p22395001.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
Re: actual status of activeMQ and AMQP
Posted by bwtaylor <br...@yahoo.com>.
There is more noise again around my shop regarding AMQP. The "AMPQ == RedHat"
assertion doesn't play because you've got RabbitMQ and Qpid. Yes, QPid
started as a Red Hat code drop, but everybody understands that Apache is
robust to domination by any one vendor, a fact that ApacheMQ and Camel both
demonstrate well. But even if what you say is true, if Red Hat is the only
vendor that comes forward with a solution for them, that's not a good place
for you to be. Nobody fears Red Hat lock in.
I do not need AMQP per se: what I need is high quality cross platform
messaging. So if you've changed your plans and aren't going to tackle AMQP
because it isn't simple to implement for existing broker platforms, why not
team up with the folks you mention and come up with something that is. I
expect that the reason the AMQP spec writers didn't come up with a solution
that could be bolted on to existing brokers is because they got the cold
shoulder from the projects you listed.
STOMP is not the answer. It's too simplistic and asking ruby and python apps
to confine their messaging capabilities to what STOMP provides is met with
the same enthusiasm you'd get asking java shops to give up JMS for it. The
stomp python clients all have various states of disrepair. The ruby one
works, but there's critical unresolved bugs related to activemq's stomp
implementation anyhow: AMQ-2137, AMQ-1941, AMQ-1873, AMQ-1807. Also stomp
won't have keep alive until v1.1 (AMQ-2019). We've seen this leak sockets to
the point where we hit the ulimit max and our broker hangs.
rajdavies wrote:
>
> The AMQP reality is that only new message brokers will implement it -
> simply because you'd have to re-write the message broker to
> accommodate it. Which is why you won't see any of the traditional
> messaging platforms like Webshpere MQ, SonicMQ or Tibco EMS, RV
> implementing any time soon. We would love to offer full support for it
> in ActiveMQ - but that's going to take lot of investment and a lot
> of work.
>
> Its a shame the AMQP spec writers didn't concentrate on making AMQP
> simple to use and implement for existing messaging platforms in the
> same way STOMP did - which is why both OpenMQ and RabbitMQ support
> STOMP - and SonicMQ will probably being doing the same in the future
> too.
>
> The AMQP protocol is open argument kinda disappears up its own
> backside once folks realize the cost of entry - that a vendor has to
> start from scratch to implement it - so in reality AMQP == RedHat
> currently for enterprises. Ironic - when the whole point of AMQP was
> to try break vendor lock-in!
>
> cheers,
>
> Rob
>
> Rob Davies
> http://fusesource.com
> http://rajdavies.blogspot.com/
>
>
>
> On 26 Jan 2009, at 18:49, bwtaylor wrote:
>
>>
>> I'll also express strong interest in AMQP and I'll take the liberty
>> of saying
>> that most people using stomp for cross platform integration with
>> ActiveMQ
>> should be expressing interest. With the influx of enterprise apps
>> being
>> written in dynamic languages, AMQP offers high end messaging
>> features in a
>> platform agnostic way.
>>
>> I would also caution against assuming that the people who want AMQP
>> for
>> messaging are likely to seek you out to express that interest. If
>> I'm a ruby
>> on rails or a django shop and I figure out I need a messaging
>> solution for
>> cross platform integration, I'll soon have an interest in AMQP.
>> When I look
>> for implementations I'll find RabbitMQ or Redhat Messaging, or AMQP in
>> Fedora 10 and never think about ActiveMQ.
>>
>> In fact, if you don't support AMQP that will be a talking point
>> against
>> deploying ActiveMQ in an IT environment where ruby or python apps
>> exist.
>> I've already had that happen at my company and I've played down AMQP
>> as
>> still in development, not quite fully baked, but now with Fedora 10
>> touting
>> AMQP as a major new feature, that argument's lifespan is ending and
>> people
>> are becoming more aware of it.
>>
>>
>>
>> James.Strachan wrote:
>>>
>>> 2008/12/19 loctorp <bo...@logica.com>:
>>>>
>>>> Hi everyone,
>>>> I was wondering about the current status of AMQP implementation into
>>>> acticeMQ. On the project page it states, that there is a sandbox
>>>> version
>>>> and
>>>> that developement has been paused.
>>>>
>>>> As we are interested in using activeMQ together with AMQP we were
>>>> wondering
>>>> if this status has changed and/or are interested in the up-to-date
>>>> outlook.
>>>
>>> The status hasn't changed since that wiki page was written. Welcome -
>>> you're the first person ever to express any interest in AMQP with
>>> ActiveMQ :)
>>>
>>> --
>>> James
>>> -------
>>> http://macstrac.blogspot.com/
>>>
>>> Open Source Integration
>>> http://fusesource.com/
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/actual-status-of-activeMQ-and-AMQP-tp21092034p21671180.html
>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>
>
>
>
>
--
View this message in context: http://www.nabble.com/actual-status-of-activeMQ-and-AMQP-tp21092034p22395001.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: actual status of activeMQ and AMQP
Posted by Rob Davies <ra...@gmail.com>.
The AMQP reality is that only new message brokers will implement it -
simply because you'd have to re-write the message broker to
accommodate it. Which is why you won't see any of the traditional
messaging platforms like Webshpere MQ, SonicMQ or Tibco EMS, RV
implementing any time soon. We would love to offer full support for it
in ActiveMQ - but that's going to take lot of investment and a lot
of work.
Its a shame the AMQP spec writers didn't concentrate on making AMQP
simple to use and implement for existing messaging platforms in the
same way STOMP did - which is why both OpenMQ and RabbitMQ support
STOMP - and SonicMQ will probably being doing the same in the future
too.
The AMQP protocol is open argument kinda disappears up its own
backside once folks realize the cost of entry - that a vendor has to
start from scratch to implement it - so in reality AMQP == RedHat
currently for enterprises. Ironic - when the whole point of AMQP was
to try break vendor lock-in!
cheers,
Rob
Rob Davies
http://fusesource.com
http://rajdavies.blogspot.com/
On 26 Jan 2009, at 18:49, bwtaylor wrote:
>
> I'll also express strong interest in AMQP and I'll take the liberty
> of saying
> that most people using stomp for cross platform integration with
> ActiveMQ
> should be expressing interest. With the influx of enterprise apps
> being
> written in dynamic languages, AMQP offers high end messaging
> features in a
> platform agnostic way.
>
> I would also caution against assuming that the people who want AMQP
> for
> messaging are likely to seek you out to express that interest. If
> I'm a ruby
> on rails or a django shop and I figure out I need a messaging
> solution for
> cross platform integration, I'll soon have an interest in AMQP.
> When I look
> for implementations I'll find RabbitMQ or Redhat Messaging, or AMQP in
> Fedora 10 and never think about ActiveMQ.
>
> In fact, if you don't support AMQP that will be a talking point
> against
> deploying ActiveMQ in an IT environment where ruby or python apps
> exist.
> I've already had that happen at my company and I've played down AMQP
> as
> still in development, not quite fully baked, but now with Fedora 10
> touting
> AMQP as a major new feature, that argument's lifespan is ending and
> people
> are becoming more aware of it.
>
>
>
> James.Strachan wrote:
>>
>> 2008/12/19 loctorp <bo...@logica.com>:
>>>
>>> Hi everyone,
>>> I was wondering about the current status of AMQP implementation into
>>> acticeMQ. On the project page it states, that there is a sandbox
>>> version
>>> and
>>> that developement has been paused.
>>>
>>> As we are interested in using activeMQ together with AMQP we were
>>> wondering
>>> if this status has changed and/or are interested in the up-to-date
>>> outlook.
>>
>> The status hasn't changed since that wiki page was written. Welcome -
>> you're the first person ever to express any interest in AMQP with
>> ActiveMQ :)
>>
>> --
>> James
>> -------
>> http://macstrac.blogspot.com/
>>
>> Open Source Integration
>> http://fusesource.com/
>>
>>
>
> --
> View this message in context: http://www.nabble.com/actual-status-of-activeMQ-and-AMQP-tp21092034p21671180.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
Re: actual status of activeMQ and AMQP
Posted by bwtaylor <br...@yahoo.com>.
I'll also express strong interest in AMQP and I'll take the liberty of saying
that most people using stomp for cross platform integration with ActiveMQ
should be expressing interest. With the influx of enterprise apps being
written in dynamic languages, AMQP offers high end messaging features in a
platform agnostic way.
I would also caution against assuming that the people who want AMQP for
messaging are likely to seek you out to express that interest. If I'm a ruby
on rails or a django shop and I figure out I need a messaging solution for
cross platform integration, I'll soon have an interest in AMQP. When I look
for implementations I'll find RabbitMQ or Redhat Messaging, or AMQP in
Fedora 10 and never think about ActiveMQ.
In fact, if you don't support AMQP that will be a talking point against
deploying ActiveMQ in an IT environment where ruby or python apps exist.
I've already had that happen at my company and I've played down AMQP as
still in development, not quite fully baked, but now with Fedora 10 touting
AMQP as a major new feature, that argument's lifespan is ending and people
are becoming more aware of it.
James.Strachan wrote:
>
> 2008/12/19 loctorp <bo...@logica.com>:
>>
>> Hi everyone,
>> I was wondering about the current status of AMQP implementation into
>> acticeMQ. On the project page it states, that there is a sandbox version
>> and
>> that developement has been paused.
>>
>> As we are interested in using activeMQ together with AMQP we were
>> wondering
>> if this status has changed and/or are interested in the up-to-date
>> outlook.
>
> The status hasn't changed since that wiki page was written. Welcome -
> you're the first person ever to express any interest in AMQP with
> ActiveMQ :)
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>
>
--
View this message in context: http://www.nabble.com/actual-status-of-activeMQ-and-AMQP-tp21092034p21671180.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: actual status of activeMQ and AMQP
Posted by James Strachan <ja...@gmail.com>.
2008/12/19 loctorp <bo...@logica.com>:
>
> Hi everyone,
> I was wondering about the current status of AMQP implementation into
> acticeMQ. On the project page it states, that there is a sandbox version and
> that developement has been paused.
>
> As we are interested in using activeMQ together with AMQP we were wondering
> if this status has changed and/or are interested in the up-to-date outlook.
The status hasn't changed since that wiki page was written. Welcome -
you're the first person ever to express any interest in AMQP with
ActiveMQ :)
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/