Something different!

Running into somekind of wall back in 2005, there was only one way to go. Where everyone else was going. Found something great on the fly while still struggling to get the most of my knowledges. Turned out that some guys had been having some great ideas and managed to create something that at least paid for their breakfast.

DotNetNuke.

Quick, dirty, ugly. Windows. Visual Studio VB - yuck. But, wow. There it was. A whole portal just for free. And with system services. Or "services" I should write. Modules I mean! And a third-party market!!

to be continued...

Inventing the wheel

This might appear as complete non-sense even to a developer, but anyway, I decided to write down what I made in 2003 program-wise - or at least what I was trying to do. I was working more or less alone in a project and saw some patterns that always returned when I was trying to make services, application, processes and machines communicate with each other.
Basically, the first problem was quite simple. SNMP is a simple protocol (hence the S) and surveying equipment with an SNMP-IO is simple. At least it should be, but some limitations makes it complicated. Turns out that an SNMP-IO is a piece of hardware that one can connect wires to. If the SNMP-IO signals a 1 on a specific port it could correspond to an alarm of some sort (fire in the server-park, an open door, it’s raining again). Of course the technician installing the alarm knows exactly what it’s for so it’s easy for him/her to just configure the port’s description to be for example “TA cab B5”. The operator however that intensely stares at the alarm list 24/7 would like to have something else. For example a longer text (no can do in the SNMP-IO), or even better a unique description number that refers automatically to a database of texts describing the cause of the problem, the location (coordinates), appropriate measures, phone numbers etc.
So, this text needs to be edited or translated or transformed into something different. Wouldn’t it be nice to do something generic, re-usable and idiot-proof? The SNMP-IO and it’s ports can form keys that would create a unique identity. These keys could be mapped to different kind of configurable values. So the incoming SNMP must be read, processed and transformed and sent into an application (for example HP OpenView NNM) for presentation. HP OpenView NNM listens on a specific port and one has to use a library and call a specific method. And of course it could run on a different computer.
So, we also need some network protocol in order to translate the simple text to something more useful. XML might do just fine - something generic at least. Hmm, what might be needed?

from, to, subject, content

“From” and “to” might need an IP-address plus a port number. Subject seems to be needed and the content should be dynamic. A DTD might be useful? Ouch.
So we need an XML-parser and an SNMP-adapter of some sort. The adapter should be of any protocol in order to be enough generic.
What to do with the processing of the message coming in from the SNMP-IO? We have to map this to something different. An SQL-database would certainly solve the problem but it might be over-kill in this example. We could store a simple Hashtable-object as an editable text-file instead. Plainly, mapping keys to values. How difficult could that be?
Format:

key_1;…;key_n; = value_1;…;value_n

A find-method would return the correct value(s) for a specific key. For the setup of the light database we need a GUI. Configurable table-headers, number of keys and values and configurable delimiters. We also need to use wild-cards when searching. When creating the simple database we need to read large configuration files that hold the configurations (description texts), these files of course contains errors, null fields and fields with illegal characters so we need some generic exception handling. And we need to be able to present the errors and allow the operator to fix them. It must be possible to define the out-format.
<…snipped, 4 pages later…>
And there we go… bingo, it works just fine! All services in the OSGi framework acts together, huge amount of code producing the single task of translating the “TA cab B5” to something more informative and editable! And we have code that we can re-use, we only need to do the adapters, some more GUI’s and sell it on the market! Right before the deployment and real use of the code, the customer changed direction and said: “Nice work, we need to be doing something else instead. The surveillance of this equipment will in 3 years be obsolete so thank you for your time and effort.”

Back to the future
Now, in 2007 the market is ready finally to take the leap to SOA and mainly Web services architectures (wow). Customers ask for .NET (that seems to be working) and something else that also seems to be good - business processing! One service handling an on-line order for some stuff, sending it to server that processes it: checking if it is a valid order, checking shipment and sending a message to another machine placing the order. This is the typical scenario. But the scenario keeps coming back in all sorts of situations. An alarm system needs to be connected to a video system. When an alarm goes of a camera shall be activated and the operator should get a wake-up call.
A person enters a door and uses his id-card a message should be sent to a machine.
Eight databases shall be analyzed and be given a generic interface in order for 10-12 applications to work together. And so on. What are the customers asking for and what is the most popular recommendation? Hmm, BizTalk, BizTalk and BizTalk.
I’ve now seen quite a few demonstration movies both from Oracle and Microsoft and they all have understood the pattern. I just wish I had known what I really was doing back then – I wish OSGi had invented the BizTalk concept back in 2001. I’ve noticed I’ve become quite happy with working with configuring (which however, is not like laying on a bed of roses) instead of doing the actual programming.
After all, that was what it was all about in the first place - producing re-usable code!
© 2007 Christer Hellberg

