Java Patterns for MPLS Network Management, Part 2
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Service-driven networking requires rapid automated provisioning in response to user demand. Suppose you want to increase your allocated bandwidth or you want to access the latest broadband game from your service provider. Typically, you must complete an online form and a provisioning server updates your profile. Then you need access to the required resources. Service providers are falling over themselves to achieve this type of rapid 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 the requested service. In this article, I'll look at how to use the Singleton design 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.
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 pattern example helps reduce 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—increasingly crucial in an era of outsourcing and a weak economy.
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., allocating 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 the complexity, as we'll see next, there is a growing demand for customer—driven network management (or customer self-service). Many customers enjoy playing around with self-service options. This also helps to reduce the cost of running the network. However, in technology nothing is ever free, and self-service infrastructure is itself complex and costly to create.
One reason why telecoms are especially complex is because of their intrinsically multi—tiered nature, consisting as it does of users, back-end systems (Provisioning Server and database), 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.