One of the things I really like about my job is that I get to spend time working with students. As a software engineer working at EclipseSource Victoria, I spend part of my time at the University of Victoria helping master’s and PhD students with their research. I have also taught and TA’d a few course at both the University of Victoria and the University of Waterloo.

One of the things I don’t think we teach very well at University is software components and modularity.  Students get a brief introduction to the concepts in their first year data structure courses.  In these courses students are  taught that if you “hide the internals” and code to a “known interface” then the implementation can be changed.    This is often demonstrated by showing them how you can create a stack using an array, and without the client knowing, the stack can be changed to use a linked list.

While it is important that students learn this, there is no practical way you could replace the implementation in any binary compatible way without considering a number of other factors.  And while the example may barely work for a stack, it doesn’t scale to anything larger than a single class.  It is often explained that packages and jars are the next abstraction up, and students are told that things generally work the same.  The truth is, packages and jars are a pretty poor form of software modularity.

I have decided to put a lecture together to demonstrate software components and modularity in the large. Enter OSGi.   Since OSGi has been around in one form or another for over 10 years, I thought it was about time students (and more importantly faculty) see how it provides a scalable method for software modularity.

The lecture hits three main points:

1. Versions.  While not necessarily an OSGi thing, the concept of versioning your API (both by versioning bundles and packages), and evolving your version number in a controlled manner (Major.Minor.Service.Qualifier) as your API evolves, allows consumers to understand and adapt to API changes.
2. Explicit Dependencies.  Since software components are rarely built in a vacuum, it is important to explicitly state what you depend on.  This allows your consumers to understand what you provide and what you require.  Instead of just dropping in the updated Stack bundle, the consumer can verify that they have the required linked list bundle.
3. Information Hiding.  Every first year will tell you that information hiding is a fundamental principle behind data abstraction.   Why languages don’t support information hiding at all levels of abstraction is  beyond me.   I demonstrate how OSGi supports internal / external (and x-friends) packages, and how these can be used to design reusable components.

I also talk a bit about bundle life-cycles, services, and class loading, but the bulk of the talk focus on the three points listed above.

if you were teaching OSGi 101, what would you cover?

What are your top 3 points?

Related posts:

• OSGi Declarative Services Tooling
• OSGi Import Package and Split Package Woes
• Building Your Equinox OSGi Application Server – Part 2
• Tip: Eclipse, OSGi and Execution Environments
• OSGi in Dublin

• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 

Tags: OSGi