By David Zinman

Software programming can be a solitary or collaborative effort. Similarly, so is creating music. The idea for both can be a singular endeavor, but it most often takes a combined effort to reach the finish. This similarity is described in the book by Andrew Johnston and Chris S. Johnson “Extreme Programming: A More Musical Approach to Software Development?“ where they hypothesize on the resemblance between musical and software development environments:

The characterization of software development as a craft rather than an engineering discipline has been proposed recently and it is felt that by considering the similarities and differences between the working and learning environments of musicians and developers that some further weight can be given to calls for a more collaborative approach to software development.

The debate that writing software code is an art has been around almost since coders have existed. I would not go so far as to say anything I have coded is “artistic” but some of the novel ideas that come from very focused coding fit with the idea of creating a piece of music.

Music is the organization of sounds with some degree of rhythm, melody, and harmony. I would argue that harmony should not be included in this definition since even a single voice is considered music where no harmony is present.

But the important idea in this definition is organization: it is the idea of organization and patterns that is common to both music and software. Design patterns are now an integral part of software development. A design pattern is a general reusable solution to a commonly occurring problem in software design. The most famous pattern in music is probably the opening sequence of Beethoven’s Fifth Symphony (G G G E-flat). Beethoven repeats this pattern several times in the movement in several variations. Once we understand the pattern of a particular piece, be it coded or musical, we are well on our way to a solution.

Jonathon Kohl explains the tension/resolution that makes up music is applicable in software testing. I would go further and say that it also applies to software coding. There is the intangible feeling of tension when an algorithm is in development, and the feeling of relief upon its successful resolution. For a great example of tension/resolution in music listen to Lenny Kravitz’ Mr. Cabdriver.

I would like to think that we should not be so pragmatic as to look at software development as being”solving a problem in order to start creating.”

It doesn’t really matter though because when I am done I put on the headphones and crank some Zeppelin. Anybody want to jam?

By David Zinman

A problem that often occurs in any software system is related to resource constraints or limitations; how do you make the best use of the resources that you have? This article will examine the challenge of designing a functional web user interface utilizing light server processing.

Modern hardware that handles copious amounts of sensitive data requires faultless processing, uninterruptible operation, and ease of use. The term ‘ease of use’ implies a user interface of some sort, in this case a web GUI. However, a highly interactive web interface can have an impact on the operation of the hardware if general processing is interrupted in order to handle user interface requests. In environments such as HTML: java script(.js), active server pages (.asp), or proprietary GUI development in C++, C# or Visual Basic, how do we maximize user interface functionality while minimizing processing on the server?

Maximize Client Processing

One solution is to limit the amount of processing on the data server that is devoted to the user interface. This may or may not be used with a third party user interface proxy server (UIPS) depending on the environment. A system that expects few concurrent users (typically 5 or less) can operate as:

UI client <–> data server

where there is not a huge demand on the processor.

A system that demands more concurrent users (6 or more) can benefit from a third party UI server operating as:

UI client <–> UIPS <–> data server

that will offload more processing power to the user interface proxy server.

Data Processing in the GUI

Giving some thought as to defining the structure of the data can be very significant in efficient data handling. Web Service Definition Language (WSDL) for SOAP, Management Information Base (MIB) for SNMP or other data syntax design for generic or specific data driven protocols should be given a high priority to assure non-redundant, efficient and light but complete coverage of information. Both the server and the web client will use the same data syntax for their respective communication layers, and as such, a data format that integrates to the system in an efficient way must be chosen.

One of the biggest burdens that is dumped on the server by data acquisition is table processing, especially large two dimensional lists. To alleviate as much overhead as possible make sure any sorting routines are carried out on the client. Table indexing in the data definition can be a big help in facilitating efficient data access.

Scripting languages can be slow and cumbersome. If possible, there should be no scripting engine residing on the server. The data is to be served in as raw a form as possible and all scripting should be carried out by the client.

Statistical data can pose a problem. Multiple server access for several statistics can put a heavy load on the server. Polling intervals should be set for a span that reports relevant information but does not overload the server.

Tradeoffs

These solutions do not come without a price. No server side scripting puts an extra effort on client development. Often the question of adding more data to a network request or supporting functionality on the server must be decided. The GUI itself must handle many of the routines easily handled on the server. This in turn can make the GUI slow and cumbersome. Consequently expert and efficient programming methods will help alleviate this issue.

By Luan Pham

One of our projects at MapleWorks in the last year required us to integrate the Open Shortest Path First protocol (OSPF) into a residential gateway product. Since OSPF is a mature protocol, and many implementations existed, it was our task to determine which OSPF stack was most suitable given timeline constraints that surround any onshore software development project.

Based on our experience, IP Infusion was the natural choice as it provided everything we needed in a modular architecture. However there was some natural scepticism about our decision, and this resulted in a survey of all the OSPF offerings that we knew of or could find on the Internet. We summarized our findings in the table below. Our survey was performed in May 2007, and much of the accuracy of the information was dependant on technical documentation publicly available at the time.

Description of columns:

OSPF Stack Vendor: IP Infusion, Data Connection, Aricent, XORP, Vyatta, Ospfd, OpenOSPFD, Zebra

Modular Architecture: Is OSPF decoupled from the RTM and other routing protocols? In the future there may be a requirement to have RIP and OSPF running at the same time. A non modular architecture would make it difficult to integrate RIP with OSPF so that both protocols run at the same time.

Management API: Does OSPF come with a clean management API to provision the protocol?

Maturity: How long has the protocol been around? Usually the longer its been around, the more bugs it has resolved making it a more solid product. This is where commercial offerings beat Open Source options.

