Back to Stockholm

In the late nineties I worked for 4 years in Stockholm part-time, while actually living on the other coast. 4 years ago we moved to Montpellier in France. This was a good move, but it does not mean we left Sweden without some pain, the 9 years we lived there were very, very nice. Since the move 4 years ago, I had only been in Sweden once, in Malmö at the Öredev conference. I was therefore rather excited when a Swedish company in Stockholm asked me to give a two day workshop. It gave me a chance to meet some friends I had not seen for a long time and these workshops are always fun to give.

I regularly give these workshops and they are invariably a success. I meet people working on real problems creating real products and the group gets access to a lot of experience in designing OSGi based systems and other development issues. Usually, the first day is an OSGi introductory course and the second day we go through their architecture and development organization setup. As said, these workshops are always fun to do, doing one in Stockholm had obviously an extra appeal.

One of the most exciting things about these workshops is that I learn a lot about a domain area. In this case, the company sells ERP systems for manufacturing companies. They actually had been using OSGi for some time, their tool chain was Eclipse based. The company uses modern web technologies and other server side technologies to create a user experience that is much simpler and better suited to their task than the established leaders in their market.

Doing the tutorial and showing how OSGi can be used to simplify the development and deployment process was really interesting. This clearly was an experienced group of developers so we could go through the lower level details quickly. We could therefore spent a lot of time on how the OSGi technology could be used in their domain. For me it is always a thrilling to see when it becomes clear to people how OSGi applications work and and the power that it gives them. It invariably starts when they for the first time start and stop a bundle, most developers find this fascinating. However, they really get excited when they see how their designs can become simpler and more powerful at the same time. After a session like this, I am always puzzled that not more companies use OSGi today, it really does solve some very real problems.

The most interesting session was when got to work on the design for their next version. Initially there was a proposal for decomposition that was more or less functional. By analyzing the existing system and the requirements for the new system we hand crafted an initial design. We used a technique that I first developed for Deutsche Telekom in 2004. A bundle is a sphere and a service is a triangle. I described this technique first in my OSGi blog. I have clearly tried to use UML for this purpose but it does neither have the right symbols for this, nor has it the right granularity. In a service oriented system, the services are paramount, the implementation details come later. UML works better for the implementations. The following picture shows the basic symbols.

During the tutorial I already had used the triangles and spheres so during the architecture session we could really dive into the issue when to use a bundle and when to use a service in their design. The goal is to simplify the complexity of the overall system. Services are extremely useful in this context. Though it is hard to give solid rules when to use a service and when to use a class from a library, it is usually not hard to recognize a good design.

There was one thing that caused us to argue quite long, until they came up with a use case that I had not seen: an abstraction for the database dialect. I must admit that I always thought that the SQL standards were as thorough as the OSGi standards until a year ago when I had to write an application with SQL. I was really flabbergasted about the immense number of dialects, even in very fundamental aspects of the language. So this company had implemented helper classes that allowed them to create SQL for different types of SQL databases. This is similar to the Hibernate dialects. We already had a higher level abstraction defined for the source of data, so I felt that the dialect issue could be dealt with inside the data source model because they only supported a few SQL databases anyway. To me, it was simpler to hide this aspect than to make it a first class citizen because I thought it was a rather static problem. Until somebody told me that certain customers or integrators sometimes want to link in other databases types, for example, an Access or Excel database. Making the helper classes services would enable this; making it an implementation detail of the data source would force these customers to write significant code.

This was a clear example where services shine: plugin models. By making this a service, we allowed the customers to use the system for their purpose, and extend it without losing other functionality. This example highlights a key aspect of a service: it is a point where others can insert behavior.

Obviously, during the remainder of the day we had many such discussions. This was clearly a smart group of people in both technical and other aspects. Instead of trying to discover all these rules themselves, they hired an external person to teach them the beginnings before they committed their designs. I can not recount the number of times when I was hired to help out after the design was already more or less frozen. The saddest thing to hear is: "Yes, you're right but it is too late to change the design." Fortunately, more and more companies realize that a small investment up-front can make a significant difference in cost, quality, and features over the life of the system.

After two days working with this smart group of people, from early morning to late in the evening I am usually exhausted. I still had to travel back to Montpellier, which was over 2500 km. However, it is extremely gratifying to see that yet another group had caught the OSGi bug.

    Peter Kriens

P.S. If you are interested in such a two day workshop, do not hesitate to contact me.