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
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
Hi Peter,
ReplyDeletewelcome back :)
For your web-application project take a look at what Pax-Web is capable of right now. Just deploy a Servlet 3.0 annotated bundle and it'll pick up your servlets and will deploy those as Services, this is by all means the fastest way of deploying Servlets in OSGi right now ;)
regards, Achim
Hello Peter, welcome back!
ReplyDeleteI would like to suggest a more generic application container model based on OSGi Application Admin. Thus, tighter integration with Resolver, Repository, Configuration Admin, etc. I personally also think that single bundle (packaged) apps with service dependencies (most probably only consumers) should also be considered more closely. This is about clear distinction of modular platform architecture from app containers.
Best regards,
Martin
Welcome back Peter. Will you be resuming your role at the helm?
ReplyDeleteWelcome Back!
ReplyDeleteHard to stay away from things you're passionate about! :)
Looking forward to see what's next. Some of the Frameworks and APIs from the early OSGi days are still my most favorite and elegant programming patterns!
@Achim: I will try to use as much as possible from what is out there but I hope to have a higher abstraction than servlets since the industry is moving back towards fat clients, but now in HTML5.
ReplyDelete@Martin: Point taken ... :-) I'd like to make it no-compromise DS µservice based
@Victor: Never was at the helm :-)
@Christian: Nice to hear!
I encourage you to consider the body of work that has come out of Spring & Equinox: Virgo.
ReplyDeleteIn many areas, Spring has served to make the developer's experience better. This was true in Spring DM, and later in Virgo (essentially eclipse Equinox + Spring OSGi goodies).
Please, include in your effort, if possible, at least meeting, if not collaborating directly with, the Spring guys. They bring an incredibly refreshing pragmatism to all of their portfolio projects.
My $0.02.
-matthew
Hi Peter,
ReplyDeletegood that your are blogging again.
My 0.02€:
Kai Tödter has a nice demo with Vaadin based gui bundles at http://www.toedter.com/blog/?p=412. By starting and stopping bundles parts of the gui change...
When going the rail ways(T) you might need to generate things. If this is the case have a look at scupltor.
It has a DSL for Domain Driven Design which can create CRUD dialogs (http://fornax.itemis.de/confluence/display/fornax/5.+CRUD+GUI+Tutorial+%28CSC%29). It's default output is a monolithic war but internally code is separated into layers as DDD strives for loose coupling as well.
In any case I'm looking forward to see what you will come up!
Jörg
Peter:
ReplyDeleteI am curious if "bypass servlet altogether" approaches are also on your path? See:
http://vertx.io/manual.html
http://underlap.blogspot.co.uk/2012/06/osgi-case-study-modular-vertx.html
Andrei.
Just wondering: why has Sling not been mentioned? https://sling.apache.org/
ReplyDeleteHi Peter,
ReplyDeletewelcome back :)