2.

MARCO DE REFERENCIA PARA EL DESARROLLO DE APLICACIONES DISTRIBUIDAS.

La forma como se desarrollan las aplicaciones actuales y las herramientas empleadas, son inapropiadas en un contexto en el que aparecen grupos de trabajo con autonoma y capacidad de decisin, que requieren del soporte de aplicaciones distribuidas. El paradigma actual debe incorporar nuevas tcnicas y metodologas que permitirn desarrollar mejores aplicaciones, independientemente de que stas sean distribuidas o centralizadas. Las mejoras perseguidas en las aplicaciones hacen referencia a la facilidad de diseo e implementacin, a la facilidad de adaptacin a nuevas necesidades, a la facilidad de uso y a la capacidad de las mismas para operar en entornos heterogneos. Para desarrollar mejores aplicaciones es fundamental considerar las diferencias entre diseo fsico y diseo lgico. Mientras que el primero hace referencia a los elementos de implementacin (como hardware, software y de Bases de Datos), el segundo se relaciona con la estructura de la aplicacin. Un buen diseo lgico es el comienzo para la obtencin de mejores aplicaciones. Los modelos arquitectnicos, que han sido empleados por siglos en la construccin de edificios, pueden ser adaptados para el caso de las aplicaciones software, definiendo un nuevo marco de referencia para los procesos de diseo e implementacin de aplicaciones, conocido como Arquitectura de Aplicaciones.

2.1

ARQUITECTURA DE APLICACIONES

Al igual que la construccin de edificios, en la construccin de aplicaciones se distinguen tres fases de desarrollo. Arquitectura. En donde se desarrollan planos de la estructura completa, se decide sobre la apariencia externa, se especifica el carcter del producto final y se proyecta la manera como se dar cumplimiento a unos requerimientos previamente establecidos. El primer paso en el proceso de diseo es el entendimiento de lo que la aplicacin debe hacer, esto permite establecer cules son las funciones que deber cumplir la aplicacin; una vez establecidas, se procede a determinar cul es la mejor estructura para la aplicacin. Ingeniera. En donde se disean las estructuras fsicas internas para soportar la forma general y la funcionalidad establecidas en el proceso de arquitectura. En esta fase se consideran aspectos de consistencia, eficiencia y costos de implementacin. Construccin. En donde se implementa las estructuras fsicas diseadas, empleando herramientas y materiales apropiados. Las aplicaciones simples pueden realizarse completamente en un computador de escritorio, pero en las aplicaciones medianas y grandes suelen identificarse dos capas, una correspondiente a la interface y otra correspondiente a la Base de Datos que se ejecuta en un servidor; esta es la razn por la cual siempre se ha identificado al mainframe como la Base de Datos. Sin embargo el mainframe y los grandes servidores son mucho ms que grandes Bases de Datos, ellos tambin ejecutan el cdigo de las reglas de procesamiento (generado por las herramientas CASE o escrito en un lenguaje de programacin). El problema de la arquitectura tradicionalmente empleada en la cocepcin de las aplicaciones medianas y grandes radica en que no se provee un espacio explcito para las reglas de procesamiento y para los procesos computacionales, sino que ellos se confunden bien sea en la capa de la interface o en la capa del manejo de la Base de Datos.
pag. 40

2.2

ARQUITECTURA DE APLICACIONES PROPUESTA.

Es necesario incluir una nueva capa que permita la construccin de aplicaciones distribuidas y de mejores aplicaciones centralizadas. La capa incluida (ubicada entre las capas tradicionales), es la capa para los procesos computacionales, que tendr sus propias caractersticas y responsabilidades. En la Tabla 2-1 se presenta un resumen de las capas propuestas con sus respectivas responsabilidades y funciones, acompaadas de las herramientas empleadas en su concepcin. Tabla 2-1. Funciones de las Capas de la Arquitectura de las Aplicaciones Cliente/Servidor Capa Responsabilidad Funciones Herramientas Herramientas lenguajes grficos y

entendible y Presentacin Navegacin Manipulacin Posibilidad de Anlisis Reglas de Polticas y reglas de Toma de decisiones procesamiento procesamiento de la Cumplimiento de empresa polticas Coordinacin de recursos Manejo de Consistencia y seguridad Consistencia Datos en el manejo de los Seguridad datos. Integridad

Aplicaciones Interface de Escritorio eficiente

C Cobol Procesador de reglas de negocios Base de Relacionales. SQL Datos

pag. 41

2.2.1 Aplicaciones de Escritorio. La capa de las aplicaciones de escritorio proveen la interface del usuario con todo el sistema. La capa realiza las funciones de presentacin, navegacin, y anlisis para la toma de decisiones; permite a los usuarios no slo introducir datos, sino tambin manejarlos empleando herramientas de productividad personal (procesadores de palabra, hojas electrnicas) antes de ingresarlos. Se emplean lenguajes y herramientas grficas (Smalltalk, Visual Basic, Excel, Paradox, Acces).

2.2.2 Capa de las Reglas de procesamiento. La capa de las reglas de procesamiento implementa las reglas de los negocios, las polticas de la organizacin (heurstica) y las consideraciones sobre la administracin de los recursos existentes. Las herramientas empleadas son los lenguajes para el procesamiento y realizacin de clculos, como COBOL, C, o el cdigo generado por las herramientas CASE con base en las reglas de procesamiento.

2.2.3 Capa de los Datos. La capa de los datos es la responsable de mantener la consistencia y seguridad (procedimientos de Backup, la redundancia de la informacin importante y el establecimiento de polticas de acceso a la informacin) sin perder las propiedades de un buen desempeo. En esta capa se requieren herramientas para el diseo de Bases de Datos y conjunto completo para la definicin de los objetos de la Base de Datos y la operacin sobre ellos (Sublenguajes de datos como SQL). La arquitectura propuesta de tres capas es de carcter lgico, con ella se persigue tener una impresin completa acerca de la estructura de la aplicacin, en este propsito los aspectos fsicos no tienen consideracin directa. La arquitectura de aplicaciones no est asociada a alguna implementacin fsica particular, por el contrario es aplicable en diferentes configuraciones (sistemas basados en mainframe y
pag. 42

terminales; sistemas que emplean tres capas fsicas -mainframe, servidores, equipos de escritorios-; sistemas distribuidos basados en LAN, etc). En el caso de la computacin centralizada (tiempo compartido de CPU), las tres capas son ejecutadas por el mainframe. En el procesamiento corporativo, para el desempeo de los equipos auto-regulados con autonoma, es necesario mover algunas reglas de procesamiento de negocios a servidores locales. La compaa continua teniendo un control centralizado sobre una Base de Datos ubicada en el mainframe, en el que se ejecutan tambin los restantes procesos de negocios. En los sistemas distribuidos, el mainframe comienza a desaparecer hasta llegar a una arquitectura fsica con dos capas (servidores y computadores personales), pero con una arquitectura lgica conservada de tres niveles. La arquitectura de tres niveles seguir siendo vlida sin importar las decisiones sobre la configuracin fsica (es decir, en forma independiente del nmero de capas fsicas de computadores). Las aplicaciones diseadas efectivamente (basadas en la arquitectura lgica de 3 capas) pueden ser fcilmente distribuidas; las aplicaciones mal diseadas no pueden distribuirse. La decisin sobre dnde se implementarn las capas definidas o sobre dnde irn los componentes es un aspecto secundario.

2.3

BENEFICIOS DE LA ARQUITECTURA DE APLICACIONES

