Using Visual Studio DSL Tools to Simplify Network Activation

Developing applications that are intuitive for the end user

Travis Brown
Qwest Communications

Joseph Hofstader
Microsoft Corporation

Gary Sidhu
Qwest Communications

January 2009

Applies to:
   Microsoft Visual Studio 2008 DSL Toolkit

Summary: This white paper—written to aid in the development of applications that are intuitive for the end user—outlines the architecture of a network-activation system that will reduce the cost to your business of development, maintenance, and training. (12 printed pages)

Contents

Introduction
The IP VPN Network
Network Activation System Architecture
Conclusion

Introduction

The ability to provide new goods or services to customers rapidly is a key success factor for any business. In a competitive subscription-based industry, such as telecommunications network service providers (NSPs), the ability to quickly get customers to use your company’s services can increase profits and prevent customers from selecting your competitors’ offerings. Over the last decade, automating the network-provisioning process—including the activation of the communications network—has been a key focus of NSPs.

Even with the productivity gains and faster time-to-revenue benefits that are realized from the automation of network activation, you can gain further efficiencies by addressing the following issues:

• Unintuitive user interface for system users—The interfaces to provisioning systems often require extensive domain knowledge that can be abstracted into a few key concepts and presented to the system user in an intuitive fashion. By creating an intuitive user experience, you can reduce the amount of time that is spent on training users on the software, and instead let them focus on their strength: provisioning telecommunications networks.
• Disparate network activation systems—Service providers utilize many network-activation systems, which are implemented as disparate applications that are targeted to a specific type of network equipment or communications services, such as SONET gear or Digital subscriber line service. These silos of systems tend not to be based on any industry standards or guidance, which adds the expense of integrating the solution into existing business processes.

This white paper will outline the architecture of a network-activation system that will reduce the cost of development, maintenance, and training. This system contains two major components: (1) an intuitive UI and (2) a framework that is defined by an industry community organization for network activation of an Internet Protocol virtual private network (IP VPN).

The IP VPN Network

Over the course of the past decade, telecommunications NSPs have built IP networks that facilitate the outsourcing of IP-backbone services for enterprise customers. The RFC2547bis standard defines a scalable and flexible approach for NSPs to provide cost-effective IP-backbone services. Implementations of RFC2547bis commonly are referred to as IP VPNs. 
Figure 1 depicts the major components of the RFC2457bis:

Figure 1. Components of the RFC2451bis (Click on the picture for a larger image)

Key elements of this model are the following:

• Virtual Route Forwarding Policy (VRF)—An artifact that details specific attributes that are associated with membership within a VPN. When reified, it contains routing information that is associated with a VPN.
• Virtual Private Network (VPN)—A collection of sites that are connected to a backbone network that shares a common VRF policy.
• Quality of Service (QoS)—Traffic-engineering techniques that provide for differentiated treatment of network traffic on a backbone network.
• Customer Edge (CE)—A router that is responsible for connecting the customer to a VPN. All ingress traffic is marked and classified for QoS before it is forwarded to a VRF.
• Provider Edge (PE)—A router that serves as the ingress/egress point to the backbone network. Additionally, PE devices manage VRF instantiations.

Network Activation System Architecture

Approach

We will define the architecture by examining the following properties of the IP VPN domain: the entities, relationships, and behaviors that make up the domain; and the static and variable attributes of those entities. By understanding the entities, relationships, and behaviors of the domain, you can derive the domain model that implements the domain for the solution; and by differentiating between the static and variable attributes of the domain, you can derive the DSL model and develop the intuitive UI for the end user.

Beyond defining the domain, there are a number of other considerations that must be addressed in order to architect the solution:

• The “workflow” of the solution must be considered, including the steps that are necessary for a successful activation, as well as a strategy for how transactions will be managed in case of failure.
• The solution boundaries, including where different pieces of data originate and where they are persisted.
• The logical architecture, depicting the technologies that make up the solution that maps those technologies to the nodes on which they reside.

Solution Layers

From the solution requirements, you can determine that the system will comprise an extendable and maintainable network-activation framework with an intuitive user experience. The approach that is taken in the solution architecture is to develop the framework by using industry guidance and to create a graphical domain-specific language (DSL) to provide an intuitive user experience, defined in a language that can be used by professionals who might not have a background in software development.

Based on the aforementioned solution requirements, you can derive a few major areas of concern within the solution that can be conceptualized as distinct layers in which you can encapsulate different types of system logic:

• Intuitive UI implemented by using a DSL
• Interface for network-facing framework
• Business-process logic to handle transactional and exception logic
• Domain model
• IP VPN network adapters

