This topic describes how to plan
effectively for Location Awareness Services for WebSphere® Sensor Events classes
and items.
To plan effectively for Location Awareness Services for WebSphere Sensor Events classes
and items, consider some basic rules and concepts behind the Location Awareness Services for WebSphere Sensor Events classes
as described below.
Class structure
When
defining classes and items, start by defining your class hierarchy
along with attributes and properties. Then, you can associate items
with the classes.
Location Awareness Services for WebSphere Sensor Events classes
make up a hierarchical tree, so remember the following:
- It is not recommended to add a class without key
properties because then you cannot use the AtlasIntegrator application
to maintain the items and several item-related Web services will not
function.
- When you delete a class, it also deletes all subclasses
and items
belonging to the deleted class or subclass.
- When you add a
subclass, it inherits all properties from the parent
class. These inherited properties cannot be changed at the subclass
level.
- When maintaining class properties, keep the following
points in
mind:
- Make sure you identify whether subclasses have been
defined for
the class and whether items were defined for the class or subclass.
- Make sure you use unique property names throughout the class hierarchy.
For example, if the class Employee has a property named BadgeNumber and
if the subclass, SecurityPersonnel, represents guards who have
special badges in addition to the normal employee badge, give the
special badge number a unique property name such as SecurityBadgeNumber.
- Changes to key properties are restricted when the class or subclass
has items defined. Therefore, the following restrictions apply:
- Adding key properties is allowed only if no items are defined
for the class or any of its subclasses.
- Deleting key properties
is allowed only if no items are defined
for the class or any of its subclasses.
- Changes to key properties
are usually allowed only if they are
less restrictive.
- Renaming key properties is allowed.
- You
can only change a key property type from any value to a string.
The values are kept.
- Changes to other properties
are restricted when the class or subclass
has items defined. Therefore, the following restrictions apply:
- Adding
other properties is allowed only if no items are defined
for the class or any of its subclasses.
- Deleting other properties
is allowed only if no items are defined
for the class or any of its subclasses.
- Changes to other
properties are usually allowed only if they are
less restrictive.
- Renaming other properties is allowed.
- You
can only change a property type from any value to a string.
The values are kept.
- Changing a property from mandatory to
optional is allowed, but
you cannot make an optional property mandatory.
- Minimize the number of levels in your class hierarchy. Too many
levels can make the display unusable and can decrease performance.
Class name length
Depending on font size and screen resolution,
long class names might be truncated in the Spatial Management Client and Location Awareness Services for WebSphere Sensor Events Administrative Console.
Subclasses are shown with an indentation that depends on
the level in the class hierarchy. In order to display the full names,
use the following guidelines:
- Top-level classes should not
be longer than 15 to 20 characters
(depending on your resolution).
- The name length should decrease
by about 20 percent per level.