La Arquitectura de Aplicaciones en tres niveles ofrece, entre otros, los siguientes beneficios: Un marco de referencia para la construccin de aplicaciones flexibles (fcilmente modificables).
pag. 43

Construccin de software re-usable Construccin de aplicaciones complejas en ambientes transaccionales y de soporte a las decisiones.

Posibilidad de desarrollar aplicaciones distribuidas.

Aunque es difcil precisar el porqu, las aplicaciones grandes son significativa y cualitativamente diferentes de las aplicaciones pequeas (que podran desarrollarse con herramientas que obviaran el empleo de alguna metodologa). Generalmente los grandes sistemas son complejos, difciles de desarrollar y difciles de mantener. La Arquitectura de Aplicaciones permite dividir grandes sistemas en partes manejables; esta divisin se consigue empleando dos mecanismos: La abstraccin y la encapsulacin. La abstraccin es una descripcin que identifica las propiedades principales de un objeto mientras esconde sus detalles (que en el momento son innecesarios). Un principio de los sistemas bien diseados es el establecimiento de diferentes niveles de abstraccin. La abstraccin ser mayor en los niveles superiores. Una arquitectura basada en la abstraccin debe tener capas e interfaces entre ellas claramente definidas. Cada nivel se soporta en los servicios ofrecidos por la capa inferior, a los que puede invocar de acuerdo con lo que se especifica en su interface. Los beneficios de la abstraccin son aplicables a la arquitectura de las aplicaciones de tres niveles. Por ejemplo: Las reglas de procesamiento estn conceptualmente aisladas de la capa que hace el manejo de la Base de Datos. El nivel ms alto de abstraccin lo constituye la capa de las aplicaciones de escritorio, esta es la parte visible a los usuarios. Para entender la arquitectura de aplicaciones en tres niveles, es importante conocer las interfaces entre las capas. Las interfaces definen la apariencia externa y el comportamiento frente a las llamadas de un componente arquitectural. Las interfaces informan a un componente arquitectural qu debe hacer, permite conocer el estado del componente y recibe los resultados de una solicitud previa.

pag. 44

En la arquitectura de aplicaciones se identifican diferentes tipos de Interfaces: Interface grfica de usuario Interface de requerimiento de proceso Interface del manejador de consultas y transacciones.

Una capa puede estar conformada por varios componentes, cada uno ellos debe especificar cmo es su interface. Esta le permite comunicarse con otros componentes (de la misma o de diferente capa). Histricamente en un programa se mezclan aspectos de la interface de usuario, de las reglas de procesamiento y de la capa de la Base de Datos. Sin embargo, para el diseo de las capas de la Arquitectura de la Aplicacin, se debe considerar la Independencia como caracterstica bsica (ninguna capa ejecuta funciones que son responsabilidad de las alguna de las restantes capas). El diseo de la capa de aplicaciones de escritorio se har en forma independiente de las reglas de procesamiento; a su vez, la capa intermedia se disear independientemente de la capa de escritorio o de la capa de la Base de Datos. Es frecuente que se haga el diseo de la Base de Datos reflejando aspectos de las polticas y/o reglas de procesamiento. Esto acarrea problemas de consistencia a largo plazo, debido a que al cambiar las reglas o las polticas, la Base de Datos quedar con una estructura inadecuada. El diseo de la Base de Datos debe hacerse con una visin futurista, de manera que sea independiente de la reglas de procesamiento y de los posibles cambios en las mismas. Para lograr un buen diseo de la Base de Datos es necesario emplear un modelo de datos cuidadosamente planeado (modelo E-R, modelo Relacional o una combinacin de los dos); se deben planear las consultas y transacciones de manera que el acceso y la modificacin se ejecuten en forma confiable, observando las reglas de consistencia.

pag. 45

En otros casos, en las aplicaciones corrientes basadas en la arquitectura tradicional, es frecuente la duplicacin de esfuerzo o duplicacin de software, debido principalmente a la falta de modularidad y a la imposibilidad de diferenciar claramente las funciones de manejo de los datos de proceso y de presentacin. As, un cambio en la interface de la aplicacin, o un cambio de un manejador de Base de Datos por otro que ofrezca mejores prestaciones, fcilmente implica la re-escritura casi total de la aplicacin. La solucin es dividir las reglas de procesamiento en unidades modulares, interoperables y re-usables (capaces de realizar un trabajo de manera compartida y coordinada). El papel principal del mainframe en la computacin centralizada estuvo y est directamente relacionado con al ejecucin de los procesos de negocios automatizados. La inflexibilidad de algunas aplicaciones centralizadas est al rededor de la implementacin de las reglas de procesamiento (pocas veces es debida a las capas de las aplicaciones de escritorio o de la Base de Datos). La Reingeniera de Procesos de negocios busca construir una infraestructura que permita que las reglas de la organizacin sean mucho ms flexibles y adaptables a condiciones locales sin que se deje de cumplir la parte esencial de las polticas de la organizacin. El problema con el mainframe, es que su uso obliga a que la organizacin se desenvuelva dentro de una implementacin centralizada de las reglas de los negocios, en la que estn restringidas las adecuaciones a condiciones especficas de una localidad. La solucin es el empleo de servidores que permitan a los individuos o a los equipos extender o adecuar las reglas de la organizacin (Distribucin de procesos). Complementariamente, una Base de Datos podra distribuirse buscando beneficios (que han sido comprobados en casos reales), tales como confiabilidad, desempeo y costo. Las transacciones podran distribuirse de forma segura y automtica sobre sistemas no slo de muchos computadores, sino a lo largo de sitios dispersos geogrficamente, con el propsito de cumplir las reglas y polticas de la organizacin. A pesar de las expectativas en torno a los sistemas distribuidos, en el panorama actual es difcil encontrar estrategias y metodologas que faciliten su diseo e implementacin, quiz
pag. 46

porque el enfoque del diseo de las aplicaciones est sobre las tareas antes que sobre los procesos.

2.4

METODOLOGA (PARADIGMAS ACTUALES)

Es universalmente aceptado que el empleo de una metodologa proporciona un marco de referencia apropiado para interpretar medir y controlar el avance del proyecto, sobre todo en aquellos casos donde los desarrollos son de mediana y gran escala. Adicionalmente las metodologas ayudan a desarrollar aplicaciones consistentes, gracias a la provisin de herramientas que ayudan a interpretar y direccionar los requerimientos de una mejor manera. Una metodologa involucra en su parte principal una Arquitectura de Aplicaciones, a partir de la cual se establece una serie de etapas (fases de desarrollo) y se define la estructura organizacional ms apropiada, de manera que los equipos establecidos trabajen de manera coordinada. Para el desarrollo de aplicaciones distribuidas -o simplemente para el desarrollo de mejores aplicaciones- la orientacin de la metodologa debe hacerse sobre los procesos y no sobre las tareas, posibilitando la aplicacin de tcnicas de Reingeniera de procesos. Infortunadamente las metodologas actuales adolecen de ciertas limitantes que dificultan su aplicacin en el desarrollo de aplicaciones distribuidas. La Ingeniera de la Informacin introducida a comienzo de los ochenta es la base para las metodologa ms comunes de hoy. La ingeniera de la Informacin propone un desarrollo de aplicaciones por etapas, basadas en un plan inicial (llamado Plan del sistema de Informacin estratgica) en el que se consideran primeramente los aspectos relacionados con la informacin mediante un modelo de datos, a partir del cual se realiza un modelaje funcional. El Plan del Sistema de la Informacin es un documento estratgico de alto nivel y amplio cubrimiento, que provee un panorama general de la estructura de las aplicaciones y que
pag. 47

