The Monad Manifesto - Annotated

by Jeffrey Snover as annotated by the PowerShell Community

---

Este proyecto está destinado a preservar The Monad Manifesto, un documento escrito por el inventor de Microsoft Windows PowerShell Jeffrey Snover en Microsoft en 2002. La idea de este proyecto fue del autor de Pluralsight Tim Warner, con las anotaciones iniciales que hicieroen Tim y el Microsoft MVP Don Jones.

El Manifiesto original era un documento prospectivo, anterior a la publicación pública de PowerShell por alrededor de 4 años. En los años transcurridos desde el lanzamiento de PowerShell 2006, el producto ha evolucionado sustancialmente, pero siempre alrededor de los conceptos descritos en el Manifiesto.

Consideramos que no sólo es importante conservar el documento con fines históricos, sino también anotar y ampliar los diversos conceptos que introduce. Intentaremos vincular las referencias de las tecnologías reales que el Manifiesto predijo y proporcionar explicaciones contextuales en torno a algunas de las directivas del Manifiesto.

Encontrará [^1] notas de pie de página en el texto. Éstas son una característica de MultiMarkdown que no son compatibles con nuestra plataforma de publicación, pero están destinadas a vincular a las notas de pie de página correspondientes en la parte inferior de la página. En algunos casos, estas son las notas originales de Jeffrey marcadas como “ORIGINAL” para separarlas de las notas a pie de página que nosotros hemos añadido.

---

Esta guía se publica bajo la licencia Creative Commons Attribution-NoDerivs 3.0 Unported. Los autores le animan a redistribuir este archivo lo más ampliamente posible, pero le solicitan que no modifique el documento original.

¿Ha sido útil este libro? El (los) autor (es) le pide (n) que haga una donación deducible de impuestos (en los EE.UU., consulte sus leyes si vive en otro lugar) de cualquier cantidad a The DevOps Collective para apoyar su trabajo.

** Revise las actualizaciones! ** Nuestros ebooks se actualizan a menudo con contenido nuevo y corregido. Los hacemos disponibles de tres maneras:

• Nuestra rama principal GitHub organization, con un repositorio para cada libro. Visite https://github.com/devops-collective-inc/
• Nuestra GitBook page, donde puede navegar por los libros en línea, o descargarlos en formato PDF, EPUB o MOBI. Utilizando el lector en línea, puede saltar a capítulos específicos. Visite https://www.gitbook.com/@devopscollective
• En LeanPub, donde se pueden descargar como PDF, EPUB, o MOBI (login requerido), y “comprar” los libros haciendo una donación a DevOps. También puede elegir recibir notificaciones de actualizaciones. Visite https://leanpub.com/u/devopscollective

GitBook y LeanPub generan la salida del formato PDF ligeramente diferente, por lo que puede elegir el que prefiera. LeanPub también le puede notificar cada vez que liberamos alguna actualización. Nuestro repositorio de GitHub es el principal; los repositorios en otros sitios suelen ser sólo espejos utilizados para el proceso de publicación. GitBook normalmente contendrá nuestra última versión, incluyendo algunos bits no terminados; LeanPub siempre contiene la más reciente “publicación liberada” de cualquier libro.

Capítulo 1 - ¿Qué es Monad?

---

Monad ^{1 2} es la próxima generación de plataformas para la automatización administrativa. Monad resuelve los problemas de gestión tradicionales aprovechando la Plataforma .NET. Desde el primer prototipo (limitado), se pueden resaltar beneficios significativos para desarrolladores, testers, usuarios avanzados y administradores. Monad aprovecha [^ 1-6] el .NET Common Runtime Runtime para proporcionar un potente, consistente, intuitivo, extensible y útil conjunto de herramientas que reducen los costos de administración y hacen que la vida de los no programadores sea mucho más sencilla.

Monad consta de:

1. Monad Automation Model (MAM): Un modelo de automatización basado en clases .NET, métodos y atributos para producir Cmdlets.³
2. Monad Shell (MSH): Un entorno de ejecución de scripts basado en .NET para exponer los Cmdlets como herramientas de línea de comandos de API y un shell de línea de comandos programable e interactivo.
3. Monad Management Models (MMM): El conjunto con las clases de base de código administrado (o interfaces) para implementar escenarios de administración específicos y herramientas administrativas in-the-box para ejecutar esos escenarios.
4. Monad Remote Scripting (MRS): Conjunto de componentes basados en Web Services que permiten ejecutar secuencias de comandos remotamente en muchas máquinas ⁴.
5. Monad Management Console (MMC): Un modelo basado en .NET y un conjunto de servicios para la creación de GUIs de administración sobre MSH exponiendo todas las interacciones de GUI como secuencias de comandos visibles por el usuario ⁵.

Este white paper presenta el enfoque tradicional de la automatización administrativa, sus fortalezas y deficiencias. A continuación, se presenta una visión general de los principales componentes de Monad. Un conjunto de propuestas de valor se articula entonces para las audiencias objetivo de Monad.

---

Notas:

Capítulo 2 – El Problema

