que - idl reporteros wikipedia

¿Qué es IDL? (6)

¿Qué se entiende por IDL? Lo he buscado en Google y descubrí que significa Lenguaje de definición de interfaz, que se utiliza para la definición de interfaz de los componentes. Pero, en la práctica, ¿cuál es el propósito de IDL? ¿Microsoft lo usa?

Define la interfaz que se utilizará para la comunicación con un servicio expuesto en otra aplicación.

Si usas SOAP, conocerás WSDL. El WSDL es otra forma de un IDL. IDL generalmente se refiere a Microsoft COM o CORBA IDL.

Es un lenguaje que se ha utilizado en la era COM para definir interfaces de una manera (supuestamente) neutral en cuanto al idioma.

IDL es un acrónimo de en.wikipedia.org/wiki/Interface_description_language de en.wikipedia.org/wiki/Interface_description_language que hay varias variaciones según el proveedor o el grupo estándar que definió el idioma. El objetivo de una IDL es describir la interfaz de algún servicio para que los clientes que quieran usar el servicio sepan qué métodos y propiedades, la interfaz que proporciona el servicio. IDL se utiliza normalmente con interfaces binarias y el archivo de idioma IDL describe los tipos de datos utilizados en la interfaz binaria.

Existen varios estándares diferentes para los componentes binarios, normalmente COTS o Commercial Off The Shelf , y la forma en que un cliente se comunica con el componente binario puede variar, aunque tradicionalmente se usa alguna versión de llamada a procedimiento remoto o RPC . Dos de estos estándares son el Modelo de objetos comunes de Microsoft o el estándar COM y el Agente de solicitud de objetos comunes o el estándar CORBA . Existen otros estándares para componentes como los complementos de Firefox o los complementos para otras aplicaciones, como Visual Studio, sin embargo, estos no necesariamente usan algún tipo de Lenguaje de Descripción de la Interfaz, sino que utilizan algún tipo de Kit de Desarrollo de Software o SDK con interfaces bien conocidas y estandarizadas para una API.

Lo que permite una IDL es un mayor grado de flexibilidad para poder crear componentes que ofrecen servicios de diversos tipos que, debido a su naturaleza binaria, pueden usarse con una variedad de lenguajes de programación diferentes y una variedad de entornos diferentes.

Microsoft usa un dialecto de IDL con objetos COM y el IDL de Microsoft no es lo mismo que el IDL CORBA, aunque hay similitudes ya que comparten raíces de idiomas comunes. El archivo IDL contiene la descripción de las interfaces admitidas por un objeto COM. COM permite la creación de servicios en proceso (puede usar RPC o llamadas directas a DLL) o servicios fuera de proceso (usa RPC). La idea detrás de COM es que el cliente solo necesita conocer el identificador del componente junto con la interfaz para poder usarlo. El cliente solicita el objeto COM y luego solicita un objeto de clase de la fábrica del objeto COM que admite la interfaz que el cliente desea usar y luego utiliza el objeto COM a través de esa interfaz.

Microsoft proporciona el compilador MIDL que procesa un archivo IDL para generar la biblioteca de tipos, que proporciona información a los usuarios del objeto COM sobre la interfaz y los apéndices necesarios para calcular los datos en la interfaz entre el cliente y el servicio.

El cálculo de los datos básicamente significa que el apéndice toma los datos proporcionados por el cliente, los empaqueta y los envía al servicio que realiza alguna acción y devuelve los datos. Este envío y recepción de datos puede realizarse a través de algún servicio RPC o mediante llamadas directas a funciones de DLL. La respuesta del servicio se traduce en una forma adecuada para el cliente y luego se proporciona al cliente. Básicamente, la funcionalidad de cálculo de referencias es un adaptador (ver el patrón de diseño del adaptador) o un puente (ver el patrón de diseño del puente) entre el cliente y el servicio.

