Package org.universAAL.lddi.abstraction
This package assumes that there are external (meaning not readily connected
to universAAL) networking-enabled HW/SW components to which we may need
access in a universAAL network.
See: Description
See: Description
| Interface | Description |
|---|---|
| ComponentIntegrator |
As a "specialist" for certain component types, it cooperates with all
communication gateways that have access to
external components of those types in order to integrate such external
components in the universAAL network by (1) publishing related events to the
universAAL context bus and / or (2) registering related service profiles to
the universAAL service bus. |
| ExternalDatapoint |
An ExternalDatapoint is a readable and / or writable datapoint outside the
universAAL network.
|
| Class | Description |
|---|---|
| CommunicationGateway |
A gateway providing a bridge to a network of external components making it
for
component integrators possible to gain access
to related external datapoints. |
| ExternalComponent |
An external component is a hard- or software component that is outside the
universAAL network and can be reached via a
gateway. |
This package assumes that there are external (meaning not readily connected to universAAL) networking-enabled HW/SW components to which we may need access in a universAAL network. As an LLDI-based approach, this package refines the LDDI abstraction layer the following way based on the assumption that all component type specific models will be provided in term of ontologies on which the access and integration layers will rely:
As can be seen in the above figure, the main elements in this framework are
communication
gateways, component integrators,
external
components, and component type specific ontologies (there are also
external datapoints
as an additional concept that is not included in this package info).
As indicated by the figure above, this package has a universAAL-specific view; in particular, the abstraction layer of LDDI exists in this package virtually in terms of a set of relevant ontologies that can be chosen to serve as the contract between the communication gateways and the component integrators with regard to whatever is component type specific.
As opposed to component integrators, the extent of dependency of
communication gateways to universAAL can be limited to the usage of
universAAL containers.
This dependency is needed so that the implemented gateway can be shared
within the container using
the container's shareObject method. On the other side, component integrators
must fetch gateways already shared within the container using
Container.fetchSharedObject( org.universAAL.middleware.container.ModuleContext, Object[], org.universAAL.middleware.container.SharedObjectListener)
so that in addition they are notified whenever new communication gateways are
shared within the container. Component integrators are then expected to
register the found gateways using
the related method of the gateway.
Important note: the above implies that with this approach, the interplay of gateways and integrators will work only when they are deployed within the same universAAL container in order to be able to effectively integrate external components into a given universAAL network.
Copyright © 2018 universAAL Consortium. All rights reserved.