incluye tambin aspectos clsicos de planeacin como factores crticos, estructuras de organizacin, etc. Con base en el Plan del Sistema de Informacin se procede a dividir las grandes aplicaciones identificadas inicialmente en un nmero de aplicaciones ms especficas; la divisin se hace tomando como base la organizacin de la institucin, o por la afinidad en la utilizacin. Esta etapa es conocida como Anlisis de las reas de negocios. Luego de establecer prioridades, cada rea se analiza detalladamente con el objeto de proveer un modelo ms definido de la Base de Datos y de las funciones requeridas. Posteriormente, las aplicaciones se disean (en una etapa conocida como Diseo del Sistema) y por ltimo se implementan (Construccin del Sistema). La esencia de esta metodologa es el desarrollo gradual e integrado de aplicaciones basado en un plan inicial (desarrollos top/down). La metodologa propuesta por la Ingeniera de Informacin tambin incluye el empleo de un conjunto de modelos y estrategias de diseo de aplicaciones. Las metodologas corrientemente empleadas presentan dos caractersticas que necesitan ser revisadas. La primera soportada en razones histricas, puesto que las Bases de Datos han servido de sustento para el funcionamiento de las grandes organizaciones, hace referencia a la centralizacin sobre el modelo de la Base de Datos de las actividades de planeacin y diseo de las aplicaciones. Este hecho hace que se reflejen los problemas particulares del modelaje de la Base de Datos en todo el proceso de desarrollo de las aplicaciones. El punto de partida (que es el modelo de datos corporativo) puede ser excesivamente complejo y difcil de establecer. Pero sobre estas consideraciones, es claro que el modelo de datos es importante, pero no suficiente para el desarrollo de aplicaciones consistentes, ms an cuando se trata de aplicaciones distribuidas. La segunda caracterstica hace referencia a que la parte funcional es extremadamente orientada a las tareas, dificultando la adopcin de las tcnicas de Reingeniera de Procesos. Sobre la parte funcional, se ha empleado la tcnica de descomposicin, que pretende la divisin de grandes procesos en tareas pequeas que pueden implementarse fcil y
pag. 48

directamente (de manera similar a la descomposicin funcional de las lneas de produccin en masa). Esta caracterstica marc a las aplicaciones desarrolladas en las dcadas pasadas. El primer paso hacia un nuevo estilo de desarrollo de aplicaciones fue la inclusin de la Reingeniera de procesos; con el apoyo de las herramientas para la representacin grfica (como los diagramas de procesos, que son de fcil entendimiento), el movimiento de Reingeniera permiten volcar la atencin hacia los procesos, de manera que se consideren como el centro de las actividades de planeacin y diseo de las aplicaciones, o ms precisamente, como el principal de los focos (puesto que el modelo de datos contina siendo importante). En este nuevo paradigma, no es el personal tcnico el que a partir del modelo de datos define el Plan del Sistema de Informacin, sino que es el personal con perfil gerencial (ejecutivo) basados en los resultado de la Reingeniera de Procesos (y apoyado en el personal tcnico), quien define el Plan. El modelo de datos sigue siendo importante, y se desarrolla en paralelo, pero este es de la exclusiva competencia del personal tcnico. Las estrategias de diseo e implementacin de las Bases de Datos distribuidas son difciles de encontrar bajo el diseo centralizado en los datos y los modelos corrientemente empleados. En primer lugar, no es posible convertir de una manera directa un esquema de datos centralizado en uno distribuido, debido a que la base centralizada se concibi con un modelo inapropiado para un entorno distribuido. Adicionalmente, los modelos de datos centralizados no llevan indicaciones sobre las ubicaciones fsicas de los mismos; por encima de la solucin a la limitacin anterior est la cuestin acerca de como hacer una distribucin. Para dar solucin a los nuevos requerimientos es necesario, en primer lugar, considerar en la actividades de planeacin y diseo un modelo basado tanto en los procesos como en los datos; y seguidamente determinar el movimiento de las tareas desde el centro de una organizacin hacia las localidades donde estn los grupos o equipos de trabajo, de manera que ellos sean responsables por los procesos que se les han asignados. La distribucin de datos ser una consecuencia de la distribucin de procesos; los datos debern moverse hacia cada servidor que ejecuta un proceso.

pag. 49

2.5

METODOLOGA CLIENTE/SERVIDOR

Las metodologas corrientes (generalmente basadas en la Ingeniera de Informacin) y todo el entorno establecido a su al rededor (entrenamiento, herramientas CASE, equipos de consultores, etc), deben cambiar o ser reemplazadas en su totalidad, pensando en la consecucin de sistemas distribuidos. El hecho de que herramientas como Acces y Power Builder, permitan desarrollar aplicaciones pequeas y de tamao medio en algunas semanas, partiendo de un diseo preliminar (modelos de datos y procesos elementales) podra interpretarse equivocadamente, asumiendo que para el desarrollo de aplicaciones distribuidas no se necesita de un marco metodolgico; sin embargo por norma, los sistemas crecern en complejidad cuando se expanden (por ejemplo para incluir un nuevo servidor geogrficamente distribuido); y los sistemas mayores (medianos y grandes) y en especial los sistemas Cliente/Servidor son cualitativamente diferentes los pequeos sistemas, haciendo imperiosa la adopcin de una metodologa de desarrollo. El grupo de desarrollo central ya no construye las aplicaciones en su totalidad, en su lugar debe proveer los aspectos esenciales de las reglas de procesamiento, la estructura fundamental de la Base de Datos, los elementos comunes de las interfaces, y en general toda la infraestructura necesaria; para que los equipos de trabajo auto-regulados (si poseen los conocimientos y el entrenamiento necesarios), puedan sobre esa base, desarrollar o adaptar las aplicaciones a sus propias necesidades. Las metodologas clsicas adolecen de serios problemas que se reflejan en las aplicaciones que ellas producen, que por lo general son monolticas (difcil de separar en piezas constitutivas y difcil de mantener, puesto que un cambio sobre una parte del sistema afecta impredeciblemente a otra), centralizadas y difciles de usar. En el corazn de las metodologas clsicas (figura 2-1), a partir de una documentacin clara sobre los requerimientos de la aplicacin, se inician las tareas de diseo con enfoque sobre dos aspectos: datos y funciones. La definicin de los modelos de datos y de funciones se hace mediante procesos recursivos que incluye la produccin, revisin y re-definicion del
pag. 50

diseo. Las herramientas CASE son importantes para la definicin y seguimiento de las actividades constituyentes, y, cuando se han establecido grupos de trabajo, para que cada uno de ellos tenga conocimiento de las actividades que otro adelanta, y de las interrelaciones existentes. Cuando se completa el proceso iterativo, se obtiene el diseo definitivo para seguir con la implementacin. Figura 2.1. Diagrama de procesos corriente para el diseo de aplicaciones distribuidas
Requerimientos

Modelo de Datos

Modelo Funcional

Diseo dela Aplicacin

En el proceso de diseo no hay consideraciones sobre la distribucin de procesos, ni sobre la interface de usuario ni sobre la interoperabilidad y re-usabilidad de componentes. Estas deficiencias deben ser suplidas de alguna manera en un nuevo marco de referencia metodolgico. Para el establecimiento de un marco de Referencia, es necesario primeramente considerar un modelo, basado tambin en la arquitectura de las aplicaciones, con las capas antes explicadas (interface, reglas de procesamiento y Base de Datos) desarrolladas a travs de los procesos de planeacin (nivel conceptual), diseo (nivel lgico) e implementacin (nivel fsico).