The Deployment Perspective

Implementing re-useable services
You have documented your design, made your choices and all you have to do now is to implement the solution that will make your customer happy. You expect no hard difficulties, although you have calculated with a lot of extra hours. After all, this is computer science. How do you also make sure to produce software that you later can re-use in the next customer project?

Background
This is one of those projects that aim to increase usability in a system and make hardware visible and accessible in software that doesn’t support the hardware’s interface. What we have is a Network Management System (let’s call it NMS), one radio base station and an SNMP-IO that all sorts of devices and alarms are connected to. The NMS is sort of an open tool for managing devices in a network. It finds the equipment in the network, creates icons and let’s the operator have an overview of the status of the different devices running. The SNMP-IO is not that important for our little example, I might write a book some day on how we implemented the solution for that. The radio base station equipment is simple enough to cause us problems. One more little detail; we are having a Unix-based system in which everything should reside. Also, the solution should easily be moved to a Windows platform.

Figure 1: The NMS and the managed device.


A Network Management Example
The choice was made to implement an OSGi solution to integrate the radio base station (let’s call it DeviceA) with the NMS. The OSGi standard uses a service-oriented architecture in where services with standardised interfaces can be installed, started, stopped and uninstalled remotely.
Java seemed to be wise to use since the customer uses other platforms as well. It seemed like a good idea to separate software dealing with the NMS and software dealing with DeviceA. What the costumer needed is a way to present a GUI for A in which an operator can remotely manage the radio base station. It must be possible to read the status, make configurations and lastly to perform diagnostic tests that DeviceA provides. The communication protocol is SNMP (Simple Network Management Protocol) and it is sent over IP. The NMS will handle lots of other devices so DeviceA must appear as any other supported device and be fully integrated.
Let me just briefly inform you about technical surveillance of equipment. For example, if you have a sensor in a door that will send out a binary 1 if the door opens and a 0 if the door closes, then you can have this sensor connected to an SNMP-IO. Each time the status of the sensor changes you can have the SNMP-IO send an SNMP-trap (an alarm) to the manager of the SNMP-IO; in our case the NMS.

Figure 2: The SL-81 SNMP-IO


SNMP-traps are sent with SNMP on a certain port number, so an NMS must listen on this port number. DeviceA sends traps whenever something is wrong with the device. You can’t have several listeners on the same port so the NMS must have some functionality to pass on the incoming traps to other interested applications. In our case, the NMS provides a C/C++ API that supports this. The Java API does not however.
So our Java solution needs a complement that will communicate with the NMS regarding SNMP-traps. We need the traps to be in a general format so de C/C++ data object must be transferred into a text based XML-format. In order to communicate with DeviceA we need an SNMP-service. The XML needs to be parsed so let’s have an XMLParser service. We need to make NMS API-calls (adding icons, setting/getting statuses etc) so NMSService will be an important service. We also need a service that handles the incoming XML-traps, a service for DeviceA and the GUI for it. The GUI should open in a separate window so we’ll have to use a Java JFrame or similar. Any kind of configuration that we need to save should be handled by a PreferenceManager. We don’t want every service to have configuration storing functionality.
This leaves us with the following services described in Figure 3.

Figure 3: Services needed for the solution.

This is not mainly an object-oriented design. We abstract “objects” on a higher level and we call them services instead. There are a lot of advantages with a design like this. Firstly, you at least make it possible to develop decoupled software, the services are stand-alone to some extent only relying on the framework and standardised open interfaces. This means the services can be re-used later on. Secondly, services share the same resources. You don’t have to implement a configuration manager in each service. You don’t need to handle logging issues in every service. This is handled by one decoupled service. Thirdly, having made a generic open interface you can later on replace any of the services to a newer and hopefully better service.

