I hope you've enjoyed reading this book and have learned enough of the basics to drive yourself to follow the fast-paced OSGi evolution. This appendix attempts to motivate you further by introducing some of the slightly more advanced topics you could follow through as the next steps.
One of the interesting aspects of the development of an OSGi service platform you should have understood is that you're not bound to a specific implementation provider: an OSGi-compliant bundle runs on an OSGi compliant service platform.
This appendix suggests a few other topics that should be at a close reach, with a good understanding of what's been learned here.
In this appendix, we will take a few brief overviews:
Of course, those are not intended to be full introductions, but should give you enough keywords and concepts to follow on and research on your own.
We've briefly mentioned OSGi Declarative Services in Chapter 1, Quick Intro to Felix and OSGi, without going into the details. The provided functionality helps with the process of publishing, binding, and finding of services. It also handles service dependencies.
In this book, we've looked at iPOJO to assist us with this task. It's an alternative to Service Component Runtime of OSGi declarative services in that it provides similar functionality through different means.
Declarative services define the service components, their properties, and references to other services, using an XML descriptor kept in the bundle's OSGI-INF directory and referenced from a manifest header (instead of it being encoded completely into a header, as we saw with iPOJO).
Refer to the Felix Service Component Runtime bundle and its documentation at http://felix.apache.org/site/apache-felix-service-component-runtime.html.
Another available alternative to OSGi Declarative Services to do some research on is that proposed by Spring Dynamic Modules, which introduces Blueprint Service specification.