Windows tiene herramientas administrativas GUI simples para usuarios básicos (Panel de control, MMC, etc.). Windows también tiene un rico conjunto de lenguajes, APIs ⁶ y modelos de objetos para programadores de sistemas avanzados (C, C++, C#, WMI, Win32, .NET, etc.). Lo que falta, son herramientas “compuestas” vitales orientadas al administrador para escribir comandos y automatizar la gestión. El centro de todo esta normalmente regido por lenguajes de scripting.

Nuestras soluciones de secuencias de comandos actuales (WSH, VB) se centran en el extremo superior del mundo de secuencias de comandos que gestionan la plataforma utilizando abstracciones de muy bajo nivel, como modelos de objetos complejos, esquemas y API ⁷. Esto puede resultar algo extraño para gran parte de la comunidad de administradores. El scripting de administración debería fluir desde línea de comandos ⁸, debería ser pequeño, simple, incremental y tratar con niveles de abstracción muy altos.

John Ousterhout describió la distinción entre scripting y programación de sistemas en su artículo Scripting: Higher Level Programming for the 21st Century.

Ousterhout postula que las secuencias de comandos deben permitir “juntar” aplicaciones, una abstracción de nivel superior a la programación de sistemas, lo que permitía un desarrollo de aplicaciones aún más rápido que con los actuales lenguajes de programación. El argumento fundamental es que debemos continuar por el camino de la Ley de Moore para llevar el desarrollo a niveles más altos de abstracción a través del scripting. Para habilitar la automatización de la administración en el mainstream, los administradores necesitan un shell completo, con scripts y utilitarios, y las GUIs administrativas necesitan estar superpuestas a esta infraestructura [^2-4]. Esto permitiría una formación eficiente de los administradores en la automatización desde la línea de comandos y garantizaría capacidades administrativas completas así como economías de escala en un modelo de automatización al que llama admin-composable. ___

Notas

[^2-4] Se tenía entonces una fuerte dependencia de las capas de GUIs. Eso explica un poco la ausencia de algunas GUIs administrativas en Linux/UNIX para algunas tareas. Su ausencia obliga a asegurarse que todo se puede hacer desde la línea de comandos. La GUI no se convierte en una clase especial de ciudadano que posee poderes especiales y únicos. Sólo es otro consumidor de la línea de comandos. La línea de comandos, a su vez, puede ser consumida más fácilmente por otros públicos diferentes a una GUI.

Capítulo 3 - El enfoque tradicional de la automatización administrativa

El modelo tradicional ⁹ para la automatización administrativa es potente y exitoso. Consiste en:

1. Un shell de programación (por ejemplo, sh, csh, ksh, bash) ¹⁰
2. Un conjunto de comandos administrativos (por ejemplo, ifconfig, ps, chmod, kill)
3. Un conjunto de utilitarios para manipulación de texto (por ejemplo, awk, grep, sed).
4. GUIs administrativas superpuestas a los comandos y los utilitarios

La filosofía de este modelo es que cada ejecutable debe hacer un pequeño conjunto de funciones, para que las funciones más complejas sean compuestas a través del uso de pipelining o una secuencia de ejecutables que se llaman unos a otros. Este modelo ha sido muy exitoso a pesar de tener algunos inconvenientes. Tras la inspección, lo que es ampliamente considerado como un bastión UNIX es de hecho una implementación defectuosa de este modelo ¹¹.

Cuando retrocede y examina lo que realmente sucede cuando alguien usa un comando pipelinado (si se me permite inventar esta palabra) como en “$ a | b | c”, se concluye que el primer comando, es decir, “a” no logró lo que el administrador quería hacer. Si lo hubiera hecho, el administrador sólo tendría que haber escrito “a” y listo. Entonces, la pregunta es ¿por qué “a” no hizo lo que el administrador quería? La respuesta es que en este modelo tradicional, los ejecutables autónomos unen firmemente tres operaciones: 1) obtener objetos; 2) procesamiento de objetos; 3) salida de resultados como texto ¹². Una de esas operaciones no hace lo que el administrador necesita, así que el resto de la tubería es un intento de corregir eso.

Debido a que el ejecutable genera texto, los elementos descendentes deben utilizar utilidades de manipulación de texto para intentar volver a los objetos originales y realizar trabajo faltante. Si bien el modelo básico es extremadamente poderoso, su defecto intrínseco es la estrecha vinculación de estas operaciones y el uso de texto no estructurado para la integración ¹³. Esto requiere utilitarios para la manipulación de texto torpes, con pérdidas e imprecisiones.

El modelo tradicional refleja el estado de la tecnología que estaba disponible en el momento en que surgió. .NET proporciona ¹⁴ un nuevo conjunto de capacidades y abre la posibilidad de nuevos enfoques. Estos nuevos enfoques nos permiten sustituir el modelo tradicional por uno decisivamente superior. Ese modelo es lo que llamamos Monad

---

Notas

Capítulo 4 - Nuevos enfoques

---

Monad adopta nuevos enfoques a los problemas de 1) construcción de comandos, 2) composición de soluciones 3) modelos de gestión y 4) GUI de gestión. La arquitectura de Monad proviene de las siguientes observaciones:

1. La mayoría de las soluciones son desarrolladas “in house” y compuestas por comandos existentes por los administradores.
2. La mayoría de las soluciones se centran en la automatización de la gestión o la provisión de correcciones ad hoc.
3. La mayoría de los administradores no son programadores “natos”. O bien no tienen el deseo, la habilidad o (más a menudo), el tiempo para hacer una programación sofisticada.
4. La mayoría de los desarrolladores de aplicaciones no harán que su código sea manejable a menos que haya un beneficio inmediato y sustancial para el usuario ¹⁵

4.1 - Un nuevo enfoque para construir comandos

