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.

@@EMG/10 - Enric Martínez Gomàriz 5
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
@@EMG/10 - Enric Martínez Gomàriz 6
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.


@@EMG/10 - Enric Martínez Gomàriz 7
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
@@EMG/10 - Enric Martínez Gomàriz 8
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.
@@EMG/10 - Enric Martínez Gomàriz 9

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ú:

O 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.
O Necesidad de duplicar los atributos de clasificación dentro del código como
atributos independientes para poderlos gestionar bien en las bases de datos.
O Que hacer con la información histórica: reconvertir códigos, eliminar a partir
de una fecha, etc.
O Convencer a todos los usuarios de la necesidad del cambio.
O Pactar los nuevos códigos.
O Repasar todos los programas (¡todos!) de la instalación, probarlos y mantener
un tiempo el cambio.
O Planificación del transitorio (que no le pase nada...)
O 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.
@@EMG/10 - Enric Martínez Gomàriz 10


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.

@@EMG/10 - Enric Martínez Gomàriz 11
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.

@@EMG/10 - Enric Martínez Gomàriz 12
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.

O 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:
O De lógica presentación.
O De lógica de datos.
O De lógica de negocio.
O De control de procesos.
O Componentes de gestión o Framework o componentes de segundo nivel, que
implementan:
O Procesos de gestión, como un mantenimiento estándar de tablas o una
gestión de documentos con cabecera y detalle.
O Procesos de negocio, como un proceso de intercambio de documentos.
O 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.

@@EMG/10 - Enric Martínez Gomàriz 13
Son componentes operacionales habituales:

O Componentes de control de procesos.
O Semáforos.
O Colas.
O Ticket.
O Agentes operacionales:
O Servidores de Impresión
O Servidor de Correo.
O Servidor de Notas y Avisos.
O El cartero.
O Vigía.
O Disparador.
O 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.

@@EMG/10 - Enric Martínez Gomàriz 14
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
@@EMG/10 - Enric Martínez Gomàriz 15

º 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.

@@EMG/10 - Enric Martínez Gomàriz 16
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 Estados
X
X
X
X

Figura 2. Representación de
un Ticket
@@EMG/10 - Enric Martínez Gomàriz 17
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.

@@EMG/10 - Enric Martínez Gomàriz 18
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.

10.3.1. Estructurales.

º 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ó Estats
X
X
X
X
Jornada xxxxxxx
Situació Estats
X
X
X
X
Jornada xxxxxxx
Situació Estats
X
X
X
X
Jornada xxxxxxx
Situació Estats
X
X
X
X
Jornada xxxxxxx
Element Descrip
p
Descripció

Figura 3. Tickets Multihoja
@@EMG/10 - Enric Martínez Gomàriz 19
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.

Figura 4. Representación
de una cola
@@EMG/10 - Enric Martínez Gomàriz 20
º 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.
@@EMG/10 - Enric Martínez Gomàriz 21

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.
@@EMG/10 - Enric Martínez Gomàriz 22
º 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ón
Referencia del cliente
1
Aceptación de anotación
Referencias de cliente y de anotación
2
Petición de una anotación
Referencia Proveedor
3
Asignación de una anotación
Referencia de proveedor y de
anotación.
4

Figura 5. Dinámica de referencias
@@EMG/10 - Enric Martínez Gomàriz 23
· 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.
@@EMG/10 - Enric Martínez Gomàriz 24
· 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:

11.10.1. Estructurales.

º 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.
@@EMG/10 - Enric Martínez Gomàriz 25
º 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:

O Aumentar el rendimiento.
O 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
@@EMG/10 - Enric Martínez Gomàriz 26
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
Servidor
de
Replicación
Ficheros
Pendientes
Cadena
Batch de
Incorporación
Gestor
Administrador
Replica
Internal
squema 1
Internal
squema 1
BD
Corporativa
Internal
squema 1
Internal
squema 1
BD
Replicada
Consultas de
Usuarios

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
@@EMG/10 - Enric Martínez Gomàriz 27
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:

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

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:

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






















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
@@EMG/10 - Enric Martínez Gomàriz 30
Esta función puede conseguirse por:

O Eventos.
O 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:

O Un directorio.
O Una cola.
O Un mail.
O Un semáforo.
O Un ticket.
O 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

Figura 15. Representació
n del
disparador

Figura 16. Representació
n del Servidor
de Correo
@@EMG/10 - Enric Martínez Gomàriz 31
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
Distribuidor
Via de gran capacidad
NODO
Usuario Usuario

Figura 17. Arquitectura básica de un servidor de correo.
@@EMG/10 - Enric Martínez Gomàriz 32

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.

@@EMG/10 - Enric Martínez Gomàriz 33
¿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:

O Anotación directa a través de un programa especializado que incluye el
servidor de correo.
O Anotación desde un programa cliente a través de API’s.

El inicio puede ser:

O Manual.
O Automático e inmediato.
O 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
Arrancada
planificada
APLICACIÓN
Comunicación
de aplicación
Servidor
ORIGEN
R
U
T
E
R
VIES
TCP/IP
Teléfono
Internet
X25,X28,X32
TCP/IP
+ SOAP
IPX
SNA
FDDI, TAM
etc ....
R
U
T
E
R
Servidor
DESTÍNO
APLICACIÓN
ERRORES
ERRORES
Administración
del sistema

Figura 18. Funcionamiento básico de un Servidor de
Correo
@@EMG/10 - Enric Martínez Gomàriz 34
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á:

O Codificar los nodos.
O Personificar el servidor que
se arranca en cada nodo.
O Informar de las vías de
comunicación disponibles
entre los nodos,
personificando los routers.
O Definir los usuarios y
programas clientes.
O Informar de los enlaces
permitidos entre los nodos,
lo que equivale a informar
la tabla de distribución.
O Informar los parámetros de
auto corrección.
O 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:

O Codificar las vías de salida de que dispone cada elemento de la plataforma.
O Identificar a cada usuario por un código.
O Permitir asignar permisos de acceso a cada usuario.
O 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.
O Poder definir por cada destino el número de reintentos a realizar y los criterios
de gestión automática de errores.
O Definir los parámetros de la cola de distribución.
O 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
U8 U14
U16
U15
U9
U10 U11 U12 U13
U1
U2
U3
___ conexión normal
___ conexión alternativa

Figura 19. Posibilidades de parametrización de un
Servidor de Correo
@@EMG/10 - Enric Martínez Gomàriz 35
O Si se utiliza la opción de control centralizado de errores, se habrá de definir el
funcionamiento de la opción para cada mensaje.
O Limitar las posibilidades de funcionamiento para cada usuario en función de
sus necesidades y derechos en el sistema distribuido.
O 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
@@EMG/10 - Enric Martínez Gomàriz 36
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:

O La guía de usuarios donde esta la dirección de acceso, normalmente la de
correo. Se recomienda aprovechar alguna entidad ya existente.
O 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.
O La relación funciones-usuarios interesados.
O El buzón, donde los programas dejan los mensajes.

La arquitectura del cartero suele ser:

O Programas GUI’s para mantener:
O La guía de usuarios,
O Las funciones.
O Las relaciones entre funciones y usuarios.
O API’s de Middleware para colocar los avisos en el buzón del cartero.

El funcionamiento es:

O Los programas que lo necesitan preparan el mensaje y lo colocan en el buzón
con una referencia de función.
@@EMG/10 - Enric Martínez Gomàriz 37
O El cartero averigua a partir de la relación entre función y usuarios los usuarios
destinatarios.
O El cartero pasa los mensajes al servidor de notas y avisos.
O 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.

Figura 21. Representació
n del cartero
@@EMG/10 - Enric Martínez Gomàriz 38
· 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.

@@EMG/10 - Enric Martínez Gomàriz 39
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.

@@EMG/10 - Enric Martínez Gomàriz 40
Otras posibilidades deseables en un servidor de correo son:

O Compactar los datos para minimizar los tiempos de transmisión.
Fundamental.
O Encriptar los datos para evitar pinchazos.
O Posibilidad de arrancar más de una instancia del servidor de correo en el
mismo nodo.
O Encapsulamiento de las vías que permita incorporar de nuevas de forma
cómoda.
O Posibilidades de planificación que permitan minimizar costes. Por ejemplo,
transmisión nocturna si se utiliza red conmutada.
O 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:

O La nueva copia destruya el contenido antiguo.
O 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.
@@EMG/10 - Enric Martínez Gomàriz 41

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.

@@EMG/10 - Enric Martínez Gomàriz 42
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.

@@EMG/10 - Enric Martínez Gomàriz 43
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.
@@EMG/10 - Enric Martínez Gomáriz 46
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.

@@EMG/10 - Enric Martínez Gomáriz 47
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.

@@EMG/10 - Enric Martínez Gomáriz 48
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:

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

El modelo conversacional tiene algunas consideraciones adicionales:

O El comportamiento de diseño de la comunicación conversacional en siempre
síncrona. Aunque observe que el modelo conversacional no lo exige.
O Una vez conectados cliente y servidor el efecto es como del de una conexión
punto a punto.
O 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.

Figura 24. Representación
del modelo
conversacional.
Servidor
Cliente El cliente espera que el
semáforo esté libre
Servidor
Cliente El cliente encuentra el
semáforo libre
Servidor
Cliente El cliente ocupa el servidor
poniendo el semáforo en
rojo y pide y recibe del
servidor el servicio
Servidor
Cliente 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
@@EMG/10 - Enric Martínez Gomáriz 49

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

O 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.
O 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.
@@EMG/10 - Enric Martínez Gomáriz 50
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.

Servidor
Cliente

Figura 27. Comunicación sin respuesta
Servidor Cliente
Respuesta

Figura 28. Comunicación con respuesta
directa
@@EMG/10 - Enric Martínez Gomáriz 51
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.

Servidor Cliente
Cola única de petición/respuesta
Servidor
Cliente
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
@@EMG/10 - Enric Martínez Gomáriz 52
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.

Figura 32. Representació
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

Figura 35. Representació
n de la
comunicación
por ODBC
@@EMG/10 - Enric Martínez Gomáriz 53

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.

Maquina
Cliente
Programa
Rutinas
Stub del
ODBC
Maquina
Servidora
Servidor
ODBC
BD

Figura 36. Arquitectura del servicio de ODBC

Figura 37. Representació
n de la
comunicación
por ADO
Maquina
Cliente
Programa
Objetos ADO
Maquina Servidora
Servidor
ODBC
BD ODBC
Proveedor
OLE DB
BD OLE DB

Figura 38. Arquitectura de ADO
@@EMG/10 - Enric Martínez Gomáriz 54
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
@@EMG/10 - Enric Martínez Gomáriz 55
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.



Figura 40. Representació
n del servicio
genérico de
acceso a datos
relacionales

Figura 41. Representació
n de un
servidor SQL

Figura 42. Representación
de la llamada a
procedimiento
catalogado.

Figura 43. Representación de
los accesos a
Internet.
@@EMG/10 - Enric Martínez Gomáriz 56
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.



Figura 44. Representació
n del acceso
por RPC
Middleware
Descripción
de la interfície
Compilador
IDL
Stub +
código
cliente
RPC
Run
Time
RPC
Run
Time
Stub +
código
servidor

Figura 45. Network Interface Definition Language (NIDL).
@@EMG/10 - Enric Martínez Gomáriz 57



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.
Arrancada
del cliente
2.Localización
del servidor
Cliente
3.Preparación
de transacción
Stub del
cliente
4.Preparación
de argumentos
Cliente
Runtime
5.RPC
Arrancada
servidor
Servidor
Stub del
servidor
Servidor
Runtime
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
@@EMG/10 - Enric Martínez Gomáriz 58
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:

O La localización de clientes y servidores.
O El paso de parámetros de forma transparente a las plataformas.
O El tratamiento de las caídas del servidor.
O 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.
@@EMG/10 - Enric Martínez Gomáriz 59
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.

Figura 47. Representació
n de la
comunicación
por SOAP

Figura 48. Modelos de
objetos
distribuidos
@@EMG/10 - Enric Martínez Gomáriz 60

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:

O Se produce el evento en un punto de la
aplicación y / o sistema.
O Otro elemento de la aplicación y/o
sistema lo recibe.
O Evalúa una condición con los
parámetros del evento recibido y su
propio estado.
O 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.

Figura 49. Representació
n de la
comunicación
por eventos
Regla: (E,C) A
Situación Reacción
Regla: (E,C) A
Situación Reacción
Evento
CUANDO el evento ocurre
SI se se satisface la condición
CUANDO el evento ocurre
SI se se satisface la condición
Situación
HACER_ejecutar la acción
HACER_ejecutar la acción
Reacción

