Note: Descriptions are shown in the official language in which they were submitted.
CA 02221648 1997-11-20
OBJECT SELECTION ACROSS MULTIPLE PROCESSES
This invention relates to the field of object-oriented progr~"""illg, and in particular to
a method of selecting a common object on one application and passing its attributes into a
foreign application.
In traditional procedural progr~mmin~, functions dictate program org~ni7.~tion. In a
procedural language, the functions are coded only once. The function must handle a variety
of di~lel~l types of data. Decision making is handled inside the function, and its
effectiveness is largely a matter of the programmer's ability to foresee how many different
kinds of data the function ~,vill have to sort out. As programs involved, a function would be
used for a greater variety of purposes, some of which the program may have foreseen, some
not. In a procedural language, one function does many things.
In an object based language, the processor decides which method to use based on the
type of object that calls the method. The underlying program code is written specifically for
objects.
Most programs are now written in object-oriented languages, and this is true of
network management software used for m~n~ging large wide area n~lwo~h~. One of the
problems with existing software is that it is not possible to select a common object on one
application, for example, a 46020 Network Manager (Newbridge Networks Corporation) and
pass its attributes into a foreign application, such as a Newbridge 45190 Element Manager.
This creates discrepancies between shared information on di~lell~ applications and degrades
data quality through data throughput errors.
According to the present invention there is provided a method m~n~ginp; data in an
object-oriented environment compri~in~ the step of referencing a common selected object
across multiple processes with the aid of a suitable protocol.
In this way, discrepancies between shared information on different applications can
be elimin~te~l greatly enhancing data quality through reduced data input errors.
CA 02221648 1997-11-20
Any situation where common data is selected by one application and used in another
application. For example, a port (an object) on 46020 Newbridge Networks Corporation
Network Manager may be selected and the characteristics (attributes) of the port used by the
45190 element manager. The 46020 can have multiple element managers connected to it and
this invention allows the 45190 to determine if the selected object is relevant to it.
The invention will now be described in more detail, by way of example only, withreference to the accompallyillg drawings, in which:-
Figure l shows the ATMC Management Architecture;
Figure 2 shows a GEM Object Model;
Figure 3 shows the GEM Form Inheritance;
Figure 4 shows the Widget Inheritance;
Figure 5 shows the basic software structure of the system;
Figure 6 shows the additions to the CKNM software to enable communication withthe ATMC system;
Figure 7 shows Figure 0- 1 Use Case - Remote 46020 Activation of GEM
Figure 8 shows Local GEM Activation;
Figure 9 shows an Open Node Request from 46020;
Figure 10 shows the case for an Open Port Configuration;
Figure 11 shows a set port configuration;
Figure 12 shows an Add Node Request from the 46020 Network Manager;
Figure 13 shows the Remote Activation of GEM;
Figure 14 Local Activation of the ATMC;
Figure 15 shows a Draw Node Request; and
Figure 16 shows an Open Port Configuration;
CA 02221648 1997-11-20
-2/1-
Figure 17 illustrates a Set Port Configuration; and
Figure 18 illustrates an Add Node Request
CA 02221648 1997-11-20
Various abbreviations are used herein which are listed in the glossary at the end of the
specification.
The invention is implemented in a graphical element manager, which, as shown in
Figure 1, provides a flexible graphical intPrf~ce, integrated with Newbridge 46020
functionality through the Qs protocol. This interface will provide device (ATMC Switch)
specific configuration and displays, allowing the user to interact with the managed devices.
In Figure 1, a Newbridge Networks Corporation 46020 network manager 1
collllllullicates with a monitoring system 2 in accordance with the invention via a
communications protocol Qs over path 3. The complete ATM management architecture is
shown in the figure. The Qs protocol is a published interface to the 46020 network manager.
Figure 2 to 4 illustrate the GEM object model and the basic interaction between the
objects. This object model does not model the exi~ting application CKNM, instead it models
the functionality added to CKNM.
Figure 3 details illustrates the partial form inheritance included in this design. Forms
will be added to the inheritance tree as new configuration requirements are established.
Forms will be re-used where available, however, where device configuration varies widely
from one device to another of a similar type ~i.e. E1 vs. STM-le or STM-lo card) separate
forms will be used. Each form will be responsible for complete data collection and display
for the managed device.
Figure 4 shows aprelilllin~ class inheritance ofthe ATMC widgets. This objects
will be used as intelligent data holders by the configuration forms. These widgets will
provide various methods to allow the form to off-load operator interaction, range checking,
difference comparison and change notification for the managed data. The form class will
concentrate on data retrieval and storage.
Figures 2-4 show the inheritance relationship of the client side IMF objects. These
objects will encapsulate the IMF message interaction for each client of the IMF transaction
services. The GEM Client will be used by processes requiring access to the graphical display.
The GEM process will make use of the resource management client side objects to hide the
CA 02221648 1997-11-20
format and interface to the IMF message objects. These client side objects can be re-used by
and process accessing the resource management IMF functions.
The GEM requires three çxtçrn~l interfaces, X11 / Motif, IMF and Multi-Language
Support. These int~ ces are described below.
The X11 / Motif int~ ce is ~ccesse~l directly using Xt and Xm calls. Each objectinteracting with the X-Displays (either local or remote) will perform all of the setup functions
required to properly draw on the X-Display. Each GEM process will be responsible for
interacting with only a single X-Display (either local or remote) all multiple display
functionality will be accomplished by activating multiple GEM processes, each slaved to a
single X-Display.
The TCP/IMF interface will provide the GEM process will access to the rest of the
ATM-C system through the BASE process. At activation the GEM process will establish a
connection to the BASE. Once this connection is negotiated this connection will remain
active throughout the duration of the GEM process life-time. A single object, the
GEMMediator, will be responsible for sending IMF_Messages to the BASE and receiving
IMF_Messages from the BASE.
This object will expose a public interface to allow other functions to send data to the
BASE. Two up-calls into the CKNM core software will be used for incoming, unsolicited
messages, one for events and one for requests. Outgoing messages can be sent with either a
blocking or non-blocking request. The blocking request will provide a time-out mech~ni~m
Incoming replyies that do not have a m~tching request pending, either through a time-out or a
non-blocking call will be dropped after reception.
Multi-language support is achieved through the use of resource strings. All textual
information displayed to the operator will be referenced in the code using a string number
and a language offset. Each time the display is created the a~ropliate strings will be loaded
from the resource file and shown on the display. This technique will be extended to the
enumerated information received from the V3 node (for example Port Status).
CA 02221648 1997-11-20
The software in the GEM is composed of two distinct sub-systems: drawing and
configuration. Each will rely on a dAtAhA~e to provide data for display to the operator, the
interface to the database will be different for each sub-system.
The drawing functionality already ~xi~ting within the CKNM software application
and is implen ented in C. This functionality will not be modified. Database accesses specific t
the ATMC system will be hooked at the lower API interface, implemented in C++ as objects
and re-directed into the ATMC system.
The configuration sub-system will invoke this C++ object oriented interface directly.
All of the lower level ATMC co~ lunication components will be implemented in C++ as
objects. Each existing function group (i.e. NCIF files, Menus etc.) that these objects must
invoke will be wrapped in an object interface. Ultimately the drawing sub-system will be
implemented in C++ as objects.
The exi~ting CKNM software provides a generic int~rfAce into which additional
database and graphical display components can be inserted. The GEM will use this software
as a base and built on the structure. CKNM is currently a C-language application that is
compiled using a C++ compiler, as such we can insert C++ objects into this application
without impacting the structure significantly.
Figure 6 shows the additions to the CKNM software to enable communication with
the ATMC system.
A new d~At~hA~e API library will be inserted which will provide a stub interface to a
database object that will implement the true ATMC database API. All other communication
objects will be positions below this database API. In addition the current form processing
will be updates to invoke ATMC form objects directly. These form objects will embody all
of the information required to query and update node objects and display the information to
the opelalor. Access to the node will be through the current CKNM generic database API.
This API will be ext~nded where required to handle the ATMC functionality.
CA 02221648 1997-11-20
The GEMClient is an object provided by the GEM sub-system to be used in client
processes (i.e. Qs Mediator) to facilitate communication with the GEM processes. This object
will generate IMF_Messages for tr~n~mi~.~ion to the GEM.
The GEM Mediator is the gateway between the GEM process and the ATM-C Base
process. It is responsible for transmitting and receiving IMF_Message to and from the ATM-
C Base.
The GEM Mediator is made up of two public routines, one SendIMF provides an,
optionally, blocking interf~ce to the GEM process for tr~n~mi.~ion of IMF_Messages. The
second intP.rf~.e will be a separate thread of execution slaved to the input socket for receiving
IMF_Message tr~n~mi~sions to the GEM process. These methods are synchronized using a
shared structure holding IMF_Message tags and IMF_Message pointers. SendIMF calls will
perform a timed loop waiting for a response to a request. The shared structure will be
protected with a sem~phore to ensure exclusive access across threads.
Events and incoming requests will p~.rOllll up-calls directly into the CKNM common
API.
The mediator provides no encoding or decoding of IMF_Message short of tag
m~thcing and type ~ rimin~tion (Event, Request, Reply). Private methods in the Mediator
will be created to facilitate the access to the shared structure and IMF_Message headers.
The GEM Proxy is a simple object residing in the ATM-C Base process, and is the
central point of co~ lication between the GEM and the ATM-C Base.
The GEM Proxy will listen in on the socket connecting the GEM to the Base. When it
detects an IMF message from the GEM (socket.read()), it will forward it to the Router. GEM
Proxy will also be responsible for sending IMF replies/requests that are meant for GEM from
the Router, by putting these on the socket (socket.writeO).
The GEM Proxy will have multiple instances and will likely be in.Ct~nti~te~ either by
a Qs draw request or Base creating an instance. Therefore, multiple instances will be based
on a unique Base session id -one for each 'display'.
- 6 -
CA 02221648 1997-11-20
Processes requesting a session in the ATMC base must perform this function through
the Session Manager object residing in the base. The initiation of the GEM process is done
through a request from the Qs Mediator to the Session ~n~ r. The Session Manager will
then launch the GEM process. The GEM process will LogIn to the Session Manager with the
a~l.pliate session ID to register against that session. All processes registered against a
specific session can then be managed together.
Comm~ line activation of the GEM without a session ID will cause the GEM to
initiate it's own session, registered with the Session Manager.
Below is a list of IMF Requests (and Replies) that the GEM will support. The object
supporting each request are identified in Section 0 -CLASS DESCRIPTION.
IMF_GUI_DrawRequest Request to GEM to craw an o ~ject, ~om Qs (v a Base)
IMF_GUI_DrawReply GEM sends co"l~"~A~i( n (OK
IMF_GUI_SelectRequest Request to select an object, oligi,lltes from either GEM or
IMF_GUI_SelectReply 46020
GEM or 46020 sends c~" ~ IllA1 inn (OK)
IMF_GUI_ClearRequest Request to clear object se!ectit~n, O~ dtcs only from
IMF_GUI_ClearReply 46020
GEM sends col.li",.~lio" (OK) to Qs
IMF_GUI_HiliteRequest Request to highlight a set of objects, from 46020
IMF_GUI_HiliteReply GEM sends c~.. ri. . n ~ ion (OK)
IMF_GUI_UnHiliteRequest Request to clear hi~hlightiru~ from 46020
IMF_GUI_UnHiliteReply GEM sends col.l~.,.. -'ion (OK)
IMF_GUI_AddNodeRequest Request to Add a Node Object to the Base Database, from
IMF_GUI_AddNodeReply Q
CA 02221648 1997-11-20
¦ GEM sends c~ ;.)n
CLASS DESCRIPTION
Class - DbAPI (Abstract)
D~L_ ;~tion
This object provides the virtual interface description for all of the database API objects, all
virtual methods must be used
Export Control: public
Pe~ h~ce: transient
Concurrency: sequential
Operations:
public
Prototype: BOOL db_initO
Description:
Concurrency: sequential
Prototype: BOOL dbGetDeviceGeometry(enum deviceType)
Description: the information required to properly render this object on a graphical display
Concurrency: sequential
Prototype: BOOL dbGetNode(baseOID nodeOID, struct nodeInfo *)
Description: the node inforrnation from the current database
Concurrency: sequential
CA 02221648 1997-11-20
Prototype: BOOL dbLoginUser(struct userInfo $, int * sessionID)
Description: user information to allow a login to the base process
Concurrency: sequential
Prototype: BOOL dbGetPort(baseOID portOID, struct portInfo *)
Description: the information related to a specific port
Concurrency: sequential
Prototype: BOOL dbGetRack(baseOID rackOID, struct rackInfo *)
Description: the rack information for a specific rack
Concurrency: sequential
Prototype: BOOL dbGetCard(baseOID cardOID, struct cardInfo *)
Description: the card information for a specific card
Concurrency: sequential
Prototype: BOOL dbSetNode(baseOID nodeOID, struct * nodeInfo)
Description: the current node information
Concurrency: sequential
Prototype: BOOL dbSetRack(baseOID rackOID, struct rackInfo *)
Description: the rack configuration
CA 02221648 1997-11-20
Concurrency: sequential
Prototype: BOOL dbSetCard(baseOID cardOID, struct cardInfo *)
Description: the card configuration
Concurrency: sequential
Prototype: BOOL dbSetPort(baseOID portOID, struct portInfo *)
Description: the port configuration
Concurrency: sequential
Prototype: BOOL dbAddNode(baseOID nodeOID, struct * nodeInfo)
Description: a node to the ATMC database
Concurrency: sequential
Prototype: BOOL dbAddRack(baseOID rackOID, struct * rackInfo)
Description: a rack object to the node configuration
Concurrency: sequential
Prototype: BOOL dbAddCard(baseOID cardOID, struct * cardInfo)
Description: a card to the node configuration
Concurrency: sequential
Prototype: BOOL dbDeleteNode(baseOID nodeOID)
- 10-
CA 02221648 1997-11-20
Description: a node configuration from the ATM-C
Concurrency: sequential
Prototype: BOOL dbDeleteRack(baseOID rackOID)
Description: a rack configuration object from the d~t~b~e
Concurrency: sequential
Prototype: BOOL dbDeleteCard(baseOID nodeOID)
Description: a card configuration object from the database
Concurrency: sequential
Prototype: BOOL getDeviceMenu(enum deviceType, struct * menuItems)
Description: the menu items associated with this object
Concurrency: sequential
Class - atmcDB
Sl.l.c~lasses: public DbAPI
D~s~ ;~lion
provides the int~rf~ce specific implementation of the GEM database
Export Control: public
Pc. i,ii.h..ce: transient
Concur, ~.. ~; sequential
CA 02221648 1997-11-20
Class - atmcMenus (Abstract)
Description
A menu will be displayed on the XDisplay using information extracted from the NCIF files,
the current selected device and the user profile information
Export Control: public
Pel ~ialellce: transient
Concurrency: sequential
Attributes:
private
struct * menllT i.~t = NULL
Operations:
public
Prototype: BOOL displayMenu(userInfo *, enum deviceType, baseOID deviceOID)
Description: the requested menu on the current display
Concurrency: sequential
Prototype: XCallback mouseCallback(struct * mouseInfo)
Description: actions in response to mouse events
Concurrency: sequential
Class - formRegistry
- 12-
CA 02221648 1997-11-20
Description
provides a central registry for all display forms, allows dirr~re,ll forrns to be associated with
devices and operations, provides soft-binding of X11 configure forms to display objects
Export Control: public
Persistence: transient
Concurrency: sequential
Attributes:
private
struct formTable = NULL
Operations:
public
Prototype: BOOL registerForm(configForrn * newForm, enurn deviceType, char *
operation)
Descripfion: a form against a device type and operation
Concurrency: sequential
Prototype: configForm * queryForrn(enum deviceType, char * operation)
Description: other objects to query the display forrn for a given device type and operation
Concurrency: sequential
Class - gemMediator
D~s~ ;~lion
- 13-
CA 02221648 1997-11-20
provides a blocking interface to the services provided in the ATMC base process
Export Control: public
Persistence: transient
Concurrency: sequential
Attributes:
private
long routerAddr = NULL
long seesionID = NULL
socketAddr localSocket = NULL
scoketAddr remoteSocket = NULL
struct * requestList = NULL
Operations:
private
Prototype: callback handleIMF_Reply(void)
Description: c~llb~çl~ handler for socket reads
Concurrency: sequential
Prototype: BOOL lockRequestList(BOOL lock)
Description: semaphore access routine to provide access to the shared request list
Concurrency: sequential
public
Prototype: BOOL sendIMF_Request(struct IMF * request, struct IMF * reply)
- 14-
CA 02221648 1997-11-20
Description: a blocking call for tr~nmi.C~ion of an IMF request
Concurrency: sequential
Prototype: BOOL sendIMF_Reply(struct IMF * reply)
Description: non-blocking request to transmit an IMF reply message
Concurrency: sequential
Proto~ype: BOOL connectBase(void)
Description: the connection to the base process
Concurrency: sequential
Class - NCIF (type=class_utility)
Description
this object provides the access to the NCIF files which contain geometry of devices for
drawing, creation rules for device creation and menu operations associated with devices
Export Control: public
Persistence: transient
Concurrency: sequential
Attributes:
private
char [] baseDirectory = getenv( "em_NCIF" );
struct ncifGeometryTable = NULL
CA 02221648 1997-11-20
struct ncifMenuTable = NULL
struct ncift)ptionLists = NULL
Operations:
public
Prototype: BOOL getGeometry(enum deviceType, struct drawItems *)
Description: the drawing rules for the specified device type from the NCIF files
Concurrency: sequential
Prototype: BOOL getCreateRules(enum deviceType, struct deviceRules *)
Description: the allowable device types for the creation of a new contained device
Concurrency: sequential
Prototype: BOOL getMenu(enum deviceType, struct menuList *)
Description: the list of menu items and associated operations for display when the user
right-clicks on a device
Concurrency: sequential
Prototype: BOOL setR~enirectory(char * newBase, BOOL createIfNotFound)
Description: an e~t~ l object to reset the base directory for all of the NCIF files, causes
the data structures to be re-initialized
Concurrency: sequential
Class Category: atmcForms
- 16-
CA 02221648 1997-11-20
Class - atmcForms (Abstract)
D~q: ;plion
this class provides the frarnework to display a configuration form on the local XDisplay of
the ATMC and/or 46020 (remote XDisplay), all operator interaction is handled by the
widgets
Export Control: public
Persistence: transient
Concurrency: sequential
Operations:
public
Proto~ype: BOOI, openForm(baseOID)
Description: the form to open on the XDisplay, retrieve the associated data and display the
data
Concurrency: sequential
Prototype: BOOL updateForm(struct * updateInfo)
Description: an asynchronous intPrf~ce for the GEM IMF sub-system to alert the from of
changed data, it is up to the form to determine if the data is ap~opliate for display to the
operator
Concurrency: sequential
Prototype: XCallback buttonCallbacks(int buttonID)
Description: form will register callbacks against button actions to allow interaction with the
widgets on SAVE and CANCEL requests
Concurrency: sequential
CA 02221648 1997-11-20
Class - atmcForm_Dashboard
Class - atmcForm_LocalLogin
Class - atmcForm_AddNode
Class - atmcForm_AddRack
Class - atmcForm_AddCard
Class - atmcForm_ConfigureNode
Class - atmcForm_ConfigureRack
Class - atmcForm_ConfigureCard
Class - atmcForm_El_ConfigureCard
Class - atmcForm_STM 1 o_ConfigureCard
Class - atmcForm_STMle_ConfigureCard
Class - atmcForm_ConfigurePort
Class Category: atmcWidgets
Class - atmcWidgets (Abstract)
Description
this class provides the framework to support display of intelligent display objects on GEM
forms
Export Control: public
Persistence: transient
Concurrency: sequential
Operations:
- 18-
CA 02221648 1997-11-20
public
Prototype: XmWidget * init(void)
Description: the widget
Concurrency: sequential
Prototype: BOOL setInitialValue(char * initialValue)
Description: the data value of the widget
Concurrency: sequential
Prototype: BOOL hasChanged(void)
Description: whether the operator changed the value displayed by this object
Concurrency: sequential
Prototype: BOOL canSave(void)
Description: whether the initial value is dirr~rel" than the tl~t~b~e value, application can
deterimine whether a save operation can safely proceed without overwritting changes
Concurrency: sequential
Prototype: BOOL setDBValue(char * newValue)
Description: the just retrieved value into the widget for future comparison by the
application
Concurrency: sequential
- 19-
CA 02221648 1997-11-20
Prototype: char * getCurrentValue(void)
Description: the user editted value
Concurrency: sequential
Prototype: XCallback callbackMethodsO
Description: actions in response to various events sent from the XDisplay
Concurrency: sequential
Class - atmcWidget_Boolean
Superclasses: public atmcWidgets
Des~ ;~lion
provides display of a boolean value, each state (TRUE / FALSE) can be associated with both
a nurneric value and a text string
Export Control: public
Persistence: transient
Concurrency: sequential
Attributes:
private
integer state_O_Int = O
integer state_l_Int = 1
Operations:
public
Prototype: XmWidget * init(RECT * position, int state_O, int state_1)
- 20 -
CA 02221648 1997-11-20
Description: the BOOL widget with the various things it needs to display
Concurrency: sequential
Class - atmcWidget_Float
Class - atmcWidget Button
Class - atmcWidget_String
Class - atmcWidget_Choice
Class - atmcWidget_List
Class - atmcWidget_Integer
Class Category: NE_Objects
Class - NE_Object (Abstract)
Description
This class provides an abstract base class for encapsulation of all IMF_Message interaction
with the corresponding object in the ATMC Net~vork Element Model (NEM). This class will
understand, generate and decode all IMF_Messages associated with this object. It is expected
that each object that the GEM manages will inherit this functionality, and add methods as
required to support all functionality associated with this object
Export Control: public
Pc. ~ .. ce: transient
Concurrency: sequential
Attributes:
private
baseOID objectID = NULL
- 21 -
CA 02221648 1997-11-20
struct * objectInfo = NULL
Ol~e ~lions:
public
Prototype: virtual IMF_Message Get(void)=0
Description: method will generate the approriate IMF_Message to retrieve this object from
the ATMC base
Concurrency: sequential
Prototype: virtual IMF_Message Set(void)=0
Description: method will generate the approriate IMF_Message to update this object in the
ATMC base
Concurrency: sequential
Prototype: virtual BOOL Reply(IMF_Message *)=0
Description: method will decode the IMF_Message recieved from the Base in response to a
previous request
Concurrency: sequential
Prototype: virtual BOOL GetAttr(char * attrName, int * attrValue)=0
Description: method will retrieve a single attribute from the local copy of this object data,
this method will be overloaded based on the type of data expected. The BOOL return type
indicates if the attribute name is valid
Concurrency: sequential
- 22 -
CA 02221648 1997-11-20
Prototype: virtual BOOL SetAttr(char * attrName, int attrValue)=0
Description: method will set a single attribute into the local copy of this object data, this
method will be overloaded based on the type of data expected. The BOOL return type
indicates if the attribute name is valid.
Concurrency: sequential
Prototype: virtual BOOL SetOID(baseOID objectOID)=0
Description: method sets the object ID for this object
Concurrency: sequential
Prototype: virtual IMF_Message AddObject(void)=0
Description: method generates an Add Object message, if applicable for this object, to be
sent to the base
Concurrency: sequential
Prototype: vir~J IMF_Message DeleteObject(void)=0
Description: method will generate a Delete Object message for tr~n~mi~sion to the ATMC
Base
Concurrency: sequential
Class - nodeNE
Class - V3-40_nodeNE
Class - V3-160_nodeNE
Class - V3_nodeNE
CA 02221648 1997-11-20
Class - rackNE
Class - ASN_rackNE
Class - AUB_rackNE
Class - AUB-SMU_rackNE
Class - cardNE
Class - El_cardNE
Class - STM-le_cardNE
Class - STM- 1 o_cardNE
Class - portNE
Class - GEMClient
Description
This object is sirnilar to the NE_Objects in that it provides client side functionality to
generate IMF_Messages for tr~n.~mi~sion to the GEM process. This object is not used
directly by the GEM but is used by clients of the GEM to hide the IMF_Message generation.
Export Control: public
Persistence: transient
Concur, ~,~c~: sequential
Attributes:
private
char * xDisplay= "0:0"
int routerAddr - 0
int sessionID = O
baseOID selectObject = NULL
- 24 -
CA 02221648 1997-11-20
Operations:
public
Prototype: BOOL SetDisplay(char * xDisplay)
Description: the display for the associated GEM, this function does not do anything once
the GEM has been started.
Concurrency: sequential
Prototype: BOOL SetSessionInfo(int sessionID, int routerAddr)
Description: the session and router info for the associated GEM process
Concurrency: sequential
Prototype: IMF_Message DrawObject(baseOID objectOID)
Description: ann IMF_Message that can be transmitted to the GEM to trigger a drawing or
form display for the assocaited object
Concurrency: sequential
Prototype: IMF_Message SelectObject(baseOID selectedOID)
Description: the current object selection on the associated GEM
Concurrency: sequential
Prototype: IMF_Message ClearSelectedObject(void)
Description: the object selection on the assocaited GEM
Concurrency: sequential
- 25 -
CA 02221648 1997-11-20
Prototype: BOOL Reply(IMF_Message *)
Description: all IMF_GUI messages from the associated GEM. Will record the currently
selected object on the assocaited GEM in a local variable for process query
Concurrency: sequential
Prototype: IMF_Message Highli~htT ict(hiliteList * objectList)
Description: method generates a highlight list for the assocaited GEM
Concurrency: sequential
Prototype: IMF_Message ClearHighli~ht(void)
Description: method generates a clear highlight message for the assocaited GEM
Concurrency: sequential
Figure 7 shows the activation of the GEM process in response to a GUI-Login fromthe 46020 to the ATMC using the Qs connection. The interaction inside the base between the
Qs process and the Security Management sub-system is documented in the Security
Management SD. This use case documents the reaction of the GEM to this GUI-Login.
The GEM process is activated using from within the ATMC Base by the Security
Management sub-system. Comm~nd line parameters are provided as follows:
C_ - ~ d Line: /ab~c/' ~ QFM -sesslD 12 -display ck156:0.0 -qsRtrAddr 14
The session ID and the Qs mediator router address indicate to the GEM process that it has
been activated by the 46020. The display tag indicates the X-Display on which to display it's
drawings and forms. No actual output will be generated until an IMF_GUI_Draw command
is received.
- 26 -
CA 02221648 1997-11-20
Once activated the GEM process will perform the following actions:
connect to the BASE process
login to the Session Manager giving the existing session ID
request User Information for this session from the Security Manager
send start reply back to Qs Mediator indicating that GEMprocess is active
The IMF message structure should be augmented with parent process ID tags to allow the
ATMC Base software to verify that the source of the IMF_Messages. This will prevent an
operator from viewing the startup command for the GEM and duplicating this process to start
a potentially privileged session.
In the case of local activation of the GEM, the GEM process will be requested by a local or
remote operator using a Telnet or rlogin type int~ ce. A command line will be entered
identifying the X-Display to be used and the GEM process will respond as follows:
initialize the database and gui API structures
connect the GEMprocess to the ATMC Base
present login form to the operator
collect user information and pass to the Security Manager in the Base for verification
once verified collect user prof le information
indicate success to the operator and present the top levelform for the stand-alone ATMC
At various times during the Qs session with the 46020 draw requests will be received by the
GEM from the Qs Mediator through the Qs connection to the 46020. This request will trigger
a drawing or form dosplay on the existing X-Display attached to this process. The interaction
isit~mi~e~ below:
draw request receivedfrom GEMMediator
common guiDrawNode request invoked
drawing frame is displayed, geometery of node to be drawn is retrievedfrom the NCIFf les
CA 02221648 1997-11-20
actual node data is requestedfrom the common database API
node_NE object is instantiated and initialized with the base OID of the node
the node_NE generates an IMF_Message to retrieve the data from the ATMC base
IMF_Message is transmitted and reply received
IMF Message is returned to the node_NE object, this object is passed back to the drawing
which querys the objectfor attribute information
node drawing is populated on the X-Display
As shown in Figure 8, when a draw request is received on an object without a drawing
association a configuration forrn will be displayed. In the case of a port configuration request
the interaction is shown above, as described below:
right mouse button is pressed, CKNMrequests a card drawing menu for a selected port
menu contents is queriedform the NCIFf les and displayed
menu item is selected and appropriate action, "Conf gure Port" is requested
form is looked up in the form registry and created
port conf gure form used the port OID and an associatedport_NE object to generate a
IMF RES_GetPortRequest for transmission to the ~ TMC base
reply is handed back to the port_NE object
form queried port_NE for attributes, intelligent widgets are created and given the inital
values for display on the X-Display
As shown in Figure 11, when a port configuration form is displayed, either locally or
remotely, the operator is permitted to manipulate the data on that form. At some point in time
the operator will request that the data be saved. The object interaction is described below:
buttonPressed event is receivedfrom operator
the form checks if anything has been changed by the operator
- 28 -
CA 02221648 1997-11-20
port conf gzlre form requests current data from the ATMC base to determine if the data have
changed since the form was displayed
the port conf gure data is passed into the widgets
the form queries each widget to determine is the data can be safely saved (if the data has
been changed outside of the form, by another operafor, the widget will report FALSE to this
query)
all data is then collected and passed to the database APIfor transmission to the node
Add Node Request from 46020
This use case documents the process occurring when a 46020 operator requests a new node
object created. The first list details events occurring external to the GEM. The information
after the figure below details the actions occurring inside the GEM.
Trigger Events forAdd Node
the 46020 will send a Qs Create Node message to the ATMC Qs Server
the Qs mediator will send a IMF Create Node request to the GEM Controller (the GEM
Controller will receive the message since in Release 2 it will be responsible for getting the
node communication parameters from the user)
an IMF Create Node Acknowledge command will be sent to the Qs Mediator from the GEM
Controller once the message has been received and validated
the Qs Mediator will then send a Qs Create Node Acknowledge to the
the GEM controller will then connect to the node
once the node is on-line, an IMF Event message will be sent to the Qs Mediator indicating
that the node is on-line
the Qs Mediator will then send a IMF Reconcile Node command to the V3 controller which
will initiate the internal reconcile of the node
the Qs Mediator will ignore any events generated by the node creation
- 29 -
CA 02221648 1997-11-20
when the reconcile is complete an IMF Reconcile Complete Reply will be sent to the Qs
Mediator
the Qs Mediator will send multiple IMF Get Requests to the V3 Controller
the V3 Controller will send multiple IMF Get Replies to the Qs Mediator
the Qs Mediator will convert the Get Replies into Qs Datasync Add Event Notifications and
send them to the 46020
when the reconcile is complete the Qs Mediator will send a Qs Datasync Modify event to the
46020 to change the node status to on-line
Once an add node request is received by the GEM a configuration form must be displayed on
the remote X-Display (46020 or other) to collect association information for inclusion in the
IMF_Message request to add a new node to the ATMC database. The interactions occuring in
the GEM are detailed below:
add node request is received
add node form is displayed on X-Display
data is collectedfrom widgets
new node_NE object is created and it is asked to generate an IMF_Message for adding a
new node
the message is transmitted to the ATMC Base and a response received
an IMF Message is returned to the Qs Mediator to indicate that the mdoe has been created
Figures 13 to 18 show interaction diagrams for use cases.
[GLOSSARY]
46020 Newbridge Networks Corporation Management Platform.
API Application Programming Interface. Exported set of functions andlor
messages used to interface with a software module.
- 30 -
CA 02221648 1997-11-20
ATMC ATM Commander. The software that provides element management
services for the Siemens EWSX V3 node (which is also known by the Newbridge name of
36109).
Base Refers to ATM-Commander 's Base Architecture and all processes within it's
process boundary.
BCT Basic Craft Terminal. Software that provides a simple (usually text based)
interface to a node.
CRISS7 Call Routing and common channel Signaling System number ~.
EF Event Forwarder. Responsible for prop~ting event objects from the
objects/modules producing them to objects/modules interested in events.
EWSXV3 Siemens ATM digital crossconnect switch.
GEM Graphical Element Manager. CrossKeys ATM-Comm~n(ler GUI, used to
manage the Siemens EWSX_V3 network element, and later, other vendor nodes.
GUI Graphical User Interface.
IMF Internal Message Format. A message format used internally by the ATM
Comm~ntler software.
NEM Network Element Model.
OID Object Identifier. Identifier that is used to uniquely reference an object. It has
the form of a sequence of numbers separated by a period (e.g. 1.3.55.23 . . .).
OM Object Model. The collection of objects defined and modelled within the
application. These are m~int~ined in a database.
Qs A published int-o.rf~se to the 46020. This interface is defined by Newbridge.
Q3 A standards based int~rf~ce for m~n~ging network elements. The Siemens
EWSX V3 is managed via a Q3 interface.
TCP/IP Transmission Control Packet Protocol.