El enfoque tradicional de la construcción de comandos es ineficiente. Gran parte del esfuerzo se dedica a reescribir las mismas funciones una y otra vez por diferentes personas de diferentes maneras. Todos para:

• Analizar, validar y codificar la entrada de usuario.
• Documentar su uso.
• Dejar registro de actividades.
• Formatear datos, resultados de salida e informes de errores.
• Operar en nodos remotos o conjuntos de nodos remotos.

Sin embargo, a pesar de toda esta coincidencia, la mayoría de las plataformas [^4-1] ¹⁶ proporcionan poco o ningún apoyo para hacer estas actividades de manera coherente. El resultado es que los comandos de hoy en día son ineficientes para desarrollar e inconsistentes en su forma de usar ¹⁷.

Monad adopta un enfoque diferente que proporciona a los desarrolladores el máximo aprovechamiento y la máxima consistencia para los usuarios finales, mediante la definición de un modelo de automatización para aplicaciones que afecta a las funciones comunes para que puedan implementarse una vez en un entorno de ejecución común ¹⁸. Los desarrolladores ya no producen ejecutables autónomos. En su lugar, escriben piezas de código muy enfocadas como clases .NET (Cmdlets) que luego se exponen como API, comandos e interfaces gráficas. Las funciones comunes se implementan y prueban una vez y proporcionan un conjunto único de semántica, así como un conjunto coherente y uniforme de mensajes de error. ¹⁹

4.2 - Un nuevo enfoque para componer soluciones

El enfoque tradicional para componer soluciones es difícil y frágil. Utiliza “pipelines” para realizar análisis basado en oraciones de flujos de texto ²⁰. Estos mecanismos son incómodos, inconsistentes e imprecisos. Los administradores pasan la mayor parte de su tiempo buscando mecanismos para resolver problemas, en lugar de resolver dichos problemas. Monad tiene un enfoque diferente que proporciona un motor de ejecución de secuencias de comandos preciso y potente para crear tuberías (pipelines) de objetos .NET. En lugar de canalizar texto no estructurado, canalizamos objetos .NET ²¹. Esto permite que los componentes de la canalización (pipelines) operen a bajo nivel directamente sobre los objetos y sus propiedades utilizando las API .NET Reflection. (Las API de Reflection permiten encontrar el tipo de un objeto, las propiedades y métodos que tiene, obtener los valores de propiedades e invocar sus métodos).

El entorno de tiempo de ejecución de Monad proporciona un medio para acceder a los cmdlets y ejecutar secuencias de comandos en máquinas remotas a través de Web Services. ²²

4.3 - Un nuevo enfoque de los modelos de gestión

El enfoque tradicional de los modelos de gestión produce una experiencia de administración inconsistente. Hoy en día hay miles de comandos optimizados localmente. Cada desarrollador de comandos define su propio modelo de gestión con un conjunto de nombres y conceptos. Mientras se produce la copia de comandos populares, no hay incentivo sistémico para hacerlo. Se han hecho esfuerzos para proporcionar directrices que impulsen la optimización global, pero el peso del legado ha dificultado que tales esfuerzos ganen mucha fuerza.

Una situación similar existe con las tecnologías de instrumentación actuales que languidecen debido a la falta de soporte de herramientas. Los esfuerzos de evangelización por instrumentación son difíciles a medida que los grupos [de productos] rechazan la estrategia “construye y vendrá”. Los desarrolladores de herramientas se resisten a la vasta superficie de los objetos y responden proporcionando una funcionalidad genérica (como supervisión o navegación) a través de una amplia gama de objetos o proporcionando funciones complejas para un pequeño conjunto de problemas.

Monad adopta un enfoque diferente: minimiza el coste de la automatización y proporciona un beneficio inmediato para el usuario final proporcionando clases de extensión de automatización basadas en escenarios y herramientas in-the-box que explotan esas clases. Monad puede soportar casi cualquier esquema de automatización, pero alienta firmemente el uso de esquemas estándar proporcionando un conjunto de clases base para escenarios administrativos específicos. Estas clases base incluyen: Navegación, Diagnóstico, Configuración, Ciclo de Vida y Operaciones ²³. Dichas clases proporcionan una sintaxis común, conmutadores, mensajes de error internacionalizados y soluciones a problemas de escenarios comunes (por ejemplo, una implementación común de una pila de directorios para todos los comandos de navegación). Monad también proporciona un conjunto de controles de interfaz de usuario y herramientas que se suministran con el sistema operativo que controla dichas extensiones para realizar una tarea de gestión específica

4.4 - Un Nuevo Enfoque a las Herramientas GUI de Gestión

El enfoque tradicional de las GUI de administración proporciona un mínimo de apalancamiento para desarrolladores. Las herramientas de GUI de administración de Windows de hoy en día se desarrollan de la misma manera que una aplicación completa. Tienen código de interfaz gráfica de usuario, aplicación de lógica de dominio/restricción y acceso de API a objetos administrados locales y remotos. Los servicios de GUI de gestión se limitan en gran medida a un contenedor de interfaz de usuario que facilita la multiplexación de varias herramientas y un cierto nivel de integración. Este enfoque requiere un esfuerzo significativo y un conjunto de pruebas exhaustivo. Dado que gran parte de la lógica del dominio y la imposición de restricciones está incrustada en la GUI, es común que las líneas de comandos expongan un subconjunto de las funciones de una GUI. El enfoque tradicional funciona en contra de la automatización.

