Thursday, June 27, 2013

Distributed Eventing RFP 158 now available

It has been a while since the OSGi Remote Services specifications were released. The Remote Services and Remote Service Admin specifications were part of the first Enterprise OSGi release which is available from early 2010. The Remote Service specs focus on using the OSGi Service model to create and consume remotely accessible services. A number of Remote Service implementations have since been created. They use a variety of wire protocols, some of them based on industry standards such as SOAP/HTTP or JSON/REST which allows them to interact with clients written in other languages.

The Remote Services specifications focus however on synchronous interactions. While asynchronous models were indeed mentioned in the original Remote Service RFP, they were not addressed in the Remote Services specifications.

Supporting asynchronous distributed eventing in OSGi through a standard, technology independent API has been on of wishlist of many for quite some time. For certain distributed event based use-cases a people have successfully used the OSGi Event Admin service. While the Event Admin API can be connected to a remote distribution or eventing system, this only addresses a certain type of use case. Specifically, reliability and queue-based semantics are not supported in a 'Distributed Event Admin' solution. For more information on the evaluation of distributing the Event Admin Service, see Marc Schaaf's Master Thesis.

Work has now finally started on a more general Distributed Eventing RFP at OSGi. This RFP looks at introducing a general Distributed Eventing solution into OSGi. You can find RFP 158 in the OSGi buzilla system here:
I you have any feedback, just leave a comment.

Oh, and just a reminder that this is an RFP, which is a requirements document. No design is yet captured in this document. The design will be part of the RFC work that is started after the RFP is done.


  1. Hi David,

    I have a couple of comments about the RFP...but they are probably going to end up being too extensive to post as a comment on this blog. For example, given the requirement that 'the solution must support one-to-many, pub-sub/topic messaging semantic' I would expect some more discussion in the RFP over requirements wrt reliability/failure detection and event ordering. This probably just needs to be added, but I do think it's going to be important to begin that discussion.

    I am not able to login to the rfp bug, so can't add a comment there. Going forward, how best to convey comments?

  2. Hi Scott,
    The best way to post comments is to log them as comments on the bug where the RFP is posted:
    Ah... I see that you actually did that already.