Arquitectura del Common Language Runtime Daniel A. Seara Director Regional MSDN Buenos Aires – ARGENTINA NDSoft.

Presentación del tema: "Arquitectura del Common Language Runtime Daniel A. Seara Director Regional MSDN Buenos Aires – ARGENTINA NDSoft."— Transcripción de la presentación:

1 Arquitectura del Common Language Runtime Daniel A. Seara Director Regional MSDN Buenos Aires – ARGENTINA NDSoft

2 Protocolos abiertos SOAP, SCL, DISCO HTTP, SMTP, XML, WAP, XSD HTTP, SMTP, XML, WAP, XSD.NET Su Aplicación y Servicio Web.NetFramework Windows CE, ME, 2000,.NET Operaciones Usuarios Finales Otras Aplicaciones usando su servicio Orquestación Sus Servicios Internos.NET Enterprise Servers Servicios “Building Block” Web Services Públicos Visual Studio.NET

3 Windows (CE, ME, 2000, and.NET) Orchestration.NET Enterprise Servers Building Block Services.NET Framework Microsoft®.Net Framework Base Classes Data & XML User Interface Common Language Runtime Web Services

4 Common Language Runtime Frameworks Class loader and layout IL to native code compilers GC, stack walk, code manager Security Execution Support Base Classes

5 Desarrollos más fáciles Escribir menos, re-usar más Marco de trabajo amplio, consistente Clases al mismo tiempo que interfaces Desaparece la “plomería” Metadata Proxies transparentes Administración de la memoria Buen soporte a herramientas WYSIWYG Diseñadores y asistentes Depuradores Administradores de perfiles

6 Desarrollo Simple y Seguro Sin Registración, instalaciones “cero impacto” Instalación con XCOPY, descarga (download) incremental Versiones lado a lado de componentes compartidos Captura de la versión en la compilación Políticas de administración en tiempo de ejecución Política de seguridad basada en evidencia Tanto en código como en el usuario Origen del código (ubicación) Publicador (clave pública)

7 Escalabilidad De dispositivos inteligentes a granjas de servidores Administración de memoria automática Auto configurable Ajuste dinámico “Thread pool” Mensajes asincrónicos Objetos remotos Eventos Versión para dispositivos inteligentes Múltiples SOTRs Las mismas herramientas que para el escritorio

8 Clientes Web ricos, publicación en Web segura Win Forms en el cliente ASP.Net Web Forms en el servidor Se asignan permisos al código Las políticas de seguridad se manejan por evidencias Aplicaciones que pueden iniciar el motor de ejecución  Internet Explorer, IIS, SQL Server ™, Shell Proveen cierta evidencia Se controla el código que se carga Se relacionan las aplicaciones con procesos

9 Convergencia de Modelos de Programación COM, ASP, Data Todos los servicios están disponibles Muchos rediseñados  Fáciles de usar  Escalables  API consistente El marco consistente permite un mayor nivel de abstracción Transición gradual desde lo simple hasta el control completo

10 Múltiples Lenguajes “Common type system” Orientado a objetos Se soportan también lenguajes procedurales Es posible además la utilización de lenguajes “por funciones” Guías de diseño del marco CLS Reglas para un alcance amplio Toda la funcionalidad del marco está disponible Más de 15 lenguajes investigados La mayoría son consumidores Muchos pueden extender el marco

11 Resumen Código Multi-lenguaje, seguro, móvil Escalable desde dispositivos móviles hasta servidores Versionamiento lado a lado Auto descriptivo Marcos poderosos Modelo de programación simplificado Fuerte integración de las herramientas

12 Metadata Clave para un modelo de programación simple Generada automáticamente Se almacena con el código en el ejecutable (.dll o.exe) Usa formato COFF existente  Por un mecanismo de extensión Almacenado en formato binario Convertible de/a “Schema XML” Convertible de/a librerías de tipos COM

13 ¿Qué hay en la Metadata? Descripción de la unidad de instalación (assembly) Identidad: nombre, versión, cultura[, clave pública] Que tipos se exportan De que otros Assemblies depende Permisos de seguridad necesarios para la ejecución Descripción de tipos Nombre, visibilidad, clase base, interfaces implementadas Miembros (métodos, campos, propiedades, eventos, tipos heredados) Atributos personalizados Del usuario Del compilador Del marco

14 Metadata: Creación y Uso Metadata (y código) Debugger SchemaGenerator Profiler OtherCompiler Proxy Generator Type Browser Compiler SourceCode XML encoding (SDL o SUDS) Serialization (e.g. SOAP) Designers Reflection