Monad adopta un enfoque diferente que proporciona un rico conjunto de servicios orientados a la gestión para desarrollar herramientas de GUI de gestión. Estos servicios permiten que las GUI de administración se superpongan al motor de secuencias de comandos y Cmdlets. Esto proporciona auditoría, grabación/reproducción de macros y herramientas integradas de GUI/línea de comandos. Esto disminuye el nivel de habilidad requerido para desarrollar una GUI de administración, al simplificar el acceso y el control de los objetos de administración transparentes de manera remota. También permite a los usuarios ver los scripts ejecutados por las interacciones GUI que les ayuda a aprender la capa de automatización y crear sus propios scripts automatizados. La estratificación reduce la matriz de pruebas aprovechando las pruebas realizadas en la línea de comandos y las secuencias de comandos y solo es necesario probar las rutas GUI para invocar esas funciones. La GUI de administración también puede exponer su funcionamiento interno a través de Cmdlets que proporciona a los desarrolladores, probadores y soporte un fácil acceso al estado interno y el control de la GUI para la depuración/diagnóstico/prueba automatizada.

---

Notas: [^4-1]: ORIGINAL: UNIX tiene getopt () para el análisis simple de opciones de comandos.

Capítulo 5 - El modelo de automatización de Monad (MAM)

---

Monad define un modelo de automatización altamente apalancado para aplicaciones. El modelo extrae funciones comunes para que puedan implementarse una vez en el entorno de ejecución. Esto proporciona tanto apalancamiento para el desarrollador como coherencia para los administradores. El costo incremental para desarrollar y probar funciones específicas de la aplicación es bastante bajo en comparación con los métodos tradicionales.

Los desarrolladores exponen un modelo de automatización a los administradores como un conjunto de nombres y verbos fáciles de utilizar. El desarrollador las implementa subclasificando un conjunto de clases de automatización base de .NET, marcándolas con atributos de automatización para producir un conjunto de Cmdlets. El motor MSH expone estos cmdlets como un API y un conjunto de comandos. Los administradores y los desarrolladores de herramientas ahora obtienen una forma general de acceder uniformemente a la automatización de todos los aspectos del sistema operativo.

5.1 - Un ejemplo

