OSGi, SOA and Web Services

(Closing my account at blogpost I made some referenced posts unavailable, so I repost this article as I was asked)

While reading Peter Kriens (OSGi Evangelist), latest blogpost at the OSGi Blog, about the relation of OSGi and Service Oriented Architecture, I felt the need to write about this, in simple tech-terms, as simple as, a newcomer (proud me) could describe OSGi(and it's position in this great set of SOA).

Several months ago I was called to participate in a development team that had to construct a concrete solution, considering OSGi as the core service management platform of this project's part. So both a beginner in Java and in OSGi, I was trying to bring myself in productive state by learning quickly what OSGi is.

OSGi is a Java-Based platform, consisting of three major inseparable components: The Framework, The life cycle model, The service registry. OSGi technology provides a service-oriented, component-based environment for developers and offers standardized ways to manage the software lifecycle. Played around with a couple of OSGi implementations and finally choosing the best appropriate for our needs, Equinox.

OSGi is maintained by the OSGi alliance. The latest revision of this project is 4.1 / May 2007. From my point of view there is one thing that someone can do in order to learn about OSGi development. To start reading the OSGi bible directly from the Alliance. As you will see during the specification book, OSGi is a sophisticated middleware. You provide functionality, you declare interfaces, imported/exported services and that's it. Your first bundle (the component of OSGi providing a specific service). There are numerous tutorials and samples with a quick scan in the above links. This isn't my intention here. So enough so far with the OSGi part, here comes the conflict with SOA.

So, during the development process of my aforementioned assignment (and as a newcomer, undergraduate student, trying to settle down with definitions and technologies) I was trying to place OSGi in my mind considering the core model that OSGi belongs/represents. At around March 2007 my first inquires came at the OSGi list, OSGi and Business Logic. Clear answers didn't came. Development continued. Later on, another task was brought about. A typical project as a part of a course that I was attending at uni. It was a presentation about Service Oriented Architecture. I grabbed some tutorials and text's. Do you know what was the first thing that I did? CTRL+F and after that "OSGi" at my sources. "Nothing found". My sources kept on and on with Web Services, loose coupling, XML, Communication protocols, discoverability, reusability, in XML, and again and again, then continuing with Enterprise integrations and matters like that. 2 things now represent what SOA is, from my point of view.

• The service-oriented architecture introduces a new logical layer within the distributed computing platform.
• The service integration layer establishes a common point of integration within application tiers and across application boundaries.

(picture scanned from a very nice book about SOA, Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services by Thomas Erl)

Now the voice of an OSGi junior. OSGi is a managed service oriented architecture by itself not some short of Web Service.

• Web Services are the building blocks of the most Service Oriented Architectures. This design approach, results in the creation of isolated units of business functionality loosely bound together by a common compliance to a standard communications framework (http at the 99%).
• Bundles are packages of functionality that consist the building blocks of OSGi, a Java-Based middleware that you can use in order to orchestrate functionality modules that can cooperate both locally and remotely. It can, enclose web services, it can become part of a bigger SOA with bundles as Web Services.

To sum up, Service - Oriented Architecture is neither web services, soap, XML nor OSGi. Technologies are based on models, models shouldn't be connected with implementations.

Well, that is for now.

Any comments are more than appreciated.