> 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. >>> >>> >> > > >