Figura 50. Mecanismo ECA.
@@EMG/10 - Enric Martínez Gomáriz 61


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:

O Diseñar la lógica de datos en la parte servidora, ya sea con procedimientos
catalogados o con servidores especializados.
O Intentar que la longitud de los mensajes sea lo más corta posible.
O 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:

O Una asistente personal, lo que supone un punto de
heterogeneidad de programación.
O Un teléfono de última generación.
O 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

Figura 52. Indicativ
o de
conexión
remota
con
dispositi
vo móvil

Figura 53. Indicativ
o de
conexión
inalámbr
ica
@@EMG/10 - Enric Martínez Gomáriz 62
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:

O Los datos del cliente
están en un servidor de
datos local en la
agencia de viajes.
O Hay más de un puesto
de venta en la agencia.
O La actualización de los
datos del vuelo se hace
en la compañía aérea.

Con todo ello se identifican
los siguientes servicios:

O 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.
O 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.
O El cargo de la venta a las cuentas de cliente se realizará también mediante un
servidor que encapsulará la función.
O La venta de directa desde casa del cliente se hará por una aplicación WEB.
O La consulta de vuelos del personal de la agencia se realizará por la Web de la
compañía aérea.
O 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.

Usuario
en tienda
Petición del cliente
Actualiza
los datos de
la compañía
aérea
Datos Compañía aérea
Cuenta Cliente
Registro
de datos del
Cliente
Anotación
en la cuenta
del Cliente
Registro
de datos del
Viaje
Identificación
Cliente
Consulta
Vuelos
Acceso
Datos
Compañía
aérea
Consulta
Datos
Vuelos

Figura 54. Diagrama de flujo de una contratación de viaje.
@@EMG/10 - Enric Martínez Gomáriz 63

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 WEB
Consulta
Datos
Compañía
aérea
Datos Compañía aérea
Obtener
Datos
Cliente
Presentación de la WEB
Identificación
Cliente
Consulta
Vuelos
Registro
Vuelos
Identificación
Cliente
Registro
Venta
Cliente Cuenta Cliente
RPC
Proceso
Compañía
Aérea
R
Cuenta Cliente
Proceso
Cuenta
Cliente

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
Registro
Datos
Cliente
Anotación
Cuenta
Cliente
Registro
Datos
Viaje
Petición
Datos
Cliente
Datos
Cabecera
Cliente
RPC
Actualiza
datos
Compañía
aérea
Obtener
Datos
Cliente
Proceso
Compañía
Aérea
Proceso
Cuenta
Cliente
R
Cliente Cuenta Cliente
Consulta
Datos
Vuelos

Figura 55. Arquitectura de servidores
@@EMG/10 - Enric Martínez Gomàriz 64
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.


Figura 57. Representación
de XML
@@EMG/10 - Enric Martínez Gomàriz 65
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:

O Siguiendo las reglas del propio XML.
O 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:

O Los que generar eventos a medidas que van analizando el documento.
O 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>.
@@EMG/10 - Enric Martínez Gomàriz 66

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:

O Separación y auto descripción de los datos con independencia de la
plataforma.
O Petición de servicios en general con independencia de la plataforma. Ideal
para la comunicación con terceros.
O Llamada a servicios a través de servidores de seguridad de forma
transparente a la plataforma.
O Configuración.
@@EMG/10 - Enric Martínez Gomàriz 67
O Estandarización de los interfaces de datos.
O Estandarización de las descripciones de las entidades más habituales.
O Definición de un lenguaje propio para las aplicaciones de un determinado
sistema de información o compañía.
O 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.

@@EMG/10 - Enric Martínez Gomàriz 68
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.

O Que el navegador reciba el XML y el XSL y los gestione.
O 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
@@EMG/10 - Enric Martínez Gomàriz 69
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:

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


@@EMG/10 - Enric Martínez Gomàriz 70
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:

O Nivel exterior o nivel cliente,
donde se sitúan los clientes.
O 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.
O 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 sistema
Servidor de aplicación
Cliente
Sistema Nivel Servidor
de aplicación
Nivel Cliente
Nivel Servidor
de Middleware

Figura 58. Organización por capas.
@@EMG/10 - Enric Martínez Gomàriz 71

O Obviamente, pero recordémoslo, el dialogo
entre clientes y servidores y entre
servidores entre si ha de ser transparente a
plataforma, sistema y usuario.
O 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.
O 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
O 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:

O La arquitectura de esa comunicación queda organizada con reglas claras.
O 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.
O Hay ventajas claras para:
O La gestión de errores, que puede ser de arrastre hacia arriba y
gestionadas por el cliente.
O 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 servidor
de Middleware

Figura 59. Diálogo cuasi-jerárquico
@@EMG/10 - Enric Martínez Gomàriz 72

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:

O Realizar una recuperación de errores eficiente. Véase, por ejemplo, la
gestión de errores propuesta en el servidor de correo.
O 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.
O 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.
O 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í:

O El cliente envía una petición de atención al servidor.
O 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.
O Cuando el servidor está en condiciones de atenderla lo
notifica al cliente.
O 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:

O El cliente envía una petición de conexión. Si pasado un tiempo (time-out) no
tiene respuesta lo vuelve a intentar.
O 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.
O Cuando el servidor ha acabado el servicio, vuelve a la exploración cíclica.


Figura 60. Representació
n del diálogo
Pull
@@EMG/10 - Enric Martínez Gomàriz 73
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
@@EMG/10 - Enric Martínez Gomàriz 74
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.

@@EMG/10 - Enric Martínez Gomáriz 75
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.

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

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:

O Programación estructura, secuencial o por eventos.
O Técnicas 4GL.
O 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:

O Todo se implementa en rutinas, acciones o funciones.
O Cada rutina esta totalmente encapsulada, es decir:
O 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.
O Todas las variables de trabajo de la rutina se declaran localmente (es
decir, internamente) a la rutina.
O No existen variables globales.
O 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:

@@EMG/10 - Enric Martínez Gomáriz 77
O Cluster para la gestión del acceso a un entorno.
O Cluster de gestión de fabricación.
O 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:

O Middleware comprado.
O Piezas reutilizadas construidas con recursos propios.
@@EMG/10 - Enric Martínez Gomáriz 78
O Fabricadas por la aplicación que se esta construyendo:
O Como reutilizables, mayor esfuerzo.
O 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:

O Orientación a Objetos (OO).
O 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.


@@EMG/10 - Enric Martínez Gomáriz 79
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:
@@EMG/10 - Enric Martínez Gomáriz 80

{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).
@@EMG/10 - Enric Martínez Gomáriz 81
º 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:
@@EMG/10 - Enric Martínez Gomáriz 82
funcion
accion

¸