You can derive the conceptual architecture for an IP VPN activation solution by separating the areas of concern in the solution into layers.
Figure 2 depicts the layers of the IP VPN activation solution:

Figure 2. Layered architecture for IP VPN activation solution

Architectural Models

The use of modeling to define a software solution is a common way for an architect to communicate a software solution to the different stakeholders of the solution and, in the process, generate an executable code for the solution.
The following models will be used to define the architecture of the solution:

• Domain Model—Consists of the classes that make up the domain, the attributes and operations of the classes, and the relationships between the classes.
• Business Process Model (BPM)—Describes the steps that are required to activate the IP VPN. Included in the BPM is transactional logic that will compensate for errors that occur during the IP VPN activation process.
• Domain Specific Language Classes and Relationships Model—Contains the classes and relationships of the graphical DSL that will act as the presentation layer of the IP VPN network-activation system.
• Conceptual Architecture—Depicts the structuring of the solution by separating it into areas of concern. Different considerations that must be taken when defining areas of concern are:
  • Solution boundaries.
  • Data inputs.
  • Business processes.
  • Data storage.
• Logical Deployment Diagram—Maps the areas of concern into technologies and processes. Definition of the logical architecture accounts for the nonfunctional requirements, such as security and scalability.

The following sections will detail each of the models in the solution.

Domain Model

Definition of a domain model requires an analysis of the entities that make up a software solution and the relationships between those entities. Most often, the domain analysis is done by the organization that is developing the solution. In the case of the IP VPN activation system, we chose to implement a model that is based on one that was created by an industry organization. With network management being such an important function of NSPs, industry organizations have defined models for network activation—foremost being the TMForum. The basis of the model for the network-activation solution is the Resource domain of the TMForum Shared Information and Data (SID) model.
Figure 3 depicts the major abstractions of that model:

Figure 3. Key classes of in the TMForum SID Resource domain model (Click on the picture for a larger image)

• Resource – An entity that is inherently manageable and makes up a product
• Physical Resource – Represents the physical aspects of a product
• Logical Resource – Represents the “brains” and nonphysical aspects of a product
• Compound Resource – Represents a collection of resources whose members can be managed individually as either a PhysicalResource or a LogicalResource
• LogicalResourceRole – The behavior that is associated with a LogicalResource in a given context
• Router –A set of physical and logical resources that collectively fulfill functions that are associated with the network layer of the Open System Interconnection (OSI) network model

Business Process Model

The BPM defines the “workflow” of the solution in how it pertains to the domain model, and it defines the behavior of the domain model as it executes within a specific context. As mentioned previously, the BPM describes the steps that are necessary to complete a business process successfully, including transactional logic for how the system behaves when errors occur.

The process for provisioning network elements requires that disparate pieces of network-equipment nodes be programmed. If the nodes are programmed successfully, the process is completed successfully. If any one of the nodes is not programmed successfully, you will have to return all of the other network elements that have been programmed to their original state.

The following are other aspects of the process that must be taken into consideration:

Is the original design correct?
A common problem among NSPs is having the logical inventory inaccurately reflect the state of the various network elements. It is a best practice to validate the design of a network service prior to programming any of the elements, in order to ensure that the service can be activated. If the design is incorrect, the process should stop, and an error should be returned that states that the process was terminated due to an inaccurate design.

Should the network elements be programmed in parallel or sequentially?
Each option that is presented has advantages: The benefit of having the network devices programmed in parallel are that you can program all of the elements in the amount of time that it takes to program a single network element; this reduces the amount of time that it takes to program the entire system.

The benefit of programming the network elements sequentially is that, when there is an error in the provisioning process, there are fewer programmed network elements that must be returned to their original state. It is important to note that accessing the network elements can be time-consuming. For example, a network element has a limited number of management ports; if another process is accessing that port for a given period of time, restoring the network element to its original state can take an excessive amount of time and make the entire process longer.

For the sake of the IP VPN solution, an optimistic approach is taken, and the network elements are programmed in parallel. The business process for activating an IP VPN contains two discrete workflows: The first is the transactional process of ensuring the accuracy of the design; the second goes out to the network elements and “programs” them for a specific IP VPN. In this context, the process that activates the IP VPN is nested within the transactional process in an activity that is called “activateElements”.
Figure 4 depicts the business process for the IP VPN provisioning system:

Figure 4. IP VPN activation BPM (Click on the picture for a larger image)

Figure 5. activateElements BPM (Click on the picture for a larger image)

DSL Classes and Relationships Model

