Open Systems Gateway Interface (OSGI)

Current gateways

Each LAN has at lest one gateway to connect it to other networks
The gateway has two network cards, one to talk to the local network, the other to talk to the remote network
Each computer is configured to send packets to external networks to the gateway
The gateway often acts as a firewall as well, blocking undesirable packets from passing in either direction
Current gateways act at the TCP/IP level

Gateways should provide application-level mechanisms
An application gateway should allow single point of call for local services wishing to access external ones, and for external ones to access local ones
A vendor who has a new version of s/w should be able to "drop it off" at the gateways, like postmen leave letters in the mailbox
The new version should be self-contained, with all classes and native libraries included, and specify which o/s, other packages it depends on, and what it includes
The "mailbox drop" should not need to know where in the LAN the s/w is stored or used - just like the postman doesn't know where in the house the mail will be read
s/w inside the LAN on the other hand should not need to know about the vendors. It should be able to look on the gateway to see if there is a new version, and if so, update itself

OSGi hints that it functions as an application gateway, but doesn't appear to do this
OSGi seems to function as a management system on every node of the internal network
It allows s/w to specify classes, libraries, dependencies, etc
It allows all "services" to register with the OSGi framework so that it knows all about its services
It does not appear to know the network, or how to manage external providers and internal users

Services have an existence independent of applications that may use them
A service may be persistent, or just come into being for a single application
An application probably doesn't know how a service is implemented, and shouldn't care much
A service may make use of other services
Services may be "bundled" together, require other services, or optionally use others
A service may maintain state information about the applications using it, or could be stateless - the application need not know how state is maintained
An application may make use of many services, or make use of many service bundles

Services will have a lifecycle independent of its users
A service will need to be started and stopped by some other mechanism than an application that uses it
OSGi supplies a management layer for services running on gateways and other computers within the network
A service manager may also ensure that required services are running, that all class files are present, etc

An OSGi bundle is a collection of related service, plus information about the services
An OSGi bundle is stored in a jar file
An OSGi bundle will include
- Java class files for the services
- Native code libraries (if needed)
- Images, HTML pages, as needed
- A MANIFEST giving information about the bundle
The MANIFEST contains
- exports: classes and packages the bundle will make available to services and applications
- import: classes and packages it requires in order to run, including version information
- native code libraries: lists of any native code libraries the bundle contains, plus O/S, O/S version, processor, language under which eadch library runs

A bundle can be in one of the states

INSTALLED: the jar file for the bundle is downloaded, and all classes and suitable native code libraries are installed
RESOLVED: the framework has successfully resolved all dependencies on classes, packages and native-code libraries that it requires from other bundles
STARTING: the start() method has been called on the bundle
STOPPING: the stop() method has been called. When it returns, state is set to RESOLVED
ACTIVE: the start() method has returned and stop has not been called
UNINSTALLED

install(): the bundle is installed and resolved, moving to state RESOLVED
start(): move from RESOLVED to ACTIVE
stop(): move from ACTIVE to RESOLVED
update(): if there is a newer version of the bundle, stop the bundle, uninstall the bundle, install the bundle, start the bundle
uninstall()

JES conforms to the OSGi managed service spec
It runs on J2ME, Personal Java, J2EE, on nodes in a network
It manages services, doesn't do gateway specific stuff
It is a "local service" mechanism
It handles "devices" by special tricks
Network services such as Jini, Salutation, SLP and UPnP are treated as opaque "devices"
HAVi devices, Jini services, etc, are not OSGi managed services

This work is licensed under a Creative Commons License
The moral right of Jan Newmarch to be identified as the author of this page has been asserted.