Microsoft.Net. CLR (Common Language Runtime)

Transcripción

1 Universidad de Oviedo Departamento de Informática Microsoft.Net. CLR (Common Language Runtime) Junio, 2002 Introducción Necesidad de una Infraestructura El desarrollo de aplicaciones software es una tarea en sí compleja La apertura de éstas a entornos distribuidos (Internet) la hace todavía más compleja Puede dar lugar al fracaso de un proyecto Los requisitos de infraestructura de las aplicaciones distribuidas son los mismos, por qué no ofrecerlos en una plataforma? Microsoft.net es una plataforma que ofrece la infraestructura para resolver los problemas comunes del desarrollo de aplicaciones distribuidas 1

2 .net Framework Introducción.net Framework proporciona soluciones prefabricadas para el desarrollo de aplicaciones distribuidas. Consta de: 1. Common Language Runtime (CLR) Proporciona el entorno de ejecución de todas las aplicaciones del sistema Proporciona una capa intermedia entre el sistema operativo y las aplicaciones Su diseño se basa en el concepto de máquina virtual o abstracta 2. Librerías de clases: Base Class Libraries (BCL), WinForms, Win32, ADO.NET Plataforma de Aplicaciones Web: ASP.NET y Servicios Web CLR Introducción La utilización del CLR aporta las siguientes ventajas: 1. Disponibilidad de las características de cualquier lenguaje: La elección del lenguaje estará condicionada por el dominio del problema, no por otras características librerías, eficiencia, frameworks... Puedo utilizar el API de Java desde otros lenguajes? 2. Heterogeneidad: Internet es una arquitectura heterogénea, las aplicaciones deberían poder ejecutarse de forma independiente a la plataforma 3. Interoperabilidad de aplicaciones orientadas a objetos, independientemente de los lenguajes de programación seleccionados 4. Gestión automática de memoria: la gestión de memoria es compleja en aplicaciones de servidor 2

3 CLR (II) Introducción 5. El mantenimiento de aplicaciones da lugar a versiones de componentes OO utilizados por diversas aplicaciones. La coexistencia de distintas versiones de componentes demandada por distintos clientes debe ser gestionada sin incoherencias 6. Las aplicaciones distribuidas por redes son cada vez más un canal de adquisición y ejecución de software. La limitación de acceso a recursos por aplicaciones posee mayor veracidad que un sistema todo o nada de certificados 7. Organización de las funciones del sistema operativo mediante jerarquías 8. Debe mantenerse compatibilidad hacia atrás para crear e interactuar con código existente (legacy code) Independencia del Lenguaje Expresividad de los Lenguajes Siempre puede aparecer la controversia acerca de qué lenguaje de programación utilizar Lo ideal es que la elección de un lenguaje estuviera condicionada al dominio del problema (parcial o total) a resolver Las facetas propias de: Librerías Gestión de memoria Eficiencia Tamaño de los programas a utilizar Componentes Portabilidad Distribución Persistencia estarán ligadas al entorno de ejecución (al CLR), no al lenguaje 3

4 Todos se ejecutan sobre el mismo entorno de ejecución: el CLR! Procesamiento del Lenguaje Independencia del Lenguaje Entorno Computacional Único JScript Perl Python Orientado a Objetos VBS VBA VB.NET C# C++ Dinámico/ Scripting Haskell Script Paradigma Funcional /Lógico Prolog Haskell Estático ML Solución Independencia del Lenguaje Objetivos Principales: Ejecución Más de aplicaciones 20 lenguajes Generación de código nativo (JIT) Pascal C# Gestión Oberonde Memoria Python (GC) Scheme Cobol Gestión de versiones (componentes) Mondrian Mercury Seguridad (acceso recursos) SML Manejo de VBexcepciones JScript Eiffel Haskell Único Sistema de tipos Independencia Compilación de la plataforma Interoperabilidad con COM Código Intermedio: IL (Intermediate Language), MSIL (Microsoft...), CIL (Common...) Ejecución CLR Sistema Operativo 4

5 Demo Independencia del Lenguaje ILASM (Intermediate Language Assembler): Hola.il Angulo.il Heterogeneidad Independencia de la Plataforma Internet es heterogéneo Una aplicación deberá ser capaz de ejecutarse en cualquier plataforma Windows o no. Write one, run anywhere La utilización de una plataforma virtual, permite que una aplicación se ejecute en cualquier dispositivo capaz de ejecutar una implementación del CLR Muy útil para distribuir código por redes 5