Cross compiling: Has the code been written to support processors with big endian as well as little endian? Most development is done on PCs which uses little endian, and all too often when code goes from one processor to another, issues with byte alignment arise. These automatically introduce bugs, and will take incur additional costs in time and money.

Open Source: Is the product open source?

Extra cost incurred relative to IP Infusion: Since the IP Infusion stack contained everything that was required for the project, it was used as a baseline to compare against all other offerings.

(Luan Pham is a Senior Software Engineer of MapleWorks Technology Inc, the smart choice for onshore software development for networking and telecom companies.)

(second of a two-part series)

By Ravi Ravishankar

In my last post (actually my first contribution as a blogger!), I discussed how for many small to medium sized equipment vendors, developing a good EMS/NMS solution is an afterthought. In trying to decide how to build it right, time and money are often sacrificed out of proportion to the actual task due to lack of domain expertise. Even if you disagree with that observation, I want to pick up on the last post by sharing some how-to on building a great solution based on what we’ve learned here at MapleWorks.

Let’s start with the main application screen. This screen should present a comprehensive view of the managed network. In a typical network this will include the list of all managed nodes, status of the nodes, fault summary, server status information, logged in user information, etc. In addition the most common/important detailed information can also be shown. In a telecom network this could the topology view of the managed network.

The layout of the screens is important as this is what gives the first impression about the application. The information presented here should be grouped according to relevance and mapped on the screen. Foremost is to show the nodes that are being managed, and this typically would be in a tree view on the left area of the screen. If groups features are supported then the groups should be displayed and the nodes under the groups can be viewed by expanding the group.

The individual nodes should display current status to the NMS server and both the nodes and the groups should display alarm summary counts. The main area of the screen should be used to view and configure functionality provided by the NMS application, like topology view, PM data, admin functions, error logs, etc. The user should be able to easily navigate between these views to access different functionalities while the rest of the screen displays real-time status information.

The colors and icons used in the GUI should be carefully coordinated so that the user is not confused when viewing the information presented. In general neutral colors should be used as much as possible making sure that the color coded alarm information is easily distinguishable. One of the areas where there is a lot of room for creativity is in the display of topology information. This is due to the number of nodes being displayed as well as the type of network connectivity.

Displaying mesh connectivity is not the same as displaying a linear network! Regardless, the graphics used to represent the topology (nodes and links) should be well designed and suitable for the entity they represent, otherwise the view can look a mess. This can be more challenging in applications that do multi-vendor network management. Some implementations have used photo images of the actual vendor equipment to distinguish the nodes but this can easily make the topology view quite an eyesore,

The information presented in your application should be clear and concise. The user should be able to easily navigate the screens and also be able to drill down to get more information.

In the case of the topology display there are several options to present the information. Among these are the use of expand/collapse capability for the node graphics, node annotations, layered view and/or drill down views, etc. The objective is to present the network topology in a clutter free form and at the same time provide the capability to delve further in to obtain more detailed information as required.

Let’s take the example of a long haul SONET network. In between the ADM nodes it may use optical repeaters (amplifiers) but the default topology view could just show the ADM nodes with the interconnecting links. There could be two options to show the components at the optical layer; one is to launch a dialog from the link of interest to view the supporting optical repeaters, and the other would be to give an option to expand the current view to redraw it showing the optical repeaters between the ADM nodes. This is an example of how the topology view can be managed as well as provides drill down capability to access information as needed.

A well designed GUI for a Network Management system should be pleasant to the eyes, provide easy to use features, and have well thought out functionality. In a crowded and competitive market space it could make or break sale of networking equipment.

(Ravi Ravishankar is a Senior Software Engineer at MapleWorks Technology Inc., the smart choice for onshore software development for networking and telecom companies.)

(first of a two-part series)

By Ravi Ravishankar

A good customized Network Management system can be the difference between making or losing a sale in the highly competitive telecom/datacom equipment industry. This is a key reason that the big equipment vendors have their own EMS/NMS applications. They have been at this for a long time and have products in the market that are fairly good at providing the required FCAPS (Fault, Configuration, Accounting, Performance, and Security) functionality to support their equipment.

On the other hand it is the medium to small sized vendors who are in a bind as to whether to develop their own EMS/NMS applications from scratch, use 3r party applications or have them built by someone else. Regardless of how this finally gets done, the end product should be something that can be used as the differentiator against the competition.

There are different architectures and technologies that can be used to build the product but the bottom line is the impression it makes on the prospective customer that finally matters. This impression is created by many factors, not the least of which is the look and feel and the ease of use of the application.

For many of the small to medium sized equipment vendors, a good EMS/NMS solution is an afterthought.  Additionally, a good number of these vendors do not have the domain expertise in this space. Trying to decide how to build it right can result in a loss of time and money – something that seems to happen fairly often in the telecom industry.  A fair bit of the time is wasted due to requirement churn and user interface changes. Therefore it is safe to say that starting the effort with good prior knowledge is a key to building a successful Network Management application.

A good EMS/NMS application should have solid coverage of the FCAPS functionality customized for the network that is to be managed. Respecting your time today, on my next post I will discuss what I feel are some of the important GUI features to consider when implementing a Network Management application for managing telecom/datacom equipment, with emphasis on network topology display. In the meantime if you want to weigh in with your own experiences on developing EMS/NMS applications please leave a comment and let’s continue the dialog.

(Ravi Ravishankar is a Senior Software Engineer at MapleWorks Technology Inc., the smart choice for onshore software development for networking and telecom companies.)