C H A P T E R 2

Basic Concepts

This section provides an overview of the concepts in Cisco EMF which should be understood prior to
starting development of any Cisco EMF-based integration solution using the CORBA Gateway. These
concepts result in benefits including:
• A future-proofed, flexible software architecture which can be extended to meet your application
requirements
• A protocol independent object model which forms the foundations of Cisco EMF applications
• A mechanism for ensuring that all applications, no matter who develops them, inter-operate
seamlessly with each other and the standard Cisco EMF applications. This is particularly suitable
for the multi-vendor, multi- technology environment which exists in carriers today.
We assume that you are a software development professional with both object oriented software
technology expertise and network management skills. In particular, we assume you are familiar with
CORBA, and the basic concepts of network management systems integration.
Developing CORBA applications on Cisco EMF will therefore involve a number of techniques and
concepts which you will be familiar with, and a number which are unique to Cisco EMF.
This chapter includes the following information:
• CORBA, page 2-1
• Cisco EMF CORBA Gateway Design, page 2-3
• The Participation Framework, page 2-4
• DataAbstractor, page 2-5
• Object Group Server, page 2-5
• Event Channels, page 2-5
• ActionLauncher, page 2-6

CORBA
CORBA (Common Object Request Broker Architecture) is a distributed object architecture that allows
objects to interoperate across networks regardless of the language in which they were written or the
platform on which they are deployed. Thus CORBA allows developers to write applications that are
more flexible and future-proof, to wrap legacy systems, and to code in the language they know best.

Cisco Element Management Framework Version 3.2 Service Pack 7 CORBA Gateway Developer Guide
OL-4684-01 2-1
 Chapter 2 Basic Concepts
CORBA

The Object Request Broker (ORB) is the middleware that handles the communication details between
the objects. The CORBA 2.0 standard, adopted in December of 1994, defines true interoperability by
specifying how ORBs from different vendors can communicate using a common protocol. CORBA is
increasingly being used in the telecommunications field to provide connectivity between different
applications and protocols.
Each CORBA object is basically broken into two pieces, a client-side proxy and a server-side
implementation. The server side implementation contains the application logic. The client-side proxy is
a proxy for the server-side object, and forwards method calls to the server-side implementation. On
instantiation, the client-side proxy binds to the server-side implementation to tie together the two pieces.
For further information on CORBA and development of CORBA applications, please refer to Other
Resources, page A-1.
The ORB chosen for the development of the Cisco EMF CORBA servers is Orbix from Iona
Technologies.
Orbix is CORBA 2.0 compliant, and so the CORBA Gateway is interoperable with CORBA 2.0
compliant ORBs from other vendors. Developers of client applications may choose to use Orbix,
OrbixWeb or any other compliant ORB. The examples in this manual use Orbix as the client-side ORB,
but instructions for connecting clients using a different ORB will be given in the Tutorial section.

Interface Definition Language

CORBA Interface Definition Language1 (IDL) is an abstract programming language used to define the
interfaces to the CORBA servers. IDL defines the functionality offered by the servers without specifying
anything about the underlying implementation of those servers.
To develop a client application, the developer must take the IDL file provided with the server, and parse
it using an appropriate IDL compiler. IDL compilers are readily available, both commercially and as
freeware, to serve most languages and platforms. The generated stub code can then be incorporated into
the client application.

The CORBA Naming Service

The CORBA Naming Service is one of the services defined by the OMG as part of the CORBA standard.
Servers can register themselves with the Naming Service, and their object reference is mapped against
a hierarchical naming structure. Clients can then easily locate the server by asking the Naming Service
to lookup the appropriate name.
The IDL file defining the Naming Service is supplied by the OMG and is therefore standard across all
ORBs, but there are various implementations provided by different ORB vendors. The IDL file should
be equivalent, regardless of which ORB is being used. The Cisco EMF CORBA Gateway uses the Orbix
Naming Service from Iona Technologies, and the IDL file (called NamingService.idl) supplied by Iona
can be examined in the Developer Toolkit.
If using a different ORB for the client side, the NamingService.idl file should be compiled using the
client-side IDL compiler to generate the NamingService.hh file for inclusion, and stubs for linking in
with your client code.

1. CORBA Interface Definition Language is a registered trademark of the OMG.