Imagine al desarrollador que necesita exponer el registro de sucesos de Windows para la automatización de informes. El desarrollador decide cómo estructurar la automatización en términos de sustantivos y verbos (“Get-EventLog”). Monad proporciona una sólida orientación sobre este tema. El desarrollador escribe un CmdLet (en C #, VB.NET, COBOL, etc) para exponer esta función.

Un CmdLet podría verse así ²⁴:

A primera vista puede parecer que el Admininistrador no va a obtener mucho uso de este código, pero nada podría estar más lejos de la realidad. El uso de los atributos CmdNoun y CmdVerb registra automáticamente este CmdLet como el comando “Get-EventLog” con un solo parámetro “LogName”. El Admininistrador entonces usa este comando junto con un conjunto de comandos de utilidad base para componer escenarios mucho más complejos

¿Qué está llenado el log de aplicación? ²⁵

¿Por qué MSI Installer está llenando el log?

¿El uso de mi registro de eventos es regular a lo largo de la semana?

El administrador puede agregar Cmdlets adicionales a la canalización (pipeline) para filtrar sólo aquellos eventos que se generaron el martes y luego averiguar qué eventos ocurren más allá de ese día ($ Get-EventLog application |Where {$\_.TimeWritten.DayofWeek -eq "Tuesday"} |Group EventID). Después de haber encontrado el evento más frecuente de los martes, pueden filtrar fácilmente el registro para ese evento y determinar la distribución de dicho evento a través de los días de la semana. ($ Get-EventLog application |Where {$\_.EventID -eq 131080} |Group {$\_.TimeWritten.DayofWeek})

Monad requiere una pequeña cantidad de código CmdLet ²⁶ para integrarse en el entorno de ejecución y aprovechar su rico conjunto de funciones y utilidades para proporcionar un potente y distinguido conjunto de funciones administrativas. Si bien este ejemplo se centró en una investigación ad hoc, es obvio cómo esta investigación podría conducir a un conjunto de informes nocturnos automatizados. Este ejemplo es un escenario sencillo. Los cmdlets completos necesitarían proporcionar una gama completa de verbos, hacer que las entradas se validen y realizar el manejo de errores. Sin embargo, los ahorros en desarrollo y prueba son dramáticos.

5.2 – Aprovechando .NET

Los desarrolladores utilizan los atributos .NET para descargar el trabajo al entorno de ejecución ²⁷. La filosofía general de Monad es implementar las cosas una vez y luego usarlas en todas partes. Un rico conjunto de atributos declarativos dirigen el tiempo de ejecución de Monad para realizar acciones en nombre del desarrollador. Esto transfiere la responsabilidad de escribir y probar este código, así como de interactuar con el usuario durante las condiciones de error y producir y localizar mensajes de error.

Monad define los atributos de automatización en las siguientes áreas:

Parsing Guidance	Indican al analizador cómo asignar la entrada del usuario al objeto de petición CmdLet. P.ej. Cómo asignar los parámetros a las propiedades, o si un calificador es obligatorio.
Data Generation	Dicen al shell que procese la entrada del usuario para generar los datos reales. También habrá procesadores para hostnames, ipaddrs, registrykeyames, ProcessNames, etc.
Data Validation	Expresan reglas de validación en los datos de entrada. P.ej. Cardinalidad de los datos, valores min/max de los datos, etc.
Encoding Directives	Transmiten la entrada del usuario procesada como objetos de datos. P.ej. Un CmdLet puede querer una matriz de StreamWriters en lugar de una matriz de nombres de archivo.
Object Processing	Realizan un conjunto de funciones comunes en tipos de datos comunes. P.ej. convertir una cadena a minúsculas, etc.
Visibility/Applicability	Proporcionan predicados para visibilidad/aplicabilidad. P.ej. Los cmdlets se pueden etiquetar con la máquina y las funciones del usuario. Si una máquina no tiene la función de servidor DHCP, los comandos del servidor DHCP no estarán visibles de forma predeterminada.
Documentation	Proporcionan información de utilidades sobre el elemento. P.ej. Ayuda
Test	Proporcionan sugerencias a las utilidades para facilitar la generación automática de matrices de prueba.

---

Notas

Capítulo 6 - El Shell Monad (MSH)

Monad proporciona un entorno de tiempo de ejecución para crear APIs, líneas de comandos e interfaces gráficas altamente coherentes, poderosas, detectables y seguras mediante la creación de pipelines de cmdlets. Esta capacidad se suministra como una clase .NET que se puede integrar en una serie de “hosts” que exponen dicha funcionalidad al usuario. El término MSH se refiere tanto al entorno de ejecución como al host que expone el uso como un shell interactivo de línea de comandos.

6.1 - Canalización de objetos (Pipelines) .NET

Monad procesa la entrada del usuario, construye una canalización (Pipeline) de Cmdlets para cada uno de los comandos ingresados, analiza y codifica la entrada del usuario para cada comando en un objeto de petición CmdLet (CRO-CmdLet Request Object). El motor de ejecución de secuencias de comandos “ensambla” la ejecución para luego invocar primer Cmdlet pasando su CRO como un parámetro. Este Cmdlet devuelve un conjunto de objetos .NET que luego se procesan y pasan al siguiente Cmdlet junto con su CRO y así sucesivamente hasta que la Canalización (pipeline) se complete.

Pasar objetos .NET a cmdlets en lugar de flujos de texto permite que las utilidades basadas en Reflection proporcionen una función para cualquier objeto .NET. En el ejemplo anterior, WHERE CmdLet filtra un conjunto de objetos basándose en una prueba de las propiedades del objeto. Resuelve objetos de cualquier tipo (por ejemplo, Procesos, Archivos, Discos, etc.) y consultas para su tipo utilizando las API de Reflection de .NET. Mediante el tipo, consulta la existencia de la propiedad especificada por el usuario (“HandleCount”). Luego, utiliza esta información para consultar cada objeto para el valor de dicha propiedad y finalmente realiza la prueba en esa propiedad para filtrar el objeto apropiadamente.

El mismo mecanismo es utilizado por SORT CmdLet para ordenar un conjunto de objetos y el FORMAT-TABLE CmdLet para mostrar las propiedades de un conjunto de objetos como una tabla. Las utilidades de Monad facilitan el procesamiento de las funciones comunes de los Cmdlets, lo que ahorra costes para el desarrollador y aumenta la potencia/consistencia de los administradores.

La integración de comandos heredados ²⁸ es trivial porque los flujos de texto son simplemente un tipo de flujo de objetos .NET. Dicho esto, una vez traducido a texto, se pierde la capacidad de operar sobre él como un objeto rico basado en Reflection para regresar de vuelta al mundo del análisis de texto.

6.2 - Componentes del entorno de tiempo de ejecución de Monad

El siguiente diagrama ilustra los principales componentes del entorno de tiempo de ejecución de Monad.

6.2.1.1 - El analizador

El analizador de Monad es utilizado por todos los Cmdlets y garantiza una sintaxis coherente. Es responsable de analizar la entrada del usuario para el motor de ejecución de secuencias de comandos. Cuando un usuario introduce una línea de comandos, el analizador asigna el comando a un método CmdLet y su Cmdlet Request Object. Los campos y atributos del objeto de petición se utilizan para analizar el resto de la línea de comandos, generar cualquier información adicional, validar la entrada y codificar esos valores en el objeto de petición.

Al realizar este proceso, el analizador puede agregar metadatos proporcionados por el objeto Request con metadatos proporcionados por proveedores de terceros. Por ejemplo, un objeto de solicitud puede indicar que puede aceptar hasta 16 nombres de nodo y que los nombres deben resolver a una dirección IPv4. Una directiva no puede cambiar esas directivas, pero podría añadir una directiva que indique que los nodos deben responder actualmente a un ping ICMP (por ejemplo, IsAlive).

6.2.1.2 - El motor de ejecución de secuencias de comandos

El motor de ejecución de secuencias de comandos Monad encadena los cmdlets y garantiza una experiencia de ejecución consistente. También es responsable de tomar las canalizaciones (pipelines) codificadas por el analizador y realizar todas las operaciones necesarias para secuenciarlas hasta su finalización. Si las acciones deben ocurrir en una máquina remota o un conjunto de máquinas remotas, se coordina con la MRS y además registra todas las actividades en el registro de auditoría. El motor de ejecución observa el flujo de datos entrante y encuentra las propiedades correctas para enlazar en un CmdLet (un CmdLet puede tener varios parámetros para aprovechar diferentes tipos de datos). La salida de un CmdLet se recoge, se procesa y se pasa a las propiedades apropiadas del siguiente CmdLet. Dado que el entorno de tiempo de ejecución se puede incrustar en varios hosts (por ejemplo, línea de comandos, GUI, etc.), es importante que un CmdLet nunca se comunique directamente con el usuario. El motor de ejecución de secuencias de comandos media esta actividad entre el CmdLet y los distintos hosts.

6.2.1.3 - Los Cmdlets

Los cmdlets realizan acciones. Hay cuatro tipos de Cmdlets: 1) Base 2) Host 3) Plataforma y 4) Usuario. Los cmdlets Base funcionarán en cualquier entorno .NET, como Sort, Where, Group, etc. Los cmdlets de Plataform son aquellos que dependen de una plataforma determinada (XP, Smart Phone o Compact Framework) y no están disponibles en otras plataformas. Los cmdlets de Host son aquellos proporcionados por la aplicación que incorpora el entorno de tiempo de ejecución de Monad. Por ejemplo, msh.exe o GUI de administración que exponen Cmdlets específicos para ese host (por ejemplo, Cambiar una fuente, cerrar una ventana, etc.). Los Cmdlets de User son los escritos por el usuario. Estos pueden ser escritos en cualquier lenguaje (C #, VB.NET, etc), pero la mayoría se escribirá en MSH (el lenguaje shell).

El identificador único de estos Cmdlets es su tipo .NET (por ejemplo, System.Command.ProcessCmdLet). Aunque este identificador siempre se puede utilizar para invocar el CmdLet, es largo y hostil. Como tal, los autores de CmdLet están obligados a proporcionar nombres amistosos a través de atributos.

Será bastante común y fácil que los Cmdlets de mayor orden se implementen obteniendo un conjunto de datos y luego utilizando el tiempo de ejecución de Monad para invocar un script en esos datos y devolver los resultados de ese script.

6.2.1.4 - El reflector de tipo extendido

El poder de Monad es su capacidad de aprovechar la reflexión (Reflection) de .NET. El problema es que hay objetos que están codificados en formas que despojan el poder de la reflexión. Por ejemplo, cuando se reflejan contra datos como Datables ADO, donde las propiedades están “encapsulados” como columnas. En esto escenario lo que necesitamos son los nombres de las columnas, pero estos se codifican de forma diferente. Un problema similar existe con WMI, Active Directory y XML. El reflector de tipo extendido está diseñado para abordar estos problemas.

6.2.1.5 - El Sistema de Anotación y Extensión de Tipo

Tratar con los objetos en crudo proporciona a veces demasiada y otras veces muy poca información. Es el trabajo del tipo anotación y sistema de extensión resolver esta paradoja, proporcionando un mecanismo para que terceras partes definan conjuntos de propiedades (por ejemplo, propiedades asociadas con el rendimiento, la configuración, el consumo de recursos o las dependencias) y dar al conjunto un nombre público. Esto permite al usuario dar un nombre en lugar de tener que especificar cada propiedad. P.ej. “Format-Table resources “ vs. “ Format-Table name ,pid, workingset, handlecount, virtualmemory, privatememory”.

Monad proporciona acceso a los objetos y los métodos sobre esos objetos. Sin embargo, los métodos intrínsecos de un objeto representan un número muy pequeño de las cosas interesantes que los usuarios quieren hacer. El mecanismo de extensión de tipo permite que terceras partes registren métodos intermedios en esos objetos. Estos métodos pueden ser accedidos utilizando la misma sintaxis que los nativos, pero este sistema los enviará al método apropiado de terceros, pasando el objeto original como un parámetro.

6.2.1.6 - El Agente Remoto

Los usuarios podrán ejecutar secuencias de comandos en máquinas remotas a través de solicitudes de servicio Web para el host de agente remoto. Este host incorporará el tiempo de ejecución y responderá a las solicitudes recibidas vía SOAP/HTTP o DIME/TCP. Los usuarios serán autenticados y sus actividades autorizadas (ya sea por ID o por ROLE). Las solicitudes y las respuestas se codificarán de manera que permitan la cancelación y el rastreo de las actividades locales a solicitudes específicas en los registros de auditoría remota.

Cuando una secuencia de comandos está completa, sus objetos de retorno se serializan por valor para la transmisión a través de la red.

6.2.1.7 - Seguridad

Monad podría ser uno de los entornos de shell más seguros jamás creados. Todas las acciones se consignan en un registro de auditoría. Las facilidades de identificación de código proporcionadas por .NET reducen significativamente la exposición a una de los problemas de seguridad más comunes en un entorno de shell: Troyanos. Firmas, nombres fuertes y hashes en la política del sistema se utilizarán para identificar qué utilidades son legítimas y están aprobadas así como para evitar que troyanos conocidos se ejecuten.

En resumen, el shell de Monad minimiza las exposiciones de seguridad y facilita la detección y corrección de las brechas de seguridad.

6.2.1.8 - Host MSH

MSH es un ensamblado .NET que se puede incrustar en cualquier host ejecutable para proporcionar ejecución de scripts y acceso a Cmdlets. Los hosts son capaces de determinar qué subconjunto de Cmdlets se ponen a disposición del usuario. El caso más común es que un Host expone todos los Cmdlets de Base (por ejemplo, ordenar, filtar, etc.), todos sus Cmdlets de Host (por ejemplo, Outlook expondría Cmdlets para tratar con buzones y mensajes) y un subconjunto apropiado de los Cmdlets de Plataforma Cmdlets que tratan de procesos, discos, adaptadores de red, etc.).

