On 3/11/2014 4:29 PM, Mike Wilson wrote:
I agree with you Christian, and I've been quite surprised not really finding any OSGi remoting projects or libraries that integrate with messaging/JMS. It's strange because messaging is a one-stop solution providing anasynchronous model, load-balancing, and configuration to discover remote servers.
ECF has a JMS-based provider [1]. This provider is used for our support of OSGi Remote Services/RSA, as well as our Load Balancing example...using JMS Queue [2], and our Distributed Event Admin impl [3].
Or is there a good reason for this, and messaging is not a good fit with OSGi service remoting?
WRT specification...there has been some work/thinking on extending the EventAdmin spec for distributed/remote eventing (asynchronous multi-point messaging)...there was an rfc at one point, but I can't find it at [4] now...I'm sure others can help out with where it went.
IMHO asynch messaging can/does support OSGi service remoting just fine (ala JMS-provider), but distributed eventing has other important aspects (e.g. ordering, reliability/group membership, multipoint) that go beyond OSGi service remoting specifically...and thus some additional/new specification (i.e. 'distributed event admin') is also desirable...so I'm in agreement with Christian about that.
Scott [1] https://github.com/ECF/JMS build/binary [2] https://wiki.eclipse.org/Load_Balancing_Remote_Services [3] https://wiki.eclipse.org/Distributed_EventAdmin_Service [4] http://wiki.osgi.org/wiki/RFCs
Best regards Mike Christian Schneider wrote: I am also looking forward to a spec about asynchronous messaging in OSGi. I think the largely snychronous model behind DOSGi and many remoting technologies like RMI and Webservices is not really that useful for remote communication. What I am looking for is a way to send events using pojos over remotely with behaviours like jms topics and queues. Serialization should allow java serialization, jaxb and json. I think the model of communicating over events is much more suitable to remote communication than services. Some reasons: 1. Most comminications are in fact asynchronous in nature. For example almost all UIs do not allow to block the UI thread. So any sync communication has to be done in a separate thread 2. Services with more than on method are difficult to version when changes happen in the contract 3. The method is rather an implementation detail. The communication should rather be defined by the data exchanged 4. Publish subscribe models allow nice extension points where new listeners can be hooked in 5. Messaging servers (like JMS server) often provide nice failover and load balancing schemes based on queues There is a rfp called distributed eventing which seems to look into this: http://blog.osgi.org/2013/06/distributed-eventing-rfp-158-now.html Eclipse E4 has an interesting API for using events too http://www.vogella.com/tutorials/Eclipse4EventSystem/article.html. If there are already some nice implementations like this out there I would be interested about any pointers. Btw. I have written a blog entry some time ago about using camel to do pojo messaging. See: http://www.liquid-reality.de/display/liquid/2011/10/19/Using+Camel+to+do+light+weight+messaging+over+any+protocol This already has some of the abilities I am looking for but I would like to see a solution the ideally only makes you depend on an OSGi spec. So you can stay largely independent of the framework you use. Christian On 03.03.2014 15:39, Mike Wilson wrote:Attempting to look wider than my previous question about remote services, I'm looking at any way to make an asynchronous call from a bundle in one OSGi container to a service in another OSGi container. There's an interesting discussion about asynchronous service calls on: http://blog.osgi.org/2010/04/calling-your-cake-and-sending-it-too.html Have there been any new developments towards standardization of any asynchronous pattern, or is using ECF or making your own still the main alternatives? Or, is the preferred option to use some third-party API directly, such as a messaging API like ActiveMQ? Thanks Mike _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev-- Christian Schneiderhttp://www.liquid-reality.de Open Source Architect http://www.talend.com _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