Cisco Element Management Framework Version 3.2 Service Pack 7 CORBA Gateway Developer Guide
2-2 OL-4684-01
 Chapter 2 Basic Concepts
Cisco EMF CORBA Gateway Design

Understand the Object Model of your Element Manager

Cisco EMF is based on a flexible dynamic object model which enables you to model a complex network
in object oriented terms, with each network element modeled as a network object. This provides both a
user and network centric view of the network topology and equipment. This is in contrast to the effective
‘one dimensional’ view often provided by SNMP MIBs. Such ‘dynamic object modeling’ typically
involves a process of mapping attributes from the local Cisco EMF database and SNMP sources into
Cisco EMF objects.

Object Identifiers
In Cisco EMF, it is not just managed network objects that are objects. Every attribute, object class, event,
containment tree etc. is an object, identified by a unique, generic, and opaque Object Identifier, or
ObjectID. The type of the object (class, attribute, etc.) is encoded within the ObjectID. The ObjectID is
modeled in IDL by the ATL_OBJ::ObjectID structure.
The ObjectIDs for known named objects can be retrieved using the AtlNaming interface, see Chapter 6,
“Naming and Identifying Cisco EMF Objects”. Typically, for efficiency, a client application will retrieve
the ObjectIDs for the containment trees, object classes and attribute names it requires at the start of the
program and store them for later use.

Cisco EMF CORBA Gateway Design

A client of the Cisco EMF CORBA Gateway must first make contact with the CORBA GatewayManager.
This server controls access to the other Cisco EMF servers by verifying the client’s userID and
password. Cisco EMF permits users to access only the services for which they have been authorized.
Refer to the Cisco EMF User Guide for further details of Access Control. Identification of the user
allows audit trail facilities to be provided.
The services which will probably be of most interest to external clients are:
• Participation—Allows external clients to initiate and participate in object lifecycle operations such
as creation and deletion
• ActionLauncher—Enables the client to invoke actions on element managers
• Event Channel Manager—Allows clients to receive Cisco EMF events
• Object Groups—Enables clients to create, change and query the object groups that exist inside of
Cisco EMF
They are supported by two utility services:
• AtlNaming—Used to translate between network object names and Cisco EMF ObjectIDs
• DataAbstractor—Allows Cisco EMF object attributes to be retrieved and set
Further information on the Cisco EMF servers can be found in the Cisco EMF Developer Concepts
Manual. However, it must be borne in mind that not all concepts described may be applicable to the
CORBA developer.

Cisco Element Management Framework Version 3.2 Service Pack 7 CORBA Gateway Developer Guide
OL-4684-01 2-3
 Chapter 2 Basic Concepts
The Participation Framework

Cisco EMF CORBA Server Design

The Cisco EMF CORBA Gateway design adopts a ‘service-oriented’ approach, that is to say, there are
a small number of CORBA server objects which provide the functionality to manipulate the large
number of network managed objects. Managed objects are identified and manipulated by opaque
identifiers, and are not exposed as CORBA objects in their own right. This approach was taken for
reasons of scalability and speed, since instantiating every managed object as a CORBA object would
impose a heavy overhead thus limiting the system’s scalability without adding functionality.

Asynchronous Calls
Cisco EMF uses asynchronous communications almost exclusively because synchronous calls which
initiate time-consuming processing on the servers can potentially block for long periods of time. By
avoiding these processing bottlenecks, this asynchronous design has proved quicker and more robust
than synchronous versions. The CORBA Gateway API also heavily relies on asynchronous calls to
reflect this underlying design philosophy.
For each interface which uses asynchronous calls, there is a corresponding callback interface, and for
each asynchronous request call, there is a callback method in the callback interface. This callback
method is used to reply to the user, returning the result of the request. The object reference for the object
which instantiates the callback interface is passed as a parameter to the request call, along with a
userdata parameter, which is returned to the user with the reply callback, and can be used to correlate
the requests with their replies.

The Participation Framework

