Resource Menu


by Julien Forest - (no comment)
The OSGI industrial standard has been chosen for the standardised communication interface in order to guaranty a high degree of interoperability with other modelling tools.

The whole system is run through a standard OSGI runtime. The Apache Felix runtime has been selected for its strict respect of the OSGI norm, its strong community support and its non-intrusive open-source licensing scheme. Apache Felix only requires a standard JVM to be run.

OSGI and the Apache Felix runtime correspond to the current de facto standard and state of the art.

An OSGi framework (OSGi being an acronym for "Open Services Gateway initiative") is a module system and service platform for the Java programming language that implements a complete and dynamic component model. Applications or components (coming in the form of bundles for deployment) can be remotely installed, started, stopped, updated, and uninstalled without requiring a reboot; management of Java packages/classes is specified in great detail. Application life cycle management (start, stop, install, etc.) is done via APIs that allow for remote downloading of management policies. The service registry allows bundles to detect the addition of new services, or the removal of services, and adapt accordingly.

The OSGi specifications are now used in applications ranging from mobile phones to the open source Eclipse IDE. Other application areas include automobiles, industrial automation, building automation, PDAs, grid computing, entertainment, fleet management and application servers. OSGI is today a reference standard in the industry; presents a stable specification and is largely used.

Figure here after summarises the key concepts of OSGI.

Any framework that implements the OSGi standard provides an environment for the modularization of applications into smaller bundles. Each bundle is a tightly coupled, dynamically loadable collection of classes, jars, and configuration files that explicitly declare their external dependencies (if any). All OSGI framework are conceptually divided into the following areas:

  • Bundles: Bundles are normal jar components with extra manifest headers.
  • Services: The services layer connects bundles in a dynamic way by offering a publish-find-bind model for plain old Java Interfaces (POJI) or Plain Old Java Objects POJO.
  • Services Registry: The API for management services (ServiceRegistration, ServiceTracker and ServiceReference).
  • Life-Cycle: The API for life cycle management (install, start, stop, update, and uninstall) for bundles.
  • Modules: The layer that defines encapsulation and declaration of dependencies (how a bundle can import and export code).
  • Security: The layer that handles the security aspects by limiting bundle functionality to pre-defined capabilities.
This choice deeply improves the modularity and the reliability of the SPIS-UI framework, tailored or specific bundles being dynamically loaded at the runtime. The OSGI specification facilitates a future deployment of SPIS-UI in a client-server or distributed approach. The choice of OSGI should facilitate the interoperability with other simulation tools.

Back home



Last edited by null at - Edit content - View history - View source