Main Menu

Project Life Cycle

List of wishes


Wishes of the end users

Summary
Description
Reporter
Date
References
Wavelengths in cNIS
  Jan Ferre (Uni-C)
2011
Question about possibility of entering fibres, wavelengths
Fibres in cNIS
  Jan Ferre (Uni-C)
2011
Question about possibility of entering fibres, wavelengths

Wishes of the community (end users and developers) reported via JIRA issues tracking tool

The following table presents reported tickets which have not been included in the current release plan.

Ideas of development team

Below you can find ideas that arose in developers' heads during the long time of cNIS development.

New applications

Network inventory database

Storing rich information about devices and fiber infrastructure, including documentation files like photos, diagrams, specifications and others.



New features

General network view and technology specific perspectives

In current version of cNIS (2.2.0) there are three network technologies distinguished (IP, Ethernet and SDH). Unfortunately they are separate modes rather than perspectives on the same network. Thereby there are different kinds of devices distinguished:

  • In IP mode: a router,
  • In Ethernet mode: a router or switch,
  • In SDH mode: a generic SDH node.

A goal of this extension is to achieve the following:

  • General view on the network, devices and links. This means that each device should be just hardware and then should have its type specified (e.g. IP router, Ethernet switch, printer, etc.).
  • Specific views (perspectives) on the network for all supported technologies (IP, Ethernet, SDH). It should be possible to see the network from specific perspective to see only technology specific features of the network. For example, in the IP perspective a user could see only IP routers, printers, etc. with their IP addresses, network masks, etc.
  • General network discovery panel to discover devices in the network no matter if they are IP routers, Ethernet switches or others.

Receiving alerts and notifications about topology changes from external systems

External sources like monitoring systems or even devices could alert/notify about changes of their state or even the topology. cNIS could receive such alerts, match them to stored topology information and update affected data.

Notifying external systems about topology data change

cNIS could provide a tool (e.g. WS call) able to notify other applications about a change of the topology information stored in a cNIS database. External applications would be informed about topology updates similarly to how a standard PC processor handles interruptions (opposite to a polling approach).

Representation of a fiber infrastructure layer

Currently, cNIS supports IP, Ethernet and SDH layers of the network. Anyway, an effort to model the lowest network layers has been made. Proposal of the final database schema is available here. Fiber and OTH parts of this schema are to be reviewed (maybe even redefined) and implemented in cNIS application.

Export of network data

Currently you can discover network topology by the plugins and browse it via CMA. The proposition is to add posibility to export data into excel file - it could be useful for manage large networks. There are two ways to do it. An easy way is to export it to csv file. More complicated but more flexible way is to use some reporting engine like jasper reports.

Feature improvements

Ability to add a link of a non-standard type

This use case is about ability to add a non-standard type of a link between devices. Currently it's impossible in cNIS to add a link other than any of the known types (IP, Ethernet, SDH). The type of a link could be simply specified by a text value, e.g. 'FR'.

Distinguishing between device types (server, host, printer and others)

This issue is about ability to specify a type of a device. Currently cNIS distinguishes between IP routers, switches and SDH nodes. The goal is to distinguish more device types, like servers, hosts, printers, IP phones and other.

Ability to jump from visualization panel to HTML page and vice versa

User can retrieve the data from cNIS using two modes: tabular (all stored information is displayed) and graphical (general information about visualized devices). It is impossible to select a visualized object a get complete information about it. Some "redirection" mechanism is needed.

Visualization of a selected part of a network

Currently it is possible to display a map of an entire network through one of three perspectives (IP, Ethernet, SDH). It's impossible to select a part of the network.
cNIS could give a possibility to narrow down a displayed scope of the network.
This use-case needs more requirements.

Organizing a network map layout using a mouse pointer

cNIS could give the user a possibility manual organizing network nodes on a diagram with use of a mouse pointer. This would make the diagram easier to understand by the user. How the nodes are located could be remembered by cNIS so the network diagram could be displayed to the user with the same layout.

Broken links distinguished by a network map and a diagram

This is tightly connected to 3.3 which is about receiving notifications from external sources.
cNIS could present information about broken links to the user by distinguishing affected links on the netwotk visualization panel.

Writing and updating topolgy data through Web Services interfaces

Current WS interfaces allow downloading topology data. There is no way to upload/update topology information by an external system/application.
WRITE access means extensions to the WS interface so external systems/applications could upload and update the topology information stored in cNIS.

Better customization of automatic discovery - a simple way of adding support for new devices (to be completed)

It should be relatively easy, for a cNIS user/administrator, to add support for automatic discovery of new devices. Currently it's possible to do it by writing a new plug-in in a Java programming language. In this case the user is expected to have an experience in Java-based application development. A more easy way could be [???].

Getting localization directly from the map

Currently there is no way to point a location on the map and get it's coordinates. It is worth to consider to add the component (e.g. google maps), from which you can pick the coordinates.

Granting permissions to a group

