Dise.o de sistemas distribuidos - Departament d'Enginyeria ...gomariz/index_archivos/... · 9...

Enric Martínez Gomàriz

Diseño de Sistemas Distribuidos

@EMG/10 – Enric Martínez Gomàriz 2

Parte 2 – Diseño de Aplicaciones Distribuidas

@EMG/10 – Enric Martínez Gomàriz

3

Presentación

Como ya se dijo en la presentación de la primera parte, esta segunda parte está dedicada específicamente al diseño y se utilizan los conceptos y nomenclatura desarrollados y presentados en la primera parte. Todo el sistema distribuido debe estructurarse en una Arquitectura Orientada a Servicios (SOA), que deberá ser robusta ante las inevitables incidencias, que habrán de utilizar personas y que se deberá administrar desde una visión unificada lo más eficiente y económicamente posible. Todo proceso negocio y unidad de información debe presentarse como un servicio. Todo el sistema se construirá como integración de servicios. Y todo lo ya existente (legancy) se integrará también como servicios. Y los servicios deberán ser transparentes, a la plataforma y a su implementación, reutilizables y permitir su integración con otros servicios. Ese debe ser el objetivo de cualquier curso de diseño distribuido.

Está segunda parte está estructurada en los siguientes bloques:

Diseño de componentes individuales. Arquitectura y comunicación de servidores. Revisión de los conceptos de Ingeniería de Software necesarios. Desarrollo de la metodología de diseño de aplicaciones distribuidas. Diseño de Interfícies Gráficas. Reingeniería de sistemas.

Y un comentario previo al inicio de esta segunda parte. En las capturas de pantalla que encontrará para ilustrar los ejemplos hay muchas de versiones anteriores de Windows. Por favor, no piense por ello que el mensaje está anticuado. No confunda la forma con el fondo. Simplemente, un día me cansé de trabajar inútilmente actualizando la imagen a cada cambio de versión del sistema operativo.

@@EMG/10 - Enric Martínez Gomàriz 4

Condicionamientos de organización.

1. Introducción.

A causa de la propia naturaleza de las aplicaciones distribuidas, en todas las instalaciones en las que deben diseñarse y utilizarse, existen condicionamientos de organización, no necesariamente informáticos, que deben conocerse y, dentro de lo posible, controlar por su influencia indirecta en el diseño. Estos condicionamientos suponen puntos de heterogeneidad y/o precondiciones al diseño y actúan, la mayoría de las veces, como corsés de los cuales no se puede huir y que incluso imposibilitan soluciones técnicamente mejores de las que finalmente se pueden implementar. Dentro de esta relación pueden incluirse temas como la unificación de los estándares de informática, la dispersión de formatos y contenidos de la información que la aplicación distribuida va a integrar, la heterogeneidad de las operativas y circuitos organizativos, la codificación heredada, los condicionantes de idioma, el estado de animo del personal, etc. En este capítulo se incluyen comentarios y reflexiones sobre algunos de ellos. El objetivo no es tanto estudiarlos, ya que son, en su mayoría, muy intuitivos, sino poner en alerta al diseñador para detectarlos en fase de análisis de requerimientos y no en la de arranque cuando sus consecuencias pueden inutilizar parte del sistema informático diseñado o poner al diseño en graves apuros. Algunos de estos condicionamientos estarán reflejados en el Plan Estratégico de la compañía pero otros son “ambientales” o transitorios. Este capitulo incluye alguno de los más habituales, pero no intenta ser en ningún caso exhaustivo ya que gran cantidad de ellos solo están presentes en unas pocas organizaciones. He intentado incluir “uno de cada tipo” para que Vd. vea diferentes fuentes.

2. Los estándares de la plataforma. Hardware, sistemas operativos, Middleware, modelos de aplicaciones, modelos de soporte a usuarios, etc. La fuente es el Plan Estratégico de la Compañía. Si no existe, le recomiendo documentarlos.

3. El estándar ofimático

Las posibilidades de los paquetes ofimáticos actuales son inmensas. Proporcionan ya fabricadas, como ya se ha dicho repetidamente en la primera parte, muchas funciones necesarias en aplicaciones distribuidas y con un nivel de prestaciones sencillamente increíbles.


Hoy día, para diseñar un sistema integrado debe utilizarse a fondo la ofimática de la Compañía. Para conseguir que el entorno ofimático sea además operativo y eficaz es fundamental que esté unificado en toda la organización. Esta unificación no pasa solo por un paquete único para todos, cosa que el Sr. Gates ya ha conseguido prácticamente en todos los sitios, sino también por establecer configuraciones y plantillas estándar dentro de cada elemento del paquete. Y establecer recomendaciones de trabajo comunes. El paquete ofimático debe disponer como mínimo de procesador de textos, hoja de cálculo, paquete de gráficos y paquete de presentaciones. Es altamente recomendable disponer también de un paquete de gestión de bases de datos, tipo Access por ejemplo. La Compañía ha de formar a los usuarios actuales y futuros en la utilización fluida y habitual de los recursos ofimáticos. Los cursos o seminarios de formación deben incluir la distribución de la operativa estándar y de las recomendaciones de trabajo comunes. Por esa razón, por las actividades de formación han de pasar, no sólo los usuarios noveles, si no también aquellos que ya usan habitualmente los paquetes ofimáticos. Obviamente, en este segundo caso la actividad de formación debe reducirse a la operativa y las recomendaciones de trabajo. En mi opinión, el usuario ha de ser autónomo en su trabajo ofimático que no debe ser soportado por el Dpto. de Informática ya que esa carga colapsaría cualquier soporte al resto de aplicaciones.

4. La unificación de la ofimática. Puede ser que dentro del proceso de integración de la ofimática, inevitable dentro de la creación de un entorno distribuido, se produzca la incorporación de usuarios que están trabajando con entornos ofimáticos diferentes al que se ha cogido como estándar en la Compañía. O, utilizando el mismo paquete, por unificación de operativas y formularios. Aunque por la presión de MS Office la mayoría de organizaciones ya han pasado por este trabajo, creo que para aquellas en las cuales no haya sido así, es conveniente incluir este punto. O aquellas que han decidido abandonar al Sr. Gates y abrazar a Open Office. Si usted ya no tiene el problema, sáltese este apartado. La integración de estos usuarios en el entorno estándar común es un esfuerzo que no debe ser menospreciado. 4. 1. Será un trabajo impopular.

Se han de cambiar operativas que los usuarios ya dominan de una forma diferente. Y desde el punto de vista del usuario para no ganar nada: cuando acabe la etapa de reciclaje, el usuario estará haciendo lo mismo que ya hacia pero de una forma diferente. No menosprecie este problema. Usuarios motivados es su principal activo para llevar a buen puerto su proyecto. No les esconda la realidad. Explíqueles, sin embargo, que con la etapa de integración, a la cual le está obligando, ganará integración de su información


con la del resto de la Compañía. Podrá distribuir y recibir más o mejor y participar de los beneficios que, una masa de usuarios mayor, le va a proporcionar. Intente por todos los medios que el usuario se sienta apoyado durante el cambio evitando que tengan la sensación que se le ha impuesto un cambio que no necesita o que se le ha “abandonado a su suerte”.

4. 2. Será un trabajo largo y pesado. Si tiene buenos usuarios, cuando se realice el inventario de documentos ya creados que tiene cada uno se quedará sorprendido de la inmensidad de la lista resultante. Y si multiplica por un factor de tiempo para conseguir la adaptación de estos documentos a los nuevos formatos pueden llegar a necesitar muchos meses de trabajo, meses de los que nadie dispondrá. No confíe en las opciones de traspaso de formato que todos los paquetes disponen para “absorber” documentos generados con paquetes de la competencia. Fuera de casos muy simples, tendrá tantos o más problemas como si los generará de nuevo. Olvídese de la solución de subcontratar la adaptación. La persona externa a la que subcontrate necesitará más tiempo para entender que pretende cada documento que para generarlo. La experiencia del día a día me ha convencido que la adaptación de un documento generado por un usuario ha de ser realizado por el mismo usuario. Puede parecer que hemos llegado a un callejón sin salida. Sería así, si la experiencia de muchos procesos de integración de este tipo, no confirme que sólo un porcentaje ínfimo de los documentos generados por un usuario de ofimática son reutilizados. Se sorprenderá de cuan pequeño es. Así pues la solución empírica del problema pasa por formar e instalar el nuevo paquete en los entornos de usuario y dejar un periodo (unos tres meses) para que el usuario realice el transito. Recomiéndele que empiece a trabajar en los documentos nuevos con el nuevo entorno y que recicle los antiguos sólo cuando reutilice. Pasado ese periodo desinstale el paquete antiguo. Es la única forma de obligar al cambio: habrá usuarios que se habrán mantenido fieles a los antiguos paquetes y que sólo en los últimos días, y ante la eminencia del cambio empezarán a trabajar con el nuevo entono. Guárdese en un servidor de uso restringido el paquete antiguo para casos excepcionales. No haga concesiones ni al Director General. Si le dejan, claro. Si lo hace, el proceso de transito no acabará nunca. Si es necesario, ¡sobórnele! Hágale la adaptación de los documentos usted mismo. Y si tiene tiempo, aplique la misma medicina a tantos altos cargos como pueda. Además de “hacer méritos”, conseguirá sus aliados más poderosos: si el jefe cambia.......

En todos los casos el trabajo se ha de cuantificar para evitar sorpresas inesperadas. Y sobre todo, recuerde “vender” la nueva solución a los usuarios afectados y de conseguir que se sientan apoyados en todo momento.


5. La dispersión de formatos y contenidos. La dispersión de formatos es otro efecto que ha de evitar a toda costa. Los mismos contenidos se presentan con formatos diferentes para diversos usuarios lo que provoca perdidas de tiempo y esfuerzo al realizar estudios comparativos. El problema se presenta tanto en información impresa como en las presentaciones de pantalla. Es un problema que escapa del entorno informático para extenderse ha todo el entorno de negocio de la empresa. Sin embargo aquí usted tendrá el control. El problema se agravará si se extiende a la dispersión de contenidos. Por ejemplo, en una reunión de ventas los jefes regionales se presentan con contenidos tan diversos como una representación gráfica de las ventas por semanas y una hoja de cálculo con las ventas por días. Va ha ser muy difícil comparar. El problema puede agravarse además si pone al descubierto la existencia de recursos diferente según los usuarios: los agravios comparativos pueden ser graves. Todo ello conlleva a reflexionar sobre la problemática de la dispersión de contenidos y formatos. 5. 1. Imposición o libertad.

Los dos extremos son malos:

El formato único es una utopía. La libertad llevará a la anarquía.

La solución depende la organización y de la actividad de la Compañía ya que estos factores condicionarán la información a compartir. Es muy difícil dar criterios genéricos pero si le quiero transmitir consejos empíricos consecuencia de mi experiencia:

Actuar nada más en el ámbito de la información compartida... Pactar la máximo los contenidos y conseguir que al final una “autoridad jerárquica superior” los apadrine.

Aconsejar formatos y decidir, como mínimo, el tipo de presentación, en particular si es gráfica o no.

Proponer plantillas que se controlarán, desarrollarán y distribuirán de forma centralizada.

6. Unidad de versión. Mantenga siempre la misma versión del paquete en todo el entorno integrado. La incompatibilidad de formatos o prestaciones “hacia arriba” de las diferentes versiones pueden llegar a crear puntos de colapso y tensión y, al final, pérdidas económicas directas o indirectas. Aquí tendrá siempre fuertes presiones ya que usuarios “avanzados” presionarán a los jefes comunes sobre lo obsoleto de su versión y lo que “se están perdiendo” no utilizando la nueva. Este último argumento, con muy honrosas excepciones, es una


falacia: la inmensa mayoría de los usuarios, todos en muchos casos, van ha utilizar las mismas opciones que utilizaban en la antigua versión cuando pasen a la nueva. Subir versión no es ninguna tontería. Los PC’s han de estar preparados (todos sabemos los aumentos de hardware que muchas subidas de versión suponen), el personal de soporte preparado, los usuarios formados y los estándares documentales de la compañía adaptados. Y las nuevas versiones se han de comprar. Además quizás el cambio de versión del paquete ofimático le obligue al cambio de versión del sistema operativo con lo que su problema será doble. Es fácil que el coste económico de todo ello sea sorprendentemente alto. Muéstrese firme. Los problemas van a ser suyos no de los usuarios críticos. Cambie cuando el retorno de la inversión este justificado; y siempre de forma planificada. Por desgracia, puede que las “circunstancias” le obliguen: el proveedor descatalogará su versión, oficialmente o “de facto”, tarde o temprano. Sin comentarios. Intente estar informado del calendario de descatalogaciones de su software actual. La complejidad que un cambio de este tipo puede suponer la obligación de adelantarse y no dejarse sorprender.

7. Necesidad de Multidioma.

Las aplicaciones distribuidas afectan cada vez más a personas que utilizan idiomas diferentes y a las que hay que integrar en el funcionamiento común. Cuando se trabaja con aplicaciones heredadas la posibilidad de disponer a corto plazo de multidioma es, en el mejor de los casos, remota. Pero en las nuevas debería ser un condicionante de diseño. Y recuerde que el multidioma es de tres tipos:

De literales en los componentes de presentación. De contenidos de base de datos. De formato de presentación de los campos: número de enteros y de decimales

(ligado a la moneda y minimizado con la llegada del euro), coma o punto, etc. Siempre que pueda, aproveche las posibilidades que le ofrezca el entorno de desarrollo que utilice.

8. La codificación histórica heredada. Es frecuente que los nuevos sistemas distribuidos que va a aprender a diseñar sustituyan o complementan a otros antiguos en los cuales las principales entidades de la compañía (clientes, productos, etc.) ya tengan un código dentro de una codificación "de siempre". Estos códigos, si son antiguos, tendrán una semántica condensada, es decir, serán cortos y dentro del código estarán atributos de clasificación (familia, grupo, zona, etc.). Es más que probable que lo que convenga es recodificar.


Llegado a este punto, ¡Houston, tenemos un problema! Además grave. Porque el problema no se reduce a cambiar el fichero maestro, sino que podemos tener una colección de problemas de muy difícil gestión. Puede escogerlos entre el siguiente menú:

Ampliación de campos, que obligará a redefinir formatos de ficheros (a lo mejor no hay ni BD) o de tablas. Y compilar programas claro.

Necesidad de duplicar los atributos de clasificación dentro del código como atributos independientes para poderlos gestionar bien en las bases de datos.

Que hacer con la información histórica: reconvertir códigos, eliminar a partir de una fecha, etc.

Convencer a todos los usuarios de la necesidad del cambio. Pactar los nuevos códigos. Repasar todos los programas (¡todos!) de la instalación, probarlos y mantener un tiempo el cambio.

Planificación del transitorio (que no le pase nada...) Y un amplio etc. tan largo como quiera.

¿Que hacer? Recodificar siempre. ¿Cómo hacerlo? No hay, desgraciadamente ninguna solución mágica. No le darán tiempo desde Dirección ya que el trabajo no aporta valor añadido, según ellos, claro está. Pero le pedirán los resultados como si ya hubiera hecho el cambio. Créame, lo he vivido varias veces. En fin, siento traer malas noticias, pero tiene un gravísimo problema si está en esta situación. Dentro del apartado de codificación existe otro problema que si puede controlar: la necesidad de codificación distribuida según como sea el modelo de datos final. Este tema esta muy relacionado con replicación y mantenimiento distribuido y lo trataremos específicamente más adelante.

9. Otros condicionamientos de datos.

9. 1. Las obligaciones de la empresa respecto a la Ley de protección de

datos. Según el grado de seguimiento a que la organización usuaria de la aplicación este obligada, puede condicionar muchas cosas. Si le dice que “pase de ella”, obtenga un documento por escrito de esa decisión.

9. 2. Necesidad de registro. Es decir, la obligación de registrar en todos (raro) o algunos nodos (más habitual) el intercambio de documentos o interfaces. A cada operación de estrada o salida registrada habrá que asignar un número certificado y una descripción completa. Es el concepto equivalente al registro de la administración pública de la que todos hemos sido en algún momento usuarios. Es un problema equivalente, informáticamente hablando, a la codificación distribuida.


10. El factor humano. Y por encima de todo tenemos personas, nuestros sufridos y tiranos compañeros de viaje. Aquí tendrá tres bloques de condicionantes: 10. 1. El estado anímico de la organización.

Poco podrá hacer aquí ya que dependerá de factores externos a usted. Pueden generarle situaciones del tipo:

Resistencia al cambio para “castigar” a la Dirección. Esta actitud será frecuente su sistema de información llega a franquicias, en empresas con problemas o en aquellas en que la nueva aplicación amenaza puestos de trabajo...

Que el usuario “pase” de la nueva aplicación y que al menor problema llame al servicio de soporte y “grite” problema.

10. 2. El nivel de los usuarios.

Y no estamos hablando solo informático sino humano. Puede tener usuarios muy buenos en su trabajo pero que cuando se enfrenta a procedimientos organizativos reorganizados o nuevos, y todo sistema de informático los lleva implícitos, se ahogan. Obviamente, no los va a cambiar a todos. Lo mejor que puede hacer es:

Establecer operativas sencillas y robustas. Formarlos, técnica y anímicamente, minimizando sus miedos.

La formación y la mejora de las operativas tiene una influencia directa: más coste de proyecto. Habrá de negociarlo.

10. 3. La resistencia al cambio. Aquí si puede hacer muchísimo, y con poco coste:

Permita que los usuarios opinen en fase de análisis. A parte que mejorará su trabajo, se implicaran en el proyecto.

Déjeles participar activamente en las pruebas. Apóyelos y motívelos en el arranque.

11. Una reflexión final. El contenido de este capítulo puede producir, en usted lector, dos efectos extremos: desolación o pasotismo. Por favor, no caiga ni en uno ni en otro extremo. No menosprecie el problema pero tampoco se colapse. Estúdielo y busque una solución correcta a los problemas que resulten de ese estudio. Pero en cualquier caso siga mi consejo y no lo ignore.


Componentes Operacionales

1. ¿Qué es un componente operacional?

En los diseños distribuidos existen elementos de utilización sistemática y repetitiva que implementan operativas de funcionamiento siempre necesarias en un buen diseño. Son los componentes operacionales. En este capitulo se van a presentar algunos de los más importantes y utilizados.

2. ¿Porqué usar componentes operacionales? Si los componentes operacionales se usan siempre, la propuesta se hace obvia: construyámoslos de forma que puedan ser reutilizados. Las ventajas son evidentes. 2. 1. Tipificar comportamiento.

Una vez especificados, construidos y probados, los componentes operacionales tipificaran un modelo de comportamiento, funcional y operativo, que facilitará el diseño de nuevas aplicaciones y la explotación de las ya creadas.

2. 2. Unificar criterios de diseño y administración. Todos los actores del sistema de información, personas y programas, trabajan con los mismos criterios, marcados por el comportamiento tipificado en la especificación.

2. 3. Bajar costes de desarrollo. La reutilización permite bajar de forma notabilísima el coste de desarrollo, puesta en marcha y formación. La reutilización de componentes operacionales no es más que una aplicación práctica del concepto de reutilización.

2. 4. Están probados. O al menos confíe en ello..... No menosprecie esta gran ventaja, no solo por la comodidad sino por la disminución de tiempo de desarrollo que supone. Si trabaja con tiempos pequeños, las desviaciones en los esfuerzos y plazos de entrega (nuestro verdadero cáncer...) serán menos visibles. Un 25% de 4 días es un día, nadie lo notará. Un 25% de 4 semanas es una semana, todo el mundo le preguntará que pasa..... Y es sabido que los retrasos llaman a gritos a los retrasos.

3. Limites.


Pero recuerde que todo tiene ventajas e inconvenientes. La reutilización también. Si Vd. es un habitual de la reutilización ya lo sabe. Pero si no lo es recuerde que si Vd. construye componentes operacionales ha de ser generoso: ha de diseñarlos potentes, robustos... y fiables. Pero no caiga el gravísimo error de querer crear el componente operacional universal y perfecto. La perfección no existe en ingeniería y acercarse a ella es carísimo. Pasado el punto optimo, cualquier generalización se hace costosa y de dudosa reutilización real, disparando costes y plazos. No se le ocurra preguntarme como saber cuando se esta empezando a superar el punto óptimo: no tengo criterios precisos que proponerle, me funciona la experiencia y la intuición (o eso espero). Si consigue una forma de calcularlo racionalmente, por favor, llámeme rápidamente a cobro revertido. Su idea bien valdrá que yo pague la llamada.

4. Una clasificación. Hay varios tipos de componentes operacionales en función de su nivel y función.

Componentes especializados o de primer nivel. Normalmente se integran en el flujo de proceso como servicios síncronos o asíncronos, ya sea pasivos, en fase de link del clientes, o dinámicos como servidores independientes. Implementan servicios de:

De lógica presentación. De lógica de datos. De lógica de negocio. De control de procesos.

Componentes de gestión o Framework o componentes de segundo nivel, que implementan:

Procesos de gestión, como un mantenimiento estándar de tablas o una gestión de documentos con cabecera y detalle.

Procesos de negocio, como un proceso de intercambio de documentos. Agentes operacionales. Se especializan en servicios activos complejos con arquitecturas basadas en muchas ocasiones en arquitecturas de agentes.

Aunque todos son importantes los hay que están más dirigidos a la implementación que al diseño. Vamos a hablar aquí, principalmente de aquellos que hacen referencia a este último apartado.

5. Componentes operacionales más importantes en el diseño. Como ya hemos dicho, los componentes operacionales pueden diseñarse para infinidad de funciones. Este capítulo podría llegar a ser un libro por si solo. No pretendo hacerlo. Voy a limitarme a introducir aquí componentes que la experiencia me ha demostrado que juegan en el diseño en todos los sistemas distribuidos importantes en los que he participado. Además, los utilizaré dentro de la metodología propuesta en los capítulos de diseño y en los ejemplos propuestos. Me facilitarán el trabajo y les ayudarán a ver su utilidad.


Son componentes operacionales habituales: Componentes de control de procesos.

Semáforos. Colas. Ticket.

Agentes operacionales: Servidores de Impresión Servidor de Correo. Servidor de Notas y Avisos. El cartero. Vigía. Disparador. Cargador, etc.

Se incluye a continuación la especificación y utilidad de los cuatro primeros. El servidor de Correo, el Servidor de Notas y Avisos, y el resto de los agentes operacionales se reservan para el capítulo siguiente. Se proporcionan también algunas ideas sobre su implementación aunque, como he repetido varias veces, este no es un libro de programación sino de diseño.

6. Tecnología de implementación de Componentes Operacionales. No se lo piense. Utilice técnicas de Orientación a Objetos (OO) o como mínimo Tipos Abstractos de Datos (TAD). Los servicios proporcionados por el componente se integrarán en métodos (OO) u operaciones (TAD). Encapsule los atributos con métodos.

7. Modelos de integración de componentes operacionales de primer nivel.

Existen dos formar de integrar componentes operacionales de primer nivel en las aplicaciones distribuidas: 7. 1. Estática.

Con el programa, normalmente un servidor o un agente, en fase de link. Este modelo es en la práctica poco eficiente ya que el programa debe dejar de hacer su trabajo para atender a las funciones del componente operacional. Pero no se confunda, aunque la implementación estática sea poco eficiente, puede ser la solución válida en un diseño. Además, las técnicas multihilo pueden ayudarle a paliar en gran parte ese problema. Defina un servicio con dos hilos, uno que atienda el servicio en sí y otro que atienda la gestión del componente operacional.

7. 2. Dinámica. Montando el componente como un servidor independiente.


Este modelo, de mayor coste tecnológico, permite autonomía y accesibilidad total. Prímelo.

8. Semáforos. 8. 1. Qué es un semáforo.

Un semáforo es un componente operacional que puede estar en dos o tres estados. Su nombre responde a su paralelismo con la luces de tráfico.

Al contrario que en el mundo real, los tres estados son excluyentes, no se recomienda que se den simultáneamente.

Un semáforo se representará en adelante por los símbolos de la figura.

Sus estados se referenciarán como rojo y verde en semáforos de dos estados y como rojo, amarillo y verde. Para mantener el paralelismo con los semáforos de nuestra vías públicas, el estado de rojo se suele reservar para ocupado (no disponibilidad) y el verde para libre (disponible).

Los semáforos habituales son de dos estados. Cuando se utilizan semáforos de tres estados, el ámbar suele reservarse para usos especiales del programa.

8. 2. Uso de los semáforos Un semáforo es un componente operacional utilizado para determinar la disponibilidad y/o estado de una situación o recurso. Es un componente que tuvo gran importancia en los tiempos heroicos de las primeras aplicaciones C/S para conocer la disponibilidad de recursos que habían de compartirse entre diferentes actores de la arquitectura C/S distribuida. Con la evolución de las aplicaciones distribuidas, la integración y gestión de la disponibilidad de estos recursos la ha asumido el Middleware y los semáforos han limitado prácticamente su ámbito de actuación a la determinación de estados. Por ejemplo, un semáforo será útil para saber si una conexión está disponible o no. Así, si al acceder a un nodo del sistema distribuido se encuentra que la conexión “ha caído”, todos los recursos localizados en ese nodo habrán dejado de estar disponibles. La aplicación activará un semáforo de forma que esa información sea conocida por todos los actores de sistema distribuido. Cada actor actuará en consecuencia con la situación y su especialización. Cuando alcance el capítulo de análisis de consistencia encontrará ejemplos de aplicación de semáforos.

8. 3. Servicios habituales. Los servicios habituales en un semáforo son:

Figura 1. Representación

de semáforos


Inicialización. Cuando instancíe el objeto, coloque como estado inicial rojo. El paso a verde deber ser una operación plenamente consciente, realizada (evidentemente) justo después de la instalación.

Colocar color. La pregunta: ¿cual es tu estado?

8. 4. Semáforos con etiqueta.

En muchas ocasiones no basta con saber si un semáforo está ocupado o no. Es necesario saber también quien lo ocupa. En este caso utilice la técnica de ocupación personalizada en la cual el estado de rojo lleva asociado tres atributos:

Referencia del ocupante, normalmente, en entornos de comunicación cliente / servidor, la del cliente o servidor.

Hora en que se ha realizado la reserva. Tiempo máximo de reserva.

La existencia de estos dos atributos le permitirá mucho juego. Por ejemplo le permitirá aplicar procesos de recuperación del tipo:

Si un semáforo ha quedado ocupado por un cliente o servicio, si el mismo elemento vuelve a pedir el recurso, se le puede dar acceso evitando el bucle. Así, si un semáforo recibe una reserva de un cliente que ya lo está reservando le dará entrada asumiendo que es una recuperación.

Si el elemento que ha hecho la reserva “cae”, no realizará la liberación y por tanto el recurso puede quedar eternamente ocupado. La presencia de los atributos “hora de reserva” y tiempo máximo de reserva” permiten, transcurrido el tiempo máximo de reserva, que el semáforo se auto libere automáticamente.

Si se usa el atributo de referencia del elemento que realiza la reserva, este dato se incluye en la petición de reserva del semáforo. Cuando el semáforo da la respuesta de que está ocupado, puede devolver la referencia del elemento que lo esta haciendo y el tiempo máximo que tardará en liberarlo.

9. Ticket. 9. 1. ¿Qué es un Ticket?

Si usted lector tiene tan mala memoria como yo, cuando debe hacer varias gestiones durante una jornada, se las anotará en una lista. Muchas veces incluso utilizará la lista para establecer un orden de realización. A medida que vaya resolviendo los asuntos de la lista ira colocando una marca sobre la gestión que ya ha realizado. En todo momento la lista le dará información de qué ha hecho y de qué no y sabrá que ha acabado en el momento que todas las líneas de la lista tengan su correspondiente marca. El componente operacional Ticket en el mundo de las aplicaciones distribuidas no es ni más ni menos, que eso.


9. 2. ¿Un nombre desafortunado? Cuando después de mis primeras experiencias C/S a primeros de los 80, vi la necesidad de tipificar este componente operacional decidí ponerle el nombre de ticket. Con este nombre escribí especificaciones, formé a mi equipo y lo usamos en nuestras aplicaciones. A los pocos meses, empezamos ha desarrollar proyectos para la gestión de puestos de venta al público al por menor. Y resultó que ha cada cliente se le entrega un comprobante de su compra que se conoce como..... ¡Ticket! Nos encontramos que nuestro ticket y su ticket sonaban igual, lo que nos creo algunos problemas para saber de cual de los dos hablábamos. Todavía hoy no entiendo como no cambié el nombre. Hoy día tengo tanta documentación con este nombre que cambiarlo ya me parece un imposible. Y me da una pereza horrible.

9. 3. Uso de los tickets. Los tickets se usan fundamentalmente en un diseño distribuido para tres funciones básicas:

9.3.1. Conocer es estado de cada proceso. Si se ha realizado y como ha acabado.

9.3.2. Coordinar lógica de ejecución de procesos.

Los diferentes procesos consultarán el ticket y según los estados que encuentren ejecutarán o no funciones.

9.3.3. Asegurar coherencia y garantizar integridad. Así, por ejemplo un proceso de seguridad centralizado no se iniciará hasta que un todos los puestos de trabajo cliente no hayan “depositado” sus copias en el servidor sobre el que se va a desencadenar el proceso de copia de seguridad centralizado. En este punto el uso de tickets da mucho juego como se verá en el capítulo dedicado a back-up.

En general, el uso habitual de los tickets es el control de la lógica de la parte cliente de la aplicación distribuida

9. 4. Elementos fundamentales de un ticket.

Los tickets van a ser representados en todo este trabajo con el símbolo de la parte superior de la figura de la izquierda. Conviene programar un componente ticket lo más general posible lo que da pie a intentar analizar que puede haber de común a diferentes tickets. Un ticket puede ser visto como una rejilla en que la primera columna representa las

Situación EstadosX

X

X

X Figura 2. Representación de

un Ticket


diferentes situaciones o procesos a controlar y el resto codifican los diferentes atributos. Dentro de las casillas se codifican los estados que se ligan a cada situación. Las situaciones se referencian por un código y se le añade una descripción. Los estados pueden ser de:

Dos posiciones: hecho o no hecho Evolutivos, siendo modificados a medida que las evolución de los procesos avanza. Así por ejemplo, una posición del estado podría indicar que no se ha iniciado todavía el proceso, otra que se ha empezado pero no acabado, otra que ha finalizado correctamente y, finalmente, una cuarta puede usarse para indicar que el proceso ha acabado erróneamente.

9. 5. Servicios habituales.

Son servicios habituales en un ticket:

9.5.1. Estructurales.

Añadir una nueva situación. Borrar una situación existente. Añadir una nueva columna de estado incluyendo sus limitaciones de valor Borrar un estado existente.

9.5.2. De gestión.

Consultar un estado de una situación. Modificar un estado de una situación. El ticket comprobará la integridad del nuevo estado con los valores proporcionados en la definición del estado. Iniciar todo un estado del ticket con un mismo valor del estado para todas las situaciones. Preguntar si todas las situaciones de un mismo estado están a un valor determinado.

10. Tickets multihoja.


10. 1. ¿Qué es un ticket multihoja?

Imaginemos en funcionamiento el ticket de control de copias de seguridad del apartado anterior. Para conocer si durante el mes todos los usuarios han hecho sus copias sobre el servidor a tiempo, puede ser interesante conservar el ticket de cada día durante todo el mes. Dicho de otra forma, cada día se anotará en una hoja individual y se guardarán las 30 hojas del mes. Eso es un ticket multihoja.

Es decir, un ticket multihoja no es más que un ticket con más de una ocurrencia simultánea.

Un ticket multihoja se representará por el elemento de la figura.

10. 2. Organización de un ticket multihoja. Un ticket multihoja tiene dos partes:

Una cabecera de descripción. Una hoja por ocurrencia. Se ha de establecer una clave para referenciar cada hoja. En el ejemplo anterior puede ser la fecha.

En los métodos de gestión hay que incorporar esa referencia de hoja.

10. 3. Métodos adicionales para tratar los tickets multihoja.


Crear una hoja. Destruir una hoja.

10.3.2. Gestión.

Verificación de un estado en un intervalo de referencias.

11. Colas.

11. 1. ¿Qué es una cola?

Usted lector sabe perfectamente que es una cola: un tipo abstracto de datos (TAD) en el cual el primer elemento que se ha anotado es el primero que se recupera (FIFO: first input, first output). Dicho más literalmente: es un sistema temporal de almacenamiento en el cual los elementos se recuperan en el orden en que han entrado.

11. 2. Utilidad de las colas.

.

Situació EstatsX

X

X

X

Jornada xxxxxxx

Situació EstatsX

X

X

X

Jornada xxxxxxx

Situació EstatsX

X

X

X

Jornada xxxxxxx

Situació EstatsX

X

X

X

Jornada xxxxxxx

Element Descripp

Descripció

Figura 3. Tickets Multihoja


Las aplicaciones distribuidas bien diseñadas deberían hacer un monumento a las colas. No se concibe una aplicación distribuida multicliente sin su existencia, claramente manifiesta a escondida en el Middleware.

Las colas, que representaremos con el elemento de la figura, se utilizarán para colocar en espera peticiones de los clientes a los servidores. Las colas marcan, pues, una frontera pactada entre unos elementos que colocan peticiones (orígenes) y otros que las procesan (destinos). La finalidad de las colas es muy precisa pero

como veremos más adelante esta llena de matices interesantísimos. Muchas veces son utilizadas también como deposito intermedio de información.

11. 3. ¿Utilizar colas de Middleware o crear colas propias? Como usted amigo lector ya ha deducido, me declaro un fan apasionado y fanático del Middleware. Pero hasta eso tiene excepciones. Para mi las colas es uno de los casos más claros. Compare las prestaciones de las MOM (Message Oriented Middleware) implementación de las colas en el Middleware con las prestaciones de una cola que yo deseo tener en mis diseños y que le propondré a continuación. No olvide, además, la poca estandarización real del Middleware MOM. Y, finalmente, créese su propia opinión. Además las colas es un componente agradecido: con poco esfuerzo puede crear objetos cola muy generales y con muchísimas prestaciones.

11. 4. Estructura básica de una cola. Una cola está formada por un conjunto de anotaciones que se recuperan en el mismo orden que han sido anotadas. Cada anotación recoge un mensaje, petición + respuesta. El formato de las anotaciones depende del mensaje del que se necesita disponer. Pero todas las colas tienen el mismo funcionamiento y descodificar el formato del mensaje no es función de la cola sino de los programas que anotan las peticiones y proporcionan las respuestas. La experiencia confirma lo que el sentido común indica: es posible implementar un componente cola independiente del formato de la anotación. Para ello basta observar que todas las anotaciones de cualquier cola tienen unos atributos comunes (referencia, fecha y hora de la anotación, etc.) que determinan claramente la anotación y otra parte, de longitud variable, que depende del mensaje pero que es transparente a la cola en si misma. Diseñe y programe su componente cola así:

Unos atributos básicos y una zona “sin formato” de longitud opcional.


de una cola


Instancíe su objeto cola para cada caso con los atributos básicos y proporcione una longitud adicional variable para contener los mensajes en función del diseño.

Un sólo objeto cola le permitirá cubrir todos los casos.

11. 5. Atributos básicos de una cola. En lo que resta de capítulo y para facilitar la comprensión se referirá como cliente al programa que anota la petición del servicio y como servidor el programa que proporciona la respuesta. Más adelante se verá que en la posición del cliente puede estar otro servidor o un agente (cosa habitual) y que en la posición del servidor puede haber un cliente (cosa sin embargo no habitual) o un agente. También se hablará genéricamente que el servidor proporciona una respuesta aunque en algunos casos esta respuesta sea simplemente decir que ya ha hecho el servicio que se le ha solicitado. Le recomiendo incluya en su componte cola como mínimo los siguientes atributos:

11.5.1. Referencia de la anotación. Será responsabilidad de la cola. Deberá tener dos partes: un identificador de la cola y un número secuencial. Es la referencia común que utilizaran todos los elementos involucrados en la comunicación.

11.5.2. Destino (servicio).

Normalmente la referencia lógica del servicio. La proporciona el cliente. Es la referencia del servicio. Permitirá colocar en una misma cola anotaciones para más de un servicio. Esta opción puede permitirle hacer aplicaciones más compactas y rápidas.

11.5.3. Servidor o agente que la atiende. Se coloca cuando el proveedor del servicio se hace cargo de la petición. Permite que varios servidores atiendan el mismo servicio.

11.5.4. Origen (cliente). Normalmente la referencia del cliente. Permite a los peticionarios conocer que la respuesta es para ellos. A veces el servicio puede cambiar el origen (destino a la respuesta) para redirigir un mensaje.

11.5.5. Referencia del cliente. Será responsabilidad del cliente. Tendrá también un identificador del cliente y un número secuencial.

11.5.6. Referencia del servidor o agente. Será responsabilidad del proveedor del servicio. Tendrá también un identificador del proveedor y un número secuencial.


11.5.7. Fechas y horas.

Incluya:

Fecha y hora de la anotación. La asignará la cola en el momento de anotar Fecha y hora de inicio del servicio. La asignará el servidor cuando empiece a atender la petición. Fecha y hora de fin de servicio. La anotará el servidor cuando deje la respuesta en la cola o haya acabado el servicio si este no necesita respuesta. Fecha y hora de captación de la respuesta. Es quizás la menos interesante de todas. La anota el cliente cuando se hace cargo de la respuesta.

11.5.8. Prioridad.

Aunque el funcionamiento de la cola es siempre FIFO conviene que su cola tenga un atributo de prioridad que permita a su diseño adelantar si es necesaria la ejecución de peticiones. No haga una prioridad demasiado amplia. Normalmente basa con un dígito de 0 a 9. Haga lo lógico, que 9 sea la más prioridad más alta. Y no abuse en su uso.

11.5.9. Estado. Codifique como mínimo los siguientes estados:

Pendiente. En proceso. Acabada sin error. Acabada con error. Recogida por el cliente. A veces se denomina a este estado “acabado”. Baja. Normalmente no estará reorganizando la cola constantemente. Este estado le permitirá saber que en el siguiente proceso de compactado de la cola la anotación es eliminable.

11.5.10. Calificador.

Le permitirá colocar en una misma cola anotaciones de procesos o servicios diferentes.

11.5.11. Caducidad y forma de eliminación de la anotación. Guardar las anotaciones de la cola un cierto tiempo puede ser útil a los responsables de su administración para analizar situaciones históricas. Las anotaciones guardadas asumen el rol de un loging. Si se necesita esta posibilidad, para gestionarla se necesita introducir dos atributos:

Tiempo que la anotación ha de permanecer en la cola.


Forma de eliminación (inmediata, diferida, etc.)

11.5.12. Longitud del mensaje. Longitud útil de la zona del mensaje. Opcional y solo de interés para minimizar los tiempos de “administración” de la cola eliminado la gestión de la parte del mensaje no utilizada en cada caso.

11. 6. Dinámica de las referencias. Las referencias se gestionan dinámicamente en paralelo con la gestión de cada anotación. En la figura se muestra la dinámica de referencias habitual. Veremos más delante que esta dinámica es fundamental en la gestión de temas tan importantes como el diseño de la consistencia. Cuando el cliente solicite al servidor la anotación de un mensaje proporcionará su referencia de cliente. La cola, una vez anotado el mensaje, devolverá, además de la referencia del cliente, la referencia asignada a la anotación en la cola. El cliente utilizará esa referencia de anotación para cualquier operación posterior que necesite realizar con su mensaje. La referencia del proveedor del servicio la asigna éste cuando pide una anotación a la cola para gestionar. La conoce el cliente de forma estática o la obtiene de forma dinámica en la respuesta a la anotación. Intercambie en todos los diálogos la doble referencia, cliente y anotación, ya que así podrá garantizar en todo momento la integridad, seguridad y fiabilidad del diálogo.

11. 7. Recomendaciones de implementación.

Defina una cola genérica con el comportamiento básico. Si lo necesita, derive del comportamiento básico comportamientos especializados.

Siempre que pueda implemente con OO. El comportamiento básico se encapsulará en un objeto y utilizando herencia y polimorfismo obtendrá fácilmente los comportamientos especializados.

Organice, como ya hemos comentado, la anotación en dos partes: Datos comunes básicos: referencias, fechas, estados, prioridades, calificadores,........

.

Cliente

Proveedor del Servicio

Petición de anotaciónReferencia del cliente1

Aceptación de anotaciónReferencias de cliente y de anotación2

Petición de una anotaciónReferencia Proveedor3

Asignación de una anotaciónReferencia de proveedor y de anotación.

4

Figura 5. Dinámica de referencias


Zona de mensaje, que será especifica de cada servicio.

11. 8. Formas de implementación: persistencia y organización interna. Las colas pueden ser persistentes o no persistentes. Una cola es persistente cuando las anotaciones se mantienen permanentemente cualquiera que sea la evolución de la explotación. La persistencia de una cola se dice que es totalmente tolerante a fallos, “full tolerance”, si la coherencia de la cola se mantiene aún en el caso de averías de la plataforma y caídas de los servidores. La persistencia de una cola obliga a grabarlas sobre disco, normalmente como un fichero. La ocupación de una cola es básicamente el resultado de multiplicar el número máximo de apuntes que se quiere permitir por la longitud de cada anotación. Siempre que sea posible, y normalmente hoy día lo es, debe montarse parcialmente sobre memoria (continuación explicaré que entiendo por parcialmente). Si no cabe en memoria interna, el fichero que la implementa sobre disco ha de ser necesariamente indexado por el número de anotación. Si la cola ha de ser totalmente tolerante a fallos y usted dispone de ordenadores convencionales estará obligado a registrar cada cambio de la cola sobre disco. Para tener tiempos de respuesta adecuados deberá programar su cola con alguna técnica especial. A continuación le propongo una que me ha demostrado ser muy eficaz.

11. 9. Implementación parcial sobre memoria. Para conseguir eficacia en la implementación de la cola de gran número de anotaciones deberá combinar técnicas de memoria con otras de disco. Mi experiencia me dice que se consiguen rendimientos aceptables montando la cola parcialmente en memoria. Veamos que quiere decir “parcialmente”. Si su cola esta matizada por prioridad y calificador ha de contemplar la posibilidad, que además será la situación más habitual, que las anotaciones no se eliminen secuencialmente. Ello le impedirá montar colas circulares. Una buena solución puede ser:

Organice un fichero de acceso directo sobre disco, dimensionado para el número máximo de registros que desee en la cola.

A la anotación en el fichero se le añaden: Dos cursores: uno que apunta al registro anterior y otro que apunta al siguiente.

Un indicativo de si el registro está ocupado o no. Cree dos zonas de memoria:

Cabecera de anotaciones: con los datos básicos de acceso al apunte, número de anotación, fechas y horas, prioridad y calificador como mínimo. Un puntero apuntará al registro físico asignado a la anotación en el fichero de acceso directo.


Ocupación del fichero de acceso directo en disco donde existirá una marca por cada fichero físico donde se anotará si el registro está ocupado o libre.

Organice el acceso sobre la cabecera y la persistencia sobre el fichero. En la zona de cabecera las anotaciones se realizan por orden de llegada. El registro físico de la anotación en el fichero se determinará sobre la zona ocupación. El registro físico asignado se colocará en la anotación correspondiente de la zona de ocupación. Se modificarán adecuadamente los cursores que apuntan a la anotación anterior y siguiente.

Se distinguirán dos operaciones diferentes: la baja (simple cambio de estado) y la eliminación del la anotación.

Cuando se elimine la anotación, se compactará la zona de cabecera, se marcará el registro físico como libre en la zona de ocupación y no se alterará ni eliminará el registro físico (lo único que sería realmente lento) y se modificarán adecuadamente los cursores de los registros correspondientes a las anotaciones anterior y posterior.

Cuando se cierre la cola o se produzca algún fin anormal, se perderán las zonas de memoria pero se garantizará la persistencia con un índice de fiabilidad suficiente.

Cuando se inicialice la cola, se habrán de regenerar las zonas de memoria.

Finalmente, la cola deberá incorporar un método para compactar la cola periódicamente o por petición.

Un consejo: no abuse de la implementación totalmente tolerante a fallos. En muchos casos, basta con implementar la cola sobre memoria, compartida o no.

11. 10. Métodos del comportamiento básico. Son servicios habituales en una cola:


Instanciar una cola para una longitud de mensaje determinada.

11.10.2. De gestión.

Insertar una nueva anotación. Borrar una anotación. Modificar una anotación. Cambiar el estado de una anotación (opcional, puede usarse el método anterior). Consultar una anotación por referencia de anotación. Consultar el estado de una anotación (opcional, puede usarse el método anterior). Seguimiento secuencial: Situar primera anotación. Leer la siguiente anotación: devuelve como parámetro “fin de cola” cuando no quedan apuntes.

11.10.3. Tratamiento de la persistencia.

Cargar la cola en memoria.


Descargar la cola (sólo en algunas implementaciones, no en las implementadas parcialmente en memoria). Compactar la cola (sólo en colas implementadas parcialmente sobre memoria).

Los métodos de consulta y recorrido de la cola están parametrizados por la prioridad, el calificador y el estado si la cola implementa estos atributos.

11. 11. Colas multihilo: multicliente y multiservidor. Que una cola ha de ser multicliente, es decir que las anotaciones puedan ser de más de un origen, es una obviedad. Que sea multiservidor, es decir que admita anotaciones para más de un servidor o destino, una prestación muy útil que se implementa muy fácilmente. Así pues, una cola en un entorno distribuido ha de ser multicliente y multiservidor (multiorigen y multidestino) presentando un modelo de funcionamiento como el de la figura.

Pero existe otra posibilidad: que un mismo servidor pueda tener más de una copia simultánea atendiendo sus peticiones.

Se dice entonces que el servidor es multihilo o multihebrado y cada copia arrancada es una hebra o un hilo.

Como es evidente el tema del multihilo abre la puerta a dos posibilidades de gran interés:

Aumentar el rendimiento. Adaptar la oferta a la demanda; cuando hay más demanda se arrancan automática o manualmente más hilos.

Pero, como también es muy obvio, un servidor multihebrado no es nada fácil de programar. Los problemas de concurrencia y paralelismo estallan en toda su intensidad. Afortunadamente muchos lenguajes actuales ponen a su disposición recursos para conseguirla de forma muy cómoda. Pero no se confunda: esas técnicas le ayudarán mucho pero no le eliminarán totalmente los problemas del paralelismo y de la concurrencia. Si no es experto en esos temas, valórese seriamente no usarlas. O aprenda. Es muy divertido. De cualquier forma, este apartado no es más que un compendio de temas tratados anteriormente.

12. Las colas como servidores. Como ya le he dicho, las colas han de ser compartidas por más de un cliente y, opcionalmente, más de un servidor simultáneamente. Por ejemplo, un cliente

Destinos

Orígenes

Figura 6. Colas multicliente y

multiservidor


necesita saber si un servidor ya ha acabado de procesar su petición de servicio mientras que otro necesita la cola para anotar una nueva petición.

Si la cola se implementa dentro del servidor, mientras el servidor trabaja no podrá atender las necesidades de sus dos clientes. Como clientes y servidores son programas, el problema que se presenta es el de compartir un recurso por más de un programa. La única solución viable es convertir la cola en un servidor autónomo

que pueden atender las necesidades de información y gestión de los clientes y servidores mientras estos trabajan asíncronamente. Una cola implementada como servidor se representará por el elemento de la figura. La comunicación de los clientes y los servidores con el servidor de cola se resolverá con un mecanismo de middleware síncrono. A ser posible hay que utilizar un servicio estándar como RPC sobre TCP/IP o SOAP. A partir de ese momento, el control del flujo ya lo cogen los clientes y los servidores a partir de las anotaciones de la cola. Estudiemos el ejemplo de la siguiente figura donde se muestra el esquema de diseño de un proceso de replicación asíncrona y en caliente del contenido de una base de datos.

Datos a Incorporar

Servidorde

Replicación

FicherosPendientes

CadenaBatch de

Incorporación

GestorAdministrador

Replica

Internal squema 1Internal squema 1BD

Corporativa

Internal squema 1Internal squema 1BD

Replicada

Consultas deUsuarios

Figura 8. Ejemplo de utilización de un servidor de cola: Anotación y Replicación asíncrona De los procesos externos que generan los datos resultan los ficheros de “datos a incorporar”. Una cadena Batch en el ordenador HOST corporativo filtra, prepara, valida e incorpora la información a las bases de datos corporativas y crea una replica generando una anotación en una cola de “ficheros pendientes de incorporar”.

Nombre y Función del Servidor de

Cola

Figura 7. Servidor de

Cola


Un servidor de replicación incorpora la información a la base de datos replicada de forma totalmente asíncrona. El proceso del HOST puede ser nocturno y el servidor de replicación arrancarse por la mañana cuando empiece la jornada laboral normal. El servidor de replicación anota en un ticket multihoja los ficheros incorporados. Observe la existencia de un programa cliente para la gestión y administración de la cola por el Administrador y de un programa de consulta del ticket para que los usuarios puedan saber si la información esta ya cargada o no. La implementación de estos programas auxiliares puede ser muy diversa. Observe en la figura siguiente como puede ser un la consulta de las hojas de un ticket por un usuario:

Figura 9. Consulta de un ticket multihoja

Observe que este es un programa genérico. La imagen de la figura corresponde a un ticket multihoja de una aplicación de incorporaciones a una BD replicada y sumarizada. Los tickets de esta aplicación se estructuran por aplicaciones (ESTADIST) y por ámbitos (DIARIA, MENSUAL). Las referencias son los archivos incorporar. Cada hoja del ticket tiene todos los días del mes. Una rejilla da información de que hay incorporado. Jugando con colores se puede informar del estado de la incorporación de cada archivo y día. En la siguiente figura puede observar que aspecto puede tener un programa de personificación de una cola:


Figura 10. Parametrización de una cola

En la figura siguiente observe el aspecto que puede presentar un programa de consulta del estado de una cola:

Figura 11. Consulta de una cola

Finalmente observe el formato que puede tener la gestión de una anotación de cola con opción a realizar anotaciones manuales:


13. Servidores de Impresión.

Los servidores de impresión independizan las impresoras de los programas permitiendo que sean compartidas de forma transparente a sus características y localización. Esta prestación, que para usted es una obviedad, era un proceso complejo en las primeras aplicaciones C/S.

Se implementan siempre con los servidores de impresión de la red o de los Mainframe y / o máquinas intermedias, como es el caso de UNIX, AS/400, etc. La gestión de los servidores de impresión tiene una operativa muy estandarizada que se va asumir aquí de la forma natural que Vd. utiliza cada día. Si no la conoce puede consultar documentación especializada o consultar el capítulo dedicado a la administración del sistema.

Componentes Operacionales implementados por Agentes

1. El Vigía y el Disparador. Es frecuente en comunicación asíncrona, especialmente si es desacoplada, que servidor o cliente destinatario de la petición de servicio sea avisado para que despierte o se active y haga su trabajo.

Figura 12. Gestión de la anotación en una cola

Figura 13. Servidor de

Impresión


Esta función puede conseguirse por:

Eventos. Un Vigía.

¿Qué es, pues un vigía? Un vigía es un componente operacional, implementado por un agente, que escucha lugares o recursos donde puede llegar un aviso diferente de un evento de sistema. Un vigía puede escuchar de:

Un directorio. Una cola. Un mail. Un semáforo. Un ticket. Etc.

El vigía realizará un ciclo de inspección y reposo analizando si ha llegado un acontecimiento. El vigía lo representaremos por el icono de la figura. Cuando es produzca el evento que el vigía escucha habrá que arrancar el servicio o programa que lo ha de gestionar. De eso se encargar el Disparador, que tendrá un mecanismo parametrizable para lanzar e inicializar clientes, servidores, agentes y servicios de NOS. Obviamente, el disparador puede usarse en entornos sin presencia de vigías. El disparador lo representaremos por el triangulo de la figura.

2. ¿Qué es un Servidor de Correo? En las aplicaciones distribuidas es muy frecuente la necesidad de intercambiar ficheros entre los distintos nodos. Para que el concepto de Middleware continúe vigente este intercambio ha de ser independiente de la plataforma distribuida.

Un Servidor de Correo es un componente de alto nivel que, integrado en el Middleware, esta pensado y diseñado para entregar, tomar y recibir información, normalmente ficheros, intercambiada entre usuarios y programas de forma transparente al sistema, protocolo, aplicación o vía.

Figura 14. Representació

n del vigía


n del disparador


n del Servidor de Correo


El estudio a fondo de un servidor de correo dentro de una formación de diseño distribuido es interesante no sólo por si mismo, si no también porque ayuda a entender algunas de las características fundamentales de este tipo de diseños.

3. Características básicas de un servidor de correo. Las características básicas deseables en un servidor de correo son:

1. Independencia de la plataforma y la infraestructura. 2. Posibilidad de una gran número de vías de conexión y abierto a implementar

de forma cómoda nuevas vías. 3. Posibilidad de iniciar la transmisión desde el origen o desde el destino según

convenga. 4. Gran facilidad de uso. 5. Posibilidad de arrancada manual, planificada o desde otros programas. 6. Auto corrección de errores según parámetros. En particular debe incluir

reintentos y posibilidad de reiniciar la transmisión desde el punto en que ha caído.

7. Posibilidad de gestión configuración y gestión de errores centralizada. 8. Recursos para garantizar la integridad de la información y la seguridad de

acceso contra usuarios no autorizados. 9. Posibilidad de caminos de más de un paso.

Y por encima de todo, ser totalmente tolerante a fallos (full tolerance). Hay que tener la certeza absoluta de que el mensaje llega a destino y en caso de imposibilidad seguridad absoluta de que se avisa del error al librador del mensaje. Todas estas características se irán presentando y ampliando a lo largo del presente capítulo.

4. Arquitectura del servidor de correo.

La plataforma se organiza en nodos donde se sitúan los programas y usuarios origen y destino de los intercambios. Lógicamente los nodos pueden ampliarse, eliminarse o cambiarse de forma totalmente flexible por el administrador del sistema distribuido. Los usuarios se localizan en esos nodos. Existen nodos especializados donde se sitúan recursos de gran capacidad para canalizar

el transporte y conseguir mayor eficacia. Estos nodos especializados son los distribuidores. De los distribuidores pueden colgar opcionalmente usuarios

Usuarioo Usuario

NODO

Distribuidor

NODO

Usuario Usuario

NODO

Usuario Usuario

Via alternativa

de seguridad

DistribuidorVia de gran capacidad

NODO

Usuario Usuario

Figura 17. Arquitectura básica de un servidor de correo.


Nodos y distribuidores están conectados entre si por vías o canales de comunicación. Así pueden ser vías de intercambio: la red local, la red conmutada de teléfonos, protocolos del tipo X25, Internet e Intranet, SNA, IPX, TCP/IP, FDDI, ATM, etc. Entre los nodos puede existir más de una vía de conexión. Por ejemplo, una principal y otra alternativa a utilizar cuando falle la principal. El camino de un nodo a otro puede incluir otros nodos. Cada transporte lleva anotado el origen y el destino. Cuando el nodo origen inicia el transporte consulta una tabla de conexión donde se informa del primer nodo a visitar para llegar al destino. El nodo origen envía el transporte a ese nodo. Cuando un nodo recibe un transporte consulta el nodo destino. Si es él mismo se queda el transporte y lo envía al usuario de su nodo que constituye el último punto de destino. Sino es para él, consulta en su tabla de conexión a que nodo ha de enviar el transporte para alcanzar el nodo destino y le envía el transporte. Evidentemente, todo el proceso es automático, desatendido y con tolerancia total a fallos. Una solución para interconectar dos grandes ciudades puede ser establecer un distribuidor en cada ciudad. Conectar los nodos de cada ciudad a su distribuidor y establecer una vía de gran capacidad de tráfico entre los dos distribuidores. Una vía alternativa de seguridad entre dos usuarios situados uno en cada ciudad puede establecerse a través de una conexión por directa por red conmutada entre los dos nodos. Lógicamente las vías de seguridad sólo se establecerán entre los nodos en los cuales haya usuarios que por su función dentro del sistema distribuido no pueden quedar aislados. Observe, finalmente, que el servidor de correo es un servicio simétrico, es decir, en cada nodo debe existir un servidor de correo que recibirá o canalizará el tráfico de su propio nodo.

5. Operativa básica de un servidor de correo.


¿Como debería de funcionar un servidor de correo? El funcionamiento básico se esquematiza en la figura. En cada nodo se arranca una instancia del servidor de correo. Cada servidor tiene una lista de anotación y un buzón donde se deja el fichero a transportar.

Normalmente la implementación del buzón y la lista es una cola de distribución. Cuando, en función de los parámetros de envío, se inicia la transmisión, el servidor localiza la vía por la que debe de enviar el mensaje. Cada vía se encapsula en un router que es el que utiliza el servidor para la salida del mensaje. Disponer de nuevas vías no supone más esfuerzo que incorporar un nuevo router, programado o comprado. El servidor del nodo destino recibe por el router el transporte y lo anota en su cola de distribución, de donde puede ser recuperado por el usuario destino. Evidentemente, si el camino de transporte incluye más de un nodo, el servidor realiza la operativa de reexpedición explicada en el apartado anterior. La anotación puede ser de dos formas:

Anotación directa a través de un programa especializado que incluye el servidor de correo.

Anotación desde un programa cliente a través de API’s. El inicio puede ser:

Manual. Automático e inmediato. Planificado. Por ejemplo, cada hora.

Existen tres funcionamientos básicos: 5. 1. Envío.

El cliente realiza la anotación y entrega el fichero.

5. 2. Recepción. El cliente anota una petición de recepción. El servidor queda a la espera de la llegada.

Inicio Directo

Arrancadaplanificada

APLICACIÓN

Comunicaciónde aplicación

Servidor

ORIGEN

R

U

T

E

R

VIESTCP/IPTeléfonoInternetX25,X28,X32TCP/IP+ SOAPIPXSNAFDDI, TAMetc ....

R

U

T

E

R

Servidor

DESTÍNOAPLICACIÓN

ERRORES ERRORES

Administración del sistema

Figura 18. Funcionamiento básico de un Servidor de

Correo


5. 3. Captura. El cliente anota una petición de captura de un fichero de otro nodo. El servidor de su nodo envía una petición al servidor del nodo origen. Este inicia el envío. Evidentemente el cliente origen ha de haber anotado el fichero. Sino es así, servidor del nodo origen devuelve una condición de error. El servidor destino repetirá la petición según sus condiciones de parametrización.

La gestión de errores se explicará más tarde. Solamente citemos aquí que después de los reintentos y recuperaciones personificadas, el servidor tiene la posibilidad de enviar mensajes de error a un puesto de control de errores centralizado.

6. Posibilidades de parametrización. Como ya se ha visto las posibilidades de un buen servidor de correo deben permitir establecer estructuras de funcionamiento como las de la figura. Para conseguirlo el administrador del sistema deberá:

Codificar los nodos. Personificar el servidor que se arranca en cada nodo.

Informar de las vías de comunicación disponibles entre los nodos, personificando los routers.

Definir los usuarios y programas clientes.

Informar de los enlaces permitidos entre los nodos, lo que equivale a informar la tabla de distribución.

Informar los parámetros de auto corrección.

Y un largo etc.

7. Posibilidades de administración. Las posibilidades que el servidor de correo debe dar al administrador del sistema distribuido para personificar y administrar el sistema son:

Codificar las vías de salida de que dispone cada elemento de la plataforma. Identificar a cada usuario por un código. Permitir asignar permisos de acceso a cada usuario. Escoger las vías de acceso, principal y alternativas, entre cada nodo / usuario que estén autorizados a comunicarse. Cada camino puede ser directo o a través de otros nodos.

Poder definir por cada destino el número de reintentos a realizar y los criterios de gestión automática de errores.

Definir los parámetros de la cola de distribución. Cuando cambie una vía entre dos nodos todos los usuarios afectados deben quedar automáticamente redefinidos.

U1

U2

U1

U3

U2

U4 U5 U6

U3

U1 U2

U4

U5

U6

U7

U8U14

U16

U15U9

U10 U11 U12 U13

U1

U2

U3 ___ conexión normal

___ conexión alternativa

Figura 19. Posibilidades de parametrización de un

Servidor de Correo


Si se utiliza la opción de control centralizado de errores, se habrá de definir el funcionamiento de la opción para cada mensaje.

Limitar las posibilidades de funcionamiento para cada usuario en función de sus necesidades y derechos en el sistema distribuido.

Y otro largo etc.

8. Características del transporte. Como ya se ha visto el transporte tiene dos partes, la anotación y el contenido. El contenido es un fichero del cual el Servidor de Correo no necesita conocer nada más que el path de origen y el de destino. En cuanto al formato de la anotación, si se recuerda que normalmente se trata de la anotación en una cola, no hace falta nada más que repasar en el capítulo anterior como es el formato de una anotación en una cola. Además del origen y del destino, atributos como prioridad y calificador son de gran interés en un servidor de correo. En especial, el calificador, que permite identificar dentro de cada usuario destinos particulares, se ha revelado de gran interés en un servidor de correo eficiente.

9. El Servidor de Notas y Avisos. El servidor de notas y avisos es un caso especial del servidor de correo en que el contenido del transporte en una nota o un aviso para un usuario. Además de las prestaciones normales de un servidor de correo, de las que solo se necesita la opción de envío, se necesita la opción de, en el momento de la entrega, poder interrumpir al usuario si la urgencia del mensaje así lo requiere. La implementación del servidor de correo y del de notas y avisos suele ser la misma. Si la base es el servidor de correo, el de notas y avisos puede implementarse montando el mensaje en una variable de tipo registro y grabando un fichero con ella. El calificador servirá para diferenciarlo. Si la base es el servidor de notas y avisos, el de correo se implementa utilizando la opción de incluir un mensaje en el fichero. A efectos de diseño conviene diferenciar el servidor de correo del de notas y avisos ya que su función es diferente.

Representaremos al servidor de notas y avisos por los elementos de la figura, reservando el de la derecha para indicar que el mensaje interrumpirá al destinatario. Todo lo que sigue es de interés para ambos tipos de servidores. Los servidores de notas y avisos son fundamentales en las aplicaciones distribuidas desatendidas. Imagine que tiene una conexión desatendida, vía

Figura 20. Representación del

servidor de Notas y Avisos


FTP, con un proveedor, Por ella este último le envía los albaranes. Usted necesita atender los albaranes tan pronto lleguen para tener su stock al día. Para resolver esta problemática montaríamos un proceso desatendido que estuviera escuchando al vía FTP. Cuando llegarán los albaranes se procesarían automáticamente y, mediante el servidor de avisos, se notificaría al responsable del proceso de la llegada. Puede extender el proceso a la recepción de las facturas. El proceso de conformación se puede disparar también automáticamente a la recepción de la factura electrónica mediante un agente. Si tanto si es aceptada o rechazada, se avisará la proveedor y al responsable interno mediante el servidor de notas y avisos. Otro uso habitual es informar de resultados de controles preventivos. Por ejemplo, se puede montar una inspección automática y de la ocupación de disco de un nodo y generar con el servidor de notas y avisos un mensaje al administrador de sistema cuando la ocupación está por encima de un tope de seguridad convenido. Un tercer uso es enviar avisos al cuadro de mandos.

10. El cartero. El cartero es un componente operacional que utiliza sistemáticamente el servidor de notas y avisos y que se encarga de repartir un aviso a una lista de usuarios de forma automática. Necesita:

La guía de usuarios donde esta la dirección de acceso, normalmente la de correo. Se recomienda aprovechar alguna entidad ya existente.

Las funciones que pueden usarlo. Por ejemplo, la llegada de albaranes de un proveedor, la finalización de procesos Bach, etc. Suele incluirse una especialización de función que permite afinar el envío. La especialización puede, por ejemplo, dentro de la llegada de albaranes ser el proveedor de origen, posibilidad que permite enviar el aviso a los responsables de cada proveedor.

La relación funciones-usuarios interesados. El buzón, donde los programas dejan los mensajes.

La arquitectura del cartero suele ser:

Programas GUI’s para mantener: La guía de usuarios, Las funciones. Las relaciones entre funciones y usuarios.

API’s de Middleware para colocar los avisos en el buzón del cartero. El funcionamiento es:

Los programas que lo necesitan preparan el mensaje y lo colocan en el buzón con una referencia de función.


El cartero averigua a partir de la relación entre función y usuarios los usuarios destinatarios.

El cartero pasa los mensajes al servidor de notas y avisos. El servidor de notas y avisos los hace llegar a los usuarios afectados.

Observe que con esta arquitectura la gestión de los usuarios queda independiente de los programas y pasa a ser una función de administración. El cartero se implementa habitualmente como un agente y lo representaremos por la imagen de la figura. Otra opción es utilizar la el middleware de publicación / suscripción si existe en la plataforma distribuida.

11. Gestión de errores en un servidor de correo. La gestión de errores en un servidor de correo es fundamental ya que su cualidad básica ha de ser la “full tolerance”. La calidad de un ser servidor de correo en este apartado puede medirse en dos dimensiones: 11. 1. Recuperación de errores.

Ha de ser automática y flexible. Cuando se inicia una transferencia, ya sea en origen o destino, si el otro lado no contesta se realizarán de forma automática un número de reintentos de transmisión espaciados en un tiempo de espera entre reintentos de transmisión. Si en uno de ellos se recupera la conexión, ésta se reinicia y continua normalmente en el punto en que se había quedado sin repetir lo que ya se había transmitido. El usuario ni lo notará. Como mucho, si el número de reintentos es alto, puede llegar a notar que la transmisión ha durado más tiempo del normal. Si a pesar de todo no puede recuperarse el error se generará un aviso de error grave. Pasado un tiempo de espera entre reintentos de conexión se reiniciará otro bloque de un número de reintentos de conexión. Si hay recuperación, la transmisión se reiniciará desde donde se había quedado, no repitiendo en ningún caso lo que ya se había transmitido. Si pasados estos reintentos no ha sido posible tampoco la recuperación se dará aviso de avería. La implementación de los tiempos de espera entre reintentos de conexión puede ser:

Lineal. La espera entre reintento y reintento es siempre la misma. Progresiva. La distancia entre reintentos se alarga en función del número de reintentos hasta un tope máximo a partir del cual es ya lineal. La progresión puede ser a su vez:

Geométrica. Escalada. Un ejemplo para un servidor de correo puede ser:

30 segundos para el primero. Se intenta solventar errores de transmisión puntuales.

2 minutos para el segundo. Se intenta salvar una congestión.


n del cartero


4 reintentos de 30 minutos. Se intenta recuperar caídas por avería del transportista.

Espera de 8 horas y reinicio del ciclo. Se intenta recuperar averías de la plataforma.

Si los nodos origen y destino tiene una conexión por vía alternativa, todo el proceso se reintentará por ella. Si la opción de loging está activada todas las incidencias ocurridas serán registradas. Obviamente todos estos parámetros pueden ser personalizados estática y dinámicamente para cada nodo. El diseño de la recuperación de errores es genérico a todos los procesos distribuidos variando en cada caso la política del tiempo de progresión. Existe la posibilidad de establecer tipologías de estrategias que se pueden cuantificar diferentemente en función de las necesidades concretas de cada nodo. Por ejemplo, una estrategia para los nodos con servicios de base de datos y otro para nodos de comunicaciones. Un nodo con un gestor de base de datos potente tendrá unos valores inferiores a otros con una base de datos de tipología usuario. Por ejemplo una espera de 3 minutos para un segundo intento para salvar la congestión es válida en un servidor de correo pero no en un servicio de consulta cara al público. Habrá que ajustarlo según las necesidades de la aplicación y las características del servicio. Por esa razón se recomienda colocar la parametrización de la gestión de errores como parte de las posibilidades de configuración del servicio y/o cliente.

11. 2. Facilidad de localización y seguimiento. El administrador del sistema tendrá a su disposición varios recursos:

11.2.1. Loging de errores. De forma parametrizada, el servidor de correo registrará un loging de incidencias y errores que permitirá obtener información por nodo, tipología, frecuencia, etc. El paquete estadístico consulta y análisis de errores, basado en el loging, puede ser un paquete proporcionado por el mismo diseñador del servidor de correo (integrado o no el modulo de seguimiento y análisis del que se habla más adelante) o realizado “a medida” a partir de herramientas de usuario tipo Access.

11.2.2. Control centralizado de errores. El servidor puede dar la opción de organizar un control centralizado de errores de forma que toda la información de errores e incidencias se envíen a un punto de sistema distribuido donde hay un administrador.


Este control se organizará basado en la gestión jerárquica de errores que se presenta a continuación. Esta opción sólo tiene interés en instalaciones muy grandes o en aquellas en que en los puntos de origen y destino no tienen administración de sistema y la existencia de errores puede pasar desapercibida.

11.2.3. Jerarquía de errores. La clasificación y calificación de los errores es de interés tanto para el loging como para el control centralizado. Los errores se clasificarán en dos grupos: graves y incidencias. Dentro de cada grupo a cada error se le asignará un código. A nivel de error, y basándose en el código, se asignará a cada uno:

Si se ha de grabar en el loging. Si de ha de enviar al control centralizado de error y como ha de informarse allí al administrador:

Nota: se depositará hasta que el administrador lo consulte voluntariamente.

Aviso: se depositará hasta que el administrador lo consulte antes de un tiempo parametrizable. Si pasado ese tiempo no lo ha hecho se interrumpirá al administrador.

Fuego: se interrumpirá al administrador en su trabajo para notificarle el error. Obviamente está interrupción sólo se aplicará a errores graves.

El administrador conocerá la existencia de notas y avisos por un icono en su pantalla de administración. Si se dispone de la especialización como servidor de notas y avisos, el envío al servicio centralizado lo utilizará.

11.2.4. Módulo de seguimiento y análisis. Todas las posibilidades de consulta, seguimiento y gestión centralizada pueden estar integradas en un módulo de seguimiento y análisis. Las posibilidades de este módulo son, como mínimo:

Seguimiento en tiempo real de errores con grabación de loging y envío de notificación al control centralizado. Estadísticas por pantalla y listado. Herramientas de análisis. Utilización por usuarios y distribución y control de costes. Posibilidad de incorporar módulos personificados por usuario según sus necesidades y organización. Gestión de la seguridad.

12. Otras posibilidades.


Otras posibilidades deseables en un servidor de correo son:

Compactar los datos para minimizar los tiempos de transmisión. Fundamental.

Encriptar los datos para evitar pinchazos. Posibilidad de arrancar más de una instancia del servidor de correo en el mismo nodo.

Encapsulamiento de las vías que permita incorporar de nuevas de forma cómoda.

Posibilidades de planificación que permitan minimizar costes. Por ejemplo, transmisión nocturna si se utiliza red conmutada.

Multidioma.

13. Semántica de comportamiento. El servidor de correo ha de ser de ejecución segura para garantizar que el trabajo de transporte que se le delega se realiza siempre. En el capítulo de consistencia diremos que tiene una semántica de comportamiento “exactamente una” (Exactly once). Olvídese de este concepto hasta entonces. Sin embargo reflexionemos sobre que pasa con el fichero que transporta. Si se ha hecho un envío anterior del mismo fichero puede interesar que:

La nueva copia destruya el contenido antiguo. La nueva copia, si tiene el mismo nombre que un fichero anterior no se acepte, función que deberá controlar el servidor de correo de destino.

Obviamente la responsabilidad de esta decisión no puede asumirla el servidor de correo, que ha de devolver un código de error, si no que ha de tomarla en que encarga el transporte. El transportista puede tener la posibilidad de poder anotar en su cola con la opción de destruir el contenido anterior o rechazar el encargo si ya existe. Por defecto, los programas que encargan trabajo deberían presuponer que la opción de trabajo estándar es la de destruir el contenido anterior ya actuar en consecuencia si no desea que esto ocurre. La clave está en jugar con el nombre del fichero.

14. Modos de trabajo habituales de un servidor de correo. Utilizando las prestaciones de un servidor de correo pueden implementarse diversos modos de trabajo. Los más habituales son: 14. 1. Push.

El cliente anota en origen y el servidor de correo de origen inicia el envío según una política. El push ha de ser multivia para poder lanzar más de un envío simultáneamente.


Puede ser:

Inmediata. El servidor de correo Diferida. Esta modalidad puede ser necesaria, aun con una plataforma continuamente abierta, si la entrega no se puede hacer efectiva por razones funcionales de la aplicación. La entrega puede ser:

Planificada. La entrega se realiza en bloque con todo lo pendiente. Por anotación. Se asocia una hora de entrega y cuando es el momento se inicia el transporte desde origen.

Si la salida es de un origen a múltiples destinos, necesita un ancho de banda importante para evitar la congestión en la salida o máquinas servidoras especializadas.

14. 2. Recogida. El destino inicia la comunicación, mira si hay algo para él y lo recoge. Aprovecha la opción de captura del servidor de correo. Puede ser:

Planificada. Por necesidades de aplicación, muchas veces iniciada por un agente en destino.

Tiene la ventaja de que la banda de comunicaciones que se necesita es menor ya que la recogida es escalada. Es la recomendable:

Con comunicación con poco ancho de banda. Número alto de clientes. Dispersión de horarios que impliquen que no hay conexión de plataforma permanente.

14. 3. Notificación.

Es un sistema intermedio en el cual el origen avisa al destino que tiene una entrega para él. El destino la recogeré cuando le convenga. En la notificación se incluye información del contenido de la entrega y posibles destinatarios en el nodo destino. El aviso puede llegar:

El servidor de notas y avisos. El cartero. Un sistema de vigía. Un evento convencional si hay una plataforma de eventos distribuida (normalmente de objetos distribuidos)

14. 4. Oportunista.


Cuando el nodo remoto se conecta para pedir algún servicio, aprovecha para preguntar si hay algo para él. Suele incluirse, como parte de la respuesta del servicio pedido, una notificación, dedicada o general, de que hay alguna cosa para él.

15. Implementación.

Las prestaciones de un servidor de correo, y su especialización como servidor de notas y avisos o cartero, constituyen un componente lógico compacto pero su implementación puede hacerse sobre más de una producto. Si es así, la dispersión de la implementación ha de estar encapsulada de forma transparente a los clientes. Si hay dispersión de plataformas una forma cómoda de conseguir un servidor de correo distribuible es el correo electrónico Hay diferentes soluciones: 15. 1. Programación propia.

Solo justificable en las condiciones mencionadas con anterioridad.

15.1.1. Aprovechar una plataforma de objetos distribuidos. La opción, de gran interés estratégico y cómoda de utilizar, tiene el inconveniente de haber diversas plataformas posibles que pueden utilizarse y que no sabemos si estarán en todos los nodos.

15.1.2. La plataforma TCP/IP + SOAP. De gran eficiencia y generalización como transportista.

Sobre ella: se realizará aplicación propia. Se utilizará un paquete ya construido.

15.1.3. Basarse en los módulos de gestión de mensajes del Middleware.

El servidor aprovechará las API’s del sistema para el uso de ese tipo de Middleware. El esfuerzo de programación es de cualquier forma notable. El buzón y la lista de distribución han de programarse siempre.

15.1.4. Aprovechar el mail. Esta opción es hoy día muy interesante por la amplitud e integración que Internet y los productos de Microsoft y Linux permiten. La lista de distribución y el buzón forma ya parte del mail y la posibilidad de atar ficheros solventa el transporte. Además, cada día es mes global e integrado. Su inconveniente es que hay que ligarse al producto de un fabricante y las limitaciones de globalidad están limitadas a las de ese producto.


15. 2. Aprovechar paquetes fabricados por terceros. Añadiendo las opciones que se necesitan y que no tiene el paquete original. Esta posibilidad es, de hecho, bastante utópica y es mejor no usar este camino si se necesitan personalizaciones.

16. Como y cuando utilizar el servidor de correo. En este punto de la exposición ya le debe ser muy evidente el uso que puede hacer de un buen servidor de correo y de su especialización como servidor de notas y avisos. Sin embargo, si usted no puede aprovechar un paquete ya construido, conseguir todas estas prestaciones supone un esfuerzo importante de programación. Pero, si su diseño necesita construir uno, no caiga en el error de programarlo sin las prestaciones mínimas para ahorrar costes. No conseguirá la tolerancia total ante fallos y eso arruinará su proyecto. Además la experiencia demuestra que un buen servidor de correo crea adición: cuanto más se usa más necesidades se encuentran,... y mejor quedan sus aplicaciones distribuidas. Finalmente otra obviedad: fabricar un servidor de correo sólo se justifica en topologías distribuidas heterogéneas, globales o muy grandes.

La Comunicación entre el Cliente y el Servidor.

1. Introducción. Cliente y Servidor son dos programas. Como tales, para poder trabajar de forma coordinada deben intercambiarse mensajes. En este capitulo vamos a estudiar la tipología básica de esta comunicación y los modelos y vías más frecuentes. Veremos en este capítulo que el diseño deberá basarse en la tipología y los modelos.

2. Características de la comunicación. La comunicación entre clientes y servidores se caracteriza por ser: 2. 1. Cooperativa.

Cliente y servidor se reparten el trabajo.

2. 2. Transaccional. Cliente y servidor se intercambian mensajes en filosofía cliente / servidor es decir, a una mensaje de petición de servicio del cliente, responde el servidor asumiendo la total responsabilidad y realizando el trabajo de forma encapsulada al cliente. Una vez realizado el trabajo, el servidor responde con un mensaje de respuesta que el cliente recoge. Este efecto de encapsulamiento, añadido a la determinación clara de responsabilidades, hace que el diálogo establecido se identifique con una transacción.

2. 3. No necesariamente sincronizada. Nótese que, si el diseño no lo pide, las peticiones y respuestas no han de ser necesariamente sincronizadas. De hecho, las comunicaciones síncronas y asíncronas conviven según las necesidades de la aplicación y las especificaciones de los diversos tipos de comunicación.

3. Tipos de comunicación. Hay tres tipos de comunicación, dos “de siempre”, síncrona y asíncrona, y eventos. 3. 1. Comunicación síncrona.

@@EMG/10 - Enric Martínez Gomáriz 45

Es un tipo de comunicación, caracterizado porque el cliente lanza la petición y espera, sin hacer nada más, la llegada de la respuesta. El servidor se comporta, a efectos de programación como una rutina “linkada” dinámicamente. La espera puede estar determinada por la vía de comunicación si ésta es de naturaleza síncrona, o bien forzada por el programa si la vía de comunicación es asíncrona. Cuando la comunicación es síncrona, el mensaje de respuesta incluye un código de retorno que

en caso de error da información al cliente de la causa. El programador deberá tratarlo y analizarlo como en cualquier llamada a rutina de un programa convencional. Esta similitud de tratamiento con un mecanismo de llamada a rutina “call-return” convencional lleva con demasiada frecuencia al programador a olvidar que, debido a que esta en un entorno distribuido, la respuesta puede no llegar y que para que su programa funcione correctamente deberá aportar software para ese caso. Curiosamente, la comunicación asíncrona que parece, a priori, tentadoramente fácil de utilizar por su similitud con programación convencional es la que presenta más problemas para tratar la “caída del servidor”. En efecto, debido a la naturaleza síncrona de la comunicación, el cliente está esperando la respuesta. Si la vía de comunicación del Middleware que utiliza lleva incorporado el control de caída del servidor, le devolverá una condición de error en el código de retorno que el programa podrá tratar (¡¡¡deberá tratar!!!) para disparar los procesos de recuperación. Pero si el control de caída del servidor no está implementando en la vía de comunicación, el programa cliente se “colgará”. En este caso, puede intentar sistemas de “timer” para pasado el tiempo máximo de espera, si esta no ha llegado, recuperar el programa. Sin embargo está solución no es ninguna trivialidad cuando se programa....

3. 2. Comunicación asíncrona. En la comunicación asíncrona el cliente lanza la petición y no se espera a que llegue la respuesta, si no que continua trabajando. La respuesta del servidor se ha generar de forma que el cliente pueda recogerla cuando este preparado para hacerlo. Es evidente que este tipo de comunicación tiene como prerrequisito que, además de la utilización de una vía asíncrona, que el servidor esté diseñado

Cliente Servidor

Petición

Respuesta

Figura 22. Esquema de comunicación

síncrona.


para trabajar de forma asíncrona. La utilización de una vía asíncrona no será garantía suficiente de buen funcionamiento si el servidor no está diseñado convenientemente.

Cualquier vía asíncrona puede ser utilizada por el cliente de forma síncrona. Basta que renuncie a continuar trabajando tras enviar la petición y que se quede en un bucle de petición periódica de la respuesta.

Note la diferencia fundamental entre hacer comunicación síncrona con una vía síncrona o hacerla con una vía asíncrona; en el segundo caso el cliente tiene control total de la “caída del servidor”.

El cliente tiene que estar diseñado para no ser interrumpido cuando no este preparado para recibir la respuesta. Por esa razón, cualquier vía de comunicación asíncrona que

se precie debe proveer tres mecanismos:

Almacenamiento de las peticiones del cliente. Almacenamiento de las respuestas del servidor. Recuperación voluntaria de la respuesta por parte del cliente

En cualquier caso, no utilice nunca la técnica “seguro que acabo antes de que el servidor me entregue la respuesta”. Habrá introducido una bomba dentro de su aplicación. Si le cambian las localizaciones de cliente y/o servidor a una máquina más o menos

potente, puede irse todo el montaje al cuerno. La utilización de técnicas asíncronas abre unas posibilidades inmensas que si usted piensa como un diseñador convencional nunca intuirá. Fíjese en la figura superior. ¡Observe todo los que puede hacer mientras el servidor está procesando su petición! Imagínese que esta diseñando una aplicación de gestión de una delegación de ventas. Y que como parte del proceso de registro de un pedido ha de verificar que puede venderle al cliente que tiene delante. Y que la verificación del cliente se ha de hacer contra un ordenador corporativo remoto. Si trabaja convencionalmente, hará la secuencia: entrada del cliente, verificación del cliente y registro de los productos del pedido, que es, en realidad, el proceso sobre el papel más lento. A parte del tiempo necesario para llamar al ordenador principal, enviar la petición, recibir la respuesta y cerrar la conexión. Piense otra solución aprovechando la disponibilidad de una vía asíncrona.

Cliente Servidor

Petición

Respuesta

Figura 23. Esquema de comunicación

asíncrona.


Diseñe un servidor de verificación del cliente. Establezca una vía de comunicación asíncrona entre el cliente y ese servidor. Y cambie la secuencia de trabajo: el programa pide el código del cliente, lanza la petición al servidor de verificación, continúa registrado los productos del pedido, y cuando acaba pide la respuesta. Si ha llegado la analiza, sino se espera a que llegue. ¡Y deje de pensar como un programador convencional! Y ni se plantee la cuestión: de que si no puedo vender a ese cliente porque es moroso, ¡habré perdido todo el tiempo de registro de los productos! Piense que lo habría perdido igual realizando la verificación. Acostúmbrese a una de las características de un diseño distribuido: la necesidad de trabajar con probabilidades a la hora de escoger soluciones. Normalmente, en la inmensa mayoría de los casos, podrá venderle al cliente que esta verificando; si la respuesta a la verificación más frecuente es que no, mejor cambie de negocio.

3. 3. Comunicación por eventos. Un evento, como Vd. ya sabe, es un acontecimiento o situación que un elemento, normalmente un objeto, envía a otro. Un gestor de eventos permite que todo funcione correctamente. Un receptor sólo es interrumpido para recibir el evento cuando esta disponible. La programación por eventos es una técnica de gran interés y potencia que puso de moda la programación de interfícies gráficas de usuario. Este no es un libro de programación por eventos. En un curso de diseño C/S sólo interesan los eventos como vía más de comunicación entre cliente y servidor. Bajo este prisma, yo opino que la comunicación por eventos entre cliente y servidor no es un tercer tipo de comunicación, sino que es una vía asíncrona más; eso si de una potencia enorme. La trataré así. Más adelante encontrará mi propuesta de tratamiento desarrollada en profundidad.

4. Las diferentes vías de comunicación Las diferentes vías de comunicación entre cliente y servidor han evolucionado a lo largo de los años y se han estandarizado con la aparición del Middleware. Vamos a realizar a continuación una exposición de las más habituales y estándares. En cada caso, además de relacionar sus características principales, se detallará si su naturaleza en síncrona o asíncrona.

5. El modelo conversacional. Más que una vía, la comunicación conversacional entre cliente y servidor es una modelo.


Recuerde que una relación conversacional entre dos programas es un modelo de comunicación entre iguales: dos programas se sincronizan, se intercambian mensajes y se desconectan. Es decir, cliente y servidor se sincronizan directamente

entre sí y se intercambian mensajes. Ello supone la presencia de servidores dedicados y la reserva exclusiva del servidor. La presencia de una vía de comunicación conversacional la representaremos por el símbolo de la figura. Hablar aquí del principio conversacional parece una

contradicción. La comunicación conversacional entre cliente y servidor se ha usado desde los tiempos heroicos en las aplicaciones C/S para establecer comunicaciones entre clientes y servidores que han de ser reservados. Imagine que tiene un solo grabador de tarjetas magnéticas en una instalación y está compartido entre dos pantallas de atención al público. El operador de cada pantalla deberá saber si el grabador “está reservado” a su estación de trabajo o no antes de actualizar o grabar una nueva tarjeta de un cliente que tenga delante. El acceso al grabador se encapsulará en un servidor protegido por un semáforo. Cada programa cliente deberá reservarlo antes de permitir a su operador pasar la tarjeta. El modelo conversacional es ideal para resolver está situación. Observe en la figura como iría la comunicación. De hecho, si necesita una comunicación de este tipo, auto impóngase la disciplina Cliente/Servidor. Realice la conversación en sólo cuatro pasos:

Reserva del servidor. Mensaje de petición de servicio. Mensaje de respuesta. Liberación del servidor.

El modelo conversacional tiene algunas consideraciones adicionales:

El comportamiento de diseño de la comunicación conversacional en siempre síncrona. Aunque observe que el modelo conversacional no lo exige.

Una vez conectados cliente y servidor el efecto es como del de una conexión punto a punto.

El cliente ha de preocupar de los time-out’s, seguimiento del diálogo y de la desconexión final.

El modelo conversacional se ha de resolver por una vía de comunicación que se habrá de escoger en cada caso (recursos multitarea, TCP/IP, etc.). En general, el resultado son servidores distribuibles y no distribuidos, ya que la necesidad del modelo conversacional es tan puntual que está ligada a un entorno concreto.


del modelo conversacional.

ServidorCliente El cliente espera que el semáforo esté libre

ServidorCliente El cliente encuentra el semáforo libre

ServidorCliente El cliente ocupa el servidor poniendo el semáforo en rojo y pide y recibe del

servidor el servicio

ServidorCliente El cliente libera el semáforo

El segundo y el tercer paso pueden ser uno solo Figura 25. Relación conversacional entre cliente y servidor


El modelo conversacional se usa muy poca como se desprende de analizar las dos razones fundamentales de uso:

Compartir recursos caros. Cada vez hay menos. Observe el coste de un grabador de tarjetas, hoy día colocaría uno en cada puesto de trabajo.

Suplir con poco esfuerzo de programación funciones que no existen en el Middleware. Hoy día son difíciles de encontrar.

Un uso actual de este tipo de conexión es la asignación fija de un hilo de un servicio master-slave, que presentaremos más adelante al hablar de arquitecturas entre servidores, a una cliente. Fuera de este caso, es muy improbable que usted necesite utilizarlo en las modernas aplicaciones distribuidas basadas en servicios multicliente.

6. Colas.

Las colas son la vía de comunicación asíncrona por antonomasia. Los clientes colocan los mensajes de petición en las colas, los servidores colocan las respuestas y, cuando les conviene, los clientes toman las respuestas. Una cola la representaremos por el símbolo de la figura, ya conocido del capítulo de componentes. De hecho, le recomiendo que

tenga presente todo lo que allí se dijo sobre colas cuando lee esta sección de la comunicación de entre cliente y servidor. Las colas, como vía de comunicación, pueden implementarse con el módulo Message-Oriented Middleware (MOM) que proporciona API’s de alto nivel para la gestión de la colas con independencia de la plataforma. Sin embargo, si Vd. ha desarrollado un modulo de gestión de, que le proporciona este recurso como un componente operacional, utilícelo. Seguro que si su componente es bueno, tendrá muchas mejores prestaciones y un mayor control de la situación. Existen tres tipos diferentes de utilización de las colas dentro de diseños cliente servidor. Son los siguientes. 6. 1. Comunicación sin respuesta o desacoplada.

Figura 26. Representación de

una cola.


Son procesos en los que el cliente encarga un trabajo al servidor donde no hay necesidad de recibir una respuesta del servidor.

En muchos casos, además, el proceso de la petición por el servidor desde la cola esta diferida en el tiempo. Es el modelo que hemos referenciado en la primera parte como comunicación desacoplada, que en el fondo es una forma de implementar interfases.

Un ejemplo muy común son los servidores de impresión; el cliente

prepara el listado y lo “encola” en la cola de spool de servidor sobre el que quiere imprimir. Otro ejemplo muy habitual es el envío de ficheros diarios de resumen de actividad desde una delegación a la central. Así por ejemplo, un servidor de ventas de la central está recogiendo por la noche los resúmenes de las ventas realizadas ese día por la red de vendedores. La comunicación sin respuesta exige del servidor garantía total de funcionamiento (full-tolerance).

6. 2. Comunicación con respuesta directa. El cliente anota las peticiones en la cola, pero espera la respuesta del servidor sin continuar su proceso. Es, pues, un tipo de comunicación síncrona en el cual la cola se utiliza solo para conseguir que el servidor no pierda peticiones y no se presenten problemas de time-out cuando lleguen peticiones al servidor de un cliente mientras está procesando la petición de otro cliente. Las vías síncronas del Middleware se implementan con este modelo de comunicación.

ServidorCliente

Figura 27. Comunicación sin respuesta

ServidorCliente

Respuesta

Figura 28. Comunicación con respuesta

directa


6. 3. Comunicación con respuesta por cola. Es el verdadero modelo de comunicación asíncrona a través de colas. Permite al servidor trabajar simultáneamente con más de un cliente y a estos escoger el momento en el que quieren obtener y analizar la respuesta. Existen dos versiones según se desea trabajar o no con la misma cola para anotar las peticiones y las respuestas. La solución con dos colas es más eficiente desde el punto de vista de tiempo de respuesta, pero en la mayoría de los casos reales se utiliza una única cola.

6. 4. Arquitectura de colas multicliente y multiservidor. Las colas son, con mucho, el sistema de comunicación más versátil permitiendo que además de varios clientes, varios servidores la ataquen simultáneamente. Los servidores que comparten la cola pueden ser de servicios diferentes (diferenciados normalmente por el calificador de la anotación) o instancias del mismo servidor. Esta arquitectura permite montar aplicaciones distribuidas muy robusta y adaptables a las variaciones y aumentos de carga (basta arrancar más instancias del servidor cuando se necesita más cantidad de proceso).

6. 5. Representación de la comunicación con servidores de cola. Para diferenciar en los esquemas cuando la comunicación con un servidor de cola es asíncrona o desacoplada utilizaremos la notación de la figura.

7. Petición de servicio al Middleware. Con el desarrollo del Middleware han ido apareciendo, y de hecho aparecen con bastante regularidad, gran cantidad de servicios estandarizados que cubren un abanico cada vez más amplio.

ServidorCliente

Cola única de petición/respuesta

ServidorCliente

Colas separadas para la petición y la respuesta

Figura 29. Comunicación con respuesta por cola

Cliente

Cliente

Cliente

Servidor

Servidor

Figura 30. Arquitectura de colas

multicliente y multiservidor.

Desacoplada

Asíncrona

Figura 31. Representación de la

comunicación desacoplada y asíncrona por medio de una

cola


El cliente pide ese servicio de forma transparente al sistema aprovechando que el Middleware le libera de conocer la localización. El formato habitual de la llamada es de API, con un código de retorno y un código de error. Por ello, el programa cliente utiliza al servidor como si fuera una rutina clásica, sin olvidar, por descontado, de tratar la no respuesta del servidor. Un servicio este tipo lo representaremos en los esquemas con el símbolo de la figura. Si la comunicación es síncrona o asíncrona depende

de la implementación que el fabricante ha hecho del servicio. De cualquier forma, son mucho más habituales los servicios síncronos que los asíncronos. La especialización del servicio puede incluirse dentro del símbolo tal como se muestra en la figura de la derecha. De cualquier forma, para los servicios más habituales que presentaremos a continuación utilizaremos símbolos específicos. Se presentan a continuación los servicios estándar más habituales disponibles en un entorno de Middleware. No se explicarán con detalle las prestaciones de cada uno de ellos. Si no se conocen se deberá consultar documentación específica. 7. 1. OLE y ACTIVE X

OLE y ACTIVE X son estándares de Microsoft desarrollado para la integración de los objetos de su paquete de ofimática Office y su intercambio entre

las diferentes aplicaciones que forman el paquete (Word, Excel, PowerPoint, etc.). Hoy día se han convertido en estándares “de facto” para la gestión e intercambio de objetos entre diferentes aplicaciones. Tienen recursos para trabajar de forma síncrona, asíncrona y desacoplada.

7. 2. ODBC.

ODBC es, como todo el mundo sabe, el estándar

de Microsoft para el acceso a las BD vía SQL. Hoy día, se ha convertido en el estándar “de facto” para la gestión de bases de datos con independencia del motor y del fabricante.

La presencia de un servidor de bases de datos conectado con ODBC la representaremos por el símbolo de la figura.

ODBC es una vía síncrona. Incluiremos como ODBC el uso de JDBC en una arquitectura J2EE.


n de la petición genérica de un

servicio.

S-ODBC S-OLE

Figura 33. Especialización de la petición de servicio

Figura 34. Representación de la comunicación por

OLE y ACTIVE X


n de la comunicación

por ODBC


Si usted ya conoce que es ODBC, sáltese el resto de este apartado. Normalmente se implementa con un servidor localizado en la parte de la BD, normalmente sobre la misma máquina física. En la parte cliente existe un stub de conexión (driver local de trasporte de parámetros del cual hablaremos más adelante). El programa linka estáticamente las rutinas de acceso. El servidor y el Stub de la parte clientes los suelen vender el propio fabricante del motor. Las rutinas el fabricante del lenguaje de programación utilizado. En la figura se muestra la arquitectura de servicio del ODBC.

7. 3. ADO.

Si el acceso a los datos es a través de ADO, la representación del servicio la haremos por el icono de la figura.

Su Vd. Ya conoce que es ADO, sáltese es resto de este apartado.

Sobre una plataforma Windows, ActiveX Data

Objects (ADO) permite acceder a bases de datos compatibles con ODBC y orígenes de datos compatibles con OLE DB. ADO proporciona objetos que se instancian en la parte cliente y a partir de ellos se ataca la base de datos. Por ejemplo, ADO proporciona el objeto Connection, que puede utilizar para establecer y administrar las conexiones entre las aplicaciones y las bases de datos de ODBC. El objeto Connection incorpora diversas propiedades y métodos que puede utilizarse para abrir y cerrar conexiones con bases de datos, y para enviar consultas de actualización de la información. Con el método Execute del objeto Connection se envían las consultas en el SQL a la BD y se recuperan los resultados.

MaquinaCliente

Programa

Rutinas

Stub del ODBC

MaquinaServidora

Servidor ODBC

BD

Figura 36. Arquitectura del servicio de ODBC



por ADO

MaquinaCliente

Programa

Objetos ADO

Maquina Servidora

Servidor ODBC

BD ODBCProveedor OLE DB

BD OLE DB

Figura 38. Arquitectura de ADO


El objeto Recordset tiene las funciones necesarias para recuperar y presentar un conjunto de filas, o registros, de una base de datos en función de las restricciones de la consulta SQL. Otros objetos proporcionan el resto de funcionalidades necesarias. En resumen, las aplicaciones programan contra objetos en lugar de tablas y columnas ADO.Net es una mejora evolutiva de ADO que aporta interoperabilidad entre plataformas y un acceso a datos escalable. Puesto que utiliza XML (Lenguaje de Marcado Extensible), ADO.NET garantiza la transferencia eficaz de los datos a cualquier aplicación que se ejecute en cualquier plataforma. La pieza central de una solución de software que utilice ADO.NET es el Recordset, que es una copia en memoria de los datos de una base de datos. Los conjuntos de los datos del Recordset contienen una serie de tablas de datos, cada una de las cuales corresponde a una tabla o vista de la base de datos. Un conjunto de datos constituye una vista "desconectada" de los datos de la base de datos, es decir, existe en memoria sin una conexión activa a una base de datos que contenga la correspondiente tabla o vista. Esta arquitectura desconectada ofrece mayor escalabilidad al utilizar los recursos del servidor sólo cuando lee o escribe en la base de datos. Durante la ejecución, los datos pasarán de la base de datos a un objeto de negocio de la capa intermedia y después a la interfaz de usuario. Para alojar el intercambio de datos, ADO.NET utiliza un formato de persistencia y de transmisión basado en XML. Para transmitir los datos de una capa a otra, una solución ADO.NET expresa los datos en memoria (el conjunto de datos) como XML y, a continuación, envía el XML al otro componente. La ilustración, bajada de la Web de Microsoft, demuestra la arquitectura de ADO.NET.

Figura 39. Arquitectura de ADO.NET


7. 4. ODBC o ADO. Servidores de Bases de Datos.

La decisión de utilizar ODBC o ADO es básicamente de programación y no de diseño.

Por esa razón, en los esquemas puede utilizarse el símbolo de la figura para referirnos a un servidor de base de datos en general, independientemente de la técnica de implementación utilizada.

7. 5. Servidores de SQL.

Son servicios de datos genéricos en los cuales la configuración de la lógica de

datos se configura en el momento del arranque del servicio mediante un SQL embebido. Presentan la ventaja de que puede cambiarse la semántica del servicio sin tocar el servidor. Se representaran por el símbolo de la figura. Es necesario disponer de un repositorio donde

registrar la descripción SQL del servicio. Pueden utilzarse para ello ficheros XML o la propia base de datos.

7. 6. Procedimiento catalogado. Recuerde que un procedimiento catalogado en un proceso de lógica de datos encapsulado dentro de la base de datos con un nombre. Puede llamarse desde un programa cliente referenciando ese nombre.

Como ya se ha dicho, los procedimientos catalogados tienen una importancia básica en sistemas C/S para conseguir rendimientos óptimos y por esa razón se tratarán más adelante ampliamente.

Un procedimiento catalogado, que representaremos por el símbolo de la figura, es una vía síncrona.

Conviene estar atento a la posibilidad de utilizar un procedimiento catalogado como Servicio WEB.

7. 7. Vías de acceso a Internet.

Como ya se ha explicado en la primera parte, usaremos en los diseños dos vías o modelos diferentes para gestionar servicios de Internet.

Web. Servicio WEB.


n del servicio genérico de

acceso a datos relacionales


n de un servidor SQL


de la llamada a procedimiento catalogado.


los accesos a Internet.


8. Remote Procedure Call (RPC). RPC es la vía síncrona por antonomasia. Fue la primera vía histórica de conexión entre un cliente y un servidor. Cuando, al principio de los tiempos C/S apareció la necesidad de conectarlos, se aprovechó, adaptándolo, el Remote Job Control (RJE) que permitía “encolar” trabajos Batch desde terminales transaccionales no inteligentes.

RPC es un mecanismo genérico mediante el cual un cliente pide un servicio, codificado en un mensaje cuya semántica conocen cliente y servidor pero ignora el transportista, y se suspende hasta que recibe la respuesta. Es, pues, una vía síncrona. Este servicio lo representaremos en nuestros esquemas con el símbolo

de la figura. RPC, como vía síncrona, se parece mucho en su concepción al mecanismo llamada a una rutina normal ya que el cliente (programa principal) llama al servidor (rutina) invocándolo por su nombre y colocando los parámetros en la cabecera de la llamada. RPC (mecanismo de llamada a rutina) recoge los parámetros de entrada, llama al servidor (rutina) referenciado por el nombre de la llamada, recibe la respuesta y la devuelve al cliente (programa principal). Este mecanismo, al principio artesanal, ya esta incluido en los servicios de Middleware que proporciona el servicio de forma transparente a la plataforma del cliente y del servidor. Para conseguirlo utiliza el mecanismo de stub’s que se muestra en la figura. Conviene repasar este mecanismo, no por su interés para el diseño ya que es transparente a cliente y servidor si no porque proporciona una visión muy útil de como montar Middleware. Si usted tiene algún día la necesidad de crear Middleware propio, puede aprovechar y adaptar la idea a sus necesidades.

La idea fundamental es describir la cabecera de la llamada (interfície) en un lenguaje simbólico sobre un fichero de texto. A continuación esta descripción se compilará para los dos entornos, el cliente y el servidor, creado dos stub’s que permitirán que los dos se entiendan en tiempo de ejecución. Para la descripción de la interfície se utiliza

el Network Interface Definition Language (NIDL), un servicio del Middleware. Como se ve claramente, la clave de todo está en disponer del compilador NIDL para las dos plataformas lo que hará que la descripción de la interfície sea independiente de la implementación de cada componente.


n del acceso por RPC

Middleware

Descripción de la interfície

CompiladorIDL

Stub + código cliente

RPC Run Time

RPC Run Time

Stub + código

servidor

Figura 45. Network Interface Definition Language (NIDL).


El funcionamiento en tiempo de ejecución se muestra el la siguiente figura.

Básicamente el funcionamiento en tiempo de ejecución es el siguiente:

1. Cuando el servidor arranca, en el Middleware se anota la localización donde

lo ha hecho. Para ello se utiliza el Directory Service que proporciona el Middleware.

2. Cuando el cliente arranca ocurre lo mismo, el Middleware se anota la localización donde lo ha hecho. A partir de ese momento es posible saber la localización de cliente y servidor independientemente de la programación de ambos programas.

3. Durante su trabajo el cliente necesita del servidor y prepara la cabecera de la llamada para la petición del servicio.

4. El cliente hace la llamada RPC al Middleware. La llamada es recogida por el Stub de la parte cliente que llama al servicio RPC del Middleware de la parte cliente.

5. El mecanismo de RPC llama al de la máquina donde está localizado el servidor.

6. El transportista lleva los parámetros de la llamada a la máquina servidora. 7. El RPC de la máquina servidora recibe la llamada. 8. El Stub de la parte servidora convierte los parámetros al formato que entiende

el servidor. 9. El servidor realiza el trabajo preparando los parámetros del mensaje de

respuesta. 10. El mensaje de respuesta es pasado al Stub de la parte servidora, que lo

codifica en el formato común y lo pasa al servicio RPC de la parte servidora. 11. El RPC de la parte servidora envía la respuesta al RPC de la máquina

cliente. 12. El transportista retorna la respuesta a la máquina cliente.

Arrancadadel cliente

2.Localización del servidor

Cliente3.Preparación de transacción

Stub del cliente

4.Preparación de argumentos

Cliente Runtime5.RPC

Arrancada servidor

Servidor

Stub del servidor

ServidorRuntime

1.Anotación de la situación

7.Recibe el RPC

8.Analiza parámetros

9.Realiza el trabajo

10.Envío respuesta

El servidor hace el trabajo

6.Transporte del mensaje

Direc-tory

service

RPC

El paso 10 sigue el mismo proceso de vuelta que a la ida. No se ha detallado para no complicar el dibujo

Figura 46. Comportamiento del RPC en tiempo de ejecución


13. El RPC de la máquina cliente recibe la respuesta y la pasa al Stub de la máquina cliente.

14. El Stub de la máquina cliente convierte los parámetros al formato del

programa cliente y devuelve la respuesta al código cliente. Note que este sistema es tan general que lo hace transparente también al lenguaje de programación.

RPC tiene fama de ser una vía muy cómoda para establecer la comunicación entre el cliente y el servidor. Pero, ¿por qué es tan cómodo RPC? RPC hace la vida muy fácil al cliente ya que delega muchos temas al Middleware:

La localización de clientes y servidores. El paso de parámetros de forma transparente a las plataformas. El tratamiento de las caídas del servidor. Seguridad, encriptación, autentificación, etc.

Además, la forma de uso emula el mecanismo “call-return”, muy fácil de programar, y el uso es siempre igual, independientemente de la semántica de la rutina. Sin embargo, su gran facilidad de uso y sus posibilidades no debe esconder su gran limitación, es una vía síncrona.

9. Comparación entre colas (MOM) y RPC. Colas y RPC han sido durante años las dos formas tradicionales de resolver la comunicación asíncrona y síncrona entre cliente y servidor. Por esa razón, la comparación entre las dos vías se ha realizado comparando las ventajas e inconvenientes de utilizar colas o RPC. Vamos a respetar está costumbre histórica. La comparación entre comunicación síncrona y asíncrona se realiza a continuación centrada en RPC y colas, aunque, evidentemente, la mayoría de los argumentos son generalizables para cualquier otro vía síncrona o asíncrona. Criterio Colas (MOM) RPC Metáfora Asíncrona: servicio de

correos Síncrona: teléfono

Secuencia C/S No hay limitaciones Los servidores han de arrancar antes de la llamada del clientes

Estilo Por colas y mensajes Mechanism “call-return” Persistencia Si Normalmente no ¿La otra parte ha de estar disponible?

No Si

¿Quién mantiene la sesión de comunicaciones?

El gestor de colas El RPC run time ya que hay conexión directa.

Load balancing Una sola cola puede implementar FIFO con o sin prioridades.

Necesita un Monitor TP independiente.


Soporte transaccional Dentro de algunos productos la cola de mensajes puede participar en la sincronización de los commits.

No. Necesita un Monitor TP independiente.

Filtro de mensajes Si No Rendimiento (Perfomace) Lenta (matizadle) Rápida Dificultad de programación

En función del modelo de comunicación que se ha escogido y de las alternativas necesarias

Mínima

Posibilidad de que el cliente haga trabajo en paralelo con el servidor.

Fácil Complicado y limitado.

10. Simple Object Access Protocol (SOAP).

SOAP es, básicamente, un transportista de funcionamiento síncrono. Hace transparente la conexión local de la remota. Es la vía habitual que se utiliza para intercambiar información XML en un entorno distribuido. Recuerde que un mensaje SOAP tiene una cabecera (Header) donde van los datos

operacionales y un cuerpo (Body) donde van los funcionales.

11. Modelos de objetos distribuidos.

Cuando queremos remarcar que el servicio se utiliza a través de un modelo de objetos distribuidos usaremos los dos iconos de la figura según se trate de J2EE o .Net. En este modelo, clases especializadas ocultan la

topología de la comunicación y los objetos se comunican normalmente por llamadas síncronas y/o eventos

12. La comunicación por eventos. Un evento es la notificación de una situación o de un cambio de estado. Cliente y servidor pueden utilizar eventos para realizar su comunicación en el momento necesario: envío de la petición, servicio realizado y respuesta preparada, hay algún problema, etc.



por SOAP

Figura 48. Modelos de

objetos distribuidos


La comunicación es básicamente síncrona. Su utilización es fundamental cuando el diseño y/o la implementación se basan en objetos distribuidos. La comunicación por eventos la representaremos por el símbolo de la figura. La comunicación por eventos entre un programa cliente y un programa servidor necesita de la presencia de un gestor de eventos alto nivel que comunique directamente los objetos distribuidos. La presencia de un modelo de objetos distribuidos supone la presencia de gran cantidad de servicios

de Middleware que facilitan en gran manera la implementación de la aplicación distribuida. Analizar a fondo un modelo de objetos distribuidos queda fuera de los objetivos de este documento dedicado al diseño. Sin embargo, le recomiendo que consulte información especializada sobre este tema, ya sea DCOM o CORBA. Este modelo de comunicación es útil en aquellas comunicaciones con terceros en que el envió y/o recepción de mensajes se ha de producir en el momento en que ocurren y ser notificado a todos los suscriptores.

13. Mecanismo ECA. Seguramente, sobre todo si usted es un experto en base de datos ya conoce el mecanismo ECA. En el mundo de la programación en general, es un mecanismo comodísimo para reaccionar. ECA es la abreviación de Event (E), Condition (C), Action (A). Básicamente, el mecanismo es una reacción a un evento generado normalmente por un trigger:

Se produce el evento en un punto de la aplicación y / o sistema.

Otro elemento de la aplicación y/o sistema lo recibe.

Evalúa una condición con los parámetros del evento recibido y su propio estado.

Si el resultado de la evaluación es cierto, reacciona al evento ejecutando una acción. En caso contrario, el evento es ignorado y / o diferido.

Como se verá más adelante los mecanismos ECA son de gran utilidad en las aplicaciones C/S.


n de la comunicación por eventos

Regla: (E,C) ASituación Reacción

Regla: (E,C) ASituación Reacción

Evento

CUANDO el evento ocurreSI se se satisface la condiciónCUANDO el evento ocurreSI se se satisface la condición

Situación

HACER_ejecutar la acciónHACER_ejecutar la acción

Reacción

Figura 50. Mecanismo ECA.


14. Comunicaciones remotas. Ya se ha comentado que la presencia de comunicaciones remotas supone, si no hay una plataforma de comunicaciones muy rápida, la introducción de un punto de heterogeneidad que suele condicionar decisivamente en diseño del sistema distribuido si se quiere disponer de tiempos de respuesta adecuados.

Es por esa razón por la que conviene marcar en los esquemas la presencia de ese punto de heterogeneidad. Para hacerlo utilizaremos el símbolo de la figura, incluyendo junto al la vía de conexión establecida entre el cliente y el servidor. Es obvio que el concepto rápido es siempre relativo y depende, básicamente de las necesidades de la aplicación distribuida que se diseña.

Aunque este tema se tratará más adelante con mayor detalle, conviene optimizar la comunicación para conseguir tiempos de respuesta aceptables. Son criterios a utilizar:

Diseñar la lógica de datos en la parte servidora, ya sea con procedimientos catalogados o con servidores especializados.

Intentar que la longitud de los mensajes sea lo más corta posible. Comprimir los mensajes.

Si la información transportada se considera critica, la información se encriptará. Adicionalmente, se incorporarán criterios de autentificación. Cuando queremos marcar que al otro extremo hay un dispositivo móvil, teléfono o PDA, lo diferenciaremos por una M en lugar de una R. Más que otra cosa nos marcará que hay un punto de heterogeneidad en el componente de presentación.

15. Comunicaciones inalámbricas. Nos referiremos a dispositivos en red local inalámbrica. Lo representaremos en el símbolo de la figura.

Al otro extremo puede haber:

Una asistente personal, lo que supone un punto de heterogeneidad de programación.

Un teléfono de última generación. Un PC portátil con lo cual el carácter de inalámbrico es solo informativo y puede obviarse.

Figura 51. Indicativ

o de conexión remota


o de conexión remota

con dispositivo móvil


o de conexión inalámbr

ica


16. Un ejemplo de utilización. Aunque la elección entre las diferentes vías de conexión entre cliente y servidor se trabajará más adelante, observemos, a modo de ejemplo, el siguiente proceso en el que se gestionan servicios. Obsérvese la utilización de los símbolos identificativos de las diferentes vías en el esquema final resultante. En el siguiente diagrama de flujo se muestra un proceso de contratación de un viaje en una compañía aérea. El sistema permite registrar ventas en la tienda de la agencia de viajes y directamente por los clientes desde Internet. El ejemplo no intenta ser real, sino ilustrativo de una arquitectura de servicios. Para decidir la arquitectura distribuida se parte de las siguientes premisas:

Los datos del cliente están en un servidor de datos local en la agencia de viajes.

Hay más de un puesto de venta en la agencia.

La actualización de los datos del vuelo se hace en la compañía aérea.

Con todo ello se identifican los siguientes servicios:

Servidor remoto vía RPC en la compañía aérea para la reserva de plazas. La agencia de viajes no conoce como es el ordenador de la compañía aérea, por ello RPC aporta la transparencia necesaria.

Un servidor para obtener los datos de cliente, situado sobre el servidor de datos de la agencia y en la misma máquina. Los programas cliente de contratación pedirán los datos de cliente a este servidor mediante una conexión vía colas. El servidor de clientes atacará los datos vía SQL.

El cargo de la venta a las cuentas de cliente se realizará también mediante un servidor que encapsulará la función.

La venta de directa desde casa del cliente se hará por una aplicación WEB. La consulta de vuelos del personal de la agencia se realizará por la Web de la compañía aérea.

La información de los vuelos desde la WEB de venta se tomará a través de un Servicio WEB de la compañía aérea.

Usuarioen tienda

Petición del cliente

Actualizalos datos dela compañía

aérea

Datos Compañía aérea

Cuenta Cliente

Registrode datos del

Cliente

Anotaciónen la cuentadel Cliente

Registrode datos del

Viaje

IdentificaciónCliente

ConsultaVuelos

AccesoDatos

Compañíaaérea

ConsultaDatos

Vuelos

Figura 54. Diagrama de flujo de una contratación de viaje.


Con todo ello el esquema de la figura anterior para las funciones de la tienda “evoluciona” a:

Y para las funciones de la aplicación de venta directa:

Componente activo de la WEBConsulta

DatosCompañía

aérea


ObtenerDatos

Cliente

Presentación de la WEBIdentificación

ClienteConsultaVuelos

RegistroVuelos


RegistroVenta

Cliente Cuenta ClienteRPC

ProcesoCompañía

Aérea

R

Cuenta Cliente

ProcesoCuentaCliente

Figura 56. Arquitectura de las funciones de venta directa

Esta aproximación intuitiva a la identificación de servidores se sustituirá más adelante por otra metódica.

Usuario

Petición cliente

Datos Compañía Aérea

Cuenta Cliente

RegistroDatos

Cliente

AnotaciónCuentaCliente

RegistroDatosViaje

PeticiónDatos

Cliente

DatosCabeceraCliente RPC

Actualizadatos

Compañíaaérea

ObtenerDatos

Cliente

ProcesoCompañía

Aérea


R

Cliente Cuenta Cliente

ConsultaDatos

Vuelos

Figura 55. Arquitectura de servidores


XML

1. Introducción. No se concibe un sistema distribuido moderno sin el uso exhaustivo de XML en varios de sus elementos desde una simple interfase a un modelo de datos. Este es un libro de diseño, como he insistido e insistiré en repetidas ocasiones, y XML es una herramienta. Sin embargo, creo que, para poder seguir un curso de diseño distribuido, debe tenerse mínimo conocimiento del mundo XML. Es el único objetivo que me planteo en este capítulo.

Aunque la utilización de XML es cada vez más la opción habitual, cuando queramos especificar que hay XML utilizaremos el símbolo de la figura. Al final de capítulo de incluyen algunos ejemplos de uso de XML dentro de aplicaciones distribuidas.

Si usted ya es un habitual de ese mundo XML vaya directamente a esa parte.

2. Introducción al XML. Ya presentamos XML en a primera parte. Si no lo recuerda, repase el capítulo dedicado a la interrelación entre sistemas centralizados, C/S e Internet. XML (Extensible Markup Language) nace del éxito de HMTL que necesitó pronto una extensión de prestaciones que empezó a hacerse de forma anárquica por las limitaciones implícitas en su propia definición que solo permite definir documentos con reglas preestablecidas. Para evitar esta anarquía el Wide Web Consortium definió y propuso en 1998 XML. XML es, básicamente, un metalenguaje de marcas que permite definir semánticas desde interfases de datos y procesos a modelos de datos y utilizarlo desde Servicios WEB o cualquier servicio en general a servidores de aplicaciones, ficheros de configuración bases de datos, intercambios y un largo etc. Con XML definimos la idea de una entidad, un cliente por ejemplo de forma que la abstracción sea independiente del sistema de información donde va a utilizarse. Con este objetivo, la definición de la entidad puede incluirse en el mismo documento XML. XSL (Extensible Stylesgheet Language) se encarga de transformar este documento en una presentación en concreto. XSL permite que la misma entidad, definida por XML pueda presentarse de tantas maneras diferentes como sea necesario. XML se basa en bloques definidos por etiquetas, ilimitadas y que definen a si mismas, con las que las aplicaciones pueden pactar como intercambiarse datos o pedirse procesos.


de XML


XML no es un mecanismo de petición de servicios: es la descripción del servicio que se pide. La comunicación de los procesos, que piden y dan el servicio, entre si necesita, pues, de un mecanismo de petición. De forma general se dispone de un mecanismo de tipo RPC que está estandarizado en el Middleware de forma transparente a las plataformas y eficazmente soportado por TPC/IP. Este montaje se realiza a través de SOAP (Simple Object Access Protocol) que proporciona el Middleware para pedir de forma segura y autorizada los servicios a través de los cortafuegos de seguridad.

La estructura de un documento XML se define en dos partes:

Siguiendo las reglas del propio XML. Añadiendo, descritas con la sintaxis del propio XML, las reglas pactadas o estandarizadas para cada caso.

La definición del documento se hace con una DTD (Document Type Definition) de forma compleja o con XML Schema Definition Language de forma simple. Hoy día hay multitud de entidades definiendo DTD estándar. Una vez definido el documento debe capturarse de forma que los programas de gestión puedan interpretarlos lo que se consigue con los parsers XML que no son más que analizadores sintácticos que transformar la información en formatos que los programas pueden tratar. Existen dos tipos de parsers:

Los que generar eventos a medidas que van analizando el documento. Los que crean un árbol que el programa puede visitar con funciones que proporciona el propio parser. Uno de estos es el DOM (Document Object Model) que crea un árbol en memoria.

Los programas actúan siguiendo los nodos del árbol. XSL actúa también así. Existen productos, estándares, y especificaciones creados sobre XML y XSML que quedan fuera del abasto del ámbito de este capítulo.

3. Componentes de un documento XML. Se utilizan para definir el contenido del elemento. Los componentes básicos de un documento XML son: 3. 1. Marcas.

Una marca es una descripción que colocamos en el documento para que nos de información de lo que contiene. Con un conjunto de marcas se construyen los elementos de XML

3. 2. Elementos. <NombreDelElemento> Contenido </NombreDelElemento>.


La descripción de cada elemento se entiende como bloque, es decir, debe tener un inicio y un final </>. Los elementos pueden anidarse. Ejemplo: <cliente> <nombre>Lluís</nombre> <dni>34567890T</dni> <fechaNacimiento>19850203</fechaNacimiento> </cliente>

3. 3. Atributos. Es un componente para añadir descripciones a un elemento. Por ejemplo: <fechaNacimiento formato= « AAAAMMDD »>19850203</fechaNacimiento>

3. 4. Comentarios. Su formato es <! ------------------------------------>

4. Creación de lenguajes.

Usted puede crear su propio lenguaje empezando por definir su propio vocabulario incorporando la gramática necesaria para construir el lenguaje. Como ya se ha dicho, existen dos formas de hacerlo. La forma compleja es a través de la validación de documentos por DTD. Consiste en agregar al documento descrito reglas de validación para poder saber si un documento es correcto o no. Este procedimiento necesita personal formado y si desea conocer el formato de las reglas de validación consulte un manual específico de XML. Hay un atajo mucho más fácil a través del XML Schema Definition Language

5. Utilidad de XML

El interés por XML en los sistemas distribuidos se centra en varios ámbitos:

Separación y auto descripción de los datos con independencia de la plataforma.

Petición de servicios en general con independencia de la plataforma. Ideal para la comunicación con terceros.

Llamada a servicios a través de servidores de seguridad de forma transparente a la plataforma.

Configuración.


Estandarización de los interfaces de datos. Estandarización de las descripciones de las entidades más habituales. Definición de un lenguaje propio para las aplicaciones de un determinado sistema de información o compañía.

Repositorio de servicios SQL como ya hemos citado anteriormente.

6. Utilización de XML para interfaces. Observe el siguiente ejemplo:

<HTML> <HEAD> <TITLE> DATAFORMAT Version 1.0 </TITLE> </HEAD> <BODY> <METADATA> <FIELDS> <FIELD>attrname="NOM_EMP" fieldtype="string" WIDTH="3"</FIELD> <FIELD>attrname="NUM_LOCAL" fieldtype="string" WIDTH="3"</FIELD> <FIELD>attrname="Jornada" fieldtype="string" WIDTH="8"</FIELD> <FIELD>attrname="Hora" fieldtype="string" WIDTH="6"</FIELD> <FIELD>attrname="DNI" fieldtype="string" WIDTH="15"</FIELD> <FIELD>attrname="CodTarjeta" fieldtype="string" WIDTH="4"</FIELD> <FIELD>attrname="EntSalAnul" fieldtype="string" WIDTH="1"</FIELD> <FIELD>attrname="ClaseTarjeta" fieldtype="string" WIDTH="1"</FIELD> <FIELD>attrname="Origen" fieldtype="string" WIDTH="1"</FIELD> <FIELD>attrname="Estado" fieldtype="string" WIDTH="1"</FIELD> <FIELD>attrname="Tarea" fieldtype="string" WIDTH="1"</FIELD> </FIELDS> <PARAMS DEFAULT_ORDER="1" PRIMARY_KEY="1" LCID="1033"/> </METADATA> <ROWDATA> <ROW> NOM_EMP="061" NUM_LOCAL="BAR" Jornada="20010913" Hora="080852" DNI="33928613W" CodTarjeta="DP" EntSalAnul="E" ClaseTarjeta="D" Origen="A" Estado="V" Tarea="N" </ROW> <ROW> NOM_EMP="061" NUM_LOCAL="BAR" Jornada="20010913" Hora="171906" DNI="33928613W" CodTarjeta="DP" EntSalAnul="S" ClaseTarjeta="D" Origen="A" Estado="V" Tarea="N" </ROW> </ROWDATA> </BODY> </HTML>

Observe que hay una descripción inicial de los datos y a continuación una ocurrencia para cada uno de los registros que se quieren traspasar. Pactando esta descripción entre los dos procesos, emisor y receptor, tenemos la interfase resuelto. ¿Qué ventajas tiene este sistema? Libertad absoluta para añadir cosas sin necesidad de modificar las semánticas ya pactadas. Fundamental para desarrollo de nuevas aplicaciones o procesos. Además, en una escena con muchos actores, cada interlocutor puede coger la parte que le interesa de una información. Y no se preocupe por el tamaño. Cuando pase un fichero *.XML por ZIP se quedará sorprendido de la reducción del tamaño.

7. Ficheros de configuración y administración.


Los ficheros INI convencionales y las anotaciones en el registro de Windows son sustituidos mucho más eficientemente por ficheros XML donde pueden establecerse y validarse cada uno de los elementos de la inicialización. XSL permitirá mantener sin esfuerzos estos ficheros de configuración.

8. El binomio XML + SQL. Una forma muy utilizada actualmente de trabajar es utilizar ficheros XML para interactuar con los servidores de datos y que estos conviertan el XML en SQL a la entrada y de SQL a XML a la salida. Compagina así las ventajas de ambos entornos. Con XML + SQL + XSL puede crearse fácilmente un Framework de mantenimiento. El programa debe empezar por extraer el formato de la tabla de la base de datos en un XML que nos defina la estructura de la tabla que define a la entidad incluyendo restricciones de integridad en general y de valores de los atributos en particular. A partir de aquí con un XSL se puede mantener cualquier entidad de forma genérica. Muchos proveedores ya ofrecen XMLQL (XML Query Language) para interactuar con esa filosofía.

9. Internet y XML. La interacción y potenciación mutua entre Internet y XML es tremenda. Empecemos por separarla en dos grandes, la WEB convencional y los Servicios WEB. La utilización de XSL permite personalizar la presentación de acuerdo con el perfil, nivel e incluso idioma del usuario que de ha autentificado. Observe, además, que esta posibilidad es extensible a aplicaciones basadas en Sistema Operativo y entornos tipo PDF. Existen dos formas de hacerlo.

Que el navegador reciba el XML y el XSL y los gestione. Que el servidor WEB sea el que asuma la función y que el navegador ya reciba la página HMTL formada.

En cuanto a los Servicios WEB, no se imaginan sin XML ya que este estándar permite la petición y recepción del servicio con independencia de la plataforma. Y cuando el servicio es de una aplicación ya existente, el servidor del Servicio WEB utilizará la potencia de XML para realizar de pasarela al servicio con independencia de los formatos y mensajes de la aplicación original.

10. XML y conexiones con terceros. Por su propia naturaleza XML se presenta como un herramienta básica con la que armar la comunicación con terceros de forma transparente a las plataformas


implicadas. Temas como el comercio electrónico e intercambio de datos parecen impensables sin el mundo de XML. El problema es el formato del intercambio. Si estamos en condiciones de imponer o de ser impuestos, ya hemos acabado. Si no habrá que pactar y aquí aparecen como una necesidad imperiosa la adopción de estándares como ebXML.

11. XML e integración de sistemas. XML se convierte en la herramienta ideal para la integración de sistemas heterogéneos. Consulte el concepto de EAI, Integración de aplicaciones corporativas, del que se habla más adelante en el tema de Reingeniería, y verá que parece pensado para XML.

12. XML y Workflow. La utilización de XML para definir los flujos de los procesos WorkFlow es del todo natural debido a la generalización y características de XML. Se aprovecharán a fondo las posibilidades de:

Definir los modelos y flujos dentro del documento XML. Adaptación al perfil del usuario autentificado. Transparencia del intercambio con independencia de la plataforma.


Arquitectura de la comunicación en un sistema distribuido.

1. Diálogo y complejidad de un sistema distribuido. Imaginemos que estamos en un sistema distribuido con gran número de servicios y clientes. En un sistema donde todos ellos hablarán entre sí sin ningún tipo de organización la arquitectura de la comunicación resultante sería muy compleja y, probablemente, poco consistente. Es necesario, pues, establecer limitaciones y modelos que organicen y, porqué no, limiten el diálogo y que lleven a arquitecturas de comunicaciones claras y robustas. Las relaciones entre clientes y servidores se estructuran por niveles y se establecen según modelos estudiados y conocidos. La restricción habitual es trabajar con un método cuasi-jerárquico de diálogo por niveles o capas, presentado a continuación, en conjunción con modelos establecidos de relaciones entres servidores, arquitectura de servidores, que se presentará más adelante, restringiendo drásticamente, sino prohibiendo, la comunicación directa entre clientes. Dejaremos para un capítulo posterior los diferentes modelos de comunicación entre servidores presentados dentro del tema Arquitectura de Servidores.

2. Organización cuasi-jerárquica de diálogo. El sistema puede imaginarse organizado en tres niveles o capas lógicas integradas en un único Middleware:

Nivel exterior o nivel cliente, donde se sitúan los clientes.

Nivel Intermedio o servidor de aplicación, donde se sitúan los servidores de aplicación. Este nivel es donde se incluyen los servidores específicos de una aplicación en concreto. Como se verá en el capítulo dedicado a la integración conviene que este grupo funcione con las mismas reglas de integración que el resto del Middleware.

Nivel interno o servidor de Middleware, donde se sitúan los servidores de Middleware. En este nivel coexistirán servidores “comprados” como Middleware estándar y servidores genéricos desarrollados por la propia instalación pero utilizados por más de una aplicación.

Estructurado en estas tres capas, se organiza el diálogo entre los componentes del sistema distribuido con los siguientes criterios:

Servidor de sistemaServidor de aplicación

Cliente

Sistema Nivel Servidorde aplicación

Nivel Cliente

Nivel Servidor de Middleware

Figura 58. Organización por capas.


Obviamente, pero recordémoslo, el dialogo entre clientes y servidores y entre servidores entre si ha de ser transparente a plataforma, sistema y usuario.

No ha de existir diálogo entre dos clientes. Cuando se necesite, situación absolutamente anormal fuera de intercambios por interfases, un servidor debe hacer de buzón de intercambio y reducir el problema a una simple interfase.

Analice el diálogo entre servidores de aplicación. Probablemente, si un servidor de aplicación ha de ser usado por otro del mismo nivel de aplicación es un aviso de que puede ser útil para otras aplicaciones y le interesa integrarlo en la capa del Middleware

La relación entre los servidores del Middleware le será la mayoría de las veces desconocida. Si usted integra servidores construidos, intente, y consiga, que cuando lo haga pueda “desconocer” como se comunican dentro de esa capa.

Las ventajas de organizar la comunicación son muchas:

La arquitectura de esa comunicación queda organizada con reglas claras. Las interacciones dentro de la capa de Middleware quedan controladas internamente con lo que, en la práctica, el número de interacciones a controlar es menor.

Hay ventajas claras para: La gestión de errores, que puede ser de arrastre hacia arriba y gestionadas por el cliente.

Para la administración del sistema.

3. El problema de la congestión. Puede haber situaciones, por fortuna cada vez menos habituales, en las cuales si muchos clientes comparten un servidor y/o el diálogo necesita un tráfico importante, el tiempo de respuesta puede ser tan grande que el cliente puede llegar a pensar que el servicio no está disponible asumiendo, erróneamente, un time-out de respuesta. Como si esto ocurre el cliente se obliga a disparar el proceso de recuperación, el rendimiento quedará gravemente perjudicado. Este es el problema conocido como congestión del diálogo. Afortunadamente, las posibilidades y la potencia de las plataformas actuales están minimizando el problema. Sin embargo, no lo menosprecie y evalúe los rendimientos en caliente cuando tras el arranque inicial de la aplicación, el sistema empiece a trabajar en un régimen normal de carga. Si le aparece el problema, pude intentar diversas técnicas para resolverlo. La primera, y que le recomiendo explícitamente, aumente la potencia de la plataforma servidora.

Nivel Cliente

Nivel Servidor de aplicación

Nivel servidorde Middleware

Figura 59. Diálogo cuasi-jerárquico


Si aun así, el problema persiste, o el coste es demasiado alto, o el problema es demasiado puntual para justificar una inversión son técnicas habitualmente utilizadas:

Realizar una recuperación de errores eficiente. Véase, por ejemplo, la gestión de errores propuesta en el servidor de correo.

Que el cliente pregunte al servidor si está libre. La llegada de la respuesta, aunque sea que esta ocupado, servirá para que el cliente sepa que el servidor está muy ocupado pero activo.

Utilizar servidores master-slave, que encontrará explicados dentro del capítulo de arquitecturas de servidores. Actualmente, esto equivale a diseñar el servidor como multihilo.

Utilizar técnicas de comunicación Pull en lugar de las habituales Push. Si al final nada funciona, habrá que modificar el diseño inicial.

4. El estilo Pull de comunicaciones. El estilo Push es el clásico cliente / servidor. Con él, el cliente lleva la iniciativa. El estilo Pull de diálogo, representado por el símbolo de la figura, se organiza así:

El cliente envía una petición de atención al servidor. Si el servidor está ocupado, notifica o no al cliente que ha de esperar pero siempre se guarda la referencia y petición del cliente.

Cuando el servidor está en condiciones de atenderla lo notifica al cliente.

El cliente envía entonces el mensaje completo. En el estilo Pull el servidor controla el diálogo ya que decide cuando ha de comunicar. Observe que el diálogo Pull permite encapsular muy fácilmente dentro del servidor un sistema de prioridades. Existe la posibilidad de organizar un modelo de comunicación conocido como Pull conversacional que consiste en:

El cliente envía una petición de conexión. Si pasado un tiempo (time-out) no tiene respuesta lo vuelve a intentar.

El servidor mira de forma cíclica (scanning) si tiene petición de un cliente. Si es así, la acepta y le da el servicio.

Cuando el servidor ha acabado el servicio, vuelve a la exploración cíclica.


n del diálogo Pull


Una desventaja importante del método es que el servidor ha de conocer que clientes tiene “que escuchar”. Una forma cómoda de hacerlo es colocarlos en una tabla que el servidor consulta cuando arranca (veremos más adelante que esta tabla es la ficha de enviroment del servidor). Evidentemente si hay posibilidad de comunicación asíncrona, cosa hoy día casi siempre cierta, este diálogo puede suplirse por una simple cola. En fin, que dudo que entre una cosa y otra, usted tenga nunca necesidad de utilizarlo. El sistema Pull huele a historia....

5. Push y Pull en Internet.

Curiosamente, últimamente y con la llegada de Internet la terminología Pull y Push ha reaparecido. Y con una semántica que es, en cierta forma, contraria a la clásica C/S. Pull se puede entender como el sistema habitual en la navegación: el cliente pide la información a los servidores WEB, el servidor se anota la dirección de cliente, este se queda en espera, y cuando dentro del servidor le toca turno, éste remite la información al cliente origen de la petición.

La tecnología Push en Internet, denominada habitualmente POP-UP, se piensa como una forma de que el servidor tenga pre-anotados que clientes están interesados en una información y cuando esta se genera, el servidor inicia el envío. Por ejemplo, si Vd. se suscribe a una información de Bolsa, podría pactar que cuando una determinada acción bajará por debajo de un valor, se le notificará automáticamente. El servidor Web de la Bolsa iniciaría la transmisión cuando esta situación ocurriera. La notificación podría ser puntual (aperiódica) o periódica. Como todos conocemos, el sistema puede tener una alta tasa de peligrosidad: pueden bombardearle con información no necesaria a que nos conectamos a alguna Web de uso gratuito.

6. El diálogo entre clientes. Aunque como ya le he dicho le recomiendo que tome como criterio de diseño que dos clientes no intercambien mensajes que no sean interfases, en la práctica

Estilo PUSH

Estilo PULL

P

Figura 61. Push versus Pull

PULL

Petición

Respuesta

PUSH

Figura 62. Push y Pull en Internet


establecer comunicaciones entre clientes puede ser necesario en algunas contadas ocasiones. En estos casos, el diálogo entre clientes ha de hacerse con filosofía store and forward, es decir, se ha de actuar como correo en filosofía de interfase... Utilice, pues, un servidor de correo o una cola desacoplada. Si no recuerda bien la filosofía de un servidor de correo ni de la conexión desacoplada, repase los capítulos dedicados a ellos. De cualquier forma, no confunda diálogo entre clientes con integración de aplicaciones, concepto que desarrollaremos más adelante.


Programación de Aplicaciones Distribuidas. Metodología Puzzle

1. Introducción. Este es un documento de diseño tecnológico. Parte de la existencia de un análisis funcional y de la necesidad de implementar la aplicación como distribuida utilizando además de los sistemas convencionales técnicas cliente/servidor basadas en sistema operativo o Internet. Desarrollará los métodos y las técnicas para llegar desde el funcional a los programas y rutinas necesarias para conseguir la arquitectura distribuida. Y acabará donde empieza la programación (no confundir, por favor, con codificación en un lenguaje de programación) de los componentes resultantes. Y con ese criterio está desarrollado. Parto de la base de que usted, amigo lector, sabe perfectamente de la programación y sus técnicas. Y, por descontado, conoce a la perfección las diferencias que hay entre diseño tecnológico y programación. Así, la programación es un paso posterior al diseño distribuido e independiente de ese diseño. Cada organización la gestionará según su metodología habitual de trabajo. De todas las técnicas que Vd. conoce para diseñar y implementar programas, voy en este capítulo a proponerle las que a mi juicio se adaptan mejor aplicaciones distribuidas, para si usted no usa ninguna, puede buscar información más completa y empezar a hacerlo. Además, son las que utilizaré cuando tenga que referirme, a efectos didácticos, a la continuación del diseño tecnológico a través de la programación.

2. Internet y piezas/componentes de software. Este apartado debería estar al final de esta sección. Sin embargo y en previsión de que ya conozca lo que aquí se explica, o Vd. simplemente le aburra y se lo salte, quiero recordarle la bendición que supone para los desarrolladores la generalización de la compra y administración de piezas por Internet. En los tiempos “históricos” de este tema, ayer, las piezas se habían de localizar y comprar a través de distribuidores locales con todas las deficiencias de servicio y coste que ello suponía. Nunca tenías soporte sobre que hacia y como lo hacía la pieza, muchas veces el propio distribuidor lo ignoraba, si ayuda en los problemas iniciales. Y hablar de tener la última versión ya era un reto inabordable. Internet ha actuado como un Sant Jordi contra el dragón eliminando todos los problemas de soporte, actualización y localización de componentes. No hace falta que diga nada más. Todo esto es su historia de cada día. Solo una reflexión. Me declaro de corazón partidario del software libre. Pero la experiencia dice que hay que ser precavido. Sobre este tema tome Vd. su propia decisión.


3. Influencia del paradigma y las técnicas en Cliente/Servidor basado en Sistema Operativo o Internet.

El diseño de aplicaciones distribuidas supone básicamente el diseño de una arquitectura de aplicación. Hoy día se están utilizando básicamente tres paradigmas para construir aplicaciones distribuidas:

Programación estructura, secuencial o por eventos. Técnicas 4GL. Orientación a Objetos bajo UML.

La arquitectura no puede quedar condicionada a los paradigmas de programación sino que el método propuesto ha de ser general e independiente. En esta línea se introduce el concepto de pieza.

4. Implementación por programación de piezas. Las características de las aplicaciones distribuidas, y en especial si la solución es cliente/servidor, obligan a implementar por encapsulamiento. Como ya conoce, esto quiere decir:

Todo se implementa en rutinas, acciones o funciones. Cada rutina esta totalmente encapsulada, es decir:

El único diálogo entre cada rutina y el componente que la usa son los argumentos que la llamada proporciona y que sustituyen a los parámetros formales de la rutina.

Todas las variables de trabajo de la rutina se declaran localmente (es decir, internamente) a la rutina.

No existen variables globales. El algoritmo que llama a la rutina desconoce y no necesita saber como es su programación. Es decir, se consigue transparencia...

Las rutinas se agrupan por funcionalidades afines. Un conjunto de rutinas encapsuladas que resuelven temas comunes y encapsulan funcionalidad constituye una pieza. Los programas se montan como una combinación de esas piezas que resuelven las prestaciones necesarias. Evidentemente, parte fundamental de la historia es que todas las piezas quedan reutilizables.

5. Piezas y Clusters.

Es muy bueno agrupar las piezas por clusters, es decir, por grupos temáticos. Son ejemplos de clusters:


Cluster para la gestión del acceso a un entorno. Cluster de gestión de fabricación. Cluster de gestión de la entidad producto después de un Upsizing.

6. Piezas y Middleware “comprado”. Desgraciadamente, mucho del software de Middleware que existe en el mercado como estándar utiliza variables globales además de parámetros. No lo utilice así. Si se le ofrece la posibilidad de utilizar variables globales o rutinas use siempre las rutinas. Y si no se proporcionan rutinas, valórese seriamente la posibilidad de encapsularlo por su cuenta. El mínimo trabajo necesario no le reportará a la larga nada más que ventajas. A modo de ejemplo, considere el atributo visible de cualquier componente gráfico de una interfície GUI. Normalmente se dispone de un atributo global que puede ponerse a falso (objeto no visible) o cierto (objeto visible) y de acciones Show (visible) o Hide (no visible). Le recomiendo que utilice siempre la segunda opción.

7. Piezas y Middleware de mundo del software libre. Vale todo lo dicho en el apartado anterior con la salvedad de la modificación: modifique lo que necesite pero a partir de ese momento no baje nuevas versiones del software modificado excepto que la necesidad sea muy clara..

8. La metodología Puzzle. Esta visión de un programa como la integración de un conjunto de piezas que se integran armónicamente para resolver la aplicación la denominaremos genéricamente como desarrollada con una metodología Puzzle.

Esta visión tiene la gran ventaja de que deja el diseño absolutamente independiente de la programación y del paradigma elegido.

Cada uno de los componentes del sistema distribuido se implementa en una pieza. La arquitectura del sistema distribuido se construirá combinado y ensamblando piezas ya construidas. Una vez el diseño especifica una pieza, si ya se tiene una con esa especificación se reutiliza. Si no se tiene se busca en el mercado del Middleware, se compra y se utiliza. Si no existe en el mercado, o es cara (por inversión inicial o por coste de licencia por cliente) se construye y se incorpora a la biblioteca de piezas disponibles. Si la pieza se ha de fabricar, se hará con el paradigma que se desee, integrándola con el resto de las piezas ya utilizables con las reglas que haya convenidas en su entorno para la integración de Middleware y programas. El origen de las piezas puede ser, pues:

Middleware comprado. Piezas reutilizadas construidas con recursos propios.


Fabricadas por la aplicación que se esta construyendo: Como reutilizables, mayor esfuerzo. Especificas de la aplicación, menor esfuerzo.

Cada pieza ha de quedar definida perfectamente por un contrato de software donde se especifica con total detalle y fiabilidad el comportamiento de la pieza (atributos, métodos, eventos, comportamiento ante los errores, etc.). Obviamente, si trabaja así la metodología puzzle garantiza independencia del diseño con el paradigma y las técnicas de programación.

9. Técnicas para construir piezas. Le recomiendo dos técnicas para construir piezas con todas las ventajas que necesita:

Orientación a Objetos (OO). Tipos Abstractos de Datos (TAD).

Recuerde en este momento los comentarios realizados sobre estas dos técnicas en el capítulo dedicado a comentar las relaciones entre OO y C/S.

10. El contrato de comportamiento de una pieza. El contrato de comportamiento del software de una pieza se convierte en el tema clave. Como ya se ha dicho, ha de definir de forma total, clara, precisa y fiable el comportamiento de una pieza así como sobre que plataformas funciona.

Si ha de construirse, ha de servir para hacer el pedido de fabricación y para verificar y certificar el comportamiento a la salida del proceso de fabricación. Y si es comprada, a la llegada del pedido. La redacción del contrato se hará con la metodología de especificación que se haga servir en la instalación. Si no se dispone de ninguna es conveniente establecerla antes de empezar. Sea cual sea, ha de permitir que la especificación del contrato sea total, clara, precisa y fiable. Se habrá de establecer un modelo de especificación del contrato de la pieza común a toda la instalación. El formato único es vital para evitar el efecto torre de babel que aparece demasiadas veces en organizaciones de desarrollo de software. Este efecto conduce inexorablemente a la existencia de servicios montados más de una vez en la organización; y a veces, con efectos no exactamente iguales. Es conveniente que el contrato de software se formalice en un modelo físico que se pueda imprimir y consultar mediante un formulario sobre el paquete de ofimática que utilice la organización. Este modelo de impreso ha de ser general y ágil. General en el sentido de que ha de permitir especificar todas las situaciones posibles. Ágil en el sentido que ha de permitir cómodamente informar, de entre todo lo posible, sólo lo que interese.


Y también ágil en el sentido de ampliable. Si usted no dispone de un modelo ya creado no intente crear directamente el modelo universal y perfecto. Empiece por lo que necesite y “algo más” que se sea muy evidente, y amplíelo progresivamente. Y si encuentra alguno que le guste, utilícelo; no hace falta que lo invente si ya existe. La definición y el uso de plantillas que permiten los paquetes de ofimática le serán de gran utilidad.

11. “Cuatro ideas” sobre especificación de piezas. Recordemos de entrada que la especificación a de contestar a la pregunta de qué hace la pieza y no como lo hace. El primer criterio a establecer es el “lenguaje” a utilizar. Veamos algunos de los más habituales con algunos comentarios muy personales sobre ellos. 11. 1. Lenguajes de especificación.

11.1.1. Métodos de análisis.

Utilizando elementos de esa etapa como diagramas jerárquicos, flujos, clases, esquemas de datos, etc. Personalmente creo sirven más para explicar como trabaja la pieza que para explicar que debe hacer y que sólo son útiles para piezas de muy alto nivel.

11.1.2. Métodos formales. Utilizan postulados lógicos para expresar las ideas. Son de una gran exactitud, pero necesitan de una gran formación para establecerlos correctamente. Y para leerlos y entenderlos. Por ejemplo, si Vd. quiere expresar que un vector (tabla o array de una dimensión) declarado como: tipus VECTOR: tabla [1..50] de entero ftipus var a: VECTOR fvar Después de la ejecución de una rutina tiene todos sus elementos a cero, puede escribir: {∀ k: 1≤k≤50 : a [k]=0} Es frecuente que especificación formal muy bien hecha por personal muy formado no sea entendida por otros informáticos que han de usar la pieza debido a que no tienen esa formación lógica. Dentro de este grupo, además de los métodos formales basado en le lógica de predicados pueden incluirse también los métodos algebraicos (todavía menos populares).

11.1.3. Métodos de texto libre. La descripción se hace con lenguaje natural. Así, el postulado anterior podría expresarse como:


{Todas las posiciones de la “tabla a” están a 0} El texto libre es, con mucho, el lenguaje de especificación más utilizado. Pero es también la fuente más importante de generación de problemas de comunicación y responsable de buena parte de los errores de un programa antes de iniciar pruebas. Hay autores que le hacen responsable de hasta un 70% de estos errores. Así pues, si se utiliza este método no hay que perder de vista las cualidades de toda especificación que ha de ser total, precisa, clara y fiable. Autores como Meyer han definido “Los Pecados del especificador formal”:

Ruido. Incluir información innecesaria o redundante. Silencio. Falta de información. Sobre especificación. Detallar más de lo necesario. Contradicción. Una misma propiedad especificada de dos formas diferentes en dos partes de la misma especificación. Ambigüedad. Por falta de precisión. Un ejemplo habitual es utilizar una palabra sinónima para definir un concepto. Referencia hacia adelante. Utilizar términos y conceptos no definidos anteriormente. Remordimiento. Hacer precisiones o introducir restricciones sobre declaraciones anteriores.

11.1.4. Métodos semiformales.

Mezclan el texto libre con símbolos de los métodos formales. El texto libre facilita la inteligibilidad y los símbolos formales hacen los postulados más concisos y precisos. Es un muy buen recurso.

11. 2. Partes de la especificación de una pieza.

La especificación de una pieza ha de tener dos partes:

11.2.1. Global.

Cada pieza se caracteriza por un nombre y una descripción. Cada pieza dará uno o más servicios. Cada servicio se habrá de especificar independientemente. Si hay más de un servicio en la pieza se definirán globalmente:

Los tipos de los datos afectados. Las restricciones generales de uso y las incompatibilidades entre los servicios que aporta la pieza. Los eventos que recibe (obviamente si los hay).


Las características operativas. Este apartado definirá el comportamiento operativo de la pieza y su contenido dependerá del tipo de pieza. Por ejemplo, para un servidor habrá que especificar:

Tipo de comunicación. Posibilidad o no de paralelismo. Condiciones de arranque. Etc.

En un Objeto se habrá de especificar las características de la clase. Los atributos de propiedad. Los controles de administración.

Referencia dentro del sistema. Requerimientos del sistema. Restricciones de uso.

Usuarios. Nodos. Horarios. Etc.

Los estándares y/o plataformas sobre los cuales trabaja. En general, cualquier otra cosa que pueda interesar para caracterizar el comportamiento de la pieza.

11.2.2. Los servicios.

Los elementos del contrato de un servicio son.

11.2.2.A. Parámetros del mensaje de petición. Variables que constituyen los parámetros: nombre y descripción. Categoría o modo de esos parámetros: entrada, salida, entrada / salida. Paso de los parámetros: por valor, por referencia (o dirección), por tipo. Precondiciones de los parámetros de entrada y la parte de entrada de los de entrada / salida. Poscondiciones de los parámetros de salida y la parte de salida de los de entrada / salida. Invariantes. Son condiciones globales que se han de mantener antes y después de ejecutar el servicio. Es recomendable formalizarlos de la misma forma que las precondiciones y las poscondiciones. Un ejemplo de invariante puede ser: después de ejecutar un grupo de modificaciones de sueldo, la masa salarial de un departamento no puede sobrepasar un incremento porcentual del valor anterior. Especificación del comportamiento de errores, que trataremos a continuación. Especificación de eventos y triggers, que también trataremos a continuación.

11.2.3. El formato de cabecera de una rutina como método de especificación

de un servicio. Una forma habitual de especificar los parámetros es el formato cabecera de rutina:


funcionaccion

nombre_servicio Parametro1,...,ParametroN

Donde por cada parametro se ha de definir:

Categoria Paso nombre: tipo tamañ o

Categoria: entsale / s

Pas: valorreftipo

Las precondiciones y poscondiciones establecerán que condiciones tienen los valores de los parámetros de entrada y salida, es decir, como es el estado de entrada y como es el estado de salida. Un estado especificará, pues, por los valores de los parámetros afectados. La diferencia entre ambos es el efecto esperado del servicio. Veamos algunos ejemplos de especificación formal: Descripción rutina: colocar a ceros un vector de dimensión variable: acción ceros_vector(ent valor n: entero; sort ref a: tabla de enteros) /* n: número de casillas */ /* a: dirección de la tabla */ precondición: {n>0} postcondición: {∀ k: 0≤k<n : a [k]=0} Descripción rutina: Busca de un valor en vector de caracteres. acción busqueda_matriz(ent valor x: entero; ent ref a[1..50] de carácter; sort ref esta: booleano; sort ref pos: entero) /* x: valor a buscar */ /* a: tabla donde se ha de buscar */ /* esta: resultado de la búsqueda */ /* si está, pos tiene la posición si no el valor de pos es indefinido */ Precondición: {a=A Λ x=X} Poscondición: {esta ≡ ∃k: 1≤k≤50: a [k]=X Λ esta ⇒ a [pos]=X}

11.2.4. Especificación del comportamiento de los errores. Cada servicio habrá de especificar que errores controla y, por tanto, genera o recoge de niveles inferiores. A cada error habrá que asignarle:

Una referencia. Una descripción, que puede ser general asociada al tipo de error. Una tipología (aviso, error,..) Un grado de reacción (inmediata, demorada,..)


Las causas que lo producen. Información si el tratamiento de error es interno a la pieza (no recuperable desde el exterior) o se ha de gestionar externamente.

La gestión de errores en un entorno distribuido es suficientemente importante como para que la tratemos más adelante en detalle. Sin embargo, adelantemos que también hay que dar especificación del tratamiento de los errores:

Si el error se trata dentro de la pieza: Operativa de tratamiento. Opciones de que dispone el operador y consecuencias de cada una de las opciones.

Si la gestión de errores es delegada al algoritmo que llama a la rutina:

El formato del error dentro de la respuesta. Descripción semántica del error. En este segundo caso, la operativa y las posibilidades de recuperación del error serán responsabilidad del algoritmo que usa la pieza y no de ésta.

11.2.5. Especificación de eventos y triggers.

11.2.5.A. Para los eventos que puede recibir la pieza:

Se especifican según un mecanismo ECA para tratarlos. Es muy recomendable que la acción del mecanismo ECA sea un servicio de la pieza. Si se hace así, la especificación del servicio referenciado ya describirá la reacción de la pieza al evento.

11.2.5.B. Para los eventos de salida de la pieza, generados por triggers:

Cada servicio especifica los suyos. Se les asignará una referencia y una descripción. Se explicará la causa. Si ha lugar, se detallará el destino.

12. Implementación de la pieza y paradigma de programación. Como ya se ha dicho, la implementación de la pieza se hará según el paradigma y las técnicas de programación existentes en la organización de desarrollo. No hay que olvidar, sin embargo, las reglas básicas fundamentales para que la pieza funcione correctamente en la metodología puzzle y que se han explicado con anterioridad. Repasemos a continuación algunas de las reglas más básicas a seguir según el paradigma de programación utilizado. 12. 1. Programación estructurada.


En programación convencional, lo mínimo exigible es programación estructurada. Si utiliza este paradigma, recuerde que:

Cada servicio será una rutina pública. No ha de haber ni variables ni constantes globales. El único diálogo entre la pieza y su cliente ha de ser la cabecera.

La pieza será un modulo que englobe todas las rutinas. Hacer servir adecuadamente el paso de parámetros para optimizar el rendimiento. Por ejemplo, aunque una matriz muy grande sea un parámetro de entrada se pasará siempre por referencia.

Respetar al máximo el mecanismo ECA. La reacción de un evento conviene que sea siempre una única rutina.

Generalizar al máximo utilizando siempre que sea posible el paso de parámetros por tipo. es decir, en lugar de pasar un vector de 1 a 50, pasar un parámetro de tipo tabla y la dimensión de 50 elementos. recuerde que en este caso, y en la mayoría de lenguajes de programación, dentro de la rutina la primera posición se referenciará por la posición 0.

12. 2. Programación orientada a objetos y tipos abstractos de datos.

Además de todo lo del apartado anterior aplicable a estos dos paradigmas:

Cada pieza será un objeto o un TAD. Cada servicio será un método o una rutina pública. Posibilidad de asignar los servicios a controladores que después delegaran a las clases que realmente proveen el servicio de forma opaca al cliente.

Encapsular en funciones la gestión de atributos. En lectura bastará una función. En modificación, le permitirá controlar la integridad (valores válidos) y la coherencia (dentro de los valores válidos cuales son actualmente admisibles en función del estado de la pieza) de los atributos. Si deja a los clientes gestión directamente los atributos puede llegar a tener graves problemas en este sentido. Incorpore a la rutina de gestión modificación del atributo, un parámetro de salida para informar de posibles errores, detallando al máximo la causa.

Respetar el mecanismo ECA. recuerde que la reacción a un evento sea un método.

Evitar al máximo la gestión de errores dentro del objeto o TAD. Si es inevitable (pocas veces lo será) y ha de haber diálogo desde dentro de la pieza, actuar en el diálogo también con los criterios de pieza.

13. Implementación de Invariantes. Los invariantes puede montarse como una pieza, individual o compartida (linkada) con otras. Para avisar del incumplimiento del invariante pueden hacerse servir diferentes técnicas:

Tratarlos como un elemento más de la respuesta. Aprovechar la gestión de eventos generando un trigger.


Pueden aprovecharse recursos específicos de cada área informática. Por ejemplo, para verificar las condiciones de integridad de bases de datos pueden utilizarse los recursos que proporcionan “de base” las bases de datos activas.

14. Integración de las piezas. El tema se tratará en profundidad más adelante. Adelantemos sólo que puede ser de dos tipos:

Estática, linkada con el programa. Dinámica, por ejemplo, en un servidor.

15. Certificación de una pieza. 15. 1. Necesidad de certificar.

La fiabilidad de la metodología puzzle es basa en la absoluta fiabilidad de la pieza. La naturaleza misma de la metodología obliga a que el que utiliza la pieza desconozca su implementación con lo que le será imposible, en caso de descubrir errores, arreglarlos. Si la pieza da errores, desvirtuará completamente la prueba del software que la utilice. En caso de duda la tendencia a “pasar” el problema a la pieza y no al programa propio es tentadora y socorrida. Además, pasado un tiempo, arreglar errores en la pieza puede ser muy costoso (nadie se acuerda como esta hecha, el que la hizo ya no trabaja con nosotros, etc.) Esa fiabilidad ha de ser garantizada por una certificación de calidad que nada más puede garantizar la prueba exhaustiva de que la pieza cumple su contrato. O por la utilización de métodos de desarrollo que utilicen programación metódica y verificación analítica, métodos y técnicas que difícilmente se utilizarán por falta de formación del personal o por inviabilidad económica. La certificación de piezas abarca dos mundos:

El de las piezas compradas El de las fabricadas con recursos propios.

De buena fe, debe suponerse que las piezas compradas funcionan correctamente. Cualquier que esté desarrollando software actualmente sabe que, desgraciadamente, eso no ocurre. No olvide, pues, de probar y certificar las piezas compradas al igual que las fabricadas.

15. 2. Metodología de certificación. La certificación se ha de contemplar como una tarea por si sola. Pasará necesariamente por pensar y desarrollar entornos de prueba para cada pieza. La verificación que ha de certificar el comportamiento de la pieza según su contrato de comportamiento no se puede improvisar sobre la marcha. Cuando se esté diseñando la pieza se ha de pensar como se ha de probar de forma metódica según los pactos del contrato. Y cada acuerdo del contrato ha de ser probado en toda su extensión.


Si la pieza es general, no es recomendable aprovechar la misma aplicación que la usará para probarla. El recurso sería poco ágil, no se probarán probablemente todos los casos y los errores de la propia aplicación pueden desvirtuar la prueba. Es mejor desarrollar un entorno propio, basado seguramente en una interfície GUI, que haga la prueba ágil y cómoda y permita tratar toda la casuística completamente y punto a punto. La verificación de las piezas genéricas puede suponer, de hecho debe, una carga de trabajo importante que no puede ser obviada en la planificación sin riesgo de caer en desviaciones importantes en los plazos de entrega y los costes... Y el error de no probar por falta de tiempo conducirá al fracaso. En piezas fabricadas es recomendable que la certificación la realice personal que no haya participado en la construcción, hecho que aumentará la fiabilidad. Evidentemente, esto difícilmente es viable en organizaciones pequeñas. En piezas compradas que tengan más opciones de las que vamos ha utilizar, puede utilizarse la táctica de certificar sólo las que necesitamos. En esta caso, en la documentación ha de quedar perfectamente estipulado que se ha certificado y que no.

15. 3. Certificación y verificación analítica. La utilización de técnicas de programación metódica y/o de verificación analítica puede ser de gran ayuda para la certificación de piezas complicadas. Su gran problema es la formación y el tiempo necesario para hacerlo bien. Hay dos caminos:

Utilizar programación metódica completa. Utilizar programación convencional, eso si, con postulados, simplificar la arquitectura del programa con análisis descendente (programación estructura) y verificar analíticamente a posteriori. En este caso habrá que reducir el número de sentencias utilizadas al mínimo y conocer claramente cuales son las reglas de inferencia de la que se utilicen. Con una composición secuencial, una composición alternativa, otra alternativa y un mecanismo de llamada a rutina tendrá suficiente.

15. 4. Comentario final.

Si estos últimos apartados sobre programación metódica y verificación analítica le han sonado a chino, olvídelos. Si le han despertado curiosidad busque documentación apropiada. Ni este es el documento apropiado ni yo sé suficiente para explicárselo.


Gestión y Reusabilidad de Piezas y Componentes.

1. Introducción. La gestión de piezas es un caso particular de la gestión de componentes. Y la construcción y gestión correcta de componentes es fundamental para conseguir índices altos de reusabilidad, necesidad perentoria si una organización de software quiere ser competitiva y trabajar bien. En cualquier curso de diseño incluir las ideas básicas sobre este tema es fundamental. SI usted amigo lector ya sabe suficiente sobre este tema, salte al capítulo siguiente ya que aquí solo encontrará las ideas básicas sobre este tema.

2. Construcción de componentes. La construcción de componentes de software debería tener siempre como segundo objetivo su reusabilidad; el primero es obviamente que cada componente funcione como sea pensado. Vaya por delante la contradicción básica de la reusabilidad: generalidad del componente versus esfuerzo de desarrollo, y por tanto coste, para construirlo. Volveremos más adelante sobre este importantísimo tema. 2. 1. Cualidades que debe cumplir un buen componente.

Sin olvidar nunca la fundamental, que funcione, pueden enumerarse las siguientes cualidades deseables:

Ha de tener una especificación bien definida, sintácticamente y semánticamente.

Ha de ser fiable y robusto. Independiente del entorno. Trabajar dentro de lo posible con estándares. Adaptable a nueva situaciones y plataformas. General, es decir, válido a más de una aplicación. Tener buenas condiciones de reusabilidad.

2. 2. Componentes arquitectónicos (Framework).

Un componente arquitectónico o Framework, es un componente de alto nivel que encapsula comportamientos típicos de diferentes arquitecturas de programas. Por ejemplo, puede pensarse en diseñar un Framework para resolver el mantenimiento de ficheros.


Con solo citar este ejemplo ya se aprecia que los componentes arquitectónicos han de ser generales y tener una gran capacidad de adaptación. Es decir, para aprovechar el polimorfismo y la herencia, en su diseño e implementación está fuertemente potenciado el paradigma orientado a objetos. El desarrollo de Framework se convierte así en un elemento básico para conseguir altos índices de reusabilidad. La naturaleza de una arquitectura Cliente/Servidor hace la variedad Framework que se puedan definir sea inmensa. Veremos alguno de los más frecuentes en lo que nos queda de viaje.

2. 3. Reusabilidad y costes de proyecto. Los componentes muy reutilizables son caros de construir. Sin embargo, detectar, diseñar y construir componentes reutilizables es importantísimo para reducir costes. Pero, si hacerlos muy reutilizables requiere un gran esfuerzo en tiempo y recursos, se ha encontrar un equilibrio entre grado de reusabilidad y inversión. Sin olvidar que cargar el coste del componente reutilizable al proyecto que lo ha detectado puede ser terriblemente injusto por la penalización de costes y plazos de entrega. ¿Donde está el límite o cual es el criterio para encontrar el punto de equilibrio? El limite es conseguir el ratio prestaciones / inversión óptimo. Lo siento pero no conozco ninguna formula para calcularlo. De cualquier forma, hay un criterio que si funciona: el sentido común. Y hacer una buena criba inicial con una sencilla decisión. Distinguir si el componente es interesante como reutilizable fuera del entorno del proyecto actual o no. Recuerde también que el concepto de componente universal no existe más que en la teoría. Y que buenos componentes reutilizables con fuerte contenido semántico obligan a consultar con expertos en los temas que resuelven. Incluidos temas informáticos. Usted es seguro un buen informático, pero es también seguro que no lo sabe todo.

2. 4. Documentación. La documentación del componente debe incluir tres tipos de información:

Información de clasificación y localización. permite localizar el componente. Debe incluir los entornos tecnológicos sobre los que opera.

Información de uso: permite saber como debe usarse, es decir, como llamarlo y como obtener y analizar los resultados obtenidos. Debe incluir los estándares que usa o soporta.

Información técnica. Permite saber como está implementado el producto. Debe incluir información sobre su diseño.

Recuerde que elementos como los Servicios Web y objetos en UML tienen sus propias reglas de documentación que hay que respetar.


3. Gestión de componentes (Component Management).

La gestión de componentes es el conjunto de actividades dirigidas a controlar, documentar y administrar los componentes (piezas) de una organización de desarrollo de software. La gestión de componentes es un mundo por si mismo y es vital para una buena gestión de la reusabilidad. Cuantos más componentes haya, más difícil será su especificación, localización y calificación. Todo el conjunto se basa en:

Un estándar de especificación y documentación. Un repositorio donde se registra toda la información disponible. Un sistema de consulta y localización.

Como estándar de especificación y documentación puede servir el mismo que para el contrato de software de las piezas. Como repositorio utilice un producto de bases de datos documental o como mínimo una base relacional. Utilice las herramientas de consulta las ligadas a esos productos. Organice consultas normalizadas y deje herramientas para que los interesados realicen consultas puntuales. Necesitará criterios de clasificación para los componentes: temas, palabras clave, entornos, origen, etc. Las actividades propias de la gestión de componentes son: 3. 1. Actividades ligadas con el desarrollo.

Marcar estándares. Especificación. Selección. Adquisición, compra o fabricación. Coordinación del desarrollo de nuevos componentes. Garantizar la certificación de calidad (¡no hacerla!). Seguir las compras a terceros.

3. 2. Actividades de administración.

La administración de componentes la realiza el bibliotecario. Son actividades propias de este grupo:

Gestión del repositorio Normalización de las especificaciones. Clasificación. Registro. Documentación Administración del ciclo de vida.


4. El Comité de Componentes. Con todo lo que hemos visto, se advierte en seguida la necesidad en las actividades ligadas al desarrollo de que exista alguien que decida los estándares de reusabilidad, que se compra, que se construye y a que nivel de generalización se llega en cada componente. Aquí parece un problema diferente según el tamaño de la organización de desarrollo. En las actividades de administración, la figura del bibliotecario, que debe existir inexcusablemente, no presenta problemas. Si la organización no tiene suficiente volumen para tener un especialista la función puede asumirla a tiempo parcial cualquier otro elemento de la organización. No pasa así con las actividades de desarrollo que necesitan formación para tomar las importantes decisiones de este ámbito. Y, claro está, aquí el volumen de la organización es primordial. Si no hay suficiente volumen habrá que responsabilizar a una persona y que subcontrate funciones cuando no llegue. Si la organización tiene suficiente volumen, el mejor sistema es organizar un Comité de Componentes y mover toda las actividades de desarrollo a su alrededor. En la figura se muestra una posible organización de la gestión de las actividades de desarrollo de la reusabilidad alrededor del Comité de Componentes. Examinemos primero quien debe formar parte del comité:

Un director con autoridad técnica y de organigrama. El responsable técnico de los componentes. El bibliotecario. Jefes de proyecto (pocos) con experiencia. Expertos rotativos sobre la funcionalidad de componentes específicos. Los que propongan nuevos componentes o modificaciones y/o ampliaciones de los existentes.

En general, no es necesaria la presencia del jefe de sistemas. Las funciones básicas que debe asumir el comité son:

Proyectosde

Aplicación

Comité deComponentes

Construcciónde

Componentes

Comprade

ComponentesLibreria de

ComponentesREPOSITORIO

Comite de Componentes•Bibliotecario•Expertos•Director Proyecto•Jefes de aplicación

Comite de Componentes•Bibliotecario•Expertos•Director Proyecto•Jefes de aplicación

Evaluación

Cer

tific

ació

n

Cambios y/oampliaciones

Rechazo deCompras

Figura 63. El Comité de Componentes


Decidir y garantizar las plataforma de reusabilidad de la compañía Establecer los estándares. Evaluar cada petición a partir de la especificación recibida. Aprobarla o rechazarla. Decidir el nivel de reusabilidad de cada componente. Autorizar la compra o la fabricación.

Se establece así un flujo de propuesta / decisión que se muestra en la figura anterior. Los jefes de proyecto realizan las propuestas de componentes después de evaluar sus necesidades y consultar el repositorio. Pueden centrarse en nuevos componentes o en cambios y / o ampliaciones de los actuales. El comité acepta o rechaza la propuesta. Note que el rechazo es hacer un componente reutilizable, no de la necesidad del componente en si, decisión que es del jefe de proyecto. A partir de aquí, empieza el proceso de compra y / o fabricación sobre el cual el comité ya no interviene. El proceso acabará con la incorporación del nuevo componente o del cambio o ampliación al repositorio, funciones que ya son específicas del bibliotecario.

5. La gestión de componentes desde el proyecto.

No hay que olvidar que tiene sentido hablar de reusabilidad porque cosas ya construidas se aprovechan en nuevos proyectos o en modificaciones de otros ya existentes. Por esa razón, al hablar de reusabilidad hay que ver también el concepto desde el punto de vista del director del proyecto. La figura muestra como creo que un director de proyecto ha de contemplar el tema. Cuando el gestor del proyecto esta decidiendo la arquitectura y organizando sus programas estará trabajando sobre funcionalidad. En ese momento deberá consultar el repositorio de su instalación, a través de la

especificación de los componentes, para ver si ya dispone de componentes que le resuelvan su problema.

EspecificaciónRepositorio

Gestor Proyecto

Catálogo

Fabricadospor terceros

Orden de Compra

Reutilizables Apl.

Fabricaciónpròpia

Especificación

Orden de Fabricación

Certificación de Calidad

Consulta componentes disponibles

Contrato de Software

Recepción

Alta en el Repositorio

Fin Pruebas

Figura 64. La reusabilidad gestionada por el

Director de Proyectos


Si ocurre, es probable que tenga que modificar ligeramente su diseño original, pero aun así las utilizará. Si no tiene nada en el repositorio que le cubra su necesidad y sospecha que puede haber algo disponible en el mercado, consultará los catálogos o buscará por Internet para ver si encuentra algo disponible fabricado por terceros. Si es así, lo propondrá al Comité de reusabilidad que aceptará el nuevo componente verificando que cumple los estándares de la organización, o en su defecto, le propondrá una solución alternativa. A continuación lanzará, personalmente, a través del Comité o través del Dpto. de Compras, la orden de compra. Cuando llegue el producto deberá pasar la certificación de calidad, tras lo cual se incorporará en el repositorio de la organización. Si no encuentra nada fabricado por terceros que le resuelva el problema deberá fabricar el componente. Deberá decidir si la propone al Comité como de reusabilidad general o la desarrolla internamente al proyecto. En el primer caso, se realizará la especificación del contrato de software, se decidirá el equipo de desarrollo y se lanzará la orden de fabricación. Después de las pruebas de programación el componente deberá pasar la certificación de calidad y, posteriormente darse de alta en el repositorio. Algunas recomendaciones si compra software a terceros:

Certifique siempre el software que compre. Y estudie y documente su instalación.

No caiga nunca en el error de modificar un componente comprado; si dispone de las fuentes evidentemente. Clavará su compra en la versión actual. Cuando cambie, deberá repetir parte del esfuerzo.

Encapsule las diferentes interfícies del software comprado si tiene algún estándar en su instalación.

Siempre que le sea posible trabaje con estándares, aunque el producto que compre no sea el mejor técnicamente.

6. El ciclo de vida de un componente. Hablemos finalmente del ciclo de vida de un componente que se muestra en la figura.


El ciclo de vida de un componente se traduce en un atributo de estado ligado a su anotación en el repositorio.

El primer estado de la vida de un componente es su especificación que va a definir como será y que es sometida al comité de componentes. Si es aceptado se generará la petición de compra o fabricación. Al final del proceso de fabricación o a la llegada de la compra el componente quedará en un

estado de “en certificación” tras el cual el componente quedará listo para distribuir y se incluirá en la librería, anotándose en el repositorio. El componente estará en uso hasta que pase una de dos situaciones. La primera es que necesite cambios o ampliaciones que necesitarán una nueva especificación y una vuelta al comité de componentes con lo que se reiniciará el circuito. La segunda situación es que, por sustitución o actualización, el componente deje de estar disponible. Evidentemente no se podrá borrar de buenas a primeras ya que existirá software que lo está utilizando. Conviene marcarlo como “pendiente de borrar”. Solo cuando ya se tenga la certeza de que ha sido sustituido en todo el software en uso o que su necesidad ha desaparecido, se podrá borrar de la librería y descatalogarlo del repositorio.

EspecificaciónNuevo En

construcciónListo para distribución

En usoPendiente de Borrar(no hacer-lo servir)

RechazoPetición

Construido

Nueva versióna la librería

Marca de borrar

Borrar

Cambio de especificación

En Procesode Compra

En Certificación

Certificado

Recibido

Figura 65. Ciclo de vida de un componente


Distribución del peso de la aplicación entre clientes y servidores.

1. Introducción. Hay funciones que son claramente del servidor. Y otras que son claramente del cliente. Otras pueden situarse tanto en el cliente como en el servidor. Es obvio que el reparto del peso de la aplicación entre clientes y servidores es importante en la arquitectura distribuida resultante. Todavía es muy prematuro para exponer criterios de distribución. Pero no lo es para introducir el concepto de distribución de la funcionalidad, que será uno de los puntos claves del diseño.

2. Distribución del peso de la aplicación. Los sistemas distribuidos pueden ser cualificados por como se distribuye el peso de la aplicación entre clientes y servidores.

Se dice que una arquitectura cliente/servidor es fat server cuando se coloca mucha funcionalidad (mucho peso) en los servidores. Por el contrario, se dice que una arquitectura cliente/servidor es fat client cuando el peso de la funcionalidad esta en la parte cliente. Como ya se ha dicho en la introducción, hay funciones que son claramente de cliente, como las interfícies GUI’s. Por el contrario, otras son típicamente servidoras, como la localización de los servidores de las bases de datos (por favor, no confunda servidores de BD con servidores de lógica de datos). Debido a lo extendida que esta (y de lo mal que suena la traducción en castellano), voy a respetar los términos ingleses para fat server y fat client.

3. Fat Clients. Como ya se ha dicho, sistemas de arquitectura fat client son aquellos en los cuales el peso de la aplicación esta en los clientes. Son las arquitecturas más tradicionales en el mundo cliente/servidor donde en muchas aplicaciones la lógica de programa se incrusta en una interfície GUI que accede únicamente a servidores de datos y de impresión. Se utilizan ampliamente

Figura 66. La balanza de distribución del peso C/S.


en aplicaciones de consulta y personales. Normalmente son el modelo resultante de las aplicaciones de diseño rápido (RAD). Así, en el cliente se incluyen, además de la lógica de presentación, la lógica de control, la mayoría de la lógica de proceso y de negocio (toda en muchísimos casos) y toda la lógica de datos excepto algún procedimiento catalogado. Los sistemas fat client necesitan máquinas clientes muy potentes. Son fáciles de programar y de administrar. Sin embargo son escasamente distribuibles con todos los inconvenientes que ello supone. Adicionalmente, hacen que las máquinas cliente se queden obsoletas más rápidamente por rendimiento. Ello es debido a que como la mayoría de funciones se linkan en el cliente, cada vez que se compila el programa con una versión nueva de compilador y/o sistema, el programa se hace más pesado. Además, añadir funciones sencillas desde el punto de vista funcional puede suponer un aumento importante de las necesidades del cliente sobre su máquina. Proporcionan flexibilidad y oportunidades para crear aplicaciones con herramientas de alto nivel (programación visual, 4GL’s, Access...) y con personal poco formado o, incluso, usuarios avanzados. Son ejemplos de fat client: consultas de bases de datos, aplicaciones departamentales con poco mantenimiento, etc. Sin olvidar aplicaciones que deberían ser avanzadas y están, por desgracia, mal diseñadas. Cuando la carga del proceso se delega en servicios se habla de clientes ligeros como técnica para integrar las funciones cliente. Hablaremos de este tema al final del la metodología de diseño en el capitulo dedicado a la integración de la parte cliente.

4. Fat Server. Aquí, los servidores asumen el mayor peso de la aplicación. Exigen personal mucho más formado, pero son más fáciles de manejar y más adaptables. Obviamente son más difícil de diseñar y integrar que las aplicaciones fat client. Pero, ¡es mucho más divertido! Utilizan una gran cantidad de Middleware, comprado o fabricado, y un alto grado de reusabilidad. Minimizan la potencia del cliente y aumentan su vida útil. El cliente proporciona básicamente la lógica de presentación y minimiza las lógicas de proceso y datos. Finalmente la presencia de muchos servidores facilita de reingeniería de sistemas y la reutilización y adaptabilidad a la evolución. Son ejemplos de aplicaciones fat server: sistemas de venta al público, transporte, Workflow, multimedia, transacciones distribuidas, integraciones de Servicios WEB, etc.

5. ¿Fat Client o Fat Server?


La distribución del peso de la aplicación entre clientes y servidores no es axiomática. Cada modelo tiene su uso y la presencia de sistemas híbridos en lo normal. Como ya hemos hablado, las aplicaciones de consulta y en general los modelos de datos sin demasiada lógica de datos, suelen ser fat cliente. Fat server está muy ligado a las nuevas generaciones de servidores que encapsulan gran cantidad de comportamiento. Y se aplican a entornos con necesidad de mucha escalabilidad y fiabilidad. Y en general a SI desarrollados por el método de diseño avanzado. Muchas veces deberá elegir según la formación de su personal. No intente crear aplicaciones fat server si su organización no está formada. En general las aplicaciones fat server son más caras inicialmente pero más baratas a la larga si se trabaja convenientemente la reusabilidad. Si usted intuye o sabe que su aplicación tendrá evoluciones importante, prime fat server; al final seguramente ahorrará costes. Por el contrario si su aplicación es de “usar rápidamente” y no ha de tener evolución, prime fat client. Puede haber condicionamientos que marquen una arquitectura determinada. Por ejemplo, si Vd. tiene PC’s cliente no muy potentes y no puede cambiarlos o su no conoce exactamente como serán sus máquinas cliente, habrá de primar fat server. En el primer caso, sin cambiar los clientes podrá colocar un par de máquinas servidoras potentes donde localizar los servicios. En el segundo caso, exigirá menos máquina a sus desconocidos clientes. El coste de administración es algo mayor en aplicaciones fat server, pero queda compensado por la agilidad que proporciona, factor de difícil cuantificación. A modo de resumen global, fat client permite obtener resultados más rápidos a cambio de diseños muy convencionales y fat server permite un diseño mucho más ágil y modular a cambio de un nivel más alto de los desarrolladores y de una mayor inversión inicial. No es una elección de blanco y negro sino de tonos de gris.


Diseño y Programación de Clientes.

1. El cliente y sus atributos básicos. Recordemos que el cliente es el elemento que pide el servicio para obtener la funcionalidad o los datos. Su posición en la comunicación C/S es preactiva, es decir, que hace la petición y recibe la respuesta. Y que normalmente lo representaremos por el símbolo de la figura. Recordemos que la ficha de sus atributos básicos es:

Atributo Comentarios Actitud Preactiva, inicia el diálogo Ejecución Arrancar y acabar. Diseño Según la lógica de la aplicación Finalidades básicas • Mantener el diálogo con el usuario:

• Menús. • Gestión de las GUI’s. • Validación del diálogo con el usuario. • Ayudas a la operación. • Ayudas de sistemas expertos.

• Gestión y recuperación de los errores. • Construcción de las salidas por pantalla e

impresora. • Manipulación de datos. • Etc.

Utiliza • Los servicios del Middleware. • Los servicios de los servidores genéricos. • Los servicios de los servidores de aplicación

Ha de evitar Comunicaciones entre clientes. Cualidades deseables Transparencia.

2. Diseño del Cliente. El diseño del cliente será el pegamento que utilizando los servidores y la especificación de la parte de la funcionalidad que el diseño de la arquitectura distribuida le ha delegado, resuelva cara al usuario la necesidad funcional para la que ha sido propuesto. Es el lugar natural, junto con los agentes, para la creación, diseño y reutilización de Framework. Estos Framework se utilizarán como armazón para incrustar el resto de piezas y las llamadas a los servidores. Poténcielos siempre que pueda ya que, como se ya visto en el capítulo de reusabilidad, tiene todas las ventajas hacerlo así. Vamos a dedicar a continuación algunos apuntes de como diseñar y programar clientes dentro de un entorno C/S.

Figura 67. Símbolo

del Cliente


3. Las lógicas en el diseño del cliente. Dentro de la primera parte hemos trabajado con la clasificación convencional de considerar un programa distribuido en tres lógicas: presentación, proceso y datos. En las aplicaciones actuales, en las que la programación por eventos es muchas veces la base, es mejor trabajar el programa con cuatro lógicas: presentación, datos, control y negocio, siendo estas últimas el desglose por su función de la tradicional lógica de proceso. 3. 1. Lógica de Presentación.

Se encarga de interaccionar con el usuario. Implementada normalmente por técnicas GUI.

3. 2. Lógica de Datos. Se encarga de gestionar los datos. Es muy habitual que si la lógica de datos no está encapsulada en servidores especializados, actúe a través de ODBC y SQL.

3. 3. Lógica de proceso. Se encarga de proporcionar la funcionalidad. Incluye la lógica de control y la lógica de proceso.

3. 4. Lógica de Control. Es la encargada de dirigir el flujo del programa. Es la parte del programa que se encarga de llamar a los servicios, tanto de datos como de negocio para, trabajando cooperativamente, obtener el funcionalidad buscada. Se encarga de conseguir la funcionalidad delegada al cliente a partir de las lógicas de proceso y de datos. Puede delegar mucha funcionalidad en servidores (fat server) o poca (fat client).

3. 5. Lógica de negocio. Es la encargada de proporcionar las reglas de negocio, por ejemplo, si un cliente es eliminable, si estamos en aplicaciones concretas o las funciones de proceso en casos más generales, como por ejemplo, una encriptación.

Usuario

CLIENTELógica de Presentación

Lógica de Proceso

Lógica de Datos

Lógica de Control

Lógica de Negocio

Figura 68. Lógicas y Programas Cliente


Es muy habitual que la lógica de negocio acabe llamando en muchas ocasiones a la de datos.

Los conceptos ligados a estas lógicas ya se han presentado anteriormente cuando se propusieron los modelos. No vamos a repetirlos aquí. El objetivo de este apartado es recomendar como montarlas dentro de un mismo programa cliente, que evidentemente, puede ser visto con el esquema de trabajo de la figura ya presentado anteriormente. Cuando diseñe su programa cliente separe y encapsule claramente las cinco lógicas. Las cinco lógicas han de ser independientes entre si, incluyendo la de proceso que incluyen las de control y negocio La relación entre las lógicas ha de ser con filosofía transaccional. Tiene dos vías para conseguirlo:

Llamada a rutina, intercambiando el mensaje en los parámetros de la cabecera.

Cree eventos de usuario si la arquitectura del programa cliente lo permite y su arquitectura lo recomienda.

Y dentro de cada una utilice a fondo la metodología puzzle. ¿Qué conseguirá además de la satisfacción de trabajar bien? Razonémoslo. Como ya hemos presentado anteriormente, en algún momento habrá de decidir que parte de la aplicación se instala en clientes y cual en servidores. Y ya hemos visto y adelantado que la decisión estará llena de matices grises que inclinarán con muy poca fuerza en un sentido o en otro. Trabajar con lógicas independientes y comunicadas transaccionalmente le permitirá corregir fácilmente decisiones equivocadas. O decisiones en las cuales el paso del tiempo y/o la evolución de su empresa han cambiado el tono del gris y ahora le inclinan a colocar la función en la otra parte. Podríamos llenar hojas y hojas con ejemplos. Espero que cuando acabe de leerme usted mismo esté en condiciones de hacerlo. Quiero, sin embargo, presentarle algunos ejemplos para que vea la importancia capital que mi experiencia me ha hecho dar a este tema.

Imagine que ha colocado en un objeto visual la lógica de selección de los locales que han de ir en una lista desplegadle. Si no lo ha encapsulado en una pieza, y quiere cambiar el criterio deberá tocar todos los programas (seguramente muchísimos) que tienen esa selección. Si ha hecho una pieza le bastará modificar la pieza y volver a compilar los programas clientes que la usen.

Cuando creó una aplicación, la lógica de eliminación de un producto de la BD (que no tenga pedidos pendientes, que no tenga movimientos de stock, que no tenga stock, etc.) sólo se utilizaba una vez y por esa razón la colocó en el cliente. Y como trabaja bien, la encapsuló en una pieza. Ha pasado el tiempo y su empresa ha crecido. Tiene una delegación a 200 Km. de la central donde le aparece la necesidad de hacer la baja de un producto. Le bastará con crear un servidor con la pieza que encapsula la


lógica de la baja del producto y modificar la llamada de la rutina dentro del cliente por la llamada al nuevo servidor que, instalado en la Central, quedará disponible para uso de su Delegación.

Su instalación trabaja con una placa de encriptación por hardware. Cuando usted está diseñado el programa la tiene instalada en su ordenador e incluye su tratamiento en una rutina linkada en el programa cliente. Cuando va a instalar su fantástica aplicación le enseñan el entorno y “cae en la cuenta” de que habrá más de un ordenador ejecutando el mismo programa y que sólo ha comprado una de esas carísimas placas de encriptación. Rápidamente convierte la pieza de la rutina de encriptación en un servidor y, con suerte, nadie se habrá dado cuenta. Naturalmente que este caso es anecdótico y ha de tomarse solo a modo de ejemplo. Seguro que a Vd. no le ha pasado, ni nunca le pasará, nada parecido. Siento confesar que a mi si. Pero nadie se enteró. Esta es la primera confesión pública de mi pecado.

4. Metodologías para diseñar la arquitectura del cliente. Aunque el tema se tratará con mucha profundidad más adelante al hablar de la integración del cliente, es conveniente tener unas nociones sobre este tema antes de hablar de metodologías de diseño. Este es el objeto de este apartado. Según que lógica tome la iniciativa hay tres formas o metodologías de enfocar el diseño de cliente: 4. 1. Basado en la lógica de presentación

La iniciativa la toma el usuario a través de una interfície GUI. La lógica de proceso se va llamando al ritmo que marca el usuario. La lógica de datos es controlada por la de proceso. Las interacciones del usuario sobre la lógica de presentación son las que marcan la secuencia de ejecución. Las interfícies gráficas se construyen por integración de controles. Y los controles se gestionan por eventos. Por esa razón, es un modelo de diseño basado en una sucesión de eventos. Así, las técnicas de programación basadas en eventos están fuertemente favorecidas en clientes de este tipo. Como el control de la secuencia de ejecución la lleva el usuario, el diseño ha de encapsular comportamientos y secuencias de ejecución inadecuadas, liberando al usuario de esa responsabilidad. Por ejemplo, una técnica habitual será poner los controles de la interfície gráfica que en ese momento no sean semánticamente activos en deseable y los controles que no tengan sentido para ese proceso o usuario en hide. El programa debe proporcionar ayudas y guías al usuario para facilitarle su trabajo y minimizar el trabajo de documentación escrita. Si lo hace bien, y se apoya en la operativa estándar actual, podrá evitar probablemente el manual de usuario. Ese documento tan desagradecido que si existe no se mira nadie y si no existen todos los que se equivocan reclaman. E incluir en lo posible recuperación de los errores “dramáticos”.

4. 2. Basado en la lógica de proceso o de control.


La iniciativa la toma la lógica de control que sólo pide la actuación del usuario, a través de la lógica de presentación, cuando se necesita. La lógica de datos es controlada por la de proceso. La lógica de procesos determina el ritmo de ejecución de los diferentes procesos, clientes o servidores, y realiza la preparación y salida, gráfica o no, de los resultados. Dentro de este modelo de integración de las funciones del cliente están Batch, Publicación / Suscripción y Workflow, que se tratarán en otros capítulos posteriores dedicado a la integración de la parte cliente y que tiene un enfoque muy superior a la visión simple de un programa.

4. 3. Basado en la lógica de datos. Son metodologías basadas en bases de datos activas de alto contenido semántico y el diseño del cliente se basa en la lógica de datos utilizando transacciones distribuidas. Necesitan, pues, de la presencia como Middleware de un potente Gestor de Transacciones Distribuidas. Es un modelo escasamente utilizado en aplicaciones distribuidas. Generalmente son aplicaciones que únicamente utilizan servicios de acceso a bases de datos no locales y servicios de impresión.

5. Diseño de la lógica de presentación. Este es un tratado de diseño distribuido, no de interfícies gráficas. Pero no se puede obviar el hecho de que la mayoría de los programas cliente / servidor e Internet están basados en la gestión de una interfície gráfica. Por esa razón, dedicaré más adelante unos capítulos ha explicarle como veo yo el tema. Sin embargo, para atacar la parte de diseño en condiciones conviene hace algunas pequeñas reflexiones sobre como organizar una GUI en condiciones. La lógica de presentación se implementa en todos los caso en interfícies gráficas, Windows o Internet. Como ambos entorno presentan en la base las mismas prestaciones nos referiremos en general simplemente como interfície gráfica o GUI. Particularmente no me gusta la terminología castellana IGU (interfície gráfica de usuario). Hay dos formas básicas de hacerlo: 5. 1. Técnicas GUI (Grafic User Interface).

Son las habituales y sobradamente conocidas. Hay dos modelos:

Windows. Internet.


5. 2. Técnicas OOUI (Object Oriented User Interface). Las lógicas de presentación y proceso pueden montarse juntas o no. OOUI es una técnica que consiste en separar la lógica de presentación como una pieza independiente, generalmente OO, separada de la lógica de proceso como un cliente La lógica de presentación y la de datos puede estar localizada incluso en otras máquinas físicas, locales o remotas. Si los programas OOUI y el, o los, que llevan la lógica de proceso han de correr en la misma máquina, es obligatorio la presencia de un sistema multitarea eficiente. Tranquilo, hoy día todos los habituales lo son. Es prácticamente obligatorio usar técnicas OO para montarlo. Es un montaje muy interesante dentro de aplicaciones fat server.

Dentro de la lógica de presentación, un tema interesantísimo es la verificación de los datos registrados por el usuario en la interfície. Qué le parece, la verificación, ¿es lógica de proceso o lógica de presentación? Según la respuesta que dé a esta pregunta deberá incluir en una u otra lógica de su programa.

Si la incluye en la lógica de presentación: Ventaja: La transacción de entrada sale validada. Inconveniente: Parte de la lógica de proceso, que puede repetirse en otros programas queda ligada a la interfície.

Si la incluye en la lógica de proceso: Ventajas: La verificación puede encapsularse en una pieza. Se corresponde al modelo MVC de OO.

Inconveniente: La transacción no sale validada de la interfície.

¿Que hacer, pues? Le voy a dar un consejo basado en la experiencia. Dado que es muy difícil dar criterios para decidir cual es la mejor solución (técnicamente es mejor la segunda pero es más clara la primera), vacúnese cogiendo el camino del medio. Incluya todas las verificaciones en piezas. Y llámelas desde la lógica de presentación. El camino es todavía mejor si trabaja en OO. La verificación se encapsula en métodos asociados a los objetos gestionados por la interfície. Además con la herencia y el polimorfismo podrá obtener un grado altísimo de reusabilidad.

6. Clientes Background y Agentes. Un programa Background es un programa, que una vez arrancado, realiza su trabajo sin establecer diálogo con un usuario. Recibe sus parámetros de ejecución desde otros programas o desde el sistema. Parece difícil diferenciar entre programas Background y programas ejecutados dentro de una cadena Batch. Sin embargo la diferencia en clara. Cuando el trabajo Batch activa un programa es porque se necesita en ese momento de la ejecución


de la cadena. Un programa Background es un programa que se arranca y permanece oculto a la espera de recibir instrucciones. La llegada de estas instrucciones puede ser:

Por activación directa. Por colas. Si no hay anotaciones, el programa Background se auto suspende un tiempo prefijado.

Por eventos. Pueden ser ejemplos de programas Background:

Un sistema de facturación en el cual el cliente recibe ordenes de facturar por diferentes vías:

Una cola con las confirmaciones de salida de almacén. Venta directa desde punto de atención directa al cliente. Los portátiles de los vendedores ambulantes. Etc.

Un gestor de copias de seguridad permanentemente activado. Un servidor de correo. Un cargador de replicas de datos, etc.

Es más, en muchas ocasiones, los clientes Background sirven como interfícies para encapsular servicios proporcionados por servidores. Esa actitud reactiva les puede confundirlos con servidores de alto nivel desacoplados, es decir, agentes. De hecho, el servidor de copias del ejemplo anterior podría ser perfectamente un servicio. ¿Le suena? Efectivamente, acabamos de encontrar un Agente. La diferencia entre clientes background y agentes no es radical y se diseñan y usan igual. Si se les quiere diferenciar puede intentarse recordando que:

Un agente esta especializado y un cliente Background no (criterio, una vez más, muy confuso).

El agente está siempre activado. El cliente puede estarlo o no (confuso). El cliente Background puede llevar un mínimo de lógica de presentación. Este criterio si que es claramente diferenciador ya que la imagen gráfica que puede asociarse a un servidor no supone en ningún caso la presencia de lógica.

El cliente back-ground realiza la gestión de errores interactivamente, el agente informa un loging de errores y los envía al centro de control de errores del centro de administración que tiene asignado (diferencial)

El servidor da respuesta a una petición. El cliente Background normalmente no (otro criterio claro).

Cuando hay comunicación desacoplada para la petición de un servicio la llamada la recibe casi siempre un agente ya al ser la comunicación desatendida el modo de trabajo del agente también debe serlo.

De cualquier forma, los clientes background no son más que una forma de obtener servicios por lo que la discusión para distinguir entre ellos y los agentes en las aplicaciones distribuidas modernas en las cuales se trabaja


con servicios que, en muchas ocasiones, no sabes donde están ni quien los suministra, parece como mínimo banal.

7. Que necesita el programa cliente del Netware Operating System (NOS). El programa cliente necesita del sistema operativo de red como mínimo los siguientes servicios:

Sistema de localización, diálogo y comunicación con los servidores. Formatos estándar. Mecanismos de transferencias de ficheros y datos. Siempre que sea posible, y muchas veces de forma obligada, multitarea en la máquina cliente.

Soporte gráfico. Etc.

8. Transportabilidad y transparencia del cliente. La transportabilidad y transparencia del código cliente se deriva habitualmente de la transportabilidad del lenguaje de programación utilizado. Existe un peligro inesperado y sorprendente que nunca debería ocurrir: versiones del mismo lenguaje y del mismo fabricante no son compatibles entre si. Sorprendente, pero desgraciadamente cierto. Lo siento, habrá de convivir con ello. Particularmente yo lo he hecho... pero no lo entenderé nunca. Fuera de entornos C++ la transportabilidad no está garantizada y se han de consultar las plataformas soportadas por cada una de las herramientas. De cualquier forma C++ no es el leguaje idóneo para la mayor parte de los programas cliente y haga muchos números antes de utilizarlo. Le quedarán otros productos que si serán transportables dentro del paraíso del Sr. Gates. Con eso, y con las cuotas de mercado de Microsoft, probablemente tendrá bastante. Una opción cada vez más pujante es utilizar JAVA que permite programas desde programas cliente a servidores y hasta terminales móviles que pueden ejecutarse tanto en entornos Unix y Linux como Windows y en aplicaciones Internet o basadas en sistemas operativos. De hecho Windows es una plataforma de transportabilidad con criterios de distribuible y no distribuido. Más que suficiente, sin embargo, en muchísimos casos.

9. Herramientas de desarrollo para la parte cliente. No pretendo aquí, bajo ningún concepto, hacer una lista exhaustiva de estas herramientas. Solo quiero familiarizarle con la tipología de las más habituales. En este sentido lea este apartado. Evidentemente los grupos no son excluyentes y existe un solape cada vez más importante entre ellos. 9. 1. Herramientas profesionales.


9.1.1. Herramientas de desarrollo rápido (RDA). Gran potencia visual y de acceso a datos. Ideales para aplicaciones fat client. Un ejemplo dentro de este grupo en Visual Basic.

9.1.2. Herramientas de desarrollo avanzado

Facilidad para crear piezas. Son Orientadas a Objetos. Un ejemplo dentro de este grupo es JAVA y Borland DELPHI.

9.1.3. Entornos integrados 4GL orientados a objetos y cliente / servidor. Gran potencia visual y de acceso a datos. Gran cantidad de Framework creados. Con ayudas guiadas en la confección de los programas. Ideales para aplicaciones fat client de consulta. Un ejemplo dentro de este grupo en PowerBuilder. Y las herramientas propietarias de ORACLE.

9.1.4. Monitores de transacciones Para montar aplicaciones transaccionales de gestión de datos. Tienen productos de este tipo INFORMIX y ORACLE. También puede usar el histórico CICS para entornos C/S.

9.1.5. Herramientas de desarrollo en Internet. Desde entornos Java a .NET

9. 2. Herramientas de usuario final. Son herramientas utilizadas por usuarios avanzados para sacar información de consulta con autonomía del los sistemas informáticos estables.

9.2.1. Hojas de cálculo y otros recursos de los paquetes de ofimática. Es sorprendente la universalidad del EXCEL….

9.2.2. Bases de datos tipo Access.

Que además de poder definir sus propias bases de datos relacionales, permiten adjuntar tablas de otros motores relacionales donde están los datos corporativos o departamentales a consultar. En mi opinión es una opción confusa. Necesitan un mínimo de conocimientos de lógica de programación. Formación de la que no dispone un usuario avanzado. Y un informático acaba antes con un lenguaje convencional.

9.2.3. Lenguajes de usuario ligados a los 4GL. Por ejemplo PowerMarker y PowerViewer de PowerSoft o los productos de esta línea de ORACLE y SAP.


Poco usados ya que, aunque potentes, no compensan la falta de formación y especialistas en contra de la universalidad de la Ofimática del Microsoft.


Diseño y Programación de Servidores.

1. El servidor y sus atributos básicos. Recordemos que el servidor es el elemento que suministra la funcionalidad o los datos y que se representa por el elemento de la figura. La ficha de sus atributos básicos es:

Atributo Comentarios Actitud Reactiva, espera la llamada. Ejecución Continuada Diseño Especializado Finalidades básicas • Proporcionar servicios funcionales y de datos.

• Datos corporativos. • Tratamientos específicos. • Reglas de negocio • Comunicaciones compartidas. • Ficheros. • Servicios de impresión. • Fecha y hora, etc…

• Distribuir el sistema Ha que está obligado A esconder su implementación Utiliza Los servicios del Middleware. Ha de evitar Comunicaciones con otros servidores de forma

anárquica. Cualidades deseables • Transparencia.

• Reusabilidad. • Re-localización.

Conviene tener presente también en este momento el concepto de localización.

2. Fundamentos del diseño de servidores. 2. 1. Fundamentos del diseño de servidores.

Es especializado a la tarea asignada. A efectos C/S no importa el diseño interno. Se coge como una pieza construida que esconde los detalles de su implementación.

Ha de establecer un modo de comunicación con sus clientes. Se ha de controlar la gestión de errores. La forma de ejecución puede ser:

Está arrancado siempre, opción normal.

Figura 69.

Símbolo del

Servidor


Arranca a petición. La forma de arranque puede ser:

Dinámica: por otros programas. Estática: por parametrización del sistema, opción normal.

2. 2. Condicionamientos de diseño.

El servidor espera peticiones iniciadas por los clientes. Los servidores con multicliente. Hay situaciones en las cuales se encuentran clientes VIP. Hay que escoger, en fase de diseño, entre fat server o fat client. Los servidores necesitan apoyarse en servicios suministrados por el NOS+DSM y por el resto de servidores.

3. Las lógicas y el diseño de servidores. Al hablar de programas clientes, presentamos las cinco lógicas necesarias para diseñar un programa, presentación, datos y proceso, incluyendo esta última la lógica de control y la lógica de negocio. En ningún momento hay que olvidar que la gran mayoría de servicios son programas y que por tanto tendrían posibilidad de participar de las todas las lógicas. Por el concepto de servicio, la lógica de presentación no es aplicable a servidores. Las lógicas de datos y negocio son muchas veces la justificación del propio servicio que se ha diseñado para proporcionarlas. Pero, cuando un servidor necesite de otros servicios para completar su función, cosa muy habitual y que es el fundamento de la Arquitectura de Servidores, el propio servicio usará lógica de control.

4. Multiservidores y paralelismo.

La utilización de multiservidores ya hemos dicho que es una herramienta potente y escalable de la capacidad de servicio. El diseño de un servidor como multiservidor supone darle la capacidad de que pueda trabajar más de una instancia o copia simultáneamente del servidor. La posibilidad y la facilidad técnica para hacerlo es hoy día notable si se utilizan las técnicas multihilo que proporcionan la mayoría de los lenguajes modernos.

Hasta aquí las buenas noticias. El problema está en que hacer trabajar dos instancias del mismo programa supone adentrarse en los mares del paralelismo y la sincronización entre procesos, que como cualquier informático que se precie sabe, no es ninguna simpleza.

Figura 70. Servidores multicliente

multiservidor


Si el servicio es idempotente, es decir, la petición de un servicio concreto puede arrancarse tantas veces como se quiera y no interfiere con las de otras instancias (por ejemplo una consulta de clientes), el crucero por el mar del paralelismo será fácil y relajado. Si el servicio no es idempotente, la travesía puede convertirse en una turbulenta experiencia si el programador del servidor no conoce la problemática y tecnología de la programación concurrente. Estas técnicas quedan fuera del abasto de este libro, pero le recomiendo que se instruya en ellas si ha de utilizarlas. Note que no todos los servicios de consulta son idempotentes, recuerde, por ejemplo, una consulta de stock: si hay que repetirla, la probabilidad de cambio puede ser alta. Esto será habitual con consultas de mucha volatilidad. Para utilizar multiservidores se necesitan, pues:

Un sistema para trabajar los hilos (threads) que implementan cada instancia: Un recurso de programación: los modernos disponen de él. Un sistema operativo multitarea: todos los son.

Mecanismos implementados en cada servidor para coordinar la ejecución simultánea de los servicios no idempotentes de los hilos.

5. ¿Qué necesita el servidor del NOS + DSM?

Disponer de gestión multitarea, incluyendo mecanismos de interconexión de programas, en el nodo.

Tiempo compartido. Prioridades Semáforos Comunicaciones interprocesos (IPC), local y remota. Interrupciones por eventos para gestionar las esperas. Protección intertareas. Gestión eficiente de la memoria. Linking dinámico.

Servicios extendidos (Extended Services). Comunicaciones transparentes. Servidores de ficheros y de impresión transparentes. Servicios globales de naming, directorio y localización. Autentificación y autorizaciones. Disponibilidad y parametrización. Gestor de objetos distribuidos.

Finalmente citar que cuando faltan servicios de sistema puede optarse por dos vías:

Valorar la posibilidad de substituirlos por otros. Substituirlos por programación propia. En este caso se ha de trabajar con el modelo real de Middleware que se presentó en el capítulo de la integración.

6. Implementación y programación de servidores. 6. 1. Programación.


Los servidores distribuidos (universales) se implementan habitualmente en entornos C++. Tambíen el viable la utilización de Java. Los servidores distribuibles mediante la utilización de un lenguaje de mayor nivel, a muy frecuentemente el mismo de la parte cliente. Los servidores se han de integrar en lo posible como un componente más del Middleware.

6. 2. La “cara” del servidor. Aunque por definición, un servidor no debe interaccionar con los operadores, es bueno que en entornos gráficos, a cada servidor se le asocie una GUI que se conoce como la cara del servidor. En ella pueden incluirse datos como:

• Proceso en curso. • Estado de trabajo. • Acceso a Log’s. • Estadísticas de uso. • Etc.

Le recomiendo, por el grado altísimo de utilización de un servidor, que haga su GUI “espectacular”. Pero siempre en los momentos de no ocupación o de inicio o final de un proceso. Si no lo hace así, perderá un tiempo de proceso innecesariamente. Puede delegar la actualización a un hilo con la prioridad más baja.

6. 3. La ficha de enviroment del servidor. Una técnica muy útil para parametrizar las características estáticas y dinámicas de trabajo de un servidor es asignarle una ficha de enviroment. En la ficha se incluirán todos los parámetros de funcionamiento del servidor susceptibles de ser parametrizados. Le recomiendo dos niveles por parámetro:

Un primer nivel ligado a una variable lógica para decir si la opción está activa o no

Si el parámetro está activo, los márgenes cualitativos y cuantitativos de funcionamiento.

Por ejemplo, usted desea personalizar si un servidor debe estar permanentemente “activo” consultado una cola de comunicación con sus clientes o desea que el servidor “duerma” un tiempo en caso de que no haya peticiones de servicio durante un periodo. Evidentemente, con esto consigue optimizar el uso de la máquina donde reside el servidor. En el primer nivel habrá una variable lógica con la semántica de “vigilia permanente” o no. Si la opción está personalizada a que el servidor no debe estar permanentemente activo, necesitará dos parámetros más de parametrización: tiempo sin trabajar para ponerse a “dormir” y tiempo de


inactividad durante el cual es servidor dormirá. Una opción también podría ser, si su Middleware lo permite, despertar con un evento de trabajo pendiente lanzado por el cliente o por el servidor de cola de comunicación.

De forma resumida, se coloca en la ficha todo aquello de interés para la configuración, localización y administración del servidor. Se pueden incluir parámetros del tipo:

Localización por defecto. Tipo de arrancada permitida. Tiempos de “sleep” cuando no esta operativo (recuerde el ejemplo anterior).

Tipos de desconexión. Dispositivos físicos por defecto. Parámetros funcionales por defecto. Criterios de los parámetros de recuperación de errores. Niveles de accesibilidad. Grabación opcional de un loging de funcionamiento para analizar problemas y / o rendimientos, etc.

La implementación de la ficha de enviroment puede ser:

Sobre la misma BD en una tabla especializada. En el registro de Windows En ficheros *.INI o *.XML.

Prime esta última opción combinándola con al segunda. Por ejemplo puede montar la jerarquía:

Si hay fichero de inicialización manda su parametrización. Si no se coge del registro. Finalmente, si no hay ni uno ni otro, se coge las opciones por defecto del servidor que, obviamente, deben estar claramente especificadas en el contrato de servicio de su especificación.

Para mantener el fichero *.INI o *.XML puede usar un editor, o si la semántica es delicada, un programa especializado. No hace falta decir, que lo primero que ha de hacer el servidor cuando arranque es leer el estado de su ficha y personalizarse en consecuencia. La parametrización será así estática. Puede pensarse también en un parametrización dinámica, es decir, que el servidor lee “`permanentemente” su ficha para rescatar algunos parámetros que pueden cambiar “en caliente”. Esta técnica es más costosa en perdida de rendimiento que en coste de programación y solo debe usarse en situaciones que realmente lo requieran y con control y medida.

6. 4. Como conseguir independencia del sistema. Para conseguir que un servidor sea distribuido no basta con que esté escrito en C. Es conocido que hay funciones (como modificar la fecha y la hora del


sistema o el tratamiento de los canales serie) que tienen API’s diferentes para diferentes sistemas operativos. Ocurre en el fondo, que por puntos de heterogeneidad del sistema, una parte de la funcionalidad del servidor depende de ese sistema. Para crear servidores con esta problemática utilice un diseño del servidor de forma que la parte dependiente se incluya en rutinas encapsuladas. Así, podrá pasar de unos sistemas otros sin más que cambiar la implementación de esas rutinas. Existen diversas formas de integrar la parte dependiente:

Una versión para cada sistema personalizada en fase de link.

Una versión única para todos los sistemas personalizados. Una variable de la fecha de enviroment (si no es posible hacerlo automáticamente) decidirá que sistema es el que localiza al servidor.

Una versión única del servidor que delega a otro servidor la parte dependiente. En cada sistema se instalará la versión distribuidle a ese sistema de la parte dependiente. Ha organizado una arquitectura de delegación que le presentaré seguidamente.

Si me deja escoger, prime la segunda opción.

Código independiente del sistema

Código dependiente del sistema

Figura 71. Servidores

dependientes del sistema

Código independiente del

sistema

Código dependiente del sistema

D

Figura 72. Implementación

por delegación.


Arquitectura de Servidores/Servicios.

1. Introducción. Conviene recordar antes de empezar este capítulo, que hace ya muchas páginas que hemos dejado de tratar a los servidores como proveedores únicos de servicios. Existen también los agentes. Sin embargo, por razones históricas, de brevedad y por que la comunicación con agentes acostumbra a ser desacoplada y por traspaso de responsabilidad, se sigue hablando de servidores. Excepto que se diga lo contrario, en este capítulo, un servidor es cualquier suministrador de un servicio y utilizaremos el término servidor en este contexto ampliado. Por ello, los términos Arquitectura de Servidores y Arquitectura de Servicios són equivalentes. Los clientes se comunican con los servidores para pedir sus servicios. Pero los servidores también se apoyan en otros servidores para conseguir proporcionar esos servicios. Se convierten así en clientes realizando un polimorfismo de roles. En la filosofía de especialización que supone el diseño basado en servicios es poco menos que esperable que esto ocurra. Pero la comunicación entre los servidores, como ya se ha visto, no puede ser anárquica. Ha de estar estructurada y modelada. Y dentro de los posible, cuasi-jerárquica. Que modelos pueden utilizarse es el tema que vamos a tratar en este capítulo.

2. Multiserver Data Flow. Sucede frecuentemente que:

Un servidor necesita de otro para completar su función. Por ejemplo, un servidor de comunicaciones necesita de otro de encriptación antes y después de enviar o recibir un mensaje.

Hay servidores que se definen a dos niveles. Por ejemplo, un servidor de datos distribuidos.

Un servidor puede integrar otros servicios proporcionando un servicio de granularidad más alta. Por ejemplo, un para conocer la fechas de entrega estimadas de un albarán

Pueden buscarse otros muchos ejemplos. La forma en que unos servidores se llaman a los otros da lugar a hablar de Multiserver Data Flow, como la arquitectura entre los servidores y el flujo de información (peticiones y respuestas) que se genera entre ellos.


La arquitectura de servidores constituye el componente estático y fundamental siendo la plataforma sobre la que se genera el flujo, componente dinámico, que superpuesto a la arquitectura da lugar a hablar del concepto de Multiserver Data Flow. Hay dos modelos básicos. 2. 1. Modelo dirigido por el cliente.

El cliente lleva el control de la relación entre los servidores y, por tanto, de los mensajes que han de intercambiarse. Obliga al cliente a conocer la arquitectura del diálogo, lo que va fuertemente en contra de la transparencia, la modularidad, la reutilización y el uso de servicios entre terceros. Lleva a aplicaciones fat client. Es, en apariencia, una forma de evitar aplicaciones avanzadas, desarrollando por RAD. En contraposición con el modelo interservidores, se solía recomendar en aplicaciones con servidores muy independientes. Yo no voy a entrar en este modelo. Mi opinión personal es que no debe utilizarse nunca.

2. 2. Modelo dirigido por los servidores (interservidores). En la idea de transparencia y reutilización, el cliente ha de desconocer el flujo entre servidores cuando unos se comunican con otros para completar el servicio que se le ha pedido a uno de ellos. Esto lleva de forma natural a un modelo en el cual los propios servidores se organizan entre ellos de forma transparente al cliente. La estructuración de los servidores entre si es lo que da lugar a hablar de Arquitectura de Servidores. El cliente solo tiene que conocer la especificación de un solo servidor: aquel al pide el servicio completo. Además, si se diseña así, la adaptabilidad a los cambios y la modificación son mucho más fáciles. Las ventajas me parecen tan obvias, que no quiero extenderme más.

3. Concepto de Arquitectura de Servidores.

Este último punto no difiere de los modelos de comunicación entre clientes y servidores que ya se han tratado ampliamente con anterioridad.

Hablar de Arquitectura de Servidores es, pues, hablar de:

La tipología de su comunicación. La estructura funcional que las llamadas establecen entre ellos. Del modelo de comunicación que utilizan.


La arquitectura de servidores constituye el componente estático y fundamental siendo la plataforma sobre la que se genera el flujo, componente dinámico, que superpuesto a la arquitectura da lugar a hablar del concepto de Multiserver Data Flow

Observe que la presencia de arquitectura de servicios conlleva la presencia de lógica de control en el servidor. Le presento a continuación las tipologías de comunicación más frecuente.

4. Delegación de Servicio o Orquestación La Delegación de Servicio (Subrrogate Clients) es una tipología de relación consistente en que un servidor llama a otro desde la misma posición y con las mismas reglas que utilizaría un cliente en su posición. Hoy dia, en el mundo SOA, esta arquitectura se conoce

también como orquestación. El servidor simplemente asume el rol de cliente y establece un dialogo Cliente/Servidor convencional. La función del servidor delegado es añadida a la del servidor llamado por el cliente de forma totalmente transparente a aquel.

Diálogo

cliente/servidor

Servidor

A

ServidorB

Cliente D

Figura 73. Delegación de Servicio

La delegación de servicio es la relación por defecto entre dos servidores, de forma que si es un esquema no se incluye la relación se asume que es por Delegación.

D

La arquitectura entre servidores se define en dos componentes:

Estática, el modelo de arquitectura establecido en el diseño. Dinámica, el formato de los mensajes de comunicación que se establecen y la secuencia en que se intercambian.


En la figura se muestra un ejemplo de Delegación de servicio en la cual un servidor, para hacer altas de clientes, la realiza en la base de datos local y delega al servidor de alta de clientes en la central el registro del nuevo cliente en la tabla de clientes unificada de la Central. Obviamente, el servidor de la central es utilizado por todas las tiendas.

Si el servidor delegado llama a su vez a otro servidor se produce una delegación con varios niveles. Se conoce como profundidad de la delegación el número de capas delegadas. Particularmente, creo que es un dato sin ningún interés. Diseñe con la profundidad que necesite. Si me pide mi experiencia en este tema, le diré que nunca existen niveles de profundidad muy grandes y que nunca me he preocupado de este tema. El único problema importante es la gestión de errores. Como conceptualmente los errores han de ser tratados en los clientes, los errores generados en las capas más profundas han de ser trasladados hacia arriba ordenadamente y sin perdida de contenido semántico e integrando por afinidad. Esto exige siempre un esfuerzo del diseñador. Hablamos de mantener contenido semántico en el sentido que si una capa da error de conexión y la otra que no existe una entidad, el mensaje hacia arriba debe mantener los dos mensajes. Hablamos de integrar por afinidad el hecho de que si dos servicios dan el mismo error con dos códigos, idiomas o textos diferentes, el error generado debe ser único. Además del flujo hacia arriba de los errores, las técnicas de delegación o subrogación, tiene más o menos problemas es función de la complejidad del proceso. Por ejemplo, dentro de una arquitectura de modificación de datos, un servidor local de datos, paralelo al de altas del ejemplo anterior, modifica su copia e inicia, por delegación, la actualización de la copia de la central. Garantizar la coherencia de los datos con esta delegación de servicio no es trivial. Por el contrario, si la delegación se hace para pedir, por ejemplo, una encriptación, la complejidad de este proceso es prácticamente nula. Si la delegación de servicio se hace de forma asíncrona el problema puede complicarse aun más ya que el servidor en la posición cliente ha podido hacer muchas más cosas antes de recibir la respuesta de error del servidor al cual ha delegado parte de su trabajo.

ServidorAlta

ClientesCliente Clientes en la Central

RD

ServidorAlta

Cliente enla CentralRPC

Clientes en la Tienda

Figura 74. Ejemplo de delegación de Servicio


El tema no es fácil pero, por favor, no caiga en la trampa de los malos informáticos y eluda el problema no utilizando delegación (cargará de proceso innecesario y replicado a sus clientes) o haciendo siempre la delegación síncrona.

5. Arquitecturas con mensaje anexo.

En una arquitectura de delegación la petición y la respuesta viajan entre el cliente el/los servidor/es. Si el tamaño de los datos de la respuesta o la petición es grande o de tamaño variable puede ocasionar una perdida importante de eficacia en el tiempo de la

respuesta y en el dispositivo de almacenamiento de peticiones y respuestas. El problema se agrava cuanto mayor es la profundidad de la delegación. La utilización de la petición y la respuesta para codificar completamente el mensaje proporciona también una cierta rigidez al diseño ya que, en caso de tener que cambiar algo, hay que modificar código. La solución pasa por establecer una arquitectura de mensaje anexo entre los servidores de forma que la respuesta o la petición viaje directamente hasta o desde el cliente. Obviamente, este tipo de comunicación puede utilizarse con cualquier otra arquitectura por lo que el mensaje anexa cualificaro a la arquitectura base y en los esquemas aparecerán dos iconos, la notación de respuesta anexa (X) y la que corresponda a la arquitectura base. El flujo de información en el caso de respuesta anexa es:

1. Petición del cliente al servidor. 2. El servidor realiza su trabajo y

coloca la respuesta en un almacén temporal de respuestas (a).

3. El servidor envía la respuesta al cliente con un localizador: 3.1. El almacén de la respuesta

(b). 3.2. Un nombre de referencia

(c) para localizarla 4. El cliente decide si le interesa la respuesta 5. Si es necesario, el cliente recoge la respuesta del recurso compartido.

(a) Puede ser temporal o estar dotado de persistencia (b) La localización del almacén puede estar pactada en la configuración del servicio. (c) El nombre puede ser la referencia de la petición o un criterio preestablecido Obviamente, el caso de petición por mensaje anexo es totalmente paralelo y el mensaje puede ser anexo tanto en petición como en respuesta. La opción más interesante, actual y fácil de implementar una arquitectura de mensaje anexo es que el mensaje almacene la respuesta y/o la petición en una zona de memoria (implementación básicamente temporal) o disco (implementación básicamente persistente) visible por todos los actores que se traspasan un localizador como parte de la respuesta o petición.

1. Petición

ServidorCliente

2. Servidor coloca

respuesta

3. Respuesta

Almacén respuestas

4. Cliente decide si le interesa la respuesta

5. Cliente recoge

respuesta si le interesa

Figura 75. Arquitectura de Respuesta Anexa

X


La arquitectura de mensaje anexo es especialmente interesante en situaciones en las cuales un servidor necesita dirigir una respuesta de un volumen alto a otro servidor antes de enviarla al cliente. Para que el cliente decida si la respuesta le interesa o no, puede incluirse en la respuesta un mecanismo para cualificar la respuesta o la petición. Este modelo se conoce como respuesta anexa condicionada. Así, si queremos dar posibilidad al cliente de recoger o no, en función de su interés o necesidad, la parte extensa del mensaje, podemos incluir en la respuesta normal la información necesaria para saber si el resto de la respuesta, almacenada en el almacén, le interesa o no. Si la respuesta es afirmativa, recogerá todo el mensaje. Si es negativa, se evitará recoger la parte larga del la respuesta minimizando los tráficos de línea y el rendimiento. Si el almacén de respuestas tiene permanencia, el cliente deberá eliminar la respuesta o el servidor deberá disponer de un mecanismo de eliminación por caducidad. Por ejemplo, imagine que quiere saber si hay cambio de tarifas en un solo paso. Lanzará una arquitectura de delegación pidiendo la tarifa actual. La respuesta colocará el servidor, por ejemplo, un fichero XML y una carperta de un directorio, y la fecha de vigencia en la respuesta normal. El cliente comparara esa fecha con su tarifa. Solo recogerá y gestionará el fichero si la tarifa conseguida es posterior a la suya.

La arquitectura de repuesta anexa presenta otra opción muy interesante: la arquitectura de respuesta anexa condicionada en la cual el contenido de la respuesta se calcula una sola vez y es válido entre dos fechas de vigencia. Imaginemos el ejemplo anterior y que muchos clientes están pidiendo la misma tarifa. Es obvio que conseguir la tarifa y todo lo que la envuelve no es rápido. El servicio puede diseñarse de forma que siempre tenga la respuesta creada. En este ejemplo, el momento es muy claro: cada vez que se cambia la tarifa se modifica el archivo secuencial con la tarifa. Recuerde también que el servidor de correo utiliza arquitectura de mensaje anexo.

6. Traspaso de Responsabilidad. El Traspaso de Responsabilidad es una topología de relación que consiste en que un servidor traspasa a otro servidor, o incluso a un programa cliente, la responsabilidad total del servicio pedido. La semántica de la relación ha de ser de

tolerancia plena (full tolerance) para asegurar que el servicio se realizará siempre.

Servidorde

TarifasCliente

BDTarifas

X

D

Tarifa

D

Figura 76. Ejemplo de Arquitectura de Delegación con Mensaje

Anexo

T


Esto es así debido a que, por la tipología de la relación, el servidor que traspasa pierde el control del servicio. El traspaso de responsabilidad es como una especie de interfície resuelta por una comunicación asíncrona desacoplada. Es la opción por defecto cuando se llama un servicio como agente a través de comunicación desacoplada. Por esta razón si el servicio es un agente podemos omitir en la arquitectura detallar que es traspaso de responsabilidad al igual que hacemos con los servidores con la delegación. En la figura se muestra un ejemplo de traspaso de responsabilidad donde se modela una aplicación de recogida de pedidos. La captación de los pedidos se hace por Internet o por teléfono y se registra sobre un Servidor de Pedidos que delega a otro servicio, normalmente un agente, la función de traspasar el pedido a la tienda más cercana a la situación del cliente. Este servidor localiza esa tienda y traspasa el pedido a su cola de pedidos. La delegación de responsabilidad de la que se habla aquí es totalmente desacoplada y una ver el servicio se ha traspasado, el peticionario asume que el servicio pedido se responsabiliza asíncronamente de llevarlo a buen fin. Se habla a veces de traspaso de responsabilidad síncrona. Ese caso lo vamos a denominar redirección y la tratamos en el apartado siguiente.

7. Redirección.

La redirección se produce cuando el cliente llama a un solo servidor que decide que servicio fuera de él debe llamar. La elección se realiza mediante lógica de control ya que puede depender del estado del programa.

ServidorAceptación

Pedido

ClienteCaptura de

PedidoDirecto

Cliente

R

RD

ServidorAceptación

ClienteRPC

T

ColaTienda 1

ColaTienda NR

R

T

T

ClienteEntregaPedido

AgenteLocalizaciónTienda más

Cercana

ClienteCaptura de

PedidoTelefónico

ServidorWeb

Figura 77. Ejemplo de una arquitectura de Traspaso de

Responsabilidad

A


Cuando ha tomado la decisión, el servidor llamado por el cliente pasa el control totalmente al nuevo servicio que es el que devolverá la respuesta al cliente. El primer servicio queda disponible para tomar otro servicio. Obsérvese que una redirección tampoco es una arquitectura de distribución ya que el mensaje ya no vuelve al servidor original. En la figura se muestra dos ejemplos de redirección. En el superior, en caso de error se pasa control a un servidor de errores donde se puede centralizar labores como avisar a los centros de control, codificar, grabar loging, etc. En el inferior, el primer servidor solo se cuida de la validación de los parámetros en función del estado del sistema. Es obvio que los dos ejemplos pueden combinarse entre ellos.

La redirección en cascada consiste en una modificación mediante la cual los servidores se van pasando la petición hasta que uno de ellos la reconoce como suya y la atiende. La notaremos por el símbolo de la figura.

8. Servidores Interceptores.

Es otra forma de indireccción. El interceptor representar a varios servidores de su mismo nodo o zona de influencia. Quando recibe un mensaje analiza si es para uno

de sus representados. Si es asi, lo intercepta, realiza un proceso de aceptación, del estilo de verificaciones de seguridad, adaptacions de formatos, etc, y lo traspasa a su representado.

9. Servidores Pasarela. El servidor pasarela recibe la petición de otro servidor o un cliente y la traspasa en bloque a otro servidor. El servidor pasarela realiza la adaptación, de forma transparente a

quien lo utiliza y de la llamada, independizándolo del entorno. La pasarela puede recibir llamadas y traspasarlas a entornos diferentes según alguno de los parámetros de la petición. Son una tipología de arquitectura muy útil para salvar heterogeneidades de Middleware, principalmente sintácticas, pero también semánticas. La pasarela encapsula esa heterogeneidad y dirige la llamada a otros servidores que hacen la

Servidor

A

Respuesta normalCliente

Gestión del error

Servidorde

errores

Respuesta de error

Servidorde filtro deparámetros

A

Error de parámetrosCliente

Parámetros correctos

Servidor1

Respuesta correctaServidor

n

A

Figura 78. Ejemplo de una arquitectura de Redirección

P

AC

I


misma función pero en entornos diferentes. Y siempre de forma transparente al cliente que no llama. Una utilización de interés es permitir el uso asíncrono de servicios síncronos en origen. El servidor recibe la llamada de forma asíncrona y la traspasa y recibe de forma síncrona. En cuanto a la gestión de la respuesta y/o los errores, la pasarela realiza la función inversa, adaptando las diferentes respuestas a un formato único pactado con su cliente.

En la figura se muestra un ejemplo de arquitectura de servidores por pasarela: un sistema de información que permite consultar la catalogación de bibliotecas dispersas geográficamente a través de una WEB. La consulta, que se implementa sobre un programa cliente integrado en un componente de

presentación Internet, dispone de dos servicios: una consulta a los índices y una ampliación de la información. Un índice actualizado periódicamente permite disponer localmente de los libros catalogados en las diferentes bibliotecas. Cuando el usuario localiza un libro de su interés, el sistema está pensado para que acceda remotamente a la biblioteca en cuestión para conocer información más detallada y saber la disponibilidad de libro. El usuario realiza sus peticiones a través de una aplicación WEB que traspasa las peticiones a dos servidores especializados, uno en la consulta de los índices, en local, y el otro a un localizador que pide las consultas ampliadas a cada biblioteca (esta arquitectura que ya hemos visto en la primera parte, la presentaremos seguidamente como arquitectura de distribución). La petición de consulta ampliada al servidor de localización se realiza con un formato de parámetros único. El servidor localizador realiza la pasarela hacia cada biblioteca, adaptando parámetros y modo de comunicación. No hay que confundir delegación y pasarela. Un servidor que delega tratamientos a otro tiene incluida lógica de control y funcional (de proceso o de datos) y las llamadas a los servidores delegados se hacen solo para “delegar” parte de los tratamientos. Un servidor pasarela recibe la petición, la dirige al servidor adecuado realizando solo la adaptación de los parámetros y / o el transportista. La lógica funcional añadida por el servidor pasarela es mínima o inexistente. La lógica de control solo gestiona la pasarela.

ServidorLocalizador

ClientePrograma

ÍndiceBibliotecas

Catálogo UPC

Catálogo VIC

Catálogo Colegio

P

R

R

RP

P

Vías a los Catálogos

ServidorDistribuidor

Servidorde Consulta

a losÍndices

Índices

DD

Figura 79. Ejemplo de una arquitectura de Pasarela


10. Broadcast Data Flows.

Es un tipo de arquitectura que consiste en enviar la petición de servicio a todos los servidores. Todos ellos examinan la petición pero el invocado o invocados soon los únicos que la recogen. Esos servidores destinatarios son los que dan el servicio.

Observe la figura. El flujo de información puede resumirse, pues, en los siguientes pasos:

El cliente lanza una petición para el servidor B.

Los servidores A y C leen el mensaje pero no responden ya que no son los destinatarios.

El servidor B lee el mensaje, lo reconoce como propio, proporciona el servicio y responde al cliente.

Observe que el sistema es altamente ineficaz y que necesita que el volumen total de las interacciones entre el cliente y los servidores sea muy bajo o el transportista muy rápido. Es difícilmente escalable y poco seguro (todo el mundo ve todo). Y en el fondo, no es más que una forma encubierta de montar una comunicación entre iguales (pear-to-pear). La técnica puede ser de interés en tareas de sincronización, como por ejemplo, una sincronización masiva de fecha y hora.

11. Arquitectura de Filtro (Filtered Data Flows).

B

DiálogoBroadcast

ServidorA

ServidorC

Cliente

ServidorB

Figura 80. Arquitectura de Broadcast.

F


En una arquitectura de delegación en la cual la petición o la respuesta respuesta debe de pasar un filtro entre el servidor y el cliente. Normalmente el tamaño del mensaje es importante por lo que lo normal es que esta arquitectura se aplique junto a la de mensaje anexo. De es tan habitual que hay la construmbre de no especificarlo en la definición del servicio. Todo lo dicho antes para este modelo de comunicación vale aquí. Observe la figura donde se aplica un filtro a la respuesta. El flujo de información es básicamente así:

1. Petición del cliente al servidor. 2. El servidor localiza la información. 3. Gestión de la respuesta

3.1. El servidor pasa la información o informa de la localización de la respuesta al filtro.

3.2. El filtro envía la información al cliente. 4. El filtro avisa al servidor que ha acabado. 5. El servidor envía la notificación de respuesta al

cliente, que ha permanecido transparente al mecanismo.

6. Si es necesario, el cliente recoge la respuesta del recurso compartido.

Observe el ejemplo de la figura. En un documento multimedia, un servidor de imágenes tiene la información comprimida. El servidor de obtención de imágenes al que llama el cliente las obtiene del servidor de imágenes y la pasa a través de una arquitectura de filtro al servidor de descompresión.

12. Servidores Master-Slave.

La arquitectura Master-Slave está basada en el modelo de comunicación del mismo nombre forzando que el modelo de comunicación sea Cliente/Servidor.

1. Petición

ServidorCliente

Filtro

2. C

onex

ión

3. Servidor coloca

respuestafiltrada

4. F

inal

izac

ión

5. Confirmación

Almacén respuesta

6. Cliente recoge

respuesta

Figura 81. Arquitectura de Filtro

ServidorObtenciónImágenes

ClienteTratamientode Imágenes

Imagen Compactada

BDImágenes

X

D

ServidorDescom-presión

Imágenes

SF

Imagen Descompactada

D

Figura 82. Ejemplo de Arquitectura de Filtro

M


El flujo de datos en esta arquitectura es el siguiente:

El cliente envía la petición a un servidor que asume la posición de master.

El servidor válida la petición e inicia la ejecución de un servidor Slave que es el que realmente da el servicio.

La respuesta es generada por el Slave de forma transparente al cliente.

Esta arquitectura es una forma de aumentar espectacularmente el volumen de servicio del servidor y por tanto de conseguir una alta escalabilidad. Además, actualmente, montar estas técnicas es muy fácil con las técnicas de multihilo. UNIX es un sistema operativo que permite montarlas muy eficientemente, por lo que en ocasiones se justifica hacer el servidor distribuible en lugar de distribuido para aprovechar estas ventajas. La arquitectura Master-Slave exige, para tener sentido, una comunicación asíncrona. Un ejemplo de utilización puede verse en la figura en que servidor de listados (por ejemplo, un impresor centralizado de facturas en una tienda) aumenta su rendimiento escalando el servicio en una arquitectura Master-Slave. Existen dos limitaciones a la técnica:

La necesidad ocasional de tener que hacer el servicio distribuible en lugar de distribuido, de la que ya hemos hablado.

Evitar el colapso de la máquina servidora por el lanzamiento de un número excesivo de Slaves en momentos de punta de servicio. Ello obliga en la práctica a limitar el número de copias dentro de la ficha del servidor.

La tercera limitación tradicional de la técnica ya no lo es en la práctica. Master y Slaves deben estar en la misma máquina lo que exige un sistema operativo multitarea. Pero hoy día todos los sistemas lo son ya. Aunque salgamos del tema de este capitulo, observe que la técnica de Master-Slave es aplicable a agentes para:

Aumentar el número de instancias que trabajan simultáneamente.

ClienteServidorMaster

ServidorSlave

Petición

Respuesta

Figura 83. Arquitectura Master-Slave

ServidorDistribución

listadosClienteObtenciónEstadística

D

M

Datos Listados

ServidorConfección

Listado

ServidorImpresión

Figura 84. Ejemplo de Arquitectura Master-Slave.


Especializar los hilos en funciones independientes: por ejemplo, el agente integra su propia cola y un hilo da los servicios de la cola.

13. Servidores de Distribución.

Ya vimos una arquitectura de distribución en el capítulo dedicado a

Internet de la primera parte. La distribución se basa en que el cliente pide servicios diferentes a un único servidor que se responsabiliza de enviar la petición a cada servidor especializado. La respuesta vuelve de la misma manera. Recuerde como ejemplo de distribución la arquitectura de Internet explicada en aquel capitulo. En la figura tiene otro ejemplo en el cual un servidor único de ficheros recoge diversos formatos desde una base de datos centralizada. La arquitectura de distribución se usa para resolver puntos de singularidad. Por ejemplo:

La conexión entre dos entornos interconectados pero no interoperables.

La distribución facilita el diseño de situaciones como en control centralizado de accesibilidad de usuarios a un grupo de servicios. El uso de esta arquitectura también facilita el analisis de consistencia permitiendo agrupar, y controlar, servicios afines. En el capitulo dedicado a la consistencia volveremos a tratar sobre este tema.

ClienteServidor

Distribuidor

TipoServidor 1

TipoServidor 2

TipoServidor 3

TipoServidor n

Peticiones

Respuestas

R R R R

Figura 85. Arquitectura de Distribución

R

ServidorDistribución

ClienteCambioTarifas

ServidorCambio

Tarifas alLocal

Tarifas Local

ClienteEntradaCódigo

ColaPeticiones

Servidorde

Ficheros

R

Tarifas en Central

BDLocal

R

ServidorCheck de

código

F

R

R

R

Figura 86. Ejemplo de Arquitectura de Distribución


14. Arquitectura de Pre-Condición.

Una arquitectura de pre-condición se establece entre dos

servidores cuando la ejecución del servicio proporcionado por uno de ellos está condicionada por una condición ligada al estado del otro. Pre-C es una referencia de la especificación de la precondición. Por ejemplo, un sistema dispone de un servidor de actualización de stock y de

otro de consulta de stock. Cuando el de consulta recibe una petición para consultar el stock de un producto deberá de asegurarse de que no hay ninguna petición de modificación de stock para ese producto en el servidor de actualización. Si es así, deberá retener la consulta hasta que la actualización se realice. Es habitual que en una arquitectura de precondición, se disponga de un mecanismo para cambiar

la prioridad de la anotación de actualización de un producto cuando hay una consulta pendiente del mismo producto. Hay diversas formas de implementar una arquitectura de pre-condición según sea la necesidad y el tipo de la condición. Una forma muy habitual es que la relación se establezca mediante una cola compartida entre los dos servidores. En este caso, la cola se monta siempre como un servidor independiente. Como ya se ha dicho en el ejemplo, el servidor pre-condicionado puede estar autorizado a cambiar prioridades de la cola para minimizar las esperas. Cuando se produce una espera por la detección de una relación de pre-condición, esta espera puede ser notificada o no al cliente. El criterio es avisar siempre que la demora pueda ser importante. La arquitectura de precondición es muy potente pero nada simple de implementar por lo que conviene no abusar de ella y utilizarla sólo cuando no sea posible otra solución.

ServidorCliente

ServidorPre-

condición

Pre-C

ServidorCliente

ServidorPre-

condición

Pre-C

Figura 87. Arquitectura de Pre-Condición

Pre-C

ServidorActualiza-

ción Stocks

ClienteMovimientos

Almacén

ServidorConsultaStocks

ColaCambios

ClienteFacturación

ColaConsultas

Stocks

No cambiosPendientes

del Producto

Cambio Prioridad

Figura 88. Ejemplo de Arquitectura de Pre-Condición


15. Arquitectura de configuración.

La arquitectura de configuración se establece entre dos servidores o un cliente y un servidor cuando uno de ellos le proporciona al otro un servicio, normalmente en el momento del arranque, para autoconfigurarse dinámicamente en función de la situación actual

del sistema de información. Por ejemplo, imaginemos un sistema en el cual las reglas de validación del stock de los productos cambien con la evolución del mercado. Para evitar tráfico y demoras innecesarias, suele ser conveniente que la lista de productos a verificar se haga llegar cada día a los puestos de venta consiguiendo así que solo se pierda tiempo verificando stock de aquellos productos que realmente lo necesiten. En esta situación, lo normal es que un departamento de la organización centralice la decisión de que productos hay que gestionar, normalmente con procesos también informatizados, y que, por tanto sea necesaria la creación de un servicio para conocer cada día que stock de productos hay que confirmar y cuales no. Cuando el servidor de validación de stock arranque, o una vez al día si está perpetuamente arrancado, accederá al servició servidor de configuración para registrar la situación de ese día. Más adelante comentaremos que posiblemente el servidor afectado tendrá una arquitectura de representante. Si el sistema de stock está basado en el propio almacén y un almacén central donde se puede recurrir en caso de ruptura del stock local, la arquitectura de servicios finalmente establecida se parecerá mucho a la de la figura. Esta arquitectura de servicios es aconsejable también cuando el tiempo de trasporte sea largo y se pueden hacer validaciones previas antes de pedir la definitiva. Esta situación es frecuente en arquitecturas basadas en Servicios WEB de Internet. Imaginemos que la validación de un cliente en un proceso de alta esta encapsulada en una regla de negocio que se mantiene centralizadamente o de forma totalmente opaca a terceros. En esta regla de negocio habrá:

Reglas estáticas:

C

ServidorStock

AlmacénCentral

Clientede captura

de pedidos

Stock local

Stock Central

ServidorStock Local

Servidorproductos con stock a verificar

Productos con stock a verificar

C

D

R R

D

Figura 89. Ejemplo de Arquitectura Configuración


Formatos sintácticos de los campos: por ejemplo, no se admiten entradas sin asignar zona o DNI.

Reglas de restricción entre los campos: por ejemplo, un cliente de extranjero no puede admitir la forma de pago a 60 días.

Etc. Reglas dinámicas.

De concurrencia: por ejemplo, la asignación de código. De gestión: por ejemplo, el cliente no está en una lista de morosos. Que productos deben verificar stock. Etc.

Alertas de negocio. Con los puntos vigilar. Como por ejemplo, stock de productos que por causas de mercado tienen problemas de abastecimiento.

En un sistema opaco a terceros como puede ser un banco, los datos de la entidad cliente que se quiere registrar viajarían hasta el banco para ser validados y si hay error devueltos al origen para ser modificados. Es evidente que esta operativa solo es estrictamente necesaria en el caso de las reglas dinámicas. Puede establecerse una arquitectura que, en el momento del arranque, el programa de alta de clientes solicite al banco las reglas estáticas de validación para que se verifiquen “in situ” antes de pedir remotamente la validación de las dinámicas. La arquitectura resultante sería la de la figura. Obsérvese que puede ser habitual que se comparta una arquitectura de delegación y configuración a través de una entrada de distribución. Esta arquitectura se monta fácilmente a través de Servicios WEB utilizando Internet como transportista y objetos como técnica de implementación donde el servidor de configuración suministra un objeto que modela el cliente del banco con un método de validación estática. El programa de altas pide el objeto a través del servició de configuración en el momento del arranque y lo instancia dentro de si mismo. Todas las verificaciones estáticas se realizan en local y solo se piden al banco las dinámicas. Obsérvese que el programa de alta de cliente puede ser Internet o Windows convencional, es decir, cliente/servidor basado en Internet o en Sistema Operativo. Otro ejemplo es el mostrado en la siguiente figura:

Servidor Altas de Clientes

Proceso de alta de clientes

Servicios del

Banco

ServidorReglas de Negocio

C

D

R R

Figura 90. Ejemplo de Arquitectura Configuración para el

alta de clientes remota.


En el se muestra una posible arquitectura de un agente que gestione PDA’s que han de trabaja de forma sincronizada. Sobre la PDA se instancia un cliente de presentación que puede estar residente en la PDA o ser arrancado desde un

programa de arranque sobre esa PDA que lo recoja de un servidor de programas. La PDA interaccionará con el resto del sistema distribuido a través de un agente master-slave. El agente, donde se llevará control y coordinación de las sesiones abiertas, de configurará a partir de servicios del sistema y/o directamente de disco, las dos opciones punteadas en la figura. Cuando la PDA arranque le pedirá la master del agente la autentificación. Este servicio de autentificación puede montarse síncrono o asíncrono (recomendable) a través de una cola implementada en un hilo del agente. La configuración de la PDA como parte del proceso de autentificación puede hacerse:

Accediendo en ese momento a los servicios y/o datos del sistema. A partir de su propia configuración creada en el momento del arranque del agente.

En la primera opción cada PDA funcionará con la última versión de la configuración y en la segunda todas lo harán con la misma versión debiéndose rearrancar el agente para actualizar la configuración. Obviamente cada aplicación deberá escoger que es lo que más le conviene. Una vez configurado, el master asignará a cada PDA de forma fija un hilo que a partir de ese momento será la llave de la PDA para interaccionar con el master y con los servicios del sistema. No hace falta decir que cada slave es un hilo. Sea de una u otra forma, lo primero que hará ese cliente de presentación es pedir al agente su autentificación. Finalmente, está técnica puede utilizarse para rebajar el grado de concurrencia ya que permite reducir el número de peticiones al servicio remoto.

Cliente de Presentación

Agente desupervisión

M

Servidorde trabajo

Resto deServicios

Autentificación

I

I

I

C

D

Trabajo I

I

D

D

D

C

Figura 91. Ejemplo de arquitectura de configuración con una PDA


16. Arquitectura de Representante o Proxy.

La arquitectura de representante o proxy consiste almacenar dentro del servicio los datos necesarios para proveerlo. De esa forma, y siempre que interese, el servidor podrá resolver el mismo la petición evitando acceder a la fuente primaria.

Esos datos, que pueden inicializarse con una arquitectura de configuración, pueden tener o no persistencia.

Hay que estudiar la importancia de que los datos cambien durante la ejecución del servicio

Observe que, según la aplicación donde se use esta arquitectura deberemos disponer de varios mecanismos adicionales:

Una forma de conocer cuando hay cambio de los datos: Por eventos. Por pregunta periódica lanzada por el mismo servidor. Por un proceso periódico con calendario pactado. Aprovechando el servicio remoto. Por ejemplo, arbitrando en la respuesta la información de cambios.

Un almacén para los datos situado en Memoria, dentro del mismo servidor. Básicamente cuando los datos no tienen persistencia autónoma. Esta es la opción recomendada ya que los datos originales ya la tendrán.

Disco, básicamente para dotar al servicio de persistencia. Si se utiliza esta solución, es normal, por temas de eficiencia, que durante el arranque del servicio se cargue en memoria.

Esta arquitectura puede utilizarse, entre otras funciones, para:

16. 1. Mejorar el rendimiento. Imagine que solo algunos de los productos de su compañía tienen problemas de roturas de stock y que esa situación se prevé dentro de un proceso periódico donde se genera la lista de productos con problemas. Durante el periodo entre proceso y proceso esa lista no cambia. Por esa razón, podríamos mejorar el rendimiento de la aplicación si el servidor se configura cuando arranca con la lista de productos con problemas y cuando sea preguntado sólo verifica el stock de esos productos. En la figura de la derecha se muestra un posible diagrama de la arquitectura de un servicio de este tipo.

Cliente que

registra pedidos

Stock

ServidorStock

Servidorproductos

con problemas de stocks

Productos con stock a verificar

C

Y

R

Figura 92. Ejemplo de Arquitectura

de Proxy para mejorar rendimiento

Y


16. 2. Poliformar la fuente del servicio. Imaginemos que disponemos de un sistema de identificación de clientes por tarjeta y que queremos llevar un control de las tarjetas anuladas. La opción habitual será disponer de un servicio situado sobre el nodo de la organización donde se gestione esa funcionalidad y que los programas que necesiten validar las tarjetas accedan a él. Imaginemos que la organización dispone de vendedores móviles con filosofía de nómadas. Cuando los vendedores tengan conexión, el servicio de Proxy accederá al servicio centralizado, pero cuando el vendedor no disponga de conexión, el servicio usará su propia información para validar la tarjeta. Todo de forma transparente a los programas clientes. El diseño deberá prever una forma de actualizar la información del servidor. Podemos usar dos recursos:

Un proceso asíncrono periódico, Actualización dinámica. Por ejemplo, diseñar que cuando el vendedor esté en línea las peticiones de consulta incluyan en su respuesta un indicativo de cambios en la lista. Si el indicativo está activado, el servicio local recogerá y actualizará la lista de tarjetas anuladas desde el servicio central. El indicativo de control de cambios podría ser la fecha de la última actualización de la lista.

16. 3. Incluir consistencia.

El ejemplo anterior nos vale también para mostrar como diseñar análisis de consistencia en servicios sobre clientes no nómadas aprovechando arquitecturas de Proxy. Cuando el cliente no reciba respuesta del servicio central, usará la información local de forma transparente al cliente que no deberá prever ningún tipo de proceso adicional.

17. La estructura del mensaje.

Cuando se hable de la estructura del mensaje estamos hablando de las la especificación de ese mensaje. En un sistema fuertemente ligado el formato del mensaje está prefijado y que cambiarlo para incluir nuevas opciones supone tocar a ambos lados, cliente y servidor. En un sistema ligeramente ligado, la descripción del servicio está en el propio mensaje y por tanto no necesita modificarse la parte cliente si se añaden nuevas prestaciones al servidor. No hace falta explicar, pues, porque este tipo de sistemas se están estandarizadazo bajo XML. La propuesta de “sistemas débilmente ligados”, contrapuesta a un “sistema fuertemente ligado”, de Microsoft para servicios de Internet es una arquitectura de distribución, donde un servidor de mensajes recoge las peticiones de servicios en XML, las analiza y las pasa al componente especializado en dar el servicio pedido.


18. Arquitectura completa del ejemplo del capitulo anterior. Se incluyen a continuación la arquitectura de datos completa del ejemplo final del capítulo dedicado a la comunicación.

Usuario

Petición cliente


Cuenta Cliente

RegistroDatos

Cliente


RegistroDatosViaje

PeticiónDatos

Cliente

DatosCabeceraCliente RPC

Actualizadatos

c.aérea

ObtenerDatos

Cliente

ProcesoCompañía

Aérea


R

Cliente Cuenta Cliente

ConsultaDatosVuelos

D

D

D

Figura 93. Arquitectura de servidores completa

Gestor de la WEB

ConsultaDatos

d.aérea


ObtenerDatos

Cliente

Presentación de la WEBIdentificación

ClienteConsultaVuelos

RegistroVuelos


RegistroVenta

Cliente Cuenta ClienteRPC

ProcesoCompañía

Aérea

R

Cuenta Cliente


D

D

R

D

D

Figura 94. Arquitectura de las funciones de venta directa completo

Una posible alternativa sería convertir el proceso de cuenta de cliente en una Agente y establecer una arquitectura de traspaso de responsabilidad en ese punto.

@EMG/05 - Enric Martínez Gomáriz 133

Arquitectura Orientada a Servicios - SOA

1. Los servicios como base del diseño distribuido. A lo largo de toda la primera parte hemos concluido tema tras tema que toda visión de cada uno de esos elementos de un sistema distribuido se reduce a una idea simple: disponer de todos los recursos del sistema, datos, procesos, dispositivos y aplicaciones heredadas, desde la perspectiva de un servicio. Diseñar el sistema distribuido no será nada más, ni nada menos, que construir los servicios, integrarlos en una arquitectura y utilizarlos. Pero para que esto sea posible será necesaria rigurosidad en el diseño de esos servicios. Con la aparición de los Servicios WEB, este enfoque se ha popularizado y se ha plasmado en un estilo de diseñar aplicaciones conocido como Arquitectura Orientada a Servicios, SOA (Service Oriented Architecture). Como sus mismos ponentes establecen, esta arquitectura va más allá de los Servicios WEB que se convierten únicamente en una forma de proveer servicios. Vamos a dedicar este capítulo a presentar las bases de esta arquitectura SOA basada en servicios que es, a mi juicio, el enfoque válido para atacar un diseño distribuido. Vaya de entrada la idea de que SOA es anterior a SOA. Es decir, el diseño por servicios es anterior a que esta palabra se popularizara y esta basado en algo tan antiguo como la informática: disponer de funciones encapsuladas que pueden usarse con fiabilidad sin conocer su implementación y con independencia de la plataforma donde están localizadas. Una vez más los informáticos hemos vuelto a poner nombre a algo que ya existía. Sin embargo hay un aspecto nuevo.

El hecho diferenciador es la idea, no estrictamente informática, de que los servicios se publican, “se venden” y se usan sin que proveedor y consumidor se conozcan. Y es más que probable que cada vez más el software se venda y se consuma como servicio y que se necesario diseñarlo todo bajo esta perspectiva.

2. Concepto de servicio. Conviene en primer lugar recordar que entendemos por un servicio.

Un servicio permite organizar y agrupar funciones de una forma que modela la realidad y que nos es familiar.

Se diferencia de forma radical la especificación y el uso a través de la implementación del servidor del servicio.


El servicio combina datos y comportamiento a través de funcionalidad. Es obligado, sin embargo, encapsular al máximo y por esa razón, todos los atributos deberían ser privados y accesibles solo a través de métodos.

Así, un servicio es un componente capaz de realizar una función o tarea a través de un interfase, un vehiculo a través del cual la necesidad del consumidor es satisfecha por un proveedor de acuerdo con un contrato negociado de forma genérica o particular. El servidor será el componente que proporcionará el servicio. Normalmente la comunicación se realiza intercambiando mensajes en una estrategia cliente/servidor conocida también como petición/respuesta. Todos servicio tiene dos visiones muy diferenciadas:

Diseño: Establece qué proporciona el servicio y la calidad de la funcionalidad que aporta valorada por el grado de adaptación a nuestros procesos de negocio.

Nivel de reusabilidad y adaptabilidad funcional. Adaptabilidad a la evolución, tanto técnica como funcional. Facilidad de gestión.

Publicación y localización Contrato de servicio. Eficiencia de la localización cuando se utilice.

Implementación tecnológica. Independencia de la plataforma. Independencia cuando se use del lenguaje y/o herramienta en que este desarrollado.

Nivel de adaptación a estándares. Bajo este enfoque, la ejecución de la implementación pude pedirse en cualquier momento y siempre que el pacto de servicio se respecte, varias implementaciones pueden dar el mismo servicio y cada uno de los componentes servidores puede cambiarse o actualizarse tantas veces como sea necesario. Las etapas del ciclo de vida de un servicio se engloban en cuatro fases:

1. Análisis orientado a servicios de las aplicaciones (nuestra idea desde el principio) que permita la identificación de los servicios necesarios para conseguir la funcionalidad buscada.

2. Diseño del servicio es decir, el desarrollo del componente que va a hacer de servidor.

3. La administración y gestión (management) del servicio incluyendo el housing o localización.

4. La compra o subcontratación del servicio según la visión del usuario si no es el propio constructor

3. Principios del diseño de servicio. Los principios de diseño de los servicios son los mismos que los de componentes reutilizables. Conviene, sin embargo, precisar algunos conceptos muy ligados a la arquitectura SOA. 3. 1. Abstracción.


Hace referencia a que el uso del servicio es independiente de la implementación y la localización. El servicio esta obligado al 100% en este tema por lo que la encapsulación debe ser total.

3. 2. Generalización. Este principio hace referencia al hecho que el servicio debe poder usarse en un número muy amplio de escenarios, incluso escenarios desconocidos en el momento de su diseño, evitando así la necesidad de adaptar el servicio a cada necesidad. Eso hará los sistemas ágiles en su adaptación al cambiante mundo de las necesidades de los negocios.

3. 3. Seguimiento de estándares. Eso permitirá adaptabilidad técnica y seguimiento evolutivo.

3. 4. Granularidad. Habrá que elegir entre escasa o gruesa (coarse en la nomenclatura de Servicios WEB) o fina (fine).

3.4.1. Ventajas de la granularidad Coarse Graneid.

Todos los datos se gestionan en pocas llamadas. Es adecuado para:

Datos complejos, por ejemplo resultantes de un Upsizing. Gestión de errores compleja e interdependiente. Mensajes de gran tamaño.

Facilidad de manejo. Encapsulación de reglas de negocio o de proceso complejas.

3.4.2. Ventajas de la granularidad Fine Graneid.

Pequeños mensajes que permiten gestionar datos simples. Proporcionan

Mayor control. Mayor facilidad de recuperación.

Posibilidad de arquitectura entre los servicios. En tiempo de ejecución permite afinar mejor lo que se pide en función del estado del proceso.

Como se ve las ventajas de uno y otro enfoque son opuestas y que es mejor es en el fondo la eterna respuesta: depende del proceso y de la aplicación. A modo de ejemplo, y con todas las excepciones que se quiera, en general:

Los objetos y procesos de negocio necesitan poca granularidad porque han de ser abstractos, complejos y encapsulados.

Los servicios de datos tienden a ser finos. Los Servicio WEB al exterior pueden servirse con diferentes niveles de granularidad para atender a diferentes requerimientos. Observe que ese enfoque necesita que los servicios internos sean finos.

Los servicios publicados de aplicaciones heredadas suelen ser de granularidad fina. Los servidores deberán verificar las interdependencias y los condicionamientos de la aplicación heredada para cada servicio suministrado al exterior.


Sin embargo, un buen criterio es trabajar con una granularidad muy fina internamente y montar los servicios al exterior con mayor agrupación utilizando los internos mediante modelos de arquitectura de servicios que veremos enseguida. Conseguiremos así mayor agilidad y adaptabilidad.

4. Puntos de articulación. La posibilidad de disponer de diferentes implementaciones o proveedores de un mismo servicio introduce el concepto de puntos de articulación donde deben contestarse preguntas del tipo:

¿Cual de los servicios debe usar la aplicación cliente? ¿Qué proveedor debe suministrarlo? ¿Qué implementación debe usarse?

Estas preguntas deben contestarse en puntos de articulación que son gestionados fuera de la aplicación cliente que siempre lanza la petición contra el mismo sitio. La solución será trabajar con arquitecturas de redirección.

5. Principios de SOA. World Wide Web Consortium (W3C) se refiere a SOA como “un conjunto de componentes que pueden ser invocados y cuya especificación, descripción y interfase, pueden ser publicadas y descubiertas”. CBDI Service Oriented Architecture Practice Portal va más allá. Considera SOA como toda una forma de trabajo: “políticas, prácticas y Frameworks que permiten que la funcionalidad de una aplicación pueda ser proporcionada, total o parcialmente, y consumida como un conjunto de servicios públicos y que el consumidor utiliza con la granularidad que necesita”. “Los servicios pueden ser publicados, descubiertos e invocados con total transparencia de la implementación y localización. El ciclo de vida de los servicios debe de basarse en estándares”. SOA es el estilo de trabajo resultante de todo ello. Observe ya de entrada que en esta definición no se habla para nada de Internet. Los Servicios WEB son una forma más de obtener los servicios de una forma muy estándar y general. Pero nada impide disponer de servicios a través de sistema operativo, sobre todo si parte o todo el sistema de información es interno a la compañía que lo usa, hay aplicaciones heredadas o hay un acuerdo entre las partes que colaboran. Lo que si es importante es mantener perfectamente diferenciada la perspectiva del proveedor y del consumidor. Antes de seguir permítame aclarar un concepto. A mi juicio el concepto de proveedor que se utiliza en el mundo SOA es incompleto. Deberíamos diferenciar el fabricante, el diseñador y programador del servicio, del suministrador u organización que suministra el servicio cuando la aplicación lo usa en el día a día. Obviamente, fabricante y suministrador puede ser personas o corporaciones


diferentes. Utilizaré el término proveedor cuando quiera referirme indistintamente a ambos y cada uno de los términos cuando quiera diferenciarlos. Cada rol aporta visiones diferentes a SOA. El consumidor solo necesita saber como es el servicio que el fabricante le suministra y donde esta el suministrador que se lo dará. El fabricante debe aportar la especificación, el contrato funcional y el componente servidor. El suministrador debe responsabilizarse del contrato de servicio. Un factor importante es administrativo: el repositorio de servicios, donde los actores implicados pueden disponer publicar los servicios que ofrecen, localizar los que necesita o suscribirse. Un repositorio estandarizado es UDDI por lo que, si no lo recuerda, repase ese tema en el capítulo de la primera parte dedicado a Servicios WEB. Observe, sin embargo, que un grupo de proveedores y/o consumidores podrían montar sus propios directorios, ya sean internos a sus organizaciones o sectoriales. En la figura se muestra la interacción entre repositorio, consumidor y proveedor, no se ha diferenciado entre fabricante y suministrador. Observe que, obviamente, un proveedor puede ser consumidor de otro proveedor.

6. Arquitectura de SOA.

Dentro de SOA se suele hablar de tres arquitecturas: 6. 1. Arquitectura de

Aplicación. Es la parte de la lógica de negocio. Es allí donde se consumen los servicios. Yo incluiría un matiz. Puede ser que un servicio se use dentro de otro, oculto al cliente, en alguna de las arquitecturas que hemos presentado de forma transparente al consumidor.

6. 2. Arquitectura de Servicios. Proporciona el puente entre las aplicaciones que consumen los servicios y los componentes que los implementan. Crea una visión lógica del servicio. Puede asimilarse a un bus lógico donde se conectar servidores y consumidores con unas reglas de juego pactadas a través de estándares. Cada sector de negocio o de actividad puede pactar las reglas de un bus a partir de las herramientas estándar. Una plataforma de servicios SOA debe pactar e incluir:

Proveedor A

ServiciosA B C

D E

Proveedor B

ServiciosB F C

G H I

Consumidor 1

Consumidor 2

Consumidor 3

Consumidor 4

Repositorio de servicios

Localización y

suscripción

Publicación

Uso

Figura 95. Interacciones en un modelo SOA


Entornos de housing y consumo y conectividad entre ellos. Middleware para diseñar y administrar. Entornos de desarrollo y de administración. Recursos de publicación, descubrimiento y suscripción. Protocolos estándares del estilo de Servicios WEB. Infraestructura de seguridad y autentificación. Monitoring. Detección y seguimiento de fallos. Certificación. Control de versiones. Gestor de eventos. Posibilidad de Workflow. Desindeterminación, es decir la automatización de información no crítica que facilite la gestión de los usuarios. Por ejemplo, recoger las fechas automáticamente, implementar las condiciones habituales por defecto, identificación de los actores, etc.…

6. 3. Arquitectura de Componentes. Describe los diferentes entornos que soportan las aplicaciones implementadas. Se incluyen aquí los entornos donde se instancian los servicios y que han de ser transparentes, me atrevo a añadir, desconocidos, para el consumidor.

Déjeme opinar. Esta clasificación no aporta nada nuevo que sea de demasiado interés para diseñadores.

7. Ventajas de SOA. Ahora debería hablar aquí de las inmensas y maravillosas ventajas de estandarización, adaptabilidad, generalización, transparencia, robustez y tantas otras cosas positivas de SOA. Supongo que estamos de acuerdo que si lo hiciera estaría repitiendo todo lo que he repetido a lo largo de lo que llevamos viajando juntos. Obviamente, no voy a repetirme. En particular se insiste mucho al hablar en SOA de adaptabilidad, en especial a los cambios en el mundo de los negocios, y en la posibilidad de disponer de datos en línea casi en el mismo momento en que se generan lo que permite una mejor toma de decisiones. Estamos todos de acuerdo en este punto ¿verdad? Lo que si es muy interesante es utilizar esta filosofía basada en servicios para conectar sistemas y aplicaciones heterogéneas ya que se basan en estándares que se encuentran en la inmensa mayoría de entornos.

8. Los Servicios WEB dentro de SOA. Ya hemos dicho en diferentes ocasiones que Servicios WEB son una forma muy interesante de conseguir servicios a través de un estándar y una plataforma, Internet, de extensión universal. Con ellos se ha creado una arquitectura de servicios aceptada como un estándar por todos.


Repase, si no recuerda, el capítulo dedicado en la primera parte a este tema.

9. Uso de XML en SOA. Aunque no sea un prerrequisito, siempre que pueda, utilice como soporte del intercambio este protocolo.

10. La conclusión final.

SOA es un estilo de trabajo que obliga a pensarlo todo como servicios y a crear la aplicación como una integración de servicios. Los servicios los proporcionan los servicios linkados, servidores, servicios pasivos, y los agentes, servicios activos, que se implementan como componentes en un mundo de competencia donde coexisten diferentes proveedores. El mundo SOA “oficial” está pensando en nuestros servicios pasivos. SOA es el armazón donde la funcionalidad se integra a través de servicios que colaboran con la aplicación de usuario y entre ellos. Diferentes áreas de negocios pueden pactar marcos de ese armazón. Ha sido muy interesante hablar de SOA. Pero poca cosa nueva nos ha aportado ya que estamos hablando de servicios desde el principio de nuestro viaje. Sin embargo, el uso de esa terminología, hoy universalmente conocida, es muy útil para formalizar la idea que hemos estado proponiendo desde el primer momento para enfocar el diseño de aplicaciones distribuidas basándolo todo en servicios.


Diseñando Servicios

1. Introducción. Hemos hablado repetidas veces del concepto de servicio e introducido la arquitectura SOA en que se integran. Hemos visto que los servicios son componentes de software que habrá que diseñar y programar. En este punto hay poco más a decir, mandan los conceptos técnicos de programación de piezas de software. Pero el concepto de servicio crea un nivel de abstracción por encima del componente que conviene analizar. No se trata tanto de presentar todos los desafíos que el diseño de servicios crea sino de introducir los criterios técnicos básicos a tener en cuenta. En el resto de este libro saldrán otros criterios que bien podrían estar en este capítulo pero que presentaremos en su momento dentro de su entorno natural de aparición Además, muchos de estos aportan buenos ejemplos de las arquitecturas de servicios que hemos presentado.

2. Especificación del servicio.

Recordemos que la especificación del servicio determina que funcionalidad da, con que granularidad, cual es su interfase y que estándares sigue. Es el primer y critico paso en al construcción de un servicio. Una vez determinada la necesidad de un servicio en una aplicación y la voluntad de un proveedor de ofrecerlo a potenciales consumidores, debe intentarse que el servicio sea lo más general posible dentro de un coste razonable. Se siguen tres pasos: 2. 1. Racionalización del servicio.

Supone un profundo análisis de las necesidades de los consumidores ya localizados y de los potenciales. Si el servicio no es estrictamente técnico, hay que consultar tanto a los consumidores detectados como a expertos sectoriales si el servicio lo requiere.

2. 2. Consolidación del servicio. Se escogen las funcionalidades que se desean ofrecer y se define la granularidad interna y externa. Debe incluirse aquí la decisión de la arquitectura de servicios necesaria para conseguir las granularidades gruesas a partir de las finas. A partir de aquí se decide en que catálogo o catálogos se publica.


2. 3. Agrupación por dominios o temas. Los servicios se agrupan por afinidades. Dentro de cada afinidad puede haber arquitecturas de precondición que se deberán resolver. Pueden ser criterios de afinidad:

Afinidad de negocio. Verificación de la accesibilidad. Aplicaciones heredadas. Bases de datos compartidas. Proximidad. Entornos de sistema operativo

Es un criterio difícil de atacar de forma sistemática.

3. Arquitectura entre los servicios.

Tanto entre los nuevos como con los ya existentes reutilizados. Habrá que decidir que modelo de utiliza y tener en cuenta las consecuencias que ya hemos visto que cada modelo tiene en el diseño. SOA plantea varios tipos de servicios:

Petición / respuesta: obtiene información, realiza cálculos y genera un resultado.

Trabajador: provoca un cambio de estado en lo que trabaja. Monitor: notifica cuando se produce un cambio notable en un estado. Agente: variante del monitor que actúa en lugar de notificar. Intermediario: intercepta una petición de servicio de forma transparente, la transforma y la envía al destino original.

Agregador: combina los resultados de diversos servicios o fuentes de datos. Proceso: agregador de larga duración, normalmente un proceso de negocio.

4. Adaptación a la arquitectura de datos distribuida.

Los servicios actúan sobre datos. Idealmente, el lugar ideal para situar los servidores es el mismo entorno donde están esos datos. Es muy frecuente que esto no pueda ser así por algunas de las múltiples razones por las que la arquitectura de datos pueden estar repartida por la plataforma distribuida: partición horizontal o vertical, consolidación de datos heterogéneos, upsizing, federación, puntos de responsabilidad en las decisiones de negocio, etc. En esta situación la sincronización y coherencia es una responsabilidad del servicio. Esto, como ya hemos visto y ampliaremos más adelante, puede ser un problema complejo. El diseño del servicio deberá adaptarse a esa obligación utilizando cualquiera de las técnicas que hemos visto y veremos. Veamos un ejemplo con una partición horizontal.


Imaginemos una organización donde la gestión de personal es responsabilidad de cada centro de trabajo y donde la aplicación heredada de personal no permite consolidar datos en tiempo real. En esa situación, los datos de los empleados estarán localizados en cada centro. Si desde la central u otro centro se necesita acceder a los datos de un empleado, habrá que ir lo a buscar a su centro de trabajo. En la figura se muestra una posible solución a la arquitectura de este servicio. El servidor de personal deberá determinar por una regla de negocio o un índice donde acceder para localizar los datos del empleado que se le ha solicitado. Se ha escogido una solución por redirección pero otra solución válida podría ser la de pasarela. Otra solución, a mi juicio menos aconsejable, es mantener un modelo de replicación con foco de mantenimiento distribuido en el cual los datos de todos los empleados están en todos los centros aunque mantengan en el centro que corresponda. De las posibilidades en esta línea hablaremos ampliamente en el capítulo dedicado a replicación.

5. Servicios para hacer publicas funcionalidades ya existentes (packaging).

Creados para aprovechar funcionalidad ya existente normalmente hasta ese momento internas a las respectivas aplicaciones. El diseño se ataca por pasos:

Agrupación por áreas de negocio y funcionalidades que se quieren dejar disponibles.

Localización de la funcionalidad en las aplicaciones heredadas. Empaquetamiento y especificación de los servicios que se van proporcionar fuera.

Clientes centro 1

Servidoren centro 1

Clientes centro n

Servidoren centro n

Consumidor

A

Servidorde personal

A

D

Figura 96. Arquitectura de un servicio con partición horizontal


Por ejemplo, imagine que tiene una aplicación de gestión administrativa y otra de facturación. Y desea montar un servicio que a partir de un albarán calcule la factura, realice la anotación contable y la impute a la cuenta del cliente para gestionar el riesgo. Para implementar el servicio, puede definir un servidor que, atacado por los clientes potenciales delegue cada función a la respectiva aplicación. La forma en que cada servicio especializado actúa depende de la aplicación existente. En el ejemplo se ha supuesto que:

Existe una rutina que calcula a partir del albarán la factura y los documentos de cobro o recibos. Esta rutina se ha linkado como un servicio pasivo con el servidor para el cálculo de la factura.

La contabilidad tiene un agente que explora las anotaciones de una cola y apunta los asientos en los archivos contables.

La imputación de los recibos se hace al final de día por lo que es necesaria una arquitectura de traspaso de responsabilidad.

Observe que la consistencia del servicio obligará a controlar que cada proceso acaba bien y, en caso contrario, decir que se hace, echar hacia atrás toda la operación o dejar pendiente de actualizar lo que no se haya podido hacer.

6. Service routing. Este aspecto hace referencia a como la petición del consumidor se dirige al servidor de forma absolutamente transparente. Pueden utilizarse varias técnicas. 6. 1. Utilizar los recursos estándares del Middleware.

Prime esta opción siempre que pueda. Un consejo, intente poder siempre.

6. 2. Localización en el propio servicio. El mismo servicio lleva información de donde esta localizado. Interesante cuando no se conoce a los potenciales consumidores.

Consumidor

Imputaciónalbarán

D

DImputación

de lafactura

Contabilidad

F

Cálculode la

facturaFacturación

D

Imputacióndel

Recibo

Gestión deCobroT

D

Figura 97. Servicio de facturación.


6. 3. Routers. Existe un servicio que se responsabiliza de esa función. Actúa con arquitectura de configuración. Tiene tres niveles posibles:

6.3.1. Servicio de router. Dentro de cada dominio conecta al consumidor con el servidor.

6.3.2. Servidor de router de dominio.

El servidor tiene información de los servicios que están en su entorno. Recibe la petición y si el servicio no es de su dominio devuelve un código de error lógico.

6.3.3. Servidor de localización. Es el nivel que ataca el potencial consumidor. Ataca a cada uno de los servidores de dominio que tiene catalogados. La arquitectura entre el servidor de router y el de dominio puede ser de delegación o de master slave para realizar todas las peticiones simultáneamente. Este nivel puede estar asumido por el consumidor o también es posible que un router le pase la petición a otro por una arquitectura de redirección.

El servicio JNDI de la arquitectura J2EE es un ejemplo aplicado de Router.

ConsumidorServidor

delocalización

C

Servidorde

dominio 2

D

Servidorde

dominio 1

D

Sistema 1

Sistema 2

Serviciode router

Serviciode router

Consumidor

Servidorde

dominio 2

AC

Servidorde

dominio 1

Sistema 1

Sistema 2C

Serviciode router

Serviciode router

Figura 98. Servicio de Router


Arquitectura Conducida por Eventos (EDA) y Arquitectura en Tiempo Real.

1. Introducción. Una arquitectura SOA es por concepto pasivo, es decir, ofrece unos servicios que los diseños aprovechan. Pero durante el día a día de la gestión ocurren cosas y la realidad evoluciona constantemente y hay que responder a los cambios, incidencias, nuevas oportunidades de negocio, amenazas, etc. Y en ámbitos tan variados como evolución de mercados, redes de ventas, cadenas de suministro, procesos internos, etc. Hace falta un recurso para reaccionar de forma automática a esa evolución. Esta posibilidad la proporciona la Arquitectura Conducida por Eventos, EDA, del nombre en inglés, Events-Driven Architecture.

2. Arquitectura EDA. Cada unos de esos cambios e incidencias de los que hemos hablado en el apartado anterior aparecen como un evento. Por ejemplo, pueden asimilarse a eventos:

La competencia ha sacado un nuevo producto. La previsión de ventas en una delegación no se está cumpliendo. Un pedido critico se esta retrasando. Un grupo de matriculación se esta completando. Un buen cliente hace tiempo que no compra. Un empleado se retrasa constantemente. Un camión de reparto ha sufrido una avería o va retrasado. Ha subido el precio de una materia prima importante. Un departamento está gastando más de lo previsto. Etc.

Observe que las apariciones de esta lista pueden tipificarse en:

Cambios en los negocios. Incidencias.

De negocio. De explotación

Y en:

Habituales (vigilar la evolución de las ventas). Imprevistas (se ha estropeado un camión).


EDA es un paradigma de arquitectura basado en utilizar los eventos como desencadenantes de procesos que reaccionan al evento para poder tomar las medidas y decisiones apropiadas para asimilar el cambio o responder a las incidencias. Note que la reacción inmediata puede decidir un proceso demorado en el tiempo. La respuesta puede concretarse en:

Un mensaje para las personas u organizaciones interesadas. Arrancar un proceso, en la mayoría de los casos distribuido.

Ambas reacciones han de poder transmitirse a una pluralidad de sistemas y/o personas. La combinación de SOA y EDA permite construir lo que algunos autores denominan Arquitecturas en Tiempo Real que permiten a las organizaciones responder en tiempo real a cambios e incidencias.

3. Metodología para establecer una Arquitectura EDA. Obviamente, una arquitectura EDA es normalmente una parte del sistema distribuido, no necesariamente TODO el sistema distribuido. Para llegar a construir esa parte del sistema distribuido deberán seguirse los siguientes pasos:

1. En la etapa de especificación: 1.1. Identificar los cambios e incidencias y asignarles un evento. 1.2. Decidir que reacción necesitan: mensaje y/o proceso. 1.3. Especificar la reacción

2. Diseñar la reacción. 3. Implementar la reacción. Debe entenderse como

Estas etapas suponen que una vez especificada la arquitectura EDA en la primera etapa, el resultado queda integrado como una funcionalidad más a resolver en el diseño tecnológico distribuido y que por tanto los tres pasos previos deberían hacerse como parte del análisis funcional o especificación del sistema.

4. Recursos tecnológicos. La mayoría ya se ha presentado o se presentaran en los próximos capítulos:

Los mecanismos ECA permiten filtran les reacciones. El vigía puede escuchar los eventos. El cartero puede ser un buen sistema de distribución de mensajes. El disparador puede lanzar procesos de reacción automáticamente. Los agentes pueden escuchar eventos “habituales”. Las técnicas de publicación suscripción pueden ser de mucho interés para gestionar mensajes.


En fin, añada aquí todo lo que ha visto y verá en nuestro viaje y que puede ser interesante para implementar una arquitectura EDA.

@EMG/07 - Enric Martínez Gomàriz 148

Integración de Clientes y Servidores en el Middleware.

1. Introducción y final. Recuerde los capítulos de la primera parte dedicados a este tema. Dentro de lo posible, catalogue y use sus clientes y servidores con los recursos de su Middleware.


Ingeniería de Software y Proyectos Cliente/Servidor.

1. Introducción. Este no es un libro de Ingeniería de Software (IS).

Sin embargo, todo desarrollador de software es un Ingeniero.

Este hecho, que para los lectores que tengan una formación Informática reglada de nivel superior o medio es una obviedad, para lectores que provengan es otras líneas de formación informática o sean autodidactas puede no estar tan claro. Sin embargo, soy un convencido de que si usted quiere realizar buenas aplicaciones distribuidas no puede prescindir de unos conocimientos mínimos de Ingeniería de Software. He dudado en incluir este capítulo en este libro. La decisión que he tomado es evidente: Vd. esta leyendo la introducción a este capítulo. Creo que para los lectores que ya conocen estos conceptos, las matizaciones de los conceptos fundamentales con el barniz distribuido puede ser un aliciente para leerlo. Aunque si lo desean sáltenselo. Para aquellos que no los poseen, leerlos aquí puede resultar motivador para profundizar consultando documentación específica. Además les ayudará a seguir con mayor fluidez los capítulos de análisis y diseño que se avecinan.

2. Características de las actividades de IS. El desarrollo de software es Ingeniería ya que participan de todas las actividades que definen en trabajo de un Ingeniero. 2. 1. Disponibilidad de Modelos, Métodos y Herramientas.

El desarrollador dispone de modelos, métodos y herramientas para hacer su trabajo. Delante de un problema, lo analiza, reconoce un modelo,

aplica un método para ese modelo y utiliza herramientas ya creadas. Cuando en el problema hay partes para las que no dispone de modelos, los crea, establece un método y, si es necesario, diseña la herramienta. El nuevo modelo y/o método y/o herramienta queda disponible para resolver nuevos problemas.

2. 2. Utiliza un proceso de fabricación.


Para la creación del producto final el desarrollador de software utiliza (o desgraciadamente en muchos casos debería utilizar) un proceso de fabricación: hay una etapa de análisis; para cubrirla hay unos datos a

recoger, unas actividades a cumplimentar, una metodología y unas herramientas a utilizar, unos plazos a estimar y cumplir, etc.

2. 3. Controla la Calidad.

Se debería medir la calidad del producto resultante, nuestra gran asignatura pendiente. Sin embargo se pueden hacer muchas cosas a un coste razonable. Más delante se introducirán algunos conceptos de Control de Calidad del Software.

2. 4. Mejora continua del proceso. El proceso de producción ha de ser medido y evaluado para mejorarlo y conseguir cada vez un producto mejor.

2. 5. Ratio Calidad / coste.

El desarrollador debe conseguir el mejor producto al menor precio; es decir el ratio Calidad / coste más alto posible.

Los Informáticos somos los reyes de intentar “coger todos los casos posibles”. Esto es una utopía absoluta y además un coste innecesario en la mayoría de proyectos. Hay que analizar los casos probables y aplicar las soluciones más rentables. No olvide que ahorrar una hora por día de gestión de usuario o de tiempo de proceso es bajar costes, adelantar un plazo de facturación puede suponer ahorrar costes de tesorería, etc. Y muchísimos ejemplos más. Vamos, el concepto de componentes y reutilización que ya hemos trabajado. Muchas veces no analizar este ratio supone una delación de funciones por parte de desarrollador, por desconocimiento o poca profesionalidad, que puede tener graves consecuencias económicas para la empresa. Si usted es Informático de una empresa con tiendas de venta, no olvide que cobra cada mes porque las tiendas venden. Su función no será crear un sistema de información prefecto, sino uno que permita a sus tiendas vender mejor y a un menor coste.

Si el lector compara estas actividades con las de un Ingeniero Químico en una fabrica se dará cuenta que básicamente no hay ninguna diferencia con las de un Ingeniero de Software.

3. Ingeniería de los Proyectos de Software. Las características generales de los proyectos de ingeniería son:

Diseño mediante modelos, metodología y técnicas sistemáticas. Planificación y seguimiento de la fabricación.


Utilización de materia prima, el proyecto aporta “valor añadido”. Certificación de la calidad. Necesidad de fabricar el mejor proyecto al menor coste.

Es evidente que los proyectos de software participan de todas estas características. Y evidentemente, los proyectos de software distribuidos también. Dentro de estas características generales de los proyectos de ingeniería, los proyectos de software tienen otras características específicas:

El software se desarrolla lo que hace que el factor humano sea fundamental.

La materia prima son los componentes prefabricados (funciones de los lenguajes, servicios de los sistemas, bibliotecas de rutinas, etc.).

El software no se deteriora con el paso del tiempo: los errores que salen con el transcurso del tiempo son siempre de la etapa de desarrollo. Si se detectaran y corrigieran en ese momento, no habría ningún tipo de problema (fuera de las averías de maquina) después.

A pesar de que el software se desarrolla para cubrir unas funciones determinadas, la utilización de componentes prefabricados, reusabilidad, es fundamental, como ya se ha visto anteriormente, para obtener costes y calidades razonables.

No es nada fácil medir más allá del tiempo real invertido, lo que conlleva que no hay ninguna costumbre de hacerlo. Y sin mediciones no hay ni métricas ni estimaciones de procesos de seguimiento y mejora de la calidad. Recuerde que el tema de medir es especialmente complicado en distribuido.

La calidad del software es muy difícil de evaluar de forma absoluta. Y un factor, el coste de mantenimiento, es desconocido en la fase de desarrollo inicial. Y al final resulta crítico en coste total.

En cuanto a software y costes, hoy día el factor fundamental no es el hardware sino el software, sin olvidar el coste de las licencias si Vd. tiene muchos usuarios. Los factores determinantes del coste del software son:

La formación y motivación del personal humano. La fiabilidad de la especificación y del análisis funcional. En general no muy alto.

El grado de reutilización. Es evidente que utilizar piezas y componentes rebaja espectacularmente los costes y los problemas (coste indirecto).

El grado de fiabilidad del software reutilizado. Las soluciones modulares permiten evolución y adaptabilidad a menor coste.

El coste del reciclaje del personal a evolución continúa de la tecnología. La conclusión es, de cualquier forma, evidente: la fabricación del software de ha de entender como una disciplina de ingeniería ya que engloba los cuatro factores principales:

Proyectos de Ingeniería

Proyectosde Software

ProyectosDistribuidos

Figura 99. Los proyectos

distribuidos como proyectos de

Ingeniería


Los modelos permiten identificar problemas y soluciones. Los métodos dan las técnicas de fabricación. Las herramientas suministran el soporte a los métodos. Los procedimientos unen métodos y herramientas y permiten desarrollar en el tiempo y la calidad deseados.

4. Gestión de un proyecto de software. 4. 1. Concepto de proyecto.

Proyecto es el conjunto de tareas necesarias para alcanzar un objetivo general al coste mínimo (tiempo y dinero) y calidad máxima. En detalle:

El objetivo general del proyecto es la suma de los objetivos de las etapas en las que se divide el proyecto.

Para alcanzar los objetivos es necesario hacer unas tareas y que estas se ejecuten en un orden determinado.

Hay que utilizar unos componentes ya construidos (materia prima). Se dispone de recursos humanos y técnicos que hay que gestionar. Hay un responsable, el Director del Proyecto.

4. 2. Dirección de un proyecto de Software.

La dirección de un proyecto es la suma de tres actividades:

4.2.1. Especificación.

4.2.1.A. Técnica. Definición de los objetivos.

4.2.1.B. Planificación

Definición de las tareas. Asignar un tiempo y unos recursos a cada tarea. Identificar los trabajos críticos. Crear una planificación de recursos (compras e incorporaciones) y tiempos (agenda).

4.2.2. Seguimiento.

Agenda Compras e incorporaciones. Revisión

4.2.3. Certificación de la calidad.

En todo el proceso tienen una importancia básica las métricas. Es imposible una buena estimación de la carga sin una metodología basada en métricas. Y para unas buenas métricas es fundamental la medición histórica y el análisis de los errores para identificar y eliminar sus causas

4. 3. Gestión.


La gestión del proyecto de software es el primer nivel de la IS. La gestión ha de cubrir todo el proceso, desde el principio al final del “ciclo productivo”.

Las fases de la fabricación a controlar es un tema en el que todos estamos de acuerdo, pero que llamamos de formas diferentes. Y establecemos entre las fases en sitios diferentes. En la figura le muestro una posible nomenclatura para esas etapas, pero no es mi objetivo en este libro entrar en ese tema. La

idea que la figura intenta transmitir es que la gestión debe incluir todo el proceso, desde la especificación, al arranque y el mantenimiento. Y que, en todo momento, la gestión debería controlarse con mediciones y métricas. He subrayado también las etapas, que como vimos en la primera parte, están más influidas por el hecho de ser el sistema distribuido. La distribución de los cambios generados por el mantenimiento es una actividad más de la administración del sistema que, como vimos, está condicionada también por el hecho de ser el sistema distribuido. Conviene resaltar que la gestión del proceso tiene dos aspectos, técnico y administrativo.

El aspecto técnico incluye los métodos, tecnologías y herramientas para construir.

El aspecto administrativo comprende la planificación y el seguimiento. Remarcar que, independientemente de las fases técnicas en un proyecto de software hay siempre (o debería haber) un pre-estudio, un estudio de viabilidad, una planificación, una ejecución y una conclusión.

5. Gestión técnica del proyecto.

Es la destinada a definir la funcionalidad del proyecto y definir la solución técnica para conseguirla. Es la fundamental en IS.

Gestión del ProyectoAnálisis Funcional /

EspecificaciónDiseño Tecnológico

CodificaciónPrueba

IntegraciónArranque

Mantenimiento

Mediciones+

Métricas

Figura 100. Fases de la gestión del Proyecto

Pre-estudio

Estudio deviabilidad

Planificación

Conclusión

Ejecución=

Seguimiento +

Control+

Revisiones

Dos aspectos:TécnicoAdministrativo

Aspectos de la gestión del Proyecto


No hace falta insistir en la necesidad de disponer de una metodología funcional. Y recordar que el diseño de la arquitectura distribuida, etapa tecnológica, comienza sólo cuando se dispone del funcional. La metodología de diseño distribuido que propondré servirá para cualquier mitología funcional. Pero, ¡ha de usar una! Si no la tiene, puede usar como mínimo la de RDA que le presentaré más adelante y que usaremos en los ejemplos. Utilizaremos dos elementos presentes en todas las metodologías:

Una descripción del modelo de datos. Una descripción de los procesos de transformación y el orden en que los procesos los ejecutan.

Adelantemos que, en la metodología que propondremos en RDA, la propuesta para especificar los datos será la realización de un esquema relacional o un modelo de objetos y que para dar los procesos se utilizarán diagramas de flujo modificados. Utilice lo que utilice, recuerde que la etapa de análisis ha de explicar que hay que hacer, no como se hace. IS se compone de una serie de pasos que se han de seguir y cumplir utilizando los métodos, las herramientas y los procedimientos. Estos pasos de conocen como paradigmas de IS. La elección del paradigma se hace en función del proyecto y de la aplicación, los métodos y las herramientas que se han de utilizar y de los controles y entregas que se han de hacer.

6. Paradigmas de la Ingeniería de Software.

No es mi objetivo hablar de este tema. Si quiero hacer mención a los más habituales para poder hacer un comentario final sobre cuales son más apropiados a los proyectos distribuidos. 6. 1. El Ciclo de Vida Clásico.

Cada etapa obtiene unos resultados que se entregan a la etapa siguiente como punto de partida. Por esa razón el ciclo de vida clásico se denomina también como ciclo de vida en Cascada. Este ciclo supone que hasta que no se acaba una etapa no empieza la siguiente. Por esta razón este ciclo es, a mi juicio, obsoleto y desfasado ya que

Requerimientosde usuario

Análisis derequerimientos

Análisis Funcional/ Especificación

Diseño

Codificación

Prueba

Integración

Instalación

Administracióndel sistemaMantenimiento

Figura 101. Ciclo de Vida Clásico o en Cascada


hoy día las aplicaciones no son lineales, el usuario ha de intervenir en la mayor parte del ciclo de vida y la evolución es una constante. Y la adaptabilidad rápida una necesidad.

6. 2. El prototipaje. El prototipaje es un paradigma que consiste en montar una simulación operativa rápida del sistema para poder adelantar como se comportará y que operativa proporcionará. En la figura se muestra un esquema del paradigma de este ciclo de vida que, con el nivel de profundidad que quiero tratar la IS en este libro, es auto explicativo. El usuario puede utilizar el prototipo y hacer críticas y aportaciones. El primer producto resultante sirve normalmente para obtener especificaciones fiables y, en la mayoría de los casos es descartable y es un grave error utilizarlo como software de explotación. En el mundo distribuido especialmente, evite la tentación de hacerlo ya que el prototipo inicial ya de ser operativo lo más rápidamente posible y por tanto no puede ser robusto. El prototipaje es una técnica de interés cuando:

El usuario no es capaz de definir exactamente cuales son sus necesidades.

Cuando se han de evaluar rendimientos. Cuando se han de definir GUI’s y de quieren mostrar al usuario en fase de diseño.

Las técnicas de prototipaje no incluyen análisis de riesgo (del que hablaré más tarde). Las técnicas de prototipaje son interesantísimas en el mundo distribuido por varias razones.

La existencia de gran número de piezas fabricadas (si sigue la metodología puzzle) permite obtener prototipos potentes en poco tiempo.

Liga muy bien con las aplicaciones RAD. La mayoría de las aplicaciones distribuidas, avanzadas o RAD, acaban integrando sus clientes con GUI’s. El prototipaje de las GUI’s puede utilizarse como herramienta de diseño tecnológico. Si se utiliza la idea de componente de presentación (con poca o inexistente lógica de datos y de proceso) el prototipaje de GUI’s es una excepción ya que puede aprovecharse para la aplicación definitiva.

Especificación de requisitos

Diseñorápido

Construir elprototipo

Evaluación delprototipo

Depuraciónprototipo

ProductoIngeniería

InicioFinal

Figura 102. Prototipaje.


Existen tres alternativas para realizar prototipaje:

6.2.1. Construcción de una maqueta. Se construye una maqueta de una primera solución de la aplicación. Esa maqueta incluye las GUI’s y los menús. El usuario puede navegar por ella pero el comportamiento será simulado. Integra todas las piezas ya construidas que se van a reutilizar en la aplicación.

6.2.2. Construcción de una parte del sistema. Se construye una parte del sistema, normalmente un subconjunto operativo critico del producto final. Sirve tanto para que el usuario valore como para estimar rendimientos y hacer la etapa de distribución que más delante denominaremos “map to reality”.

6.2.3. Adaptar un programa existente. Se coge un programa ya existente que tiene el comportamiento esperado, se revisa para eliminar la funcionalidad no deseada, adaptar la que se reutilice e incorporar la nueva. Tiene el inconveniente de que necesita un esfuerzo más grande ya que hay que entender primero el programa que se reutiliza. Tradicionalmente se ha dicho que es, de las tres alternativas, la que da mejores resultados en la simulación del comportamiento final ya que parte de un programa operativo completo y real. Estoy de acuerdo con una importante excepción. Si usted dispone de una buena colección de piezas reutilizables, utilizar las dos anteriores sin tener que saber como se ha construido un programa ya existente (por desgracia, seguramente poco documentado) es una opción que puede salirle mucho más rentable en tiempo y costes.

6. 3. El modelo en espiral.

El modelo en espiral de Boehm se ha pensado para aprovechar las ventajas fusionadas de los modelos de ciclo de vida clásico y de prototipaje permitiendo introducir la gestión del riesgo que no se usa con prototipaje y que es necesaria en los modelos distribuidos avanzados para los que es muy

Planificación Análisis del riesgo

Evaluación del usuario

Ingeniería

Requerimientos Iniciales

Planificación basada en la evaluación del usuario

Evaluación del usuario

Análisis según requerimientos

iniciales

Análisis basado en la evaluación del usuario

Prototipo Inicial

Prototipo del segundo nivel

Avance hacia el Sistema Final

Figura 103. Ciclo de vida en Espiral


interesante este ciclo. El modelo en espiral realiza cuatro tareas cíclicamente:

Evaluación y planificación. Análisis del riesgo. Construcción. Evaluación del producto.

Así de en cada vuelta de van añadiendo prestaciones y la aplicación se va acercando al producto final. Conviene remarcar que cada ciclo aporta funcionalidad definitiva. Así, el ciclo en espiral se convierte en la forma de desarrollar de forma incremental, panacea para vacunarse contra muchos problemas. Cada etapa se aprovecha casi totalmente y en cada vuelta se van evaluando resultados y riesgos del modelo que se esta construyendo y se replantean cuales son las alternativas a seguir. No hace falta decir que este método aporta seguridad. Observe que cada vuelta puede hacerse utilizando cualquiera de los otros paradigmas y que necesita Gestión del Proyecto.

6. 4. Las técnicas 4GL. Las técnicas 4GL se basan en la adaptación a la funcionalidad específica necesaria de gran número de Framework ya construidos. Recuerde que un Framework es una pieza de algo nivel que integra una operativa compleja. Por ejemplo, un Framework de mantenimiento integrará todo lo necesario, GUI incluida, para realizar altas, bajas y modificaciones de ficheros independientemente de su formato y contenido semántico. Para realizar la modificación de un fichero en concreto se partirá del Framework general y se incorporará la sintaxis y la semántica de ese fichero en concreto. Así el entorno de 4GL se convierte en el soporte del diseño. Estas técnicas tienen su origen, y están basadas muy frecuentemente, en las herramientas 4GL, del tipo PowerBuilder. Estas herramientas disponen de Framework que permiten resolver rápidamente todo lo relacionado con la gestión y consulta de datos en soporte relacional, la base de los datos distribuida. Aporten además muchas herramientas de construcción de GUI’s, listados y funciones de todo tipo. Y, en general, un lenguaje de usuario avanzado. Las ventajas de las técnicas de 4GL son:

La gran ventaja en que la funcionalidad, la lógica del proceso y la operativa, que constituyen la parte complicada de probar, ya están probadas en su mayor parte.

Eficacia probada por los años en aplicaciones pequeñas e intermedias basadas en los datos.

Estandarización de la operativa. Rapidez en obtener resultados.

Las desventajas más claras son:


Aunque la idea de Framework es independiente de una herramienta en concreto, lo habitual es utilizar una. Ello comporta que el software creado queda ligado a esa herramienta.

Es muy difícil modificar el comportamiento del Framework para cubrir necesidades operativas especiales.

6. 5. La orientación a objetos.

No voy a repetir aquí todo lo explicado de OO en capítulos anteriores. Solo recordar que:

La OO. y C/S tienen una interacción prácticamente total y que OO. es la técnica fundamental en aplicaciones distribuidas avanzadas y en las integraciones cliente por GUI’s.

Las técnicas OO. son fundamentales por dos razones:

Existencia de clases que se reutilizan

Adaptabilidad por polimorfismo que permite adaptar las clases generales a los casos concretos con muy poco esfuerzo.

El desarrollo OO. es de naturaleza incremental. Se necesita formación para trabajar OO.

Se puede diseñar convencional e implementar OO.

Como la orientación a objetos se base en la construcción de sistemas a partir de clases (componentes sencillos por ser simples o por reutilizar otras clases ya construidas) extremadamente probadas se ha de trabajar con un ciclo de vida ligado a la clase o a un conjunto de clases (cluster) que resuelve modelan una problemática concreta. Así, un cluster no es más que una agrupación de clases afines.

Cluster 3Especificación Diseño/

ImplementaciónValidación/

Generalización

Cluster 2Especificación Diseño


Generalización.

Cluster 1Especificación Diseño/


Generaliación

Figura 104. Ciclo de vida de clase de Meyer

Sistemas del mundo real

Mantenimento

UsoPrograma

Más Desarrollo

Análisis de requerimentos

Especificación de losRequerimientos de SoftwareEspecificación de los Requerimentos de Usuario

Disño del sistema

Diseño del programaCodificación

Prueba UnitàriaPrueba de Sistema

Figura 105. Ciclo de vida OO de Henderson -

Sellers


Al ser una clase un componente simple, el ciclo de vida de una clase no es complicado y como se puede ver en la figura (ciclo de vida del paradigma OO) basado en clase propuesto por Meyer en 1989) es lineal cubriendo tres etapas:

Especificación. Construcción: Diseño e Implementación. Validación y Generalización.

Y además, gran ventaja, no hay sincronización entre los ciclos de vida de cada clase o cluster. Las cosas son más complejas si estudiamos el ciclo de vida de la construcción de todo un sistema a partir de las clases. No es el objeto de este libro y por tanto no entraré. Para que se haga una idea observe el ciclo de vida OO de Henderson-Sellers que se muestra en la figura. El modelo remarca el fuerte arraigamiento en el modelare, un alto nivel de interacción y una significativa fusión de las etapas del modelo clásico. Y, por descontado, que es desarrollo es incremental.

7. Gestión administrativa del proyecto.

Como ya se ha dicho, el aspecto administrativo del proyecto comprende la planificación y el seguimiento de la gestión técnica. La gestión técnica acaba generando especificaciones de cada una de las etapas que es la información que se toma como base para administrar el proyecto. Un esquema de la gestión administrativa de un proyecto y de sus acciones se muestra en la figura de la derecha. Repasaremos a continuación conjuntamente el ciclo revisando el contenido de cada una de las acciones que se muestran en la figura. 7. 1. Estimación.

La estimación es la actividad de la administración de un proyecto enfocada a valorar, a partir de la especificación, la carga de trabajo y los recursos necesarios para completar el proyecto. Como resultados de la estimación del proyecto se obtienen:

Los componentes de software, hardware y Middleware. El esfuerzo humano.

Estimación

Planificación

Agenda

Seguimiento

Revisión

Certificación de CalidadPuesta en MarchaCierre

Gestión Técnica

Figura 106. Esquema de Administración de un Proyecto


Las fechas cronológicas del proyecto que se habrán de cumplir. El coste

¿Cómo se realiza la estimación? Mediante técnicas de estimación basadas en mediciones, refrendadas y corregidas con la experiencia y reflejadas en métricas obtenidas por aquellas mediciones. Las estimaciones se revisan y planifican ajustándolas con el análisis de riesgos del que le hablaré más tarde. Hay parámetros comunes a todas las técnicas de estimación:

No se puede estimar sin establecer antes muy claramente el ámbito del proyecto: qué, cómo, cuando y donde.

El proyecto hay que desglosarlo en tareas individuales perfectamente definidas. Esas tareas hay que agruparlas por fases.

No se puede estimar sin métricas de software basadas en datos históricos.

Las métricas generales deben ser ajustadas con parámetros de corrección resultantes de cada organización y de cada cliente. No debería ser así pero, lo siento, si que lo es.

7. 2. Planificación y agenda.

La estimación lleva a la planificación. Y la planificación se concreta en una agenda. Se entiende por planificación la determinación de objetivos, las alternativas, las restricciones, la determinación de los recursos humanos y técnicos y la concreción de la agenda. El objetivo básico de la planificación es dar una estructura que permita al Director del proyecto hacer una previsión razonable de recursos, costos y agenda. La planificación se hace mediante una cuantificación de recursos y esfuerzos a partir de la estimación. La planificación se ha de hacer en un marco de tiempo limitado, al inicio del proyecto, pero ha de ser seguida, controlada, revisada y actualizada a medida que avanza el proyecto. La planificación temporal de un proyecto de software no es diferente de una de cualquier otro proyecto de Ingeniería. Hay que:

Identificar las tareas. Establecer las dependencias entre ellas. Estimar el esfuerzo en recursos técnicos y humanos Asignar personal y recursos. Crear la “red de tareas”. Asignar fechas objetivo Establecer la agenda donde queda reflejada la planificación temporal. Informar a los afectados y conseguir su consenso (fundamental).

7. 3. Seguimiento, Control y Revisión.


El seguimiento comienza cuando se dispone de la agenda y es la herramienta de control del Director del Proyecto. Se realiza siguiendo la evolución de cada tarea y comparándola con la planificación. Si una tarea no se desarrolla según las previsiones se ha de analizar el porqué y decidir como se puede corregir. Las acciones a realizar para hacerlo constituyen una revisión del proyecto. Una revisión supone, si es necesario, asignar o reorganizar los recursos, reorganizar las tareas o modificar los compromisos, que debería ser la última solución por razones obvias. Para que todo el proceso sea operativo y no utilice más tiempo del necesario, evitando costes, es conveniente que se use una herramienta automatizada. Y recuerde que las revisiones han de ser notificadas y consensuadas con los afectados.

7. 4. Puesta en marcha. Es un momento clave: si la puesta en marcha en los usuarios es mala, el proyecto quedará marcado. Para ello no se ha de iniciar la puesta en marcha sin la certificación de calidad de la parte a arrancar. Y en los proyectos distribuidos, es de especial importancia certificar el plan de integración. La teoría dice que hay que pensar en una puesta en marcha paulatina, sin tensiones de agenda. La cruda realidad es que siempre existen. Sin embargo, escoja retrasar los plazos antes que arrancar mal. Hágame caso, es peor sufrir la tortura lenta de una puesta en marcha mal hecha que la bofetada rápida de una negociación para retrasar un plazo. En la puesta en marcha, y para cada tarea que se arranca, hay que hacer las siguientes actividades:

Valoración de la especificación con el usuario responsable. Formación de los usuarios. Seguimiento de la calidad y las reacciones de plataforma y usuarios. Anotación de las pequeñas mejoras operativas (malo si no son pequeñas).

Puesta en marcha de esas mejoras. Aprobación final del usuario responsable y de los usuarios operativos. La primera necesaria, la segunda política.

7. 5. Conclusión de la etapa de desarrollo.

Las actividades a cubrir en ese momento son:

Confirmación de las prestaciones globales con el usuario. Seguimiento de las primeras explotaciones de todo el sistema acabado. Confirmación de la calidad. Aprobación completa del usuario responsable. Recolección de las medidas para las métricas. Catalogación y revisión final de la documentación. Informe de finalización de la etapa de desarrollo. Traspaso del proyecto al personal de mantenimiento.


8. Análisis de riesgos.

8. 1. ¿Qué se entiende por Análisis de Riesgos?

Analizar los riesgos es una sana actividad de administración, raras veces realizada, que consiste en preguntarse que puede ir mal, vacunarse y prever las soluciones si las vacunas no surten efecto y el riesgo acaba concretándose en una realidad. Esta actividad es fundamental en proyectos distribuidos avanzados, en los que, por la naturaleza de una arquitectura distribuida, hay muchas cosas con riesgo potencial.

8. 2. Metodología. Por raro que le parezca existen metodologías para analizar el riesgo. La primera de ellas es identificar áreas de duda. Hay áreas de duda estándares:

¿Se ha entendido realmente lo que el usuario necesita? ¿Qué especificaciones no parecen del todo fiables a pesar del esfuerzo del análisis?

¿Nuestro personal esta correctamente formado en las herramientas y los recursos que se van a utilizar?

¿Los plazos de entrega son realmente asumibles? ¿Vamos a tener que abordar trabajos no previstos? ¿Hay problemas técnicos escondidos? ¿Tenemos capacidad y recursos para hacer revisiones ante los problemas y cambios que, seguro, aparecerán?

¿Qué compras y subcontrataciones pueden tener retrasos? El análisis de riesgos consiste realmente en una serie de paso de control de esos riesgos que permiten combatirlos. Esos pasos se aplican a todo el proceso de IS:

8. 3. Actividades. Las actividades a cubrir son básicamente cuatro:

8.3.1. Identificación de los riesgos. Hay que preguntarse dentro de cada área de duda cuales son los riesgos de que un proyecto fracase tarea a tarea. Consiste en relacionar, entre todas las listas de riesgos posibles, cuales afectan al proyecto. Hay cuatro grandes grupos de riesgos en que se agrupan las respuestas a las preguntas realizadas en las áreas de duda. Le relaciono a continuación los riesgos potenciales dentro de cada grupo, marcando en negrita los riesgos, que a mi juicio, son más peligrosos en el mundo distribuido.


8.3.1.A. Riesgos de proyecto.

Complejidad del proyecto. Tamaño. Fiabilidad de la especificación. Problemas presupuestarios. De personal, en especial formación, pero también motivación. De cambio de plazos. De cambio de Personal De recursos. De usuario.

8.3.1.B. Riesgos técnicos.

Problemas u omisiones de diseño. Implementación. Pruebas. Integración. Mantenimiento “post arranque”. Estado de la plataforma. Riesgo de que fallen los plazos de entrega de compras y subcontrataciones.

8.3.1.C. Riesgo de negocio.

Oportunidad. ¿Está la organización preparada? ¿La calidad buscada es la realmente necesaria? No olvide que los informáticos somos en muchas ocasiones demasiado perfeccionistas. Grado de adaptación del proyecto a la estrategia global de la empresa. Mejor no ir contracorriente... ¿Es el producto vendible? Riesgo de gestión o pérdida de soporte por los usuarios que han promocionado el proyecto. Incluya aquí la opción de cambio de personas que se produce cíclicamente en las empresas. Riesgo de presupuesto o pérdida de presupuesto monetario y/o recursos. ¿Es el coste asumible por la organización? O nos hemos metido en un volumen de gasto que no nos podemos permitir. No menos precie este riesgo ya que la solución fácil es cortar prestaciones o actividades. Y esta opción conduce el fracaso. Vale más que revise los objetivos, corte lo que supone menos retorno de inversión y recalcule todo de nuevo. Vale más un proyecto posible pequeño realizable que uno grande no asumible.

8.3.1.D. Riesgos imprevisibles.

Desgraciadamente existirán aunque esta lista quedará vacía en su identificación de riesgos: si un riesgo imprevisible es previsible ya no es imprevisible. Perdóneme el juego de palabras, no me he podido resistir.


8.3.2. Cálculo del riesgo. Una vez identificados los riesgos hay que ver como afectan a los plazos y recursos, cuantificar como afectan a las tecnologías, recursos humanos y resto de factores del proyecto.

8.3.3. Proyección. La siguiente actividad será establecer el impacto en el proyecto de la cuantificación calculada, decidir las soluciones alternativas y ver como afectarían al proyecto si han de ser activadas. La proyección intenta evaluar el riesgo de dos formas:

Probabilidad de que el riesgo sea real. Consecuencias en caso de que aparezca. También llamado grado de desastre.

El gestor ha de hacer cuatro subactividades básicas:

Establecer una escala de medida. Definir las consecuencias. Estimar el impacto en el proyecto. Anotar todo lo necesario para la gestión.

8.3.4. Gestión.

Finamente, habrá que realizar las actividades de gestión estableciendo las estrategias de control del riesgo, resolución o momento en que se activan las soluciones alternativas y supervisión de esas soluciones.

9. Una reflexión final. Las ventajas de considerar el software como un proceso industrial son incuestionables. También es incuestionable que el software está desarrollado normalmente con procesos de fabricación artesanales o, el los casos más favorables, con criterios industriales mínimos. Y que prácticamente nadie mide y aplica procesos de mejora de calidad como resultado del análisis de esas mediciones. Los factores fundamentales son a mi juicio:

1. La poca formación de algunos directores de proyecto. 2. El alto coste del proceso de fabricación industrial del software. Y aquí se

produce el contrasentido que un criterio de ingeniero (mejor producto al menor coste) entra en conflicto con otro (coste alto del proceso de fabricación).

El factor compensador es el “menor coste” de fabricación, mantenimiento, ampliación y gestión del software bien construido. Pero, ¿como se mide esto? Y al final, el factor determinante es el juego de mercado. En mi faceta de profesor universitario, he intervenido en muchas conversaciones en que se acusa a la industria del software de no saber trabajar bien. En mi faceta de diseñador industrial


también he intervenido en muchas conversaciones de “industriales” que afirman la tontería de que “los universitarios” pierden el tiempo y que todas sus propuestas son imposibles de seguir en la industria. Es un hecho que es coste de un proyecto bien hecho no es competitivo en el mercado. Si usted pasa una oferta por un proyecto bien hecho irá mucho más caro que su competencia que ignora la gestión industrial de proyectos o, simplemente, pasa de ella. Y como muchos de los clientes potenciales no distinguen un diseño de un código en un lenguaje de programación, su oferta no será la escogida. Y si no le contratan proyectos no cobrará. Y si no cobra no comerá.... ¿Cómo se cambia la tendencia? ¡No tengo ni idea! Ojala lo supiera.....


Del Análisis Funcional/Especificación al inicio del diseño de los Sistemas

Distribuidos

1. Posibilidades de utilización de servicios.

Como hemos presentado en la primera parte, hay tres posibilidades para utilizar servicios: • Desde la especificación: Especificación por servicios:

o El sistema se contempla como una integración de servicios. o Los servicios están ya definidos y especificados. o Si alguno no lo está, hay que especificarlo. o Los datos son responsabilidad de los servicios. o Veremos posibilidades de integración en la composición de servicios.

• En el diseño: Diseño por/con servicios. o Hay que identificar y diseñar servicios de datos y procesos. o Es una etapa interpuesta en el diseño clásico.

• Solución hibrida: Servicios como agentes externos. o Es una situación habitual.

1. 1. Especificación por servicios.

Los procesos de negocios se muestran como una interacción del servicios. Necesitamos un documento que muestre la interacción de servicios:

• Proporcionado directamente por el organizador. • Creado por el informático: Un recurso puede ser el diagrama de

actividades.

1. 2. Diseño por/con servicios. El matiz por incluye todo por servicios y el con, ayudarse por servicios y utilizarlos junto a componentes queno lo son. A grandes rasgos, se caracteriza por:

• El diseño empieza a partir de la documentación de especificación. • Al asignar responsabilidades, hay algunas que son asumidas por

servicios ya existentes. • Como hemos introducido, hay dos posibilidades:

o Con servicios: solo una parte de la especificación es asumida por servicios.

o Por servicios: Todos son servicios. • Obviamente, las dos posibilidades se diseñan de forma parecida:

identificando por servicios todo o solamente una parte de la funcionalidad.


• La parte que quede responsabilidad de los servicios, no ha de permitir diferenciar entre:

o Servicios construidos para la aplicación. o Servicios reutilizados: o De otras aplicaciones ya existentes. o Suministrados por terceros

• Hay que “trocear” el diagrama de datos eliminado aquellos que quedan como responsabilidad de los servicios.

1. 3. Servicios como agentes externos.

Se incluyen como tales en los casos de uso de la especificación UML. Hay que eliminar del diagrama conceptual de datos los que quedan como responsabilidad del servicio. Se han de incluir las especificaciones y los contratos de los servicios utilizados.

2. Introducción al diseño distribuido.

Como ya se ha dicho anteriormente, el diseño distribuido que supone la existencia de un sistema distribuido influye básicamente en el diseño tecnológico del sistema de información. Así pues, las técnicas de diseño distribuido van a desarrollarse para esa etapa. Sin embargo, es evidente que para que sea posible la existencia de un diseño tecnológico es necesaria la existencia de un análisis funcional o especificación que determine que se desea del sistema de información que se está creando. Usaré los términos Análisis Funcional (denominación clásica) o Especificación (Orientación a Objetos UML) indistintamente para referirme a la definición de las funcionalidades que debe cumplir el sistema de información que se diseña. Para no repetir continuamente los dos términos usaré sólo uno de ellos, primando análisis funcional. Usaremos el término diseño tecnológico en ambos casos para referirnos a la etapa en que a partir del diseño funcional se crea la arquitectura de sistema y se diseñan los programas y procesos para acabar implementando la funcionalidad sobre herramientas de desarrollo. La metodología que se propone para el diseño distribuido es independiente de la metodología utilizada en los diseños funcional y tecnológico. Esto es así porque se basa en tres patas que proporcionan todas las metodologías funcionales y tecnológicas:

Una descripción de los datos. Diagramas de transformación. Una secuencialización de los procesos.

Las aplicaciones avanzadas necesitarán, como todas, de una metodología de diseño funcional. Escoja la que quiera. Particularmente mi voto es por Orientación a Objetos.


Para las aplicaciones de RAD le voy a proponer una metodología propia, MAFDRA, que utilizaremos también para documentar la funcionalidad de los ejemplos que diseñaremos después tecnológicamente en este documento. En organizaciones que no dispongan de una metodología propia para RDA pueden usar la propuesta MAFDRA. Va a ser una precondición que el lector esta versado en los elementos básicos del diseño funcional y tecnológico como modelos de datos, diagramas de flujo, diagramas jerárquicos, diagramas de estados, diagramas de secuencia, casos de uso, etc. Aunque este capítulo y los siguientes proporcionan suficientes conocimientos sobre estas herramientas para seguir las explicaciones, el lector puede consultar documentación especializada si desea mayor nivel de conocimientos.

3. Elementos comunes a cualquier metodología de diseño. Cara a la presentación de la metodología de diseño distribuido es conveniente hacer una reflexión previa. A lo largo de la evolución de las metodologías de diseño es contrastable que, independientemente de la forma y herramientas propuestas cualquier metodología de tiene los siguientes bloques comunes: 3. 1. La descripción de los datos.

En la que siempre hay una descripción de las entidades de datos afectados y las relaciones estáticas y dinámicas que se establecen entre ellas.

3. 2. Descripción de los procesos de transformación. Un sistema de información trasforma la información contenida en unas entidades de entrada generando nuevas entidades de salida, o las mismas de entrada modificadas de acuerdo con las necesidades para las que se ha diseñado. Así un sistema de información puede ser contemplado como un conjunto de Procesos de Transformación. Todas las metodologías funcionales recogen estos procesos de una forma u otra. En las metodologías convencionales, una de las herramientas comúnmente utilizadas para hacerlo son los diagramas de flujo. Mi metodología RDA se va a basar en ellos. En las orientadas a objetos, esta información puede extraerse de los casos de uso, los diagramas de secuencia y los diagramas de comunicación/colaboración cuando se incluyen

3. 3. Secuencia en que se ejecutan los procesos de transformación. En las metodologías convencionales, esta información esta repartida entre el funcional, los diagramas de flujo y la descripción de los programas. Básicamente, mi metodología de diseño distribuido aplicada a RDA aprovechará la segunda vía analizando dentro de los programas cliente y los servidores en que orden se ejecutan internamente los procesos de transformación.


En las metodologías OO., esta información se contempla en los diagramas de secuencia y colaboración y de aquí partiremos.

Reparemos, finalmente, que como estos tres elementos están presentes en cualquier metodología de desarrollo, las técnicas que se presentarán serán válidas para cualquiera de ellas.

Como se verá en el capítulo dedicado al diseño de la arquitectura distribuida habrá dos formas básicas de identificar servicios será analizar:

Revisar la localización y gestión de las entidades de datos. Analizar la secuencualización.

4. Encaje de la etapa de diseño tecnológico en el ciclo de desarrollo del software.

Las metodologías de diseño de aplicaciones avanzadas como UML realizan la etapa de análisis funcional/especificación y a partir de ahí inician una etapa de diseño tecnológico que acaba con la construcción de la arquitectura de sistema o del software según la terminología de cada una. Las metodologías de diseño RAD, como MAFDRA, realizan la etapa de diseño funcional e incluyen como última etapa de esta fase una descripción de los programas más complejos que sustituye a la inexistente etapa de diseño tecnológico. La arquitectura del sistema en tan trivial que normalmente se omite en la documentación o se incluye al final del análisis funcional. En la metodología que le voy a proponer, la etapa de diseño distribuido se encaja delante de la conclusión de la arquitectura del sistema, tal como se muestra en la figura de la derecha. En las dos metodologías, en ese punto se dispone ya de la documentación necesaria para proporcionar las tres patas en que me basaré: descripción de los datos, procesos de transformación y secuencialización.

5. Resumen de puntos de partidas según la metodología empleada.

En los capítulos siguientes se incluye la descripción de los elementos utilizados en el diseño de sistemas convencionales y en los orientados a objetos. Si, como espero, Vd. ya los conoce, le recomiendo que se salte esos capítulos excepto aquellos puntos donde se explica la metodología MAFDRA para el diseño de aplicaciones de desarrollo rápido. Conviene que revise esos apartados porque ese será el marco (por su sencillez y claridad didáctica) que voy a utilizar para la descripción de los ejemplos que acompañarán a las presentaciones teóricas.

Etapa TecnológicaEtapa FuncionalAnálisis Funcional /

Especificación Diseño Tecnológico

Diseño DistribuidoDescripción de los programas principales

Arquitectura del Sistema/Software

UML

UM

L

MAFDRA

MA

FDR

A

CO

MU

N

Figura 107. Encaje del diseño distribuido en el ciclo de desarrollo del

software


Por si no visita completamente cada uno de esos capítulos, incluyo a continuación un resumen de los puntos de partida de partida de cada metodología.

Metodologías convencionales: Datos: Modelo relacional Procesos de transformación: Diagramas de flujo. Secuencia de transformación: Descripción de los procesos y programas tras el tecnológico.

Metodología RDA - MAFDRA Datos: Diagrama de Datos OO – Modelo conceptual de especificación. Procesos de transformación: Diagramas de flujo. Secuencia de transformación: Secuencialización de los procesos dentro de los diagramas de flujo.

Metodología OO – UML. Datos: Modelo conceptual de diseño. Procesos y secuencia de transformación:

Diagramas de Secuencia de diseño. Diagramas de Actividades de diseño. Diagramas de Colaboración de diseño.

Integración de la parte cliente: Casos de Uso y Diagramas de Colaboración (cuando existen)

Verá más adelante que en MAFDRA el funcional y el reducido tecnológico que necesita una aplicación RDA se desarrollan simultáneamente. En los otros dos casos es necesario disponer como mínimo de la arquitectura del sistema para poder atacar la etapa de diseño tecnológico distribuido.


Elementos funcionales y tecnológicos para la descripción de los procesos en

metodologías convencionales

1. Introducción.

Se incluyen en este capitulo la descripción de los elementos funcionales de las metodologías convencionales que voy a utilizar para escribir los procesos en la metodología funcional RAD.

2. Descripción de los procesos de transformación. Diagramas de Flujo. Un sistema de información trasforma la información contenida en unas entidades de entrada generando nuevas entidades de salida, o las mismas de entrada modificadas de acuerdo con las necesidades para las que se ha diseñado. Así un sistema de información puede ser contemplado como un conjunto de Procesos de Transformación. Todas las metodologías funcionales recogen estos procesos de una forma u otra. Una de las herramientas comúnmente utilizadas para hacerlo son los diagramas de flujo. En la figura de la izquierda de muestran tres procesos de transformación reflejados en un diagrama de flujo. Como cualquier lector familiarizado con este tipo de diagramas podrá ver fácilmente el de la figura presenta algunos componentes que no son habituales y que presento y justifico en el apartado siguiente.

3. Extensión de los diagramas de flujo. Para poner definir y utilizar la metodología de diseño RAD voy a proponerle tres extensiones de los diagramas de flujo. Los dos primeros, iconos especializados y secuencialización, los voy a presentar aquí. La tercera, dedicada a la representación de los procesos de consistencia, la presentaré en el capitulo dedicado a esa parte de diseño distribuido.

Petición cliente

Actualizadatos

Datos Compañía aera

Clientes

EntradaPetición

Cliente

Clientes

Vuelos por cliente

ReservaCliente

ImpresiónReserva

Crédito estandar

Figura 108. Ejemplo de diagrama de flujo.


3. 1. Iconos.

A continuación le presento los iconos que utilizaré dentro de los diagramas de flujo. La mayoría de ellos son estándar. Unos pocos son específicos de metodología que desarrollaremos después.

3.1.1. Agente externo. Elemento que proporciona o recibe información a o del sistema.

3.1.2. Entidad.

Agrupación de datos que representa una unidad de información. En estos diagramas de flujo una entidad es un

concepto lógico independiente de localización u organización. Así, una entidad producto puede localizarse en una base de datos relacional y una entidad datos del pedido puede corresponder al contenido de una GUI. Trabajar así permitirá pensar primero y después implementar, aunque en muchas ocasiones la localización y organización de la entidad será obvia y, frecuentemente, en BD.

3.1.3. Proceso de transformación.

Corresponde al componente habitual de los diagramas de flujo que transforma, total o parcialmente, unas entidades en otras. La transformación puede afectar a campos o a la totalidad de la entidad. En algunos diagramas de flujo se identifican los atributos que cambian.

En nuestra metodología no utilizaremos esa opción.

3.1.4. Salida impresa. Entidad representada sobre un soporte de papel. Suele corresponder a la representación con formato de una secuencia.

3.1.5. GUI.

Se representará por el icono de una pantalla.

3.1.6. Entidad implementa en BD.

Cliente

Productos

Actualizadatos

ReservaCliente


Entidad representada sobre base de datos.

3.1.7. Servicio.

Representación que conocemos desde los primeros capítulos. Mas adelante incluiremos también iconos específicos para representar los agentes y los clientes

background y reserváremos este sólo para servidores.

3.1.8. Modelos de comunicación C/S. Recuerde y repase los presentados en el capítulo dedicado a este tema.

3. 2. Secuencialización.

Un diagrama de flujo tradicional muestra los procesos de transformación, no en que orden se ejecutan.

Para construir los elementos distribuidos, clientes, servidores o agentes, que llaman a servicios, es interesante conocer en que orden se ejecutan los procesos. En la metodología que propondremos, para indicar el orden de ejecución de los procesos de transformación utilizaremos una extensión de los diagramas de flujo consistente en indicar en el propio diagrama en que secuencia se ejecutan los procesos. Utilizaremos una fecha en “grueso” para indicar esta secuencialización de los procesos, tal como se muestra en la figura. Esto nos permitirá, entre otras cosas, detectar puntos donde la comunicación asíncrona puede permitir mejorar el rendimiento del proceso.

Observe el ejemplo de la figura. En ella se muestra un proceso de captación de un pedido de un cliente en un puesto de venta. El proceso necesita verificar el crédito accediendo a un servidor de crédito localizado en la central y accesible solo a través de una vía remota lenta. Observe que, después

ActualizarCrédito

Actualizadatos

EntradaPetición

Cliente

Pedido

ComprobarCréditoPetición

Cliente

Accesoal

Cliente PedirProductos

TomarDatos

Clientes

ClientesServidor de

Crédito

R

Cuentas Clientes

Imprimirfactura

Contado

Avisoal

Cliente

Factura

Sin Crédito

Con Crédito

Figura 109. Ejemplo de la utilidad de la

secuencialización


de identificar al cliente, se accede aun servidor de datos de cliente local que tiene que acceder al crédito de la central. La comunicación se ha diseñado asíncrona, mediante colas, para permitir que, mientras el servidor de clientes accede a al central, el proceso cliente pida al cliente los productos que desea. Después de entrarse los productos del pedido el proceso recoge o espera la respuesta. Como lo normal es que el cliente tenga crédito (cierre el negocio en caso contrario) el tiempo de espera del cliente ante el puesto de venta se ha reducido al mínimo. Observe que las flechas de secuencialización de entrada y salida al servidor de clientes llegan y van a procesos de transformación del programa cliente diferentes.

3. 3. Decisiones.

Cuando hay secuencialización hay alternativas o puntos del proceso donde hay que tomar decisiones. No hace falta decir, que por su naturaleza, los diagramas de flujo no contemplan tampoco nada relacionado con este concepto. Cuando dentro de uno de nuestros diagramas de flujo haya que tomar una decisión lo representaremos con la salida desde un proceso de transformación de más de una flecha, colocando en la fecha la condición que lleva a seguir esa vía.

Observe el ejemplo de la figura. Un acceso a clientes puede acabar encontrando el cliente o no. La vía de No Existe lleva a un proceso de alta en el cual se pedirán al cliente sus datos, mientras que la vía de Existe pasa directamente a pedir los productos que

el cliente desea comprarnos. En ambos casos, los datos del cliente quedan reflejados sobre una pantalla. En el diagrama de flujo del apartado anterior observará también la representación de una decisión, el análisis de si un cliente tiene crédito o no.

3. 4. Enlace entre diagramas. Y la última consecuencia de la secuencialización es que, muy excepcionalmente, un diagrama de flujo a de “empalmar” con otro. Verá que, en mi metodología y debido a la utilización del análisis descendente del que hablaré a continuación, este caso es absolutamente opcional.

Dar deAlta

Acceso aClientes

PedirProductos

Cliente

Clientes

No Existe

Existe

Figura 110. Ejemplo de Decisión dentro de la Secuencia de

Ejecución.


Cuando esto ocurra, utilizaremos el método de crear una entidad que sea de salida del de origen y de entrada del de destino.

4. Análisis descendente. 4. 1. Introducción.

Como parte de la metodología propuesta, y como explicaremos más adelante, para detallar los procesos se va a utilizar Análisis Descendente. Si el lector conoce este concepto puede omitir la lectura de este apartado.

4. 2. Concepto de acción, parámetro, efecto y estado. Aquí asimilaremos acción a proceso de transformación

4. 3. Especificación. La especificación de una acción define el efecto del proceso de transformación. Para que una especificación defina claramente el efecto debe contener:

La declaración de parámetros. Los estados inicial y final. El nombre asignado al proceso, cabecera y como se utiliza.

Ha de ser concreta, precisa, unívoca y clara.

4. 4. Metodología de especificación. Para obtener la especificación de un proceso deben seguirse los siguientes pasos:

Identificar los parámetros afectados por el proceso. Deberá revisarse el entorno del proceso, que datos hay de entrada y que resultados se desean. A partir de aquí identificaremos que parámetros representan los datos encontrados.

Determinar los tipos de esos parámetros. Se intentará asignar un tipo de datos entre los estándar. Si no existe se creará uno de nuevo con un constructor de tipo. Conviene en todo momento tener una referencia única de todos los tipos utilizados en el entorno.

Determinar la categoría o modo de los parámetros: entrada, salida o de entrada / salida.

Definir la precondición y la poscondición. Definiremos uno o más postulados en la precondición para cada parámetro de entrada o de entrada / salida. El efecto esperado del proceso se reflejará en la poscondición incluyendo uno o más postulados por cada parámetro de salida o de entrada salida.

Asignaremos un nombre al proceso y el orden en que se le pasan los parámetros. Es lo que normalmente se conoce como cabecera de la llamada al proceso.

4. 5. Descomposición de procesos. Concepto de primitiva.


Es intuitivo que para conseguir el efecto de un proceso será necesario descomponer el proceso que se ha de diseñar en otros más simples cuyo efecto combinado produzca al efecto total buscado. Se produce así un refinamiento de proceso original ya que cada vez los procesos obtenidos son más simples. La descomposición de procesos continuará hasta que se lleguen a procesos “ya programados”. Surge así el concepto de primitiva como un proceso que no puede o no necesita ser descompuesto porque alguien lo ha programado antes. Las fuentes de procesos primitivos pueden ser muy variadas pero a efectos prácticos siempre toman cuatro formas:

4.5.1. Sentencias. Proporcionadas por los lenguajes de programación.

4.5.2. Rutinas ya programadas. Cuyo comportamiento estará perfectamente definido a través de su especificación. El programador podrá utilizarlas sin saber como se han programado interiormente. Para que las rutinas primitivas sean cómodas de utilizar, evitando efectos colaterales no deseados, es necesario que las rutinas se programen con técnicas de encapsulamiento, se decir su única comunicación con el exterior sea su cabecera. Ello conlleva la no existencia de variables globales y por tanto que todas las variables de trabajo sean locales a la rutina. De cualquier forma, recuerde que del concepto de encapsulamiento ya hemos hablado anteriormente.

4.5.3. Piezas y / o Objetos. De hecho, éste caso es una aplicación del anterior ya que la utilización de una pieza se realiza siempre a través de rutinas.

4.5.4. Servicios. Adquiridos o construidos.

4. 6. Metodología del análisis descendente. Es necesario establecer una técnica para realizar el refinamiento que permite descomponer los procesos. Esta técnica será el análisis descendente. El análisis descendente esta basado en el Teorema de la Composición Secuencial. Se entiende por composición secuencial el efecto producido por la combinación de los efectos de dos o más procesos que se ejecutan secuencialmente. Si se tiene un proceso S1 que lleva de una precondición {P} a una poscondición {R} y otro proceso S2 que lleva de la misma precondición {R} a una poscondición {Q}, el efecto combinado de S1;S2, que representaremos por S, es llevar de la precondición {P} a la poscondición {Q}.


Algebraicamente el teorema de composición secuencial de procesos adopta la forma: {P} S1 {P} {R} ≡ S donde S≡S1;S2 S2 {Q} {Q} La utilización “inversa” del teorema de composición proporciona la técnica simple, robusta y muy potente para descomponer procesos. Si se tiene un proceso S que ha de llevar de la precondición {P} a la poscondición {Q} podemos descomponerla en otras dos S1; S2 encontrando un estado intermedio {R} que sea poscondición de la primera y precondición de la segunda. El teorema de composición secuencial garantiza la validez de la descomposición. Evidentemente, el teorema y la técnica pueden generalizarse al caso en que S sea composición de más de un proceso: S≡S1; S2;.......; Sn. Así la metodología de análisis descendente como técnica de descomposición de procesos adopta la metodología siguiente.

Se especifica el proceso que se quiere diseñar. El proceso de descompone en dos o más procesos que se ejecutan secuencialmente obteniendo estados intermedios que sean precondición del anterior y poscondición del siguiente.

Evidentemente el estado inicial es la precondición y el final es la poscondición del proceso a diseñar.

El proceso se aplica recursivamente y el refinamiento acaba cuando todos los procesos finales son primitivas o ya han salido anteriormente.

Todos los parámetros del proceso a diseñar han de aparecer como entradas o salidas, según su categoría, de como mínimo un proceso de los obtenidos por descomposición. Es habitual que por el camino se obtengan otros objetos intermedios de trabajo que siempre quedarán internos, locales, al proceso que se está diseñando.

Es habitual representar gráficamente el resultado de la descomposición con un grafo como es de la figura. Sin embargo la experiencia demuestra que esta representación gráfica, que es muy clara, en ejemplos simples queda gravemente limitada es casos reales ya que la profundidad del árbol

yo hace de muy difícil representación gráfica y además puede haber procesos elementales utilizados en más de un nivel y a diferentes “profundidades”.

S

S1

S2

S11

S12

S13

S12a

S12b

Figura 111. Análisis Descendente


4. 7. Ejemplos. Veamos la utilización de análisis descendente a dos ejemplos muy simples.

4.7.1. Contar consonantes después de la aparición de una vocal en un texto. La especificación del proceso a diseñar es: var S: texto de carácter; compt: entero {S está informado} contar(ent S, sal compt) {compt tiene el número de consonantes después de la primera vocal del texto}. Aplicando análisis descendente: contar (S,compt)

{S está informada} buscar_la_primera_vocal(S) {S esta situado en la primera vocal o fi(S)} si no fi(S) entonces contar_consonantes(S,compt) sino compt:= 0 fsi {compt tiene el número de consonantes después de la primera vocal del texto}.

Los procesos de buscar_la_primera_local y contar_consonates no son primitivas. La asignación del valor 0 a compt si lo es. Habrá que aplicar de nuevo análisis descendente a las dos primeras: buscar_la_primera_vocal (S,compt)

{S está informada} colocar_texto_al_principio (S) mientras no vocal (caracter_actual(S)) i no fin(S) hacer situar_el_caracter_seguiente(S) fmientras {S esta situado en la primera vocal o fin(S)}

Colocar_text_al_principio, caracter_actual, fin(S) y situar_caracter_seguiente, son primitivas del sistema. El lector puede asimilar el texto a un fichero de texto secuencial. Las primitivas corresponden a open, read_position, seek y eof. La función vocal será: función vocal(ent valor c: carácter) retorna (c=‘A’ o c=‘E’ o c=‘I’ o c=‘O’ o c=‘U’) ffunción La función contar_consonante es contar_consonante (S,compt)

{S esta situado en la primera vocal} compt:=0 mientras no fi(S) hacer


si no vocal(caracter_actual(S)) entonces compt:=compt+1 fsi situar_el_caracter_seguient(S) fmientras {compt tiene el número de consonantes después de la primera vocal del texto y fi(S)}

4.7.2. Pedir un código de cliente y sacarlo por la pantalla

La especificación del proceso es: tipus CLIENTE= ; PANTALLA= var cliente: CLIENTE; salida: PANTALLA_CLIENTE {cliente.codigo esta informado} consultar_cliente(sal cliente, sal salida) {salida es una pantalla con los datos del cliente cliente.codigo}. consultar_client (cliente,salida)

{ } obtener_datos_cliente(cliente) {Client tiene los datos o cliente.codigo no existe} si cliente.codigo no existe entonces avisar_en_la_pantalla(salida,aviso) sino preparar_pantalla(salida,cliente) fsi {salida es una pantalla con los datos del cliente cliente.código}.

Si obtener_datos_cliente es un servidor y la gestión de pantallas son servicios del sistema (primitivas), el diseño ya ha acabado.

4. 8. ¿Porqué utilizar análisis descendente? Además de su simplicidad y potencia, es aplicable a todos los ámbitos, datos y procesos. Supone una metodología de general a detalle (top-down) fácil de aplicar y sistematizar. La claves es una buena elección del estado intermedio con el cual se “rompe” el proceso que estamos diseñando y disponer de buenas primitivas en cantidad y calidad. El “divide y vencerás” siempre es una buena táctica. Además, el concepto de primitiva liga perfectamente con el de reutilización. La técnica de análisis descendente puede potenciarse con otras que permitan especificación formal y verificación analítica. Sin embargo entrar en ellas queda fuera del ámbito de este libro. El lector podrá consultar documentación específica se desea ampliar los conceptos expuestos aquí.

5. Diagramas Jerárquicos.

Los diagramas jerárquicos permiten el análisis de la funcionalidad por áreas. Los procesos de transformación se agrupan por temas y grupos de ejecución. Marcan la jerarquía de control y ejecución, conocida, a veces, como jerarquía de programa. No representan aspectos procedimentales del tipo secuencia de procesos, decisión de procesos, etc.


Al ser jerárquicos, permiten establecer relaciones entre módulos como: módulo

superior, subordinado, visibilidad, conexiones, etc. En efecto, observe el diagrama jerárquico de la figura. La aplicación se ha dividido en cuatro subsistemas. Cada subsistema tendrá módulos y los módulos integrarán

funciones. No son, pues, de interés para el diseño distribuido de forma directa. Pero si lo son de forma indirecta ya que la mayoría de los procesos cliente en las arquitecturas distribuidas son programas con interfaces GUI’s, especialmente en RDA, y los diagramas jerárquicos son, por su naturaleza, la forma más cómoda de establecer

la jerarquía de pantallas y menús en que se organiza la aplicación. Aunque no hay una regla de obligado cumplimento, el diagrama jerárquico de la figura llevaría a una pantalla principal asociada a la aplicación en la que habría un menú cada

uno de los subsistemas. Un submenú asociado a cada subsistema desplegaría los módulos de ese subsistema. La llamada al módulo llevaría, probablemente, a una nueva GUI’s donde se tratarían un menú o por botones cada función. Los diagramas jerárquicos no obligan a que todas las funciones que desarrollan cada módulo sean independientes entre si. Puede ocurrir, y de hecho pasa habitualmente, que más de un módulo compartan una única función, tal como se representa en el diagrama de la figura. Evidentemente, este hecho no supone ninguna complicación adicional a la hora de plantear los menús. Finalmente, en la figura de la derecha se muestra un ejemplo de un diagrama jerárquico aplicado a una aplicación de producción y stock.

Subsistema 1

Módulo A

Función 1 Función 2 Función 3 Función 4

Módulo B Módulo C

Subsistema 2 Subsistema 3 Subsistema 4

APLICACIÓN

Figura 112. Diagrama Jerárquico

Módulo A

Función 1 Función 2

Módulo B

Subsistema 1 Subsistema 3

Módulo C Módulo D

Función 3

Subsistema 4

APLICACIÓN

Figura 113. Diagrama Jerárquico con funciones compartidas

GestiónAlmacenes

InventarioValorado

STOCKS

Ofertas

Lanzamiento

ControlCalidad

Entradaa Stocks

Recepción

Pedidos

COMPRAS

Planificación Seguimiento Rebajarde Stocks

PRODUCCIÓN

FABRICACIÓN

Figura 114. Ejemplo de Diagrama Jerárquico.


Descripción de los Datos en un Modelo Relacional

1. Introducción. Le voy a presentar en esta parte del libro las dos formas básicas, que a mi juicio, pueden utilizarse para describir los datos en los diseños de las aplicaciones distribuidas:

• El Modelo Relacional • El Modelo de Objetos de las metodologías OO.

El segundo es el adecuado para las aplicaciones avanzadas. Para las aplicaciones rápidas, puede utilizarse el modelo relacional, aunque no desprecie la posibilidad de utilizar también el modelo de objetos. Le he comentado anteriormente que todas las aplicaciones distribuidas implementan sus datos sobre el modelo relacional. ¿Qué hacer si se utiliza el modelo de objetos? No se preocupe, como veremos en un capítulo posterior implementar un modelo de objetos sobre un SBDR relacional supone la aplicación de unas reglas de mapeo de una facilidad extraordinaria. Por esa razón, describir OO aprovechando las ventajas de su mayor potencia semántica, e implementar relacional se convierte en una vía muy interesante. Este capítulo está dedicado a dos temas:

Establecer una terminología base de datos para que usted y yo nos entendamos.

Recordar (¡sólo recordar!) los fundamentos básicos del modelo relacional. Dejaremos para un capítulo posterior el recordatorio del modelo de datos en una metodología OO.

2. Terminología básica para la descripción de los datos. El Modelo de Datos.

Establezcamos una terminología básica de datos. Los modelos de la realidad se representan por entidades de datos, clases en los modelos OO. Así, podemos hablar de Persona, Cliente, Producto, Coche, Equipo, etc. Aquí se va ha utilizar el termino entidad ya que la clase de OO modela además de datos comportamiento. La descripción de las entidades se realiza a través de sus atributos. Así, una Persona tiene un Nombre, un DNI, una altura...., un Coche tiene un color, un motor, un fabricante.... Los atributos de una entidad se representan por un tipo de dato. Por ejemplo, la altura de una persona es un real, su edad un entero, su nombre un string.... Los atributos de una entidad toman un valor del domino o rango de valores que caracterizan al tipo.


En la inmensa mayoría de los casos, los atributos no pueden tomar cualquiera de los valores del dominio de su tipo, sino que los valores posibles están limitados y acotados por restricciones; así, la altura de una persona su puede ser cuatro metros ni la edad mayor que 140 años, al menos que usted lector no sea un extraterrestre. Si es usted un vulcaniano como el Sr. Spoc esta restricción deberá ampliarse. Es fácil, pues, derivar que las restricciones dependen en muchos casos del modelo que se está representando con la entidad. Una instancia en el modelo OO o una fila en el modelo relacional de una entidad es combinación de valores de sus atributos que cumplen las restricciones (valores válidos). Usaré el término instancia. Entre las entidades se establecen relaciones. Así, una instancia de la entidad Factura es de una instancia de la entidad Cliente. La relación se establece entre instancias de la entidad a través de atributos comunes; en el ejemplo anterior el código de cliente. Existen dos tipos de relaciones, estáticas y dinámicas. Así la relación “pertenece a” que se establece entre Persona y Raza es estática ya que es “indisoluble”. De otra parte, la relación “pareja” que se establece entre dos miembros de la entidad Persona es dinámica ya que puede cambiar sin afectar a la naturaleza de las instancias afectadas. La diferenciación entre ambos tipos de relaciones no es sencilla y en algunos atributos puede ser ambigua. Así la relación entre una factura y su cliente, es ¿estática o dinámica? Más adelante se establecerá una clasificación de las relaciones en especialización o herencia, agrupación y asociación. El conjunto de entidades, atributos, restricciones y relaciones forman el Modelo de Datos que modela la realidad que se está analizando.

3. El Modelo Relacional. El modelo relacional de BD fue propuesto por Codd a finales de los 70 y desarrollado ampliamente a lo largo de los 80. Es un modelo de organización de datos estructurado según un modelo matemático (Álgebra Relacional) que establece una separación y una relación entre los modelos lógicos y físicos. Se basa en un concepto muy simple: la tabla. Un gestor de base de datos (DBMS) relacional (SGBDR o RDBMS) es un gestor de estas tablas basado en tres componentes:

Los datos representados en las tablas. Operadores para manipular las tablas. Reglas de integridad entre las tablas.

La BD Relacional es una colección de tablas que representan entidades. Las tablas tienen un número de columnas que se corresponden con los atributos de la


entidad. Las filas de las tablas se denominan tuplas y se corresponden con registros. Un valor se almacena en la intersección de una fila con una columna y corresponde al valor de un atributo. Cada tabla tiene una clave principal y cero o varias claves secundarias. Cada clave está formada por uno o más atributos. La clave principal se utiliza para mantenimiento y las claves secundarias para mejorar los tiempos de acceso. Una vez diseñadas las tablas quedan definidas unas relaciones entre las entidades. Estas relaciones se representan por medio de un esquema gráfico que se conoce como Diagrama Entidad-Relación (E-R). Cada cuadro del diagrama representa una relación y cada línea una clave foránea que no es más que una relación establecida entre dos entidades por uno o más atributos comunes. En la figura se muestra un ejemplo de un diagrama E-R Cada relación de la base de datos equivale aun verbo. Por ejemplo, trabaja en. Las tablas pueden relacionar entre sí de tres formas:

Uno a Uno. Uno a muchos. Muchos a Muchos.

Las formas normales son reglas para prevenir redundancia, que dificulta el mantenimiento, en la organización de las tablas. Hay múltiples niveles de formas normales, cada una un paso más restrictivo del anterior. Consulte documentación especializada si desea más información. Pero recuerde: cuanto más profundo baje, más problemas de rendimiento encontrará. Busque el punto de equilibrio.

4. ANSI/SPARC three schema architecture.

Es una arquitectura estándar de tres niveles propuesta por ANSI/SPARC, un comité de DBMS. La idea básica es que es diseño de la BD se estructura a tres niveles:

Empleado

Oficina

Trabaja en

Perfil

Experto en Experiencia

Departamento

Ligado a

Jefe

1

M

M

M

1 1

1

M

Figura 115. Ejemplo de Modelo Relacional


4. 1. Esquema externo (External Schema). Es la visión de la aplicación. Esta formada por abstracciones del esquema conceptual. Permite que las aplicaciones sean independientes a los cambios del esquema conceptual.

4. 2. Esquema Conceptual (Conceptual Schema).

Es el nivel lógico, define la estructura de la información de forma genérica, desde la perspectiva del interés general.

4. 3. Esquema Interno (Internal Esquema). Es el nivel físico. Implementa el modelo conceptual según las reglas del DBMS escogido. Este nivel traduce el esquema conceptual a un código DBMS; en el modelo relacional SQL.

5. Restricciones de integridad.

Las restricciones de Integridad (constraints) son las definiciones de los estados legales de la base de datos. Dentro del mundo relacional y el SQL se incluyen: 5. 1. Entity Integrity Constraints.

Las restricciones de integridad de la entidad (Entity Integrity Constraints) aseguran que cada fila de la tabla es única. Se especifican estableciendo claves primarias que identifican de forma unívoca a cada fila.

5. 2. Validity Check Constraints. Las restricciones de integridad de valores válidos (Validity Check Constraints) limitan los valores que pueden aparecer en una columna además de los permitidos por tipo de la columna. Este tipo de restricciones de integridad proporciona opciones de “checking” dentro de los comandos de alta (INSERT) y modificación (UPDATE).

5. 3. SQL-92 domains and assertions. Estos dos tipos de restricciones de integridad fueron introducidos por la revisión del SQL realizada en 1992.

Esquema Conceptual

Esquema Externo 1

Esquema Externo N

Esquema Externo 2

Aplicación 1 Aplicación 2 Aplicación N

{Nivel de Esquema Externo

{Nivel de Esquema

Conceptual

{Nivel de Esquema Interno

EsquemaInterno 1

Esquema Interno M

Figura 116. Arquitectura ANSI/SPARC de tres niveles


Un dominio (domain) es una restricción adicional de los valores de los datos que pueden aparecer en una columna y que proporciona una forma más precisa de definir el tipo. Un dominio puede crearse, alterarse y eliminarse. Las aserciones (assertions) son un mecanismo que permiten asociar reglas de restricción entre las columnas mediante un lenguaje formal.

5. 4. Referencial Integrity. La integridad referencial (Referencial Integrity) asegura que les referencias cruzadas entre las tablas son siempre válidas. Les regles son especificadas dentro del comando CREATE TABLE mediante los dos conjuntos de claves relacionales, primarias y foráneas: las claves foráneas han de existir dentro de las claves primarias de las tablas referenciadas.

5. 5. Referencial triggered actions. Se conocen también como reglas de modificación o borrado y especifican como tratar filas que dependen entre sí cuando se borra o modifica una de esas filas relacionadas. Por cada clave foránea se pueden especificar una entre cuatro clases de este tipo de acciones:

NOACTION rule: no borrar o no modificar si hay una restricción de integridad.

SET NULL rule: las claves foráneas se colocan automáticamente a NULL.

CASCADE rule: se borran o modifican automáticamente todas las filas dependientes.

SET DEFAULT rule: todas les columnas relacionadas se poden al valor por defecto.

5. 6. Control de las restricciones de integridad en un sistema distribuido.

Las diferentes reacciones a los errores lógicos producidos por la vulneración de las relaciones de integridad producen acciones diferentes según el Middleware utilizado. La situación ideal sería que se produjera un retorno de error lógico que el programa pudiera interceptar siempre y tratar según su conveniencia. Pero, desgraciadamente, algunos de los productos de Middleware reaccionan “automáticamente” produciendo un error que aparece y necesita aceptación en el punto donde se ha producido el acceso a la BD que ha producido la violación. Si la lógica de datos está en el cliente, el único efecto será folklórico: aparece un mensaje indescifrable para el usuario, que después del susto, producirá una llamada al departamento de soporte la primera vez que aparezca. Eso si el usuario llama claro está. Le cuento una anécdota: un programa de entrada de datos creado por una persona de mi equipo producía un error en cada alta que no apareció en fase de pruebas. Un usuario se paso toda la


mañana entrando datos y “aceptando” un mensaje en inglés que el sistema presentaba tras cada alta para avisarle que el alta no se había llegado a producir por la violación de una restricción de integridad. Durante la comida, y comentándolo con un compañero más experto, el usuario descubrió que había perdido la mañana. Y eso en el mejor de los casos. Si usted es un buen diseñador y encapsula en servidores su lógica de datos compleja puede localizar el servidor en una máquina diferente a la que opera su usuario. El servidor se parará esperando un aceptar de un usuario que no está delante y colapsará todas las peticiones del resto de programas cliente. Por favor, vigile meticulosamente las respuestas del su Middleware a las violaciones de las restricciones de integridad. Para saber que tipo de control tiene debe conocer si su base de datos es activa o pasiva. Y en caso de ser activa (hoy día todas lo son) si su diseño ha sido “activo” o “pasivo”; es este segundo caso, a efectos prácticos es evidente que la base de datos se ha de tratar como pasiva. Y siempre existe una posibilidad: no delegar a la BD la comprobación de las restricciones de integridad y verificarlas como parte de la lógica de datos de la aplicación.

6. Bases de datos activas y pasivas.

Las bases de datos pasivas son aquellas en que las respuestas a las operaciones son siempre, y solo, los resultados o las condiciones de errores, lógicos y físicos, detectados y producidos. Ello obliga a que todos los programas verifiquen las condiciones de integridad. Este hecho hace fundamental un diseño cuidadoso que encapsule totalmente en

piezas esas verificaciones. Si las piezas se linkan con los clientes las aplicaciones resultantes tenderán a ser fat client en datos. Si se montan en servidores de lógica de datos, las serán más fat server. La primera solución es la escogida en aplicaciones de desarrollo rápido, mientras que la segunda en la solución adoptada en las aplicaciones avanzadas. Haga lo que haga, por favor, encapsule en piezas para garantizar un tratamiento único y fácilmente accesible. Observe que en este caso, como la base de datos informa de todo en los resultados, los programas, clientes o servidores, tienen control total de la situación a cambio, eso sí, de mayor trabajo y menor tiempo de respuesta. Las bases de datos activas incorporan mecanismos de triggers, eventos, reglas, etc., que permiten que la propia base de datos asuma funciones de control de restricciones de integridad, reglas, etc. El diseño del esquema incorpora estros mecanismos que se ocultan al programa facilitando la programación, centralizando parte de la lógica de datos y mejorando los tiempos de respuesta.

Schema

ResultsOperationsDBMS

Figura 117. Bases de datos pasivas


Sin embargo, el inconveniente es que todos estos mecanismos están ligados al motor y dejan las aplicaciones distribuidas en lugar de distribuibles. Y eso es, hoy día, un inconveniente no despreciable ya que inutiliza una de las grandes ventajas de de los servidores de base de datos actuales: la posibilidad de cambiar el motor.

En la figura tiene un esquema del funcionamiento de las bases de datos activas, en que el lanzamiento de operaciones puede generan además de resultados triggers que disparan eventos que se tratan internamente a la base de datos y oculto de los programas. Trataremos a continuación algunos de los mecanismos que incorporan las bases de datos activas y comentaremos su impacto en los diseños distribuidos.

7. Triggers.

Los triggers son, en general, reacciones del sistema delante de una determinada situación. En los servidores de base de datos, los triggers son mecanismos que invocan acciones definidas por el usuario cuando en el servidor se produce un evento. El mecanismo de trigger de un evento que dispara una acción ya sido ampliamente popularizado por las interfícies gráficas, aunque se primera aplicación masiva se produjo en el mundo de las bases de datos. La reacción de un evento disparado por un trigger es recomendable, tanto en BD como en GUI’s, que sea un mecanismo ECA (Event-Condition-Action) del que se hable en otra parte de este libro. Los triggers en una base de datos se clasifican según su propósito: 7. 1. Control de Acceso.

Monitorización de acceso a datos. Detección de accesos no autorizados a datos protegidos. Inicio de acciones que producen violaciones de seguridad.

Schema

ResultsOperations

DBMS

facts ECA-rules

ActionsEvents

ECA-rules

Figura 118. Bases de datos activas

Acciones Externas

INSERT

UPDATE

DELETE

Base de datos

Errores

Even

tos

Trigger

ProcedimentoProcedimento

catalogadoReglaGestor de error

GestoresEventos

Figura 119. Mecanismo de trigger


7. 2. Control de Integridad.

Comprobación de las restricciones de integridad y disparo de las acciones de restauración.

Verificación de las restricciones de integridad entre bases de datos heterogéneas, de gran interés en los entornos distribuidos donde se han producido Upsizing.

7. 3. Soporte de datos.

Propagación de modificaciones sobre datos derivados. Actualizaciones inmediatas, periódicas o producidas por un acontecimiento.

7. 4. Notificación de cambios y transiciones de la BD.

Reconocimiento de condiciones complejas sobre estados de las bases de datos

Identificación de transiciones entre estados y lanzamiento de acciones asociadas.

7. 5. Medidas de rendimiento.

Control y traza de eventos. Estadísticas para posteriores optimizaciones. Inicio de técnicas de balance de la carga.

7. 6. Reglas.

Una regla es un tipo especial de trigger que se utiliza para realizar checking’s de datos. Pueden realizar muchas acciones complejas mediante la potencia de un lenguaje procedural ligado a la base da datos.

7. 7. Gestión de triggers de la BD en entornos distribuidos. Para que los diseños sean limpios, los triggers de las bases de datos activas deben gestionarse dentro del mismo esquema de la base de datos. El recurso generalmente utilizado son los procedimientos catalogados. Al elemento, cliente o servidor, que ha iniciando el tratamiento de la BD, y a través de la transacción, debe devolver un error lógico con suficiente contenido semántico para que sea capaz de gestionar ese error convenientemente.

8. Vistas. Una vista es una abstracción simplificadora de una parte del esquema conceptual. Recoge un aspecto simple de la estructura de base de datos eliminando todo aquello que no es importante o no se quiere mostrar desde el punto de vista que se está mirando en ese momento la base de datos. Una vista en el modelo relacional es una tabla virtual que se monta dinámicamente cuando se abre.


La utilidad de las vistas es muy amplia:

Definir visiones simplificadoras de la BD que la acerquen a la visión que se necesita en cada momento.

Eliminar las desventajas de la evolución manteniendo, a efectos de gestión, el esquema anterior.

Una forma de implementación de esquemas externos.

Establecer mecanismos de autorizaciones. En particular, pueden dar acceso a atributos a usuarios que no tienen permisos de lectura a la tabla.

Integración de esquemas de datos distribuidos.

Esta última utilidad sólo puede aplicarse sí:

Las dos bases de datos son relacionales. Las tablas están repartidas entre los esquemas, y obviamente sola hay una de cada entidad en el total de esquemas.

La vista define el esquema común. Como opción adicional puede encapsularse el acceso a la vista en una pieza. En todo caso, recuerde, la vista sólo debe utilizarse para consultar, no para modificar.

9. ODBC/JDBC y ADO. Ya presentamos ODBC y ADO anteriormente. Y hemos hablado ampliamente de su importancia en muchos otros puntos. No voy a hablar mucho más. A efectos de programación ODBC y ADO no son ni más ni menos que una puerta SQL estándar e independiente del motor que permite un acceso unificado y homogéneo.

10. Procedimientos catalogados. Dentro de un modelo relacional no puede faltar este punto. Pero, ¿no le parece que ya hemos hablado suficiente de él y de su importancia?

ConceptualSchema 1

Internal squema 1

ConceptualSchema N

Internal squema N

Vista

Aplicación

Figura 120. Vistas e Integración de

BD's


Método de Análisis Funcional para Aplicaciones de Desarrollo Rápido.

1. Introducción. Con los elementos funcionales y de descripción de datos expuestos en los capítulos anteriores estamos ya en condiciones de establecer el método de análisis funcional que le propongo aplicar a las aplicaciones de desarrollo rápido y a los ejemplos de este libro. Sólo una salvedad. El modelo de datos puede establecerse según el modelo relacional, ya presentado, o según un modelo de objetos que le presentaré en el capítulo siguiente al hablar del análisis de aplicaciones avanzadas. Si no lo conoce, creo que es mejor que lea primero este capítulo y ya lo visitará en el siguiente.

2. Método de Análisis Funcional de Desarrollo Rápido de Aplicaciones (MAFDRA).

MAFDRA está basado en el análisis del flujo de la información. Toma como base los diagramas de flujo ampliados y como metodología análisis descendente. Desde la especificación, MAFDRA propone cinco etapas con pasos a cumplir en cada etapa: 2. 1. Diseño de los datos.

1. Identificación de las entidades. 2. Identificación de los atributos de esas entidades. 3. Identificar las claves primarias y secundarias. 4. Asignación de tipos a esos atributos. 5. Establecer los criterios de codificación. 6. Creación del Diccionario de Conceptos con la explicación de los atributos (sí

la necesitan). Más adelante, y durante el desarrollo de los procesos se irán incorporando todos aquellos que vayan surgiendo cono conceptos derivados, conceptos de operación, etc. La idea es incorporar de forma centralizada y unificada todo aquello que sea necesario precisar.

7. Identificación de las restricciones de integridad. 8. Identificación de las relaciones entre las entidades y con ello las claves

foráneas. 9. Diseño del modelo de datos mediante:

9.1. Modelo Relacional. 9.2. Modelo de Objetos OO. Si se escoge este segundo método habrá que

mapear el modelo de objetos al modelo relacional.

2. 2. Identificación de los procesos básicos.

1. Se identifican sobre la especificación los procesos lógicos básicos. 2. Estos procesos básicos se organizan por unidades lógicas. 3. Se crea un diagrama jerárquico con un primer nivel formado por las unidades

lógicas y un segundo por los procesos básicos que integran. Si el árbol


resultante es muy ancho o profundo utilice la técnica de desarrollar hojas en diagramas jerárquicos independientes.

4. Las funciones de cada unidad lógica se explican en una Descripción Funcional de la Aplicación.

5. Todo ello se puede organizar en un documento con una estructura del tipo: 5.1. Introducción: ámbito, especificación, objetivos básicos de la aplicación,

bibliografía, justificación, etc. 5.2. Diccionario de Conceptos. 5.3. Descripción funcional: unidades lógicas, procesos identificados, visión

funcional conjunta, operativas de explotación y, en general, cualquier otra funcional adicional de interés para explicar y entender el funcional.

5.4. Codificación. 5.5. Descripción de los datos. 5.6. Volúmenes y condicionamientos tecnológicos, si los hay: tiempos

máximos de respuesta, infraestructura, etc. 5.7. Un capitulo por cada unidad lógica que incluye descripción de sus

procesos. Incluye el diseño de la lógica de presentación, listados e integración de los procesos cliente.

Los puntos 1 a 3 es documentación compartida con el usuario y, por esa razón, debe estar redactada en términos que una persona no informática pueda entender. El resto de puntos es información técnica.

2. 3. Diseño de los procesos. 1. Asimilar cada proceso básico a un único proceso de transformación en que

cada una de las entradas y salidas del sistema se asimila a un parámetro. Con ello se dibuja el primer diagrama de flujo.

2. Se aplica análisis descendente a este proceso de transformación básico descomponiéndolo en dos o más procesos. Las entradas y salidas de proceso inicial se distribuyen entre los nuevos procesos obtenidos. Se marca la secuencia de ejecución con los recursos de los diagramas de flujo extendidos.

3. Se incorporan al diagrama de flujos resultante los parámetros intermedios necesarios para interconectar los procesos de transformación resultantes.

4. El proceso se repite hasta que se obtienen: • Procesos de transformación ya diseñados. • Acceso directo a datos. • Procesos que usen de forma directa primitivas sin aportar lógica

adicional. • Procesos de presentación o de listado.

2. 4. Diseño de la lógica de presentación.

1. La lógica de presentación se incorpora en GUI’s. Más adelante encontrará un

capítulo sobre este tema. 2. Se propone el formato de los listados.

2. 5. Organización de la explotación.

Se integran en el diagrama jerárquico inicial los puntos de entrada directos, si los hay, de los procesos de transformación obtenidos por descomposición.


3. Desarrollo de un ejemplo. 3. 1. Reflexión previa.

Este no es un libro de análisis. Los análisis funcionales utilizados no serán completos, sólo incluirán aquello necesario para preparar los ejemplos utilizados para implementar el diseño distribuido. Si usted desea practicar completamente los métodos funcionales, extienda lo aquí expuesto empezando por completar la especificación inicial y desde ahí desarrollar el funcional completo.

3. 2. Especificación inicial. Se ha de crear un sistema de venta de viajes aéreos conjuntamente con pernoctaciones en hoteles si el cliente lo necesita. El sistema se gestionará mediante una red de delegaciones de venta. Cada delegación es una tienda u oficina de atención al público. La tienda ha de atender a los clientes, venderles sobre catálogo los vuelos y las plazas de hotel libres y hacer las correspondientes reservas. Los clientes trabajan habitualmente con una de las tiendas, pero el sistema ha de permitir que los clientes puedan comprar en cualquiera de las tiendas. Es necesario tener estadísticas de venta por cliente y por vuelos, no por hoteles. Estas estadísticas se utilizan solo en la central. El proceso de venda debe proporcionar al cliente un albarán de reserva de la contratación realizada. El cobro se realiza por domiciliación bancaria mediante una factura mensual que agrupa todos los albaranes de ese mes. La facturación se realiza un sistema de facturación centralizado ya diseñado. El sistema a crear debe realizar una interfase con el sistema de facturación ya creado. Cada cliente tiene un crédito asignado que se gestiona en la central. El algoritmo de asignación de crédito a nuevos clientes esta encapsulado en una pieza ya creada y que se puede reutilizar. Dada la solvencia de muchos de los clientes, no es necesario verificar su crédito antes de venderles. Los clientes trabajan habitualmente con una sola oficina, pero el sistema debe quedar abierto para que los clientes puedan contratar desde cualquier oficina de la red. Las compañías aéreas disponen de un servicio RPC remoto para pedir reservas de vuelos. Este servicio reserva las plazas pedidas o devuelve aviso de que no están disponibles. Las consultas sobre los vuelos se realizan a través de la WEB de cada compañía. La consulta de disponibilidad de hoteles y la reserva de habitaciones se realiza a través de un servicio centralizado para toda la organización donde se autorizan los hoteles con que se puede trabajar.


3. 3. Diseño de datos. De la especificación se identifican las siguientes entidades:

Clientes. Cuentas analíticas de clientes. Movimientos de cuentas analíticas de clientes. Compañías aéreas. Vuelos. Hoteles. Plazas de hoteles

Las entidades Cuentas Analíticas y Movimientos de Cuentas Analíticas implementan la entidad lógica de Cuentas de Clientes, las entidades Compañías Aéreas y Vuelos implementan la entidad Datos Compañía Aérea y las entidades hoteles y plazas de hoteles implementan la entidad Datos Hoteles. Estas entidades presentan los siguientes atributos de los tipos y formatos que se muestran en las siguientes fichas: Clientes Atributo Tipo Formato Observaciones DNI String 14 Nombre String 50 Dirección String 4x40 La dirección no tiene estructura

prefijada Grupo Contable String 6 Clave foránea. Ver Diccionario de

Conceptos Cuenta Contable String 10 Clave Foránea. Etc.

Cuentas Analíticas de Clientes Atributo Tipo Formato Observaciones Grupo Contable String 6 Ver Diccionario de Conceptos Cuenta Contable String 10 Descripción String 50 Grupo de Balance

String 1 Ver Diccionario de Conceptos

Crédito asignado Número 10,2 Etc.

Movimientos de Cuentas Analíticas de Clientes Atributo Tipo Formato Observaciones Grupo Contable String 6 Ver Diccionario de Conceptos Cuenta Contable String 10 Fecha de la anotación

Fecha 8

Concepto String 30 Importe Real 10,2 Etc.

Compañías Aéreas


Atributo Tipo Formato Observaciones Compañía String 4 Nombre String 50 Numero para pedir reservas

Véase diccionario de conceptos

Etc. Vuelos Atributo Tipo Formato Observaciones Compañía String 4 Clave foránea Número Vuelo String 4 Etc.

Hoteles Atributo Tipo Formato Observaciones Hotel String 20 Nombre String 50 Etc.

Plazas de hotel Atributo Tipo Formato Observaciones Hotel String 20 Clave foránea Día Fecha 8 Numero de habitaciones

Small Integer

5

Habitaciones reservadas

Small Integer

5

Etc. Restricciones de Integridad. Se deberían identificar en este punto las restricciones de integridad. Dado el carácter docente de este ejemplo, dejo este trabajo para el lector. Relaciones. Se identifican las relaciones:

Corresponde a: los clientes se asocian a una cuenta analítica a través de las claves foráneas grupo y cuenta contable.

Es movimiento de: los movimientos de ventas y cobros se relacionan con las cuentas analíticas a través de las claves foráneas grupo y cuenta contable.

Servido por: Los Vuelos se asocian a Compañías a través de la clave foránea.

Habitación de: Las habitaciones se asocian a Hoteles a través de la clave foránea.

Viaje Comprado por: Los vuelos se relacionan con los clientes que los han contratado mediante una relación con atributos implementada en una tabla:

Vuelos por Cliente


Atributo Tipo Formato Observaciones Cliente String 14 Clave foránea Compañía String 4 Clave foránea Vuelo String 4 Clave foránea Fecha del vuelo Fecha 8 Número de plazas vendidas

Small Integer

3

Etc. Esta tabla tiene como claves primarias cliente, compañía y vuelo. Necesitará unas claves secundarias por compañía, vuelo y cliente para gestionar una de las estadísticas pedidas. Codificación.

La clave primaria del cliente es su DNI. La clave primaria de cada compañía área es su pre-código de vuelos. La clave primaria de vuelos en una clave doble formada por el código de la compañía y el número del vuelo dentro de la compañía.

Los hoteles se referencian secuencialmente. La clave primaria de habitaciones es una clave doble formada por el código del hotel el día.

La fecha se codifican en formato String: AAAAMMDD donde AAAA es el año, MM es el mes y DD es el día. La ventaja de codificar por String es que se consigue independencia del motor de la base de datos. Recuerde que el formato de las fechas es una de los puntos de heterogeneidad más habituales, y escondidos, entre los diferentes motores de bases de datos relacionales. Si se decide este formato para la fecha, deberá crear una pieza con las rutinas más habituales de gestión de fecha: verificación, comparación, días entre dos fechas, obtención de forma separada del año, mes y día de forma, etc.

Un formato de número 10,2 indica 10 cifras de las cuales 2 son decimales.

Conviene matizar la precisión de los enteros entre Small y Long. Diccionario de Conceptos: Concepto Descripción Cuenta Contable Véase la descripción del concepto Grupo Contable Grupo Contable La cuenta contable asociada a cada cliente se

relaciona por el grupo contable al que pertenecen los clientes (por ejemplo, 4300) y la cuenta contable dentro del grupo

Grupo de Balance Partida del balance de explotación donde se acumula el saldo de la cuenta.

Número de reservas Número telefónico proporcionado por cada Compañía aérea para pedir el servicio RPC de reserva de plazas en sus vuelos.


Con todo ello ya estamos en condiciones de proponer un modelo de datos que reflejaremos en el esquema relacional de la figura.

3. 4. Identificación de los procesos básicos.

En la especificación se identifican tres procesos lógicos básicos agrupados en dos unidades lógicas, Proceso de Ventas y Estadísticas. En el diagrama jerárquico de la figura se muestra la primera organización de procesos. El mantenimiento de los ficheros básicos se realiza a través de programas de mantenimiento interactivo con presentación GUI. El diseño de estos procesos

se realiza directamente dentro del apartado de componente de

presentación proponiendo un Framework que se personaliza para cada uno de los ficheros básicos.

El diseño de los procesos de Ventas y Estadísticas se desarrolla a continuación.

3. 5. Diseño del Proceso de Venta de Viajes Aéreos y Hotel.

Cliente

CuentaAnalítica

Vuelos

ViajesComprados

por

Vuelos por

Cliente

1

M

1

N

Corresponde a

AnotacionesCuenta

Analítica

1

MEs movimiento de Compañía

Servido por

M 1

PlazasHotel Hoteles

Habitación de

M 1

Figura 121. Modelo de datos.

Venta de Vuelos en Delegaciones

Proceso de Ventas Estadísticas

Obtención Estadísticas

Mantenimiento de ficheros básicos

Venta Viaje Aéreo y Hotel

Figura 122. Diagrama Jerárquico inicial de unidades y

procesos lógicos


El proceso se asimila inicialmente al proceso de transformación del diagrama de flujo de la figura. Las entradas y salidas esperadas de los procesos se distribuyen alrededor del proceso de transformación básico. Aplicando de forma reiterada análisis descendente en el primer refinamiento el proceso básico inicial se descompone en otros cuatro:

Registro de la Petición del Cliente.

Actualización de Datos en la compañía aérea. e internos.

Impresión de la Reserva del cliente.

Consulta datos de vuelos.

Para enlazar internamente los tres primeros aparece un almacén interno para registrar la petición del cliente. Distribuyendo las entradas y salidas del proceso de transformación inicial en este primer refinamiento se obtiene el diagrama de flujo secuencial izado de la figura. El proceso de Consulta de Datos de Vuelos se resolverá por el acceso a las Web’s de las Compañías Refinando seguidamente el proceso de Entrada de la Petición se obtiene el diagrama de flujo la figura en el cual se identifican los procesos Pedir al Cliente su identificación, Acceder a los Datos del Cliente, Registro de los Datos del Cliente en la petición, Pedir el Viaje elegido, Consultar el Crédito del Cliente para verificar si tiene crédito para contratarlo, y en caso contrario, Avisar al Cliente que no se le puede hacer la venta. En caso de que el cliente no exista, se procederá a darlo de alto mediante el proceso de Alta de Cliente.

Cliente

VentaViaje Aéreo

y Hotel


Cuentas Clientes

Clientes

Vuelos por cliente

ReservaCliente

Crédito estándar

Datos Hotel

Figura 123. Proceso de Venta de Viaje Aéreo

Petición Cliente

ActualizaDatos


Clientes

EntradaPetición

Cliente

Clientes

Vuelos por Cliente

ReservaCliente

ImpresiónReserva

Crédito Estándar Datos Hotel

Consultadatos de vuelos

Figura 124. Primer proceso de refinamiento de Venta Viaje y Hotel a

Cliente


Cliente

Petición Cliente

RegistroDatos

ClientePeticiónCliente

AccesoDatos

Cliente

RegistroDatosViaje

ConsultaCuentaCliente

Cuenta Clientes

RechazarVenta

AltaCliente

Cliente

Re-intentar

Crédito Estándar

No créditoSin hotel

Figura 125. Refinamiento de Entrada de la Petición

Una opción alternativa sería aprovechar la propia GUI para implementar la entidad Petición Cliente. La entrada para Reintentar se tratará más adelante y la salida de “sin hotel” se obtiene del refinamiento del proceso Registro de los datos del Viaje del cual se habla a continuación. Si refinamos el proceso de Registro de Datos del Viaje tendremos el diagrama siguiente donde se ha previsto la posibilidad de que los hoteles estén completos. En este caso se preguntará al cliente y si no necesita forzosamente la habitación se aceptará únicamente el vuelo y en caso contrario se rechazará la venta. La entidad “Sin hotel” permitirá la salida sin cerrar la venta. Se marcará en la petición de cliente el hecho de que la operación es sin hotel.

Vendedor

Petición Cliente

RegistrarDatosVuelo Registro

DatosHotelDatos Compañía Aérea

ConsultarDatos deVuelos

ConsultarDatos

Hoteles

Datos Hotel

Sin hotel

No hay habitaciones

Cliente

Aviso alCliente

Acabar

Necesita Hotel

No Necesita Hotel

Figura 126. Refinamiento de Registro Datos del Viaje


Todos los procesos de entrada de petición pueden considerarse ya primitivas ya que usarán operaciones simples y bien definidas. Todas excepto el proceso de Alta de Clientes, que vamos a diseñar a continuación. Si aislamos este proceso, obtendremos el proceso de transformación de la

parte superior de la figura. Aplicando análisis descendente, el proceso de alta puede dividirse en tres: Petición de los Datos al cliente, Incorporar los datos al fichero de Clientes y Asignar el Crédito para generar la Cuenta Analítica del Cliente. Recuerde que

este proceso esta encapsulado en una pieza que se puede usar como una primitiva del sistema. Los otros tres pueden considerarse también primitivas a efectos de la metodología. Diseñemos, finalmente, el proceso de Actualizar Datos. Aplicando análisis descendente se obtienen, en principio los procesos: Actualizar Compañía Aérea, para reservar las plazas en el vuelo elegido, Actualizar los datos del Hotel con la reserva de la habitación, Anotación en la Cuenta del Cliente, para iniciar el proceso de cobro y aumentar el riesgo, y Anotación del Vuelo por Cliente. Cuando se analizan las salidas del proceso de reserva del vuelo se identifican dos salidas posibles: que el vuelo tenga plazas libres o que no las tenga. En el segundo caso, aparecen dos procesos adicionales para Avisar al Cliente y para Anular la Venta de ese vuelo, y una salida del diagrama de flujo hacia la

PedirDatos

ClienteCliente

Cliente

Cuenta Cliente

Incorporara Clientes

AsignarCrédito

Crédito Estándar

AltaCliente

ClienteCliente

Cuenta ClienteCrédito Estándar

Figura 127. Proceso de Alta de Clientes

Petición Cliente

Actualizareservac.aérea


Datos Hotel

Actualizadatoshotel

Vuelos por Cliente

Anotacióndel vuelo por

Cliente

Avisoal

Cliente

AnularVenta

Re-intentar

Cliente

No hay plazas

Hay plazas


Cuenta Clientes

Figura 128. Proceso para Actualizar Datos.


petición de nuevo del vuelo al cliente. Esta salida se asimila a una entidad Re-intentar que conecta este diagrama de flujo con el de Petición de Datos. Se supone que no habrá problemas al confirmar la reserva del hotel para no montar un proceso similar y complicar el ejemplo docente sin valor añadido.

3. 6. Diseño del Proceso de Estadísticas. El diseño del proceso de Estadísticas puede representarse por el diagrama de flujo de la figura. La entidad Vuelos por Clientes generada a partir del proceso de Venta de Viajes Aéreos es la entrada principal de este proceso de estadísticas. Aparece como parámetro a proporcionar al proceso el periodo a listar. Aplicando análisis descendente al proceso básico de estadísticas se obtienen tres nuevos procesos: Entrada Periodo a Listar, Listado Ventas por Cliente y Listado Ventas por Vuelo que se representan en al diagrama de flujo secuencializado de la figura. Estos tres procesos podemos considerarlos ya primitivas en el contesto de MAFDRA.

3. 7. Diseño de los componentes de presentación.

A las pantallas GUI identificadas se asignarán un código y se diseñarán con la metodología de cada instalación. Aunque el diseño GUI no tiene nada a ver con el diseño distribuido, como la integración GUI es frecuente en el mundo distribuido dedicaremos un tiempo más adelante a presentar criterios y consejos.

3. 8. Diseño de los listados.

Estadísticas

Datos Compañía áreaClientes

Vuelos por cliente

Venta por Cliente

Periodo a Listar

Venta por Vuelo

Figura 129. Proceso de Estadísticas

EntradaPeriodo a

Listar

Datos Compañía áreaClientesVuelos por cliente

Venta por Cliente

Venta por Vuelo

Periodo a Listar

ListadoVentas por

Cliente ListadoVentas por

Vuelo

Figura 130. Refinamiento del Proceso de Estadísticas


Se realizarán mediante un esquema donde se relacione la cabecera, los totales de agrupación y la línea de detalle. No los desarrollaré aquí. Usted amigo lector, puede realizarlos se decide completar el ejercicio.

3. 9. Organización de la explotación. Finalmente, conviene añadir al diagrama jerárquico inicial el proceso básico de alta como de primer nivel y desglosar los procesos básicos en los obtenidos en el diseño de esos procesos básicos.



Obtención EstadísticasMantenimiento de ficheros básicos Alta de Clientes Venta Viaje Aéreo

Registro de la petición

Actualizaciones

Compañía Aérea

Hotel

Cuenta cliente

Venta por cliente

Venta por vueloDatos Vuelo

Datos Hotel

Vuelos por cliente

Figura 131. Diagrama jerárquico ampliado

@@EMG/10- Enric Martínez Gomàriz 203

Diseño Funcional de Aplicaciones Avanzadas – Introducción a la Orientación a

Objetos

1. Introducción.

El diseño funcional de las aplicaciones distribuidas avanzadas debe atacarse con metodologías OO. Lo creo firmemente. Aunque puede usarse cualquier otra metodología funcional completa, la íntima relación entre distribución y OO de la que ya hemos hablado anteriormente, hace que esa solución sea, a mi juicio, la mejor con diferencia. Y evidentemente, la amplitud de una metodología OO basada en UML queda fuera del abasto de este libro. De cualquier forma, voy a introducir a continuación, cuatro ideas sobre una metodología OO con dos finalidades:

Presentar el Modelo de Objetos, que como ya he dicho, es un método muy eficiente para describir los modelos de datos.

Presentar los conceptos mínimos para programar en OO aunque el diseño sea convencional.

En todo lo que seguirá a este capitulo partiré de la base de la base de que usted lector está familiarizado con los conceptos básicos de OO (clase, instancia, herencia, polimorfismo, etc.) y los del modelo conceptual de datos. Para eso es este capítulo. Si necesita información adicional consulte bibliografía apropiada. Si conoce estos conceptos, sálteselo. Los dos capítulos siguientes al que está empezando a leer están dedicados también a orientación a objetos. El capítulo siguiente esta dedicado al maqueo de un modelo de objetos conceptual sobre un gestor de base de datos relacional. El segundo capitulo estará dedicado a la integración de la metodología distribuida que voy a proponerle con especificación y diseño de sistemas modelados por orientación a objetos en UML (Unified Modeling Language). Dada la extensión de UML, no creo que este libro sea el lugar apropiado para presentarlo. Partiré de la base de que Vd. también está familiarizado con los conceptos de UML (casos de uso, diagramas de secuencia, modelos conceptuales de datos, diagramas de clases, diagramas de despliegue, etc.). Si no es así, le ruego que consulte documentación sobre UML antes de seguir. O que salte el capítulo siguiente y atáquelo cuando tenga tiempo de documentarse OO.

2. Conceptos básicos.


2. 1. Introducción del Concepto OO. En su forma más intuitiva, un objeto consiste en coger los dos componentes básicos de un sistema de información, datos y procesos, reducir el énfasis en los procesos y fortalecer el encapsulamiento en un módulo autónomo de datos y funciones juntos, añadiendo una especificación clara y precisa de la interfície. El sistema pasa a describirse como una integración y una interacción entre estos objetos. El análisis y el diseño de alto nivel se realizan en dos fases: 1. Identificación de los objetos. 2. Análisis de como interactúan los objetos entre si mediante mensajes que

piden a los objetos que ejecuten un procedimiento o informen de su estado. El análisis y el diseño se retardan dentro del ciclo de vida y los detallen de la implementación se esconden.

Para el desarrollo del sistema informático el paradigma orientado a objetos se base en la construcción de un modelo informático del sistema real de donde se extrae la información que interesa. Por el contrario, el enfoque clásico parte del concepto de crear un sistema para obtener una información concreta. Este enfoque clásico es menos general y con menor adaptabilidad a los cambios y ampliaciones que el OO. El desarrollo OO es basa, pues, en el acoplamiento de objetos prefabricados integrados para resolver una necesidad funcional. OO lleva implícita una altísima reusabilidad.

2. 2. Terminología básica. Desgraciadamente no hay una terminología básica unificada y consolidada. Sin embargo los términos más generalmente utilizados son:

Clase: encapsulación de datos y procedimientos. Instancia: ocurrencia de una clase. Así, una clase persona tiene instancia para cada persona representada en el sistema.

Objeto: Instancia de una clase. Luís y Enric son objetos de la clase persona. Instancia y objeto son, de hecho, términos equivalentes.

Atributo: dato interno de una clase. Servicio o método: procedimiento (función o acción) accesible de un objeto.

Estado: situación de una instancia o objeto determinada por una combinación de todos o parte de sus atributos.

Evento: notificación de un cambio de estado. Mensaje: forma de comunicación entre dos objetos para pedir la ejecución de algún servicio o método. El mensaje esta formado por parámetros y esta ligado a la llamada a un método o por el disparo de algún evento.

Figura 132. Concepto de Objeto


2. 3. El triángulo orientado a objetos.

Técnicamente OO se basa en tres bases representadas por el triángulo de la figura.

2.3.1. Encapsulación. A estas alturas ya conocemos perfectamente el concepto de encapsulación. En OO hace referencia a agrupar en un objeto datos y proceso. La encapsulación por si misma no garantiza la ocultación de la información. Es necesario un mecanismo de private para garantizar que la información queda realmente escondida en el interior del objeto. En los lenguajes OO es obligatorio aplicar estos conceptos por la propia sintaxis.

2.3.2. Abstracción y clasificación. La modelización utiliza el concepto de TAD (tipo abstracto de datos) y la de tipos definidos por el usuario. La abstracción dentro del mundo OO es eso: pensar las clases de objetos como tipos de objetos y utilizarlos dentro de ese ámbito como si fuera cualquier otro tipo. La clasificación será la agrupación de ideas en clases de cosas que se podrán concretar en instancias y objetos, manipularlos y destruirlos. La abstracción de las clases no se hace solo con los conceptos de bajo nivel sino en conceptos de alto nivel como la gestión completa de un producto, una lista o un Framework de mantenimiento de archivos. La primera etapa será siempre la identificación y abstracción de las clases del modelo del mundo real que vamos a crear.

2.3.3. Polimorfismo a través de la herencia. Más adelante volveremos sobre este concepto que es una de las diferencias fundamentales entres clase y TAD.

2. 4. Clase de Objetos. Una clase de objetos (Object Class) describe un grupo de objetos con similares propiedades (atributos), un comportamiento común (operaciones o métodos), las mismas relaciones con otros objetos y una semántica común. Cada objeto conoce su clase ya que es una propiedad implícita a su instanciación. Esta propiedad es accesible desde los lenguajes OO. Si pensamos, por ejemplo, en una cola, vemos que es un concepto muy genérico y que una clase que la represente podría ser aplicable a muchos tipos de elementos organizados en colas.

Figura 133. El triángulo OO


Podríamos pensar en hacer una abstracción de una cola genérica, crear una clase genérica que modele el comportamiento de una cola y especializarla después en cada situación concreta en el momento de la instanciación mediante polimorfismo. Este es el concepto de clase genérica, contenedora o parametrizada. Una clase abstracta o diferida es aquella en la cual falta algún elemento, atributo o método, por definir y que por tanto no puede ser instanciable directamente. Hay diferentes razones para crear una clase abstracta. Dos de básicas son:

Crear una superclase para reflejar aquello que tienen de común dos clases.

Se quiere forzar que todas las subclases tengan atributos y/o métodos comunes.

Por ejemplo, si tenemos diferentes clientes, cada uno con una forma de cálculo del descuento, podemos crear una clase abstracta Cliente donde colocamos un servicio Descuento que definiremos más tarde en la subclase. En la figura se muestra un ejemplo de clase.

La notación y representación de clases se realiza mediante el cuadrado de la figura donde en la parte superior se representan los atributos, en medio se colocan los métodos y en la parte inferior los eventos. El comportamiento (behaviour) de un objeto queda determinado por las prestaciones de los métodos disponibles para tratarlo. Ya hemos hablado de que es una instancia (Instance) de una clase y de

la cierta ambigüedad del término objeto. Por esa razón se habla de Object Class y de Object Instance. En el ámbito de diagrama clase e instancia se representan como se muestra es la figura.

Clase Biclicleta:Atributos:

Medida del marcoTamaño de la ruedaCadenaMaterial

Métodos:Cambiar de marxaPedalearReparar

Instancias:La bicicleta de CarlosLa biclicleta de María

Abstracción

Figura 134. Representación de una clase bicicleta

Figura 135. Representación de una

Clase

Figura 136. Notación de Clase e Instancia


2. 5. Concepto de Herencia. La herencia (Inheritance) es una nueva idea introducida por OO que se corresponde a una analogía para software de la idea biológica: el hijo hereda las características (atributos y métodos) del padre mediante una relación jerárquica. Si usted compara clientes y proveedores verá que comparten gran cantidad de atributos y comportamiento: defina una clase analítica y especialice las clases cliente y proveedor por herencia. Las ventajas de la herencia son claras:

Reusabilidad. Adaptabilidad. Extensibilidad. Bajo coste de mantenimiento. Potencia semántica. Compartir código.

La herencia es un tipo de relación jerárquica que se representa con el icono de la figura. La herencia representada en la figura es la habitual, conocida también como herencia simple en la cual el hijo hereda de un solo padre. En la otra figura se representa la herencia múltiple en

que un hijo hereda de más de un padre. Este tipo de herencia no esta soportada en todos los lenguajes OO. La relación “is-a” es la que representa la relación de herencia. Si tenemos una clase podemos definir una nueva como una subclase que tendrá atributos adicionales y algunos servicios adicionales o redefinidos. No se permite, sin embargo, anular atributos o servicios, aunque si vaciar servicios de contenido.

2. 6. Polimorfismo.

El polimorfismo sale de la posibilidad de las clases de adaptar un método genérico a la semántica de su comportamiento. El primer, y básico, tipo de polimorfismo se obtiene ligado a la herencia de la posibilidad del hijo de modificarse, a partir de las características del padre a su propia necesidad. El polimorfismo por herencia se conseguirá:

Añadiendo todo aquello que le es propio y que no tenía el padre. Modificando, por redefinición, aquello que tiene alguna característica diferencial de lo heredado.

Nunca eliminado atributos del padre, actuación imposible en OO. Por ejemplo, en una jerarquía de productos, la clase producto tiene unos atributos que heredan dos clases, el producto de venta y la materia prima. La materia prima se adapta añadiendo el proveedor que la suministra.

Figura 137. Herencia

Figura 138. Herencia

múltiple.


Hay otro tipo de polimorfismo entre clases diferentes. Un método mover, puede adaptarse en una clase archivo secuencial a cambiar de directorio y en una clase listado a salir por una impresora. Un método mover aplicado a una clase coche se adapta al concepto de avanzar con él; en una clase pieza de ajedrez al hecho de desplazarse por el tablero. El método, aplicado a cada pieza tendrá un polimorfismo de herencia, que determinará para cada pieza su

forma de moverse en el tablero. La importancia de las posibilidades que abre el polimorfismo es, a mi juicio fundamental. La posibilidad de adaptar un método a las características de una clase es una herramienta tan potente que sólo se puede apreciar cuando se utiliza habitualmente. Permite compartir propiedades de forma genérica sin tener que hacer cambios importantes para conseguir adaptabilidad en cada subclase. Todo ello permite enviar mensajes a objetos sin necesidad de saber exactamente su tipo. En tiempos de compilación o de ejecución la llamada al método se resolverá según las características específicas del objeto instanciado. Y eso es una herramienta potentísima para la ampliación de programas con nuevas semánticas. En la clase producto que hemos hablado antes, si se introduce una especialización creando una subclase envase, todo lo programado hasta ese momento para la clase producto se puede utilizar para la clase envase con coste de programación cero. Veamos un ejemplo práctico y simple de utilización de polimorfismo. En el diagrama de objetos de la figura se muestra una jerarquía de herencia de una clase genérica Polígono. Aparte de los atributos, de los cuales y evidentemente sólo se ha representado una muestra simbólica, existen los métodos de la figura. Es evidente que, representando los vértices por una tabla de puntos, los métodos de crear, mover y dibujar pueden crearse de forma genérica en la clase polígono. Esto no pasa así en el método cálculo del área, que se poliforma para cada subclase. Para calcular el área en programación convencional deberíamos programar una secuencia alternativa del tipo: a: polígono IF a.tipo_polígono = ‘Triángulo’ THEN cálculo_del_área_triángulo() ELSIF a.tipo_polígono = ‘Rectángulo’ THEN cálculo_del_área_rectángulo() ELSIF a.tipo_polígono = ‘Pentágono’ THEN cálculo_del_área_pentágono() ENDIF En OO bastará hacer: a: polígono a = CREATE (Subclase polígono) a.cálculo_del_área()

Figura 139. Clase

mover.


Si ahora deseamos ampliar las subclases con otros polígonos, en programación clásica deberemos añadir una rama a la composición alternativa. En programación OO bastará con redefinir el método cálculo_del_área para el nuevo polígono. Si se extrapola este sencillo ejemplo a toda una programación, incluyendo los

Framework, se hace evidente la importancia del polimorfismo.

2. 7. Visibilidad de atributos y métodos. El concepto de visibilidad está ligado a la accesibilidad que la clase da a sus atributos y métodos. Un atributo o un método pueden ser:

2.7.1. Público. Visible desde el exterior o el interior de la clase.

2.7.2. Privado. Nada más puede consultarse o utilizarse desde dentro de la clase.

2.7.3. Protegido. Nada más puede consultarse o utilizarse desde dentro de la clase y desde sus subclases derivadas por herencia.

Existe una polémica abierta en el mundo OO. ¿Han de ser los atributos públicos? Hay autores que sostienen que no y otros que sí. Para poder formarse su opinión, si no es un experto OO, recuerde todos los atributos de una clase visual. Por ejemplo, uno de clásico es el visible, que suele ser una variable lógica que se coloca a cierto o falso según convenga a la lógica del programa. Este atributo suele tener dos métodos asociados Show() y Hide() que realizan la misma función. Observe que esta táctica el habitual en las clases comerciales y de hecho, es más habitual todavía que los atributos sean públicos y no tengan métodos para asignarles valores o leerlos. Los que defienden los atributos como públicos argumentan que las clases son más sencillas. Los que defienden la privacidad argumentan que permiten modificar los argumentos permite que los programadores externos puedan modificar comportamiento incluyendo valores y condiciones que vulneren las restricciones de integridad de la clase. Me declaro seguidor acérrimo de esta

PolígonoVerticesColor de aristasColor del fondoCrearCáculo del áreaMoverDibujar

Triángulo

Cálculo del área

Rectángulo

Cálculo del área

Pentágono

Cálculo del área

Figura 140. Jerarquía de una Clase Polígono


segunda corriente de opinión: los atributos han de ser siempre privados. Y, a mi juicio, las razones son tan obvias que no hace falta hablar más. Encapsular la modificación de un atributo en el método vacuna contra manipulaciones no válidas. Y como la opción de dejar un atributo público de lectura no existe... Si usted lector se decanta por esta opción deberá definir:

Un método público, normalmente una función, de lectura del atributo. Un método público, normalmente una acción, para verificar si un valor es correcto.

Un método público, normalmente una acción, para modificar el atributo y que internamente llamará al de verificación.

Mayor trabajo, pero mayor seguridad.

3. Los fundamentos de una metodología de diseño OO. El diseño OO es una forma de pensar software basada en hacer abstracciones de las cosas que existen en el entorno que se está diseñando. La esencia del diseño es la identificación y organización de los conceptos del dominio de la aplicación, no de los procesos que accidentalmente poden ejecutarse en un momento determinado. Vea la diferencia de enfoque. En no OO, primero se estudian los procesos y de aquí se deducen las entidades necesarias para realizarlos. En OO, primero se identifican las entidades de forma independiente, y después se diseñan los procesos. De hecho lo que modela la realidad en algo más que entidades: son los atributos y del modelo de comportamiento que proporcionan métodos y eventos. El énfasis es la abstracción de objetos y su estructura, no los procesos. El esfuerzo más importante se hace en las modelización de los conceptos, no en la implementación.

4. Etapas de una metodología de construcción de software OO en UML. 4. 1. Especificación.

La especificación construye un modelo del mundo real mostrando sus propiedades más importantes. El moldeo es una concisa y precisa abstracción de que queremos que el sistema contemple, no de como lo hará. La teoría puede hacer pensar que hay que modelar totalmente la realidad. Obviamente, la fase de análisis no comporta ninguna decisión de implementación. Por ejemplo, una clase persona es descrita en términos de sus atributos, de los métodos públicos que modelan su comportamiento y de los eventos; externos a los que puede reaccionar e internos que puede lanzar. Evidentemente los conceptos de ingeniería que obligan a considerar la relación prestaciones / coste lleva a que la modelización se haga en los términos que el entono a diseñar necesita no de la totalidad del modelo. Pero la gracia de analizar OO es que las ampliaciones del modelo, si más tarde se necesitan y


se ha trabajado bien, serán muy fáciles y, sobre todo, no traumáticas con lo ya implementado. En UML, durante la especificación todas las operaciones funcionales detectadas se asignan a una clase única denominada Sistema. Partiremos de la base de que esta etapa genera como mínimo:

El modelo conceptual de clases de especificación. Los casos de uso. Los diagramas de secuencia de las operaciones de sistema. Los diagramas de estado necesarios.

Y opcionalmente:

Diagramas de actividad. Diagramas de colaboración.

4. 2. Diseño del sistema.

El diseñador toma decisiones de alto nivel sobre la arquitectura. El sistema es organizado en subsistemas basándose en el análisis de la estructura y de la arquitectura propuesta. El diseñador ha de decidir:

Las características de las cuales ha de optimizar el rendimiento. Escoger una estrategia para atacar. Hacer una propuesta para la localización de los recursos.

Las operaciones de sistema de la especificación acaban asignándose a las clases. Partiremos de la base de que de esta etapa se obtiene como mínimo:

El modelo conceptual de clases de diseño. Los casos de uso concretos. Las interfícies GUI necesarias para implementar los casos de uso que interaccionen con el usuario.

Las operaciones asignadas a las clases y necesarias para implementar la funcionalidad de las operaciones de sistema detectadas a la especificación.

Los diagramas de estado completos. Los patrones arquitectónicos propuestos para desarrollar la arquitectura del sistema..

4. 3. Diseño de los objetos.

Construye un modelo de diseño basado en el modelo de análisis pero incluyendo detalles de implementación de los objetos detectados. Los objetos, representados por las clases, son especificados y descritos en términos de sistema operativo, hardware y resto de elementos de la plataforma.

4. 4. Implementación (Implementation).


Las clases de objetos y las relaciones detectadas a lo largo del análisis son trasladadas a un lenguaje de programación, base de datos y plataforma. A lo largo de la implementación es importante seguir buenas prácticas de ingeniería de software ya que debe conducir a una implementación flexible y, sobre todo, extensible.

5. Los tres modelos de la metodología OO. Una metodología OO se basa en describir la realidad mediante tres modelos:

Modelo de Objetos. Modelo Dinámico. Modelo Funcional.

Cada modelo es aplicable a todas las etapas del diseño y se hace más rico a medida que avanza. Una descripción completa del sistema necesita de los tres modelos. 5. 1. Modelo de Objetos.

Describe la estructura estática de los objetos en el sistema y sus relaciones. Se empieza identificando las clases, sus atributos, métodos y eventos básicos. A partir de aquí, se establecen las relaciones estáticas entre las clases. Existen tres tipos de relaciones.

Herencia. Agregación. Asociación.

El modelo de objetos contiene Diagramas de Objetos (Object Diagrams) que son grafos en los cuales los nodos son clases y los arcos relaciones entre ellas.

5. 2. El modelo dinámico. Describe las interacciones de los objetos en el sistema, los aspectos que cambian con el tiempo y la secuencia de operaciones que esos cambios producen. Se detectan y documentan:

Los estados por los que puede pasar la clase. Los eventos que marcan cambios de estado. La secuencia en que se producen esos eventos. La organización de eventos y estados.

El modelo dinámico se utiliza para especificar e implementar los aspectos de control del sistema.


El modelo dinámico contiene diagramas de estados. Un diagrama de estados es un grafo en el cual los nodos son estados y los arcos transiciones entre estados causados por eventos.

5. 3. El modelo funcional. El modelo funcional describe las transformaciones de los valores de los datos en el sistema. Contiene diagramas de secuencia que detallan como se implementa cada operación y que métodos necesita utilizar de otras clases. Estos diagramas son utilizados como base de la metodología de diseños distribuidos.

6. Las relaciones entre los tres modelos. Los tres modelos son ortogonales: cada uno describe una parte del sistema y ninguno de los tres son completamente independientes entre sí. Sin embargo, las relaciones entre ellos son limitadas, claras y explícitas. El modelo de objetos describe la estructura de los datos sobre la cual operan los modelos dinámico y funcional. El modelo dinámico describe la estructura de control de los objetos, muestra decisiones que dependen de los valores y que llaman a funciones. El modelo funcional describe funciones llamadas por operaciones en el modelo de objetos y por acciones del modelo dinámico. El modelo de objetos es fundamental porque es necesario para describir que ha de cambiar o transformarse antes de describir donde o como es el cambio o la transformación.

En los siguientes puntos vamos a presentar algo más de los tres modelos básicos, especialmente del modelo de objeto, que como ya hemos dicho anteriormente tiene mucha mayor potencia semántica que el modelo relacional y que puede ser utilizado como forma alternativa de descripción de datos.

7. Descripción del modelo de objetos. 7. 1. Plantilla de definición de Clases y Objetos.

Nombre y Descripción. Visibilidad. Instanciable: SI/NO. Estática, es decir, si solo hay una clase en el sistema: SI/NO. Genérica y lista de parámetros si lo es: SI/NO. Subsistema al cual pertenece la clase. Invariantes que ha de mantener y tratamiento si no se cumple. Estados. Cardinalidad o número de instancias simultáneas que puede haber en el sistema.

Persistencia: SI/NO. Restricciones de clase.


Observaciones de clase. Lista de los atributos. Por atributo:

Nombre, descripción y tipo. Visibilidad: Público, privado, protegido (sólo para las clases derivadas por herencia).

Rango de valores y restricciones. Observaciones de atributo.

7. 2. Diagramas de Clases y de Instancias.

Como ya hemos hablado el modelo de objetos se representa mediante Diagramas de Clases u Objetos. Proveen una notación formal gráfica para modelar objetos, clases y relaciones entre ellos. Un diagrama de clases es un esquema para describir muchas posibilidades

de instancias. Un diagrama de instancias describe un conjunto particular de objetos que se relacionan entre ellos. Son muy útiles para trabajar sobre casos concretos (escenarios). En el ámbito de análisis y diseño se utilizan, obviamente, los

Diagramas de Clases. Las relaciones entre las clases son:

Herencia. Asociación Agregación.

La herencia ya ha sido tratada anteriormente. La asociación y la agregación se presentan a continuación.

7. 3. Asociaciones y links. Una asociación (association) es una relación entre clases de objetos. Un link es una conexión entre instancias que define una tupla. Es decir, un link es una instancia de la

PaísNombre

CiudadNombre

Tiene_ciudades Diagrama de Clase

(País)Francia

(Ciudad)París

Tiene_ciudades

(Ciudad)Lión

(Ciudad)Montpelier

Tiene_ciudades

Tiene_ciudades

Diagrama de

Instancia

Figura 141. Ejemplo de Diagramas de Clases e Instancias

Figura 142. Notación de las asociaciones


correspondiente asociación. A cada asociación se le asigna un nombre. Opcionalmente se puede colocar el rol de cada clase en su extremo. En la figura anterior se muestra un ejemplo de asociación y de link. (tiene_ciudades). En la figura de la izquierda se muestra la notación empleada y un ejemplo. Las asociaciones son bidireccionales. El nombre se lee normalmente en una dirección, pero la asociación puede ser transitada en las dos direcciones. Las asociaciones pueden ser binarias, como en los ejemplos anteriores, ternarias o de orden superior. En la figura de la derecha se muestra un ejemplo de asociación ternaria y su correspondiente link. La multiplicidad (Multiplicity) de una asociación especifica cuantas instancias de una clase pueden ser relacionadas con una instancia de la otra. Existen dos formas básicas de notar en un diagrama de objetos la multiplicidad de una asociación:

Colocar la multiplicidad como un entero en cada extremo de la asociación. El entero positivo (cardinal) indica cuantas instancias puede haber de la clase de ese lado de la relación. Observe que es una notación parecida a la relacional. Esta notación fue propuesta inicialmente por Cood/Yourdon.

Representar la multiplicidad por símbolos gráficos, notación iniciada por el grupo promotor de OMT.

Proyecto Lenguaje

Persona

(Persona)María

(Proyecto)Programa CAD

(Lenguaje)C

(Proyecto)Contabilidad

(Lenguaje)Cobol

Diagrama de Clase

Diagrama de Instancia

Figura 143. Ejemplo de Asociación Ternaria

PaísNombre

CiudadNombre

Tiene-capital1 1

PaísNombre

CiudadNombre

Tiene-ciudades1 N

LíneaNombre

PuntoNombre

Se-cruzan0,2+ 0,N

WorkstationNombre

WindowNombre

Consola_de_errores1 0,1

ArcivoNombre

UsuarioNombre

Accesible por0,N 0,N

Clase-1 Clase-2Número-1 Número-2

Exemplos

Figura 144. Notación de la Multiplicidad por un cardinal.


Exactamente una (Exactly one) Cero o más (Many) Cero o una (Optional) Una o más (One o more) Especificada (Numerically specified)

En la figura de la derecha se muestran algunos ejemplos de multiplicidad notados de esta forma. Se han escogido los mismos ejemplos de la notación anterior para poder comparar las dos anotaciones. Es habitual que una asociación tenga atributos. Así en el ejemplo de

accesibilidad de la figura anterior, se puede asociar a la relación Accesible_por el

atributo de Permiso_de_acceso por usuario. Una asociación con atributos puede modelarse como una clase, que a su vez, puede relacionarse con otras. En la figura se muestra un ejemplo. El tema de asociaciones puede tratarse en mayor profundidad. Sin embargo, para los efectos de este libro, utilizar los diagramas de objetos para modelar los esquemas de datos de las aplicaciones distribuidas, tenemos suficiente.

7. 4. Agregaciones.

Clase

Clase

Clase

Clase1+

Clase1-2,4

PaísNombre

CiudadNombre

Tiene-capital

PaísNombre

CiudadNombre

Tiene-Ciudades 1+

Se-cruzanLíneaNombre

PuntNombre2+

WorkstationNombre

WindowNombre

Consola_de errores

ArchivoNombre

UsuarioNombre

Accesible por

Figura 145. Notación Simbólica de la Multiplicidad

Figura 146. Ejemplo de Asociación con atributos

Figura 147. Ejemplo de Asociación con Atributos modelada

como una clase.


La Agregación (Agregation) es una relación “part-whole” o “a-part-of” en la cual los objetos componentes (Components) son asociados en un nuevo objeto ensamblado (Assembly). En la figura se muestra la notación y un ejemplo de agregación.

Observe que hay una diferencia fundamental entre una asociación y una agregación. En una agregación, si se cambia un componente de la instancia, cambia el objeto; en una asociación no. Así, si en un coche es cambia el motor, el coche es, incluso legalmente, otro. En la figura de la derecha se muestran dos ejemplos más de agrupaciones.

7. 5. Algunos ejemplos de Modelos de Objetos. Con todos los componentes presentados, se muestran a continuación algunos ejemplos de modelos de objetos.

Término

ExpresiónOperador Binario

VariableNombre

ConstanteValor

Primer Operando

Segundo Operando

Figura 150. Modelo de Objetos de una

Expresión

LíneaTexto

ColumnaCoordenada XCoordenada YAnchoLargo

PáginaAnchoLargoMargen izquierdoMargen derechoMargen superiorMargen inferior

Figura 151. Modelo de Objetos de un texto.

Figura 148. Notación y

ejemplo de Agregación

Documento Parrafo Palabra

PC

Monitor Cajade sistema Mouse Teclado

Chasis CPU RAM Ventilador

1+Discp

1+

Figura 149. Ejemplos de Agregaciones


PaísNombre

Fronteras

(País)Australia

(País)Italia

Diagramas de instancias

(País)Francia

(País)Suiza

(País)Italia

(País)Italia

Figura 152. Diagrama de Objetos de fronteras

de países

Colección de cartasJugador

Res

5Cartas

PaloNúmero

Pareja Trio Full Poquer Color

Evidentemente, faltan jugadas ....

Figura 153. Modelo de Objetos de una mano

de poker.

8. Reflexión final. Si usted ya conocía los fundamentos de OO este capítulo se ha supuesto una pérdida (¿total?) de tiempo. Si no los conocía, no le habrá servido para nada más que para motivar su interés. Eso espero al menos. Pero como ve la metodología OO aporta los dos componentes básicos que necesitamos: la descripción de los datos y la descripción del flujo de información mediante los diagramas de flujo. Por tanto todo lo que desarrollaremos a continuación vale para cualquier sistema distribuido independientemente del método de análisis empleado.

CiudadNombre

Aeropuerto

Nombre

AerolíneaNombre

PilotNombre

VueloFechaNúmero

Origen

Llegada

AviónModeloNúmeroHoras vuelo

PasageroNombre

AsientoLocalización

Figura 154. Modelo de Objetos de un sistema

de transporte aéreo

EmpleadosCompañía

Ordenador

Persona

Propietaris Asignado a

Figura 155. Uso de ordenadores por

empleados

@@EMG/10-Enric Martínez Gomàriz 219

Implementación de un modelo de objetos sobre un modelo relacional

1. Introducción.

Hoy día los gestores de bases de datos utilizados están basados en el modelo relacional. Recordemos que pasa con las metodologías de análisis de datos. El modelo OO permite, de forma estándar, dotar al esquema de datos de especializaciones y generalizaciones (mecanismo de herencia), agregaciones y asociaciones frente a solo relaciones del modelo relacional convencional. Existen propuestas para extender el modelo relacional y dotarlo de especializaciones, generalizaciones y agrupaciones, pero ninguna de ellas se ha utilizado masivamente. Y además, ¡para que complicarse la vida si el modelo de objetos OO ya dispone en su base de la potencia semántica que le falta al relacional y además ya es un estándar! Mi consejo es muy claro y directo: utilice el modelo OO para describir los datos. Además de su potencia frente al relacional, sirve tanto para aplicaciones RDA como avanzadas. Así, pues, es mucho mejor utilizar el modelo de objetos de las tecnologías OO en lugar del modelo relacional para analizar, crear y documentar los datos. Llegados a este punto, puede pensar, amigo lector, que estamos en un camino sin salida: utilizaremos el modelo de objetos OO para analizar pero la implementación es relacional. No se preocupe. Existe una metodología muy simple para mapear el modelo de objetos OO sobre un modelo relacional. Es el objetivo de este capítulo que le va a parecer sorpresivamente corto para la importancia que tiene.

2. Traspaso de esquemas. Cuando hablamos de traspaso de esquemas hemos de hablar del mapeo (mapping) del modelo de objetos sobre el modelo relacional. La equivalencia se hace sobre el esquema de tres niveles ANSI/SPARC que le recuerdo el la figura. La equivalencia se estable a nivel del esquema conceptual. El modelo de objetos se mapea sobre el esquema conceptual relacional.

Conceptual Schema

External Schema 1

External Schema N

External Schema 2

Application 1 Application 2 Application N

{External squema layer

{Conceptualsquema layer

{Internal squema layer Internal

squema 1Internal

squema M

ANSI/SPARC three schema architecture

Figura 156. ANSI/SPARC three schema architecture


Aunque en el mundo OO no es nada habitual, puede hablarse de establecer External Object Models equivalentes a los External Models relacionales. Sin embargo, la focalización del mapeo es el esquema conceptual:

El modelo de objetos OO se traspasará a un esquema conceptual relacional utilizando reglas de mapeo.

El esquema conceptual resultante se traducirá a una esquema interno relacional con las herramientas habituales del modelo de gestión de bases de datos relacionales. Recordemos que el modelo interno no es más que el conjunto de comandos SQL que crean las tablas, atributos y estructuras de perfomance-tunning, por ejemplo los índices.

Pueden escogerse diferentes alternativas de mapeo; por ejemplo, hay dos formas de mapear una asociación de tablas y cuatro de mapear una generalización. Cuando se realiza el mapeo hay que añadir detalles que no están en el modelo de objetos como claves primarias, secundarias y foráneas, atributos que no pueden ser nulos, etc. Vamos a tratar en lo que sigue de todo ello.

3. Mapeo de clases. Aunque el criterio inicial es que una clase se convierte en una tabla, en la práctica es frecuente que una clase pueda convertirse en una o más tablas. El caso contrario también es habitual, una tabla puede ligar más de una clase sí éstas están conectadas por una asociación o una jerarquía. Las razones pueden ser de dos tipos: rendimiento y relaciones establecidas entre las dos clases. Dicho de otra forma, para mapear clases en tablas hay estudiar las relaciones que establece con otras clases. Una razón habitual para partir una clase es el rendimiento. Como la clase ha de modelar complementa a la entidad, tendrá todos sus atributos. Si embargo, es muy frecuente que sólo una parte de esos atributos se consulte habitualmente, o solo una parte de ellos esté habitualmente informada. El hecho de que las instancias de una misma entidad tengan una frecuencia muy diferente de acceso puede favorecer también la partición.

ExternalObjectModels

Conceptual table model

Familia de aplicaciones relacionadas

Internal squema 1Internal

squema 1Internal squema 1

External table

modelsExternal

table modelsExternal

table models

Vistas y/o interfícies de programas

mapping rules

ConceptualObjectModel

mapping rules

Figura 157. Equivalencia de de niveles entre OO y relacional


Así, se habla de dos tipos de partición de clase:

Partición Vertical, en la cual las instancias se dividen en más de una tabla. Partición Horizontal, en la cual los atributos se dividen en más de una tabla, repitiendo la clave en cada tabla.

Obviamente, la partición puede hacerse en las dos dimensiones. Cada tabla derivada ha de tener una clave primaria que debe escogerse entre los atributos que identifiquen unívocamente a cada instancia. Deberán definirse las claves secundarias necesarias para conseguir rendimiento en los accesos previstos. Este tema es fundamental en aplicaciones distribuidas. Todas las claves resultantes no deberán permitir nulos. La existencia o no de nulos en el resto de campos que implementen el resto de atributos quedará a decisión del diseñador.

4. Mapeo de asociaciones a tablas. Las asociaciones pueden mapearse, según los casos, en tablas o definirse directamente en las tablas de las clases ligadas. Las ventajas de implementar en tablas son:

Tablas más reducidas. Mayor rendimiento y facilidad de navegación.

Las desventajas son:

Esquemas resultantes más complejos. Mayor dificultad de ampliación. Menor aproximación del modelo conceptual OO a resultante relacional.

Quedará a criterio del diseñador ponderar los aspectos de cada modelo y escoger la solución que más convenga. Asociaciones N a N.

Cada asociación de N a N se implementa en una tabla relacional. La clave primaria de la tabla son los atributos que definen la asociación. En esta tabla, esas claves principales son claves foráneas de las tablas en las que se han mapeado las clases ligadas por la asociación. Normalmente se implementan claves secundarias por cada una de las clases asociadas. Una asociación N a N entre una clase producto y una clase proveedor que tenga como atributo el las condiciones de compra se resolvería con una tabla que implementaría la asociación donde:

El identificador de producto y el identificador de proveedor serían las claves principales.

Los identificadores de producto y de proveedor serían las claves foráneas de las respectivas tablas.

Las condiciones de compra serían los campos. Habrá claves secundarías por cada uno de los identificadores.


Asociaciones 1 a N.

Las asociaciones de 1 a N se pueden implementar en una tabla o pueden ser escondidas como un atributo de la tabla que mapea la clase de la que parte la relación de cardinalidad N. El atributo es clave foránea de la clase de cardinalidad 1. Habrá que definir tantos parámetros adicionales defina la relación. Por ejemplo, sea una asociación entre un local de una compañía y las personas que trabajan en la cual el atributo sea el despacho que ocupan. Existen dos posibilidades.

Una solución paralela a la anterior. Colocar en la tabla de personas dos tributos, uno para indicar en que local están (clave foránea de la tabla de locales) y otro para el despacho.

Asociaciones 1 a 1.

Cada relación 1 a 1 puede mapearse en una nueva tabla independiente o puede ser establecida mediante una clase foránea asociada a un atributo cruzado definido en cualquiera de las dos tablas. De hecho, este caso es un caso particular del anterior.

El nombre de los rols de la asociación se incorpora como parte del nombre del atributo de la clave foránea.

5. Agregaciones. La implementación de agregaciones es paralela a la de las asociaciones. Sin embargo la solución más usada es la de añadir atributos a la clase construida con los identificadores de las clases componente. Estos identificadores son claves foráneas de las correspondientes tablas de los componentes. Así la clásica agregación de un coche construido a partir de un chasis y de un motor se resuelva añadiendo dos atributos a la tabla en la que se ha mapeado la clase coche.

6. Herencia para definir especializaciones y generalizaciones. Hay tres formas de mapear herencias, que definan generalizaciones y/o especializaciones, en tablas. En dos de los casos es necesario crear un atributo nuevo que indicará que tipo de subclase es cada instancia. Así, si estamos ante una especialización de productos en materia prima y producto de venta, este nuevo atributo, que podríamos llamar tipo_de_producto, tendrá dos valores, un para cada especialización. Cada clase y cada subclase se mapea en una tabla diferente.

El identificador de la instancia se repite en cada una de las tablas como clave primaria. En la tabla de la subclase, además es clave foránea a la tabla padre.


En cada tabla se colocan los atributos de cada nivel. En la tabla que mapea la clase padre hay que colocar el atributo que indica el tipo de instancia informada. Este enfoque permite mantener la lógica de datos y da gran extensibilidad. Sin embargo la navegación por las tablas puede ser muy lenta ya que para situar una instancia de una subclase hay que: • Leer de la tabla de la clase padre. • Tomar los atributos, y entre ellos el tipo de instancia. • En función del valor de ese atributo, acceder a la instancia en la subclase. • Recuperar los atributos de la subclase, reconstruyendo con los anteriores el

total de atributos de la instancia.

La clase padre y todas subclases se mapean en una única tabla (todo en una sola tabla). No hay mucho a decir aquí. El acceso es muy eficiente pero hay un desaprovechamiento de espacio ya que hay que poner todos los atributos de todas las especializaciones, y solo habrá que informar los que corresponden al tipo de la instancia.

Cada subclase se mapea en una tabla diferente. En este caso no hay ninguna tabla que mapee la clase padre, todos los atributos comunes se repiten en cada subclase. Es el caso en que no se necesita el atributo de tipo de instancia. Es una solución de gran rendimiento de navegación a cambio de una perdida razonable de espacio. La perdida será tanto más razonable cuando menor sea el número de atributos comunes.

Encontrará un ejemplo de mapeo de jerarquías en el ejemplo del capítulo “Ejemplo de Diseño de los Componentes Gráficos de una aplicación RDA” de la parte de diseño de interfícies gráficas y su uso en aplicaciones RDA.

Diseño de Aplicaciones Avanzadas por UML integrado con la metodología de diseño

distribuido 1. Introducción.

Le recuerdo que hemos trabajado en capítulos anteriores que el diseño distribuido:

Es una etapa adicional al diseño tecnológico del sistema. Es una etapa independiente de la metodología utilizada para el análisis y el diseño tecnológico de la aplicación.

Partirá de que se dispone de: Un modelo conceptual de datos. Las funciones del sistema. La sequencialización de las funciones del sistema.

Dedicaremos este capítulo a presentar la integración entre UML y diseño distribuido explicando básicamente:

De donde sale la información anterior. Como se integran en el diseño UML los resultados de la etapa de diseño distribuido.

Recuerde que partimos de la base de que Vd. conoce las herramientas básicas de UML.

2. Diseño de Sistemas por UML. (a) Especificación.

Equivale a la etapa de análisis funcional de las metodologías convencionales. Como rasgos característicos del proceso de especificación recuerde que:

Define el modelo conceptual de datos con clases, atributos y relaciones entre clases.

Existen dos criterios para las operaciones: Suponer que todas las funciones las proporcionan operaciones de una única clase denominada Sistema, que seguiremos aquí.

Asignar desde un principio las operaciones a las clases. Obviamente, usar uno u otro criterio no afecta a la metodología excepto demorar al diseño la asignación de las operaciones a las clases. Para simplificar trabajaremos con el primer criterio asignado todas las operaciones a una clase única que referenciaremos como Sistema. De la especificación se obtienen:

El modelo conceptual de especificación:

225

Está formado por los diagramas estáticos de las clases del dominio, incluyendo las relaciones.

La descripción de las clases solo contiene los atributos y se presenta sin operaciones.

El modelo de Casos de Uso que incluye: Los Casos de Uso esenciales. Los Diagramas Secuencia de los Casos de Uso.

El modelo de Comportamiento del Sistema reflejado en los: Diagramas de Secuencia de las Operaciones de Sistema. Contratos de las Operaciones de Sistema. Diagramas de Actividades (si se desarrollan) Diagramas de Colaboración (si se desarrollan)

El modelo de Estados reflejado en los: Diagramas de Estado de Objetos. Diagramas de Estado de los Casos de Uso.

Otros documentos adicionales.

(b) Diseño Tecnológico. Su objetivo es definir un Sistema de Software con la suficiente precisión para permitir su construcción física (implementación). El punto de partida son los resultados de la especificación. Los resultados obtenidos después de realizar el proceso de diseño son, básicamente:

La Arquitectura del Sistema de Software. El Diseño de los Datos a través del Modelo Conceptual de Diseño donde las clases incluyen las operaciones diseñadas para implementar las operaciones de sistema de la especificación.

El Diseño de la Arquitectura del Software. El Diseño de las Interfícies GUI, como normalmente se integra la parte cliente.

El Diseño de los Flujos de proceso (Batch, Workflow, etc.) El Diseño de los Programas a través de los Diagramas de Seqüència.

El proceso para obtener el diseño a partir de la especificación se apoya en:

Utilizar Patrones de Arquitectura. Aplicar la Metodología de diseño adoptada para cada patrón arquitectónico utilizado.

Adaptación de soluciones genéricas de diseño basadas en la utilización sistemática de patrones de diseño.

La Arquitectura de Software es para UML lo mismo que para las metodologías convencionales la Arquitectura del Sistema: la descripción de los subsistemas y componentes del sistema de software y las relaciones entre ellos. En uno de los primeros pasos del diseño habrá que definir la arquitectura de software. Para hacerlo nos basamos en:

La elección y aplicación de Patrones de Arquitectura.

226

La aplicación sistemática en todo momento del Patrón OO (obvio si es UML)

No es necesario incluir aquí una lista exhaustiva de los patrones arquitectónicos disponibles. A modo de ejemplo, veamos algunos de los más habituales en el mundo de aplicaciones distribuidas:

Arquitectura de capas: Arquitectura de tres capas:

Presentación. Dominio Datos.

Arquitectura de dos capas: Presentación. Datos.

Flujo de datos: Cadenas Batch. Procesos de Workflow.

Etc. Obviamente, en una misma arquitectura de software compleja pueden convivir varios patrones arquitectónicos. De hecho, es frecuente que lo hagan en una arquitectura tan amplia como la que configura un sistema distribuido. En las primeras etapas habrá que hacer la normalización del modelo conceptual de datos de diseño. Se puede atacar como una etapa previa al diseño o en los primeros pasos de cada arquitectura o en ambos momentos a la vez. Obviamente si se hace en las dos fases, en la segunda sólo habrá que trabajar las ampliaciones surgidas en el diseño. Recuerde que, partiendo del modelo conceptual de especificación, para normalizar hay que realizar las:

Transformaciones canónicas Eliminación de asociaciones n-arias y clases asociativas. Traspaso de las restricciones de integridad. Materialización y/o cálculo de las asociaciones y atributos derivados.

Trasformaciones relacionales. Se suelen hacer en el diseño de la capa de datos e incluyen:

Mapeo de jerarquías de herencia. Mapeo de las relaciones: agrupaciones y/o composiciones.

Las transformaciones relacionales forman parte del diseño de la base de datos y se atacaran normalmente en la etapa de diseño de la capa de datos. Podemos encontrar dos situaciones:

Las clases del modelo conceptual no existen en la base de datos: Se atacará como un diseño nuevo.

Parte o todas las clases ya existen en la base de datos. Deberá proporcionar un metaesquema de equivalencia. El caso más simple será establecer la equivalencia clase-tabla.

227

Si no hay equivalencia directa, pueden aparecer problemas idénticos a los de un Upsizing que resolveremos de la misma forma. Más adelante presentaré cómo hacerlo.

La metodología genérica a aplicar en el diseño incluye:

Elección de los patrones arquitectónicos a utilizar. Asignación de los casos de uso a cada patrón arquitectónico. Aplicar la metodología apropiada a cada patrón arquitectónico

Obviamente, la metodología especifica de cada patrón arquitectónico se adaptará a cada uno de ellos y ya he dicho que queda fuera del abasto de este libro. Veamos a modo de ejemplo la Arquitectura por Capas que se basa, como su propio nombre indica, en definir la arquitectura del sistema de software en capas jerárquicas que interaccionan únicamente con sus capas inferior y superior a través de servicios que la inferior proporciona a la superior. La arquitectura de tres capas es la que se aplica normalmente a aplicaciones con interfície gráfica que se distribuyen en tres niveles:

Presentación, que recibe los eventos del sistema a través de GUI’s Dominio, que implementa la funcionalidad Datos, que proporciona la persistencia.

La capa de presentación sólo puede interactuar con la de dominio y siempre a través de servicios. La capa de dominio solicita también servicios a la de datos. La metodología a aplicar a una arquitectura de tres capas es, básicamente:

Asignación de la comprobación de las restricciones de integridad a las operaciones.

Análisis de la interfície gráfica. A partir de los casos de uso y las operaciones de sistema afectadas se proponen:

Las maquetas de las Interfícies Gráficas necesarias. El flujo de diálogo propuesto dentro de cada interfície. Los casos de uso concretos. Los mapas navegacionales.

Distribución de las responsabilidades de las operaciones de sistema por capas.

La comunicación entre capas es siempre por servicios. La respuesta a los eventos del sistema y de los errores se hace siempre en la capa de presentación.

Determinación de los servicios que cada capa ha de suministrar a la superior.

Agrupándolos por controladores. Proporcionando los contratos de las operaciones resultantes.

Determinación de la respuesta a los eventos básicos de la capa de presentación que puede necesitar servicios adicionales de la capa de dominio.

Diseño posterior e independiente de cada capa.

(c) Documentación resultante del diseño.

228

De la etapa de diseño UML se obtienen:

El modelo conceptual de diseño: Diagramas estáticos de las clases del dominio y las clases de diseño aparecidas.

Las clases incluyen las operaciones de diseño. Aportan la información de los datos.

El modelo de Casos de Uso: Casos de uso concretos. Diagramas de Secuencia de los Casos de uso concretos. Interfícies Gráficas.

Diseño. Mapas navegacionales:

Internos a cada pantalla. Entre pantallas.

Secuencias de flujo. Aportan parte de los criterios para integrar la parte cliente.

El modelo de Comportamiento: Diagramas de Secuencia de las operaciones de diseño. Contratos de las Operaciones de diseño. Diagramas de Colaboración (pocas veces desarrollados) Diagramas de Actividades (si existen). Aportan descripción de las funciones del sistema y secuencialización.

El modelo de Estados Diagramas de Estado de Objetos y Casos de Uso completos

Otros documentos adicionales.

(d) Puntos de partida de la etapa de diseño distribuido. Recordemos de donde obtendremos los puntos de partida para añadir al diseño de la arquitectura de software los pasos adicionales del diseño distribuido:

La descripción de datos: Modelo conceptual de diseño.

Determinación de la arquitectura de datos. Servicios de Lógica de Datos.

Descripción de las funciones del sistema. Operaciones asignadas a las clases de diseño.

Secuencialización de procesos. Integración del cliente.

Casos de uso de diseño, normalmente solo para identificar: Los eventos del sistema a los que responde la parte cliente.

La forma de integración. Descripción de los flujos de las cadenas de diseño

229

Identificación de Servicios. Diagramas de secuencia de las operaciones de diseño.

Diagramas de actividad.

Diagramas de colaboración.

En la figura de la derecha se muestra un esquema de la metodología de diseño UML y su integración con el diseño distribuido.

3. Diagramas de despliegue. En UML, los diagramas de despliegue muestran la disposición de los distintos materiales, denominados también nodos, que entran en la composición de un sistema y el reparto de los componentes sobre esos materiales o nodos. Los nodos pueden:

Estereotiparse: servidores, bases de datos, PC’s, impresoras, dispositivos de tipos concretos, etc.

Relacionarse entre ellos incluyendo la cardinalidad, el tipo de la relación (TCP/IP, Internet, etc.) y los roles.

Informar de los materiales que incluyen. Para poder describir el sistema distribuido usaremos las siguientes posibilidades adicionales:

Anidar nodos. Aunque UML no define claramente esa posibilidad, incluyendo un nodo en la lista de materiales incluidos en otro nodo se consigue ese efecto.

Referenciar cada material o nodo con un nombre.

Asignar cada material o nodo a una situación física.

En la figura se muestra la representación gráfica de un nodo en un diagrama de despliegue. Una observación práctica. Es muy frecuente que la relación de materiales incluidos en un nodo no quepa dentro del cuadro reservado en la representación gráfica del nodo. Cuando esto ocurre, la relación se incluye en una lista aparte bajo un epígrafe con la referencia del nodo.

Especificación

Datos (Modelo Conceptual)

Funcionalidad(Casos de uso /

operaciones de sistema)

Diseño UML no distribuido

Modelo de Clases

Sequencialización (Casos de uso de diseño +

Flujos de diseño + Diagramas de secuencia + Diagramas de actividad +

Diagramas de colaboración)

Atributos

Métodos

Dis

eño

del S

iste

ma

Dis

tribu

ido

Figura 158. Evolución del diseño UML a distribuido

<<Estereotipo>> + Referencia

Materiales o nodos que incluye

Referencia del material donde se sitúa físicamente

Figura 159. Representación gráfica a de los nodos en un diagrama de despliegue

230

A partir de aquí podemos construir los siguientes diagramas de despliegue para poder describir nuestro sistema distribuido. (a) Diagrama de Sistema.

Describe mediante un diagrama de despliegue las características genéricas de la plataforma de sistema. Constituye “de facto” una representación de la arquitectura de plataforma de sistema incluida en el Plan Estratégico Distribuido de la Compañía. En la figura se muestra un ejemplo de diagrama de sistema. Observe que se ha aprovechado la cardinalidad para prever un máximo de 100 directores de zona, cada uno de ellos haciéndose cargo de un máximo de 5 locales. La conexión por Terminal Server se utilizará para que cada director de zona pueda acceder y controlar los locales de venta que tenga asignados. La conexión por Internet a la central le permitirá acceder, por ejemplo, al servicio de correo y a los resultados de explotación de sus locales.

(a) Diagrama de la infraestructura.

<<Host>>

AS/400

• AplicacionesHeredadas

• DB2

<<Servidor decomunicaciones>>

PC

• Linux• Citrix

<<Servidor WEB>>

PC

• Lnux• Data Warehouse con Oracle.

• Apache.

1 *

1

1

<<Servidor de Local>>

PC

• Windows• Citrix• SQL-Server

TCP/IP

1 1..20

<<Puesto de Venta>>

TPV

• Windows

TCP/IP

TCP/IP

1

1..12

TCP/IP

<<Supervisor>>

PC Portátil

• Aplicación de Ventas

11..100Internet

TerminalServer

1..5

1

Figura 160. Ejemplo de diagrama de Sistema

231

Describe mediante un diagrama de despliegue la infraestructura de la plataforma. Debe ser una instancia del Diagrama de Sistema. En la figura se muestra un ejemplo de un diagrama de infraestructura correspondiente al ejemplo de diagrama de sistema anterior. Piense en una organización con 70 locales y 15 directores de zona e intente imaginarse un diagrama gráfico con estos números. Deducirá fácilmente porque no es habitual desarrollar este diagrama de forma gráfica.

(a) Diagrama de niveles físicos Normalmente se utiliza como tal el Diagrama de Sistema. Solo se desarrolla un diagrama específico cuando hay algún matiz del modelo que se cree necesario particularizar

(b) Diagrama de niveles lógicos. Corresponde a la situación de los niveles lógicos sobre los físicos. A cada nodo lógico se asigna un nombre, que puede ser el mismo que el nodo físico, y en la localización se especifica el nodo del diagrama de niveles físicos / sistema en el que se aloja. En la figura se muestra un ejemplo de diagrama de niveles lógicos basado en el diagrama de sistema del ejemplo anterior. Observe que sobre los niveles físicos se estable un doble nivel lógico:

Locales: Primer nivel lógico: HOST.

Segundo nivel lógico: Servicios del local, localizados sobre el nivel físico del servidor del local.

Host

Barcelona

Servidor Comunic. 1

Barcelona

Servidor Comunic. 2

Barcelona

Servidor Local

Les Corts

Servidor Local

Rambles

Servidor Local

Sants

Puesto de Venta

3 TPV’s

Puesto de Venta

5 TPV’s

Puesto de Venta

2 TPV’s

Servidor LocalPuerta del sol

Servidor Local

Moratalaz

Puesto de Venta

4TPV’s

Puesto de Venta

2 TPV’s

SevidorWEB

Barcelona

Supervisor

Lluís Puig

Supervisor

Ana Ros

Figura 161. Ejemplo de diagrama de Sistema

Serviciosde Host

<<Host>>

Servidor WEB

<<Servidor WEB>>

1

1

1

Servicios del Local


*

Puesto de Venta

<<Puesto de Venta>>

1

1..12

Supervisor

<<Supervisor>

11..100

1..5

1

Mando del Local


1

1

Figura 162. Diagrama de Niveles Lógicos

232

Tercer nivel lógico: cliente, con tres perfiles: Mando del local, situado sobre el nivel físico del servidor de local.

Puesto de venta, situado sobre le nivel físico del puesto de venta.

Supervisor, situado sobre el nivel físico del mismo nombre. Servicios WEB:

Primer nivel lógico: HOST. Segundo nivel lógico: Servidor WEB situado sobre el nivel físico del mismo nombre.

Tercer nivel: Supervisor, utilizando un navegador situado en el nivel físico del mismo nombre.

(a) Diagrama de la Arquitectura de Servicios.

Los servicios, agentes y clientes se estereotipan como un nodo y el nombre del componente y las relaciones del diagrama de despliegue muestran la arquitectura obtenida del diseño distribuido. Sobre el diagrama de despliegue resultante deberemos incluir el tipo de comunicación y la arquitectura de servicios:

Asignando un nombre a la relación que incluya el tipo de comunicación, el tipo de arquitectura entre los dos servicios y posibles puntos de heterogeneidad como la presencia de una comunicación remota (opción UML pura)

Utilizando iconos como los presentados de este libro para la notación MAFDRA, opción no estándar dentro de UML, pero a mi juicio mucho más clara si el modelo de objetos distribuidos es un punto de heterogeneidad como presentaremos en el apartado siguiente.

Se puede utilizar la navegabilidad de la relación para documentar si la comunicación es desacoplada o no. En la figura se muestran las dos posibilidades. Observe que en los diagrama de arquitectura de servicios la cardinalidad es:

Siempre de muchos (*) en la parte del cliente ya que un servidor atiende un número indeterminado de clientes. Podríamos forzar una cardinalidad concentra N si quisiéramos indicar que:

Hay un tope de clientes. El servicio es multinstancia y que cada N clientes debe arrancarse una instancia nueva del servicio.

En la parte del servidor: 1 si queremos indicar que el servidor del servicio es único.

Alta Clientes en el Local

Alta Clientes en la Central1* D


Alta Clientes en la Central1* RPC Remoto

Delegación

Figura 163. Diagrama de Arquitectura de

Servicios – Notación.

233

N si queremos indicar que el servicio es multinstancia. Observe que la cardinalidad muchos (*) no es realmente factible ya que indicaría que la máquina donde se aloja el servidor del servicio es infinita en recursos.

En la figura se incluye un ejemplo de utilización de los diagramas de despliegue para documentar la arquitectura de servicios. He incluido la notación MAFDRA para describir de forma rápida el servicio objeto del ejemplo. Otra posibilidad para implementar el diagrama de Arquitectura de Sistemas es un Diagrama de Colaboración. En la figura se muestra una propuesta de notación. Si utiliza un diagrama de colaboración para documentar la arquitectura de servicio no es necesario que utilice la posibilidad de numerar cada paso de colaboración: es diagrama de arquitectura de servicios no necesita esa información ya que refleja la relación estructural entre los servicios, no la dinámica.

(a) Diagrama de Localizaciones. Los elementos, servicios, agentes y clientes del Diagrama de Arquitectura de Servicios y los programas obtenidos en la fase de integración del cliente se sitúan sobre el Diagrama de la Infraestructura lógica.

ServidorAlta

ClientesCliente Clientes en la Central

RD

ServidorAlta



Cliente Alta Clientes1*

Alta Clientes en la Central

1

*

Base de datosCentral

•Oracle

Base de DatosLocal

•SQL-Server1*

1*

D

Figura 164. Ejemplo de diagrama de Arquitectura de Servicios

D

1* RPC Remoto

Delegación



1*Alta Clientes en el Local


Figura 165. Diagrama de Arquitectura de Servicios

implementado como diagrama de Colaboración

234

En la figura se muestra el diagrama de localizaciones del ejemplo de arquitectura de servicios anterior. Observe que este diagrama es prácticamente igual que el de servicios incluyendo el nivel lógico donde se aloja cada servicio. Dadas las pocas diferencias entre los diagramas de despliegue de la arquitectura de servicios y de localización, incluir en la documentación únicamente uno de ellos.

4. Fuentes de servicios sobre un diseño UML. Una vez concluida la etapa de diseño de sistema del software “no distribuido”, los resultados se analizarán para detectar servicios aplicando todos los criterios que hemos visto hasta ahora y los que incluiremos más adelante. En la metodología integrada de diseño distribuido que presentaré más adelante, veremos que esta etapa está muy hacia el principio. No hay problema, pues, para aplicarla sobre un diseño UML para identificar servicios. (a) Diagramas de clases.

El diagrama de clases de diseño, en cuanto a atributos y relaciones, se mapeará sobre el modelo relacional. A partir de aquí se aplicaran los criterios de análisis de datos distribuidos que veremos más adelante. La Arquitectura de Datos Distribuida resultante deberá enlazarse con el diagrama de clases de diseño al dotarlo de persistencia mediante servicios de lógica de datos, posiblemente con la gestión de un metaesquema que mapee el esquema conceptual de diseño sobre la arquitectura distribuida.

(b) Diagramas de actividad. Representan y describen el estado de ejecución de un proceso bajo la forma de un desarrollo de etapas agrupadas secuencialmente en ramas paralelas y concurrentes de flujo de control. Un diagrama de actividades es provechoso para entender el comportamiento de alto nivel de la ejecución de un sistema, sin profundizar en los detalles internos de los mensajes. Equivalen a los diagramas de flujo de metodologías tradicionales, incluyendo la secuencialización de procesos que hemos incluido en los diagramas de flujo MAFDRA.

Cliente

Mando del Local

Alta Clientes

Servicios del Local

1*


Servicios de Host

1

*

Base de datosCentral

Servicios de Host

•Oracle

Base de DatosLocal

Servicios del Local

•SQL-Server1*

1*

D

Figura 166. Diagrama de Localizaciones

235

Aplicando los criterios de identificación de servicios a esas actividades se detectarán cuales de ellas han de ser servicios. Las actividades estarán asignadas a clases, que se podrán integrar completamente a servicios o dividirlas o especializarlas por herencia y polimorfismo en clases. Veamos un ejemplo. En la figura se muestra una aplicación de ventas en la que el pedido se registra en una tienda, la facturación es diferida y centralizada y los pedidos se preparan y envían al cliente desde almacenes a los que se asigna cada tienda. Presuponemos que no hay rotura de stocks y que el riesgo se verifica de forma centralizada en la central. Aplicando criterios para identificar servicios obtenemos:

Los clientes se replican en la tienda por criterios de disponibilidad y eficiencia.

La obtención de riesgo se localizará en la central por criterios de localización funcional. Necesitaremos un servicio.

Necesitaremos una agente en el entorno de la aplicación de facturación para la recepción del pedido a facturar.

La facturación se realizará en la central por ser la aplicación heredada. El proceso de facturar será un servicio suministrado por un agente que envolverá a la aplicación corporativa.

La impresión del albarán se realizará utilizando Word como servidor de Impresos.

Central AlmacénTiendaRegistrar Cliente

Obtener Riesgo

Rechazar Cliente

Registrar Pedido

[Sin crédito]

Facturar

[Con crédito]

Preparar Envío

Imprimir Albarán

Enviar al Cliente

Figura 167. Ejemplo de Diagrama de Actividades como fuente de servicios

Central AlmacénTiendaRegistrar Cliente

Obtener Riesgo

Rechazar Cliente

Registrar Pedido

[Con crédito]

Facturar

[Sin crédito]

Preparar Envío

Generación del Albarán

Enviar al Cliente

Comprobar Riesgo

Imprimir Albarán

Enviar para facturación

Recibir Facturación

Enviar Albarán

Recepción de Albaranes

Figura 168. Ejemplo de Diagrama de Actividades adaptado tras el diseño distribuido

236

Necesitaremos un servicio de agente para traspasar la responsabilidad de entrega del material al almacén.

Con todo ello y realizando el diseño distribuido informalmente, el diagrama de actividades distribuido será el que se muestra en la figura anterior. En la integración de la parte cliente supondremos que hay:

Un programa en la tienda para Captura de los Pedidos que integra todas la funciones de la parte de la tienda que no son servicios.

Un proceso en el almacén para Servir Pedidos que no detallaré. La aplicación heredada proporciona en la central un servicio envolvente de Facturación para facturar a través de la aplicación corporativa.

Con todo ello, el diagrama de despliegue que representará la arquitectura de servicios resultante, presentado como diagrama de localización, será el de la figura de la derecha. Se ha supuesto que el modelo de objetos distribuidos es un punto de heterogeneidad en el sentido que se presenta en el apartado siguiente (no se puede extender a todo el sistema distribuido).

(a) Diagramas de secuencia. Los diagramas de secuencia muestran la interacción entre los objetos desde el punto de vista temporal. Los objetos se comunican intercambiando mensajes representados por medio de flechas horizontales orientadas del emisor del mensaje al destinatario. El orden de los mensajes viene dado por la posición sobre el eje vertical. Se usan básicamente para:

Documentar los casos de uso. Descripción y diseño de las operaciones de las clases.

Son documentos que, a diferencia de los diagramas de actividad y colaboración, existen siempre y que por tanto son fuente primaria para la identificación de servicios aplicando los criterios de distribución y ruptura de la funcionalidad.

Recepción Albaranes

Servidor Almacén

Captura de Pedidos

TPV Tienda

Obtener Riesgo

Servidor de Servicios Host

Recepción Facturación

Servidor de Servicios Host

Base de Datos Central

D

Base de Datos Local

Servidor Tienda

Leer Clientes

Servidor Tienda

Servidor de Impresos

TPV Tienda

• Word

D

T

D

Servir Pedidos

Servidor Almacén

Servicio de Facturación

Host

T

D

Figura 169. Arquitectura de Servicios del Diagrama de Actividades adaptado tras el diseño distribuido

237

Por todo ello, son la herramienta básica que se identifican servicios. He utilizado los diagramas de secuencia como herramienta de diseño en el pequeño ejemplo con que acaba este capítulo. Utilícelo como ejemplo de identificación de servicios sobre diagramas de secuencia.

(b) Diagramas de colaboración. Los diagramas de colaboración muestran interacciones entre objetos insistiendo en la estructura estática organizada y basada en los objetos que toman parte en la interacción y los enlaces entre los mismos. Los objetos intercambian mensajes que se representan a lo largo de los enlaces que comunican los objetos. Los pasos reflejados en cada enlace puede numerarse secuencialmente para informar del orden de ejecución. A diferencia de los diagramas de secuencia, los diagramas de colaboración muestran las relaciones entre los roles de los objetos. La identificación de servicios se hace de forma análoga a los diagramas de actividades y de secuencia. Hay, sim embargo, un importante matiz. Por su naturaleza, los diagramas de colaboración relacionan clases y no directamente operaciones por lo que solo detectaran clases que se integraran totalmente como servicios. En la figura de la derecha se muestra un ejemplo simple de diagrama de colaboración que refleja el intercambio entre dos agentes de una entidad encriptada. El análisis distribuido es tan simple que incluyo la arquitectura de servicios sin más explicación adicional. Observe la presencia de dos instancias del servicio encriptador, una en el local y otra en la Central. Observe que este es un ejemplo en que el diagrama de Localizaciones y el de Arquitectura de Sistemas no son idénticos. En este último, el servicio Encriptador nada más aparecería una vez y sería llamado por los dos agentes.

(a) Primera versión de la integración de servicios en clases.

Agente de envío

Agente de Recepción

Encriptador2. Transporte

1. Encriptación

3. Desencriptación

Agente de envío

Servidor del Local

Encriptador

Servidor del local

D

Agente de envío

Servicios en Central

Encriptador

Servicios en Central

D

T

Figura 170. Identificación de servicios en un Diagrama de Colaboración

238

Adelantemos una parte de la explicación de cómo integraremos servicios en clases. Si existe un modelo de objetos distribuidos global a toda la plataforma distribuida, bastará implementar las clases sobre él. Si no existe una plataforma de objetos distribuidos o existe un punto de heterogeneidad en el contexto que presentaré en el apartado siguiente, la identificación de servicio puede determinar que:

Toda la clase se incluya en el servicio. Haya que especializar la clase en dos o más subclases. Haya que dividir la clase. Haya que utilizarse un patrón de diseño controlador en arquitectura de distribución para conectar los dos o más entornos en que se distribuyen las funcionalidades. El controlador actuará como puerta de entrada al entorno traspasando la responsabilidad a cada una de las clases que proveen el servicio. La arquitectura necesaria puede resolverse de diversas formas. En la figura se incluyen tres posibilidades en notación MAFDRA. Las opciones master/slave y de redirección permitirían mayor eficiencia.

La clase actúe como modulo de integración de varios servicios.

Más adelante ampliaremos este punto.

5. Vistas de la arquitectura del Software. Los subsistemas y componentes se especifican normalmente en vistas:

Vista lógica. Muestra la organización del sistema en clases

Vista de procesos. Describe los flujos de control de datos. En nuestro caso incluirá la arquitectura de servicios.

Vista de desarrollo. Encapsula los elementos de diseño en módulos. Se corresponde con nuestros conceptos de:

Servicios linkados, donde cliente y servicio se lindan en un solo módulo.

Patrón Controlador

(Master)

Clase Cliente

Clase Proveedora del Servicio

1


N

Patrón Controlador

(Slave)

D

D

R M

Patrón Controlador

Clase Cliente


1


N

D

D

R

Patrón Controlador

Clase Cliente


i

A

R

Figura 171. Posibilidades de integración de servicios entre entornos

239

Servicios pasivos y activos, donde el servicio, sólo o junto a otros afines, comparten un servidor o agente.

Integración de la parte cliente, o módulos donde se lindan las funciones clientes.

Vista de despliegue. Muestra la distribución de los módulos de la vista de desarrollo por la plataforma.

Se conoce también como vista física, terminología de la que huiré aquí para evitar equívocos.

Se corresponde con nuestro concepto de localización. Vista de escenarios o casos de uso.

Muestra los usos más significativos del sistema y como afectan a las otras vistas.

Articula las otras cuatro vistas. Se habla por eso de 4+1 vistas. Se puede hablar de otras vistas: vista de datos, vista de seguridad, etc.

6. Concepto de Frontera. Fronteras y nodos.

Se denominan fronteras de la distribución a las separaciones físicas entre los componentes de sistema. El sistema se organiza en nodos separados por “fronteras” locales o remotas. Las fronteras que realmente interesa detectar son aquellas que influyen en el rendimiento del sistema, es decir, las remotas. En el resto de nuestro viaje, cuando hablemos de fronteras entenderemos en todos los casos que nos referimos a fronteras remotas. Las fronteras de la distribución condicionan las vistas de desarrollo y despliegue y están determinadas por la infraestructua del sistema distribuido, actuando como precondiciones del diseño. Un sistema absolutamente general debería diseñarse en la hipótesis de que todos los nodos están aislados por fronteras remotas. El evidente que si se actúa así, el sistema podrá adaptarse a cualquier evolución de las fronteras de remotes a locales y viceversa. Pero también es evidente que el esfuerzo de aplicar esta hipótesis es mucho mayor que si se parte de una situación menos generalista en la cual solo se identifican algunas de las fronteras como remotas. En cada caso el diseñador habrá de tomar las decisiones que el entorno aconseje reflejando las fronteras remotas como precondiciones del diseño distribuido.. En los ejemplos que siguen actuaremos como si todas las fronteras entre los nodos fueran remotas. En la práctica, cuando no sea así, podrá simplificarse el diseño actuando como si fuera no distribuido en las fronteras locales.

7. Otros factores de interés en el diseño UML distribuido.

Uso del patrón representante para minimizar el acceso a nodos remotos. Por ejemplo, no cargar todas las imágenes remotas si no son consultadas.

Uso del patrón DTO para acceso grueso en lugar de fino a los servicios de datos. Por ejemplo, recuperar toda la entidad desde el nodo remoto y tratar

240

los campos en local. La aplicación de este patrón es básica en OO donde la costumbre es acceder por atributos.

Primar los procesos por lotes en lugar de los singulares. Por ejemplo, en lugar de registrar un pedido artículo a artículo, recoger el pedido completo antes de saltar la frontera remota.

8. Arquitectura de Objetos Distribuidos en la práctica.

El siguiente paso consiste en contestar a la pregunta: ¿La arquitectura de objetos distribuidos de que disponemos es de ámbito global? Entendiendo por global la posibilidad de usarla de forma distribuida interoperable en toda la plataforma distribuida En función de la respuesta podremos actuar en dos direcciones:

Si el ámbito es global, para construir la arquitectura distribuida basta implementar las clases con los medios que proporciona el modelo de objetos distribuidos.

Ojo: nadie evita: Los análisis de arquitectura de servicios, consistencia y administración.

Preocuparse del rendimiento. Si no es global hay que analizar los puntos de heterogeneidad y actuar en consecuencia.

Los puntos de heterogeneidad que pueden localizarse en un modelo de objetos distribuidos, y la forma de actuar en cada caso, son:

Se trabaja con una arquitectura de datos distribuida que imposibilita el mapeo directo del modelo de datos de diseño a un esquema relacional.

Consecuencia: la persistencia de las clases se ha de gestionar “convencionalmente”. Servicios de datos se encapsularan en clases para resolver el metaesquema.

No existe tal plataforma de objetos distribuidos. El modelo OO es simplemente un entorno de desarrollo orientado a objetos.

Consecuencia: todos los servicios se comunican “convencionalmente”. Convivencia de más de una plataforma y/o ausencia en algunos de los nodos.

Consecuencia teórica: sólo hay que utilizar modelos de comunicación entre servicios convencionales en los saltos entre los nodos heterogéneos.

Consecuencia real: todos los servicios se comunican “convencionalmente” (sino habrá que repetir servicios o no tendríamos transportabilidad).

No se quiere usar la plataforma de objetos distribuidos en la arquitectura distribuida:

Consecuencia: todos los servicios se comunican “convencionalmente”.

241

Se fuerza una única plataforma: Consecuencia: es sistema queda distribuible, no distribuido.

Si la arquitectura de objetos distribuidos es global, el modelo de comunicaciones entre los nodos se reduce a eventos y llamadas síncronas entre clases. Las clases engloban y encapsulan uniformemente las diferentes topologías de comunicación. Si la arquitectura no es global, las clases se han de comunicar utilizando los recursos convencionales y encapsulando en operaciones de clases existentes o nuevas que se responsabilizarán de la comunicación con casuística de la petición / respuesta por el modelo escogido. Veamos un ejemplo con el servicio de datos sobre un modelo de replicación como el que se presenta en la figura de la figura. Para resolver la situación del lugar donde realizamos la instancia podemos utilizar un patrón estrategia superpuesto a otro de plantilla donde se delega a la subclase la implementación del acceso a la central mediante la operación AltaCentral() donde se realizará desde el nodo el alta en la copia de la central. Obviamente, si la situación de la instancia es la Central, la subclase correspondiente implementará vacía la operación. Si la instanciación es en el nodo, la subclase correspondiente deberá llegar hasta la central para realizar el alta. Si necesita conocer el path y no puede obtenerlo automáticamente (por ejemplo con un servicio JNDI de J2EE o ADO en .NET) debe suponerse que hay un punto de heterogeneidad. Obviamente si utilizamos uno u otro servicio la aplicación quedará distribuible y no distribuida. Ni no podemos

En presencia de un modelo OO distribuido: síncrono/eventos.Las clases encapsulan uniformemente caca tipo de comunicación.

:objeto cliente

:objeto servidor

En ausencia de un modelo OO distribuido: síncrono/asíncrono/eventos/etc.Nuevas operaciones en la clases o nuevas classes encapsulan y resuelven cada una de las tipologías de comunicación convencionales.

:objeto cliente

:objeto servidor

Figura 172. Influencia de la arquitectura OO en el modelo de comunicación

ServidorAlta

ClientesCliente Clientes en la Centr

RD

ServidorAlta



ClienteAlta()

SituaciónAlta()AltaCentral()

1 1

Alta nodo local + AltaCentral()

CentralAltaCentral()

NodoAltaCentral() Alta nodo

remoto(central)

Vacia

Servidor CentralClienteAlta()

Servidor localClienteAlta()

Resolución si hay heterogeneidad en la comunicación

Figura 173. Ejemplo de implementación de un servicio de datos

242

permitirnos esa limitación, deberemos considerar también que hay un punto de heterogeneidad. En la figura se muestra también una posible solución para resolverlo en que cada servidor, local o central, instancia su propia clase.

9. Implementación de la arquitectura distribuida sobre un modelo OO. Como consecuencia de todos los puntos que hemos analizado, podemos concretar y ampliar la integración de servicios en clases que hemos iniciado antes:

Al final, los servicios los proveen instancias de una clase, especializada o no. Los servicios son operaciones de la clase que proveen directamente el servicio o resuelven y encapsulan los puntos de heterogeneidad.

Como ya he comentado, existe la posibilidad de agruparlos por afinidades (concepto que saldrá más adelante al hablar del análisis de consistencia) a través de patrones controlador y arquitecturas de distribución.

Es necesario añadir el análisis de consistencia que puede considerarse un paso incremental de la especificación y el diseño.

La administración, excepto el cuadro de mandos, es posible que quede fuera del diseño del modelo OO ya que incluirá el uso de muchas herramientas heterogéneas no necesariamente orientadas a objetos. Conviene, sin embargo, implementar en OO.

La localización es un diagrama de despliegue. Si existe una heterogeneidad en la comunicación y queremos mantener un modelo de comunicación por eventos podemos aprovechar filosofías de vigía / disparador, ya vistas, o de publicación / suscripción, que veremos más adelante.

10. Un ejemplo. Para aplicar la metodología, le propongo un ejemplo muy sencillo sin grandes prestaciones funcionales que actúen como ramas que no escondan el tronco. Imagine que tiene un caso de uso de asignación de una materia prima a un proveedor con el que hemos pactado suministro y que, una vez asignada la materia prima al proveedor, el sistema ha de informar informa del número de proveedores que suministra la materia prima. No hace falta matizar que una misma materia prima puede suministrarla más de un proveedor. Empecemos por especificar el sistema en UML De forma muy simple, el caso de uso esencial de la especificación sería: caso de uso esencial: Asignación de proveedor a materia prima actores: Usuario, Sistema precondición: No se realizan altas de materias primas mientras se

asignan proveedores de compras. curso principal:

1. El Usuario indica al Sistema el nombre de la materia prima a la que quiere asignar un nuevo proveedor.

2. El Usuario indica al Sistema el nombre del proveedor. 3. El Sistema asigna la materia prima al proveedor. 4. El Sistema muestra al Usuario el número de proveedores que suministran la

materia prima.

243

Extensiones: 5. mp-no-existe: No existe ninguna materia prima con el nombre informado (1)

5.1. El Sistema avisa al Usuario que no existe ninguna materia prima con ese nombre

5.2. Vuelve al paso 1 del escenario principal 6. prov-no-existe: No existe ningún proveedor con el nombre informado (2)

6.1. El Sistema avisa al Usuario que no existe ningún proveedor con ese nombre.

6.2. Vuelve al paso 2 del escenario principal. 7. ya-asignada: La materia prima ya está asignada al proveedor (2)

7.1. El Sistema avisa al Usuario que el proveedor ya sirve la materia prima. 7.2. Vuelve al paso 1 del escenario principal.

Y suponga que dentro del modelo conceptual de datos de especificación, que se muestra en la figura, se incluyen las clases Materia Prima y Proveedor y que existen las restricciones de integridad textuales:

No existen dos productos con la misma referencia ref.

No existen dos analíticas con el mismo NIF.

No existen dos ocurrencias de la relación Suministra con la misma materia prima y proveedor.

Para cumplir con el caso de uso se necesitará una operación de sistema con un contrato informal del estilo: asignarProveedor(ent mp: String, ent pr: String) Retorno: Entero Precondiciones: Postcondiciones:

2. En la operación: 2.1. La materia prima mp se asigna al proveedor pr. 2.2. Se devuelve el total de proveedores que suministran la materia prima.

Pasemos ahora a la etapa de diseño. Se decide utilizar un patrón arquitectónico de tres capas para implementar este caso de uso a través de una interfície gráfica.

*

Compra

*

*

*

*

11

*

ref: Stringnom: String

Producto

densidad: Real

Materia Prima

costFabr: RealpreuVenta: Real

Producto Venta

Liquido

Capacidad: Real

Envase

dia: Date

Fecha

precioVenta: Realcantidad: Real

Consumo

NIF: Stringnom: Stringdir: String

Analítica

Proveedor Cliente

costeComp:Real

Suministra

Figura 174. Modelo conceptual de especificación

:Usuario :Sistema

asignarProveedor(mp, pr): entero

Figura 175. Diagrama de secuencia del caso de uso

244

Empezaremos por realizar la normalización del esquema conceptual de especificación y obteniendo así el de diseño que se muestra en la figura. Observe que las relaciones binarias y ternarias se en implementado como nuevas clases.

Después de realizar la normalización revisamos si las restricciones de integridad afectan a las operaciones que vamos a diseñar. En este caso, el contrato de la operación assigarProveedor debe ser modificado añadiendo las comprobaciones: asignarProveedor(ent mp: String, ent pr: String, out totalPrv: entero) Retorno: Booleano Precondiciones: Postcondiciones:

1. La operación devuelve falso y no hace hada si: 1.1. mp no corresponde a una materia prima válida. 1.2. pr no corresponde a un proveedor válido. 1.3. el proveedor pr ya suministra la materia prima mp.

2. En caso contrario la operación es correcta, devuelve cierto y: 2.1. La materia prima mp se asigna al proveedor pr. 2.2. En el argumento totalPrv se devuelve el total de proveedores que

suministran la materia prima. La necesidad de realizar el retorno del error obliga a tratar como un parámetro de salida el total de proveedores que suministran la materia prima.

*

Compra

1 1

1

*

*

1*

11

*

ref: Stringnom: String

Producte

densitat: Real

Materia Primera

costFabr:DinerpreuVenda:Diner

Producte Venda

Liquid

Capacitat: Real

Envas

data: Date

Data

preuVenda:Dinerquantitat:Real

Consum

NIF: Stringnom: Stringdir: String

Analítica

Proveïdor Client

costComp:Diner

Suministra* 1

Figura 176. Modelo conceptual de diseño

245

A continuación realizaremos el análisis de la interfície gráfica para la que se propone la maqueta de la figura con el objetivo de filtrar el mayor número de errores posibles en la capa de presentación. En la interfície gráfica se incluyen los siguientes componentes:

LMP - Materia Prima: una lista desplegable con todas las materias primas de la empresa (la precondición del caso de uso supone que no hay altas mientras se ejecuta la asignación).

LPR - Proveedor: una lista desplegable con todos los proveedores que todavía no suministran la materia prima situada en la cima del desplegable de materias primas.

PMP - Número actual de proveedores: un cuadro de texto donde se mostrará el número total de proveedores que suministrarán la materia prima.

Registrar - Botón para registrar la nueva relación.

Acabar – Botón para finalizar el caso de uso. Dialogo - Un cuadro de edición multilínea para mostrar los mensajes de diálogo y/o error.

Se decide el siguiente flujo de dialogo.

El operador escoge una materia prima de la lista. El sistema muestra al operador la lista de proveedores de materias primas que todavía no la suministran.

El operador elige un proveedor de la lista. El operador pulsa Registrar El sistema establece la relación. El sistema muestra el número total de proveedores que suministran la materia prima.

El proceso se repite hasta que el operador pulsa Acabar. Con este flujo de diálogo y la interfície gráfica diseñada, el caso de uso concreto será: caso de uso concreto: Asignación de proveedor a materia prima actores: Usuario, Sistema precondición:

1. Todas las materias primas entre las que puede elegir el Usuario son válidas. 2. No se realizan altas de materias primas mientras se asignan proveedores de

compras curso principal:

Materia Prima:

Proveedor:

(cuadro de diálogo con el operador)

Registrar Acabar

Número actual de proveedores :

Figura 177. Interfície gráfica de la operación

asignarProveedor()

246

1. El Usuario indica al Sistema el nombre de la materia prima a la que quiere asignar un nuevo proveedor eligiéndola de la lista desplegable.

2. El Sistema presenta al Usuario la lista con los proveedores que todavía no sirven la materia prima elegida.

3. El Usuario indica al Sistema el nombre del proveedor eligiéndolo de la lista desplegable.

4. El Usuario pulsa el botón Registrar. 5. El Sistema asigna la materia prima al proveedor. 6. El Sistema muestra al Usuario el número de proveedores que suministran la

materia prima. 7. Se vuelve al punto (1)

Extensiones: 8. pulsado_acabar: El usuario desea acabar el caso de uso (cualquier momento)

8.1. El Sistema cierra la interfície gráfica. En estas condiciones el servicio que la capa de dominio ha de suministrar a la capa de presentación para cumplir con la operación será: asignarProveedor(ent mp: String, ent pr: String, out totalPrv: entero) Retorno: Precondiciones

1. mp corresponde a una materia prima válida. 2. pr corresponde a un proveedor válido. 3. el proveedor pr no suministra la materia prima mp.

Postcondiciones: 2. La operación se ejecuta y:

2.1. La materia prima mp se asigna al proveedor pr. 2.2. En el argumento totalPrv se devuelve el total de proveedores que

suministran la materia prima. Opcionalmente, y ya que ha desaparecido la necesidad de controlar errores, podríamos haber devuelto el parámetro totalPrv a retorno en lugar de mantenerlo como parámetro de salida. Para cumplir su función, la capa de presentación necesita nuevos servicios de la capa de dominio: listaMateriasPrimas(): Set(String) Retorno: Devuelve los nombres de las materias primas de la Compañía. Postcondiciones:

2. Se devuelve un conjunto con las materias primas válidas. listaProveedores(ent mp: String): Set(String) Precondiciones

1. mp corresponde a una materia prima válida. Postcondiciones:

2. Se devuelve un conjunto con los proveedores que todavía no suministran la materia prima mp.

finCasoDeUso() Así pues, la capa de presentación comunicará con la capa de dominio a través de un controlador con los servicios:

asignarProveedor() lanzado con el evento de clikado del botón Registrar

247

listaMateriasPrimas() lanzado con el evento de creación de la interfície gráfica listaProveedores() lanzado con el evento de cambio de contenido de la cima de la lista desplegable de materias primas

finCasoDeUso() lanzado con el evento de clikado del botón Acabar. En un ejemplo tan sencillo, no cuesta demasiado ver que la capa de dominio necesitará de la capa de datos los servicios: obtenerMP(): Retorno: Set(String). Precondiciones: Postcondiciones:

2. Se devuelve un conjunto con las materias primas válidas. obtenerPR(ent mp: String) Retorno: Set(String). Precondiciones


2. Se devuelve un conjunto con los proveedores que todavía no suministran la materia prima mp.

asignarPR(ent mp: String, ent pr: String) Retorno: Precondiciones

1. mp corresponde a una materia prima válida. 2. pr corresponde a un proveedor válido. 3. el proveedor pr no suministra la materia prima mp.

Postcondiciones: 2. La materia prima mp se asigna al proveedor pr.

totalPR(ent mp: String) Retorno: Entero. Precondiciones


2. Se devuelve el número total de proveedores que suministran la materia prima mp.

Es decir, la capa de dominio comunicará con la capa de presentación a través de los servicios:

obtenerMP(): utilizado para implementar la operación listaMateriasPrimas(). obtenerPR(): utilizado para implementar la operación listaProveedores(). asignaPR(): utilizado para implementar la operación asignarProveedor(). totalPR(): utilizado para implementar la operación asignarProveedor().

Finalmente, para completar el flujo de diálogo diseñado, la interfície gráfica ha de disponer como mínimo de las siguientes operaciones:

inicializar() la lista desplegable LMP. cambia() la cima de la lista LMP - desplegable de materias primas. inicializar() la lista desplegable LPR. escogerProveedor() sobre la cima de LPR que serán las propias primitivas proporcionadas por la clase lista desplegable.

248

pulsado() el botón registrar para realizar la asignación. poneTexto() en el cuadro PMP para informar del total de proveedores que suministran la materia prima.

pulsado() el botón Acabar para finalizar el caso de uso. Con todo ello, el diagrama del caso de uso concreto será el que se muestra en la figura. A continuación atacaríamos el diseño de completo de cada capa.

Diseñamos el controlador de la capa de dominio con el patrón controlador transacional que se muestra en la figura. Las llamadas y relaciones entre todos estos servicios quedarían detalladas en los respectivos diagramas de secuencia del diseño completo. Una posible solución se desarrolla en los diagrama de secuencia que se muestran a continuación.

Usuario Ventana Capa de Dominio Capa de DatoslistaMateriasPrimas()

obtenerMP()

Registrar:: pulsado()

listaProveedores()obtenerPR()

asignarProveedor()

LMP::cambia()

escogeProveedor()

Acabar:: pulsado ()

loop

PMP::poneTexto()

LPR::inicializar()

LMP::inicializar()

finCasoDe Uso()

asignarPR()totalPR()

[No pulsado acabar]

Figura 178. Diagrama de secuencia del caso de uso concreto.

mp: Stringpr: StringTotalPrv; Date

:TxAsignarProveedor

ejecutar()TxAsignarProveedor(mp,pr)

ejecutar()

Transacción

resultado: Set(String):TxListaMateriasPrimas

ejecutar()obtieneResultado():

Set(String)TxListaMateriasPrimas()

mp: Stringresultado: Set(String)

:TxListaProveedores

ejecutar()obtieneResultado():

Set(String)TxListaProveedores()

Figura 179. Controlador transaccional para comunicar las

capas de presentación y de dominio

249

El programa que realiza la interacción con el usuario deberá empezar por instanciar la ventana (APMP) que implementa la interfície gráfica diseñada. El diagrama de secuencia correspondiente se muestra en las dos figuras de la derecha.

APMP: Ventana

LMP: Desplegable(cx1, cy1, ..., “LMP”)

(dim, “Asignación de proveedor a materia prima”, ...)

Registrar: Botón(cx4, cy4, ..., “Registrar”)

Acabar: Botón(cx5, cy5, ..., “Acabar”)

CP: Programa

creación()

añadirComponenteVisual(LMP)

Diálogo: Área de texto(cx6, cy6, ... “Diálogo”)

inicializar()

.. Y evadir el resto de componentes creados.

mostrar()

LPR: Desplegable(cx2, cy2, ..., “LPR”)

PMP: Cuadro de texto(cx3, cy3, ..., “PMP”)

Figura 180. Diagrama de secuencia de la creación de la ventana

APMP :Ventana

tx: TxListaMateriasPrimas()inicializar()

Coloca lmp en la llista

Col.loca lmp[1] en la cima

ejecutar()tx

lmpobtieneResultado()

LMP: Desplegableinicializar(lmp)

Coloca blancos en el texto

PMP: Cuadro de TextolimpiaTexto()

cambiaLMP()

Coloca blancos en el texto

Diálogo: Área de TextolimpiaTexto()

Figura 181. Diagrama de secuencia de la creación de la ventana.

Inicialización

250

Tal como hemos diseñado, al cambiar la cima de la lista desplegable de materias primas habrá de cargarse en el desplegable de proveedores la lista de los que todavía no suministran esa materia prima. El diagrama de secuencia correspondiente se muestra en la figura de la izquierda. En la misma figura se muestra la reacción al botón de Acabar. No está desarrollado el proceso de

finalización ya que dependerá del total del sistema en que está incluido y no aportaría nada significativo al ejemplo. La reacción al botón de Registrar será realizar la asignación del nuevo proveedor a la materia prima escogida. El diagrama de secuencia de la operación de la ventana que reacciona se muestra en la figura de la derecha. Finalmente, habrá que completar el diseño de los servicios de la capa de dominio que interaccionarán con la capa de datos. Puede optarse por dos soluciones:

Diseñar un controlador para agrupar los servicios de datos a dominio de forma análoga a como hemos hecho entre presentación y dominio.

alt

APMP :Ventana

cambiaLMP()

tx: TxListaProveedores(mp)

Coloca lp en la lista

Coloca lp[1] en la cima

ejecutar()

[lp está vacío]

lpobtieneResultado()

LPR: Desplegable

inicializar(lb)

LMP :Desplegable cambia()

APMP :Ventana

pulsadoAcabar()

Acabar :Botón

pulsado() Acabar el caso de uso solicitado el servicio finCasoDeUso()

LMP: DesplegableobtieneCima()

mp

[lp no está vacío]

Dialogo: Àrea de texto

poneTexto(“no hay proveedores”)

Figura 182. Diagrama de secuencia de la actualización del desplegable de

proveedores al cambiar la cima del desplegable de materia prima

APMP :Ventana

pulsadoRegistrar()

tx: TxAsignarProveedor(mp,pr)

ejecutar()tx

Registrar :Botón pulsado()

LMP: DesplegableobtieneCima()

mpLPR: Desplegable

obtieneCima()

pr

ObtenerTotalPrv()

totalPrv

PMP: Cuadro de TextoponeTexto(Texto(totalPrv)

Figura 183. Diagrama de secuencia de la reacción al botón Registrar para

asignar el proveedor a la materia prima.

251

Permitir que la capa de dominio pida directamente los servicios a la capa de datos.

He escogido la segunda solución por dos razones:

La operación del ejemplo es tan sencilla que de hecho podría montarse en dos capas.

Mostar otra opción de integración entre capas. En la figura de la derecha se muestran los diagramas de secuencia de la interacción de los servicios de la capa de dominio con la de datos. Observe que me limito a hablar de servicios que atacan la base de datos. Eso es así, porque en los próximos pasos hablaremos de diferentes formas de integración y este montaje genérico nos dará más juego. Ya estamos en condiciones de atacar ahora el diseño distribuido. Supondremos que

Disponemos de una arquitectura física de tres niveles: central, servidor departamental y máquinas cliente.

La arquitectura de datos es centralizada y el gestor relacional esta situado en el nodo de la central.

El análisis de consistencia deberá prever el fallo de los servicios que se decida montar como activos. Para simplificar, supondremos que la decisión será simplemente esperar que el servicio se recupere y volver a pedir el registro.

Vamos a analizar a continuación diferentes soluciones para la vista de desarrollo. (a) Presentación y dominio agrupados.

Si suponemos que no hay frontera entre las capas de presentació y dominio pero si entre dominio y datos, obtenemos una arquitectura lógica de dos niveles: cliente y central. Con esta decisión:

Son servicios pasivos linkados con el programa cliente:

:TxListaMateriasPrimasejecutar()

:Base de datos

obtenerMP()lmp

Servicio que devuelve todas las materias primas.

:TxListaProveedoresejecutar() obtenerPR(mp)

lp

:TxAsignarProveedorejecutar()

v: Pasarela Sumistro(mp,pr)

asignaPR():Base de datos

Servicio que resuelve la asignación de la relación

Servicio que devuelve todos los proveedores que no suministran todavía la materia prima

resultado=lp

totalPR(mp)

Servicio que devuelve el total de proveedores que suministran la materia prima

tp

totalPrv=tp

insertar()

Figura 184. Diagrama de secuencia de los servicios de la capa de datos.

252

asignarProveedor. listaMateriasPrimas. listaProveedores. finCasoDeUso.

Son servicios activos suministrados por el motor de la base de datos: Con comunicación ODBC-SQL:

asignarPr. totalPR.

Con procedimiento catalogado: ObtenerMP. ObtenerPR.

Para simplificar, he aprovechado el diagrama de caso de uso concreto para documentar la arquitectura de servicios. El cuadro corresponde a las funciones agrupadas en el programa cliente que interacciona con el usuario.

(a) Presentación y dominio separados sin mantener el controlador. Si suponemos ahora que hay tambien frontera entre las capas de presentación y de dominio, obtenemos una arquitectura lógica de tres niveles: cliente, servidor departamental y central. Con esta decisión todos los servicios son activos:

Suministrados por servidores: asignarProveedor. listaMateriasPrimas. listaProveedores. finCasoDeUso (podría valorarse dejarlo como pasivo según cual fuera el proceso a realizar para acabar el caso de uso.

Son servicios suministrados por el motor de la base de datos: Con comunicación ODBC-SQL:

asignarPr. totalPR.

Con procedimiento catalogado: ObtenerMP.

Usuario Ventana Capa de Dominio Capa de DatoslistaMateriasPrimas()

obtenerMP()


listaProveedores()obtenerPR()

asignarProveedor()asignarPR()

LMP::cambia()

escogeProveedor()

Acabar:: pulsado ()

PMP::poneTexto()

LPR::inicializar()

LMP::inicializar()

finCasoDe Uso()

RtotalPR()

R

R

R

Figura 185. Implementación 1.

253

ObtenerPR.

(a) Presentación y dominio separados manteniendo el controlador. Supongamos ahora que hay frontera entre las capas de presentación y dominio pero no entre ésta y la de dagtos. Es una variación de la anterior en la cual el controlador se mantiene como servidor en una arquitectura de distribución y los servicios de la capa de dominio son linkados y están incluidos en el controlador.

Desarrollemos, finalmente, los diagramas de despliegue suponiendo que elegimos la implementación del apartado 5.2. En ese supuesto:

La integración de la parte cliente nos proporcionaría el programa Asignación de Proveedor de integración gráfica.

Obtenemos los servidores: Obtener Materias Primas para el servicio listaMateriasPrimas(). Obtener Proveedores para el servicio listaProveedores(). Asignar Proveedor para el servicio AsignarProveedor().

Se necesitan los procedimientos catalogados: ObtenerMP para obtener la lista de materias primas de la base de datos. ObtenerPR para obtener la lista de materias primas de la base de datos.

Crearemos los servicios de datos SQL integrados como servicios pasivos en le servidor Asignar Proveedores:

AsignarPR para registrar la asignación sobre la base de datos.

Usuario Ventana Capa de Dominio Capa de DatoslistaMateriasPrimas() obtenerMP()


listaProveedores() obtenerPR()

asignarProveedor() asignarPR()

LMP::cambia()

escogeProveedor()

Acabar:: pulsado ()

PMP::poneTexto()

LPR::inicializar()

LMP::inicializar()

finCasoDe Uso()

R

totalPR() R

R

R

D

D

D

D

Figura 186. Implementación 2.

254

TotalPR para obtener el número total de proveedores que suministran la materia prima.

A modo de ejemplo, supondremos que disponemos de la plataforma de sistema descrita en el diagrama de despliegue de sistemas de la figura de la derecha. Esta plataforma define una arquitectura física de tres niveles. Sobre ella construiremos la

arquitectura lógica de tres niveles que se muestra en la figura de la izquierda con un nivel de servicios sobre el HOST para envolver las aplicaciones corporativas, otro sobre el servidor departamental para los servicios del departamento y los puestos de trabajo sobre los PC’s. Aunque es este ejemplo no es necesario, conviene remarcar que, como se muestra en el diagrama de niveles lógicos, la aplicación de compras heredada sobre el HOST estaría envuelta por una capa de servicios para dejarla integrada en el sistema distribuido.

<<Host>>

IBM370

•Aplicaciones Heredadas

•Oracle

<<Servidor deCompras>>

PC

•Windows1 1

<<Puesto de trabajode Compras>>

PC

•Windows

TCP/IP

1

*

TCP/IP

Figura 187. Diagrama de Sistemas de Asignar

Proveedor.

Servicios en la Central

HOST

•Aplicación de compras•Servicios de envolvente

Servicios deCompras

Servidor de Compras

1 1

Gestión de Compras

Puesto de trabajo de Compras

1

*

Figura 188. Diagrama de Niveles Lógicos de

Asignar Proveedor.

255

Sobre está arquitectura lógica realizaremos la localización de los servicios de la vista de despliegue. En la figura de la derecha se establece la arquitectura de servicios resultante del diseño, que se incluye dentro de la vista de procesos. Dada la sencillez del ejemplo, he aprovechado un único diagrama de despliegue para reflejar los diagramas de la Arquitectura de Sistema y de la Localización.

Asignar Proveedor

Servicios de Compras

Programa de Asignación de

Proveedor

Gestión de Compras

Obtener Materias Primas


1*

Obtener Proveedores


Base de datos Central

Servicios en la Central

•Oracle1* D

1

*1

*

1

*

D

1

*D

Figura 189. Diagrames de Servicios y de Localización de Asignar

Proveedores.


Datos y Diseño Distribuido 1. Introducción.

Todo lo que encontrará sobre datos y distribución en este y los capítulos siguientes es una continuación del tema desarrollado en la primera parte dedicada a introducir los principios básicos de una arquitectura distribuida. Conviene que, si no recuerda bien los conceptos allí desarrollados, los repase antes de seguir.

2. Criterios generales de partida. Como se explicó en la primera parte,

Los datos son un tema “duro” en los diseños distribuidos. Basta tener presente el cuadro de clasificación de los datos presentado en la primera parte.

Hay una gran alternativa inicial: datos centralizados, fáciles de administrar pero con tráfico de líneas, versus datos distribuidos, con menor tráfico de líneas pero más difíciles de administrar.

El Upsizing de sistemas de información obliga normalmente a un esfuerzo adicional de diseño para resolver las diferencias semánticas y sintácticas. Recuerde que hay otras situaciones asimilables al Upsizing.

En este y los siguientes capítulos vamos a desarrollar temas relacionados con el modelo de datos para completar lo que necesitamos sobre este asunto para el diseño distribuido.

3. Centralizar versus distribuir: Resumen de modelos lógicos del datos. Centralizar datos (aprovechando todas las ventajas de la integridad, seguridad, back-up, etc.) o distribuirlos (aprovechando las ventajas de accesibilidad y minimización de tráfico de redes y comunicaciones) es la gran polémica y el mayor problema del diseño distribuido. No hay “varitas mágicas”. Cada aplicación es diferente y sus necesidades condicionan y conducen hacia la solución más adecuada. En particular el análisis de consistencia marcará en gran manera muchas de las posibles soluciones si hay que garantizar servicio en caso de caída de los servidores de datos de la red. Además con anchos de banda apropiados se puede disponer de un modelo distribuido muy centralizado físicamente por lo que la administración puede hacerse “en local”. Pero como en todo lo demás, se puede disponer “a priori” de modelos, estrategias y métodos entre los cuales se elegirá para crear la solución final.


Es importante darse cuenta que desde el punto de vista de la lógica de proceso de los programas hay 4 casuísticas bien diferenciadas: 3. 1. Datos en servicios en nube.

No existen para los clientes y usuarios. La responsabilidad es de los constructores (diseño) y suministradores (administración).

3. 2. Datos centralizados.

A la hora de programar son un único bloque lógico. A la hora de administrar y según el tipo del modelo:

Unificados: un único bloque físico. Sin problemas de diseño ni administración.

Repartidos: más de un bloque físico. Posibles problemas de diseño, resueltos habitualmente por el motor de la base de datos, de:

Tiempo de acceso. Análisis de consistencia.

Necesidad de análisis de administración para la integridad de los datos. Normalmente a cargo del motor de la base de datos.

Dicho en otras palabras, en el caso de centralizadas repartidas, si el motor se comporta, los datos se han de tratar como centralizados, sino no hace, los datos se diseñan como distribuidos. Si el motor se comporta, además, solo habrá que gestionar las políticas de copias de seguridad para garantizar la consistencia de las copias.

3. 3. Datos distribuidos.

Deben agruparse dos casos:

3.3.1. Homogéneos. A la hora de programar son un único bloque lógico con puntos de heterogeneidad de velocidad de acceso si alguna de las copias físicas está accesible sólo por una vía de baja velocidad. Necesitan trabajar la consistencia e integridad de los datos en del diseño y en la administración

A la hora de administrar con más de un bloque físico lo que obliga a trabajar el análisis de administración de sistema. Los modelos gestionados a efectos de diseño como datos distribuidos homogéneos son:

Centralizados repartidos en que el motor de BD no se comporta igual en todos los nodos. Hoy, y desde la unificación de los servidores de datos bajo SQL, prácticamente desaparecido. Particionados:

Verticalmente.


Horizontalmente. En diseño hay que disponer de un criterio para la localización de los registros.

Integrado homogéneo. Replicado.

Debe añadirse una política de replicación.

3.3.2. Datos distribuidos heterogéneos. A la hora de programar hay más de un bloque lógico lo que obliga a sofisticar la lógica de datos que habrá que encapsular en su totalidad A la hora de administrar son más de un bloque físico con las mismas incidencias que cualquier otro modelo con estas características. Solo pertenecen a este grupo aquí los modelos integrados heterogéneos incluyendo el Upsizing. Recuerde, finalmente, que en la realidad conviven en un solo sistema de información más de uno de estos modelos.

4. Esquemas de niveles de datos.

Tradicionalmente las arquitecturas de datos se han esquematizado en un grafo como el de la figura, donde S representa el servidor que ataca el software a través del Middleware y las copias físicas quedan accesibles a través de él.

Cuando los modelos eran simples, el esquema era visualmente muy válido. Pero si intenta hacer un esquema de todos los casos que le presenté en la clasificación de los datos extendida, verá que el trabajo no es simple y no aporta, en el fondo, nada fundamental ya que lo que importa es la visión lógica para la programación y la

visión física para administrar y gestionar la consistencia. De cualquier forma, en la profundización de los modelos de datos que visitaremos en los siguientes capítulos presentaré el esquema correspondiente.

5. ¿Por qué definir y usar modelos de datos? En la primera parte se han presentados los diferentes tipos de modelos de datos que pueden presentarse en un entorno distribuido que, como vimos, se establecen en función de la visión lógica que el diseño tiene de los datos y en función de la localización física necesaria. Los modelos de datos, como en cualquier rama de la ingeniería permiten:

Tipificar comportamientos. Normalizar soluciones aplicables a problemas parecidos. Asimilar el comportamiento de cada modelo a una visión lógica de proceso.

Figura 190. Esquematización de la

arquitectura de datos


6. Arquitectura de datos distribuidos.

Tradicionalmente se hacía una presentación de los modelos de datos distribuidos como la que se muestra en la figura. Con ella se pretendía ayudar a conocer que contenido tenía cada modelo. Está tan obsoleta que no la presenté ni en la introducción. La adjunto aquí como curiosidad. De hecho, hay dos formas básicas de distribuir datos: replicar y particionar. Las arquitecturas distribuidas suponen como mínimo la

presencia de dos niveles. Los servidores A y B dan servicio a sus respectivos entornos y C da servicio a todos los usuarios. La interacción entre el primer y segundo nivel depende del tipo de distribución. Así, C tiene:

Un índice, para datos particionados Las fuentes de datos para datos replicados.

7. Bases de datos y sistemas distribuidos. Hoy día sería un grave error pensar arquitecturas distribuidas sin organizar los datos dentro de una base de datos relacional. El resto de tipos de base de datos no han tenido éxito. Parto de la base que el lector conoce SQL. Si no es así deberá consultar documentación especializada antes de seguir. Trabaje siempre sobre estándares ya que así sus aplicaciones serán totalmente transportables desde la perspectiva de la lógica de datos. La única excepción son los procedimientos catalogados que ligan el programa al motor escogido. Sin embargo, aún así siempre tendrá la opción de reprogramarlos cuando cambie de motor. Podrá así, utilizar desde grandes motores ORACLE e INFORMIX, a intermedios como SQL Server y pequeños como Access. Como parte del modelo de datos, sobre todos en temas de consistencia, no hay que olvidar los ficheros XML

ABCDEFGHIJKLMNOPQR

ABCDEFGHIJKLMNOPQR

ABCDEFGHIJKLMNOPQR

ABCDEFGHIJKLMNOPQR

ABCDEF

GHIJKLMNO

PQR

ABGJMPBHKNQCFILOR

GHIJKLMNO

Replicadas

Particionadas

Reorganizadas

Replicadastemporalmente(Cached)

Figura 191. "Visión" de los modelos de datos

Figura 192. Arquitectura de datos distribuidos


8. Arquitectura de los Datos del Sistema Distribuido. Una vez acabado el análisis funcional se tiene el diseño lógico de los datos reflejado en un esquema conceptual de especificación. En algunas metodologías, como UML, el modelo se ajusta en la etapa de diseño para obtener el modelo lógico de diseño que, a efectos de datos no suele variar mucho en la mayoría de los casos. Eso hace que en muchos casos se siga hablando siempre de modelo conceptual de datos en todo el proceso de diseño distribuido. En general, vamos a seguir aquí ese criterio. Desde ese punto de partida, al diseñar la arquitectura distribuida de datos, si el modelo escogido es centralizado el esquema conceptual se implementa en un esquema interno que corresponde al diseño físico. En un entorno distribuido las cosas no son tan simples. Por factores de eficacia, coste y disponibilidad el esquema lógico “se trocea” y reparte por la arquitectura distribuida según los modelos de datos que le he presentado anteriormente. El conjunto resultante constituye la Arquitectura de los Datos del Sistema Distribuido. Sobre esta arquitectura se basará la lógica de datos. Y la estructura de los datos será una de las causas de que esa lógica se encapsule o no en servidores. Los otros dos grandes motivos serán los procesos complejos y las reglas de negocio. Así la arquitectura de los datos se convierte en el primer e importante paso para empezar a identificar los servidores de nuestro sistema distribuido. Personalmente pienso que la importancia de los datos es tanta que la arquitectura de los datos debe estudiarse de forma individualizada en la primera etapa del diseño de la arquitectura distribuida. De forma resumida, la estrategia para construir la arquitectura de los datos del sistema distribuido a partir del esquema conceptual lógico del funcional es:

Distribuir los datos según los modelos eliminado las características especificas: centralizado: distribuido homogéneo, distribuido heterogéneo y replicación.

Identificar, analizar y modelar los datos que no están en BD Realizar la localización física. Ajustar los recursos de conectividad y Middleware. Reajustar la arquitectura para minimizar el tráfico. Identificar los servidores de lógica de datos y establecer el flujo entre ellos. Decidir usar mecanismos (como los procedimientos catalogados) para mejorar la eficacia del modelo.

Cuando lleguemos al análisis de la consistencia veremos que como resultados de él, pueden proponerse cambios en la arquitectura inicialmente propuesta.

9. Upsizing. Recuerde el problema que le presenté con los datos resultantes de un proceso de Upsizing.


Hoy día, la gestión por Middleware de los esquemas de datos de las BD heterogéneas son muy pobres y poco estándares. El problema ha de ser resuelto por Middleware de usuario. La forma habitual es encapsular las heterogeneidades semánticas y sintácticas en servidores de lógica de datos.

10. Recordatorio importante.

A partir de este punto trabajaremos para conducir todos los casos a los conceptos lógicos de arquitectura de datos presentados en del apartado: Centralizar versus distribuir: Resumen de modelos lógicos del datos


Modelo Centralizado 1. Introducción.

El modelo centralizado fue el primero. Repase si no recuerda lo que hablamos en la primera parte. Poca cosa más podemos añadir aquí.

2. Modelo centralizado de datos. Recordemos que desde el punto de vista de administración y programación son el modelo más cómodo pero que presentan el problema del tráfico de líneas y de la ventana de disponibilidad. Recordemos también que hay varias combinaciones. En particular conviene citar los modelos centralizados con más de un esquema físico y los modelos centralizados de nivel departamental. Recordemos que puede haber dos situaciones: 2. 1. El modelo pequeño.

Suele tener un solo esquema físico y solo accesos en red local. No suele tener puntos de heterogeneidad por conexiones lentas. El diseño y la administración en simple.

2. 2. Modelo grande. La terminología “grande” suele obedecer a uno o combinación de más de uno de estos factores:

Número alto de usuarios. Conexiones lentas. Más de un esquema físico.

Suele apoyarse sobre gestores de bases de datos de gran potencia transaccional capaces de soportar gran número de clientes. El diseño en fácil ya que la presencia de monitores transaccionales de gran potencia suele minimizar la presencia de heterogeneidades por conexiones lentas. La única complicación, aunque mínima con las herramientas administrativas de hoy día, suele ser la administración cuando existe más de un esquema físico.

Figura 193. Modelo centralizado

pequeño.

Figura 194. Modelo centralizado grande.


Corresponden habitualmente a aplicaciones de tipologías jerárquicas y modelos de presentación de datos. En el ámbito de diseño se ataca un sólo esquema conceptual y la única salvedad es controlar los puntos de heterogeneidad por comunicaciones lentas si hay algún esquema interno físico conectado por una vía de baja capacidad.

3. Gestión de más de un esquema físico.

El tratamiento de más de un esquema físico dentro de un modelo centralizado está muy ligado a las posibilidades que aporte el Middleware asociado al motor de la base de datos utilizado. Si ese Middleware incluye las funciones de programación, para mantener la coherencia de los datos, y de administración, el problema estará resuelto desde el punto de vista del diseño. Si no es así, el diseño habrá de aportar la lógica de datos necesaria para gestionar la distribución física. La arquitectura habitual es un servidor en la parte cliente que trabaja por delegación de trabajo con otro situado encima de cada base de datos. Obviamente habrá un servidor por cada esquema físico. Como ya hemos dicho antes, la forma de enfocarlo es igual que si el sistema fuera distribuido por lo que todo lo que muchas cosas de las que diremos a continuación serán válidas aquí. El formato del mensaje serán las sentencias SQL. No confundir esta arquitectura con una pasarela ya que el servidor de la parte cliente ha de asumir el control de la coherencia de los datos. El esquema es, en el fondo, la gestión de datos particionados por lo que muchas de las técnicas que veremos más adelante podrán utilizarse aquí si el problema se complica.

Replicación 1. Una observación inicial.

Hablar de replicación suena a pasado. La replicación tuvo su origen y auge, en funciones y problemas, en la época en que los sistemas distribuidos no disponían de las facilidades de conectividad actuales. Se dice que la replicación está en claro retroceso. Nada más cierto y nada más falso. La cantidad de replicaciones debe disminuir espectacularmente por la supresión de la causa que supuso su expansión: las limitaciones en las comunicaciones. Pero no olvidemos que cuando estamos haciendo una concentración de datos en Data Warehouse o integrando un entorno Upsizing o preparando los datos de una WEB estamos replicando. Que cuando enviamos datos a un puesto de venta para garantizar su autonomía estamos replicado, aunque al final esos datos de guarden en un fichero XML. Y que cuando concentramos servicios físicamente para abaratar la administración sin modificar arquitecturas de software seguimos replicando. En pocas palabras la replicación sigue siendo un tema, aunque duro, plenamente necesario y actual aunque haya disminuido la frecuencia de utilización.

2. Arquitectura de Datos Replicados. La arquitectura de datos replicados consiste en la coexistencia de múltiples copias de parte de los datos del entorno distribuido: una o más fuentes a uno o más destinos, llamados también copias o replicas.

En la arquitectura de niveles que estamos viendo, los servidores A y B contienen los mismos datos que C.

Como ya se vio en el capitulo de datos de la primera parte, la replicación puede ser por copia, reorganización o sumarización. Revise, si no lo recuerda, todo lo dicho allí para este tema. No voy a repetirlo. El hecho de que sea por copia, sumarización o reorganización es solo una particularidad. Evidentemente todo lo que hay que hablar sobre datos replicados es independientemente de la forma en que se han replicado. Replicar puede parecer una solución fácil, pero solo es así superficialmente. A poco que se recapacite, aparecen problemas de todo tipo para garantizar la coherencia de los datos entre la fuente y los destinos.

Figura 195. Esquema de datos replicados.

265

Esto ha hecho que una solución alternativa a la replicación sean las aplicaciones Internet. En este punto el solape de ámbito entre las aplicaciones de tecnología C/S basado en sistema operativo e Internet es claro. A final de este capítulo, cuando hayamos desarrollado en su totalidad el tema de la replicación valoremos cuando utilizar una u otra solución.

3. Gestión de datos replicados. Las razones más frecuentes para replicar datos son:

Velocidad de la conexión frente al volumen transportado Resolver conexiones lentas. Tener autonomía de trabajo en el puesto cliente. Disminuir el tráfico de datos por la red, local o remota. Resolver diferencias semánticas y sintácticas. Limitar accesos por criterios de seguridad.

La gran desventaja es el mantenimiento. Cualquier modificación de los servidores de primer nivel ha de ser propagada a todas las replicas. Uno de los parámetros básicos a establecer es la periodicidad de esa replicación que se ha de montar en un proceso de forma desatendida con intervención del administrador sólo en caso de incidencias. El control mediante tickets es muy cómodo y flexible. La protección y coherencia de los datos no son triviales. Eso hace necesario la planificación de procesos de auditoria y recuperación de la coherencia y consistencia de los datos.

4. Terminología de datos replicados. 4. 1. Replicación síncrona o asíncrona.

En la replicación síncrona cada transacción de mantenimiento modifica todas las copias existentes “tan rápido como se pueda”. Pero recuerde, ¡nunca inmediatamente! Asíncronamente la replicación se realiza periódicamente de forma planificada según un calendario. Es evidente que las dos necesitan análisis de consistencia para garantizar la integridad y la consistencia de los datos. De los procesos de auditoria de las replicas se hablará de forma específica más adelante.

4. 2. Tipología de la forma de transmitir los cambios.

4.2.1. Emisión. Es la forma habitual. Desde el lugar de la fuente se actualizan todos las replicas.

266

4.2.2. Cascada. Desde la fuente se lanzan las actualizaciones de una parte de las replicas y estas actualizan otras replicas; el proceso en cascada continua hasta que se actualizan todas las copias. Por ejemplo, un cambio de tarifas se trasmite desde la central al servidor de la tienda y desde allí a cada puesto de venta. Es un sistema eficaz que minimiza costes de transmisión pero tiene el inconveniente que solo puede utilizarse cuando no es necesario retroceder los cambios si una de las replicas falla.

4.2.3. Replicación bidireccional. En ocasiones el mantenimiento está distribuido sobre más de una copia, y la replicación debe hacerse desde más de una fuente. Correspondería a una situación en la cual, por ejemplo, todos los clientes estén en todos los puntos de venta y el mantenimiento se realice en todos los puntos. Aunque se hable de bidireccional el caso es extensible a más de dos copias. Sin embargo, esta situación solo es operativa cuando el número de copias es muy bajo. Observe que en los datos particionados habrá problemas parecidos.

4.2.4. Replicación entre iguales. Es una forma diferente de hablar de replicación bidireccional cuando hay más de dos copias. El hecho el nombre viene de que al hacer el mantenimiento todas las copias, estas se hacen “iguales” a efectos de replicación.

4. 3. Replica incremental.

Hay un tipo de replica caracterizado porque los datos se incrementan a “saltos”. Un ejemplo clásico son las replicas dedicadas a analizar los resultados de ventas y/o gestión de resultados: los datos a analizar se replican por bloques que coinciden con los periodos a analizar, normalmente un mes. Este tipo de replica se conoce como replica incremental. La replica incremental puede ser lanzada de forma automática o manual. La replica incremental conlleva ligado el concepto de caducidad y eliminación histórica. Si solo se realizan procesos de replica incremental, más tarde o más temprano, el disco se “desbordará”. Hay que pensar, como parte del diseño, en los procesos de eliminación histórica, procesos que seguramente no se utilizarán hasta mucho tiempo después, al vencer la caducidad establecida para la información. Un lugar muy interesante para localizar los procesos de eliminación histórica es el mismo proceso de actualización en la replica de la copia incremental recibida: se borrará de forma automática toda la información por debajo de la fecha de caducidad. Obviamente, la fecha de caducidad es la actual menos el periodo de caducidad establecido.

267

En la replica incremental es muy útil trabajar con el concepto de cierre del periodo a replicar. El cierre es un proceso, paralelo a la idea de cierre contable, que garantiza cuando la información es definitivamente válida, momento en que puede generarse la replica que, al estar ya “cerrada” no cambiará nunca más. En organizaciones en que el cierre no cambia habitualmente los datos, es frecuente hacer un “cierre provisional” anterior en varias fechas al “cierre definitivo”, y hacer dos cargas para adelantar al máximo la disponibilidad de la información. La forma de habilitar la idea de cierre, provisional y definitivo, es el uso de tickets jugando con los estados.

4. 4. Mecanismos de replicación. El mecanismo de replicación es la forma que se realiza tecnológicamente las copias. En la replicación síncrona se habla de mecanismo de replicación “en caliente”. En la replicación asíncrona se habla de mecanismos de replicación en frío:

Replicación por extracción. Replicación por log's Replicación por mensajes. Replicación por eventos. Replicación por suscripción / publicación.

Los trataremos en detalle más adelante ya que muchas de estas técnicas con útiles también en servidores de programas.

5. Copia principal y foco del mantenimiento. La copia principal o master de un sistema de replicación es la copia desde donde se recupera la información en caso de caída de algún nodo. La localización de la copia principal debe tener una política perfectamente definida de administración de copias y restauraciones para garantizar la coherencia e integridad de la información. El foco de mantenimiento es el lugar/es desde donde se mantienen o generan los datos. Aunque lo ideal es que la copia principal y el foco de mantenimiento compartan localización son diversas las aplicaciones en que esto no ocurre y el diseño lo deberá tener en cuenta. La influencia de la no coincidencia de ambos focos depende de cada aplicación pero hay problemáticas comunes a todos los casos. Entre ellas están:

268

Controlar la posibilidad de mantenimiento simultáneo de una misma entidad en puntos diferentes de la plataforma distribuida.

Necesidad de transmisión de los cambios síncronamente a todos los nodos. Problemas de codificación distribuida que abordaremos más tarde.

6. Agrupaciones de replicación. Es frecuente que una serie de entidades estén relacionadas entre si y que sus condiciones de trabajo permitan replicarlas simultáneamente. Por ejemplo:

Los productos, proveedores y sus condiciones de compra. Productos y composición. Productos, clientes y condiciones de venta.

Y un largo etc. que depende de cada aplicación. Cada una de estos bloques se conoce como una agrupación de replicación. La identificación de agrupaciones de replicación clarifica y facilita el diseño y la administración. El aumento de la potencia de la plataforma distribuida, en particular del ancho de banda, ha hecho que el uso de este concepto de replicación sea de gran interés en los actuales sistemas distribuidos

7. Replicación síncrona. Como ya se ha dicho en la replicación síncrona las copias se actualizan tan “rápido como se pueda” y, como en cualquier replicación, es necesario auditar periódicamente la consistencia de los datos entre todas las replicas. Sin embargo, para la replicación síncrona pueden utilizarse otros mecanismos adicionales para garantizar la consistencia. Uno de los más cómodos, fiables y utilizados es el protocolo de confirmación de dos fases (tho-phases ccmmit) que se muestra en la figura. El mantenimiento de la fuente primaria se realiza convencionalmente y a partir de aquí se inicia la actualización de las replicas. Para garantizar la “full tolerance” el mecanismo de modificación se realiza en tres etapas utilizando ese protocolo:

Mantenimiento

Fuente de datos primaria

Fase 1 Fase 2

Copia1

Copia2

1

2

1

2

Copia1

Copia2

35

45

4

Copia1

Copia2

3

Figura 196. Protocolo de dos fases (Tho-phases Commit)

269

7. 1. Reserva de todas las replicas. El programa de replicación lanza una petición de preparación y reserva a cada una de las copias que van contestando que están preparadas y reservadas. Sólo cuando todas las copias han enviado el reconocimiento de reserva se inicia la siguiente etapa. La reserva se realiza del ámbito de registros que hay que actualizar, nunca de todas la entidad destino. El mecanismo debe montar un proceso de control de time-out para prever que unas de las copias no envíe, pasado un tiempo, la notificación de que esta reservado. En ese caso hay que liberar las copias previamente reservadas y reintentar más tarde.

7. 2. Modificación de todas las copias. A continuación se realiza la actualización en todas las copias. Si una de las actualizaciones falla hay que decidir en diseño una estrategia:

7.2.1. Mismo nivel en todas las replicas. Si esta es la estrategia, el fallo de una actualización obliga a retroceder todas las copias que habían acabado con éxito. Es la opción más recomendable.

7.2.2. Admitir diferentes niveles en las copias. En este no se habrán de retroceder las actualizaciones con éxito y se podrá lanzar las que todavía no se han hecho. No hace falta decir la importancia que tiene aquí el uso de tickets como elemento de registro y control. Es más eficiente pero más difícil de programar y, a mi juicio, sobre todo menos interesante al tener diferentes niveles de datos lo que puede llevar a importantes disfunciones organizativas y operativas.

7. 3. Confirmación y liberación En esta tercera etapa, se confirma el éxito en cada una de las copias y se libera cada una de las replicas. Si la etapa anterior ha acabado con éxito normalmente esta etapa puede limitarse a la liberación de la replica. Si la información es muy crítica puede realizarse una confirmación adicional “leyendo” la modificación y comprobando que coincide con los datos del origen. Pueden utilizarse también mecanismos de cheksum o recuperación de campos concretos o valores acumulados si hay cantidades numéricas implicadas.

270

Cuando se utilizan mecanismos de replicación síncrona, es fácil darse cuenta que la actualización de todas las copias puede llevar un tiempo. Por esa razón la arquitectura de la solución no es recomendable que delegue al programa de mantenimiento de la fuente primaria la actualización de las copias. Es mejor que se monte una arquitectura de servicios como la de la figura en la cual el programa de mantenimiento anota la modificación en una cola y un agente o un cliente background se responsabiliza de actualizar las replicas liberando al programa de mantenimiento que puede continuar trabajando. Es evidente que teniendo en cuenta el tráfico de líneas que genera el mecanismo para garantizar la “full tolerance” puede no interesar la replicación síncrona en redes complejas o lentas (normalmente remotas). Y si la replicación se hace en muchos casos para disminuir el tráfico de líneas, es también muy evidente que la replicación síncrona esta muy penalizada y que es mucho más interesante y práctica la asíncrona. Otra forma habitual de controlar el proceso es usar tickets que cada uno de los actores actualizan y que permiten controlar el flujo del sistema y que ha acabado correctamente.

8. Replicación asíncrona. Como ya se ha dicho, la replicación asíncrona se realiza en bloques cada cierto tiempo. El lanzamiento de la replicación puede hacerse:

Periódicamente, a intervalos de tiempo pactados. Es la opción escogida casi en todos los casos.

Cuando hay un número predeterminado de modificaciones pendientes. La replicación asíncrona es más escalable que la síncrona pero la coherencia y la sincronización de las copias es mucho más difícil de conseguir. Sin embargo, permite distribuir los cambios en bloque, lo que minimiza los tiempos de comunicación. El problema queda aumentado si la replica es bidireccional.

9. La escala copia / replica.

Cola deCambios

Fuente de datos primaria

Mantenimiento de la fuente

primaria

Agente de replicación síncrona

Fase 1 Fase 2

Copia1

Copia2

1

2

12

Copia1

Copia2

3 54

54

Copia1

Copia2

3

Figura 197. Arquitectura de Replicación Síncrona

271

La relación entre la utilización de replicación síncrona o asíncrona y el uso que se hace de la información se refleja en una esquema conocido como la escala copia / replica. Copia hace referencia a asíncrona y replica a asíncrona. En el extremo de la copia asíncrona está la información de soporte a la decisión y en el extremo de la derecha la disponibilidad inmediata. Repasemos la escala de izquierda a derecha. 9. 1. Replicación

asíncrona a petición. La replicación la inicia el propio usuario cuando necesita los datos. Corresponden a replicas que se dedican a soportar dos tipos de procesos:

Procesos aperiódicos de soporte a la decisión. Corresponden al ámbito de la denominada informática de investigación, especializada en ayudar a montar nuevos procesos operativos o estrategias dentro de la compañía. Un ejemplo clásico es la exploración de ventas para decidir nuevas líneas de productos.

Cambios puntuales en ficheros replicados que tienen cambios aperiódicos. Un ejemplo clásico son los cambios de tarifas en ficheros de productos con pocas altas y bajas.

9. 2. Replicación asíncrona planificada.

La replicación se realiza por copia según un calendario prefijado. La información replicada se utiliza para los denominados procesos de análisis. Un proceso de análisis clásico es el estudio del resultado de las ventas del mes anterior. Es la replicación más habitual. En particular cubre un caso muy frecuente: replicación de ficheros en puestos clientes para conseguir autonomía en caso de fallo de la conexión. Por ejemplo, replicar un fichero de productos con los precios de venta en los TPV’s para conseguir que puedan seguir vendiendo aunque caiga el servidor.

9. 3. Asíncrona entre iguales y bidireccional. Es el modelo de tránsito entre los dos tipos de replicación. La replicación es periódica por copia pero de frecuencia muy alta.

• Asincrona• Puntual por

petición

• Asincrona• Planificada

• Asincronaentre iguales

• Bidireccio-nal

• Sincrona• Confirma-

ción en dos fases

• Copia en Caliente

• Full Tolerance

Alta disponibilidadSoporte a la decisión

Investigación AnálisisConsulta y

Mantenimiento “no crítico”

Aplicaciones“tiempo real”

Replicación de seguridad ante fallos de

servidores

Figura 198. La escala copia / replica.

272

Es utilizada para información de análisis en continuo o para procesos de mantenimiento “no crítico”. Este concepto hace referencia a mantenimientos de entidades de baja volatilidad y en la cual los cambios no se necesitan rápidamente actualizados. Un ejemplo habitual es el mantenimiento de la entidad cliente: un cambio en la dirección de envío de la mercancía se ha de actualizar pronto pero no es crítico: la probabilidad de que un cliente haga un pedido que haya de entregarse ¡“ya”! es un lugar diferente del aquel donde ha hecho el cambio de la dirección de envío es prácticamente nula. Sin embargo, para este tipo de proceso es recomendable la escala siguiente. Es interesante también en modelos en los cuales la responsabilidad del mantenimiento esta repartida entre los nodos donde existen replicas completas, aunque al igual que en el caso anterior, puede se más interesante el siguiente tipo.

9. 4. Replicación síncrona con confirmación en dos fases. Es el tipo de replicación síncrona en el cual los cambios se transmiten “tan rápido” como es posible. Se utiliza para los procesos de mantenimiento no crítico contemplados en el punto anterior.

9. 5. Replicación síncrona inmediata y el caliente. La idea de esta escala de replicación es que el cambio se transmite inmediatamente a todas la replicas. Intenta parecerse a un mantenimiento clásico que reserva el registro a modificar y cuando lo libera el cambio ya es vigente. Usted podría mantener el stock de sus almacenes así. Personalmente pienso que es una quimera irrealizable y peligrosísima. Si usted tiene replicas es porque no tiene acceso fácil a la fuente. Y si no tiene acceso fácil, los cambios llevarán un tiempo y ¡pueden fallar por la caída de la conexión! Hágame caso: si tiene tentación de utilizar esta escala, es que ha diseñado mal; piense otra solución. Existen mecanismos como la replica por instantáneas (snapshots) pensadas para esta escala y aplicables, obviamente, a la filosofía de tan “rápido como se pueda”.

273

10. Uso de técnicas Master-Slave en replicación.

El uso de técnicas master/slave implementadas por multihilo puede ser una solución muy eficaz en replicación, sobre todo si el modelo de replicación es síncrono. Si la replicación es síncrona el master recibe el cambio y delega a cada slave la modificación de un nodo. En este caso, cada hilo puede no ser idempotente ya que, como se ha dicho antes, si la actualización de un nodo no acaba bien, lo normal es no deshacer los que han acabado bien. El problema de la sincronización de la concurrencia y el paralelismo no es trivial y debe tratarse con cuidado si se quiere conseguir la replicación con la rapidez y eficacia que ha justificado este tipo de replicación.

Si la replicación es asíncrona, normalmente se pasa una copia al master y cada slave actualiza su nodo. Como lo normal es, en este caso, que las copias no se tiren hacia atrás si una de los nodos falla, cada hilo es idempotente con los otros y los problemas de concurrencia y paralelismo son mínimos. En cualquier caso, el master se encarga de garantizar la consistencia que puede incluir una cola de los cambios y un ticket de control asociado a cada cambio.

11. “Full Tolerance” y tickets. Una forma habitual de controlar la “full tolerance” de las replicas asíncronas es el uso de tickets. Las estrategias pueden ser muy diferentes en función de los diferentes condicionantes de cada aplicación. A modo de ejemplo, imagine que quiere controlar el buen fin de todas las replicaciones cuando no importa que todas las copias estén al mismo nivel. Puede establecerse un sistema de tickets del estilo de:

Un ticket multihoja en el lado de la fuente crea una hoja para cada fecha de replicación donde las situaciones son los nodos a replicar y los estados la situación del proceso de replicación.

Cada vez que se emite o recoge una copia a o desde un nodo se coloca el estado de “iniciado” para la posición del nodo en el ticket.

Cuando el nodo recibe la copia, coloca el estado de “recibido”. Cuando el nodo actualiza la replica coloca el estado de “acabado” si finaliza correctamente o de error si no es así.

De esta forma desatendida y automática pueden contestarse, desde la fuente, a preguntas del tipo: ¿ha acabo todo?, ¿qué me falta por actualizar?, ¿qué nodos han acabado mal?, etc. Y lanzar procesos automáticos del estilo de avisar automáticamente cuando un nodo acaba con error, o pasado un tiempo, que nodos están todavía pendientes, etc.

Figura 199. Replicación

por master/slave.

274

12. Mecanismos de replicación.

12. 1. Replicación por protocolo de dos fases. Es el mecanismo de replicación síncrona que se ha presentado anteriormente.

12. 2. Replicación por extracción. Es el sistema asíncrono por definición: la copia, sumarización o reorganización se extrae de la fuente y se envía a las replicas. Es muy habitual que se utilice como plataforma el servidor de correo en tres pasos:

Extracción de la fuente y anotación en el buzón del servidor de correo. Transporte por el servidor de correo de la copia al lado de la replica. Sustitución o actualización de los cambios en la replica extrayéndolos de la copia del buzón, posiblemente con un sistema de vigía-disparador sobre la lista de recepción.

Existe también la posibilidad de encargar el trabajo a un procesador distribuido de los que se presentan en el capítulo de integración de la parte cliente.

12. 3. Replicación por log's.

Es un modelo indistinto para síncrono y asíncrono. Cuando se utiliza este mecanismo, el programa de mantenimiento de la fuente primaria graba un log con los cambios. El sistema de replicación transmite los cambios a los nodos de las replicas. Este método es especialmente útil cuando la periodicidad es baja o los volúmenes son altos. Evita la extracción. Para cargar el log en la parte replicada puede utilizarse el log del motor de la base de datos en la fuente, aunque hay que llevar cuidado de copiar cosas innecesarias o prohibidas. Una posibilidad es hacer una selección sobre el log original, enviarlo a la replica y cargarlo con las herramientas del Middleware del motor de BD. La sumarización o reorganización penalizan gravemente la utilización de esta técnica.

Fuente de datos primaría

Mantenimiento

Copia1

Copia2

CopiaN

Sistema de replicación

Log

Figura 200. Replicación por log's

275

Es un sistema muy eficiente pero que exige auditoria para evitar incoherencias y desniveles en las copias, obviamente en el caso de que se necesite mismo nivel.

12. 4. Replicación por mensajes. Normalmente la replicación por mensajes síncrona. Cada mensaje lleva la información de un cambio que se transmite por un mecanismo cliente / servidor. Es la típica replicación síncrona a través de servidores. Observe, como curiosidad que la replicación síncrona por mensajes suele hacerse a través de colas, mecanismo de comunicación asíncrono.

12. 5. Replicación por eventos. Cuando hay un cambio se avisa con un evento a cada nodo. El aviso puede ser de un cambio para replicación síncrona en cuyo caso los parámetros del evento llevan la información del cambio. El aviso puede ser también de la existencia de una nueva versión de la replica en replicación asíncrona iniciada desde la banda de la replica.

12. 6. Replicación por instantáneas (snapshots). La transacción de modificación de la fuente actualiza al mismo tiempo las replicas. La idea del snapshot (instantánea en inglés), es que se copia la información tal como está en ese instante en todas las copias. La idea es mantener origen y destinos “instantáneamente al mismo nivel. Si no se quieren tener inconsistencias deben bloquearse los registros afectados en todas las bases de datos lo cual no es nada sencillo. Si se utiliza el mecanismo que proporcionan algunos motores puede ser una opción válida. Una de sus características diferenciales en mantenimiento síncrono es que la sincronización no es lanzada por el proceso de mantenimiento. Eso la hace muy poco eficiente e innecesaria por el concepto de replica como soporte de consulta no de datos “instantáneos” mantenidos “on-line”.

12. 7. Replicación por Publicación / Suscripción. Utilizando este mecanismo, que hemos presentado en la primera parte y detallaremos más adelante, puede obtenerse un sistema muy fiable de mantener replicar en caliente o en frío. Así, cuando la base de datos sobre la cual se realiza el cambio detecta una modificación, el cambio se publica de forma que un evento avisa a cada una de las replicas suscritas. El sistema es muy flexible ya que permite suscribirse a cambios de todo el esquema o sólo de unas determinadas tablas, con partición horizontal o vertical. Hay varias de formas de trabajar:

276

Aprovechando los mecanismos automáticos que suministran los gestores de bases de datos.

Publicando los cambios desde los programas de modificación y suscribiendo con clientes background o agentes que se despiertan con los eventos de cambio.

Utilizar un mecanismo específico de Publicación / Suscripción.

12. 8. Usar los mecanismos de replicación de los gestores de la base de datos.

Si el gestor de la base de datos ofrece la posibilidad de replicación automática siempre puede usarla. Sin embargo, sea muy precavido en dos sentidos:

Compruebe que realmente funciona. La aplicación quedara distribuible en lugar de distribuida al estar cautiva de los recursos de un modelo específico de gestor.

13. Utilidad del Vigía y del Disparador en gestión de replicas asíncronas. Permiten automatizar la carga en la parte replicada. El Vigía escuchará el directorio, cola, mail o cualquier otro recurso donde aparezcan las copias y el Disparador lanzará el proceso que corresponda.

14. Replicación Caché. Hablamos de datos replicados temporalmente o caché cuando la replicación se realiza mediante una copia en una zona de acceso rápido que cuando deja de ser usada se destruye. Se consigue así una mejora importantísima en la velocidad de respuesta cuando se necesitan esos datos. La mejora es todavía mayor si se aprovecha la copia para organizar los datos con un tipo de organización de acceso más eficiente de acuerdo con el uso que se va hacer de los datos. Es evidente que para que esta replicación se pueda utilizar es necesaria la certeza de que los datos no cambiarán mientras están en caché. Pude haber cuatro formas de hacer la replicación caché:

En memoria interna del programa. En una zona de memoria compartida. En un disco virtual. En una zona de disco de alta velocidad de acceso.

Las dos primeras son más rápidas pero solo se pueden usar con datos de volumen medio. En el primer caso lo normal es que la replica se realice cuando arranque el programa, en las dos últimas cuando arranca el nodo y en la segunda cuando arranca el primer programa que las usa.

277

La replicación puede ser de dos tipos: 14. 1. Caché interna al programa.

Cada programa, cliente o servidor, copia los datos en una zona de su exclusiva disponibilidad.

14. 2. Caché compartida. La replicación queda a disposición de todos los programas usuarios del nodo donde se localiza la caché.

Las técnicas caché se usaron también en tiempos históricos para datos particionados que se mantenían en caliente. Hoy día las técnicas en ese contexto están totalmente obsoletas ante los avances del Middleware de datos. No las encontrará en este libro. Por último, remarcar que no debe confundirse este tipo de replicación con los mecanismos de persistencia automática que proporcionan algunos lenguajes OO.

15. Data Warehouse y replicación. Una forma habitual de implementar una replicación es usar un Data Warehouse del que ya he hablado en la primera parte. Si no lo recuerda, por favor, reléalo. Sólo recordar que como soporte de la replicación un Data Warehouse proporciona dos características adicionales importantes:

• Soporte de datos con heterogeneidades semánticas y sintácticas en las fuentes.

• Escalabilidad al aumento de clientes.

16. Replicación virtual o Data Warehouse virtual. La idea de replicación conlleva dos necesidades básicas: el proceso de replicación en si y que la disponibilidad de los datos no es instantánea. Estos dos inconvenientes pueden solventarse mediante una técnica conocida por algunos autores como replicación virtual o Data Warehouse virtual. Consiste en acceder directamente a las fuentes de datos a través de servicios que realizan la unificación semántica y sintáctica de los datos en cada fuente a través de un metaesquema. Los servicios pueden implementarse con técnicas de Servicios WEB para conseguir estandarización y generalización. En mi opinión, esta estrategia no tiene nada que ver con replicación, si no que está en la línea de servicios de datos. ¿Qué opina Vd.?

17. Auditoria de datos replicados. Si la replicación se hace asíncronamente por sustitución, es decir, enviando periódicamente todos los datos de la fuente a la replica, el proceso de auditoria es

278

innecesario ya que la llegada de la nueva copia (que recordémoslo, llegará con “full tolerance”) garantizará la igualdad de la fuente y replica. Pero recordemos que esta vía de replicación sólo puede usarse para copias de volúmenes pequeños o cuando la sumarización y / o reorganización disminuyen de forma importante el volumen de los datos a replicar. Y que además las conexiones lentas, causa importante de la existencia de las replicas, disminuyen el número de casos en que la replica por sustitución puede usarse. Si el mantenimiento es síncrono o asíncrono incremental o en foco del mantenimiento es distribuido, es obvio que hay que establecer un proceso para garantizar la coherencia e integridad de los datos entre la fuente y las replicas y, si la aplicación lo necesita, que fuente y replicas estén al mismo nivel. Este proceso se conoce con el nombre de auditoria de datos replicados. El tema no es trivial ya que para auditar la fuente y las copias hay que comparar cada uno de sus registros, y sea cual sea la forma de hacerlo, en algún momento habrá que tener en el mismo lado los valores a comparar de las dos partes. Y esto llevará un tiempo: el mismo que impide que la replica se haga por sustitución. Se produce, pues, un verdadero abrazo mortal. La auditoria puede ser en caliente o en frío. Si es posible hacerla en frío fuera de los periodos de servicio pactados con los usuarios, debe primarse esa opción. Si no es posible, se habrá de hacer el caliente, “reservado” temporalmente la entidad auditada si es necesario; está última circunstancia dependerá de las características y uso de cada entidad. Si hay datos numéricos involucrados (por ejemplo, un fichero de ventas) una opción valida es sumariar en los dos lados, enviar el sumario de un lado al otro y comparar. Si no hay diferencias, auditoria con éxito. Si la hay deberá analizarse el detalle del descuadre. Las diferencia es arreglarán en la replica con el valor de la fuente y solo en caso extremo se enviará una copia total nueva, opción que, en cualquier caso, hay que tener siempre prevista.

Un esquema de la operativa del proceso de auditoria se muestra en la figura. Es bueno dotar al mecanismo de auditoria de dos procesos:

Uno de comparación que proporcione información de las diferencias.

Y otro de reparación. Basta para ello tener un parámetro que diga si el proceso de auditoria se pide sólo de comparación

Servidor de referencia

Servidor replicado

Comparación

Diferencias

ActualizaciónAutomática

Conforme

Análisis de diferencias

Figura 201. Esquema de Auditoria de Datos Replicados

279

(la verdadera auditoria) o también de reparación. Observe que a efectos de programa solo supone la ejecución o no de una llamada SQL para reparar la replica. Esta posibilidad permite analizar el por qué de las diferencias y si se detectan causas físicas (plataforma), lógicas (de programas) o de operación (usuario) añadir las mejoras para que las causas desaparezcan. En particular, si la causa en un error de operación, blinde la aplicación para que el usuario no pueda repetirla.

18. Factores a considerar en la política de replicación. La organización que tiene datos replicados debe establecer una política de replicación que hay que implementar en el diseño de la aplicación. Para establecer la política hay que ponderar diferentes factores: 18. 1. Localización de las copias.

El primer factor a determinar es la localización física de las replicas. Recuerde que solo podrá utilizar los nodos de los niveles lógicos. Se ponderarán básicamente dos criterios:

Localizar los datos tan cerca de los usuarios como sea posible. Garantizar el trabajo en caso de caída cuando está situación sea necesaria.

18. 2. Situación de la replicación en la escala copia-replica.

Se determinará el uso de la copia: investigación, análisis, mantenimiento “no crítico”, etc. Y con este factor se hará una primera situación según la escala que tipo replicación, síncrona o asíncrona, debe de usarse.

18. 3. Volatilidad. La volatilidad (frecuencia de los cambios) de los datos tiene una importancia fundamental para determinar el modelo de replicación (síncrono o asíncrono) y el calendario.

18. 4. Tamaño de los datos. Ver que se necesita copiar determina el tamaño de los datos condiciona el tiempo necesario y por tanto puede determinar el tipo de mecanismo a utilizar. Si el tiempo es alto, habrá que decantarse por sistemas de log que evitan la extracción.

18. 5. Tipología de la forma de transmitir los datos.

Se analizará si el mantenimiento se realiza en un único punto (situación que debe primar) o no. Si no es así, deberá hacer replica bidireccional. En caso contrario deberá elegir, en función de su aplicación, si hace emisión o cascada.

18. 6. Importancia de las copias y necesidades de fiabilidad.

280

La importancia de las copias decidirá la fiabilidad necesaria y el nivel de auditoria a realizar. Se supone que la “full tolerance” está garantizada.... Dentro de los factores relacionados con la importancia de los datos deben incluirse los factores que determinan si el mantenimiento es “crítico” o no.

18. 7. Plan de auditoria. El plan de auditoria está, lógicamente relacionado con la fiabilidad. Habrá que decidir hacerla en frío o en caliente y cómo, cuando y donde se hará.

18. 8. Disponibilidad. La disponibilidad de las dadas en horario y acceso influirá básicamente en la localización. Por ejemplo, si un usuario es nómada, por acceso deberá tener la replica en su portátil. Si una delegación trabaja fuera de los horarios de los ordenadores centrales, por horario de acceso

18. 9. Calendario y horario.

En replicaciones asíncronas habrá que decidir cada cuando se actualizan las copias (factor muy ligado a la volatilidad) y encajar estas copias en el calendario si la dispersión geográfica es importante. Finalmente habrá que decidir el horario.

18. 10. Copiar, Reorganizar o Sumarizar. Escoja la combinación de los tipos de replicación que le conviene. Recuerde, que si puede sumarizar o reorganizar minimizar volúmenes y por tanto costes.

18. 11. Como es el foco de mantenimiento. Es un tema fundamental. Podrá elegirse entre:

Centralizado sobre la copia master o sobre una replica. Distribuido.

18. 12. Desde donde se inicia la replicación.

Si el modelo de replicación es asíncrono, el proceso de replica se puede lanzar:

Desde la fuente. Habrá de garantizar que el destino esté disponible. Desde el destino. Habrá de poner a disposición del destino un semáforo o un ticket que le informe si la copia ya está disponible. Es una opción muy útil para resolver la problemática del calendario y el horario y el acceso desde usuarios nómadas.

18. 13. Caducidad de la replica.

Cuando la replica es incremental recuerde que debe decidir la caducidad histórica y si la eliminación se hace manual o automática (prime esta segunda opción).

281

18. 14. Preguntas de interés. Antes de tomar decisiones definitivas hágase las preguntas:

Si ha elegido esa opción, ¿es realmente necesaria la replicación síncrona?

¿Cómo es el mantenimiento y cual es la copia master? ¿Los criterios de mantenimiento “crítico” (necesidad de actualización permanente) son correctos?

¿Las pérdidas de rendimiento por procedimientos de “dos fases” son tolerables?

¿La no sincronización de las copias es peligrosa? ¿Puedo sumarizar y / o reorganizar en lugar de copiar?

19. Cuestiones de interés técnico. Existen cuestiones de interés técnico que pueden influir, aunque se debería evitar, en la política de replicación ya que muchas son enmascarables desarrollando lógica de datos.

Existencia de soportes heterogéneos en la fuente primaria y los destinos. Obliga a realizar los cambios semánticos y/o sintácticos en el proceso de replicación. Recuerde que la presencia de puntos replicados en XML supone una heterogeneidad.

Que el entorno disponga o no de recursos de programación y ejecución de multihilo (un sistema multitarea) condicionará las soluciones técnicas. Sin embargo, la realidad actual lo da prácticamente siempre resuelto.

Posibilidad de basar la replicación en el motor de la base de datos. SQL Server, por ejemplo, mantiene la replicación entre diferentes copias físicas de forma automática. Ventajas: economía y comodidad. Desventajas: solo replicación por copia y no es segura la consistencia.

Presencia de nodos remotos lentos y de usuarios nómadas. Alternativas por Internet, de las que se hablará a continuación.

20. Política de replicación. La respuesta que de todas estas cuestiones establecerá la política de replicación que deberá quedar definida y documentada en el análisis y que se deberá concensuar y pactar con el administrador del sistema y el responsable de los datos.

21. Los gestores de BD como Middleware de replicación. Cada vez más los gestores de BD proporcionan con el motor herramientas de Middleware para replicación de datos y sincronización de esquemas entre copias físicas diferentes. Las posibilidades replicación de este Middleware, inexistente hace pocos años, debe conocerse por los diseñadores y administradores para implementar la política de replicación.

282

El camino es el de siempre: marcar nuestra política de replicación, ver que cosas da el Middleware del fabricante y desarrollar los procesos que hagan falta para completar las funciones pedidas al sistema y facilitar su administración. Conviene hacer unas reflexiones sobre esta vía. La solución quedará ligada al gestor que utilice. Es decir, será distribuida, no distribuible. Asegúrese de que el producto aporta de verdad full tolerance. Las soluciones técnicas mejor resueltas son las asíncronas periódicas, por extracción y propagación por emisión. Repitiendo la emisión se obtiene la cascada.

22. Aplicaciones C/S basadas en sistema operativo trabajando sobre datos replicados versus aplicaciones Internet.

Evidentemente, una primera situación rápida lleva a centrar el ámbito de la comparación sobre las aplicaciones de consulta. Si la volatilidad de los datos es alta o los volúmenes son grandes, las aplicaciones Internet tendrán todas las ventajas sobre las C/S. En particular, la existencia de uno o más puntos de heterogeneidad por conexiones lentas (normalmente remotas) hace que el nivel de “volúmenes altos” esté más bajo. En el otro extremo, replicaciones periódicas de datos poco volátiles o que no tienen sentido hasta la replicación (como, por ejemplo, replicas para estudiar los resultados de ventas de una periodo) y los usuarios nómadas priman las aplicaciones C/S sobre la Internet. Y un factor claro a favor de Internet: la generalización de la conexión y la independencia de la aplicación de la máquina cliente. En medio, un amplio gris de difícil sistematización. Pero me deja darle una impresión: creo firmemente que las aplicaciones Internet llevan, en general, ventaja sobre las C/S en estas aplicaciones de consulta. Hay que evitar de cualquier forma la falacia de que como la replicación es un tema complejo, se haga todo por Internet.

23. Aplicaciones con mantenimiento distribuido de replicas. En los modelos en que el mantenimiento se hace indistintamente en cualquier nodo y debe ser propagado a toda la organización, hay varias soluciones que hay que comparar y valorar:

Un modelo replicado entre iguales mantenido de forma sincronía bidireccionalmente. Normalmente utilizará servicios de lógica de datos para encapsular la integridad y consistencia.

Un modelo centralizado, o al menos de las entidades afectadas. Si la aplicación distribuida esta basada en sistema operativo, el acceso se hará en tiempo real a través de una conexión permanentemente

283

abierta. En general, tendrá pocos problemas de tiempo de respuesta en acceso a registros y una cierta lentitud en procesos en bloque.

Si la aplicación es Internet o utiliza Servicios WEB para la gestión de los servicios de datos, el modelo resuelve el problema ya que la gestión de los datos se hace en la parte servidora WEB que está, en general, muy cercana al gestor de base de datos.

24. Servidores de programas replicados.

Ya hemos hablado de la disyuntiva entre servidor de programas único o en cada puesto de trabajo y las ventajas e inconvenientes que tiene cada solución. Básicamente, facilidad de administración contra independencia del puesto. Una solución intermedia es trabajar con servidores de programas replicados. La idea es mantener por administración manual la última versión en un servidor y mantener automáticamente las replicas en los puesto de trabajo o en los servidores intermedios. Se combinan así las ventajas de las dos soluciones. Obviamente la solución puede arrancarse automáticamente desde un servidor único colocado en la central Estamos, como ya ve, ante un mantenimiento de versiones en cascada que se puede montar de varias formas. Una muy cómoda y eficiente es responsabilizar del arranque de todos los programas a un ejecutor que recibe el nombre del programa que se quiere arrancar. El ejecutor mira contra el servidor de referencia si hay nueva versión con fecha de vigencia alcanzada. Si la hay, la copia en el servidor de programas replicado y después pasa control al programa solicitado desconectándose a si mismo. Si no hay nueva versión arranca la actual. Si el servidor de programas no está disponible arranca la copia actual. Esta técnica tiene un inconveniente si el programa, como puede ser un servidor, está arrancado perpetuamente. Rápidamente verá varias soluciones para este problema que se basan en preguntar de tanto en tanto si hay nueva versión disponible y en caso afirmativo autollamarse a través del ejecutor.

Haynueva

versión?

Servidor de programas de

referencia

Servidor de programas

local

Copiarnueva

versión

ArrancarPrograma

pedidoAuto

desconexión

SiNo

Figura 202. Arquitectura de un ejecutor


Datos Particionados 1. Introducción.

Como ya se ha dicho en varias ocasiones, hay dos formas de distribuir datos: replicar y particionar. En el capítulo anterior hemos hablado ampliamente de la replicación. Vamos a tratar ahora la partición. Va a observar un resultado muy curioso. La gestión de datos particionados parece a priori más compleja que la replicación. Pero observará que este capítulo es sorprendentemente más corto que el correspondiente a la replicación. Despierte de su asombro. Es lo lógico. Si particiona los datos, cada bloque es como un modelo centralizado a su entorno. Solo hay un problema: la coherencia del índice central. Que, por cierto, no es un problema trivial. ¿Por qué? Porque está delante de un problema de replicación.

2. Modelo particionado de datos.

Dentro de la arquitectura de datos particionados, los servidores A y B no tienen datos en común. El servidor C hace de “manager”: si A necesita información de B la consigue a través de C.

El servidor C no tiene datos, solo sabe como localizarlos. La forma en que C implementa está opción es a través de un índice que mantienen los servidores A y B. La forma en que A y B realizan este mantenimiento puede ser: 2. 1. Mantenimiento síncrono.

En caliente: cada vez que hay un cambio en A y B, este se actualiza en el índice tan rápido como sea posible en C.

2. 2. Mantenimiento asíncrono En frío: los cambios de A y B se actualizan periódicamente en C.

3. Técnica.

Puede utilizarse dos formas básicas para localizar cada registro:

Figura 203. Arquitectura de datos particionados


3. 1. Índice. Mantener un índice en C de los datos de A y B. Observe que no es más que un caso especial de replicación en que sólo se replica la clave de cada registro y su localización. Son aquí válidas todas las técnicas presentadas en el capítulo anterior, y que, por tanto, no repetiré aquí.

3. 2. Regla de negocio.

Existe alguna regla de negocio o sistema de codificación para saber a que nodo hay que acceder.

Ponga especial interés en mantener la consistencia y totalidad de los datos si el mantenimiento del índice es síncrono.

4. Auditoria de datos particionados. Es evidente, que al igual que en los datos replicados, los datos particionados necesitan de auditoria para garantizar que el índice es C es coherente y completo con los datos de A y B. Las técnicas de auditoria son, una vez más, las mismas que en la replicación. Hay, sin embargo, una diferencia fundamental. El volumen de datos para mantener un índice es muchísimo más pequeño que el de una replica. Ello hace que en lugar de la auditoria por comparación, sea muy viable hacer actualización por copia de las claves principales de cada entidad.

5. Una reflexión final. Los datos particionados son muy eficientes ya que están muy cerca de donde se necesitan. No son mucho más difíciles de mantener que los replicados; quizás, incluso, menos. La administración es muy sencilla ya que la auditoria se hace prácticamente siempre por sustitución y la administración de cada partición es centralizada. Siempre que la aplicación lo permita, por ejemplo casos en que los clientes estén muy localizados en las delegaciones de venta, ¿por qué no se usan más? ¿Por miedo?, ¿por falta de formación?

Codificación distribuida 1. Introducción.

Tanto el modelo replicado con focos de mantenimiento diferentes del nodo primario o master como en datos particionados, se platea un problema de codificación cada vez que hay que hacer un alta. ¿Cómo hacer que el código que voy a asignar no esté repetido? Imaginemos un entorno en el cual hay una base de productos compartida pero alguno de los nodos va a tener que dar de alta sus propios productos. Uno de estos nodos hace un alta y asigna un código. Y tras hacerlo empieza a utilizar el registro. Si cuando la información se concentra resulta que el código está duplicado, se deberá, además de avisar al usuario remoto, cambiar todos los códigos de los registros de las entidades donde ya se haya utilizado. En fin, un verdadero problema. Y no imaginemos un entorno en que el código se ha intercambiado ya con terceros, situación cada vez más frecuente. Este es el emergente concepto de codificación distribuida: como asignar códigos en un sistema distribuido sin que haya colisiones. El problema afecta tanto a replicaciones como a datos particionados. Deberá empezar por dotar a la organización de un criterio claro de asignación de códigos remotos. La decisión de dejar la elección del código al usuario utilizando esas reglas es peligrosa ya que tarde o temprano se va ha equivocar. No la use. La solución organizativamente válida pasa por delegar la codificación distribuida a la propia aplicación. Este es el tema que vamos a tratar en este capitulo.

2. Criterios de asignación de códigos. Usted que conoce su organización sabrá cual es el mejor criterio para codificar de forma distribuida en su aplicación. Pero si no lo tiene claro hay un sistema muy general y eficiente que le voy a presentar aquí. Consiste en asignar un nodo a cada base de datos presente en el sistema distribuido y crear un código del tipo:

Serie, opcional Referencia de nodo.

@@EMG/10 - Enric Martínez Gomàriz

287

Numero secuencial dentro del nodo. Veamos dos ejemplos.

Productos: Referencia de nodo: dos dígitos siempre informados. Es decir el 1 se codifica siempre 01. Si hay productos que solo se pueden mantener en la central se les puede reservar un nodo base, por ejemplo 00.

Numero secuencial de cinco dígitos siempre informados. Pedidos y albaranes.

Serie: un digito, A o P. Referencia de nodo: dos dígitos. Número formado por:

Dos dígitos para el año. Cuatro dígitos para un numero secuencial

3. Gestión de la codificación distribuida. La asignación de referencias de nodo y series se hace normalmente de forma centralizada y se distribuye como parte de los datos de configuración. Cuando un mantenimiento necesita un nuevo código, la propia aplicación sugiere el siguiente al último utilizado. La verificación de no duplicidad de ese código debe comprobarse siempre como medida adicional de seguridad. Aquí hay muchas posibilidades. Son opciones clásicas: 3. 1. Verificación síncrona

Cuando se acepta el alta se accede a la copia master, en el caso de replicación, o al índice en el caso de datos particionados, y se verifica. Puede hacerse:

Atacando la base de datos directamente través del servidor de base de datos.

Estableciendo un servicio especifico implementados en un servidor sobre la base de datos master.

Según sea la entidad habrá que hacer o no una prerreserva del código. Hay varias formas de hacerlo.

Alta condicional de forma que si pasado un plazo no se ha confirmado se elimina.

Tabla temporal de códigos en curso donde se mirará para saber si una petición de verificación o petición de nuevo de código pueda comprobarlo aunque todavía no exista en la base de datos porque todavía no se ha realizado la transacción de alta.

3. 2. Verificación asíncrona.

@@EMG/10 - Enric Martínez Gomàriz

288

La verificación se hace cuando se consolidan las copias. Solo la recomiendo en los casos de probabilidad muy baja de errores. Con estos criterios, en una codificación distribuida de códigos de artículos se tiende a verificación síncrona y en una de albaranes a asíncrona. La solución es más un proceso organizativo que informático. Puede consistir simplemente copiar el registro con otro código y pasar el programa de cambio en bloque de códigos del que se habla a continuación.

3. 3. Asignación dinámica. Un servicio centralizado dará el código. No hace falta decir que ya no tenemos problema de verificación. Tiene al ventaja de que para cambiar el criterio solo es necesario modificar un único servicio. El inconveniente es que hay que restringir las altas a la disponibilidad del servicio o montar un proceso de asignación provisional de código para cuando se trabaje en emergencia.

4. Cambios de código en bloque. Como vacuna final le aconsejo que disponga siempre de una función en la aplicación distribuida que le permita cambiar los códigos asignados en una codificación distribuida en bloque en todas las entidades que los han podido utilizar. Como partimos de la base de que se hacen bien las cosas y no deberá usarse casi nunca, la opción es muy fácil implementar ya que no necesita ser eficiente sino únicamente eficaz y de fácil operativa. Y además podrá obligar a pasarla en frío.

Aplicación del Patrón DTO 1. Introducción.

Imaginemos que existe una frontera entre un nodo donde se realiza la gestión de una entidad y el nodo en que se encuentra la base de datos que registra la entidad y que razones del proceso hemos de consultar i/o modificar diversos atributos de la entidad en momentos determinados de ese proceso. Si actuaramos convencionalmente, cada acceso y restitución de cada atributo sobre la base de datos deberia acceder a la base de datos. La consecuencia sería muy clara: perdida importante del rendimiento. La solución, aplicar el patrón DTO (Data Transferir Object). Observemos que la aplicación de ese patrón en evidente en aplicaciones de consulta pero mucho más problemática en aplicaciones de mantenimiento ya que obliga a reservar la entidad en la base de datos mientras el modifica en el nodo remoto. La aplicación puede realizarse sobre un único registro o un conjunto de regristros en la línea de una selec.

2. Aplicación del patrón DTO. La aplicación del patrón siempre supone DTO siempre supone los siguientes pasos que se muestran en la figura de la derecha: 2. 1. Obtención de registro o registros.

El cliente o servicio recupera el registro o conjunto de registros desde el nodo remoto y lo traslada en un DTO hasta el nodo donde reside. Si la aplicación ha de modificar el registro, deberá reservarlo en la base de datos.

2. 2. Gestión del DTO. La gestión del registro o conjunto de registros se realiza sobre el DTO, “local” para el cliente.

2. 3. Modificación de la base de datos. Si los datos se han modificado, el cliente modifica finalmente el DTO sobre la base de datos remota y libera los registros afectados.

:Cliente :DTO

sRecuperación del/de los registros

:Controlador Remoto de Datos

Gestión de los datos sobre el DTO

Actualización del DTO

Nodo Cliente Nodo de datos

Fron

tera

Figura 204. Aplicación del patrón DTO para mejorar rendimiento

290

Servicios de Agrupación de Entidades de Datos

1. Introducción.

A lo largo del estudio y el diseño de los datos en un entorno distribuido han surgido diferentes ocasiones (Outsizing, particionado horizontal y vertical, etc.) en que una entidad aparece distribuida por la plataforma. Y recordemos que la distribución de los datos, con esquemas homogéneos o heterogéneos, puede obligar a la “reconstrucción” de la entidad yendo a buscar los atributos a más de una localización y teniendo que resolver diferencias sintácticas y semánticas entre los atributos comunes. La idea básica es que puede ser necesario dentro del entorno distribuido acceder a la entidad como un todo. Desde el primer momento es evidente que el problema no es trivial y que se agrava si deseamos hacer el mantenimiento de entidad desde el entorno distribuido lo que nos obligará a garantiza la coherencia de los datos en todas las plataformas afectadas. Es necesario definir servicios que nos solución el problema. Estos servicios son los que se denominan Servicios de Agrupación de Entidades, que incluyen:

Agregación. Por ejemplo, un pedido y todos los albaranes en que se ha servido.

Integración. Por ejemplo juntar los atributos de producto de las aplicaciones de fábrica y de facturación.

Agregación e integración simultánea. Es evidente que con todas las herramientas ya presentadas Vd., amigo lector, podría atacar el diseño de estos servicios por si sólo. Pero dada la importancia de esta tipología de servicios vamos a dedicarle un capítulo específico.

2. Precondiciones. Partimos de la base de que todas y cada una de las entidades, atributos y restricciones de integridad de los sistemas de origen se acceden a través de servicios de lógica de datos. En ningún caso el servicio de agrupación de entidades que vamos a definir accede directamente a las fuentes de los datos, normalmente bases de datos relacionales, que el nuevo servicio va a integrar y/o agrupar. Observe que este enfoque presenta la enorme ventaja de independencia del soporte o el esquema original con el único peaje de que, si ya no existen, deben crearse los servicios necesarios para envolver el entorno de origen de los datos. Otras precondiciones necesarias son:

291

Que se dispone de permiso de acceso proporcionado por los propietarios de los datos. Este permiso deberá ser verificado por el servicio de tres formas:

Con una autentificación inicial y una clave de autentificación del permiso que se incorporara a cada petición.

Autentificación a cada acceso. Responsabilizándose la aplicación de uso. Esta solución es admisible en aplicaciones internas pero no en relaciones con terceros.

Conocer los esquemas lógicos de origen y de los servicios de acceso de los que hemos hablado.

Disponer del criterio de partición horizontal en caso de existencia de esta situación.

Toda esta información estará presente en el metaesquema del que hablaremos más adelante.

3. Sistematización de la casuística. Si analizamos con cuidado todos los ejemplos que han salido de heterogeneidades de datos podemos clasificarlas en la siguiente casuística: 3. 1. Visión unificada de una entidad.

Integrando en una sola vista todos los atributos dentro del sistema distribuido de una única entidad. Obliga a resolver diferencias semánticas y sintácticas entre los atributos comunes.

3. 2. Partición horizontal. Obliga a localizar cada registro en la localización en que se encuentra. Es prerrequisito conocer el criterio de particionado, no siempre la distribución geográfica.

3. 3. Escenarios de agregación. También conocidos como escenarios Cross-Join. Agrupan datos de entidades diferentes proporcionados. Hay dos casos muy diferenciados.

Todas las entidades comparten localización. Hay dispersión de localizaciones, donde puede haber problemas de rendimientos al tener que hacer y montar joins distribuidas.

Un ejemplo clásico de esta última situación es analizar la situación del stock en un sistema de almacenes distribuido donde la responsabilidad de cada saldo la lleva el propio almacén y el dato de su stock está en su base de datos local y donde deben juntarse stock y pedidos a proveedores pendientes de recibir.

4. El metaesquema.

292

El metaesquema proporciona la visión única del modelo de datos integrado a través de un modelo conceptual de datos unificado y armoniza ese esquema con cada fuente de datos. Debe contener:

El esquema conceptual integrado. Donde se ha de ir a buscar cada atributo del metaesquema y en caso de duplicidad, cual es la copia master del atributo. Los atributos master pueden estar repartidos entre más de una fuente.

Todas las equivalencias necesarias para resolver las diferencias semánticas y sintácticas entre atributos compartidos. Incluye las reglas de transformación.

Equivalencia de claves principales, secundarias y auxiliares. El criterio de partición horizontal si esta presente esa casuística. La descripción de los servicios de acceso a las fuentes de origen.

En los procesos de lectura, solo deberá accederse a las copias donde esta cada atributo master. En la creación o modificación conviene actualizar todas las copias del atributo. A efectos de rendimiento, siempre que sea posible, debería trabajarse con una copia master de la entidad y solo buscar los atributos que no estén allí en las alternativas Los atributos que se utilizan como referencias principales pueden ser diferentes en diferentes esquemas de origen. Un ejemplo clásico pude ser un fichero de clientes que en contabilidad se identifique por el NIF y en facturación por un código. Como todos los atributos descritos en el metaesquema, este incluirá también los criterios de mapeo de referencias. Nótese que la presencia de claves alternativas pude obligar en caso de modificación y en caso de que no sea la fuente de origen la master de los atributos afectados, a procesos de baja y alta. Esa información también ira en el metaesquema. La equivalencia de claves puede llegar a ser imposible de detectar de forma automática y exigir la intervención de algún usuario responsable que tenga conocimientos y experiencia para hacer la propuesta. Esta problemática, que ha de intentar evitar siempre que se pueda, puede obligar a proceso de workflow asociados al sincronizador que veremos al hablar de la arquitectura de replicación. El metaesquema debe representarse siempre de forma descriptiva y no estar incluido dentro de una zona ejecutable. Ello permitirá generalización, adaptabilidad y extensibilidad. Un servicio de interpretación o interpretador, generalmente un servicio pasivo, atacará el metaesquema desde los servicios de agrupación de entidades. Dos formas habituales de guardar el metaesquema son:

Interpretador

Metaesquema

Figura 205. El servicio de interpretación

293

XML. SQL.

En algunos de los esquemas que siguen, y para no complicar-los, no incluiremos al interpretador ya que esta presente en el 100% de servicios de agrupación.

5. Servicio de Agrupación de Entidades. Como ya hemos dicho, el objetivo básico de un servicio de este tipo es proporcionar un punto único de acceso a datos repartidos por la plataforma distribuida. El servicio utilizará el metaesquema para resolver las diferencias semánticas y sintácticas y acceder a los servicios de origen. Existen dos formas básicas de diseñar el servicio de agrupación: 5. 1. Por servicios.

A través de servicios proporcionados por los entornos de origen y utilizándolos en tiempo real. Supone que las fuentes de los datos han de estar permanentemente accesibles. Observe que la arquitectura basada en servicios permite lanzar varias peticiones simultáneamente para optimizar los tiempos de respuesta:

Si la comunicación con los servicios de origen es asíncrona bastará aprovechar este recurso.

Si es síncrona, cosa habitual en servicios de datos, habrá que utilizar alguna de las dos arquitectura que se muestran en la figura:

Master/slave. Delegación de dos capas donde la segunda resuelve de forma asíncrona el acceso síncrono al origen.

El servicio genérico representado por la S simboliza cualquier método de acceso síncrono.

5. 2. Por replicación. Utilizando normalmente una arquitectura de replicación síncrona. Esta arquitectura se deberá primar en los casos analizados que justifican replicación:

Servidorde

agrupación Serviciode

Conexión

D

P

S

Servidorde

agrupaciónM

Serviciode origen

P

S

Figura 206. Arquitectura de servidor de agrupación con servicios

síncronos en origen

294

Presencia de usuarios aislados o nómadas. No hay seguridad de acceso permanente. Problemas de rendimiento, etc.…

Es una obviedad decir, aunque conviene remarcarlo aquí, que el hecho de que la arquitectura del servicio de agrupación sea de replicación debe quedar totalmente escondida al usuario del servicio. Por otra parte vale también el principio genérico de que el servicio de agrupación no debe atacar nunca directamente las fuentes de datos de origen, Vuelve a ser importante remarcarlo aquí ya que en muy habitual que aplicaciones heredadas no dispongan de servicios de replicación. Si esto es así, deberá crearlos como parte del primer diseño que los necesite. La replicación suele ser por copia ya que se necesitan todos los atributos y registros de la entidad disponibles, pero puede valorarse también copias selectivas, como la partición horizontal, según cual sea la necesidad y el entorno de la aplicación. De hecho desde un punto de vista riguroso, es reorganización más que copia ya que la copia replicada se mantiene en el formato unificado proporcionado por el metaesquema. Un punto fundamental será la decisión de:

El tipo de mantenimiento: distribuido, centralizado, desde cada nodo o distribuido entre los nodos.

El lugar donde reside el master de la replicación. Una opción interesante es que la replicación se haga por reorganización guardando solo las referencias y/o los campos de acceso más habituales. Esta posibilidad, con un buen metaesquema, donde el lugar de origen de cada atributo esta perfectamente marcado, es muy fácil de montar.

En la figura se muestra una posible arquitectura de un servicio de agrupación de entidades en un diseño de replicación. Observe la presencia de un servicio asíncrono implementado por un agente y que denominaremos el sincronizador.

Para el diseño del sincronizador utilizaremos cualquiera de los recursos para replicación síncrona que hemos visto en el capítulo dedicado a replicación.

P

S

Servidor de agrupación

M

D

S

Punto deentrada

Entidades afectadas

Sincronizador

Serviciode origen

Gestióna las

entidades

AccesoRegistro

decambios

MPunto de

salida

Figura 207. Arquitectura del servicio de agrupación basado en

replicación

295

El proceso para la gestión de las entidades afectadas puede ser en paralelo. En la figura se muestra una solución Master-Slave. Sin embargo es muy frecuente que, al ser la copia replicada local, no sea necesario complicar el diseño y el acceso se realice a directamente a la base de datos. La cola de comunicación entre el sincronizador y el servicio en sí debe tener persistencia.

5. 3. Por servicios y replicación. Es obvio que en muchos casos ambas arquitecturas pueden combinarse. La arquitectura resultante será la agrupación de ambas.

6. Semántica CRUD (Create-Read-Update-Delete).

Una primera decisión a tomar puede ser dividir el servicio en dos basándose en el criterio de que la lectura es idempotente. Así aparecerán dos tipologías de servicio:

Servicio de lectura donde no tendremos problemas de consistencia, Recordemos que un servicio de lectura se usa en muchas más ocasiones.

Servicio de mantenimiento para las altas, modificaciones y bajas. El comportamiento es diferente si la arquitectura del servicio de agrupación de entidades es por servicios o por replicación. Veamos cada caso por separado partiendo de la base que el interpretador resuelve todas las diferencias y en particular las equivalencias de claves.

7. Semántica CRUD en la arquitectura por servicios. La operación de lectura no presenta más problemática que decidir que se hace en el caso de que parte de los atributos no se recupera. Siempre que pueda, mi consejo es que actúe por blanco o negro, o todo o nada. Si eso no es una opción posible en el análisis de consistencia, deberá marcar que campos son válidos y cuales no. No coloque nunca los valores por defecto: puede consumir a sus usuarios a graves errores de operación. Una forma de implementar esta opción es añadir a la respuesta, en caso de incompleta, un XML con los campos válidos. Observe lo que le complica la gestión admitir información parcialmente recuperada. Hágalo solo si realmente lo necesita en su análisis de consistencia. He elegido para el paralelismo de acceso la solución master-slave. En la

Punto deentrada

D Serviciode origen

MAcceso

Agregaciónde

resultadosInterpretador

MetaesquemaPunto de

salida

Figura 208. Lectura por servicios

296

práctica es la más utilizada por los mecanismos multihilo. En la figura de la derecha se muestra un esquema del posible diseño. Observe que la las transformaciones las realiza el paso de agregación de resultados a partir de los datos que le proporciona el Interpretador que encapsula el metaesquema.

La semántica de la operación de modificación es parecida y se muestra en la figura de la izquierda. En este caso es obligado trabajar con criterios de atomicidad, deshaciendo las operaciones si alguna de las actualizaciones falla. Si en alguna de las entidades de origen no existe el registro que se quiere modificar, el proceso de acceso deberá tratar esa fuente como alta en lugar de modificación. Para el mensaje de actualización puede escogerse entre:

• Enviar de nuevo todo el registro. • Enviar solo una lista con los valores modificados. En este caso una solución

XML puede ser muy útil. Los procesos de alta y baja son muy parecidos por lo que creo que no necesitan explicación adicional.

8. Semántica CRUD en la arquitectura por replicación. En la arquitectura basada en replicación el problema de la lectura se reduce a un acceso sobre la base de datos local donde está el esquema unificado. Si se separan los servicios de lectura y modificación, el servicio de agrupación de lectura puede evitar la arquitectura interna master/slave y actuar con mecanismos SQL convencionales.

Analicemos las otras semánticas. En el proceso de alta, después de realizarla en local, se anota en la cola del sincronizador el nuevo registro. El sincronizador se cuidará de registrarlo síncronamente en la central desde donde se propagará la resto de las copias. Recuerde una vez más que replicación síncrona debe leerse en el sentido de “tan rápido como se pueda”. Cuando el alta se realiza en la central o en otro nodo distinto, el registro acaba en todos los casos en la central. Así pues, la llegada de la modificación a cada nodo debe esperarse siempre desde la central.

Punto deentrada

D Serviciode origen

MAcceso

TransformarAtributos Interpretador

Metaesquema

Punto desalida

DeterminarReferencias

Figura 209. Modificación por servicios.

297

Esta espera puede resolverse de varias formas:

El servicio de agrupación ofrece a la central un servicio de actualización del nodo local.

Verificando una cola de operaciones pendientes donde la central anote los nuevos registros.

Haciendo que el nodo se suscriba a los cambios de la central: Recibiendo un evento cada vez que hay cambios. Accediendo periódicamente a buscarlos.

Estas dos posibilidades pueden ofrecerse a su vez de dos formas:

Como un hilo más del sincronizador. Como un agente independiente incluido en el servicio de agrupación y que trabaja con una de las filosofías anteriores.

En la figura se muestra una ampliación de la arquitectura del servidor de agrupación por replicación donde se usa un hilo para vigilar una cola donde la central registra los cambios. Observe que en este caso la comunicación de la replicación es por mensajes. Las semánticas de modificación y baja son parecidas y creo que no hace falta a estas alturas que las tratemos específicamente. Un momento puntual del ciclo de vida de un servicio de este tipo en la carga inicial y la auditoria. Para la carga inicial pueden usarse dos soluciones:

Una carga masiva por interfase, en la línea de otras que vemos en este libro. Utilizar el servicio de replicación para recibir uno a uno los registros.

No hace falta decir que es más eficiente la primera que solución que puede usarse también para implementar los procesos de auditoria y reconstruir rápidamente el nodo. La ventaja de la segunda es que ya esta programa.

Serviciode origen

P

S

Servidor de agrupación

Registro delos cambios

recibidosdesde elexterior

M

D

S

Punto deentrada

Entidades afectadas

Sincronizador

Gestióna las

entidades

AccesoRegistro

decambios

MPunto de

salida

Servicioreplicación

origen

Figura 210. Servidor de agrupación por replicación ampliado

298

9. Implementación utilizando los recursos del motor de la base de datos. Pude utilizarse como parte de la solución los mecanismos de replicación proporcionados por los motores de las bases de datos. En general, realizan procedimientos de publicación/suscripción utilizando snapshot como mecanismo de replicación síncrona. Si decide utilizar estos recursos deberá consultar la documentación de cada motor, y si puede, a alguien con experiencia real en su uso.


Metodología de Diseño Distribuido 1. Introducción.

¡Ha llegado el gran momento! Vamos a encajar todos los conceptos y todas las piezas presentadas hasta ahora en una metodología integrada de diseño. Como ya se explicó en la primera parte hay dos formas básicas de diseñar aplicaciones distribuidas.

Aplicaciones de Desarrollo Rápido Aplicaciones Avanzadas.

Antes de seguir avanzando este capitulo conviene que repase aquel otro de la primera parte si no lo recuerda suficientemente bien. En este capitulo le voy a introducir las etapas del diseño de las aplicaciones avanzadas. Recuerde que el método a aplicar en las de tipo RAD supone, básicamente, eliminar o minimizar etapas. Ya ha quedado claro a lo largo de los capítulos anteriores que el termino C/S es aplicable tanto a arquitecturas C/S convencionales basadas en sistema operativo como a Internet. Y que muchas veces habrá servicios desacoplados. Por esa razón, voy a usar en lo que sigue de forma genérica el término distribuido con independencia de que la técnica de implementación sea una u otra.

2. Recordatorio de las Etapas de Diseño. Para que las recuerde le propongo que consulte estos dos esquemas. Si no recuerda alguna de las etapas, vuelva a repasar el capítulo de la primera parte.


2. 1. Aplicaciones avanzadas.

Análisis/Diseño funcional.

Diseño de la Arquitectura Distribuida

Diseño de Consistencia.

Diseño de la Administración del Sistema.

Diseño Distribuido

Figura 211. Etapas de diseño de las aplicaciones avanzadas

2. 2. Aplicaciones RAD.

3. Metodología Integrada de Diseño.

Las etapas del diseño distribuido se organizan en la metodología integrada que se muestra en la siguiente figura:

Análisis/Diseño funcional.

Diseño de la Arquitectura Distribuida (nulo en RAD).

Diseño de Consistencia.

Diseño de la Administración del Sistema (mínimo en RAD).

Diseño Distribuido

Figura 212. Etapas de diseño de aplicaciones RAD


DiseñoFuncional

Diseño de la Arquitectura distribuida

Análisis de los Datos

Distribución del Proceso AplicaciónCrear Arquitectura

de servicios

Map to reality

Diseño Administración

Diseño DistribuidoDiseño de

Consistencia

Metodología Puzzle

Especificaciónservicios

Especificaciónresto piezas

Plan de Integración

Plan Estratégico Distribuido de la

Compañía

Completar Diseño de los clientes

Integración funcional

Lógica presentación y/o flujo de procesos

Lógicas de proceso y datosEspecificación piezas cliente

Ampliar el cuadrocontrol admistraciónDiseñar el cuadro

control del negocio

Diseño Tecnológico

Identificación fronteras

Precondiciones de Plataforma

Identificación de puntosde heterogeneidad

Figura 213. Metodología Integrada de Diseño Distribuido.

A continuación detallaremos el contenido de cada una de las etapas. Observe, sin embargo, que como ya se ha dicho anteriormente, la etapa de diseño es una etapa del diseño tecnológico que se “intercala” entre el funcional y/o el tecnológico y la etapa de programación convencional. Y observe también la utilización del Plan Estratégico Distribuido de la Compañía como documento de consulta, y obligaciones a cumplir, que en todo momento ha de estar presente en el momento de tomar decisiones. Su situación en la figura superior a la entrada del proceso entre el diseño funcional y el diseño distribuido alude a ese rol.

4. Contenido de cada una de las etapas. 4. 1. Análisis Funcional /Especificación – Diseño de la arquitectura del

tecnológico. El análisis tecnológico o especificación establece las prestaciones funcionales básicas que se piden al Sistema de Información que se va a crear. Recuerde que se ha de hacer sin pensar que después la arquitectura será distribuida. Si la aplicación es de desarrollo rápido, este paso proporciona habitualmente todo lo necesario para la etapa de desarrollo tecnológico. En este tipo de aplicaciones, además, lo normal es que no haya etapa de diseño tecnológico convencional. SI la aplicación distribuida que se va a construir es un modelo avanzado existirá una etapa de diseño tecnológico para construir la arquitectura del sistema de software. Tras ella se iniciará la etapa de diseño distribuido.


Como ya he remarcado, por una u otra vía, los resultados de estas etapas previas proporcionan siempre:

La descripción de los datos, contenido, relaciones y estructura. Procesos de transformación de la información. Integraciones de ejecución que tienen en cuenta roles, circuitos, etc.

Las diferentes metodologías se diferencian en el método, las herramientas y la forma en que reflejan esos contenidos, pero todas dan como mínimo esa información. La metodología de diseño distribuido se basará en ellos. Para simplificar la notación de los ejemplos y centrarnos en los conceptos de diseño distribuido, en los ejemplos que acompañan a las exposiciones usaremos MAFDRA, el método de diseño funcional RDA presentado anteriormente.

4. 2. Determinación de las precondiciones de la plataforma.

4.2.1. Identificación de las fronteras. Estudiando la infraestructura de la plataforma distribuida, la identificación de las fronteras realizará en las siguientes etapas.

1. Incluir, si ha lugar el incremento de plataforma que supondrá la nueva aplicación.

2. A partir de los niveles lógicos de la plataforma, identificar claramente los nodos donde va a localizarse los servicios con especial cuidado en aquellos donde se van a localizar las bases de datos.

3. Relacionar los nodos cliente que no son fronterizos. Lo normal es que todos los clientes tengan frontera con sus servicios por lo que es mejor identificar directamente los que son locales.

4. Hacer una propuesta de localización de todos los nodos sobre la plataforma.

5. Identificar las fronteras. Si una misma función está en un nodo fronterizo y en otro que no lo es, se ha de suponer que existe frontera. Recuerde ser conservador, donde no identifique frontera, nunca podrá haber frontera sin modificar el diseño.

4.2.2. Determinación de los puntos de heterogeneidad.

A partir del Plan Estratégico de la Compañía averiguaremos que puntos de heterogeneidad hay que considerar en la diseño que empezamos a desarrollar. Esta fase puede impulsar una primera actuación si se detecta que alguno de estos puntos puede y debe ser resuelto con aumento de la plataforma: se preverá eliminarlo, se planificará la inversión y el timming y se actuará en el diseño como si ya estuviera resuelto. Para evitar contratiempos se incluirá en el análisis de riesgos el seguimiento de este punto.

4. 3. Diseño de la Arquitectura Distribuida.


Partiendo del análisis funcional, el diseño de la arquitectura distribuida se responsabiliza de repartir los datos y la funcionalidad por el sistema distribuido. Se realiza en cuatro etapas:

4.3.1. Análisis de los datos. En esta etapa se analiza el modelo de datos del funcional y se integra en la plataforma distribuida obteniendo dos resultados: 4.3.1.A. Arquitectura de los datos.

En función de los criterios aplicables a los datos se decide el modelo que más conviene al sistema distribuido. La arquitectura de datos se construye combinando los modelos de datos entre los presentados en los capítulos dedicados a los datos.

4.3.1.B. La lógica de datos del sistema distribuido. Encapsulan la lógica de datos que se decide implementar en servidores convencionales o en procedimientos catalogados.

4.3.2. Distribución del Proceso de la Aplicación. Se distribuye la funcionalidad de los procesos en el sistema distribuido identificando los servicios de proceso. En un capítulo posterior repasaremos los criterios para identificar y separar los servicios.

4.3.3. Creación de la Arquitectura de Servicios. Una vez identificados los servicios, se crea la arquitectura de servicios añadiendo:


4.3.3.A. El modelo de comunicación. De cada servicio con sus clientes,

4.3.3.B. El formato del mensaje. Especificación y cabecera del mensaje de comunicación o del fichero XML involucrado.

4.3.3.C. Las dependencias entre servicios. Cuando uno o más servicios utilizan a su vez otros servicios, habrá que elegir como se establece esa dependencia. En principio, la relación entre dos servidores es, por defecto, la delegación de servicio. Y con un agente el traspaso de responsabilidad. Pero recuerde que hay otras formas de establecer esas dependencias. Más adelante recordaremos los criterios para elegir la más conveniente.

4.3.3.D. Modo de ejecución y de arranque. Aunque el modo de ejecución habitual de un servidor es continuado y la forma de arrancarlo estática, recuerde que un servidor puede arrancarse dinámicamente a petición y ejecutarse temporalmente.

4.3.4. Map to reality.

No he conseguido nunca una traducción clara al castellano tan gráfica como el término inglés. Por lo tanto voy a seguir utilizándolo. La función básica de esta etapa es comprobar si el modelo de arquitectura distribuida es técnicamente viable en la plataforma de sistema prevista y si el rendimiento estará dentro de los parámetros deseados. Puede sorprender que esta etapa, más propia del final de la aplicación que del diseño, haya de adelantarse. No debería ser así, ya que estamos hablando de un entorno distribuido donde la plataforma ya hemos visto que tiene mucho a decir. Esta etapa se realiza adelantando una cosa que habrá que hacer tarde o temprano: la localización de los servicios sobre la plataforma lógica, que como ya sabemos, lleva implícita una plataforma física. Hacerlo así, permitirá identificar con tiempo suficiente problemas del estilo de:

Demasiada carga para un nodo: la máquina puede no tener suficiente capacidad de proceso, memoria, disco, etc. Demasiado tráfico de líneas que dificulta alcanzar los tiempos de repuesta necesarios. Necesidad de localizar servicios en puntos de la arquitectura de niveles físicos en los que no hay nivel lógico asociado. Etc.


Y tomar decisiones para solucionar los problemas detectados. Las decisiones pueden ser tres tipos:

Ampliaciones de la plataforma, decidiendo, por ejemplo, cambiar una máquina servidora de un nodo por otra más potente. Modificación de la plataforma lógica, añadiendo, por ejemplo, administración de sistema a un nivel físico y incorporando así un nuevo nodo a un nivel lógico o incluso creando un nivel lógico totalmente nuevo. Modificación del diseño, modificando la arquitectura de datos o de servicios creada. Cuando se elige esta solución, se justifica el bucle que habrá observado dentro de la casilla de arquitectura distribuida en el esquema de la metodología de diseño integrada presentada antes. Pero no se engañe, si tiene que dar más de una segunda vuelta (dos en raras ocasiones), revise su solución, probablemente hay algún punto en que ha tomado decisiones equivocadas. Busque donde. Pero no caiga en el otro extremo: la solución fácil, ampliar la plataforma, no siempre es la buena en prestaciones / coste. Así, por ejemplo, para resolver la cogestión de un nodo la mejor solución puede no ser una ampliación del nodo sino arrancar parte de los servicios a petición; por ejemplo, puede pasar que un bloque de servicios se utilice solamente cuando otro bloque no esté activo. Y si da otra vuelta no olvide volver a comprobar el “map to reality”.

4. 4. Diseño de consistencia.

Añade resistencia contra errores y caídas y establece los procesos automáticos de recuperación y como hay que trabajar (si es necesario) cuando algunos de los servicios no están disponibles. Esta situación de trabajo bajo servicios caídos la denominaré trabajo en situación de emergencia pero en su visa profesional llámela trabajo off line es menos dramático y más marquetiano. La forma de hacerlo es clara. Se repasa la arquitectura de servicios y en todas las comunicaciones de los servicios activos se realiza la pregunta: ¿qué hay que hacer si éste servicio falla? El diseño de la consistencia supone definir procesos específicos para gestionarlo. Estos procesos de control han de añadirse a los ya construidos lo que supone volver a la etapa de diseño de la arquitectura distribuida. Este hecho justifica la flecha que vuelve en el esquema de la metodología de diseño integrada de la casilla de la consistencia a la de arquitectura distribuida. Normalmente el proceso es “limpio” ya que supone cambios mínimos o inexistentes en la arquitectura construida. Y en ningún caso debe suponer hacer más de una nueva vuelta al bucle de diseño de la arquitectura distribuida.

4. 5. Diseño de la administración del sistema. Añade las funciones de administración para ayudar al Administrador de Sistema a gestionarlo de forma distribuida. Se focaliza a través del cuadro centralizado de control y gestión que se presentará más adelante.


La introducción a esta parte del diseño ya se ha realizado en la primera parte del este libro al introducir la administración del sistema distribuido. Repáselo allí si no lo recuerda ahora. Recuerde, sin embargo, que esta etapa del diseño proporciona las políticas de administración. Si las herramientas de Middleware no aportan toda la funcionalidad necesaria, esta etapa del diseño complementará esas funciones de Middleware con herramientas creadas específicamente. Dada la naturaleza de esas nuevas herramientas, lo más probable es que queden disponibles para aplicaciones posteriores como nuevos elementos del Middleware, el de usuario en este caso. Recuerde también que diseño tecnológico debe asegurar y verificar la seguridad y que para que un sistema sea seguro debe garantizar las siguientes características:

Identificar a los usuarios. Autentificarlos. Controlar el acceso a todos los recursos. Anotar dinámicamente los accesos de los usuarios al sistema. Impedir los accesos que vulneren la seguridad. Garantizar la integridad de los datos. Mantener la disponibilidad de datos, procesos y recursos.

Todo ello debe ser mantenido dentro del sistema distribuido por las herramientas disponibles en el DSM y las añadidas por el análisis de administración dentro del sistema distribuido.

4. 6. Identificación y especificación de piezas. Después de realizar las etapas de diseño específicas del sistema distribuido, la aplicación de la metodología Puzzle permitirá identificar piezas que se añadirán a las obtenidas en la etapa de diseño tecnológico convencional y preparar la implementación del sistema distribuido como un conjunto integrado de todas las piezas. Se identificarán dos tipos de piezas:

Piezas ya construidas que se reutilizarán. Nuevas piezas que habrá que construir y decidir, con criterios de coste, si se dejan reutilizables o simplemente ligadas a la aplicación. En las organizaciones en que exista, esas piezas deberán someterse al Comité de Reusabilidad.

Es difícil marcar criterios genéricos a esta etapa. Hay, sin embargo, algunos que sí conviene seguir:

Los servidores serán siempre piezas que se encapsularán junto con un mecanismo de llamada. Ya hemos hablado en otros momentos de la gran ventaja que esto supone para la adaptabilidad de la aplicación y para la minimización de los efectos de los errores del diseño.

Las piezas aportadas por las etapas de administración acostumbran a ser piezas de alto nivel de Middleware de Usuario.

Todas las piezas nuevas deberán especificarse mediante su contrato de software tal como se ha explicado en el capítulo correspondiente. Las


piezas a comprar deberán iniciar el proceso de adquisición de cada compañía. Recuerde la importancia de la certificación del contrato de software tanto de las construidas como de las compradas.

4. 7. Diseño de los Clientes.

Una vez separados e identificados los servicios, el resto de las piezas se han de diseñar e integrar en programas clientes. Diseñar un programa cliente ya es un trabajo “convencional”. Para integrar las funciones cliente en programas hay diversas posibilidades o modelos de integración.

Aunque la integración gráfica, GUI o Internet, es, de largo, la más utilizada, recuerde que no es la única y que un buen diseñador elegirá la que más le convenga. Los procesos de negocio resultantes se habrán de introducir en el cuadro de control del sistema distribuido y en el cuadro de control del negocio que presentaremos más delante. Finalmente, remarcar que en la parte cliente es también muy recomendable utilizar metodología Puzzle. Ello supondrá la identificación y especificación de un nuevo bloque de piezas a construir o comprar. A nivel cliente es normal la aparición de piezas de alto nivel tipo Framework que modelan un comportamiento. Utilizar aquí OO como herramienta de implementación puede aumentar espectacularmente la reutilización. Y recuerde que en aplicaciones RAD, que son muy fat client, trabajar bien supone también reutilizar.

4. 8. Plan de Integración. Ya hemos hablado anteriormente de que la fase de integración, posterior a la certificación de piezas y prueba de los programas, es fundamental y crítica en los sistemas distribuidos. Ese plan de integración es fundamental cuando la aplicación aporte servicios de nueva fabricación, de los que habrá que probar cuidadosamente y productos de Middleware de Usuario para sistemas heterogéneos en los que habrá que verificar el comportamiento. Es muy necesario pues, pues, que el diseñador piense y planifique cuidadosamente cual ha de ser el plan de integración y lo formalice en un documento. El plan de integración se desglosa en una secuencia de unidades de prueba organizada por niveles. Cada unidad de prueba incorpora una nueva capa e incluye que se ha de hacer fallar para comprobar cual ha de ser la reacción del software. Cada nivel de prueba ha de establecer:

Elementos de la plataforma involucrados. Piezas a integrar normalmente servicios y clientes back-ground. El contrato de software dará el comportamiento a verificar.


Localización. Fallos a provocar. Procesos de administración de las piezas a verificar. Dependencias entre las piezas, o servicios, a verificar.


Diseño de la Arquitectura Distribuida de Servicios

1. Introducción. En este capítulo y en los siguientes vamos a describir detalladamente cada una de las etapas de la metodología general integrada presentada en el anterior. El contenido de este capítulo es una aplicación sistemática e integrada de todo aquello que se ha presentado anteriormente y que tiene influencia en el diseño de la arquitectura distribuida. Por ello, todos los temas básicos sobre modelos de comunicación, petición / respuesta, arquitectura de servidores, modelos de datos y procesos, etc..., se usarán directamente y por esa razón ¡hay que recordarlos en todo momento!

2. Etapas del Diseño de la Arquitectura de servicios del Sistema Distribuido.

El detalle de las etapas de esta fase del diseño se muestran en la figura siguiente donde se detallan las etapas presentadas en la metodología general.

Vamos a hablar con detalle de cada una de estas etapas.

3. Análisis de los datos La identificación y separación de los servicios se hace a partir de los datos y de los procesos. Como ya he comentado, creo que la importancia de los datos en un

Identificar funcionesDistribuirlas por niveles lógicosSeparar funciones entre clientes y servidoresIdentificar servicios

Distribución del Proceso de la

AplicaciónDefinir comunicación cliente-servidor.Definir arquitectura servicios.Definir arquitectura cliente/servidorAnalizar

Crear la Arquitectura Distribuida

LocalizaciónConfiguraciónAnalizar rendimiento

Map to Reality

Análisis Funcional

Completarel Diseño

Arquitectura de datosAdaptar diseño funcionalDiseño lógica de datosEspecificarAnalizar rendimiento

Análisis deDatos

Análisis Tecnológico

Figura 214. Etapas del Diseño de la Arquitectura Distribuida


sistema distribuido es tan condicionante que conviene hacer en primer lugar la identificación de los servidores de datos. A grandes rasgos esta etapa, a partir del modelo de datos y de los condicionamientos de implementación del sistema distribuido, escogerá en modelo de datos distribuido más adecuado plasmándolo en una Arquitectura de Datos Distribuidos, adaptará el Diseño Funcional con los nuevos procesos resultantes, identificará los servidores de lógica de datos necesarios para gestionar correctamente el sistema distribuido, plasmándola en una Lógica de Datos del Sistema Distribuido. Las etapas de esta fase se detallan en el siguiente cuadro:

Observe que, una vez relacionados los prerrequisitos, hay una etapa clara de diseño de datos y posteriormente una evaluación de rendimiento que puede llevar a aceptar el modelo o ha modificarlo en una segunda vuelta. Comentemos a continuación, y con detalle, cada una de las etapas. 3. 1. Prerrequisitos.

El análisis funcional y el plan estratégico establecen (¡o al menos deberían hacerlo!) una serie de prerrequisitos que van ha tener una importancia básica a la hora de tomar decisiones.

3.1.1. Puntos de heterogeneidad. A lo largo de los capítulos anteriores hemos ido encontrando y relacionando diversas causas que generan puntos de heterogeneidad. En particular hay tres que conviene remarcar:

LocalizaciónModelización

Analizar Rendimiento

AnálisisFuncional /

Tecnológico

Arquitectura de Datos - Valorar y Decidir

Identificacióndel resto deServidores

Modelo, esquema accesoPiezas, servidores y procedimientos catalogados

Especificar la Arquitectura de Datos

Localización obligadaAplicar criterios y escoger la Arquitectura Distribuida

Diseño Arquitectura de Datos Distribuida

Decidir el modo de acceso entre accesos directos SQL y encapsulamiento de la lógica de datos.Identificar servicios de agrupación de datos.Identificar patrones DTO.Elegir modelo encapsulamiento (ex: pr.catalogados)Establecer la arquitectura de servidores de datos.Identificar posibles arquitecturas de pre-condición

Diseño de la Lógica de Datos Distribuida

Localización del mantenimiento y codificación distrb.Criterios de auditoria

Mantenimiento y Auditoria

Añadir nuevas funciones datosAdaptar Diseño Funcional

Puntos de acceso heterogéneoNiveles lógicosTamaño, accesibilidad y volatilidadTiempos de respuesta necesariosLocalización de los puntos de mantenimientoCodificación Dis.

Pre-requisitos

Figura 215. Etapas del Análisis de los datos


3.1.1.A. Conexiones lentas. Entenderemos por conexiones lentas, tanto la velocidad como la necesidad de levantar la línea. Normalmente ocurre en conexiones remotas. Condicionan costes de comunicaciones (cada vez menos) y tiempos de respuesta. En general son generadores de arquitecturas de replicación.

3.1.1.B. Diferencias semánticas y sintácticas entre entidades. En general se resuelven con un metaesquema que conduce a piezas, servidores independientes o no, que encapsulan la lógica de datos que las resuelven.

3.1.1.C. Heterogeneidad de Middleware de datos. En franco retroceso en un mundo en que SQL reina como soberano absolutista (y bondadoso). Conlleva el cambio del motor de datos o en encapsulamiento de la lógica de datos.

3.1.2. Niveles Lógicos.

De la arquitectura física, que condiciona los puntos de localización de los datos por la existencia en ellos de servicios de administración, copias entre otros. De hecho, este prerrequisito no viene del funcional sino del plan informático de la compañía.

3.1.3. Factores de gestión y proceso. Tratados ampliamente al hablar de la replicación. Se enumeran en este grupo factores del tipo:

Tamaño de los datos. Actividad o número de accesos. Volatilidad versus estabilidad, en referencia al número de cambios. Servicios de administración disponibles. Etc.

Repase en aquel capítulo las implicaciones de cada uno de los factores si no las recuerda. La idea es muy clara: revisar la lista en cada diseño y comprobar, en ese diseño, las implicaciones de cada uno de los factores.

3.1.4. Tiempos de respuesta admisibles.

3.1.5. Codificación distribuida. Repasar el capítulo anterior dedicado a este tema.

3. 2. Diseño de los Datos. Esta etapa tiene como objetivo valorar todos los condicionantes funcionales y tecnológicos recogidos, aplicar los criterios teóricos y decidir la arquitectura de los datos y de su lógica de tratamiento.


Se organiza en cinco subetapas.

3.2.1. Diseño de la Arquitectura de Datos Distribuida. Se deberá proponer la arquitectura de datos distribuidos eligiendo la combinación de modelos de datos que más convengan a la aplicación que se está diseñando. Los modelos y criterios ya se han visto anteriormente. No voy a caer aquí en el error de repetirlos. Repase en esos capítulos, consulte la agrupación de criterios que le presento en el apartado siguiente y aplíquelos aquí. Solo recordar que, además resolver el problema planteado, se deben conseguir los costes mínimos de administración y comunicaciones que garanticen los tiempos de respuesta necesarios.

3.2.2. Mantenimiento y auditoria.

Aunque es un parte de la adaptación del diseño funcional, la importancia que este tema tiene dentro de la identificación de servicios de datos, hace necesario realizar de forma específica la reflexión sobre estos dos temas, que en el fondo, no son más que mantener la coherencia e integridad de los datos del modelo distribuido elegido Se ha de atacar en varios pasos:

3.2.2.A. Definir el foco del mantenimiento de cada entidad. Permitirá saber donde, como y quien mantiene y como se propagan los cambios.

3.2.2.B. Criterios de codificación distribuida.

3.2.2.C. Definir la política de auditoria. Permitirá conocer como hay que controlar la propagación de los cambios y como se auditarán periódicamente. Todo ello se reflejará en las políticas de seguridad e integridad.

3.2.3. Adaptar el Diseño Funcional.

En función de los resultados obtenidos en el diseño de la arquitectura de datos distribuida y de la implementación de esa arquitectura resultante, se habrá de modificar el análisis funcional para adaptarlo al modelo escogido, incluyendo los procesos necesarios para gestionarlo.

3.2.4. Diseño de la Lógica de Datos Distribuida. Esta etapa puede hacerse ahora o retrasarla a la identificación de los servidores de procesos. Por coherencia de exposición voy a desarrollarla aquí.


3.2.4.A. Decidir el modo de acceso. Habrá que decidir que accesos se hacen por SQL directo y cuales se encapsulan en la lógica de datos. Esto permitirá identificar servicios de datos que después habrá linkar en fase de programación o implementar con servidores convencionales, servidores SQL o procedimientos catalogados. Le aconsejo que cómo criterio general, encapsule todos los accesos en piezas. Estas piezas podrán linkarse o independizarse en servidores según otros criterios que ya hemos visto anteriormente. Recordemos algunos. La localización obligada condicionará los procesos. Si hay accesos desde entornos cliente situados fuera de la localización se habrán de gestionar por servidores localizados sobre la zona de la base de datos. Si la lógica de datos integra más de una entidad (por ejemplo, los datos descriptivos de cliente y su crédito), hay acceso a una entidad particionada (por ejemplo, clientes por delegaciones) o resuelve alguna heterogeneidad, encapsule siempre. Y si el acceso se ha de hacer desde máquinas “no locales” que es lo normal, defínalos siempre como servidores. Hay que separar los servicios de consulta (idempotentes) de los de mantenimiento y encapsularlos en servidores diferentes. Es conveniente hacerlo cara a: Establecer el análisis de consistencia (las consultas en general no lo necesitan). Facilitar la programación del paralelismo, fácil en los servicios de consulta, estadísticamente muchísimo más utilizados que los de mantenimiento.

Recuerde otros criterios ya aparecidos: Reglas de negocio fijas, priman modelo estático. Seguridad alta priman modelos dinámicos. Replicaciones síncronas fuerzan a servidores.


Y finalmente, que en todo momento se ha de garantizar la coherencia y la integridad de los datos y recuerde la importancia que en este tema tiene el uso de tickets.

3.2.4.B. Identificar los servicios de agrupación de datos. Ya hemos hablado de este tema en el capitulo correspondiente. Si no los recuerda, repáselo.

3.2.4.C. Identificar los patrones DTO. A partir de las fronteras, decida cuando aplicarlos. Siempre que pueda, hágalo.

3.2.4.D. Escoger el modo de encapsulamiento. Una vez identificados los servicios de lógica de datos, habrá que decidir si se implementan con servidores convencionales o con otras formas de encapsulamiento como procedimientos catalogados o servicios de SQL embebido.

3.2.4.E. Establecer la arquitectura entre los servidores de datos. En los servidores de datos la arquitectura suele ser muy poco profunda y por delegación de servicio. Más adelante se recordarán los criterios para decidir las arquitecturas entre servidores. En el caso de datos, existe uno de específico que es garantizar la integridad y seguridad de los datos, que puede obligar a “romper” un servidor en dos; el segundo encapsulará la integridad y/o la seguridad y podrá ser utilizado por delegación por otros servidores de datos.

3.2.4.F. Identificar posibles arquitecturas de precondición. Aunque la precondición es una forma más de arquitectura, dada su importancia conviene identificarlas de forma precisa e individualizada. Decida como implementa la precondición, escogiendo siempre que pueda la solución por colas. La implementación de precondiciones obliga a implementar los servicios de datos con servidores convencionales.

3.2.5. Especificar la Arquitectura y la Lógica de los Datos.

Finalmente habrá que especificar y documentar la arquitectura de datos distribuida en sus dos componentes.


3.2.5.A. Modelo distribuido y esquema acceso. Para documentar el modelo se incluirán en el esquema conceptual las nuevas tablas necesarias para implementar el esquema de acceso distribuido.

3.2.5.B. Mantenimiento y auditoria.

Incluye los focos de mantenimiento, las copias master, los planes de replicación y auditoria, si los hay, y los criterios de codificación distribuida. Los planes se completarán tras el análisis de administración.

3.2.5.C. Piezas, servidores, procedimientos catalogados y servidores de SQL.

Se utilizarán los recursos normales de la instalación para especificar piezas. En la descripción habrá que incluir de forma clara y precisa que lógica de datos se implementa en cada pieza.

3. 3. Analizar el rendimiento (Perfomance).

Una vez decidida la arquitectura de datos, y debido a la naturaleza de la aplicación distribuida hay que analizar el rendimiento de la solución escogida. El tema es fundamental antes de seguir con las otras etapas del diseño distribuido. Para realizar este análisis la mejor referencia es evaluar los tiempos de respuesta para confirmar que están dentro de los parámetros previstos y hacer una evaluación de los costes de comunicación, si hay conexiones remotas claro está. Realizar este estudio en este momento del diseño no es ninguna tontería. Habrá que empezar por implementar, si no existe ya, la parte que se prevea critica del modelo de datos, y lo que es peor por trabajo, rellenar las tablas para poder hacer evaluación de rendimientos reales. Una vez cargado el modelo, hay dos soluciones para evaluar el rendimiento:

Implementar una maqueta de la lógica de datos en que solo se evalúen los accesos a los datos.

Utilizar una herramienta que permita realizar SQL sobre el modelo de datos elegido

De cualquier forma, el coste de hacer un camino u otro está plenamente justificado con el hecho de obtener la garantía del rendimiento esperado. Y por favor, pruebe siempre con la situación de la plataforma más desfavorable. Un consejo, conserve máquinas obsoletas para implementar los modelos de evaluación de rendimiento. La razón en obvia, así cualquier situación real será más favorable a la de la prueba.


Los resultados pueden obligar a retocar el modelo de datos inicialmente previsto. En casos de problemas, se hace difícil tipificar las correcciones a realizar, aunque hay soluciones clásicas para mejorar el rendimiento:

Cambiar por máquinas más potentes los servidores de las bases de datos. La experiencia dicta que difícilmente va a conseguir mejoras substanciales de rendimiento con ampliaciones de las máquinas actuales.

Definir claves secundarias para habilitar vías rápidas de acceso. ¡Ojo!, no introduzca claves secundarias innecesariamente, relantiza los procesos de alta y modificación. El criterio es ponerlas siempre, ¡qué sea realmente necesario! Y “el realmente necesario” solo lo puede marcar una evaluación práctica del rendimiento.

Incluir en el modelo de datos distribuido replicación, en muchos casos de sumarización.

Sustituir lógica de datos implementada en servidores convencionales por procedimientos catalogados.

Los cambios introducidos pueden obligar, aunque no sea muy habitual, a volver a hacer una vuelta de diseño de análisis de datos; de ahí la flecha de retorno que observará en la figura del esquema general de diseño de los datos.

4. Criterios para diseñar la arquitectura de datos.

Tenga en todo momento presente las fronteras que ha decidido establecer en el sistema distribuido. Conviene marcar dos pasos: 4. 1. Localización Obligada.

Localice primero aquellas entidades en la que no pueda elegir por estar localizadas como precondición, tanto física como de proceso o condicionamiento organizativo. Vigile en cualquier caso, que una aparente localización obligada no pueda, en una diseño concreto, ser mejorada con otro modelo de replicación o particionado.

4. 2. Criterios funcionales. Se habrá de resolver a continuación, para el problema concreto que estemos diseñado, el problema clásico: los datos han de estar lo más cerca posible de los usuarios, impulso hacia arquitectura distribuida, versus facilidad de administración y mantenimiento, impulso hacia la centralización. Recuerde que para decidir la localización deberá respetar los niveles lógicos de la compañía y que la arquitectura resultante será, normalmente, una combinación de más de un modelo de datos. Aunque ya he comentado antes que no voy a repetir la lista de criterios, existen unos criterios genéricos utilizables a modo de plantilla. Se agrupan en dos grandes bloques:


4.2.1. Criterios independientes de la optimización del rendimiento a la plataforma.

Son criterios que pueden aplicarse sin considerar las características de la plataforma física.

4.2.1.A. Por las características de la aplicación.

• Si tiene datos de mantenimiento centralizado y conexiones

rápidas podrá decidirse por modelos centralizados. • Si tiene mantenimiento centralizado y conexiones lentas o

nómadas, habrá de replicar y decidir todos los factores de la política de replicación (repáselos).

• Si tiene mantenimiento descentralizado podrá decidirse por modelos distribuidos, horizontal o verticalmente.

4.2.1.B. Por la tipología de los datos:

4.2.1.B.a. Datos de Usuario.

Dentro del ordenador del usuario (primado) o en el servidor departamental.

4.2.1.B.b. Datos Departamentales. • De tamaño medio y pequeño en el servidor de red

departamental, si éste es un nudo lógico, y en el nivel inferior si el servidor departamental no es más que nodo físico.

• De gran volumen y/o con requerimientos estrictos de seguridad, dentro del HOST o en servidores departamentales especializados, que en muchas ocasiones, sirven a más de un departamento. Para estos servidores son frecuentes soluciones UNIX / LINUX.

4.2.1.B.c. Datos Corporativos de mantenimiento centralizado

• De elevada volatilidad y/o gran tamaño y/o estrictos

requerimientos de seguridad dentro del servidor corporativo, localizado muchas veces en un HOST, y bajo un modelo centralizado.

• De tamaño medio, alta actividad de consulta y poca volatilidad, bajo un modelo replicado en los servidores departamentales. En este caso hay que valorar el uso de replicación síncrona o no.

4.2.1.B.d. Datos Corporativos de mantenimiento distribuido.

Sobre un modelo particionado en los servidores departamentales. Índice en el HOST.

4.2.1.B.e. Usuarios nómadas Aquí hay que tener presente también los casos de usuarios nómadas. Este tema afecta tanto a datos como procesos y, por


tanto, puede desarrollarse aquí o allí. He preferido hacerlo en el apartado de procesos.

4.2.1.C. Mantener los datos más usados en zonas de rápido

acceso. Hay dos posibilidades básicas de conseguir almacenamientos de acceso rápido:

• Localizándolos lo más cerca posible de los usuarios: utilizando técnicas de replicación o particionado de los datos.

• Utilizar técnicas cash.

4.2.1.D. Agrupar datos afines en la misma localización. Criterio aplicable en modelos particionados y en menor medida en replicación.

4.2.1.E. Emplear al máximo técnicas de paralelismo. Potencia el uso de arquitecturas de servicios master-salve. Este criterio es de intereses en los servicios de consulta y complicado de utilizar en servicios de mantenimiento

4.2.1.F. Evitar los cuellos de botella. Por ejemplo, colocando varias instancias del servicios de acceso a los datos en maquinas diferentes a la localización de la base de datos. En la práctica se diseña como un caso particular del anterior.

4.2.1.G. Utilizar empaquetamiento.

4.2.2. Criterios dependientes de la optimización del rendimiento a la plataforma.

Son criterios que pueden aplicarse para optimizar el rendimiento en función de las características de la infraestructura y la localización. Tienen el inconveniente que están afectados por los cambios en estos dos componentes. Sin embargo, en la práctica, los cambios en la infraestructura son para mejor y los cambios en las localizaciones de datos son muy poco frecuentes.

4.2.2.A. Adaptación a la red y las comunicaciones.

Adaptar el volumen de las trasmisiones al ancho de banda de la red y las comunicaciones.

4.2.2.B. Adaptar la arquitectura del servicio a la localización de los

datos. Imagine que tiene que obtener los datos básicos de un cliente y los pedidos que ha realizado en un periodo y que la entidad cliente está en una base datos en el nodo A y los datos de pedidos están en una segunda base de datos en el nodo B. Puede establecer una arquitectura en que el cliente pida el servicio a un servido en A que


obtenga los datos del cliente en A y delegue a otro servidor en B obtener los pedidos.

4.2.2.C. Minimizar la lactancia. Normalmente, el tamaño del mensaje en servicios de datos es muy grande. Evitando los nodos intermedios entre el cliente y la base de datos ganaremos tiempo. Otra posibilidad es utilizar arquitecturas de filtro mensaje anexo.

5. Un interesante dilema sobre la gestión de las restricciones de integridad.

¿Qué le parece mejor, gestionar las restricciones de la base de datos por software o por implementarlas en el esquema lógico de la base de datos? Es un muy interesante dilema con defensores en cada una de las dos posturas. La implementación de las restricciones por la base de datos obliga a romper esas restricciones antes de muchos procesos. Hacerlo desde los programas facilita la programación pero deja la responsabilidad a la aplicación. ¿Me pide opinión? Ponga las restricciones en la base de datos aunque eso le produzca algún problema más de programación. La necesidad de soluciones robustas en un tema tal vital y difícil como los datos justifican el uso de cualquier mecanismo que ayude a garantizarlos.

6. Distribución del Proceso de la Aplicación. Una vez realizado el análisis de los datos, puede iniciarse el análisis de los procesos en el sistema distribuido. Notará que algunas de las etapas que aquí se citarán ya se han explicado en el apartado anterior ya que los datos llevan a la identificación de servidores de lógica de datos, procesos al fin de cuentas. Procuraré no repetirme, citando únicamente en secuencia las etapas coincidentes. En los capítulos de introducción ya se habló cual va ha ser la base de la estrategia:

Identificar funciones, obtenida en las etapas de análisis y diseño tecnológico. Distribuirlas identificando servicios. Integrarlas. Organizar la explotación.

De las dos primeras etapas se cuida esta fase de Distribución de la Proceso de la Aplicación (Balancing Aplication Processing). De las dos últimas se cuida la etapa de diseño siguiente dedicada a montar la arquitectura distribuida integrando los servicios con los clientes.


El primer paso para crear la arquitectura distribuida es decidir, llanamente hablando, que hacen los servidores y que hacen los clientes. En este momento hay que recordar todos lo que le he ido presentando hasta aquí sobre este tema y que en este apartado nos limitaremos a relacionar. En particular cabe recordar en primer lugar la distribución de funcionalidad “fat server” o “fat client” que marca un criterio básico: la aplicación tendrá pocos o muchos servidores marcando así la dificultad del trabajo a realizar. Es muy interesante que recuerde los criterios para balancear entre fat server y fat client; son prerrequisito. Tenga en todo momento presente las fronteras que ha decidido establecer en el sistema distribuido. 6. 1. Identificar Funciones.

Se realiza dentro de funcional / especificación y/o el diseño tecnológico y son, por tanto, precondiciones en esta fase del diseño. En mi metodología se reflejará en diagramas de flujo secuencializados o herramientas que den información equivalente.

6. 2. Distribuirlas por Niveles Lógicos. Las funciones habrán de distribuirse por niveles lógicos. Esta distribución se hará en dos fases:

Una inicial por localizaciones obligadas. Por ejemplo: La existencia de un proceso especifico de un punto de la organización.

Servicios reutilizados. Servicios comprados

Una posterior a la identificación de servidores y dentro del “map to reality”. Prime siempre que pueda esta segunda opción que pueden usar prácticamente siempre en los sistemas distribuidos modernos y que no le pone ningún impedimento a la localización.

6. 3. Separar funciones entre clientes y servidores.

Los criterios para distribuir funciones se han ido trabajando a lo largo de los capítulos anteriores. Vamos a realizar aquí una relación clasificada de los más importantes. Recuerde además que:

La mayoría de los criterios de este apartado depende de cada aplicación y son difíciles de generalizar de forma abstracta.

Pocos de estos criterios son de blanco o negro: la mayoría son tonos grises que habrá que analizar contra las necesidades y condicionamientos de nuestra aplicación antes de tomar una decisión.

Si utiliza la técnica de encapsular en piezas, las decisiones tomadas, que pueden variar en el tiempo por haber cambiando los criterios que apoyaron un camino o, simplemente, por un error de valoración de esos criterios, podrán modificarse sin cambios importantes.


6.3.1. Por la localización de las clases y las instancias de los objetos. Este bloque solo tiene sentido en modelos avanzados analizados funcionalmente por Orientación a Objetos. Al tener los objetos atributos (datos) y métodos (procesos) los criterios a aplicar son tanto unos como otros. Le aconsejo que aquí se asegure de los que hacen referencia a los datos y que siga con los de los procesos como si la metodología de análisis funcional hubiera sido convencional.

6.3.2. Por la tipología de las tareas. Una vez separadas las tareas distinguir entre:

Tareas de clientes. Tareas de cliente background, normalmente agentes. Servicios en general y programas servidores y agentes en particular.

Las tareas no especializadas han de hacerse en el cliente y las especializadas son susceptibles de encapsulamiento y por tanto de ser implementadas en servicios. Escoger agentes o clientes background en procesos con comunicación asíncrona desacoplada y full tolerance. Las tareas intensivas en tiempo, es decir, largas, han de ser implementadas como criterio general, en los clientes, sean piezas o no. Si tienen filosofía de servicio, la alternativa son clientes back-ground o darles categoría de servicios y asignarlas a agentes. Son tareas intensivas en tiempo que se localizan siempre en cliente:

La gestión de dibujo gráfico. Ordenaciones. Las búsquedas en tablas grandes. Interpretación de reglas de negocio. Preparación y postratamiento de querys. Proceso de texto. Análisis estadístico. Etc.

Son tareas que, aunque intensivas en tiempo, pueden distribuirse por otros criterios:

Compresión y descompresión por software. Si el algoritmo es un siempre el mismo, la pieza se linka en el cliente. Si el algoritmo puede variar dinámicamente, prime los servidores. Encriptación y desencriptación por software. Vale lo mismo del punto anterior. Captura Multimedia. Sirve lo mismo de los dos apartados anteriores. Recuerde que si hay delegación de servicio, es una delegación potencial de arquitectura de filtro entre los servidores afectados.


Hay funciones propias del cliente y funciones para compartir entre clientes y servidores. Son funciones propias del cliente:

La lógica de presentación. Diálogo con los usuarios. Validaciones de las entradas. Ayudas en línea. Diálogo de la gestión de errores. Etc.

Son funciones a repartir entre clientes y servidores:

La lógica de proceso específica de la aplicación. La gestión y recuperación de errores, aunque en general, el cliente lleva la iniciativa de la gestión y el servidor de la recuperación. Recuerde que de informar al usuario siempre se ha de ocupar un cliente.

Las funciones para un único usuario, son siempre de cliente.

6.3.3. Por los datos. Ya tratados en el apartado anterior.

6.3.4. Por los recursos.

Gestionar todos los recursos compartidos por servidores. Habrá que decidir si el recurso ha de tratarse de forma exclusiva o no. En este caso, que ha de ser excepcional, hay utilizar un modelo de comunicación conversacional. Los recursos físicos de localización obligada han de tratarse siempre por servidores. Por ejemplo, una placa de encriptación por hardware, que al ser caras, son piezas singulares en los nodos del esquema de niveles lógico.

6.3.5. Por la oferta de los servicios.

Servicios que han de ofecerse el 100% del tiempo deben independizarse en servidores o agentes.

6.3.6. Por los condicionamientos de organización. Pueden ser muy variados y de difícil clasificación. Son buenos ejemplos:

La localización operativa. Por ejemplo, la gestión de riesgo de un cliente se suele llevar centralizada lo que obliga de definir un servidor de riesgo localizado en el nodo lógico del Dpto. que lo gestiona. Políticas de administración del sistema. Por ejemplo, la compañía no desea administración en un nodo lógico. Condicionantes de proveedores y clientes. Etc.


6.3.7. Por la administración del sistema. Como se cita en el apartado anterior, dentro de los criterios de organización hay parte de los criterios para la administración del sistema: aquellos que marca la política de administración de la compañía. Dentro de este bloque pueden incluirse:

Jerarquía de la administración establecida para la compañía. Propagación de los cambios (datos y programas) por el sistema distribuido. Diseño y control de la administración remota. Definición de la política y los parámetros de seguridad. Etc.

El tema se tratará específicamente y a fondo dentro de los capítulos dedicados a la administración del sistema. Sin embargo, en diseñadores expertos, aquí se suele adelantar mucho trabajo.

6.3.8. Usuarios remotos y nómadas. La presencia de usuarios remotos donde las velocidades de transmisión son lentas aporta otro bloque de criterios. Además, el tema de los nómadas aporta en muchas ocasiones la no disponibilidad de conexión en periodos normales de trabajo. Aunque de este tema ya hemos hablado, conviene relacionar aquí brevemente las soluciones y precondicionamientos aportados por esta situación:

Utilización de replicación de datos. Uso de comunicaciones asíncronas para utilizar los tiempos muertos en los programas cliente. Ello obliga a servidores en las dos bandas y modelos de comunicación por colas. Las conexiones síncronas y el particular el RPC quedan penalizadas. Esquemas de conexión, petición de servicio, obtención de la respuesta y desconexión para minimizar el coste de las comunicaciones. Este ciclo hace la conexión todavía más lenta potenciando todavía más la comunicación asíncrona. Utilización exhaustiva de procedimientos catalogados en la implementación de los servicios de la lógica de datos o de servidores de datos en la parte de la BD que reciban las peticiones y devuelvan respuestas de alto nivel. Conviene primar, sin embargo, los procedimientos catalogados ya que minimizan el tiempo de conexión bajando proporcionalmente el coste de las comunicaciones. Apoyarse todo lo posible en Internet, tanto como soporte de aplicaciones distribuidas como transportista C/S. Priman soluciones en comunicación asíncrona desacoplada

Hay una arquitectura de servidores prácticamente obligada cuando existe una conexión lenta y se quiere aprovechar el tiempo de la


llamada asíncrona para hacer proceso en el programa cliente, es decir, un modelo de trabajo asíncrono. Razonémosla. Si se realiza la llamada a través, por ejemplo de colas, el criterio es localizar la cola en el lado del servidor. Si se hace así la conexión del cliente con la cola será lenta (solución 1 en la figura). Si el cliente ha de repetir más de una vez la pregunta a la cola para saber si ya tiene el servicio disponible será más eficiente que el cliente hable con una cola local y que un servidor para Pasar la Petición se encargue del diálogo con la cola remota (solución 2 en la figura). La solución, recomendable en vías lentas, es obligada si la línea se ha de levantar para cada petición de servicio. El tiempo entre la finalización del servicio por el servidor y el momento de la recogida de la respuesta por el cliente se puede ahorrar de la factura de comunicaciones ya que el servidor de Pasar Petición habrá bajado la línea tras recibir la respuesta. Esta arquitectura permite también optimizar costes cuando hay multicliente (obviamente lo normal) ya que el servidor de paso solo bajará la línea cuando no tenga nada pendiente de ninguno de los clientes.

6. 4. Identificar servicios. Aplicando todos estos criterios a los diagramas de flujo o de secuencia, según corresponda:

Se identificarán los procesos que han de ser servicios a los que asignamos un nombre.

Se añadirá un proceso de transformación, o paso en el diagrama de secuencia, en el diagrama de flujo para implementar la llamada al servidor y se marcará en la secuencia del diagrama de flujo si la llamada es síncrona o asíncrona. Si es síncrona, el proceso añadido para implementar la llamada recibe también la respuesta. Si es asíncrona, e interesa aprovechar el tiempo de espera, un segundo proceso añadido diferente del de la llamada recibe la respuesta.

Deberá decidirse también aquí si implementamos servicios pasivos, servidores o agentes.

TomarRespuesta

Llamada

PasarPetición

Servidorde Trabajo

TomarRespuesta

Llamada

Servidorde Trabajo

R

RSolución 1Solución 1

Solución 2Solución 2

Figura 216. Arquitectura de una llamada asíncrona a

través de una vía lenta.


6. 5. Un pequeño ejemplo en MAFDRA. Más adelante aplicaremos todo este nuevo paso de la metodología al ejemplo de la agencia de viajes. Sin embargo, y para clarificar esta etapa vamos a aplicar todo esto a un pequeño ejemplo. El sistema de información de la figura corresponde a un proceso de venta en delegaciones en el cual los clientes se identifican previamente a la venta con un carné que se expende de forma centralizada e independientemente del SI de la figura. Este hecho tiene como importante consecuencia que el fichero de clientes estará centralizado y el SI que vamos a manejar no deberá contemplar proceso de alta de clientes. Cada tienda tiene un almacén para entregar el género al cliente. La naturaleza de los productos vendidos no produce roturas de stock. El almacén se repone cada semana con un proceso que queda fuera del SI que tratamos. Al cliente se le entrega un albarán de los productos retirados. Estos albaranes de recogen en la Delegación y se envían cada noche a la Central donde se realiza un proceso de facturación y cobro centralizado. El riesgo del cliente se mantiene, pues, centralizado. Aplicando análisis descendente al proceso de transformación que representa al SI se obtiene el primer refinamiento de la figura. Observe la aparición de las entidades intermedias, pedido en curso para almacenar los datos que se están registrando en el pedido actual y albaranes locales, para almacenar todos los albaranes emitidos y enviarlos cada noche a la central. Obviamente los proceso de registro de pedido y servir pedido están secuencializados ya que se ejecutan uno detrás de otro para cada pedido, pero

Cliente

VentaProductos

Productos

Cuentas Clientes

Clientes

Albaranes

Albarán

Figura 217. SI para la Venta de Productos en Delegaciones

Pedido en Curso

ServirPedido

Albaranes Local

RegistroPedido

Cliente

Clientes

Cuentas ClientesAlbarán

Productos

EnviarAlbaranes

a la Central

Albaranes Centra

Figura 218. Primer Refinamiento


no así el de enviar albaranes a la central ya que sólo se ejecuta una vez al final del día. Aplicando otro nivel de refinamiento a los dos primeros se obtienen los diagramas de flujo secuencializados de las figuras siguientes.

Una aproximación al modelo de datos nos permite decidir la arquitectura de los datos:

Los clientes solo existirán en la central ya que se identifican por tarjeta. Los productos estarán replicados en la central y en el local. Los albaranes se mantendrán en un modelo replicado con la copia master en la central y el foco de mantenimiento en el local.

Adelantando el análisis de consistencia, inevitable en el estudio del modelo de datos, necesitaremos tener una lista de las tarjetas anuladas para trabajar en emergencia. Esta copia la mantendremos en XML.

Si aplicamos ahora criterios para separar funciones cliente de funciones servidoras podremos llegar a identificar los siguientes servicios: 1. Las entidades cliente y cuenta de cliente son centralizadas por lo que el

acceso deberá hacerse por comunicaciones a la central para cada pedido. Como se unen datos de dos entidades, por lógica de datos se identifica un servidor para Leer Datos del Cliente en la Central.

2. Para utilizar las posibilidades de impresión de Word se utilizará como Servidor de Impresos.

3. Para enviar los albaranes a la Central se utilizará un Servidor de Correo. 4. Para recibir los albaranes en la central necesitaremos un servicio

desacoplado para la Recepción e Incorporación de los Albaranes a las bases de datos corporativas. Lo montaremos con un agente

Colocando estos servidores en los diagramas de flujo de obtendrán los siguientes diagramas evolucionados.

Pedido en Curso

VerificarCrédito

RegistroProductos

Pedido

Cliente

Clientes

Cuentas Clientes

Productos


LeerDatos

Cliente

Avisoal

Cliente

No hay Crédito

Figura 219. Refinamiento de Registro de Pedido

Pedido en Curso

ImprimirAlbarán

Albaranes

PrepararEntrega

Albarán

AcumularAlbaranes

Figura 220. Refinamiento de Servir Pedido


Observe en el primer refinamiento que la utilización del servidor de correo comporta que el proceso de Enviar Albaranes a la Central se ha convertido en una simple anotación a la cola del servidor de correo que es el que realizará el envío de forma autónoma con los parámetros con los cuales se haya parametrizado. El servicio para Incorporar a BD Corporativa será una envolvente de la aplicación del HOST.

El servidor de Leer Datos del Cliente localizado en la central agrupará los accesos a las tablas de clientes y cuentas de clientes con el diagrama de flujo de la figura. Observe ahora el

diagrama de flujo evolucionado del Registro del Pedido. Notará que las lecturas de cliente y cuenta de cliente han desaparecido integradas en el nuevo servidor de Leer Datos de Cliente localizado en la Central. Se han incluido dos nuevos procesos para hacer la petición y tomar la respuesta, proceso que como se observa en la figura se trabaja de forma asíncrona. Observe la necesidad de definir un nuevo servidor en el parte de la Delegación para poder realizar correctamente la llamada asíncrona salvando la heterogeneidad de la conexión lenta, tal como se ha comentado anteriormente.

Pedido en Curso

ServirPedido

Albaranes Local

RegistroPedido

Cliente

Clientes

Cuentas ClientesAlbarán

Productos

AnotarEnvío

Albaranes

Albaranes Central

Servidorde correo

RIncorporar

a BDcorporativa

Figura 221. Arquitectura Distribuida del primer refinamiento

Respuesta

TomarCrédito

Clientes Cuentas Clientes

LeerDatos

Cliente

Código Cliente en Petición

Figura 222. Refinamiento del Servidor para Leer los Datos del

Cliente


Pedido en Curso

TomarDatos

Cliente

RegistroProductos

Pedido

Cliente

Productos


PedirDatos

Cliente

Avisoal

Cliente

No hay Crédito

VerificarCredito

PasarPetición ala Central

LeerDatos

ClienteR

Figura 223. Arquitectura Distribuida de Registro del Pedido

Finalmente, observemos la arquitectura distribuida de Servir Pedido en la figura de la derecha. Observe que en estas figuras ya se han adelantado los modos de comunicación entre cliente y servidor que trataremos en el apartado siguiente. Lo he hecho así para minimizar mi trabajo, y porque creo que no debería suponer ningún problema, si he hecho bien mi exposición, hasta este momento.

7. Creación de la Arquitectura Distribuida. Una vez identificados los servidores, ya es posible la completar la construcción de la arquitectura distribuida. Habremos de analizar y concretar:

El modelo de comunicación entre cada servicio y sus clientes. Agrupa. Tipo de comunicación. Formato del mensaje

Las relaciones entre los servicios, reflejada en la tipología de la arquitectura de servicios.

Flujo de mensajes. La modalidad y el momento del arranque. La implementación de cada servicio.

Pedido en Curso

PedirImprimirAlbarán

Albaranes

PrepararEntrega

Albarán

AcumularAlbaranes

ImpresiónAlbarán

Figura 224. Arquitectura Distribuida de Servir

Pedido.


Para conseguirlo seguiremos los siguientes pasos: 7. 1. Definir el tipo de comunicación.

Para cada servicio identificado en la etapa anterior habrá que decidir el modelo de comunicación con sus clientes. Lo primero que habrá que mirar es si el servicio utiliza algún recurso de Middleware que obligue a un modelo de comunicación determinado. Por ejemplo la utilización de ODBC marca el modelo de comunicación síncrono ligado a este tipo de servicio de datos. A continuación habrá que preguntarse si el servicio necesita ser reservado de forma que el cliente sepa que lo tiene. Si es así el modelo de comunicación a escoger será el conversacional. Recuerde que hoy día esto es un caso excepcional. Si el servicio ha de quedar disponible para clientes que desconozcan la maquina donde se va ha localizar, por ejemplo, terceras compañías, una buena elección será RPC o Servicio WEB. A continuación, y para el resto, queda la elección clásica: ¿RPC o Colas?, ¿Síncrono o Asíncrono? Repase las ventajas e inconvenientes de unos y otros

desarrolladas en el capítulo dedicado a los modelos de comunicación. Aunque ya conoce mi forma de pensar: prime la comunicación asíncrona sobre la síncrona. Y siempre que pueda, implemente la comunicación asíncrona con colas con el conocido esquema multicliente y multiservidor.

Hay otra situación en que puede valorarse seriamente la utilización de RPC, o cualquier otra modalidad síncrona, en lugar de cola: cuando hay comunicaciones lentas y el cliente ha de esperarse siempre a la respuesta, es decir, la comunicación es por aplicación síncrona. Pero por favor, ¡no elija nunca síncrono solo porque es fácil de programar! En todos los casos, habrá que definir el formato del mensaje de cabecera para el mecanismo de petición / respuesta de servicio. Y finalmente habrá que tomar decisiones en comunicaciones remotas sobre sí:

Encriptar o no la comunicación. Empaquetar o no el mensaje. Time-out si la comunicación es síncrona y el Middleware no proporciona ese mecanismo.

Checkpoints de calidad de la transmisión en mensajes largos, etc.

7. 2. Definir la arquitectura entre los servicios.

Figura 225. Servidores multicliente

y multiservidor


Esta etapa se habrá empezado en la etapa de identificación de servicios y deberá completarse aquí. Repase las posibles arquitecturas entre servidores si no las recuerda. Se han de crear arquitecturas que favorezcan la escalabilidad, pero sin llegar a extremos que penalicen el tiempo de respuesta. Recordemos los criterios básicos.

Recuerde que la arquitectura por defecto entre dos servidores es la delegación de servicio. Si el contenido del mensaje es muy grande, valore la utilización de una arquitectura de filtro.

Recuerde también que la arquitectura de comunicación con un agente es desacoplada y de traspaso de responsabilidad.

Si necesita servidores muy escalables en potencia de servicio, proponga una arquitectura master/slave. Si utiliza esta arquitectura recuerde de decidir que sistema utiliza para implementar el paralelismo de los slaves. Si puede utilice las herramientas y las técnicas del multihilo.

Si tiene una conexión entre dos puntos heterogéneos por una vía lenta por la que han de viajar peticiones de servicio diferentes para varios servidores, valore una arquitectura de distribución.

Si tiene una función única que ha de ser atendida por servidores diferentes en entornos heterogéneos, encapsule la llamada con una arquitectura de pasarela para utilizar una sola llamada lógica desde los clientes y encapsular la heterogeneidad de la prestación de servicio.

Y busque cuidadosamente las relaciones precondición que puedan haber surgido en su arquitectura de servidores. No hacerlo, puede ser muy peligroso y conducir a grandes problemas en tiempo de explotación.

7. 3. Documentar la Arquitectura Distribuida.

Finalmente habrá que documentar y especificar todo en la metodología utilizada. Recuerde, dentro de lo posible, implementar con la idea de que un servidor es una pieza encapsulada, no necesariamente un programa, con un modelo de comunicación. Y este es un buen momento para concretar la ficha de enviroment del servidor o agente. Recuerde, parametrice todo lo que razonablemente se le ocurra.

7. 4. Analizar la solución obtenida. La importancia de las decisiones que ha tomado es tal que le recomiendo en este punto de su diseño que haga una pausa, revise la arquitectura obtenida y reflexione y valore sobre la bondad, eficacia, eficiencia y viabilidad de la solución adoptada. Obviamente, si se decide algún cambio, se habrá de volver al punto de la metodología afectado.

7. 5. Creación de la Arquitectura Distribuida del ejemplo de venta de productos.

Como ejemplo corto de aplicación de esta parte de la metodología comentemos la arquitectura distribuida del anterior ejemplo de venta de productos en Delegaciones.


7.5.1. Elección del Modelo de comunicación.

Repasando servidor por servidor vamos a elegir el modelo de comunicación.

Servidor de Correo. La comunicación por colas es obligada ya que es un producto de Middleware. Servidor de BD. Todos los accesos a las BD son síncronas ODBC de forma obligada ya que utilizamos este estándar para independizar los accesos del motor. Servidor para pasar la petición de clientes a la Central. La comunicación es asíncrona por colas por decisión de diseño. Servidor de Leer Datos de Cliente. Como ha de trabajar junto con el anterior elegimos, también colas. Servidor de Impresos de albaranes. Al utilizar Word para implementar este servidor, la comunicación será asíncrona desacoplada por OLE. Al elegir este modelo, el programa cliente que integre esta parte de la aplicación deberá pedir conformación de que el albarán ha salida correctamente o dar posibilidad de repetir la impresión del albarán a voluntad del operador. Prime esta segunda opción ya que lo normal es que salga siempre bien (sino, ¡mal vamos!) y evitará acciones no necesarias de operación.

7.5.2. Arquitectura de servidores.

Entre el Servidor para Pasar la Petición y el Servidor para Leer Datos del Cliente se establece una arquitectura de delegación de servicio.

Al final documentaríamos la solución elegida añadiéndola a los diagramas de flujo o de secuencia según corresponda, acción, que como ya he dicho en el apartado anterior ya había adelantado para ahorrarme trabajo. Obviamente, y por tratarse de un ejemplo corto didáctico, no realizo el “map to reality” que se explica a continuación, aunque si propongo una localización:

Servidor de Correo. Una parte en el servidor de la delegación y otra en la Central.

Servidor de BD. Donde se localicen los motores. Habrá un en la Delegación y otro en la Central.

Servidor para pasar la petición de clientes a la Central. En el servidor departamental.

Servidor de Leer Datos de Cliente. En la Central Servidor de Impresión de albaranes. En cada máquina cliente.

8. Map to Reality. Ya hemos comentado anteriormente el por qué es tan interesante adaptar la solución lógica a la plataforma en este punto de la metodología: se adelanta un trabajo que habrá que acabar realizando para ganar fiabilidad de rendimiento y operatividad. La adaptación se realiza en tres pasos:


8. 1. Localización. De los servicios sobre la plataforma física. La decisión se habrá de concensuar con el Administrador de Sistema. Ya se han visto muchos criterios de localización. En los capítulos dedicados al diseño de la administración del sistema se verá el resto (en realidad, pocos más de los que ya conoce).

8. 2. Configuración. De los servicios, estática o dinámica. Se decidirá, entre otros factores:

La parametrización de los motores de bases de datos (búferes, tamaño de las zonas de trabajo y loging, etc.), de importancia fundamental para el rendimiento.

La configuración de los productos de Middleware. El plan de arranque de los servidores y su configuración a través de la ficha de enviroment.

8. 3. Analizar rendimiento.

Este apartado es básicamente igual que el correspondiente de los datos. Es caso de duda se ha de asegurar, por prueba, la interoperatividad y el rendimiento. La valoración de la interoperatividad es más importante en los procesos que en los datos. Uno de los factores a asegurar aquí de forma específica en el rendimiento de las colas. Este factor está en función del tiempo medio de respuesta de una anotación por el número de usuarios. Por ejemplo, si hay 40 peticiones por segundo y el tiempo de respuesta es de 300 milisegundos, tendremos un tiempo de respuesta de 300*40=12.000 milisegundos, 12 segundos. La pregunta será: ¿es válido un tiempo de respuesta de 12 segundos? Si la respuesta es negativa y el servidor no se ha pensado multihilo, puede forzarse ese cambio. Si ya es multihilo, habrá de dimensionarse el servidor donde se localice para permitir arrancar más instancias simultáneas. Recuerde que el tiempo de respuesta de una cola es el tiempo de gestión de sus anotaciones, pero principalmente, el tiempo de servicio de los servidores que la utilizan. Conviene medir con dos parámetros:

Número máximo de usuarios simultáneo. Número medio de accesos simultáneos.

Se valorará con el segundo, pero se asegurará que el primero es aceptable como excepción puntual. En cualquier caso, recuerde que la prueba ha de ser medida y que como resultado de la prueba, quizás se deberá volver atrás para cambiar alguna decisión o añadir algún proceso. O cambiar algún recurso de la plataforma. Y


que ambas decisiones, que son muchas veces alternativas, han de valorarse económicamente.

9. Diseño de la Arquitectura distribuida del ejemplo de la venta de viajes aéreos y hotel.

Apliquemos todo el contenido al ejemplo que desarrollamos para presentar MAFDRA. Repase el análisis funcional y, ¡adelante! Le avanzó que necesitará definir el concepto de cliente habitual. Le recomiendo que desarrolle el ejemplo sin mirar la solución y la consulte después. 9. 1. Análisis de datos.

En la especificación se han recogido dos puntos que serán de interés ahora:

Habitualmente los clientes trabajan con una sola oficina, aunque el sistema debe permitir venderles en cualquier tienda.

Hay clientes solventes a los cuales no hay que verificar el crédito. Estos dos factores permiten tomar decisiones en el equilibrio costes versus administración. En cada tienda estarán en local los clientes que habitualmente trabajan con esa tienda. El mantenimiento se realizará en la tienda, pero la copia master será el fichero consolidado de la Central. Para facilitar esta gestión es necesario cuantificar la relación cliente habitual de una tienda. La estableceremos como el cliente que ha realizado al menos una operación en la tienda en los últimos tres años. Observe que esta decisión supone que puede haber clientes replicados en más de una tienda, lo que justifica que la copia de referencia sea la de la Central y no nos decidamos por un modelo particionado. Observe también que pasados tres años desde una compra ocasional desde una tienda no habitual, el cliente desaparecerá del fichero de esa tienda. Para implementar esta nueva relación cliente habitual de se utilizará una nueva tabla de formato:

Relación Tienda-Cliente Atributo Tipo Formato Observaciones Tienda String 4 DNI String 14 Fecha de la última operación

Fecha 8

Lo que obliga a considerar una tabla de tiendas que hasta ahora, aunque obvia, no había sido necesaria.

Tiendas Atributo Tipo Formato Observaciones Tienda String 4


Nombre String 50 Etc.

Este cambio, trasladado al modelo de datos, lleva al esquema de datos modificado de la figura de la izquierda. A la tabla de clientes se añadirá un nuevo atributo para controlar que clientes son solventes y no necesitan verificación

del crédito antes de venderles:

Clientes Atributo Tipo Formato Observaciones DNI String 14 Nombre String 50 Dirección String 4x40 La dirección no tiene estructura

prefijada Grupo Contable String 6 Clave foránea. Ver Diccionario de

Conceptos Cuenta Contable String 10 Clave Foránea. ¿Necesita control de riesgo?

String 1 S: lo necesita, N: no lo necesita. En la práctica se añadiría al diccionario de conceptos.

Etc.

9.1.1. Arquitectura distribuida de los datos. Apliquemos ahora los criterios para llegar a la arquitectura de datos distribuida. Aplicando el criterio de localización obligada:

El modelo de datos modificado se implementará totalmente en la Central. Los clientes serán el total de clientes de la Compañía. Será la copia master, aunque su mantenimiento se hará desde las tiendas. En cada tienda se implementarán sólo las tablas de clientes de esa tienda, la de compañías aéreas y de los hoteles para tener en las tiendas el teléfono de llamada para reservas. El fichero de

ClientesCentral

CuentaAnalítica

Vuelos

ViajesComprados

por

Vuelos por

Cliente

1

M

1

N

Corresponde a

AnotacionesCuenta

Analítica

1

MEs movimiento de

CompañíaServido por

M 1

Clientehabitual

deTiendas

RelaciónTienda-Cliente

N M

PlazasHotel

Hoteles

Habitación deM

1

Figura 226. Esquema de datos modificado


compañías se mantendrá directamente en la tienda dentro de los procesos de mantenimiento de los ficheros maestros.

Es decir, escogemos para la entidad cliente un modelo de replicación con el master en la central pero con el mantenimiento localizado en el punto de venta. El resto del modelo es centralizado. Los esquemas de datos distribuidos se presentan en las figuras siguientes.

ClientesCentral

CuentaAnalítica

Vuelos

ViajesComprados

por

Vuelos por

Cliente

1

M

1

N

Corresponde a

AnotacionesCuenta

Analítica

1

MEs movimiento de

CompañíaServido por

M 1

Clientehabitual

deTiendas

RelaciónTienda-Cliente

N M

PlazasHotel

Hoteles

Habitación deM

1

Figura 227. Arquitectura de datos de la Central

ClientesTienda

Compañía

Hoteles

Figura 228. Arquitectura de datos de la

Tienda.

9.1.2. Mantenimiento y auditoria. Clientes se mantiene en el puesto de venta y la replica master es la de la central. El mantenimiento de las replicas será síncrono. Los volúmenes de clientes en una tienda en el ámbito de un negocio de este estilo no pueden ser grandes por lo que parece clara la decisión de establecer una política de replica mensual por extracción copia selectiva, que no necesitará, por tanto, auditoria. Si el cliente se localiza en la central no se da de alta en local hasta el proceso de replica mensual.

El fichero de compañías aéreas es centralizado en la Agencia y en la Central. Se mantienen individual e independientemente y no prevemos proceso de auditoria. El fichero de hoteles se mantendrá en la central y se replicará a las tiendas. El código del cliente será su DNI por lo que no necesita criterios de codificación distribuida.


Los pedidos se numeran dentro de cada DNI por tienda, fecha y un número secuencial por si un cliente compra más de una vez el mismo día. No necesita, pues, criterios de codificación distribuida adicionales.

9.1.3. Adaptación del diseño. Observemos que esta implementación de la arquitectura distribuida de datos obliga a pensar en nuevas situaciones ligadas a la lógica de datos:

Modificar el proceso de lectura y acceso a clientes. Modificar el proceso de alta de cliente. Mantener la fecha de la última operación realizada por un cliente en una tienda. Un proceso para replicar clientes y hoteles.

Así, el proceso para tomar los datos de clientes debe ser modificado para adaptarse a la arquitectura de datos distribuida elegida resultando un nuevo proceso a desglosar de la forma en que muestra en el diagrama de flujo de la figura. El otro proceso afectado por la arquitectura de datos distribuida de las tablas que afectan a clientes es el de alta de clientes. En la parte superior de la figura se muestra la nueva especificación con las dos tablas de clientes separadas y la nueva de clientes por tienda. En la parte inferior de la figura se muestra es nuevo diagrama de flujo del proceso de alta.

Accedera clientesCentral

Accedera cliente

local

TomarDatos

Cliente

Clientes local

El clienteno

existeix

Clients central

No existe Cliente

No existe cliente en local

El cliente existe en local

No existe cliente en Central

El cliente existe en la Central

Datos Cliente

Figura 229. Proceso para Leer los datos del Cliente.


AltaCliente

ClienteClientes Local

Cuenta ClienteCrédito Estándar

Clientes Central

Cliente por Tienda

PedirDatos

Cliente

Cliente

Clientes Local

Crédito Estándar


LocalAsignarCrédito

Cuentas ClienteClientes Central

Incorporara ClientesCentral


por Tienda

Clientes por tienda

Figura 230. Proceso de Alta de Cliente Modificado

Estos cambios afectan al diseño de Entrada de la Petición que queda redefinido como se muestra en la figura.

En el proceso de actualización de datos en la central hay que añadir un proceso nuevo para actualizar la operatividad del cliente en cada tienda. El proceso modificado se muestra en la figura.

Cliente

Petición Cliente

RegistroDatos

ClientePeticiónCliente

AccesoDatos

Cliente

RegistroDatosViaje

ConsultaCuentaCliente

Cuenta Clientes

RechazarVenta

AltaCliente

Clientes CentralRe-intentar

Crédito Estándar

No créditoClientes Local

Clientes por Tienda

No existe Cliente

Sin hotel

Figura 1. Entrada de la Petición modificada.


Petición Cliente

Actualizareservac.aérea


Cuenta Clientes


Vuelos por Cliente

Anotacióndel vuelo por

Cliente

Avisoal

Cliente

AnularVenta

Re-intentar

Cliente

No hay plazas

Hay plazas

Clientes por Tienda

AnotaciónFecha

Operación

Actualizadatoshotel

Datos Hotel

Figura 231. Proceso de Actualización de Datos modificado.

Aparece un nuevo proceso de Replicación de los Clientes de la Tienda desde la Central. El proceso de Replicación de Hoteles seguirá la misma operativa El proceso implementará la política de replicación que se quiera establecer. Analicemos cual puede ser esa política. Los datos de referencia de clientes son los de la Central, pero el mantenimiento se realiza desde la tienda. Este hecho hace que, en principio, los datos de las replicas en la tienda hayan de estar siempre al día. Escogemos, como ya se ha dicho, un modelo de propagación de la replica síncrona pero un proceso de replicación por copia mensual para evitar la auditoria. Este proceso de replica por extracción, lanzado desde la central, seleccionará desde el fichero de clientes de la central, y con los datos de clientes por tiendas, los clientes de cada tienda sobre un fichero secuencial. Este fichero se enviará de forma automática a cada tienda donde sustituirá a la replica de clientes local. Un diagrama de flujo secuencializado del proceso se muestra en la figura anterior.

SelecciónClientesdel Local

Clientes Central

Clientes Local

Clientes por Tienda

Enviara la

Tienda

Replica Clientes Local

Tiendas Calendario de Fiestas

Figura 232. Nuevo Proceso de Replicación de Clientes


La replicación mensual se hará de forma automática y desatendida la noche entre los dos primeros días laborables consecutivos del mes. Para ello se habrá de llevar en la Central un calendario de los días festivos de cada tienda.

9. 2. Diseño de la Arquitectura Distribuida.

9.2.1. Diseño de la lógica de datos distribuida e identificación de servicios. Las comunicaciones están resueltas por el Middleware por lo que los servicios diseñados utilizarán directamente los servicios de comunicaciones de la plataforma. Para analizar los servicios de datos se partirá de la base de las localizaciones obligadas y de encapsular los accesos de la lógica de datos. Todos los accesos de datos directos utilizarán SQL. Se relacionan a continuación los servicios de datos identificados, desde donde han aparecido en el funcional, su función y el tipo de implementación, por servidores o por procedimiento catalogado.


9.2.1.A. Leer Datos Cliente. Función: Acceder de forma encapsulada a los datos de cliente

desde la tienda, desligando al cliente de la existencia de dos ficheros de cliente.

Origen: Estudio del diagrama de flujo de Entrada de la Petición.

9.2.1.B. Leer Datos Cliente en la Central. Función: Acceder de forma encapsulada a los datos de cliente

localizados en la Central desde los servidores de cada tienda. El servidor se ha de utilizar para obtener los datos descriptivos del cliente y los de crédito. Como el cliente se tomará habitualmente del fichero de clientes del local, en la mayoría de los casos el acceso a la Central solo será para saber el estado del crédito en aquellos clientes que necesiten verificación de crédito. Por esa razón, es conveniente que se prevea la opción de pedir sólo los datos de crédito en el mensaje de petición de servicio.

Origen: Estudio del diagrama de flujo del servidor Leer Datos Cliente.

9.2.1.C. Alta Cliente en la Central.

Función: Realizar el alta de todas las entidades de cliente en los

ficheros de la Central desde los servidores de cada tienda. Origen: Estudio del diagrama de flujo de Alta de Clientes.

9.2.1.D. Actualizar Datos de Venta de Clientes en la Central. Función: Acumular los resultados de la venta en los ficheros de

clientes de la Central desde los servidores de datos de cada tienda.

Origen: Estudio del diagrama de flujo de Actualizar Datos de Venta.

9.2.1.E. Actualización de Datos de la Compañía aérea.

Función: Pedir la reserva de las plazas vendidas a ala compañía

aérea. Origen: Estudio del diagrama de flujo de Actualizar Datos de

Venta.


9.2.1.F. Consulta de Hoteles. Función: Consulta de las disponibilidades de habitaciones en los

diferentes hoteles. Origen: Estudio del diagrama de flujo de Registro Datos Viaje

9.2.1.G. Actualización de Datos de la Hotel. Función: Confirma reserva de habitaciones. Origen: Estudio del diagrama de flujo de Registro Datos Viaje

Los datos de hotel se gestionarán a través de Servicios WEB. Todo el resto de la lógica de datos se implementa en servidores convencionales y no es necesaria la creación de ningún procedimiento catalogado. Se identifican, además dos servidores de proceso:

9.2.1.H. Impresión de la Reserva para el cliente. Función: Impresión del documento de reserva de las plazas de avión

de la venta realizada al cliente. Se utilizará como servidor de impresos Word para aprovechar las ventajas de creación de formularios (multidioma incluido) de un procesador de textos.

Origen: Estudio del diagrama de flujo de Entrada de la Petición.

9.2.1.I. Servidor de Correo. Función: Traspaso de ficheros. Origen: Estudio del diagrama de flujo de Replicación de Clientes.

9.2.2. Elección del modelo de comunicación.

9.2.2.A. Leer Datos Cliente.

Modelo: Cola. Acceso a los datos del local por SQL. Uso: Asíncrono para utilizar el tiempo de acceso a la Central

para registrar los vuelos solicitados. Parámetros Mensaje: De entrada: código cliente y tipo de petición

(completa o solo de crédito). De salida: indicativo de existencia y atributos

del cliente y de crédito.

9.2.2.B. Leer Datos Cliente en la Central. Modelo: Cola remota. Acceso a los datos de la central por SQL Uso: Síncrono. Parámetros Mensaje: De entrada: código cliente De salida: indicativo de existencia y atributos

del cliente y de crédito.

9.2.2.C. Alta Cliente en la Central. Modelo: Cola remota. Acceso a los datos de la central por SQL Uso: Síncrono.


Parámetros Mensaje: De entrada: atributos de cliente. De salida: indicativo de alta correcta.

9.2.2.D. Actualizar Datos de Venta de Clientes en la Central. Modelo: Cola remota. Acceso a los datos de la central por SQL Uso: Síncrono. Parámetros Mensaje: De entrada: datos de la venta De salida: indicativo de servicio completo.

9.2.2.E. Actualización de Datos de la Compañía aérea. Modelo: RPC. Uso: Síncrono. Parámetros Mensaje: De entrada: Compañía, vuelo y plazas a

reservar. De salida: indicativo de sí existen las plazas

pedidas. En caso de fracaso, no se reserva ninguna y se devuelven el número de plazas libres en ese momento.

9.2.2.F. Consulta de Hoteles.

Modelo: Servicio WEB. Uso: Síncrono. Parámetros Mensaje: De entrada: Ciudad, Categoría del hotel, día De salida: indicativo de sí existen

habitaciones pedidas. En caso afirmativo, Lista de hoteles posibles con enlace a su página WEB.

. 9.2.2.G. Actualización de Datos del Hotel.

Modelo: Servicio WEB. Uso: Síncrono. Parámetros Mensaje: De entrada: Hotel, día, datos cliente De salida: indicativo de confirmación.

9.2.2.H. Impresión de la Reserva para el cliente.

Modelo: Active X. Uso: Asíncrono desacoplado. Parámetros Mensaje: De entrada: datos de la reserva e idioma De salida: indicativo de servicio recibido.

9.2.2.I. Servidor de Correo.

Modelo: Colas. Uso: Asíncrono desacoplado. Parámetros Mensaje: De entrada: fichero a trasladar y tienda destino De salida: indicativo de servicio recibido.

Todas las colas se implementarán como servidores autónomos, localizadas en el lado del servidor.


9.2.3. Creación de la Arquitectura Distribuida. Creemos ahora la arquitectura distribuida incluyendo todas las decisiones tomadas en los diagramas de flujo secuencializados. Utilizando el procesador de textos Word como servidor de impresos el proceso de Impresión de la Reserva se convierte en una llamada Word. Como la comunicación es asíncrona desacoplada es necesario preguntar si la impresión ha sido correcta o no. Este proceso deberá incluirse como llamada independiente en el diagrama jerárquico de la aplicación para permitir copias adicionales. Dar la posibilidad de reimpresión de la Reserva de Cliente supone dar a la Petición de Cliente persistencia y, por tanto, la necesidad de crear un nuevo proceso de Eliminación de Peticiones que se añadirá al jerárquico definitivo para que el usuario lo ejecute de tanto en tanto. Existe una precondición entre los servidores de Leer Datos de Cliente en la Central y el de Actualizar Datos de Venta en la Central por el atributo de crédito consumido. El efecto, si hay una actualización del crédito de un cliente por una venta, puede ser que antes de registrarse en el servidor de actualización se pida consulta a través del de lectura y que se dé un valor equivocado. La precondición entre ambos servidores se establecerá de forma que cuando se realice una consulta del cliente se mire si hay una actualización de venta de ese cliente pendiente y, si es así, no dando la respuesta hasta haber completado la actualización. La precondición se establecerá compartiendo ambos servidores la cola de comunicación con sus clientes, tal como se muestra en la figura. Esta cola la denominaremos en el contesto del ejemplo Cola de Clientes. La precondición la deberá revisar el servidor de lectura. Hay que hacer una aclaración importante. En el contesto de este ejemplo la

Petición Cliente

ImpresiónReserva

ReservaCliente

Servidor deImpresosWORD

PreguntaImpresiónCorrecta

Repetir

Formularios

EliminaciónHistóricaPeticiones

Fecha

Figura 233. Proceso de impresión de la reserva del cliente

LeerClientes enla Central

Pre-C

ActualizarVenta

Clientes en la Central

ColaClientes

Figura 234. Precondición en la gestión del Crédito de

Cliente


precondición es muy forzada ya que la probabilidad de que un cliente que acaba de hacer una compra concrete otra antes de que haya tiempo de actualizar su crédito es muy remota. Unido al hecho de que, el problema sería realmente grave si se hiciera desde otra tienda donde no hay ningún conocimiento de la venta no registrada, hace que la probabilidad de ocurrencia sea prácticamente nula. De cualquier forma mantendremos la precondición a efectos docentes. El servidor para Actualizar Datos de Cliente en la Central implementará esas funciones del proceso de actualizar datos y su diseño se muestra en la figura. Observe que la única función de Actualizar Datos de Venta no implementada es la de petición de la reserva del vuelo a la compañía aérea que dispone de un servidor propio. Implementemos ahora el servidor de Leer Datos de Cliente en la Central. En el diagrama de flujo de la figura se muestra su diseño interno.

Datos cliente

CogerCrédito

CogerDatos

Cliente

Clientes Central

Prepararrespuesta

CogerPetición

ActualizarClientes enla Central

Cuenta Cliente

Parámetros

ColaClientes

Pre-CSolo Crédito

Actualización Pendiente

Figura 236. Refinamiento del Servidor de Leer Datos de Cliente

en la Central En este diagrama de flujo hay un proceso, Coger Crédito, que puede ser desglosado mediante análisis descendente en el siguiente diagrama de flujo:

Referencia Cliente

Cuenta Cliente


Vuelos por Cliente

Anotacióndel vuelo

por Cliente

Anotaciónfecha

Operación

Clientes por Tienda

Colocarrespuesta

CogerPetición

ColaClientes

Figura 235. Servidor de Actualizar Datos de Cliente en la Central


El diagrama implementa una acción muy habitual en este tipo de precondiciones: el cambio de prioridad de los movimientos de actualización pendientes de las referencias que se quieren consultar. El proceso devuelve al anterior una salida condicionada si no ha podido tratar la petición actual para que trate el siguiente movimiento. Obviamente, la implementación ha de controlar que se trate realmente la petición siguiente para evitar el bucle. Estamos en condiciones de resolver la arquitectura del servidor de Leer Datos de Cliente localizado en la Tienda. Existen dos soluciones. La primera, que denominaremos solución A, se muestra en la figura. La arquitectura se ha construido con la identificación de servidores que se ha realizado anteriormente. Existe, sin embargo, otra solución que denominaremos B, un poco más compleja pero más limpia de diseño que se muestra en la figura siguiente. Observe la aparición de dos servidores nuevos:

Datos Clientes

LeerCrédito

Cuenta Cliente

CogerPeticionesdel Cliente

Verificar sihay cambiosPendientes

CambiarPrioridad

Actualización Pendiente

Cliente (Parámetro)

Cambios Saldo Pendientes

ColaClientes

Hay Actualizaciones Pendientes

Sin Actualizaciones Pendientes

Figura 237. Refinamiento del servidor de lectura del crédito.

Clientes local

LeerDatos

Cliente

Clientes central

R

Leer DatosClientes enla Central

Cuentas Clientes

ColaClientes


Pre-C

Figura 238. Solución A para la arquitectura del

servidor de Leer Datos del Cliente en el servidor de la Tienda.


Acceder a Clientes en la Central, que permite mediante una arquitectura de distribución llamar a las dos funciones de obtener datos descriptivos de cliente y obtener el crédito. Leer Crédito del Cliente, que lee de forma especializada sólo el crédito.

Y de una modificación, ya que el servidor de Leer Datos de Cliente en la Central sólo tomará los datos descriptivos. Dejo al lector como ejercicio el diseño interno de estos dos nuevos servidores y del modificado. ¿Cuál es mejor? Por temas de rendimiento son equivalentes, la diferencia de coste de programación es mínima y la solución B es más limpia que la A. ¿Adivina mi voto? Pues aunque lo haga, por favor, ¡elija el suyo! Con todo ello, la arquitectura del servidor para Leer Datos de Cliente en la Tienda queda tal como muestra la figura. Observe que el proceso para leer los datos de cliente de la Central se ha convertido en una llamada al servidor remoto de la central.

Clientes local

LeerDatos

Cliente

Clientes central

Leer Crédito

del Cliente

Cuentas Clientes

Acceso aClientes enla Central

Leer datosClientes enla Central

R R

ColaClientes

R


Pre-C

Figura 239. Solución A para la arquitectura del

servidor de Leer Datos del Cliente en el servidor de la Tienda.


Desarrollemos ahora la arquitectura de los procesos para el alta de clientes. El diseño del servidor para el Alta del Cliente en la Central se muestra en la figura. Finalmente, el proceso de Entrada de la Petición del cliente queda como se muestra en la siguiente figura. Observe, comparándolo con el inicial, que el proceso queda cambiado y simplificado.

PedirclienteCentral

Accedera cliente

local

TomarDatos

Cliente

Clientes local

Colocaren

respuesta



No existe cliente en Central

El cliente existe en la Central

Respuesta

Clientes central

Leer DatosCliente enla Central

ColaClientes

Petición: Código Cliente

Cuentas Clientes

R TomarDatos

Cliente

TomarCrédito

R

Hay que tomar Crédito

Figura 240. Refinamiento del servidor de lectura de datos de clientes en la Tienda

Clientes Central Cuentas Cliente

Incorporara ClientesCentral

Parámetro: Datos Cliente

AsignarCrédito

Crédito estándar


por Tienda

Clientes por Tienda

Figura 241. Arquitectura del servidor de Alta de Clientes

en la Central.


Cliente

Petición Cliente

RegistroDatosViajePetición

ClienteAccesoDatos

Cliente

RegistroDatos

ClienteVerificarCréditoCliente

RechazarVenta

AltaCliente

Re-intentar

No crédito

Leer DatosCliente

No existe el Cliente

Sin hotel

Figura 242. Arquitectura del proceso de Entrada de la Petición.

Para facilitar la claridad de la figura no se han incluido las entradas y salidas del proceso de Alta de Cliente y del servidor para Leer los Datos del Cliente en la Tienda. Desarrollando la arquitectura del proceso de Registro de Datos del Viaje obtenemos:

Navegador

Vendedor

Petición Cliente

RegistrarDatosVuelo Registro

DatosHotelDatos Compañía Aérea

ConsultarDatos deVuelos

ConsultarDatos

Hoteles

Datos Hotel

Sin hotel

No hay habitaciones

Cliente

ConsultarDatos

HotelesAcabar

Necesita Hotel

No Necesita Hotel

R

Figura 243. Arquitectura del proceso de Registro Datos Viaje

Observemos que la consulta de los datos de vuelo se ha asumido por el Navegador.


La arquitectura final del proceso para Actualizar Datos de la Venta se muestra en la figura de la derecha. El proceso se ha convertido en una secuencia de dos llamadas, una al servidor de la compañía aérea y otro al servidor de la central que actualiza la venta en los ficheros de cliente. La actualización de datos de cliente en la central puede montarse con filosofía de agente para liberar antes el programa de actualización. Incluyendo el servidor de Correo dentro del proceso de replicación de clientes, la arquitectura resultante es la de la figura. La comunicación con el servidor de correo es asíncrona desacoplada por los que la flecha de secuencia solo hace referencia a que el sistema se parametriza dé forma que cuando el fichero de clientes replicado se recibe en la tienda se lanza de forma automática el proceso de generación de la replica sobre la BD de la tienda. El proceso de Estadísticas de Venta se pasa en la Central y por esa razón los únicos servicios que utilizarán será ODBC - SQL, para acceder a los datos, y los servicios de impresión de la red. No se incluye, por su poca significación en diagrama. En la figura se muestra el diagrama de flujo de la arquitectura resultante.

Petición cliente

ActualizaReservaC.Aérea

Anotaren la

Central

No hay plazas

ActualizarDatos

Clientes enla Central

R


RPC

ActualizarDatos

CompañíaAéreaR

ColaClientes

Actualizadatoshotel

Datos HotelR

Figura 244. Arquitectura del proceso de Actualización de Datos de

la Venta

SelecciónClientesdel Local

Clientes Central

Clientes Local

Clientes por Tienda

GenerarReplicaReplica Clientes

Tiendas Calendario de Fiestas

Colocaren

Cola

Servidorde correo

R

Replica Clientes

Figura 245. Arquitectura del proceso de Replicación de Clientes


9.2.4. Map to Reality.

Obviamente, en un libro este apartado ha de ser meramente teorizante y fuera de todo contesto de evaluación de rendimiento. Se incluye únicamente a efectos descriptivos. Suponemos que todas las tiendas tienen suficiente volumen para disponer de un servidor propio (precondición de organización). La configuración de la plataforma es:

Servidor de datos de la central: ORACLE bajo Linux. Servidor de datos de la tienda: SQL-Server. Red de la tienda: Windows sobre TCP/IP. Servidor de red de la tienda: Windows. Puesto de trabajo de la tienda: Windows. Ofimática: Microsoft Office, el particular Word como servidor de impresos. Word se instalará en cada puesto de trabajo para conseguir autonomía y seguridad en el servidor de impresión de las reservas. Servidor de Correo. GEYCE-Link (producto de Middleware comprado). Middleware de fabricación propia: Sistema de colas. Middleware estándar: Servicio WEB, RPC, TCP/IP y recursos de administración de red.

Los servidores se arrancarán estáticamente en el momento del arranque de las máquinas respectivas. La localización de los servidores será:

Servidor de la Central. Correo. Cola de Clientes. Alta de Clientes. Leer Datos de Clientes en la Central. Actualizar Datos de Venta.

Servidor de la Tienda. Correo. Leer Datos Cliente.

Puesto de trabajo. Word.

Los servidores de las Compañías aéreas son transparentes a nuestro sistema de información.

9. 3. El diseño de los Servicios WEB.


Podemos suponer que la Compañía de nuestro ejemplo quiere ofrecer estos servicios de consulta y reserva de hoteles para otros clientes mediante una cuota económica y que es por eso por lo que se ha decidido por la técnica de Servicio WEB para la implementación. Prescindiendo de la implementación de los servicios, recuerde que este es un libro de diseño, observe que la arquitectura de los servicios será la de la figura. El Servicio WEB no será más que una arquitectura de pasarela hacia los sistemas de información de los hoteles publicados.

9. 4. Diagrama jerárquico modificado. Como resultado de esta parte del diseño se llega al diagrama jerárquico modificado de la figura.

Servidor para

actualizar

Clientes

Servidor de

Consultas

R D Web Service

Otros ServiciosInternos

R

RP

P

P

Figura 246. Arquitectura del proceso de Actualización de Datos

de la Venta




Obtención Estadísticas

Mantenimiento de ficheros básicos Alta de Clientes Venta Viaje Aéreo

Registro de la petición

Actualizaciones

Compañía Aérea

Hotel

Cuenta cliente

Venta por cliente

Venta por vueloDatos Vuelo

Datos Hotel

Vuelos por cliente

Impresión Reserva Eliminación Peticiones

Figura 247. Diagrama Jerárquico tras el diseño de la Arquitectura distribuida.


Políticas de Administración de un Sistema Distribuido.

1. Introducción. Para poder desarrollar los análisis de consistencia y de administración del sistema es necesario desarrollar previamente las políticas posibles en la administración del sistema distribuido. Y estas políticas están basadas en las actividades a cubrir. Este conocimiento nos permitirá establecer plataformas y procesos de administración. Y la plataforma se utilizará como componente de la gestión de análisis de consistencia. No partimos de cero. En la primera parte hemos dedicado un capitulo a introducir la administración del sistema distribuido. No vamos a repetirlo aquí. Repáselo, como siempre, si no lo recuerda. En especial revise los apartados dedicados a explicar que hay de diferente entre los sistemas centralizados y los distribuidos, los elementos a administrar y los procesos básicos. Recuerde, eso sí, que la administración es uno de los puntos débiles y que, por tanto, debe ser cuidado especialmente. Aquí hablaremos de políticas. Más adelante estableceremos los criterios del análisis de la administración del sistema que ha de aportar lo necesario al DSM del Middleware para desarrollar la política elegida. Recordemos también que el Plan Estratégico de Gestión del Sistema Distribuido actúa también como fuente de precondiciones al diseño de la administración del sistema distribuido.

2. La administración de sistemas distribuidos. Administrar sistemas distribuidos supone gestionar centenares de recursos y componentes dentro de entornos muy heterogéneos y con dispersión geográfica. El factor humano es también un punto a considerar ya que los administradores y los administrados muchas veces ni se conocen y cualquiera que tenga mínimos conocimientos de las relaciones humanas (¡ese sí que es un tema complejo!) sabe que el contacto personal facilita muchísimo esas relaciones. En entornos distribuidos, actividades que en los sistemas centralizados son resueltas por simples utilidades se convierten en problemas muy complejos. En muchas ocasiones el coste es tan alto que la solución que dejaría satisfechos a administradores y administrados solo es viable económicamente en grandes instalaciones. Pero en cualquier caso, el error más grave que puede cometer es no planificarlo. Seguro que más tarde o más pronto le estallará en la cara. Por favor, antes de seguir repase los procesos básicos a administrar detallados en el capítulo correspondiente de la primera parte.


3. Áreas de actividades en la administración de un sistema distribuido. Es muy difícil catalogar y estructurar todas las actividades de administración presentes en un sistema distribuido por la dispersión de elementos involucrados, el menosprecio de la importancia de las personas y la muy diversa importancia que en cada sistema distribuido tienen. A mi juicio para analizar estas actividades debe partirse de la clasificación y del flujo que se muestran en la figura.

Recolección Información

Análisis de la gestión

Planificación de estrategias

Consola de gestión y control

Almacén del conocimiento

Asistencia a los usuarios

Nuevos elementos y cambios

Análisis de rendimientos

Inventario de activos

Datos

Áreas de administraciónPlanificación

Análisis

Gestión y control

Inventario y Monitoring

Soporte a usuarios

Datos

Automatizar tareas intensivas

Area de Costes

Repercusión de costes

Auditoria Interna y Externa

Instalación, configuración i parametrización

Figura 248. Clasificación de las actividades de administración

Las actividades de primer nivel que se muestran en la figura se agrupan en áreas genéricas:

Área de planificación, destinada a definir los criterios de gestión del sistema distribuido. Incluye:

La inclusión de nuevos elementos y cambios. Como parte del diseño distribuido habrá que decidir como se interaccionan los nuevos elementos o cambios realizados con la plataforma de administración del sistema distribuido.

La planificación de las estrategias de acuerdo con las políticas de negocio de la empresa o empresas afectadas.

Área de gestión y control, desde donde se gestiona el día a día. Área de administración de los datos. Engloba todas las actividades de administración de los datos de las que hemos hablado ampliamente a lo largo de nuestro viaje.

Área de análisis, donde se analiza los resultados obtenidos y se proponen las mejoras. Incluye, básicamente dos aspectos:

Análisis de rendimientos, para ayudar a la gestión del día a día. Análisis de la gestión, que analizar la gestión en relación a los costes, la calidad del servicio y el seguimiento con la línea de negocio de la


compañía. Sirve de realimentación en la planificación de las estrategias con la propuesta de las mejoras.

Auditoria Interna y Externa, para ayudar a los procesos de auditoria legal (Seguimiento de la ley de protección de datos, procesos de blanqueo de dinero, etc... ) y técnica..

Área de Costes. Donde hay que identificar y automatizar trabajos y tareas intensivas en tiempo.

Área de soporte a usuarios. Área de Inventario y Monitoring, cuyas actividades están dedicadas a recoger las medidas del sistema y almacenarlas como soporte a la decisión. Incluye tres actividades básicas:

Recolección de la información. Inventario de activos. Archivo de conocimiento adquirido.

Excepto en el caso del área de análisis que se trata dentro de cada una de las otras áreas, a continuación trataremos más a fondo cada una de estas actividades básicas. Y antes de hacerlo vamos a introducir algunos conceptos que nos serán de interés.

4. Organización de la administración. Antes de entrar a fondo en la descripción de las actividades concretas de cada área conviene pensar sobre que elementos de organización se configuran esas actividades: 4. 1. El Centro de Dirección del Sistema Distribuido (CDSD).

La función básica del CDSD es responsabilizarse de las actividades del área de planificación para definir los criterios de gestión del entorno distribuido, negociándolos con:

La dirección. Los usuarios. Los responsables de aplicación Los administradores de sistema.

Lo representaremos por el símbolo de la figura. Ha de ser único en el ámbito de la compañía, pero puede apoyarse a la hora de establecer los criterios técnicos en empresas externas especializadas.

4. 2. El Centro de Administración del Sistema Distribuido (CASD). La función básica del CASD es gestionar la administración del sistema, el día a día, a partir de la las directrices del CDSD. Lo representaremos por el símbolo

de la figura. Hay un CASD central que puede delegar en CASD locales. Los CASD’s pueden estar subcontratados a empresas

especializadas.

CDSD

CASD


Son funciones genéricas del CASD:

Llevar a la práctica, apoyar y supervisar las estrategias de administración establecidas por el CDSD.

Gestionar la configuración en general y la plataforma estándar en particular.

Gestionar y controlar el sistema distribuido. Mantener el repositorio de administración. Dar soporte y controlar los centros de soporte.

4. 3. El Centro de Soporte a usuarios del Sistema Distribuido (CSSD).

La función básica del CSSD es dar soporte y asistencia a los usuarios del sistema distribuido. Lo representaremos por el símbolo de la figura.

Los CSSD pueden estar integrados dentro de los CASD o actuar como unidades organizativas autónomas. Los CSSD’s pueden estar subcontratados a empresas

especializadas. Son funciones del CSSD:

Dar el soporte a los usuarios a través de la Hot-Line. Reuniones planificadas o puntuales con los usuarios. Recolectar la información de la actividad de Monitoring para determinar el nivel de satisfacción de los usuarios.

Estos centros se organizan según un organigrama operativo que se presenta en el apartado posterior dedicado al soporte a los usuarios.

5. Estrategias de administración. Las estrategias para organizar las tareas de cada área pueden ser muy diversas. Veamos un ejemplo en la estrategia propuesta por ITIL para los servicios de administración. Recordemos que La Biblioteca de Infraestructura de Tecnologías de Información, abreviada ITIL (del inglés Information Technology Infrastructure Library), es un marco de trabajo de las buenas prácticas destinadas a facilitar la entrega de servicios de tecnologías de la información (TI). ITIL resume un extenso conjunto de procedimientos de gestión ideados para ayudar a las organizaciones a lograr calidad y eficiencia en las operaciones de TI. Estos procedimientos son independientes del proveedor y han sido desarrollados para servir como guía que abarque toda infraestructura, desarrollo y operaciones de TI. Pues bien, ITIL propone una estrategia basada en tres bloques de actuaciones:

• Gestión de incidencias. Los técnicos dedicados a este bloque de actividades sólo se preocupará de la recuperación del servicio e informará en el repositorio de incidencias de su actividad.

CSSD


• Gestión de problemas. Los técnicos asignados a este bloque analizaran las incidencias, buscaran las causas y propondrán las soluciones.

• Gestión de cambios. Finalmente, los técnicos de este bloque de actividades implementaran las soluciones a los problemas.

En cualquier caso, la estrategia en cada entorno es fruto de un análisis profundo de las necesidades y los hábitos.

6. La plataforma estándar. El concepto de plataforma estándar es simple pero potente: definir una forma única de instalar y configurar la plataforma básica del cliente. La utilización de la plataforma estándar permite administrar el sistema distribuido mejor y más fácilmente. 6. 1. Definición de la plataforma estándar.

La definición de la plataforma estándar tiene dos factores:

Relación de Componentes: sistemas operativos, redes, hardware, servidores locales,...

Configuración de esos componentes. Dentro de la plataforma estándar debe incluir la conectividad y la ofimática, factor este último de gran dispersión. Por desgracia, es habitual que un documento de ofimática se cambie de cliente y presente problemas de formato por la diferencia entres plantillas con el mismo nombre (y teóricamente estándares). Normalmente hay más de una implementación del estándar en el entorno distribuido en función de las configuraciones presentes en los diferentes nodos. Está diversificación, hasta cierto punto normal, debe tenerse controladamente y trabajar con el mínimo de modelos posibles de la plataforma estándar. El contenido de la plataforma estándar detalla la relación y configuración de:

Prestaciones mínimas de hardware (CPU, memoria, disco, multimedia, etc.)

Particiones de disco: directorios mapeados compartidos. Estructura de directorios, diferenciando los del sistema, programas, usuario, temporales y por defecto.

Configuración de red. Estándar de enviroment de sistema, teclado, impresora y Mouse. Contenido de los ficheros de configuración del startup. Configuración de los canales serie. Valores mínimos de los parámetros de configuración ligados a rendimiento: búferes, caché, áreas de trabajo de las BD, etc.

Usuarios por defecto y sus derechos. Carpetas y contenido de esas carpetas. Configuración y estándares del entorno de ofimática. Configuración por defecto de las diferentes aplicaciones distribuidas.

6. 2. Administración de la plataforma estándar.


La plataforma estándar es definida por el CDSD y gestionada por el CASD central. Se guarda dentro del repositorio de administración. Dentro del repositorio de administración debe de existir la información de que plataforma estándar corresponde a cada nodo. Se define un procedimiento estándar de instalación y configuración, elemento fundamental en una buena gestión de la plataforma estándar ya que su ejecución garantiza la regeneración en caso de degradación o avería. Desde el CASD central se ha de hacer llegar a cada nodo la configuración estándar que corresponde a su plataforma, el procedimiento automático de instalación y configuración, las instrucciones para arrancarlo y resolver las incidencias más habituales que pueden salir al hacerlo. El soporte último siempre es el CSSD a través de la Hot-Line. Conviene que los procesos para la instalación y para la configuración estén separados y puedan arrancarse independientemente. Si se actúa así, el resultado es más operativo. Por ejemplo, si hay problemas y se duda del estado actual de la configuración es recomendable reconfigurar ejecutando sólo el procedimiento de configuración. En caso de avería o caída destructiva del sistema de habrá de reinstalar desde el principio. En este caso, el usuario ha de ser consciente que la configuración propia sobre la estándar no catalogada en procedimientos se perderá capa vez que se reinstale.

6. 3. Organización de la administración del cliente sobre la plataforma estándar.

La plataforma estándar de instalación y parametrización del puesto cliente se instala sobre la plataforma de sistema del puesto cliente. Sobre ella se construyen dos plataformas más:

La plataforma de las aplicaciones distribuidas, creada junto a los jefes de diseño de cada aplicación, y sobre la que se organiza la explotación de esas aplicaciones. Se integra dentro de la plataforma estándar y es, por tanto, definida por el CDSD (junto a los jefes de diseño) y administrada por el CASD Central.

La plataforma de usuario, en la que se incluyen las aplicaciones y ficheros específicos de cada usuario.

6. 4. Delimitación de responsabilidades.

La delimitación y reparto de responsabilidades entre los CASD y los usuarios se establece en el contrato de administración y servicio de un cliente.

Este contrato no es más que un pacto de los compromisos y obligaciones que cada parte, usuario y administrador, adquieren. Es de vital importancia, no

Plataforma Estándar

Sistema Cliente

Plataforma Aplicaciones Distribuidas

Plataforma de Usuario

Figura 249. Niveles de configuración del

puesto cliente


para buscar culpables a posteriori, sino permitir a cada parte prepararse para el trozo de contrato que asume y saber como hay que actuar en todas las actividades de la administración del sistema, desde la instalación y parametrización al soporte directo a los usuarios. El contrato debe contener una cláusula, básica, que contemple la existencia de la plataforma estándar, que hay que explicar y justificar a los usuarios ya que puede parecerles una intromisión en “la intimidad de su ordenador”. El usuario debe entender la importancia, para sus propios intereses, de que la plataforma estándar sea reinstalable en cualquier momento. Y que este derecho del CASD destruirá su plataforma de usuario, lo que le obliga a tenerla documentada y a disponer de un sistema de recuperación automática de forma análoga a la de la plataforma estándar. Cualquier cosa que haya instalado o modificado en cualquier parte de las plataformas estándar o de aplicación o sobre la de usuario se perderá si el CASD se ve obligado a reconstruirlas. Como contrapartida, el CASD debe dar todo tipo de ayuda y soporte que el Plan Estratégico Distribuido de la Compañía le permita para que el usuario pueda instalar correctamente su plataforma estándar y para que disponga en todo momento de procesos de reconstrucción automática para pasarlos después de reinstalar la plataforma estándar. Pero en cualquier caso debe quedar claro que la responsabilidad de la plataforma de usuario es del usuario, que ha de ser plenamente consciente que el CASD se reserva el derecho de cambiar y reinstalar la plataforma estándar cuando sea necesario. Otra cláusula fundamental en el contrato es la delimitación de la responsabilidad de las copias de seguridad. Es usuario deberá entender claramente que tenerlas siempre al día es fundamental ya que después de la reconstrucción de las plataformas siempre habrá que instalar los datos de usuario en el puesto cliente. A está mentalización del usuario para hacer siempre sus copias no ayuda nada la gran fiabilidad de los equipos actuales y los horarios tan largos que todos hacemos que nos llevan a acabar tan tarde que pensamos que las copias pueden esperar a mañana. Un consejo, recomiende a sus usuarios que se habitúen a hacer copias, como mínimo, por la mañana. El contrato administración y servicio no está casi nunca oficializado y en, muchas ocasiones no está ni escrito. Sin embargo, mi opinión personal es que debería estar siempre redactado, consensuado y presentado y aprobado por Dirección.

7. Área de planificación. Las actividades específicas incluidas en esta área son:

Coordinación de las políticas de administración del sistema distribuido con los objetivos de dirección para alinearse con la evolución y el desarrollo del negocio. Las políticas de negocio y el nivel de servicio necesario actúan de precondiciones.


Definir el nivel de servicio y de asistencia, en particular delimitar horarios y condiciones de servicio.

Definir las estrategias técnicas de inclusión de los nuevos elementos o de los cambios que se realizan.

Intentar conseguir el mejor resultado con el mínimo coste. Este objetivo es una política continúa optimización de procesos para el aumento de la calidad y la reducción de costes. Se parte de:

La información de proporcionada por el análisis de la gestión. La propuesta de los centros de administración tras el análisis de rendimientos.

La evolución de la tecnología. Establecer las políticas de distribución de costes, si la política de negocio lo requiere. Como criterio general, siempre el bueno que los consumidores sean conscientes del coste del servicio que reciben.

Las funciones del área de planificación se concretan en:

Definir las políticas de administración. Definir las estrategias de administración. Definir las operativas estándares. Definir la plataforma estándar. Definir las plataformas de las aplicaciones distribuidas junto a los responsables de aplicación.

Pactar y aprobar el contrato de servicio. Establecer el último nivel de resolución de incidencias en el sentido de avisar a expertos en el tema objeto del problema.

8. Área de administración de datos. Los datos son uno de los activos más valiosos de la compañía ya que incluyen la información y por tanto el conocimiento que tiene de su negocio en todas sus áreas: administración, productos, mercado, clientes, proveedores, producción y un amplio etc. El abaratamiento de las unidades de almacenamiento y el aumento espectacular de sus capacidades ha hecho que el la mayoría de las empresas los datos almacenados hayan aumentado de forma espectacular pero en la mayoría de los caos anárquicamente y sin ningún tipo de catalogación ni administración solo siguiendo la conocida teoría de que los datos tienden a ocupar todo el espacio disponible. En este mundo actual donde crecimiento de los datos es explosivo en entornos cada vez más complejos y cambiantes donde conviven inevitablemente los datos centralizados y distribuidos. Las interrupciones son costosas y las perdidas impensables. Dicho de otra forma la administración, y la planificación de esa administración son pieza fundamental. Y como ya hemos dicho repetidamente, si el modelo de datos es distribuido esta actividad es fundamental, y nada simple. En un sistema distribuido abundan las fuentes de datos con esquemas y soportes heterogéneos. Causa de esa heterogeneidad son bases datos especializadas y de usuario pero con importancia corporativa en la parte de esquemas lógicos y, aunque estamos en un mundo donde SQL es el rey, los proveedores presentan matizaciones importantes en cuanto a esa implementación, los procedimientos catalogados no son estándares y hay mucha información de intercambio,


configuración e incluso de soporte en XML. Cada uno es una isla que hay que integrar. Es una versión nueva y actual de nuestro tradicional Upsizing. Para administrar esos datos se necesitan políticas y herramientas que los soporten dentro de soluciones EDM (Enterprise Data Management) que desde el centro de control del sistema distribuido han de controlar y gestionar bases de datos heterogéneas y de diferentes fabricantes, datos no incluidos en esas bases de datos como ficheros XML y en una arquitectura distribuida. Deben primarse al máximo los automatismos y las políticas preventivas ya que el objetivo es dar el mejor servicio con el mínimo de interrupciones. Hay que reducir al mínimo el mantenimiento en frío y gestionar en caliente todo lo que se pueda. Es posible establecer automatismos en actividades del tipo:

Gestión de versiones. Comparación de esquemas. Nivelación de esos esquemas.

Marcha atrás. Sincronización de datos. Recuperar datos. Integridad física. Replicación y todos sus factores. Reorganización de índices etc.

Es necesaria una postura proactiva sobre la tradicional de reacción ante problemas. La administración de los recursos de almacenamiento de datos tiene todas las actividades que hemos visto hasta ahora y a medida que íbamos hablando de datos y que pueden clasificarse en: 8. 1. Definir las políticas de administración.

La política de administración de datos es marcar pautas y seguimiento en cada actividad. Se acabará plasmando en una política de gestión integrada.

8. 2. Gestión de la localización, planificación de la capacidad y planificación de migraciones.

Donde y porque se sitúan los datos y que capacidad se le asigna.

8. 3. Gestión de uso. Para determinar y eliminar entidades y zonas que no se han usado nunca. Este análisis lleva resultados que seguro le sorprenderán sobre la cantidad de información en esta situación.

8. 4. Gestión del rendimiento. Solo se hace, por tema de costes, en grandes instalaciones. Se trata de analizar los rendimientos de acceso y actuar en consecuencia. Es una actividad de análisis de la gestión.


El estudio del rendimiento es importante para evitar la congestión de:

La base de datos. El gestor que la soporta. La maquina servidora. La aplicación, la causa más frecuente del problema.

Hay que potenciar el uso de recursos de autodiagnóstico y autocorreción, por ejemplo aumentar la capacidad de la BD automáticamente, resolver inconsistencias de forma desatendida, etc. Del análisis pueden implicarse acciones de reorganización física del tipo:

Colocar las entidades y archivos según grado de utilización. Por ejemplo: los más usados con los menos.

Striping de datos acción que consisten en repartir el dispositivo lógico entre varios dispositivos físicos para que más de un cabezal actué sobre la misma entidad o que la entidad pueda tener un volumen muy grande.

Gestión jerárquica de los almacenamientos colocando lo más usado en los dispositivos más rápidos.

Y actividades de mejora de las aplicaciones del tipo:

Cambios en el diseño o los programas. Nuevos índices. Uso de procedimientos catalogados.

8. 5. Gestión de la disponibilidad de los datos.

Cuando están disponibles y como se gestionan las alternancias de fuentes en caliente para mantener los datos siempre accesibles.

8. 6. Gestión de la coherencia, seguridad y el back-up y recuperación. En el capítulo siguiente hablaremos ampliamente de este tipo

8. 7. Monitoring de datos.

Recogida de la información necesaria para el análisis de la gestión de datos.

8. 8. Gestión de eventos y alertas de datos.

Se incluirán normalmente dentro del cuadro de control de administración,

9. Actividades del área de soporte a usuarios. Los sistemas distribuidos necesitan dar soporte a sus usuarios como cualquier otro sistema informático, pero, por su naturaleza, tienen una problemática diferente debido a:

La dispersión geográfica y, a veces, horaria. El número de usuarios. La heterogeneidad de sus perfiles y formación.


La variedad de sus aplicaciones. La presencia de más de una plataforma de sistema. Este factor aparece cada vez menos gracias a nuestro apreciado Sr. Gates y la omnipresencia de Windows.

Definir la estructura operativa del soporte supone decidir:

De qué se da soporte. Dónde se da ese soporte. Quien lo da. Cuándo se da. Cómo es el pacto de servicio establecido.

Estos términos se definen en el contrato de servicio y la gestión de la plataforma estándar que trataré más adelante. 9. 1. Organización operativa del soporte.

Para cumplir sus funciones el CASD, los CASD’s y los CSSD se organizan según un organigrama operativo cuyo modelo general se muestra en la figura. Cada organización especializará este organigrama según sus necesidades. Los CASD’s se organizan jerárquicamente. El CDSD se constituye en staff del CASD central. Cada CASD local da soporte a la plataforma de su zona de influencia. Si la organización tiene CSSD diferenciado del CASD, suele ser general para toda la organización. Los usuarios contactan con él y allí se hace el diagnostico, contactando con los CASD o los proveedores externos involucrados. El funcionamiento de trabajo se explica más adelante. Observe la parición de una figura, a mi juicio, fundamental: el usuario avanzado. Un usuario avanzado es un usuario formado tanto en la plataforma de su entorno como en la aplicación o aplicaciones que se utilizan en ese entorno. Suele ser una persona no informática salida de los entornos de aplicación de la compañía. Es una persona motivada, con formación informática originalmente empírica pero con mucha experiencia y que probablemente se ha reforzado con cursos especializados. Da el primer nivel de soporte de su entorno resolviendo gran cantidad de incidencias de nivel primario (las más según las estadísticas de servicio) descargando de mucho trabajo a los CSSD.

Central

CASD

CDSD

Local

CASDCSSDLocal

CASD

Vendedores

Especialistasde producto

EspecialistasInformáticos

UsuarioAvanzado

Figura 250. Organización operativa del soporte a usuarios.


La utilización de un usuario avanzado como primer nivel de soporte tiene, además, dos ventajas importantes:

Habla el mismo lenguaje que los usuarios a los que da soporte. Conoce a los usuarios personalmente, eliminando así, el problema de que el soporte y el usuario no se conozcan.

9. 2. Formas del soporte a usuarios.

La actividad de soporte a usuarios se da dos formas:

9.2.1. Hot-Line. Este servicio, llamado también Call Center o Help Desk, se basa en que el usuario llama a un número telefónico cuando tiene un problema. Si hay un técnico disponible, atiende inmediatamente la llamada. En caso contrario, se anota para contestarla en cuanto haya un técnico disponible. La localización de la Hot-Line es el CSSD o en su defecto el CASD local cuando está distribuida o el CASD central si se está centralizada. Puede estar subcontratada a una empresa externa. El usuario puede llamar a un servicio de recogida de llamadas o directamente al técnico, pero las características del servicio no cambian por ese hecho. El usuario explica su problema y el técnico realiza el diagnóstico. En función de ese diagnostico pueden ocurrir varias situaciones. En primer lugar, el técnico puede resolver el problema por si solo con lo cual la llamada queda cerrada. El número de llamadas que el diagnóstico puede cerrar depende de la formación del técnico que atiende la llamada. Aquí se produce el conocido problema de que técnicos buenos y formados no pueden atender el diagnóstico ya que deben ser promocionados por bien de la compañía y de su propia satisfacción profesional. Cuando el técnico no puede resolver la incidencia, debe pasar el problema a los especialistas quedando la avería pendiente de resolución. Si el diagnóstico es avería de hardware, se notificará a los responsables de resolverla, generalmente el proveedor. El personal de la Hot-Line deberá controlar que la avería se resuelve en los plazos acordados. Hoy día, la estandarización de los elementos de hardware, ha permitido que empresas especializadas concentren el mantenimiento de varios elementos aunque no sean los proveedores originales del material facilitando mucho la gestión de este tipo de incidencias. Cuando el diagnóstico es de problema de sistemas, lo normal es que la persona que lo ha hecho sea capaz de resolverlo ya que el perfil habitual de ese personal es del área de sistemas. Para este tipo de incidencias es fundamental hoy día las inmensas posibilidades que la administración remota proporciona. En caso de que la persona que realiza el diagnóstico no sea capaz de resolver la incidencia, lo normal


es que consulte al CASD y cuando éste no sea capaz de resolverlo, se avise a los especialistas y proveedores externos. Si el problema es de aplicación puede tener un triple origen:

El primer lugar está la parametrización de la aplicación. En este caso, conviene que el personal de diagnostico disponga de una buena documentación y de un mínimo de formación sobre este tema para poder resolver un máximo de incidencias.

Una segunda situación aparece cuando el problema es de operativa de uso. En este caso, lo normal que se traspase la resolución al especialista de la aplicación.

Y, finalmente, si el problema es un fallo de programa la llamada es traspasada al equipo de desarrollo.

En todos los casos conviene que el equipo de Hot-Line controle que las incidencias se resuelvan en un tiempo razonable. La adaptación del servicio a las necesidades reales de la organización es un trabajo continuo, además de sufrido y poco gratificante. Para poder mejorarlo, el CASD central y el CDSD deben disponer de estadísticas de utilización que solo pueden salir de una aplicación de soporte que, además de ayudar a gestionar el servicio en los términos que hemos hablado hasta ahora, debe dar la información de uso. La aplicación de soporte debe aportar sus datos a la aplicación de Monitoring. De esta información, y dentro de la actividad de análisis de la gestión, el estudio del número de incidencias por usuario debe ayudar a detectar lugares en que hay que hacer actuaciones de formación o intervenciones, nunca agradables, de llamada al orden a usuarios no motivados o histéricos. El estudio del número de incidencias por tramos horarios ayudará a adaptar los recursos del servicio a las necesidades reales. La tipología de las incidencias ayudará a mejorar los programas reforzando la aplicación en aquellos aspectos que presentan más incidencias. El estudio de los tiempos medios de resolución permitirá conocer si los compromisos pactados de tiempo de diagnostico y resolución se están cumpliendo. Aunque la justificación básica del servicio de Hot-Line es ayudar al usuario ante problemas, es evidente que también puede utilizarse para consultas de operativa, posibilidades del entorno y formación puntual. Déjeme darle un consejo final en este tema. El perfil del personal de Hot-line que da el primer nivel de soporte no debería ser mayoritariamente informático, sino administrativo, con ilusiones informáticas, eso sí. Con ello conseguirá dos importantes objetivos:

Qué el personal de hot-line no se le queme ya que un informático arde rápidamente en este puesto: ha estudiado informática para algo más que resolver problemas y aguantar usuarios desagradecidos y desagradables (aunque muchas veces tengan motivos para serlo).


Que se trabaje con documentación y que los programas de administración funcionen. Obviamente, como el personal administrativo no tendrá formación informática avanzada, no podrá seguir atajos que después no documente.

9.2.2. Reuniones.

Aunque el soporte a usuarios se basa habitualmente en un servicio de Hot-Line, no debe olvidarse nunca que las reuniones con los usuarios son fundamentales para definir estrategias, mejorar operativas, mejorar la formación de los usuarios y asesorarles en temas como ofimática, agendas electrónicas, correo electrónico, etc. Las reuniones, además, permiten que usuarios y técnicos se conozcan personalmente, circunstancia, a mi juicio y como ya he dicho, muy importante.

9. 3. Facilidades para el soporte a usuarios.

9.3.1. Ayudas en línea. Puede ser de varios tipos:

9.3.1.A. Generales. E incluidas en la instalación de los productos de sistema. Por ejemplo, las posibilidades de Windows y los productos de Office.

9.3.1.B. De operación estándar. Válidas para toda la instalación.

9.3.1.C. De uso de las aplicaciones. Son desarrolladas e incorporadas en el momento de la instalación. Le recomiendo que para desarrollarlas utilice herramientas estándar. Si desea desarrollar software especial piénseselo dos veces; hágalo sólo cuando sea claramente justificable y cree siempre componentes reutilizables.

Particularmente no creo nada en este tipo de ayudas. Y la recusación no viene de la calidad técnica sino del uso. Las que nos vienen hechas no nos cuestan nada, pero a nivel del usuario son ininteligibles y es dificilísimo encontrar rápidamente lo que buscas. Las que creamos nosotros, cuestan un montón de esfuerzos y dinero, y como son internas, el usuario coge antes el teléfono para pedir soporte a la Hot-Line que se pone a navegar con la ayuda.

9.3.2. Definición de procedimientos de actuación. Métodos, consejos, operativas para detectar, diagnosticar y resolver incidencias y problemas. Esta información va enriqueciéndose continuamente con la experiencia del día a día. Definir procedimientos supone:


Reconocimiento de problemas e incidencias. Seguimiento y análisis de esas incidencias. Aislamiento de los problemas. identificación y tipificación. Resolución guiada de los problemas tipificados. Criterios para decidir cuando se pide ayuda al escalón superior de asistencia.

Y no olvide que es fundamental realimentar las facilidades de soporte con los resultados de la experiencia de cada día.

9.3.3. Estandarización de la operativa de los programas. Ya he insistido varias veces a los largo del camino en la importancia que tiene en el soporte a usuarios la estandarización de operativas, diálogos, mensajes de error, recuperaciones, etc. para vacunarnos contra incidencias. Pienso firmemente que este punto es básico.

9. 4. Nivel de aceptación del servicio. Si aspira a obtener un 100% de usuarios contentos, olvídese. En un entorno tan disperso seguro que hay usuarios descontentos. Los descontentos son de tres tipos.

Los que achacan al servicio de soporte sus propias carencias. Si tiene usuarios así, tiene un problema ya que como los usuarios del soporte son clientes la tendencia a “el cliente siempre tiene razón” es muy alta. Además, como su servicio seguro que tiene problemas (puntas, tiempos de resolución, incidencias perdidas, y un amplio etc.) siempre habrá algo a lo que esos usuarios podrán agarrarse para atacarle. Solo conozco una defensa: demostrar que su estadísticas de problemas son repetitivas y por encima de la media. Necesitará, sin embargo, un sistema de Monitoring fiable si desea usar esta información.

Los que se quejan constructivamente. Los notará porque sus quejas aparecen en más de uno de ellos y su tono suele ser constructivo, si no están muy quedados, claro está.

Y finalmente, los que realmente tienen razón porque, de una forma u otra, han sufrido carencias en el servicio, en tiempo de respuesta o en calidad de servicio.

Para conocer la opinión se estos usuarios organice de forma sistemática una actividad de Monitoring encaminada a conocer el grado de satisfacción. La forma de hacerlo es a través de una Encuesta de Calidad de Servicio periódica y lo más codificada posible. Para conseguir una aceptación razonable de la calidad del servicio es básico:

La rapidez en el diagnostico. El seguimiento de las resoluciones en los tiempos pactados Potenciar la resolución automática de incidencias.


Organice el seguimiento como una actividad más del análisis de la gestión. Se trata, en el fondo, de determinar el grado de cumplimiento, por ambas partes, del contrato de servicio pactado.

10. Área de Inventario y Monitoring. La actividad de cualquier sistema informático debe ser medida aplicando métricas. A partir de esas medidas hay que analizar los resultados y conseguir gestionar y planificar mejor la administración. En los sistemas distribuidos esta actividad es especialmente importante ya que, como hemos hablado en otros capítulos, la dispersión de elementos hace muy complejo saber en que puntos hay que actuar para mejorar el funcionamiento. Inventario de activos, rendimiento, capacidades, parametrización, instalación y uso han de ser medidos y modelados en función de la evolución del sistema. Obviamente, todos estos datos han de salir del sistema de Monitoring. Las actividades básicas de esta área son:

Monitoring o recolección de información. Medir. Recoger las mediciones (recolectar en el argot). Transformarla. Integrar la información centralizándola en el archivo único. Catalogación por temas. Archivar en el repositorio de administración.

Inventario de activos. Gestión del repositorio.

A partir de aquí se podrán disparar las actividades de análisis de la actividad que permitirá detectar los puntos débiles y proponer las mejoras necesarias en la actividad técnica y en la económica (no olvide que su empresa o su cliente han de ganar dinero para pagarle).

11. Actividades de Monitoring.

Las actividades de Monitoring han de ser automáticas. Cada elemento de la plataforma, los clientes, los servidores, los agentes y el transportista habrían de disponer de recursos para monitorizar su actividad. Aquí, y una vez más, surge la pregunta: ¿sale a cuenta la inversión en un sistema de Monitoring para mejorar el rendimiento del sistema? Lo que me puedo ahorrar, ¿retornará la inversión en la implementación del sistema de Monitoring? La respuesta, como siempre: no hay varitas mágicas, depende del sistema y de la organización y hay que estudiar cada caso. Pero en este tema, yo soy determinista: medir siempre es bueno. La experiencia de cada día me ha enseñado que tarde o temprano, la aplicación de métricas a un sistema distribuido siempre acaba mejorarlo notablemente el sistema en su conjunto.

11. 1. El modelo de Monitoring.


El modelo o arquitectura del Monitoring se ha de montar sobre la estructura operativa del soporte del CASD. Es, por tanto, de arquitectura básicamente jerárquica. La actividad se monitoriza y se mide “in situ”. El primer paso es transformarla a un formato común. Normalmente se generan archivos secuenciales, si es posible en formatos XML o tablas en bases de datos locales. La información medida se concentra en los centros de administración locales y de allí se traspasa al Central. El objetivo básico del modelo es hacer llegar la información que necesitan a los centros de administración y dirección. La plataforma de transporte de la información recogida suele ser el servidor de correo a quien se le entrega una copia secuencial de los ficheros (locales o remotos) donde se reúne la información recogida. Allí se cataloga y se archiva en una base de datos o archivo de conocimiento sobre los que se realiza el análisis.

11. 2. La actividad de medir. El componente o lugar de trabajo va generando una información secuencial que se graba en un fichero o en una tabla de una BD local, pero siempre con filosofía de registro secuencial. En el argot hablamos del log de actividad del puesto de trabajo. Este log de actividad puede tener formatos muy variados desde el paso de uso de un servidor programado por nosotros mismos hasta un log de actividad de una base de datos. La información medida ha de reflejar los datos básicos del elemento y contiene las características, resultados, cliente y tiempos de trabajo. La generación del log puede consumir tiempo por lo que ha de ser activable y desactivable a voluntad desde los CASD. Eso permitirá activar un log costoso en tiempo para analizar un problema y volverlo a desactivar cuando ya se tenga la información. El log de actividad puede tener dos formatos:

Exhaustivo. Normalmente se activará para realizar estudios puntuales. De paso, con los datos mínimos. Normalmente estará permanentemente activado y dará la información mínima para el análisis periódico.

Planteemos un ejemplo clásico: la monitorización de la actividad de un servidor. Cuando el servidor arranca anota el día, la hora y el nodo donde lo ha hecho. Cada vez que el servidor proporciona un servicio anota en el log:

Referencia del cliente. Fecha y hora de inicio del servicio. Fecha y hora de fin del servicio.

Si el servidor recoge sus peticiones de un servidor de cola, la monitorización de su actividad puede mejorarse midiendo sobre la cola, además de los datos anteriores, la fecha y la hora de la anotación de petición de servicio.


Si el servidor es remoto al cliente, el cliente puede anotar la hora en que ha lanzado la petición y la hora en que le ha llegado la respuesta (información que puede ser irrelevante sí la comunicación es síncrona). Este dato permitirá valorar la eficiencia del transportista. Estos datos suelen anotarse sobre un fichero secuencial y transportarse más tarde a una base de datos donde se dispone de herramientas para obtener reportes y gráficos con los que analizar la actividad. Es fácil derivar de información del tipo:

Tanto por ciento de ocupación por cada cliente. Tiempo de transporte de las peticiones. Tiempos de espera del cliente y tiempos medios de respuesta. Distribución de peticiones por tramos horarios, etc.

Del análisis de está actividad pueden derivarse acciones de mejora del tipo:

Localización del servidor cerca de los clientes de mayor actividad. Arrancar más de una instancia en las puntas de servicio. Mejorar la plataforma de transporte si los tiempos de traslado son demasiado altos, etc.

Para las mediciones generales como nivel de ocupación de discos, cogestión de la plataforma de conectividad, ocupación de CPU o memoria, etc. si no se usa software específico de DSM, se suelen implementar y diseñar agentes que periódicamente o por eventos miden e incluyen los resultados en el modelo de Monitoring. Finalmente, los datos objetivos del servicio de asistencia se sacan de la propia aplicación de soporte, normalmente por un proceso periódico. Una opción válida es no integrar esta información con el resto de datos, realizando la gestión sobre el propio sistema de apoyo.

11. 3. Los datos de calidad de servicio. Como he planteado al hablar de soporte, es muy importante disponer de una encuesta de grado de satisfacción de los usuarios. Esta encuesta puede realizarse sobre un impreso WEB u ofimático y a partir de aquí incluirlo en la recolecta del proceso de Monitoring. Estos impresos tendrán dos partes:

Valoración cuantitativa. Por ejemplo, valorar de 1 a 10 la opinión sobre el cumplimiento del tiempo de respuesta.

Valoración subjetiva. Conviene añadir un apartado de varios para que el usuario incluya de forma textual otras opiniones adicionales que sean de su interés.

El análisis de gestión ligado a la calidad de servicio se establece en dos niveles:

Cuantitativo: encuestas por debajo de mínimos. Se confrontan con los datos de las mediciones automáticas y la medición del soporte


deduciendo si el problema es de servicio o de usuario y actuando en consecuencia.

Revisando los comentarios subjetivos. Es la tarea más ardua pero que ayuda muchas veces a descubrir cosas que ni sabíamos que pasaban. Puede generar la incorporación de nuevas valoraciones subjetivas.

12. Registro del Inventario de activos tecnológicos.

Se registrará descripción, coste, uso y ciclo de vida por elemento. Es un proceso administrativo no trivial y que debe apoyarse en fuentes objetivas como:

Recursos de inventario automático. Facturas de compra y/o servicio. Albaranes del servicio de soporte.

Hay que intentar inventariar el bien, no su composición exacta ya que puede variar con el tiempo. Por ejemplo, puede hablarse de un PC tipo con un nivel de cpu, memoria y disco, pero dejando un margen el detalle y/o número de serie de esos componentes.

13. La gestión del repositorio de administración. Para conseguir una buena gestión de los recursos del sistema distribuido es necesario, como ya hemos citado reiteradamente, disponer del repositorio de administración donde se archivan el inventario de activos y los resultados del inventario y del Monitoring:

Inventario de activos. Catalogo de servicios. Aplicaciones. Datos de rendimiento Datos de soporte, etc.

El punto de partida es referenciar, asignar un nombre lógico (Naming), catalogar (Directory) y registrar las características y parámetros de cada uno de los recursos. La responsabilidad de la estructura, contenido y formato del repositorio es del CDSD. La gestión de los valores de la información codificada dentro del repositorio es del CASD Central, aunque delegar puntualmente en CASD locales. La implementación del repositorio se hace dentro del entorno del CASD, preferentemente con recursos del DSM. Desgraciadamente, si utiliza este camino no tendrá un repositorio unificado sino hace la etapa de integración. Por ejemplo, los recursos lógicos de las impresoras los gestionará a través de los administradores de impresoras, los recursos que corresponden a los directorios compartidos a través de las herramientas de directorios y ficheros, la seguridad de BD a través de sus gestores, la de los ficheros a través de las herramientas de gestión de directorios y ficheros, los clientes y servidores se catalogarán en directorios del gestor de ficheros, etc.


Y, lo más grave, no tendrá un fichero unificado que corresponda al repositorio y que pueda copiar, reproducir y restaurar. Si decide implementarlo por su cuenta, utilizará una BD y un lenguaje de usuario y deberá crear software para traducir el repositorio al sistema. Este esfuerzo solo le va a ser rentable en instalaciones muy grandes. Otra opción es utilizar una aplicación de gestión del conocimiento. La mejor solución es hoy día, utilizar los recursos de los paquetes de administración integrada que se han citado en la primera parte, que, por cierto, no son nada baratos. Déjeme ser, por un momento, pesimista. Pocas veces se lleva un repositorio medianamente válido ya que nadie aprecia las ventajas y solo ve los costes.

14. Area de Análisis de la gestión: Auditoria del Outsourcing

Las actividades del área de gestión, culminación de muchas de las actividades del resto de les áreas, se han ido explicando a lo largo del capitulo. Por su importancia, vamos a citar aquí una actividad específica: la auditoria de los procesos de Outsourcing. En la figura de la derecha se muestra un ejemplo de cómo actuar en esta área. Cualquier actividad de Outsourcing ha de estar acordada en contratos entre proveedor y cliente. En la redacción de estos contratos han de intervenir los departamentos Informático y Legal de ambas partes. Los contratos deben ser asumidos por la Dirección de ambas partes. Esos acuerdos tienen como parte fundamental los niveles de servicio pactados. Como el incumplimiento de esos niveles está normalmente ligado a penalizaciones, los acuerdos deben contener indicadores para medir claramente ese nivel de servicio y poderlo comparar con los pactos. Prime la simplicidad y fiabilidad de los indicadores sobre una sofistificación que haga imposible la fiabilidad de la medición y por tanto la aplicación de las penalizaciones. No hace falta que añada que la medición en fase de explotación de los indicadores se obtiene del Área de Análisis de la Administración del Sistema.

Cliente

Proveedor

Servicios

ContratosPactos de nivel de Servicio

Indicadores del nivel de servicio pactado

Área de AdministraciónMedida de los Indicadores del

nivel de servicio pactado

Auditoria ExternaComparación para el

seguimiento del nivel de servicio pactado

Figura 251. Auditoría de los procesos de Outsourcing.


15. Área de costes. Será fundamental detectar las tareas intensivas en tiempo. Recordemos que una tarea puede ser intensiva en tiempo por dos razones:

• Por que dure mucho tiempo. • Por que se repita muchas veces.

Una vez detectadas habrá que definir procesos automáticos para resolverlas. En el segundo de los casos, un valor añadido importante será la eliminación de errores que la reiteración de un mismo proceso puede producir. Será también importante, como ya se ha citado anteriormente, disponer de un criterio para repercutir los costes en los diferentes usuarios o departamentos que utilizan el sistema distribuido: lo que cuesta se valora más y se gestiona mejor. Pueden utilizarse criterios del tipo:

Costes directos por la infraestructura asignada para uso exclusivo. Prorrateo de la infraestructura compartida. Por el consumo dinámico:

Transacciones. Soporte, etc.…

16. Análisis de la gestión de errores. Esta actividad del área de análisis consiste en analizar las causas de los errores producidos en el sistema y buscarle solución. Básicamente los errores se acaban clasificando y analizando en áreas.

Errores en la obtención de servicios. Más adelante, y en el capitulo de consistencia hablaremos como. Permite detectar puntos débiles por diseño, congestión o plataforma y tomar las acciones oportunas para resolverlos.

Errores de operativa. Afectan básicamente al área del usuario y los programas cliente. Llevan a detectar:

Fallos de formación, que pueden aconsejar acciones formativas globales.

Fallos de operativa de detectes operativas poco robustas que hay que mejorar.

Usuarios “obtusos” por: Desidia, que habrá que reprimir Condiciones naturales, que habrá que formar especialmente o cambiar.

17. Área de gestión y control. La gestión del sistema se realizará a partir de herramientas de DSM o recursos proporcionados por el análisis de administración de cada una de las aplicaciones distribuidas. La configuración de la plataforma se hace a través de los recursos para:


Planificación de procesos y servicios. Automatización de eventos. Planificación y gestión de cambios y configuraciones. En particular la administración de las fichas de enviroment de los servicios.

Gestión de problemas. Gestión de recursos de almacenamiento. Gestión de activos y directorios. Administración de clientes y servidores y localización de recursos de las que se habla específicamente más adelante.

Nunca debe olvidarse que lo importante es la aplicación, que es el elemento que realiza el trabajo, y no la infraestructura en sí que está a su servicio. Una vez el sistema en explotación, dos componentes han de permitir controlar y gestionar en caliente el sistema distribuido: 17. 1. Cuadro de mandos del sistema distribuido.

Donde se representa el estado actual de la plataforma y de la explotación de los procesos de negocio y sus incidencias. El cuadro de mandos de un sistema distribuido es una extensión y una generalización de un concepto tan antiguo como la informática y que, como enésima versión de nuestra manía de inventar nombres para conceptos similares, se ha llamado de diversas formas: control de objetivos, gestión del rendimiento, etc... Recordemos que el cuadro de mandos del sistema distribuido tiene dos partes que ha veces se solapan:

Cuadro de mandos de explotación o administración (extensión del ámbito de clásico centrado en los negocios).

El cuadro de mandos de seguimiento del estado del negocio. Un sistema distribuido, que como tal permite disponer en línea de un porcentaje altísimo de la información y los recursos de la empresa, permite que los cuadros de mandos dispongan de recursos y actitudes que de los que no se disponían anteriormente.

• La alta disponibilidad permite, entre otras ventajas, disgregar la complejidad de organizaciones grandes. Se manifiesta en dos grandes líneas:

o Volumen e instantaneidad de la información. o Usuarios responsables conectados, lo que permite traspasar la

responsabilidad a primera línea. • Poder trabajar con planificación continua y previsiones ondulantes que

permiten adaptar los recursos a los objetivos con total flexibilidad: por ejemplo, con revisiones trimestrales.

• Reaccionar a los cambios: o Ampliar los objetivos fijos (por ejemplo, los presupuestos

anuales) con variables en función de la evolución de la situación. Sin olvidar, obviamente, que los objetivos variables han de estar alineados con los fijos. Por ejemplo, detectamos una desviación


importante de ventas en un punto del negocio y reaccionamos estableciendo un objetivo variable para recuperarlo.

o Incorporar nuevos objetivos y adaptar los actuales sin esperar a los ciclos de planificación, normalmente anuales.

• Pasar de actitudes reactivas a proactivas, probando los efectos de las decisiones antes de ponerlas en práctica.

• Aumentar la trasparencia. • Disminuir los riesgos.

17.1.1. Filosofías de integración.

Existen dos formes básicas de consolidar el cuadro de mandos que pueden utilizarse de forma conjunta: 17.1.1.A. Estática.

Basada en una arquitectura Data Warehouse. Los procesos que crean el cuadro de mandos trabajan sobre él. Puede tener tres visiones, combinadas o no:

• Data Warehouse convencional. • Data Warehouse con actualización tan rápida como sea

posible, mal llamada, en mi opinión, DW en tiempo real. • Sistema de gestión integrada de la información Empresarial.

17.1.1.B. Dinámica.

Basada en utilizar y combinar les técnicas:

• Los procesos que construyen el cuadro de mandos van a buscar la información a las fuentes originales, idealmente con técnicas SOA y agentes en la zona del cuadro de mandos.

• Web Services, cuando los datos están en terceros. No deja de ser un caso especial del anterior.

• Las aplicaciones originales envían los datos al cuadro de mando, frecuentemente con agentes o un proceso de recolección.

17.1.2. Cuadro de mandos de explotación o administración.

El cuadro de mandos de explotación, conocido también como cuadro de administración, puede ser definido por los diseñadores informáticos junto a los administradores de sistema consultando a los responsables de explotación de cada una de las aplicaciones. Reflejará la situación de la explotación en caliente de temas como: Mapa de comunicaciones:

Estado de comunicaciones. Nodos con problemas.

Mapa de negocio. Estado de los procesos de negocio. Estado de flujo de archivos. Control de los procesos Bach.


Control de llegada. Estado de ejecución.

Control de incidencias pendientes de resolver. Estado de los procesos de replicación.

Situación de los back-up’s. Integrar el centro de errores. Incidencias sin resolver de Hot-Line. Etc.

Observe que dentro del cuadro de mandos de explotación del sistema distribuido hay dos visiones: La de sistema, que acostumbra a ser única. La aplicación para el responsable de explotación de cada aplicación, que depende de la organización de cada compañía y puede ser personal no informático. ES habitual que esta parte sea responsabilidad de los usuarios avanzados de cada entorno.

Le recomiendo que haga un diseño único y especialice por la autentificación de cada usuario. De hecho hay funciones que ya se podrán pensar en este momento y otras, básicamente en el ámbito de los procesos de negocio, que aparecerán después de la integración de la parte cliente. Para obtener el cuadro de mandos hay que potenciar los procedimientos automáticos que acaben alimentando un Framework que consolide la información. Las funciones del cuadro de mandos deben visualizarse en función del perfil del usuario identificado. Esta sencilla posibilidad permite montar cuadros de mandos por líneas de negocio. Así puede conseguirse desde que el responsable de stock solo vea los elementos de control de su actividad hasta que el administrador vea toda la actividad del sistema. El cuadro de mandos ha de ser claro y simple por lo que no puede contener excesivo detalle en la descripción. Pueden definirse estados del sistema a controlar y asociar un semáforo a cada uno de ellos. A partir de aquí la información será jerárquica. El estado verde se asociará todo correcto, el ámbar a aviso y el rojo a problema grave. Por ejemplo, se puede asociar un estado de sistema a controlar la plataforma de comunicaciones. Si está en verde, todo esta correcto. Si hay nudos con problemas de reintentos fuera del rango normal, se colocará en ámbar y si hay un nodo fuera de línea se colocará en rojo. Haciendo doble clic sobre el semáforo se obtendrá una colección de semáforos asociados a cada uno de los nodos de la plataforma de comunicaciones que nos afinarán la información. Otro ejemplo puede ser la recepción diario de los ficheros de ventas de las tiendas de una organización de venta directa al cliente. Se asocia un


semáforo al proceso y se define que si, por ejemplo, a las 9 de la mañana del día siguiente quedan aún locales por enviar la información, se coloque el semáforo en ámbar y si a partir de las 12 todavía hay cosas pendientes se coloque en rojo. En segundo nivel se puede asociar un ticket mutihoja a cada tipo de información y a partir de aquí se arranca un programa que permite analizar y diagnosticas las causas de la incidencia con los recursos habituales de los tickets. Un tercer ejemplo puede ser la conformación de documentos de stock de un nodo donde hay un almacén. Si pasado un día de la fecha de llegada el albarán está por confirmar el semáforo del estado se coloca a ámbar y pasado 2 días a rojo. Cada aplicación debería, en su diseño de administración, incluir su información en este Framework. No hace falta decir que cada caso se habrá de diseñar teniendo en cuenta sus propias características y que la personalización a través de fichas de enviroment será determinante para la adaptabilidad y control del sistema distribuido.

17.1.3. Cuadro de mandos de seguimiento del estado del negocio. Para diseñar el cuadro de mandos de seguimiento del estado del negocio los diseñadores necesitan conocer el mapa estratégico del negocio, donde dirección reflejara los objetivos a cubrir por cada persona y/o departamento de la compañía. Por ejemplo, imaginemos que una unidad de negocio debe cubrir cada mes una cifra determinada de ventas, con un tanto por ciento de coste de materia prima y un tanto por ciento de coste de personal. En el cuadro de mandos debería comparar el total de venta previsto con el cubierto, y los costes de personal y materia prima actuales respecto a la previsión objetivo. Será bueno incluir porcentajes y códigos de colores del estilo: Verde: objetivo en vías de cubrirse. Ámbar: vamos por debajo. Rojo: vamos muy por debajo.

Cuando una unidad de ventas está en rojo se podría enviar un aviso a la central. Obsérvese que la idea del cuadro de mandos del negocio y el de explotación es en el fondo la misma. Así, todo lo que hemos dicho y diremos para el cuadro de mandos de explotación es traspasable al cuadro de mandos del negocio.

17. 2. Consola única Desde donde se puede acceder de forma remota a cualquier punto del sistema distribuido. Suele integrarse en el cuadro de control.


Ha de permitir dos filosofías:

Pantalla compartida, tipo PC Anywhere Entrada sin interferir con el trabajo habitual del nodo, tipo Terminal Server.

18. Características de las actividades de Administración de clientes.

La administración de los puestos clientes viene condicionada por una tenaza:

Delegar totalmente conduce al fracaso ya que es poco tiempo no hay dos plataformas iguales.

Querer tener una intervención absoluta sobre la plataforma los que es inviable e impopular.

Para resolver este dilema y librarse de la tenaza, existen tres líneas de actuación:

Estandarización controlada de la plataforma mediante la definición de una plataforma estándar.

Delimitación de responsabilidades con el usuario. Administración remota.

A continuación desarrollaremos algunos de los puntos de este apartado.

19. Administración de servidores. Los servidores pueden estar distribuidos por toda la organización pero, a pesar de ello, la responsabilidad de la administración es siempre del CASD Central, el cual, a efectos operativos, puede delegar en el CASD local. En particular, la parametrización y el arranque han de estar siempre bajo la responsabilidad del CASD. Siempre que sea posible, los servidores, incluyendo como tales el Housing WEB, han de estar localizados en zonas de acceso restringido a los usuarios. Si las características del servidor lo requieren hay que prever visitas de mantenimiento preventivo o procedimientos automáticos, de los que ya hemos hablado anteriormente, para hacerlo, Las visitas no necesariamente físicas: no olvide las inmensas posibilidades de la administración remota. Para llevar una buena administración de servidores es necesario:

Llevar un inventario fiable y referenciado de los servidores, normalmente dentro del repositorio de administración.

Documentación fiable y precisa del contrato de software del servidor, incluyendo de forma específica la parametrización y arranque. Si es comprado, se habrá de documentar igualmente para el CASD.

Potenciar y conocer la ficha de enviromente del servidor. Posibilidad de gestión remota.

20. Gestión remota y desatendida de clientes y servidores.


Ya hemos hablado suficientemente de la importancia de la administración remota que permite el acceso “in situ” a clientes y servidores. Sencillamente fundamental. Pero, además de la gestión remota, la dispersión y cantidad de usuarios, es necesario montar procesos de administración automática. Para la gestión desatendida ya hemos visto herramientas a lo largo de los capítulos anteriores:

Procesos de checking automáticos. Log’s de trabajo. Recuperaciones automáticas y/o iniciadas por el usuario, etc.

Montarlas es rentable hasta en instalaciones muy pequeñas en las cuales disponer de un servicio de administración consolidado puede ser inviable económicamente. Un ejemplo de proceso de checking automático puede ser el siguiente, pensado para evitar problemas de disco lleno:

Cuando la máquina arranca, se accede al nivel de ocupación del disco. Si la ocupación es superior a la máxima de alerta, se envía un mensaje de aviso al CASD.

Si la ocupación es superior al máximo de parada, es suspende el arranque, se avisa al usuario y se envía un mensaje de emergencia al CASD. Si el sistema es crítico y no puede pararse se deben diseñar procesos automáticos de recuperación como, por ejemplo, la limpieza de las áreas de trabajo y eliminación de datos históricos con la caducidad superada.

Observe que los procesos de checking deben montarse, siempre que sea posible, como piezas reutilizables para más de una aplicación.

21. Localización de recursos. A efectos de administración, la localización de recursos se ha de entender en su sentido amplio, desde impresoras a servidores, pasando por los directorios compartidos y las bases de datos. El diseño y los criterios de administración del sistema dejarán los recursos lo más distribuibles posible: es decir, independientes de la plataforma. La gestión de la localización de recursos es un tema muy disperso. El CDSD habrá de establecer criterios y el CASD y los responsables de aplicación deberán decidir la localización de los recursos en las etapas del diseño como hemos hablado en los capítulos anteriores. Esta localización inicial deberá optimizarse con el análisis de los primeros resultados del arranque de la explotación. La localización de recursos, además, deberá adaptarse a la evolución de la organización y de la técnica y a los resultados de los estudios de rendimiento de las actividades de Monitoring. Aunque, como ya hemos dicho antes, la localización es un tema muy disperso, recuerde todos los criterios de localización que hemos visto en capítulos anteriores y que no voy a repetir aquí.


En cualquier caso, debe escogerse el modelo de ejecución más sencillo que cumpla la plataforma pedida. Para hacerlo, cada nodo de hardware ya de ser calibrado en su potencia de proceso valorando su memoria, procesador y disco.

22. SOA Governance.

En una arquitectura SOA, el gobierno de los servicios es fundamental des del primer momento. El gobierno del sistema SOA asegura que los conceptos y los principios de la arquitectura distribuida SOA sean manejados correctamente y se mantengan alineados con los objetivos de negocio. SOA supone la coexistencia simultanea de muchos elementos: componentes, especificaciones, condiciones de servicio, metaesquemas de datos, reglas y modelos de negocio, etc… Estos elementos deben ser gestionados. Hay que saber como son, que son, porque existen, para qué sirven, donde están, sus políticas de uso y explotación, su rendimiento, su utilización y sus condiciones de seguridad. SOA Governance permitirá controlar y gobernar todos los aspectos en el ciclo de vida del servicio. SOA Governance no es más que una aplicación de los procesos del área de dministración de Inventario y Monitoring que permitirá tomar decisiones sobre:

• Catalogo de servicios y su ciclo de vida. • Regles de despliegue. • Rendimiento, etc...

La SOA Governance tiene tres aspectos:

• En desarrollo para contrastar rendimientos, escalabilidad y comportamiento.

• En despliegue, para validar las decisiones. • En producción, para administrar, en el concepto amplio de la palabra.

Podemos aprovechar herramientas y plantearnos la solución en el ámbito del diseño de la administración del sistema distribuido. Tanto en un caso como en el otro, se suele trabajar con agentes que se despliegan con los servicios de forma no intrusiva y que recogen información en tiempo de producción y la envían al centro de mando del sistema distribuido. Allí se gestionan como cualquier otra actividad de Monitoring.

23. Estrategias de actuación en la administración.

23. 1. Esperar a que pase el problema.

Necesita de la existencia de un fuerte soporte preparado para actuar cuando pase el problema. Es una estrategia muy peligrosa que no le recomiendo ya que, si el equipo de administración no está sobre dimensionado, son demasiado frecuentes las puntas que desacreditan el servicio de administración.

23. 2. Administración desde el usuario.


El usuario se guiará por manuales, guías y procedimientos, pero intentará resolverlo solo cuando tenga el problema acudiendo a los CASD sólo en casos extremos. Puede ser una opción muy válida que supone:

Un esfuerzo fuerte de normalización. Alta probabilidad de llegar a incompatibilidad de plataformas.

Puede utilizarse soporte de terceros, que el usuario contratará o no directamente.

23. 3. Administración remota. Desde los CASD se llega a todos los elementos por administración remota.

23. 4. Que le recomiendo. Difícil cuestión a la que me atrevo a contestar solo por los resultados de mi experiencia:

23.4.1. Soporte de la plataforma y distribución e instalación del software de aplicación:

Administración remota. Recuerde, sin embargo, que entre un 20% y un 30% de las actuaciones necesitan soporte local.

23.4.2. Parametrización y soporte del software de aplicación: Administración de la gestión desde el usuario pero con un servicio de apoyo remoto a partir de los problemas de nivel medio.

24. Repercusión del coste. Es bueno que es usuario tenga idea de lo que cuesta darle servicio. Nada más dejo el tema en el aire. Decida si en su organización conviene o no repercutir del coste del soporte al usuario.

25. Clasificación de las actividades de administración por su naturaleza. Las actividades de administración de los sistemas distribuidos pueden clasificarse desde una visión no de servicio sino de naturaleza en cuatro grandes disciplinas:


Catalogación, Instalación y Configuración. Gestión del estado (status). Estudio del rendimiento (perfomance). Soporte a usuario.

Y abarcar cinco áreas:

Clientes Servidores. Conectividad Middleware. Hardware y periféricos.

Esta relación en dos dimensiones suele representarse con el cubo de la figura. Dentro de cada celda se incluyen una o varias actividades de administración. A partir de aquí se puede obtener una clasificación. Le dejo como ejercicio (muy evidente) que clasifique las actividades de detalladas en la primera parte dentro de cada celda. EN mi opinión es mejor trabajar con la visión de servicio.

26. Diseño de la administración del sistema. Se hace muy difícil proponer una metodología sistemática y completa para desarrollar el diseño de la administración del sistema pero podemos intentarlo en el diagrama de la figura.

Grupos de actividades de

administración

Clientes

Servidores

Middleware

Conectividad

Hardware y Periféricos

Con

figur

ació

nSt

atus Pe

rfom

ance

Sopo

rte

Figura 252. Clasificación de las

actividades de administración


Diseño de AdministraciónDiseño

ConsistenciaFunciones de

DSMIdentificar lo que falta

Diseño e Implementación


Monitoring

Definir funcionesDiseño e

Implementación

Procesos intensivos en

tiempoIdentificación


Cuadro de mandos

Cuadro de mandos para el seguimiento

del negocio


Cuadro de mandos de explotación

Consensuar contenidos

Mapa Estratégico del negocio

Figura 253. Diseño de la administración de sistema

27. Que dice la experiencia.... Montar un sistema de administración y soporte como el que hemos visto, y completaremos en el capítulo siguiente, es caro de establecer y gestionar. No tanto por el importe en sí, si no porque es un coste fijo. Hoy día, todas las compañías usan la informática a tope para minimizar costes y ganar calidad de servicio. El coste de parada por avería o falta de soporte es por ello muy alto y, aunque es muy difícil de valorar, seguro que justifica los costes de organizar un mínimo sistema de administración. Sin embargo, decidir cual es la mejor opción es complicado. La tarea de los diseñadores y administradores para conseguir una relación prestaciones/costes de eficiencia óptima es muy difícil. Siempre esta justificado, y lo que es más importante, sale a cuenta, trabajar con la idea de la plataforma estándar. Disponer de una completa ficha de configuración de cada servicio es primordial. Administrar con recursos propios, y delegar en terceras compañías especializadas en soporte es una muy buena solución. Lo mismo que apoyarse en compañías especializadas a la hora de establecer políticas basadas en las posibilidades del sistema. Esto último evita el coste de reciclaje técnico en compañías pequeñas y medias. En este sentido, si la estandarización es muy alta, un sistema posible es que los usuarios contraten el soporte directamente a compañías cercanas a su situación geográfica. Sin embargo, a mi no me parece la mejor solución hoy día con las extraordinarias posibilidades de administración remota disponibles, las use Vd. o las compañías a las que subcontrate.


Normalizar operativas, y utilizar al máximo los estándares de mercado, es otro gran recurso. Y, finalmente, hoy día si no dispone de administración remota móntela lo más rápido que pueda. Y manténgala siempre con la plataforma de comunicaciones más rápida que la evolución de las prestaciones versus costes le permita.


Diseño e Implementación de Actividades de Administración de Sistemas.

1. Introducción. En el capítulo anterior hemos revisado las políticas de administración. Este capítulo está dedicado a explorar algunos de los componentes para diseñar e implementar las actividades necesarias para desarrollar esas políticas. Como ya se ha dicho anteriormente, la mayoría de las actividades de administración han de ser apoyadas por las herramientas de DSM y el diseño ha de complementar aquellas actividades a las que no llegue aquel. Son objetivos adicionales de este capítulo es:

Presentar diferentes estrategias para aquellas actividades que tienen un tratamiento claramente diferencial dentro de un entorno distribuido.

Presentar posibilidades de implementación de herramientas pseudo-DSM cuando el entorno DSM no las tenga.

Recuerde que las estrategias de las que hablaremos en esta sección se montarán más fácilmente y/o quedarán obsoletas a medida que los estándares de DSM+NOS sean más potentes y amplios.

2. Captura de las direcciones variables de IP. Es frecuente que las direcciones de IP varíen en cada conexión cuando la plataforma de comunicaciones contratada en cada nodo no garantiza IP fija. Si la IP varía en cada arranque del nodo y ese nodo debe ser administrado de forma remota, si no tomamos ninguna medida adicional, el administrador que quiere acceder remotamente deberá llamar por teléfono al centro para averiguarla sobre la máquina. Y la respuesta deberá dársela un usuario que es probable que no sepa donde buscarla. Y, aún en el mejor de los casos, se perderá un tiempo precioso y con impacto directo sobre el coste del servicio de soporte. La dirección IP estará sobre el registro de cada nodo en el repositorio de administración. Bastará un simple proceso, que cada vez que arranque el nodo envíe su IP al centro de administración para solucionas este problema. Para implementar esta actividad de administración puede darse diversas soluciones tecnológicas a partir de un cliente back-ground que se arranca cada vez que se levanta línea y que envía a la central la información:

Que el cliente back-ground acceda directamente al repositorio. Montar una estructura de dos niveles donde el cliente back-ground utiliza un servicio localizado en el centro de administración que recibe la información y modifica dirección del nodo.


3. Copias de Seguridad (Back-up y Restore). El sistema de copias de seguridad ha de establecer procedimientos de back-up y restore para el total de la arquitectura de datos distribuida. Como ya se ha hablado anteriormente, el problema no es trivial y adicionalmente, tiene que garantizarse la igualdad de nivel entre todas las copias de los nodos de forma que en caso de recuperación pueda garantizarse la coherencia de todos los datos. El diseñador ha de tener en cuenta que, si tiene parte de la responsabilidad, el usuario tiene tendencia a no hacer copias. Por eso, sea cual sea la estrategia que se adopte, ha de dejarse muy claro entre el usuario y el CASD que responsabilidad acepta cada uno y las consecuencias de no hacer copias. 3. 1. Condicionantes.

Existen unos condicionantes que conviene estudiar de forma diferenciada.

3.1.1. Capacidad de los dispositivos de Back-up. La capacidad máxima de los dispositivos de los dispositivos de back-up puede llegar a ser una gran limitación. Para hacernos una idea, revisar unos números de capacidad necesaria: en un sistema de 50 usuarios (pequeño) en el cual cada usuario tiene asignado 100MB de disco (no demasiado), la capacidad total del dispositivo de back-up debería ser de 50 * 100 = 5000MB (5GB).

3.1.2. Tiempo necesario para hacer la copia. Si el tiempo necesario para hacer la copia en frío (sin los usuarios trabajando), sea por volumen y/o por velocidad y capacidad de los dispositivos de copia, es grande aparece un problema adicional que puede obligar a realizar la copia en caliente, es decir, con los usuarios trabajando. Si esto ocurre el diseño de administración debe preverlo. Una opción válida para resolver este problema es hacer copias en línea (on line) con discos espejo (mirrors). Si son removibles, pueden utilizarse como copias de back-up fuera de línea (off line)

3.1.3. Dispersión de lógica de información. Del condicionante derivado de la dispersión de información inherente a una arquitectura distribuida de datos, ya se ha hablado ampliamente con anterioridad. Dificulta la consistencia y la coherencia de nivel entre cada copia.

3.1.4. Dispersión geográfica. En paralelo al punto anterior, supone la dispersión física, y muchas veces, comunicaciones lentas entre los nodos.

3.1.5. Diferencias de calendario y horario.


También hemos hablado ampliamente de este punto con anterioridad. No voy a repetirme.

3. 2. Estrategias de copias de seguridad. Las estrategias de copias de seguridad se establecen por niveles y áreas según seis coordenadas: calendario, momento, lugar, rotación, almacén y tipo de gestión. La estrategia se establecerá determinando un criterio para cada coordenada. Por ejemplo:

Área: datos de usuario. Calendario: cada día. Momento: una vez al día, a las 8 de la tarde. Lugar: los servidores departamentales. Rotación: se guardan dos generaciones. Almacén: una caja de seguridad ignífuga. Tipo de gestión: manual por el responsable del CASD local.

Veamos algunos detalles de cada componente.

3.2.1. Áreas y ámbitos de datos. Hay que diferenciar tres ámbitos:

Información centralizada. Información departamental. Información de usuario.

Y tres áreas:

Programas y tablas de parametrización. Ficheros con volatilidad mínima (los productos acostumbra a ser un buen ejemplo). Datos con volatilidad alta.

3.2.2. Gestión de cada una de las áreas.


3.2.2.A. Área de programas. Se mantendrá una copia de seguridad que nada más se actualizará cuando haya un cambio de versión o de configuración. La recuperación se hará fácilmente volviendo a copiar los programas desde la copia. Si el tiempo no es muy grande, tiene también el recurso de no hacer copias y reinstalar en caso de caída.

3.2.2.B. Área de datos no volátiles. Se actualizará la copia sólo cuando cambien. Tiene dos opciones: copiar toda la base de datos con un programa de copia y usar los recursos de la base de datos para obtener copias individualizadas de las tablas afectadas. No caiga en el error de hacer la copia total de la base de datos: ¡la recuperación de unas pocas tablas no volátiles colisionará con el nivel de datos de todas las tablas volátiles! Utilice siempre el segundo método y, si es necesario, haga la recuperación con los recursos de recuperación de la propia base de datos.

3.2.2.C. Área de datos. Es la parte más dura, y es la que realmente obliga ha hablar de estrategias de copias de seguridad. Si la responsabilidad es del CASD (se lo recomiendo) se ha de establecer una rotación (hablaremos más tarde de este aspecto) que el CASD debe pactar con los responsables de aplicación. Aquí tiene también la opción de utilizar los recursos de la base de datos y copiarla toda como un fichero más. La decisión se la habrá de estudiar en función de cada caso. Sin embargo, y sabría relacionar el porqué, yo me inclino por utilizar los recursos de la base de datos. No hace faltar remarcar que si utiliza la copia restaurará recopilando y si utiliza los recursos de back-up de la base de datos para la copia también utilizará los de restore para recuperación.

3.2.3. Responsabilidad de cada ámbito.

3.2.3.A. Información centralizada. Supone siempre la presencia de bases de datos y en algunos casos incluso heterogéneas. La responsabilidad de su administración es del CASD. Estas bases de datos son potentes en recursos y herramientas de administración y son muy fáciles de administrar.

3.2.3.B. Información departamental.

Supone, normalmente, la coexistencia de bases de datos departamentales y de ficheros convencionales. Como ya hemos visto anteriormente, existe el concepto de servidor lógico que puede estar


implementado en más de una base de datos, situadas en una o más máquinas, y que puede tener problemas de heterogeneidad. Remarcar, finalmente, que lo normal es que la información departamental incluya más de un Dpto. con información compartida y/o individualizada por Dpto. La responsabilidad de su administración es del CASD departamental que puede delegar en un usuario avanzado. Si en ese punto no existe CASD, la responsabilidad es del CASD central que tiene que delegar, para ser operativo, en un usuario avanzado del entorno donde está situada la información departamental.

3.2.3.C. Información de usuario.

Formada por ficheros convencionales (mucha ofimática) y esporádicamente alguna base de datos propia tipo Access. Físicamente la información de usuario puede estar en su disco local o dentro de los servidores de red, es este caso, con prioridad en el de su departamento. La responsabilidad de la información es del usuario. Hay dos estrategias: La copia se saca sobre la máquina del usuario (responsabilidad total el usuario). La información o esta en el servidor o se envía allá por el usuario y es allí donde se saca la copia. En este caso, es habitual que el back-up se delegue en el CASD o en un usuario avanzado.

3.2.4. Calendario.

Es el día y la hora (momento, factor del que hablaremos a continuación) en el cual se hacen las copias. Conviene establecer un calendario con múltiplos naturales: cada día, cada dos días, cada 6 horas, por la noche, etc. Recuerde aquí el problema que para la sincronización de copias supone los diferentes días festivos de las zonas geográficas.

3.2.5. Momento. Si es posible, hay que escoger uno en el cual se puedan hacer las copias en frío. Y recuerde que parar a los usuarios para hacerlas no es una buena estrategia ni política (es impopular) ni económicamente (hoy día todos los puestos de trabajo tienen un ordenador y pararlos a todos supone un dispendio económico enorme). Si la empresa hace un horario rígido, aproveche los huecos, aunque, desgraciadamente para los administradores, cada vez hay menos empresas (yo creo que ya no existen) en las cuales haya momentos en horas razonables en los cuales nadie trabaje. En las oficinas un buen momento suele ser a última hora de la noche, aunque es este caso, le


recomiendo hacer una copia en caliente sobre el medio día ya que toda una jornada es demasiado periodo entre copias. Recuerde también aquí, los problemas que los husos horarios pueden aportan para la sincronización de copias si es esquema de datos es distribuido.

3.2.6. Lugar. Este suele ser un componente muy poco disperso ya que las copias se hacen donde se instalan los recursos para hacerlas y esa localización no suele ser polémica. Sin embargo, la dispersión de los componentes del sistema distribuido puede ser tan variada que puede convenir establecer una normalización focalizando cuatro lugares:

Puestos cliente. Servidores departamentales bajo la administración de un CASD local o de los responsables de aplicación. Servidores compartidos por varios departamentos y bajo la administración de un CASD local. Servidores centrales bajo la responsabilidad del CASD central.

3.2.7. Rotación.

La coordenada rotación hace referencia a cuantas generaciones y como se cambian las copias. Así se pueden hablarse de tres generaciones: abuelo, padre e hijo y cambiarse el abuelo cada mes, el padre cada semana y el hijo cada día. Y, perdóneme, no soy capaz sistematizar más este punto.

3.2.8. Almacén. Esta coordenada hace referencia a donde se guardan las copias:

Lugar: el mismo sitio de la copia, otro local, la central, etc. La caja: el despacho del responsable de aplicación, el departamento de informática, una caja ignífuga, etc.

3.2.9. Tipos de gestión.

Hace referencia a la forma en la que se generan las copias. Hay varios aspectos.

3.2.9.A. Según la forma de arrancar: Automática. Manual.

3.2.9.B. Como está el sistema de información:

Trabajando: en caliente.


Parado: en frío. Obviamente, son preferibles las copias en frío que en caliente.

En sistemas distribuidos, las copias automáticas han de estar garantizadas, es decir, hay que asegurarse que realmente se hacen.

3. 3. Las herramientas.

Hay dos fuentes de herramientas para hacer las copias y restaurarlas si es necesario:

Los recursos de DSM. Poco útiles las incluidas dentro del software de base y decisivas las fabricadas por terceros. Hay verdaderas maravillas en este sector. Búsquelas: le resolverán todos los problemas que pueda imaginar.

Los recursos de las bases de datos: tienen lo necesario para salvar y restauran sus datos.

3. 4. Implementación de copias automatizadas.

Hay tres formes de implementar copias automáticas.

Mediante montajes Batch que utilizan recursos de DSM y lanzados por reloj de forma automática.

Mediante clientes back-ground específicos. Utilizar programas de terceros (los hay fabulosos).

Cuando las copias son automáticas, un buen lugar para llevar los parámetros de la copia es el repositorio de administración.

3. 5. Algunas estrategias habituales de back-up.

3.5.1. Back-up distribuido. Cada ámbito se gestiona de forma autónoma e independiente. El arranque de la información central y departamental puede ser manual o automático La gran ventaja es la independencia entre cada administración y su gran inconveniente garantizar el mismo nivel de copias en todos los nodos.

Información de usuario

Usuario

Información Central

Central

CASD

Información Departamental

Local

CASD

Figura 254. Back-up Distribuido


3.5.2. Back-up de usuario sobre el entorno departamental. Se aprovechan las ventajas de capacidad de back-up del entorno departamental. La responsabilidad es del usuario. El proceso se muestra de forma bastante auto explicativa en la figura. El arranque por el usuario de los procesos de inclusión y generación de la copia puede ser automático, pero en cualquier caso ha de ser consensuado con el CASD.

3.5.3. Back-up departamental. La información departamental y de usuario se centraliza en el servidor departamental desde donde se copia en el recurso de back-up. El usuario se responsabilizará de copiar sus datos en el servidor departamental antes de la hora pactada para la copia. El arranque puede ser manual o automático, pero la responsabilidad es del CASD local o del usuario avanzado delegado. El usuario puede incluir su información de forma manual, mediante un trabajo Batch o una opción de menú.

Local

CASD


Usuario


Información temporal de

usuario

Proceso para incluir la información deusuarioen el entorno departamental

Proceso de generación de la copia de seguridad

Figura 255. Back-up de usuario sobre entorno departamental


Local

CASD


Usuario


Usuario

Ticket de control

Figura 256. Back-up Departamental

Figura 257. Formato del ticket de control de un

back-up departamental


Un back-up de este tipo ha de ser controlado y garantizado. Si se quiere tener control de sí el usuario hace su copia y del estado del proceso puede usarse un ticket para controlarlo. Un posible formato se muestra en la figura. La gestión del ticket de control puede ser del tipo:

El usuario es el responsable, directamente o través del proceso de copia que lanza, de anotar la columna de “recibido” en el momento que tiene la certeza de que la copia ya esta en el servidor departamental. El CASD local y / o el programa que haga la copia si la gestión es automática, ha de verificar que todos los usuarios han enviado la información antes de disparar la copia. El programa de copia habrá de modificar, en función del resultado, la columna de “grabado”. Conviene, además del Si / No tener otros estados de información como: error, anulada, hoy no se copia, etc. Se ha de establecer una política de administración en caso de que falte alguna copia.

No hace falta mucha imaginación para pensar otros procesos basados en el ticket que avisen minutos antes de la copia a los usuarios que todavía no la hayan hecho, protejan contra quejas de perdida de información, fuercen la copia de usuario, etc. La gestión del control de procesos de administración mediante tickets de control es generalizable a otros procesos de administración. La existencia dentro del entorno de administración de una pieza que implemente el uso de estos tickets es altamente recomendable. La gestión completa del ticket necesitará de los habituales procesos de consulta, consulta por excepción, eliminación histórica, etc.

3.5.4. Back-up departamental centralizado. Se trata de aprovechar al máximo la potencia de los sistemas de back-up centrales. Solo es posible en departamentos “junto” a la central, es decir, a los que se accede a la central por redes locales. Es obvio que este modelo es de gestión muy parecida al anterior. El arranque de la incorporación departamental es aquí siempre automático, iniciada por el CASD local o por el CASD central.


centralizada

Central

CASD

Informacióndepertamental

Información departamental

Local

CASD

Figura 258. Back-up departamental centralizado


Existe un peligro que se ha de vigilar: los volúmenes de las BD pueden ser muy grandes y el traslado de los datos puede no ser la solución, sino que el sistema de back-up central ha de ir a buscarlos a los servidores departamentales. Aun así, el traslado de l información llevará tiempo. No hace falta insistir que el proceso ha de estar controlado y garantizado. Una opción es colocar el servidor de seguridad en una central y concentrar en ella las copias remotas de todos o parte de los nodos. Es obvio que necesitaremos una ancho de banda que permita realizar las copias en un tiempo apropiado, y si es posible, disponer de la posibilidad de hacerlas en caliente, situación que reduciría el impacto del ancho de banda.

3.5.5. No back-up y reconstrucción. La estrategia es clara: en lugar de copiar, reconstruir desde cero. Obviamente, nada más se puede utilizar con arquitectura de replicas.

4. Consolidación de datos. Consiste en asegurarse que los datos generados por el sistema distribuido se reciben y consolidan en los nodos master de datos o se intercambian en los plazos previstos y con coherencia de códigos y contenidos. Se controlan básicamente con dos recursos.

Tickets multihoja. Auditorias de datos.

Es muy importante la definición de procesos periódicos de cierre.

5. Administración de impresoras. 5. 1. La impresión en entornos distribuidos.

Desde el punto de vista de la administración, la gestión de las impresoras es muy diferente en entornos distribuidos que en sistemas centralizados. En un entorno centralizado, las colas de impresión y las impresoras cuelgan del Mainframe; en su sistema distribuido las impresoras están conectadas a diferentes servidores, de diferentes dominios y de diferentes redes. Desde el punto de vista de programación, la impresión es ya absolutamente transparente a la situación y el modelo de las impresoras. Así, pues, hablar de las impresoras en un entorno distribuido se reduce a hablar de administración.

5. 2. Formas de conectar las impresoras. Hay tres posibilidades de conectar impresoras a una red.


5.2.1. A un servidor dedicado. Disponibilidad siempre que este el servidor arrancado. El inconveniente es que los servidores acostumbran a estar situados en zonas de poca accesibilidad a los usuarios. Y problemas tan triviales como vigilar el papel y cambiar la tinta se convierte en temas conflictivos.

5.2.2. A una máquina cliente. Disponibilidad solo cuando la máquina del cliente está encendida. La ventaja es que esta muy accesible a los usuarios. Otro inconveniente es que consume recursos de la máquina cliente.

5.2.3. A un Printer Server. Un Printer Server es un recurso que permite conectar directamente la impresora a la red. Y además es barato. Grandes ventajas:

Disponibilidad en todo momento. Accesibilidad de los usuarios ya que se pueden situar cerca de grupos de trabajo.

El inconveniente es que son algo más difíciles de administrar.

5. 3. Estrategias.

La política de que todo el mundo accede a todo el mundo se ha demostrado errónea a poco que el entorno tenga un cierto volumen. Y curiosamente, mi experiencia me ha hecho vivir que nadie establece estrategias. Y la solución fácil es comprar una impresora por usuario. Y como hay tantas impresoras, son baratas y lentas. Y cuando hay que imprimir volúmenes intermedios, el tiempo de espera de los usuarios traducido a pesetas paga en poco tiempo las impresoras más caras. Por favor, no menosprecie este coste escondido. Una buena gestión de impresoras pasa por:

Definir grupos de impresión con los usuarios. No hay criterios rígidos. Pueden valer del tipo: proximidad, afinidad, dependencia, etc. Y uno muy válido es el departamento: la camaradería y la presencia de un jefe, son dos puntos de mucha fuerza para este criterio.

Organizar esos grupos de forma jerárquica. Tipificar los modelos de impresión, independientemente de las impresoras físicas que se instalen después. Tipificar un modelo supone escoger una velocidad, una tecnología y un driver estándar, no usando opciones de impresoras especializadas si no es estrictamente necesario.

Definir los back-up’s operacionales en caso de avería o saturación. Definir los responsables de consumibles:

Encargados de la reposición del stock en almacenes centralizados por zonas de la empresa.

Encargados de colocarlos en las impresoras compartidas.

5. 4. Organización jerárquica de los grupos de impresión.


Los usuarios individuales se organizan en Grupos de Impresión. Una vez definidos los grupos, estos estructuran jerárquicamente en grupos de Impresión Departamental y estos, a su vez, en grupos de Impresión Centralizada.

5.4.1. Nivel Usuario.

Corresponde a impresoras asignadas de forma exclusiva a usuarios individuales. Estos usuarios suelen estar dotados de impresoras lentas (el concepto lento evoluciona hacia arriba según el mercado). La responsabilidad de operación y de reposición de consumibles es del usuario. La de configuración del CASD local. El soporte se lo da al usuario el responsable del grupo de impresión, que como veremos a continuación, suele ser un usuario avanzado.

5.4.2. Nivel grupo de usuarios. Los grupos de usuarios, que comparten entorno de trabajo, deberían disponer de, como mínimo, una impresora de velocidad media-alta, conectada mejor a un Printer Server que a un usuario o un servidor. Obviamente, todas las impresoras compartidas son visibles por todos los usuarios del grupo. Ha de asumir toda la capacidad de impresión habitual del grupo. Los cambios de consumibles son realizados por los miembros del grupo.

Impresión Centralizada

Impresión Departamental



Grupos de Usuarios Grupos de Usuarios

Usuarios Individuales

Figura 259. Organización jerárquica de los grupos de impresión

Nivel Departamental

Nivel Grupo

Usuario

Nivel Grupo

Local

CASD

UsuarioAvanzado

Central

CASDNivel Centralizado

Figura 260. Distribución jerárquica de los recursos de

impresión


El soporte lo da habitualmente un usuario avanzado, y sino, el CASD local.

5.4.3. Nivel Departamental. En la impresión departamental pueden incluirse varios departamentos. Si incluye más de un grupo de usuarios, solo deberían colocarse impresoras muy rápidas o, simplemente, no tener recursos de impresión. Si coinciden los grupos de usuarios con el departamento, vale lo escrito en el párrafo anterior para aquellos. Esta dentro del entorno del CASD local. La configuración y mantenimiento de consumibles es de su responsabilidad. Actúa también como back-up de los niveles de usuario.

5.4.4. Nivel Centralizado o Corporativo. En la Impresión Centralizada sólo se colocarán impresoras especializadas (por ejemplo, una fotocopiadora-impresora de color de alta calidad) o muy, muy rápidas. Necesitan, además, administración del CASD para controlar consumos y gastos por usuarios. Está dentro del entorno del CASD local o central, según su situación. La configuración y mantenimiento es, obviamente, de su responsabilidad.

5.4.5. Impresión entre ramas. La impresión entre dos ramas (por ejemplo, dos departamentos) es, en principio, esporádica. Cuando se necesite es mejor intercambiar ficheros. Sin embargo, para poder pasar ficheros es necesario que el destinatario disponga del programa necesario para obtener el listado del fichero. Cuando el intercambio sea de ofimática esto va a ocurrir siempre (ojo con los formatos de estilos, marcos, etc.). Si es un programa de aplicación, la cosa ya no es tan clara ya que, además del programa, el usuario destino deberá tener acceso y derechos sobre los ficheros auxiliares para obtener el listado (por ejemplo, en un listado de ventas, el fichero de vendedores). En este caso, habrá que disponer de acceso a la impresora del usuario. Es evidente que puede ser muy pesado de gestionar que sea la impresora de cada usuario la visible desde el entorno exterior ya que, con varios usuarios interconectados, habría que definir cada impresora destino en cada usuario origen. El conjunto queda bastante poco operativo. La solución es hacer visibles desde el exterior las impresoras de nivel departamental, ya que así, de un solo tiro se matan todos los pájaros. Y si es posible, no siempre lo es, colocar el destinatario en la cabecera del listado. Si el listado lo genera un programa de la aplicación distribuida que se esta


programando, el diseñador debe dar la posibilidad de colocar un destino en el momento de que el usuario origen pida el listado. Y recuerde, que hoy día, no hay ningún problema para compartir impresoras remotas. El único problema que se puede encontrar es compartir impresoras de entonos heterogéneos. No es un problema trivial. Trátelo puntualmente al administrar el entorno. Y verifique lo que dicen los manuales: no siempre funciona tan fácil como dicen. Finalmente, un uso habitual de la impresión entre ramas es el back-up de impresoras departamentales.

5. 5. Implementación de las estrategias de administración de impresoras. Hoy día todo el necesario esta disponible a través de los recursos que proporcionan en NOS y el DSM. Así, pues, se han de usar siempre los recursos de los servidores de impresión de la red. Recuerde que la impresión se organiza en colas que corresponden a un nombre de impresora lógica. Cada una de estas colas las gestiona un servidor de impresión. Los recursos de DSM permiten instalar y configurar con facilidad las colas e impresoras. Otro tema es la gestión de listados. Cosas como cambiar listados de colas, no son (¡increíblemente!) posibles todavía en los sistemas de red más populares. Recomiendo encarecidamente a los fabricantes de herramientas DSM para gestionar listados que hagan una visita a las posibilidades que los gestores de spool de los Mainframe han dado siempre. Amigo lector, no se desanime, seguro que el Sr. Gates lee este libro y me hace caso..... Uno de los problemas que también existen en los entornos de red modernos es la poca o nula facilidad para archivar en el repositorio los parámetros de instalación y de configuración y los derechos de los usuarios, y así, poderlos reproducir en casos de instalaciones iguales o de recuperación de averías. Esperemos que en poco tiempo, este problema nos lo arreglen también para facilitar la vida a los administradores. Esta grave carencia debe ser suplida por una buena documentación; si, eso que nunca existe. Por favor, en este tema, anótelo todo, no sabe la de tiempo que ganará y las tensiones que se evitará.

6. Administración de usuarios y derechos. En cualquier sistema pedir la identificación del usuario para autentificarlo antes de darle acceso al sistema es fundamental. Y en un entorno distribuido, la preocupación debe ser todavía mayor ya que los usuarios están bastante más descontrolados. Y la identificación permitirá darle acceso solo a lo que tenga derecho. Existen dos entornos en los que hay que delimitar derechos y restricciones:

Recursos del sistema; en este tema, no incluya los datos como recurso del sistema.

Información, es decir datos, a través de tres vías:


Derechos de acceso a las BD determinados sobre el gestor de la base de datos.

Visibilidad a través de las aplicaciones. Visibilidad de directorios con información restringida.

El objetivo ideal seria que hubiera un solo repositorio de derechos y restricciones de los usuarios en todo el sistema. Desgraciadamente, en entornos heterogéneos esta posibilidad no es siempre viable por DSM. 6. 1. Organización de usuarios y gestión de los derechos.

Los usuarios se organizan en grupos, por afinidad funcional. A cada grupo se le asignan derechos y restricciones de las que participan de forma genérica todos los usuarios del grupo. Estos grupos, en general, ya son suficientes para gestionar los derechos sobre los recursos del sistema. La relación entre grupos y recursos se establece con las herramientas de DSM. Para la gestión de la información el criterio de grupo se queda corto ya que dentro de un mismo grupo, puede haber usuarios con derechos de lectura, otros con derechos de mantenimiento y otros con acceso a solo una parte de los atributos de una entidad. Para gestionar la información es necesario, pues, distribuir los usuarios por perfiles a los que se asignan los derechos de visibilidad y mantenimiento de los datos. Los programas de las diferentes aplicaciones deberán determinar el perfil del usuario identificado, obtener su perfil de un repositorio y, a partir de aquí, personificar GUI’s con los derechos y restricciones genéricas del perfil. La relación grupo-perfil, aunque se pueda ver operativamente como jerárquica, es conceptualmente ortogonal ya que el mismo perfil puede repetirse en dos grupos diferentes. Sin embargo, y en la práctica, como unos grupos de usuarios suelen utilizar información diferente de los otros, la relación deviene jerárquica. El concepto de perfil no suele existir en los repositorios gestionados por el DSM por lo que se hace necesario implementar una pieza que lo gestione. Para gestionas los accesos a la información dentro de la BD, los grupos marcan el entorno general que después habrá que acabar de afinar usuario por usuario. En este tema puede ser también interesante utilizar los perfiles. El único problema viene del hecho de que la mayoría de los gestores de BD no permiten definir este concepto directamente lo que obliga a utilizar los perfiles como grupos en la base de datos perdiéndose la presión jerárquica de la relación grupo-perfil. En todo este tema recuerde una trivialidad. De cada información hay que determinar un responsable, perfiles de mantenimiento y de consulta. La recomendación es que si tiene un problema no trivial de restricciones no monte nada sofisticado basado directamente en gestionar los usuarios individualmente ya que se vuelve rápidamente ineficaz y pesado de administrar.


Y no olvide que cuando un usuario cambia de grupo o se marcha, deben eliminarse rápidamente sus derechos actuales. Una cuestión adicional, ¿hay que pedir autentificación de acceso a la base de datos a un usuario que se ha identificado previamente en la red cada vez que inicia un programa que accede a la BD? Un purista le dirá que no, que con una vez ya vale. Sin embargo, no menosprecie el valor de seguridad adicional que supone la identificación por inició de sesión en la red y repetirla cada vez que un programa inicia una sesión (login) en la BD. Evitará que un usuario deje abierta una sesión de red, situación muy habitual, y que otro no autorizado se aproveche para acceder a información a la que no tiene acceso.

6. 2. Gestión de directorios con información restringida.

La explosión en el uso de la ofimática ya llevado a que información de acceso restringido se ha implementado sobre ella. Y como la ofimática gestiona ficheros, estos se agrupan por directorios. Los directorios y los ficheros los gestionan usuarios diferentes que difícilmente se van a coordinar entre ellos. Y, por desgracia en este tema, los accesos a directorios se gestionan con herramientas de DSM que no tienen el concepto de perfil. Todo ello ha llevado a un bloque de gestión de derechos muy conflictivo porque los ficheros son muchos y la anarquía con que se agrupan es grande. En este tema también existe un responsable, perfiles de mantenimiento y de lectura. Pero las herramientas de DSM no disponen de perfiles por tipo de fichero. O sea, que como diría un famoso astronauta en problemas: Houston, tenemos un problema. Como la inexistencia de perfiles en el DSM solo hay una solución: organización. Le recomiendo:

Defina un directorio como un recurso compartido en algún servidor de ficheros y mapee ese recurso como una unidad lógica con el mismo nombre para todos los usuarios.

Organice una jerarquía de directorios ligada a los perfiles sobre esa unidad lógica.

Asocie un grupo de usuarios a cada perfil. Gestione los permisos de esos directorios en función de esos grupos dándoles permiso de lectura.

Responsabilice de cada directorio a un/os usuario/s del grupo y déles control total sobre los directorios base y todos los derivados. Serán los únicos que podrán crear nuevos directorios.

Decida que usuario/os mantiene/n los ficheros y déles permiso de mantenimiento sobre sus ficheros.

A los documentos más confidenciales, introdúzcales una contraseña de acceso que solo sepan los usuarios que pueden visualizarlos.

No de permisos a los administradores. Cuando un administrador debe gestionar algo, debe estar presente el responsable de esos directorios, picar su clave y supervisar el trabajo de los administradores. Como mucho, define dos niveles de confidenciabilidad, cree un usuario administrador especial y déle permisos solo a los de segundo nivel. Y la


clave de ese usuario solo debe saberla en jefe de administradores y, como mucho, otro administrador de confianza.

6. 3. Gestión de los derechos de impresión.

La gestión de los derechos de impresión no debe confundirse con los derechos de usar una impresora. Estamos hablando de los derechos de un usuario a volcar por una impresora unos datos. Y también recuerde que no necesariamente todos los usuarios con derecho de consulta los han de tener también de impresión. El control de los derechos de impresión desde programas de aplicación debe llevarlos los mismos programas. Los de ofimática no se puede controlar: quien consulta puede listar.

6. 4. Implementación del perímetro de seguridad. Como ya se ha dicho, la base de la implementación de perímetro de seguridad es siempre el DSM de la red. Si la red es homogénea la implementación de ese perímetro de seguridad se hace sin problemas con las herramientas del DSM. Si la red es heterogénea, hay que definir el perímetro sobre cada red. Hay tres opciones:

6.4.1. Perímetro de seguridad múltiple. Hay dos opciones:

Repositorio Red 1

Repositorio o Red 2

Administrador

Sesión de red

Sesión de red

Gestión de usuarios

Gestión de usuarios

Figura 261. Perímetro de seguridad múltiple con

identificación múltiple


6.4.1.A. Identificación múltiple. La definición de usuarios se realiza en cada red con sus herramientas de DSM. El usuario se identifica cada vez que inicia una sesión en cada red.

6.4.1.B. Identificación única. La definición de usuarios se realiza en cada red con sus herramientas de DSM. El usuario se identifica cada vez que inicia una sesión en cada red. Supone la existencia de un repositorio de administración unificado y de herramientas de DSM, compradas o fabricadas, para gestionar de forma automática desde él cada red.

6.4.2. Perímetro de seguridad único.

Supone la administración única como en el caso anterior, pero además el usuario solo se identifica una vez. Es necesaria la existencia de herramientas adicionales de DSM, compradas o fabricadas y de un servidor de identificación para autentificar el acceso.

6. 5. Una posible arquitectura de un servicio de identificación. Un servicio de autentificación puede montarse fácilmente con un servidor.

Repositorio administración

Repositorio Red 1

Repositorio Red 2

Gestión de

usuarios

Administrador

Traspaso automático


Sesión de Red

Sesión de Red

Figura 262. Perímetro de seguridad múltiple con

identificación única

Repositorio administración

Repositorio Red 1

Repositorio Red 2

Gestión de

usuarios

Administrador



Servidor de

acceso

Figura 263. Perímetro de seguridad único


La idea es bien simple. En un fichero XML se guardan los entornos contra los que hay que validarse y las condiciones y reglas de autentificación de cada uno de ellos. El programa cliente que necesita autentificarse lo hace contra el servicio que a partir del fichero XML se valida contra cada entorno. Para completar el cuadro, bastará añadir un programa para administrar los ficheros XML y una forma de hacerlos llegar a los puestos cliente.

7. Gestión del software. 7. 1. Distribución y control del software.

La gestión del software dentro de un entorno distribuido presenta características no presentes en un entono centralizado debido a la multiplicidad de copias:

Necesidad de controlar la versión cada nodo. Necesidad de distribuir nuevas versiones. Necesidad de sincronizar los cambios de los esquemas de BD con el cambio de versión de los programas que los tratan, o en su defecto, pensar en situaciones transitorias entre versiones y, por tanto, posible coexistencia de diferentes versiones en los nodos.

Necesidad, en algunos casos (a evitar) de arrancar versiones sincronizadas.

Administrar el software supone, pues marcar la estrategia a seguir en dos temas:

7.1.1. Localización de los programas. Los programas se sitúan en los servidores de programas. Recuerde aquí todo lo que se ha hablado con anterioridad de este tema con la dualidad: un solo servidor es fácil de administrar pero frágil ante caídas de sistema versus colocar la copia en el cliente, política segura pero difícil de administrar. Y, recuerde también, que el mejor sistema suele ser una solución híbrida: colocar en los clientes los programas imprescindibles para que el nodo siga activo aunque caiga el servidor y en los servidores de programas el resto.

7.1.2. Control y distribución de versiones. Controlar es, en principio, fácil. Solo hay que ser metódico en la asignación de versiones al software y en anotar la versión que tiene cada nodo, de programa y de esquema de base de datos. El problema es la distribución, de esquema de datos y de programas. Huya de la necesidad de arrancar sincronizadamente versiones; siempre el mejor pensar en un transitorio que permita evitar el colapso y la tensión que produce un arranque sincronizado. Piense por ejemplo que tiene una aplicación de ventas en una red de tiendas que envían los datos de facturas cada noche a la central. Si ha


de cambiar el formato de las facturas puede montar un transitorio muy fácil disponiendo de una tabla que diga que versión tiene cada tienda. Cuando se decida a arrancar el cambio, cambiará los programas de la central y colocará todos los nodos en la versión antigua. Los programas de recepción deberán estar preparados para recibir los dos formatos. Podrá iniciar entonces el cambio de los nodos con rapidez pero sin urgencias; bastará que cada vez que cambie un nodo, informe en la tabla que ya está en la nueva versión para que el programa de recepción conozca que los datos que le llegan están en el nuevo formato. En cualquier caso, haga el cambio tan rápido como pueda no sea que aparezca una tercera versión antes de que todos los nodos tengan ya la tercera. ¡Montar un transitorio con tres versiones ya es demasiado! Y cuando el cambio de versión no afecta a la BD todo es mucho más simple. Cuando el cambio de versión a de ser sincronizada no hay más remedio que introducir el concepto de fecha de vigencia, o día, y a veces hora, en que la nueva versión ha pasar a ser la activa. De esta forma la distribución de puede hacer antes del arranque. Recuerde que en este caso ha de montar un sistema de consistencia, un ticket bastará, para que cuando el nodo tenga la versión disponible avise al centro de distribución de forma que el administrador pueda saber con antelación si todos los nodos están preparados, y en caso contrario, resolver el problema en los que no lo estén antes de la entra en vigencia de la versión que se está distribuyendo. Cuando se alcance la fecha de vigencia, un programa automático, normalmente en el momento del arranque del nodo, verificará si hay una versión que arranca ese día y, en caso afirmativo, la pondrá en explotación. Conviene que avise al ticket de control de la central de forma que los administradores puedan comprobar que en todos los nodos se ha realizado el cambio, y en caso contrario, realizar acciones puntuales, y urgentes, para resolver el problema. Puede estudiarse, si la naturaleza del cambio lo permite, guardar la versión anterior y recuperarla en caso de error mientras se analiza que ha impedido la entrada en vigor de la nueva versión. En la gestión de cambios puede tener muchísimas ventajas la utilización de interfases basadas en XML ya que, al poder llevar incorporada la semántica de la interfase, facilitará la identificación de la versión que ha generado la interfase que se ha recibido.

7. 2. Distribución de replicas de ficheros fijos. Recordemos que entendemos por ficheros fijos los de parametrización y los ficheros de datos de volatilidad periódica como, por ejemplo, las tarifas de productos en restauración. La distribución de los ficheros de parametrización ha de ir ligada a la de los programas. Los ficheros de datos pueden gestionarse con políticas de replicación (ya vistas) o como programas.

7. 3. Herramientas disponibles. Hay dos opciones muy claras:


7.3.1. Utilizar paquetes.

7.3.2. Utilizar herramientas de DSM.

Integrándolas o no en una herramienta de nivel superior mediante un desarrollo específico. Así, el repositorio de administración puede utilizarse para catalogar las versiones, el servidor de correo puede utilizarse para la distribución, un cliente back-ground puede utilizarse pasar las versiones pendientes a actuales al alcanzar la fecha y la hora de vigencia como alternativa a una acción manual, etc.

Valore aquí la posibilidad de hacer software propio: puede salirle rentable.

8. Aportaciones del Diseño de Administración del Sistema al NOS+DSM. Como ya se ha dicho antes, el diseño de administración supone, en realidad, añadir nuevas opciones a los NOS y el DSM, muy especialmente al segundo. Se pueden hacer dos tipos de aportaciones:

Piezas para implementar recursos necesarios no presentes en el NOS+DSM. Piezas para facilitar la operación, basadas en encapsular recursos ya existentes de NOS+DSM.

De cualquier forma, es importante resaltar que esta etapa añade al sistema distribuido funciones que no afectan a la arquitectura del sistema distribuido sino a su administración.

9. Algunas ideas más.

A lo largo de estos dos últimos capítulos he ido presentando algunas ideas de como complementar el NOS+DSM para conseguir una mejor administración del sistema. Finalmente, y como despedida de los capítulos dedicados a la administración del sistema distribuido, déjeme relacionarle algunas más:

Un repositorio de administración puede montarse fácilmente en entorno ofimático con una BD tipo Access.

Un sistema de referenciar recursos que el NOS+DSM no incluya es siempre un archivo, un programa de mantenimiento y consulta de ese archivo y rutinas que hay que incluir dentro de los programas que utilizan esos recursos.

Un inventario de elementos puede llevarse dentro del repositorio de administración. Aquí, por favor, recuerde que el inventario no puede ser cuantitativo, ha de ser cualitativo y con los datos mínimos necesarios para administrar. Incluya los parámetros de garantía y mantenimiento.

La forma de montar todas las piezas construidas debe ser el esquema del Middleware real, de forma que a medida que los DSM avancen puedan sustituirse las piezas construidas por las funciones estándar.


Diseño de Consistencia

1. Objetivos del Diseño de Consistencia.

Como ya hemos comentado anteriormente,

El diseño de consistencia hace a las aplicaciones distribuidas robustas, es decir, resistentes a fallos y caídas. Dicho en otras palabras, hace las aplicaciones

fiables. Supone una etapa incremental de la especificiación inicial. El diseño de la consistencia viene motivado por las circunstancias excepcionales o los fallos de servicios en el sistema distribuido. Cuatro son los temas a estudiar dentro del análisis del diseño de la consistencia:

1. Gestión de errores. 2. Gestión de la concurrencia. 3. Semántica de servidores para la recuperación de las caídas. 4. Previsión de situaciones alternativas de trabajo cuando caen los servicios en

lo que denominaremos situación o trabajo en emergencia. Notas de marketing:

Sondee a su cliente antes de hablar análisis de consistencia, puede que no entienda que ha de prepararse por si un servicio cae (sobre todo si la competencia se lo esconde para construir una oferta más barata o por simple desconocimiento).

Si no es receptivo tendrá un dilema: Si lo incluye, lo pagará Vd. Si no lo hace, no quedará satisfecho profesionalmente.

Delante de sus clientes no utilice el término trabajo en emergencia si no otros del estilo de trabajo off line.

Voy a seguir utilizando el término emergencia para referirme a la situación de trabajo sin el/los servicios disponible/es ya que el me parece muy adaptado a la situación que define. Sin embargo, es un término políticamente incorrecto desde el punto de vista de marketing por lo que le recomiendo que delante de sus clientes use sinónimos del tipo trabajo off line.

Aunque voy a tratar cada uno de los puntos con detalle a lo largo de este capitulo, conviene tener de entrada una visión global de la estrategia a seguir. Cuando el cliente detecte un problema, ejecutará los procesos de recuperación de los servidores. Las funciones del cliente que los harán serán nuevas funciones, no detectadas, en principio, en el funcional ni el tecnológico hasta ese momento, y que serán independientes del flujo principal. Para gestionar el proceso de recuperación, se establecerán unas reglas de comportamiento (semántica de los servidores) para que cliente y servidor tengan claro como han de actuar.


Si el cliente no puede recuperar el servicio entrará en situación de emergencia, en la que deberá trabajar, si es necesario, sin el/los servicio/os que ha/han caído. Finalmente, será necesario un proceso, manual o automático, que detecte cuando el servicio se ha recuperado y un proceso de reconexión del cliente cuando esto ocurra. La importancia del análisis de consistencia dentro de un sistema distribuido será tanto mayor cuanto más sofisticada sea la arquitectura distribuida, más actualizaciones de datos realice el sistema y más caro sea tener el sistema parado.

Toda aplicación distribuida debería contemplar esta etapa del diseño. Por desgracia, o por desconocimiento del diseñador o por coste, finalmente no se implementa. ¡Grave error! Al final, tarde o temprano, pero inexorablemente, el usuario, y de rebote el

diseñador, tendrá la sensación de que el sistema le domina, la presión del usuario se hará angustiosa y la aplicación se habrá convertido en la peor de sus pesadillas. Si va corto de tiempo y dinero, el diseñador debe identificar como mínimo los problemas y pensar soluciones, aunque estas sean manuales de forma que, cuando aparezcan los problemas, se sepa que hacer y no se inicie la histeria a la que conduce la indeterminación. Recuerde que la mayor parte de los fracasos, que han traído una cierta mala fama a los sistemas distribuidos, se ha debido a la omisión de esta etapa del diseño. Finalmente, verá que en la mayoría de los casos solo hablo de comportamiento de servidores: recuerde que un agente necesita certeza absoluta de funcionamiento (full-tolerence). Y esta semántica de comportamiento tendrá una gestión muy concentra y definida dentro del análisis de consistencia. Por esa razón, Por se suele hablar siempre en este apartado como si los proveedores de servicios fueran siempre servidores.

2. ¿Por qué y como caen los servidores? Un servidor esta localizado en un nodo. Y para llegar a ese nodo, hay que utilizar un transportista que utiliza una vía de la plataforma de conectividad. Si el nodo donde está el servidor cae, por ejemplo por avería de la máquina, caerá el servicio. Si la vía utilizada por el transportista cae, el cliente tampoco tendrá acceso al servicio. Un servicio también puede dar “el efecto de que ha caído” por congestión cuando, puntualmente muchos clientes lo piden simultáneamente. Este error debe recuperarse siempre por el sistema distribuido, siempre que esté bien diseñado, obviamente. Observe dos hechos fundamentales:

Difícilmente el cliente puede saber si ha caído el nodo o el transportista. Y, además, normalmente no necesita saberlo. Su operativa de consistencia está ligada simplemente a la no obtención del servicio.


Cuando un servicio cae, normalmente caen también otros. Si lo que se ha estropeado es nodo, caerán todos los servicios localizados en el nodo. Si cae una vía del transportista, caen todos los servicios que utilicen la misma vía.

Si el programa sabe que varios servicios están ligados al mismo nodo o vía de transporte (por ejemplo, un servidor de datos), podrá poner en emergencia todos los servicios relacionados. Esto permitirá minimizar el tiempo para pasar el sistema de trabajo normal a emergencia. Observe que si los servidores van cayendo de uno en uno cada cual hará su propio proceso de recuperación y la conmutación emergencia puede alargarse sin ninguna necesidad. Finalmente, observe que si cae un servidor sin caer todo el resto la causa será probablemente de congestión y/o diseño o programación, y no de caída real.

3. La consistencia por plataforma redundante. Una forma de conseguir que la plataforma no caiga, y que por tanto minimizar, y hasta suprimir, el diseño de la consistencia por software, es trabajar con una plataforma redundante en que, en caso de la caída de un nodo o una línea, se pueda trabajar con una alternativa. Esta posibilidad, atractiva desde el punto de vista teórico, choca directamente con el criterio económico de la ingeniería: es cara, muy cara si quiere ser completa. Solo puede justificarse en unos pocos y escogidos sistemas. Para conseguir consistencia por plataforma redundante hay que prever como mínimo:

• Clusters en los servidores. • Puestos clientes alternativos. Este suele ser el menor de los problemas debido a la

proliferación de PC’s. • Disco redundante. Un sistema SAN puede ser apropiado. • Vías alternativas en la plataforma de conectividad. Vital. Aquí es también importante huir de

las soluciones, hardware y software, en estrella y potenciar las arquitecturas en red. • Sistemas que garanticen el suministro de energía eléctrica el 100% del tiempo de

funcionamiento. Todo ellos comporta, además de mayor rigidez en la adaptabilidad, un mayor coste de inversión, funcionamiento (consumo y mantenimiento) y administración de la plataforma. Este puede ser el gran problema, la gran trampa: puede ocurrir que el software de consistencia proporcione una solución más barata y flexible. Obviamente, si esta es la solución escogida, aquí acaba el capitulo. Si la consistencia es por software, en lo que resta encontrará diversas, y espero interesantes, propuestas. 4. Ciclo del Análisis de Consistencia.


Las etapas que un diseño de consistencia debe contemplar se resumen en el cuadro de la figura, en el cual, además se han secuenciado en el tiempo. El sistema trabaja la inmensa mayoría del tiempo normalmente (sino es así, apaga y vámonos). Si en algún momento del trabajo se produce un error en la utilización de algún

servicio, lo primero que el programa debe hacer es analizar el error. Una primera criba se realiza separando los errores lógicos (no existe cliente, no hay stock, etc.) de los físicos, normalmente representados por la no recepción, total o parcial, de un servicio solicitado. Lo segundo que hay que hacer es intentar recuperar el error. Si la recuperación acaba con éxito, el trabajo se reiniciará sin mayor problema. Lo máximo que notará el usuario es que esa petición ha tardado más que las otras. No le recomiendo sacar ningún tipo de aviso de que el sistema está haciendo un reintento. El usuario no sacará ninguna información útil de ese aviso y por contra le transmitirá desconfianza y desprestigio injusto sobre una aplicación tan bien diseñada que es capaz de recuperar los errores sin que el trabajo se resienta. Si finalmente el error no se puede recuperar, se habrá de avisar al usuario e iniciar, si tiene sentido, un proceso para pasar el sistema a emergencia, es decir a trabajar sin la disponibilidad del servicio que ha caído. De hecho es más que probable que cuando cae un servicio, caigan también otros muchos a los que se llega por el mismo transportista. Es recomendable, si el sistema distribuido lo permite, lanzar un aviso al centro de administración del cual dependa el servicio. No debe basarse nada en esta notificación ya que será muy habitual que la caída haya producido también la desconexión del transportista que conecta con el CASD. Si la caída necesita de la acción del CASD, el programa debe prever que si el mensaje no se puede enviar automáticamente, se avise al operador de que avise telefónicamente al CASD. Una vez iniciado el trabajo en emergencia, el sistema trabajará en esta situación hasta que, automática o manualmente, se detecte la recuperación del sistema. Durante el trabajo en emergencia deberá generarse un log con el trabajo realizado. Este log ha de permitir la recuperación de la información generada en emergencia cuando el sistema se recupere. En ese momento, se iniciará un proceso de recuperación, que puede incluir el proceso o la transmisión del log (otra opción es hacerlo más tarde) y el sistema volverá a trabajar normalmente. En el resto del capítulo se analizan cada una de estas etapas.

Análisisdel Error

Intentos de recuperación

Inicio de la Situación de Emergencia

No recuperable

Trabajo en Emergencia

TrabajoNormal

Error

Recuperación de la Situación

Normal

Recuperación del sistema

Log

CASD

Aviso

Error físico

Figura 264. Ciclo de trabajo del Análisis de Consistencia.


5. Gestión de errores en un sistema distribuido. La gestión de errores en un entorno distribuido presenta características claramente diferenciadas de las de un entorno centralizado: plataformas diferentes, dispersión geográfica, dispersión horaria, perfiles de usuarios muy diferentes, etc. Al final, y de hecho, la gestión de errores es más compleja y crítica. Muchos de los criterios citados aquí se han presentado ampliamente al hablar del servidor de correo. Si no los recuerda bien, por favor, reléalos. Los errores se deberán informar, como criterio que debe omitirse en contadas y muy justificadas ocasiones, en los clientes, que son los puntos donde están los usuarios. Cuando existe una delegación de servicio entre servidores, o cualquier otra arquitectura de comunicación entre servidores, el error debe arrastrarse hacia arriba y trasladarlo hasta el cliente. Cuando el error sea recibido por un agente deberá hacerse cargo de él y notificarlo a su CASD. Recuerde que un agente es desatendido y que por tanto no es válida la opción de mostrar un mensaje por pantalla: es más que probable que nadie lo vea. La gestión de errores se basa en dos parámetros: el número de reintentos a hacer y el tiempo entre ellos (tiempo de sleep). Este último parámetro es fundamental, es el as escondido en la manga. Si la caída del servicio se ha debido a una sobrecarga de clientes o transportista, si los reintentos se hacen rápidamente, ocuparán un tiempo mínimo y no esperaran a que la punta pase, produciendo una caída del sistema que nunca debería producirse. Recuerde, una vez más, lo que sobre los parámetros de gestión de errores hablamos en el servidor de correo.

Conviene que los parámetros sean personificables y deben colocarse en la ficha de entorno del servidor, del agente o del cliente y los administradores deben tener posibilidad de modificarlos. El programa los tomará al principio, parametrización estática, o cuando ha de usarlos, parametrización dinámica. Una vez detectado que

hay un error físico, el programa entrará en un ciclo de gestión del error que se muestra en la figura y que puede acabar con la recuperación del error y la continuación del trabajo normal, o con la imposibilidad de hacerlo y la entrada en emergencia de ese servicio.

Reintentos=NTiempo_sleep=M

Error

Reintentos del servicio

Ficha del servidor o del

cliente

N,M

Trabajo Normal

Recuperación

Reintentos

Reintentos - 1

= 0 Entrar en emergencia

Sleep M segundos

> 0

Error físico

Figura 265. Ciclo de la gestión de errores.


Como ha de ser el reintento depende de la semántica del servidor. Más adelante trataremos este tema. Pero recuerde que, como criterio general, el reintento ha de ser controlado evitando ejecuciones no controladas. Por ejemplo, si actualiza un stock, el servidor ejecuta el servicio pero se pierde la respuesta, si el cliente reintenta sin más y la semántica de comportamiento cliente / servidor no está bien definida, puede llegarse a rebajarse dos veces el mismo stock. Más adelante hablaremos de semántica, y en ese momento recuerde que la gestión de errores debe tenerla en cuenta. 5. 1. Elementos para el análisis de los errores.

Para analizar los errores en una aplicación distribuida hay que tipificar los errores, asignarles un destinatario y un nivel de gravedad. Y hacerlos llegar al centro de control del sistema distribuido:

En caliente para el centro de errores de control de administración. En frío a través de las actividades de Monitoring para análisis.

Vamos a exponer, recordar de hecho, algunos puntos de interés sobre cada tema.

5.1.1. Tipos de errores.

Conviene diferenciar entre tres tipos de errores:


5.1.1.A. Errores lógicos. O aquellos, como se ha dicho antes, que se generan por la lógica de aplicación y no por la caída de un servicio. El servidor los devolverá codificados al cliente dentro de la respuesta y el cliente los gestionará.

5.1.1.B. Errores físicos. Generados por caídas, cogestión del transportista y concurrencia de muchos clientes en un servicio. Ha de haber un proceso de recuperación que se implementa en el cliente o el agente. El servidor ha de colaborar intentando, en lo posible, que la concurrencia no produzca un error físico, cosa que no es ninguna trivialidad, razón por la cual la gestión del error se suele dejar para el cliente. Cuando el error no se recupera, se ha de notificar al usuario, y si está previsto, iniciar el proceso de emergencia.

5.1.1.C. Errores de administración. Del tipo falta papel en una impresora. Hay que hacerlo llegar hasta el responsable sea el mismo usuario o un administrador. Si la comunicación es asíncrona desacoplada, la gestión la realizará el servidor o cliente back-ground afectado. Si no lo es, el programa esperará normalmente a la resolución y continuará normalmente.

5.1.2. Destinatario. El error se ha de notificar al usuario responsable de resolverlo, que en un entorno distribuido, puede estar alejado del punto en que se ha detectado que a su vez puede estar alejado del punto donde se ha producido. Cuando la notificación hay que enviarla a un punto diferente del usuario que al que se ha notificado, es conveniente normalizar los centros de gestión de errores. Y es recomendable que estos centros coincidan con la organización de administración. Recordemos que esta organización es jerárquica y que puede localizarse en usuarios avanzados, en el CASD local o el CASD central. Un buen lugar donde enviar los errores en el cuadro de control de explotación del sistema distribuido.

5.1.3. Nivel de gravedad.


5.1.3.A. Crítico. La notificación del error debe interrumpir el trabajo del responsable de gestionarlo.

5.1.3.B. Urgente. Se ha de notificar visualmente al responsable pero no hay que interrumpir su trabajo. Conviene que si pasado un tiempo no ha sido resuelto el error cambie de urgente a critico para que el responsable no se olvide de gestionarlo.

5.1.3.C. Aviso. Los errores se guardan en una lista para que el responsable los consulte cuando le interese. Conviene también en este caso que pasado un tiempo el error pase de aviso a urgente y a crítico si no es resuelto.

6. Análisis histórico de los errores. Para una buena gestión del sistema distribuido es muy útil realizar estudios de la frecuencia y localización de los errores. Pueden analizarse, y resolverse, factores de gran interés:

Localizar puntos donde las caídas son demasiado frecuentes y donde puede haber una avería.

Puntos de servicio que motivan caídas y que pueden ser resueltas por time-out.

Detección de puntos desprotegidos delante de errores de operativa y que pueden protegerse por software

Puntos de alta concurrencia, etc. Para hacerlo solo es necesario dar persistencia y caducidad al sistema de almacenar los errores con las herramientas de Monitoring y registrarlo en el sistema de Análisis de la Gestión de la administración del sistema distribuido.

7. Implementación de la gestión de errores. Si en la instalación hay sistema de Monitoring, o en su ausencia servidor de correo o el cartero, para distribuir los errores se utilizarán estos componentes. Si no los hay puede utilizarse el mail. Otra opción es utilizar la plataforma de mensajes del Middleware encapsulándola en una pieza. Una vez los errores han llegado a destino han de almacenarse, consultarse, gestionarse y analizarse. Si Vd. lector revisa lo que hemos dicho de errores, verá que su gestión es fácilmente implementable en piezas de reutilización prácticamente total. Una buena implementación de una gestión de errores empieza por una normalización en que raras veces se piensa cuando se inicia una aplicación distribuida: los errores han de ser codificados.


Es una vuelta al pasado. Cuando sólo existían los grandes Mainframe, recuerdo que cuando el sistema generaba un error, lo hacia con un código de referencia y un mensaje muy críptico. Con el mensaje de error había que consultar unos manuales gigantescos donde, tras un entrenamiento apropiado, se encontraba el error perfectamente documentado: donde y cuando se producía y como se resolvía y/o evitaba. Los programas de aplicación copiaban esta filosofía, y como había tiempo, los equipos de desarrollo continuaban esta inercia en sus aplicaciones. Con la llegada de los sistemas abiertos, y la facilidad con que se podía avisar por pantalla del error, llevó a la eliminación de los manuales de errores y por tanto a la codificación de estos. Este fue, a mi juicio, un paso atrás. La gestión del error se limitó a dar un mensaje en el momento y lugar donde se detectaba, no cuando y donde se producía. Y como el nivel de documentación bajó, se dejo de documentar. Y apareció, además, el efecto torre de babel: el mismo error se informaba con mensajes diferentes que hacían creer a los usuarios que eran diferentes. Existe un caso muy clásico, dar aviso que no existe una referencia, por ejemplo de cliente; mensajes del tipo: NO EXISTE CÓDIGO DE CLIENTE, CLIENTE NO DISPONIBLE, ERROR EN EL ACCESO A CLIENTES, hasta ERROR DE E/S, etc., se utilizaban para avisar de este error. Y la llegada de los sistemas distribuidos fue el remate final. La distribución del desarrollo entre diferentes equipos de trabajo y la extensión de los lugares de origen acabó de agravar el problema. Soy un firme defensor de que los errores deben estar codificados e informados en un repositorio de errores, donde a demás de un código, cada error debe tener su origen, su destino, su nivel de gravedad, etc. Y desde aquí, hacer la gestión de errores multidioma es muy simple. Las piezas necesarias para gestionar este repositorio serán:

Un sistema de mantenimiento del repositorio de tipificación de errores. Un modulo de gestión de errores desde los programas de aplicaciones con las prestaciones que hemos visto desde aquí. En particular habrá un método para, dado un código de error, localizar su descripción y tratamiento. Puede existir también un método que permita al operador obtener información “on line” del error para evitarle consultar manuales.

Un modulo de administración que permita cambiar sobre la marcha los parámetros dinámicos: gravedad, destinatario, etc.

Un sistema rápido de consulta “on line”. Cuando un programador deba dar un error, consultará el repositorio: si el error ya existe lo usará identificándolo por su referencia. Si no existe, lo añadirá. Codificar nuevos errores puede dejarse a libertad del programador u obligar a pasar por un filtro unificador. Cada organización elegirá la solución que más le convenga.

Un transportista de mensajes de error del que ya se ha hablado. Un sistema de archivar los errores producidos. Un módulo para de análisis de los errores archivados. Dispondrá de las opciones necesarias de consulta y notificación a los responsables de los errores de que ya se ha hablado. Si se le da persistencia permitirá el análisis histórico


Siempre que pueda, aproveche al máximo la plataforma de análisis de la gestión de la administración del sistema integrando la gestión de errores en ella. Una recomendación final. Recordarle que dentro del capitulo dedicado al servidor de correo se aportan criterios sobre la gestión de errores que no voy a repetir aquí. Por favor, si no los recuerda, consúltelos.

8. Gestión de la concurrencia, el paralelismo y la recuperación.

La necesidad de controlar la concurrencia surge del hecho de que diversos clientes accedan de forma simultánea al mismo servicio produciendo una congestión puntual reflejada en una deterioración del tiempo de respuesta que puede llegar a producir en el cliente la notificación errónea de caída del servicio. El tema suele ser importante en los servicios de datos, especialmente de consulta. La necesidad de controlar el paralelismo surge del hecho de que más de un servidor atienda el mismo servicio, solución habitual para el tema de la congestión en la concurrencia. Recuerde que hay dos formas de hacerlo: con más de una instancia del servidor y con un servidor multihilo. En cualquier caso, el problema es aquí evitar que los diferentes servidores o hilos colisionen entre sí. Estos temas deben ser contemplados en el diseño del sistema distribuido, en particular, dentro del diseño de la arquitectura distribuida. Es un error pensar que el esfuerzo importante se ha de hacer dentro del análisis de consistencia. La necesidad de la recuperación surge de la posibilidad de que alguno de los servicios que se ejecutan fallen por causes lógicas, físicas, de concurrencia o de paralelismo. La concurrencia ha de ser contemplada en el diseño en dos sentidos. En primer lugar diseñando la arquitectura distribuida en función de la ocupación prevista para cada servicio. En segundo lugar proporcionando las herramientas de administración necesaria para gestionarla correctamente. Concurrencia y recuperación están ligadas por el hecho de que la congestión pueda inducir al cliente a la caída. La recuperación de la congestión necesitará normalmente sólo de la gestión de errores; difícilmente una congestión resistirá una buena gestión de recuperación de errores. Si la gestión de errores no llega a recuperarla, se producirá la caída en emergencia y el inicio de la situación de trabajo de ese estado. Tampoco aquí habrá problemas para seguir si la situación de emergencia está bien resuelta. En cualquier caso, los administradores deberán ajustar los parámetros de la gestión de errores (número de reintentos y espacio entre ellos) para conseguir evitar la caída. Si aún así hay ocasiones en que el sistema cae, debe dirigir el problema a los diseñadores que deberán mejorar la arquitectura del sistema o los recursos de hardware para resolver el origen del problema. Por favor, no abuse del aumento de potencia de la plataforma: si realmente hay un problema de congestión, originado en un fallo de diseño o en un aumento de las necesidades del sistema distribuido, se ha demostrado que la solución del hardware es siempre provisional y que al final, el problema siempre acaba reapareciendo.


El paralelismo es un tema totalmente de desarrollo y una aplicación bien diseñada y bien implementada no debería presentar problemas de este tipo en fase de explotación. Recuerde, finalmente, que los problemas del paralelismo suelen agruparse alrededor de dos grandes ejes:

Sincronización de las instancias y/o de los hilos. Acceso simultáneo a la cola y recursos compartidos por las instancias o hilos.

Por último, remarcar que el problema de la concurrencia es especialmente importante en las aplicaciones cliente/servidor basadas en Internet. Aunque aquí, la naturaleza transaccional de la WEB facilita en gran manera la solución. Se cualquier forma, los diseñadores de las aplicaciones Web deben ser especialmente sensibles en este tema.

9. Tipificación del comportamiento del servidor: semántica de servidores. Con los agentes la comunicación es desacoplada y que el servicio se interrumpa temporalmente, siempre que se pueda certificar la certeza de la anotación en curso (implementación de la “full tolerante”), no supone un problema especialmente grave. Por el contrario, los servidores, que son especializados, encapsulan los servicios y caen, son el punto fundamental sobre el que debe girar el análisis de la consistencia ya que provocan “el cuelgue” de los clientes que los han solicitado. Por eso, si el análisis de consistencia gira a su alrededor, será interesante tipificar el comportamiento de un servidor en caso de caída de una conexión entre un servidor y un cliente. La clasificación del comportamiento de un servidor según sea su compromiso de servicio en caso de caída se conoce como semántica del servidor. Así se habla de las siguientes semánticas de comportamiento de un servidor: 9. 1. Servidor “may be” (quizás).

Es un servidor sin garantía de servicio. Su comportamiento es inseguro. El cliente no puede recuperar nada porque no tiene información de que ha pasado. Observe que la única forma de asegurar el servicio es consultar algún parámetro que permita asegurar que ha acabado bien; por ejemplo, si es una modificación, consultar que el valor está cambiado en destino. Si el dato es poco volátil, puede ser una solución, pero se imagina esto en una gestión de stocks distribuida.... Y en cualquier caso el sistema es altamente ineficaz. No hay que decir, pues, que es un comportamiento no admisible en un servicio. Pero, ¡no se fíe! ya que desgraciadamente, aunque no se lo digan, puede encontrar servicios de Middleware que se comporten así.

9. 2. Servidor “at least once” (al menos una vez). Son servidores de ejecución segura. Esta semántica garantiza que, si el servidor ha sido llamado, el servicio se ha ejecutado. Observe que con esta


semántica, si el servicio se ha pedido más de una vez, por ejemplo por una recuperación de cliente ante una caída aparente del servicio, este se ha ejecutado dos veces; de ahí lo de ejecución segura. El mecanismo de recuperación del cliente envía la petición de servicio tantas veces como tenga parametrizado en su gestión de errores hasta conseguir respuesta, y si finalmente no se recuperará caerá en emergencia. Observe que para que un servidor pueda tener esta semántica de comportamiento, el servicio a de ser idempotente.

9. 3. Servidor “at most once” (como máximo una vez). Ejecución segura y sólo una vez. El servidor es capaz de reconocer que el servicio ya de ha pedido antes, no lo procesa pero lanza la respuesta como si lo hubiera hecho. De ahí, que la ejecución sea segura y sólo una vez. Garantiza que el servicio no ha quedado a medias y se ha completado siempre y que si hay una nueva petición del mismo servicio, se recupera el estado anterior sin ejecutar de nuevo la petición y se transmite al cliente, que de está forma da el servicio por acabado correctamente. De esta forma, el cliente para recuperar el servicio, sólo tiene que reintentarlo hasta conseguir respuesta. Es el comportamiento deseable y recomendado en un servidor de aplicación. Invertir en conseguirlo, es abaratar “a tope” los costes de explotación y administración.

9. 4. Servidor “exactly once” (exactamente una vez). Fiabilidad total (“full tolerance”). El cliente no necesita controlar la ejecución del servicio. Es un nivel de comportamiento exigible en una comunicación asíncrona desacoplada. Es, naturalmente el servidor ideal ya que garantiza la ejecución única en cualquier circunstancia. Es un comportamiento que, obviamente, no es fácil de implementar y que difícilmente encontrará en un servicio de Middleware.

9. 5. Implementación de semántica en servicios montados sobre colas. Existe una forma muy fiable de implementar un comportamiento “at most once” y “full tolerence” en servidores que se comunican con sus clientes por una cola, situación por otra parte muy habitual. Consiste en trabajar correctamente con la referencia de cliente (que proporciona éste) y la referencia de anotación (que proporciona la cola) en las anotaciones de petición de servicio. Antes de seguir, si no recuerda este tema repáselo en los apartados dedicados a las colas en el capítulo dedicado a los componentes operacionales; en particular, recuerde el apartado dedicado a la Dinámica de las Referencias. Recuerde también que un diálogo cliente/servidor es un protocolo de dos mensajes, uno de petición y otro de respuesta. Para que la consistencia sea posible, dentro de cada mensaje deberá de tener dos pasos.


En la petición: envío del cliente y notificación del servicio de que la anotación se ha recibido.

En la respuesta: envío del servidor y notificación del cliente de que se ha recibido.

La implementación de una semántica “at most one” o “full tolerante” deberá seguir los siguientes pasos.

9.5.1. Atributos de la comunicación.

Incluir en todas las comunicaciones las referencias de cliente y anotación el mecanismo de confirmación. Y en las comunicaciones cola/servidor la referencia del servidor que atiende el servicio.

9.5.2. Anotación del servicio por el cliente:

El cliente aportará la referencia de cliente y en la cola devolverá en la confirmación a referencia de anotación. El cliente sabrá que el mensaje se ha anotado cuando reciba su referencia de cliente junto a una de anotación. A partir de aquí todas las comunicaciones incluirán ambas referencias. Si la cola recibe otra petición de anotación con la misma referencia de cliente sobre grabará la anterior si no está en ejecución (por si ha habido algún cambio) y devolverá la referencia de anotación que ya tenía asignada a esa petición. Puede incluirse en la respuesta un aviso del estado de tratamiento de la anotación para mejor control del cliente.

9.5.3. Comunicación cola/servidor. Cuando el servidor pida una anotación pendiente, la cola anotará la referencia del servidor. Si el servidor no puede anotar la respuesta en la cola, cuando vuelva a pedir una nueva anotación, la cola ha de detectar que ese servidor tiene una en proceso le ha de proporcionar la misma referencia. El servidor detectará que ya la ha gestionado por coincidir las dos referencias y volverá a anotar la respuesta sin hacer otra vez el servicio. Como el servidor tendrá más de un cliente, deberá crear una tabla dinámica de últimos servicios, con un número máximo de clientes y un número máximo de llamadas recibidas por cliente, donde anotará las últimas referencias de cliente y anotación gestionadas. Cuando el servidor arranque, esta tabla se vaciará; cada vez que un nuevo cliente realice la primera petición, se le dará de alta en la tabla con el máximo de servicios que hay que almacenar; dentro de la zona de cada cliente, la gestión de sus anotaciones será de cola circular.

9.5.4. Respuesta de la cola al cliente. Si el cliente pierde la respuesta, la cola se la reenviará sin ningún problema. Cuando la cola reciba la confirmación del cliente de que ha

ColaCliente PeticiónEnvío

Confirmación

ColaCliente RespuestaEnvío

Confirmación

ServidorRecogida

Devolución

Figura 266. Mecanismo de comunicación C/S

con confirmación


recibido la respuesta ya estará en condiciones de poder borrar la anotación en el momento que tenga planificado. Si lo que se pierde en la confirmación del cliente de que ha recibido la respuesta, la anotación de la respuesta quedará en la cola como pendiente de servir y deberá ser eliminada por caducidad. Conviene estudiar las respuestas pendientes de recoger para detectar puntos débiles en el sistema.

9. 6. Servidores de datos y comportamiento “at most one”. Dentro del diseño de la arquitectura de servidores he defendido que las funciones de modificación y consulta se separen en servidores separados. Utilizando este criterio, los servicios de consulta son idempotentes y la semántica “al menos una vez” ya les va bien. Igual pasa en los servicios de mantenimiento idempotentes. La recuperación puede centrarse en los de mantenimiento no idempotentes (lo habitual) en los que hay que garantizar comportamiento “al most one”. Para dar este comportamiento a los servidores de datos, es muy útil disponer de dos mecanismos adicionales en los servidores de las BD.:

Recuperación dinámica hacia atrás del estado del sistema tal cual estaba antes de la petición del servicio, pocas veces utilizado si existe un control como el anterior.

Rearraque de emergencia de forma que, cuando el servidor vuelva a arrancar después de la caída de su nodo, sea capaz de saber que le ha quedado una transacción pendiente y acabarla o retrocederla.

Para conseguir estas funciones, las BD suelen dar los recursos necesarios a través del Middleware que las envuelve. Existen cuatro mecanismos clásicos que pueden utilizarse para garantizar la integridad de los datos modificados:

9.6.1. Protocolo de dos llamadas. El protocolo de tiene los siguientes pasos:

El cliente lanza una petición de servicio asíncrona y recibe la confirmación de la aceptación de la petición por el servidor. Cuando el servidor acaba deja notificación al cliente de que tiene la respuesta preparada y queda a la espera de la segunda llamada. El cliente pregunta si tiene la respuesta disponible. El cliente pide al servidor la respuesta en la segunda llamada.

Aunque el mecanismo es clásico de datos, obviamente puede utilizarse para cualquier servidor. Observe de cualquier forma que esta forma de implementar la consistencia de llamada por la dinámica de referencias.


9.6.2. Mecanismo de “Call-back” (llamada al origen). Es una solución alternativa en la cual el servidor llama al cliente para enviarle la respuesta cuando la tiene. El servidor necesita saber la localización del cliente que le ha hecho la llamada. No es un sistema que yo le recomiende ya que estropea del criterio básico que establece que la petición la inicia el cliente de forma transparente.

9.6.3. Mecanismo de Confirmación por Lectura. Solo en situaciones muy críticas (problemas de eficiencia) y con flujos de modificación bajos podría recurrirse a verificar con una lectura posterior la modificación. Puede mejorarse la eficacia confirmando por sumarización.

9.6.4. Mecanismos de control de la replicación. Repáselos en el capítulo correspondiente.

9. 7. Arrancadas alternativas.

Una opción válida para garantizar el funcionamiento es arrancar el servidor en otro nodo cuando el que está trabajando cae y desviarle en tráfico pendiente en ese momento. Esta solución suele montarse con una arquitectura de distribución. Un servidor de distribución se localiza en el mismo nodo que el cliente. Todas las peticiones del cliente se dirigen a este servidor, que obviamente nada más caerá si cae el nodo y por tanto también el servidor. El servidor de distribución redirige la llamada al servidor especializado. En caso de caída, el servidor de distribución puede pasar la llamada a otro nodo, arrancando el servidor si es necesario. Observe que según el volumen de la respuesta habrá que complementar la solución con una arquitectura de filtro y que el servidor debe saber si la petición que se recibe es una caída en otra instancia y, si es necesario, verificar que, si el servicio no es idempotente, el otro servidor no hubiera finalizado ya el servicio antes de caer. Es importante conocer también si la caída del servicio ha sido por fallo del nodo o por caída del transportista. La técnica puede ser utilizada también en caso de congestión, arrancando otras instancias del servidor que cooperen en el trabajo. No tengo que recordarle que los servidores han de ser concurrentes y con arquitectura multicliente-multiservidor. La técnica es de un alto coste de programación.

10. Utilización de arquitecturas Proxy.

Recuerde que una de las formas de diseñar consistencia incluyéndola en el propio servicio es la utilización de arquitecturas de Representante o Proxy.


Si no la recuerda, repase este tipo de arquitectura de servicios en el capitulo dedicado a ese tema.

11. El problema de los huérfanos.

Hasta ahora hemos visto la caída siempre desde la óptica del cliente: el que cae es el servidor. Pero, por favor, pensemos un poco desde la perspectiva del sufrido servidor. Si el cliente cae, el servidor puede encontrarse con una respuesta que no tiene quien la recoja. El proceso servidor se ha quedado huérfano. Este problema se referencia por eso como el problema de los huérfanos. Si la comunicación es asíncrona el problema prácticamente no existe ya que el servidor habrá colocado la respuesta en la cola de comunicación. El cliente podrá consultarla si hay reintento. Si es síncrona, el servidor la ignorará o guardará, junto a la referencia del cliente, por si hay reintento. Se escogerá una opción u otra según la semántica del servidor. Si el modo de comunicación, por ejemplo colas, guarda respuestas huérfanas, periódicamente hay que preveer un proceso de eliminación. Mucho cuidado en comunicaciones síncronas, sobre todo si son piezas de Middleware comprado, ya que un servidor huérfano puede quedarse clavado esperando la disponibilidad del cliente para enviarle su respuesta. El efecto de esta situación sería una parada drástica del servicio en todo el sistema distribuido. Y observe también que un sistema síncrono con full tolerance y con control de huérfanos se parece descaradamente a un servicio asíncrono. Finalmente hacer notar que el problema de los huérfanos es especialmente importante en Internet, donde el cliente es desconocido del servidor y puede ser cancelado, por acción de operador o por time-out, en cualquier momento.

12. Arrancada del servidor desde el cliente. Si el entorno y la aplicación lo permiten, parte del proceso de recuperación del servicio puede ser arrancar el servidor desde el cliente por si por la causa que fuera el programa servidor ha “desaparecido” Si se utiliza este recurso debe asegurarse como mínimo que:

El cliente tiene forma de conocer donde se debe arrancar el servicio. El servidor debe auto controlar en su arrancada que:

No hay otra instancia arrancada si no es el multinstancia. Coordinarse con las ya arrancadas si lo es.

13. Gestión de la situación de emergencia.


Como ha se dicho anteriormente, si el servicio no se recupera, habrá que decidir que hay que hacer. Si el sistema lo permite, puede simplemente esperarse a que el servicio se recupere; un caso típico es una aplicación de consulta con crítica cuando cae el servidor de datos. Si el sistema de información ha de seguir trabajando (un caso típico es una oficina de ventas), habrá que poner el sistema en emergencia y definir una estrategia para seguir trabajando. Pueden utilizarse dos estrategias:

Cancelar la operativa de los servidores y hacer que el sistema deje de trabajar con ese servicio. Por ejemplo si cae un servidor de crédito de clientes, puede decidirse que en la situación de emergencia no se verifique el crédito.

Sustituir el servicio del servidor por otro de emergencia, y encolar los servicios no realizados para recuperarlos cuando el servidor vuelva a estar disponible. Si la estrategia es recuperar, han de diseñarse funciones paralelas que se han de responsabilizar de hacerlo cuando el servidor vuelva a estar disponible. En función de las características del servicio, el cliente saldrá de emergencia antes o después de procesar las peticiones pendientes.

Los criterios para la gestión de la situación de emergencia son organizativos (que se puede hacer, donde y como) y económicos (coste, directo e indirecto, de no dar servicio). 13. 1. Componentes de la gestión de la situación de emergencia.

El diseño de los procesos de trabajo en emergencia puede atacarse de una forma genérica. Si se hace así, se detecta rápidamente la existencia de componentes reutilizables. A continuación le presento estos componentes dejando para el final un esquema de funcionamiento conjunto.

13.1.1. Una agrupación de trabajo de servidores. Es decir, agrupar todos los servidores unidos por afinidad. La agrupación puede ser:

Estrictamente física: Todos los servidores que atacan la misma base de datos. Agrupar servidores por el uso seguro de un recurso físico obligado; por ejemplo, todos los servidores que atacan un nodo remoto por la misma vía física.

Basada en la localización. Por ejemplo, todos los servidores localizados en la misma máquina servidora. Funcional. Todos los agentes, la comunicación con los cuales es desacoplada pueden formar una agrupación ya que la recuperación es por reintento después del tiempo de “sleep” y el log de trabajos pendientes es la misma cola de espera o el mecanismo equivalente que se utilice para pasarle el trabajo.

Como observará, los dos primeros criterios son muy claros, pero el último está condicionando fuertemente la administración del sistema ya que un servidor, que puede parecer muy claro que estará en un nodo


junto a otros, puede, con el transcurso del tiempo y por las circunstancias de consumo y evolución tecnológica, pasar a estar en otro nodo. Le aconsejo, pues, que utilice a fondo los dos primeros pero huya del tercero.

13.1.2. Semáforo de disponibilidad. Cuando en servidor cae en emergencia, debe conocer que en la siguiente llamada no debe intentar usar el servicio ya que si lo hace volverá a repetir todo el proceso de recuperación y la respuesta del sistema se ralentizará innecesariamente. Para controlar si el servicio está en uso o no, asocie un semáforo por cada grupo de servidores lógico. Si el servidor no pertenece a ningún grupo, el semáforo estará implementado en su interior. La activación del servicio puede recibirse por un evento o preguntarse periódicamente a través de un hilo. Note que en este caso el cliente siempre llama al servicio que es el que le devuelve si esta en emergencia o no. Si es de un grupo, el semáforo deberá ser un recurso compartido por el grupo, estático (fichero) o dinámico (servidor independiente). El servidor, cuando detecte que el servicio ha caído pondrá el semáforo en rojo. Y antes de cada llamada lo consultará. Por esta razón, el semáforo deberá montarse de forma que su respuesta sea muy eficiente, lo que prima mucho su implementación estática sobre la dinámica. Es conveniente utilizar semáforos de tres posiciones ya que el amarillo puede utilizarse para funciones de control durante la recuperación. Hablaremos más adelante de está posibilidad. Observe que en este caso, la consulta de situación de emergencia se puede hacer tanto desde el cliente como desde el servidor lo que permite decidir quien gestiona la situación de emergencia, el cliente o el servidor. Si la alternativa es utilizar otro servicio prime la opción del servidor. Si la alternativa es hacer otros procesos para cubrir la situación de emergencia, es mejor responsabilizar al cliente.

13.1.3. El vigilante. Vigilará si el servicio sigue caído o no. Deberá activarse cuando el servicio haya caído, y periódicamente, con el tiempo que tenga parametrizado, hará comprobaciones de sí el servicio está recuperado o no. Cuando detecte la recuperación colocará el semáforo en amarillo o verde según convenga a la funcionalidad de la aplicación. Para comprobar si el servicio se ha recuperado puede utilizarse: • Una petición especializada del tipo petición de conexión.


• Una petición de servicio particular e inocuo para el sistema. Por ejemplo, en una base de datos, acceder a una entidad con una referencia que no exista; si el servidor ya está disponible responderá con un no existe suficiente para saber que ya está activo.

El vigilante debe disponer de un mecanismo para lanzar programas. Se utilizará para lanzar los procesos de recuperación. El proceso de recuperación está ligado al semáforo y deberá ser, obviamente, parametrizable. En principio, se asocia un vigilante a cada semáforo. Sin embargo, si hay muchos semáforos puede haber un problema de eficacia y es mejor que un solo vigilante controle más de un semáforo. Un vigilante se implementa como un cliente back-ground y es un firme candidato a ser empaquetado en una pieza reutilizable. Cuando lo diseñe y programe piense siempre en darle esa posibilidad. Los semáforos a controlar deben ser también parametrizables. En particular, el vigilante debe conocer la localización del servidor. Observe que vigilante y semáforos deben compartir la información del recurso que controlan. Esa razón hace recomendable que compartan el fichero de parametrización.

13.1.4. Log’s para registrar el trabajo en emergencia. La implementación siempre es por fichero, sobre la BD o simplemente secuencial. Obviamente, la presencia de log's sólo es necesaria si el sistema ha de recuperar sobre el servidor el trabajo en emergencia, situación, por otra parte, muy normal. La implementación de log’s se encapsula en una pieza genérica que se especializa en rutinas específicas para cada log.

13. 2. Ciclo de trabajo en emergencia. Los semáforos de disponibilidad y los vigilantes permiten controlar la situación de emergencia con el ciclo genérico de trabajo en emergencia se muestra en la figura. En él se detalla el funcionamiento dinámico conjunto de los componentes anteriores.


La figura es bastante clara y no necesita, una vez conocidas las funciones de cada componente, de demasiadas aclaraciones adicionales. Cuando el cliente está trabajando normalmente y se produce la caída de un servicio, realizará el proceso de recuperación de errores. Si es sistema no se recupera se iniciará el proceso de funcionamiento en emergencia que colocará el semáforo en rojo, iniciará el log y si no lo está ya, arrancará también el vigilante correspondiente. A partir de este momento cliente y vigilante funcionarán simultáneamente. Como el cliente consultará el semáforo antes de utilizar el servicio, cuando detecte que está en verde, volverá a la situación normal o lanzará el proceso de recuperación según este último este integrado en él o no. Cuando el vigilante detecte la subida del servicio:

Colocará el semáforo en verde o ámbar. Iniciará, si así está diseñado, el proceso de recuperación. Si no tiene ningún semáforo más a controlar, se auto suspenderá.

El estado de ámbar se utilizará para indicar a los programas cliente que el servicio ya está activo pero que el proceso de recuperación de log no se ha acabado todavía. Cada servidor hará uso de está información como convenga a su trabajo. Finalmente, cuando el proceso de recuperación del log acabe, pondrá el semáforo en verde pasando la totalidad del sistema a trabajar normalmente. Desde los clientes existen dos formas básicas de gestionar el estado de emergencia:

Coger el estado del semáforo antes de cada acceso al servidor.

Log

Proceso Vigilancia

Checking de Recuperación

SleepInicio Proceso

de Recuperación

Error

Recuperación

Recuperación

Gestionar Log

Recuperar Situación normal

Error Trabajo Cliente

En Emergencia

Trabajo Normal

Recuperación?No Si

Inicio Situación Emergencia

Activar Logy Status

Arrancar Proceso de Vigilancia de Recuperación

PonerRojo

PonerAmbar

PonerVerde

Verde?

Figura 267. Ciclo de trabajo en emergencia.


Que cada cliente lleve un semáforo interno y que el vigilante avise de la recuperación a todos los servidores afectados por el evento.

14. Anotación del diseño de consistencia sobre los diagramas de flujo en

MAFDRA.

El análisis de consistencia supone la incorporación de nuevos proceso y / o la modificación de otros ya existentes para recoger las nueva funciones necesarias para implementarlo. La metodología MAFDRA que utilizamos propone describirlos de la misma forma y los mismos elementos, que ya se han presentado, que el resto del sistema. Y como es muy útil diferenciar en diagramas de flujo ampliados que procesos son funcionales y cuales de consistencia le propongo utilizar para la descripción de los flujos de consistencia del criterio de control de esos diagramas: utilizar el trazo discontinuo para diferenciarlos.

15. Metodología del Análisis de Consistencia. Podemos agrupar todo lo expuesto en este capítulo en una metodología cuya secuencia se ilustra en la siguiente figura:

Diseño de ConsistenciaDiseño de la Arquitectura Distribuida

Semántica de Servidores

Definición y AnálisisDiseño de la

Implementación


Análisis de los Errores

IdentificaciónGestión

Administración

Diseño de Administración

Diseño TecnológicoDiseñar Procesos

Preparar el Plan de Integración

Análisis Situación de EmergenciaPolítica General

Análisis de la CaídaAnálisis del Trabajo

en EmergenciaAnálisis Vigilancia

Análisis Recuperación

Negociación

Figura 269. Metodología del Diseño de la Consistencia

Proceso

Datos Almacén de Datos

Dirección del Flujo

Dirección de Transformación

Figura 268. Extensión de los

diagramas de flujo para recoger el

análisis de consistencia.


Partiendo del Diseño de la Arquitectura Distribuida, le propongo marcar cuatro etapas bien diferenciadas:

1. Definir la Semántica de los Servidores, encaminada a definir el comportamiento de recuperación de cada uno de los servidores identificados en la etapa anterior.

2. Análisis de los Errores, encaminada a identificar y normalizar los errores de caída del sistema.

3. Análisis de la Situación de Emergencia, pensada para definir como se quiere trabajar en esta situación, y, una vez analizado, definir los procesos de Caída, Trabajo, Vigilancia y Recuperación.

4. Diseño Tecnológico del Análisis de la Consistencia, con una primera aproximación al Plan de Integración.

El proceso continuará con el Diseño de la Administración del Sistema Distribuido. A continuación se detallan con mayor precisión cada una de estas etapas. 15. 1. Definir la Semántica de Comportamiento de los Servidores.

Para cada uno de los servidores identificados en el sistema se realizarán dos etapas:

15.1.1. Definición y Análisis. Se analizará la semántica necesaria en el comportamiento del servidor según su función. Se hará uso la semántica presentada anteriormente. Es a mi juicio la etapa clave de toda la consistencia.

15.1.2. Diseño de la Implementación. Se buscará la solución informática para implementar la semántica y se dejará documentada para su implementación.

15. 2. Análisis de los errores.

15.2.1. Identificación.

Se revisarán todos los errores generados en la relación entre clientes y servidores. Los errores se referenciarán, se separaran en lógicos y físicos, se les asignará prioridad y destinatario funcional. Poner especial cuidado en que dentro de las arquitecturas de servidores los errores se arrastren correctamente hacia arriba.

15.2.2. Gestión. La gestión se establecerá con todas las ideas reflejadas con anterioridad, decidiendo las soluciones tecnológicas necesarias.

15.2.3. Administración. Finalmente, se establecerán los criterios de administración, paso que conviene adelantar y que equivale al “map to reality” de otras etapas del


diseño. Conviene hacerlo para verificar que se disponen de los recursos de plataforma para conseguir la gestión deseada. En particular se decidirán aquí número y espacio entre los reintentos y que usuarios serán los destinatarios físicos de los errores.

15. 3. Análisis de la Situación de Emergencia. Si utilizamos, parte o totalmente, el ciclo de trabajo en emergencia propuesto habrá que marcar hasta cinco etapas.

15.3.1. Definir la Política General. Pensar de forma genérica una opción alternativa a la caída del servicio. Se utilizará como opción por defecto para definir el trabajo en emergencia de los clientes que lo usan. Es bueno adelantar aquí la decisión de los grupos de vigilancia ya que los servidores de cada grupo tienen políticas de emergencia ligadas. Repasar, después, cada conexión de servicio proveyendo la situación de trabajo en emergencia. Ver si la opción alternativa prevista para el servidor sirve para la caída en ese cliente. Si no es así definir una de nueva e incluirla en la documentación del servidor.

15.3.2. Negociación. Los diseñadores informáticos deberán presentar a los responsables de las aplicaciones las soluciones adoptadas y obtener su validación. El objetivo es triple:

Que el usuario valore el alcance de cada decisión. Validar todo lo previsto. Obtener su compromiso

15.3.3. Análisis de la Caída en Emergencia.

Poco habrá que hacer aquí ya que las funciones suelen estar, como ya se ha visto, bien definidas.

15.3.4. Análisis del Trabajo en Emergencia. Habrá que ver si los cambios introducidos por la situación de emergencia no vulneran ninguna funcionalidad.

15.3.5. Análisis de la Vigilancia. Habrá que confirmar definitivamente los grupos de vigilancia y personalizar a los vigilantes.

15.3.6. Análisis de la Recuperación. Estudiar la viabilidad de la recuperación prevista y ajustar el funcionamiento de los clientes durante ese periodo.


15. 4. Diseño Tecnológico.

15.4.1. Diseño de los Procesos. Diseñar los nuevos procesos y/o incluir en los ya existentes, las nuevas funciones de consistencia (gestión de errores, caída en emergencia, trabajo en emergencia y recuperación). Actualizar la documentación, principalmente los diagramas de flujo

15.4.2. Preparar el Plan de Integración. Es un buen momento para iniciar la preparación del Plan de Integración, revisando cada caída e incluyendo que se ha de probar en la recuperación de errores y la situación de emergencia.

16. El proceso paralelo como técnica de consistencia. En servicios críticos puede diseñarse que la ejecución de la misma petición del servicio se realice por más de una instancia del servicio ejecutándose en localizaciones físicamente distintas. Todas las ejecuciones se coordinan al principio y al final para asegurar que el servicio solo se ejecuta una vez para cada petición del cliente. Si una de la ejecuciones falla las otras acabaran y el servicio será de semántica de ejecución segura. Esta técnica permitiría un diseño muy seguro a costa de dificultar la programación y la administración y usar más recursos de la infraestructura. 17. Diseño de Consistencia de la aplicación de Viajes Aéreos y Hoteles.

Vamos a aplicar está metodología a la aplicación de viajes aéreos que estamos diseñado como ejemplo en paralelo a la presentación teórica. 17. 1. Semántica de servidores.

17.1.1. Leer Datos Cliente.

Semántica: Al menos una vez (At least one). Implementación: Bastará asegurarse que la confirmación de anotación

en la cola y de captación por el servidor funciona correctamente.

17.1.2. Leer Datos Cliente en la Central.

Semántica: Al menos una vez (At least once). Implementación: Bastará asegurarse que la confirmación de anotación

en la cola y de captación por el servidor funciona correctamente.

17.1.3. Alta Cliente en la Central.

Semántica: Como máximo una vez (At most once). Implementación: Si al dar el alta servidor encuentra que el cliente ya

existe, supondrá ya se ha ejecutado con anterioridad. No se prevé ninguna verificación más debido a que se supone que un mismo cliente no puede estar al mismo


tiempo en dos oficinas. Si se quisiera seguridad adicional podría montarse un control chequeando las referencias de cliente y anotación.

17.1.4. Actualizar Datos de Venta de Clientes en la Central.

Semántica: Como máximo una vez (At most once). Implementación: Se montará un control dentro del servidor con tabla de

referencias de los últimos servicios.

17.1.5. Actualización de Datos de la Compañía aérea. Semántica: Como máximo una vez (At most once). Implementación: El servidor es implementado por la Compañía aérea.

Si no nos inspira confianza y disponemos de la posibilidad, podemos confirmar por lectura de la reserva realizada.

17.1.6. Consulta de Hoteles.

Semántica: Al menos una vez (At least one). Implementación: El servicio es implementado por el Servicio WEB.

17.1.7. Actualizar Datos de Hoteles. Semántica: Como máximo una vez (At most once). Implementación: El servicio es implementado por el Servicio WEB.

17.1.8. Impresión de la Reserva para el cliente. Semántica: Quizás (May be). Implementación: Como la impresión se hace sobre una impresora en

cada puesto de venta, confirmación de impresión es visual. Se deberá montar una pregunta para confirmar la impresión y, en caso negativo, reintentar.

17.1.9. Servidor de Correo.

Semántica: Exactamente una vez (Exacty once), ya que la

comunicación en asíncrona desacoplada. Implementación: Entre cliente y servidor de correo se deberá asegurar

la certeza de la anotación. Entre las dos partes del servidor de correo (origen y destino) los bloques de ficheros se intercalarán con número de secuencia que garantiza que no se pierde ningún bloque (que se incluirá en la respuesta) y un check por software que garantiza la calidad interna de cada bloque. Al final de la transmisión se incluirá un check engloba y el número de paquetes transmitidos para garantizar que la información es completa. La parte del servidor de corre de destino deberá garantizar que la anotación en la cola de destino es segura.


17.1.10. Servidor de Cola. Semántica: Exactamente una vez (Exacty once), ya que la es la

pieza fundamental del diálogo. Implementación: Bastará normalmente con el diálogo de intercambio de

referencias. 17. 2. Análisis de errores.

17.2.1. Identificación.

Para poder identificar los errores hay que llegar a una profundidad de diseño e implementación que queda fuera de abasto de este ejemplo centrado en la parte de arquitectura del sistema del tecnológico.

17.2.2. Gestión. Se montará totalmente con el esquema general propuesto en este documento.

17.2.3. Administración. Los errores se tratarán dentro de la tienda, que actuará como CASD local. Se montará una persistencia de tres meses para los log’s de error. No se prevé un paquete específico de gestión de errores; en caso de que se necesite algo en esta línea, se utilizarán los recursos de Office, en particular Excel y Access.

17. 3. Diseño de la Situación de Emergencia.

El trabajo en emergencia no afectará a los procesos de estadísticas, que esperaran en caso de caída a la recuperación del servicio.

17.3.1. Definición de la política general. Se analizamos las conexiones cliente/servidor de la localización propuesta, observamos la presencia de cuatro grupos de vigilancia muy diferenciados:

17.3.1.A. Servidores localizados en la Central. Si el cliente se ha de ir a buscar a la Central y el servicio ha caído, se supondrá que es alta. Posteriormente el proceso de recuperación habrá de confirmarlo: Si realmente es un alta, se hará en la Central. Si ya existía, no se hará nada.

Si el importe de la venta es menor de una cantidad (parametrizable) se supondrá que tiene crédito y la venta se realizará. Si es superior, se pedirá confirmación por teléfono. La aplicación deberá pedir esa confirmación al usuario que registra la venta. Si el teléfono también ha caído, de supondrá en todos los casos que el cliente tiene crédito.


Habrá que guardar las ventas y enviarlas a la Central cuando se recupere, o en caso de que la caída dure mucho tiempo, se volcarán a CD y se enviarán por mensajero. Como medida adicional de seguridad, las ventas se guardarán también en el PC del puesto de venta para que en caso de error no recuperable en el servidor, poderlas recuperar de allí. En este caso se utilizará el CD o un mail según que el servidor de la tienda esté en funcionamiento o no.

17.3.1.B. Compañía Aérea. Si cae la WEB de la compañía aérea, la gestión se hará sobre el catálogo de programación de vuelos impreso. Cuando caiga la conexión con la Compañía Aérea, la confirmación se hará telefónicamente. Si el teléfono no funciona, la venta no se confirmará en ese momento. Si el cliente esta de acuerdo, en cuanto sea posible, se confirmará y avisándose al cliente del éxito o fracaso de la gestión. En caso de que haya plazas, el cliente deberá confirmar que sigue interesado con el viaje enviando una aceptación por mail o fax.

17.3.1.C. Datos Hoteles. Cuando caiga los servicios de Servicio WEB se actuará de igual forma que en el caso de la compañía aérea. Por esa razón, en el resto del capítulo se tratará únicamente el caso de la compañía aérea.

17.3.1.D. Servidores localizados en el servidor de la tienda. Si caen esos servidores, la venta se hará “a mano”, montándose un programa de “data entry” para registrarlo en el puesto cliente y gestionar la venta más adelante. Se habrán de registrar todos los datos del cliente si el que registra la venta no tiene la certeza absoluta de que ese cliente ya es de la empresa. Note que habrá de hacerse el circuito de emergencia de la Compañía Aérea.

17.3.1.E. Servidores localizados en el puesto cliente. El procesador de textos está localizado en la máquina cliente. Solo puede caer por avería de la máquina. Así, si cae también lo hará el programa de venta por lo que no se prevé ninguna situación de emergencia. Si cae la impresora del puesto cliente, se dirigirán los impresos hacia la impresora de otro puesto utilizando los recursos de la red. De cualquier forma, se preverá la existencia de preimpresos por si


finalmente no queda ninguna impresora disponible o por si ha caído la red junto con la avería de la impresora.

17.3.2. Análisis de la caída en emergencia. En la caída en emergencia:

Se habrá de iniciar el log de trabajo y/o la confirmación telefónica de reserva y/o crédito o el proceso de venta manual según corresponda. Si lo que ha caída es la central o la Compañía Aérea, habrá que arrancar el proceso de vigilancia.

17.3.3. Análisis del trabajo en emergencia.

No hay nada más a aportar ya que la política general vale para todos los casos y no vulnera ninguna funcionalidad.

17.3.4. Análisis de la vigilancia. El control de la situación de emergencia se montará con la operativa de vigilante propuesta anteriormente. Se utilizarán dos semáforos:

Uno para el grupo de servidores localizados en la Central. Otro para el servidor de la Compañía Aérea.

La recuperación del servidor de la tienda se controlará manualmente. La implementación de los semáforos será sobre archivos sobre el servidor de la tienda y localizados en un subdirectorio del directorio del vigilante. Un único vigilante controlará los dos semáforos. Los semáforos y el vigilante se localizarán en el servidor de la tienda.

17.3.5. Análisis de la recuperación. Los clientes pueden rearrancar sin espera a la recuperación del log. Esta recuperación se hará de forma automática con un cliente back-ground.

17. 4. Diseño Tecnológico.

17.4.1. Diseño de los procesos.


Empecemos por refinar el vigilante. Aplicando un primer nivel de diseño, y una vez arrancado, su funcionamiento se muestra en la figura. El tiempo de espera será parametrizable dentro de la ficha de configuración del vigilante y diferenciará valores diferentes para la Central y la Compañía Aérea. Obviamente, cuando los dos semáforos están en verde el vigilante se auto parará. Realizando un refinamiento del proceso de Verificación de Conexión con la Central, se obtiene el diagrama de flujo de la figura. Para verificar si hay conexión se utilizará el servicio de consulta de clientes realizando una petición para un cliente inexistente y esperando una respuesta con el error lógico “no existe”. Finalmente, en la figura de la izquierda se muestra el refinamiento de la Verificación de la Conexión con la Compañía Aérea. Como petición de prueba se hará servir en este caso una reserva de un vuelo que no existe.

Verificar Conexión

conla Central

Tiempo de espera

Verificar Conexión

con la Compañía

Aérea

Sleep

Figura 270. Diagrama de flujo inicial del

Vigilante

ConexiónCentral

EstadoConexiónCentral

Rojo

ComprobarConexiónCentral

Respuesta

PonerSemáforoen Verde


RCola

Clientes

Figura 271. Refinamiento del proceso para Verificar la

Conexión con la Central

ConexiónCompañía

Aérea

EstadoConexiónC.Aérea

Rojo

ComprobarConexiónC.Aérea

Respuesta

PonerSemáforoen Verde

ProcesoCompañía

AéreaRRPC

Figura 272. Refinamiento del proceso para Verificar la

Conexión con la Compañía Aérea.


Observe que, como el vigilante controla los dos semáforos ha de preguntar si el grupo está caído antes de reintentar. Observe también el acceso con bloqueo al semáforo ya que es un recurso compartido montado sobre un fichero en disco. Analicemos ahora como afecta el proceso de vigilancia a los servidores. En la figura se muestra la adaptación del servidor para Leer Datos Cliente de la Central. De la arquitectura completa de la parte de la Central se ha representado únicamente el servidor para Leer Datos de Cliente en la Central. Si incluimos este proceso en el refinamiento del servidor llegamos al diagrama de flujo de la figura inferior.

PedirclienteCentral

Accedera cliente

local

TomarDatos

Cliente

Clientes local

Colocaren

respuesta



No existe cliente en CentralEl cliente existe

en la Central

Respuesta

Clientes central

Leer DatosCliente enla Central

ColaClientes

Petición: Código Cliente

Cuentas Clientes

R TomarDatos

Cliente

TomarCrédito

R

Hay que tomar Crédito

Emergencia? No

Si

Poneren Rojo

Caída del Servidor

ConexiónCentral

Figura 274. Consistencia del servidor de leer datos de cliente en la tienda

El proceso de para actualizar datos en la central y en la compañía aérea quedará modificado de la siguiente forma:

Clientes local

LeerDatos

Cliente

Clientes central

RLeer DatosCliente enla Central

Poner en Rojo

Caída del servicio

ConexiónCentral

ColaClientes

Figura 273. Consistencia del Servidor para Leer Datos Cliente


Observe la aparición de una nueva cola sobre disco con las actualizaciones pendientes de realizar y de la copia en local (maquina cliente) de las ventas. Aparece un proceso completamente nuevo para recuperar la información de la central después de la recuperación o por CD si ésta no se produce a tiempo. El diagrama de flujo de este nuevo proceso se muestra en la siguiente figura:

Anotaren la

Central

ActualizarDatos

Clientesen la Central

R

PedirAlta en la

Central

Alta de Clientes enla CentralR

Accedera ClienteCentral

Leer DatosClientes enla CentralR

Cola de Actualizaciones Pendientes

ya existe

no existe

GrabarVentas

Pendientea Floppy

Copia Ventas Local

GrabarVentas de

una jornadaa Floppy

EliminaciónHistórica

Periodo a Eliminar

Figura 276. Nuevo proceso de Recuperación de la Situación de Emergencia

Petición Cliente

Actualizareservac.Aérea

Anotaren la

Central

No hay plazas

ActualizarDatos

ClientesEn Central

R


RPCProceso

CompañíaAéreaR

Poner noConexióna C.AéreaCaída

ConexiónCompañía

AéreaConsultaTelefónica

EmergenciaCompañía

Aérea?

EmergenciaCentral? Poner no

Conexióncon Central

ConexiónCentral

EncolarPetición

Cola de Actualizaciones Pendientes

ColaClientes

Anotaren la

Central

Copia en Local de Ventas

Figura 275. Diagrama de Consistencia del proceso para Actualizar Ventas.


Este proceso de recuperación se montará como un cliente back-ground con posibilidad de arrancarse manualmente o de forma automática desde el vigilante. Observe también la aparición del proceso de selección en CD de las ventas pendientes y de recuperación de ventas de una jornada desde cada puesto de trabajo. Obviamente, en este último caso, habrá que sacar un CD de cada puesto de trabajo. Si la copia se envía por mail se utilizará el paquete de correo electrónico de la instalación. Evidentemente la aplicación de la Central debe tener un proceso back-ground que lea del CD y llame al servidor de actualización.

Finalmente, debe preverse un proceso de eliminación histórica de las copias de ventas. Este proceso se puede integrar en un cliente back-ground que se pase de forma automática cada vez que se arranque el puesto cliente parametrizado con la fecha del día como tope superior y que elimine todo lo anterior.

El proceso de Data-Entry

permitirá simplemente imprimir la reserva. Se guardará una copia de la reserva para, junto con la relación de ventas realizadas, hacer la venta posteriormente, y con los programas habituales sin tener el cliente delante, cuando el servidor de la

tienda se recupere.

17.4.2. Preparar el Plan de Integración. El plan de integración deberá contener como mímico las siguientes pruebas de consistencia:

Desconexión de la línea de telefónica con la compañía aérea. Volverla a conectar antes del último reintento de recuperación: comprobar que el proceso recupera correctamente.

Esperar a que se inicie el proceso de emergencia. Comprobar que se arranca el vigilante y que el proceso de emergencia (la petición de telefónica funciona).

Reconectar la línea: comprobar que el vigilante lo detecta, notifica correctamente y se auto detiene.

Desconexión de la comunicación con la Central y actuar de la misma forma que en el apartado anterior. Probar con la situación de

EntradaManual

Relación de Ventas

Albarán

ImpresiónAlbarán

Cliente

Albarán

ProcesoNormal

de Venta

Cliente

Figura 277. Proceso de Data Entry para la Venta

Manual


emergencia con clientes nuevos y ya existentes. Probar y comprobar el proceso de recuperación de forma exhaustiva. Probar conjuntamente las dos situaciones de emergencia. Comprobar que los CD’s de recuperación se procesan correctamente en la Central. Probar la caída del servidor del Local y probar el programa de data-entry. Comprobar que con la copia de la reserva puede recuperar el proceso a posteriori.

En fin, no intento ser aquí muy exhaustivo ya que la profundidad del análisis del ejemplo tampoco lo permite. Baste esta pequeña lista para que Vd. lector se haga una idea del contenido de que deberá dotar al plan de integración.

18. Diseño de Administración de la aplicación de Viajes Aéreos. El diseño de administración de un ejemplo docente es de muy difícil realización sobre el papel ya que necesita enfrentarse a una situación organizativa y operativa real. Pero entrar en describir una situación real no es nada que mejore substancialmente la calidad didáctica de una metodología de diseño como la que estamos desarrollando. Por tanto, me voy a limitar aquí a apuntar un simple boceto.

El Centro de Administración Central (CASD) y el Centro de Dirección (CDSD) están en la Central.

El Centro de Administración Local es la oficina de venta. La Gestión remota se hará mediante un programa especializado. Además de las métricas de gestión de redes, se dispondrán, para medir, valorar y mejorar el rendimiento del sistema, de todas las trazas de funcionamiento de los servidores, que podrán activarse a voluntad del CASD. El diseñador deberá tenerlo en cuenta cuando diseñe e implemente los servidores.

El soporte de usuario se dará jerarquizado con la estructura de administración. Se prevé montar ayudas en los programas para minimizarlo.

El servicio de Hot-Line está subcontratado. La gestión de copias de seguridad será de back-up departamental. Dentro de cada tienda todas las impresoras estarán disponibles para todo el mundo. La administración de impresoras se realizará con los recursos de red.

Se montará un servidor de programas en el servido de la tienda. Se replicarán los programas necesarios para cubrir la situación de emergencia en cada puesto de venta.

Para la gestión de versiones se utilizará un paquete especializado. Se instalará un firewall en el servidor del local y antivirus en todas las máquinas con mantenimiento de versión centrada en el servidor del local.


Integración funcional del Cliente.

1. Introducción. En la metodología que estamos desarrollando, una vez separados los servidores, el resto de funciones deben implementarse en los clientes. Recuerde que deberá integrar en la parte como una parte más de la funcionalidad:

El análisis de consistencia. La parte delegada a los clientes del análisis de administración.

De las diferentes formas de hacerlo trata este capítulo.

2. La implementación del cliente. El desarrollo de esta parte de una aplicación distribuida es, en el fondo, convencional. Se trata de integrar las funciones no contempladas como servicio en un programa cliente que utiliza los servicios a través de llamadas con las reglas pactadas. Le recomiendo que utilice también aquí la metodología puzzle identificando el máximo número de piezas. Ya hemos hablado de las ventajas de todo tipo que ello comporta. En particular, déjeme recordarle la más importante: la facilidad para cambiar decisiones para separar funciones servidoras y clientes, que ya sean por error o por evolución del sistema deben reconsiderarse.

Los pasos a seguir son: 2. 1. Decidir del modelo de Integración Funcional.

Se deberá definir el modelo de integración funcional que conviene al proceso que se está programado. Este es, en el fondo, el punto fundamental de este capítulo y es por eso que se tratará con detenimiento más adelante.

2. 2. Crear la lógica de presentación y/o los flujos de los procesos. Evidentemente la lógica de presentación sólo deberá crearse si el modelo de integración escogido la necesita. Ya sabemos que aunque el modelo de integración no sea propiamente guiado por el cliente a través de una GUI, en general, existe siempre. Por esa razón,

Completar Diseño de los clientes

Integración funcional

Lógica de presentacióny/o flujos de procesos

Lógicas de proceso y datos

Especificación piezas cliente

Ampliar el cuadrocontrol administración

Diseñar el cuadro de control del negocio

Figura 278. Integración del

Cliente


cuando no hay GUI’s lo normal es que haya que definir los flujos de proceso. Esto es lo que ocurre en batch y workflow, por ejemplo.

2. 3. Crear las lógicas de proceso y de datos del cliente. Es aquí donde se incluirán las llamadas a los servicios y donde deberá brillar su dominio de la metodología puzzle.

2. 4. Especificación de las piezas cliente. Habrá que especificar y catalogar las piezas creadas durante la implementación del cliente. En realidad, convengamos que esto debería hacerse en el punto anterior. Pero, permítame, remarcarlo como fase independiente por la importancia que estas alturas ya ha visto que le doy a todo lo que huela a reutilización.

2. 5. Modificar y ampliar el cuadro de control del sistema distribuido. Deberán incluir en zona del cuadro todos los procesos de negocio obtenidos en esta parte del diseño. En particular, es frecuente que como parte de la integración hayan salido nuevos tickets de control que habrá que supervisar.

2. 6. Diseñar el cuadro de mandos del negocio. La idea es paralela al cuadro de mandos de administración pero trasladado al negocio. Se trata de resumir en una sola presentación el estado de negocio. Aunque los formatos y contenidos dependen de cada negocio, se incluirán con toda probabilidad ítems del tipo:

Comparación actualizada de previsiones contra la realidad. Un ejemplo clásico es la comparación entre previsiones de venta y grado de cumplimiento a nivel de jornada de trabajo y de periodo, normalmente el mes, de evaluación.

Alertas y avisos de negocio: costes de personal disparados, precios de compra por encima de lo esperado, roturas de stock críticas, etc.

Se primarán al máximo las presentaciones gráficas. La granularidad de la información dependerá del punto de acceso. Así, por ejemplo, será habitual una estructura jerárquica en la cual el cuadro de mandos de negocio tenga una vista para cada centro de coste, por ejemplo una tienda de venta, y que en la central haya dos vistas ortogonales:

La de dirección, que integra todo el negocio. La de cada departamento especializado, en la que se presentan solo los indicadores de los que es responsable.

Desde estos niveles integradores se podrá navegar hasta la información de cada centro de coste. Observe que la implementación visual y tecnológica es la misma que en el cuadro de mandos de administración pero en la esfera de los objetivos de


negocio por lo que lo que todo lo que hemos dicho, y diremos en el ejemplo de la tercera parte, es válido para los dos entornos y no hace falta duplicar explicaciones para incluir ambas casuísticas.

3. Perfiles de usuario e integración.

Cuatro líneas para recordarle que el modelo de integración elegido habrá de tener en cuenta los perfiles de los usuarios identificados. Recuerde, que como ya se ha dicho anteriormente, el modelo de integración deberá tener en cuenta:

Los derechos de cada usuario según el perfil de los grupos de usuarios a los que pertenecen.

Las opciones específicas de los programas codificados por perfiles específicos a los que el usuario puede tener o no derecho.

Sea como sea, recuerde que los perfiles marcan derechos y restricciones para cada usuario que el modelo de integración deberá reflejar y respetar. Dispondrá, o deberá crear, de una serie de servicios de seguridad que deberá utilizar como cualquier otro servicio para gestionar la seguridad.

4. Modelos de Integración. Existen diversos modelos de integrar el cliente:

Modelos en los que la iniciativa la lleva el usuario: Con una interfície convencional.

Integración no gráfica, prácticamente obsoleta fuera de los procesos en línea.

Integración gráfica. Integración GUI. Integración WEB.

Portal. Clientes ligeros. Transaccional.

Integraciones basadas en Internet. Clientes back-ground. Trabajos Batch Integración por estereotipos. Integración en Workflow.

Trabajo cooperativo. Flujo de procesos.

Integración por publicación / suscripción. Integración por objetos distribuidos

Pura Como plataforma de distribución.

A continuación se desarrollan cada uno de los modelos. Notará que prácticamente de todos ya se ha hablado directa o indirectamente antes de llegar aquí. Como siempre, no voy a repetir cosas. En el resto del capítulo voy a relacionarlos


remarcando los aspectos más importantes y le dejo como práctica añadir lo de que cada uno hemos hablado a lo largo del texto.

5. Modelos en los cuales la iniciativa la lleva el usuario con una interfície convencional. Son aquellos en los cuales la secuencia de los acontecimientos la marca el usuario escogiendo los procesos que quiere ejecutar entre las posibilidades que le ofrece el programa en cada momento. Es la forma más habitual de integración en la cual el usuario escoge que quiere hacer entre el menú de opciones que le ofrece el sistema. A pesar de ser el modelo más habitual de integración de la parte cliente, es, curiosamente, el más complicado ya que el programa debe cerrar en todo momento al usuario caminos no válidos en función de la evolución de la secuencia de ejecución seguida por el usuario y filtrar sus actuaciones en cada momento. Además debería dar opción a recuperar posibles acciones erróneas, en particular, si son muy “destructivas”. Eso es lo que debe pasar. Otra cosa es lo que realmente pasa: las integraciones cliente se hacen rápidamente y mal; ni se cierran caminos, ni se dan opciones de recuperación y, a duras penas, se filtran errores. Estamos, pues, ante modelos de integración guiados por la lógica de presentación. He eludido hasta aquí esta palabra para que Vd., amigo lector, no confunda este modelo de integración con una interfície gráfica, la forma prácticamente universal con la cual se integra hoy día este modelo. Sin embargo, no confunda la forma con el fondo. Puede resolver este modelo con una integración no gráfica, tipo diálogo por líneas. Imagine aquí una pantalla, de una máquina herramienta por ejemplo, trabajando línea a línea, en la cual las opciones del menú se sacan por líneas y el operador escoge a través de la consola. De cualquier forma, es evidente que hoy día todo son interfícies gráficas y que esta es la opción a utilizar siempre con excepción de muy contadísimas ocasiones, Una de las excepciones que todavía se encuentra son los procesos industriales en los cuales, por razón de la dureza del puesto de trabajo, hay elementos de diálogo con visores no gráficos de pocas líneas y caracteres. Dentro de la integración gráfica hay dos posibilidades, la integración con el estándar Windows y la de Internet. Esta segunda tiene la gran ventaja de la estandarización con independencia de la plataforma, el gran sueño de todos los informáticos. Son modelos en general de clientes pesados. Recuerde que las características de la interdice gráfica cambian según el ámbito a que va dirigida en uno de los subbloques:

Administración. Gestión. Explotación.


Consulte, sino lo recuerda el capitulo de la primera parte dedicado a la administración donde hablamos de este tema. Finalmente acuérdese de diferenciar en el diseño las GUI’s de:

Navegación, donde prima de uso del ratón. Registro de datos, donde prima la gestión automática de la posición del campo actual y el uso de los tabuladores para moverse entre campos vecinos.

La integración gráfica la representaremos como se muestra en la figura.

6. Integración grafica multivista.

Surge de la necesidad de adaptar la vista las características del dispositivo que la pide i/o del perfil del usuario tipo del dispositivo. El componente grafico se monta en dos partes:

• Obtención de los datos de la vista. • Adaptación al dispositivo o perfil de usuario.

Hoy día existen estándares para conocer cual es el tipo de dispositivo del terminal que hace la petición. El perfil tipo del usuario puede estar parametrizado en función de la referencia del terminal que hace la petición.

7. Portal.

La integración por portal es la idea que ha popularizado la WEB y que da entrada a toda la información y procesos de negocio disponibles desde un único punto. La integración en Portal la representaremos como se muestra en la figura. En la página de despliegue existirá, además de toda la información que se desea dejar pública, recursos para autentificar usuarios, internos o

externos, y permitirles introducirse hasta el nivel y contenidos a los que tengan derechos. No hay que decir que exige un alto esfuerzo en controlar los derechos y deberes de cada usuario en todas las funciones afectadas a partir de su autentificación. El ámbito de los portales puede ser:

Generalista o temático según se acceda a información general o de un tema o área específica

Vertical u horizontal según se gestionen datos de una única fuente o de varias


la integración GUI


la integración por Portal


Evidentemente, las dos dimensiones son ortogonales. Observe que en cualquier caso la idea central es la misma: un punto de entrada único. Existen de hecho tres tipos de portales que se corresponden históricamente con su evolución. Los tres tipos están activos y muchas veces coinciden en un único portal. 7. 1. Portales de contenidos.

El portal abre acceso a repositorios pasivos de información o a publicaciones activas.

7. 2. Portales de aplicación. El portal se utiliza como punto de entrada a servidores de aplicaciones ya existentes, adaptando las funciones visibles al usuario identificado pero trabajando las aplicaciones de forma independiente. Si es necesaria coordinación se realiza por interfases automáticas u operadas directamente por los operadores.

7. 3. Portales de proceso. El portal guía al usuario través de diferentes escenarios y le proporciona la información y la ayuda para tomar decisiones. Todas las aplicaciones se ven como una sola. El portal se puede convertir en un punto de acceso intuitivo a la información y los procesos de la totalidad de la empresa, colaboradores, proveedores y clientes. Observe la importancia que en este tipo de portales tienen los problemas derivados de la dispersión de criterios de autentificación de usuarios. Existen dos posibilidades de enfocar el portal:

Por roles, que es la habitual. Por dispositivos.

Aquí es fundamental separar la lógica de presentación de las de proceso y datos que deben crearse o evolucionar a servicios. Este objetivo debe ser una prerrequisito en las nuevas aplicaciones y obligar a reingeniería en las heredades. En muchas ocasiones los portalesw de proceso conllevan problemas de Upsizing que complican la integración. Son portales con necesidad de consistencia, tanto de recuperación de errores como de trabajo en emergencia, con las limitaciones que conlleva este punto si el portal esta desarrollado bajo Internet. En efecto, imaginemos que el portal integra varias formas de datos o procesos de forma transparente al usuario. Y que una de ellas falla. El portal debe reintentar y en caso de no conseguirlo avisar al usuario, suplir la información que falta o buscar vías alternativas. La arquitectura de un portal de proceso se basa en cuatro componentes:

Los servidores de aplicación vistos como servicios.


Servicios creados ya como tales. Motores de procesos de negocio que permitan definir Workflow de procesos y datos.

El portal en sí, que se responsabilizará de: La autentificación de usuarios y la personificación derivada. El diálogo interactivo con el usuario a través de una GUI. La definición de los modelos de los procesos de negocio y hacer de motor ejecutor de esos modelos.

La integración de los servicios. Realizar en lo posible tratamientos asíncronos para optimizar tiempos.

8. Clientes ligeros. Los clientes ligeros o modelos de presentación activos son montajes, normalmente muy fat server, en los cuales el cliente suele ser un componente de presentación que se implementa la lógica de negocio utilizando gran cantidad de servicios proporcionados su misma compañía o por terceros. Los representaremos por el símbolo de la figura. Aunque son modelos, como los anteriores en los cuales la iniciativa la lleva el usuario, están basados en reducir el programa cliente a un componente de presentación especializado que controla la mayor parte de la lógica de negocio o la delega en un solo servicio. Este montaje es el habitual para la utilización de Servicios WEB en plataforma de transporte Internet por lo que en la inmensa mayoría de los casos, son un caso particular de ese tipo de integración. La integración en cliente ligero frente a la de cliente pesado tiene muchas opiniones a favor y en contra, muchas veces condicionadas por las necesidades comerciales de los productos que se están ofreciendo. Veamos las posibles ventajas e inconvenientes, aunque ya le sonarán de otras partes del libro. 8. 1. Ventajas.

Mínima configuración del puesto cliente, pudiéndose usar simplemente un navegador.

Especialización del cliente mucho más fácil y rápida. Ventaja fundamental.

Reutilitzación d’aplicacions ya existentes. Ofrecer beneficios muy rápidamente. Bajar el volumen de servicio de Hot-Line al estar los servicios muy probados y ser la parte cliente muy pequeña y especializada.

Facilidad de mantenimiento de versiones. Adaptabilidad a la plataforma actual de hardware. Estamos prácticamente en situación de always on sobre cualquier punto del sistema de información, es decir, la disponibilidad es alta.

Figura 281. Representación de un

cliente ligero


8. 2. Inconvenientes.

Que existan los servicios que necesito. Necesidad de ancho de bando importante. Las herencias pueden motivar descoordinación entre los servicios que se ofrecen.

La técnica de clientes ligeros no se lleva nada bien con procesos del análisis de consistencia.

Al final, lo de siempre: valorar pros y contras y decidir como ingenieros que somos. Observe que hay condicionantes de precondición muy importantes:

La presencia de servicios que resuelvan mi problema y que además sea posible coordinar entre si de forma cómoda.

La fuerte dependencia de la red obliga a valorar de entrada la Importancia del análisis de consistencia en el sistema de información.

¿Donde está el límite? No lo sé. Pero tengo un sueño; llevarme mi informática conmigo sin cargar con mi PC portátil. Igual que hace unos años llamábamos por teléfono a una casa y no a una persona y la telefonía móvil ha revolucionado totalmente el concepto de la comunicación, ¿por qué no puedo pensar que en un futuro próximo podré tener mi informática disponible en cualquier PC del mundo o terminal de mano sin más que autentificarme? Habremos vuelto al proceso centralizado. ¡Ni hablar! Muy buenos diseñadores distribuidos habrán hecho muy bien su trabajo para permitirnos esa comodidad apoyándose en el trabajo de los ingenieros de plataformas. Una posible arquitectura de este tipo son las Aplicaciones Dinàmicas de Internet (RIAs) basadas en AJAX (Asynchrnous JavaScript and XML) como capa de presentación.

9. Integración transaccional. Recuerde el esquema y la explicación desarrollada al principio de la primera parte. Observe que necesita un monitor transaccional, una arquitectura de servidor de aplicaciones o una plataforma Internet.


Recuerde también que es una muy buena solución cuando el número de clientes será muy alto, con puntas o, simplemente, imprevisible.

La integración transaccional la representaremos por el símbolo de la figura. Veamos un ejemplo de aplicación transaccional que es posible que Vd. utilice con frecuencia: una red de cajeros automáticos de cualquier caja o

banco. La arquitectura de funcionamiento de una red de cajero acostumbra a tener el diseño de la figura donde un monitor de transacciones hace de puente entre los cajeros, que llevan el peso de la aplicación en filosofía de fat client, y los servicios de cuentas de cliente que ofrecen los servicios centrales, normalmente localizados en un mainframe.

10. Integración basada en Internet.

Gestor de Transacciones

Procesador

Componente de

presentación

Componente de

presentación

Arquitectura Transaccional

Datos

Memoria

DatosDisco

Figura 282. Integración transaccional


una Integración Transaccional

Entorno Corporativo

Maquina ServidoraServicios

deCuentas

Cajero 1

BDCajero n

Monitor deteleproceso

R

R

Serviciosde

envolvente

Figura 284. Ejemplo de integración trasaccional de una

red de cajeros automáticos.


Permite muchas combinaciones tal como se muestra en la arquitectura habitual de estas soluciones, muy cercanas a la red global que

todos hemos soñado, que se presenta de forma global en la figura. Son arquitecturas, como hemos visto reiteradamente a lo largo de nuestro viaje, muy flexibles en las cuales muchas veces coexisten y cooperan elementos basados en Sistema Operativo e Internet y en

la cuales Internet no es más, ni menos, que la plataforma de transporte. Hay presencia de arquitecturas de configuración para que el cliente se pueda autoconfigurar con reglas de

negocio opacas o dinámicas y la situación actual del sistema de información. Se caracteriza porque gran parte de la verificación remota se realiza en la parte

cliente par rebajar la concurrencia y/o el tráfico de líneas. Observe la total opacidad de la parte de servicios remotos, aprovechando os estándares de Internet, la coexistencia de plataformas Windows, Linux y WEB.

Recordemos, en particular, la integración como cliente WEB que representaremos tal como se muestra en la figura de la derecha. Cuando queramos representar una WEB convencional usaremos la figura de la derecha.

11. Clientes Back-Ground. Son clientes que, como ya hemos dicho anteriormente, trabajan sin interactuar con el usuario e implementan procesos desatendidos, es decir, que no necesitan entradas del usuario una vez iniciados. Pueden confundirse con agentes. Repase el apartado donde se hizo la diferenciación entre servidores implementados en agentes y clientes Back-Ground. La mayoría de los agentes son clientes back-ground por lo que esta integración y la encapsulación en servicios implementados por agentes son muy parecidas.


de un cliente WEB

Otros Servicios

Clientes

ServidorReglas de Negocio

C

D

R T

WEB

SERVICESCliente

Windows

WEB

Browser R T

R T

Otros ServiciosInternos

API’S

Reglas de Negocio

Cliente LINUX

R T

Otros Web Services

Figura 286. Presentación Activa y plataforma Servicios

WEB


una WEB convencional


n de clientes Back-ground


Un cliente Back-Ground puro lo representaremos como se muestra en la figura.

12. Integración Batch. Es la agrupación clásica de programas en una cadena que se ejecuta de forma automática. Repase, por sabor, el capítulo de la primera parte en el cual se hablo de este tema.

Parámetros de filtro y configuración

Definición del flujo

Proceso n

Proceso i

Proceso i+1

Arquitectura Batch

Proceso 1

GestorRJE

Parámetros control de la cadenaResultados

ProcesoIniciador

Interactivo

ProcesoIniciador

Desacoplado

Figura 289. Integración batch

Recuerde que puede utilizarse un componente de presentación para pedir los parámetros de la cadena.

Una cadena batch la representaremos como se muestra en la figura. La única limitación de esta integración, que debería utilizarse más veces de lo que se hace, es que las cadenas resultantes son distribuibles y no distribuidas ya que quedan ligadas al lenguaje Batch para la

descripción de la cadena de cada sistema operativo ya que nunca se ha desarrollado un estándar en este sentido. Cuando nació el proceso Batch, allá por la cercana prehistoria de nuestra profesión, los procesos de negocio cubiertos eran pocos y muy básicos, se ejecutaban sobre las máquinas de la central y se actuaba por calendarios pactados. Todo el mundo sabía cuando la información estaba disponible. En los sistemas distribuidos actuales las cadenas Batch se pueden ejecutar en cualquier nodo, muchas veces se inician automáticamente cuando la información necesaria ya ha llegado de todos los nodos afectados, es necesario incluir como parte del diseño de la cadena Batch tres funciones adicionales.


de cadena Batch


12. 1. Control de llegada de toda la información necesaria. Puede resolverse, por ejemplo, por un ticket multihoja asociado a cada proceso. Consultando manual o automáticamente el ticket mediante un agente pueden generarse funciones del tipo:

Reclamaciones automáticas a los retrasados. Arranque automático de los procesos batch. Notificación a los responsables del lanzamiento manual de que la información ya ha llegado completamente o de que hay nodos que están fuera de plazo, etc.

Para la gestión de avisos se hará servir el Cartero. La supervisión del control de llegada debe ser un elemento más del cuadro de control de explotación del sistema distribuido.

12. 2. Control de ejecución. El estado de ejecución de los proceso batch han de ser un elemento más del cuadro de mandos de administración.

12. 3. Notificación de resultados Cuando la cadena se ha ejecutado, los usuarios afectados por su trabajo deben ser informados de ello. La forma de conseguirlo puede ser, por ejemplo:

Dirigir sus listados a sus impresoras. Utilizar el Cartero.

12. 4. Formas de montar una arquitectura batch.

12.4.1. Ejecución centralizada.

Es la arquitectura tradicional. Toda la cadena se ejecuta en un única maquina, generalmente un HOST. Observe que si el proceso objetivo de la cadena batch es distribuido, toda la información debe estar disponible en el HOST antes de iniciar la ejecución de la cadena batch. Existen dos formas de conseguirlo:

Recolección. Desde el HOST se lanzan los procesos de captura a los nodos distribuidos mediante:

Una arquitectura master-slave. Eventos. Comunicación desacoplada.

Interfase. Los diferentes procesos distribuidos envían a la central los datos cuando los tienen disponibles.

En ambos casos el uso de ticket para controlar y sincronizar el proceso se hace fundamental.

12.4.2. Ejecución distribuida. Esta arquitectura evita el trasiego de datos si los volúmenes son altos.


Obliga a análisis de consistencia. Existen dos posibilidades:

12.4.2.A. Captura de datos distribuida. La cadena batch va a buscar los datos a cada uno de los nodos originales a través de servicios. En una forma de mundo al revés ya que normalmente es el nodo el que envia o busca los datos en la central.

12.4.2.B. Ejecución de procesos distribuida. La cadena batch se estructura en una arquitectura master-slave de de delegación donde el master, localizado en el HOST asume la dirección y las cadenas esclavas se ejecutan en los nodos distribuidos.

13. La integración por estereotipos o agentes. Cada cliente asume una función o estereotipo funcional. Cada estereotipo funcional es asumido por un agente. La integración por estereotipos la representaremos como se muestra en la figura. OJO: Este agente no es el mismo concepto

que el agente proveedor de servicios, aunque muchas veces un estereotipo es un servicio desacoplado y en ese caso si que coinciden ambas acepciones de la palabra agente.

Así, en un proceso de traspaso de información pueden existir los estereotipos o agentes: generador, transportista, facturador, cobrador, distribuidor, incorporador, recodificador, etc.

Figura 291. Representación de una

integración por estereotipos


En la figura se muestra un ejemplo de integración por estereotipos en el cual un generador se cuida de extraer la información de una BD origen, un distribuidor la coloca en la de envío para varios nodos donde la lleva un transportista. En uno de los nodos un recodificador

cambia códigos diferentes entre las dos bases de datos y, finalmente, un incorporador la incluye en la base de datos destino. En este montaje, el generador puede ser una cadena Batch que anota en una cola y que utiliza el distribuidor como un servicio pasivo. El transportista será un servidor de correo. El recodificador y el incorporador serán probablemente agentes en el concepto de servicio. La integración por estereotipos es una utilización final de la metodología de diseño por estereotipos muy de boga en los primeros años del proceso distribuido pero caída hoy día en desuso por sus grandes limitaciones en aplicaciones grandes. Sin embargo, como forma de integración funcional del cliente puede ser útil y clarificadora. Cada estereotipo se implementa con un cliente o en un servicio proporcionado por un servidor o por un agente. Los clientes son de integración guiada por el usuario o Back-Ground, con preferencia de este segundo modelo sobre el primero. En los pasos intermedios suelen estar los servicios. Es fácil confundir el modelo de estereotipos con Workflow. No caiga en el error. La integración de estereotipos supone proceso secuencial en el cual los agentes asumen funciones, modeladas en estereotipos, especializadas y claramente diferenciales.

14. Procesador distribuido.

El procesador distribuido es un ejemplo de integración por estereotipos montados en agentes que diferenciaremos gráficamente tal como se muestra en la figura. Empecemos por presentar el concepto de procesador distribuido. Normalmente el traspaso de información entre nodos suele establecerse con filosofía de interfase. En un

BDOrigen

BDDestino 1

BDDestino 2

Generador Distribuidor

TransportistaRecodificador

Incorporador Incorporador

Figura 292. Integración por agentes

Figura 293. Representación de un

procesador distribuido


momento en que los nodos tienen comunicaciones punto a punto permanentemente abiertas a costes razonables, se plantea la posibilidad de intercambiar información entre nodos con la filosofía de la replicación síncrona, es decir, tan rápido como sea posible. La arquitectura del procesador distribuido responde a esa necesidad. En una aplicación suele haber una serie de funciones que se necesitan ejecutar tanto en local como el remoto. Estas funciones se agrupan conceptualmente bajo un agente que llamaremos Procesador. Las opciones del procesador son piezas, objetos o rutinas, que se especializan en una función de la aplicación integradas como servicios pasivos. Estas piezas, que forman el corazón del procesador, pueden estar también integradas tanto en los programas clientes como en servidores, Estos clientes y/o servidores los referenciaremos en el esquema simplemente como Aplicación. Si estas funciones se quieren ejecutar independientemente de que la base de datos es local o remota estaremos ante un procesador distribuido.

Empezamos por necesitar una forma de situar la base de datos independientemente de su localización física. Para conseguirlo podemos asociar un nodo a cada una de esas localizaciones y ligar a cada nodo su dirección IP. De esta forma podremos dejar operativa una plataforma SOAP y podremos actuar con ADO si nos conviene. Montaremos los servidores y agentes siguientes:

Un servidor de cola de procesos pendientes con ficheros XML para describirlos y actuando en arquitectura de filtro.

Base datos local

Base datos remota

AplicaciónProcesador Transporte

Vigía

Procesador Transporte Transporte

Vigía

ProcesadorCola de procesos

Cola de procesosEntorno

Local

Entorno Remoto

Figura 294. Arquitectura de un procesador distribuido.


Un vigía que explorará la cola de procesos pendientes y, si el trabajo es para el nodo local le pasará control al agente procesador local y si es para un nodo remoto al agente de transporte.

Un agente procesador que recibe por traspaso de responsabilidad el trabajo del vigía, realizándolo y devolviendo el estado de error o éxito, que anota en la cola local.

Un agente de transporte que recoge el aviso del vigía y contacta con el trasporte de la parte remota, reintentándolo tantas veces como sea necesario. El transporte de la parte remota revisará la cola de procesos remota y cuando vea que la anotación ya está procesada devolverá ese estado al agente de transporte de origen, que anotará el resultado en la cola local. Observemos que este mecanismo asegura ejecución segura (“full tolerance”).

Como se ve esta función se puede utilizar por la aplicación tanto asíncrona como síncronamente, aunque todo el conjunto es de arquitectura asíncrona y simétrica y cualquier nodo se puede comunicar con cualquier nodo de forma simultánea quedando resuelta la concurrencia y el paralelismo. Una variante de esta arquitectura es permitir la posibilidad de que la aplicación, si necesita hacer muchas conexiones síncronas, incorpore ella misma el transporte de forma que minimice el número de pasos, evitando la cola y consiguiendo así un tiempo de respuesta mucho más rápido. Conviene remarcar, finalmente, que las funciones de transporte no son, en el fondo, más que otro conjunto de piezas que hace totalmente posible su integración estática en la aplicación. La arquitectura del procesador distribuido pude construirse también con una solución no tan exigente tecnológicamente. En la parte local, el vigía integra al procesador y al transporte siendo el funcionamiento en esta parte muy parecido al caso anterior. La novedad está en la parte remota donde existe un único agente, que llamaremos el ejecutor, donde se integran el transporte y el procesador y en que la comunicación entre los dos transporte es síncrona. Para permitir un mínimo de concurrencia, dentro del ejecutor se integran una pequeña cola y el transporte y el procesador se montan en dos hilos diferentes. De esta forma, el trasporte puede trabajar de forma desacoplada con el procesador y se pueden atender, siempre síncronamente, varios clientes, transporte o aplicación. Observe que en cualquier caso, debe proporcionarse un aviso de “ejecutor ocupado” para el caso de que su cola interna se llene.

Base datos local

AplicaciónProcesador Transporte

Vigía

Procesador Transporte

Cola de procesos

Entorno Local

Base datos remota

Ejecutor

Transporte Procesador

Entorno Remoto

Figura 295. El Procesador distribuido síncrono


15. Integración por Workflow.

La integración por Workflow se basa en distribuir las funciones cliente entre programas, muchas veces agentes, distribuidos que se ejecutan según una arquitectura de Workflow que representaremos como se muestra en la figura. Al Workflow, por su importancia, ya dedicamos en la primera parte un capítulo entero. Si no lo recuerda, por favor, repáselo. Recordemos que hay dos tipos de procesos de Workflow que se traducen en dos tipos de integración: 15. 1. Trabajo Cooperativo.

En el que varios clientes colaboran en un mismo trabajo, normalmente un documento. Es paralelo al Workflow “ad hoc”. Por ejemplo, la gestión de un informe obliga a que anoten diferentes áreas de la compañía.

15. 2. Workflow de procesos. Los clientes distribuidos se agrupan en flujos Workflow que modelan procesos de negocio de la compañía. Para que vea como

puede integrarse una aplicación distribuida siguiendo un modelo de

Workflow recordemos el ejemplo, que se vuelve a mostrar en la figura, de capítulo de la primera parte dedicado a este tema.


una integración Workflow

Petición de compra del cliente

VENTAS

Análisis del risgo

del crédito

CRÉDITOSRechazo

CRÉDITOS

Aprobación

CRÉDITOS

Aviso del rechazo del

crédito

VENTAS

Reserva producto

ALMACÉN

Confirmación de la venta

VENTASAviso del rechazo al

cliente

VENTAS

Figura 297. Ejemplo de Workflow.


En la siguiente figura se muestra una posible integración de una solución construida con clientes bajo una arquitectura distribuida para la aceptación o no del crédito. Se supone que existe una BD histórica con datos de morosidad disponible de forma pública y un servidor externo a la empresa, y una base de créditos concedidos en la empresa. Se propone un cliente Back-ground con tres procesos: Evaluar, que con la llamada a un servidor localizado en la máquina de la Base de Datos de Créditos decide si el pedido ha de ser aceptado o rechazado. El proceso llama por RPC a la Base de Datos externa.

Rechazar, que con la ayuda del servidor de correo devuelve el pedido al Dpto. comercial.

Aceptar, que con el mismo servidor de correo envía el pedido a almacén. 15. 3. Workflow de datos: Sistema de Gestión de documentos.

Recordemos el ejemplo de SGD que presentamos en la primera parte como un ejemplo de Workflow. No es muy difícil ver que es una integración de tipo Workflow donde se distinguen los elementos:

• El agente de Reconocimiento y clasificación puede ser activado por un conjunto de Vigía + Disparador.

• La eliminación histórica es implementada por un agente. 16. Integración por publicación y suscripción.

Petición

Rechazo

Petición

Aprobación

Petición

Evaluar

Sistema experto

Base Histórica

Rechazar

Aprobar

BD Créditos

RPCR

ActualizarCréditos

RR Servidor

de correo

Servidorde correo R

R

Figura 298. Implementación del proceso de Aceptación del Crédito.

SGD (sistema de gestión de datos) o ECM (Gestión de contenidos empresariales)

Proceso

Ofimática

Fuentes de documentos

Agente de Reconocimiento y Clasificación

Correo

Directorio (indice)

Repositorios

Eliminación del original

Archivo del original

Ús pel SD

EliminaciónHistórica

Destinatarios

Proceso

Figura 299. Implementación de un Sistema de Gestión de

documentos.


una integración por publicación/suscripción


La integración por publicación y suscripción en un sistema muy potente de integrar funciones que traspasa el ámbito interno de aplicaciones y se convierte en una forma de integrar aplicaciones muy heterogéneas entre si o de terceros, basadas en local o remoto y con diseño distribuido, Cliente / Servidor o Internet. Este tipo de integración lo representaremos tal como se muestra en la figura La idea es simple y potente. Cuando uno de los módulos tiene alguna información o cambio de estado que puede ser de interés para otros participantes del escenario lo "publica" para conocimiento general. Por otro lado, los módulos que necesitan estar informados de unos determinados acontecimientos se "suscriben" a la lista de suscripción donde se publican esos acontecimientos. Cuando el distribuidor recibe una publicación genera un evento para avisar a todos los suscriptores de ese tipo de información registrados en la lista de suscripción. En suscriptor, que está ocupado en su trabajo normal, interrumpe su trabajo para responder al evento o se lo guarda para actuar más adelante. Por su importancia, dedicaré a la publicación y suscripción un capítulo específico. Sin embargo, le propongo un ejemplo sencillo para que vea el funcionamiento general de está forma de integrar. Imaginemos que un grupo de compañías de seguros quieren controlar clientes "poco rentables" que cambian de compañía para evitar penalizaciones. Podrían organizar una lista de suscripción en la que se publicaran los datos de estos clientes. Cada vez que una de ellas tuviera un percance con uno de ellos, lo publicaría en el tablón que se encargaría de generar un evento de aviso al resto de compañías suscritas. Si una nueva compañía se incorpora al sistema, solo deberá registrarse. Como ya le he comentado, trataremos enseguida el tema en profundidad. Sin embargo, amigo lector, se le ocurrirán rápidamente infinidad de usos de esta técnica.

17. Integración por objetos distribuidos.

Si la utilización de objetos distribuidos es pura, los componentes del sistema se conectan al bus de modelo de objetos distribuidos elegido y se comunican entre ellos. Los objectos que asumen el rol cliente utilizan la interface de los servicios que proporciona la plataforma y los servidores proporcionan los servicios definidos a las interfaces. Sin embargo, una plataforma de objetos distribuidos puede utilizarse también, y es el caso más frecuente, como plataforma de comunicación entre las clases en un dialogo C/S convencional.

18. Los papeles múltiples.

La posibilidad de que un cliente pueda tener, con una sola versión de programa, diferentes modos de funcionamiento es un aspecto muy importante en la integración del cliente que muchas veces es menospreciado o ignorado pese al poco esfuerzo que supone disponer de él.


No hay ninguna razón técnica que impida que un solo ejecutable pueda, por ejemplo, estar en una cadena batch, participar de un flujo de Workflow o ejecutarse desde una interfície gráfica. Siempre que el programa cumpla una función en que este adaptabilidad tenga sentido, claro está. Imaginemos, por ejemplo, un agente de facturación, que a partir de un fichero de albaranes y una impresora, pude generar todos los documentos implícitos a una facturación: la factura en si, su impresión, su inclusión en el diario de ventas y la cuenta de cliente, etc. Nos puede interesar arrancar este facturador:

Desde una cadena Batch, tomando los parámetros del flujo de la cadena. Desde un flujo de Workflow cuando se generar una autorización de compra pro forma.

Una venta directa en tienda con el cliente presente. Lanzar desde una opción del menú la facturación de todos los albaranes pendientes.

Y no queremos hacer cuatro montajes de programa, que aunque compartan la mayoría de las piezas, nos obligaría a mantener y distribuir cuatro versiones de ejecutable Montaremos el programa con una arquitectura como la que se presenta en la figura gestionando:

Un parámetro inicial de arranque que nos permitirá saber cual es el modo de trabajo de la ejecución. Por ejemplo, el modo puede estar asignado a un parámetro del comando de ejecución del programa. Si se ejecuta desde menú, desde un proceso de Workflow o desde un escritorio Windows se añadirá en las propiedades del programa y si se llama como servicio se le pasará como parámetro en el comando de llamada desde el programa cliente que solicita su trabajo. Si no hay parámetro de configuración, se asume por defecto que la ejecución es batch.

El resto de parámetros se pasarán dentro de un fichero XML. El nombre de este fichero se tomará en batch de un parámetro de la cadena, en el flujo Workflow y el la llamada como servicio de una cola de comunicación y en la llamada GUI se pedirán al operador como parte de la interdice gráfica.

Parámetros de la

cadena

Parámetros de configuración e ejecución

Captura Batch

Captura WorkFlow

Captura de servicio

Configuración Inicial

Captura Gui

Componentes de proceso y datos

Comando de ejecución

Figura 301. Papeles múltiples.


Para los parámetros de resultados se seguirán estrategias parecidas. Los parámetros se gestionan transaccionalmente, es decir, unas piezas de captura filtrarán la heterogeneidad del modo de ejecución, los colocarán en una zona interna del programa y partir de aquí el resto de piezas que formen el programa comenzará a trabajar. Observe que en esta arquitectura el programa original se ha convertido “de facto” en un servicio de alto nivel, que es posible independizar como un servicio más como intenta simbolizar el marco de la figura anterior. La guinda final se la imagina en seguida. Esta “tirado” convertir los componentes de captura en reutilizables para todos los programas por lo que en el fondo, hacer su programa adaptable no le costará nada. Fuera de diseñar bien, claro está.

19. La integración basada en sistema operativo desde Internet. Las aplicaciones basadas en sistema operativo, básicamente Windows, son perfectamente operables desde Terminal Server lo que plantea una interesante disyuntiva:

Integrar sobre sistema operativo y extender a Internet por Terminal Server. Integrar sobre Internet y extender al sistema operativo por Intranet.

¡Más gris, más temas sin decisiones claras,… pero más posibilidades de adaptabilidad! Y como siempre, el caso real como factor básico de la decisión.

@EMG-08 - Enric Martínez Gomàriz 460

Integración por publicación y suscripción.

1. Introducción. La integración de funciones distribuidas tiene en la publicación y suscripción (P/S) una técnica muy potente y flexible que trasciende el ámbito de la integración corporativa y abarca la extra corporativa. Permite tanto la integración entre módulos, que vamos a llamar en lo sucesivo interlocutores, de una misma aplicación como la de aplicaciones diferentes, en local o en remoto, de la misma compañía o de diversas, y en el apoteosis de la integración, en arquitectura cliente/servidor, Internet o centralizada. La Integración de aplicaciones empresariales o EAI (Enterprise Application Integration) se hace muchas veces por un modelo de publicación y suscripción. Vamos a hablar dentro de este capitulo de esta idea simple, potente y general.

2. ¿Qué es integrar por publicación y suscripción? Hagamos, de entrada, una rápida introducción a este concepto. En el sistema habitual, que se muestra en la parte superior de la figura, los interlocutores se comunican cara a cara o por interfase.

En una comunicación cara a cara, síncrona o asíncrona, cada interlocutor conoce a priori que módulos necesita utilizar o necesitan de su trabajo. Para una comunicación por interfase, es decir desacoplada, las necesidades de conocer puntualmente donde está la otra parte es

menos crítica, pero persiste. Sea de forma síncrona, asíncrona o desacoplada, los interlocutores se intercambian mensajes directamente cuando se necesitan mutuamente. Cuando se establece una comunicación que no existía hay que actuar sobre los dos interlocutores afectados. Si hay más de un interlocutor, habrá que desarrollar un modelo de comunicación para cada uno de los modelos de desarrollo de los componentes del escenario. Y además hay que tener posibilidad de hacerlo ya que

Módulo

MóduloMódulo

Módulo

Comunicación cara a caraComunicación cara a cara

Módulo Módulo Módulo Módulo

Comunicación por busComunicación por bus

Figura 302. Comunicación cara a cara versus comunicación por bus.


necesitamos información de cómo son esos interlocutores con los que nos queremos integrar. Y en muchas ocasiones el entorno de desarrollo de cada aplicación es muy heterogéneo. Si son dos módulos de organizaciones diferentes, una organización debe conocer a la otra, lo cual exige una negociación técnica y política porque los sistemas que soportan los módulos a comunicar puede ser muy heterogéneos al haberse desarrollado con plataformas, infraestructuras y lenguajes muy diferentes. Además, a medida que aumenta el número de interlocutores, se hace más complicado desarrollar y mantener todas las relaciones. En fin, los problemas de flexibilidad, escalabilidad, costes y rapidez en disponer de la solución pueden ser tan importantes que hasta imposibiliten obtener una arquitectura integrada. Pero podemos pensar en otra forma de hacerlo en la que todos los módulos se conectan a un bus capaz de hacer circular mensajes. Cuando un módulo necesita de un servicio de otro módulo o desea enviarle una información la coloca en un mensaje sobre un bus donde se han ensamblado los interlocutores como se muestra en la parte inferior de la figura anterior. El bus lo hace circular entre todos los interlocutores. Cuando un interlocutor recibe un mensaje averigua si es para él, y en caso afirmativo, lo recoge. ¿Le suena?, efectivamente, es la arquitectura de comunicación entre servidores por Broadcast Data Flow que presentamos en el capítulo dedicado a Arquitectura de Servicios. Con una diferencia que mejora notablemente la eficiencia: los mensajes no se dirigen a todos, sino solo a los interesados. La gran ventaja es que el emisor y el receptor no están comunicados directamente. Cualquiera que conozca las reglas de juego del bus, puede publicar o suscribirse a una información. El problema principal es la ineficacia, ya que se establece mucho tráfico innecesario. Hay que buscar, pues, una solución ese problema, combinado las ventajas del bus, independencia entre los módulos, y del cara a cara, minimización del tráfico. La arquitectura de la solución pasa una vez más por la idea de Middleware. Cada interlocutor hablará con unas reglas pactadas, que serán un estándar para todos los interlocutores. Para integrar un nuevo módulo sólo habrá que conocer y usar las reglas de juego. El Middleware será el responsable de proporcionar eficacia al conjunto de la integración resolviendo el Broadcast con una conexión virtual cara a cara. Inmediatamente le explicaré cómo.

3. Caracterización del mensaje y la suscripción. El mensaje puede ser:

Auto descriptivo llevando toda la información del evento. De aviso, conteniendo únicamente la notificación de que ha ocurrido el evento y la dirección, un archivo o un servidor, donde está toda la información completa.


Según su personalización, la suscripción puede ser:

Estática, establecida por las herramientas del Middleware P/S de administración.

Dinámica modificada en tiempo de ejecución por las API’s de desarrollo. Debe evitarse siempre que sea posible.

En función del destino:

General: a todos los suscriptores. Especializada: sólo a los interesados en un tema

En función del criterio, la suscripción puede ser:

A un conjunto de publicadores. A un conjunto de publicaciones, escogiendo todas las noticias o sólo las de una determinada

4. Paradigmas.

4. 1. Publicación Broadcast. Un interlocutor publica una información sin saber que interlocutores la necesitan. Observe que es la opción convencional de un modelo de publicación y suscripción.

4. 2. Solicitud y respuesta. Un interlocutor interesado pregunta al sistema por una información y el sistema le devuelve la respuesta generada por el interlocutor que la tiene.

4. 3. Solicitud y respuesta Multicast. Llamada también Broadcast/Manycast, es un caso particular del anterior en que hay más de un interlocutor capaz de proporcionar el servicio. La petición se hace circular entre todos los publicadores capaces de proporcionar el servicio y responde el primero que está disponible. Estos interlocutores pueden ser instancias de un mismo interlocutor.

4. 4. Transaccional. Varios eventos, relacionados entre si, se encapsulan en una transacción para minimizar el tráfico. Es obvio que el sistema transaccional puede utilizarse conjuntamente con cualquiera de los dos paradigmas anteriores. Es muy recomendable cuando una información no es útil sin el resto.

5. Arquitectura de publicación y suscripción. En la figura que se muestra más adelante se muestra la arquitectura básica de los componentes de un Middleware de este tipo. En ella se integran los siguientes elementos:


5. 1. Los interlocutores.

Módulos integrados en el sistema. Los hay de dos tipos:

Publicador. Suscriptor.

Obviamente la situación de publicador o suscriptor de un interlocutor es dinámica y un mismo interlocutor adopta, habitualmente, los dos perfiles en una sesión de trabajo. Cada interlocutor se identifica por un nombre.

5. 2. El Bus Queda representado por las API’s de la capa P/S. Como en todo Middleware, hay API’s de:

Desarrollo. De administración.

5. 3. La publicación.

Diario o revista donde se publican las noticias y al que se suscriben los interlocutores interesados.

5. 4. La noticia. Evento o información que cambia dentro de cada publicación. Se pueden tipificar.

5. 5. El mensaje. La notificación de la noticia que se pasa o recibe del bus. Cada mensaje se coloca en el bus una sola vez.

5. 6. La lista de distribución. Donde se anota la tipología de eventos a controlar y los suscriptores interesados. Debe proporcionar también una forma para disponer de más de una lista de distribución para tener posibilidad de llevar más de una publicación.

5. 7. El adaptador. Es el componente desarrollado dentro de cada interlocutor para conectarse al bus. Utilizará las API’s del Middleware P/S. El adaptador será un mero exportador/importador de datos que serán visibles por todos los interlocutores conectados al sistema de publicación y suscripción.

5. 8. El distribuidor.


El agente encargado de recibir y distribuir los mensajes.

5. 9. La memoria. Observe que el Middleware de P/S debe tener memoria histórica ya que es más que posible que cuando una noticia se publica, haya suscriptores que no estén escuchando. Esta memoria histórica se traduce, generalmente, en una tabla cruzada de noticias y suscriptores con una tributo para conocer si ha sido entregada o no. Es fácil imaginar el funcionamiento conjunto. Las noticias se publican en mensaje por los publicadores sobre el bus con una referencia de publicación. El Distribuidor del Middleware envía el mensaje a todos los suscriptores de esa publicación que están escuchando. Si hay suscriptores fuera del bus es ese momento, se guarda el mensaje hasta que se conectan. Para conseguir este funcionamiento se habrán de usar:

Con las API’s de administración:

Se establecen, por temas, las publicaciones necesarias.

Se codifican las tipologías de noticias y eventos a gestionar

Se crea una lista distribución por cada publicación que se necesite.

Se referencian, si es necesario, los publicadores responsables de cada tipología de noticia.

Se establecen las suscripciones estáticas.

Con las API’s de desarrollo:

Paradigma de publicación Broadcast. Los interlocutores publican las noticias de cada publicación. El Distribuidor recibe las noticias, consulta la lista de distribución y la envía a los suscriptores.

Paradigma de solicitud / respuesta. El interlocutor envía el mensaje de petición. El Distribuidor pregunta a los publicadores. El publicador envía la respuesta. El distribuidor hace llegar la respuesta al solicitante.

Con las API’s de monitorización seguiremos el funcionamientos dinámico

del sistema:

Distribuidor

Lista deDistribución

BUSBUS

Interlocutor A

Adaptador

Interlocutor C

Adaptador

Interlocutor B1

Interlocutor D

Adaptador

Memoria

Interlocutor B2

Adaptador

Servidor de Pasarela

T

Figura 303. Arquitectura básica de publicación suscripción


Rendimiento. Mensajes pendientes de entregar, etc.

El Distribuidor puede verse, pues, como un servidor P/S con semántica de comportamiento full tolerance. Observe también que la filosofía de un adaptador es de una arquitectura de pasarela. Si se monta como un servidor la comunicación con el bus será con esa arquitectura. La arquitectura de pasarela resolverá también la no existencia de un estándar P/S. Los interlocutores delegarán la conexión en un servidor P/S que actuará como pasarela a los diferentes buses P/S que haya que adaptar.

Y si ve claro que está ante un servidor y diseña la capa P/S, recuerde de hacerlo con todas las cualidades que exigimos a nuestros servidores. En particular, el paralelismo que le permitirá arrancar más de una instancia del Distribuidor y dar gran escalabilidad ante aumento de tráfico. En el Map to Reality de un servicio P/S debe analizarse el ancho de banda del bus para evitar demoras no deseadas. Note que un Middleware de este tipo es dos capas:

Una capa especifica de publicación / suscripción. Otra de mensajería o transporte.

Entre las dos se establece una arquitectura de delegación. La segunda es ya un estándar. La primera no lo es tanto y en muchas ocasiones sale a cuenta montarla como Middleware de usuario. No hay que decir que la capa de mensajería ha de ser independiente de la vía como cualquier transportista que se precie. Tanto los adaptadores como el distribuidor, que en el fondo generan eventos, pueden potenciarse con mecanismos ECA que permiten implementar reglas de negocio. Al ser las reglas de negocio particulares de cada instalación, es mejor implementarlas dentro de los adaptadores que en el distribuidor.

6. Tipología de adaptadores.

6. 1. Adaptadores de mensaje completo. El mensaje es auto explicativo conteniendo los datos involucrados. Se utilizan las API’s del Middleware P/S.

Interlocutor 1 Interlocutor 2

Adaptador A

Servidor de Pasarela

T

Adaptador B Adaptador C

BUS P/S 1

BUS P/S 2

BUS PS/3

T T

Figura 304. Acceso a P/S heterogéneos.


6. 2. Adaptadores de archivo con mensaje de aviso. El mensaje se reduce a un aviso. El traspaso de los datos se realiza a través de un archivo plano. Normalice el formato. Le recomiendo:

Como primera opción, ficheros XML. Como segunda, ficheros de texto con los atributos separador por un carácter de control y los registros por <CR,LF>.

Perderá algo de eficacia en ocupación pero ganará en independencia de representación y podrá leerlos con un simple editor.

6. 3. Adaptadores de archivo sin mensaje de aviso. Es una variación del anterior en la cual no hay mensaje de aviso. El adaptador reconoce el aviso por la aparición del fichero en un directorio pactado. El distribuidor genera el evento. Simplifica el diseño del adaptador ya que no ha de preocuparse de la comunicación. Es cómodo para la publicación pero poco eficiente para la suscripción ya que obliga al suscriptor a escuchar el bus. Le recomiendo que reduzca su uso a la publicación. Obviamente, puede utilizar aquí mecanismos de Vigía y Disparador.

6. 4. Adaptadores sobre BD. Es una variación de los anteriores en que el intercambio de información se realiza directamente sobre BD. Exige como mínimo el uso de ODBC-SQL. La solución es algo más eficaz al evitar la grabación del fichero plano pero queda distribuible en lugar de distribuida.

6. 5. Adaptadores basados en correo electrónico. Para la salida se genera un mensaje de correo electrónico que debe ser capturado por el adaptador y desencadenar un evento.

6. 6. Adaptadores basados objetos distribuidos. Optimo en aplicaciones OO., puede utilizarse también en aplicaciones convencionales ya que la implementación OO se reduce al adaptador. El modelo de comunicación suele ser por eventos.

6. 7. Adaptadores fabricados por proveedores de componentes. Es una buena solución que solo tiene un “pequeño” problema: no hay estándares.

7. Publicación y Suscripción versus comunicación cara a cara. La mayoría de las ventajas P/S son inherentes al concepto de Middleware en que está basado:


Transparencia de la localización. Disponibilidad ya que es muy rápido conectar nuevos interlocutores. Escalabilidad ya que pueden arrancarse varias instancias del Distribuidor y de los publicadores (en paradigma solicitud / respuesta).

Reducción del trabajo ya que sólo hay que desarrollar el adaptador al bus. Reducción de los costes de adaptación y mantenimiento.

Puede parecerle que este modelo de integración es la panacea de todos los modelos. Por favor, no caiga en ese error. Es mucho más ineficiente que la cara a cara. Mucho más. Y más caro. Como buen diseñador, úselo sólo en los casos que potencian sus ventajas: sistemas heterogéneos, interlocutores de terceros, comunicaciones fuertemente desacopladas, etc. Además trabajando en SOA se tienen acoplamientos mínimos…, y eso desmonta parte de las “”ventajas” de la P/S.

8. Herramientas para la capa de mensajería o transporte. Han de permitir el desacoplamiento total de los interlocutores evitando que deban conocerse entre si y que permitan la parametrización dinámica permitiendo añadir o retirar interlocutores dinámicamente. Podemos usar: 8. 1. Herramientas de Middleware de mensajes (MOM).

Aunque en un sistema de publicación y suscripción no existen clientes o servidores en el concepto tradicional, es evidente que esta herramienta de aplicable. En capítulos anteriores hemos discutido ampliamente sobre ventajas e inconvenientes de utilizar MOM como Middleware estándar o de usuario. En una arquitectura de publicación y suscripción es obligado el uso del estándar. Permite todos los paradigmas P/S.

8. 2. Herramientas de RPC. Igual que el anterior pero con las limitaciones de ser síncrona y la ventaja de ser más estándar que el Middleware MOM.

8. 3. Modelos de objetos distribuidos. El mecanismo a utilizar en el gestor de eventos. Muy potente y flexible, permite todos los modelos de paradigmas P/S

8. 4. Gestores de Colas. Se puede decir aquí lo mismo que en MOM.

8. 5. Correo electrónico. Ventajas de amplitud y estandarización.

8. 6. Monitores de transacciones.


Recomendable, obviamente, para el paradigma transaccional.

8. 7. Software propio en integración intracorporativa. Dado el estado del arte, no le recomiendo esta vía más que en casos muy claros en que la publicación y suscripción se inicie cuando en la instalación ya existan herramientas de integración previamente desarrolladas y utilizadas en el Middleware de usuario.

8. 8. Bus basado en Internet. Las ventajas de P/S se aplican a Internet por técnicas de push. No voy a volver a comentar esta técnica. Si no la recuerda, revise el capítulo dedicado a la Arquitectura de la Comunicación en un Sistema Distribuido. Las soluciones de este tipo entran en el marco de los modelos que he presentado en el capítulo dedicado a las relaciones entre C/S e Internet. La aplicación Internet ha de ser activa ya que necesita interactuar con el sistema local. Hay varias formas de montarlo.

8.8.1. Cliente HTML puro localizado en la WEB. La información se publica en un formulario HTML y se utilizan técnicas de push para avisar a los suscriptores.

8.8.2. Cliente HTML usando otro módulo del sistema WEB. Recordemos que el cliente puede interactuar con el sistema en el que está localizada la WEB. Existen diversas formas de conseguirlo:

Por CGI/ISAPI/NSAPI o API’s especiales a un módulo del sistema donde esta localizada la WEB. Las API’s P/S se incluyen en la llamada. A través de un Servicio WEB localizado en la WEB. El servidor realiza la llamada a las API’s del Middleware P/S. Esta implementación tiene la ventaja sobre la anterior de que puede usarse también por los procesos locales.

8.8.3. Uso de Applet.

Es un montaje paralelo al anterior en que la diferencia está en la implementación. Cuando el interlocutor se conecta al sistema P/S arranca un applet que lo liga al sistema por uno de los dos sistemas anteriores

El Servidor de Versiones

1. ¿Qué es un servidor de versiones? En un sistema distribuido, en los diferentes nodos hay programas y datos. Como hemos hablado reiteradamente, sincronizar todos los elementos del sistema no es una tarea banal. A lo largo de nuestro viaje hemos presentado y explicado los elementos y criterios necesarios para gestionar este tema. Sin embargo, dada su importancia, podemos plantearnos un ejercicio. Diseñaremos la arquitectura de un servidor de versiones que permita mantener al día todos los nodos sincronizados en datos no volátiles y programas. En general los datos volátiles suelen tener sus propias vías de replicación especializadas. Llamaremos servidor de versiones a la arquitectura resultante que nos resuelve el problema. Obviamente, la plataforma sobre la que hay que actuar depende de cada caso. Sin embargo, las funciones son siempre las mismas:

Empezaremos por fijar los niveles lógicos de la arquitectura sobre la que vamos a actuar.

Seguiremos por definir que elementos queremos sincronizar. A continuación definiremos el modelo de datos relacionado. Finalmente propondremos la arquitectura del servidor de versiones que la desarrolla.

2. Especificación de los niveles lógicos de la plataforma. A efectos de centrar el ejemplo, vamos a trabajar con una plataforma de tres niveles lógicos:

Central. Nodo servidor Clientes de dos tipos.

Los que no necesitan autonomía de trabajo. Vamos a suponer que la autonomía de trabajo se puede conseguir con ficheros XML.

Los que la necesitan. Los programas deben estar en todos los nodos y los datos solo en la central y en los nodos servidores.

3. Elementos a sincronizar. Nos planteamos mantener de forma automática versiones de:


Programas Servidores. Agentes. Clientes.

Datos. Modelo a través de SQL que contienen las modificaciones del modelo de datos y las acciones necesarias para pasar del antiguo al nuevo. Pueden estar aquí:

Inicialización de nuevos campos. Migración de contenidos. Resolución de restricciones de integridad, etc.

Parametrización en BD o definición de comportamiento incluida en tablas de la BD.

Contenido de las entidades de la BD. Fecha y hora del sistema distribuido.

En programas, aunque a afectos de versiones no hay diferencias entre clientes, agentes y servidores, el matiz está en prever que el servidor y el agente pueden estar arrancados permanentemente y que hay que prever un mecanismo de notificación de nueva versión que puede ser:

Un evento. Una pregunta periódica planificada en la ficha de Enviroment del servidor. Una petición al servidor de auto actualización prevista en el flujo de mensajes, Una rearrancada periódica automática o manual, etc.

. Algo absolutamente paralelo ocurre con la modificación del modelo de datos, las tablas de parametrización contenidas en BD y el contenido de las entidades. También vamos a generalizarlas como datos. En lo que sigue hablaré en general de programas y datos, dejando el matiz diferenciador entre los actores para un ejercicio adicional del lector.

4. Arquitectura del servidor de versiones. El modelo de datos debe ser ampliado para contener el registro de los elementos y versiones que hay en cada nodo. Podemos registrar, por ejemplo, una entidad en la BD o en fichero XML con:

Nodo. Elemento. Versión actual del elemento. Fecha y hora de actualización, etc.

Lo que vamos a tratar aquí es una extensión de la replicación de programas presentada en el capítulo de la replicación. Es peligroso actualizar “demasiado automáticamente” ya que puede crearse inconsistencia en la coordinación del sistema. Por esa razón es bueno disponer de la posibilidad de añadir a las versiones pendientes de actualizar fechas para controlar:


Cuando hay que transmitir el cambio de la central a los nodos periféricos. Cuando se ha de hacer efectivo en el nodo de destino.

La filosofía de trabajo será hacer que cuando cada programa arranque:

Verifique si ha de hacer efectivos cambios ya registrados en su nodo. Compruebe con el nodo superior en jerarquía si hay cambios pendientes de ser registrados. Una vez traslados hasta el nodo, deberá verificarse si se han de hacer efectivos con los recursos del punto anterior.

En la plataforma lógica que hemos planteado el servidor de versiones tendrá dos módulos:

La actualización servidor del nodo contra central. La actualización del cliente contra el servidor del nodo.

En la siguiente figura se muestra una posible arquitectura de un servidor de versiones para gestionar, en la especificación que hemos planteado, la actualización del servidor de nodo contra la central.

Servidorde

Configuración

Servidorde fecha y hora

Servidorde

archivos

Versiones datos y

programas

ServidorVerificaciónversiones

Servidorde correo Datos

Versiones datos y

programas

Datos

Programas

Configuración

Servidorde

Versiones

Arranqueprograma

ServidorArranque

Servidorde correo

Programaen

servidor

Servicio de carga de archivos

Programas

R

Fecha y Hora

Procesadordistribuido

Procesadordistribuido

D

D

C

D

T

RD

R

R

TT

T

Fecha y Hora

Central

Nodo

Figura 305. Arquitectura de un servidor de versiones.

Un programa que se ejecute en el servidor de nodo no se iniciará nunca automáticamente sino a través de un programa de arranque que recibirá como parámetro el nombre y localización del programa definitivo. Esta función de ejecución llamará a un servidor de arranque que verificará si hay versiones en el mismo nodo cuya fecha de vigencia ya se ha alcanzado. Si es así, pasará control al servidor de carga de ficheros para realizar la actualización. A continuación realizará una llamada al servidor de versiones de la central que le pasará:

Los posibles cambios de configuración.


La sincronización de fecha y hora. Verificará que la versión que le pasa el nodo es la última. Si no es así se lo notificará,

Para realizar el movimiento de las versiones entre la central y el nodo, hay varias soluciones:

Que el servidor de carga de archivos comunique con un servidor de archivos de la central se envíe las nuevas versiones a través del servidor de correo.

Aprovechar una arquitectura de procesador distribuido parecida a la que hemos visto anteriormente.

En cualquier caso debe arbitrase una forma, normalmente la consulta de las colas, para saber si los procesos de transporte y carga se han acabado ya, La consistencia se resuelve con los siguientes criterios.

Si el servidor de arranque no responde, se trabajará con la última versión registrada en el nodo.

Si el servidor de versiones de la central no responde, se supondrá que no hay nueva versión.

Si pasado un time out no han llegado los ficheros, se arranca también con la última versión.

Aunque en el ejemplo se plantea, para simplificar el esquema, que es en el arranque de cada programa cuando se verifica la versión contra la central, la forma habitual de hacerlo es que sistemática un agente verifique todos los cambios de versión contra la central y los actualice sobre el nodo. El agente ocupa el lugar del servidor de arranque y puede incluir el servidor de carga de archivos. Un semáforo puede avisar que hay una actualización en curso. El mismo agente puede gestionar la entrada en vigencia o dejar esa función para el arranque de cada uno de los programas tal como se ha planteado en el ejemplo. En la figura inferior se muestra una posible arquitectura de un servidor de versiones para gestionar, en la especificación que hemos planteado, la actualización de los puestos clientes contra del servidor de nodo.


ArranquePrograma

BDServidorArranque

ClienteBD

ServidorProgramas

Servidorde fecha y hora

Versiones datos y

programas

Programas

Fecha y Hora

DatosProgramas

Copias XML de datos básicos

ArranquePrograma

XML

ClienteXML

Fecha y Hora

Emergencia

D

T

Cliente

Cliente

Servidor del nodo

Figura 306. El servidor de versiones de los puestos cliente.

Los programas cliente que trabajan contra la base de datos tienen un comportamiento básicamente parecido. En los programas cliente en los que se ha previsto consistencia por XML, se regrabarán en esos ficheros XML cada vez que haya cambios. En caso de caída del servidor del nodo, el programa cliente trabajará contra los ficheros XML en lugar de contra la BD.

5. La actualización a través de Internet, Otra opción para montar esta arquitectura es la conocida actualización a través de Internet, disponiendo un servicio que avise al cliente que hay nuevas versiones disponibles y dejando al usuario la responsabilidad de hacerlo. Esta solución en un sistema distribuido administrado debe gestionarse con muchas precauciones que puede conllevar inconsistencias de versión entre los nodos. Si se utiliza, debe asegurarse que cuando el agente avisa al usuario de la nueva versión realmente puede actualizarse. No está demás prever la opción de forzar el cambio de versión no permitiendo al programa trabajar en caso contrario.

6. Generalización. Le recuerdo que hemos querido hacer un ejemplo. Como puede ver, esta arquitectura es totalmente adaptable a las diferentes funciones y arquitectura de niveles que pueda tener cada plataforma en concreto por lo que sería un buen ejemplo que la pensara y adaptara para caso concretos que le son conocidos.


7. Arquitectura de replicación, Recuerde también que en le capítulo dedicado a la replicación de datos es han visto técnicas que permiten montar lo servidores de programas por replicación ya que un distribución de versiones no es más que un caso especial de replicación.

@EMG/10 - Enric Martínez Gomàriz 475

Técnicas de diseño por Modelos de Aplicación.

1. Cuadro de técnicas por modelos de diseño. Simplemente, déjeme presentarle en un cuadro resumen de técnicas se emplean en cada caso.

Modelo de Diseño Análisis Funcional

Arquitectura Distribuida

Análisis de Consistencia

Análisis de Administración

Presentación RAD No No tiene sentido No tiene sentidoDatos centralizados con lógica en los Clientes

RAD No No es necesario ya que solo hay consultas

No es necesario ya que la administración es centralizada

Datos centralizados actualizables y con lógica en los Clientes

RAD No Importante a pesar de que la mayoría de los casos no se hace

No es necesario ya que la administración es centralizada

Datos distribuidos con lógica en los servidores

RAD / Avanzado

Si Si Si

Datos distribuidos y con lógica en los Clientes

Avanzado Si Si Si (fundamental)

Tratamientos Distribuidos

Orientado a Objetos

Si Si Si

Procesos Distribuidos

Orientado a Objetos

Si Si Si


Interfícies Gráficas de Usuario

1. Introducción. El diseño de la Lógica de Presentación no es un tema de diseño distribuido. Existe diseño distribuido sin interfícies gráficas. Si en este momento de su lectura no he sido capaz de convencerle, he fracasado en mis objetivos básicos. Sin embargo, es indudable que la mayor parte de las aplicaciones distribuidas acaban fabricando clientes que interactúan con los usuarios mediante interfícies gráficas. Y es también un hecho ineludible que en la mayoría de los casos, la lógica de presentación implementada en la interfície es, simplemente, inexistente. Y el grado de reutilización cero. Su construcción se reduce a “tirar” los componentes sobre un contenedor de objetos gráficos. Por todo ello, creo que sería un grave error proponerle una metodología de diseño de aplicaciones distribuidas sin hacer una propuesta de diseño de interfícies gráficas que prevenga contra los dos males, no estar diseñadas y no generar componentes reutilizables. Vamos a plantear el tema en dos partes:

Presentación del concepto de interfícies gráfica y de sus componentes. Si Vd., amigo lector domina el tema, sálteselo. No intentaré ser exhaustivo ya que controles los hay de todo tipo y color. Solo hablaré de los habituales a efectos de apoyarme en ellos para presentar las ideas básicas objeto de esta breve excursión opcional en nuestro viaje.

Diseño de la lógica de presentación. En este, si domina el tema, haga una lectura rápida para comparar sus ideas con las mías.

Y un comentario previo para la lectura estos capítulos. Recuerde me comentario incluido en la presentación de esta segunda parte sobre las capturas de pantalla que encontrará para ilustrar los ejemplos hay muchas versiones anteriores de Windows. Por favor, no piense por ello que el mensaje está anticuado. No confunda la forma con el fondo. Simplemente, un día me cansé de trabajar inútilmente actualizando la imagen a cada cambio de versión del sistema operativo.

2. Qué es una Interfície Gráfica de Usuario. Por Interfície Gráfica de Usuario (IGU en castellano) o Graphic User Interface (GUI en inglés, y abreviación que yo utilizaré) es una forma estandarizada, inventada por Apple y extendida y popularizada por Windows, de interactuar con los usuarios para pedir datos y decisiones y proporcionarle resultados. Como Vd. las conoce perfectamente, solo quiero remarcar sus características básicas:


Utilización de componentes visuales con comportamiento estandarizado y conocido por todo el mundo, lo que ahorra costosos esfuerzos de documentación y formación de usuarios.

Alta calidad de presentación. Facilidad de programación y utilización. Uso exhaustivo del Mouse.

Las GUI’s están basadas en la técnica de enseñar y escoger. Ofrecen gran número de ventajas al usuario:

Pueden visualizar diferentes tipos de información simultáneamente. Permiten a los programadores implementar un nivel de comunicación con el usuario muy alto que le ayuda a conocer mejor en todo momento lo que ha de hacer y lo que recibe.

La utilización de botones, menús y listas desplegables permiten realizar mejor y de forma más sencilla tareas de control y diálogo.

Le evita tener que aprender una operativa de comunicación diferente para cada aplicación.

La utilización de componentes visuales facilita la navegación y aumenta la eficacia, reduciendo la utilización del teclado a la entrada de datos.

Es importantísimo recordar una característica básica ya citada en otros puntos de este libro: la gestión de una GUI es transaccional. El usuario prepara el trabajo navegando por la GUI, acepta o cancela el trabajo, el programa procesa la entrada y presenta los resultados; el usuario los estudia y navega para preparar el siguiente ciclo. Una GUI es, en el fondo, un contenedor de objetos gráficos integrados por una lógica de presentación. Este contenedor recibe diferentes nombre según los lenguajes, pero existe en todos. Y no es solo una ventana, también es, como veremos más adelante, una integración que puede insertarse en bloque en otro contenedor, ventana o no.

3. Elementos de una Interfície Gráfica. Los elementos o componentes de una interfície gráfica son perfectamente conocidos por Vd. En la pantalla le presento una ficha con los componentes básicos, sin más objetivo que unifiquemos nomenclatura para todo lo que sigue en este capítulo y el siguiente.


Los elementos de una GUI se obtienen y sitúan a partir de Generadores de Recursos, que son herramientas que permiten a los programadores definir interactivamente y con gran facilidad la parte gráfica (componentes visuales) de una GUI. Pero, ¿hay otra parte, además de la gráfica, en una GUI? ¡Claro que sí!, el diseño de la lógica de presentación. La gran facilidad aportada a por los generadores de recursos es la causa, en manos inexpertas claro está, del mal diseño de las GUI’s. ¡Es tan fácil tirar los componentes sobre el contenedor gráfico nada más empezar y sin diseñar nada! Estos recursos tienen, como ya se ha dicho, un formato y comportamiento estandarizado y conocido por programadores y usuarios. Todos los entornos de programación aportan uno que permiten gestionarlos estática, instanciados de entrada, o dinámicamente, instanciados en fase de ejecución según las necesidades del programa. No desprecie esta potente opción de programación que puede permitirle cosas “muy guapas”, como personificar la GUI en función del contexto de la aplicación en cada momento de la ejecución. Todos los componentes son Objetos y conocer los fundamentos de OO para gestionar GUI’s no es imprescindible, pero si muy útil para conseguir reusabilidad y aprovechar al máximo las posibilidades de esos componentes. En este contexto, dejo una pregunta en el aire: ¿cuantos diseñadores y programadores de interfícies gráficas tienen conocimientos mínimos (de verdad) de OO? Según la respuesta que dé a esta pregunta entenderá muchas cosas...

4. Tipos de Ventanas. Las ventanas son el contenedor final de la GUI. Existen diferentes tipos de ventanas con contenido semántico diferente. No creo necesario hablar de ventanas pero si de sus tipos y uso. 4. 1. Principal (Main).

Es la ventana asociada al programa principal. Se instancia automáticamente cuando el programa arranca, personificándose antes de la primera interacción del programa con el usuario.

4. 2. Hija (child).

Aplicación

VentanaPrincipa

Ventana Hija

Controles

Botones deredimensionamientoMenú de

control

Extremos deredimensionamiento

Aceleradoresde teclado

Menú de Conexto

Menú de usuario

Figura 307. Componentes de una interfície gráfica de usuario


Se llaman desde otra ventana, referenciada como madre, y que no es necesariamente la principal. Le recomiendo que no abuse de una jerarquía demasiado profunda, puede crear confusión en los usuarios. Se cierran automáticamente cuando se cierra la madre. Pueden desplazarse fuera del área de la madre. Suelen utilizarse para iniciar un proceso de detalle que puede convivir con otros procesos de detalle iniciados desde la misma ventana madre. Poder desplazarlas fuera de la madre ayuda a tener a la vista más de una simultáneamente. Una alternativa válida es personificar una zona de una única ventana en función del estado del flujo de diálogo.

4. 3. Pop-Up. Son ventanas que se abren también dentro de la madre pero no pueden salir de su interior. Cuando se cierra la madre se cierran todas las Pop-Up abiertas. Su utilización es literalmente jerárquica: no hay que volver a la madre hasta que se ha acabado el trabajo para el que se ha iniciado la hija.

4. 4. Response. Son ventanas Pop-Up que cogen en exclusividad del “foco” de la aplicación; dicho de otra forma, el usuario solo puede interactuar con ellas. Se utilizan para diálogos en los que no se puede seguir sin que el usuario los cumplimente. Un ejemplo habitual es las elecciones entre diversas opciones, las cajas de elección de archivo y las de informe y solución de errores.

5. Controles. Son los objetos visuales integrados en la GUI. Los hay de dos clases:

Activos: suponen gestión del usuario. Son ejemplos de controles activos botones, listas despegables, check-box. etc.

Pasivos, u objetos de dibujo (Drawing Objects): se utilizan sólo para hacer la GUI más atractiva y dividirla por zonas operativas. No generan eventos. Son ejemplo de controles de este tipo textos, líneas, rectángulos, círculos, etc.

Una de las grandes aportaciones de Windows fue la estandarización de los controles más habituales, y, aunque hay diferentes controles según las herramientas de diseño utilizadas, los fundamentales se comportan y se usan igual en todas ellas. Los controles, implementados siempre por una clase OO quedan definidos, como cualquier otra clase por: Un estado a través de los valores de sus atributos. Un comportamiento a través de sus métodos y de los eventos que es capaz de producir. Hay unos atributos que son comunes a todos los controles: control, tamaño, posición, visibilidad, activo o no, etc. Y otros que son específicos a cada control. La


gracia de los comunes es que puede tratarse independientemente del tipo de control. Una especial atención merece los atributos visible y activo (enabled). Un control puede estar visible o no, según convenga; si se pone no visible, desaparece de la GUI. Un control puede estar activado o no. Si está activado puede recibir instrucciones del usuario; si no está se muestra, generalmente en gris, pero no se puede gestionar. Los atributos de un control suelen ser públicos pero tener además métodos que los gestionan. Un ejemplo habitual es el atributo visible, que tiene los métodos hide() para esconderlo y show() para hacerlo visible. La disponibilidad de los atributos desde los programas permite una cosa que, a mi juicio, es peligrosísima: se puede tocar sin control de la clase. Sea precavido con este hecho y utilice, siempre que le sea posible, los métodos en lugar de leer o modificar directamente los atributos. La utilización de estos dos atributos permite personalizar GUI’s escondiendo información no autorizada a un usuario y dejar no disponibles opciones que según el contexto del momento no se pueden pedir o modificar. Además pueden ayudarle a navegar con mayor comodidad por la pantalla. Colocando el control visible y no activo se puede mostrar información a usuarios que no pueden modificarlas Otro concepto interesante en el de “control que tiene el foco”, es decir, el control que en ese momento recibe la acción del usuario. El foco puede cambiarse de diferentes formas:

Con el Mouse. Con la tecla TAB. Forzándolo directamente por programa.

El concepto de foco también es aplicable a la ventana que está recibiendo en ese momento la acción de usuario. Los eventos más comunes de un control son:

Clicked, cuando el control es marcado por el botón del Mouse. Puede ser generado con doble o simple click o por el botón izquierdo (lo estándar), central o izquierdo del Mouse.

Getfocus, cuando el control recibe el foco. LoseFocus, cuando el control pierde el foco. Drag&Drop, cuando el control es arrastrado y soltado sobre otro. Hablaremos más tarde de estas técnicas.

Vamos a exponer a continuación los más habituales, no para enseñárselos, que seguro ya los conoce, sino para repasar su comportamiento básico y utilización. 5. 1. Botones (Command Button).

Cuando se les pulsa, producen un evento dentro del cual, normalmente, se dispara una acción. Normalmente se agrupan para cubrir todo el abanico de una elección.


5. 2. Botón de imagen (Picture Button).

Tienen un comportamiento igual que los anteriores pero en el interior en lugar de un texto hay una imagen. Suelen usarse de forma estática en las ventanas para permitir al usuario opciones que puede ejecutar en cualquier momento.

5. 3. RadioButton. Son controles que tiene dos estados: seleccionado o no. Representan opciones que se excluyen mutuamente. Siempre se presentan en grupos dentro de un GroupBox. Nada más que un botón es seleccionable dentro de cada grupo; la selección de uno supone la no selección automática de todos los demás. El usuario clikea con el Mouse el que le interesa y el programa los consultan cuando lo necesita.

5. 4. CheckBox. Son utilizables de forma parecida a los RadioButton pero se puede seleccionar más de uno simultáneamente. Representan opciones que pueden pedirse al mismo tiempo, y que sólo se agrupan a efectos de claridad. Normalmente sólo se trabajan dos estados: seleccionado o no, pero puede existir un tercer estado que indica indefinición de la opción o no disponibilidad en ese momento de control.-

5. 5. Lista desplegable (ListBox). Tienen diferentes formatos, pero en el fondo, todos tienen el mismo comportamiento. El programa carga, estática o dinámicamente una lista de valores entre los cuales el usuario ha de escoger una.

5. 6. Línea de edición (SingleLineEdit).

Permiten gestionar una línea de texto por el usuario. Pueden trabajar simultáneamente con el portapapeles. El usuario dispone de los recursos de edición habituales en la gestión de textos de Windows.

5. 7. Línea de edición múltiple. Se comportan de forma parecida a los anteriores pero permiten editar más de una línea. Conjuntamente con las barras de desplazamiento permiten gran flexibilidad para gestionar textos del tamaño muy grande, aunque en la práctica tengan un límite de tamaño.


5. 8. Barras de desplazamiento. Se utilizan normalmente junto a otros controles para indicar al usuario que la información no cabe en la zona “visible” del control. Su utilización permite al usuario desplazar la zona visible del control por toda la información contenida en él Pueden hacerse servir también de forma autónoma para escoger un rango de valores. Recuerde que el desplazamiento tiene dos ritmos: lento (línea en textos) y rápido (página en textos).

5. 9. Pestañas (TabSet). Permite agrupar un conjunto de vistas relacionadas entre sí y hacerlas accesibles de una en una utilizando pestañas. Un uso muy habitual en la agrupación de las diferentes posibilidades de los parámetros de una parametrización.

5. 10. Rejillas (Grids). Hay rejillas de muchos tipos, pero la idea de las rejillas es proporcionar un componente de imagen y utilización parecidas a las de una hoja de cálculo. La información se organiza en una matriz donde cada celda proporciona una unidad de información. Es la imagen habitual de una hoja de cálculo.

5. 11. Cajas de Diálogo. Son objetos visuales construidos por integración de otros más simples y que se utilizan para informar al usuario de acontecimientos y darle opción de elección entre las diversas opciones que ese acontecimiento da.

Una clasificación interesante de los controles es por el uso que se hace de ellos:

Controles que inician acciones: CommandButton PictureButton

Controles que gestiona datos. ListBox StaticText SingleLineEdit MultiLineEdit Grids. Tabset.

Controles que indican elección. RadioButton CheckBox

Controles para decorar. Drawing Objects


6. Menú. Ya sé que Vd. sabe que es un menú. Sólo quiero unificar terminología. Los menús son listas de comandos u opciones (menu items) entre las que el usuario puede escoger. A cada opción del menú se le asigna una acción. Los menús pueden anidarse jerárquicamente (menús desplegables). Cada opción del menú puede estar, según la necesidad del momento:

Seleccionada. No seleccionada. Deshabilitada.

Existe la posibilidad de definir teclas de aceleración asociadas a un ítem de un menú y que provocan la misma acción que la selección por el Mouse. Existen menús de contexto, es decir, menús que activados por el botón derecho del Mouse sobre un objeto, proporcionan la lista de opciones que el usuario tiene sobre ese objeto.

7. Los mensajes. Unos de los elementos importantes en una GUI y por otro lado uno de los que menos se racionalizan son los mensajes. Existen mensajes de varios tipos: 7. 1. Indicadores de acción.

Informan al usuario que un proceso ligado a una acción se ha iniciado. Están basados normalmente en un texto.

7. 2. Indicadores de progresión. Basados en un componente gráfico, indican al usuario el avance de un proceso de larga duración. Es importante que “se muevan” ya que su seguimiento dará al usuario menos sensación de espera. Hoy día encontrará componente de progresión ya prefabricados y muy espectaculares que podrá incorporar a sus GUI’s sin costes de desarrollo adicionales. Recuerde que en procesos largos:

Deben deshabilitarse el resto de opciones. Debe darse siempre opción de cancelación.

7. 3. Mensajes informativos.

Informan al usuario del resultado de la ejecución de una acción a conjunto de acciones. Se basan en un texto o en un una caja de diálogo cuando interesa


que el usuario informe a la GUI de forma explícita que conoce que el proceso se ha realizado.

7. 4. Mensaje de Aviso. Informan al usuario de que un proceso delicado comienza y le pide confirmación. Por ejemplo, cuando se lanza un proceso que puede suponer perdida de información (una baja de fichero por ejemplo), de pedirá confirmación al usuario. Se basan normalmente en una caja de diálogo. No conviene abusar de los mensajes de aviso porque se genera en el usuario el efecto contrario, inseguridad antes los efectos que una respuesta equivocada a tanta pregunta puede causar.

7. 5. Mensajes de Error o Anomalía. Informan al usuario de que un error o una situación excepcional se han producido. El usuario ha de realizar acciones para recuperar (sí es posible) el error o la anomalía. Se gestiona normalmente con una caja de diálogo en que cada botón corresponde a una posible acción. Con viene añadir un botón de ayuda con las diferentes posibilidades de que el usuario dispone.

8. Técnicas Drag&Drop. Permiten simulaciones gráficas basadas en:

Coger con el Mouse un objeto visual. Arrastrarlo sobre otro. Dejarlo caer sobre él.

Esta simulación gráfica permite representar acciones de forma muy intuitiva: copia de un fichero de un directorio a otro, pasar contenido de un objeto de edición a otro, etc. Arrastrar un control sobre la GUI habilita en todo momento un mínimo de dos objetos visuales, controles o no:

El Drag Control, que es el que se está arrastrando. El Target, que es el control sobre el cual está pasando el anterior.

Cuando el objeto visual se coge, se activa un Drag Icon que representa al objeto que se empieza a arrastrar. La gestión del proceso se controla mediante los Drag Events:

DragDrop Even, cuando el Drag Icon está sobre el Target y se suelta del Mouse.

DragEnter Even, cuando el Drag Icon entra dentro de los límites del Target. DragLeave Even, cuando el Drag Icon deja los límites del Target.


Identificación de Objetos Visuales y Diseño Tecnológico de GUI’s.

1. Introducción. La programación de GUI’s se ha hecho tradicionalmente de forma anárquica: los objetos visuales se colocan sobre los contenedores con criterios únicamente estéticos. Sin menospreciar el alto valor de la estética aportada por el diseño artístico de la GUI, lo primero que se ve, éste no debería ser el criterio único. Mi objetivo en este capítulo es hacer apostolado en este sentido. Vamos a ver:

Cuales son los objetos identificables. Cuales son sus atributos y métodos habituales. Como se construyen objetos derivados. Como se combinan entre los objetos visuales. Criterios de diseño tecnológico.

Por criterios docentes, me parece importante venderle primero la importancia de diseñar bien el tecnológico de la GUI, he puesto este capítulo antes del de diseño funcional de la GUI que trataremos en el capítulo siguiente. Me parece fundamental convencerle de que debe trabajar bien antes de presentarle los criterios funcionales que le permiten componer tecnológicamente las GUI’s.

2. Objetos Visuales y Orientación a Objetos. La implementación de objetos visuales se hace siempre por OO. De este tema ya hemos hablado anteriormente y voy a intentar no repetirme. Sin embargo quiero hacer un recordatorio de varios puntos que me parecen básicos antes de continuar:

Las herramientas de desarrollo que aportan objetos visuales todas son OO. Los conocimientos OO necesarios para tratar los objetos visuales según este paradigma son mínimos y conviene saberlos para programar GUI’s.

Si además se saben técnicas de herencia y polimorfismo, y se aplican, la calidad, visual, operativa y reutilizable, es enorme.

3. Identificación de Clases Visuales relacionadas con una GUI. Si examinamos e intentamos identificar clases de objetos visuales con el criterio estándar de identificación clases OO, obtenemos una jerarquía de clases del estilo que se muestra en la figura:


Esta jerarquía se concreta en cada entorno de una forma determinada pero siempre existe. Trabajaremos con esta simplemente para poder concretar la explicación. Todos las clases proporcionan los habituales atributos, métodos y eventos comunes a todos los objetos visuales de los que ya hemos hablado en el capítulo anterior y que no voy a repetir aquí. Relacionaré a continuación las clases identificadas y sus atributos y métodos diferenciales de su estado y su comportamiento. 3. 1. Aplicación.

La clase aplicación es la que implementa el programa que contiene la GUI. Recibe diferentes nombre según el lenguaje o la forma del programa: Aplication en PowerBuilder, Formulario en DELPHI, etc. Evidentemente esta clase es bastante más que un objeto visual, pero sea cual sea su implementación, si el programa ha de interaccionar con el usuario, siempre aporta o se asocia un contenedor GUI de objetos visuales donde el programador colocará los objetos gráficos especializados que van a forma la GUI. Este contenedor suele estar ligado a una ventana principal que es a la que la aplicación pasa control una vez arrancada. Desde esta ventana principal se desencadena todo el diálogo GUI. Además de los métodos, atributos y eventos necesarios para gestionar y controlar la ejecución de la aplicación, esta clase proporciona:

3.1.1. Atributos. • Nombre y titulo. • Contenedor GUI. • Lista de Eventos.

3.1.2. Métodos.

APLICACIÓN• Nombre• Contenedor GUI • Ventana principal. • Cola de eventos.• Iniciador de aplicación• Gestor del Contenedor

GUI.• Gestor de la instancia• Gestor de Eventos.

OBJETO VISUAL• Nombre• Posición.• Padre• Atributos visuales• Visible y habilitado.• Dibujo e inicilización• Obtener atributos• Gestión de hijos• Relación con el padre• Gestión atributos visuales• Sistema gestió eventos

ACTIVO

EDICIÓN• Contenido

• Inicialización contenido• Utilización per el usuario• Tomar estado• Relaciones con el

portapapeles• Dibujo

CAJA SELECCIÓN• Contenido.• Valor selecciondo.

• Gestión de la selección• Selección por el usuario• Dibujo

MENÚ• Nombre• Descripción• Padre

• Notificaciones de selección

• Gestinó del estado de las opciones

• Dibujo

BOTÓN• Estado de selección

• Gestión de selecció• Dibujo

PASIVO

FIGURAUna subclase por

figura

• Dibujo

TEXTO

• Dibujo

ICONO• Nombre• Descripción

• Dibujo

VENTANA• Titulo.• Tipo de ventana.• Menú de control.• Menú de contexto.• Consulta y modificación

del titulo.• Gestión de la dimensión

con los botones de redimensionamiento.

• Gestión de los menús de principal y de contexto.

CONTROL MENÚ DECONTEXTO

MENÚPRINCIPAL

Figura 308. Identificación de Clases Visuales.


• Iniciador de aplicación. • Gestor del Contenedor GUI • Gestor de la ejecución de la Instancia. • Gestor de Eventos.

3. 2. Objeto Visual. Existe una jerarquía formada por todos los objetos visuales que hemos visto en el capítulo anterior. En la cima de la jerarquía está una clase genérica de objeto visual. En esta clase se engloban todos los atributos y métodos comunes a cualquier objeto visual:

3.2.1. Atributos. • Nombre • Posición. • Atributos visuales: Tamaño, Color, Fuente, Fondo etc. • Visible y habilitado. • Objeto padre

3.2.2. Métodos. • Dibujo e inicialización. • Obtener atributos • Gestión de hijos • Relación con el padre • Control de estado • Gestión de los atributos visuales • Sistema gestión eventos.

3. 3. Especializaciones de la Clase Objeto Visual.

Existen dos especializaciones de esta clase:

3.3.1. Ventana. Es la clase que implementa este tipo de componente visual. Aporta:

3.3.1.A. Atributos. • Título. • Tipo de ventana. • Menús principales y de contexto.

3.3.1.B. Métodos. • Consulta y modificación del titulo. • Gestión de la dimensión con los botones de redimensionamiento. • Gestión de los menús principal y de contexto.

3.3.2. Control.


O simplemente control. Tiene las dos especializaciones que ya hemos visto: control activo y control pasivo.

3. 4. Control Activo. Tiene diversas especializaciones genéricas enfocadas por su utilidad.

3.4.1. Clases de Edición.

Como líneas de edición simples y múltiples, rejillas, etc. Dispone de atributos para implementar el contenido y de métodos para consultarlo y modificarlo y para interaccionar con el portapapeles.

3.4.2. Botones. Para pedir acciones.

3.4.3. Cajas de selección. Para elegir entre opciones: listas desplegables, radio botones, checks box, etc. Obviamente, este último nivel de especialización puede tener variaciones en su jerarquía y diferentes especializaciones según la herramienta. Sin embargo, observe que en todos los casos, la clasificación existe y es muy parecida.

3. 5. Control pasivo. Tienen dos especializaciones por su contenido:

3.5.1. Textos.

3.5.2. Figuras.

3. 6. Iconos. No hace falta recordar que los iconos se utilizan para representar otros objetos, visuales o no.

3. 7. Menús. Con dos especializaciones:

3.7.1. Menú principal. Asociado normalmente a ventanas.

3.7.2. Menú de Contexto. Asociado a otros objetos para orientar al usuario sobre las opciones disponibles sobre él.


4. Programación de interfícies gráficas. La inmensa potencia y facilidades que aportan las herramientas de desarrollo para crear interfícies gráficas se convierten en manos inexpertas o poco profesionales en una trampa mortal. En efecto, esas personas confunden el diseño de las GUI’s con coger de las paletas los componentes gráficos y tirarlos sobre el contenedor, haciendo la distribución estética antes de atacar a fondo el comportamiento. La gravedad de las consecuencias de este acto irresponsable es inmensa. Las tres consecuencias fundamentales y trágicas son:

Grado de reusabilidad de las GUI’s = 0. La misma vista de una entidad, por ejemplo producto, se programa tantas veces como programas la usan aumentando desmesuradamente los costes y los plazos de desarrollo.

La estandarización de semántica y uso de las GUI’s brilla por su ausencia, complicando la vida a los usuarios y al personal de soporte.

La tercera consecuencia es la bajísima calidad del diseño interno de los programas que dificulta enormemente su mantenimiento y ampliación.

Para solventarlo sólo hay dos antídotos: Diseñar la GUI antes de sentarse a programarla, tema que trataremos en el capítulo siguiente.

Utilizar a fondo las técnicas OO para construir a partir de los objetos básicos otros objetos derivados que encapsulen comportamiento y visión y que puedan reutilizarse.

En esta última línea resulta fundamental del concepto de objetos visuales derivados que vamos tratar a continuación.

5. Objetos visuales derivados. A partir de los objetos visuales simples pueden construirse otros que encapsulen comportamiento y visión. Existen dos formas básicas de hacerlo. 5. 1. Especialización.

La técnica de la especialización consiste en derivar por herencia un componente visual de otro, estándar o derivado, para:

Especializar su comportamiento. Por ejemplo, puede especializar una lista desplegables para que muestre la lista de los productos de su empresa.

Aumentar su visión. Es decir, puede hacer cosas más complejas, como derivar de una vista general de productos otra que visualice las materias primas; o los productos de venta.

Ampliación

Objecto Visual

Nuevo Objecto

Función básica

Definir objectos visuales con

comportamientos especializados

o visión ampliada

Figura 309. Derivación por especialización.


5. 2. Integración.

La derivación por integración consiste en agrupar objetos visuales para definir otro de mayor complejidad que visualiza, normalmente, una entidad. Por ejemplo, Vd. puede construir una vista de un cliente agrupando en un componente visual derivado todos los objetos visuales que representan cada uno de los atributos. Permítame, dentro de la línea de apostolado pro buen diseño de GUI’s, insistir en las ventajas de reutilización y estandarización que trabajar así comporta. A partir de aquí, las posibilidades son inmensas:

Puede esconder atributos, poniendo no visibles sus correspondientes objetos visuales, si el usuario identificado no tiene permisos para verlos.

Puede colocar todo el componente derivado en modo no habilitado (que mal suena, me sigue sonando mejor not enable).

Permitir solo modificar los atributos sobre los que tiene derechos el usuario, etc.

6. Composición de Objetos Visuales. Una GUI puede modelarse desde una perspectiva OO como una composición representada por un modelo conceptual de objetos como el de la figura. A una aplicación puede asociarse o integrarse un icono. La aplicación integra una ventana principal. Desde esta ventana se puede navegar por otras normalmente agrupadas pero también en ocasiones relacionadas. Una ventana puede integrar un menú principal. La ventana es una agrupación de controles u objetos derivados. Un objeto derivado es la agrupación de otros estándares o derivados. Y un objeto puede tener asociado un menú de contexto. Etc, etc, etc.

Integración

Objecto Visual

Nuevo ObjectoFunción básica

Agrupación de uno o más elementos pera

definir un nuevo objecto visual que los gestione como

un todo. En particular, integrarlo como componente

de otro

Objecto Visual

Figura 310. Derivación por integración.

VENTANA

1,1

MENÚ

0,n0,n

MENU CONTEXTO

0,1

ICONO

0,1

CONTROL

0,n 0,n

1,0 0,1

0,n

OB.DERIVADOS

APLICACIÓN

Figura 311. Modelado de una GUI.


7. Recomendaciones. 7. 1. De uso de los objetos.

Utilícelos siempre que sea posible (¿siempre?) a partir del modelo: tendrá independencia de muchas cosas.

Asocie la terminología de objetos visuales de su herramienta de desarrollo al modelo general.

Utilice a fondo la técnica derivar objetos para encapsular comportamiento y operativa y mejorar la claridad del código.

Asocie objetos derivados a las entidades. Definir un objeto que modele el enviroment que se integre en la GUI de forma que todos los objetos integrados lo tengan disponible. Se instanciará en el constructor de la GUI.

7. 2. De tratamiento de los eventos.

Asociar la gestión de cada evento a un método, de la GUI o de sus componentes. Primar fuertemente, y en aras de la reutilización, la integración de esos métodos en los objetos visuales. La gestión de evento simplemente la llamada al método.

Definir en cada objeto visual derivado, y de forma general, cuales son los eventos que puede recibir y enviar, y que respuesta hay que dar a cada evento interno.

Si se crean subclases, establecer en cada subclase cuales de ellos se tratan y como. Para ello, en la llamada al método se usará un mecanismo Evento - Condición - Acción (ECA).

8. Una reflexión final. Vd. puede estar muy o poco de acuerdo con este modelo conceptual de Interfícies gráficas. Respeto su opinión. Lo único que he pretendido es explicarle mi visión de un posible modelo y, por encima de todo, forzarle, si no lo ha hecho nunca, a meditar que el diseño tecnológico de una GUI no debe ser anárquico sino organizado y estructurado para conseguir fuertes cotas de reutilización y de normalización de uso y operación.


Diseño Funcional de la Lógica de Presentación.

1. Introducción. Como ya hemos dicho retiradamente aquí, la lógica de presentación se representa hoy día con una GUI. Y esa lógica ha de ser diseñada funcional y tecnológicamente. En el capítulo anterior hemos hablado del diseño tecnológico. Vamos a abrir aquí del funcional.

2. Diseño funcional de interfícies gráficas. El diseño funcional de la lógica de presentación lleva al paradigma de la comunicación visual. Es fundamental tener presente que:

La interfície gráfica (GUI) desarrolla un modelo conceptual de como el usuario trabaja con la aplicación.

El flujo del diálogo ha de ser controlado por el diseño. El usuario marca la iniciativa. Eso hace que la GUI ha de cerrarle los caminos no válidos.

La presencia de ayudas es muy útil. Siempre que sea posible, hay que dar al usuario la posibilidad de deshacer una acción errónea.

3. Elementos del diseño funcional. 3. 1. Perfil.

Identifica un rol dentro de la aplicación, cuales son los derechos y cuales las restricciones.

3. 2. Identificación de usuario. El usuario ha de identificarse para definir claramente cual es su perfil y, por tanto, su rol de derechos y restricciones.

3. 3. Metáfora o Analogía. El modelo que la GUI implementa ha de ser claro para el usuario.

3. 4. Modelo de Conocimiento. Los datos, funciones, tareas y perfiles han de ser organizadas de forma correcta, respetando en todo momento los perfiles del usuario identificado. Se


dice así, que la GUI implementa el modelo de conocimiento que el usuario ha de obtener de la GUI.

3. 5. Ergonomía.

Ha de existir un esquema eficiente de navegación por los componentes de la GUI.

3. 6. Imagen (Look).

La presentación ha de ser de calidad. La relación imagen / tiempo de desarrollo ha de ser correcta (otra vez este ratio tan complicado de establecer).

3. 7. Comodidad. La interacción ha de ser cómoda, agradable y efectiva para el usuario.

3. 8. Técnicas gráficas disponibles.

Objetos visuales de las herramientas de desarrollo. Normas de formatos, ventanas, proporciones, etc. Criterios tipográficos: tipos de fuentes, tamaño, colores, etc. Las imágenes que se utilizan: signos, iconos, etc. La secuencia de navegación por la pantalla y la organización de los controles.

Las técnicas de animación para la visualización dinámica. Técnicas para hacer consistente la interfície gráfica.

4. Principios Básicos del Lenguaje Visual. 4. 1. Organización.

Proporciona al usuario una estructura conceptual nítida, consistente y navegable.

4.1.1. Principio de consistencia. Utilizar reglas de organización de los diferentes objetos visuales y establecer relaciones nítidas entre ellos con el fin de ayudar al usuario en la navegación por los diferentes componentes de la interfície gráfica. Es fruto de la unión de cuatro factores:

GUI estructurada

GUI no estructurada

Figura 312. Principio de Consistencia.


4.1.1.A. Interno. Garantiza que se mantienen las mismas normas y criterios para todos los elementos de la GUI.

4.1.1.B. Externo. Considerando la Plataforma GUI que estamos haciendo servir (en la mayoría de los casos el Windows o Internet) y las consideraciones culturales dominantes, hemos de hacer servir los mismos signos para los mismos mensajes visuales.

4.1.1.C. Los referentes al entorno del mundo real. En la composición del mensaje visual pueden, y deben, utilizarse objetos, procesos y eventos que son familiares y que forman parte de su cultura y experiencia visual. Por ejemplo, si se arrastra un producto que ha ocupar la posición de ser un envase, el icono utilizado puede ser una botella.

4.1.1.D. Inconsistencia. Las desviaciones de la norma, en algunos casos, pueden aportar un valor añadido muy claro al usuario. Particularmente, no soy muy partidario de este criterio si la contrapartida no es extraordinariamente clara. En muchas ocasiones, la necesidad de la inconsistencia es solo aparente y se debe a una operativa no suficientemente estudiada.

4.1.2. Normas de visualización. La organización se refuerza siguiendo normas de visualización:

Agrupando los objetos visuales por grupos conceptuales y tipología. Normalizando la composición de objetos. Distribuyendo los objetos visuales sobre la base de sus posibles relaciones, evitando saltos en la navegación por la pantalla. Organizando correctamente el salto de un objeto al siguiente. Cerrando caminos inapropiados en función del estado de la GUI.

En pocas palabras, las relaciones entre los objetos han de ser claras, consistentes y apropiadas.

4.1.3. La composición espacial. La organización de la composición espacial ha de distribuir los elementos del mensaje visual en grupos principales y secundarios suministrando un foco inicial que fije la atención del usuario (atención directa) y los focos secundarios o periféricos que le ayuden en la navegación.

4. 2. Economía.


Consigue las máximas prestaciones con el mínimo de elementos visuales: máximo ratio de prestaciones / coste. El principio de la economía es la unión de diversos factores.

4.2.1. Simplicidad. Nada más se han de incluir aquellos objetos que son esenciales a la comunicación.

4.2.2. Claridad. Los componentes que se incorporen al mensaje visual no han de ser ambiguos.

4.2.3. Diferenciación. El mensaje visual ha de distinguir y remarcar todas aquellas propiedades más importantes de los componentes.

4.2.4. Énfasis. En un mensaje visual hay elementos importantes que se han de resaltar y hacer fácilmente distinguibles.

4. 3. Comunicación.

Ajusta el modelo y tipología de la presentación a las capacidades y formación de los usuarios.


4.3.1. Factores. Ha de buscar equilibrar diversos factores:

4.3.1.A. Legibilidad. Criterios escogidos para el diseño de los caracteres, símbolos y componentes visuales han de ser obvios y fáciles de distinguir para los usuarios.

4.3.1.B. Comprensibilidad. La visualización de la GUI ha de ser comprensible para el usuario, es decir, fácil de identificar e interpretar y tener, además, capacidad para captar la atención del usuario.

4.3.1.C. Utilización tipográfica. En al comunicación del mensaje visual es recomendable utilizar un número reducido de tipos de fuente, estilos y medida de los caracteres. Hacerlo así, hace la presentación de la GUI más descansada y agradable al usuario.

4.3.1.D. Simbolismo. La elección de iconos, símbolos, diagramas e imágenes fotográficas y/o dibujadas ha de ser cuidadosa para comunicar mejor el mensaje deseado. El simbolismo tiene un alto componente subjetivo. Cada organización, departamento dentro de la organización e, incluso, cada usuario puede tener preferencia por sus propios símbolos. Es evidente que la lucha debe ser por crear una cultura única. Los intentos toparan siempre de entrada con reticencias en los usuarios que han de cambiar. Sin embargo, la experiencia dice que rápidamente todo el mundo se acomoda al lenguaje común. Sea político, si tiene que escoger símbolos para unificar varias culturas, escoja un poco de todo; como ya le he dicho, lo importante en la unificación y la comprensibilidad, no el símbolo en si, ya que rápidamente todo el mundo se acostumbra. Conviene utilizar a fondo la cultura dominante y mantener una posición conservadora; con ello se facilitará que el usuario reconozca de entrada el contenido de una parte del mensaje visual y se identifique más fácilmente con él.

4.3.2. División del mensaje. Un mensaje complejo ha de ser dividido en varios de más simples o submensajes. La utilización de esta técnica no es ninguna trivialidad. El mensaje se ha de dividir en otros más simples con criterio coherentes, respetando siempre las unidades básicas del mensaje. Así,


una vista compleja de clientes puede dividirse en submensajes parciales que detallen direcciones, formas de pago, etc. Pero la división no puede dejar los atributos de la forma de pago en dos submensajes diferentes. Aquí las técnicas de derivar objetos visuales e instanciación dinámica son fundamentales.

La navegación entre los submensajes ha de ser coherente. El panel de presentación de los submensajes ha de ser muy cuidado. Se deben cerrar caminos erróneos. Aquí la utilización de los atributos habilitado y visible es fundamental.

4.3.3. Vistas múltiples.

Una de las técnicas más importantes para mejorar la comunicación en entornos gráficos es la utilización de vistas (perspectivas) múltiples en la visualización de estructuras y procesos complejos. Esta técnica ha de utilizarse en áreas como:

Los formatos de presentación. Los niveles de abstracción. La presentación de situaciones alternativas. Los procesos secuenciales. Las referencias cruzadas.

La utilización de perspectivas no debe abusar de cambio de la pantalla de foco lo que acabaría causando cansancio visual al usuario. Utilice hábilmente los atributos habilitado y visible, la gestión del foco e instanciación dinámica según la situación de objetos visuales derivados. Por ejemplo, si está gestionando materias primas, si el producto actual es una envase puede instanciar en una zona de la vista en objeto visual derivado que presente sus atributos diferenciales. Cuando la materia prima sea un líquido cambiará dinámicamente la zona de los atributos diferenciales. Complementando todo ello con imágenes e iconos que visualmente muestren que tipo de materia prima está en pantalla pueden conseguirse perspectivas con alto nivel de comunicación sin demasiado esfuerzo.

4.3.4. Color y textura. Es un factor muy complejo de la comunicación visual y tan subjetiva como el simbolismo. El color es una de las herramientas más potentes para la comunicación visual si se utiliza correctamente: la cultura dominante asocia el rojo a peligro o camino prohibido, el verde a adelante, el amarillo a precaución, el azul a relajación, etc. La utilización adecuada del color proporciona diversas posibilidades:

Poner énfasis en determinadas informaciones del mensaje. Por ejemplo, un crédito sobrepasado puede ponerse en rojo y uno muy cercano a cero en amarillo. Identificar estructuras y subsistemas.


Asignar los colores naturales a los objetos visuales. Así, si un líquido es verde, su símbolo será de ese color. Reducir los riesgos de interpretación. Un mensaje en rojo no deja lugar a dudas de que hay que tener precaución con algo. Se pueden aumentar los niveles de entendimiento, claridad y credibilidad. Se pueden simplificar los niveles de abstracción.

El uso incorrecto de estas técnicas puede llevar a efectos contrarios a los buscados: • Hay combinaciones de colores poco atractivas. Ojo con este factor

que es altamente subjetivo. • Algunos colores pueden causar incomodidad y provocar cansancio

visual. • Hay colores que pueden tener significado diferentes en diversas

zonas del mundo. Es conocido que el negro se asocia en occidente al luto y el blanco a la pureza y que oriente el blanco es el color el luto.

4. 4. Normativas y recomendaciones.

Utilice a fondo las normativas y recomendaciones dominantes, no invente si no es necesario. Facilitará la vida al usuario y a Vd. mismo ahorrándose formación y asistencia. Dentro de este apartado, que de hecho ya se ha ido citando en los anteriores, quiero remarcarle la importancia de una distribución lógica y coherente de las zonas de la pantalla. Cada mensaje debe ir en la zona adecuada. En la figura se muestra un ejemplo de una posible organización zonal de una pantalla. No intenta ser un axioma, sino solamente una motivación para que Vd. tenga en cuenta este principio de la comunicación a mi juicio fundamental.

4. 5. Los flujos de diálogo. Los flujos de diálogo entre el usuario y la GUI marcan el camino o caminos que el usuario debe seguir para completar una determinada tarea. Quedan determinados por las características de cada una de las aplicaciones. Pueden resolverse según dos modelos:

GUI’s tradicionales: modelos menú / botones para dar la elección, elección / petición del usuario y acción. Dos versiones:

Windows.

Área de TítuloControles de Ventana

Menú

Zona de acciones

Área cliente

Áreas de Desplazamiento

ÁreaInformátiva

Figura 313. División por áreas de una ventana.


Internet OOUI’s: modelo objeto, acción.

GUI’s es el sistema convencional que seguro Vd. conoce sobradamente. OOUI’s es un enfoque basado en la gestión de objetos visuales complejos. OOUI puede asimilarse a componente de presentación. Para mí no hay demasiada diferencias entre las dos técnicas si las GUI’s se diseñan correctamente ya que la utilización de objetos derivados no difiere demasiado de una técnica OOUI. Esta es la razón por la que no me parece ahora demasiado didáctico hablar de este tema ya que puede distraerle del verdadero e importante objetivo de este capitulo, que como ya hemos dicho, es explicar los criterios de diseño funcional de una interfície gráfica independientemente de sí el OOUI o GUI. Volviendo a los flujos de diálogo, la interfície gráfica no deberá nunca interferirlos, sino todo lo contrario facilitarlos. Según la aplicación puede haber diferentes caminos para un determinado trabajo. Es diálogo debe basarse en el principio de “ver y apuntar”: se presentan las opciones actualmente accesibles según el rol del usuario y el estado de ejecución del trabajo. Deben existir procesos de mantenimiento instantáneo de este principio en función de las acciones que va realizando el usuario. No deben presentarse pantallas innecesarias. Los mensajes han de ser breves y claros. Suele decirse que esos mensajes han de usar una terminología accesible al usuario, omitiendo tecnicismos informáticos y de aplicación. Me van a permitir que difiera un poco (sólo un poco) de ese principio general. Lo que se debe omitir son tecnicismos innecesarios. No se puede caer en el error con el fin de evitar usar esos tecnicismos, usar mensajes que sean largos y utilicen términos no técnicos que desvirtúen el contenido semántico del mensaje. Soy un firme defensor que el usuario ha de poner algo de su parte, aprendiendo los tecnicismos básicos del entorno donde trabaje. Si es necesario monte un plan de formación (siempre corto) para lógralo. Por otro lado, si que me parece fundamental otro aspecto: el flujo de diálogo ha de ser tolerante con los errores. Las acciones han de tener, dentro de lo posible (casi siempre), la posibilidad de deshacer y recuperar una acción equivocada. En los casos extremos que eso no sea posible, el usuario ha de tener notificación expresa. La utilización de ventanas secundarias es importante en el flujo de diálogo. Como ya se ha dicho, y Vd. ya conocía, existen:

4.5.1. Ventanas nodales. Cogen de forma exclusiva el foco de su aplicación. Obliguen al usuario a completar todas las acciones establecidas en la ventana antes de abandonarlas.

4.5.2. Ventanas no nodales.


Dejan al usuario interaccionar simultáneamente con todas las ventanas abiertas. Las ventanas están activas mientras no completen su función o no se cierren explícitamente.

Ambos tipos de ventanas han de combinarse de la forma que más convenga a las necesidades del flujo del diálogo.

5. Metodología de Diseño de interfícies Gráficas. Una vez presentados todos los conceptos, le voy a proponer una metodología de diseño de GUI’s. El punto de partida es la especificación del trabajo que el diseño de la explicación ha delegado en la GUI. Como en todo otro proceso, la precondición establecerá la información que se proporciona a la GUI y la poscondición lo que se espera recibir. No olvidemos que el diálogo de una GUI es transaccional y que la GUI no es el proceso sino la interfície de interacción del proceso con el usuario. Esto ha de estar claro para Vd. incluso en los procesos GUI’s más simples, las consultas. Para que se convenza de ello, repasemos el ciclo de un trabajo de ese tipo. La aplicación empieza presentando un GUI de la que el usuario saldrá con una petición de información o una cancelación. Si la petición es de información, la transacción de salida llevará las claves que determinan el acceso a la información que el usuario desea. La aplicación obtendrá esa información y la devolverá a la GUI en otra parte del mensaje de la transacción. En el caso más simple, este proceso de consulta se implementará en el evento del botón de aceptar la petición. La transacción no existirá físicamente ya que los campos clave se tomarán directamente de la GUI y la información obtenida se colocará directamente sobre la GUI. Pero observe que aun en este caso, el concepto de transacción se mantiene aunque el mensaje se codifique en la misma GUI. Y en cualquier caso, recuerde que en el evento solo debe hacer una llamada a un método que implemente la consulta a la base de datos. El ciclo de trabajo es:

Activación de la GUI. La GUI recibe en la precondición una señal de que es la primera entrada. Puede tener ya datos a mostrar o no. Según la pantalla sea de presentación, petición de datos o combinación de ambas.

Salida de la GUI. El mensaje de salida depende de la finalidad de la GUI. En GUI’s de presentación, el mensaje de salida es simplemente la aceptación del usuario de la información recibida. En pantallas de petición, los datos solicitados.

Proceso del mensaje de salida, que puede volver a originar una entrada en la GUI.

Aceptación por la GUI de esta precondición de entrada colocando la información recibida en la interfície gráfica y volviendo al segundo paso.

Teniendo este aspecto claro ataquemos el diseño en sí.


En primer lugar, una reflexión y un consejo. Atendiendo a las características del trabajo a las herramientas disponibles, para documentar el análisis de la GUI pueden utilizarse técnicas de prototipaje para que el usuario vea como quedará y el programador que se ha de hacer. Recuerde que si para documentar utiliza prototipos, son prototipos, no la primera versión de la GUI definitiva. 5. 1. Definición de los modelos.

Los modelos son las visiones ha tener en cuenta en el diseño. Cuando se comienza ese diseño hay que tener en cuenta cuatro visiones o modelos diferentes.

5.1.1. Modelo de diseño. Creado por el ingeniero de software según las necesidades de la aplicación. No contiene la imagen gráfica, sino los contenidos de la GUI a través de su precondición y poscondición. Es un resultado del análisis funcional de los procesos. Aporta las entidades y atributos de los datos, procedimientos y estructuras de software que han de ir ligadas a la interfície o en su interior. Aporta también las posibles restricciones.

5.1.2. Modelo gráfico de usuario. Llamado también en algunas metodologías diseño externo. Es creado por el diseñador de interfícies gráfica, que obviamente, puede ser el mismo ingeniero de software. Es la adaptación gráfica que se cree adecuada al modelo de diseño en función de los estándares, normas, características de la aplicación y perfil del usuario, y utilizando todos los principios del lenguaje visual que hemos visto anteriormente. Incluye el perfil de los usuarios finales del sistema. Para construir una interfície eficaz hay que empezar por conocer a los usuarios. Los perfiles de usuario puede agruparse en:

Noveles con pocos conocimientos de la aplicación y/o los ordenadores. Se les ha de guiar mucho. Usuarios intermitentes con capacidad de aprendizaje. Tienen conocimientos razonables, pero como el uso que harán es intermitente, tendrán poca memoria de la interfície. Usuarios frecuentes con buenos conocimientos. Se les ha de proporcionar formes abreviadas de interacción. Hay un subgrupo peligroso, los hackers o buscadores de agujeros: suelen descubrir trucos no cubiertos por la interfície.

La importancia del diseño externo puede llegar a ser grande que existen verdaderos especialistas en la materia, más relacionados con el mundo del diseño gráfico que con la informática.

5.1.3. Modelo del usuario o percepción del usuario. Es la imagen mental que el usuario imagina de la interfície. Soy de los firmemente convencidos de que debe ser recogida antes de concretar el


modelo gráfico de usuario. Respeto, pero no comparto, la opinión de los que piensan que la perspectiva del usuario no debe influir en el diseño inicial y que solo debe ser requerida al final del proceso. Tres argumentos avalan mi opinión: el usuario conoce su trabajo, sabe lo que mejor le conviene y hoy día dispone de una formación informática básica producto de la utilización masiva de aplicaciones a través de interfícies gráficas. La percepción y la imagen que el usuario se haga del sistema de forma mental dependerán de su perfil y experiencia anterior.

5.1.4. La imagen del sistema. Es el resultado final que los diseñadores quieren dar al sistema y que es producto de la interacción de los tres modelos. La imagen del sistema combina la manifestación externa de toda la información que describe la sintaxis y la semántica del sistema. Cuanto más coinciden la imagen del sistema y la percepción del usuario más efectiva es la comunicación y más eficiente es el uso que se hace el software.

Establecer la relación entre los tres modelos no es simple. Desgraciadamente, las cuatro visiones pueden diferir significativamente. El papel del diseñador es reconciliarlas y generar una representación consistente, eficaz y consensuada de la interfície. No es difícil deducir que lo conveniente es que participen en el proceso de diseño todas las partes implicadas trabajando cooperativamente. La interacción entre los tres modelos es tan obvia como se muestra en la figura. El diseñador gráfico recoge como precondiciones las especificaciones del modelo de diseño y, a mi juicio, la perspectiva del usuario, y utilizando los componentes del lenguaje visual, las normas y recomendaciones, analiza y modela las tareas formalizando la GUI en la imagen gráfica del usuario. Esta imagen se evalúa en rendimiento y se muestra al usuario que la contrasta con su perspectiva de usuario y el proceso se realimenta hasta crea la imagen final del sistema.

5. 2. Análisis y modelación de las tareas para crear el modelo gráfico de usuario.

Modelode

Diseño

Imagen delSistema

Modelo gráfico

de usuario

Diseñador Gráfico

Usuario

Percepción del

sistema

DiseñoExterno

DiseñoInterno

Programador

Figura 314. Interacción entre los modelos.


Las tareas que el modelo de diseño ha decidido que la interfície debe realizar han de ser diferenciadas claramente, modeladas según la percepción del usuario y formalizadas con los componentes visuales. En todo el proceso se han de tener en cuenta los principios del lenguaje visual detallados anteriormente en este capítulo. Una vez realizado este proceso, se han de evaluar los tiempos de respuesta a través de sus dos factores:

Tiempos de espera / respuesta. Variabilidad de la espera.

A continuación hay que incorporar la integridad y consistencia para proteger a los usuarios de los errores y caminos inadecuados. En esta etapa se implementaran las opciones de deshacer para recuperar errores. Finalmente se incorporaran las ayudas y facilidades para el usuario.

5. 3. Formalización del diseño en la interfície. Una vez concensuado el diseño externo de la GUI habrá que realizar su programación “informática”, conocida también como diseño interno. Aquí vuelve a actuar el programador, y recomendablemente, con técnicas OO. La formalización de la modelo gráfico de usuario se realizará en la herramienta de diseño del equipo de desarrollo.

5. 4. Evaluación de la interfície. Como ya he comentado, a partir del modelo de diseño el diseñador gráfico realiza un diseño inicial reflejado en un prototipo del modelo gráfico de usuario. Este primer diseño se evalúa técnicamente en cuanto a tiempos de respuesta y navegación. Se realiza a continuación una primera evaluación con el usuario. Los resultados de esta evaluación se estudian por el diseñador y se incorpora la modelo gráfico. Si se considera que los cambios son suficientemente importantes para hacerlo, se modifica el diseño, se adapta el prototipo de la interfície y se evalúa de nuevo con el usuario. El ciclo se repite hasta que el diseñador gráfico y el usuario consideran que la interfície ya esta acabada.

Prototipo del modelo gráfico

Evaluación con el

usuarioModificación

del diseño

Adaptar el prototipo de la

interficie

Estudio por el diseñador de la evaluación

Diseño final de la imagen del sistema

Evaluación Técnica

Diseño Inicial

Figura 315. Ciclo de evaluación de una interfície.


5. 5. Entrega de la interfície. Finalmente, el diseñador gráfico entrega la GUI a los desarrolladores para su incorporación a la aplicación. Aprovecha este momento para explicarles los criterios utilizados en el diseño. El objetivo de esta acción es doble. Por una parte el programador participa de la semántica de la pantalla y por la otra es informado de los criterios que pueden influir en la gestión de los procesos de la GUI.

6. Criterios a tener en cuenta en el diseño. Evidentemente, todos los presentados al desarrollar el lenguaje visual. A modo de resumen, pueden agruparse en tres grupos: 6. 1. Criterios de interacción con el usuario.

Ser consistente con todo lo explicado en el lenguaje visual. Ofrecen una realimentación significativa. Es decir, adaptar la GUI a la evolución de la acción del usuario.

Pedir verificación de cualquier acción destructiva no trivial. Permitir acciones de deshacer. Reducir el esfuerzo de memorización del usuario. Es decir evitarle tener que recordar operativa no expresada explícitamente en la GUI.

Buscar eficacia en el diálogo. Este es otro de aquellos criterios de difícil medida.

Proteger la GUI de errores de usuario cortando los caminos no deseados. Conseguir una navegación eficiente. Otro criterio difícil de medir. Proporcionar facilidades de ayuda sensibles al contexto. Importante para guiar al usuario.

Utilizar verbos de acciones simples y lo más adaptados posible a la cultura general.

6. 2. Criterios de visualización de la información.

Mostrar nada más la información importante en el contexto actual. No ahogar al usuario con datos. Hacer servir nombres consistentes y unificados y formatos claros y estándares.

Permitir al usuario mantener el foco inicial. Producir mensajes significativos. Hacer buenos modelos de los diferentes tipos de información mediante el uso apropiado de objetos visuales derivados.

Hacer una buena composición visual de los componentes en la GUI de forma que no produzca al usuario cansancio visual.

6. 3. Criterios de entrada de datos.

Minimizar el número de acciones. Mantener consistencia entre la información visualizada y los datos que se están pidiendo.

Permitir al usuario la personalización, si es posible, de la entrada de datos.


La interacción ha de ser flexible y adaptarse lo más posible al modelo deseado por el usuario.

Organizar una buena secuencialización de los controles que representan los campos a entrar. El orden ha de ser lo más cercano posible al de la fuente de datos.

Desactivar opciones no disponibles en el contexto actual. Permitir al usuario controlar el flujo. Proporcionar ayudas de contexto. Eliminar entradas innecesarias.

7. Una reflexión final. Si Vd. ha desarrollado GUI’s, le propongo que se haga una pregunta simple y busque una respuesta verídica. ¿Cuántas veces ha diseñado sus GUI’s de esta forma? Si me hace Vd. a mí la pregunta, le seré sincero: poquísimas. ¿Quiere ello decir que este capítulo sobra? Creo firmemente que no. El problema, como otros muchos de nuestra profesión, es que hacerlo bien es caro y las ventajas solo se ven a medio plazo. Además los plazos que nos piden suelen ser para ayer. Las ventajas se miden en fase de explotación en un menor tiempo de trabajo para los usuarios. Y cuando han de hacerse mejoras y ampliaciones del sistema y nos iría bien reutilizar. Y eso es dinero, ¡y del bueno!, del que se gana día a día y para siempre. Pero, ¿cómo medirlo en fase de diseño? Yo lo veo imposible. Nuestro cliente habrá de hacer acto de fe en nuestro apostolado de que las GUI’s han de diseñarse bien. Hago aquí constancia de que en mi siguiente aplicación gráfica voy a intentar diseñarla bien. Y, desgraciadamente, también confieso que difícilmente voy a conseguirlo.


Construcción de Frameworks.

1. Introducción. En los capítulos anteriores dedicados a las GUI’s hemos visto la importancia de trabajar con objetos visuales derivados que encapsulan la vista de una entidad compleja. Para conseguir una reutilización importante, minimizando costes y plazos, y normalizar al máximo la operativa, minimizando la formación y las incidencias, es necesario dar un paso más. Se trata de encapsular proceso. Por ejemplo, toda la gestión del mantenimiento de una entidad. Este nuevo objeto visual derivado, complejo por lo que se quiere de él, vamos a reverenciarlo como Framework. En este capítulo voy a darle unas nociones básicas sobre construcción de Framework. Para hacerlo, voy a tener que utilizar más nivel de orientación a objetos del que he utilizado (intencionadamente) en este libro. Siento hacerlo así, pero creo firmemente que si no lo hago, explicaría pobremente el tema, faltando a mi obligación con Vd. de explicar las cosas lo mejor que mi formación y experiencia me hace capaz.

2. El Paradigma MVC. MVC es el acrónimo de Model-View-Controller propuesto al mundo OO por los creadores de Smalltalk. La idea básica consiste en separar la funcionalidad de la interfície:

El Modelo (Model) es la clase del objeto. La Vista (View) es objeto gráfico (prácticamente siempre un objeto derivado) que proporciona la imagen visual de la clase. Obviamente puede haber más de una vista por clase.

El Controlador (Controller) es el encargado de interpretar la entrada de la vista y gestionar la grabación y lectura del modelo en disco, es decir, la Persistencia del modelo. En lo sucesivo, nos referiremos siempre al Controlador como Persistencia.

La implementación del controlador como gestor de la persistencia hará que, a partir de este punto, me refiera al paradigma MVC como MVP. Un Framework modelará el comportamiento global de la acción realizada por el usuario (por ejemplo, un mantenimiento de instancias de la clase), incorporará los controles adicionales para facilitar la operación de las diferentes opciones ligadas a la acción (alta, baja, modificación, consulta) y llevar la gestión de los mensajes necesarios para el flujo del diálogo.


La construcción de un Framework utilizará este paradigma. Además de los objetos visuales ligados a las opciones y a los mensajes, el Framework integrará los componentes MVP que colaborarán entre sí para implementar el Framework.

El Modelo implementará la clase, atributos y restricciones de integridad como mínimo.

La Vista interaccionará los atributos con el usuario. La Persistencia interpretará la entrada del producto y actualizará el modelo en el almacén de datos persistente.

En todo este capítulo voy a seguir siempre con conceptos OO. Pero observe que la idea MVP, aunque originaría del mundo OO, puede ser aplicada a piezas, que si no recuerda a estas alturas del libro, no son más que clases sin herencia ni polimorfismo. Sin embargo, las ventajas y facilidades OO son demasiado importantes como prescindir de ellas como confirmará a medida que avance en la lectura de este capítulo. Las ventajas del paradigma son MVP son muchas. Ha demostrado ser muy eficaz ya que independiza la interfície, muy volátil, de la verdadera naturaleza del objeto o entidad gestionada: se puede cambiar la vista, sin cambiar el modelo. La misma película puede rodarse con la persistencia que permite la independencia del acceso cualquiera que sea finalmente la implementación de la base de datos (relacional SQL-ODBC, orientada a objetos, jerárquica, etc.)

3. Multivistas, especialización y jerarquía de vistas.

Como ya hemos dicho, un objeto puede tener más de una vista.

Por transportabilidad. Por ejemplo, una para Windows y otra para X-Windows en UNIX.

Por necesidad de aplicación, el caso más habitual. Por ejemplo, una vista puede dar acceso a todos los atributos y otra especializada en solo a una parte.

Así, pues, es muy evidente que la vista de un objeto no suele ser única y acaba teniendo más de una implementación según las necesidades. Sin embargo, hay que evitar caer en la trampa de tener demasiadas vistas ya que la reutilización sería muy baja y este es uno de los factores más interesantes aportados por el paradigma MVP. La especialización de la vista con el uso adecuado e imaginativo de los atributos visible y habilitado ayudará muchísimo. También ayudará el uso de la especialización por herencia de la que hablaremos enseguida. Sin embargo, no debe confundirse el concepto de más de una vista con el de vista adaptada al perfil y derechos del usuario. En el primer caso, la multivista se implementa en objetos visuales diferentes adaptados por criterios como espacio, nivel del usuario, uso, etc. En el segundo caso, una única vista se particulariza al perfil del usuario jugando con los mecanismos de instanciación dinámica y los atributos de visible y habilitado. Un caso especial e interesantísimo de multivista es el caso de las vistas asociadas a una jerarquía de clases. Es muy recomendable que la organización de las vistas de una jerarquía de clases se haga según la misma jerarquía de la clase modelo. Si


se hace así, la aplicación será mucho más organizada, gestionable y podrá aprovechar las ventajas del paralelismo entres la herencia del modelo y de la vista. El concepto de mantener una jerarquía de clases modelo es aplicable también a la persistencia, aunque con mucho menos interés. Así como en el caso de las vistas debería ser casi una obligación de diseño, en el caso de la persistencia la obligación es más tenue.

4. Arquitectura de Diseño de un Framework.

A efectos docentes, le voy a presentar una arquitectura de Framework en la línea de utilización de un sólo modelo y una sola vista. Sin embargo, como verá la arquitectura es totalmente generalizable al caso general que involucre a varios de estos elementos. En la figura se muestra un esquema de bloques de la arquitectura de un Framework gráfico.

4. 1. Arquitectura de

bloques. En esta arquitectura se identifican diferentes bloques.

4.1.1. La interfície gráfica (GUI) del Framework. Es el contenedor gráfico asociado al Framework dentro del cual se instanciarán la vista, los objetos visuales de las opciones y la zona de mensajes.

4.1.2. El modelo. Que aporta los atributos y comportamiento de la entidad gestionada.

4.1.3. La persistencia. Que aporta su lectura y grabación en disco.

4.1.4. Los atributos del Framework. Que aportan los datos específicos de trabajo del Framework.

4.1.5. La Lógica de proceso del Framework. Que aporta los métodos que implementan el comportamiento del Framework.

Framework de aplicación

Modelo

Persistencia

Lógica de proceso del Framework

Vista

Zona de Mensajes

GUI

Opc

ione

s

Entorno

Atributos del Framework

Figura 316. Arquitectura de un Framework gráfico.


4.1.6. El entorno (enviroment). Leído en el proceso de construcción durante la instanciación del Framework, aportará, entre otros, las características de la plataforma, de la parametrización y del usuario. Servirá para particularizar el aspecto y comportamiento del Framework.

4. 2. Modelo de Objetos del Framework.

El modelo de objetos que representa a un Framework se presenta en la figura. La clase que modela el Framework, además de disponer de los atributos y métodos necesarios para modelar su propio estado y comportamiento, agrupa e instancia un objeto del modelo, vista y persistencia, además de otro de la clase entorno. La clase Framework integra también una clase visual que modela la GUI, que tendrá su propio modelo de objetos con los criterios que hemos mostrado en los capítulos anteriores. A estas agrupaciones, se añaden cinco asociaciones dinámicas:

La Vista con el Modelo. La Persistencia con el Modelo. El Entorno con la Vista. La Vista con la GUI. El Entorno con la GUI

La asociación dinámica la establece el Framework pasando en el constructor de la persistencia la instancia de la clase modelo, en el constructor de la vista la instancia del modelo y la del entorno, y en el constructor de la GUI la vista y el entorno. Vista y GUI utilizarán el entorno para especializarse.

4. 3. La Clase Entorno. En todas las aplicaciones, y particularmente en aquellas en las cuales la integración del cliente es mediante una GUI, la definición del entorno es fundamental.

Clase Fremeworkobjeto clase_modelovista clase_vistaes clase_persistenciaentorno clase_entornoAtributos del FrameworkMetodos de proceso del Framework

Clase Vistaobjeto clase_modelo

constructor(objeto,entorno)

Clase Persistenciaobjeto clase_modeloconstructor(objeto)

Clase Modelo

Clase EntornoAtributos Entorno

GUIvista clase_vistaentorno clase_entornoconstructor(objeto,

entorno) Figura 317. Modelo de Objetos de un Framework.


La gestión del entorno no es un problema de complejidad, sino de hacerlo bien. Su descripción ha de ser clara, precisa y compartida por todos los módulos. Por esa razón, el entorno en los Framework se implementa en un objeto que se traspasa y/o inicializa entre los módulos. Cada parámetro del entorno será un atributo de la clase. Todos los atributos serán privados y accesibles nada más que por métodos lo que garantizará su integridad. Los programas los consultarán y cambiarán mediante estos métodos. Los orígenes de los valores de los parámetros del entorno son dos:

Los parámetros estáticos definidos en los ficheros de inicialización estática del tipo *.INI o XML donde se colocan sus valores por defecto. Se personalizan por el administrador de sistema o en responsable de la aplicación con los criterios establecidos por el diseñador.

Los parámetros dinámicos que se obtiene o piden en el momento de la instanciación del objeto. El perfil de usuario es un caso claro de este grupo.

Cuando se instancia el objeto se cargan los parámetros estáticos y se piden los dinámicos, si el objeto entorno recibido no los tiene ya registrados. Para traspasar el objeto entorno entre módulos se utilizan las dos técnicas clásicas: pasar la instancia o dotar de persistencia a la clase entorno.

4. 4. Consejos para hacer Framework de uso general. Imagine que quiere crear un Framework de mantenimiento de uso general que ha de servir para cualquier entidad. Para conseguirlo deberá crear el Framework como una clase abstracta que se adaptará por herencia y polimorfismo a cada entidad. Para que eso sea posible, deberá crear jerarquía de clases para los modelos, las vistas y las persistencias. En la raíz de estas jerarquías estará una clase abstracta de cada tipo. La clase Framework abstracta integrará por agrupación estas clases abstractas. Las clases abstractas definirán el comportamiento mediante métodos genéricos que se adaptarán por herencia y polimorfismo a cada entidad. La clave es esa, la abstracción del comportamiento en la raíz de la jerarquía. Como ya se ha dicho anteriormente, la jerarquía de las vistas y, en menor medida la de las persistencias, debe imitar a la del modelo. Encapsule las opciones y la zona de mensajes en clases visuales derivados, que, en general, serán independientes de las entidades. En cualquier caso, si debe hacer una especialización de estas dos clases para alguna entidad, se será mucho más fácil hacerlo, una vez más, por herencia y polimorfismo.


La Comunicación por eventos como vía para obtener servicios.

1. Introducción. Voy a pagar en este capítulo una deuda. He estado afirmando desde el principio que iba a proponerle un modelo de diseño independiente de la metodología de diseño de aplicaciones utilizada. Y hasta ahora, a parte del capitulo dedicado a introducir la metodología OO aplicada al diseño de aplicaciones, no he hecho ninguna mención más. Pero observe que, a la pasiva, tampoco en toda la metodología expuesta he presentado nada que exija que la aplicación se haya diseñado convencionalmente. Con esta presentación, no le sorprenderá que le diga que en este capítulo voy a extender la metodología a modelos orientados a objetos. Voy a centrarme en el caso de comunicación C/S pero como verá los conceptos son aplicables a cualquier entorno distribuido en que los eventos tengan sentido.

2. La comunicación por eventos como vía para pedir servicios. Recuerde que un evento no es más que la notificación de un cambio de estado. Por favor, repase (como siempre si no lo recuerda) lo que comentamos sobre eventos anteriormente. El modelo de comunicación que define un evento es, por naturaleza, asíncrono desacoplado. El lugar o el componente que sufre el cambio de estado genera el evento para que lo recoja quien este escuchando y, en principio, no espera respuesta. Nada impide, sin embargo, que el oyente que captura el evento realice su trabajo y responda con otro evento. Según el emisor se haya quedado a la espera de la respuesta o no tendremos implementado un modelo de comunicación síncrono o asíncrono. Una forma muy eficiente de implementar el mecanismo para utilizarlo como vía para obtener servicios es que el potencial cliente implemente un semáforo. Así pues, con eventos podrá realizar una petición de servicios, en una comunicación con un estilo cliente / servidor de petición respuesta, siguiendo estos pasos:

1. El cliente genera la petición del servicio emitiendo un evento con los parámetros del mensaje. Si el modelo de comunicación implementado es desacoplado, ya hemos acabado. Si no, coloca el semáforo en rojo. Si el cliente continua trabajando deseará un modelo de comunicación asíncrono y si espera la respuesta deseará comunicarse con el servidor de forma síncrona.


2. El servidor o una cola recibirán el evento y prestarán su servicio. Cuando hayan acabo generarán un evento con la respuesta.

3. El cliente recibirá el evento, recogerá la respuesta de los parámetros y colocará el semáforo en verde.

4. Cuando el cliente lo necesite consultará el semáforo y, cuando lo encuentre verde, continuará.

Ésta es sólo una forma, muy frecuente, de implementar el diálogo pero, obviamente, pueden pensarse otras. Por ejemplo, implicando una cola que registre la llegada de peticiones eliminado el semáforo y convierta el servicio en multicliente. Un entorno de eventos exige la presencia de un Gestor de Eventos entre los diferentes componentes que desarrollan los procesos. Analicemos el funcionamiento de un gestor de eventos consultando la figura.

El origen de los eventos puede ser el sistema o un componente del sistema. Cada componente puede generar eventos contra sí mismo o contra otros componentes. Cada sistema dispone de un gestor de eventos que recoge tanto sus propios eventos como los de sus componentes. Si los eventos no

pueden pasarse a otro sistema el gestor de eventos es de bajo nivel; si puede enviarlos a otros sistemas, el gestor se dice que es de alto nivel. Veamos ahora que hemos de pedirle a un gestor de eventos para que nos permita usarlo para implementar una aplicación distribuida.

Posibilidad de pasar eventos entre componentes independientes ejecutándose simultáneamente. No se da esta posibilidad cuando Vd. utiliza, por ejemplo, eventos en una interfície gráfica ya que todas las partes de la gestión están integradas en el mismo ejecutable.

Posibilidad de pasar parámetros entre sistemas. Posibilidad de pasar parámetros en el evento. Si no deberá hacer trampas utilizando un área de uso común como zona intermedia. Mal asunto a poco que medite.

Observe que los gestores de eventos convencionales no dan ese servicio. Si lo dan, y forma parte de su naturaleza, los gestores de eventos de los modelos de objetos distribuidos y que son gestores de eventos de alto nivel.

EVENTO

Gestor de bajo nivel

Gestor de alto nivel

EVENTO

SISTEMA

• Captura los eventos de sistema

• Identifica el destinatario .• Los envia al destinatario-

Gestor de eventos

SISTEMA 1COMPONENTE

COMPONENTE

SISTEMA 2COMPONENTE

COMPONENTE

Figura 318. Esquema de funcionamiento de un Gestor de Eventos.


Carga del programa

Entrada de datos

Proceso de datos

Registro de resultados

Seguir?

Salida del programa

Figura 319. Esquema de programación secuencial.

Inicio Aplicación

Captura eventos

Notificación delos eventos

Evento

Gestión EVENTO 1

Gestión EVENTO i

Gestión EVENTO n

Gestión eventosCola eventospendientes

Fin Aplicación

Figura 320. Esquema de programación por eventos

No voy a detallarlo, pero consulte las figuras para recordar la diferencia entre la programación secuencial y la programación por eventos.

3. Inclusión de los eventos en los diagramas de flujo.

La metodología MAFDRA que hemos utilizado en los capítulos anteriores usa los diagramas de flujo para identificar servidores. La propuesta para introducir los eventos en los diagramas de flujo se muestra en la figura de la izquierda. Observe la posibilidad que da la notación de proteger la llegada de un evento con un mecanismo ECA (Evento-Condición-Acción). A modo de ejemplo, desarrollaremos a continuación

un pequeño ejemplo basado en la implementación por eventos de control de conexión con la Central y la compañía aérea del análisis de consistencia de la aplicación de la agencia de viajes que hemos desarrollado en paralelo con la metodología.

SalidaEvento

oDestino.Evento

Procesoque logenera

Entrada Mecanismo ECA

Procesoque

responde

Eventoo

Origen.Evento

Figura 321. Notación de los eventos en los diagramas

de flujo.


El proceso de tomar cliente quedará como se muestra en la figura. Observe que cuando se detecta la caída de un servicio la notificación se hace lanzando un evento. Este montaje permitiría arrancar a los vigilantes dejándolos permanentemente

“dormidos” hasta que llegada del evento que los despierte. El refinamiento de verificar conexiones no cambia y será:

Tiempo de espera

VerificarConexiónCentral

VerificarConexiónC.Aérea

Sleep

Emergencia_Central

Emergencia Central

Anotar noconexiónen Central

Emergencia_C_Aérea

Emergencia C. Aérea

Anotar noconexión

en C.Aérea

Figura 323. Refinamiento verificar conexiones por eventos.

Y, finalmente, el refinamiento de la conexión con la central será el de la figura donde la restauración de la conexión con la central se notifica por un evento.

Cliente local

TomarCliente

R


Posar noConexiónen Central

Time-out

Emergencia_Central

Emergencia Central

Anotar noConexiónen Central

Conexión_Central

Emergencia Central

AnotarConexiónen Central

Clientes central

Figura 322. Consistencia del proceso de conexión con la central por

eventos.


EstadoConexiónCentral

ComprobarConexiónCentral

Respuesta

Acceso aClientes ala Central

R

Emergencia Central

Posar conexión

con CentralConexión_Central

Anotar conexión

con Central

Figura 324. Reconstrucción de la conexión con la central por eventos.


Reingeniería de Sistemas.

1. Introducción al concepto de Reingeniería. Reingeniería es un término muy utilizado (queda muy “guai” en conferencias y libros) pero muy ambiguo. Conviene que centremos en primer lugar en que contexto vamos a utilizarlo. Es evidente que la informática no llegó a las organizaciones ayer. La inmensa mayoría de ellas disponen de aplicaciones informáticas desde hace mucho tiempo. Las aplicaciones no pueden seguir el ritmo de avance en las posibilidades que los sistemas van incorporando día. Tres son las razones básicas:

El coste de las aplicaciones en sí. El tiempo necesario para desarrollarlas. El coste organizativo de adaptación al cambio.

Y, además, no hay que caer en el error de cambiar por cambiar: si un sistema de información está trabajando perfectamente aunque no utilice tecnología punta, no se debe cambiar y hay que dedicar los esfuerzos a otras áreas. Observe que no pasa lo mismo con los avances de hardware: a nadie le amarga más velocidad y espacio en disco. Pero volviendo a las aplicaciones, también es evidente que aquellas que son muy estables también deben de evolucionar para dar mejor servicio aprovechando las nuevas posibilidades de las plataformas. La Reingeniería de sistemas se encarga de analizar, valorar e implementar esa evolución. La evolución se concreta en:

Mejorar la utilización de las aplicaciones. Complementar una aplicación con nuevas prestaciones. Sustituir parte de una aplicación por módulos nuevos. Evolucionar de una aplicación antigua a otra nueva de forma progresiva y no traumática.

Sustituir aplicaciones antiguas por otras nuevas sin evolución y traspasando sólo los datos.

De hecho, el término Reingeniería tiene dos niveles:

Reingeniería de aplicaciones con todos los matices anteriores. Reingeniería de sistemas de información con la integración de las aplicaciones y plataformas antiguas con las nuevas.

De todo ello vamos a tratar en este capítulo. Verá que muchos de estos temas ya los hemos tratado a lo largo del libro. Sin embargo, no está de demás recapitularlos aquí. He introducido también algunos apartados dedicados a procesos de reingeniería que son más presentación comercial que técnicas en si mismas. Lo hago para que


Vd. pueda ligar esos términos comerciales con las técnicas y estrategias de diseño distribuido que hemos presentado en nuestro viaje.

2. Los beneficios del efecto 2000 y del EURO. Nos pasamos cinco años hablando del terrible efecto 2000. Los artículos, libros y conferencias sobre el tema fueron un aluvión. Y el histerismo de los medios de comunicación en diciembre del 99 ya fue el acabose. Y llegó el 1 de Enero del 2000 y prácticamente no pasó nada. Y nos pasamos cuatro meses más oyendo que el problema había sido exagerado y magnificado. Le aseguro que muchos de los que habían hablado antes del problema, repitiéndose más que el ajo, se reconvirtieron después a apóstoles que fustigaron a los catastrofistas: “la pela es la pela” que decimos en mi tierra. O deberíamos decir ya “el euro es el euro”. Pero, dejándonos de broma, analicemos técnicamente el asunto. El efecto 2000 consistía básicamente en dos puntos:

Los años de las fechas se habían codificado con 2 dígitos en lugar de cuatro. Existían razonables sospechas de como se iban de comportar las rutinas de gestión de fechas y periodos con el cambio de siglo y el mes de febrero del 2000 que era bisiesto.

El segundo punto era mucho menos preocupante ya que se trata de un proceso y si se detecta un error se cambia la rutina y volviendo a distribuir los programas problema resuelto. Podía acarrear tensiones y problemas pero era fácil de simular, detectar y resolver. El cuanto al primero, déjeme hacer un comentario previo. Fue muy fácil decir el 1 de Enero del 2000, a las 12 del mediodía: ¡qué malos eran aquellos informáticos históricos del siglo pasado que colocaban solo dos dígitos en los años! Yo, que me enorgullezco de ser un informático actual muy histórico, quiero defender a aquellos heroicos técnicos que con poca información reglada y pocos medios montaban aplicaciones que funcionaban (y todavía funcionan en algunos casos) con 4 KB de memoria (si KB), cassettes (si cintas) y más tarde con evolucionados ordenadores con floppys de 8” de 256 KB memoria externa. Recuerde que los primeros PC’s de los jóvenes años 80 tenían 256 KB de memoria y uno o dos floppys de 512 KB. Dos bytes por cada aparición de un campo tan frecuente como una fecha era una enormidad. Hoy día con máquinas que ya ni sabes que disco tienen, memoria por un tubo, capacidad de proceso distribuida ilimitada y conectividad a tope es muy fácil hablar. Sin embargo, como siempre ha habido y habrá técnicos malos, en el déficit de nuestra profesión, si que hay que decir que, increíblemente, hubo aplicaciones diseñadas primeros de los 90 que cayeron en el error. El caso extremo que yo conozco es una aplicación que diseñada en 1998. Pero la mayoría de los profesionales ya atacaron el problema desde finales de los 80 cuando las plataformas de sistema nos empezaron a liberar de las restricciones de disco y memoria.


Y finalmente a mediados de los 90 se tomó conciencia de que había un tercer factor que, como un caballo de Troya, había permanecido escondido: eran las plataformas de hardware y sistema las que no pasaban el efecto 2000. Los problemas de las plataformas y las aplicaciones obligaron a las compañías a realizar un plan de inversiones para adaptarse. Y como, debido a un efecto muy positivo de las campañas catastrofistas, las direcciones de las compañías no discutieron los medios, los informáticos pudimos:

Adaptar y modernizar las plataformas de sistema. Hacer Reingeniería o sustituir las aplicaciones dejándolas modernizadas.

Fue como si pasáramos los sistemas de información por un taller y un túnel de lavado del que salieron un aire de frescor renovado. No es extraño, pues, que la llegada del 2000 se redujera solo a una gran fiesta planetaria. No fue por que se hubiera exagerado el problema sino por el esfuerzo de los profesionales y las inversiones de las compañías. Este es el gran logro del efecto 2000, fundamental hasta tal punto que pienso que la informática deberá levantarle un monumento. En Europa otro caballo tiró también del carro, la introducción del EURO. Sin embargo, su influencia fue muchísimo menor.

3. La evolución por escenarios y el flujo de los sistemas de información hacia la integración. Es fundamental que antes de seguir vuelva a leer el capítulo de la primera parte, Dos gotas de Reingeniería, en el cual se tratan estos temas. Y, por favor, hágalo con los ojos de todo lo que ha aprendido en el viaje por el diseño. Y tenga claro que el flujo de los sistemas de información hacia la integración es imparable.

4. La migración de los datos. En ocasiones el proceso de reingeniería se traduce en la necesidad de una migración de datos, proceso nada trivial i que debe ser abordadazo rigurosamente. En primer lugar hay que valorar la influencia en nuestro entorno de los problemas clásicos de este proceso de reingeniería: 4. 1. Problemas clásicos.

• Inexperiencia interna. Lo normal es que en la empresa no se tenga experiencia: busque asesores.

• Volumen brutal de datos históricos que relantizan los procesos: depure previamente, pero guarde copia de todo lo que elimina, nunca se sabe….

• Desconocimiento del modelo de datos. Lo normal es que quien los montó ya no esté con nosotros. Tiene un problema de narices. Reconstruya el modelo como paso previo a la migración.


• Llevará tiempo y los procesos del día a día no pueden pararse. Ni la intente en frío. Planifique la migración siempre en caliente.

• Los plazos se agotan sin acabar el proceso. Lo siento, este es el problema clásico de cual no le puedo aportar más ayuda que recordarle que planifique bien, de forma pesimista y que no admita trabajos intermedios no previstos inicialmente (cosa que, me temo, no conseguirá).

• Calidad de los datos. Como usted es un buen técnico, sus aplicaciones no lo permitirán, ¿verdad? Pero, si no se fina, depure los datos antes de iniciar la migración.

4. 2. Pasos a seguir.

• Unificar la plataforma. • Diseñar el nuevo modelo de datos, que probablemente será

distribuido. • Gestionar y planificar el proceso de migración como un proyecto de

ingeniería de software critico. • Diseñar el proceso de migración; Etapas: análisis, planificación,

extracción, cambio de formato, transferencia, limpieza, validación, carga (estas dos últimas fases pueden intercambiarse) y pruebas.

5. Maquillaje de aplicaciones existentes. Ya sabe que en los primeros tiempos de las interfícies gráficas hubo intentos para cambiar las interfícies tradicionales de las aplicaciones HOST por interfícies gráficas sin cambiar el rediseño. Estos intentos, más o menos automáticos, no llevaron a nada ya que no se ganaba nada más que estética. El verdadero maquillaje se obtiene “cortado” la presentación, encapsulado en un servidor el proceso y desarrollando una componente de presentación con GUI nuevo. No hace falta decir que el modelo de diseño a emplear en el modelo de presentación desarrollado por técnicas GUI. Esta vía de Reingeniería se ha visto potenciada con la llegada de Internet que ha permitido el maquillaje sin necesidad de ir a los puestos cliente, es decir, sin necesidad de administrar a los clientes. La utilización de Mainframe para el Housing no ha hecho más que potenciarlo. Recuerde, finalmente, que para poder hacer maquillaje la aplicación heredada debe ser transaccional.

6. Upsizing de sistemas. Ya hemos hablado mucho del Upsizing de datos que se produce cuando un sistema aislado se integra en el sistema distribuido. Como siempre, no voy a repetirme, pero recuerde que no es un tema trivial, y más por la integración de los datos que de los procesos. Por esa razón, el trabajo ha de ser evaluado, medido y planificado. Muchas veces necesitará de técnicas avanzadas para materializar la integración. O de procesos radicales de sustitución total del entorno informático de la unidad a integrar.


Dentro de este capitulo, hay que incluir la integración de sistemas de compañías independientes ya sea por minimizar costes de negocio o para dar servicios. Como los sistemas a integrar no se conocen entre sí, la utilización de estándares y de Internet es aquí fundamental. El tema del Upsizing de procesos aparecerá dentro de este capitulo.

7. El papel de los Mainframe. También hemos hablada ya de este tema. Las opiniones de que los Mainframe desaparecerían la erraron de todas, todas. La bajada de precios y el aumento todavía mayor de sus prestaciones han vuelto a enseñarlos en la línea operativa de donde, de hecho, no habían salido nunca. El HOST se ha convertido en una parte integrada en los sistemas interoperables montados sobre las plataformas distribuidas. Y en un lugar ideal para colocar el Housing de las WEB’s. Con todo ello, son contadas las instalaciones que han apagado sus Mainframe o planean hacerlo. Las funciones asumidas por los Mainframe dentro del sistema integrado son principalmente:

Servidor de bases de datos centralizadas. Concentrador / distribuidor, en particular en conexiones con otros HOST de la misma u otras compañías.

Lugar de localización de recursos y servidores compartidos por función, coste o localización obligada. Obviamente, los servicios quedan distribuidos y no distribuibles.

Localización de aplicaciones tradicionales a las que se accede como siempre por emulación de pantallas desde los PC’s en un escenario HOST/escritorio.

Encapsular aplicaciones heredades como servidores de altísimo nivel. Son las denominas técnicas de envolvente del HOST.

Housing / hosting WEB. Localización de Servicios WEB. Servidores de aplicaciones de segunda generación Internet/intranet.

8. Técnicas de envolvente del HOST. Hay un hecho: el código heredado de un HOST es demasiado importante como para reproducirlo, es gigantesco, complejo y está poco o nada documentado. Hay una opción teórica: reconstrucción con una base de datos, una interfície gráfica y una arquitectura distribuida. Hay una realidad práctica: la opción teórica es cara, peligrosa y se hace difícil de atacar ya que funciona y vale millones sustituirla. Y hay, finalmente, una solución: envolver al Mainframe.


Las técnicas de envoltura del HOST consisten en rodear al sistema heredado de una envoltura de software que esconde los problemas del código heredado con aplicaciones distribuidas C/S sobre sistema operativo o Internet. Para desarrollar esa envolvente hay varios caminos:

Utilizar una herramienta que permita acceder directamente al HOST (COBOL, C++, SMALLTALK, 4GL’s,...).

Atacar vía Internet. Está opción ha sido fundamental que organizaciones que no habían querido distribuir sus sistemas cuando solo disponían de soluciones Cliente / servidor ya fuera por costes o, simplemente, por falta de formación y cultura para hacerlo. El componente Internet suele ser de presentación

Encapsular el código heredado como un servidor de alto nivel. Aquí el maquillaje es fundamental. Una solución muy recurrida es utilizar Servicios WEB

Las ventajas de las técnicas de envoltura son inmediatas:

Permite acceder al HOST, integrarlo en el sistema distribuido global y utilizarlos en aplicaciones distribuidas eliminado la complejidad del HOST.

La solución es relativamente rápida y eficaz. Permite, una vez hecha la integración, la sustitución paulatina de las partes obsoletas del HOST sin influencia en el funcionamiento global del sistema distribuido.

La única desventaja real es que por debajo todavía está la aplicación antigua con sus problemas de siempre. Sin embargo, se ha conseguido congelarla y ya sea por Reingeniería o por nuevo desarrollo, hacerla evolucionar a pesar de esos problemas. Los envolventes pueden tipificarse en tres grupos:

Envolvente de bases de datos. Encapsulación por servidores de datos. Envolvente de servicios.

Encapsulamiento mediante servidores propios de Mainframe, por ejemplo, grandes impresoras.

Gestores de transacciones. Correo electrónico. Envolvente de aplicaciones, mediante aplicaciones de presentación.

Y utilizar dos vías:


Cliente / servidor basado en:

Sistema operativo. Internet.

Internet / Intranet / Extranet convencional sobre servidores WEB. La arquitectura de la envoltura es la que se muestra en la figura, que se explica por sí sola. Solo remarcar la aparición de las API’s que se han desarrollado para implementar la envoltura encapsulando el HOST. Las técnicas de envoltura de aplicaciones a través de un componente de presentación presentan la ventaja de que la aplicación heredada no sufre cambios. Como ya he dicho, es muy fácil de implementar en aplicaciones transaccionales aprovechando el formato del mensaje de la transacción para implementar el mensaje y la respuesta del nuevo componente de presentación. El protocolo se implementa en la API. Se montan con la arquitectura de tres niveles de la figura. El BT Server es común para todo el sistema heredado. Acepta transacciones de los niveles distribuidos y las descompone en los elementos específicos de cada aplicación heredada. Permite paralelismo. Contiene la lógica de la aplicación para gestionar condiciones de error, puntos de decisión, reglas de negocio, etc. La capa de LT Server convierte la transacción de componentes a un flujo de caracteres 3270, 5250, VT 100, etc. emulando la sesión de usuario final de un terminal no inteligente, es decir, implementando el protocolo de la transacción. Comporta diferentes problemas técnicos:

Debe conectarse al sistema heredado y mantener la conexión por tiempo indefinido.

Nuevo Sistema Distribuido

Envoltura de aplicación

API’s

Envoltura de datos

API’s

Aplicación heredada

Envoltura de servicios

API’s

AS/400

Base de Datos

Figura 325. Arquitectura de Envolvente.

Lógica de presentación

LT Server

BT Server


Base de Datos

LT Server


Figura 326. Envolvente de presentación de tres

niveles


Debe establecer el modo de emulación del terminal. La interacción del LT Server con el sistema heredado puede dar diferentes errores y / o excepciones. El BT Server debe reconocerlos y resolverlos.

Ha de gestionar los fallos del servidor (en que se ha convertido el sistema heredado) o del transportista y resolverlos.

9. Downsizing. Downsizing de la técnica de pasar las aplicaciones HOST a máquinas más pequeñas eliminado la parte no rentable de los sistemas de información. En los sistemas HOST se comprobó que una parte importante de los recursos, y por tanto de los costes, de utilizaba para obtener una información con poco valor añadido. Si eliminamos esa parte abaratamos los costes informáticos sin pérdidas importantes de prestaciones prácticas. En esta tesitura, el sistema de información puede montarse sobre plataformas más pequeñas y por tanto de menos coste tanto de inversión como, y fundamentalmente, de explotación. La razón principal del Downsizing no es hoy bajar costes sino mejorar los sistemas informáticos y conseguir una mayor adaptabilidad a los cambios técnicos y organizativos. Y además, y según el tipo de negocio y la situación inicial, al final también puede conseguirse un ahorro de costes. Un Downsizing ha de ser un proceso gradual que siga reglas básicas:

Realizar un entrenamiento con una parte pequeña del sistema, que no sea estratégica, para rodar a las personas, las herramientas y la metodología.

Planificación: comenzar el proceso de migración por las aplicaciones generadoras de beneficios (ventas, marketing, etc.). Aquellas que dan soporte a la operativa interna de la empresa se ha de dejar para el final (contabilidad, recursos humanos, etc.). La migración de los procesos Batch difícilmente aportan beneficios. Obviamente la prioridad deberá cambiarse si la situación en las aplicaciones internas está deteriorada.

Decidir la integración de la información de análisis y de investigación en un almacén de datos. Esto le permitirá integrar de forma cómoda la información histórica de las aplicaciones que dejará atrás con la nueva.

Ya puede realizar la sustitución de las aplicaciones internas generadoras de beneficio por el nuevo sistema. Para estas aplicaciones debe primarse el uso de paquetes, personalizaciones y aplicaciones periféricas. Repase aquí lo que hablamos en la primera parte sobre ERP’s.

Concentrarse en los procesos de negocio, no en los datos.


Déjeme, finalmente, hacer algunas reflexiones sobre un proceso de Downsizing.

1. No lo inicie si no es necesario para su negocio, y aun así, esté muy convencido antes de iniciarlo.

2. Redacte un plan estratégico de la arquitectura distribuida que desea e incluya el plan de migración.

3. No haga cambios masivos e intente seguir bastante rigurosamente el esquema propuesto arriba.

4. No confíe en conseguir grandes ahorros, busque mejorar sus procesos y adaptabilidad a los cambios.

5. Intente que el plazo de cada etapa no sea muy largo y que el proceso avance de forma gradual.

6. No empiece hasta que no esté preparado evitando que en el arranque y los primeros meses de funcionamiento hayan muchos problemas que desprestigien el proceso y den pie a los detractores que siempre existirán ya que las personas tenemos la inercia de oponernos a cambiar las cosas que llevamos haciendo mucho tiempo y, que por tanto, dominamos.

7. Tenga en cuenta que el proceso total puede durar más de dos años por lo que deberá estar atento a los cambios tecnológicos de forma que al final del proceso consiga el sistema más actual posible.

8. Tenga en cuenta que el renacimiento de los Mainframe y e Internet como herramienta de aplicaciones periféricas puede desaconsejar Downsizing, en principio, muy claros.

10. EAI: Integración de aplicaciones corporativas. Es frecuente que en una compañía existan diferentes aplicaciones conviviendo en áreas de trabajo diferentes y que en cada una la aplicación este resolviendo satisfactoriamente su función no habiendo necesidad de cambiarlas.

Trainnig con una aplicación pequeña

y no críticaHost Planificación

Trasladar los sistemas de toma de decisión a un

almacén de datos

Arrancar las aplicaciones generadoras de beneficio

con paquetes y aplicaciones periféricas

Traspasar el resto de aplicaciones

Desconectar la aplicación

del Mainframe

SistemaDistribuido

Figura 327. El camino del Downsizing.


Y que como parte de la evolución normal del sistema de información haya llegado el momento de integrarlas, tanto por procesos de negocio internos como externos. Acaba de aparecer la necesidad de iniciar un proceso EAI, término inglés de la integración de aplicaciones corporativas. O dicho en otras palabras, nuestro conocido Upsizing aplicado a datos y procesos de negocio. Aparecen todos los problemas que ya hemos hablado ampliamente dentro de Upsizing, en particular las heterogeneidades sintácticas y semánticas. EAI engloba el conjunto de técnicas que permiten el acceso sin restricción pero con autentificación a los datos y procesos de negocio de cualquier aplicación y/o fuente de datos de la compañía. El concepto puede extenderse, obviamente, a la integración con clientes, proveedores y terceros con un matiz no técnico sino político: la necesidad de negociar y pactar. El concepto es extensible a dos conceptos más:

La integración de empresas fusionadas. La necesidad de ofrecer servicios corporativos operativos en la actualidad al exterior.

En el lenguaje común de EAI, cada sistema constituye un nodo o isla de información. El sistema convencional tradicional ha sido:

Integrar por intercambio de interfases. Integrar punto a punto estableciendo un conducto especializado entre cada nodo. Aquí la integración de datos se ha conseguido de varía formas:

Replicación uni o bidireccional según se decida que la fuente de mantenimiento sea compartida o unificada. La sincronización de la replicación puede ser:

Síncrona, en el concepto de replicación: tan rápido como se pueda.

Asíncrona con calendarios pactados. Integrar los datos en un modelo único y adaptar las aplicaciones de origen. Es decir un Upsizing de datos.

Con las herramientas de integración de plataformas apareció la posibilidad de integrar de forma transparente los sistemas a través de Middleware que algunos llaman businessware. ¡Qué manía de inventar términos nuevos para otros ya existentes que tenemos! Las funciones básicas que necesitamos de este Middleware son:

Transparencia de acceso a los datos. Mecanismos de sincronización de los datos del modelo de datos distribuido resultante.

Un mecanismo de intercambio de eventos en el concepto general del tema: cosas que pasan en un entorno y que se han de notificar a otros.

Integración de las plataformas de intercambio de mensajes. Posibilidad de intercambiar servicios. Disponer de una herramienta de generación de informes integrados.


Para resolver todas estas necesidades puede utilizar cualquiera de las técnicas que ha aprendido, eso espero, en este libro. Así:

Los mecanismos de publicación / suscripción pueden resolver perfectamente la sincronización de datos e el intercambio de eventos

La realización de servidores de distribución es ideal para integrar servicios internos.

Las técnicas de envolvente le pueden resultar muy útiles si necesita hacen publicas funciones en aplicaciones heredadas de Mainframe.

Los procesos de Workflow pueden ser la clave para integrar nuevos procesos de negocio que integren varias aplicaciones.

Los Servicios WEB son un procedimiento estupendo para intercambiar con terceros.

La utilización de XML, por su estructura y posibilidades que se han visto ampliamente en este libro, es una necesidad.

La técnicas de Donwsizing o sustituir parte de los sistemas antiguos por un ERP suelen incluirse como de EAI. Yo particularmente pienso que no lo son. Aunque es una opinión particular.

Cuando la técnica utilizada es de Servicios WEB se suelen marcar los siguientes pasos:

Experimentación con Servicios WEB en la plataforma y en la organización. Recubrimiento de las aplicaciones actuales con Servicios WEB. El uso se deja a la iniciativa de los propios usuarios.

Integración de todo el sistema. 10. 1. Etapas.

En la figura siguiente se muestra un esquema de las etapas necesarias para un proceso EAI.

10.1.1. Definición clara de los objetivos que motivan la necesidad.

Definición e identificación de objetivos

Integración de Datos•Definición del Metaesquema•Diseño:

• Replicación.•Sincrona.•Asincrona.

• Servicios.

Identificación, diseño y publicación de servicios

de proceso

Implementación de los procesos de negocio

motivadores

Revisión del resto de procesos internos

Integración de procesos de negocio con

terceros

Figura 328. Etapas de un proceso EAI.


Es muy importante hacerlo para no embarcarse en aventuras sin meta clara. Recuerde valorar tanto las motivaciones internas como las externas.

10.1.2. Integración de datos. Por estrategias de Upsizing, resolviendo las heterogeneidades sintácticas y semánticas con un metaesquema. Necesitara también la publicación como servicios de datos desde las fuentes originales de todo lo necesario para consulta y/o mantenimiento. Hágalo así, no acceda nunca directamente a los gestores originales. Recuerde que dispone de dos modelos de gestión:

Replicación. Síncrona Asíncrona.

Servicios, actuando sobre las fuentes originales, técnica que hemos dicho antes que se conoce como replicación virtual.

10.1.3. Identificación, diseño y publicación de los servicios de proceso.

Obviamente, desde las aplicaciones originales. Escoja un sistema estándar, como puede ser Servicios WEB, aunque en principio no necesite interactuar con el exterior: quedará preparado para el futuro.

10.1.4. Implementación de los procesos de negocio involucrados.

Es decir, los que han motivado el proceso de EAI.

10.1.5. Revisión de los procesos de negocio internos. En función de las nuevas funcionalidades seguro que puede conseguir un gran retorno de inversión rediseñando la mayoría de los procesos de negocio de su empresa.

10.1.6. Integración de procesos externos con terceros. En este punto habrá de pactar con sus clientes, proveedores o colaboradores.

Finalmente, permítame que no incluya aquí ningún esquema de arquitectura de un sistema EAI: escoja entre todos los que hemos visto, la parte de la solución que decida para cada tema.

11. La consolidación de recursos de plataforma. El aumento espectacular de la banda de comunicaciones permite la consolidación de los recursos de la compañía, especialmente los máquinas ervidoras, eliminando niveles físicos en primer lugar y lógicos como segundo paso. La idea es simple: aprovechando la mejora de las comunicaciones, concentrar los servidores y simplificar las aplicaciones eliminado costes de administración y mejorando la coherencia e integridad del sistema.


Observemos que la aplicación continua siendo distribuida aunque seguramente más simple de arquitectura. La consolidación de servidores tiene diversas ventajas claras:

Control del crecimiento de la granja de servidores y optimización del crecimiento evitando la presencia de máquinas pequeñas o infrautilizadas.

Posibilidad de trabajar con clusters y recursos afines para garantizar al máximo del tiempo de servicios.

Optimización de la inversión. Centralización de la gestión en unos pocos servidores físicos que conlleva:

Optimización de los recursos humanos, menos, más formados y mejor pagados.

Posibilidad de establecer procesos metodológicos y automatizados. Reducción de los elementos de la infraestructura a administrar. Reducción del tiempo de respuesta ante problemas y mejora conjunta del nivel de servicio.

Reducción del número de licencias. Reducción del número de servidores de programas. Mayor estabilidad. Facilidad para controlar la seguridad de acceso. Mejor control de software dañino. Facilidad para mantener las versiones del software de la plataforma actualizadas.

Facilidad de Back-up con posibilidad de tener mejores dispositivos de copia.

Mayor coherencia del sistema y las aplicaciones. Control de crecimiento. Mayor facilidad en la renovación, simplificando y agilizando, en tiempo y dinero, el proceso.

Mejora de la oferta, proporcionado mayor capacidad de proceso y de almacenamiento de datos.

Liberación de espacio, ventaja indirecta nada desdeñable. Solo con consultar esta lista es fácil reparar en que los beneficios económicos, directos por ahorro y optimización, e indirectos, por mejora del nivell de servicio, son inmediatos. La realización de un plan de consolidación pasa por tres fases: 11. 1. Preparación.

Debe analizarse la situación actual y realizar la propuesta. Las etapas a seguir son:

Inventario de los recursos actuales. Redefinición de comunicaciones y servidores con la propuesta de ancho de banda necesaria.

Replanteamiento de los servicios de back-up de datos y procesos. Redefinición de los procesos de administración afectados.

El resultado final es el plan de migración.


11. 2. Desarrollo. Las etapas a cubrir son:

Consolidación de comunicaciones. Concentración de servidores físicos e implementación de las nuevas maquinas previstas. Note que al final de un proceso de concentración puede resultar que hay más niveles lógicos que físicos.

Poner en marcha la nueva política de administración.

11. 3. Mejora. Que consiste en estudiar, especificar, diseñar, implementar y poner en marcha los procesos para simplificar y mejorar el sistema distribuido aprovechando las nuevas mejoras de la plataforma y su menor nivel de dispersión. No hace falta decir que esto es ni más ni menos que un proyecto de diseño distribuido.

12. Reingeniería de procesos de negocio.

Hablar de este tema a estas alturas, en que hemos tratado a fondo y desde múltiples puntosa de vista la integración de sistemas, ya no aporta nada nuevo. Pero si que es bueno resaltar que la reingeniería de procesos de negocio, conocida como BPF en este mundo delirante de siglas que es nuestro entorno, es una técnica de reingeniería (permítame repetir la palabra) de amplías posibilidades y que hay que potenciar ya que puede afectar tanto al ámbito externo como al interno mejorando los costes de explotación y potenciando y mejorando la gestión. Por esa razón voy a reproducir los criterios de Garther Grup sobre este tema. Según esta consultora, hay seis factores indispensables para alcanzar esta fusión.

1. Conocimiento y documentación de los procesos de negocio a integrar. 2. Arquitectura orientada a servicios en las aplicaciones. 3. Utilización de XML. 4. Estándares de definición de las entidades compartidas: facturas, albaranes,

productos, servicios bancarios y un amplio etc. tan largo como quiera. 5. Integración basada en el modelo portal. 6. Sistemas de almacenamiento de datos compartidos.

¿Le suena? Llevo un montón de páginas hablando de ello por lo que me parece innecesario añadir nada más. Me repetiría. Observe, finalmente los pre-requisitos que se necesitarían:

Integración de infraestructura de la plataforma. Mecanismo de integración de aplicaciones. Mecanismos de integración de datos.

Vamos, volver a inventar el Middleware…

INDICE DE LA SEGUNDA PARTE

Presentación 3

Condicionamientos de organización. 4 1. Introducción. 4 2. Los estándares de la plataforma. 4 3. El estándar ofimático 4 4. La unificación de la ofimática. 5

4. 1. Será un trabajo impopular. 5 4. 2. Será un trabajo largo y pesado. 6

5. La dispersión de formatos y contenidos. 7 5. 1. Imposición o libertad. 7

6. Unidad de versión. 7 7. Necesidad de Multidioma. 8 8. La codificación histórica heredada. 8 9. Otros condicionamientos de datos. 9

9. 1. Las obligaciones de la empresa respecto a la Ley de protección de datos. 9 9. 2. Necesidad de registro. 9

10. El factor humano. 10 10. 1. El estado anímico de la organización. 10 10. 2. El nivel de los usuarios. 10 10. 3. La resistencia al cambio. 10

11. Una reflexión final. 10 Componentes Operacionales 11

1. ¿Qué es un componente operacional? 11 2. ¿Porqué usar componentes operacionales? 11

2. 1. Tipificar comportamiento. 11 2. 2. Unificar criterios de diseño y administración. 11 2. 3. Bajar costes de desarrollo. 11 2. 4. Están probados. 11

3. Limites. 11 4. Una clasificación. 12 5. Componentes operacionales más importantes en el diseño. 12 6. Tecnología de implementación de Componentes Operacionales. 13 7. Modelos de integración de componentes operacionales de primer nivel. 13

7. 1. Estática. 13 7. 2. Dinámica. 13

8. Semáforos. 14 8. 1. Qué es un semáforo. 14 8. 2. Uso de los semáforos 14 8. 3. Servicios habituales. 14 8. 4. Semáforos con etiqueta. 15

9. Ticket. 15 9. 1. ¿Qué es un Ticket? 15 9. 2. ¿Un nombre desafortunado? 16 9. 3. Uso de los tickets. 16

9.3.1. Conocer es estado de cada proceso. 16 9.3.2. Coordinar lógica de ejecución de procesos. 16 9.3.3. Asegurar coherencia y garantizar integridad. 16

9. 4. Elementos fundamentales de un ticket. 16 9. 5. Servicios habituales. 17

9.5.1. Estructurales. 17 9.5.2. De gestión. 17

10. Tickets multihoja. 17 10. 1. ¿Qué es un ticket multihoja? 18


10. 2. Organización de un ticket multihoja. 18 10. 3. Métodos adicionales para tratar los tickets multihoja. 18

10.3.1. Estructurales. 18 10.3.2. Gestión. 18

11. Colas. 18 11. 1. ¿Qué es una cola? 18 11. 2. Utilidad de las colas. 18 11. 3. ¿Utilizar colas de Middleware o crear colas propias? 19 11. 4. Estructura básica de una cola. 19 11. 5. Atributos básicos de una cola. 20

11.5.1. Referencia de la anotación. 20 11.5.2. Destino (servicio). 20 11.5.3. Servidor o agente que la atiende. 20 11.5.4. Origen (cliente). 20 11.5.5. Referencia del cliente. 20 11.5.6. Referencia del servidor o agente. 20 11.5.7. Fechas y horas. 21 11.5.8. Prioridad. 21 11.5.9. Estado. 21 11.5.10. Calificador. 21 11.5.11. Caducidad y forma de eliminación de la anotación. 21 11.5.12. Longitud del mensaje. 22

11. 6. Dinámica de las referencias. 22 11. 7. Recomendaciones de implementación. 22 11. 8. Formas de implementación: persistencia y organización interna. 23 11. 9. Implementación parcial sobre memoria. 23 11. 10. Métodos del comportamiento básico. 24

11.10.1. Estructurales. 24 11.10.2. De gestión. 24 11.10.3. Tratamiento de la persistencia. 24

11. 11. Colas multihilo: multicliente y multiservidor. 25 12. Las colas como servidores. 25 13. Servidores de Impresión. 29

Componentes Operacionales implementados por Agentes 29 1. El Vigía y el Disparador. 29 2. ¿Qué es un Servidor de Correo? 30 3. Características básicas de un servidor de correo. 31 4. Arquitectura del servidor de correo. 31 5. Operativa básica de un servidor de correo. 32

5. 1. Envío. 33 5. 2. Recepción. 33 5. 3. Captura. 34

6. Posibilidades de parametrización. 34 7. Posibilidades de administración. 34 8. Características del transporte. 35 9. El Servidor de Notas y Avisos. 35 10. El cartero. 36 11. Gestión de errores en un servidor de correo. 37

11. 1. Recuperación de errores. 37 11. 2. Facilidad de localización y seguimiento. 38

11.2.1. Loging de errores. 38 11.2.2. Control centralizado de errores. 38 11.2.3. Jerarquía de errores. 39 11.2.4. Módulo de seguimiento y análisis. 39

12. Otras posibilidades. 39 13. Semántica de comportamiento. 40 14. Modos de trabajo habituales de un servidor de correo. 40

14. 1. Push. 40 14. 2. Recogida. 41


14. 3. Notificación. 41 14. 4. Oportunista. 41

15. Implementación. 42 15. 1. Programación propia. 42

15.1.1. Aprovechar una plataforma de objetos distribuidos. 42 15.1.2. La plataforma TCP/IP + SOAP. 42 15.1.3. Basarse en los módulos de gestión de mensajes del Middleware. 42 15.1.4. Aprovechar el mail. 42

15. 2. Aprovechar paquetes fabricados por terceros. 43 16. Como y cuando utilizar el servidor de correo. 43

La Comunicación entre el Cliente y el Servidor. 44 1. Introducción. 44 2. Características de la comunicación. 44

2. 1. Cooperativa. 44 2. 2. Transaccional. 44 2. 3. No necesariamente sincronizada. 44

3. Tipos de comunicación. 44 3. 1. Comunicación síncrona. 44 3. 2. Comunicación asíncrona. 45 3. 3. Comunicación por eventos. 47

4. Las diferentes vías de comunicación 47 5. El modelo conversacional. 47 6. Colas. 49

6. 1. Comunicación sin respuesta o desacoplada. 49 6. 2. Comunicación con respuesta directa. 50 6. 3. Comunicación con respuesta por cola. 51 6. 4. Arquitectura de colas multicliente y multiservidor. 51 6. 5. Representación de la comunicación con servidores de cola. 51

7. Petición de servicio al Middleware. 51 7. 1. OLE y ACTIVE X 52 7. 2. ODBC. 52 7. 3. ADO. 53 7. 4. ODBC o ADO. Servidores de Bases de Datos. 55 7. 5. Servidores de SQL. 55 7. 6. Procedimiento catalogado. 55 7. 7. Vías de acceso a Internet. 55

8. Remote Procedure Call (RPC). 56 9. Comparación entre colas (MOM) y RPC. 58 10. Simple Object Access Protocol (SOAP). 59 11. Modelos de objetos distribuidos. 59 12. La comunicación por eventos. 59 13. Mecanismo ECA. 60 14. Comunicaciones remotas. 61 15. Comunicaciones inalámbricas. 61 16. Un ejemplo de utilización. 62

XML 64 1. Introducción. 64 2. Introducción al XML. 64 3. Componentes de un documento XML. 65

3. 1. Marcas. 65 3. 2. Elementos. 65 3. 3. Atributos. 66 3. 4. Comentarios. 66

4. Creación de lenguajes. 66 5. Utilidad de XML 66 6. Utilización de XML para interfaces. 67 7. Ficheros de configuración y administración. 67 8. El binomio XML + SQL. 68


9. Internet y XML. 68 10. XML y conexiones con terceros. 68 11. XML e integración de sistemas. 69 12. XML y Workflow. 69

Arquitectura de la comunicación en un sistema distribuido. 70 1. Diálogo y complejidad de un sistema distribuido. 70 2. Organización cuasi-jerárquica de diálogo. 70 3. El problema de la congestión. 71 4. El estilo Pull de comunicaciones. 72 5. Push y Pull en Internet. 73 6. El diálogo entre clientes. 73

Programación de Aplicaciones Distribuidas. Metodología Puzzle 75 1. Introducción. 75 2. Internet y piezas/componentes de software. 75 3. Influencia del paradigma y las técnicas en Cliente/Servidor basado en Sistema Operativo o

Internet. 76 4. Implementación por programación de piezas. 76 5. Piezas y Clusters. 76 6. Piezas y Middleware “comprado”. 77 7. Piezas y Middleware de mundo del software libre. 77 8. La metodología Puzzle. 77 9. Técnicas para construir piezas. 78 10. El contrato de comportamiento de una pieza. 78 11. “Cuatro ideas” sobre especificación de piezas. 79

11. 1. Lenguajes de especificación. 79 11.1.1. Métodos de análisis. 79 11.1.2. Métodos formales. 79 11.1.3. Métodos de texto libre. 79 11.1.4. Métodos semiformales. 80

11. 2. Partes de la especificación de una pieza. 80 11.2.1. Global. 80 11.2.2. Los servicios. 81 11.2.3. El formato de cabecera de una rutina como método de especificación de un servicio. 81 11.2.4. Especificación del comportamiento de los errores. 82 11.2.5. Especificación de eventos y triggers. 83

12. Implementación de la pieza y paradigma de programación. 83 12. 1. Programación estructurada. 83 12. 2. Programación orientada a objetos y tipos abstractos de datos. 84

13. Implementación de Invariantes. 84 14. Integración de las piezas. 85 15. Certificación de una pieza. 85

15. 1. Necesidad de certificar. 85 15. 2. Metodología de certificación. 85 15. 3. Certificación y verificación analítica. 86 15. 4. Comentario final. 86

Gestión y Reusabilidad de Piezas y Componentes. 87 1. Introducción. 87 2. Construcción de componentes. 87

2. 1. Cualidades que debe cumplir un buen componente. 87 2. 2. Componentes arquitectónicos (Framework). 87 2. 3. Reusabilidad y costes de proyecto. 88 2. 4. Documentación. 88

3. Gestión de componentes (Component Management). 89 3. 1. Actividades ligadas con el desarrollo. 89 3. 2. Actividades de administración. 89

4. El Comité de Componentes. 90 5. La gestión de componentes desde el proyecto. 91


6. El ciclo de vida de un componente. 92 Distribución del peso de la aplicación entre clientes y servidores. 94

1. Introducción. 94 2. Distribución del peso de la aplicación. 94 3. Fat Clients. 94 4. Fat Server. 95 5. ¿Fat Client o Fat Server? 95

Diseño y Programación de Clientes. 97 1. El cliente y sus atributos básicos. 97 2. Diseño del Cliente. 97 3. Las lógicas en el diseño del cliente. 98

3. 1. Lógica de Presentación. 98 3. 2. Lógica de Datos. 98 3. 3. Lógica de proceso. 98 3. 4. Lógica de Control. 98 3. 5. Lógica de negocio. 98

4. Metodologías para diseñar la arquitectura del cliente. 100 4. 1. Basado en la lógica de presentación 100 4. 2. Basado en la lógica de proceso o de control. 100 4. 3. Basado en la lógica de datos. 101

5. Diseño de la lógica de presentación. 101 5. 1. Técnicas GUI (Grafic User Interface). 101 5. 2. Técnicas OOUI (Object Oriented User Interface). 102

6. Clientes Background y Agentes. 102 7. Que necesita el programa cliente del Netware Operating System (NOS). 104 8. Transportabilidad y transparencia del cliente. 104 9. Herramientas de desarrollo para la parte cliente. 104

9. 1. Herramientas profesionales. 104 9.1.1. Herramientas de desarrollo rápido (RDA). 105 9.1.2. Herramientas de desarrollo avanzado 105 9.1.3. Entornos integrados 4GL orientados a objetos y cliente / servidor. 105 9.1.4. Monitores de transacciones 105 9.1.5. Herramientas de desarrollo en Internet. 105

9. 2. Herramientas de usuario final. 105 9.2.1. Hojas de cálculo y otros recursos de los paquetes de ofimática. 105 9.2.2. Bases de datos tipo Access. 105 9.2.3. Lenguajes de usuario ligados a los 4GL. 105

Diseño y Programación de Servidores. 107 1. El servidor y sus atributos básicos. 107 2. Fundamentos del diseño de servidores. 107

2. 1. Fundamentos del diseño de servidores. 107 2. 2. Condicionamientos de diseño. 108

3. Las lógicas y el diseño de servidores. 108 4. Multiservidores y paralelismo. 108 5. ¿Qué necesita el servidor del NOS + DSM? 109 6. Implementación y programación de servidores. 109

6. 1. Programación. 109 6. 2. La “cara” del servidor. 110 6. 3. La ficha de enviroment del servidor. 110 6. 4. Como conseguir independencia del sistema. 111

Arquitectura de Servidores/Servicios. 113 1. Introducción. 113 2. Multiserver Data Flow. 113

2. 1. Modelo dirigido por el cliente. 114 2. 2. Modelo dirigido por los servidores (interservidores). 114

3. Concepto de Arquitectura de Servidores. 114


4. Delegación de Servicio o Orquestación 115 5. Arquitecturas con mensaje anexo. 117 6. Traspaso de Responsabilidad. 118 7. Redirección. 119 8. Servidores Interceptores. 120 9. Servidores Pasarela. 120 10. Broadcast Data Flows. 122 11. Arquitectura de Filtro (Filtered Data Flows). 122 12. Servidores Master-Slave. 123 13. Servidores de Distribución. 125 14. Arquitectura de Pre-Condición. 126 15. Arquitectura de configuración. 127 16. Arquitectura de Representante o Proxy. 130

16. 1. Mejorar el rendimiento. 130 16. 2. Poliformar la fuente del servicio. 131 16. 3. Incluir consistencia. 131

17. La estructura del mensaje. 131 18. Arquitectura completa del ejemplo del capitulo anterior. 132

Arquitectura Orientada a Servicios - SOA 133 1. Los servicios como base del diseño distribuido. 133 2. Concepto de servicio. 133 3. Principios del diseño de servicio. 134

3. 1. Abstracción. 134 3. 2. Generalización. 135 3. 3. Seguimiento de estándares. 135 3. 4. Granularidad. 135

3.4.1. Ventajas de la granularidad Coarse Graneid. 135 3.4.2. Ventajas de la granularidad Fine Graneid. 135

4. Puntos de articulación. 136 5. Principios de SOA. 136 6. Arquitectura de SOA. 137

6. 1. Arquitectura de Aplicación. 137 6. 2. Arquitectura de Servicios. 137 6. 3. Arquitectura de Componentes. 138

7. Ventajas de SOA. 138 8. Los Servicios WEB dentro de SOA. 138 9. Uso de XML en SOA. 139 10. La conclusión final. 139

Diseñando Servicios 140 1. Introducción. 140 2. Especificación del servicio. 140

2. 1. Racionalización del servicio. 140 2. 2. Consolidación del servicio. 140 2. 3. Agrupación por dominios o temas. 141

3. Arquitectura entre los servicios. 141 4. Adaptación a la arquitectura de datos distribuida. 141 5. Servicios para hacer publicas funcionalidades ya existentes (packaging). 142 6. Service routing. 143

6. 1. Utilizar los recursos estándares del Middleware. 143 6. 2. Localización en el propio servicio. 143 6. 3. Routers. 144

6.3.1. Servicio de router. 144 6.3.2. Servidor de router de dominio. 144 6.3.3. Servidor de localización. 144

Arquitectura Conducida por Eventos (EDA) y Arquitectura en Tiempo Real. 145

1. Introducción. 145


2. Arquitectura EDA. 145 3. Metodología para establecer una Arquitectura EDA. 146 4. Recursos tecnológicos. 146

Integración de Clientes y Servidores en el Middleware. 148 1. Introducción y final. 148

Ingeniería de Software y Proyectos Cliente/Servidor. 149 1. Introducción. 149 2. Características de las actividades de IS. 149

2. 1. Disponibilidad de Modelos, Métodos y Herramientas. 149 2. 2. Utiliza un proceso de fabricación. 149 2. 3. Controla la Calidad. 150 2. 4. Mejora continua del proceso. 150 2. 5. Ratio Calidad / coste. 150

3. Ingeniería de los Proyectos de Software. 150 4. Gestión de un proyecto de software. 152

4. 1. Concepto de proyecto. 152 4. 2. Dirección de un proyecto de Software. 152

4.2.1. Especificación. 152 4.2.2. Seguimiento. 152 4.2.3. Certificación de la calidad. 152

4. 3. Gestión. 152 5. Gestión técnica del proyecto. 153 6. Paradigmas de la Ingeniería de Software. 154

6. 1. El Ciclo de Vida Clásico. 154 6. 2. El prototipaje. 155

6.2.1. Construcción de una maqueta. 156 6.2.2. Construcción de una parte del sistema. 156 6.2.3. Adaptar un programa existente. 156

6. 3. El modelo en espiral. 156 6. 4. Las técnicas 4GL. 157 6. 5. La orientación a objetos. 158

7. Gestión administrativa del proyecto. 159 7. 1. Estimación. 159 7. 2. Planificación y agenda. 160 7. 3. Seguimiento, Control y Revisión. 160 7. 4. Puesta en marcha. 161 7. 5. Conclusión de la etapa de desarrollo. 161

8. Análisis de riesgos. 162 8. 1. ¿Qué se entiende por Análisis de Riesgos? 162 8. 2. Metodología. 162 8. 3. Actividades. 162

8.3.1. Identificación de los riesgos. 162 8.3.2. Cálculo del riesgo. 164 8.3.3. Proyección. 164 8.3.4. Gestión. 164

9. Una reflexión final. 164

Del Análisis Funcional/Especificación al inicio del diseño de los Sistemas Distribuidos 166

1. Posibilidades de utilización de servicios. 166 1. 1. Especificación por servicios. 166 1. 2. Diseño por/con servicios. 166 1. 3. Servicios como agentes externos. 167

2. Introducción al diseño distribuido. 167 3. Elementos comunes a cualquier metodología de diseño. 168

3. 1. La descripción de los datos. 168 3. 2. Descripción de los procesos de transformación. 168 3. 3. Secuencia en que se ejecutan los procesos de transformación. 168


4. Encaje de la etapa de diseño tecnológico en el ciclo de desarrollo del software. 170 5. Resumen de puntos de partidas según la metodología empleada. 170

Elementos funcionales y tecnológicos para la descripción de los procesos en metodologías convencionales 172

1. Introducción. 172 2. Descripción de los procesos de transformación. Diagramas de Flujo. 172 3. Extensión de los diagramas de flujo. 172

3. 1. Iconos. 173 3.1.1. Agente externo. 173 3.1.2. Entidad. 173 3.1.3. Proceso de transformación. 173 3.1.4. Salida impresa. 173 3.1.5. GUI. 173 3.1.6. Entidad implementa en BD. 173 3.1.7. Servicio. 174 3.1.8. Modelos de comunicación C/S. 174

3. 2. Secuencialización. 174 3. 3. Decisiones. 175 3. 4. Enlace entre diagramas. 175

4. Análisis descendente. 176 4. 1. Introducción. 176 4. 2. Concepto de acción, parámetro, efecto y estado. 176 4. 3. Especificación. 176 4. 4. Metodología de especificación. 176 4. 5. Descomposición de procesos. Concepto de primitiva. 176

4.5.1. Sentencias. 177 4.5.2. Rutinas ya programadas. 177 4.5.3. Piezas y / o Objetos. 177 4.5.4. Servicios. 177

4. 6. Metodología del análisis descendente. 177 4. 7. Ejemplos. 179

4.7.1. Contar consonantes después de la aparición de una vocal en un texto. 179 4.7.2. Pedir un código de cliente y sacarlo por la pantalla 180

4. 8. ¿Porqué utilizar análisis descendente? 180 5. Diagramas Jerárquicos. 180

Descripción de los Datos en un Modelo Relacional 182 1. Introducción. 182 2. Terminología básica para la descripción de los datos. El Modelo de Datos. 182 3. El Modelo Relacional. 183 4. ANSI/SPARC three schema architecture. 184

4. 1. Esquema externo (External Schema). 185 4. 2. Esquema Conceptual (Conceptual Schema). 185 4. 3. Esquema Interno (Internal Esquema). 185

5. Restricciones de integridad. 185 5. 1. Entity Integrity Constraints. 185 5. 2. Validity Check Constraints. 185 5. 3. SQL-92 domains and assertions. 185 5. 4. Referencial Integrity. 186 5. 5. Referencial triggered actions. 186 5. 6. Control de las restricciones de integridad en un sistema distribuido. 186

6. Bases de datos activas y pasivas. 187 7. Triggers. 188

7. 1. Control de Acceso. 188 7. 2. Control de Integridad. 189 7. 3. Soporte de datos. 189 7. 4. Notificación de cambios y transiciones de la BD. 189 7. 5. Medidas de rendimiento. 189 7. 6. Reglas. 189


7. 7. Gestión de triggers de la BD en entornos distribuidos. 189 8. Vistas. 189 9. ODBC/JDBC y ADO. 190 10. Procedimientos catalogados. 190

Método de Análisis Funcional para Aplicaciones de Desarrollo Rápido. 191 1. Introducción. 191 2. Método de Análisis Funcional de Desarrollo Rápido de Aplicaciones (MAFDRA). 191

2. 1. Diseño de los datos. 191 2. 2. Identificación de los procesos básicos. 191 2. 3. Diseño de los procesos. 192 2. 4. Diseño de la lógica de presentación. 192 2. 5. Organización de la explotación. 192

3. Desarrollo de un ejemplo. 193 3. 1. Reflexión previa. 193 3. 2. Especificación inicial. 193 3. 3. Diseño de datos. 194 3. 4. Identificación de los procesos básicos. 197 3. 5. Diseño del Proceso de Venta de Viajes Aéreos y Hotel. 197 3. 6. Diseño del Proceso de Estadísticas. 201 3. 7. Diseño de los componentes de presentación. 201 3. 8. Diseño de los listados. 201 3. 9. Organización de la explotación. 202

Diseño Funcional de Aplicaciones Avanzadas – Introducción a la Orientación a Objetos 203

1. Introducción. 203 2. Conceptos básicos. 203

2. 1. Introducción del Concepto OO. 204 2. 2. Terminología básica. 204 2. 3. El triángulo orientado a objetos. 205

2.3.1. Encapsulación. 205 2.3.2. Abstracción y clasificación. 205 2.3.3. Polimorfismo a través de la herencia. 205

2. 4. Clase de Objetos. 205 2. 5. Concepto de Herencia. 207 2. 6. Polimorfismo. 207 2. 7. Visibilidad de atributos y métodos. 209

2.7.1. Público. 209 2.7.2. Privado. 209 2.7.3. Protegido. 209

3. Los fundamentos de una metodología de diseño OO. 210 4. Etapas de una metodología de construcción de software OO en UML. 210

4. 1. Especificación. 210 4. 2. Diseño del sistema. 211 4. 3. Diseño de los objetos. 211 4. 4. Implementación (Implementation). 211

5. Los tres modelos de la metodología OO. 212 5. 1. Modelo de Objetos. 212 5. 2. El modelo dinámico. 212 5. 3. El modelo funcional. 213

6. Las relaciones entre los tres modelos. 213 7. Descripción del modelo de objetos. 213

7. 1. Plantilla de definición de Clases y Objetos. 213 7. 2. Diagramas de Clases y de Instancias. 214 7. 3. Asociaciones y links. 214 7. 4. Agregaciones. 216 7. 5. Algunos ejemplos de Modelos de Objetos. 217

8. Reflexión final. 218


Implementación de un modelo de objetos sobre un modelo relacional 219 1. Introducción. 219 2. Traspaso de esquemas. 219 3. Mapeo de clases. 220 4. Mapeo de asociaciones a tablas. 221

Asociaciones N a N. 221 Asociaciones 1 a N. 222 Asociaciones 1 a 1. 222

5. Agregaciones. 222 6. Herencia para definir especializaciones y generalizaciones. 222

Cada clase y cada subclase se mapea en una tabla diferente. 222 La clase padre y todas subclases se mapean en una única tabla (todo en una sola tabla). 223 Cada subclase se mapea en una tabla diferente. 223

Diseño de Aplicaciones Avanzadas por UML integrado con la metodología de diseño distribuido 224

1. Introducción. 224 2. Diseño de Sistemas por UML. 224

(a) Especificación. 224 (b) Diseño Tecnológico. 225 (c) Documentación resultante del diseño. 227 (d) Puntos de partida de la etapa de diseño distribuido. 228

3. Diagramas de despliegue. 229 (a) Diagrama de Sistema. 230 (a) Diagrama de la infraestructura. 230 (a) Diagrama de niveles físicos 231 (b) Diagrama de niveles lógicos. 231 (a) Diagrama de la Arquitectura de Servicios. 232 (a) Diagrama de Localizaciones. 233

4. Fuentes de servicios sobre un diseño UML. 234 (a) Diagramas de clases. 234 (b) Diagramas de actividad. 234 (a) Diagramas de secuencia. 236 (b) Diagramas de colaboración. 237 (a) Primera versión de la integración de servicios en clases. 237

5. Vistas de la arquitectura del Software. 238 6. Concepto de Frontera. Fronteras y nodos. 239 7. Otros factores de interés en el diseño UML distribuido. 239 8. Arquitectura de Objetos Distribuidos en la práctica. 240 9. Implementación de la arquitectura distribuida sobre un modelo OO. 242 10. Un ejemplo. 242

(a) Presentación y dominio agrupados. 251 (a) Presentación y dominio separados sin mantener el controlador. 252 (a) Presentación y dominio separados manteniendo el controlador. 253

Datos y Diseño Distribuido 256 1. Introducción. 256 2. Criterios generales de partida. 256 3. Centralizar versus distribuir: Resumen de modelos lógicos del datos. 256

3. 1. Datos en servicios en nube. 257 3. 2. Datos centralizados. 257 3. 3. Datos distribuidos. 257

3.3.1. Homogéneos. 257 3.3.2. Datos distribuidos heterogéneos. 258

4. Esquemas de niveles de datos. 258 5. ¿Por qué definir y usar modelos de datos? 258 6. Arquitectura de datos distribuidos. 259 7. Bases de datos y sistemas distribuidos. 259 8. Arquitectura de los Datos del Sistema Distribuido. 260


9. Upsizing. 260 10. Recordatorio importante. 261

Modelo Centralizado 262 1. Introducción. 262 2. Modelo centralizado de datos. 262

2. 1. El modelo pequeño. 262 2. 2. Modelo grande. 262

3. Gestión de más de un esquema físico. 263 Replicación 264

1. Una observación inicial. 264 2. Arquitectura de Datos Replicados. 264 3. Gestión de datos replicados. 265 4. Terminología de datos replicados. 265

4. 1. Replicación síncrona o asíncrona. 265 4. 2. Tipología de la forma de transmitir los cambios. 265

4.2.1. Emisión. 265 4.2.2. Cascada. 266 4.2.3. Replicación bidireccional. 266 4.2.4. Replicación entre iguales. 266

4. 3. Replica incremental. 266 4. 4. Mecanismos de replicación. 267

5. Copia principal y foco del mantenimiento. 267 6. Agrupaciones de replicación. 268 7. Replicación síncrona. 268

7. 1. Reserva de todas las replicas. 269 7. 2. Modificación de todas las copias. 269

7.2.1. Mismo nivel en todas las replicas. 269 7.2.2. Admitir diferentes niveles en las copias. 269

7. 3. Confirmación y liberación 269 8. Replicación asíncrona. 270 9. La escala copia / replica. 270

9. 1. Replicación asíncrona a petición. 271 9. 2. Replicación asíncrona planificada. 271 9. 3. Asíncrona entre iguales y bidireccional. 271 9. 4. Replicación síncrona con confirmación en dos fases. 272 9. 5. Replicación síncrona inmediata y el caliente. 272

10. Uso de técnicas Master-Slave en replicación. 273 11. “Full Tolerance” y tickets. 273 12. Mecanismos de replicación. 274

12. 1. Replicación por protocolo de dos fases. 274 12. 2. Replicación por extracción. 274 12. 3. Replicación por log's. 274 12. 4. Replicación por mensajes. 275 12. 5. Replicación por eventos. 275 12. 6. Replicación por instantáneas (snapshots). 275 12. 7. Replicación por Publicación / Suscripción. 275 12. 8. Usar los mecanismos de replicación de los gestores de la base de datos. 276

13. Utilidad del Vigía y del Disparador en gestión de replicas asíncronas. 276 14. Replicación Caché. 276

14. 1. Caché interna al programa. 277 14. 2. Caché compartida. 277

15. Data Warehouse y replicación. 277 16. Replicación virtual o Data Warehouse virtual. 277 17. Auditoria de datos replicados. 277 18. Factores a considerar en la política de replicación. 279

18. 1. Localización de las copias. 279 18. 2. Situación de la replicación en la escala copia-replica. 279 18. 3. Volatilidad. 279


18. 4. Tamaño de los datos. 279 18. 5. Tipología de la forma de transmitir los datos. 279 18. 6. Importancia de las copias y necesidades de fiabilidad. 279 18. 7. Plan de auditoria. 280 18. 8. Disponibilidad. 280 18. 9. Calendario y horario. 280 18. 10. Copiar, Reorganizar o Sumarizar. 280 18. 11. Como es el foco de mantenimiento. 280 18. 12. Desde donde se inicia la replicación. 280 18. 13. Caducidad de la replica. 280 18. 14. Preguntas de interés. 281

19. Cuestiones de interés técnico. 281 20. Política de replicación. 281 21. Los gestores de BD como Middleware de replicación. 281 22. Aplicaciones C/S basadas en sistema operativo trabajando sobre datos replicados versus

aplicaciones Internet. 282 23. Aplicaciones con mantenimiento distribuido de replicas. 282 24. Servidores de programas replicados. 283

Datos Particionados 284 1. Introducción. 284 2. Modelo particionado de datos. 284

2. 1. Mantenimiento síncrono. 284 2. 2. Mantenimiento asíncrono 284

3. Técnica. 284 3. 1. Índice. 285 3. 2. Regla de negocio. 285

4. Auditoria de datos particionados. 285 5. Una reflexión final. 285

Codificación distribuida 286 1. Introducción. 286 2. Criterios de asignación de códigos. 286 3. Gestión de la codificación distribuida. 287

3. 1. Verificación síncrona 287 3. 2. Verificación asíncrona. 287 3. 3. Asignación dinámica. 288

4. Cambios de código en bloque. 288 Aplicación del Patrón DTO 289

1. Introducción. 289 2. Aplicación del patrón DTO. 289

2. 1. Obtención de registro o registros. 289 2. 2. Gestión del DTO. 289 2. 3. Modificación de la base de datos. 289

Servicios de Agrupación de Entidades de Datos 290 1. Introducción. 290 2. Precondiciones. 290 3. Sistematización de la casuística. 291

3. 1. Visión unificada de una entidad. 291 3. 2. Partición horizontal. 291 3. 3. Escenarios de agregación. 291

4. El metaesquema. 291 5. Servicio de Agrupación de Entidades. 293

5. 1. Por servicios. 293 5. 2. Por replicación. 293 5. 3. Por servicios y replicación. 295

6. Semántica CRUD (Create-Read-Update-Delete). 295 7. Semántica CRUD en la arquitectura por servicios. 295


8. Semántica CRUD en la arquitectura por replicación. 296 9. Implementación utilizando los recursos del motor de la base de datos. 298

Metodología de Diseño Distribuido 299 1. Introducción. 299 2. Recordatorio de las Etapas de Diseño. 299

2. 1. Aplicaciones avanzadas. 300 2. 2. Aplicaciones RAD. 300

3. Metodología Integrada de Diseño. 300 4. Contenido de cada una de las etapas. 301

4. 1. Análisis Funcional /Especificación – Diseño de la arquitectura del tecnológico. 301 4. 2. Determinación de las precondiciones de la plataforma. 302

4.2.1. Identificación de las fronteras. 302 4.2.2. Determinación de los puntos de heterogeneidad. 302

4. 3. Diseño de la Arquitectura Distribuida. 302 4.3.1. Análisis de los datos. 303 4.3.2. Distribución del Proceso de la Aplicación. 303 4.3.3. Creación de la Arquitectura de Servicios. 303 4.3.4. Map to reality. 304

4. 4. Diseño de consistencia. 305 4. 5. Diseño de la administración del sistema. 305 4. 6. Identificación y especificación de piezas. 306 4. 7. Diseño de los Clientes. 307 4. 8. Plan de Integración. 307

Diseño de la Arquitectura Distribuida de Servicios 309 1. Introducción. 309 2. Etapas del Diseño de la Arquitectura de servicios del Sistema Distribuido. 309 3. Análisis de los datos 309

3. 1. Prerrequisitos. 310 3.1.1. Puntos de heterogeneidad. 310 3.1.2. Niveles Lógicos. 311 3.1.3. Factores de gestión y proceso. 311 3.1.4. Tiempos de respuesta admisibles. 311 3.1.5. Codificación distribuida. 311

3. 2. Diseño de los Datos. 311 3.2.1. Diseño de la Arquitectura de Datos Distribuida. 312 3.2.2. Mantenimiento y auditoria. 312 3.2.3. Adaptar el Diseño Funcional. 312 3.2.4. Diseño de la Lógica de Datos Distribuida. 312 3.2.5. Especificar la Arquitectura y la Lógica de los Datos. 314

3. 3. Analizar el rendimiento (Perfomance). 315 4. Criterios para diseñar la arquitectura de datos. 316

4. 1. Localización Obligada. 316 4. 2. Criterios funcionales. 316

4.2.1. Criterios independientes de la optimización del rendimiento a la plataforma. 317 4.2.2. Criterios dependientes de la optimización del rendimiento a la plataforma. 318

5. Un interesante dilema sobre la gestión de las restricciones de integridad. 319 6. Distribución del Proceso de la Aplicación. 319

6. 1. Identificar Funciones. 320 6. 2. Distribuirlas por Niveles Lógicos. 320 6. 3. Separar funciones entre clientes y servidores. 320

6.3.1. Por la localización de las clases y las instancias de los objetos. 321 6.3.2. Por la tipología de las tareas. 321 6.3.3. Por los datos. 322 6.3.4. Por los recursos. 322 6.3.5. Por la oferta de los servicios. 322 6.3.6. Por los condicionamientos de organización. 322 6.3.7. Por la administración del sistema. 323 6.3.8. Usuarios remotos y nómadas. 323


6. 4. Identificar servicios. 324 6. 5. Un pequeño ejemplo en MAFDRA. 325

7. Creación de la Arquitectura Distribuida. 328 7. 1. Definir el tipo de comunicación. 329 7. 2. Definir la arquitectura entre los servicios. 329 7. 3. Documentar la Arquitectura Distribuida. 330 7. 4. Analizar la solución obtenida. 330 7. 5. Creación de la Arquitectura Distribuida del ejemplo de venta de productos. 330

7.5.1. Elección del Modelo de comunicación. 331 7.5.2. Arquitectura de servidores. 331

8. Map to Reality. 331 8. 1. Localización. 332 8. 2. Configuración. 332 8. 3. Analizar rendimiento. 332

9. Diseño de la Arquitectura distribuida del ejemplo de la venta de viajes aéreos y hotel. 333 9. 1. Análisis de datos. 333

9.1.1. Arquitectura distribuida de los datos. 334 9.1.2. Mantenimiento y auditoria. 335 9.1.3. Adaptación del diseño. 336

9. 2. Diseño de la Arquitectura Distribuida. 339 9.2.1. Diseño de la lógica de datos distribuida e identificación de servicios. 339 9.2.2. Elección del modelo de comunicación. 341 9.2.3. Creación de la Arquitectura Distribuida. 343 9.2.4. Map to Reality. 350

9. 3. El diseño de los Servicios WEB. 350 9. 4. Diagrama jerárquico modificado. 351

Políticas de Administración de un Sistema Distribuido. 353 1. Introducción. 353 2. La administración de sistemas distribuidos. 353 3. Áreas de actividades en la administración de un sistema distribuido. 354 4. Organización de la administración. 355

4. 1. El Centro de Dirección del Sistema Distribuido (CDSD). 355 4. 2. El Centro de Administración del Sistema Distribuido (CASD). 355 4. 3. El Centro de Soporte a usuarios del Sistema Distribuido (CSSD). 356

5. Estrategias de administración. 356 6. La plataforma estándar. 357

6. 1. Definición de la plataforma estándar. 357 6. 2. Administración de la plataforma estándar. 357 6. 3. Organización de la administración del cliente sobre la plataforma estándar. 358 6. 4. Delimitación de responsabilidades. 358

7. Área de planificación. 359 8. Área de administración de datos. 360

8. 1. Definir las políticas de administración. 361 8. 2. Gestión de la localización, planificación de la capacidad y planificación de migraciones. 361 8. 3. Gestión de uso. 361 8. 4. Gestión del rendimiento. 361 8. 5. Gestión de la disponibilidad de los datos. 362 8. 6. Gestión de la coherencia, seguridad y el back-up y recuperación. 362 8. 7. Monitoring de datos. 362 8. 8. Gestión de eventos y alertas de datos. 362

9. Actividades del área de soporte a usuarios. 362 9. 1. Organización operativa del soporte. 363 9. 2. Formas del soporte a usuarios. 364

9.2.1. Hot-Line. 364 9.2.2. Reuniones. 366

9. 3. Facilidades para el soporte a usuarios. 366 9.3.1. Ayudas en línea. 366 9.3.2. Definición de procedimientos de actuación. 366 9.3.3. Estandarización de la operativa de los programas. 367


9. 4. Nivel de aceptación del servicio. 367 10. Área de Inventario y Monitoring. 368 11. Actividades de Monitoring. 368

11. 1. El modelo de Monitoring. 368 11. 2. La actividad de medir. 369 11. 3. Los datos de calidad de servicio. 370

12. Registro del Inventario de activos tecnológicos. 371 13. La gestión del repositorio de administración. 371 14. Area de Análisis de la gestión: Auditoria del Outsourcing 372 15. Área de costes. 373 16. Análisis de la gestión de errores. 373 17. Área de gestión y control. 373

17. 1. Cuadro de mandos del sistema distribuido. 374 17.1.1. Filosofías de integración. 375 17.1.2. Cuadro de mandos de explotación o administración. 375 17.1.3. Cuadro de mandos de seguimiento del estado del negocio. 377

17. 2. Consola única 377 18. Características de las actividades de Administración de clientes. 378 19. Administración de servidores. 378 20. Gestión remota y desatendida de clientes y servidores. 378 21. Localización de recursos. 379 22. SOA Governance. 380 23. Estrategias de actuación en la administración. 380

23. 1. Esperar a que pase el problema. 380 23. 2. Administración desde el usuario. 380 23. 3. Administración remota. 381 23. 4. Que le recomiendo. 381

23.4.1. Soporte de la plataforma y distribución e instalación del software de aplicación: 381 23.4.2. Parametrización y soporte del software de aplicación: 381

24. Repercusión del coste. 381 25. Clasificación de las actividades de administración por su naturaleza. 381 26. Diseño de la administración del sistema. 382 27. Que dice la experiencia.... 383

Diseño e Implementación de Actividades de Administración de Sistemas.385 1. Introducción. 385 2. Captura de las direcciones variables de IP. 385 3. Copias de Seguridad (Back-up y Restore). 386

3. 1. Condicionantes. 386 3.1.1. Capacidad de los dispositivos de Back-up. 386 3.1.2. Tiempo necesario para hacer la copia. 386 3.1.3. Dispersión de lógica de información. 386 3.1.4. Dispersión geográfica. 386 3.1.5. Diferencias de calendario y horario. 386

3. 2. Estrategias de copias de seguridad. 387 3.2.1. Áreas y ámbitos de datos. 387 3.2.2. Gestión de cada una de las áreas. 387 3.2.3. Responsabilidad de cada ámbito. 388 3.2.4. Calendario. 389 3.2.5. Momento. 389 3.2.6. Lugar. 390 3.2.7. Rotación. 390 3.2.8. Almacén. 390 3.2.9. Tipos de gestión. 390

3. 3. Las herramientas. 391 3. 4. Implementación de copias automatizadas. 391 3. 5. Algunas estrategias habituales de back-up. 391

3.5.1. Back-up distribuido. 391 3.5.2. Back-up de usuario sobre el entorno departamental. 392 3.5.3. Back-up departamental. 392


3.5.4. Back-up departamental centralizado. 393 3.5.5. No back-up y reconstrucción. 394

4. Consolidación de datos. 394 5. Administración de impresoras. 394

5. 1. La impresión en entornos distribuidos. 394 5. 2. Formas de conectar las impresoras. 394

5.2.1. A un servidor dedicado. 395 5.2.2. A una máquina cliente. 395 5.2.3. A un Printer Server. 395

5. 3. Estrategias. 395 5. 4. Organización jerárquica de los grupos de impresión. 395

5.4.1. Nivel Usuario. 396 5.4.2. Nivel grupo de usuarios. 396 5.4.3. Nivel Departamental. 397 5.4.4. Nivel Centralizado o Corporativo. 397 5.4.5. Impresión entre ramas. 397

5. 5. Implementación de las estrategias de administración de impresoras. 398 6. Administración de usuarios y derechos. 398

6. 1. Organización de usuarios y gestión de los derechos. 399 6. 2. Gestión de directorios con información restringida. 400 6. 3. Gestión de los derechos de impresión. 401 6. 4. Implementación del perímetro de seguridad. 401

6.4.1. Perímetro de seguridad múltiple. 401 6.4.2. Perímetro de seguridad único. 402

6. 5. Una posible arquitectura de un servicio de identificación. 402 7. Gestión del software. 403

7. 1. Distribución y control del software. 403 7.1.1. Localización de los programas. 403 7.1.2. Control y distribución de versiones. 403

7. 2. Distribución de replicas de ficheros fijos. 404 7. 3. Herramientas disponibles. 404

7.3.1. Utilizar paquetes. 405 7.3.2. Utilizar herramientas de DSM. 405

8. Aportaciones del Diseño de Administración del Sistema al NOS+DSM. 405 9. Algunas ideas más. 405

Diseño de Consistencia 406 1. Objetivos del Diseño de Consistencia. 406 2. ¿Por qué y como caen los servidores? 407 3. La consistencia por plataforma redundante. 408 4. Ciclo del Análisis de Consistencia. 408 5. Gestión de errores en un sistema distribuido. 410

5. 1. Elementos para el análisis de los errores. 411 5.1.1. Tipos de errores. 411 5.1.2. Destinatario. 412 5.1.3. Nivel de gravedad. 412

6. Análisis histórico de los errores. 413 7. Implementación de la gestión de errores. 413 8. Gestión de la concurrencia, el paralelismo y la recuperación. 415 9. Tipificación del comportamiento del servidor: semántica de servidores. 416

9. 1. Servidor “may be” (quizás). 416 9. 2. Servidor “at least once” (al menos una vez). 416 9. 3. Servidor “at most once” (como máximo una vez). 417 9. 4. Servidor “exactly once” (exactamente una vez). 417 9. 5. Implementación de semántica en servicios montados sobre colas. 417

9.5.1. Atributos de la comunicación. 418 9.5.2. Anotación del servicio por el cliente: 418 9.5.3. Comunicación cola/servidor. 418 9.5.4. Respuesta de la cola al cliente. 418

9. 6. Servidores de datos y comportamiento “at most one”. 419


9.6.1. Protocolo de dos llamadas. 419 9.6.2. Mecanismo de “Call-back” (llamada al origen). 420 9.6.3. Mecanismo de Confirmación por Lectura. 420 9.6.4. Mecanismos de control de la replicación. 420

9. 7. Arrancadas alternativas. 420 10. Utilización de arquitecturas Proxy. 420 11. El problema de los huérfanos. 421 12. Arrancada del servidor desde el cliente. 421 13. Gestión de la situación de emergencia. 421

13. 1. Componentes de la gestión de la situación de emergencia. 422 13.1.1. Una agrupación de trabajo de servidores. 422 13.1.2. Semáforo de disponibilidad. 423 13.1.3. El vigilante. 423 13.1.4. Log’s para registrar el trabajo en emergencia. 424

13. 2. Ciclo de trabajo en emergencia. 424 14. Anotación del diseño de consistencia sobre los diagramas de flujo en MAFDRA. 426 15. Metodología del Análisis de Consistencia. 426

15. 1. Definir la Semántica de Comportamiento de los Servidores. 427 15.1.1. Definición y Análisis. 427 15.1.2. Diseño de la Implementación. 427

15. 2. Análisis de los errores. 427 15.2.1. Identificación. 427 15.2.2. Gestión. 427 15.2.3. Administración. 427

15. 3. Análisis de la Situación de Emergencia. 428 15.3.1. Definir la Política General. 428 15.3.2. Negociación. 428 15.3.3. Análisis de la Caída en Emergencia. 428 15.3.4. Análisis del Trabajo en Emergencia. 428 15.3.5. Análisis de la Vigilancia. 428 15.3.6. Análisis de la Recuperación. 428

15. 4. Diseño Tecnológico. 429 15.4.1. Diseño de los Procesos. 429 15.4.2. Preparar el Plan de Integración. 429

16. El proceso paralelo como técnica de consistencia. 429 17. Diseño de Consistencia de la aplicación de Viajes Aéreos y Hoteles. 429

17. 1. Semántica de servidores. 429 17.1.1. Leer Datos Cliente. 429 17.1.2. Leer Datos Cliente en la Central. 429 17.1.3. Alta Cliente en la Central. 429 17.1.4. Actualizar Datos de Venta de Clientes en la Central. 430 17.1.5. Actualización de Datos de la Compañía aérea. 430 17.1.6. Consulta de Hoteles. 430 17.1.7. Actualizar Datos de Hoteles. 430 17.1.8. Impresión de la Reserva para el cliente. 430 17.1.9. Servidor de Correo. 430 17.1.10. Servidor de Cola. 431

17. 2. Análisis de errores. 431 17.2.1. Identificación. 431 17.2.2. Gestión. 431 17.2.3. Administración. 431

17. 3. Diseño de la Situación de Emergencia. 431 17.3.1. Definición de la política general. 431 17.3.2. Análisis de la caída en emergencia. 433 17.3.3. Análisis del trabajo en emergencia. 433 17.3.4. Análisis de la vigilancia. 433 17.3.5. Análisis de la recuperación. 433

17. 4. Diseño Tecnológico. 433 17.4.1. Diseño de los procesos. 433


17.4.2. Preparar el Plan de Integración. 437 18. Diseño de Administración de la aplicación de Viajes Aéreos. 438

Integración funcional del Cliente. 439 1. Introducción. 439 2. La implementación del cliente. 439

2. 1. Decidir del modelo de Integración Funcional. 439 2. 2. Crear la lógica de presentación y/o los flujos de los procesos. 439 2. 3. Crear las lógicas de proceso y de datos del cliente. 440 2. 4. Especificación de las piezas cliente. 440 2. 5. Modificar y ampliar el cuadro de control del sistema distribuido. 440 2. 6. Diseñar el cuadro de mandos del negocio. 440

3. Perfiles de usuario e integración. 441 4. Modelos de Integración. 441 5. Modelos en los cuales la iniciativa la lleva el usuario con una interfície convencional. 442 6. Integración grafica multivista. 443 7. Portal. 443

7. 1. Portales de contenidos. 444 7. 2. Portales de aplicación. 444 7. 3. Portales de proceso. 444

8. Clientes ligeros. 445 8. 1. Ventajas. 445 8. 2. Inconvenientes. 446

9. Integración transaccional. 446 10. Integración basada en Internet. 447 11. Clientes Back-Ground. 448 12. Integración Batch. 449

12. 1. Control de llegada de toda la información necesaria. 450 12. 2. Control de ejecución. 450 12. 3. Notificación de resultados 450 12. 4. Formas de montar una arquitectura batch. 450

12.4.1. Ejecución centralizada. 450 12.4.2. Ejecución distribuida. 450

13. La integración por estereotipos o agentes. 451 14. Procesador distribuido. 452 15. Integración por Workflow. 455

15. 1. Trabajo Cooperativo. 455 15. 2. Workflow de procesos. 455 15. 3. Workflow de datos: Sistema de Gestión de documentos. 456

16. Integración por publicación y suscripción. 456 17. Integración por objetos distribuidos. 457 18. Los papeles múltiples. 457 19. La integración basada en sistema operativo desde Internet. 459

Integración por publicación y suscripción. 460 1. Introducción. 460 2. ¿Qué es integrar por publicación y suscripción? 460 3. Caracterización del mensaje y la suscripción. 461 4. Paradigmas. 462

4. 1. Publicación Broadcast. 462 4. 2. Solicitud y respuesta. 462 4. 3. Solicitud y respuesta Multicast. 462 4. 4. Transaccional. 462

5. Arquitectura de publicación y suscripción. 462 5. 1. Los interlocutores. 463 5. 2. El Bus 463 5. 3. La publicación. 463 5. 4. La noticia. 463 5. 5. El mensaje. 463 5. 6. La lista de distribución. 463


5. 7. El adaptador. 463 5. 8. El distribuidor. 463 5. 9. La memoria. 464

6. Tipología de adaptadores. 465 6. 1. Adaptadores de mensaje completo. 465 6. 2. Adaptadores de archivo con mensaje de aviso. 466 6. 3. Adaptadores de archivo sin mensaje de aviso. 466 6. 4. Adaptadores sobre BD. 466 6. 5. Adaptadores basados en correo electrónico. 466 6. 6. Adaptadores basados objetos distribuidos. 466 6. 7. Adaptadores fabricados por proveedores de componentes. 466

7. Publicación y Suscripción versus comunicación cara a cara. 466 8. Herramientas para la capa de mensajería o transporte. 467

8. 1. Herramientas de Middleware de mensajes (MOM). 467 8. 2. Herramientas de RPC. 467 8. 3. Modelos de objetos distribuidos. 467 8. 4. Gestores de Colas. 467 8. 5. Correo electrónico. 467 8. 6. Monitores de transacciones. 467 8. 7. Software propio en integración intracorporativa. 468 8. 8. Bus basado en Internet. 468

8.8.1. Cliente HTML puro localizado en la WEB. 468 8.8.2. Cliente HTML usando otro módulo del sistema WEB. 468 8.8.3. Uso de Applet. 468

El Servidor de Versiones 469 1. ¿Qué es un servidor de versiones? 469 2. Especificación de los niveles lógicos de la plataforma. 469 3. Elementos a sincronizar. 469 4. Arquitectura del servidor de versiones. 470 5. La actualización a través de Internet, 473 6. Generalización. 473 7. Arquitectura de replicación, 474

Técnicas de diseño por Modelos de Aplicación. 475 1. Cuadro de técnicas por modelos de diseño. 475

Interfícies Gráficas de Usuario 476 1. Introducción. 476 2. Qué es una Interfície Gráfica de Usuario. 476 3. Elementos de una Interfície Gráfica. 477 4. Tipos de Ventanas. 478

4. 1. Principal (Main). 478 4. 2. Hija (child). 478 4. 3. Pop-Up. 479 4. 4. Response. 479

5. Controles. 479 5. 1. Botones (Command Button). 480 5. 2. Botón de imagen (Picture Button). 481 5. 3. RadioButton. 481 5. 4. CheckBox. 481 5. 5. Lista desplegable (ListBox). 481 5. 6. Línea de edición (SingleLineEdit). 481 5. 7. Línea de edición múltiple. 481 5. 8. Barras de desplazamiento. 482 5. 9. Pestañas (TabSet). 482 5. 10. Rejillas (Grids). 482 5. 11. Cajas de Diálogo. 482

6. Menú. 483 7. Los mensajes. 483


7. 1. Indicadores de acción. 483 7. 2. Indicadores de progresión. 483 7. 3. Mensajes informativos. 483 7. 4. Mensaje de Aviso. 484 7. 5. Mensajes de Error o Anomalía. 484

8. Técnicas Drag&Drop. 484 Identificación de Objetos Visuales y Diseño Tecnológico de GUI’s. 485

1. Introducción. 485 2. Objetos Visuales y Orientación a Objetos. 485 3. Identificación de Clases Visuales relacionadas con una GUI. 485

3. 1. Aplicación. 486 3.1.1. Atributos. 486 3.1.2. Métodos. 486

3. 2. Objeto Visual. 487 3.2.1. Atributos. 487 3.2.2. Métodos. 487

3. 3. Especializaciones de la Clase Objeto Visual. 487 3.3.1. Ventana. 487 3.3.2. Control. 487

3. 4. Control Activo. 488 3.4.1. Clases de Edición. 488 3.4.2. Botones. 488 3.4.3. Cajas de selección. 488

3. 5. Control pasivo. 488 3.5.1. Textos. 488 3.5.2. Figuras. 488

3. 6. Iconos. 488 3. 7. Menús. 488

3.7.1. Menú principal. 488 3.7.2. Menú de Contexto. 488

4. Programación de interfícies gráficas. 489 5. Objetos visuales derivados. 489

5. 1. Especialización. 489 5. 2. Integración. 490

6. Composición de Objetos Visuales. 490 7. Recomendaciones. 491

7. 1. De uso de los objetos. 491 7. 2. De tratamiento de los eventos. 491

8. Una reflexión final. 491 Diseño Funcional de la Lógica de Presentación. 492

1. Introducción. 492 2. Diseño funcional de interfícies gráficas. 492 3. Elementos del diseño funcional. 492

3. 1. Perfil. 492 3. 2. Identificación de usuario. 492 3. 3. Metáfora o Analogía. 492 3. 4. Modelo de Conocimiento. 492 3. 5. Ergonomía. 493 3. 6. Imagen (Look). 493 3. 7. Comodidad. 493 3. 8. Técnicas gráficas disponibles. 493

4. Principios Básicos del Lenguaje Visual. 493 4. 1. Organización. 493

4.1.1. Principio de consistencia. 493 4.1.2. Normas de visualización. 494 4.1.3. La composición espacial. 494

4. 2. Economía. 494 4.2.1. Simplicidad. 495


4.2.2. Claridad. 495 4.2.3. Diferenciación. 495 4.2.4. Énfasis. 495

4. 3. Comunicación. 495 4.3.1. Factores. 496 4.3.2. División del mensaje. 496 4.3.3. Vistas múltiples. 497 4.3.4. Color y textura. 497

4. 4. Normativas y recomendaciones. 498 4. 5. Los flujos de diálogo. 498

4.5.1. Ventanas nodales. 499 4.5.2. Ventanas no nodales. 499

5. Metodología de Diseño de interfícies Gráficas. 500 5. 1. Definición de los modelos. 501

5.1.1. Modelo de diseño. 501 5.1.2. Modelo gráfico de usuario. 501 5.1.3. Modelo del usuario o percepción del usuario. 501 5.1.4. La imagen del sistema. 502

5. 2. Análisis y modelación de las tareas para crear el modelo gráfico de usuario. 502 5. 3. Formalización del diseño en la interfície. 503 5. 4. Evaluación de la interfície. 503 5. 5. Entrega de la interfície. 504

6. Criterios a tener en cuenta en el diseño. 504 6. 1. Criterios de interacción con el usuario. 504 6. 2. Criterios de visualización de la información. 504 6. 3. Criterios de entrada de datos. 504

7. Una reflexión final. 505 Construcción de Frameworks. 506

1. Introducción. 506 2. El Paradigma MVC. 506 3. Multivistas, especialización y jerarquía de vistas. 507 4. Arquitectura de Diseño de un Framework. 508

4. 1. Arquitectura de bloques. 508 4.1.1. La interfície gráfica (GUI) del Framework. 508 4.1.2. El modelo. 508 4.1.3. La persistencia. 508 4.1.4. Los atributos del Framework. 508 4.1.5. La Lógica de proceso del Framework. 508 4.1.6. El entorno (enviroment). 509

4. 2. Modelo de Objetos del Framework. 509 4. 3. La Clase Entorno. 509 4. 4. Consejos para hacer Framework de uso general. 510

La Comunicación por eventos como vía para obtener servicios. 511 1. Introducción. 511 2. La comunicación por eventos como vía para pedir servicios. 511 3. Inclusión de los eventos en los diagramas de flujo. 513

Reingeniería de Sistemas. 516 1. Introducción al concepto de Reingeniería. 516 2. Los beneficios del efecto 2000 y del EURO. 517 3. La evolución por escenarios y el flujo de los sistemas de información hacia la integración. 518 4. La migración de los datos. 518

4. 1. Problemas clásicos. 518 4. 2. Pasos a seguir. 519

5. Maquillaje de aplicaciones existentes. 519 6. Upsizing de sistemas. 519 7. El papel de los Mainframe. 520 8. Técnicas de envolvente del HOST. 520


9. Downsizing. 523 10. EAI: Integración de aplicaciones corporativas. 524

10. 1. Etapas. 526 10.1.1. Definición clara de los objetivos que motivan la necesidad. 526 10.1.2. Integración de datos. 527 10.1.3. Identificación, diseño y publicación de los servicios de proceso. 527 10.1.4. Implementación de los procesos de negocio involucrados. 527 10.1.5. Revisión de los procesos de negocio internos. 527 10.1.6. Integración de procesos externos con terceros. 527

11. La consolidación de recursos de plataforma. 527 11. 1. Preparación. 528 11. 2. Desarrollo. 529 11. 3. Mejora. 529

12. Reingeniería de procesos de negocio. 529 INDICE DE LA SEGUNDA PARTE 530

INDICE DE FIGURAS DE LA SEGUNDA PARTE 552

INDICE DE FIGURAS DE LA SEGUNDA PARTE Figura 1. Representación de semáforos......................................................................... 14 Figura 2. Representación de un Ticket........................................................................... 16 Figura 3. Tickets Multihoja.............................................................................................. 18 Figura 4. Representación de una cola............................................................................ 19 Figura 5. Dinámica de referencias.................................................................................. 22 Figura 6. Colas multicliente y multiservidor .................................................................... 25 Figura 7. Servidor de Cola.............................................................................................. 26 Figura 8. Ejemplo de utilización de un servidor de cola: Anotación y Replicación

asíncrona ............................................................................................................ 26 Figura 9. Consulta de un ticket multihoja........................................................................ 27 Figura 10. Parametrización de una cola ......................................................................... 28 Figura 11. Consulta de una cola..................................................................................... 28 Figura 12. Gestión de la anotación en una cola ............................................................. 29 Figura 13. Servidor de Impresión ................................................................................... 29 Figura 14. Representación del vigía ............................................................................... 30 Figura 15. Representación del disparador...................................................................... 30 Figura 16. Representación del Servidor de Correo ........................................................ 30 Figura 17. Arquitectura básica de un servidor de correo................................................ 31 Figura 18. Funcionamiento básico de un Servidor de Correo ........................................ 33 Figura 19. Posibilidades de parametrización de un Servidor de Correo ........................ 34 Figura 20. Representación del servidor de Notas y Avisos ............................................ 35 Figura 21. Representación del cartero ........................................................................... 37 Figura 22. Esquema de comunicación síncrona............................................................. 45 Figura 23. Esquema de comunicación asíncrona........................................................... 46 Figura 24. Representación del modelo conversacional.................................................. 48 Figura 25. Relación conversacional entre cliente y servidor .......................................... 48 Figura 26. Representación de una cola.......................................................................... 49 Figura 27. Comunicación sin respuesta ......................................................................... 50 Figura 28. Comunicación con respuesta directa ............................................................ 50 Figura 29. Comunicación con respuesta por cola .......................................................... 51 Figura 30. Arquitectura de colas multicliente y multiservidor.......................................... 51 Figura 31. Representación de la comunicación desacoplada y asíncrona por medio de

una cola .............................................................................................................. 51 Figura 32. Representación de la petición genérica de un servicio. ................................ 52 Figura 33. Especialización de la petición de servicio ..................................................... 52 Figura 34. Representación de la comunicación por OLE y ACTIVE X .......................... 52 Figura 35. Representación de la comunicación por ODBC............................................ 52 Figura 36. Arquitectura del servicio de ODBC................................................................ 53 Figura 37. Representación de la comunicación por ADO............................................... 53 Figura 38. Arquitectura de ADO ..................................................................................... 53 Figura 39. Arquitectura de ADO.NET ............................................................................. 54 Figura 40. Representación del servicio genérico de acceso a datos relacionales ......... 55 Figura 41. Representación de un servidor SQL ............................................................. 55 Figura 42. Representación de la llamada a procedimiento catalogado.......................... 55 Figura 43. Representación de los accesos a Internet. .................................................. 55 Figura 44. Representación del acceso por RPC ............................................................ 56 Figura 45. Network Interface Definition Language (NIDL).............................................. 56 Figura 46. Comportamiento del RPC en tiempo de ejecución........................................ 57 Figura 47. Representación de la comunicación por SOAP ............................................ 59 Figura 48. Modelos de objetos distribuidos .................................................................... 59 Figura 49. Representación de la comunicación por eventos.......................................... 60


Figura 50. Mecanismo ECA............................................................................................ 60 Figura 51. Indicativo de conexión remota....................................................................... 61 Figura 52. Indicativo de conexión remota con dispositivo móvil..................................... 61 Figura 53. Indicativo de conexión inalámbrica................................................................ 61 Figura 54. Diagrama de flujo de una contratación de viaje. ........................................... 62 Figura 55. Arquitectura de servidores............................................................................. 63 Figura 56. Arquitectura de las funciones de venta directa.............................................. 63 Figura 57. Representación de XML................................................................................ 64 Figura 58. Organización por capas................................................................................. 70 Figura 59. Diálogo cuasi-jerárquico................................................................................ 71 Figura 60. Representación del diálogo Pull .................................................................... 72 Figura 61. Push versus Pull............................................................................................ 73 Figura 62. Push y Pull en Internet .................................................................................. 73 Figura 63. El Comité de Componentes........................................................................... 90 Figura 64. La reusabilidad gestionada por el Director de Proyectos .............................. 91 Figura 65. Ciclo de vida de un componente ................................................................... 93 Figura 66. La balanza de distribución del peso C/S. ...................................................... 94 Figura 67. Símbolo del Cliente ....................................................................................... 97 Figura 68. Lógicas y Programas Cliente......................................................................... 98 Figura 69. Símbolo del Servidor ................................................................................... 107 Figura 70. Servidores multicliente multiservidor ........................................................... 108 Figura 71. Servidores dependientes del sistema.......................................................... 112 Figura 72. Implementación por delegación................................................................... 112 Figura 73. Delegación de Servicio............................................................................... 115 Figura 74. Ejemplo de delegación de Servicio ............................................................. 116 Figura 75. Arquitectura de Respuesta Anexa............................................................... 117 Figura 76. Ejemplo de Arquitectura de Delegación con Mensaje Anexo...................... 118 Figura 77. Ejemplo de una arquitectura de Traspaso de Responsabilidad.................. 119 Figura 78. Ejemplo de una arquitectura de Redirección............................................... 120 Figura 79. Ejemplo de una arquitectura de Pasarela ................................................... 121 Figura 80. Arquitectura de Broadcast. .......................................................................... 122 Figura 81. Arquitectura de Filtro ................................................................................... 123 Figura 82. Ejemplo de Arquitectura de Filtro ................................................................ 123 Figura 83. Arquitectura Master-Slave ........................................................................... 124 Figura 84. Ejemplo de Arquitectura Master-Slave. ....................................................... 124 Figura 85. Arquitectura de Distribución ........................................................................ 125 Figura 86. Ejemplo de Arquitectura de Distribución ..................................................... 125 Figura 87. Arquitectura de Pre-Condición .................................................................... 126 Figura 88. Ejemplo de Arquitectura de Pre-Condición ................................................. 126 Figura 89. Ejemplo de Arquitectura Configuración ....................................................... 127 Figura 90. Ejemplo de Arquitectura Configuración para el alta de clientes remota...... 128 Figura 91. Ejemplo de arquitectura de configuración con una PDA............................. 129 Figura 92. Ejemplo de Arquitectura de Proxy para mejorar rendimiento...................... 130 Figura 93. Arquitectura de servidores completa ........................................................... 132 Figura 94. Arquitectura de las funciones de venta directa completo ............................ 132 Figura 95. Interacciones en un modelo SOA................................................................ 137 Figura 96. Arquitectura de un servicio con partición horizontal .................................... 142 Figura 97. Servicio de facturación. ............................................................................... 143 Figura 98. Servicio de Router ....................................................................................... 144 Figura 99. Los proyectos distribuidos como proyectos de Ingeniería........................... 151 Figura 100. Fases de la gestión del Proyecto .............................................................. 153 Figura 101. Ciclo de Vida Clásico o en Cascada ......................................................... 154 Figura 102. Prototipaje. ................................................................................................ 155 Figura 103. Ciclo de vida en Espiral ............................................................................. 156 Figura 104. Ciclo de vida de clase de Meyer................................................................ 158


Figura 105. Ciclo de vida OO de Henderson - Sellers.................................................. 158 Figura 106. Esquema de Administración de un Proyecto............................................. 159 Figura 107. Encaje del diseño distribuido en el ciclo de desarrollo del software ......... 170 Figura 108. Ejemplo de diagrama de flujo. ................................................................... 172 Figura 109. Ejemplo de la utilidad de la secuencialización .......................................... 174 Figura 110. Ejemplo de Decisión dentro de la Secuencia de Ejecución. ..................... 175 Figura 111. Análisis Descendente................................................................................ 178 Figura 112. Diagrama Jerárquico ................................................................................. 181 Figura 113. Diagrama Jerárquico con funciones compartidas ..................................... 181 Figura 114. Ejemplo de Diagrama Jerárquico. ............................................................. 181 Figura 115. Ejemplo de Modelo Relacional .................................................................. 184 Figura 116. Arquitectura ANSI/SPARC de tres niveles ................................................ 185 Figura 117. Bases de datos pasivas............................................................................. 187 Figura 118. Bases de datos activas.............................................................................. 188 Figura 119. Mecanismo de trigger ................................................................................ 188 Figura 120. Vistas e Integración de BD's ..................................................................... 190 Figura 121. Modelo de datos. ....................................................................................... 197 Figura 122. Diagrama Jerárquico inicial de unidades y procesos lógicos.................... 197 Figura 123. Proceso de Venta de Viaje Aéreo ............................................................. 198 Figura 124. Primer proceso de refinamiento de Venta Viaje y Hotel a Cliente............. 198 Figura 125. Refinamiento de Entrada de la Petición .................................................... 199 Figura 126. Refinamiento de Registro Datos del Viaje................................................. 199 Figura 127. Proceso de Alta de Clientes ...................................................................... 200 Figura 128. Proceso para Actualizar Datos. ................................................................ 200 Figura 129. Proceso de Estadísticas............................................................................ 201 Figura 130. Refinamiento del Proceso de Estadísticas ................................................ 201 Figura 131. Diagrama jerárquico ampliado................................................................... 202 Figura 132. Concepto de Objeto................................................................................... 204 Figura 133. El triángulo OO.......................................................................................... 205 Figura 134. Representación de una clase bicicleta...................................................... 206 Figura 135. Representación de una Clase ................................................................... 206 Figura 136. Notación de Clase e Instancia................................................................... 206 Figura 137. Herencia .................................................................................................... 207 Figura 138. Herencia múltiple....................................................................................... 207 Figura 139. Clase mover. ............................................................................................. 208 Figura 140. Jerarquía de una Clase Polígono.............................................................. 209 Figura 141. Ejemplo de Diagramas de Clases e Instancias ......................................... 214 Figura 142. Notación de las asociaciones.................................................................... 214 Figura 143. Ejemplo de Asociación Ternaria................................................................ 215 Figura 144. Notación de la Multiplicidad por un cardinal. ............................................. 215 Figura 145. Notación Simbólica de la Multiplicidad ...................................................... 216 Figura 146. Ejemplo de Asociación con atributos......................................................... 216 Figura 147. Ejemplo de Asociación con Atributos modelada como una clase. ............ 216 Figura 148. Notación y ejemplo de Agregación............................................................ 217 Figura 149. Ejemplos de Agregaciones........................................................................ 217 Figura 150. Modelo de Objetos de una Expresión ....................................................... 217 Figura 151. Modelo de Objetos de un texto.................................................................. 217 Figura 152. Diagrama de Objetos de fronteras de países............................................ 218 Figura 153. Modelo de Objetos de una mano de poker. .............................................. 218 Figura 154. Modelo de Objetos de un sistema de transporte aéreo............................. 218 Figura 155. Uso de ordenadores por empleados ......................................................... 218 Figura 156. ANSI/SPARC three schema architecture .................................................. 219 Figura 157. Equivalencia de de niveles entre OO y relacional ..................................... 220 Figura 158. Evolución del diseño UML a distribuido..................................................... 229 Figura 159. Representación gráfica a de los nodos en un diagrama de despliegue.... 229


Figura 160. Ejemplo de diagrama de Sistema.............................................................. 230 Figura 161. Ejemplo de diagrama de Sistema.............................................................. 231 Figura 162. Diagrama de Niveles Lógicos.................................................................... 231 Figura 163. Diagrama de Arquitectura de Servicios – Notación................................... 232 Figura 164. Ejemplo de diagrama de Arquitectura de Servicios................................... 233 Figura 165. Diagrama de Arquitectura de Servicios implementado como diagrama de

Colaboración..................................................................................................... 233 Figura 166. Diagrama de Localizaciones ..................................................................... 234 Figura 167. Ejemplo de Diagrama de Actividades como fuente de servicios............... 235 Figura 168. Ejemplo de Diagrama de Actividades adaptado tras el diseño distribuido 235 Figura 169. Arquitectura de Servicios del Diagrama de Actividades adaptado tras el

diseño distribuido.............................................................................................. 236 Figura 170. Identificación de servicios en un Diagrama de Colaboración.................... 237 Figura 171. Posibilidades de integración de servicios entre entornos ......................... 238 Figura 172. Influencia de la arquitectura OO en el modelo de comunicación .............. 241 Figura 173. Ejemplo de implementación de un servicio de datos ................................ 241 Figura 174. Modelo conceptual de especificación........................................................ 243 Figura 175. Diagrama de secuencia del caso de uso................................................... 243 Figura 176. Modelo conceptual de diseño.................................................................... 244 Figura 177. Interfície gráfica de la operación asignarProveedor()................................ 245 Figura 178. Diagrama de secuencia del caso de uso concreto.................................... 248 Figura 179. Controlador transaccional para comunicar las capas de presentación y de

dominio ............................................................................................................. 248 Figura 180. Diagrama de secuencia de la creación de la ventana............................... 249 Figura 181. Diagrama de secuencia de la creación de la ventana. Inicialización ........ 249 Figura 182. Diagrama de secuencia de la actualización del desplegable de

proveedores al cambiar la cima del desplegable de materia prima.................. 250 Figura 183. Diagrama de secuencia de la reacción al botón Registrar para asignar el

proveedor a la materia prima. ........................................................................... 250 Figura 184. Diagrama de secuencia de los servicios de la capa de datos................... 251 Figura 185. Implementación 1. ..................................................................................... 252 Figura 186. Implementación 2. ..................................................................................... 253 Figura 187. Diagrama de Sistemas de Asignar Proveedor. ......................................... 254 Figura 188. Diagrama de Niveles Lógicos de Asignar Proveedor. ............................... 254 Figura 189. Diagrames de Servicios y de Localización de Asignar Proveedores. ....... 255 Figura 190. Esquematización de la arquitectura de datos............................................ 258 Figura 191. "Visión" de los modelos de datos .............................................................. 259 Figura 192. Arquitectura de datos distribuidos ............................................................. 259 Figura 193. Modelo centralizado pequeño. .................................................................. 262 Figura 194. Modelo centralizado grande. ..................................................................... 262 Figura 195. Esquema de datos replicados. .................................................................. 264 Figura 196. Protocolo de dos fases (Tho-phases Commit) .......................................... 268 Figura 197. Arquitectura de Replicación Síncrona ....................................................... 270 Figura 198. La escala copia / replica. ........................................................................... 271 Figura 199. Replicación por master/slave. ................................................................... 273 Figura 200. Replicación por log's ................................................................................. 274 Figura 201. Esquema de Auditoria de Datos Replicados ............................................. 278 Figura 202. Arquitectura de un ejecutor ....................................................................... 283 Figura 203. Arquitectura de datos particionados.......................................................... 284 Figura 204. Aplicación del patrón DTO para mejorar rendimiento ............................... 289 Figura 205. El servicio de interpretación ...................................................................... 292 Figura 206. Arquitectura de servidor de agrupación con servicios síncronos en origen293 Figura 207. Arquitectura del servicio de agrupación basado en replicación ................ 294 Figura 208. Lectura por servicios ................................................................................. 295 Figura 209. Modificación por servicios. ........................................................................ 296


Figura 210. Servidor de agrupación por replicación ampliado ..................................... 297 Figura 211. Etapas de diseño de las aplicaciones avanzadas..................................... 300 Figura 212. Etapas de diseño de aplicaciones RAD .................................................... 300 Figura 213. Metodología Integrada de Diseño Distribuido. .......................................... 301 Figura 214. Etapas del Diseño de la Arquitectura Distribuida ...................................... 309 Figura 215. Etapas del Análisis de los datos............................................................... 310 Figura 216. Arquitectura de una llamada asíncrona a través de una vía lenta. ........... 324 Figura 217. SI para la Venta de Productos en Delegaciones....................................... 325 Figura 218. Primer Refinamiento.................................................................................. 325 Figura 219. Refinamiento de Registro de Pedido......................................................... 326 Figura 220. Refinamiento de Servir Pedido.................................................................. 326 Figura 221. Arquitectura Distribuida del primer refinamiento ....................................... 327 Figura 222. Refinamiento del Servidor para Leer los Datos del Cliente...................... 327 Figura 223. Arquitectura Distribuida de Registro del Pedido........................................ 328 Figura 224. Arquitectura Distribuida de Servir Pedido.................................................. 328 Figura 225. Servidores multicliente y multiservidor ...................................................... 329 Figura 226. Esquema de datos modificado .................................................................. 334 Figura 227. Arquitectura de datos de la Central ........................................................... 335 Figura 228. Arquitectura de datos de la Tienda............................................................ 335 Figura 229. Proceso para Leer los datos del Cliente.................................................... 336 Figura 230. Proceso de Alta de Cliente Modificado...................................................... 337 Figura 231. Proceso de Actualización de Datos modificado. ....................................... 338 Figura 232. Nuevo Proceso de Replicación de Clientes .............................................. 338 Figura 233. Proceso de impresión de la reserva del cliente......................................... 343 Figura 234. Precondición en la gestión del Crédito de Cliente..................................... 343 Figura 235. Servidor de Actualizar Datos de Cliente en la Central .............................. 344 Figura 236. Refinamiento del Servidor de Leer Datos de Cliente en la Central ........... 344 Figura 237. Refinamiento del servidor de lectura del crédito. ...................................... 345 Figura 238. Solución A para la arquitectura del servidor de Leer Datos del Cliente en el

servidor de la Tienda. ....................................................................................... 345 Figura 239. Solución A para la arquitectura del servidor de Leer Datos del Cliente en el

servidor de la Tienda. ....................................................................................... 346 Figura 240. Refinamiento del servidor de lectura de datos de clientes en la Tienda ... 347 Figura 241. Arquitectura del servidor de Alta de Clientes en la Central. ...................... 347 Figura 242. Arquitectura del proceso de Entrada de la Petición. ................................. 348 Figura 243. Arquitectura del proceso de Registro Datos Viaje..................................... 348 Figura 244. Arquitectura del proceso de Actualización de Datos de la Venta.............. 349 Figura 245. Arquitectura del proceso de Replicación de Clientes................................ 349 Figura 246. Arquitectura del proceso de Actualización de Datos de la Venta.............. 351 Figura 247. Diagrama Jerárquico tras el diseño de la Arquitectura distribuida. ........... 352 Figura 248. Clasificación de las actividades de administración ................................... 354 Figura 249. Niveles de configuración del puesto cliente .............................................. 358 Figura 250. Organización operativa del soporte a usuarios. ........................................ 363 Figura 251. Auditoría de los procesos de Outsourcing................................................. 372 Figura 252. Clasificación de las actividades de administración ................................... 382 Figura 253. Diseño de la administración de sistema.................................................... 383 Figura 254. Back-up Distribuido ................................................................................... 391 Figura 255. Back-up de usuario sobre entorno departamental .................................... 392 Figura 256. Back-up Departamental............................................................................. 392 Figura 257. Formato del ticket de control de un back-up departamental ..................... 392 Figura 258. Back-up departamental centralizado......................................................... 393 Figura 259. Organización jerárquica de los grupos de impresión ................................ 396 Figura 260. Distribución jerárquica de los recursos de impresión................................ 396 Figura 261. Perímetro de seguridad múltiple con identificación múltiple...................... 401 Figura 262. Perímetro de seguridad múltiple con identificación única ......................... 402


Figura 263. Perímetro de seguridad único ................................................................... 402 Figura 264. Ciclo de trabajo del Análisis de Consistencia............................................ 409 Figura 265. Ciclo de la gestión de errores.................................................................... 410 Figura 266. Mecanismo de comunicación C/S con confirmación ................................. 418 Figura 267. Ciclo de trabajo en emergencia................................................................. 425 Figura 268. Extensión de los diagramas de flujo para recoger el análisis de

consistencia. ..................................................................................................... 426 Figura 269. Metodología del Diseño de la Consistencia .............................................. 426 Figura 270. Diagrama de flujo inicial del Vigilante........................................................ 434 Figura 271. Refinamiento del proceso para Verificar la Conexión con la Central ........ 434 Figura 272. Refinamiento del proceso para Verificar la Conexión con la Compañía

Aérea. ............................................................................................................... 434 Figura 273. Consistencia del Servidor para Leer Datos Cliente................................... 435 Figura 274. Consistencia del servidor de leer datos de cliente en la tienda ................ 435 Figura 275. Diagrama de Consistencia del proceso para Actualizar Ventas................ 436 Figura 276. Nuevo proceso de Recuperación de la Situación de Emergencia ............ 436 Figura 277. Proceso de Data Entry para la Venta Manual ........................................... 437 Figura 278. Integración del Cliente............................................................................... 439 Figura 279. Representación de la integración GUI....................................................... 443 Figura 280. Representación de la integración por Portal ............................................. 443 Figura 281. Representación de un cliente ligero .......................................................... 445 Figura 282. Integración transaccional .......................................................................... 447 Figura 283. Representación de una Integración Transaccional ................................... 447 Figura 284. Ejemplo de integración trasaccional de una red de cajeros automáticos.. 447 Figura 285. Representación de un cliente WEB........................................................... 448 Figura 286. Presentación Activa y plataforma Servicios WEB ..................................... 448 Figura 287. Representación de una WEB convencional .............................................. 448 Figura 288. Representación de clientes Back-ground.................................................. 448 Figura 289. Integración batch....................................................................................... 449 Figura 290. Representación de cadena Batch ............................................................. 449 Figura 291. Representación de una integración por estereotipos................................ 451 Figura 292. Integración por agentes............................................................................. 452 Figura 293. Representación de un procesador distribuido........................................... 452 Figura 294. Arquitectura de un procesador distribuido................................................. 453 Figura 295. El Procesador distribuido síncrono............................................................ 454 Figura 296. Representación de una integración Workflow........................................... 455 Figura 297. Ejemplo de Workflow................................................................................. 455 Figura 298. Implementación del proceso de Aceptación del Crédito. .......................... 456 Figura 299. Implementación de un Sistema de Gestión de documentos. .................... 456 Figura 300. Representación de una integración por publicación/suscripción .............. 456 Figura 301. Papeles múltiples. ..................................................................................... 458 Figura 302. Comunicación cara a cara versus comunicación por bus. ........................ 460 Figura 303. Arquitectura básica de publicación suscripción......................................... 464 Figura 304. Acceso a P/S heterogéneos. ..................................................................... 465 Figura 305. Arquitectura de un servidor de versiones. ................................................. 471 Figura 306. El servidor de versiones de los puestos cliente......................................... 473 Figura 307. Componentes de una interfície gráfica de usuario .................................... 478 Figura 308. Identificación de Clases Visuales. ............................................................. 486 Figura 309. Derivación por especialización. ................................................................. 489 Figura 310. Derivación por integración......................................................................... 490 Figura 311. Modelado de una GUI. .............................................................................. 490 Figura 312. Principio de Consistencia. ......................................................................... 493 Figura 313. División por áreas de una ventana. ........................................................... 498 Figura 314. Interacción entre los modelos.................................................................... 502 Figura 315. Ciclo de evaluación de una interfície......................................................... 503


Figura 316. Arquitectura de un Framework gráfico. ..................................................... 508 Figura 317. Modelo de Objetos de un Framework. ...................................................... 509 Figura 318. Esquema de funcionamiento de un Gestor de Eventos. ........................... 512 Figura 319. Esquema de programación secuencial. .................................................... 513 Figura 320. Esquema de programación por eventos.................................................... 513 Figura 321. Notación de los eventos en los diagramas de flujo. .................................. 513 Figura 322. Consistencia del proceso de conexión con la central por eventos............ 514 Figura 323. Refinamiento verificar conexiones por eventos......................................... 514 Figura 324. Reconstrucción de la conexión con la central por eventos. ...................... 515 Figura 325. Arquitectura de Envolvente. ...................................................................... 522 Figura 326. Envolvente de presentación de tres niveles .............................................. 522 Figura 327. El camino del Downsizing.......................................................................... 524 Figura 328. Etapas de un proceso EAI......................................................................... 526

Dise.o de sistemas distribuidos - Departament d'Enginyeria ...gomariz/index_archivos/... · 9...

Documents

Transcript of Dise.o de sistemas distribuidos - Departament d'Enginyeria ...gomariz/index_archivos/... · 9...