Diseñando Aplicaciones Distribuidas

Enviado por csalazar

Resumen

En nuestros días el vertiginoso avance de la informática y las comunicaciones, con sus mayores exponentes Internet e Intranet, y la cada vez más creciente demanda de la empresa de aplicaciones de calidad que den solución a sus necesidades, ha hecho que las técnicas tradicionales de diseño e implementación de aplicaciones comiencen hacer insuficiente, por lo que un nuevo enfoque de desarrollo se hace necesario.

El presente trabajo tiene como objetivo principal lograr introducir al desarrollador en las nuevas técnicas de diseño de aplicaciones distribuidas, para ello hemos divido el estudio en dos partes. Una primera está orientada al estudio de los componentes software, y al entorno normalizado de desarrollo COM+. En la segunda describimos un diseño de aplicaciones distribuidas cliente/servidor concluyendo con la muestra de un ejemplo.

Palabras Claves: Componentes, distribuidas y aplicaciones.

Articulo de tipo : Académico

Componentes Software

¿Alguna vez ha pensado que un programa pudiera ser como… una bicicleta?. Si es necesario cambiar la cadena de la bicicleta, usted solo se centra en la cadena, no tiene que lidiar con otros componentes ajenos, como por ejemplo, las gomas o tan sencillo como el timbre, sino solo la cadena. Sabe con exactitud donde está el componente y puede modificarlo (engrasar) o actualizarlo (una nueva). Si ahora le dijera que pudiera hacer lo mismo con los software que usted desarrolla, ¿qué diría al respecto?.

El objetivo de la tecnología de componentes software es construir aplicaciones complejas mediante ensamblado de módulos (componentes) que han sido previamente diseñados por otras personas a fin de ser rehusados en múltiples aplicaciones. La ingeniería de programación que sigue esta estrategia de diseño se le conoce por el acrónimo CBSE1 y es actualmente una de las más prometedoras para incrementar la calidad del software, abreviar los tiempos de acceso al mercado y gestionar el continuo incremento de su complejidad.

La arquitectura software de una aplicación basada en componentes consiste en uno o un número pequeño de componentes específicos de la aplicación (que se diseñan específicamente para ella), que hacen uso de otros muchos componentes prefabricados que se ensamblan entre sí para proporcionar los servicios que se necesitan en la aplicación.

En la tecnología de componentes la interfaz constituye el elemento básico de interconectividad. Cada componente debe describir de forma completa las interfaces que ofrece, así como las interfaces que requiere para su operación. Y debe operar correctamente con independencia de los mecanismos internos que utilice para soportar la funcionalidad de la interfaz.

Características muy relevantes de la tecnología de programación basada en componentes son la modularidad, la rehusabilidad y componibilidad y en todos ellos coincide con la tecnología orientada a objetos de la que se puede considerar una evolución. Sin embargo, en la tecnología basada en componentes también se requiere robustez ya que los componentes han de operar en entornos mucho más heterogéneos y diversos.

El desarrollo de software basado componentes es la evolución natural de la ingeniería software para mejorar la calidad, disminuir los tiempos de desarrollo y gestionar la creciente complejidad de los sistemas.

Entornos normalizados de desarrollo de componentes software.

Para que una arquitectura de componentes pueda operar es necesario disponer de un entorno normalizado que proporcione soporte a los mecanismos con que se comunican las interfaces.

COM (Component Object Model).

Los lenguajes de programación clásicos fueron diseñados para desarrollar aplicaciones secuenciales compuestas de módulos, todos ellos codificados con un solo lenguaje. Sin embargo, hay situaciones en las que no es práctico restringirse al uso de un único lenguaje. La tecnología COM aborda la solución a este problema proporcionando un sencillo, pero a la vez potente modelo para construir sistemas software a partir de la interacción de objetos (componentes).

COM define un estándar binario (esto implica que es independiente del lenguaje de programación) para objetos y la intercomunicación entre ellos. Toda comunicación se realiza a través de operaciones que son proporcionadas dentro de interfaces. El diseñador invoca las operaciones que necesita directamente, incluso si el objeto destinatario está localizado en otro proceso o en otra máquina.

