Este equipo de especialistas luego de ciertos días de trabajo y de recopilar de datos, hallamos la solución, nuestro deseo es que resulte útil para ti en tu trabajo.
Solución:
Se utiliza un lenguaje de definición de interfaz (IDL) para configurar las comunicaciones entre clientes y servidores en llamadas a procedimiento remoto (RPC). Ha habido muchas variaciones de esto, como Sun RPC, ONC RPC, DCE RPC, etc.
Básicamente, utiliza un IDL para especificar la interfaz entre el cliente y el servidor para que el mecanismo RPC pueda crear los códigos auxiliares necesarios para llamar a 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 en el siguiente gráfico:
+----------------+
| Client |
| +----------+ | +---------------+
| | main | | | Server |
| |----------| | | +----------+ |
| | stub_cli |----(comms)--->| stub_svr | |
| +----------+ | | |----------| |
+----------------+ | | function | |
| +----------+ |
+---------------+
En este ejemplo, en lugar de llamar function en el mismo programa, main llama a una función de código auxiliar de cliente (con el mismo prototipo que function) que es responsable de empaquetar la información y llevarla a través del cable a otro proceso, a través del canal de comunicaciones.
Esta puede ser la misma máquina o una máquina diferente, realmente 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 stub del servidor recibe la información, la descomprime y la pasa a la función real.
La función real luego hace lo que necesita y regresa al stub del servidor que puede empaquetar la información de retorno (tanto el código de retorno como cualquier [out] o [in,out] variables) y devolverlo al stub del cliente.
El código auxiliar del cliente lo descomprime y lo devuelve a main.
Los detalles reales pueden diferir un poco, pero esa explicación debería ser lo suficientemente buena para una descripción general conceptual.
El IDL real puede verse así:
[ 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
);
Toda esa información en la parte superior (por ejemplo, uuid o endpoint) es básicamente información de red que se utiliza para conectar el cliente y el servidor. La “carne” está dentro de la sección de interfaz donde se muestra el prototipo. Esto permite al compilador IDL construir el function funciones de stub de cliente y servidor para compilar y vincular con su código de cliente y 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 existe el Lenguaje de datos interactivos que tenía un trabajo usando para el análisis de datos científicos, pero tal vez por el contexto le quede claro que eso no es lo que significa este IDL.
IDL es un acrónimo de Interface Definition Language, del cual existen 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 deseen utilizar el servicio sepan qué métodos y propiedades, la interfaz, el servicio proporciona. 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 componentes binarios, generalmente COTS o Commercial Off The Shelf, y la forma en que un cliente se comunica con el componente binario puede variar, aunque tradicionalmente se utiliza alguna versión de Remote Procedure Call o RPC. Dos de estos estándares son el estándar Microsoft Common Object Model o COM y el Common Object Request Broker o estándar CORBA. Existen otros estándares para componentes como complementos de Firefox o complementos para otras aplicaciones, como Visual Studio, sin embargo, estos no necesariamente usan algún tipo de lenguaje de descripción de interfaz utilizando en su lugar algún tipo de kit de desarrollo de software o SDK con interfaces estandarizadas y bien conocidas para una API.
Lo que permite un IDL es un mayor grado de flexibilidad para poder crear componentes que ofrecen servicios de diversa índole que, por su naturaleza binaria, se pueden utilizar 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 Microsoft IDL no es lo mismo que CORBA IDL, aunque hay similitudes ya que comparten raíces lingüísticas comunes. El archivo IDL contiene la descripción de las interfaces compatibles con un objeto COM. COM permite la creación de servicios en proceso (puede usar RPC o llamadas DLL directas) 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, luego solicita un objeto de clase de la fábrica del objeto COM que admite la interfaz que el cliente desea usar y luego usa 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, proporcionando información a los usuarios del objeto COM acerca de la interfaz y los apéndices necesarios para ordenar los datos a través de la interfaz entre el cliente y el servicio.
La clasificación de datos básicamente significa que el stub 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 DLL. La respuesta del servicio se traduce en un formulario adecuado para el cliente y luego se proporciona al cliente. Básicamente, la funcionalidad de clasificación es un adaptador (consulte el patrón de diseño del adaptador) o un puente (consulte 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 se pueden usar 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 oculta bastantes detalles que puede investigar más adelante y el proyecto de diálogo MFC simple proporciona una manera fácil de crear un contenedor. También puede utilizar la herramienta Contenedor de pruebas de control ActiveX, disponible en Visual Studio, para realizar pruebas preliminares y ver cómo funcionan los métodos y las propiedades.
También hay varios proyectos de ejemplo en sitios web como codeproject.com. Por ejemplo, aquí hay uno que usa C para exponer toda la desagradable plomería detrás de COM y aquí hay uno que usa C ++ sin ATL.
Recuerda que puedes dar recomendación a este tutorial si si solucionó tu problema.