Nine years ago, when we started working on the OSGi specifications, we used the word
service to describe the object that acted as a conduit between bundles. Today, Service Oriented Architectures (SOA) are hot and every software vendor seems intent on confusing a muddy picture even further by bringing their products under this wide umbrella. The result is that many people file OSGi under
webservices, as the most popular exponent of SOA,
and then conveniently ignore any further documentation because they already know what web services are. As an example, a friend of mine consistently gets his papers rejected because many of the reviewers make this very false assumption.
A bit of history. In 1985, I was developing systems for the newspaper market and we just started our Magnus Opus: a newspaper page makeup terminal (this was the time that a
25 Mhz 286 was state of the art). This product was of strategic importance for our company and I did due diligence on a lof of languages to select the best one for this project. After discovering
Smalltalk/V 286, I fell head over heels in love. I thought object oriented (OO) software was the best thing since sliced bread! I never had been comfortable with the common design methodologies at that time called
Structured Design. Discovering OO felt like coming home after a long journey. After grasping the technology I made my second worst advice ever (the worst was when I told a programmer friend in 1994 that building an e-commerce shopping cart application was a silly idea, sorry Matts). I told my manager that if we started to build our systems using objects we would be able to get fantastic reuse after a year or so. Obviously under the condition that he allowed me to go to all these cool conferences like the
OOPSLA. I assured him, new applications could be build in days instead of years, just using objects ...
Well, as most of us know it did not turn out this way. Yes, we got a lot of advantages using OO technology but reuse turned out a lot harder than we thought. Sadly, I think the key cause of the lack of reuse was the violation of the two sacred rules of Structured Design: low coupling, high cohesion. It was very much like a couple of girls on the beach trying desperately not to expose themselves to the boys in front of them while changing into their swimming gear; not realizing that there were also some boys sitting behind them. We were so busy hiding our data in instance variables writing get and set methods that we never realized that we were exposing the
object structure to anybody using our classes. That is, if you do
new Foo() from class
Bar, you just coupled the classes Foo and Bar for eternity. Trying to reuse Bar immediately drags in Foo. Now if Foo and Bar had been cohesive (meaning they are really parts of the same function) this would not be such a problem. However, because we were so busy writing get/set methods we mostly ended up with systems that had transitive dependencies that basically included all classes in your company's repository. If you want to see an example, write a "Hello world" program with an empty local Maven repository. Not only made this coupling reuse very hard, the coupling made making changes also very complicated because many changes were far reaching.
At the end of the previous millennium our industry learned many hacks to reduce this structural coupling; the most (in)famous is the
Factory pattern. This pattern allowed you to manage the coupling outside the original program by moving the coupling to a runtime decision. However, it is a hack. OO languages have no built-in answer to this problem, just look at the large number of attempts one can find in Java to solve this coupling problem.
Also, if you look at one of the great insights of the last decade, Inversion of Control (IoC), you see that this is really about decoupling. IoC (or the Hollywood principle of "do not call us, we will call you") takes an object and provides it with its dependencies instead of this object trying to create its dependencies. This simple idea allows for POJOs, objects that are minimally coupled.
Services are trying to solve the same problem: minimize complexity by decoupling. The key insight that lead to the service model is that the OO has an important role in modularization on the small scale but we need something of a bigger granularity on the larger scale. A modularity that minimizes coupling to well defined conduits between coarse components. This was exactly the problem we tried to solve since that 1998 meeting in the Research Triangle Park in Raleigh where the technical OSGi work got started. Our key assignment was to let software from many different
service providers collaborate in a single residential gateway. Trying to standardize large class libraries with highly coupled frameworks would have taken forever and it would have done a terrible job. By focusing on the coarse components (the bundles) that would collaborate through objects named by their interface that were found in a registry (the services) we created a model that had minimal, well defined, and documented coupling between bundles.
The key advantage of SOA is therefore the reduced coupling between the blocks of a system. The model became wide known with Webservices because Microsoft and IBM decided to put a lot of marketing dollars in that direction, making SOA almost synonymous with XML, SOAP, HTTP, some other acronyms, and associated distributed computing problems. It is not. Service Oriented Architectures reduces the complexity caused by not managing structural coupling by providing well defined conduits between components. Webservices achieve this using a myriad of acronyms, OSGi technology achieves this by using an extremely low overhead in-VM service publish/find/bind model.
So the key question is if the confusion between Webservices and OSGi is doing us harm? I think it does, many people fail to look further because they assume they understand. For example, I am flabbergasted that leading software magazines like
ACM Communications and
IEEE Software never had an in-depth article about OSGi technology because I strongly believe that the ramifications of this technology for our industry are profound.
Peter Kriens