pag. 51

Contrariamente a la propuesta de un trnsito progresivo desde el nivel conceptual al fsico, la tendencia corriente es obtener el producto (la aplicacin definitiva) de la manera ms inmediata posible. Esta tendencia es consecuencia de que las herramientas para Computadores Personales (altamente difundidos) operan a nivel fsico (construccin de formas, generacin de cdigo, generacin y ejecucin de aplicaciones de Bases de Datos, etc.); sin embargo, el establecimiento de los tres niveles -conceptual, lgico y fsico- es altamente conveniente.

2.5.1 Nivel Conceptual. El nivel conceptual se desarrolla con la intencin de dar indicaciones sobre la apariencia de la aplicacin y sobre los cambios que son necesarios implementar en la forma de procesamiento. El anlisis inicial se hace para cada una de las capas establecidas en la arquitectura de aplicaciones. En la capa de las aplicaciones de escritorio el estudio se hace a partir del flujo de trabajo entre personas o entre dependencias, sin tener en cuenta detalles de la interface. El flujo de trabajo, en situaciones aisladas puede interpretarse equivocadamente como una forma alternativa de desarrollar aplicaciones -de negocios, de oficinas- sin necesidad de programacin (tales como las aplicaciones de correo electrnico); al margen de estas situaciones particulares, el flujo de trabajo proporciona una representacin de la aplicacin. A nivel de la capa de procesos, el anlisis se hace por medio de diagramas de procesos (burbujas funcionales interconectadas). Las tareas de Reingeniera de procesos se adelantan bajo este modelo de procesos (realizado por personal con perfil gerencial, con el apoyo de personal tcnico). En la capa de la Base de Datos, el anlisis se hace empleando modelos de datos corporativos (modelos de datos de alto nivel, en los que no se consideran detalles de la informacin, ni aspectos de integridad ni de confiabilidad). El personal calificado sigue realizando la labor de definicin del modelo de la Base de Datos, pero ahora como una consecuencia del trabajo realizado al rededor del modelo de procesos.

pag. 52

2.5.2 Nivel Lgico. El nivel lgico (que corresponde al diseo detallado de la aplicacin) tiene el propsito de probar que el nuevo sistema puede cumplir con los requerimientos establecidos En la capa de las aplicaciones de escritorio, el flujo de trabajo se transforma en flujo de formas que muestran como completar un proceso. De estas tareas de diseo se obtienen los prototipos de las pantallas (interfaces) de la aplicacin. En la capa intermedia, las reglas de procesamiento se consideran en detalle; las burbujas se explotan en otras con mayor nivel de detalle (diagramas de flujo de datos o diagramas de interaccin de objetos), presentando un cuadro sobre el funcionamiento general del sistema, sin consideran aspectos de rendimiento de la aplicacin (como velocidad, requerimientos de almacenamiento, etc.). Dentro del proceso de Reingeniera, los diagramas son revisados -y a veces alterados- por el personal especializado que conocen como se ejecutan los procesos dentro de la organizacin. Al nivel de la Base de Datos, las consideraciones iniciales se detallan hasta llegar a constituir los Diagramas detallados de los datos (por lo general diagramas Entidad-Relacin), que dan lugar al esquema detallado de la Base de Datos, sin considerar an aspectos como normalizacin integridad, ndices o formato de almacenamiento.

2.5.3 Nivel Fsico. El nivel fsico se establece con el propsito de dar respuesta sobre la forma como el nuevo sistema se implementar y sobre su desempeo. El diseo lgico se transforma en el sistema actual. En la capa de las aplicaciones de escritorio, los prototipos se someten a un proceso de depuracin hasta llegar a obtener la interface grfica definitiva. El flujo de proceso (de la capa intermedia) se amplia para considerar mdulos, objetos, procesos, que se convierten en cdigo, luego de considerar aspectos de rendimiento y funcionalidad.

pag. 53

En la capa de la Base de Datos, el esquema inicial se amplia luego de realizar las tareas de normalizacin sobre las tablas de datos y de incluir aspectos de integridad. El esquema definitivo se implementa segn la herramienta disponible.

2.5.4 Trnsito desde el nivel conceptual al nivel fsico. El desarrollo de aplicaciones a travs de los tres niveles (conceptual, lgico y fsico) y que considera en cada nivel las aplicaciones de escritorio, las reglas de procesamiento y la Base de Datos, exige nuevos modelos, nuevas tcnicas, nuevos esquemas organizacionales, y en general un nuevo marco de referencia que puede derivarse de los tradicionales (como el modelo clsico), siempre que se realicen las adecuaciones del caso. A continuacin se presenta una alternativa basada en el modelo secuencial (Figura 2-2). Con relacin al modelo clsico, la primera gran diferencia es la presencia de cuatro dominios para las tareas de anlisis en lugar de dos (dominio funcional y domino de la informacin). En el nuevo modelo y en relacin a los trabajos de anlisis, se incluye una etapa correspondiente a cada una de las capas de la arquitectura de aplicaciones (aplicaciones de escritorio, reglas de procesamiento y Base de Datos), observando que sobre cada capa se hace un trabajo de anlisis conceptual y lgico. La fase llamada arquitectura considera la aplicacin integrada y es la encargada de tratar y resolver aspectos globales que involucran a todo el sistema, coordinando actividades paralelas y estableciendo relaciones entre las tres restantes capas. Las habilidades requeridas para el desarrollo de cada etapa son diferentes, lo que implica la conformacin de grupos interdisciplinarios bajo cierta organizacin, de manera que se permita su interaccin, y de alguna manera se tenga control sobre su desempeo. Figura 2.2. Nuevo Diagrama de Procesos Para el Diseo de Aplicaciones Distribuidas.

pag. 54

Requerimientos

Base de Datos

Procesos

Interface de Usuario

Arquitectur a

Diseo dela Aplicacin

Los diseadores de Base de Datos por lo general conforman un grupo pequeo pero crtico, en donde su principal virtud es la visin a largo tiempo que tienen sobre el procesamiento, de manera que puedan encauzar su visin en un modelo consistente de datos. Los diseadores de procesos, en el ms alto nivel (conceptual) se centran en los procesos de Reingeniera; en el nivel lgico, el diseador tiene al conjunto de reglas de procesamiento como su principal herramienta, de manera que stas conducen hacia el diseo final del sistema en su parte funcional. Los diseadores de la interface de la aplicacin, tienen el perfil de un diseador de presentaciones, y su forma de trabajo, contrariamente al de los diseadores de otras reas no es estructurada. Los arquitectos tiene un perfil amplio que incluye entendimiento de los procesos, conocimiento tcnico y una capacidad de coordinacin e integracin del trabajo desarrollado por separado. Entre los grupos de trabajo debe existir mucha interaccin y sincronizacin, estableciendo puntos de revisin, siempre que sea conveniente y/o necesario. Los cambios establecidos en un sector pueden incidir en el desarrollo de otro.
pag. 55

La arquitectura de aplicaciones en conjunto con la encapsulacin permite convertir los grandes sistemas, en otros de magnitud menor, sobre los que se puede ejercer un mejor control; ste es el proceso de abstraccin. La encapsulacin, el otro principio que ayuda al entendimiento de aplicaciones mayores, tienen su fundamento en el uso de objetos.

2.6

MODELOS PARA LOS PRXIMOS AOS.

