6.1 The .NET Framework and scripting

Although the .NET Framework is a well-determined Microsoft strategy today and represents a step forward in simplification, you still need to understand some of the underlying mechanisms that WMI takes advantage of, such as the CIM repository and the nature of the classes (i.e., instance class, event class). The .NET Framework System. Management and System.Management.Instrumentation namespaces deliver a new management programming object model, which is more consistent than the isolated islands of interfaces implemented by COM technologies, such as is the case when WMI is combined with ADSI or CDOEXM to do some Exchange management. Unfortunately, we already know that the current .NET Framework classes do not represent all the manageable elements of a Windows platform, since most features rely on the existing COM plumbing. As such, there are still many interfaces that need to be provided before we will be able to write code to manage every facet of the Windows operating system. Keep in mind that "managing" implies the concepts of "configuration," "monitoring," and "alerting." In this sense, the current .NET Framework classes still have their limitations, since most information exposed by the .NET classes relies on WMI.

To improve matters, Microsoft is considering the development of a new Windows management layer, which will include the current WMI implementation, as well as some new implementations to cover areas not yet contained in WMI. Since the access method to the management data will be .NET based, the transparency of the access method will be handled behind the scenes by the .NET Framework abstraction layer. Regardless of how the management data is retrieved (via the existing WMI implementation or some new technologies still not fully defined), the Windows management layer will provide the information in an abstracted way. The goal of such an implementation is to hide the complexity that you cannot skip today if you are willing to use WMI. The new abstraction layer, acting as a management infrastructure service, will ideally be more object oriented when compared with the current implementation, which requires too much effort to work with. Of course, one can say that the current implementation is already object oriented, since we deal with COM objects all the time! So, where is the difference? In an ideal object-oriented world, a developer doesn't normally deal with the infrastructure implementation as we do with WMI. The essence of objects available through the model should provide the necessary information without having to deal with its core implementation. From that perspective, WMI is far from an ideal object-oriented programming environment. This is a major focus for Microsoft as it drives for future simplification. Bear in mind that this vision is a generic representation of how things could be. There is no implementation available in any form at the time of this writing. In fact, these statements are purely the vision of things that may be realized over a two- to three-year time frame.

Another aspect is the scripting environment itself. Today, we have two directions clearly defined in Microsoft technologies: the programming model, based on the .NET Framework class model and the new line of .NET Server products such as Windows Server 2003, and a set of next-generation servers to replace current versions of products such as Exchange and SQL that will be built on the .NET framework. The question we must ask is: Where do scripting technologies fit?

The aim of scripting technologies is to fill a gap between the pure programming world only used by "real programmers" and the user interface mostly used by support teams, help desks, and administrators. However, most enterprise administrators need to automate tasks in their day-to-day work, but they are not programmers and don't want to be one. Even if the .NET Framework class model offers most of the features to create managed code and manage the Windows environment, it does not necessarily represent a viable solution for enterprise administrators. In fact, you very rarely find administrators who install Visual Studio.NET and start learning languages such as C# or VB.NET just to write a few lines of code to automate simple or repetitive management tasks. In addition, any good operating system always provides a shell with a scripting language to develop coded logic (i.e., the Korn and C shells for the UNIX platform or REXX for IBM systems). Therefore, Microsoft needs to fill a space in its operating system that offers the advantages of the scripting environments, as we know them today, and exploits the power of the .NET environment at the same time.