15 Los compiladores usan la Metadata Par importar datos entre lenguajes Se emite la metadata junto con el código compilado Describe los tipos definidos y los que utiliza Registra los assemblies externos referenciados Registra la información de versión Atributos personalizados Obsoletos Compatibilidad CLS Compilado para depuración Marcadores específicos del lenguaje

16 Otras herramientas usan Metadata Comportamiento del diseñador Controlado por atributos del usuario  Categoría  Descripción Extensibilidad del diseñador Atributos de usuario que especifican código a utilizar  Convertidores de tipo  Editores Los métodos como Servicios Web se marcan por atributos personalizados Visor de tipos

17 Assemblies Unidad de instalación Uno o más archivos, independiente del empaquetado Auto descriptivos a través de metadata (“manifiesto”) Versionamiento Capturado por el compilador Políticas por aplicación y por máquina Límites de seguridad Los Assemblies garantizan permisos Los métodos pueden reclamar prueba que toda la cadena de llamadas tiene permisos adecuados Importación y exportación mediada por tipos Los tipos se nombran relativos a los assemblies

18 Aplicaciones Las aplicaciones son unidades configurables Uno o más assemblies Archivos o datos específicos por aplicación Los Assemblies se buscan basados en… Su nombre lógico La aplicación que lo carga Las aplicaciones pueden tener versiones privadas de los Assemblies La versión privada se prefiere respecto de la compartida La política de versiones puede ser por aplicación

19 Modelo de ejecución VBVC...Script IL Native Code “Econo”JIT Compiler Standard JIT Compiler Native Code Install time Code Gen Common Language Runtime

20 El modelo de proceso Proceso Datos Compartidos de la clase y código nativo App. Domain (Datos Compartidos de la clase y código nativo) App. Domain Hilo

21 Código Administrado Provee... Metadata que describe Ubicación de referencias a los objetos Tabla de controladores de excepciones El motor de ejecución provee… Manejo de excepciones Seguridad Manejo automático de la “vida” de los objetos Depuración y perfiles

22 Control de flujo del Motor Class Loader IL to native code compiler CPU Security System Code Managers Managed Native Code Assembly Primer llamada a un método Primer referencia al tipo Execution Support

23 Compilando IL a Cód. Nativo “Econo” JIT Genera código nativo “no optimizado” El código puede descartarse y regenerarse “Standard” JIT Genera código optimizado Incluye verificación del código IL Generación del código en la instalación Reduce el tiempo de inicio El código nativo tiene control de versión y puede revertir al JIT si hay diferencias

24 Datos Manejados Disposición provista por el Motor Usualmente automática La Metadata puede especificar  Orden  Empaquetado  Disposición explícita El tiempo de vida es manejado por el Motor (GC) Se compacta el área de trabajo Los datos se “mueven” Se actualizan las referencias a los objetos Menos intrusivo que un “fallo de página”

25 Llamando código “no manejado” Native Code “Econo”-JIT Compiler Standard JIT Compiler Native Code Common Language Runtime Unmanaged Managed

26 Cruzando los Límites Modo de transición para el manejador de código Las convenciones de llamadas difieren en x86 Rápido, aunque raramente mejor que la búsqueda en la Registry “Marshalling” de datos Las representaciones pueden no coincidir Pueden requerirse punteros, copias o cambios de formato Soporta “marshalling” personalizado El compilador IL a nativo ayuda Transición en línea de código y “marshalling” simple El costo por llamada es muy bajo  Más un pequeño costo en la entrada a un procedimiento que puede hacer llamadas fuera de los límites

27 3 mecanismos Puntero a función No hay transición, ni “marshalling” Restricciones rigurosas en el código llamado “Funciona” Transición de modo, sin “marshalling” Todo el trabajo lo realizan las herramientas (VC)  El vinculador(Linker) resuelve las referencias  El “Class loader” crea manejadores de transición “Platform invoke” (p/Invoke) Transición de modo,”marshalling”

28 COM Interoperabilidad Usa mecanismos p/Invoke Se mantiene la identidad de los objetos (IUnknown) Interfaces COM creadas automáticamente Los tipos se exportan y registran automáticamente a COM Las bibliotecas de tipos de COM pueden convertirse a metadatas e importarse Muchos tipos de datos pueden manejarse por “marshalling”

29 Resumen Simple… Desarrollo, instalación, administración Código multilenguaje, móvil, seguro Todo el código se compila antes de ser ejecutado ¡No es una “máquina virtual” tradicional! Interoperabilidad completa con código no administrado COM, servicios COM+ 1.0, win32 ®, DLLs Escalable: de dispositivos móviles hasta granjas de servidores