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:[email protected]] Sent: Thu 1/7/2010 5:52 PM To: [email protected] 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 <[email protected]>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. >> >> >
