You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Geert Schuring <ge...@schuring.eu> on 2010/01/07 23:05:59 UTC
Proposal: Felix Messaging Service
Hey all,
I'm using Felix in a security software integration environment, and it supprised me that I couldn't find a messaging service that would handle JMS messaging for me. Did I miss something? If not, I would like to develop and contribute the "Felix Messaging Service". I have an API bundle in mind with several implementation bundles like ActiveMQ, WebsphereMQ, OpenJMS, Microsoft MQ, etc.
Let me know what you think.
Greets,
Geert Schuring.
RE: Proposal: Felix Messaging Service
Posted by Craig Phillips <lc...@praxiseng.com>.
Classic problem... Well stated...
Slightly aside, any time I see "JNDI", a big flashing red warning light goes off (I just do not like "statics")... Of course, whenever I see "UUID" or even log4j, a big flashing red warning light goes off, but I digress...
Even though I occasionally see forays into "distributed OSGi", I don't see anything concrete... Although, I have always liked Newton, including the concepts presented therein; Excellent ideas went into that effort;
I have come up with a very interesting distributed OSGi, using streaming technology; I embedded Felix inside a streaming container; Now, here's the JMS kicker...
I designed a streaming API to/from a "transport operator"; Hence, be it active MQ, or openJMS or whatever, the clients are purely decoupled from the actual implementation without even worrying about things like JNDI or brokers; The clients simply use the streaming API; There can also be more than one transport operator in the mix, so you could have both activeMQ as well as homegrown socket or anything and the clients are purely unaware; They simply send and receive messages over the transport(s) a la topics and maps therein; Even better, the clients are unaware of whether the distant cooperants are of the same streaming nature or of some other platform;
Just fodder to the mix... Craig Phillips, Praxis Engineering;
________________________________
From: Gerry Woods [mailto:gerrywoods@gmail.com]
Sent: Thu 1/7/2010 5:52 PM
To: dev@felix.apache.org
Subject: Re: Proposal: Felix Messaging Service
While I think the EventAdmin maps well to JMS for distribution of events,
I'm not sure that JMS maps well onto the EventAdmin. We have a similar need
to integrate JMS into an OSGi environment. The overriding problem from my
point of view is not the lack of an API, but the inherent difficulty of
introducing the prerequisites for different vendor implementations into the
OSGi framework. It seems to me that if a provider bundle published regular
JMS connection factories into OSGi, that would provide an adequate API for
any consumers. The implementation can create the factories using any
mechanism it favors behind the scenes, whether that be through JNDI, direct
instantiation, or whatever. So I guess my questions would be:
- Are the existing JMS APIs deficient or inadequate?
- Would this proposed API hide the JMS API altogether in favor of a new
model?
On Thu, Jan 7, 2010 at 2:30 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> Are you aware of:
>
> http://fusesource.com/wiki/display/LIGHTSABRE/Home ?
>
> Not exactly the same, but related. I am not familiar enough with JMS to say
> whether or not a new API is needed or if the EventAdmin API could be
> commandeered for this purpose. I do think there is potential, but let's see
> what others have to say.
>
> -> richard
>
>
> On 1/7/10 17:05, Geert Schuring wrote:
>
>> Hey all,
>>
>> I'm using Felix in a security software integration environment, and it
>> supprised me that I couldn't find a messaging service that would handle JMS
>> messaging for me. Did I miss something? If not, I would like to develop and
>> contribute the "Felix Messaging Service". I have an API bundle in mind with
>> several implementation bundles like ActiveMQ, WebsphereMQ, OpenJMS,
>> Microsoft MQ, etc.
>>
>> Let me know what you think.
>>
>> Greets,
>> Geert Schuring.
>>
>>
>
Re: Proposal: Felix Messaging Service
Posted by ge...@schuring.eu.
> While I think the EventAdmin maps well to JMS for distribution of events,
> I'm not sure that JMS maps well onto the EventAdmin.
That was exactly my conclusion after using LightSabre. I'm missing stuff
like transactions in the EventAdmin.
> We have a similar need
> to integrate JMS into an OSGi environment. The overriding problem from my
> point of view is not the lack of an API, but the inherent difficulty of
> introducing the prerequisites for different vendor implementations into
> the
> OSGi framework. It seems to me that if a provider bundle published
> regular
> JMS connection factories into OSGi, that would provide an adequate API for
> any consumers. The implementation can create the factories using any
> mechanism it favors behind the scenes, whether that be through JNDI,
> direct
> instantiation, or whatever. So I guess my questions would be:
> - Are the existing JMS APIs deficient or inadequate?
> - Would this proposed API hide the JMS API altogether in favor of a new
> model?
I guess the "JMS problem" can be solved at 2 levels. First of all the way
you described, by registering JMS objects like ConnectionFactories or even
Connections in the OSGi Service Registry. These can be configured through
the ConfigAdmin. I'm already doing it this way and it works very flexible
since I can change the configuration of the connection (hostname, queue
name, etc) without taking the application down.
And secondly by creating an optional higher level API that simply allows
you to use JMS without knowing how to setup connections, sessions,
MessageProducers or transactions. *For instance*, that API could provide a
method:
public Future<Throwable> sendToQueue(URL server, String queueName, boolean
useTransactions, Object... messages);
The MessageService can handle connection pooling and transaction
management for you, and send the given message objects the right way:
- Strings are send as TextMessage
- JAXB (annotated) objects are marshalled to XML and send in a TextMessage
(I'm using this, very nice way to send complex objects to other platforms)
- Maps are send as MapMessage
- Serializable objects are send as ObjectMessage
- and other objects generate exceptions :))
Using the Future object you can choose to wait for the messages to be
delivered (call .get() on the Future), or ignore the Future and use the
call as Fire-and-Forget.
What do you think?
Geert.
>
>
> On Thu, Jan 7, 2010 at 2:30 PM, Richard S. Hall
> <he...@ungoverned.org>wrote:
>
>> Are you aware of:
>>
>> http://fusesource.com/wiki/display/LIGHTSABRE/Home ?
>>
>> Not exactly the same, but related. I am not familiar enough with JMS to
>> say
>> whether or not a new API is needed or if the EventAdmin API could be
>> commandeered for this purpose. I do think there is potential, but let's
>> see
>> what others have to say.
>>
>> -> richard
>>
>>
>> On 1/7/10 17:05, Geert Schuring wrote:
>>
>>> Hey all,
>>>
>>> I'm using Felix in a security software integration environment, and it
>>> supprised me that I couldn't find a messaging service that would handle
>>> JMS
>>> messaging for me. Did I miss something? If not, I would like to develop
>>> and
>>> contribute the "Felix Messaging Service". I have an API bundle in mind
>>> with
>>> several implementation bundles like ActiveMQ, WebsphereMQ, OpenJMS,
>>> Microsoft MQ, etc.
>>>
>>> Let me know what you think.
>>>
>>> Greets,
>>> Geert Schuring.
>>>
>>>
>>
>
>
>
Re: Proposal: Felix Messaging Service
Posted by Gerry Woods <ge...@gmail.com>.
While I think the EventAdmin maps well to JMS for distribution of events,
I'm not sure that JMS maps well onto the EventAdmin. We have a similar need
to integrate JMS into an OSGi environment. The overriding problem from my
point of view is not the lack of an API, but the inherent difficulty of
introducing the prerequisites for different vendor implementations into the
OSGi framework. It seems to me that if a provider bundle published regular
JMS connection factories into OSGi, that would provide an adequate API for
any consumers. The implementation can create the factories using any
mechanism it favors behind the scenes, whether that be through JNDI, direct
instantiation, or whatever. So I guess my questions would be:
- Are the existing JMS APIs deficient or inadequate?
- Would this proposed API hide the JMS API altogether in favor of a new
model?
On Thu, Jan 7, 2010 at 2:30 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> Are you aware of:
>
> http://fusesource.com/wiki/display/LIGHTSABRE/Home ?
>
> Not exactly the same, but related. I am not familiar enough with JMS to say
> whether or not a new API is needed or if the EventAdmin API could be
> commandeered for this purpose. I do think there is potential, but let's see
> what others have to say.
>
> -> richard
>
>
> On 1/7/10 17:05, Geert Schuring wrote:
>
>> Hey all,
>>
>> I'm using Felix in a security software integration environment, and it
>> supprised me that I couldn't find a messaging service that would handle JMS
>> messaging for me. Did I miss something? If not, I would like to develop and
>> contribute the "Felix Messaging Service". I have an API bundle in mind with
>> several implementation bundles like ActiveMQ, WebsphereMQ, OpenJMS,
>> Microsoft MQ, etc.
>>
>> Let me know what you think.
>>
>> Greets,
>> Geert Schuring.
>>
>>
>
Re: Proposal: Felix Messaging Service
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Are you aware of:
http://fusesource.com/wiki/display/LIGHTSABRE/Home ?
Not exactly the same, but related. I am not familiar enough with JMS to
say whether or not a new API is needed or if the EventAdmin API could be
commandeered for this purpose. I do think there is potential, but let's
see what others have to say.
-> richard
On 1/7/10 17:05, Geert Schuring wrote:
> Hey all,
>
> I'm using Felix in a security software integration environment, and it supprised me that I couldn't find a messaging service that would handle JMS messaging for me. Did I miss something? If not, I would like to develop and contribute the "Felix Messaging Service". I have an API bundle in mind with several implementation bundles like ActiveMQ, WebsphereMQ, OpenJMS, Microsoft MQ, etc.
>
> Let me know what you think.
>
> Greets,
> Geert Schuring.
>