Echelon LNS - Manual (Page 292)

LNS Programmer's Guide 278
Introduction to the LNS Plug-In Model
All LNS applications achieve a level of interoperability by using the common API
provided by the LNS Server, and by using the LNS global database and shared network
databases. The shared network databases allow one LNS application to add a new device
to a network, and for all other LNS applications attached to the database to immediately
know about the new device. This level of interoperability is achieved whether the other
applications run on the same PC, on different PCs on the same L ON W ORKS network, or
on PCs connected to the LNS Server and database via a TCP/IP connection.
An LNS network tool could be constructed from a mixture of any of the following
components:
• Generic components created by tools vendors for viewing all objects in a
system and invoking commands on the objects.
• Device type specific components created by device manufacturers for
device configuration, monitoring, and control.
• System specific components created by system manufacturers for system
configuration and management.
• Generic components created by tools vendors for alarming, logging, and
trending.
In addition to providing a common API and database for these types of applications, LNS
defines standard interfaces that applications can use to communicate with each other.
These interfaces can be used to categorize LNS applications into the following types:
• Director applications: applications that call and initialize other LNS
applications. Director applications use the LNS Plug-In API to invoke the
other type of LNS application: plug-in applications. An example of a
director application is a generic system navigator that allows the user to
navigate through the subsystems in a system, select a device, and invoke
a command on the device. The command may be carried out directly by
the navigator, or the navigator may invoke a device plug-in to carry out
the command.
• Plug-ins: applications that are called by director applications and are
implemented as ActiveX automation servers. They typically implement
their own user interfaces, and may be able to operate independently as
stand-alone applications. Plug-ins are typically used for device type
specific applications (called device plug-ins), system-specific applications,
and generic applets such as alarming, logging, and trending. Most device
manufacturers implement plug-ins to simplify configuration, monitoring,
or control of their devices. Plug-ins also implement the LNS Plug-In API.
The interface between director applications and plug-ins consists of standard ActiveX
automation interfaces. An application can operate as an LNS plug-in and as an LNS
director by implementing both sides of the interface. The number of director applications
per system will typically be limited to provide a unified interface to the end-user.
The techniques introduced in this chapter allow an additional level of interoperability to
be achieved. They allow network tools to be built from component applications that
directly interact with each other. The methods and techniques introduced in this chapter
are described in more detail in the LNS Plug-in Programmer's Guide, which can be