The Cisco EMF Participation Framework has been developed to allow arbitrary clients to initiate and
participate in arbitrary object management operations within Cisco EMF. The Framework is completely
generic and data-driven, so although its main use at this time is for object deployment, it could be used
for other types of object lifecycle operation in the future.
There are three types of actors involved in a Participation scenario:
• ParticipationCoordinator
• Participant(s)
• Initiator
The Participation Coordinator is an Cisco EMF server which oversees the Participation operations.
The phases of the operation cycle are represented by a number of participation levels. The coordinator
ensures that all the levels have been processed in the correct order for successful completion of the
operation.
The data which defines the operation to be carried out is encapsulated in a participation context. The
initiator creates the context and fills it with the appropriate data, before submitting it to the coordinator
to initiate the operation. The initiator also specifies the start and end levels of the operation. An
application which creates new managed objects in Cisco EMF is an example of an initiator.
Each participant registers with the coordinator to indicate its intention to participate in operations at a
particular level. An inventory reporting application which needs to monitor managed object lifecycle
events such as object creation and deletion would be an example of a participant. As the operation
proceeds and reaches a level at which there is a registered participant, the coordinator will pass the

Cisco Element Management Framework Version 3.2 Service Pack 7 CORBA Gateway Developer Guide
2-4 OL-4684-01
Chapter 2 Basic Concepts
DataAbstractor

context to that participant, which can then carry out its processing or monitoring (including modifying
the contents of the context). When ready, it passes the context back to the coordinator. The coordinator
then passes the modified context on to the next level and registered participants in the cycle.
If the operation encounters an error condition and fails, it will start to revisit the earlier levels in reverse
order, giving the participants the opportunity to undo their processing.
Upon reaching the final level, the initiator is informed of the successful completion of the operation, and
is passed the final contents of the context.

DataAbstractor
The data abstractor is used whenever you need to traverse a containment view. It is also used for getting
and setting attributes. Hence the primary role of the data abstractor is for provisioning and inventory
management. In the future the DataAbstractor is also going to be used for fault management - raising,
acknowledging and clearing faults, and performance management - to get historical performance data.

Object Group Server

The CORBA Object Groups API allows clients to manipulate Cisco EMF Object Groups.
An object group is simply a collection of objects which are related in some way. They may all be the
same type of equipment or all belong to the same customer.
Object groups can be built either manually or by building a query. Some Cisco EMF subsystems may
also build object groups which may be visible and usable by the Cisco EMF user.
The CORBA Object Group server provides CORBA clients with the ability to manipulate the Object
Groups stored in Cisco EMF. CORBA clients can create and delete object groups using the CORBA
Deployment interface. Also, clients can add or remove objects from groups and iterate over the contents
of object groups.
A good example of the use of the CORBA Object Group server is obtaining all the CISCO 6260 devices
being managed and then using the CORBA ActionLauncher to perform an action on each of them.
Further information on Object Groups may be found in the Cisco EMF Developer Concepts Manual.

Event Channels
The Event Channel Service can be used for fault management to notify an EMS of a new alarm, or the
change of status of an existing alarm. It can also be used in provisioning and inventory applications to
notify the higher level system of new network elements or insertion or removal of modules in a NE.
The Cisco EMF CORBA Gateway uses the standard OMG Notification Service to export internal events
to interested CORBA-based clients. The clients register with notification channels, expressing their
interest in particular event types available on the channels and optionally specifying a filter to be used.
The events exported allow clients to keep track of changes happening within Cisco EMF, for example:
• Object Creation /Deletion
• Metadata changes
• Alarms raise/cleared
• Attribute changes

Cisco Element Management Framework Version 3.2 Service Pack 7 CORBA Gateway Developer Guide
OL-4684-01 2-5
 Chapter 2 Basic Concepts
ActionLauncher

• SNMP Traps received / mapped

• etc
The Events are sent via the CORBA standard's Notification Service, this service has full filtering
capabilities and implements various optimizations

ActionLauncher
In some Element Managers provisioning of services to subscribers is done using user actions. The
ActionLauncher allows CORBA clients to invoke actions in Cisco EMF. Actions are high-level
commands which perform complex tasks on an element manager. These are the tasks which are typically
launched by the end user clicking a button on the EMS GUI. For example -
• Connecting a new subscriber to a service
• Initiate a software download
• Initiate a sub-rack discovery
• Call APIs on an EMS
• Set/Move the state of object in an EMS

Cisco Element Management Framework Version 3.2 Service Pack 7 CORBA Gateway Developer Guide
2-6 OL-4684-01