Traditionally, management software technology has used a simple mechanism that supports get, set, and notify capabilities:
- When you want to retrieve the value of something, you use the get facility.
- When you want to modify the value of something, you use the set facility.
- When you want to be informed about a change in the value of something, you use the notification mechanism.
The "something" in each case could be some state variable that represents an underlying entity (more on this topic later).
Sounds simple, doesn’t it? This get/set/notify model is supported by many technologies, such as SNMP , JMX, WSDM, etc. The JavaBeans standard also provides partial support in the way it requires explicit getter and setter pattern methods. The authors of C# are continuing this tradition, and that’s the subject of this article.
To describe the C# mechanisms, we need a managed entity. If you’ve read my earlier articles without being lulled into a peaceful slumber, you might recall some discussion of label-switched paths (LSPs). LSPs are basically predefined paths through a network that implement a technology called multiprotocol label switching (MPLS). In spite of the huge amounts written about MPLS, it operates in a fairly simple way: You create your LSP, enable it, and then data passes across it. I’ll illustrate the C# management model with reference to LSPs.
Getting the Picture
I continue to use the amazing open source SharpDevelop integrated development environment (IDE) product. The code for this article is available as a complete SharpDevelop project. But, as before, you can use any toolkit you like—Visual Studio, for example, or even the command line. What I really like about SharpDevelop is the speed with which you can get up and running. It can even load Microsoft Visual C# solutions. This capability reflects the fact that software has entered a commodity age. My thinking is that if a software tool requires a lot of configuration and upfront effort to learn, that tool might not have a great future. Of course, this depends on your idea of what constitutes a lot of configuration! For myself, if a tool takes in excess of half a day to get up and running, I usually start to wonder if an alternative exists. SharpDevelop really does work out of the box.
As usual, Listing 1 shows a sneak preview of the finished C# code, where I do the following:
- Create an LSP.
- Register some event handlers to track the state of the LSP.
- Forward some data across the LSP to cause state changes.
Listing 1 The finished C# code.
Lsp lsp = new Lsp("LSP1", 1, 5, "R1R2R3R4R5", 100, 150); // Register event handlers. lsp.FullyCongested += new Lsp.LspEventHandler(FullyCongested); lsp.GettingCongested += new Lsp.LspEventHandler(GettingCongested); lsp.CannotForwardData += new Lsp.LspEventHandler(CannotForwardData); // Forward some blocks of data (to generate some events) Console.WriteLine("\n***** Forwarding data *****"); for (int i = 0; i < 3; i++) lsp.ForwardSomeData(20);
One other thing I’ll describe is the clever way in which C# allows you to use properties in order to allow access to and modification of class data.
Just so you have a picture of what’s happening, Figure 1 illustrates my example network. Don’t worry about the details of Figure 1. The important thing for this discussion is the entity LSP123 in the middle of the network.
Figure 1 The example network.
LSP123 in Figure 1 traverses the nodes R2, R3, R4, and R5. Incoming IP packets that land at R2 are pushed into the path supported by LSP123. Note in passing that this path is longer than the alternative path R2, R6, R5. If you relied upon default IP forwarding (as used on the Internet), the latter path generally would be used. So using LSPs gives the network manager choice in how to carve up the network resources.