Hasta ahora, las metodologas clsicas de desarrollo giran al rededor de dos modelos fundamenteales (modelo de datos y modelo funcional), la tendencia es hacia la utilizacin de modelos basados en objetos. Sobre los Objetos y sobre su alcance, se han tejido muchas expectativas, al igual que se han realizado grandes investigaciones con el fin de proveer un soporte real a la Programacin Orientada a Objetos (tales como desarrollo de sistemas operativos, nuevas herramientas, nuevas metodologas, etc). Sin embargo, en su gran mayora las aplicaciones se continan desarrollando de la manea tradicional, y los grandes avances en la produccin de nuevas herramientas (como aquellas que literalmente permiten que los no-programadores desarrollen aplicaciones menores y medianas) no han estado al rededor de los objetos. Las caractersticas tcnicas de los objetos (encapsulacin, polimorfismo, herencia) apuntan hacia el empaquetamiento y re-usabilidad de cdigo, como solucin a la duplicacin de software para tareas comunes y a la dificultad de tener aplicaciones interoperables. En la historia del software, se observa una bsqueda constante por lograr el empaquetamiento de cdigo (Sub-rutinas, Procesos, Paquetes y Objetos). Las Sub-rutinas presentan interfaces claras -nombres, argumentos y valores que retornan-, encapsulan el comportamiento, constituyen el fundamento de los lenguajes modernos de programacin y constituyen la primera alternativa de re-uso de componentes software.

pag. 56

Los Procesos que son construcciones de alto nivel (compuestas por cientos de subrutinas que conforman piezas grande de cdigo re-usable), constituyen el mecanismo para compartir cdigo y datos (programas independientes que son arbitrados por el sistema operativo, y que pueden comunicarse con otros programas mediante mensajes -IPC mecanismos de comunicacin entre procesos-). De acuerdo con lo anterior, los procesos son la esencia de la arquitectura Cliente/Servidor; por ejemplo una Base de Datos puede ser inmersa en un proceso para proveer servicios a otros procesos que se ejecutan en el mismo o en otro computador; otro proceso puede manejar la cola de impresin, para ofrecer servicios de impresin al proceso servidor de Base de Datos o a uno distinto. Los procesos, adicionalmente, son la base para la construccin de sistemas operativos modernos, redes y ambientes distribuidos. Su principal deficiencia es la carencia de un mecanismo de descripcin de su interface, que parcialmente puede ser solucionada (a nivel de usuario), proveyendo la documentacin necesaria. A nivel de las herramientas de desarrollo es necesario que se conozca y entienda la interface de manera que dichas herramientas puedan llevar a cabo su misin de ayudar a los desarrollares a emplear el proceso. Los Paquetes, contrariamente a los objetos poseen una interface formalmente definida que provee el soporte para la construccin software re-usable empaquetado. Los paquetes fueron promocionados por el lenguaje de programacin ADA, y justamente se atribuye a la complejidad del mismo el hecho que los paquetes no fueran construcciones conocidas; sin embargo, los paquetes constituyen la base para el desarrollo de los objetos. Los Objetos pueden apreciarse bajo diferentes enfoques: En primer lugar, interpretando la tendencia natural de los humanos por reconocer los objetos con los que trabaja antes que las acciones que se ejecutan sobre ellos, se habla de Interfaces orientadas a objetos (en una connotacin distinta al aspecto tcnico del empaquetamiento y de la re-utilizacin de cdigo) . Un objeto se selecciona, se abre, o se cierra, invocando la accin o la herramienta apropiada. De otra parte, los objetos se aprecian como un peldao ms en el avance tecnolgico hacia el empaquetamiento. Bajo esta perspectiva un objeto es un paquete ms generalizado.

pag. 57

Guardando las distancias, los proceso pueden ser vistos como objetos y los objetos tambin pueden considerarse como proceso: Objetos vistos como procesos (procesos de alto nivel). En el diseo de una aplicacin los procesos (de alto nivel, aquellos que se representan como burbujas) se pueden considerar como objetos, en el sentido que son componentes que cooperan con otros en la ejecucin de un trabajo. Haciendo uso de la equivalencia establecida, los diagramas de procesos permiten descubrir los objetos de alto nivel. Estos objetos de alto nivel permiten el trnsito hacia los objetos ms especficos (cuando las burbujas se exploten en diagramas ms detallados), en el que se indica la interaccin entre ellos travs de sus interfaces formalmente definidas. Procesos vistos como objetos (implementaciones tcnicas). Los proceso (como los conocidos bajo Unix), poseen las caractersticas atribuidas a los objetos: Encapsulacin (los procesos se componen de cdigo y datos, frecuentemente protegidos en direcciones de memoria separada, y se comunican algn mecanismo de comunicacin IPC), Herencia (los procesos pueden crear subprocesos que heredan el contexto -datos y cdigooriginal), y Polimorfismo (una operacin -un mensaje- puede ser enviada a varios procesos al tiempo). Bajo esta consideracin los objetos podran ser implementados en cualquier lenguaje (Cobol, c, SmallTalk, C++ o cualquier combinacin de ellos), puesto que esta es una caracterstica de los proceso. Estos -los procesos- proveen la infraestructura fundamental para implementar sistemas orientados a objetos, de manera que los beneficios perseguidos (entendimiento de grandes sistemas, flexibilidad, cdigo re-usable, interoperabilidad) se pueden obtener. Considerando las equivalencias establecidas, la interoperabilidad, re-usabilidad, flexibilidad y operacin sern beneficios de alto nivel conseguidos gracias al empleo de objetos (entendidos como procesos de alto nivel con interfaces perfectamente definidas) en las tareas de anlisis y diseo, sin embargo la implementacin no necesariamente debe hacerse mediante programacin orientada a objetos sino mediante procesos, al menos mientras las

pag. 58

herramientas de implementacin se difunden ms y mejoran sus prestaciones en cuanto a facilidad de manejo.

2.7

NUEVO MARCO DE REFERENCIA PARA EL DESARROLLO DE APLICACIONES.

La sntesis de un nuevo marco de referencia, se hace a partir, en primer lugar del empleo de los dos mecanismos de abstraccin (arquitectura de la Informacin y establecimiento de fases progresivas -conceptual, lgica y fsica-); sobre esta base se emplea el conjunto de modelos fundamentales que conducen el proceso de diseo. En la Tabla 2-2 se presenta una comparacin entre la formas tradicional y nueva de emplear las corrientes de diseo. Tabla 2-2. Comparacin entre la formas actual y propuesta de emplear los modelos que manejan el proceso de diseo de aplicaciones Nivel Arquitectura Aplicaciones de Escritorio Procesos Base de Datos Actual Propuesto Modelo de interaccin de objeto Objetos; prototipos Objetos; modelo funcional Modelo de Datos

Modelo Funcional Modelo de datos

Se propone que una aplicacin sea descompuesta haciendo uso de los mecanismo de abstraccin y encapsulamiento. De un lado, la aplicacin se divide arquitectnicamente en las capas conocidas (Aplicaciones de escritorio, reglas de procesamiento, y Base de Datos), separando las funciones de interface, procesamiento y almacenamiento de datos, y buscando interoperabilidad antes de que cada capa sea diseada por separado. De otra parte, los componentes en cada capa son conceptualizados y diseados en trminos de componentes separados pero con alto grado de interaccin.
pag. 59

