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: https://www.osgi.org/bugzilla/show_bug.cgi?id=168
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.

I am back ...

Since last week, I am back, working for the OSGi Alliance. To some this may come as a surprise but talking to people it seems that many actually had expected this.

So what happened? In the past year I've developed a repository (https://www.jpm4j.org) from scratch. Partly because I think such a repo is absolutely necessary, partly because I felt I needed to make an enterprise like app so I knew better what I was talking about. Both succeeded; What did not work out as hoped was commercializing it. I guess business aspects have never been my strongest point :-( and there is only so much I could spent on this sabbatical.

However, this was not the only aspect that made me return. Though I wanted to keep a distance of OSGi in the beginning I developed jpm with OSGi in the way that I've always have advocated: Services first. The good news was that to my great relief, this actually worked much better than I told people. I am now more convinced than ever that the OSGi service model is a true innovation that is highly undervalued in the industry. The bad news was that it required the development of too many basic components just to get started. Though there are an amazing number of libraries and bundles out there they often look awkward  because they do not leverage the unique advantages of OSGi: services + configuration admin. For me it became clear that the threshold to start with OSGi for a real web application was way too high.

After talking to some OSGi Alliance people we proposed to create a 'starter-kit' that would enable developers to start on a much higher level than a servlet. It should provide a foundation like a Ruby-on-Rails but now based on the much more scalable OSGi technology. On top of this foundation we plan to add a real application, demonstrating all the OSGi's best practices. This was proposed to the board and they actually wanted me to start weeks earlier than I had planned. So here I am!

I will therefore  be working on a foundation for OSGi web applications. If you have ideas, let me know. I am sure to keep you posted via this blog and twitter.

Peter Kriens