(
¸
(
(
(
|
\

|
.
|
|
\

|
.
|

¸

(
¸
(
(
(
(
(
(

¸

(
¸
(
(
(
(
(
(
(
nombre_servicio Parametro1,...,ParametroN
Donde por cada parametro se ha de definir:
Categoria Paso nombre: tipo tamañ o
Categoria:
ent
sal
e / s
Pas:
valor
ref
tipo


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,..)
@@EMG/10 - Enric Martínez Gomáriz 83
º 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.

@@EMG/10 - Enric Martínez Gomáriz 84
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:

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

@@EMG/10 - Enric Martínez Gomáriz 85
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:

O Estática, linkada con el programa.
O 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.

@@EMG/10 - Enric Martínez Gomáriz 86
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.


@@EMG/10 - Enric Martínez Gomàriz 87
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.

@@EMG/10 - Enric Martínez Gomàriz 88
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.

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

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:

O Un estándar de especificación y documentación.
O Un repositorio donde se registra toda la información disponible.
O 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.


@@EMG/10 - Enric Martínez Gomàriz 90
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é:

O Un director con autoridad técnica y de organigrama.
O El responsable técnico de los componentes.
O El bibliotecario.
O Jefes de proyecto (pocos) con experiencia.
O Expertos rotativos sobre la funcionalidad de componentes específicos.
O 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:

Proyectos
de
Aplicación
Comité de
Componentes
Construcción
de
Componentes
Compra
de
Componentes
Libreria de
Componentes
REPOSITORIO
Comite de
Componentes
•Bibliotecario
•Expertos
•Director Proyecto
•Jefes de aplicación
Comite de
Componentes
•Bibliotecario
•Expertos
•Director Proyecto
•Jefes de aplicación
Evaluación
C
e
r
t
i
f
i
c
a
c
i
ó
n
Cambios y/o
ampliaciones
Rechazo de
Compras

Figura 63. El Comité de Componentes
@@EMG/10 - Enric Martínez Gomàriz 91
O Decidir y garantizar las plataforma de reusabilidad de la compañía
O Establecer los estándares.
O Evaluar cada petición a partir de la especificación recibida.
O Aprobarla o rechazarla.
O Decidir el nivel de reusabilidad de cada componente.
O 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ón
Repositorio
Gestor Proyecto
Catálogo
Fabricados
por terceros
Orden de
Compra
Reutilizables
Apl.
Fabricación
prò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
@@EMG/10 - Enric Martínez Gomàriz 92
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:

O Certifique siempre el software que compre. Y estudie y documente su
instalación.
O 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.
O Encapsule las diferentes interfícies del software comprado si tiene algún
estándar en su instalación.
O 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.
@@EMG/10 - Enric Martínez Gomàriz 93

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ón
Nuevo
En
construcción
Listo para
distribución
En uso
Pendiente de Borrar
(no hacer-lo servir)
Rechazo
Petición
Construido
Nueva versión
a la librería
Marca de borrar
Borrar
Cambio de especificación
En Proceso
de Compra
En
Certificación
Certificado
Recibido

Figura 65. Ciclo de vida de un componente
@@EMG/10 - Enric Martínez Gomàriz 94
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.
@@EMG/10 - Enric Martínez Gomàriz 95
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?

@@EMG/10 - Enric Martínez Gomàriz 96
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.


@@EMG/10 - Enric Martínez Gomàriz 97
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
@@EMG/10 - Enric Martínez Gomàriz 98


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
CLIENTE
Ló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
@@EMG/10 - Enric Martínez Gomàriz 99
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:

O Llamada a rutina, intercambiando el mensaje en los parámetros de la
cabecera.
O 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.

O 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.
O 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
@@EMG/10 - Enric Martínez Gomàriz 100
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.
O 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.

@@EMG/10 - Enric Martínez Gomàriz 101
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.

@@EMG/10 - Enric Martínez Gomàriz 102
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.

O Si la incluye en la lógica de presentación:
O Ventaja: La transacción de entrada sale validada.
O Inconveniente: Parte de la lógica de proceso, que puede repetirse en
otros programas queda ligada a la interfície.
O Si la incluye en la lógica de proceso:
O Ventajas: La verificación puede encapsularse en una pieza. Se
corresponde al modelo MVC de OO.
O 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
@@EMG/10 - Enric Martínez Gomàriz 103
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:

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

Pueden ser ejemplos de programas Background:

O Un sistema de facturación en el cual el cliente recibe ordenes de facturar por
diferentes vías:
O Una cola con las confirmaciones de salida de almacén.
O Venta directa desde punto de atención directa al cliente.
O Los portátiles de los vendedores ambulantes.
O Etc.
O Un gestor de copias de seguridad permanentemente activado.
O Un servidor de correo.
O 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:

O Un agente esta especializado y un cliente Background no (criterio, una vez
más, muy confuso).
O El agente está siempre activado. El cliente puede estarlo o no (confuso).
O 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.
O 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)
O 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
@@EMG/10 - Enric Martínez Gomàriz 104
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:

O Sistema de localización, diálogo y comunicación con los servidores.
O Formatos estándar.
O Mecanismos de transferencias de ficheros y datos.
O Siempre que sea posible, y muchas veces de forma obligada, multitarea en la
máquina cliente.
O Soporte gráfico.
O 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.

@@EMG/10 - Enric Martínez Gomàriz 105
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.

@@EMG/10 - Enric Martínez Gomàriz 106
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.



@@EMG/10 - Enric Martínez Gomàriz 107
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
Servido
r
@@EMG/10 - Enric Martínez Gomàriz 108
· 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
@@EMG/10 - Enric Martínez Gomàriz 109

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:

O Un sistema para trabajar los hilos (threads) que implementan cada instancia:
O Un recurso de programación: los modernos disponen de él.
O Un sistema operativo multitarea: todos los son.
O 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?

O Disponer de gestión multitarea, incluyendo mecanismos de interconexión de
programas, en el nodo.
O Tiempo compartido.
O Prioridades
O Semáforos
O Comunicaciones interprocesos (IPC), local y remota.
O Interrupciones por eventos para gestionar las esperas.
O Protección intertareas.
O Gestión eficiente de la memoria.
O Linking dinámico.
O Servicios extendidos (Extended Services).
O Comunicaciones transparentes.
O Servidores de ficheros y de impresión transparentes.
O Servicios globales de naming, directorio y localización.
O Autentificación y autorizaciones.
O Disponibilidad y parametrización.
O Gestor de objetos distribuidos.

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

O Valorar la posibilidad de substituirlos por otros.
O 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.

@@EMG/10 - Enric Martínez Gomàriz 110
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
@@EMG/10 - Enric Martínez Gomàriz 111
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
@@EMG/10 - Enric Martínez Gomàriz 112
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
dependie
ntes del
sistema
Código
independiente del
sistema
Código
dependiente
del sistema
D

Figura 72. Implementación
por delegación.
@@EMG/10 - Enric Martínez Gomàriz 113
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:

O 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.
O Hay servidores que se definen a dos niveles. Por ejemplo, un servidor de
datos distribuidos.
O 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.

@@EMG/10 - Enric Martínez Gomàriz 114
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:

O La tipología de su comunicación.
O La estructura funcional que las llamadas establecen entre ellos.
O Del modelo de comunicación que utilizan.
@@EMG/10 - Enric Martínez Gomàriz 115

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
Servidor
B
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:

O Estática, el modelo de arquitectura establecido en el diseño.
O Dinámica, el formato de los mensajes de comunicación que se establecen
y la secuencia en que se intercambian.
@@EMG/10 - Enric Martínez Gomàriz 116
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.

Servidor
Alta
Clientes
Cliente Clientes en la Central
R
D
Servidor
Alta
Cliente en
la Central RPC
Clientes en la Tienda

Figura 74. Ejemplo de delegación de Servicio
@@EMG/10 - Enric Martínez Gomàriz 117
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
Servidor Cliente
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
@@EMG/10 - Enric Martínez Gomàriz 118

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.
Servidor
de
Tarifas
Cliente
BD
Tarifas
X
D
Tarifa
D

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

@@EMG/10 - Enric Martínez Gomàriz 119
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.
Servidor
Aceptación
Pedido
Cliente
Captura de
Pedido
Directo
Cliente
R
R
D
Servidor
Aceptación
Cliente RPC
T
Cola
Tienda 1
Cola
Tienda N
R
R
T
T
Cliente
Entrega
Pedido
Agente
Localización
Tienda más
Cercana
Cliente
Captura de
Pedido
Telefónico
Servidor
Web

Figura 77. Ejemplo de una arquitectura de Traspaso de
Responsabilidad

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

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 normal
Cliente
Gestión del error
Servidor
de
errores
Respuesta de error
Servidor
de filtro de
parámetros
A
Error de parámetros
Cliente
Parámetros correctos
Servidor
1
Respuesta correcta
Servidor
n
A

Figura 78. Ejemplo de una arquitectura de Redirección


P

AC
I
@@EMG/10 - Enric Martínez Gomàriz 121
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.
Servidor
Localizador
Cliente
Programa
Índice
Bibliotecas
Catálogo UPC
Catálogo VIC
Catálogo Colegio
P
R
R
R
P
P
Vías a los Catálogos
Servidor
Distribuidor
Servidor
de Consulta
a los
Índices
Índices
D
D

Figura 79. Ejemplo de una arquitectura de Pasarela
@@EMG/10 - Enric Martínez Gomàriz 122


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:

O El cliente lanza una
petición para el servidor
B.
O Los servidores A y C
leen el mensaje pero no
responden ya que no
son los destinatarios.
O 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álogo
Broadcast
Servidor
A
Servidor
C
Cliente
Servidor
B

Figura 80. Arquitectura de Broadcast.
F

@@EMG/10 - Enric Martínez Gomàriz 123
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
Servidor Cliente
Filtro
2
.

C
o
n
e
x
i
ó
n
3. Servidor
coloca
respuesta
filtrada
4
.

F
i
n
a
l
i
z
a
c
i
ó
n
5. Confirmación
Almacén
respuesta
6. Cliente
recoge
respuesta

Figura 81. Arquitectura de Filtro
Servidor
Obtención
Imágenes
Cliente
Tratamiento
de Imágenes
Imagen Compactada
BD
Imágenes
X
D
Servidor
Descom-
presión
Imágenes
S
F
Imagen Descompactada
D

Figura 82. Ejemplo de Arquitectura de Filtro
M

@@EMG/10 - Enric Martínez Gomàriz 124
El flujo de datos en esta arquitectura es el
siguiente:

O El cliente envía la petición a un
servidor que asume la posición de
master.
O El servidor válida la petición e inicia
la ejecución de un servidor Slave
que es el que realmente da el
servicio.
O 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:

O La necesidad ocasional
de tener que hacer el
servicio distribuible en
lugar de distribuido, de
la que ya hemos hablado.
O 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:

O Aumentar el número de instancias que trabajan simultáneamente.
Cliente
Servidor
Master
Servidor
Slave
Petición
Respuesta

Figura 83. Arquitectura Master-Slave
Servidor
Distribución
listados
Cliente
Obtención
Estadística
D
M
Datos Listados
Servidor
Confección
Listado
Servidor
Impresión

Figura 84. Ejemplo de Arquitectura Master-Slave.
@@EMG/10 - Enric Martínez Gomàriz 125
O 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:

O 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.

Cliente
Servidor
Distribuidor
Tipo
Servidor 1
Tipo
Servidor 2
Tipo
Servidor 3
Tipo
Servidor n
Peticiones
Respuestas
R R
R
R

Figura 85. Arquitectura de Distribución
R

Servidor
Distribución
Cliente
Cambio
Tarifas
Servidor
Cambio
Tarifas al
Local
Tarifas Local
Cliente
Entrada
Código
Cola
Peticiones
Servidor
de
Ficheros
R
Tarifas en Central
BD
Local
R
Servidor
Check de
código
F
R
R
R

Figura 86. Ejemplo de Arquitectura de Distribución
@@EMG/10 - Enric Martínez Gomàriz 126
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.


Servidor Cliente
Servidor
Pre-
condición
Pre-C
Servidor Cliente
Servidor
Pre-
condición
Pre-C

Figura 87. Arquitectura de Pre-Condición
Pre-C
Servidor
Actualiza-
ción Stocks
Cliente
Movimientos
Almacén
Servidor
Consulta
Stocks
Cola
Cambios
Cliente
Facturación
Cola
Consultas
Stocks
No cambios
Pendientes
del Producto
Cambio Prioridad

Figura 88. Ejemplo de Arquitectura de Pre-Condición
@@EMG/10 - Enric Martínez Gomàriz 127
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á:

O Reglas estáticas:

C

Servidor
Stock
Almacén
Central
Cliente
de captura
de
pedidos
Stock local
Stock Central
Servidor
Stock
Local
Servidor
productos
con stock
a verificar
Productos con stock a verificar
C
D
R
R
D

Figura 89. Ejemplo de Arquitectura Configuración
@@EMG/10 - Enric Martínez Gomàriz 128
O Formatos sintácticos de los campos: por ejemplo, no se admiten
entradas sin asignar zona o DNI.
O Reglas de restricción entre los campos: por ejemplo, un cliente de
extranjero no puede admitir la forma de pago a 60 días.
O Etc.
O Reglas dinámicas.
O De concurrencia: por ejemplo, la asignación de código.
O De gestión: por ejemplo, el cliente no está en una lista de morosos.
O Que productos deben verificar stock.
O Etc.
O Alertas de negocio.
O 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
Servidor
Reglas de
Negocio
C
D
R R

Figura 90. Ejemplo de Arquitectura Configuración para el
alta de clientes remota.
@@EMG/10 - Enric Martínez Gomàriz 129

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:

O Accediendo en ese momento a los servicios y/o datos del sistema.
O 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 de
supervisión
M
Servidor
de trabajo
Resto de
Servicios
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
@@EMG/10 - Enric Martínez Gomàriz 130


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:

O Una forma de conocer cuando hay cambio de los datos:
O Por eventos.
O Por pregunta periódica lanzada por el mismo servidor.
O Por un proceso periódico con calendario pactado.
O Aprovechando el servicio remoto. Por ejemplo, arbitrando en la
respuesta la información de cambios.
O Un almacén para los datos situado en
O 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.
O 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
Servidor
Stock
Servidor
productos
con
problemas
de stocks
Productos con stock a verificar
C
Y
R

Figura 92. Ejemplo de Arquitectura
de Proxy para mejorar
rendimiento
Y
@@EMG/10 - Enric Martínez Gomàriz 131
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.


@@EMG/10 - Enric Martínez Gomàriz 132
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
Datos Compañía Aérea
Cuenta Cliente
Registro
Datos
Cliente
Anotación
Cuenta
Cliente
Registro
Datos
Viaje
Petición
Datos
Cliente
Datos
Cabecera
Cliente
RPC
Actualiza
datos
c.aérea
Obtener
Datos
Cliente
Proceso
Compañía
Aérea
Proceso
Cuenta
Cliente
R
Cliente Cuenta Cliente
Consulta
Datos
Vuelos
D
D
D

Figura 93. Arquitectura de servidores completa

Gestor de la WEB
Consulta
Datos
d.aérea
Datos Compañía aérea
Obtener
Datos
Cliente
Presentación de la WEB
Identificación
Cliente
Consulta
Vuelos
Registro
Vuelos
Identificación
Cliente
Registro
Venta
Cliente Cuenta Cliente
RPC
Proceso
Compañía
Aérea
R
Cuenta Cliente
Proceso
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.

O Un servicio permite organizar y agrupar funciones de una forma que modela la
realidad y que nos es familiar.
O Se diferencia de forma radical la especificación y el uso a través de la
implementación del servidor del servicio.
@EMG/05 - Enric Martínez Gomáriz 134
O 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:

O Diseño:
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.
O Nivel de reusabilidad y adaptabilidad funcional.
O Adaptabilidad a la evolución, tanto técnica como funcional.
O Facilidad de gestión.
¤ Publicación y localización
¤ Contrato de servicio.
¤ Eficiencia de la localización cuando se utilice.
O Implementación tecnológica.
O Independencia de la plataforma.
O Independencia cuando se use del lenguaje y/o herramienta en que este
desarrollado.
O 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.

@EMG/05 - Enric Martínez Gomáriz 135
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.
@EMG/05 - Enric Martínez Gomáriz 136

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:

O ¿Cual de los servicios debe usar la aplicación cliente?
O ¿Qué proveedor debe suministrarlo?
O ¿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
@EMG/05 - Enric Martínez Gomáriz 137
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
Servicios
A B C
D E
Proveedor B
Servicios
B 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
@EMG/05 - Enric Martínez Gomáriz 138

º 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.
@EMG/05 - Enric Martínez Gomáriz 139

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.


@@EMG/10 - Enric Martínez Gomàriz 140
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.

@@EMG/10 - Enric Martínez Gomàriz 141
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:

O Petición / respuesta: obtiene información, realiza cálculos y genera un
resultado.
O Trabajador: provoca un cambio de estado en lo que trabaja.
O Monitor: notifica cuando se produce un cambio notable en un estado.
O Agente: variante del monitor que actúa en lugar de notificar.
O Intermediario: intercepta una petición de servicio de forma transparente, la
transforma y la envía al destino original.
O Agregador: combina los resultados de diversos servicios o fuentes de datos.
O 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.

@@EMG/10 - Enric Martínez Gomàriz 142
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:

O Agrupación por áreas de negocio y funcionalidades que se quieren dejar
disponibles.
O Localización de la funcionalidad en las aplicaciones heredadas.
O Empaquetamiento y especificación de los servicios que se van proporcionar
fuera.

Clientes centro 1
Servidor
en centro 1
Clientes centro n
Servidor
en centro n
Consumidor
A
Servidor
de personal
A
D

Figura 96. Arquitectura de un servicio con partición horizontal
@@EMG/10 - Enric Martínez Gomàriz 143
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:

O 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.
O La contabilidad tiene un agente que explora las anotaciones de una cola y
apunta los asientos en los archivos contables.
O 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ón
albarán
D
D
Imputación
de la
factura
Contabilidad
F
Cálculo
de la
factura
Facturación
D
Imputación
del
Recibo
Gestión de
Cobro
T
D

Figura 97. Servicio de facturación.
@@EMG/10 - Enric Martínez Gomàriz 144
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.


Consumidor
Servidor
de
localización
C
Servidor
de
dominio 2
D
Servidor
de
dominio 1
D
Sistema 1
Sistema 2
Servicio
de router
Servicio
de router
Consumidor
Servidor
de
dominio 2
AC
Servidor
de
dominio 1
Sistema 1
Sistema 2
C
Servicio
de router
Servicio
de router

Figura 98. Servicio de Router
@@EMG/10 - Enric Martínez Gomáriz 145
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:

O La competencia ha sacado un nuevo producto.
O La previsión de ventas en una delegación no se está cumpliendo.
O Un pedido critico se esta retrasando.
O Un grupo de matriculación se esta completando.
O Un buen cliente hace tiempo que no compra.
O Un empleado se retrasa constantemente.
O Un camión de reparto ha sufrido una avería o va retrasado.
O Ha subido el precio de una materia prima importante.
O Un departamento está gastando más de lo previsto.
O Etc.

Observe que las apariciones de esta lista pueden tipificarse en:

O Cambios en los negocios.
O Incidencias.
O De negocio.
O De explotación

Y en:

O Habituales (vigilar la evolución de las ventas).
O Imprevistas (se ha estropeado un camión).


@@EMG/10 - Enric Martínez Gomáriz 146
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:

O Un mensaje para las personas u organizaciones interesadas.
O 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:

O Los mecanismos ECA permiten filtran les reacciones.
O El vigía puede escuchar los eventos.
O El cartero puede ser un buen sistema de distribución de mensajes.
O El disparador puede lanzar procesos de reacción automáticamente.
O Los agentes pueden escuchar eventos “habituales”.
O Las técnicas de publicación suscripción pueden ser de mucho interés para
gestionar mensajes.

@@EMG/10 - Enric Martínez Gomáriz 147
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.

@@EMG/10 - Enric Martínez Gomàriz 149
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.


@@EMG/10 - Enric Martínez Gomàriz 150
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:

O Diseño mediante modelos, metodología y técnicas sistemáticas.
O Planificación y seguimiento de la fabricación.




@@EMG/10 - Enric Martínez Gomàriz 151
O Utilización de materia prima, el proyecto aporta “valor añadido”.
O Certificación de la calidad.
O 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:

O El software se desarrolla lo que hace que el
factor humano sea fundamental.
O La materia prima son los componentes
prefabricados (funciones de los lenguajes,
servicios de los sistemas, bibliotecas de rutinas,
etc.).
O 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.
O 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.
O 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.
O 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:

O La formación y motivación del personal humano.
O La fiabilidad de la especificación y del análisis funcional. En general no
muy alto.
O El grado de reutilización. Es evidente que utilizar piezas y componentes
rebaja espectacularmente los costes y los problemas (coste indirecto).
O El grado de fiabilidad del software reutilizado.
O Las soluciones modulares permiten evolución y adaptabilidad a menor
coste.
O 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
Proyectos
de Software
Proyectos
Distribuidos

Figura 99. Los proyectos
distribuidos como
proyectos de
Ingeniería
@@EMG/10 - Enric Martínez Gomàriz 152
O Los modelos permiten identificar problemas y soluciones.
O Los métodos dan las técnicas de fabricación.
O Las herramientas suministran el soporte a los métodos.
O 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.

@@EMG/10 - Enric Martínez Gomàriz 153
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 Proyecto
Análisis Funcional /
Especificación
Diseño Tecnológico
Codificación
Prueba
Integración
Arranque
Mantenimiento
Mediciones
+
Métricas

Figura 100. Fases de la gestión del Proyecto
Pre-estudio
Estudio de
viabilidad
Planificación
Conclusión
Ejecución
=
Seguimiento
+
Control
+
Revisiones
Dos aspectos:
Técnico
Administrativo
Aspectos de la gestión del Proyecto
@@EMG/10 - Enric Martínez Gomàriz 154

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:

O Una descripción del modelo de datos.
O 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
Requerimientos
de usuario
Análisis de
requerimientos
Análisis Funcional
/ Especificación
Diseño
Codificación
Prueba
Integración
Instalación
Administración
del sistema Mantenimiento

Figura 101. Ciclo de Vida Clásico o en Cascada
@@EMG/10 - Enric Martínez Gomàriz 155
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ño
rápido
Construir el
prototipo
Evaluación del
prototipo
Depuración
prototipo
Producto
Ingeniería
Inicio
Final

Figura 102. Prototipaje.
@@EMG/10 - Enric Martínez Gomàriz 156

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
@@EMG/10 - Enric Martínez Gomàriz 157
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:

@@EMG/10 - Enric Martínez Gomàriz 158
º 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 3
Especificación
Diseño/
Implementación
Validación/
Generalización
Cluster 2
Especificación
Diseño
Implementación
Validación/
Generalización.
Cluster 1
Especificación
Diseño/
Implementación
Validación/
Generaliación

Figura 104. Ciclo de vida de clase de Meyer
Sistemas del mundo real
Mantenimento
Uso
Programa
Más Desarrollo
Análisis de requerimentos
Especificación de los
Requerimientos de
Software
Especificación de los
Requerimentos
de Usuario
Disño del sistema
Diseño del programa
Codificación
Prueba Unitària
Prueba de Sistema

Figura 105. Ciclo de vida OO de Henderson -
Sellers
@@EMG/10 - Enric Martínez Gomàriz 159
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 Calidad Puesta en Marcha Cierre
Gestión Técnica

Figura 106. Esquema de Administración de un Proyecto
@@EMG/10 - Enric Martínez Gomàriz 160
º 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.

@@EMG/10 - Enric Martínez Gomàriz 161
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.

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

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.
@@EMG/10 - Enric Martínez Gomàriz 163

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.

@@EMG/10 - Enric Martínez Gomàriz 164
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
@@EMG/10 - Enric Martínez Gomàriz 165
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.....


@@EMG/10 - Enric Martínez Gomàriz 166
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.
@@EMG/10 - Enric Martínez Gomàriz 167
• 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:

O Una descripción de los datos.
O Diagramas de transformación.
O 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.

@@EMG/10 - Enric Martínez Gomàriz 168
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.

@@EMG/10 - Enric Martínez Gomàriz 169
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:

O Revisar la localización y gestión de las entidades de datos.
O 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ógica Etapa Funcional
Análisis Funcional /
Especificación
Diseño Tecnológico
Diseño Distribuido
Descripción de los
programas principales
Arquitectura del
Sistema/Software
UML
U
M
L
MAFDRA
M
A
F
D
R
A
C
O
M
U
N

Figura 107. Encaje del diseño distribuido en el ciclo de desarrollo del
software
@@EMG/10 - Enric Martínez Gomàriz 171
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.

O Metodologías convencionales:
O Datos: Modelo relacional
O Procesos de transformación: Diagramas de flujo.
O Secuencia de transformación: Descripción de los procesos y programas
tras el tecnológico.
O Metodología RDA - MAFDRA
O Datos: Diagrama de Datos OO – Modelo conceptual de especificación.
O Procesos de transformación: Diagramas de flujo.
O Secuencia de transformación: Secuencialización de los procesos dentro
de los diagramas de flujo.
O Metodología OO – UML.
O Datos: Modelo conceptual de diseño.
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.
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.


@@EMG/10 - Enric Martínez Gomàriz 172
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
Actualiza
datos
Datos Compañía aera
Clientes
Entrada
Petición
Cliente
Clientes
Vuelos por cliente
Reserva
Cliente
Impresión
Reserva
Crédito estandar

Figura 108. Ejemplo de diagrama de flujo.
@@EMG/10 - Enric Martínez Gomàriz 173

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

Actualiza
datos

Reserva
Cliente

@@EMG/10 - Enric Martínez Gomàriz 174
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

Actualizar
Crédito

Actualiza
datos
Entrada
Petición
Cliente
Pedido
Comprobar
Crédito Petición
Cliente
Acceso
al
Cliente
Pedir
Productos
Tomar
Datos
Clientes
Clientes
Servidor de
Crédito
R
Cuentas Clientes
Imprimir
factura
Contado
Aviso
al
Cliente
Factura
Sin
Crédito
Con
Crédito

Figura 109. Ejemplo de la utilidad de la
secuencialización
@@EMG/10 - Enric Martínez Gomàriz 175
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 de
Alta
Acceso a
Clientes
Pedir
Productos
Cliente
Clientes
No Existe
Existe

Figura 110. Ejemplo de Decisión dentro de la Secuencia de
Ejecución.
@@EMG/10 - Enric Martínez Gomàriz 176
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.

@@EMG/10 - Enric Martínez Gomàriz 177
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}.
@@EMG/10 - Enric Martínez Gomàriz 178

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
@@EMG/10 - Enric Martínez Gomàriz 179
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
@@EMG/10 - Enric Martínez Gomàriz 180
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.
@@EMG/10 - Enric Martínez Gomàriz 181

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ón
Almacenes
Inventario
Valorado
STOCKS
Ofertas
Lanzamiento
Control
Calidad
Entrada
a Stocks
Recepción
Pedidos
COMPRAS
Planificación Seguimiento Rebajar
de Stocks
PRODUCCIÓN
FABRICACIÓN

Figura 114. Ejemplo de Diagrama Jerárquico.
@@EMG/10 - Enric Martínez Gomàriz 182
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:

O Establecer una terminología base de datos para que usted y yo nos
entendamos.
O 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.
@@EMG/10 - Enric Martínez Gomàriz 183

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:

O Los datos representados en las tablas.
O Operadores para manipular las tablas.
O 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
@@EMG/10 - Enric Martínez Gomàriz 184
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:

O Uno a Uno.
O Uno a muchos.
O 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
@@EMG/10 - Enric Martínez Gomàriz 185
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
EsquemaI
nterno 1
Esquema
Interno M

Figura 116. Arquitectura ANSI/SPARC de tres niveles
@@EMG/10 - Enric Martínez Gomàriz 186

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
@@EMG/10 - Enric Martínez Gomàriz 187
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
Results
Operations
DBMS

Figura 117. Bases de datos pasivas
@@EMG/10 - Enric Martínez Gomàriz 188
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
Results
Operations
DBMS
facts
ECA-
rules
Actions
Events
ECA-rules

Figura 118. Bases de datos activas
Acciones
Externas
INSERT
UPDATE
DELETE
Base de
datos
Errores
E
v
e
n
t
o
s
Trigger
Procedimento
Procedimento
catalogado
Regla
Gestor de error
Gestores
Eventos

Figura 119. Mecanismo de trigger
@@EMG/10 - Enric Martínez Gomàriz 189

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.

@@EMG/10 - Enric Martínez Gomàriz 190
La utilidad de las vistas es muy amplia:

O Definir visiones simplificadoras de la BD que la acerquen a la visión que se
necesita en cada momento.
O Eliminar las desventajas de la evolución manteniendo, a efectos de gestión, el
esquema anterior.
O Una forma de implementación de
esquemas externos.
O Establecer mecanismos de autorizaciones.
En particular, pueden dar acceso a
atributos a usuarios que no tienen
permisos de lectura a la tabla.
O Integración de esquemas de datos
distribuidos.

Esta última utilidad sólo puede aplicarse sí:

O Las dos bases de datos son relacionales.
O 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?

Conceptual
Schema 1
Internal
squema 1
Conceptual
Schema N
Internal
squema N
Vista
Aplicación

Figura 120. Vistas e Integración de
BD's
@@EMG/10 - Enric Martínez Gomàriz 191
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
@@EMG/10 - Enric Martínez Gomàriz 192
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.


@@EMG/10 - Enric Martínez Gomàriz 193
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.

@@EMG/10 - Enric Martínez Gomàriz 194
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
@@EMG/10 - Enric Martínez Gomàriz 195
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
@@EMG/10 - Enric Martínez Gomàriz 196
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.

@@EMG/10 - Enric Martínez Gomàriz 197
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
Cuenta
Analítica
Vuelos
Viajes
Comprados
por
Vuelos
por
Cliente
1
M
1
N
Corresponde a
Anotaciones
Cuenta
Analítica
1
M
Es movimiento de Compañía
Servido por
M 1
Plazas
Hotel
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
@@EMG/10 - Enric Martínez Gomàriz 198
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
Venta
Viaje Aéreo
y Hotel
Datos Compañía Aérea
Cuentas Clientes
Clientes
Vuelos por cliente
Reserva
Cliente
Crédito estándar
Datos Hotel

Figura 123. Proceso de Venta de Viaje Aéreo
Petición Cliente
Actualiza
Datos
Datos Compañía Aérea
Clientes
Entrada
Petición
Cliente
Clientes
Vuelos por Cliente
Reserva
Cliente
Impresión
Reserva
Crédito Estándar Datos Hotel
Consulta
datos de
vuelos

Figura 124. Primer proceso de refinamiento de Venta Viaje y Hotel a
Cliente
@@EMG/10 - Enric Martínez Gomàriz 199

Cliente
Petición Cliente
Registro
Datos
Cliente
Petición
Cliente
Acceso
Datos
Cliente
Registro
Datos
Viaje
Consulta
Cuenta
Cliente
Cuenta Clientes
Rechazar
Venta
Alta
Cliente
Cliente
Re-intentar
Crédito Estándar
No crédito
Sin 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
Registrar
Datos
Vuelo
Registro
Datos
Hotel
Datos Compañía Aérea
Consultar
Datos de
Vuelos
Consultar
Datos
Hoteles
Datos Hotel
Sin hotel
No hay
habitaciones
Cliente
Aviso al
Cliente
Acabar
Necesita Hotel
No Necesita Hotel

Figura 126. Refinamiento de Registro Datos del Viaje
@@EMG/10 - Enric Martínez Gomàriz 200
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
Pedir
Datos
Cliente
Cliente
Cliente
Cuenta Cliente
Incorporar
a Clientes
Asignar
Crédito
Crédito Estándar
Alta
Cliente
Cliente
Cliente
Cuenta Cliente
Crédito Estándar

Figura 127. Proceso de Alta de Clientes
Petición Cliente
Actualiza
reserva
c.aérea
Datos Compañía Aérea
Datos Hotel
Actualiza
datos
hotel
Vuelos por Cliente
Anotación
del vuelo por
Cliente
Aviso
al
Cliente
Anular
Venta
Re-intentar
Cliente
No hay plazas
Hay plazas
Anotación
Cuenta
Cliente
Cuenta Clientes

Figura 128. Proceso para Actualizar Datos.
@@EMG/10 - Enric Martínez Gomàriz 201
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 área
Clientes
Vuelos por cliente
Venta por
Cliente
Periodo a Listar
Venta por
Vuelo

Figura 129. Proceso de Estadísticas
Entrada
Periodo a
Listar
Datos Compañía área Clientes Vuelos por cliente
Venta por
Cliente
Venta por
Vuelo
Periodo a Listar
Listado
Ventas por
Cliente
Listado
Ventas por
Vuelo

Figura 130. Refinamiento del Proceso de Estadísticas
@@EMG/10 - Enric Martínez Gomàriz 202
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.
Venta de Vuelos en
Delegaciones
Proceso de Ventas Estadísticas
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 vuelo Datos 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:

O Presentar el Modelo de Objetos, que como ya he dicho, es un método muy
eficiente para describir los modelos de datos.
O 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.

@@EMG/10- Enric Martínez Gomàriz
204
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
@@EMG/10- Enric Martínez Gomàriz
205

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
@@EMG/10- Enric Martínez Gomàriz
206

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.


EClase Biclicleta:
OAtributos:
¤ Medida del marco
¤ Tamaño de la rueda
¤ Cadena
¤ Material
OMétodos:
¤ Cambiar de marxa
¤ Pedalear
¤ Reparar
EInstancias:
OLa bicicleta de Carlos
OLa 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
@@EMG/10- Enric Martínez Gomàriz
207
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.
@@EMG/10- Enric Martínez Gomàriz
208
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.
@@EMG/10- Enric Martínez Gomàriz
209

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ígono
Vertices
Color de aristas
Color del fondo
Crear
Cáculo del área
Mover
Dibujar
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
@@EMG/10- Enric Martínez Gomàriz
210
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
@@EMG/10- Enric Martínez Gomàriz
211
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).

@@EMG/10- Enric Martínez Gomàriz
212
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.

@@EMG/10- Enric Martínez Gomàriz
213
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.
@@EMG/10- Enric Martínez Gomàriz
214
º 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ís
Nombre
Ciudad
Nombre
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
@@EMG/10- Enric Martínez Gomàriz
215
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ís
Nombre
Ciudad
Nombre
Tiene-capital
1 1
País
Nombre
Ciudad
Nombre
Tiene-ciudades
1 N
Línea
Nombre
Punto
Nombre
Se-cruzan
0,2+ 0,N
Workstation
Nombre
Window
Nombre
Consola_de_errores
1 0,1
Arcivo
Nombre
Usuario
Nombre
Accesible por
0,N 0,N
Clase-1 Clase-2
Número-1 Número-2
Exemplos

Figura 144. Notación de la Multiplicidad por un cardinal.
@@EMG/10- Enric Martínez Gomàriz
216

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
Clase
1+
Clase
1-2,4

País
Nombre
Ciudad
Nombre
Tiene-capital
País
Nombre
Ciudad
Nombre
Tiene-Ciudades
1+
Se-cruzan
Línea
Nombre
Punt
Nombre
2+
Workstation
Nombre
Window
Nombre
Consola_de errores
Archivo
Nombre
Usuario
Nombre
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.
@@EMG/10- Enric Martínez Gomàriz
217
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ón
Operador Binario
Variable
Nombre
Constante
Valor
Primer Operando
Segundo Operando

Figura 150. Modelo de Objetos de una
Expresión
Línea
Texto
Columna
Coordenada X
Coordenada Y
Ancho
Largo
Página
Ancho
Largo
Margen izquierdo
Margen derecho
Margen superior
Margen inferior

Figura 151. Modelo de Objetos de un texto.


Figura 148. Notación y
ejemplo de
Agregación
Documento Parrafo
Palabra
PC
Monitor
Caja
de sistema
Mouse Teclado
Chasis CPU RAM Ventilador
1+
Discp
1+
Figura 149. Ejemplos de Agregaciones
@@EMG/10- Enric Martínez Gomàriz
218
País
Nombre
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 cartas
Jugador
Res
5
Cartas
Palo
Número
Pareja Trio Full Poquer Color
EEvidentemente, 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.

Ciudad
Nombre
Aeropuerto
Nombre
Aerolínea
Nombre
Pilot
Nombre
Vuelo
Fecha
Número
Origen
Llegada
Avión
Modelo
Número
Horas vuelo
Pasagero
Nombre
Asiento
Localización

Figura 154. Modelo de Objetos de un sistema
de transporte aéreo
Empleados
Compañí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
{
Conceptual
squema layer
{
Internal
squema layer
Internal
squema 1
Internal
squema M
ANSI/SPARC three schema architecture

Figura 156. ANSI/SPARC three schema architecture
@@EMG/10-Enric Martínez Gomàriz 220

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:

O El modelo de objetos OO se traspasará a un esquema conceptual relacional
utilizando reglas de mapeo.
O 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.

External
Object
Models
Conceptual
table model
Familia de aplicaciones relacionadas
Internal
squema 1
Internal
squema 1
Internal
squema 1
External
table
models
External
table
models
External
table
models
Vistas y/o interfícies
de programas
mapping rules
Conceptual
Object
Model
mapping rules

Figura 157. Equivalencia de de niveles entre OO y relacional
@@EMG/10-Enric Martínez Gomàriz 221
Así, se habla de dos tipos de partición de clase:

O Partición Vertical, en la cual las instancias se dividen en más de una tabla.
O 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:

O Tablas más reducidas.
O Mayor rendimiento y facilidad de navegación.

Las desventajas son:

O Esquemas resultantes más complejos.
O Mayor dificultad de ampliación.
O 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.
@@EMG/10-Enric Martínez Gomàriz 222

· 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.
@@EMG/10-Enric Martínez Gomàriz 223
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:

O Es una etapa adicional al diseño tecnológico del sistema.
O Es una etapa independiente de la metodología utilizada para el análisis y el
diseño tecnológico de la aplicación.
O Partirá de que se dispone de:
O Un modelo conceptual de datos.
O Las funciones del sistema.
O 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:

O De donde sale la información anterior.
O 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:

O Estereotiparse: servidores, bases de datos, PC’s, impresoras, dispositivos de
tipos concretos, etc.
O Relacionarse entre ellos incluyendo la cardinalidad, el tipo de la relación
(TCP/IP, Internet, etc.) y los roles.
O Informar de los materiales que incluyen.

Para poder describir el sistema distribuido usaremos las siguientes posibilidades
adicionales:

O 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.
O Referenciar cada material o
nodo con un nombre.
O 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
D
i
s
e
ñ
o

d
e
l

S
i
s
t
e
m
a

D
i
s
t
r
i
b
u
i
d
o

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
• Aplicaciones
Heredadas
• DB2
<<Servidor de
comunicaciones>>
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
1
1..100
Internet
Terminal
Server
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
Local
Puerta
del sol
Servidor
Local
Moratalaz
Puesto
de Venta
4TPV’s
Puesto
de Venta
2 TPV’s
Sevidor
WEB
Barcelona
Supervisor
Lluís Puig
Supervisor
Ana Ros

Figura 161. Ejemplo de diagrama de Sistema
Servicios
de Host
<<Host>>
Servidor WEB
<<Servidor WEB>>
1
1
1
Servicios del
Local
<<Servidor de
Local>>
*
Puesto de
Venta
<<Puesto de
Venta>>
1
1..12
Supervisor
<<Supervisor>
1
1..100
1..5
1
Mando del
Local
<<Servidor de
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 Central 1
*
D
Alta Clientes
en el Local
Alta Clientes
en la Central 1 * 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.

Servidor
Alta
Clientes
Cliente Clientes en la Central
R D
Servidor
Alta
Cliente en
la Central RPC
Clientes en la Tienda
Cliente Alta Clientes
1 *
Alta Clientes
en la Central
1
*
Base de datos
Central
•Oracle
Base de Datos
Local
•SQL-Server
1 *
1 *
D

Figura 164. Ejemplo de diagrama de Arquitectura de Servicios
D
1 *
RPC Remoto
Delegación
Alta Clientes
en el Local
Alta Clientes
en la Central
1 *
Alta Clientes
en el Local
Alta Clientes
en la Central

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 *
Alta Clientes
en la Central
Servicios de
Host
1
*
Base de datos
Central
Servicios de
Host
•Oracle
Base de Datos
Local
Servicios del
Local
•SQL-Server
1 *
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én Tienda
Registrar
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én Tienda
Registrar
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
Encriptador
2. 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:

O Vista lógica.
O Muestra la organización del sistema en clases
O Vista de procesos.
O Describe los flujos de control de datos.
O En nuestro caso incluirá la arquitectura de servicios.
O Vista de desarrollo.
O Encapsula los elementos de diseño en módulos.
O 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
Clase
Proveedora
del Servicio
N
Patrón
Controlador
(Slave)
D
D
R M
Patrón
Controlador
Clase
Cliente
Clase
Proveedora
del Servicio
1
Clase
Proveedora
del Servicio
N
D
D
R
Patrón
Controlador
Clase
Cliente
Clase
Proveedora
del Servicio
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.
O Vista de despliegue.
O Muestra la distribución de los módulos de la vista de desarrollo por la
plataforma.
O Se conoce también como vista física, terminología de la que huiré aquí
para evitar equívocos.
O Se corresponde con nuestro concepto de localización.
O Vista de escenarios o casos de uso.
O Muestra los usos más significativos del sistema y como afectan a las
otras vistas.
O 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.

O 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.
O 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.
O 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:

O Si el ámbito es global, para construir la arquitectura distribuida basta
implementar las clases con los medios que proporciona el modelo de objetos
distribuidos.
O Ojo: nadie evita:
¤ Los análisis de arquitectura de servicios, consistencia y
administración.
¤ Preocuparse del rendimiento.
O 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:

O Se trabaja con una arquitectura de datos distribuida que imposibilita el mapeo
directo del modelo de datos de diseño a un esquema relacional.
O Consecuencia: la persistencia de las clases se ha de gestionar
“convencionalmente”. Servicios de datos se encapsularan en clases
para resolver el metaesquema.
O No existe tal plataforma de objetos distribuidos. El modelo OO es
simplemente un entorno de desarrollo orientado a objetos.
O Consecuencia: todos los servicios se comunican “convencionalmente”.
O Convivencia de más de una plataforma y/o ausencia en algunos de los nodos.
O Consecuencia teórica: sólo hay que utilizar modelos de comunicación
entre servicios convencionales en los saltos entre los nodos
heterogéneos.
O Consecuencia real: todos los servicios se comunican
“convencionalmente” (sino habrá que repetir servicios o no tendríamos
transportabilidad).
O No se quiere usar la plataforma de objetos distribuidos en la arquitectura
distribuida:
O Consecuencia: todos los servicios se comunican “convencionalmente”.
241
O Se fuerza una única plataforma:
O 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
Servidor
Alta
Clientes
Cliente Clientes en la Centr
R D
Servidor
Alta
Cliente en
la Central RPC
Clientes en la Tienda
Cliente
Alta()
Situación
Alta()
AltaCentral()
1 1
Alta nodo local +
AltaCentral()
Central
AltaCentral()
Nodo
AltaCentral()
Alta nodo
remoto(central)
Vacia
Servidor Central
Cliente
Alta()
Servidor local
Cliente
Alta()
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:

O Al final, los servicios los proveen instancias de una clase, especializada o no.
O Los servicios son operaciones de la clase que proveen directamente el
servicio o resuelven y encapsulan los puntos de heterogeneidad.
O 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.
O Es necesario añadir el análisis de consistencia que puede considerarse un
paso incremental de la especificación y el diseño.
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.
O La localización es un diagrama de despliegue.
O 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:

O No existen dos
productos con la
misma referencia ref.
O No existen dos
analíticas con el
mismo NIF.
O 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
*
*
*
*
1
1
*
ref: String
nom: String
Producto
densidad: Real
Materia Prima
costFabr: Real
preuVenta: Real
Producto Venta
Liquido
Capacidad: Real
Envase
dia: Date
Fecha
precioVenta: Real
cantidad: Real
Consumo
NIF: String
nom: String
dir: 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
*
1
1
*
ref: String
nom: String
Producte
densitat: Real
Materia Primera
costFabr:Diner
preuVenda:Diner
Producte Venda
Liquid
Capacitat: Real
Envas
data: Date
Data
preuVenda:Diner
quantitat:Real
Consum
NIF: String
nom: String
dir: 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:

O 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).
O 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.
O 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.
O Registrar - Botón para
registrar la nueva relación.
O Acabar – Botón para finalizar el caso de uso.
O 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.

O El operador escoge una materia prima de la lista.
O El sistema muestra al operador la lista de proveedores de materias primas
que todavía no la suministran.
O El operador elige un proveedor de la lista.
O El operador pulsa Registrar
O El sistema establece la relación.
O El sistema muestra el número total de proveedores que suministran la materia
prima.
O 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:

O asignarProveedor() lanzado con el evento de clikado del botón Registrar
247
O listaMateriasPrimas() lanzado con el evento de creación de la interfície gráfica
O listaProveedores() lanzado con el evento de cambio de contenido de la cima
de la lista desplegable de materias primas
O 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
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.

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
1. mp corresponde a una materia prima válida.
Postcondiciones:
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:

O obtenerMP(): utilizado para implementar la operación listaMateriasPrimas().
O obtenerPR(): utilizado para implementar la operación listaProveedores().
O asignaPR(): utilizado para implementar la operación asignarProveedor().
O 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:

O inicializar() la lista desplegable LMP.
O cambia() la cima de la lista LMP - desplegable de materias primas.
O inicializar() la lista desplegable LPR.
O escogerProveedor() sobre la cima de LPR que serán las propias primitivas
proporcionadas por la clase lista desplegable.
248
O pulsado() el botón registrar para realizar la asignación.
O poneTexto() en el cuadro PMP para informar del total de proveedores que
suministran la materia prima.
O 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 Datos
listaMateriasPrimas()
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: String
pr: String
TotalPrv; Date
:TxAsignarProveedor
ejecutar()
TxAsignarProveedor(mp,pr)
ejecutar()
Transacción
resultado: Set(String)
:TxListaMateriasPrimas
ejecutar()
obtieneResultado():
Set(String)
TxListaMateriasPrimas()
mp: String
resultado: 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
lmp
obtieneResultado()
LMP: Desplegable
inicializar(lmp)
Coloca blancos
en el texto
PMP: Cuadro de Texto
limpiaTexto()
cambiaLMP()
Coloca blancos
en el texto
Diálogo: Área de Texto
limpiaTexto()

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:

O 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]
lp
obtieneResultado()
LPR: Desplegable
inicializar(lb)
LMP :Desplegable
cambia()
APMP :Ventana
pulsadoAcabar()
Acabar :Botón
pulsado()
Acabar el caso de uso solicitado
el servicio finCasoDeUso()
LMP: Desplegable
obtieneCima()
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: Desplegable
obtieneCima()
mp
LPR: Desplegable
obtieneCima()
pr
ObtenerTotalPrv()
totalPrv
PMP: Cuadro de Texto
poneTexto(Texto(totalPrv)

Figura 183. Diagrama de secuencia de la reacción al botón Registrar para
asignar el proveedor a la materia prima.
251
O Permitir que la capa de dominio pida directamente los servicios a la capa de
datos.

He escogido la segunda solución por dos razones:

O La operación del ejemplo es tan sencilla que de hecho podría montarse en
dos capas.
O 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

O Disponemos de una arquitectura física de tres niveles: central, servidor
departamental y máquinas cliente.
O La arquitectura de datos es centralizada y el gestor relacional esta situado en
el nodo de la central.
O 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:
:TxListaMateriasPrimas
ejecutar()
:Base de datos
obtenerMP()
lmp
Servicio que devuelve todas
las materias primas.
:TxListaProveedores
ejecutar()
obtenerPR(mp)
lp
:TxAsignarProveedor
ejecutar()
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 Datos
listaMateriasPrimas()
obtenerMP()
Registrar:: pulsado()
listaProveedores()
obtenerPR()
asignarProveedor()
asignarPR()
LMP::cambia()
escogeProveedor()
Acabar:: pulsado ()
PMP::poneTexto()
LPR::inicializar()
LMP::inicializar()
finCasoDe Uso()
R
totalPR()
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:

O La integración de la parte cliente nos proporcionaría el programa Asignación
de Proveedor de integración gráfica.
O Obtenemos los servidores:
O Obtener Materias Primas para el servicio listaMateriasPrimas().
O Obtener Proveedores para el servicio listaProveedores().
O Asignar Proveedor para el servicio AsignarProveedor().
O Se necesitan los procedimientos catalogados:
O ObtenerMP para obtener la lista de materias primas de la base de datos.
O ObtenerPR para obtener la lista de materias primas de la base de datos.
O Crearemos los servicios de datos SQL integrados como servicios pasivos en
le servidor Asignar Proveedores:
O AsignarPR para registrar la asignación sobre la base de datos.
Usuario Ventana Capa de Dominio Capa de Datos
listaMateriasPrimas()
obtenerMP()
Registrar:: pulsado()
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
O 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 de
Compras>>
PC
•Windows
1 1
<<Puesto de trabajo
de 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 de
Compras
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
Servicios de
Compras
1 *
Obtener
Proveedores
Servicios de
Compras
Base de datos
Central
Servicios en la
Central
• Oracle
1 *
D
1
*
1
*
1
*
D
1
*
D

Figura 189. Diagrames de Servicios y de Localización de Asignar
Proveedores.
@@EMG/10 - Enric Martínez Gomàriz 256
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,

O 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.
O 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.
O 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.

@@EMG/10 - Enric Martínez Gomàriz 257
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.
@@EMG/10 - Enric Martínez Gomàriz 258
· 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:

O Tipificar comportamientos.
O Normalizar soluciones aplicables a problemas parecidos.
O Asimilar el comportamiento de cada modelo a una visión lógica de proceso.


Figura 190. Esquematización de la
arquitectura de datos
@@EMG/10 - Enric Martínez Gomàriz 259

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:

O Un índice, para datos particionados
O 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
ABC
DEF
GHI
JKL
MNO
PQR
ABC
DEF
GHI
JKL
MNO
PQR
ABC
DEF
GHI
JKL
MNO
PQR
ABC
DEF
GHI
JKL
MNO
PQR
ABC
DEF
GHI
JKL
MNO
PQR
ABGJMP
BHKNQ
CFILOR
GHI
JKL
MNO
Replicadas
Particionadas
Reorganizadas
Replicadas
temporalmente
(Cached)

Figura 191. "Visión" de los modelos de datos

Figura 192. Arquitectura de datos distribuidos
@@EMG/10 - Enric Martínez Gomàriz 260


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:

O Distribuir los datos según los modelos eliminado las características
especificas: centralizado: distribuido homogéneo, distribuido heterogéneo y
replicación.
O Identificar, analizar y modelar los datos que no están en BD
O Realizar la localización física.
O Ajustar los recursos de conectividad y Middleware.
O Reajustar la arquitectura para minimizar el tráfico.
O Identificar los servidores de lógica de datos y establecer el flujo entre ellos.
O 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.

@@EMG/10 - Enric Martínez Gomàriz 261
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



@@EMG/10 - Enric Martínez Gomàriz 262
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.
@@EMG/10 - Enric Martínez Gomàriz 263
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:

O Velocidad de la conexión frente al volumen transportado
O Resolver conexiones lentas.
O Tener autonomía de trabajo en el puesto cliente.
O Disminuir el tráfico de datos por la red, local o remota.
O Resolver diferencias semánticas y sintácticas.
O 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
O Controlar la posibilidad de mantenimiento simultáneo de una misma entidad
en puntos diferentes de la plataforma distribuida.
O Necesidad de transmisión de los cambios síncronamente a todos los nodos.
O 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:

O Los productos, proveedores y sus condiciones de compra.
O Productos y composición.
O 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
Copia
1
Copia
2
1
2
1
2
Copia
1
Copia
2
3
5
4
5
4
Copia
1
Copia
2
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:

O Periódicamente, a intervalos de tiempo pactados. Es la opción escogida casi
en todos los casos.
O 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 de
Cambios
Fuente de
datos primaria
Mantenimiento
de la fuente
primaria
Agente de
replicación
síncrona
Fase 1 Fase 2
Copia
1
Copia
2
1
2
1
2
Copia
1
Copia
2
3
5
4
5
4
Copia
1
Copia
2
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
• Asincrona
entre
iguales
• Bidireccio-
nal
• Sincrona
• Confirma-
ción en dos
fases
• Copia en
Caliente
• Full
Tolerance
Alta disponibilidad Soporte a la decisión
Investigación Análisis
Consulta 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:

O 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.
O 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.
O Cuando el nodo recibe la copia, coloca el estado de “recibido”.
O 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
Copia
1
Copia
2
Copia
N
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é:

O En memoria interna del programa.
O En una zona de memoria compartida.
O En un disco virtual.
O 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:

O Uno de comparación
que proporcione
información de las
diferencias.
O 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ón
Automá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.

O 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.
O 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.
O 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.
O Presencia de nodos remotos lentos y de usuarios nómadas.
O 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:

O 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.
O Un modelo centralizado, o al menos de las entidades afectadas.
O 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.
O 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.


Hay
nueva
versión?
Servidor de
programas de
referencia
Servidor de
programas
local
Copiar
nueva
versión
Arrancar
Programa
pedido
Auto
desconexión
Si
No

Figura 202. Arquitectura de un ejecutor
@@EMG/10 - Enric Martínez Gomàriz 284
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
@@EMG/10 - Enric Martínez Gomàriz 285
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:

O Serie, opcional
O Referencia de nodo.
@@EMG/10 - Enric Martínez Gomàriz

287
O Numero secuencial dentro del nodo.

Veamos dos ejemplos.

O Productos:
O 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.
O Numero secuencial de cinco dígitos siempre informados.
O Pedidos y albaranes.
O Serie: un digito, A o P.
O Referencia de nodo: dos dígitos.
O 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
s
Recuperació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
F
r
o
n
t
e
r
a

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:

O Agregación. Por ejemplo, un pedido y todos los albaranes en que se ha
servido.
O Integración. Por ejemplo juntar los atributos de producto de las aplicaciones
de fábrica y de facturación.
O 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
O 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:
O Con una autentificación inicial y una clave de autentificación del permiso
que se incorporara a cada petición.
O Autentificación a cada acceso.
O Responsabilizándose la aplicación de uso. Esta solución es admisible en
aplicaciones internas pero no en relaciones con terceros.
O Conocer los esquemas lógicos de origen y de los servicios de acceso de los
que hemos hablado.
O 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:

O El esquema conceptual integrado.
O 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.
O Todas las equivalencias necesarias para resolver las diferencias semánticas y
sintácticas entre atributos compartidos. Incluye las reglas de transformación.
O Equivalencia de claves principales, secundarias y auxiliares.
O El criterio de partición horizontal si esta presente esa casuística.
O 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
O XML.
O 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:

Servidor
de
agrupación
Servicio
de
Conexión
D
P
S
Servidor
de
agrupación
M
Servicio
de 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 de
entrada
Entidades afectadas
Sincronizador
Servicio
de origen
Gestión
a las
entidades
Acceso
Registro
de
cambios
M
Punto 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:

O Servicio de lectura donde no tendremos problemas de consistencia,
Recordemos que un servicio de lectura se usa en muchas más ocasiones.
O 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 de
entrada
D
Servicio
de origen
M
Acceso
Agregación
de
resultados
Interpretador
Metaesquema
Punto 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 de
entrada
D
Servicio
de origen
M
Acceso
Transformar
Atributos
Interpretador
Metaesquema
Punto de
salida
Determinar
Referencias

Figura 209. Modificación por servicios.
297
Esta espera
puede
resolverse
de varias
formas:

O El
servici
o de
agrupa
ción
ofrece
a la
central
un
servici
o de
actuali
zación
del
nodo
local.
O Verificando una cola de operaciones pendientes donde la central anote los
nuevos registros.
O Haciendo que el nodo se suscriba a los cambios de la central:
O Recibiendo un evento cada vez que hay cambios.
O Accediendo periódicamente a buscarlos.

Estas dos posibilidades pueden ofrecerse a su vez de dos formas:

O Como un hilo más del sincronizador.
O 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:

O Una carga masiva por interfase, en la línea de otras que vemos en este libro.
O 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.


Servicio
de origen
P
S
Servidor de agrupación
Registro de
los cambios
recibidos
desde el
exterior
M
D
S
Punto de
entrada
Entidades afectadas
Sincronizador
Gestión
a las
entidades
Acceso
Registro
de
cambios
M
Punto de
salida
Servicio
replicació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.

@@EMG/10 - Enric Martínez Gomàriz 299
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.

O Aplicaciones de Desarrollo Rápido
O 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.

@@EMG/10 - Enric Martínez Gomàriz 300
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
@@EMG/10 - Enric Martínez Gomàriz 301
Diseño
Funcional
Diseño de la
Arquitectura distribuida
Análisis de los
Datos
Distribución del
Proceso Aplicación
Crear Arquitectura
de servicios
Map to reality
Diseño
Administración
Diseño Distribuido
Diseño de
Consistencia
Metodología Puzzle
Especificación
servicios
Especificación
resto 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 datos
Especificación
piezas cliente
Ampliar el cuadro
control admistración
Diseñar el cuadro
control del negocio
Diseño
Tecnológico
Identificación fronteras
Precondiciones de
Plataforma
Identificación de puntos
de 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.

@@EMG/10 - Enric Martínez Gomàriz 302
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.

@@EMG/10 - Enric Martínez Gomàriz 303
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:

@@EMG/10 - Enric Martínez Gomàriz 304
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.

@@EMG/10 - Enric Martínez Gomàriz 305
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.

@@EMG/10 - Enric Martínez Gomàriz 306
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
@@EMG/10 - Enric Martínez Gomàriz 307
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.
@@EMG/10 - Enric Martínez Gomàriz 308
º Localización.
º Fallos a provocar.
º Procesos de administración de las piezas a verificar.
º Dependencias entre las piezas, o servicios, a verificar.

@@EMG/10 - Enric Martínez Gomàriz 309
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 funciones
× Distribuirlas por
niveles lógicos
× Separar funciones
entre clientes y
servidores
× Identificar servicios
Distribución del
Proceso de la
Aplicación
× Definir comunicación
cliente-servidor.
× Definir arquitectura
servicios.
× Definir arquitectura
cliente/servidor
× Analizar
Crear la
Arquitectura
Distribuida
× Localización
× Configuración
× Analizar rendimiento
Map to Reality
Análisis
Funcional
Completar
el Diseño
× Arquitectura
de datos
× Adaptar
diseño
funcional
× Diseño lógica
de datos
× Especificar
× Analizar
rendimiento
Análisis de
Datos
Análisis
Tecnológico

Figura 214. Etapas del Diseño de la Arquitectura Distribuida
@@EMG/10 - Enric Martínez Gomàriz 310
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ón
× Modelización
Analizar Rendimiento
Análisis
Funcional /
Tecnológico
Arquitectura de Datos - Valorar y Decidir
×Identificación
del resto de
Servidores
× Modelo, esquema acceso
× Piezas, servidores y procedimientos catalogados
Especificar la Arquitectura de Datos
× Localización obligada
× Aplicar 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 datos
Adaptar Diseño Funcional
× Puntos de
acceso
heterogéneo
× Niveles lógicos
× Tamaño,
accesibilidad y
volatilidad
× Tiempos de
respuesta
necesarios
× Localización de
los puntos de
mantenimiento
× Codificación Dis.
Pre-requisitos

Figura 215. Etapas del Análisis de los datos
@@EMG/10 - Enric Martínez Gomàriz 311
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.
@@EMG/10 - Enric Martínez Gomàriz 312

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í.

@@EMG/10 - Enric Martínez Gomàriz 313
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.
@@EMG/10 - Enric Martínez Gomàriz 314

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.

@@EMG/10 - Enric Martínez Gomàriz 315
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.

@@EMG/10 - Enric Martínez Gomàriz 316
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:

@@EMG/10 - Enric Martínez Gomàriz 317
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
@@EMG/10 - Enric Martínez Gomàriz 318
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
@@EMG/10 - Enric Martínez Gomàriz 319
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:

O Identificar funciones, obtenida en las etapas de análisis y diseño tecnológico.
O Distribuirlas identificando servicios.
O Integrarlas.
O 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.

@@EMG/10 - Enric Martínez Gomàriz 320
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.

@@EMG/10 - Enric Martínez Gomàriz 321
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.

@@EMG/10 - Enric Martínez Gomàriz 322
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.

@@EMG/10 - Enric Martínez Gomàriz 323
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
@@EMG/10 - Enric Martínez Gomàriz 324
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.

Tomar
Respuesta
Llamada
Pasar
Petición
Servidor
de Trabajo
Tomar
Respuesta
Llamada
Servidor
de Trabajo
R
R
Solución 1
Solución 1
Solución 2
Solución 2

Figura 216. Arquitectura de una llamada asíncrona a
través de una vía lenta.
@@EMG/10 - Enric Martínez Gomàriz 325
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
Venta
Productos
Productos
Cuentas Clientes
Clientes
Albaranes
Albarán

Figura 217. SI para la Venta de Productos en Delegaciones
Pedido en Curso
Servir
Pedido
Albaranes Local
Registro
Pedido
Cliente
Clientes
Cuentas Clientes
Albarán
Productos
Enviar
Albaranes
a la Central
Albaranes Centra

Figura 218. Primer Refinamiento
@@EMG/10 - Enric Martínez Gomàriz 326
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
Verificar
Crédito
Registro
Productos
Pedido
Cliente
Clientes
Cuentas Clientes
Productos
Identificación
Cliente
Leer
Datos
Cliente
Aviso
al
Cliente
No hay Crédito

Figura 219. Refinamiento de Registro de Pedido
Pedido en Curso
Imprimir
Albarán
Albaranes
Preparar
Entrega
Albarán
Acumular
Albaranes



Figura 220. Refinamiento de Servir Pedido
@@EMG/10 - Enric Martínez Gomàriz 327

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
Servir
Pedido
Albaranes Local
Registro
Pedido
Cliente
Clientes
Cuentas Clientes
Albarán
Productos
Anotar
Envío
Albaranes
Albaranes Central
Servidor
de correo
R
Incorporar
a BD
corporativa

Figura 221. Arquitectura Distribuida del primer refinamiento
Respuesta
Tomar
Crédito
Clientes
Cuentas Clientes
Leer
Datos
Cliente
Código Cliente en Petición

Figura 222. Refinamiento del Servidor para Leer los Datos del
Cliente
@@EMG/10 - Enric Martínez Gomàriz 328
Pedido en Curso
Tomar
Datos
Cliente
Registro
Productos
Pedido
Cliente
Productos
Identificación
Cliente
Pedir
Datos
Cliente
Aviso
al
Cliente
No hay Crédito
Verificar
Credito
Pasar
Petición a
la Central
Leer
Datos
Cliente
R

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:

O El modelo de comunicación entre cada servicio y sus clientes. Agrupa.
O Tipo de comunicación.
O Formato del mensaje
O Las relaciones entre los servicios, reflejada en la tipología de la arquitectura
de servicios.
O Flujo de mensajes.
O La modalidad y el momento del arranque.
O La implementación de cada servicio.
Pedido en Curso
Pedir
Imprimir
Albarán
Albaranes
Preparar
Entrega
Albarán
Acumular
Albaranes
Impresión
Albarán

Figura 224. Arquitectura Distribuida de Servir
Pedido.
@@EMG/10 - Enric Martínez Gomàriz 329

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
@@EMG/10 - Enric Martínez Gomàriz 330
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.
@@EMG/10 - Enric Martínez Gomàriz 331

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:

@@EMG/10 - Enric Martínez Gomàriz 332
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
@@EMG/10 - Enric Martínez Gomàriz 333
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
@@EMG/10 - Enric Martínez Gomàriz 334
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
Clientes
Central
Cuenta
Analítica
Vuelos
Viajes
Comprados
por
Vuelos
por
Cliente
1
M
1
N
Corresponde a
Anotaciones
Cuenta
Analítica
1
M
Es movimiento de
Compañía
Servido por
M 1
Cliente
habitual
de
Tiendas
Relación
Tienda-
Cliente
N M
Plazas
Hotel
Hoteles
Habitación de
M
1

Figura 226. Esquema de datos modificado
@@EMG/10 - Enric Martínez Gomàriz 335
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.

Clientes
Central
Cuenta
Analítica
Vuelos
Viajes
Comprados
por
Vuelos
por
Cliente
1
M
1
N
Corresponde a
Anotaciones
Cuenta
Analítica
1
M
Es movimiento de
Compañía
Servido por
M 1
Cliente
habitual
de
Tiendas
Relación
Tienda-
Cliente
N M
Plazas
Hotel
Hoteles
Habitación de
M
1

Figura 227. Arquitectura de datos de la Central




Clientes
Tienda
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.

@@EMG/10 - Enric Martínez Gomàriz 336
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.
Acceder
a clientes
Central
Acceder
a cliente
local
Tomar
Datos
Cliente
Clientes local
El cliente
no
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.
@@EMG/10 - Enric Martínez Gomàriz 337
Alta
Cliente
Cliente
Clientes Local
Cuenta Cliente
Crédito Estándar
Clientes Central
Cliente por Tienda
Pedir
Datos
Cliente
Cliente
Clientes Local
Crédito Estándar
Incorporar
a Clientes
Local
Asignar
Crédito
Cuentas Cliente Clientes Central
Incorporar
a Clientes
Central
Incorporar
a Clientes
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
Registro
Datos
Cliente
Petición
Cliente
Acceso
Datos
Cliente
Registro
Datos
Viaje
Consulta
Cuenta
Cliente
Cuenta Clientes
Rechazar
Venta
Alta
Cliente
Clientes Central
Re-intentar
Crédito Estándar
No crédito
Clientes Local
Clientes por Tienda
No existe Cliente
Sin hotel

Figura 1. Entrada de la Petición modificada.
@@EMG/10 - Enric Martínez Gomàriz 338
Petición Cliente
Actualiza
reserva
c.aérea
Datos Compañía Aérea
Cuenta Clientes
Anotación
Cuenta
Cliente
Vuelos por Cliente
Anotación
del vuelo por
Cliente
Aviso
al
Cliente
Anular
Venta
Re-intentar
Cliente
No hay plazas
Hay plazas
Clientes por Tienda
Anotación
Fecha
Operación
Actualiza
datos
hotel
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ón
Clientes
del Local
Clientes Central
Clientes Local
Clientes por Tienda
Enviar
a la
Tienda
Replica Clientes Local
Tiendas Calendario de Fiestas

Figura 232. Nuevo Proceso de Replicación de Clientes
@@EMG/10 - Enric Martínez Gomàriz 339

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.

@@EMG/10 - Enric Martínez Gomàriz 340
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.

@@EMG/10 - Enric Martínez Gomàriz 341
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.
@@EMG/10 - Enric Martínez Gomàriz 342
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.

@@EMG/10 - Enric Martínez Gomàriz 343
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ón
Reserva
Reserva
Cliente
Servidor de
Impresos
WORD
Pregunta
Impresión
Correcta
Repetir
Formularios
Eliminación
Histórica
Peticiones
Fecha

Figura 233. Proceso de impresión de la reserva del cliente
Leer
Clientes en
la Central
Pre-C
Actualizar
Venta
Clientes
en la Central
Cola
Clientes

Figura 234. Precondición en la gestión del Crédito de
Cliente
@@EMG/10 - Enric Martínez Gomàriz 344
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
Coger
Crédito
Coger
Datos
Cliente
Clientes Central
Preparar
respuesta
Coger
Petición
Actualizar
Clientes en
la Central
Cuenta Cliente
Parámetros
Cola
Clientes
Pre-C
S
o
l
o

C
r
é
d
i
t
o
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
Anotación
Cuenta
Cliente
Vuelos por Cliente
Anotación
del vuelo
por Cliente
Anotación
fecha
Operación
Clientes por Tienda
Colocar
respuesta
Coger
Petición
Cola
Clientes

Figura 235. Servidor de Actualizar Datos de Cliente en la Central
@@EMG/10 - Enric Martínez Gomàriz 345
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
Leer
Crédito
Cuenta Cliente
Coger
Peticiones
del Cliente
Verificar si
hay cambios
Pendientes
Cambiar
Prioridad
Actualización Pendiente
Cliente (Parámetro)
Cambios Saldo Pendientes
Cola
Clientes
Hay Actualizaciones Pendientes
Sin Actualizaciones Pendientes

Figura 237. Refinamiento del servidor de lectura del crédito.
Clientes local
Leer
Datos
Cliente
Clientes central
R
Leer Datos
Clientes en
la Central
Cuentas Clientes
Cola
Clientes
Actualizar
Clientes en
la Central
Pre-C

Figura 238. Solución A para la arquitectura del
servidor de Leer Datos del Cliente
en el servidor de la Tienda.
@@EMG/10 - Enric Martínez Gomàriz 346

º 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
Leer
Datos
Cliente
Clientes central
Leer
Crédito
del Cliente
Cuentas Clientes
Acceso a
Clientes en
la Central
Leer datos
Clientes en
la Central
R
R
Cola
Clientes
R
Actualizar
Clientes en
la Central
Pre-C

Figura 239. Solución A para la arquitectura del
servidor de Leer Datos del Cliente
en el servidor de la Tienda.
@@EMG/10 - Enric Martínez Gomàriz 347

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.
Pedir
cliente
Central
Acceder
a cliente
local
Tomar
Datos
Cliente
Clientes local
Colocar
en
respuesta
No existe
cliente en local
El cliente
existe en local
No existe
cliente en
Central
El cliente existe
en la Central
Respuesta
Clientes central
Leer Datos
Cliente en
la Central
Cola
Clientes
Petición: Código Cliente
Cuentas Clientes
R
Tomar
Datos
Cliente
Tomar
Cré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
Incorporar
a Clientes
Central
Parámetro: Datos Cliente
Asignar
Crédito
Crédito estándar
Incorporar
a Clientes
por Tienda
Clientes por Tienda

Figura 241. Arquitectura del servidor de Alta de Clientes
en la Central.
@@EMG/10 - Enric Martínez Gomàriz 348
Cliente
Petición Cliente
Registro
Datos
Viaje
Petición
Cliente
Acceso
Datos
Cliente
Registro
Datos
Cliente
Verificar
Crédito
Cliente
Rechazar
Venta
Alta
Cliente
Re-intentar
No crédito
Leer Datos
Cliente
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
Registrar
Datos
Vuelo
Registro
Datos
Hotel
Datos Compañía Aérea
Consultar
Datos de
Vuelos
Consultar
Datos
Hoteles
Datos Hotel
Sin hotel
No hay
habitaciones
Cliente
Consultar
Datos
Hoteles
Acabar
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.
@@EMG/10 - Enric Martínez Gomàriz 349


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
Actualiza
Reserva
C.Aérea
Anotar
en la
Central
No hay plazas
Actualizar
Datos
Clientes en
la Central
R
Datos Compañía Aérea
RPC
Actualizar
Datos
Compañía
Aérea
R
Cola
Clientes
Actualiza
datos
hotel
Datos Hotel
R

Figura 244. Arquitectura del proceso de Actualización de Datos de
la Venta
Selección
Clientes
del Local
Clientes Central
Clientes Local
Clientes por Tienda
Generar
Replica
Replica Clientes
Tiendas Calendario de Fiestas
Colocar
en
Cola
Servidor
de correo
R
Replica Clientes

Figura 245. Arquitectura del proceso de Replicación de Clientes
@@EMG/10 - Enric Martínez Gomàriz 350

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.

@@EMG/10 - Enric Martínez Gomàriz 351
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
Servicios
Internos
R
R
P
P
P

Figura 246. Arquitectura del proceso de Actualización de Datos
de la Venta
@@EMG/10 - Enric Martínez Gomàriz 352
Venta de Vuelos en
Delegaciones
Proceso de Ventas Estadísticas
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 vuelo Datos 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.

@@EMG/10 - Enric Martínez Gomàriz 353
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.


@@EMG/10 - Enric Martínez Gomàriz 354
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ón
Planificació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:

O Área de planificación, destinada a definir los criterios de gestión del sistema
distribuido. Incluye:
O 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.
O La planificación de las estrategias de acuerdo con las políticas de
negocio de la empresa o empresas afectadas.
O Área de gestión y control, desde donde se gestiona el día a día.
O Á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.
O Área de análisis, donde se analiza los resultados obtenidos y se proponen
las mejoras. Incluye, básicamente dos aspectos:
O Análisis de rendimientos, para ayudar a la gestión del día a día.
O 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
@@EMG/10 - Enric Martínez Gomàriz 355
compañía. Sirve de realimentación en la planificación de las estrategias
con la propuesta de las mejoras.
O 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..
O Área de Costes.
O Donde hay que identificar y automatizar trabajos y tareas intensivas
en tiempo.
O Área de soporte a usuarios.
O Á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:
O Recolección de la información.
O Inventario de activos.
O 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
@@EMG/10 - Enric Martínez Gomàriz 356

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
@@EMG/10 - Enric Martínez Gomàriz 357
• 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.

@@EMG/10 - Enric Martínez Gomàriz 358
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

@@EMG/10 - Enric Martínez Gomàriz 359
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:

O 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.
@@EMG/10 - Enric Martínez Gomàriz 360
O Definir el nivel de servicio y de asistencia, en particular delimitar horarios y
condiciones de servicio.
O Definir las estrategias técnicas de inclusión de los nuevos elementos o de los
cambios que se realizan.
O 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:
O La información de proporcionada por el análisis de la gestión.
O La propuesta de los centros de administración tras el análisis de
rendimientos.
O La evolución de la tecnología.
O 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:

O Definir las políticas de administración.
O Definir las estrategias de administración.
O Definir las operativas estándares.
O Definir la plataforma estándar.
O Definir las plataformas de las aplicaciones distribuidas junto a los
responsables de aplicación.
O Pactar y aprobar el contrato de servicio.
O 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,
@@EMG/10 - Enric Martínez Gomàriz 361
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:

O Gestión de versiones.
O Comparación de esquemas.
O Nivelación de esos esquemas.
O Marcha atrás.
O Sincronización de datos.
O Recuperar datos.
O Integridad física.
O Replicación y todos sus factores.
O 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.
@@EMG/10 - Enric Martínez Gomàriz 362

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:

O La dispersión geográfica y, a veces, horaria.
O El número de usuarios.
O La heterogeneidad de sus perfiles y formación.
@@EMG/10 - Enric Martínez Gomàriz 363
O La variedad de sus aplicaciones.
O 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:

O De qué se da soporte.
O Dónde se da ese soporte.
O Quien lo da.
O Cuándo se da.
O 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
CASD
CSSD
Local
CASD
Vendedores
Especialistas
de producto
Especialistas
Informáticos
Usuario
Avanzado

Figura 250. Organización operativa del soporte a usuarios.
@@EMG/10 - Enric Martínez Gomàriz 364

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
@@EMG/10 - Enric Martínez Gomàriz 365
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).
@@EMG/10 - Enric Martínez Gomàriz 366
º 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:
@@EMG/10 - Enric Martínez Gomàriz 367

º 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.

@@EMG/10 - Enric Martínez Gomàriz 368
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:

O Monitoring o recolección de información.
O Medir.
O Recoger las mediciones (recolectar en el argot).
O Transformarla.
O Integrar la información centralizándola en el archivo único.
O Catalogación por temas.
O Archivar en el repositorio de administración.
O Inventario de activos.
O 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.

@@EMG/10 - Enric Martínez Gomàriz 369
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.

@@EMG/10 - Enric Martínez Gomàriz 370
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
@@EMG/10 - Enric Martínez Gomàriz 371
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:

O Recursos de inventario automático.
O Facturas de compra y/o servicio.
O 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:

O Inventario de activos.
O Catalogo de servicios.
O Aplicaciones.
O Datos de rendimiento
O 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.

@@EMG/10 - Enric Martínez Gomàriz 372
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
Contratos
Pactos de nivel de Servicio
Indicadores del nivel de
servicio pactado
Área de Administración
Medida de los Indicadores del
nivel de servicio pactado
Auditoria Externa
Comparación para el
seguimiento del nivel de
servicio pactado

Figura 251. Auditoría de los procesos de Outsourcing.
@@EMG/10 - Enric Martínez Gomàriz 373
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:

O Costes directos por la infraestructura asignada para uso exclusivo.
O Prorrateo de la infraestructura compartida.
O Por el consumo dinámico:
O Transacciones.
O 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.

O 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.
O Errores de operativa. Afectan básicamente al área del usuario y los
programas cliente. Llevan a detectar:
O Fallos de formación, que pueden aconsejar acciones formativas
globales.
O Fallos de operativa de detectes operativas poco robustas que hay que
mejorar.
O 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:
@@EMG/10 - Enric Martínez Gomàriz 374

O Planificación de procesos y servicios.
O Automatización de eventos.
O Planificación y gestión de cambios y configuraciones. En particular la
administración de las fichas de enviroment de los servicios.
O Gestión de problemas.
O Gestión de recursos de almacenamiento.
O Gestión de activos y directorios.
O 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
@@EMG/10 - Enric Martínez Gomàriz 375
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.
@@EMG/10 - Enric Martínez Gomàriz 376
· 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
@@EMG/10 - Enric Martínez Gomàriz 377
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.

@@EMG/10 - Enric Martínez Gomàriz 378
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:

O Delegar totalmente conduce al fracaso ya que es poco tiempo no hay dos
plataformas iguales.
O 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:

O Estandarización controlada de la plataforma mediante la definición de una
plataforma estándar.
O Delimitación de responsabilidades con el usuario.
O 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:

O Llevar un inventario fiable y referenciado de los servidores, normalmente
dentro del repositorio de administración.
O 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.
O Potenciar y conocer la ficha de enviromente del servidor.
O Posibilidad de gestión remota.


20. Gestión remota y desatendida de clientes y servidores.

@@EMG/10 - Enric Martínez Gomàriz 379
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:

O Procesos de checking automáticos.
O Log’s de trabajo.
O 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:

O Cuando la máquina arranca, se accede al nivel de ocupación del disco.
O Si la ocupación es superior a la máxima de alerta, se envía un mensaje de
aviso al CASD.
O 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í.

@@EMG/10 - Enric Martínez Gomàriz 380
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.

@@EMG/10 - Enric Martínez Gomàriz 381
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:

@@EMG/10 - Enric Martínez Gomàriz 382
O Catalogación, Instalación y Configuración.
O Gestión del estado (status).
O Estudio del rendimiento (perfomance).
O Soporte a usuario.

Y abarcar cinco áreas:

O Clientes
O Servidores.
O Conectividad
O Middleware.
O 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
C
o
n
f
i
g
u
r
a
c
i
ó
n
S
t
a
t
u
s
P
e
r
f
o
m
a
n
c
e
S
o
p
o
r
t
e

Figura 252. Clasificación de las
actividades de
administración
@@EMG/10 - Enric Martínez Gomàriz 383
Diseño de Administración
Diseño
Consistencia
Funciones de
DSM
Identificar lo que falta
Diseño e
Implementación
Plan de
Integración
Monitoring
Definir funciones
Diseño e
Implementación
Procesos
intensivos en
tiempo
Identificación
Diseño e
Implementación
Cuadro de
mandos
Cuadro de mandos
para el seguimiento
del negocio
Diseño e
Implementación
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.

@@EMG/10 - Enric Martínez Gomàriz 384
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.

@@EMG/10 - Enric Martínez Gomàriz 385
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:

O Presentar diferentes estrategias para aquellas actividades que tienen un
tratamiento claramente diferencial dentro de un entorno distribuido.
O 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:

O Que el cliente back-ground acceda directamente al repositorio.
O 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.
@@EMG/10 - Enric Martínez Gomàriz 386


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.

@@EMG/10 - Enric Martínez Gomàriz 387
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.

@@EMG/10 - Enric Martínez Gomàriz 388
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
@@EMG/10 - Enric Martínez Gomàriz 389
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
@@EMG/10 - Enric Martínez Gomàriz 390
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.
@@EMG/10 - Enric Martínez Gomàriz 391
º 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
@@EMG/10 - Enric Martínez Gomàriz 392
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
Información de
usuario
Usuario
Información
Departamental
Información
temporal de
usuario
Proceso para incluir la
información deusuario
en el entorno
departamental
Proceso de
generación de la
copia de seguridad

Figura 255. Back-up de usuario sobre entorno departamental
Información
Departamental
Local
CASD
Información
de usuario
Usuario
Información
de usuario
Usuario
Ticket de
control

Figura 256. Back-up Departamental

Figura 257. Formato del ticket de control de un
back-up departamental
@@EMG/10 - Enric Martínez Gomàriz 393
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.
Información
Departamental
centralizada
Central
CASD
Información
depertamental
Información
departamental
Local
CASD

Figura 258. Back-up departamental centralizad