6 Portabilidad de un Lenguaje Máquina abstracta: Diseño de un procesador computacional sin intención de que éste sea desarrollado de forma física La utilización de una plataforma intermedia abstracta (máquina virtual) ya fue utilizada en los 70 por la UCSD para construir código pascal portable (p-code) Posteriormente, se utilizó en Scheme, Prolog, Smalltalk y Java Pascal P-code Compilación Heterogeneidad Ejecución Máquina-P Máquina-P Máquina-P Máquina-P Zilog Z80 DEC LSI Motorola Intel 8088 Distribución de Código Heterogeneidad Las aplicaciones podrán ejecutarse en todas las plataformas que posean una implementación de la máquina abstracta Se facilita la distribución de código por la red: En el caso de Java, permitía ejecutar Applets en cualquier plataforma (navegador) Aplicación Compilación Código Portable 6

7 Heterogeneidad Portabilidad de un Único Lenguaje La utilización de máquinas virtuales ha estado enfocada a la portabilidad de un único lenguaje Lo mejor de la plataforma Java, sólo es accesible desde el lenguaje Java : Modelo de componentes (JavaBeans) Distribución (RMI, applets, java.net...) Serialización Gestión de memoria Conjunto de librerías Servidores de aplicaciones J2EE... La idea de Microsoft.net es que todas estas ventajas sean accesibles directamente (sin bridges) desde cualquier lenguaje Heterogeneidad Common Language Runtime El CLR fue diseñado para poder ejecutar un elevado número de lenguajes de programación (Common) Es capaz de ejecutar cualquier lenguaje? Existen algún lenguaje (o características de algún lenguaje), que no puede computar de un modo directo: Forth El concepto de continuation de Scheme C# VB Eiffel Haskell Compilación CLR Sistema Operativo Ejecución 7

8 Demo Heterogeneidad HolaVB.vb HolaCS.cs ILDASM (Intemediate Language Disassembler) Comparación de código generado Eficiencia Heterogeneidad La utilización de un único motor computacional (CLR) proporciona multitud de ventajas, pero un claro inconveniente: la eficiencia La interpretación es más cara que la ejecución nativa, puesto que existe un nivel computacional más Es el CLR un intérprete? NO (necesariamente) En lugar de interpretar el código, el CLR (Compilador JIT): Compila dinámicamente el código a su representación nativa en la plataforma de ejecución Optimiza el código generado (e.g., inlining) Aplicación Código Portable Compilador JIT Compilación Ejecución 8

9 Utilización del JIT Heterogeneidad La utilización de la compilación bajo demanda (JIT) es óptima para aplicaciones descargadas de una red Se ejecutan de un modo esporádico Su actualización es frecuente Sin embargo, la generación de código nativo, cada vez que se ejecuta una aplicación de escritorio, es una tarea inútil: Conviene llevar en el sistema un almacén de imágenes nativas de las aplicaciones generadas Demo Heterogeneidad JIT.cs NGEN (Native Generator) Compilación / Ejecución: Debug / sin imagen (ngen /delete) No-debug / con imagen (ngen) 9

10 Interoperabilidad Interacción de Aplicaciones La utilización de una máquina virtual permite que las aplicaciones interactúen independientemente del lenguaje de programación empleado COM trataba de conseguir dicho objetivo, pero tiene los siguientes inconvenientes: Es necesaria una elevada infraestructura para cada componente: factorías de clases, contadores de referencias de interfaz, GUIDs, Progs IDs, necesidad o no de IDispatch... No se comparte una única implementación de un modelo computacional: la traducción de los distintos elementos es una tarea compleja String(Pascal)!= String(C++)!= String(Java) La representación de los objetos es distinta para cada lenguaje... Metadatos Interoperabilidad La interacción entre aplicaciones en.net es directa gracias a los metadatos (metadata): la representación de los datos es común en todos los lenguajes de programación Un archivo.exe en.net es portable (portable executable) puesto que consta de: Código gestionado (managed code): Código intermedio que será ejecutado por el CLR en cualquier plataforma Metadatos (metadata): Descripción de todas las estructuras de una aplicación (clases, atributos, métodos, signaturas...) De este modo, la interacción entre aplicaciones es directa, sin necesidad de traducciones previas 10