El modelo de programación COM esta basado en la distribución de código de clases en componentes binarios. Esto significa que el software (componentes) que se adhiere a COM, puede ser rehusado sin ninguna dependencia de código fuente. Los desarrolladores pueden exponer sus trabajos como ficheros binarios sin dar a conocer sus algoritmos.

El desarrollo basado en componentes resuelve muchos de los problemas asociados con las aplicaciones monolíticas. Permite al grupo de desarrollo exponer ficheros binarios en vez de código fuente. Los componentes binarios pueden ser actualizados independientemente y reemplazados, lo que se hace mucho más fácil mantener y extender una aplicación después de que esta ha sido puesta en explotación.

MTS (Microsoft Transaction Server).

MTS es una pieza de software que fue creada para Windows NT Server. Como su nombre implica, MTS permite a los objetos de la capa media (más adelante se expone una arquitectura de diseño) correr sobre Windows NT Server y controlar las transacciones distribuidas, es decir, permite a los componentes ser esparcidos por la red y que se ejecuten en otras computadoras con sistema operativo Windows NT Server. MTS provee un entorno de ejecución para objetos COM, adicionando soporte para la seguridad, soporte para administración y configuración. Es posible administrar varios servidores desde una simple computadora.

COM+

COM+1, no es más que la integración de la arquitectura COM y MTS (Microsoft Transation Server). A diferencia de MTS, esta nueva capa de ejecución no es opcional2 , COM+ es parte por defecto de la instalación del sistema operativo Windows 2000.

Como COM, COM+, es basado sobre componentes binarios y programación basada en interfaces. Los Componentes COM+ pueden ser actualizados y extendidos una vez que estén en explotación sin afectar a las aplicaciones clientes que los usan en la producción.

De este modo, la combinación de la tecnología COM+ junto con las técnicas de programación orientada a objeto, nos ofrece una importante simplificación en el proceso de desarrollo de aplicaciones informáticas.

Diseñando Aplicaciones Distribuidas.

El diseño de aplicaciones modernas involucra la división de una aplicación en múltiples capas; la interfase de usuario, la capa media de objetos de negocios, y la capa de acceso a datos. Puede ser útil identificar los tipos de procesamiento que podemos esperar que una aplicación realice. Muchas aplicaciones pueden, al menos, hacer lo siguiente:

Cálculos u otros procesos de negocios.
Ejecución de reglas de negocios.
Validación de datos relacionados al negocio.
Manipulación de datos.
Ejecución de las reglas de datos relacional.
Interactuar con aplicaciones externas o servicios.
Interactuar con otros usuarios.

Nosotros podemos tomar estos tipos de servicios y generalizarlos dentro de los tres grupos o capas que a continuación se resumen:

Interfase de usuario (Capa de Presentación)
- Interactuar con otros usuarios.
- Interactuar con aplicaciones externas o servicios.
Procesos de negocios (Capa de Negocios)
- Cálculos u otros procesos de negocios.
- Ejecución de reglas de negocios.
- Validación de datos relacionados al negocio.
Procesos de datos (Capa de Servicios de Datos).
- Manipulación de datos.
- Ejecución de las reglas de datos relacional.

La división de estos procesos de aplicaciones y su distribución entre diferentes procesos cliente/servidor es conocido como Procesamiento Distribuido. Generalizando estos procesos dentro de estas tres categorías o capas es una distribución lógica y no refleja necesariamente alguna opción de diseño físico sobre computadoras, terminales u otros equipos. Usted puede desarrollar una aplicación cliente/servidor distribuida basada sobre estas tres capas de Presentación, Lógica de Negocios y Servicios de Datos y tener la aplicación entera corriendo sobre una simple computadora. Alternativamente, usted puede esparcir estas tres capas a través de un gran número de diferentes computadoras sobre una red. De cualquier forma usted ha desarrollado una aplicación cliente/servidor de tres capas.

Capa de Presentación.

