Container - universAAL/middleware GitHub Wiki
As suggested by the layer model, there must be a footprint of the middleware on those nodes that can host “AAL-aware” software components so that they are able to easily find and share the local representation of the middleware. From another point of view, the possibility of finding and sharing this local representation of the middleware can be understood as a kind of container functionality. This container functionality is similar to the functionality of other known containers, such as Web Containers, Servlet Containers and Portlet Containers.
One of the major benefits of such container view is the enforcement of a shared working model, beyond the API of the middleware and beyond sharing its representation on each node. Containers provide normally facilities for modules to be installed and provide some life cycle management while resolving the dependencies between them; in this way, outsourced functionality can be found and shared (so, also the middleware). However, containers can do this in a technology-specific way, normally for interoperability within one node.
The introduction of container concept aims at defining an execution environment that can be easily instrumented to locally and remotely install, upgrade, configure and monitor AAL applications. Such basic functionalities are considered to take into account business and use cases where Service Providers must simplify the management and deployment of heterogeneous uSpaces, that is a standard interface for managing remote resources deployed on different platforms. Thus, such separation of concerns is mainly needed for scalability reasons.
A specification that deals with the abstraction of management capabilities for embedded devices is the UPnP Device Management DCP. It is a set of Device Protocol Specifications whose implementation can be realised for different execution platform technologies. In the appendix A of the Software Management Service is provided a summary of the execution platforms considered during the design of first UPnP DM version. The table of such technologies is reported below. A distinction is made among deployment unit and execution units, in programming platforms like OSGi or .NET they are represented by bundles and assemblies, in OS platform like Linux by packages and scripts. The different actions associated to the diverse software lifecycle (install/stop, load/unload, PackageInstall/PackageUnistall) are conveniently mapped on the standard message of the UPnP Device Management specification.
|
Technology |
Deployment Unit |
Execution Unit |
Dependency |
Actions |
Events |
|
OSGi |
Bundle |
Bundle |
Bundle, Package, Service |
Install, Start, Stop, Update, Uninstall |
Installed, Starting, Resolved, Active, Uninstalling |
|
Java MIDP |
Midlet Suite |
Midlet |
Library (MIDP3) |
StartApp, DestroyApp |
NA |
|
.NET |
Assembly |
Assembly |
Assembly |
Download, Load, Unload (AppDomain), Invoke |
NA |
|
Linux Debian |
Package |
RC Script, possibly others |
Package |
PackageInstall, PackageUninstall, ServiceStart ServiceStop |
Triggering Updates |
|
SCOMO |
Delivery Package |
Deployment Component |
NA |
Download, DownloadInstall, DownloadInstallInactive, Install, InstallInactive, Update, Remove, Activate, Deactivate |
Operational Results |
According to the requirement "Independence of the container functionality" all container functionality was abstracted and separated from OSGi-specific methods. This way, it is possible to provide the same interface independent from a specific container, hardware, or operating system. This decision has led to the implementation of two software artefacts:
- mw.container.core: container-independent interfaces
- mw.container.osgi: OSGi-specific implementation; depends on mw.container.core
A set of container-independent interfaces and basic functionalities of the container.
| Artefact: Container Core | |
|---|---|
| Maven artefact | org.universAAL.middleware / mw.container.core |
| Maven Site | https://universaal.github.io/middleware/middleware.core/mw.container.core/index.html |
- Management of modules
- definition of a module context to describe the context of a module
- install/uninstall modules
- start/stop modules
- Management of shared objects
- register/query a shared object
- notification for new shared object
- Configuration
- registration of config file names
- reading config files
- notification for changes in config files
- Logging
- log a message
- provide functionality to listen to logged messages
The design of these interfaces is very much inspired by OSGi and PAX logging. Thus, we avoid repeating them here; a mapping between these functionalities and their OSGi counterpart can be found in the design decisions of the osgi container.
Implementation of container-specific functionalities of the interfaces provided by the Container Core for OSGi.
| Artefact: Container OSGi | |
|---|---|
| Maven artefact | org.universAAL.middleware / mw.container.osgi |
| Pax Composite bundle | scan-composite:mvn:org.universAAL.middleware/mw.container.osgi/x.y.0/composite |
| Karaf Feature | - |
| Maven Site | https://universaal.github.io/middleware/middleware.osgi/mw.container.osgi/index.html |
Implementation of the Core features for OSGi, see the features of the Core component.
Since the design of the Core artefact is very much inspired by OSGi, there a close mapping between these two:
- Management of modules: a module corresponds to a bundle and the module context corresponds to a bundle context. The basic functionality to install/uninstall and to start/stop is directly provided by OSGi.
- Management of shared objects: shared object correspond to service reference.
- Configuration: configuration files can be specified as properties of a managed service of OSGi.
Implementation of container-specific functionalities of the interfaces provided by the Container Core for Junit-POJO testing.
| Artefact: Container JUnit | |
|---|---|
| Maven artefact | org.universAAL.middleware / mw.container.junit |
| Pax Composite bundle | - |
| Karaf Feature | - |
| Maven Site | https://universaal.github.io/middleware/middleware.core/mw.container.junit/index.html |
Note this is a library intended for testing, so dependencies to this component must be scoped as test; it should only be used in testing environments or custom POJO applications.
Implementation of the Core features for JUnit-POJO, see the features of the Core component.
The container and Module context implementations are the simplest POJO implementation of the interfaces. For logging it uses apache log4j, self configured to log on console.
The advantage of this container, compared with the itest framework, is that it can be directly used in JUnit testing for simple unit testing; without the need to load all the middleware nor the component to be tests (in the cases where the test and the normal module initialization are incompatible). Since it implements the logging it can be used with components that use ModuleContext only for logging and cannot be tested otherwise.
A general-purpose system for installing and un-installing applications in the uSpace. This box is composed by a set of bundles at different layers (Manager to Connector Layer) in order to install software artifacts in the uSpace.
The next figure highlights the bundles that are required by middleware in order to implement the provisioning system.
The provisioning system flows across the following steps:
- Developers upload applications in the uStore. An Application (uAAP) is packaged as a Zip file that contains several resources such as configuration file and a number of software parts. Every part can be installed in one ore more Peers of the uSpace, according to the requirements defined in the configuration file.
- The Service Provider packages a service (namely the USERV package) by combining the uAAP provided by the developers. A Service can be composed by software, hardware or human resources (see D1.3-E Chapter 2, for more information abut the Service concept).
- The end-users browses the uStore by means of the UCC application. The user can select an interesting Service and he/she can download it.
- The middleware discovers the target Peers on which to install the different application parts, by means of the Deploy Manager.
| Artefact: mw.managers.deploy | |
|---|---|
| Maven artefact | org.universAAL.middleware / mw.managers.deploy {.core/.osgi} |
| Pax Composite bundle | scan-composite:mvn:org.universAAL.middleware/mw.managers.deploy.osgi/x.y.0/composite |
| Karaf Feature | - |
| Maven Site |
https://universaal.github.io/middleware/middleware.core/mw.managers.deploy.core/index.html https://universaal.github.io/middleware/middleware.osgi/mw.managers.deploy.osgi/index.html |
| Artefact: mw.connectors.deploy.karaf.osgi | |
|---|---|
| Maven artefact | org.universAAL.middleware / mw.connectors.deploy.karaf.osgi |
| Pax Composite bundle | - |
| Karaf Feature | - |
| Maven Site | https://universaal.github.io/middleware/middleware.osgi/mw.connectors.deploy.karaf.osgi/index.html |
- Request the installation of the application part (uaap part) to the target peers
- General purpose API for installing and un-installing application parts in the middleware container
- Install an application part in the Karaf Container
The Service Provisioning is a general purpose mechanism for installing application part (uaap - part) in the container (e.g Apache Karaf). There are 2 key components that implement the provisioning system:
- Deploy Manager
- Deploy Connector
The Deploy Managers implements a set of APIs in order to install and un-install uAAP in the uSpace. For example
- public InstallationResults requestToInstall(UAPPPackage app)
- public InstallationResults requestToUninstall(String serviceId, String id)
- For every application part contained in the uAAP archive, selects the target peer to which to send the application part
- Sends a message to the target peer containing the application part
- Receives asynchronously a notification message from the target peer with the outcome of the installation
When a peer receives the installation message from the Deploy Manager, the Deploy Connector will take care of that message. Currently the middleware provides only the Karaf Deploy Connector. Such connector allows to install software artifact into a Karaf OSGi environment. In the future it will be possible to extend the number of Deploy Connectors by implementing a specific connector for every platform (e.g. Android Deploy Connector, Felix Deploy Connector, Linux Deploy Connector...).
The Karaf Deploy Connector exploits the Karaf OSGi services in order to install the artefacts contained in the application part. It uses the provisioning mechanism described in the Apache Karaf official page http://repo.maven.apache.org/maven2/org/apache/karaf/manual/2.3.1/manual-2.3.1.html.
A set of universAAL shell commands in order to debug and check the status of the middleware instances.
| Artefact: mw.karaf.shell.universAAL.osgi | |
|---|---|
| Maven artefact | org.universAAL.middleware / mw.karaf.shell.universAAL.osgi |
| Pax Composite bundle | - |
| Karaf Feature | - |
| Maven Site | https://universaal.github.io/middleware/middleware.osgi/mw.karaf.shell.universAAL.osgi/index.html |
- Browse the available uSpaces
- Print the uSpace to which the current instance is connected
- List the peers that join to the same uSpace
- Install the middleware by means of the Apache karaf provisioning mechanism
The universAAL commands have been designed for the Apache Karaf OSGi container. The commands can be invoked from the GoGo console available in all the Karaf distributions. The commands follow the standard Karaf convention that is 'type of command':'command', in particular
- universaal:spaces: list the uSpace discovered from the middleware instance. The character '*' marks the uSpace to which the current instance belongs to
- universaal:peers: list the the Peers that join the same uSpace. The character '*' marks the current middleware instance