Figure PR.09 -The Concept of a DeviceRole

Before we dive deeper, let’s clear up one thing that we previously hinted at. We have defined previously a Switch and a Router as types of Devices. We all know the basic difference between a Switch and a Router – the former forwards traffic, while the latter routes and forwards traffic. But what about the so-called “Layer 3” switches, which are Switches that have Routing capability?<br/>Assume that our model actually did implement a router and a switch subclass of PhysicalDevice. One would then be tempted to invent a new subclass, called Layer3Switch, which subclasses a Switch and adds routing capabilities, to handle this new type of device. However, this is a poor solution, because now every time routing changes, we have to update the Router and the Layer3Switch class. Besides, this implies that a Layer3Switch can do everything that a full-blown Router can do, which is almost never the case. There are other problems too, but this is enough for now.<br/>One may then be tempted to use multiple inheritance to solve this problem. However, this creates a new problem – one of extensibility. What if there is a “Layer4Switch” (unfortunately, some vendors do define such an animal!)? What if we want to differentiate between the type of routing done in a Router vs. those done in the Layer3Switch vs. those done in the Layer4Switch? What if there is a Router that has firewalling capabilities? The list is endless. Multiple inheritance cannot be used to solve all of these problems, and besides, many implementations don’t support multiple inheritance. We don’t want to compromise our ability to build a system view out of this business view!<br/>Instead, a much more elegant and extensible solution is available – we can use the notion of roles. In fact, one of the strengths of a good model is to be able to reuse the same set of patterns over and over. Roles form a core part of the Party model, which (among other things) describes People, Organizations, and the functions (i.e., roles) that they play. This is documented in GB922 Common guide book (the Common Business Entity Addendum that defines Party and PartyRole).<br/>Our approach is now simplified. Instead of trying to either define many subclasses or introduce multiple inheritance, we can instead define a set of roles that the device is meant to play. (It should be noted that this is another reason why the concept of a managed device is a good one – now, we can define a base concept of a managed device, and model its functionality by associating one or more roles to it as appropriate). This solves the mess of having the same generic function (such as routing) assigned to two different types of devices that implement that same generic function in different ways, producing different subsets of functionality.<br/>Since the networking industry has shown to be ever-evolving, inheritance is not appropriate for capturing this behavior, as the behavior itself changes over time. In addition, by capturing the key functional concepts as roles, we can model present and future Devices as entities that can play many roles at one time.<br/>Thus, by modelling DeviceRole as a separate concept from Device, we can represent these complex behaviors in an extensible manner.<br/>The following Figure shows a simple model introducing the concept of a DeviceRole.<br/>It should be noted that the Figure does not define all of the different types of roles that a Device can take on. This concept is clearly not a physical one, but rather a logical one, and will show up in other Addenda. It is brought up in this Addendum because this is a critical concept for modelling different types of devices, and the Physical Resource model must be able to interface with this concept. It also inspires us to see if there isn’t a similar concept that can be used to abstract similar differences in the physical world. In fact, there is a similarity, and is defined in the following section.<br/>