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 authenticates and 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 database) and the associated network devices.
In the midst of all 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.
So, 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, round-trip delay 20ms, 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.
So, our provisioning server handles all service change requests and typically routes them for validation to another system. This offloading helps reduce the load on the provisioning server.
The provisioning server focuses its efforts on presenting a single instance, receiving orders, and updating the complex back-end systems. It's a good candidate for implementation using the Singleton pattern. So let's take a look at this.