Snippet A: Code to start and stop the service. package companyproject.snmp import org.osgi.framework.*; import java.util.*; public class SNMPActivator implements BundleActivator { public void start(BundleContext context) throws Exception { // start it just like with static void main } public void stop (BundleContext context) throws Exception { // stop threads etc. } } Snippet B: Code to register the service in the framework. _context.registerService( SNMPService.class.getName(), _snmp, _snmp.getProperties()) Snippet C: Code for access to another service in the framework. ServiceReference ref = _context.getServiceReference(SNMPService.class.getName()); SNMPService _snmp = _context.getService(ref);

By a generic interface I mean that you should use for example a getProperties()-method instead of 10-20 get()/set() methods for each property.
Let’s have a closer look on the services. The SNMP service a communication protocol service that would take months to develop from scratch. There are some open source implementations and if you look at the source you’d also probably implement around 36 classes handling all sorts of data-objects. We were not interested in doing that.
Instead, all we needed was to add an OSGi-layer. That is done by creating a Java-interface and replacing the “static void main” method with a start and a stop method, like in Snippet A. This is what you fundamentally do. In order to be seen in the framework you’d also have to register the service like in Snippet B. To get access to other services in the framework you must get a reference to the registered interface and then fetch the service itself, as done in Snippet C. The installation of the service is in this case handled by a service that reads a configuration file when the framework has started. You specify which services to be started an in which order. You can later when the framework is running install other services, start and stop services (for upgrade for example) if you want remotely on the fly.
So, which methods do we need in the SNMPService?

package companyproject.osgi.snmp import java.util.*; public interface SNMPService { public Hashtable getProperties(); public long send(SNMPMessage msg, Hashtable resendPolicy); public void receive(long requestId, SNMPMessage snmpMessage); }

That might just be all. There is still a question on how other services get notified on incoming SNMP-traps so we need an SNMP listener interface also with like two methods in it. First we implemented a solution where the traps were registered in the framework as an SNMP object. Then every SNMP listener was notified of the new object and could act upon it. Right after the registration of the SNMP object it was unregistered. But, this was memory consuming as the SNMP objects continued to be held in memory in spite of no references to it was kept. So the SNMP objects was redirected directly to any SNMP listener instead of using the framework registry. Seems complicated? It’s not.
We have the following diagram:
Figure 4: Description of software modules.

I will not get into the details of the diagram, but you can see that there are some different ways instructions are going, and then there’s also communication between the services in the OSGi framework. The NMS API is huge so we tried to scale it down to a number of methods that we really needed. We needed to get hold of the different objects that the NMS supported and could find in the network and we needed to add some objects that we needed to create on the fly. So for me personally, I was relieved when I could put my own methods into the OSGi service that would map to the corresponding NMS API methods, for example:
ApplApiDbListObjectsByFieldValues(ApplApiFieldBindList fieldList) would instead become getObjects(String[] fieldValues) – phew! Perhaps I could also mention what we did with the SNMP traps that we transferred into XML. The outgoing format became:

That was also a relief.
The Java SNMP object has basically one method and that is getProperties(). We added only a few convenience methods.

Surely now nothing can go wrong…
One of the good things with Unix-based systems is that they do exactly what you tell them to do. Now, adding multi-user functionality to the NMS should not be a problem, but we found out that a certain variable used by XWindows and the NMS would not only reveal but also wake up a giant bug that was to be the one factor that crashed our budget. This T-Rex bug forced us to come up with a slightly different design than we had from start. So what were the features of the “little” fellow then?
XWindows uses a variable called DISPLAY that tells which screen a window should appear in. This variable is read when the Java Virtual Machine is invoked and cannot later be changed – wow! This means if I’m the first one to start the NMS everything will work fine. I open the DeviceA GUI and will be able to whatever I want with it. But if another person (let’s say he sits in Australia) has already started the NMS and then when I start my session, any attempt to try and open the DeviceA GUI will make that window to pop-up in Australia instead of on my screen in Sweden. All according to the slogan: “Run once – display somewhere else”?
This bug is well documented for example bug with the id 4670851 in Sun’s Bug Database. We would have foreseen it if we had had any experience with XWindows before.
In order to get it right we’d have to run a separate Java-application that is started with every NMS-session. This extra little application must handle SNMP-calls, NMS API calls, receive traps, and create GUIs. I would basically be a flat non-service application that would make the original design obsolete. And with ten users logged in it would create an absurd amount of software running just to open a window on the right screen.

Do or die
We could either close down the whole project or continue to finance it ourselves. We chose to continue but no-one was happy about it at all. We had fallen into a well-known pit and had to dig us out by ourselves.
Luckily, we already had a Transport service developed in another project. The service can send Java-objects between different Java-processes that run on different machines (not using Remote Method Invocation). Locking the IP-address to the local host IP and using a range of ports would make it work in one machine and with no security issues to worry about.
Since we had implemented the solution in a object-oriented high-level language we could use the advantages of the object-orientation. This means it is possible to extend classes and use functionality in several places. In our session application we could extend the key classes that represented the services and then pass requests and replies to the real services via the Transport service. Most of the classes could be re-used, some new interfaces had to be created and a whole lot of work was spent to get the API calls to the NMS work as expected. There was also an issue with read/write permissions in the NMS. The diagram in Figure 5 describes the new design.

Figure 5: A new design with the session support.

Although we might have implemented a whole lot more than we needed from start with this service-oriented design, I’d say without it we’d have a lot more problems to worry about if we had made one big application instead. Thanks to the robust design we could re-arrange the code so that it could handle the new situation.

Conclusions
It’s important to focus on what was created in the end. We managed to create services instead of applications; we managed to build in functionality into an NMS that we now can re-use. We have opened up the NMS so that it now can support any other device or protocol that it does not support. We, instead of the vendor, have made a general OSGi bundle that can be extended with whatever we later need. We managed to create 3-4 service more that we will be able to re-use. We developed another re-usable database service that we didn’t decide to use, but it’s possible we’ll have use for it later.
We did not hold the budget frames, but the investments that we have made can lift us to another level when producing software in the future. The design fell apart due to an out of control horrendous bug, but we could still use our implemented design to recreate the functionality!
The services are now deployed and I long for the day when we’ll need an upgrade or when we can re-use our services in another project. It’s like having made one wheel and to wait for the making of three more and the chassis.

The System Designer's Perspective

The System designer’s dream
Imagine one day your boss comes into your office and say: “Hey, I’m feeling happy today, here’s 10 million dollars, do something useful for me and mankind for a year and let’s talk again after that. If it seems good you’ll get another 10 million.”

Background
You might not believe there could be such a situation, but never mind that. Let’s just play with the thought. You might not be up to such a task, who would? But, you’d have nothing to lose and let’s say also that you could be the software dictator of the world demanding unrestricted obedience. Let’s also say that you’re not Charles Montgomery "Monty" Burns of the Simpson’s. Seriously, what would you do for the benefit of mankind that would surely render you another 10 million dollars?

What to do with it
Since you have been struggling with software development half of your grown up life, let’s see what annoys you the most. First in mind might be to invent a decent test-editor and finally get rid of that Notepad on your windows system or that VI for that matter. Wait a minute that must have been done already. Maybe you could develop another Operating System? That would be pretty cool, and then just hand it out to the world for free. Nah, that’s been do too I guess with Linux. How about creating a new protocol for distributing software? It could be called File Push Protocol. You’d wake up every morning with you separate hard drive full of good stuff that others have given you. Nah, maybe not, that might be illegal even. Something old, something new, something, borrowed something blue… Suddenly, you might think of a new programming language, like another XML-standard and start then wondering why we need all these standards. Wouldn’t it be great to do something that everyone could use? And that could be run on all types of devices? Implement once, run anyway. That sounds a bit like Java. Maybe a new programming language should be invented? An operating system developed in Java? Nah, but, it would be nice if one could take advantage of all code and libraries that is out there, so maybe an operating system that hovers on top of everything?
I have no idea what runs through your head at the moment, but doesn’t that seem to be a good idea? Let’s use what have so far developed and see if we can create something that runs on top of the Java Virtual Machine that would work like an operating system. Not in the computer itself but mainly in the Network the computer is connected to. Let’s see if we can find something useful in between the client, the server and the network. Let’s see if we can find something interesting in between the WAN, LAN and the PAN that could benefit mankind.

Problems
When we send data between devices we need to use protocols. There are hundreds and hundreds of protocols out there designed for every little purpose. How can we communicate with all kinds of devices seamlessly and without inventing a new communication standard?
There are hundreds and hundreds of different API’s and libraries out there, how do we communicate with these seamlessly and generally speaking?
One of today’s major problems within software development is the cost of developing new software. Code is seldom re-useable and system developers tend to re-invent the wheel all the time, if it’s not for legal problems it’s for design or reliability problems. How do we ensure that we create software that can be re-usable, can be replaced, repaired and enhanced?
How can we find a way to be sure that we are creating building blocks that can be run anywhere on any device?
The terms “block” and “components” describes rather stiff and fixed properties. Let’s call it services instead. Like a waiter that provides a service. Or your best buddy. Let’s make best buddy software. And, I almost forgot, since we can dictate, let the best guys in the industry from every vendor come and make suggestions on how we should do it.

India, we have a problem
Dear India, if you don’t have anything else to do, help us with this and let’s get this train going. We are not sure where we are heading but we’re sure it’s somewhere better than where we are now! We have a great idea, but we don’t really think we can pull it off for even 10 million dollars. Can you do something with the money? And if you don’t mind, we’d like to take credit and make it our very own brainchild. Let’s fix this industry once and for all and make sure we can all create standardised services that truly will run anywhere, all the time and on any networked device. Let’s hand it out for free and see if we can create a revolution that will rock this world in its foundations!

One year later...

Ok, let’s slow down and stop imagining now. Let’s get serious for a moment. After all, we don’t have the money and why would companies adopt the standard just like that? It surely couldn’t work. Or can it?

Where do we stand today?
Actually, there is a standard implemented since around 1999 (it’s not Indian). Beginning with all major software companies – except for the Company, they didn’t need any expert help – an independent organisation started to sketch on a solution that roughly would be able become a solution to any known problem in computer science. How is it working then? Fundamental is Java that runs on any operating system, Java also nowadays runs in very small devices like a telephone for example. On top of the Java Virtual Machine runs a framework, where you can install, start, stop and uninstall services – remotely if preferred – on the fly. The services offer a Java interface to the framework. The interface is the service. Anything that implements that interface is hidden from the other services. So the only connection to the service itself is the interface that is open, public, for free, usable and preferably it’s very clean and simple.

A few words on what is done
So how do we handle different network protocols that we might need to speak? We implement a service for each protocol. This way we are sure of not inventing another protocol, and we are sure of that we can speak native whether it’s an internet protocol or an application protocol or something else.
How can we be sure that we are building services that can be re-used? It’s really a design question. Implementing a protocol is quite easy. What do we do with services like logging and storage of a service’s preferences? If some services are so typical that a program will always use them, they could be implemented once and for all. That would also save memory space. The framework must be able to start and stop services so we need to handle recently started and stopped services. We have to have a really nice class loader that can find implementations of a service on the fly. Since many different versions of the same service might exist in the framework we need to handle this in a good way.
Java guarantees a lot when speaking of where the service could run. Not to mention all different kinds of security layers that is provided. So there is a standardised framework out there together with some basic system services. What is it then?

OSGi Alliance’s solution
Let’s see now, it’s an open, standardised execution environment for networked devices. It’s a magical machine that could help any application or device or appliance getting in contact with the rest of the universe in the network - WAN, LAN or PAN.


©www.osgi.org
Once you have your special service into the framework you’ll have access to other vendor’s services, if you have installed any that is. If you are in the device making business and have a little device that measures indoor temperature and you have a driver for a desktop PC, you could easily make it OSGi compatible by replacing your main method with the OSGi start-method, bundle it in a Jar-file and adding it into the framework. If you have your driver in C/C++ you can use Java anyway to get it into the framework. With that you could for instance use an SMS-gateway that of course is installed and connected to the desktop framework somewhere in the network. Whoops, all of a sudden you have a lot more to offer than a device that reads the temperature!
If you have a major application like a Network Management System, why not offer and OSGi-service as well, making your NMS-API available for other vendors? Of course they will provide an OSGi-service if you do and “Whoops” again; you can manage all kinds of devices that you didn’t support before. Plus you’d have the opportunity to speak any protocol you’d need and would be able to present whatever you’d like to present on any kind of equipment connected to the network. Provide your goods and let the others provide theirs. Everyone would play in the same arena, on the same terms.

Why don’t we?
God knows, implementing services are one thing that seems to be catching on at least. We are limiting ourselves to creating services that runs in service oriented architectures. We are limiting ourselves to making services as Web services. At least we have found some common standards when communicating. It might just be enough at the moment, but we still lack of openness, collaboration and cooperation. And all systems that only run on one operating system? What a complete waste of resources building systems that are locked to a certain processor and a certain operating system and a certain vendor.
So, is there a lesson to be learned here? One might be that no matter how good you do it, you still will have difficulties finding acceptance due to the fact that it’s a competition out there that is killing. There are two many examples of situations where the products, systems, protocols or whatever that are second or third best for all of us have been the ones that have been accepted as standards.
We still have a long road ahead of us, just at least have in mind that someone has probably already done exactly what you are about to do next… Lastly, which programming endeavour would you put your money on?

The Executive Perspective

Putting it all together
We have the hardware, the software, the standards, the tools and the people with the right ideas. Yet, we can’t seem to put it all together. We have everything we need in order develop applications that may seem very simple, but still we can’t. Economic factors prevent us from lifting our eyes above what we are currently doing, the difficulties of creating something substantial together and forming a common foundation for how we do things prevents us still from being successful in the field of computer science. What will we have to do in order to finish software projects within budget and that will meet all requirements? Are we just poor at estimating costs or is there something fundamentally wrong with the whole business? The following article tries to put some light over an open standard for developing software that might make a different in the future.

Economics
There are many reasons why we aren’t successful in software development, mainly for three reasons; economics, economics and economics. Firstly, the cost of living in the western world is too high so our wages becomes too high. This creates expensive software. Let’s not go into that further. Secondly, if we do find the funds to create software we do not make sure that we can re-use the software. We are still after over 50 years of writing software re-inventing wheels. This causes us to start all over again every time we want to create something useful. Integrating software and systems might be as expensive as rewriting everything from scratch. This creates expensive software. Thirdly, the requirements of today’s systems and the systems we create are very complex. Indeed, complexity is a killer of applications. No single person can solely have full knowledge of what’s going on even in a smallest “Hello world” application. Developing software requires an experienced development team. This creates expensive software.
Another key factor that will make us fail in software development projects is the lack of standards, or perhaps the flow of standards that has not been commonly accepted. Every vendor has its own way of implementing the solution to a problem no matter what the product is trying to do. We do have standards that work when we agree on communication protocols. And we might say that we have a high-level programming language that is at last working painlessly on all major platforms, namely Java. Unfortunately, this is not enough to be able to produce successful and affordable applications and systems that can be re-usable. When discussing web servers and databases we’re fine. Anything that we can break out and put separately in a box will work and will be future-proof. This fact might give us a clue on what we need to do.
There are also other factors that will make us do the wrong choices when designing systems. We might lock ourselves into one vendor’s specific operating system, hardware or API. This might be the case for short sighted economic reasons, knowledge reasons or just plain old habit reasons. It brings problems further down the road though, that in the end will make it more expensive.
Of course, there are more reasons for failed software developing projects than I can mention here. Anything from poor leadership to lousy programmers and customer’s that don’t know what they want. Those issues are not as interesting as the following ideas I will try to explain.

The Service Model
Now, let’s get back to the web server that will do its thing no matter how you want to use it for. It defines a service. You can ask it something through a certain protocol and you’ll get a reply back with hopefully something useful. It can also perform tasks and hold data (provide a connection to a database). What you can’t do though is shut it down or do something else nasty to it. It defines a idempotent service even. Whatever reason you want to use it for you’d know what it can do. You can re-use it, re-use and re-use it.
What defines a service? You might say a service is a self contained entity in which consumers interact through well defined rules. The consumer does not know or care how the service implements the requested action - only that the service performs what is defined by its published rules. Are there different kinds of services?

Typically we are talking about consumer and producer services. And some services can define both. Somehow the services must communicate and it’s done via a common transport interface. This could be for example through Internet.
Now, if you can produce code and functionality that works like the web server, wouldn’t it seem to be natural to state that we can find economy in what we are about to do? Now, not all services are as clear as the web server. And of course you can just start making a bunch of applications and put each in a separate machine and have little Internets here and there. We need to be more efficient.

Service-oriented Architecture
What many system developers have discovered is that it’s a good methodology to develop applications as services instead. There is a whole river of new standards that addresses the issues how you define the public interface and the communication protocols handling the various data transactions between the services. Often it’s done by using XML, WSDL (Web Services Description Language) and UDDI (Universal Description, Discovery and Integration). This kind of developing applications goes under the name of Web services. A bit wider definition is called SOA which stands for Service-Oriented Architecture. Here’s one definition found in Google: “A service-oriented architecture is a collection of services that communicate with each other. The services are self-contained and do not depend on the context or state of the other service. They work within distributed system architecture.”
Web services are one example of a SOA. We might just be on to something here. Most modern software companies use a unique model to implement the services they need, relying on open communication standards. They create their services and hopefully they will be able to stop re-inventing wheels. However, it’s still kind of a war going on. Different companies compete with the same services but on different playing fields. The “system services” that provide basic functionalities do not perform standardised tasks that for example the web server does.

An Example
Let me give you an example. Company A has developed a little robot that has a WLAN, a GSM interface and a little video camera. They don’t really care what customers would like to do with it. They think it’s up to them to define the applications. Could it be used to mow the lawn? Could it be used to spy on someone? Could it be sent into a building on fire? The applications are numerous. Now, another Company B has a little device that is somewhat smaller than a laptop and slightly bigger than a PDA, with a WLAN and GSM interface. Company B thinks it would be interesting to be able to control the little robot with their device. The little robot uses a Linux library to read and perform instructions and of course; the handheld device relies solely on Windows technology. How do we put this together and create a solution that will stand time? How would the robot company implement a solution that will make them available for any other interested customer? How would the handheld device company best implement a solution so that they can control and interact with any other kind of device, or server or service?
There is a really brilliant answer to these questions.

The Standardised Execution Environment
You might wonder what this means. It’s an environment where you can execute stuff. An environment is in this case a framework where you can install, start, stop and uninstall services. A framework is a program that starts other separate programs that follows some specific rules or format. The framework and the services are written in the platform independent programming language Java, hence they will run on any device that cares to host a Java Virtual Machine. Some say this might be a limitation, and some say it’s a huge advantage. Platform independency costs in some ways, but dependency also costs, and it’s always better to have options, right? What does the standard part mean? It means it’s a standardised framework and that it’s open to one and all and comes along with load of basic system services that is re-useable over and over again. When comparing with the web server and the common standardised Internet-protocols (UDP/TCP, IP, HTTP etc) the framework is the corresponding Internet. So communications between services are made internally within one single process (thread) via direct calls and via a registry. And of course you can have other separate threads running and use all sorts of programming languages and libraries within your service. What ever you want to do you can do as you would do “normally”. If you want to make a web server though there’s no need to. That’s a standard service that you can access on the fly within the framework. You can create a whole web-site dynamically by just entering a door. That is if the sensor in the door has some sort of a driver that is loaded into the framework…
Now, we are really getting somewhere.

The OSGi Alliance
OSGi Alliance is an independent organisation that was formed in 1999 and is now run by around 40 different companies. They have developed an open service-oriented framework that delivers software bundles as services. From OSGi business white paper “Leveraging OSGi™ Technology”:
“The OSGi Alliance and its technology address the following challenges:

• How do we assemble, maintain, repair, and enhance that software affordably, transparently, efficiently and reliably?
• How do we create the flexibility needed to accommodate the wide range of business models used in the market today for software and services, and enable new and profitable business models for the future?”

It’s quite an achievement having implemented this; it seems to be harder to make it commonly accepted though. How does one carry out such a change in how people implement ideas? Well, OSGi Alliance is after six years starting to make an impact. The maybe most famous project using OSGi technology is the Eclipse SDK (www.eclipse.org). Deep down in the menus where you can find your installed software you’ll find the acronym OSGi.
The service concept is not at all some feature OSGi is trying to sell. There are so many angles on this it’s nearly impossible to sell. There’s no single selling point, there are multiple all depending on what you want your system and applications to do. OSGi Alliance has until now been concentrating on residential gateways, telematics and mobile telephony. But they state that their non-proprietary service platform also spans:

• Automotive
• Embedded appliances
• Industrial computers
• Desktop PCs
• High-end servers, including mainframes.

And these are the key features of the OSGi Service Platform:

• Flexible software component model
• Open integration of protocols and standards
• Reusability of software modules
• Dynamic software updates
• Remote control/maintenance/diagnosis
• Secure, authorization rules
• Platform-independence
• Horizontal deployment features

OSGi Alliance’s view on what they have done is described as follows:

©www.osgi.org

Many are the topics that can be written books about in this picture. Security is always an issue, but here it’s almost not. Layer upon layer of security guarantees the highest possible protection for the services run in the framework and for the users of the services. There are around 20 open standardised services that are specified by the OSGi Alliance, but if you’d collect all vendors’ implemented services you can probably say that every popular protocol has been implemented. And probably, every single one of them is re-usable on any kind of device for any kind of purpose. Now, that’s economy.