Currently you might only grant permission to an user. The proposition is to add a grant to the group - the user should inherit all the permissions from the group he belongs to.

Adding users to a group from a group screen

Currently you can only add user to a group from user screen. Consider situation, when there are a lot of users in the system and you are adding a new group. To add users to this group you must edit every user, you want to belong to the group. This can be done easier by adding users from a group screen by selecting them from an user list.

User friendly component to adding nodes and defining links between them

Currently hand defining link between nodes is difficult. E.g. if you want to add two IP routers and link between them, you should define router A, then the router B (from another screen) and switch to another screen to add link between them. It should be possible to do it all from one screen, for example in a flash component.

There is too few path to managing the components

Currently you can add the components mostly from one screen. For example you can can add router interface only from "router edit" screen. In the "domain edit" screen, you can see interfaces in this domain, but you can't define new one. This option is not necessary and redundant but it can make cNIS more user-friendly.

Installation and administration

cNIS binary distribution with Apache Tomcat embedded

This use case is about embedding the Apache Tomcat in cNIS and distributing it in a single package.

Pros:

  • simplified installation of the software, because deploying cNIS in a web server is already done.

Cons:

  • Forces the 'cnis-support' team to solve Apache Tomcat specific issues.



Implementation

Separated & lightweight Java implementation of cNIS data model

cNIS data model is a scheme of data describing a world of computer networks. cNIS POJO classes provide a Java object representation for that data model. This representation is used by cNIS developers to represent the networking world in cNIS applications. It can be also used in any other software product that processes topology data. External developers can use it to develop their own 'network topology based' applications.
Real life use case:

  • GEANT2 network services (like AMPS or AutoBAHN ) or other application can use a part of existing cNIS implementation (e.g. a JAR file) for internal representation of topology data.

Deliverable:

  • a lightweight binary distribution of the cNIS POJO classes.

Technical issues:

  • POJO classes have to be separated from others so they could be placed in a separate JAR file,
  • set of Maven dependencies for POJO classes has to be minimized.

Java framework for cNIS database support

cNIS stores data in a database. To support database storage a dedicated framework has been implemented in scope of the cNIS project. The framework can be used by external programmers to develop an application which is able to work with cNIS data model and store topology data in a cNIS database. The framework can be used to integrate other applications with cNIS on the database level.
Real life use cases:

  • An other application works with cNIS data model and needs to be able to store the data in a database.
  • An other application (like AMPS or [AutoBAHN]) shares the same database with the cNIS service.

Deliverable:

  • A lightweight binary distribution of a framework providing cNIS database support.

Technical issues:

  • Database scheme (Hibernate mappings) and other relevant classes need to be separated from the rest of cNIS sources,
  • the framework need to be independent on all unnecessary and heavy libraries (like [SpringFramework]).

Java framework for processing cNIS data model in XML

cNIS or other application working with the cNIS data model can use the framework to represent data in XML. XML is often used to exchange data using disk files or web services communication. Applications can use the framework to convert cNIS Plain Old Java Objects (POJO) to XML format and to load XML data into the cNIS POJO.
A lightweight distribution of the cNIS XML Framework can be used by external developers to develop applications able to exchange cNIS data in an XML format.
Real life use cases:

  • Developers of a GEANT2 service that need to cooperate with cNIS can use the framework to implement cNIS XML data exchange.

Deliverable:

  • a lightweight binary distribution of a framework for processing cNIS data model in the XML format

Technical issues:

  • to refactor, extend and/or design brand new XML schema covering the whole cNIS data model.
  • To implement two-way Java-to-XML mapping that can be used for data marshalling and unmarshalling.

Separating a Java framework for network topology discovery

cNIS uses its internal framework Network Discovery and Management Application to manage network topology changes. For automatic collection of network topology data the NDMA uses another internal framework called Network Explorer. However the NE can be used by developers of any other project based on automatic network discovery.
Real life use cases:

  • Developers of plugins to Network Explorer need the framework to use it as a base for the plugin implementation.
  • Developers of other applications can use the framework to implement the automatic network discovery functionality.

Deliverable:

  • a lightweight binary distribution of a framework that can be used for NE plugins implementation and for automatic network discovery implementation.

Technical issues:

  • to refactor cNDMA sources: NE and cNDMA have to be separated.

Java framework for accessing cNIS external interfaces

Framework for accessing cNIS external interfaces in an easy way. External developers can use such framework to integrate their applications with cNIS.
Real life use case:

  • Developers of an external Java or non-Java service takes an interface specification (WSDL) as a base for a web service client implementation.
  • Developers of an external Java service takes a Java binary implementation of a cNIS web service client to easy implement a communication with cNIS.

Deliverable:

  • A lightweight binary distribution of a framework for accessing the cNIS external interfaces.

Technical issues:

  • The distribution should include WSDL files which can be used by all developers to develop a cNIS web service client.
  • The distribution should include an implementation of a cNIS web service client which can be easily adopted by other Java developers.
Skip to end of metadata
Go to start of metadata
Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.