FW: OSGi spike for the platform

[Sanchit Bahal]

I had sent this mail sometime back, but doesn’t look like it got delivered to the group. So, sending it again.

 

Thanks,

Sanchit Bahal

Mobile: +91 9980141983 | Y!: sanchit_bahal | Skype: sanchit.bahal

 

From: Sanchit Bahal [mailto:sba...@thoughtworks.com]
Sent: 23 December 2011 12:12
To: motech-ar...@googlegroups.com
Subject: OSGi spike for the platform

 

Hello,

 

Here is a brief write up on our findings from the OSGi spike card that we had played some time back.

 

Tool used

 

Eclipse Virgo (http://www.eclipse.org/virgo/)

 

Virgo comes with an embedded Tomcat server. Overall, Virgo is supposed to ease out running any spring-based application in OSGi mode.

Please refer to the excerpt below from Virgo’s documentation.

 

The Virgo Tomcat Server is built on top of the following core technologies:

• Spring Framework, obviously!
• Tomcat as the web container.
• OSGi R4.3.
• Equinox as the OSGi implementation.
• Spring Dynamic Modules for OSGi for working with OSGi in a Spring application.
• SpringSource Tool Suite for developing applications.

Note, however, that the Virgo Tomcat Server isn’t just a combination of these technologies. Rather, it integrates and extends these technologies to provide many features essential for developing, deploying, and managing today’s enterprise Java applications.

 

Understanding / Approach

 

The OSGi container would follow the lifecycle of the Virgo server, i.e., the OSGi container would come up with the server start, and would be brought down with the server shutdown. Each module in the platform would be installed/deployed as a bundle in the OSGi container.

 

The OSGi container has a shared service registry which would be available to all the bundles deployed in the container. The individual modules would register their services into this service registry, and the bundles that want to consume these services would query the service registry to provide a service instance to work with. This way, the bundles would be able to use the services that they want to, still being independent of each other.

 

The application (say TAMA) would also be deployed in the OSGi container as a bundle, and it would be interacting with the container’s service registry in order to consume the services.

 

We tried out this approach with the motech-alert-api module in the platform. motech-alert-api  module registered the AlertService to the container’s service registry. In turn, TAMA (which is also deployed as an OSGi bundle), queried the service registry for an instance of the AlertService, and used that to send out alerts.

 

Things that still need to be explored

 

·         Should the application (say TAMA) be capable of starting the OSGi container? Is that even a valid requirement? This would not be possible with Virgo though. A related question - Will a non-OSGi application be able to access any bundle from outside the container?

·         In the example above, at build time, TAMA’s pom.xml would have a direct dependency on motech-alert-api module for the AlertService contract. Is it possible to work with the OSGi setup at build time? This can be achieved by separating out the service contracts and implementations in two separate modules, e.g., motech-alerts (for contracts) and motech-alerts-api (for implementations).

·         Once we convert all the platform modules into OSGi bundles, will they still be usable in non-OSGi mode? Do we even need this?

·         Virgo has support only for Tomcat and Jetty servers. If we go ahead with Virgo, would we not tie the platform just with these two servers? Can this be looked as a limitation?

·         We encountered some performance issues when we tried running TAMA as a .war in Virgo. Need to investigate further on this.

 

The above understanding/approach is still in strawman state, and needs to be ironed out. Please provide your inputs, and validate our understanding of how we would like to introduce OSGi in the platform.

 

Thanks,

Sanchit Bahal

Mobile: +91 9980141983 | Y!: sanchit_bahal | Skype: sanchit.bahal

 

[Rob LaRubbio]

Some comments inline

On 01/03/2012 03:12 PM, Sanchit Bahal wrote:

Understanding / Approach

 

The OSGi container would follow the lifecycle of the Virgo server, i.e., the OSGi container would come up with the server start, and would be brought down with the server shutdown. Each module in the platform would be installed/deployed as a bundle in the OSGi container.

Sounds good.  I'd also like to see us take things that currently aren't modules and move them over.  So the IVR and Rules core platform features would move into the module space.  Perhaps even the scheduler and some other pieces of functionality.

The OSGi container has a shared service registry which would be available to all the bundles deployed in the container. The individual modules would register their services into this service registry, and the bundles that want to consume these services would query the service registry to provide a service instance to work with. This way, the bundles would be able to use the services that they want to, still being independent of each other.

Yes!

The application (say TAMA) would also be deployed in the OSGi container as a bundle, and it would be interacting with the container’s service registry in order to consume the services.

Yes!

Things that still need to be explored

 

·         Should the application (say TAMA) be capable of starting the OSGi container? Is that even a valid requirement? This would not be possible with Virgo though. A related question - Will a non-OSGi application be able to access any bundle from outside the container?

I would say no.  I think it's ok (if writing an application as a module is not that much extra work) to say that is how you develop ontop of our platform.  I also think we can punt on the related question.  I think each module should also expose a REST interface in addition to the service interface so an external app should be able to access that.

·         Once we convert all the platform modules into OSGi bundles, will they still be usable in non-OSGi mode? Do we even need this?

I would say they should no longer be usable in non-OSGi mode.  It sounds like it could complicate our work and I'd like us to focus on getting the modules working well in one mode rather then getting distracted.

·         Virgo has support only for Tomcat and Jetty servers. If we go ahead with Virgo, would we not tie the platform just with these two servers? Can this be looked as a limitation?

I think this is ok.  Tomcat and Jetty are popular if we list that as something we support I don't think it will harm adoption.

·         We encountered some performance issues when we tried running TAMA as a .war in Virgo. Need to investigate further on this.

Hopefully that can be fixed.

-Rob