Visual Studio, mi experiencia es con C ++, contiene una serie de asistentes que pueden usarse para generar un ejemplo para que pueda jugar con esto. Si está interesado, puede crear un espacio de trabajo y luego en el espacio de trabajo puede crear un proyecto ATL para generar un control y luego un proyecto de diálogo MFC simple para probarlo. El uso de ATL para su control COM esconde bastantes detalles que puede investigar más adelante y el simple proyecto de diálogo MFC proporciona una manera fácil de crear un contenedor. También puede usar la herramienta ActiveX Control Test Container, disponible en Visual Studio, para realizar pruebas preliminares y ver cómo funcionan los métodos y las propiedades.

También hay una serie de proyectos de ejemplo en sitios web como codeproject.com. Por ejemplo, aquí hay uno que usa C para exponer todas las tuberías feas detrás de COM y aquí hay uno que usa C ++ sin ATL .

IDL es vital en 2 casos. 1. Para crear dlls de proxy / stub para servidores exe. 2. Crear una biblioteca de tipos para servidores de automatización.

Hay un muy buen artículo para los conceptos básicos de IDL en el link

Para estudiar IDL, es mejor leer los propios archivos de encabezado idl de los compiladores, que incluyen el subdirectorio del paquete VC ++.

Se utiliza un lenguaje de definición de interfaz (IDL) para configurar las comunicaciones entre clientes y servidores en llamadas a procedimientos remotos (RPC). Ha habido muchas variaciones de esto, como Sun RPC, ONC RPC, DCE RPC y así sucesivamente.

Básicamente, usa una IDL para especificar la interfaz entre el cliente y el servidor, de modo que el mecanismo RPC pueda crear los códigos de código necesarios para llamar a las funciones en la red.

RPC necesita crear funciones de código auxiliar para el cliente y un servidor, utilizando la información IDL. Es muy similar a un prototipo de función en C, pero el resultado final es ligeramente diferente, como:

+----------------+ | Client | | +----------+ | +---------------+ | | main | | | Server | | |----------| | | +----------+ | | | stub_cli |------->| stub_svr | | | +----------+ | | |----------| | +----------------+ | | function | | | +----------+ | +---------------+

En este ejemplo, en lugar de llamar a la function en el mismo programa, main llama a una función de código auxiliar de cliente (con el mismo prototipo que la function ) que es responsable de empaquetar la información y enviarla a otro proceso. Esta puede ser la misma máquina o una máquina diferente, en realidad no importa, una de las ventajas de RPC es poder mover los servidores a voluntad.

En el servidor, hay un proceso de "escucha" que recibirá esa información y la pasará al servidor. El apéndice del servidor recibe la información, la desempaqueta y la pasa a la función real.

La función real hace lo que necesita y regresa al apéndice del servidor, que puede empaquetar la información de devolución (tanto el código de retorno como cualquier variable [out] o [in,out] ) y devolverla al stub del cliente.

El apéndice del cliente luego lo desempaqueta y lo pasa de nuevo a main .

Los detalles reales pueden diferir un poco, pero esa explicación debería ser lo suficientemente buena para una descripción conceptual.

El IDL real puede verse como:

[uuid(f9f6be21-fd32-5577-8f2d-0800132bd567), version(0), endpoint("ncadg_ip_udp:[1234]", "dds:[19]")] interface function_iface { [idempotent] void function( [in] int handle, [out] int *status ); }

Todo lo que hay en la parte superior es básicamente información de red, la parte de ella está dentro de la sección de interfaz donde se muestran los prototipos. Esto permite que el compilador IDL cree las funciones del servidor x stub y x para compilar y enlazar con su cliente y el código del servidor para que RPC funcione.

Microsoft usa IDL (creo que tienen un compilador MIDL) para cosas COM. También he usado productos de terceros con sistemas operativos MS, tanto DCE como ONC RPC.

También hay un lenguaje de datos interactivo que tenía un trabajo que utilizaba para el análisis de datos científicos, pero tal vez desde el contexto sea claro para usted que no es este IDL.