MSH es también un ejecutable autónomo que aloja el motor de ejecución de secuencias de comandos y proporciona una rica experiencia interactiva al mismo tiempo que una experiencia de tipo vt100 convincente. MSH proporciona capacidades gráficas complejas como Intellisense para completar el comando. Los datos se pueden imprimir en formatos gráficos para aprovechar las capacidades de interacción y visualización de las PC.

6.3 - Lenguaje de secuencias de comandos de MSH

MSH proporciona un lenguaje de scripting completo utilizando las funciones y la sintaxis del modelo POSIX Shell (control de flujo, manejo de fallas, variables, definición de funciones, alcance, redireccionamiento IO, etc.) como punto de partida, para mejorar la experiencia de programación, aprovechar la nueva funcionalidad o proporcionar una ruta de evolución a C#. El objetivo es que los administradores de UNIX que trabajen con Windows encuentren fácil aprender y migrar sus habilidades a MSH.

Además de escribir funciones tradicionales, los usuarios pueden usar las capacidades de secuencias de comandos de MSH para escribir sus propios Cmdlets y para agregar o reemplazar verbos a los sustantivos existentes de CmdLet.

---

Notas

Capítulo 7 - Modelos de gestión de Monad (MMM)

Monad ayuda a los desarrolladores de aplicaciones a diseñar la experiencia administrativa proporcionando un conjunto de modelos de gestión. Un MMM es un conjunto rico de clases base de automatización basadas en escenarios y una herramienta o conjunto de herramientas que utilizan esas clases para realizar un escenario de administración particular. Estas clases bases cubren los principales escenarios de administración, incluyendo: Navegación, Diagnóstico, Configuración, Ciclo de vida y Operaciones. Las clases base proporcionan una forma común de realizar estas tareas en varios tipos de recursos. Esto permite al administrador aprender un modelo para gestionar un escenario en particular y luego aplicar ese modelo a una amplia gama de problemas y nuevas situaciones. Los desarrolladores seleccionan el conjunto apropiado de clases base, derivan sus propias clases de éstas e implementan los métodos apropiados para sus tipos de recursos. Las clases base proporcionan lo siguiente:

1. Un conjunto de verbos para el escenario (por ejemplo, Navigation tiene el conjunto de verbos: pwd, cd, dir, pushd, popd, dirs)
2. Un conjunto de objetos de solicitud base que definen calificadores comunes. P.ej. Si el escenario se refiere a una máquina remota, el objeto de petición base definiría un calificador común -MACHINENAME. Esto disuade a la gente de usar los términos: NODE, SERVER, HOST, etc.
3. Un conjunto de excepciones y mensajes de error para ese escenario. P.ej. Habrá una excepción esquematizada estándar para “Recurso no disponible” para que no terminemos con decenas de variaciones [que existen hoy en día].
4. Soluciones comunes a problemas de escenario comunes. P.ej. Las clases base proporcionarán una solución estándar para el problema de que alguien pida accidentalmente demasiada información [por ejemplo, obtener todos los objetos en LDAP].

Microsoft localizará todas las partes visibles de estos escenarios (verbos, calificadores, mensajes de error, etc.) para que los ISVs puedan reducir significativamente sus costos de desarrollo mediante el aprovechamiento de estas clases base. Además de estos beneficios, Monad proporciona controles de interfaz de usuario para mostrar gráficamente e interactuar con implementaciones de estas clases base. Monad enrá con un plug-in MMC de herramientas que alojan estos controles de interfaz de usuario, pero los ISV o los desarrolladores internos pueden alojar los controles en sus propias UI de administración. Dado que estos controles tendrán acceso a interfaces de datos y control bien definidos, terceras partes también pueden crear controles de reemplazo.

Un ejemplo

La navegación proporciona un ejemplo de un modelo de gestión. Habrá una clase base para todos los Cmdlets que quieran hacer Navigation. Esto definirá los verbos (pwd, cd, pushd, dirs, popd, dir), mensajes de error comunes y proporcionará implementaciones comunes para problemas comunes (pushd, dirs y popd se implementarán una vez). Esa clase base puede ser “subclaseada” para proporcionar una experiencia de administración consistente con una cantidad mínima de código. Una vez que el administrador aprende cómo usar este modelo, podrá utilizarlo en una amplia gama de recursos. Navegar el sistema de archivos será el caso por defecto:

Los mismos comandos se pueden utilizar para explorar el Registro:

Los mismos comandos se pueden utilizar para explorar el sistema de Ayuda, Active Directory, bases de datos SQL, WMI u otros espacios de nombres.

Capítulo 8 - El Script Remoto de Monad (MRS)

Monad proporciona un mecanismo basado en Web Services para ejecutar scripts en sistemas remotos. Los scripts se pueden ejecutar en un solo o un gran número (muchos miles) de sistemas remotos. Los resultados de los scripts pueden ser procesos a la medida que cada script individual completa o los resultados pueden ser agregados y procesados en masa cuando todos han terminado. Un script se puede ejecutar en modo BestEffort o Reliable. Los scripts de BestEffort se ejecutan desde el proceso existente y si ese proceso termina, no se realiza ningún trabajo para limpiar los scripts remotos y se pierden los resultados. Los scripts de modo Reliable se persisten en una tienda de SQL local y un servicio maneja la ejecución de la secuencia de comandos. El usuario puede iniciar sesión en la máquina y el servicio continúa procesando el script. El usuario puede iniciar sesión y obtener los resultados de ese trabajo en el futuro.

