Figure SO.24 - Multiple Command Syntaxes and Programming Models

<font color="#e0121d"><b>Linking to QoS – ServicePackage and ServiceBundle</b></font><br/><font color="#29313b">The Service QoS guide book defines of the QoS model. The purpose of this model is to satisfy one of the use cases of the Service Domain in general, by describing how QoS mechanisms on a device are configured. Here, “mechanisms” refers to modeling the end-user features of the device.</font><br/><font color="#29313b">Conceptually, what makes this a daunting task is that Services involve multiple devices which can have heterogeneous commands and programming models, as is shown in Figure SO.24 below.</font><br/><font color="#29313b">Current network devices have different programming models using different commands. This makes it very difficult for common tasks to be performed, because in effect the network operator must know different languages. If we also take into account the fact that commands change per OS version, the analogy grows to a single person having to know multiple dialects of multiple languages. This cannot scale.</font><br/><font color="#29313b">The Figure above illustrates the use of different commands and programming models to perform the same high level task. The device on the left has configuration modes, each mode defining a set of appropriate commands. The device on the right has no such modes. Furthermore, the syntax used to perform the same task is drastically different.</font><br/><font color="#29313b">Note that each network device supports a Service through configuring a DeviceInterface and/or its LogicalDevice. This is worse for two reasons. First, the thought of doing this manually, for thousands of networks, is no longer viable, due to both the complexity of networks, the complexity of services that networks support, and the interaction between services supported on a network. Second, since each Device in general has a different programming model, there is no way to tell in advance which way (or ways) a Device can be programmed. </font><br/><font color="#29313b">Clearly, manually configuring each Service that can run on a given device is not a viable process. This Addendum introduces two innovative classes – ServicePackageSpec and ServiceBundleSpec – that serve to link the business requirements of QoS to its implementation. Note that this is done at the specification level, to enable this to be templatized. Of course, this is yet another instance of the Entity-EntitySpecification pattern, which is used throughout the SID. (This in and of itself is important, because it shows how the existing Service model can be easily extended to bridge new concepts using the same set of standardized mechanisms. This is an indicator of the robustness and inherent extensibility of the SID.)</font><br/><br/>