You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by James Carman <ja...@carmanconsulting.com> on 2015/03/30 15:23:19 UTC
[PROPOSAL] Pluggable Brokers...
All,
With all the talk over the last week or so regarding the "Broker
Wars", especially after reading Rob Davies' email about how the broker
has been tweaked through the years to emphasize different aspects
(long-term storage for instance), it occurred to me that we might be
able to move past all this craziness by providing an abstraction layer
above the broker and try to make them "pluggable."
If there really are situations where the broker needs to focus on one
particular aspect of message delivery, that sounds to me like the
"strategy" pattern. If a broker can be written in such a way that it
is allowed to focus on certain aspects and maybe ignore or completely
forego others, then it would seem to me that the code could be made
much more straight-forward, because it doesn't have to try to be the
"swiss army knife", solving everyone's problems at one time.
Of course, this may be just a pipe dream and there's no way to do it
(admittedly I'm not terribly familiar with the code), but I thought
I'd throw it out there as a possible approach. I mean, we do this
sort of thing already with the persistence providers, so maybe there's
an opportunity here as well.
Thoughts?
James
Re: [PROPOSAL] Pluggable Brokers...
Posted by Rob Davies <ra...@gmail.com>.
So I haven't had the time to research this - but as lack of instant
feedback is interpreted as ignoring, I believe this has merit - but will
require some in depth investigation.
> James Carman <ma...@carmanconsulting.com>
> 8 April 2015 08:13
> Pluggable *within* ActiveMQ. That is what doesn't exist. The idea is that
> the underlying engine could be optimized on a case-by-case basis. For
> instance, you may be able to streamline the implementation of a broker
> that
> doesn't require persistence at all. Right now, we have one implementation
> that tries to be the end-all-be-all solution for everything.
>
>
> Jim Gomes <ma...@apache.org>
> 8 April 2015 07:45
> I'm with Guillaume on this. From the NMS perspective, the broker
> already is
> a plugin implementation. I don't understand why it would need to go any
> deeper than that. NMS can talk to TIBCO or ActiveMQ brokers via one common
> API. The idea of pluggable brokers already exists.
>
>
> Guillaume Nodet <ma...@apache.org>
> 30 March 2015 16:32
> Fwiw, the whole broker implementation looks like an implementation detail
> from a user point of view that uses the JMS spec... ;-)
>
>
> Hadrian Zbarcea <ma...@gmail.com>
> 30 March 2015 16:12
> +1.
>
> The blocking today it merely an implementation detail than can be
> addressed.
>
> Hadrian
>
>
Re: [PROPOSAL] Pluggable Brokers...
Posted by Jim Gomes <jg...@apache.org>.
I guess if this would help the ActiveMQ developer by reducing code debt and
making maintenance simpler, it's a Good Thing. Pluggable architectures have
a certain amount of overhead, though.
I don't want to discourage interesting and new areas of architecture. The
original message said the pluggable interface would be "above" the broker,
not within it. That's what didn't make a lot of sense to me. If it's above
it, then the obvious plugin interface would be the existing wire protocols:
JMS via OpenWire or STOMP. If it's within the broker, where are the plugin
interface points? Is that what would need to be rearchitected, and is this
a significant amount of effort? I don't know enough of ActiveMQ's internals
to know where the boundaries are for clean separation.
On Wed, Apr 8, 2015, 12:15 AM James Carman <ja...@carmanconsulting.com>
wrote:
> Pluggable *within* ActiveMQ. That is what doesn't exist. The idea is that
> the underlying engine could be optimized on a case-by-case basis. For
> instance, you may be able to streamline the implementation of a broker that
> doesn't require persistence at all. Right now, we have one implementation
> that tries to be the end-all-be-all solution for everything.
>
> On Wednesday, April 8, 2015, Jim Gomes <jg...@apache.org> wrote:
>
> > I'm with Guillaume on this. From the NMS perspective, the broker already
> is
> > a plugin implementation. I don't understand why it would need to go any
> > deeper than that. NMS can talk to TIBCO or ActiveMQ brokers via one
> common
> > API. The idea of pluggable brokers already exists.
> >
> > On Mon, Mar 30, 2015, 8:32 AM Guillaume Nodet <gnodet@apache.org
> > <javascript:;>> wrote:
> >
> > > Fwiw, the whole broker implementation looks like an implementation
> detail
> > > from a user point of view that uses the JMS spec... ;-)
> > >
> > > 2015-03-30 17:12 GMT+02:00 Hadrian Zbarcea <hzbarcea@gmail.com
> > <javascript:;>>:
> > >
> > > > +1.
> > > >
> > > > The blocking today it merely an implementation detail than can be
> > > > addressed.
> > > >
> > > > Hadrian
> > > >
> > > >
> > > > On 03/30/2015 09:23 AM, James Carman wrote:
> > > >
> > > >> All,
> > > >>
> > > >> With all the talk over the last week or so regarding the "Broker
> > > >> Wars", especially after reading Rob Davies' email about how the
> broker
> > > >> has been tweaked through the years to emphasize different aspects
> > > >> (long-term storage for instance), it occurred to me that we might be
> > > >> able to move past all this craziness by providing an abstraction
> layer
> > > >> above the broker and try to make them "pluggable."
> > > >>
> > > >> If there really are situations where the broker needs to focus on
> one
> > > >> particular aspect of message delivery, that sounds to me like the
> > > >> "strategy" pattern. If a broker can be written in such a way that
> it
> > > >> is allowed to focus on certain aspects and maybe ignore or
> completely
> > > >> forego others, then it would seem to me that the code could be made
> > > >> much more straight-forward, because it doesn't have to try to be the
> > > >> "swiss army knife", solving everyone's problems at one time.
> > > >>
> > > >> Of course, this may be just a pipe dream and there's no way to do it
> > > >> (admittedly I'm not terribly familiar with the code), but I thought
> > > >> I'd throw it out there as a possible approach. I mean, we do this
> > > >> sort of thing already with the persistence providers, so maybe
> there's
> > > >> an opportunity here as well.
> > > >>
> > > >> Thoughts?
> > > >>
> > > >> James
> > > >>
> > > >>
> > >
> >
>
Re: [PROPOSAL] Pluggable Brokers...
Posted by James Carman <ja...@carmanconsulting.com>.
Pluggable *within* ActiveMQ. That is what doesn't exist. The idea is that
the underlying engine could be optimized on a case-by-case basis. For
instance, you may be able to streamline the implementation of a broker that
doesn't require persistence at all. Right now, we have one implementation
that tries to be the end-all-be-all solution for everything.
On Wednesday, April 8, 2015, Jim Gomes <jg...@apache.org> wrote:
> I'm with Guillaume on this. From the NMS perspective, the broker already is
> a plugin implementation. I don't understand why it would need to go any
> deeper than that. NMS can talk to TIBCO or ActiveMQ brokers via one common
> API. The idea of pluggable brokers already exists.
>
> On Mon, Mar 30, 2015, 8:32 AM Guillaume Nodet <gnodet@apache.org
> <javascript:;>> wrote:
>
> > Fwiw, the whole broker implementation looks like an implementation detail
> > from a user point of view that uses the JMS spec... ;-)
> >
> > 2015-03-30 17:12 GMT+02:00 Hadrian Zbarcea <hzbarcea@gmail.com
> <javascript:;>>:
> >
> > > +1.
> > >
> > > The blocking today it merely an implementation detail than can be
> > > addressed.
> > >
> > > Hadrian
> > >
> > >
> > > On 03/30/2015 09:23 AM, James Carman wrote:
> > >
> > >> All,
> > >>
> > >> With all the talk over the last week or so regarding the "Broker
> > >> Wars", especially after reading Rob Davies' email about how the broker
> > >> has been tweaked through the years to emphasize different aspects
> > >> (long-term storage for instance), it occurred to me that we might be
> > >> able to move past all this craziness by providing an abstraction layer
> > >> above the broker and try to make them "pluggable."
> > >>
> > >> If there really are situations where the broker needs to focus on one
> > >> particular aspect of message delivery, that sounds to me like the
> > >> "strategy" pattern. If a broker can be written in such a way that it
> > >> is allowed to focus on certain aspects and maybe ignore or completely
> > >> forego others, then it would seem to me that the code could be made
> > >> much more straight-forward, because it doesn't have to try to be the
> > >> "swiss army knife", solving everyone's problems at one time.
> > >>
> > >> Of course, this may be just a pipe dream and there's no way to do it
> > >> (admittedly I'm not terribly familiar with the code), but I thought
> > >> I'd throw it out there as a possible approach. I mean, we do this
> > >> sort of thing already with the persistence providers, so maybe there's
> > >> an opportunity here as well.
> > >>
> > >> Thoughts?
> > >>
> > >> James
> > >>
> > >>
> >
>
Re: [PROPOSAL] Pluggable Brokers...
Posted by Jim Gomes <jg...@apache.org>.
I'm with Guillaume on this. From the NMS perspective, the broker already is
a plugin implementation. I don't understand why it would need to go any
deeper than that. NMS can talk to TIBCO or ActiveMQ brokers via one common
API. The idea of pluggable brokers already exists.
On Mon, Mar 30, 2015, 8:32 AM Guillaume Nodet <gn...@apache.org> wrote:
> Fwiw, the whole broker implementation looks like an implementation detail
> from a user point of view that uses the JMS spec... ;-)
>
> 2015-03-30 17:12 GMT+02:00 Hadrian Zbarcea <hz...@gmail.com>:
>
> > +1.
> >
> > The blocking today it merely an implementation detail than can be
> > addressed.
> >
> > Hadrian
> >
> >
> > On 03/30/2015 09:23 AM, James Carman wrote:
> >
> >> All,
> >>
> >> With all the talk over the last week or so regarding the "Broker
> >> Wars", especially after reading Rob Davies' email about how the broker
> >> has been tweaked through the years to emphasize different aspects
> >> (long-term storage for instance), it occurred to me that we might be
> >> able to move past all this craziness by providing an abstraction layer
> >> above the broker and try to make them "pluggable."
> >>
> >> If there really are situations where the broker needs to focus on one
> >> particular aspect of message delivery, that sounds to me like the
> >> "strategy" pattern. If a broker can be written in such a way that it
> >> is allowed to focus on certain aspects and maybe ignore or completely
> >> forego others, then it would seem to me that the code could be made
> >> much more straight-forward, because it doesn't have to try to be the
> >> "swiss army knife", solving everyone's problems at one time.
> >>
> >> Of course, this may be just a pipe dream and there's no way to do it
> >> (admittedly I'm not terribly familiar with the code), but I thought
> >> I'd throw it out there as a possible approach. I mean, we do this
> >> sort of thing already with the persistence providers, so maybe there's
> >> an opportunity here as well.
> >>
> >> Thoughts?
> >>
> >> James
> >>
> >>
>
Re: [PROPOSAL] Pluggable Brokers...
Posted by artnaseef <ar...@artnaseef.com>.
Right, and users that use STOMP are not concerned with how well the solution
works for JMS or AMQP users. Although some users may want support for
multiple protocols. That's at least four use-cases right there.
An idea that keeps coming to mind -- the computer world has already
implemented the tool that "solves all problems" -- it's called a CPU. Our
job as developers is not to write the one solution that does everything, but
to find a balance and implement the "right size". Which raises the
question, "what is the right size?"
One messaging solution that meets all needs sounds like a huge challenge.
That's like asking for one database solution that meets all needs. I
wouldn't want to use a DBMS that handles large warehousing solutions
effectively in a small, embedded device.
--
View this message in context: http://activemq.2283324.n4.nabble.com/PROPOSAL-Pluggable-Brokers-tp4694058p4694074.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: [PROPOSAL] Pluggable Brokers...
Posted by Guillaume Nodet <gn...@apache.org>.
Fwiw, the whole broker implementation looks like an implementation detail
from a user point of view that uses the JMS spec... ;-)
2015-03-30 17:12 GMT+02:00 Hadrian Zbarcea <hz...@gmail.com>:
> +1.
>
> The blocking today it merely an implementation detail than can be
> addressed.
>
> Hadrian
>
>
> On 03/30/2015 09:23 AM, James Carman wrote:
>
>> All,
>>
>> With all the talk over the last week or so regarding the "Broker
>> Wars", especially after reading Rob Davies' email about how the broker
>> has been tweaked through the years to emphasize different aspects
>> (long-term storage for instance), it occurred to me that we might be
>> able to move past all this craziness by providing an abstraction layer
>> above the broker and try to make them "pluggable."
>>
>> If there really are situations where the broker needs to focus on one
>> particular aspect of message delivery, that sounds to me like the
>> "strategy" pattern. If a broker can be written in such a way that it
>> is allowed to focus on certain aspects and maybe ignore or completely
>> forego others, then it would seem to me that the code could be made
>> much more straight-forward, because it doesn't have to try to be the
>> "swiss army knife", solving everyone's problems at one time.
>>
>> Of course, this may be just a pipe dream and there's no way to do it
>> (admittedly I'm not terribly familiar with the code), but I thought
>> I'd throw it out there as a possible approach. I mean, we do this
>> sort of thing already with the persistence providers, so maybe there's
>> an opportunity here as well.
>>
>> Thoughts?
>>
>> James
>>
>>
Re: [PROPOSAL] Pluggable Brokers...
Posted by Hadrian Zbarcea <hz...@gmail.com>.
+1.
The blocking today it merely an implementation detail than can be addressed.
Hadrian
On 03/30/2015 09:23 AM, James Carman wrote:
> All,
>
> With all the talk over the last week or so regarding the "Broker
> Wars", especially after reading Rob Davies' email about how the broker
> has been tweaked through the years to emphasize different aspects
> (long-term storage for instance), it occurred to me that we might be
> able to move past all this craziness by providing an abstraction layer
> above the broker and try to make them "pluggable."
>
> If there really are situations where the broker needs to focus on one
> particular aspect of message delivery, that sounds to me like the
> "strategy" pattern. If a broker can be written in such a way that it
> is allowed to focus on certain aspects and maybe ignore or completely
> forego others, then it would seem to me that the code could be made
> much more straight-forward, because it doesn't have to try to be the
> "swiss army knife", solving everyone's problems at one time.
>
> Of course, this may be just a pipe dream and there's no way to do it
> (admittedly I'm not terribly familiar with the code), but I thought
> I'd throw it out there as a possible approach. I mean, we do this
> sort of thing already with the persistence providers, so maybe there's
> an opportunity here as well.
>
> Thoughts?
>
> James
>
Re: [PROPOSAL] Pluggable Brokers...
Posted by artnaseef <ar...@artnaseef.com>.
I'm not sure how this proposal fits into the existing ActiveMQ solution at
this point. It should be feasible to start down this path and consider how
it fits later down the line.
Giving it a little thought right now, one possible approach would be to get
the API defined, and then make a new messaging solution by taking key
ActiveMQ features (e.g. virtual topics) and putting them into a new artifact
that uses the Engine API.
I have another concept that may help to see how this proposal innovates.
This borrows from the "use before reuse" idea. Instead of creating a single
messaging solution (or broker), having a toolset for creating messaging
solutions makes it possible to better address diverse needs.
Another concept... We have socket, filesystem, and other APIs that make
networking, file storage, and other needs in applications easy. There are
multiple implementations of these APIs (every O/S has its own). And we have
messaging APIs (e.g. JMS) that makes messaging in applications easy. In
between, we have large solutions (ActiveMQ, XMPP, etc). What would happen
if we split that middle into two parts: one that brings up, from the bottom,
a "messaging engine" or "messaging primitives" API, creating a space coming
down from the top into which multiple implementations can be placed and more
easily developed?
Creating the best fit...
--
View this message in context: http://activemq.2283324.n4.nabble.com/PROPOSAL-Pluggable-Brokers-tp4694058p4694144.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: [PROPOSAL] Pluggable Brokers...
Posted by Guillaume Nodet <gn...@apache.org>.
The only way this proposal would help is if, once we have an API
(and it seems some people, especially those actually working on
the broker have some real doubts about its feasibility), we can adapt
the current activemq5 broker without actually fully rewriting it. Is
that even possible ?
If this new api leads to a rewrite of activemq5 to adapt, we'd end up
with 2 new brokers instead of having one in maintenance (activemq5)
and one new (the hornetq based one). This would be an even worse
situation imho.
2015-03-30 15:23 GMT+02:00 James Carman <ja...@carmanconsulting.com>:
> All,
>
> With all the talk over the last week or so regarding the "Broker
> Wars", especially after reading Rob Davies' email about how the broker
> has been tweaked through the years to emphasize different aspects
> (long-term storage for instance), it occurred to me that we might be
> able to move past all this craziness by providing an abstraction layer
> above the broker and try to make them "pluggable."
>
> If there really are situations where the broker needs to focus on one
> particular aspect of message delivery, that sounds to me like the
> "strategy" pattern. If a broker can be written in such a way that it
> is allowed to focus on certain aspects and maybe ignore or completely
> forego others, then it would seem to me that the code could be made
> much more straight-forward, because it doesn't have to try to be the
> "swiss army knife", solving everyone's problems at one time.
>
> Of course, this may be just a pipe dream and there's no way to do it
> (admittedly I'm not terribly familiar with the code), but I thought
> I'd throw it out there as a possible approach. I mean, we do this
> sort of thing already with the persistence providers, so maybe there's
> an opportunity here as well.
>
> Thoughts?
>
> James
>
Re: [PROPOSAL] Pluggable Brokers...
Posted by artnaseef <ar...@artnaseef.com>.
This is awesome. I have been thinking of a similar idea.
Separation of concerns... Core "messaging" implementation separated from the
overall messaging solution, allowing multiple messaging solutions with
varying needs to be maintained separately while also making it possible to
replace the engine implementation easily:
----------------------
messaging-solution
----------------------
| * client API
| * transaction management (including XA, if so desired)
| * features (such as Virtual Topics)
| * message containers (queues, topics, chat rooms, private message
rooms)
| * persist message for longer-term access, as-needed
|
| <--- *** Messaging Engine API
|
V
---------------------
messaging-engine
---------------------
* persist messages for guaranteed delivery (only; and not a required
feature of the engine)
* route messages
* transaction support
* enable enforcement of order
* moving messages to endpoints
NOTE: this needs more thought; the separation above may not be a good
dividing line, but I hope it makes my thinking more clear.
One key I see here - the ability to create a complete messaging solution
that is tuned to specific use-cases (e.g. small, embedded architecture; or
large, enterprise messaging backbone), while using the same engine. And,
the means to replace the engine with another one as long as the API is met.
James - is this in-line with your idea?
--
View this message in context: http://activemq.2283324.n4.nabble.com/PROPOSAL-Pluggable-Brokers-tp4694058p4694072.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: [PROPOSAL] Pluggable Brokers...
Posted by Clebert Suconic <cl...@gmail.com>.
I'm just saying I don't see how where / how I would find a common API.
I'm supportive of this thought if you find a good common API on a prototype.
Anyway, the issue on that thread is not technical at all.
On Mon, Mar 30, 2015 at 10:51 AM, Jamie G. <ja...@gmail.com> wrote:
> If I'm not mistaken, AMQ and HQ configurations are not all too
> different - how does this become recursive? A common API is just an
> adapter layer to everything else, when did abstraction of this form
> become a performance penalty?
>
> Cheers,
> Jamie
>
> On Mon, Mar 30, 2015 at 12:09 PM, Clebert Suconic
> <cl...@gmail.com> wrote:
>> The behaviour on how things happen at the server will make it hard to
>> have a common API.
>>
>> Second: it gets really recursive. it becomes an extra layer of
>> abstraction where you need the code as fast as possible.
>>
>>
>> I'm just saying I don't see how someone could make a single API for
>> the broker. what would be the pluggable points?
>>
>> The protocol layer is implemented at the server, storage at the
>> server... and they all need Asynchronous implementation. I don't see
>> a single point where you could plug these behaviours. If we had it we
>> wouldn't need all this discussion.
>>
>>
>> On Mon, Mar 30, 2015 at 10:34 AM, Jamie G. <ja...@gmail.com> wrote:
>>> Hi,
>>>
>>> Just a quick question on "For instance, when you receive a message,
>>> activemq is blocking a thread, while it should be asynchronous on the
>>> server, a callback be sent to the client whenever it was possible,
>>> from a callback handler.", can you explain this?
>>>
>>> Are you referencing synchronized vs actor based/callback code?
>>>
>>> How would this impact James' proposal?
>>>
>>> Cheers,
>>> Jamie
>>>
>>> On Mon, Mar 30, 2015 at 11:33 AM, Clebert Suconic
>>> <cl...@gmail.com> wrote:
>>>> If there was a semantic behavior in common where this would be
>>>> possible, we probably wouldn't need any improvements at all.
>>>>
>>>> For instance, when you receive a message, activemq is blocking a
>>>> thread, while it should be asynchronous on the server, a callback be
>>>> sent to the client whenever it was possible, from a callback handler.
>>>>
>>>>
>>>> It's different how lockings will happen, what makes a common API even
>>>> more unlikely.
>>>>
>>>>
>>>>
>>>>
>>>> Besides, It gets a bit recursive really, implementing an interface to
>>>> the broker implementing the broker.
>>>>
>>>>
>>>> I'm not saying it's impossible, but it seems unlikely to be possible.
>>>>
>>>> On Mon, Mar 30, 2015 at 9:23 AM, James Carman
>>>> <ja...@carmanconsulting.com> wrote:
>>>>> All,
>>>>>
>>>>> With all the talk over the last week or so regarding the "Broker
>>>>> Wars", especially after reading Rob Davies' email about how the broker
>>>>> has been tweaked through the years to emphasize different aspects
>>>>> (long-term storage for instance), it occurred to me that we might be
>>>>> able to move past all this craziness by providing an abstraction layer
>>>>> above the broker and try to make them "pluggable."
>>>>>
>>>>> If there really are situations where the broker needs to focus on one
>>>>> particular aspect of message delivery, that sounds to me like the
>>>>> "strategy" pattern. If a broker can be written in such a way that it
>>>>> is allowed to focus on certain aspects and maybe ignore or completely
>>>>> forego others, then it would seem to me that the code could be made
>>>>> much more straight-forward, because it doesn't have to try to be the
>>>>> "swiss army knife", solving everyone's problems at one time.
>>>>>
>>>>> Of course, this may be just a pipe dream and there's no way to do it
>>>>> (admittedly I'm not terribly familiar with the code), but I thought
>>>>> I'd throw it out there as a possible approach. I mean, we do this
>>>>> sort of thing already with the persistence providers, so maybe there's
>>>>> an opportunity here as well.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> James
>>>>
>>>>
>>>>
>>>> --
>>>> Clebert Suconic
>>>> http://community.jboss.org/people/clebert.suconic@jboss.com
>>>> http://clebertsuconic.blogspot.com
>>
>>
>>
>> --
>> Clebert Suconic
>> http://community.jboss.org/people/clebert.suconic@jboss.com
>> http://clebertsuconic.blogspot.com
--
Clebert Suconic
http://community.jboss.org/people/clebert.suconic@jboss.com
http://clebertsuconic.blogspot.com
Re: [PROPOSAL] Pluggable Brokers...
Posted by "Jamie G." <ja...@gmail.com>.
If I'm not mistaken, AMQ and HQ configurations are not all too
different - how does this become recursive? A common API is just an
adapter layer to everything else, when did abstraction of this form
become a performance penalty?
Cheers,
Jamie
On Mon, Mar 30, 2015 at 12:09 PM, Clebert Suconic
<cl...@gmail.com> wrote:
> The behaviour on how things happen at the server will make it hard to
> have a common API.
>
> Second: it gets really recursive. it becomes an extra layer of
> abstraction where you need the code as fast as possible.
>
>
> I'm just saying I don't see how someone could make a single API for
> the broker. what would be the pluggable points?
>
> The protocol layer is implemented at the server, storage at the
> server... and they all need Asynchronous implementation. I don't see
> a single point where you could plug these behaviours. If we had it we
> wouldn't need all this discussion.
>
>
> On Mon, Mar 30, 2015 at 10:34 AM, Jamie G. <ja...@gmail.com> wrote:
>> Hi,
>>
>> Just a quick question on "For instance, when you receive a message,
>> activemq is blocking a thread, while it should be asynchronous on the
>> server, a callback be sent to the client whenever it was possible,
>> from a callback handler.", can you explain this?
>>
>> Are you referencing synchronized vs actor based/callback code?
>>
>> How would this impact James' proposal?
>>
>> Cheers,
>> Jamie
>>
>> On Mon, Mar 30, 2015 at 11:33 AM, Clebert Suconic
>> <cl...@gmail.com> wrote:
>>> If there was a semantic behavior in common where this would be
>>> possible, we probably wouldn't need any improvements at all.
>>>
>>> For instance, when you receive a message, activemq is blocking a
>>> thread, while it should be asynchronous on the server, a callback be
>>> sent to the client whenever it was possible, from a callback handler.
>>>
>>>
>>> It's different how lockings will happen, what makes a common API even
>>> more unlikely.
>>>
>>>
>>>
>>>
>>> Besides, It gets a bit recursive really, implementing an interface to
>>> the broker implementing the broker.
>>>
>>>
>>> I'm not saying it's impossible, but it seems unlikely to be possible.
>>>
>>> On Mon, Mar 30, 2015 at 9:23 AM, James Carman
>>> <ja...@carmanconsulting.com> wrote:
>>>> All,
>>>>
>>>> With all the talk over the last week or so regarding the "Broker
>>>> Wars", especially after reading Rob Davies' email about how the broker
>>>> has been tweaked through the years to emphasize different aspects
>>>> (long-term storage for instance), it occurred to me that we might be
>>>> able to move past all this craziness by providing an abstraction layer
>>>> above the broker and try to make them "pluggable."
>>>>
>>>> If there really are situations where the broker needs to focus on one
>>>> particular aspect of message delivery, that sounds to me like the
>>>> "strategy" pattern. If a broker can be written in such a way that it
>>>> is allowed to focus on certain aspects and maybe ignore or completely
>>>> forego others, then it would seem to me that the code could be made
>>>> much more straight-forward, because it doesn't have to try to be the
>>>> "swiss army knife", solving everyone's problems at one time.
>>>>
>>>> Of course, this may be just a pipe dream and there's no way to do it
>>>> (admittedly I'm not terribly familiar with the code), but I thought
>>>> I'd throw it out there as a possible approach. I mean, we do this
>>>> sort of thing already with the persistence providers, so maybe there's
>>>> an opportunity here as well.
>>>>
>>>> Thoughts?
>>>>
>>>> James
>>>
>>>
>>>
>>> --
>>> Clebert Suconic
>>> http://community.jboss.org/people/clebert.suconic@jboss.com
>>> http://clebertsuconic.blogspot.com
>
>
>
> --
> Clebert Suconic
> http://community.jboss.org/people/clebert.suconic@jboss.com
> http://clebertsuconic.blogspot.com
Re: [PROPOSAL] Pluggable Brokers...
Posted by Tracy Snell <ts...@gmail.com>.
> On Mar 30, 2015, at 10:39 AM, Clebert Suconic <cl...@gmail.com> wrote:
>
> Second: it gets really recursive. it becomes an extra layer of
> abstraction where you need the code as fast as possible.
I’ve never considered abstraction a performance penalty.
Still thinking about the merits of the proposal and undecided.
Re: [PROPOSAL] Pluggable Brokers...
Posted by Clebert Suconic <cl...@gmail.com>.
The behaviour on how things happen at the server will make it hard to
have a common API.
Second: it gets really recursive. it becomes an extra layer of
abstraction where you need the code as fast as possible.
I'm just saying I don't see how someone could make a single API for
the broker. what would be the pluggable points?
The protocol layer is implemented at the server, storage at the
server... and they all need Asynchronous implementation. I don't see
a single point where you could plug these behaviours. If we had it we
wouldn't need all this discussion.
On Mon, Mar 30, 2015 at 10:34 AM, Jamie G. <ja...@gmail.com> wrote:
> Hi,
>
> Just a quick question on "For instance, when you receive a message,
> activemq is blocking a thread, while it should be asynchronous on the
> server, a callback be sent to the client whenever it was possible,
> from a callback handler.", can you explain this?
>
> Are you referencing synchronized vs actor based/callback code?
>
> How would this impact James' proposal?
>
> Cheers,
> Jamie
>
> On Mon, Mar 30, 2015 at 11:33 AM, Clebert Suconic
> <cl...@gmail.com> wrote:
>> If there was a semantic behavior in common where this would be
>> possible, we probably wouldn't need any improvements at all.
>>
>> For instance, when you receive a message, activemq is blocking a
>> thread, while it should be asynchronous on the server, a callback be
>> sent to the client whenever it was possible, from a callback handler.
>>
>>
>> It's different how lockings will happen, what makes a common API even
>> more unlikely.
>>
>>
>>
>>
>> Besides, It gets a bit recursive really, implementing an interface to
>> the broker implementing the broker.
>>
>>
>> I'm not saying it's impossible, but it seems unlikely to be possible.
>>
>> On Mon, Mar 30, 2015 at 9:23 AM, James Carman
>> <ja...@carmanconsulting.com> wrote:
>>> All,
>>>
>>> With all the talk over the last week or so regarding the "Broker
>>> Wars", especially after reading Rob Davies' email about how the broker
>>> has been tweaked through the years to emphasize different aspects
>>> (long-term storage for instance), it occurred to me that we might be
>>> able to move past all this craziness by providing an abstraction layer
>>> above the broker and try to make them "pluggable."
>>>
>>> If there really are situations where the broker needs to focus on one
>>> particular aspect of message delivery, that sounds to me like the
>>> "strategy" pattern. If a broker can be written in such a way that it
>>> is allowed to focus on certain aspects and maybe ignore or completely
>>> forego others, then it would seem to me that the code could be made
>>> much more straight-forward, because it doesn't have to try to be the
>>> "swiss army knife", solving everyone's problems at one time.
>>>
>>> Of course, this may be just a pipe dream and there's no way to do it
>>> (admittedly I'm not terribly familiar with the code), but I thought
>>> I'd throw it out there as a possible approach. I mean, we do this
>>> sort of thing already with the persistence providers, so maybe there's
>>> an opportunity here as well.
>>>
>>> Thoughts?
>>>
>>> James
>>
>>
>>
>> --
>> Clebert Suconic
>> http://community.jboss.org/people/clebert.suconic@jboss.com
>> http://clebertsuconic.blogspot.com
--
Clebert Suconic
http://community.jboss.org/people/clebert.suconic@jboss.com
http://clebertsuconic.blogspot.com
Re: [PROPOSAL] Pluggable Brokers...
Posted by "Jamie G." <ja...@gmail.com>.
Hi,
Just a quick question on "For instance, when you receive a message,
activemq is blocking a thread, while it should be asynchronous on the
server, a callback be sent to the client whenever it was possible,
from a callback handler.", can you explain this?
Are you referencing synchronized vs actor based/callback code?
How would this impact James' proposal?
Cheers,
Jamie
On Mon, Mar 30, 2015 at 11:33 AM, Clebert Suconic
<cl...@gmail.com> wrote:
> If there was a semantic behavior in common where this would be
> possible, we probably wouldn't need any improvements at all.
>
> For instance, when you receive a message, activemq is blocking a
> thread, while it should be asynchronous on the server, a callback be
> sent to the client whenever it was possible, from a callback handler.
>
>
> It's different how lockings will happen, what makes a common API even
> more unlikely.
>
>
>
>
> Besides, It gets a bit recursive really, implementing an interface to
> the broker implementing the broker.
>
>
> I'm not saying it's impossible, but it seems unlikely to be possible.
>
> On Mon, Mar 30, 2015 at 9:23 AM, James Carman
> <ja...@carmanconsulting.com> wrote:
>> All,
>>
>> With all the talk over the last week or so regarding the "Broker
>> Wars", especially after reading Rob Davies' email about how the broker
>> has been tweaked through the years to emphasize different aspects
>> (long-term storage for instance), it occurred to me that we might be
>> able to move past all this craziness by providing an abstraction layer
>> above the broker and try to make them "pluggable."
>>
>> If there really are situations where the broker needs to focus on one
>> particular aspect of message delivery, that sounds to me like the
>> "strategy" pattern. If a broker can be written in such a way that it
>> is allowed to focus on certain aspects and maybe ignore or completely
>> forego others, then it would seem to me that the code could be made
>> much more straight-forward, because it doesn't have to try to be the
>> "swiss army knife", solving everyone's problems at one time.
>>
>> Of course, this may be just a pipe dream and there's no way to do it
>> (admittedly I'm not terribly familiar with the code), but I thought
>> I'd throw it out there as a possible approach. I mean, we do this
>> sort of thing already with the persistence providers, so maybe there's
>> an opportunity here as well.
>>
>> Thoughts?
>>
>> James
>
>
>
> --
> Clebert Suconic
> http://community.jboss.org/people/clebert.suconic@jboss.com
> http://clebertsuconic.blogspot.com
Re: [PROPOSAL] Pluggable Brokers...
Posted by Clebert Suconic <cl...@gmail.com>.
If there was a semantic behavior in common where this would be
possible, we probably wouldn't need any improvements at all.
For instance, when you receive a message, activemq is blocking a
thread, while it should be asynchronous on the server, a callback be
sent to the client whenever it was possible, from a callback handler.
It's different how lockings will happen, what makes a common API even
more unlikely.
Besides, It gets a bit recursive really, implementing an interface to
the broker implementing the broker.
I'm not saying it's impossible, but it seems unlikely to be possible.
On Mon, Mar 30, 2015 at 9:23 AM, James Carman
<ja...@carmanconsulting.com> wrote:
> All,
>
> With all the talk over the last week or so regarding the "Broker
> Wars", especially after reading Rob Davies' email about how the broker
> has been tweaked through the years to emphasize different aspects
> (long-term storage for instance), it occurred to me that we might be
> able to move past all this craziness by providing an abstraction layer
> above the broker and try to make them "pluggable."
>
> If there really are situations where the broker needs to focus on one
> particular aspect of message delivery, that sounds to me like the
> "strategy" pattern. If a broker can be written in such a way that it
> is allowed to focus on certain aspects and maybe ignore or completely
> forego others, then it would seem to me that the code could be made
> much more straight-forward, because it doesn't have to try to be the
> "swiss army knife", solving everyone's problems at one time.
>
> Of course, this may be just a pipe dream and there's no way to do it
> (admittedly I'm not terribly familiar with the code), but I thought
> I'd throw it out there as a possible approach. I mean, we do this
> sort of thing already with the persistence providers, so maybe there's
> an opportunity here as well.
>
> Thoughts?
>
> James
--
Clebert Suconic
http://community.jboss.org/people/clebert.suconic@jboss.com
http://clebertsuconic.blogspot.com
Re: [PROPOSAL] Pluggable Brokers...
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
+1
Regards
JB
On 03/30/2015 03:23 PM, James Carman wrote:
> All,
>
> With all the talk over the last week or so regarding the "Broker
> Wars", especially after reading Rob Davies' email about how the broker
> has been tweaked through the years to emphasize different aspects
> (long-term storage for instance), it occurred to me that we might be
> able to move past all this craziness by providing an abstraction layer
> above the broker and try to make them "pluggable."
>
> If there really are situations where the broker needs to focus on one
> particular aspect of message delivery, that sounds to me like the
> "strategy" pattern. If a broker can be written in such a way that it
> is allowed to focus on certain aspects and maybe ignore or completely
> forego others, then it would seem to me that the code could be made
> much more straight-forward, because it doesn't have to try to be the
> "swiss army knife", solving everyone's problems at one time.
>
> Of course, this may be just a pipe dream and there's no way to do it
> (admittedly I'm not terribly familiar with the code), but I thought
> I'd throw it out there as a possible approach. I mean, we do this
> sort of thing already with the persistence providers, so maybe there's
> an opportunity here as well.
>
> Thoughts?
>
> James
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com