En el desarrollo de las aplicaciones se hace uso de modelos dinmicos, modelos estticos y prototipos. Los diagramas de interaccin entre objetos corresponden a modelos dinmicos que presentan informacin a diferentes niveles, as, en la capa de arquitectura se representa la interaccin entre componentes; a nivel de la interface de usuario se representa como flujo de trabajo; en la capa de procesos como reglas de procesamiento, y a nivel de Base de Datos se representa la interaccin entre transacciones definidas sobre los datos. los modelos estticos se utiliza de manera extensa en la representacin de los datos (tales como los diagramas E-R), que permiten describir y definir las estructuras de algunos componentes (como entidades, atributos, relaciones, y si se hacen las ampliaciones del caso, tambin se emplean para describir objetos). Los modelos (estticos y dinmicos) permiten ejecutar las tareas de anlisis, control y diseo necesarias en las etapas de arquitectura, reglas de procesamiento y Base de Datos. Los modelos constituyen el centro de los grandes diseos. Los modelos le permiten al diseador experimentar sin tener que construir el producto final. Para el desarrollo de la interface de la aplicacin, que no se puede encasillar dentro de un modelo por ser una tarea de carcter creativo y espontneo, se hace uso de los prototipos. Como se conoce, los prototipos proporcionan informacin que no es posible recoger por medio de documentos escritos, y permiten las primeras evaluaciones por parte de los usuarios, para establecer si se estn alcanzando sus requerimientos. A diferencia de la capa de las aplicaciones de escritorio, los modelos para describir las reglas de procesamiento y la Base de Datos son muy diferentes del producto final (no son representaciones visuales). Por lo general en el modelaje se emplean diagramas (de descomposicin funcional, de flujo de datos, de dependencia de procesos, de interaccin de objetos, de jerarquas de clases, etc -del lado de las reglas de procesamiento- y EntidadRelacin -para la Base de Datos-) complementados con texto explicativo. A pesar de que en estos casos el modelo no es una representacin visual del producto final, los diagramas (por ejemplos los diagramas Entidad-Relacin empleado en la Base de Datos), al igual que los

pag. 60

prototipos de la interface del usuario, constituyen una representacin til y una plataforma slida para su posterior desarrollo.

2.7.1 Organizacin de los Grupos de Trabajo. El modelaje y los prototipos son clave en la consecucin de diseos apropiadas para aplicaciones Cliente/Servidor, sin embargo no es suficiente con el seguimiento de los mtodos establecidos, es necesario tambin buscar la mejor organizacin, que por lo general se consigue al rededor del establecimiento de pequeos grupos de trabajo. El establecimiento de los grupos de trabajo y su forma de operar, deben establecerse con un criterio diferente al que se ha empleado tradicionalmente, pues aunque histricamente las aplicaciones se han dividido (en subsistemas y stos a su vez en mdulos), siempre ha existido un alto grado de interdependencia en cuanto a definiciones de cdigo y datos de las partes, de manera que difcilmente un grupo podra desarrollar un mdulo sin ejecutarlo como parte de uno mayor. El criterio sugerido gravita al rededor de la aplicacin de las tcnicas de Calidad Total y Reingeniera de procesos (antes descritas) sobre el propio desarrollo del software. La intencin es que grupos con autorizacin y poder y que actan de manera auto-regulada, traten a cada componente establecido como si fuera una aplicacin completa, sobre la que se establecern sus requerimientos propios, sus tcnicas de prueba, e incluso su propio cronograma de desarrollo. La propuesta anterior, apunta hacia el desarrollo de aplicaciones re-usables (puesto que los grupos de desarrollo se encargan de definir y optimizar su interface y su comportamiento, de manera que puede invocarse desde diferentes aplicaciones), flexibles (puesto que los cambios internos en los requerimientos sern asumidos internamente en la aplicacin particular, sin que estos cambios afecten a otras aplicaciones que la invocan), y con capacidad de adaptacin a la necesidades particulares de procesamiento (puesto que sobre un comportamiento general ofrecido por una aplicacin a travs de su interface, puede hacerse un manejo especial, mediante un nuevo mdulo desarrollado por un grupo localsobre los casos especiales).
pag. 61

Adicionalmente a los grupos de desarrollo, es necesario establecer los grupo encargados de las tareas de arquitectura y de las herramientas de desarrollo. El primer grupo -el de arquitectura- es el encargado de proveer la visin completa sobre la estructura de la aplicacin y de las aplicaciones menores establecidas. El segundo grupo, debe evaluar las validez y utilidad de las herramientas disponibles; siempre que sea posible, debe desarrollar herramientas que cubran las necesidades de los dems grupos, y por ltimo, debe (segn las necesidades) definir cules son las nuevas herramientas que se deben adquirir. Una vez evaluadas, el grupo de herramientas establece patrones estndares sobre su uso. Sin embargo, la eleccin de las herramientas para el desarrollo de aplicaciones (de todos los tipos, no slo bajo el esquema Cliente/Servidor) siempre ha sido tema de discusin.

2.7.2 Herramientas. Debe considerarse que ninguna herramienta, por completa que sea, har todo el trabajo necesario en el proceso de desarrollo; siendo este proceso compuesto de actividades de mltiples facetas, se necesitarn diferentes conjuntos de herramientas a las que tendrn acceso los grupos de desarrollo. Para cada propsito existir un lenguaje que debe seleccionarse apropiadamente. Las aplicaciones pequeas pueden desarrollarse empleando un solo lenguaje, en las aplicaciones medianas, la parte frontal se desarrolla empleando lenguajes grficos especializados y la parte posterior mediante un lenguaje de Bases de Datos. En las aplicaciones grandes, en donde se identifican las tres capas, es comn que se empleen varios lenguajes, buscando especializacin en el desarrollo de cada capa. En la capa intermedia ( reglas de los procesamiento) que requiere de un manejo eficiente y controlado, es comn el empleo de lenguajes como COBOL, C, C++. En la capa de la Bases de Datos, que implica un tratamiento con alto grado de computacin y manipulacin de registros, se emplean lenguajes como los de la familia dBASE o, preferiblemente, SQL.

pag. 62

Las herramientas visuales se han difundido con gran rapidez. Se supone que ellas evitan el uso de metodologas pesadas y son de fcil aprendizaje. La programacin orientada a eventos es un claro ejemplo del uso de las herramientas visuales. El punto de partida es la presentacin grfica (interface de usuario), en donde se planea la respuesta a los eventos generados por el usuario. Estos ambientes asocian automticamente un conjunto de eventos a cada elemento de la pantalla, definiendo sobre l una accin por omisin. El programador puede asociar una accin a la ocurrencia de un evento (particular), controlando de esta manera los resultados del trabajo del usuario, mientras le permite un alto grado de independencia sobre la forma de interactuar con la aplicacin. Adicionalmente los ambientes visuales, proveen facilidades de conectividad a Bases de Datos posteriores, permitiendo la definicin de consultas y la construccin de reportes. Por lo general los entornos estn construidos sobre una arquitectura de slo dos capas (la interface y el servidor de Base de Datos). Algunos ejemplo de ambientes de programacin conducidos por eventos son: Visual-Basic y Power Builder, que tiene al BASIC como lenguaje de base, Enfin (basado en SmallTalk), Notes (con lenguaje propio basado en formula) e Hypercard (fundamentando en HyperTalk). A pesar de las facilidades ofrecidas por el modelo orientado por eventos, su aplicacin no es suficiente para el desarrollo de aplicaciones completas; en el desarrollo de grandes sistemas seguirn siendo necesarias herramientas ms sofisticadas, alternativamente, las herramientas visuales se pueden combinar con otras herramientas destinadas a la construccin. La tendencia es emplear una herramienta CASE como la parte administradora de la Base de Datos del modelo de la aplicacin (conocida como enciclopedia de la aplicacin) y emplear herramientas de diseo visual que permitan la asociacin a un evento de un componentes escrito en cualquier lenguaje. Algunos productos como IEF, de Texas Instruments, ofrecen desde comienzos de los 80s el manejo de enciclopedia de la aplicacin, y otros fabricantes, como IBM, propusieron el concepto de enciclopedia abierta (que es un marco de referencia para la integracin de herramientas diferentes).
pag. 63

