| Artículos | 01 SEP 1999

Personalizar Outlook para mejorar la comunicación interna en la empresa

Tags: Histórico
José M. Alarcón.
El OMG y la especificación CORBA cumplen una década de existencia. En este artículo le introducimos en una tecnología sólida y probada aunque poco conocida.

Para el grueso de los programadores, gran parte de los cuales se mueven en torno a Windows, las palabras CORBA y OMG suenan a algo nuevo, debido al reciente desarrollo de los entornos distribuidos. Lo cierto, sin embargo, es que CORBA existe casi desde antes que Windows y, por supuesto, desde antes que Internet fuese algo conocido. Ha sido no obstante la Red, concretamente el uso de sus protocolos en redes empresariales, lo que ha provocado el crecimiento de los entornos distribuidos y heterogéneos e, indirectamente, el uso de CORBA.
En estas nuevas redes conviven diferentes sistemas operativos, desde el omnipresente Windows hasta los sistemas mainframes, pasando por MacOS, Linux e innumerables versiones de Unix. Asimismo los desarrollos sobre esos sistemas utilizan diferentes lenguajes y herramientas, lo que complica aún más una posible colaboración entre ellas. El único hilo conductor que comunica aplicaciones y sistemas tan diferentes es un protocolo de transporte, conocido como IP, y algunos protocolos de conversación como TCP y UDP. A éstos se les llama genéricamente TCP/IP.
La presencia de ese hilo conductor, de TCP/IP, y la existencia de los elementos de CORBA en una treintena de sistemas diferentes es lo que hace posible crear aplicaciones distribuidas que se comunican entre sí saltando los muros que representan los sistemas y lenguajes. No importa, por lo tanto, la herramienta de desarrollo usada o el sistema operativo sobre el que se trabaje. CORBA es fácil de usar desde C++ y Java, los dos lenguajes a los que más se asocia, pero también desde Borland Delphi, COBOL o Visual Basic, por mencionar sólo los más conocidos.
CORBA es una arquitectura íntimamente ligada a las tecnologías de orientación a objetos, si bien es cierto que no es preciso un lenguaje de este tipo para aprovechar las posibilidades de CORBA. Estas aplicaciones no son construcciones monolíticas, sino más bien elementos discretos, los podemos llamar componentes, que se ejecutan distribuidamente sobre múltiples sistemas y se comunican entre sí mediante una infraestructura de red.
Si está interesado en conocer cuáles son los elementos fundamentales de esta arquitectura y quiere saber cómo se desarrollan aplicaciones CORBA siga leyendo. Este artículo le servirá para adquirir una visión global sobre técnicas que están llamadas a tener cada vez una mayor presencia en el ámbito de la informática empresarial.

Modelos de aplicaciones
Los departamentos de informática y empresas de desarrollo tienen que decidir, a la hora de planificar la creación de una nueva aplicación, cuál de los modelos posibles quieren utilizar. Actualmente los modelos existentes son básicamente tres: monolítico o tradicional, cliente/servidor y de múltiples capas o niveles. Cada uno de estos tiene, como cualquier otro elemento, sus ventajas y desventajas, que será preciso conocer para poder decidir.
Cualquier aplicación actual cuenta generalmente con tres partes bien diferenciadas: una interfaz de usuario, unas reglas de negocio y una gestión de datos. La interfaz de usuario es el elemento con el que interacciona el usuario de la aplicación, ejecutando acciones, introduciendo u obteniendo información. Las reglas de negocio son las que procesan la información para generar los resultados que se persiguen, siendo el elemento fundamental que diferencia a unas aplicaciones de otras. Por último está la gestión de datos, que se ocupa del almacenamiento y recuperación de la información en medios persistentes, habitualmente discos.
En una aplicación monolítica, representada en la Figura 1, las tres partes citadas forman un todo y se ejecutan en la misma máquina. Es la tradicional aplicación DOS/Windows que se encarga de solicitar/mostrar los datos, los procesa y, además, gestiona su almacenamiento/recuperación en archivos o bases de datos locales. Se trata de un modelo fácil de desarrollar, difícil de mantener, poco escalable y que precisa de una cierta potencia de proceso. Comparativamente hablando, instalar en cada puesto de operador de una empresa un sistema informático completo para ejecutar una aplicación sería como tener una centralita telefónica para cada trabajador, por el simple hecho de que necesita utilizar el teléfono. Resulta caro y los costes de mantenimiento son también altos.
El modelo cliente/servidor es el más usado en la actualidad. Una aplicación de este tipo, también conocida como aplicación en dos capas, separa la interfaz de usuario y reglas de negocio de la gestión de los datos, que queda en manos de un servidor que suele ejecutarse en una máquina dedicada. El equipo de desarrollo se centra en la creación de la interfaz con el usuario y el proceso de los datos, mientras que el almacenamiento y recuperación se deja en productos de tipos estándar: los habituales servidores de datos (Oracle, Informix, Interbase, SQL Server, etc.)
La aplicación es relativamente más compleja en el modelo cliente/servidor que en el monolítico. Ahora hay que comunicarse con un servidor de datos remoto pero, a cambio, muchos procesos que se realizaban localmente en la aplicación son ejecutados ahora por ese servidor, que es capaz de ofrecer resultados más elaborados. La potencia de proceso necesaria ahora se reparte, siendo precisos clientes más o menos rápidos para ejecutar las reglas de negocio y un potente servidor que sea capaz de atender las solicitudes de datos de todos esos clientes, tal y como se muestra en la Figura 2.

Aplicaciones en múltiples capas
Esta extraña pero aceptada denominación hace referencia a aplicaciones que se ejecutan de forma distribuida en varias máquinas, denominándose nivel o capa a cada una de las divisiones. Cuando la aplicación se divide en dos partes se habla de arquitectura cliente/servidor, mientras que al existir tres o más niveles las aplicaciones se denominan multicapa o multitier.
El caso más típico es el mostrado en la Figura 3, la aplicación en tres capas: un cliente que ejecuta la interfaz, un servidor de aplicaciones que procesa las reglas de negocio y un servidor de datos. Existe, no obstante, la posibilidad de aumentar el número de capas añadiendo nuevos servidores de aplicaciones y datos, de tal forma que la carga de trabajo se distribuya entre varias máquinas.
Un servidor de aplicaciones puede ser un servidor web que ejecuta programas ante determinadas solicitudes de los clientes. Los servidores más conocidos disponen de conjuntos de funciones, como ISAPI/NSAPI, que permiten esas construcciones. En este caso está claro que el cliente, que ejecuta la interfaz, sería una aplicación como Netscape Communicator, Internet Explorer o similar.
Alternativamente es posible utilizar tecnologías de objetos distribuidos, como DCOM, CORBA o Java RMI, que permiten ejecutar objetos remotos sin necesidad de tener un servidor web. En cualquier caso, siempre es preciso contar con unos servicios mínimos que permiten localizar los objetos, gestionar las llamadas entre clientes y servidor, etc. A éstos se les conoce habitualmente como middleware.
Desarrollar una aplicación en múltiples capas es una tarea más compleja, sobre todo si se compara con la construcción de un típico programa monolítico. A cambio, sin embargo, se obtienen muchos

Contenidos recomendados...

Comentar
Para comentar, es necesario iniciar sesión
Se muestran 0 comentarios
X

Uso de cookies

Esta web utiliza cookies técnicas, de personalización y análisis, propias y de terceros, para facilitarle la navegación de forma anónima y analizar estadísticas del uso de la web. Consideramos que si continúa navegando, acepta su uso. Obtener más información