La capa de Presentación provee su aplicación con una interfase de usuario(IU). Aquí es donde su aplicación presenta información a los usuarios y acepta entradas o respuestas del usuario para usar por su programa. Idealmente, la IU no desarrolla ningún procesamiento de negocios o reglas de validación de negocios. Por el contrario, la IU debería relegar sobre la capa de negocios para manipular estos asuntos. Esto es importante, especialmente hoy en día, debido a que es muy común para una aplicación tener múltiples IU, o para sus clientes o usuarios, que le solicitan que elimine una IU y la remplace con otra. Por ejemplo, usted puede desarrollar una aplicación Win32 (un programa en Visual Basic) y entonces solicitársele remplazarla con una página HTLM., quizás usando tecnología ASP.

Una de las mayores dificultades y factores importantes cuando desarrollamos aplicaciones cliente/servidor es mantener una separación completa entre la presentación, la lógica de negocios y los servicios de datos. Es muy tentador para los desarrolladores mezclar una o más capas; poniendo alguna validación u otro proceso de negocios dentro de la capa de presentación en vez de en la capa de negocios.

Capa de Negocios.

Toda aplicación tiene código para implementar reglas de negocios, procesos relacionados a los datos o cálculos y otras actividades relativas a los negocios. Colectivamente este código es considerado para formar la capa de negocios. Otra vez, uno de los principios del diseño lógico cliente/servidor, la lógica de negocios debe mantenerse separada de la capa de presentación y de los servicios de datos. Esto no significa necesariamente que la lógica de negocios está en cualquier parte, por el contrario, esta separación es en un sentido lógico.

Hay muchas formas de separar la lógica de negocios. En términos orientados a objetos, usted debería encapsular la lógica de negocios en un conjunto de objetos o componentes que no contienen presentación o código de servicios de datos. Teniendo separada lógicamente su lógica de negocios de ambas, la capa de presentación y servicios de datos, usted ganará en flexibilidad en término de donde usted puede almacenar físicamente la lógica de negocios. Por ejemplo, usted puede seleccionar almacenar la lógica de negocios sobre cada estación de cliente, u optar por ejecutar la lógica de negocios sobre un servidor de aplicaciones, permitiendo a todos los clientes acceder a un recurso centralizado.

Los objetos de negocios son diseñados para reflejar o representar sus negocios. Ellos se convierten en un modelo de sus entidades de negocios e interrelaciones. Esto incluye tanto objetos físicos como conceptos abstractos. Estos son algunos ejemplos de objetos del mundo real: un empleado, un cliente, un producto, una orden de compra.

Todos estos son objetos en el mundo físico, y la idea en su totalidad detrás de usar objetos de negocios de software, es crear una representación de los mismos objetos dentro de su aplicación. Sus aplicaciones pueden hacer que estos objetos interactúen unos con otros como ellos lo hacen en el mundo real. Por ejemplo, un empleado puede crear una orden de compra a un cliente que contiene una lista de productos. Siguiendo esta lógica usted puede crear objetos de negocios de una orden conteniendo el código necesario para administrarse a si mismo, así usted nunca necesitará replicar código para crear ordenes, usted solo usará el objeto. Similarmente, un objeto cliente contiene y administra sus propios datos. Un buen diseño de un objeto cliente contiene todos los datos y rutinas necesitadas para representarlo a través del negocio completo, y puede ser usado a través de toda la aplicación de ese negocio.

No toda la lógica de negocio es la misma. Alguna lógica de negocio es un proceso intensivo de datos, requiriendo un eficiente y rápido acceso a la base de datos. Otras no requieren un frecuente acceso a los datos, pero es de uso frecuente por una interfase de usuario robusta para la validación en la entrada de campos u otras interacciones de usuarios. Si nosotros necesitamos una validación al nivel de pantallas y quizás cálculos en tiempos real u otra lógica de negocios, pudiéramos considerar este tipo de lógica de negocios para ser parte de la IU, ya que en su mayor parte es usada por la interfase de usuario.

Una alternativa de solución es dividir la capa de lógica de negocios en dos:

Objetos de negocios de la IU.
Objetos de negocios de datos.