Capítulo 9 - La consola de administración de Monad (MMC)

Monad proporciona un conjunto rico de Cmdlets de servicio de marco de administración para facilitar la creación de consolas de administración. Estos servicios reducen los costos de desarrollo y de pruebas para producir UIs y consolas de administración, a la vez que permiten una experiencia integrada y administrativa. Los servicios se utilizan para producir una consola de administración integrada, pero también pueden ser utilizados por terceros o por la propia TI para implementar su propia consola de gestión. El objetivo es ser capaz de proporcionar el 50-70% de una herramienta genérica de administración GUI de forma gratuita sólo mediante la construcción del tipo correcto de Cmdlets. Monad ofrece los siguientes recursos y servicios:

1. Un entorno de ejecución de secuencias de comandos que proporciona a las GUI un acceso uniforme y coherente a recursos locales y remotos.
2. Una interfaz integrada y un entorno de línea de comandos para que las interacciones GUI se muestren en una consola de línea de comandos. Los usuarios pueden usar esto para aprender la capa de automatización y también pueden ejecutar directamente acciones de línea de comandos. Este mecanismo además proporciona el soporte para la grabación/reproducción de macros.
3. Scripts de aplicaciones específicas. La aplicación puede exponer sus funciones internas (por ejemplo, botones, pantallas, estructuras de datos internas, etc.) a través de Cmdlets para permitir scripting específico de aplicaciones, depuración y compatibilidad.
4. Controles de la interfaz de usuario base asociados con MMMs específicos. (Por ejemplo, controles de navegación, controles del ciclo de vida, controles de diagnóstico).
5. Conjunto rico de mensajes de error de base que se localizarán por MMC.
6. Un marco de interfaz de usuario declarativa para permitir GUI de administración personalizada basada en metadatos.

Chapter 10 - Value Propositions

• For application developers who need to expose their administrative functions as command lines and GUIs, Monad provides a highly productive development framework.
  • Unlike building stand-alone command lines, Monad provides most of the common functions including a parser, a data validator/encoder, error reporting mechanisms, common functions like sorting/filtering/grouping/formatting/outputting and a set of management models which provide common verb sets, error messages and solutions to common problems and tools.
  • Unlike WMI/WMIC, Monad provides a simple programming model. Cmdlets are merely attributed .Net classes.
  • Unlike MMC, Monad provides strong guidance on how to perform management tasks and large benefits (reduced coding/testing) for those that follow that guidance.
• For application testers who want to ensure that the administrative command lines and GUIs operate correctly, Monad reduces the amount of code that needs to be tested and increases the productivity of the test process.
  • Unlike building stand-alone command lines, Monad provides a common implementation of most common functions minimizing the amount of application code to develop and test.
  • Unlike traditional management GUIs, Monad layers GUIs on top of Cmdlets so the bulk of the GUI core will already be tested when the command line is tested. Monad will also make it easier to test GUIs by exposing the inner workings of the GUI through a command line shell and by the ability to drive the GUI controls and code paths through command line scripts.
• For power users who want to interact with the system through command line interfaces, Monad provides a highly consistent set of commands and utilities as well as an environment that allows the creation of custom admin tools (i.e. not scenario bound).
  • Unlike cmd.exe, sh, ksh, csh, etc and traditional commands and utilities, Monad provides a common parser for all CmdLet and utilities ensuring syntactic consistency and common input error handling and messaging across all Cmdlets and utilities.
  • Unlike cmd.exe, sh, ksh, csh, etc and traditional command and utilities, Monad provides a strong prescriptive guidance and enforcement of CmdLet naming and error handling and provides a set of scenario automation base classes which make it easy and valuable for developers to follow those guidelines.
  • Unlike cmd.exe, sh, ksh, csh, etc and traditional command and utilities, Monad replaces pipelines passing text with pipelines passing .Net objects which allows utilities to use the .Net reflection APIs to operate directly against the objects without the need to perform error-prone text parsing and object lookup.
• For Administrators that want to develop management scripts to automate the management of their systems, Monad provides a highly productive model for learning and effecting that automation.
  • Unlike cmd.exe, the Monad shell is based upon and extends the Bourne Shell syntax and control structures facilitating the skill transfer of Unix Admins.
  • Unlike sh, ksh, csh, etc and traditional command/utilities, Monad uses .Net objects instead of text as an integration mechanism allowing easier and more precise integration.
  • Unlike sh, ksh, csh, etc and traditional command/utilities, Monad exposes a rich error model leveraging .Net objects to expose precise details of what went wrong, where, when, and what objects where processed/unprocessed.
  • Unlike traditional management GUIs, Monad GUIs allow Admins the ability to see the inner workings of the GUI by exposing their actions via a command line console so that the Admin can learn the automation surface by using the GUI.
• For GUI users who want to automate their operations, Monad facilitates learning the automation layer by exposing the shell equivalents of GUI interactions.
  • Unlike traditional management GUIs, Monad GUIs are layered on top of Cmdlets so every function available in the GUI is also available via the command line. Unlike traditional management GUIs, Monad GUIs allow Admins the ability to see the inner workings of the GUI by exposing their actions via a command line console so that the Admin can see the command line equivalent of their GUI interactions.

Notas