IDL ayuda al ORB a cumplir su papel. Un ORB es una capa de software que no puede recibir llamadas directas por un cliente a servicios de los servidores, ya que desconoce a los objetos servidores que se diseñarán a lo largo de su vida. El ORB solo puede proporcionar unos servicios genéricos del tipo llamar método ¿pero como averigua el nombre del método correspondiente en el servidor?, lo suyo sería poder hacer llamadas desde el cliente al servidor viendo sus métodos en el lenguaje propio del cliente. Con IDL se consiguen ambas cosas. Un compilador de IDL genera unas librerías especificas, por ejemplo DDLS, para los lenguajes de programación, que funcionan como vía de comunicación con el ORB. Las llamadas al servidor que se realizan desde el cliente se empaquetan por el stub y se convierten en llamadas genericas al ORB. Este se encarga de localizar el servidor, ya sea localmente o a través de una red. En la parte del servidor se habla de los IDL-Skeletons. Para pasar la llamada del cliente al servidor, el ORB llamaría a una capa intermedia (el object Adapter) y éste al IDL-Skeleton para acceder al método de la implementación del servidor. La idea es que el skeleton conoce el nombre del método que debe llamar, ya que fue generado junto con el servidor. Debe traducir por tanto la llamada genérica que recibe del object adapter a la llamada correcta al objeto servidor, aportando el object adapter unos servicios que ayudan a localizar el skeleton y objeto correcto. Delphi 4 soporta IDL y dos de los tipos de datos usados en CORBA (struct y union) IDL supone una revolución en el mundo cliente/servidor. Además del código generado por el compilador de IDL, se genera información sobre la interfaz accesible por todo el sistema que se almacena en una base de datos propia del ORB llamada Interface Repository, identificada en todo el sistema por el repository IDS con objeto de no crear inconsistencias al usar varios orbs de distintos fabricantes. Esta información es útil para poder generar llamadas dinámicas, llamadas en tiempo de ejecución. Para ello, un cliente consulta la información necesaria mediante unos servicios del Interface Repository y construye a partir de esta la llamada al servidor. CORBA provee para ello una interfaz especial llamada Dynamic Invocation Interface (DII) que el cliente puede usar para hacer la llamada dinámica tras haber obtenido la información necesaria para ello del repositorio, es decir, una referencia al objeto, función y parámetros. El equivalente de esto en la parte del servidor se conoce como Dynamic skeleton Interface(DSI) y es útil para permitir la asociación dinámica de la llamada a una función de un objeto servidor. La diferencia de prestaciones entre el Dynamico y estático es: El método estático es fácil de usar y rápido, mientras que el dinámico es más costoso en esfuerzo de programación y tiempo de ejecución pero a la vez mucho más flexible. Otro componente es el Object Adapter o adaptador de objetos. Su función principal consiste en generar e interpretar referencias a objetos, recibir las llamadas a un método de un objeto servidor que le llegan del ORB y pasarlas a través del IDL-Skeletoon o DSI al objeto correcto, activar/desactivar objetos y servicios de seguridad. Los OA pueden variar en los servicios que ofrecen en cada implementación de ORB especifica, pero todas deben soportar, al menos, la especificaión del Basic Object Adapter de CORBA que incluye los mencionados más un servicio mínimo de persistencia consistente en poder almacenar perfectamente una referencia de un objeto. Todo lo comentado anteriormente lo podemos ver reflejado en el siguiente cuadro: El módelo de comunicación de CORBA funciona en un principio de manera sincrona, un cliente que realiza una llamada debe esperar hasta que su petición se haya servido o surja un error. Sin embargo, existen otras modalidades, una se llama one-way-request y permite que el cliente no tenga que esperar, pero sujeta a la condición que no reciba resultados del servidor. Otra modalidad se conoce como deferred-synchronas-request, es decir, petición sincrona diferida. En este modo el cliente hace su petición, sigue ejecutandose y puede recoger más adelante los resultados de la llamada. Sus funciones son las siguientes: Los CORBA services u objectservices proporcionan una serie de servicios para el móldeado lógio y almacenamiento físico de objetos. Aquí entran el ciclo de vida, persistencia, eventos, dentificadores/denominación y transacciones robustas. La CORBAfacilies consiste en una serie de clases dedicadas a funciones genéricas para distintos tipos de aplicaciones y contienen servicios como soporte de GUIS, de impresión… Los CORBAdomains están dedicados a ámbitos, dominios especificos de aplicaciones como aplicaciones financieras, Cad,etc.. De momento están sin especificar pero serán básicamente marcos de trabajo especializados en los distintos dominios. Los Application object representan a los objetos de la aplicación en sí, es decir, los que diseña e implementa el desarrollador. Corba permite comunicar objetos distribuidos.