11 Demo Interoperabilidad Modificar Holacs.cs para que invoque a HolaVB.Mostrar() Compilar Holavb.vb con /target:library Compilar Holacs.cs con /r:holavb.dll Holacs.exe: Interacción directa de dos lenguajes de dos lenguajes de programación (VB y C#) Ensamblados Interoperabilidad Un ensamblado (assembly) es una colección lógica de recursos de una aplicación (archivos.exe,.dll,.ini,.jpg...) Es una unidad reutilizable de implantación (despliegue); componente La generación de ensamblados puede llevarse a cabo mediante la utilización del Assembly Linker (AL.exe) del.net Framework Los ensamblados poseen un conjunto de módulos: código gestionado (archivos.exe y.dll ) 11

12 Módulos Interoperabilidad Los ensamblados poseen un conjunto de módulos: código gestionado (archivos.exe y.dll ) Los cada ensamblado ha de tener un módulo principal Los distintos módulos Módulo Principal de un ensamblado CIL interactúan entre sí mediante la Metadatos utilización de sus metadatos: Metadatos Metadatos CIL CIL Módulo 2 Módulo 3 Ensamblado Manifiestos Interoperabilidad Todo ensamblado contiene un manifiesto (manifest): metadatos que describen el ensamblado y sus módulos. Consta de: Dependencias con otros ensamblados (.assembly extern) Identificación de ensamblado (nombre) Versión Valor hash (CRC) Clave pública (opcional) Módulo principal (.module) Módulos secundarios (.module extern) Archivos adicionales (.file) Información adicional de compiladores y herramientas 12

13 Demo Interoperabilidad Mostrar los manifiestos de los dos ensamblados: ILDASM holacs.exe ILDASM holavb.dll Crear un único ensamblado (único manifiesto) con todos los módulos de la aplicación: VBC /target:module /out:holavb.dll holavb.vb CSC /target:module /out:holacs.dll holacs.cs AL holacs.dll,holavb.dll /target:exe /out:ens.exe /main:holacs.main ILDASM ens.exe Gestión de Memoria Liberación Automática En el desarrollo de aplicaciones de servidor la gestión automática de memoria es una tarea crítica: Ejecución continua durante largos periodos Múltiples clientes en aplicaciones multihilo Utilización de protocolos stateless (HTTP) Una de las tareas del CLR es gestionar automáticamente la liberación automática de memoria: recolección de basura (Garbage Collection) 13

14 Infierno de las DLLs Versiones de Componentes DLLs Las aplicaciones se construyen mediante la utilización de componentes El mantenimiento de aplicaciones requiere el mantenimiento de los componentes empleados Los componentes sufren modificaciones y sus nuevas versiones reemplazan las antiguas La compatibilidad hacia atrás no se consigue en multitud de ocasiones: Aplicaciones funcionaban correctamente, al instalar nuevas aplicaciones, dejan de funcionar Este problema se conoce como Infierno de las DLLs (DLL Hell) Ensamblados Versiones de Componentes La sobrescritura de DLLs y su registro en el Registry es eliminada en.net El concepto a utilizar es el de ensamblado: Podrán coexistir diversas versiones del mismo ensamblado en un mismo equipo Los ensamblados no necesitarán entradas en el Registry Existen dos tipos de ensamblados: Privados a una aplicación (ej. ens.exe): Uso exclusivo de una aplicación basta con ubicarlo en su directorio Compartidos por aplicaciones: Se utiliza cuando se desea el componente sea accesible para cualquier aplicación 14

15 Versiones de Componentes Ensamblados Compartidos Un ensamblado compartido se ubica en el GAC (Global Assembly Cache) \\winnt\assembly\ (Windows 2000) \\windows\assembly\ (Windows XP) Éste puede verse con el Assembly Cache Viewer que es una extensión del explorador de archivos No utiliza el Registry ni el Active Directory Para manipular el GAC, tenemos la utilidad GACUTIL del.net framework Nombre Seguro Versiones de Componentes Un nombre nombre seguro o compartido (strong name) consta de: 1. Nombre (identificador) 2. Clave pública del fabricante 3. Versión Con 1 y 2, evitamos la colisión de nombres Con 1, 2 y 3, evitamos la colisión de versiones Los componentes se deben firmar desde el VS.NET o con SN.exe del SDK 15

16 Services Description Discovery Organización de Funciones Llamadas al Sistema System.Web La plataforma.net ofrece el acceso System.Drawing a sus librerías Security Drawing2D Printing dentro del concepto de organización jerárquica SessionState Imaging Text espacio de nombres (namespace) La funcionalidad System.Data del sistema se ofrece System.Xml por medio SQL XSLT Serialization del espacio de nombres System SQLTypes XPath El conjunto de funcionalidades se denomina librería de clases base System (BCL, Base Class Library) Protocols Caching Configuration ADO Design Collections Configuration Diagnostics Globalization UI HtmlControls WebControls IO Net Reflection Resources Security ServiceProcess Text Design Threading System.WinForms ComponentModel Runtime InteropServices Remoting Serialization Interoperabilidad con COM Legacy Code Existen múltiples aplicaciones desarrolladas para las antiguas plataformas Win32. La compatibilidad hacia atrás con este tipo de aplicaciones (lecacy code) es esencial para.net El CLR es capaz de interactuar con COM en dos sentidos para: Acceder desde nuevas aplicaciones.net a módulos o aplicaciones COM, sin necesidad de rescribir éstas Actualizar aplicaciones antiguas con nuevos módulos desarrollados en.net: acceso desde COM a.net 16

17 Acceso a COM Legacy Code Un cliente.net tiene acceso a COM mediante RCW Runtime Callable Wrapper La utilidad TLBIMP del SDK permite crear el RCW a partir de un componente COM Importando el espacio de nombres, podemos crear objetos mediante new (CoCreateInstance) En el paso de mensajes se efectúa el marshaling de parámetros de.net a COM El decremento de la referencia a este objeto es gestionada por el recolector de basura Cliente.net RCW Componente COM Demo Legacy Code Desde VS.NET, Project Add Reference se crea un espacio de nombres envoltorio que traduce su acceso al propio del componente COM Añadir una referencia Automation al Word Word.Application ap=new Word.ApplicationClass(); 17

18 Acceso desde COM Legacy Code.net Framework permite que un cliente COM pueda acceder a objetos.net CCW, COM Callable Wrapper ofrece dicha funcionalidad: El componente ha de estar firmado El componente ha de estar en el GAC La clase.net que sea accesible desde COM, debe ofrecer un constructor sin parámetros Es necesario incluir una entrada en el Registry, mediante RegAsm.exe del SDK Se crean los interfaces IUnknown e IDispatch más los interfaces de las clases públicas Clase.net MiInterface CCW IUnknown MiInterface IDispatch Cliente COM Carencias de Seguridad Seguridad La mayoría de sistemas de seguridad se basan en listas de control de acceso (ACL) Este sistema de acceso es correcto para aplicaciones de escritorio, pero qué sucede con la distribución de aplicaciones por medio de redes (Internet)? Authenticode es realmente un sistema de responsabilidad, no de seguridad: identifica quien produjo el daño, pero no lo evita Lo que se desea es limitar las operaciones que puedan realizar los distintos fragmentos de código en función del nivel de confianza (trust management) que tengan 18

19 Acceso a Recursos Seguridad El administrador otorga los niveles de confianza a los distintos ensamblados del sistema \\WINDOWS\Microsoft.NET\Framework\[version]\CONFIG\security.config El CLR ejecuta el código de las aplicaciones limitando el acceso a los recursos en base a su configuración Se puede dar un nivel de confianza (IPermission) a ensamblados agrupados por distintos criterios (PermissionSet) Procedencia: Internet, LocalIntranet, Execution (Desktop)... Fabricante: ECMA, Microsoft, My_Computer_Zone, All_Code... Se trata pues de un sistema de privilegio de acceso a recursos por código, no usuario Documentación S. Lidin. Inside Microsoft.net IL Assembler Microsoft Press, 2002 J. Gough Compiling for the.net Common Language Runtime Bertrand Meyer Series Editor, 2002 msdn.microsoft.com/net Download de.net Framework SDK Documentación (Common Language Specification, MS-IL Assembly Programmers Guide...) Artículos de.net E. Meijer, J. Gough Technical Overview of the Common Language Runtime Microsoft.com,

20 Universidad de Oviedo Departamento de Informática Microsoft.Net. CLR (Common Language Runtime) Junio,