The Singleton as a Network Management Pattern

Service-driven networking requires rapid automated provisioning in response to user demand. Suppose you want to increase your allocated bandwidth or access the latest broadband game from your service provider. You fill in an online form, a provisioning server updates your profile, and you then have access to the required resources. Service providers are falling over themselves to achieve this type of customer response! Speed and accuracy of order fulfillment is of the essence.

An important element of this is the provisioning server--the software that modifies the network to deliver a requested service. In this article, I'll look at how to use the Singleton pattern, among others, to implement a simple, extensible provisioning server. The latter could be used to modify the bandwidth of the service provider link for two types of users: a home office user, and a large enterprise network manager.

A good reference for this material is Craig Larman's Applying UML and Patterns. As is well described in Larman's book, the major merit of using patterns is the speed at which fairly complex and complete software can be written. The other merit is that patterns encourage architects, designers, and developers to think outside the box (i.e., outside the code) by sharing a common vocabulary. A simple example is when an architect or designer says, "Class X should be loosely coupled to class Y, because Y will change in the next release." The developers can then create the two classes so that X and Y are minimally co-dependent. This is a pattern example that helps in reducing unnecessary future code changes.

One of the best investments of our precious time is to study a good patterns book and, as you read it, try to dream up applications (in your own specific domain) for each of the different pattern variants. This is a difficult undertaking, but potentially very rewarding; later, when you're embroiled in a project and trying to solve tough problems, you can consult your patterns notes to see when/if a pattern can be employed. This is also often a good time to update your notes. Patterns help move practitioners up the value chain--crucial in an era of outsourcing.

Service with a Smile

Our goal here is to be able to quickly switch on a network service. To do this, we must interact with the network and change its configuration and state in some fashion (e.g., allocate more bandwidth from a service provider). This simple task is often incredibly difficult to achieve in telecom networks! It requires interaction with multiple back-end systems--service portals, databases, and network devices, as illustrated in Figure 1.

Figure 1. Service provider network layers

In spite of this complexity, as we'll see below, there is a growing demand for customer-driven network management. One reason why telecom is especially complex is because of its intrinsically three-tier nature--users, back-end systems (provisioning servers and databases), and network devices (routers and switches), as illustrated in Figure 1. Let's now take a quick look at the typical workflows that accompany the user-driven service change requests.

Sample Workflow

The home office user in Figure 1 places an online order for an increase in the bandwidth of her broadband connection (Link 1 in Figure 1). Likewise, the network manager at the headquarters site also places an order to increase her bandwidth on Link 2. These two orders are typically routed through some type of workflow system (not shown in Figure 1) that verifies the change requests. The change requests are ultimately translated into a series of device-configuration changes that are applied in an orderly fashion to the routers (the hockey puck symbols) in Figure 1.

We'll simulate this workflow with a simple user-driven GUI front end that communicates with the provisioning server in Figure 1. This GUI is typically accessed using a browser. The provisioning server then applies the required changes to the back-end systems (in this case, storing the request in a relational database) and the associated network devices.

In the midst of all of this complexity, we want to provide a way to rapidly implement the required capability. Patterns come to the rescue! Let's briefly review the major requirements:

• The user interface allows limited service display and change requests.
• A single instance of a provisioning server handles all change requests.
• The provisioning server updates the back-end systems (i.e., the database and network devices).

We need a basic GUI for the customers in Figure 1. This GUI facility is often called customer network management and is increasingly a feature of service provider networks. A very popular customer network management feature is called service-level assurance monitoring. This allows a customer to view the parameters of a contractual service level agreement (e.g., 2Mbps guaranteed, a 20ms round-trip delay, etc.). If the customer breaks the agreement by sending too much traffic, then the provider can drop excess traffic. If the service provider fails to meet the agreement (e.g., dropping or delaying traffic during periods of congestion), then the customer gets a financial rebate. Creating the infrastructure to do this is at the leading edge of modern network development.

Our provisioning server handles all service change requests and typically routes them for validation to another back-end system. This offloading helps reduce the load on the provisioning server itself.

The provisioning server focuses its efforts on presenting a single instance, receiving orders, and updating the complex back-end systems. In network management, it's often a key requirement that there is only one provisioning server instance. Orders are routed to this instance using intra-JVM static access (as used in this example), RMI, CORBA, etc. Traditionally, the server software is installed on a single designated machine and clients then access the services it exports. This solves the problem of avoiding multiple instances of the server code--by deploying just one. In other words, the provisioning server is a good candidate for implementation using the Singleton pattern. Let's take a look at it.

The Singleton Pattern

The Singleton pattern is often used where you want just one (and only one) instance of a class in a given JVM. This can be useful for applications that require a single point of entry for a block of functionality (e.g., order fulfillment in our example domain). In the telecom world, it's often highly important to have ordered use of devices, such as routers or legacy network elements. By ordered, I mean configuration commands are sent at a predetermined rate of arrival, so as not to overwhelm the device. In many cases, the devices implement network management facilities in code that has a lower priority than the traffic handling code. Remember, network devices have a lot of work to do besides responding to network management commands--all the more so, as network technology speeds and feeds increase.

In effect, resource consumption can be controlled using the Singleton pattern.

The Service Order GUI

The service order GUI is very simple--it allows a user to see and update the existing configuration of his or her service. For our home office user, this is 56Kbps on Link 1 in Figure 1, and for the corporate user, it's 5Mbps on Link 2 in Figure 1. In passing, please note that the units of kilo- and mega- in the telecom world relate to 1000 and 1,000,000, respectively (not 1024 and 1,048,576, as used in the storage domain). So 56Kbps is actually 56,000bps and 5Mbps is 5,000,000bps.

Let's assume our home office user wins the lottery and decides to upgrade her connection by 1Mbps. She runs the service configuration program and sees the GUI shown in Figure 2. This is the allowed view of the service for our newly rich home office user!

Figure 2. Service configuration view

The current allocated service level is 56Kbps, and three options are available with the portal in Figure 2:

• Update Profile: Allows the configuration to be changed.
• Undo: Reverses the most recent configuration change.
• Exit: Exit the program.

Selecting the update option sends an order to the provisioning server to upgrade the service by 1Mbps, as illustrated in Figure 3. The order is dispatched to the server and the result is seen in Figure 3.

Figure 3. Service upgrade GUI