The goal of defining a graphical DSL is to create an intuitive experience for the end user of the solution. The Microsoft Visual Studio 2008 DSL Toolkit provides an intuitive environment for defining the different parts of the DSL: the classes to display to the end user, the attributes that are required for entry by the end user (variable attributes), and the tools for designing the user experience of the DSL.

Static Attributes

The process of defining a DSL requires an understanding of the static and variable attributes within a business domain. The static attributes then can be persisted in a database or a resource file, and the variable attributes can be input by the individual who is responsible for activating the network elements.

Variable Attributes

For the purpose of this document, the variable components for network activation are the type of device to which the service is connecting, the IP address of the device, the QoS that is required for the service, and the relationships of the CE and PE equipment.

DSL Designer

The DSL Designer in Visual Studio 2008 contains a designer for classes, relationships, and properties. The classes can be abstract or concrete, and the relationships can be containment or reference. The properties of the classes are the variable attributes for which the user will provide values. The DSL Designer also provides drag-and-drop capabilities for associating graphical elements that will be used within the DSL with the classes and relationships that will be displayed to users and added to their toolbox.
Figure 6 shows the classes and relationships in the DSL Designer:

Figure 6. Classes and Relationships for the IP VPN Activation DSL (Click on the picture for a larger image)

The DSL User Experience

Figure 7 depicts the DSL running in Visual Studio. This layout contains the following components:

• The toolbox is in the upper-left corner and contains the classes that are in the DSL. Each class is given an intuitive name and assigned an icon that can represent its image on the screen.
• The model explorer is in the upper-right corner and contains a hierarchical view of the classes that are contained in the instance of the IP VPN.
• The properties window is in the lower-right corner and allows the user to provide the values to the variable attributes for the classes in the model.
• The design surface is in the center of the window and contains the instance of the IP VPN that will be developed within this context. It has the same look and feel of all Visual Studio applications, so that the user need only drag components from the toolbox to the design surface in order to define the layout of the IP VPN, with all constraints enforced by the model that is defined in the DSL Designer.

Figure 7 is a representation of the IP VPN that is being designed in this DSL, while Figure 1 is based on the TMF 2547 model. This, therefore, is the most intuitive model for the purpose of this solution:

Figure 7. IP VPN DSL running in Visual Studio (Click on the picture for a larger image)

Logical Deployment Model

Now that the application has been designed, consideration must be given to how the different parts of the solution will be deployed as a cohesive system. As with any solution that is part of the operation support system (OSS) of an NSP, the system must be highly scalable, reliable, and secure. That being said, it is critical to design the system so that it can be scaled to meet test and production transactional loads.

The architecture for the provisioning system contains three main processes: a Windows Vista desktop that is running Visual Studio 2008, to host the DSL; a Windows Communication Foundation (WCF) service that is hosted in Microsoft Internet Information Services (IIS) 7.0, to host a workflow that will provide a transactional context for the provisioning of each network element; and a Microsoft SQL Server 2008 server that contains the metadata to drive the framework. The WCF service, named the Network Activation Service, also will host the Network Activation Framework that is based on the TMF 2547 specification.
Figure 8 depicts the deployment of the IP VPN activation system:

Figure 8. Architecture for IP VPN provisioning solution

Conclusion

The DSL Designer in Visual Studio 2008 provides an excellent environment to design and develop intuitive user experiences for complex domains. That being said, no tool can compensate for a poor methodology in the architecture and design of a solution. It also is important to note that a poor implementation of a technology, including any of the technologies that are mentioned in this white paper, can be a serious hindrance to the success of a software system.

Although the focus of this document is on the Visual Studio 2008 DSL Toolkit, the domain-driven methodology—and the separation of static and variable class attributes to derive the minimal amount of system input—is an excellent way to design intuitive software. When you assess the quality of a software system, usability should be at the top of your list. A key usability factor for software is to require the user to enter the least amount of data that is required to perform a task in a software system. The Visual Studio DSL Toolkit is a technology that provides that capability.

About the Authors

Travis Brown is a Staff Software Development Engineer at Qwest Communications. He has architected and developed network-management solutions for many network service providers. Travis holds an MBA from the Daniels College of Business, University of Denver, and a BS in Computer Science from Colorado State University.

Joseph Hofstader is an Architect in the Microsoft Development and Platform Evangelism Division. He has spent his career architecting, designing, and developing software in the telecommunications industry, including cloud-based solutions. Joseph is also a professor in the School of Information Technology and Electronic Commerce at the University of Denver.

Gary Sidhu is a Staff Software Development Engineer at Qwest Communications.  Gary has spent his career architecting and developing communications network management solutions.  Gary also has an expertise in business process automation software.