Service Protection: How to access KESO's system objects
Domains in KESO not only provide spatial isolation but also service protection,
that is the use of system services is restricted to only affect entities within
the same domain, if sensible/possible. This means, for example, that tasks can
only activate tasks within the same domain, occupy resources within the same
domain or reconfigure alarms within the same domain. The developer may, however,
specifiy exceptions to this, for example it may make system services for a
specific tasks possible from a specific other domain. Entities that are
subject to service protection are the OSEK operating system level entities
tasks,
resources and
alarms,
but also KESO mechanisms such as the Proxy objects
required to use the Portal inter-domain communication
mechanism.
Service protection in KESO is purely language based. The parameters of system services
that are subject to service protection have been changed to object types rather than
the primitive values used in OSEK. For example, the
ActivateTask() service in OSEK is passed
a numeric task id to identify the task that should be activated. The corresponding
KESO API in the
TaskService,
activate(), is passed a
Thread object rather than a numeric id.
To activate a certain task/thread, the application thus first needs to get hold of
the system object (Thread object) of that
task. The system objects are provided by a name service, e.g.
getTaskByName() in the case of tasks,
which will only provide the system object to the caller if the entity represented by
the system object belongs to the same domain or has explicitely been made available
to that domain. If neither of these conditions is met, the name service will return
a null reference.
Thread taskA = keso.core.TaskService.getTaskByName("TaskA");
keso.core.TaskService.activate(taskA);
// or alternatively using the standard Java API
taskA.start();
The visibility of system objects in KESO can be extended to other domains
by defining import statements in the Domain blocks of the configuration
file. There is an import statement for each type of OSEK system object:
ImportTask, ImportResource and ImportAlarm.
The value assigned to the attribute is the name of the system object that
should be visible to that domain. The attribute may be defined multiple
times in a Domain block to import multiple system objects of one
type.
The following example shows how the visibility of Task T1 is extended
to the domain B by defining an ImportTask attribute in the
domain block of domain B. In this configuration, the
getTaskByName() would return the
system object for Task T1 when invoked from control flows executing
in the context of either domain A or B, but would return
null for control flows executing
in the context of domain C.
To retain the statically configured service protection, system objects must not be
passed as parameters to portal calls, since this would potentially enable control
flows of other domains to invoke system services in a manner that is not apparent
from the static configuration file. To avoid this problem, all system object classes
implement the
NonCopyable marker interface,
which means that references to system objects will simply be subsituted by a
null reference during a portal call.
