Robust collaboration services with OSGi
2Let's see how OSGi framework is utilized in providing a resilient architecture for maintaining a web conferencing service with mission-critical requirements.
The speaker is Computer Scientist in Adobe, working for Adobe Connect, a web conferencing solution from Adobe. He has been involved in the adoption of OSGi framework in Adobe's web conferencing solution.
Live real-time collaboration is mission critical for any web conferencing solution. Nothing is worse than a technical failure/downtime occurring while hosting a seminar on a web conferencing solution like ours. When dealing with such a kind of requirement, it is desirable to have a framework where a software component failure is isolated to the functionality based on it or at most, the parts which depend on it. Also it should be possible to fix and upgrade the components in isolation without impacting other pieces of functionality. The OSGI framework is a perfect match for our requirement. The OSGi framework provides a mechanism of plugging in/out services from a running server without pulling the server down.
Let's consider a scenario where component of a web conferencing service needs to be upgraded. In one case it's deployed on a regular application server while in the other it is deployed in an OSGi container.
Non-OSGi: Bringing the server down for an upgrade would not only make the concerned part of web conferencing service unavailable but also all other services offered by the server would become unavailable too, thus resulting in an overall downtime.
OSGi: If this service is deployed as an OSGi service instead then it would be possible to just upgrade this service while the other services would continue to work un-interrupted.
Consider our use case of a web conferencing system which provides several services like chat, audio conference control integration with several conferencing systems by means of adapters. Let's assume, there are 2 conferencing providers A and B, with an adapter for each of them. At some point in time, the conferencing system A got upgraded. Consequently we have to upgrade the adapter A to support the changes. At the time of upgrade, provider B has some critical conferences in progress. Now if we use the conventional approach of deploying all the adapters on an application server, we would need to stop it, deploy adapter A and restart it. During this process, conferences of provider B needlessly gets interrupted. Taking this point further, if we had more providers, all of them would have got interrupted because of changes in just one . And these interruptions would be very frequent as one or the other conferencing system would keep changing.
The solution to the problem is to segregate these as separate services and deploy them on an OSGi based server. Adapter A and Adapter B would be 2 now be separate OSGi services. If service A has to be upgraded,only it will be stopped, upgraded and restarted, without disturbing service B. Deploying as an OSGi service ensures code modularity because individual services have a clean separation and can be developed independently. Also an OSGi services' configuration can be dynamically updated on the fly without stopping the server.