What is next after OSGi Release 4?
I am currently working on the OSGi specifications as the editor. Next week is an important deadline: my vacation. I therefore spent a lot of time reading, reviewing, rewriting, processing feedback, answering questions, and other non creative tasks. So now and then I need to escape and do some programming or other thinking.
One key issue that has been on my mind for ages is what comes next? With Release 4 we have created a secure computing platform for networked applications. Usable from mobile phones to high end web servers. Did we solve the task we set out to solve when we started in 1997?
Don't think so. The original goal was to develop a computing environment for household computers; The OSGi architecture evolved around that primary use case. It gave us the management and deployment model so that operators could manage it. It gave us security so that different parties could use an OSGi device for different purposes. It resulted in the service oriented architecture so that these different parties could discover and build upon eachother's services. And best, it gave us the dynamics that are so important to deliverusability. All good stuff, so why are we not yet there then? Why is the following picture not common? (translation: she is starting her washing machine at home with her mobile).
The key problem we have not solved is the composition of the system; What and how services are composed to form a collaboration. The composition is so complex because it requires preferences, constraints, context (location, time, plans), and security. It is so complex, that today this problem is dumped in the lap of the least suitable person: the end user. Last winter I gave a at CASSIS about this subject. A fine specimen of this is setting up Bluetooth or other networks. We all probably know the many configuration screens that must be filled in, with often hard to understand labels. Still this seems to be the only way to configure (sub)systems.
To realize the vision of home automation, we must address this configuration problem. The OSGi Service Platform is a state of the art deployment and component platform and it solves many hard problems. However, we still rely on largely manual configuration to make the systems work, though we can simplify a bit by having the operator in the loop. However, many problems are just to expensive too require any manual intervention by an operator.
This configuration problem has been bothering me for years (my work on ] in Ericsson was partly driven by this). There is surprisingly little work being done in this area. Most researchers shy away from it because it is not recognized as a real problem. I was therefore pleasantly surprised to meet Richard S. Hall last year. He is the author of the open source OSGi implementation Oscar and he is driven to solve the service composition problem. His current research involves Gravity, which is an OSGi based framework for service composition. He has some very interesting ideas to address the service composition problem that he is trying to work out.
Further, I do not know any other people that try to solve this configuration problem. Strange, because if we can create composite systems without (too much) manual intervention, we will significantly reduce the cost of ownership. Better, it will explode many application markets. Maybe home automation might finally come true if we now can also solve this problem ...
Peter Kriens
posted by Peter @ Friday, July 08, 2005