Las herramientas CASE se han ampliado para incluir aspectos propios de los entornos Cliente/Servidor (muchas de ellas estn siendo re-escritas para soportar tcnicas de Reingeniera de procesos, equipos auto-regulados, arquitectura de aplicacin, etc. Los lenguajes de Cuarta generacin, constituyen otra herramienta cuya intencin es eliminar la necesidad de programacin; bajo este esquema el programador especifica las normas y el orden en el que ellas se aplican (con clara aplicacin sobre la capa de las reglas de procesamiento). Estos son sistemas conducidos por normas (reglas), la eleccin del orden de ejecucin queda a cargo del lenguaje. La aplicacin de estas herramientas supone un ahorro de tiempo en la programacin y la capacidad de adaptacin a nuevas reglas, sin embargo trabajan en dominios limitados, son inestables y tienen un pobre desempeo

2.8

REFINAMIENTO APLICACIONES.

DE

LAS

CAPAS

DE

LA

ARQUITECTURA

DE

La arquitectura de aplicaciones propone el establecimiento de tres capas (aplicaciones de escritorio, reglas de procesamiento y Base de Datos) y dentro de cada capa a su vez se proponen tres subniveles (Tal como se muestra en la Tabla 2-3), de manera que se permita describir completamente a los sistemas distribuidos. Tabla 2-3. Capas y subcapas Definidas en la Arquitectura de Aplicaciones Capa Aplicacin de Escritorio Reglas de procesamiento Base de Datos Navegacin y control Ventanas Manejador de procesos Manejador de transacciones Componentes Activos Aplicaciones de escritorio basadas en ventanas Reglas de procesamiento Base de Datos OLE Agente de requerimientos Coordinador de transacciones Integracin

pag. 64

 Navegacin y control (que es la subcapa ms externa y provee facilidades para encontrar componentes y asegurarse de que ellos cumplan con la tarea asignada). Subnivel de los componentes activos (que hace referencia a los objetos dentro de cada capa). Integracin que permite que los componentes independientes dentro de una capa trabajen conjuntamente como si se tratase de un gran componente.

2.8.1 Aplicaciones de escritorio. En cuanto a la subcapa de navegacin y control el propio ambiente (como en el caso de Microsoft Windows) es el que ofrece las facilidades de bsqueda e inicio de las aplicaciones. La subcapa intermedia (componentes activos) est constituida por las propias aplicaciones de escritorio orientadas al manejo por medio de ventanas. La capa inferior, realiza su funcin integradora mediante el uso de las facilidades OLE, permitiendo que varias aplicaciones se comporten como una aplicacin mayor.

2.8.2 Base de Datos. Los componentes activos (subnivel intermedio) son las propias tablas que hacen parte de la Base de Datos. La subcapa de navegacin y control corresponde al manejador de transacciones (que es un componente software encargado de mantener un seguimiento sobre las transacciones disponibles -tanto de aquellas que modifican los archivos de datos como de aquellas que nicamente los consultan); ste busca la independencia de la Base de Datos mediante el uso de un lenguaje de acceso estndar (como SQL) y el uso de pasarelas (encargadas de hacer las traducciones necesarias entre plataformas o motores de Bases de Datos diferentes). La lgica transaccional, sin embargo, se debe codificar como parte de la capa de las reglas de procesamiento. La subcapa integradora posibilita realizar un tratamiento sobre una Base de Datos distribuida como si se tratase de una gran Base de Datos centralizada. Productos comerciales como Omniserver de Sybase y EDA/SQL ofrecen procesadores de consultas distribuidas que permiten extraer informacin desde diferentes Bases de Datos; una forma
pag. 65

alternativa de integracin se basa en la replicacin de datos (evitando la necesidad de hablar a ms de una Base de Datos al tiempo), en este caso las consultas son directas sobre los datos recolectados en cada estacin. Para el caso de las actualizaciones se emplean las Transacciones Distribuidas que se deben tratar como si fuera una sola (esto constituye el servicio clave en el entorno Cliente/Servidor, puesto que los equipos humanos de trabajo debern estar en capacidad de iniciar transacciones que afectan a datos locales y remotos). Productos comerciales como Oracle, Informix, Sybase, SQL Server ofrecen transacciones con compromiso en dos fases (two phases commit, un protocolo que coordina las operaciones de actualizacin sobre varias Bases de Datos, en cuyo caso la transaccin se completa con xito en cada uno de los puntos o en caso contrario cada base vuelve a su estado original). En la ejecucin de una transaccin distribuida los sistemas de Bases de Datos involucrados mantienen los dato en memoria; el Monitor de Procesamiento de Transacciones (TPM, que es un componente infraestuctural -software- del Sistema de Base de Datos) enva a cada base una orden de precompromiso, que cada sistema contestar, entonces TPM enva la orden de compromiso a cada sistema de Base de Datos, y stos debern comprometer los datos y responder al TPM. El monitor de transacciones completa la transaccin cuando recibe respuesta de cada sistema; si algn sistema de Base de Datos responde negativamente a las rdenes de precompromiso o de compromiso, el TPM se encarga de volver atrs la transacciones en cada sitio. En ambientes distribuidos la misin del TPM es delicada y ms si las Bases de Datos implicadas son de diferentes proveedores u operan sobre diferentes plataformas. Tuxedo (Unix Systems Laboratories) es un TPM que controla actualizaciones en redes que tienen clientes DOS, OS/2, Windows y Unix. Tuxedo emplea protocolos de comunicacin TCP/IP y NetBIOS, y adicionalmente soporta algunas funciones de procesamiento distribuido (por ejemplo enrutamiento de peticiones segn el tipo de servicio). Encina (Transarc Corporation) es un TPM disponibles en entornos Hewlett-Packard , IBM y SUN. Ofrece entorno de desarrollo, ejecucin y gestin bajo los estndares de OSF y tambin llamadas a procesos remotos de transacciones (RPC). Encina soporta redes SNA y TCP/IP.
pag. 66

Sistema de Control de Informacin al Cliente (CICS de IBM), de amplia utilizacin. Usa funciones Encina en la implementacin AIX/6000. La aproximacin del monitor de transacciones en dos fases requiere que los vendedores de Bases de Datos provean las facilidades mnimas para el trabajo de coordinacin. En 1990 X/Open defini el estndar XA que especifica un protocolo para la comunicacin entre Bases de Datos que aceptan compromiso de dos faces, con lo que se allanara el camino para la ejecucin de transacciones distribuidas; sin embargo, no todos los sistemas de Bases de Datos soportan el estndar. Los sistemas distribuidos, de un lado involucra transacciones que se deben ejecutar en tiempo real (transacciones interactivas orientadas a la conexin que necesitan atencin en tiempo real empleando RPC), pero adicionalmente por el hecho de que ellos implementan los procesos de negocios requieren de facilidades para el manejo de secuencias transacciones (grupo de transacciones controladas mediante la tcnica de almacenamiento y reenvo, que hace necesaria la presencia de un gestor de colas de mensajes en cada extremo transacciones no orientadas a la conexin-). Las transacciones en tiempo real son manejadas en la capa de la Base de Datos, pero las transacciones extendidas pueden ser gobernadas por el gestor de procesos que est en la capa superior (Reglas de procesamiento)

2.8.3 Reglas de Procesamiento. Constituyen la principal y ms extensa capa dentro de la arquitectura. Los componentes activos son los procesos escritos en Cobol, C, C++ u otro lenguaje y que implementan las reglas de procedimiento. La subcapa de integracin es la encargada del manejo y operacin de los procesos fundamentales que mantiene en operacin a la organizacin. Su misin es proveer el mecanismo para que los componentes puedan trabajar coordinadamente para actuar como una aplicacin que contempla una gran coleccin de reglas de procesamiento. En este entorno se identifican componentes que formulan solicitudes y otros que los atienden; el mecanismo que permite la integracin es conocido como Agente de Requerimientos
pag. 67

(Request Broker), ste se encarga de tomar una solicitud hecha por un componente y de encontrar el lugar apropiado para su procesamiento. Los componentes que implementan las reglas de procesamiento aceptan solicitudes por medio de algn mtodo de invocacin (RPC o de paso de mensajes); la coleccin de requerimientos a los que un componente responde conforma su interface. Para la construccin directa de una aplicacin se necesita conocer cules son los componentes disponibles, cul es su localizacin y su interface, pero cuando se trata de aplicaciones distribuidas se pueden generar nuevas exigencias, en cuyo caso el Request Broker se encarga de formular los requerimientos de un computador a otro, manejar las situaciones en las que un componente cambia de residencia y prestar servicios de directorio. El Agente de requerimientos consta de mecanismo de peticiones (que incluye una manera estndar de formular peticiones independiente del proveedor del servicio y del lenguaje de programacin de base). Los mecanismos de solicitud de servicios ms comunes son las RPC y el paso de mensajes (aunque RPC y mensajes son, en esencia, mecanismos equivalentes), la eleccin entre una y otra representacin se reduce a aspectos como la disponibilidad y la adaptacin a su manejo. Generalmente las referencias a Procesos Remotos se resuelven en tiempo de ejecucin ligando (binding) el programa llamante con la rutina invocada que se est ejecutando en otro computador. El mecanismo RPC interpreta las llamadas a la subrutina, convirtindolas en mensajes que enva al computador que la contiene, encargndose de invocarla en aquel computador. La respuesta de la subrutina es interceptada, convertida en mensaje y retornada al computador que inicia el requerimiento. El proceso de llamada es transparente, de manera que para el programador, la forma de invocar una RPC es la misma que se emplea en el llamado a rutinas corrientes. Las RPC representan una tecnologa madura y que ha demostrado un funcionamiento real. En el caso prctico los mecanismos de invocacin exigen algunas condiciones de compatibilidad entre sistemas cruzados. Alrededor de RPC existen dos representaciones: Las RPC de ONC (Computacin de Red Abierta RPC/XDR), de amplia difusin sobre plataformas IBM, Unix System V 4.xx, Novell
pag. 68

TI-RPC (RPC independiente del nivel de transporte), y las RPC de OSF (Fundacin para el Software Abierto), proporciona un lenguaje de programacin y un compilador para el desarrollo de aplicaciones que se ejecutan en sistemas clientes y en sistemas servidores. Para las RPC de OSF se especifica la definicin de interface mediante IDL (Lenguaje de desarrollo de interfaces); el compilador IDL traduce la definicin en fragmentos ligados al cliente y al servidor; el fragmento del servidor permanece a la espera del procedimiento cliente; algo similar sucede en el otro extremo. La posibilidad de ejecucin de procesos sobre ambientes heterogneos ofrecida por las RPC implican el cumplimiento de ciertas tareas, por ejemplo, las diferencias entre las representaciones de los datos en cada mquina (que se solucionan etiquetando la llamadas con la descripcin de la representacin de datos bsica de la mquina que realiza la llamada), recuperacin de fallos (del lado del cliente, del servidor o de la red), mecanismos de seguridad para garantizar privacidad e integridad de la comunicacin, soporte multihilado para el procesamiento concurrente o paralelo en la red, etc. El mecanismo para realizar las solicitudes lo constituyen las RPC, pero adicionalmente a ste se requiere de un mecanismo localizador de servicios, que permita que los componentes adviertan que servicios estn disponibles y cul es la forma correcta de accederlos (Servicios de Directorio). Muchos RPC tienen alguna forma de localizador de servicios, tal como las pginas blancas y amarillas de SUN, que presentan listados de componentes por nombres y servicios respectivamente. Otros posibilidades de servicios de Directorio (con mucha proyeccin y pleno desarrollo actual), se ofrecen con CORBA (Arquitectura Comn del Agente de requerimientos de Objetos) de OMG (Grupo de Manejo de Objetos), Monitor Transacciones (que permite advertir los servicios de una transaccin), Sistemas Operativos Orientados a Objetos (como Taligent --de IBM y Apple--, Cairo --de Microsoft--, NextStep, que en un futuro prximo pretenden incluir agentes localizadores con independencia geogrfica), y Enciclopedias (que ofrecen aplicaciones soportadas en una Base de Datos, de manera que se disponga con la informacin suficiente (clase, ubicacin) para responder a una solicitud; idealmente la enciclopedia podra ser encadenada directamente a un sistema operativo orientado objetos, de manera que el proceso de localizacin sea transparente).
pag. 69

La subcapa de Navegacin y control (manejador de procesos) es la responsable de controlar y activar los componentes que implementas las reglas de procesamiento. Es una parte crucial de la infraestructura necesaria (que tambin es la que con mayor frecuencia falta). En cada servidor se debe ejecutar un manejador de procesos, que est directamente relacionado con el agente de requerimientos del sistema, de manera que se pueda hacer el seguimiento de los requerimientos, tomar decisiones cuando un requerimiento no puede atenderse inmediatamente, en caso de fallas en alguno de los sitios y si la transaccin es extendida en el tiempo, entonces deshacer el proceso adelantado y repetir el requerimiento, monitorear el tiempo tomado por un requerimiento, y en coordinacin con el TPM balancear la carga de procesamiento. Los componentes infraestructurales (descritos para cada subnivel) se pueden integrar para constituir sistemas completos que operen de manera distribuida. Desde la perspectiva del usuario, las aplicaciones de escritorio le permiten completar tareas discretas, que unidas conforman lo que se conoce como flujo de trabajo; ste flujo se relaciona directamente con el flujo de procesos, debido a que el primero puede iniciar una secuencia de tareas -con la posibilidad de que sean extendidas en el tiempo-, y en otras ocasiones un proceso puede originar la ejecucin de un flujo de trabajo. Bajo el flujo de procesos, ocurren transacciones y consultas distribuidas. Muchos de los componentes infraestructurales estn disponibles y son objetos de mejoras y ampliaciones, por ejemplo: el ambiente de las aplicaciones de escritorio (incluida la tecnologa OLE), el Agente de Requerimientos, los manejadores de transacciones distribuidas, etc. Sin embargo algunas partes estn an en la etapa de investigacin, tales como los Manejadores de Procesos (en la parte de navegacin y control de la capa de las reglas de procesamiento) y el coordinador de transacciones (en la capa de la Base de Datos), lo que no impide que los sistemas se comiencen a disear esperando la maduracin o la disposicin de todos los componentes identificados.

pag. 70