Un ejemplo del objeto Empleado de la capa objetos de negocios de la IU proveerá propiedades y métodos para usar por el diseñador de la interfase de usuario. Ejemplo de propiedades y métodos pudieran ser: IDEmpleado, Nombre, Dirección, etc., y como métodos crear una de compra, etc. El objeto Empleado de la capa de objetos de negocios de datos será responsable de los mecanismos de persistencias, interactuar con la base de datos. Los objetos de esta capa son considerados sin estado, solo poseen métodos.

Capa de Servicios de Datos.

Muchas aplicaciones interactúan con datos, los almacenan en alguna forma de bases de datos. Hay algunas funciones básicas que son comunes a todos los procesos. Estas incluyen:

Crear datos,
leer datos,
actualizar datos y
eliminar datos.

Adicionalmente, nosotros tenemos servicios más avanzados disponibles, tales como: búsquedas, ordenamientos, filtrados, etc.

Ejemplo de Aplicación Cliente/Servidor.

Especificaciones Técnicas.

Nuestro ejemplo fue desarrollado con Microsoft Visual Basic 6.0 y la base de datos fue elaborada en Microsoft Access 2000. El mismo carece de complejidad, la única intención ha sido la de mostrar como se desarrolla una aplicación cliente/servidor empleando un diseño distribuido. Es suficiente con una sola estación de trabajo que tenga instalado el sistema operativo Microsoft Windows 2000 para su ejecución, aunque pudiera esparcirse por varias computadoras en una red.

Descripción.

La aplicación cuenta con una simple interfase como se muestra en la siguiente figura:

Permitiendo dos funciones básicas la de crear nuevos empleados y borrar, tal como se muestran en las figuras siguientes:

Figure 1 Borrar un empleado

Figure 2 Adicionar un empleado

La aplicación cuenta con una simple interfase permitiendo dos funciones básicas la de crear nuevos empleados y borrar.

Para un mayor control de la aplicación se le ha incorporado a la capa de negocios la seguridad a través de un objeto Session. Esto permite aislar al desarrollador de la interfase de usuario de esta responsabilidad. De esta forma logramos una mayor autonomía de la capa de negocios.

Cuando se pretende acceder al objeto de negocio Employee, este chequeara si el objeto Session ya ha sido creado, de no estarlo automáticamente lanzara una ventana de autenticación para la creación del objeto, por lo que al destruirse el objeto Employee se destruirá automáticamente el objeto Session. Por lo que hemos creado este objeto Session justamente al inicio de la aplicación, limitando el acceso a usuarios no deseados.

El objeto Session puede crearse a través del siguiente segmento de código al comenzar la aplicación en un módulo de código:

Set Session = New SecurityObject.Session

Una vez ejecutada la sentencia anterior se mostraría la siguiente ventana:

Figure 1 Ventana de autenticación

Diagrama de clases

Diagrama de Componentes

Conclusiones.

La adopción de un diseño distribuido de aplicaciones empresariales, aumenta la reusabilidad, reduce la cantidad de recursos, y los costes necesarios de desarrollo y mantenimiento.

Este nuevo enfoque de diseño pone en manos de los desarrolladores no solo la funcionalidad que demandan las aplicaciones, sino también la seguridad, rapidez y flexibilidad.

Bibliografía

MSDN Library – January 2001.
- COM+ Overview for Microsoft Visual Basic Programmers.
Rebecca M. Riordan. Designing Relational Database Systems. ISBN 0-7356-0634-X.
Rockford Lhotka. Visual Basic 6 Business Objects, Enterprise Design e Implementation. ISBN 1-861001-4-01.
Ted Pattison. Programming Distributed Applications with COM+ and Visual Basic 6.0, Second Edition. ISBN 0-7356-1010-X.
David A. Solomon, Mark Russinovich. Inside Microsoft Windows 2000. ISBN 0-7356-1021-5
Guy Eddon, Henry Eddon. Inside COM+ Base Services ISBN 0-7356-0728-1

Autor:

MsC. Caridad Salazar Alea.

MsC. Antonio Cortina Rodríguez.

Institución: Universidad de Pinar del Río "Hnos Saíz Montes de Oca".

País: Cuba