DissenyoAplicacionesDistribuidas EnricMartinez

Enric Martnez Gomriz
Diseo de Sistemas
Distribuidos
@EMG/10 Enric Martnez Gomriz 2

Parte 2 Diseo de
Aplicaciones Distribuidas
@EMG/10 Enric Martnez Gomriz

3
Presentacin

Como ya se dijo en la presentacin de la primera parte, esta segunda parte est dedicada
especficamente al diseo 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
habrn de utilizar personas y que se deber administrar desde una visin unificada
lo ms eficiente y econmicamente posible.

Todo proceso negocio y unidad de informacin debe presentarse como un servicio.
Todo el sistema se construir como integracin de servicios. Y todo lo ya existente
(legancy) se integrar tambin como servicios.

Y los servicios debern ser transparentes, a la plataforma y a su implementacin,
reutilizables y permitir su integracin con otros servicios.

Ese debe ser el objetivo de cualquier curso de diseo distribuido.

Est segunda parte est estructurada en los siguientes bloques:

- Diseo de componentes individuales.
- Arquitectura y comunicacin de servidores.
- Revisin de los conceptos de Ingeniera de Software necesarios.
- Desarrollo de la metodologa de diseo de aplicaciones distribuidas.
- Diseo de Interfcies Grficas.
- Reingeniera 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 da me cans de trabajar intilmente
actualizando la imagen a cada cambio de versin del sistema operativo.

@@EMG/10 - Enric Martnez Gomriz 4
Condicionamientos de organizacin.

1. Introduccin.

A causa de la propia naturaleza de las aplicaciones distribuidas, en todas las
instalaciones en las que deben disearse y utilizarse, existen condicionamientos de
organizacin, no necesariamente informticos, que deben conocerse y, dentro de lo
posible, controlar por su influencia indirecta en el diseo.

Estos condicionamientos suponen puntos de heterogeneidad y/o precondiciones
al diseo y actan, la mayora de las veces, como corss de los cuales no se puede
huir y que incluso imposibilitan soluciones tcnicamente mejores de las que
finalmente se pueden implementar.

Dentro de esta relacin pueden incluirse temas como la unificacin de los
estndares de informtica, la dispersin de formatos y contenidos de la informacin
que la aplicacin distribuida va a integrar, la heterogeneidad de las operativas y
circuitos organizativos, la codificacin heredada, los condicionantes de idioma, el
estado de animo del personal, etc.

En este captulo se incluyen comentarios y reflexiones sobre algunos de ellos. El
objetivo no es tanto estudiarlos, ya que son, en su mayora, muy intuitivos, sino
poner en alerta al diseador para detectarlos en fase de anlisis de requerimientos
y no en la de arranque cuando sus consecuencias pueden inutilizar parte del
sistema informtico diseado o poner al diseo en graves apuros.

Algunos de estos condicionamientos estarn reflejados en el Plan Estratgico de la
compaa pero otros son ambientales o transitorios.

Este capitulo incluye alguno de los ms habituales, pero no intenta ser en ningn
caso exhaustivo ya que gran cantidad de ellos solo estn presentes en unas pocas
organizaciones. He intentado incluir uno de cada tipo para que Vd. vea diferentes
fuentes.

2. Los estndares de la plataforma.

Hardware, sistemas operativos, Middleware, modelos de aplicaciones, modelos de
soporte a usuarios, etc.

La fuente es el Plan Estratgico de la Compaa. Si no existe, le recomiendo
documentarlos.

3. El estndar ofimtico

Las posibilidades de los paquetes ofimticos 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 increbles.

Hoy da, para disear un sistema integrado debe utilizarse a fondo la ofimtica de la
Compaa. Para conseguir que el entorno ofimtico sea adems operativo y eficaz
es fundamental que est unificado en toda la organizacin.

Esta unificacin no pasa solo por un paquete nico para todos, cosa que el Sr.
Gates ya ha conseguido prcticamente en todos los sitios, sino tambin por
establecer configuraciones y plantillas estndar dentro de cada elemento del
paquete. Y establecer recomendaciones de trabajo comunes.

El paquete ofimtico debe disponer como mnimo de procesador de textos, hoja de
clculo, paquete de grficos y paquete de presentaciones. Es altamente
recomendable disponer tambin de un paquete de gestin de bases de datos, tipo
Access por ejemplo.

La Compaa ha de formar a los usuarios actuales y futuros en la utilizacin fluida y
habitual de los recursos ofimticos. Los cursos o seminarios de formacin deben
incluir la distribucin de la operativa estndar y de las recomendaciones de trabajo
comunes. Por esa razn, por las actividades de formacin han de pasar, no slo los
usuarios noveles, si no tambin aquellos que ya usan habitualmente los paquetes
ofimticos. Obviamente, en este segundo caso la actividad de formacin debe
reducirse a la operativa y las recomendaciones de trabajo.

En mi opinin, el usuario ha de ser autnomo en su trabajo ofimtico que no debe
ser soportado por el Dpto. de Informtica ya que esa carga colapsara cualquier
soporte al resto de aplicaciones.

4. La unificacin de la ofimtica.

Puede ser que dentro del proceso de integracin de la ofimtica, inevitable dentro
de la creacin de un entorno distribuido, se produzca la incorporacin de usuarios
que estn trabajando con entornos ofimticos diferentes al que se ha cogido como
estndar en la Compaa. O, utilizando el mismo paquete, por unificacin de
operativas y formularios.

Aunque por la presin de MS Office la mayora 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, sltese este apartado.

La integracin de estos usuarios en el entorno estndar comn 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. Explqueles, sin embargo, que con la etapa de
integracin, a la cual le est obligando, ganar integracin de su informacin
con la del resto de la Compaa. Podr distribuir y recibir ms 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 sensacin 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
adaptacin de estos documentos a los nuevos formatos pueden llegar a
necesitar muchos meses de trabajo, meses de los que nadie dispondr.

No confe 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 ms problemas
como si los generar de nuevo.

Olvdese de la solucin de subcontratar la adaptacin. La persona externa a la
que subcontrate necesitar ms tiempo para entender que pretende cada
documento que para generarlo. La experiencia del da a da me ha convencido
que la adaptacin de un documento generado por un usuario ha de ser
realizado por el mismo usuario.

Puede parecer que hemos llegado a un callejn sin salida. Sera as, si la
experiencia de muchos procesos de integracin de este tipo, no confirme que
slo un porcentaje nfimo de los documentos generados por un usuario de
ofimtica son reutilizados. Se sorprender de cuan pequeo es.

As pues la solucin emprica 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. Recomindele que empiece a trabajar en los
documentos nuevos con el nuevo entorno y que recicle los antiguos slo
cuando reutilice.

Pasado ese periodo desinstale el paquete antiguo. Es la nica forma de obligar
al cambio: habr usuarios que se habrn mantenido fieles a los antiguos
paquetes y que slo en los ltimos das, y ante la eminencia del cambio
empezarn a trabajar con el nuevo entono. Gurdese 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, sobrnele! Hgale la
adaptacin de los documentos usted mismo. Y si tiene tiempo, aplique la
misma medicina a tantos altos cargos como pueda. Adems de hacer mritos,
conseguir sus aliados ms 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 solucin a los usuarios
afectados y de conseguir que se sientan apoyados en todo momento.

5. La dispersin de formatos y contenidos.

La dispersin 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 informacin impresa como en las presentaciones
de pantalla. Es un problema que escapa del entorno informtico 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 dispersin de contenidos. Por ejemplo,
en una reunin de ventas los jefes regionales se presentan con contenidos tan
diversos como una representacin grfica de las ventas por semanas y una hoja de
clculo con las ventas por das. Va ha ser muy difcil comparar. El problema puede
agravarse adems si pone al descubierto la existencia de recursos diferente segn
los usuarios: los agravios comparativos pueden ser graves.

Todo ello conlleva a reflexionar sobre la problemtica de la dispersin de
contenidos y formatos.

5. 1. Imposicin o libertad.

Los dos extremos son malos:

El formato nico es una utopa.
La libertad llevar a la anarqua.

La solucin depende la organizacin y de la actividad de la Compaa ya que
estos factores condicionarn la informacin a compartir.

Es muy difcil dar criterios genricos pero si le quiero transmitir consejos
empricos consecuencia de mi experiencia:

Actuar nada ms en el mbito de la informacin compartida...
Pactar la mximo los contenidos y conseguir que al final una autoridad
jerrquica superior los apadrine.
Aconsejar formatos y decidir, como mnimo, el tipo de presentacin, en
particular si es grfica o no.
Proponer plantillas que se controlarn, desarrollarn y distribuirn de
forma centralizada.

6. Unidad de versin.

Mantenga siempre la misma versin 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 tensin y, al final, prdidas
econmicas directas o indirectas.

Aqu tendr siempre fuertes presiones ya que usuarios avanzados presionarn a
los jefes comunes sobre lo obsoleto de su versin y lo que se estn perdiendo no
utilizando la nueva. Este ltimo argumento, con muy honrosas excepciones, es una
falacia: la inmensa mayora de los usuarios, todos en muchos casos, van ha utilizar
las mismas opciones que utilizaban en la antigua versin cuando pasen a la nueva.

Subir versin no es ninguna tontera. Los PCs han de estar preparados (todos
sabemos los aumentos de hardware que muchas subidas de versin suponen), el
personal de soporte preparado, los usuarios formados y los estndares
documentales de la compaa adaptados.

Y las nuevas versiones se han de comprar. Adems quizs el cambio de versin del
paquete ofimtico le obligue al cambio de versin del sistema operativo con lo que
su problema ser doble. Es fcil que el coste econmico de todo ello sea
sorprendentemente alto.

Mustrese firme. Los problemas van a ser suyos no de los usuarios crticos.
Cambie cuando el retorno de la inversin este justificado; y siempre de forma
planificada.

Por desgracia, puede que las circunstancias le obliguen: el proveedor
descatalogar su versin, 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
obligacin de adelantarse y no dejarse sorprender.

7. Necesidad de Multidioma.

Las aplicaciones distribuidas afectan cada vez ms a personas que utilizan idiomas
diferentes y a las que hay que integrar en el funcionamiento comn.

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 debera ser un condicionante de diseo.

Y recuerde que el multidioma es de tres tipos:

De literales en los componentes de presentacin.
De contenidos de base de datos.
De formato de presentacin de los campos: nmero 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 codificacin histrica heredada.

Es frecuente que los nuevos sistemas distribuidos que va a aprender a disear
sustituyan o complementan a otros antiguos en los cuales las principales entidades
de la compaa (clientes, productos, etc.) ya tengan un cdigo dentro de una
codificacin "de siempre".

Estos cdigos, si son antiguos, tendrn una semntica condensada, es decir, sern
cortos y dentro del cdigo estarn atributos de clasificacin (familia, grupo, zona,
etc.). Es ms que probable que lo que convenga es recodificar.

Llegado a este punto, Houston, tenemos un problema! Adems grave. Porque el
problema no se reduce a cambiar el fichero maestro, sino que podemos tener una
coleccin de problemas de muy difcil gestin. Puede escogerlos entre el siguiente
men:

O Ampliacin 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 clasificacin dentro del cdigo como
atributos independientes para poderlos gestionar bien en las bases de datos.
O Que hacer con la informacin histrica: reconvertir cdigos, eliminar a partir
de una fecha, etc.
O Convencer a todos los usuarios de la necesidad del cambio.
O Pactar los nuevos cdigos.
O Repasar todos los programas (todos!) de la instalacin, probarlos y mantener
un tiempo el cambio.
O Planificacin del transitorio (que no le pase nada...)
O Y un amplio etc. tan largo como quiera.

Que hacer? Recodificar siempre. Cmo hacerlo? No hay, desgraciadamente
ninguna solucin mgica. No le darn tiempo desde Direccin ya que el trabajo no
aporta valor aadido, segn ellos, claro est. Pero le pedirn los resultados como si
ya hubiera hecho el cambio. Crame, lo he vivido varias veces. En fin, siento traer
malas noticias, pero tiene un gravsimo problema si est en esta situacin.

Dentro del apartado de codificacin existe otro problema que si puede controlar: la
necesidad de codificacin distribuida segn como sea el modelo de datos final.

Este tema esta muy relacionado con replicacin y mantenimiento distribuido y lo
trataremos especficamente ms adelante.

9. Otros condicionamientos de datos.

9. 1. Las obligaciones de la empresa respecto a la Ley de proteccin de
datos.

Segn el grado de seguimiento a que la organizacin usuaria de la aplicacin
este obligada, puede condicionar muchas cosas.

Si le dice que pase de ella, obtenga un documento por escrito de esa
decisin.

9. 2. Necesidad de registro.

Es decir, la obligacin de registrar en todos (raro) o algunos nodos (ms
habitual) el intercambio de documentos o interfaces. A cada operacin de
estrada o salida registrada habr que asignar un nmero certificado y una
descripcin completa.

Es el concepto equivalente al registro de la administracin pblica de la que
todos hemos sido en algn momento usuarios.

Es un problema equivalente, informticamente hablando, a la codificacin
distribuida.

10. El factor humano.

Y por encima de todo tenemos personas, nuestros sufridos y tiranos compaeros
de viaje.

Aqu tendr tres bloques de condicionantes:

10. 1. El estado anmico de la organizacin.

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

Resistencia al cambio para castigar a la Direccin. Esta actitud ser
frecuente su sistema de informacin llega a franquicias, en empresas con
problemas o en aquellas en que la nueva aplicacin amenaza puestos de
trabajo...
Que el usuario pase de la nueva aplicacin 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 informtico 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 informtico los lleva
implcitos, se ahogan.

Obviamente, no los va a cambiar a todos. Lo mejor que puede hacer es:

Establecer operativas sencillas y robustas.
Formarlos, tcnica y anmicamente, minimizando sus miedos.

La formacin y la mejora de las operativas tiene una influencia directa: ms
coste de proyecto. Habr de negociarlo.

10. 3. La resistencia al cambio.

Aqu si puede hacer muchsimo, y con poco coste:

Permita que los usuarios opinen en fase de anlisis. A parte que
mejorar su trabajo, se implicaran en el proyecto.
Djeles participar activamente en las pruebas.
Apyelos y motvelos en el arranque.

11. Una reflexin final.

El contenido de este captulo puede producir, en usted lector, dos efectos extremos:
desolacin o pasotismo. Por favor, no caiga ni en uno ni en otro extremo. No
menosprecie el problema pero tampoco se colapse. Estdielo y busque una
solucin correcta a los problemas que resulten de ese estudio. Pero en cualquier
caso siga mi consejo y no lo ignore.

Componentes Operacionales

1. Qu es un componente operacional?

En los diseos distribuidos existen elementos de utilizacin sistemtica y repetitiva
que implementan operativas de funcionamiento siempre necesarias en un buen
diseo. Son los componentes operacionales.

En este capitulo se van a presentar algunos de los ms importantes y utilizados.

2. Porqu usar componentes operacionales?

Si los componentes operacionales se usan siempre, la propuesta se hace obvia:
construymoslos 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 diseo de nuevas aplicaciones y la explotacin de las ya
creadas.

2. 2. Unificar criterios de diseo y administracin.

Todos los actores del sistema de informacin, personas y programas, trabajan
con los mismos criterios, marcados por el comportamiento tipificado en la
especificacin.

2. 3. Bajar costes de desarrollo.

La reutilizacin permite bajar de forma notabilsima el coste de desarrollo,
puesta en marcha y formacin. La reutilizacin de componentes operacionales
no es ms que una aplicacin prctica del concepto de reutilizacin.

2. 4. Estn probados.

O al menos confe en ello.....

No menosprecie esta gran ventaja, no solo por la comodidad sino por la
disminucin de tiempo de desarrollo que supone. Si trabaja con tiempos
pequeos, las desviaciones en los esfuerzos y plazos de entrega (nuestro
verdadero cncer...) sern menos visibles. Un 25% de 4 das es un da, nadie
lo notar. Un 25% de 4 semanas es una semana, todo el mundo le preguntar
que pasa..... Y es sabido que los retrasos llaman a gritos a los retrasos.

3. Limites.

Pero recuerde que todo tiene ventajas e inconvenientes. La reutilizacin tambin.

Si Vd. es un habitual de la reutilizacin ya lo sabe. Pero si no lo es recuerde que si
Vd. construye componentes operacionales ha de ser generoso: ha de disearlos
potentes, robustos... y fiables.

Pero no caiga el gravsimo error de querer crear el componente operacional
universal y perfecto. La perfeccin no existe en ingeniera y acercarse a ella es
carsimo. Pasado el punto optimo, cualquier generalizacin se hace costosa y de
dudosa reutilizacin 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 intuicin (o eso
espero). Si consigue una forma de calcularlo racionalmente, por favor, llmeme
rpidamente a cobro revertido. Su idea bien valdr que yo pague la llamada.

4. Una clasificacin.

Hay varios tipos de componentes operacionales en funcin de su nivel y funcin.

O Componentes especializados o de primer nivel. Normalmente se integran en
el flujo de proceso como servicios sncronos o asncronos, ya sea pasivos, en
fase de link del clientes, o dinmicos como servidores independientes.
Implementan servicios de:
O De lgica presentacin.
O De lgica de datos.
O De lgica de negocio.
O De control de procesos.
O Componentes de gestin o Framework o componentes de segundo nivel, que
implementan:
O Procesos de gestin, como un mantenimiento estndar de tablas o una
gestin 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 estn ms dirigidos a la implementacin
que al diseo. Vamos a hablar aqu, principalmente de aquellos que hacen
referencia a este ltimo apartado.

5. Componentes operacionales ms importantes en el diseo.

Como ya hemos dicho, los componentes operacionales pueden disearse para
infinidad de funciones. Este captulo podra 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 diseo en todos los sistemas distribuidos importantes
en los que he participado.

Adems, los utilizar dentro de la metodologa propuesta en los captulos de diseo
y en los ejemplos propuestos. Me facilitarn el trabajo y les ayudarn a ver su
utilidad.

Son componentes operacionales habituales:

O Componentes de control de procesos.
O Semforos.
O Colas.
O Ticket.
O Agentes operacionales:
O Servidores de Impresin
O Servidor de Correo.
O Servidor de Notas y Avisos.
O El cartero.
O Viga.
O Disparador.
O Cargador, etc.

Se incluye a continuacin la especificacin 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 captulo siguiente.

Se proporcionan tambin algunas ideas sobre su implementacin aunque, como he
repetido varias veces, este no es un libro de programacin sino de diseo.

6. Tecnologa de implementacin de Componentes Operacionales.

No se lo piense. Utilice tcnicas de Orientacin a Objetos (OO) o como mnimo
Tipos Abstractos de Datos (TAD). Los servicios proporcionados por el componente
se integrarn en mtodos (OO) u operaciones (TAD).

Encapsule los atributos con mtodos.

7. Modelos de integracin de componentes operacionales de primer
nivel.

Existen dos formar de integrar componentes operacionales de primer nivel en las
aplicaciones distribuidas:

7. 1. Esttica.

Con el programa, normalmente un servidor o un agente, en fase de link. Este
modelo es en la prctica 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 implementacin esttica sea poco eficiente,
puede ser la solucin vlida en un diseo. Adems, las tcnicas 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 gestin del
componente operacional.

7. 2. Dinmica.

Montando el componente como un servidor independiente.

Este modelo, de mayor coste tecnolgico, permite autonoma y accesibilidad
total. Prmelo.

8. Semforos.

8. 1. Qu es un semforo.

Un semforo es un componente operacional que puede estar en dos o tres
estados. Su nombre responde a su paralelismo con la luces de trfico.

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

Un semforo se representar en adelante por los
smbolos de la figura.

Sus estados se referenciarn como rojo y verde en
semforos de dos estados y como rojo, amarillo y
verde. Para mantener el paralelismo con los
semforos de nuestra vas pblicas, el estado de
rojo se suele reservar para ocupado (no
disponibilidad) y el verde para libre (disponible).

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

8. 2. Uso de los semforos

Un semforo es un componente operacional utilizado para determinar la
disponibilidad y/o estado de una situacin 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
haban de compartirse entre diferentes actores de la arquitectura C/S
distribuida.

Con la evolucin de las aplicaciones distribuidas, la integracin y gestin de la
disponibilidad de estos recursos la ha asumido el Middleware y los semforos
han limitado prcticamente su mbito de actuacin a la determinacin de
estados.

Por ejemplo, un semforo ser til para saber si una conexin est disponible o
no. As, si al acceder a un nodo del sistema distribuido se encuentra que la
conexin ha cado, todos los recursos localizados en ese nodo habrn dejado
de estar disponibles. La aplicacin activar un semforo de forma que esa
informacin sea conocida por todos los actores de sistema distribuido. Cada
actor actuar en consecuencia con la situacin y su especializacin. Cuando
alcance el captulo de anlisis de consistencia encontrar ejemplos de
aplicacin de semforos.

8. 3. Servicios habituales.

Los servicios habituales en un semforo son:

Figura 1. Representacin
de semforos

Inicializacin. Cuando instance el objeto, coloque como estado inicial
rojo. El paso a verde deber ser una operacin plenamente consciente,
realizada (evidentemente) justo despus de la instalacin.
Colocar color.
La pregunta: cual es tu estado?

8. 4. Semforos con etiqueta.

En muchas ocasiones no basta con saber si un semforo est ocupado o no.
Es necesario saber tambin quien lo ocupa.

En este caso utilice la tcnica de ocupacin personalizada en la cual el estado
de rojo lleva asociado tres atributos:

Referencia del ocupante, normalmente, en entornos de comunicacin
cliente / servidor, la del cliente o servidor.
Hora en que se ha realizado la reserva.
Tiempo mximo de reserva.

La existencia de estos dos atributos le permitir mucho juego. Por ejemplo le
permitir aplicar procesos de recuperacin del tipo:

Si un semforo 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 semforo recibe una reserva de un cliente que ya lo est
reservando le dar entrada asumiendo que es una recuperacin.
Si el elemento que ha hecho la reserva cae, no realizar la liberacin y
por tanto el recurso puede quedar eternamente ocupado. La presencia
de los atributos hora de reserva y tiempo mximo de reserva permiten,
transcurrido el tiempo mximo de reserva, que el semforo se auto libere
automticamente.

Si se usa el atributo de referencia del elemento que realiza la reserva, este dato
se incluye en la peticin de reserva del semforo. Cuando el semforo da la
respuesta de que est ocupado, puede devolver la referencia del elemento que
lo esta haciendo y el tiempo mximo 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 realizacin.

A medida que vaya resolviendo los asuntos de la lista ira colocando una marca
sobre la gestin que ya ha realizado. En todo momento la lista le dar
informacin de qu ha hecho y de qu no y sabr que ha acabado en el
momento que todas las lneas de la lista tengan su correspondiente marca.

El componente operacional Ticket en el mundo de las aplicaciones distribuidas
no es ni ms ni menos, que eso.

9. 2. Un nombre desafortunado?

Cuando despus 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 gestin de
puestos de venta al pblico 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 hablbamos. Todava hoy no
entiendo como no cambi el nombre. Hoy da tengo tanta documentacin 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 diseo distribuido para tres
funciones bsicas:

9.3.1. Conocer es estado de cada proceso.

Si se ha realizado y como ha acabado.

9.3.2. Coordinar lgica de ejecucin de procesos.

Los diferentes procesos consultarn el ticket y segn los estados que
encuentren ejecutarn 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
captulo dedicado a back-up.
En general, el uso habitual de los tickets es el control de la lgica de la parte
cliente de la aplicacin distribuida

9. 4. Elementos fundamentales de un ticket.

Los tickets van a ser representados en todo
este trabajo con el smbolo de la parte
superior de la figura de la izquierda.

Conviene programar un componente ticket
lo ms general posible lo que da pie a
intentar analizar que puede haber de comn
a diferentes tickets.

Un ticket puede ser visto como una rejilla
en que la primera columna representa las
Situacin Estados
X
X
X
X

Figura 2. Representacin de
un Ticket
diferentes situaciones o procesos a controlar y el resto codifican los
diferentes atributos. Dentro de las casillas se codifican los estados que se
ligan a cada situacin.

Las situaciones se referencian por un cdigo y se le aade una descripcin.

Los estados pueden ser de:

Dos posiciones: hecho o no hecho
Evolutivos, siendo modificados a medida que las evolucin de los
procesos avanza. As por ejemplo, una posicin del estado podra indicar
que no se ha iniciado todava 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
errneamente.

9. 5. Servicios habituales.

Son servicios habituales en un ticket:

9.5.1. Estructurales.

Aadir una nueva situacin.
Borrar una situacin existente.
Aadir una nueva columna de estado incluyendo sus limitaciones
de valor
Borrar un estado existente.

9.5.2. De gestin.

Consultar un estado de una situacin.
Modificar un estado de una situacin. El ticket comprobar la
integridad del nuevo estado con los valores proporcionados en la
definicin 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 estn a un
valor determinado.

10. Tickets multihoja.

10. 1. Qu es un ticket multihoja?

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

Es decir, un ticket multihoja no es ms que
un ticket con ms de una ocurrencia
simultnea.

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

10. 2. Organizacin de un ticket multihoja.

Un ticket multihoja tiene dos partes:

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

En los mtodos de gestin hay que incorporar esa referencia de hoja.

10. 3. Mtodos adicionales para tratar los tickets multihoja.


Crear una hoja.
Destruir una hoja.

10.3.2. Gestin.

Verificacin 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 ms 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
Las aplicaciones distribuidas bien diseadas deberan hacer un monumento a
las colas. No se concibe una aplicacin distribuida multicliente sin su
existencia, claramente manifiesta a escondida en el Middleware.

Las colas, que representaremos con el
elemento de la figura, se utilizarn para
colocar en espera peticiones de los clientes a
los servidores.

Las colas marcan, pues, una frontera pactada
entre unos elementos que colocan peticiones
(orgenes) y otros que las procesan (destinos).
La finalidad de las colas es muy precisa pero
como veremos ms adelante esta llena de matices interesantsimos.

Muchas veces son utilizadas tambin como deposito intermedio de
informacin.

11. 3. Utilizar colas de Middleware o crear colas propias?

Como usted amigo lector ya ha deducido, me declaro un fan apasionado y
fantico del Middleware. Pero hasta eso tiene excepciones. Para mi las colas
es uno de los casos ms claros. Compare las prestaciones de las MOM
(Message Oriented Middleware) implementacin de las colas en el Middleware
con las prestaciones de una cola que yo deseo tener en mis diseos y que le
propondr a continuacin. No olvide, adems, la poca estandarizacin real del
Middleware MOM. Y, finalmente, crese su propia opinin.

Adems las colas es un componente agradecido: con poco esfuerzo puede
crear objetos cola muy generales y con muchsimas prestaciones.

11. 4. Estructura bsica de una cola.

Una cola est formada por un conjunto de anotaciones que se recuperan en el
mismo orden que han sido anotadas. Cada anotacin recoge un mensaje,
peticin + 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 funcin de la cola sino de los programas que anotan
las peticiones y proporcionan las respuestas.

La experiencia confirma lo que el sentido comn indica: es posible implementar
un componente cola independiente del formato de la anotacin.

Para ello basta observar que todas las anotaciones de cualquier cola tienen
unos atributos comunes (referencia, fecha y hora de la anotacin, etc.) que
determinan claramente la anotacin y otra parte, de longitud variable, que
depende del mensaje pero que es transparente a la cola en si misma.

Disee y programe su componente cola as:

Unos atributos bsicos y una zona sin formato de longitud opcional.

de una cola
Instance su objeto cola para cada caso con los atributos bsicos y
proporcione una longitud adicional variable para contener los mensajes
en funcin del diseo.

Un slo objeto cola le permitir cubrir todos los casos.

11. 5. Atributos bsicos de una cola.

En lo que resta de captulo y para facilitar la comprensin se referir como
cliente al programa que anota la peticin del servicio y como servidor el
programa que proporciona la respuesta. Ms adelante se ver que en la
posicin del cliente puede estar otro servidor o un agente (cosa habitual) y que
en la posicin del servidor puede haber un cliente (cosa sin embargo no
habitual) o un agente.

Tambin se hablar genricamente 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 mnimo los siguientes
atributos:

11.5.1. Referencia de la anotacin.

Ser responsabilidad de la cola. Deber tener dos partes: un
identificador de la cola y un nmero secuencial. Es la referencia comn
que utilizaran todos los elementos involucrados en la comunicacin.

11.5.2. Destino (servicio).

Normalmente la referencia lgica del servicio. La proporciona el cliente.
Es la referencia del servicio. Permitir colocar en una misma cola
anotaciones para ms de un servicio. Esta opcin puede permitirle
hacer aplicaciones ms compactas y rpidas.

11.5.3. Servidor o agente que la atiende.

Se coloca cuando el proveedor del servicio se hace cargo de la peticin.
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 tambin un identificador del
cliente y un nmero secuencial.

11.5.6. Referencia del servidor o agente.

Ser responsabilidad del proveedor del servicio. Tendr tambin un
identificador del proveedor y un nmero secuencial.

11.5.7. Fechas y horas.

Incluya:

Fecha y hora de la anotacin. 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 peticin.
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 captacin de la respuesta. Es quizs 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 diseo adelantar si
es necesaria la ejecucin de peticiones.

No haga una prioridad demasiado amplia. Normalmente basa con un
dgito de 0 a 9. Haga lo lgico, que 9 sea la ms prioridad ms alta. Y
no abuse en su uso.

11.5.9. Estado.

Codifique como mnimo 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 anotacin 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 eliminacin de la anotacin.

Guardar las anotaciones de la cola un cierto tiempo puede ser til a los
responsables de su administracin para analizar situaciones histricas.
Las anotaciones guardadas asumen el rol de un loging.

Si se necesita esta posibilidad, para gestionarla se necesita introducir
dos atributos:

Tiempo que la anotacin ha de permanecer en la cola.
Forma de eliminacin (inmediata, diferida, etc.)

11.5.12. Longitud del mensaje.

Longitud til de la zona del mensaje. Opcional y solo de inters para
minimizar los tiempos de administracin de la cola eliminado la gestin
de la parte del mensaje no utilizada en cada caso.

11. 6. Dinmica de las referencias.

Las referencias se gestionan dinmicamente en paralelo con la gestin de cada
anotacin. En la figura se muestra la dinmica de referencias habitual.
Veremos ms delante que esta dinmica es fundamental en la gestin de
temas tan importantes como el diseo de la consistencia.

Cuando el cliente solicite
al servidor la anotacin
de un mensaje
proporcionar su
referencia de cliente. La
cola, una vez anotado el
mensaje, devolver,
adems de la referencia
del cliente, la referencia
asignada a la anotacin
en la cola.

El cliente utilizar esa
referencia de anotacin
para cualquier operacin
posterior que necesite
realizar con su mensaje.

La referencia del
proveedor del servicio la
asigna ste cuando pide una anotacin a la cola para gestionar. La conoce el
cliente de forma esttica o la obtiene de forma dinmica en la respuesta a la
anotacin.

Intercambie en todos los dilogos la doble referencia, cliente y anotacin, ya
que as podr garantizar en todo momento la integridad, seguridad y fiabilidad
del dilogo.

11. 7. Recomendaciones de implementacin.

Defina una cola genrica con el comportamiento bsico.
Si lo necesita, derive del comportamiento bsico comportamientos
especializados.
Siempre que pueda implemente con OO. El comportamiento bsico se
encapsular en un objeto y utilizando herencia y polimorfismo obtendr
fcilmente los comportamientos especializados.
Organice, como ya hemos comentado, la anotacin en dos partes:
Datos comunes bsicos: referencias, fechas, estados, prioridades,
calificadores,........
.
Cliente
Proveedor del
Servicio
Peticin de anotacin
Referencia del cliente
1
Aceptacin de anotacin
Referencias de cliente y de anotacin
2
Peticin de una anotacin
Referencia Proveedor
3
Asignacin de una anotacin
Referencia de proveedor y de
anotacin.
4

Figura 5. Dinmica de referencias
Zona de mensaje, que ser especifica de cada servicio.

11. 8. Formas de implementacin: persistencia y organizacin interna.

Las colas pueden ser persistentes o no persistentes. Una cola es persistente
cuando las anotaciones se mantienen permanentemente cualquiera que sea la
evolucin de la explotacin.

La persistencia de una cola se dice que es totalmente tolerante a fallos, full
tolerance, si la coherencia de la cola se mantiene an en el caso de averas
de la plataforma y cadas de los servidores.

La persistencia de una cola obliga a grabarlas sobre disco, normalmente como
un fichero.

La ocupacin de una cola es bsicamente el resultado de multiplicar el
nmero mximo de apuntes que se quiere permitir por la longitud de cada
anotacin. Siempre que sea posible, y normalmente hoy da lo es, debe
montarse parcialmente sobre memoria (continuacin 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 nmero de anotacin.

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 tcnica especial. A continuacin le propongo una que me ha
demostrado ser muy eficaz.

11. 9. Implementacin parcial sobre memoria.

Para conseguir eficacia en la implementacin de la cola de gran nmero de
anotaciones deber combinar tcnicas 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 adems ser la situacin ms habitual, que las anotaciones no
se eliminen secuencialmente. Ello le impedir montar colas circulares.

Una buena solucin puede ser:

Organice un fichero de acceso directo sobre disco, dimensionado para el
nmero mximo de registros que desee en la cola.
A la anotacin en el fichero se le aaden:
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 bsicos de acceso al
apunte, nmero de anotacin, fechas y horas, prioridad y calificador
como mnimo. Un puntero apuntar al registro fsico asignado a la
anotacin en el fichero de acceso directo.
Ocupacin del fichero de acceso directo en disco donde existir una
marca por cada fichero fsico 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 fsico de la anotacin en el fichero se determinar sobre la
zona ocupacin. El registro fsico asignado se colocar en la anotacin
correspondiente de la zona de ocupacin. Se modificarn
adecuadamente los cursores que apuntan a la anotacin anterior y
siguiente.
Se distinguirn dos operaciones diferentes: la baja (simple cambio de
estado) y la eliminacin del la anotacin.
Cuando se elimine la anotacin, se compactar la zona de cabecera, se
marcar el registro fsico como libre en la zona de ocupacin y no se
alterar ni eliminar el registro fsico (lo nico que sera realmente lento)
y se modificarn adecuadamente los cursores de los registros
correspondientes a las anotaciones anterior y posterior.
Cuando se cierre la cola o se produzca algn fin anormal, se perdern las
zonas de memoria pero se garantizar la persistencia con un ndice de
fiabilidad suficiente.
Cuando se inicialice la cola, se habrn de regenerar las zonas de
memoria.
Finalmente, la cola deber incorporar un mtodo para compactar la cola
peridicamente o por peticin.

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

11. 10. Mtodos del comportamiento bsico.

Son servicios habituales en una cola:


Instanciar una cola para una longitud de mensaje determinada.

11.10.2. De gestin.

Insertar una nueva anotacin.
Borrar una anotacin.
Modificar una anotacin.
Cambiar el estado de una anotacin (opcional, puede usarse el
mtodo anterior).
Consultar una anotacin por referencia de anotacin.
Consultar el estado de una anotacin (opcional, puede usarse el
mtodo anterior).
Seguimiento secuencial:
Situar primera anotacin.
Leer la siguiente anotacin: devuelve como parmetro fin de cola
cuando no quedan apuntes.

11.10.3. Tratamiento de la persistencia.

Cargar la cola en memoria.
Descargar la cola (slo en algunas implementaciones, no en las
implementadas parcialmente en memoria).
Compactar la cola (slo en colas implementadas parcialmente
sobre memoria).

Los mtodos de consulta y recorrido de la cola estn 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 ms de un origen, es una obviedad.

Que sea multiservidor, es decir que admita anotaciones para ms de un
servidor o destino, una prestacin muy til que se implementa muy fcilmente.

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 ms de una copia
simultnea 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 inters:

O Aumentar el rendimiento.
O Adaptar la oferta a la demanda; cuando
hay ms demanda se arrancan
automtica o manualmente ms hilos.

Pero, como tambin es muy obvio, un servidor multihebrado no es nada fcil de
programar. Los problemas de concurrencia y paralelismo estallan en toda su
intensidad.

Afortunadamente muchos lenguajes actuales ponen a su disposicin recursos
para conseguirla de forma muy cmoda. Pero no se confunda: esas tcnicas le
ayudarn mucho pero no le eliminarn totalmente los problemas del
paralelismo y de la concurrencia. Si no es experto en esos temas, valrese
seriamente no usarlas. O aprenda. Es muy divertido.

De cualquier forma, este apartado no es ms que un compendio de temas
tratados anteriormente.

12. Las colas como servidores.

Como ya le he dicho, las colas han de ser compartidas por ms de un cliente y,
opcionalmente, ms de un servidor simultneamente. Por ejemplo, un cliente
Destinos
Orgenes

Figura 6. Colas multicliente y
multiservidor
necesita saber si un servidor ya ha acabado de procesar su peticin de servicio
mientras que otro necesita la cola para anotar una nueva peticin.

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 ms de un programa. La nica solucin
viable es convertir la cola en un servidor autnomo
que pueden atender las necesidades de informacin y gestin de los clientes y
servidores mientras estos trabajan asncronamente. Una cola implementada como
servidor se representar por el elemento de la figura.

La comunicacin de los clientes y los servidores con el servidor de cola se
resolver con un mecanismo de middleware sncrono. A ser posible hay que utilizar
un servicio estndar 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
diseo de un proceso de replicacin asncrona y en caliente del contenido de una
base de datos.

Datos a Incorporar
Servidor
de
Replicacin
Ficheros
Pendientes
Cadena
Batch de
Incorporacin
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 utilizacin de un servidor de cola: Anotacin y Replicacin asncrona

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 informacin a las bases de datos corporativas y crea una
replica generando una anotacin en una cola de ficheros pendientes de
incorporar.

Nombre y
Funcin del
Servidor de
Cola

Figura 7. Servidor de
Cola
Un servidor de replicacin incorpora la informacin a la base de datos replicada de
forma totalmente asncrona. El proceso del HOST puede ser nocturno y el servidor
de replicacin arrancarse por la maana cuando empiece la jornada laboral normal.

El servidor de replicacin anota en un ticket multihoja los ficheros incorporados.

Observe la existencia de un programa cliente para la gestin y administracin de la
cola por el Administrador y de un programa de consulta del ticket para que los
usuarios puedan saber si la informacin esta ya cargada o no.

La implementacin 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 genrico. La imagen de la figura corresponde a
un ticket multihoja de una aplicacin de incorporaciones a una BD replicada y
sumarizada. Los tickets de esta aplicacin se estructuran por aplicaciones
(ESTADIST) y por mbitos (DIARIA, MENSUAL). Las referencias son los archivos
incorporar. Cada hoja del ticket tiene todos los das del mes. Una rejilla da
informacin de que hay incorporado. Jugando con colores se puede informar del
estado de la incorporacin de cada archivo y da.

En la siguiente figura puede observar que aspecto puede tener un programa de
personificacin de una cola:


Figura 10. Parametrizacin 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 gestin de una anotacin de cola
con opcin a realizar anotaciones manuales:


13. Servidores de Impresin.

Los servidores de impresin independizan las
impresoras de los programas permitiendo que sean
compartidas de forma transparente a sus
caractersticas y localizacin.

Esta prestacin, que para usted es una obviedad, era
un proceso complejo en las primeras aplicaciones
C/S.

Se implementan siempre con los servidores de impresin de la red o de los
Mainframe y / o mquinas intermedias, como es el caso de UNIX, AS/400, etc.

La gestin de los servidores de impresin tiene una operativa muy estandarizada
que se va asumir aqu de la forma natural que Vd. utiliza cada da.

Si no la conoce puede consultar documentacin especializada o consultar el
captulo dedicado a la administracin del sistema.

Componentes Operacionales
implementados por Agentes

1. El Viga y el Disparador.

Es frecuente en comunicacin asncrona, especialmente si es desacoplada, que
servidor o cliente destinatario de la peticin de servicio sea avisado para que
despierte o se active y haga su trabajo.

Figura 12. Gestin de la anotacin en una cola

Figura 13. Servidor de
Impresin
Esta funcin puede conseguirse por:

O Eventos.
O Un Viga.

Qu es, pues un viga?

Un viga 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 viga puede escuchar de:

O Un directorio.
O Una cola.
O Un mail.
O Un semforo.
O Un ticket.
O Etc.

El viga realizar un ciclo de inspeccin y reposo
analizando si ha llegado un acontecimiento.

El viga lo representaremos por el icono de la figura.

Cuando es produzca el evento que el viga 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 vigas.

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 contine 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 diseado para entregar, tomar y
recibir informacin, normalmente ficheros,
intercambiada entre usuarios y programas de
forma transparente al sistema, protocolo,
aplicacin o va.

Figura 14. Representaci
n del viga

n del
disparador

n del Servidor
de Correo
El estudio a fondo de un servidor de correo dentro de una formacin de diseo
distribuido es interesante no slo por si mismo, si no tambin porque ayuda a
entender algunas de las caractersticas fundamentales de este tipo de diseos.

3. Caractersticas bsicas de un servidor de correo.

Las caractersticas bsicas deseables en un servidor de correo son:

1. Independencia de la plataforma y la infraestructura.
2. Posibilidad de una gran nmero de vas de conexin y abierto a implementar
de forma cmoda nuevas vas.
3. Posibilidad de iniciar la transmisin desde el origen o desde el destino segn
convenga.
4. Gran facilidad de uso.
5. Posibilidad de arrancada manual, planificada o desde otros programas.
6. Auto correccin de errores segn parmetros. En particular debe incluir
reintentos y posibilidad de reiniciar la transmisin desde el punto en que ha
cado.
7. Posibilidad de gestin configuracin y gestin de errores centralizada.
8. Recursos para garantizar la integridad de la informacin y la seguridad de
acceso contra usuarios no autorizados.
9. Posibilidad de caminos de ms 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 caractersticas se irn presentando y ampliando a lo largo del presente
captulo.

4. Arquitectura del servidor de correo.

La plataforma se organiza
en nodos donde se sitan
los programas y usuarios
origen y destino de los
intercambios. Lgicamente
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
sitan 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 bsica de un servidor de correo.

Nodos y distribuidores estn conectados entre si por vas o canales de
comunicacin. As pueden ser vas de intercambio: la red local, la red conmutada
de telfonos, protocolos del tipo X25, Internet e Intranet, SNA, IPX, TCP/IP, FDDI,
ATM, etc.

Entre los nodos puede existir ms de una va de conexin. 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 conexin donde se informa del primer nodo a visitar para llegar al
destino. El nodo origen enva 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
enva al usuario de su nodo que constituye el ltimo punto de destino. Sino es para
l, consulta en su tabla de conexin a que nodo ha de enviar el transporte para
alcanzar el nodo destino y le enva el transporte.

Evidentemente, todo el proceso es automtico, desatendido y con tolerancia total a
fallos.

Una solucin 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 va de gran capacidad de trfico entre los dos distribuidores. Una va
alternativa de seguridad entre dos usuarios situados uno en cada ciudad puede
establecerse a travs de una conexin por directa por red conmutada entre los dos
nodos.

Lgicamente las vas de seguridad slo se establecern entre los nodos en los
cuales haya usuarios que por su funcin dentro del sistema distribuido no pueden
quedar aislados.

Observe, finalmente, que el servidor de correo es un servicio simtrico, es decir, en
cada nodo debe existir un servidor de correo que recibir o canalizar el trfico de
su propio nodo.

5. Operativa bsica de un servidor de correo.

Como debera de
funcionar un servidor
de correo? El
funcionamiento bsico
se esquematiza en la
figura.

En cada nodo se
arranca una instancia
del servidor de correo.

Cada servidor tiene
una lista de anotacin
y un buzn donde se
deja el fichero a
transportar.
Normalmente la implementacin del buzn y la lista es una cola de distribucin.

Cuando, en funcin de los parmetros de envo, se inicia la transmisin, el servidor
localiza la va por la que debe de enviar el mensaje. Cada va se encapsula en un
router que es el que utiliza el servidor para la salida del mensaje. Disponer de
nuevas vas no supone ms 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 distribucin, de donde puede ser recuperado por el usuario destino.
Evidentemente, si el camino de transporte incluye ms de un nodo, el servidor
realiza la operativa de reexpedicin explicada en el apartado anterior.

La anotacin puede ser de dos formas:

O Anotacin directa a travs de un programa especializado que incluye el
servidor de correo.
O Anotacin desde un programa cliente a travs de APIs.

El inicio puede ser:

O Manual.
O Automtico e inmediato.
O Planificado. Por ejemplo, cada hora.

Existen tres funcionamientos bsicos:

5. 1. Envo.

El cliente realiza la anotacin y entrega el fichero.

5. 2. Recepcin.

El cliente anota una peticin de recepcin. El servidor queda a la espera de la
llegada.

Inicio Directo
Arrancada
planificada
APLICACIN
Comunicacin
de aplicacin
Servidor
ORIGEN
R
U
T
E
R
VIES
TCP/IP
Telfono
Internet
X25,X28,X32
TCP/IP
+ SOAP
IPX
SNA
FDDI, TAM
etc ....
R
U
T
E
R
Servidor
DESTNO
APLICACIN
ERRORES
ERRORES
Administracin
del sistema

Figura 18. Funcionamiento bsico de un Servidor de
Correo
5. 3. Captura.

El cliente anota una peticin de captura de un fichero de otro nodo. El servidor
de su nodo enva una peticin al servidor del nodo origen. Este inicia el envo.
Evidentemente el cliente origen ha de haber anotado el fichero. Sino es as,
servidor del nodo origen devuelve una condicin de error. El servidor destino
repetir la peticin segn sus condiciones de parametrizacin.

La gestin de errores se explicar ms tarde. Solamente citemos aqu que despus
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 parametrizacin.

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 vas de
comunicacin 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 distribucin.
O Informar los parmetros de
auto correccin.
O Y un largo etc.

7. Posibilidades de administracin.

Las posibilidades que el servidor de correo debe dar al administrador del sistema
distribuido para personificar y administrar el sistema son:

O Codificar las vas de salida de que dispone cada elemento de la plataforma.
O Identificar a cada usuario por un cdigo.
O Permitir asignar permisos de acceso a cada usuario.
O Escoger las vas de acceso, principal y alternativas, entre cada nodo / usuario
que estn autorizados a comunicarse. Cada camino puede ser directo o a
travs de otros nodos.
O Poder definir por cada destino el nmero de reintentos a realizar y los criterios
de gestin automtica de errores.
O Definir los parmetros de la cola de distribucin.
O Cuando cambie una va entre dos nodos todos los usuarios afectados deben
quedar automticamente 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
___ conexin normal
___ conexin alternativa

Figura 19. Posibilidades de parametrizacin de un
Servidor de Correo
O Si se utiliza la opcin de control centralizado de errores, se habr de definir el
funcionamiento de la opcin para cada mensaje.
O Limitar las posibilidades de funcionamiento para cada usuario en funcin de
sus necesidades y derechos en el sistema distribuido.
O Y otro largo etc.

8. Caractersticas del transporte.

Como ya se ha visto el transporte tiene dos partes, la anotacin y el contenido.

El contenido es un fichero del cual el Servidor de Correo no necesita conocer nada
ms que el path de origen y el de destino.

En cuanto al formato de la anotacin, si se recuerda que normalmente se trata de la
anotacin en una cola, no hace falta nada ms que repasar en el captulo anterior
como es el formato de una anotacin en una cola. Adems del origen y del destino,
atributos como prioridad y calificador son de gran inters en un servidor de correo.
En especial, el calificador, que permite identificar dentro de cada usuario destinos
particulares, se ha revelado de gran inters 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.

Adems de las prestaciones normales de un servidor de correo, de las que solo se
necesita la opcin de envo, se necesita la opcin de, en el momento de la entrega,
poder interrumpir al usuario si la urgencia del mensaje as lo requiere.

La implementacin 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
opcin de incluir un mensaje en el fichero.

A efectos de diseo conviene diferenciar el servidor de correo del de notas y avisos
ya que su funcin 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 inters para ambos tipos de
servidores.

Los servidores de notas y avisos son fundamentales
en las aplicaciones distribuidas desatendidas.
Imagine que tiene una conexin desatendida, va

Figura 20. Representacin del
servidor de Notas y
Avisos
FTP, con un proveedor, Por ella este ltimo le enva los albaranes. Usted necesita
atender los albaranes tan pronto lleguen para tener su stock al da.

Para resolver esta problemtica montaramos un proceso desatendido que
estuviera escuchando al va FTP. Cuando llegarn los albaranes se procesaran
automticamente y, mediante el servidor de avisos, se notificara al responsable del
proceso de la llegada.

Puede extender el proceso a la recepcin de las facturas. El proceso de
conformacin se puede disparar tambin automticamente a la recepcin de la
factura electrnica 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 inspeccin automtica y de la ocupacin de disco de un nodo
y generar con el servidor de notas y avisos un mensaje al administrador de sistema
cuando la ocupacin 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 sistemticamente el servidor
de notas y avisos y que se encarga de repartir un aviso a una lista de usuarios de
forma automtica.

Necesita:

O La gua de usuarios donde esta la direccin 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 finalizacin de procesos Bach, etc. Suele incluirse una
especializacin de funcin que permite afinar el envo. La especializacin
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 relacin funciones-usuarios interesados.
O El buzn, donde los programas dejan los mensajes.

La arquitectura del cartero suele ser:

O Programas GUIs para mantener:
O La gua de usuarios,
O Las funciones.
O Las relaciones entre funciones y usuarios.
O APIs de Middleware para colocar los avisos en el buzn del cartero.

El funcionamiento es:

O Los programas que lo necesitan preparan el mensaje y lo colocan en el buzn
con una referencia de funcin.
O El cartero averigua a partir de la relacin entre funcin 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 gestin de los
usuarios queda independiente de los programas y pasa
a ser una funcin de administracin.

El cartero se implementa habitualmente como un agente
y lo representaremos por la imagen de la figura.

Otra opcin es utilizar la el middleware de publicacin /
suscripcin si existe en la plataforma distribuida.

11. Gestin de errores en un servidor de correo.

La gestin de errores en un servidor de correo es fundamental ya que su cualidad
bsica ha de ser la full tolerance.

La calidad de un ser servidor de correo en este apartado puede medirse en dos
dimensiones:

11. 1. Recuperacin de errores.

Ha de ser automtica y flexible. Cuando se inicia una transferencia, ya sea en
origen o destino, si el otro lado no contesta se realizarn de forma automtica
un nmero de reintentos de transmisin espaciados en un tiempo de
espera entre reintentos de transmisin. Si en uno de ellos se recupera la
conexin, sta se reinicia y continua normalmente en el punto en que se haba
quedado sin repetir lo que ya se haba transmitido. El usuario ni lo notar.
Como mucho, si el nmero de reintentos es alto, puede llegar a notar que la
transmisin ha durado ms 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 conexin se
reiniciar otro bloque de un nmero de reintentos de conexin. Si hay
recuperacin, la transmisin se reiniciar desde donde se haba quedado, no
repitiendo en ningn caso lo que ya se haba transmitido. Si pasados estos
reintentos no ha sido posible tampoco la recuperacin se dar aviso de avera.

La implementacin de los tiempos de espera entre reintentos de conexin
puede ser:

Lineal. La espera entre reintento y reintento es siempre la misma.
Progresiva. La distancia entre reintentos se alarga en funcin del
nmero de reintentos hasta un tope mximo a partir del cual es ya lineal.
La progresin puede ser a su vez:
Geomtrica.
Escalada. Un ejemplo para un servidor de correo puede ser:
30 segundos para el primero. Se intenta solventar errores de
transmisin puntuales.
2 minutos para el segundo. Se intenta salvar una congestin.

n del cartero
4 reintentos de 30 minutos. Se intenta recuperar cadas por
avera del transportista.
Espera de 8 horas y reinicio del ciclo. Se intenta recuperar
averas de la plataforma.

Si los nodos origen y destino tiene una conexin por va alternativa, todo el
proceso se reintentar por ella.

Si la opcin de loging est activada todas las incidencias ocurridas sern
registradas.

Obviamente todos estos parmetros pueden ser personalizados esttica y
dinmicamente para cada nodo.

El diseo de la recuperacin de errores es genrico a todos los procesos
distribuidos variando en cada caso la poltica del tiempo de progresin.

Existe la posibilidad de establecer tipologas de estrategias que se pueden
cuantificar diferentemente en funcin 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
tipologa usuario.

Por ejemplo una espera de 3 minutos para un segundo intento para salvar la
congestin es vlida en un servidor de correo pero no en un servicio de
consulta cara al pblico. Habr que ajustarlo segn las necesidades de la
aplicacin y las caractersticas del servicio.

Por esa razn se recomienda colocar la parametrizacin de la gestin de
errores como parte de las posibilidades de configuracin del servicio y/o
cliente.

11. 2. Facilidad de localizacin y seguimiento.

El administrador del sistema tendr a su disposicin 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 informacin por nodo,
tipologa, frecuencia, etc.

El paquete estadstico consulta y anlisis de errores, basado en el
loging, puede ser un paquete proporcionado por el mismo diseador del
servidor de correo (integrado o no el modulo de seguimiento y anlisis
del que se habla ms 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 opcin de organizar un control centralizado de
errores de forma que toda la informacin de errores e incidencias se
enven a un punto de sistema distribuido donde hay un administrador.

Este control se organizar basado en la gestin jerrquica de errores
que se presenta a continuacin.

Esta opcin slo tiene inters en instalaciones muy grandes o en
aquellas en que en los puntos de origen y destino no tienen
administracin de sistema y la existencia de errores puede pasar
desapercibida.

11.2.3. Jerarqua de errores.

La clasificacin y calificacin de los errores es de inters tanto para el
loging como para el control centralizado.

Los errores se clasificarn en dos grupos: graves y incidencias. Dentro
de cada grupo a cada error se le asignar un cdigo.

A nivel de error, y basndose en el cdigo, 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 interrupcin slo se
aplicar a errores graves.

El administrador conocer la existencia de notas y avisos por un icono
en su pantalla de administracin.

Si se dispone de la especializacin como servidor de notas y avisos, el
envo al servicio centralizado lo utilizar.

11.2.4. Mdulo de seguimiento y anlisis.

Todas las posibilidades de consulta, seguimiento y gestin centralizada
pueden estar integradas en un mdulo de seguimiento y anlisis.

Las posibilidades de este mdulo son, como mnimo:

Seguimiento en tiempo real de errores con grabacin de loging y
envo de notificacin al control centralizado.
Estadsticas por pantalla y listado.
Herramientas de anlisis.
Utilizacin por usuarios y distribucin y control de costes.
Posibilidad de incorporar mdulos personificados por usuario segn
sus necesidades y organizacin.
Gestin de la seguridad.

12. Otras posibilidades.

Otras posibilidades deseables en un servidor de correo son:

O Compactar los datos para minimizar los tiempos de transmisin.
Fundamental.
O Encriptar los datos para evitar pinchazos.
O Posibilidad de arrancar ms de una instancia del servidor de correo en el
mismo nodo.
O Encapsulamiento de las vas que permita incorporar de nuevas de forma
cmoda.
O Posibilidades de planificacin que permitan minimizar costes. Por ejemplo,
transmisin nocturna si se utiliza red conmutada.
O Multidioma.

13. Semntica de comportamiento.

El servidor de correo ha de ser de ejecucin segura para garantizar que el trabajo
de transporte que se le delega se realiza siempre. En el captulo de consistencia
diremos que tiene una semntica de comportamiento exactamente una (Exactly
once). Olvdese de este concepto hasta entonces.

Sin embargo reflexionemos sobre que pasa con el fichero que transporta.

Si se ha hecho un envo 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, funcin que deber controlar el servidor de correo de destino.

Obviamente la responsabilidad de esta decisin no puede asumirla el servidor de
correo, que ha de devolver un cdigo 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 opcin
de destruir el contenido anterior o rechazar el encargo si ya existe.

Por defecto, los programas que encargan trabajo deberan presuponer que la
opcin de trabajo estndar 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 ms habituales son:

14. 1. Push.

El cliente anota en origen y el servidor de correo de origen inicia el envo segn
una poltica.

El push ha de ser multivia para poder lanzar ms de un envo simultneamente.

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 aplicacin. La entrega puede ser:
Planificada. La entrega se realiza en bloque con todo lo pendiente.
Por anotacin. 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 mltiples destinos, necesita un ancho de banda
importante para evitar la congestin en la salida o mquinas servidoras
especializadas.

14. 2. Recogida.

El destino inicia la comunicacin, mira si hay algo para l y lo recoge.
Aprovecha la opcin de captura del servidor de correo.

Puede ser:

Planificada.
Por necesidades de aplicacin, 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 comunicacin con poco ancho de banda.
Nmero alto de clientes.
Dispersin de horarios que impliquen que no hay conexin de plataforma
permanente.

14. 3. Notificacin.

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 notificacin se incluye informacin 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 viga.
Un evento convencional si hay una plataforma de eventos distribuida
(normalmente de objetos distribuidos)

14. 4. Oportunista.

Cuando el nodo remoto se conecta para pedir algn servicio, aprovecha para
preguntar si hay algo para l.

Suele incluirse, como parte de la respuesta del servicio pedido, una
notificacin, dedicada o general, de que hay alguna cosa para l.

15. Implementacin.

Las prestaciones de un servidor de correo, y su especializacin como servidor de
notas y avisos o cartero, constituyen un componente lgico compacto pero su
implementacin puede hacerse sobre ms de una producto. Si es as, la dispersin
de la implementacin ha de estar encapsulada de forma transparente a los
clientes.

Si hay dispersin de plataformas una forma cmoda de conseguir un servidor de
correo distribuible es el correo electrnico

Hay diferentes soluciones:

15. 1. Programacin propia.

Solo justificable en las condiciones mencionadas con anterioridad.

15.1.1. Aprovechar una plataforma de objetos distribuidos.

La opcin, de gran inters estratgico y cmoda de utilizar, tiene el
inconveniente de haber diversas plataformas posibles que pueden
utilizarse y que no sabemos si estarn en todos los nodos.

15.1.2. La plataforma TCP/IP + SOAP.

De gran eficiencia y generalizacin como transportista.

Sobre ella: se realizar aplicacin propia.
Se utilizar un paquete ya construido.

15.1.3. Basarse en los mdulos de gestin de mensajes del Middleware.

El servidor aprovechar las APIs del sistema para el uso de ese tipo de
Middleware. El esfuerzo de programacin es de cualquier forma notable.
El buzn y la lista de distribucin han de programarse siempre.

15.1.4. Aprovechar el mail.

Esta opcin es hoy da muy interesante por la amplitud e integracin
que Internet y los productos de Microsoft y Linux permiten. La lista de
distribucin y el buzn forma ya parte del mail y la posibilidad de atar
ficheros solventa el transporte.

Adems, cada da es mes global e integrado. Su inconveniente es que
hay que ligarse al producto de un fabricante y las limitaciones de
globalidad estn limitadas a las de ese producto.

15. 2. Aprovechar paquetes fabricados por terceros.

Aadiendo las opciones que se necesitan y que no tiene el paquete original.
Esta posibilidad es, de hecho, bastante utpica 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 exposicin ya le debe ser muy evidente el uso que puede hacer
de un buen servidor de correo y de su especializacin 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 programacin. Pero, si
su diseo necesita construir uno, no caiga en el error de programarlo sin las
prestaciones mnimas para ahorrar costes. No conseguir la tolerancia total ante
fallos y eso arruinar su proyecto. Adems la experiencia demuestra que un buen
servidor de correo crea adicin: cuanto ms se usa ms necesidades se
encuentran,... y mejor quedan sus aplicaciones distribuidas.

Finalmente otra obviedad: fabricar un servidor de correo slo se justifica en
topologas distribuidas heterogneas, globales o muy grandes.

La Comunicacin entre el Cliente y el
Servidor.

1. Introduccin.

Cliente y Servidor son dos programas. Como tales, para poder trabajar de forma
coordinada deben intercambiarse mensajes.

En este capitulo vamos a estudiar la tipologa bsica de esta comunicacin y los
modelos y vas ms frecuentes.

Veremos en este captulo que el diseo deber basarse en la tipologa y los
modelos.

2. Caractersticas de la comunicacin.

La comunicacin 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 filosofa cliente / servidor es
decir, a una mensaje de peticin 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, aadido a la determinacin clara de
responsabilidades, hace que el dilogo establecido se identifique con una
transaccin.

2. 3. No necesariamente sincronizada.

Ntese que, si el diseo no lo pide, las peticiones y respuestas no han de ser
necesariamente sincronizadas. De hecho, las comunicaciones sncronas y
asncronas conviven segn las necesidades de la aplicacin y las
especificaciones de los diversos tipos de comunicacin.

3. Tipos de comunicacin.

Hay tres tipos de comunicacin, dos de siempre, sncrona y asncrona, y eventos.

3. 1. Comunicacin sncrona.

Es un tipo de comunicacin,
caracterizado porque el cliente
lanza la peticin y espera, sin
hacer nada ms, la llegada de la
respuesta.

El servidor se comporta, a efectos
de programacin como una rutina
linkada dinmicamente.

La espera puede estar
determinada por la va de
comunicacin si sta es de
naturaleza sncrona, o bien
forzada por el programa si la va
de comunicacin es asncrona.

Cuando la comunicacin es
sncrona, el mensaje de respuesta
incluye un cdigo de retorno que
en caso de error da informacin 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 comunicacin asncrona que parece, a priori, tentadoramente
fcil de utilizar por su similitud con programacin convencional es la que
presenta ms problemas para tratar la cada del servidor.

En efecto, debido a la naturaleza sncrona de la comunicacin, el cliente est
esperando la respuesta. Si la va de comunicacin del Middleware que utiliza
lleva incorporado el control de cada del servidor, le devolver una condicin de
error en el cdigo de retorno que el programa podr tratar (deber tratar!!!)
para disparar los procesos de recuperacin.

Pero si el control de cada del servidor no est implementando en la va de
comunicacin, el programa cliente se colgar. En este caso, puede intentar
sistemas de timer para pasado el tiempo mximo de espera, si esta no ha
llegado, recuperar el programa. Sin embargo est solucin no es ninguna
trivialidad cuando se programa....

3. 2. Comunicacin asncrona.

En la comunicacin asncrona el cliente lanza la peticin 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 comunicacin tiene como prerrequisito que,
adems de la utilizacin de una va asncrona, que el servidor est diseado
Cliente
Servidor
Peticin
Respuesta

Figura 22. Esquema de comunicacin
sncrona.
para trabajar de forma asncrona. La utilizacin de una va asncrona no ser
garanta suficiente de buen funcionamiento si el servidor no est diseado
convenientemente.

Cualquier va asncrona puede ser
utilizada por el cliente de forma
sncrona. Basta que renuncie a
continuar trabajando tras enviar la
peticin y que se quede en un bucle
de peticin peridica de la
respuesta.

Note la diferencia fundamental entre
hacer comunicacin sncrona con
una va sncrona o hacerla con una
va asncrona; en el segundo caso el
cliente tiene control total de la cada
del servidor.

El cliente tiene que estar diseado
para no ser interrumpido cuando no
este preparado para recibir la
respuesta. Por esa razn, cualquier
va de comunicacin asncrona que
se precie debe proveer tres mecanismos:

Almacenamiento de las peticiones del cliente.
Almacenamiento de las respuestas del servidor.
Recuperacin voluntaria de la respuesta por parte del cliente

En cualquier caso, no utilice nunca la tcnica seguro que acabo
antes de que el servidor me entregue la respuesta. Habr
introducido una bomba dentro de su aplicacin. Si le cambian las
localizaciones de cliente y/o servidor a una mquina ms o menos
potente, puede irse todo el montaje al cuerno.

La utilizacin de tcnicas asncronas abre unas posibilidades inmensas que si
usted piensa como un diseador convencional nunca intuir. Fjese en la figura
superior. Observe todo los que puede hacer mientras el servidor est
procesando su peticin!

Imagnese que esta diseando una aplicacin de gestin de una delegacin 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 verificacin del cliente
se ha de hacer contra un ordenador corporativo remoto.

Si trabaja convencionalmente, har la secuencia: entrada del cliente,
verificacin del cliente y registro de los productos del pedido, que es, en
realidad, el proceso sobre el papel ms lento. A parte del tiempo necesario
para llamar al ordenador principal, enviar la peticin, recibir la respuesta y
cerrar la conexin.

Piense otra solucin aprovechando la disponibilidad de una va asncrona.
Cliente
Servidor
Peticin
Respuesta

Figura 23. Esquema de comunicacin
asncrona.

Disee un servidor de verificacin del cliente. Establezca una va de
comunicacin asncrona entre el cliente y ese servidor. Y cambie la secuencia
de trabajo: el programa pide el cdigo del cliente, lanza la peticin al servidor
de verificacin, contina 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
cuestin: 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 habra
perdido igual realizando la verificacin. Acostmbrese a una de las
caractersticas de un diseo distribuido: la necesidad de trabajar con
probabilidades a la hora de escoger soluciones. Normalmente, en la inmensa
mayora de los casos, podr venderle al cliente que esta verificando; si la
respuesta a la verificacin ms frecuente es que no, mejor cambie de negocio.

3. 3. Comunicacin por eventos.

Un evento, como Vd. ya sabe, es un acontecimiento o situacin que un
elemento, normalmente un objeto, enva a otro. Un gestor de eventos permite
que todo funcione correctamente. Un receptor slo es interrumpido para recibir
el evento cuando esta disponible.

La programacin por eventos es una tcnica de gran inters y potencia que
puso de moda la programacin de interfcies grficas de usuario.

Este no es un libro de programacin por eventos. En un curso de diseo C/S
slo interesan los eventos como va ms de comunicacin entre cliente y
servidor.

Bajo este prisma, yo opino que la comunicacin por eventos entre cliente y
servidor no es un tercer tipo de comunicacin, sino que es una va asncrona
ms; eso si de una potencia enorme. La tratar as. Ms adelante encontrar
mi propuesta de tratamiento desarrollada en profundidad.

4. Las diferentes vas de comunicacin

Las diferentes vas de comunicacin entre cliente y servidor han evolucionado a lo
largo de los aos y se han estandarizado con la aparicin del Middleware.

Vamos a realizar a continuacin una exposicin de las ms habituales y
estndares. En cada caso, adems de relacionar sus caractersticas principales, se
detallar si su naturaleza en sncrona o asncrona.

5. El modelo conversacional.

Ms que una va, la comunicacin conversacional entre cliente y servidor es una
modelo.

Recuerde que una relacin conversacional entre dos programas es un modelo de
comunicacin 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 va de
comunicacin conversacional la representaremos
por el smbolo de la figura.

Hablar aqu del principio conversacional parece una
contradiccin. La comunicacin 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 magnticas
en una instalacin y est
compartido entre dos pantallas
de atencin al pblico. El
operador de cada pantalla
deber saber si el grabador est
reservado a su estacin 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 semforo. Cada
programa cliente deber
reservarlo antes de permitir a su
operador pasar la tarjeta. El
modelo conversacional es ideal para resolver est situacin. Observe en la figura
como ira la comunicacin.

De hecho, si necesita una comunicacin de este tipo, auto impngase la disciplina
Cliente/Servidor. Realice la conversacin en slo cuatro pasos:

O Reserva del servidor.
O Mensaje de peticin de servicio.
O Mensaje de respuesta.
O Liberacin del servidor.

El modelo conversacional tiene algunas consideraciones adicionales:

O El comportamiento de diseo de la comunicacin conversacional en siempre
sncrona. Aunque observe que el modelo conversacional no lo exige.
O Una vez conectados cliente y servidor el efecto es como del de una conexin
punto a punto.
O El cliente ha de preocupar de los time-outs, seguimiento del dilogo y de la
desconexin final.

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

del modelo
conversacional.
Servidor
Cliente El cliente espera que el
semforo est libre
Servidor
Cliente El cliente encuentra el
semforo libre
Servidor
Cliente El cliente ocupa el servidor
poniendo el semforo en
rojo y pide y recibe del
servidor el servicio
Servidor
Cliente El cliente libera el
semforo
El segundo y el tercer paso pueden ser uno solo

Figura 25. Relacin conversacional entre cliente y servidor

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 da colocara uno en cada puesto de trabajo.
O Suplir con poco esfuerzo de programacin funciones que no existen en el
Middleware. Hoy da son difciles de encontrar.

Un uso actual de este tipo de conexin es la asignacin fija de un hilo de un servicio
master-slave, que presentaremos ms 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 va de comunicacin
asncrona por antonomasia. Los clientes
colocan los mensajes de peticin en las colas,
los servidores colocan las respuestas y,
cuando les conviene, los clientes toman las
respuestas. Una cola la representaremos por el
smbolo de la figura, ya conocido del captulo
de componentes. De hecho, le recomiendo que
tenga presente todo lo que all se dijo sobre colas cuando lee esta seccin de la
comunicacin de entre cliente y servidor.

Las colas, como va de comunicacin, pueden implementarse con el mdulo
Message-Oriented Middleware (MOM) que proporciona APIs de alto nivel para la
gestin de la colas con independencia de la plataforma.

Sin embargo, si Vd. ha desarrollado un modulo de gestin de, que le proporciona
este recurso como un componente operacional, utilcelo. Seguro que si su
componente es bueno, tendr muchas mejores prestaciones y un mayor control de
la situacin.

Existen tres tipos diferentes de utilizacin de las colas dentro de diseos cliente
servidor. Son los siguientes.

6. 1. Comunicacin sin respuesta o desacoplada.

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

En muchos casos, adems, el proceso
de la peticin por el servidor desde la
cola esta diferida en el tiempo. Es el
modelo que hemos referenciado en la
primera parte como comunicacin
desacoplada, que en el fondo es una
forma de implementar interfases.

Un ejemplo muy comn son los
servidores de impresin; 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 envo de ficheros diarios de resumen de
actividad desde una delegacin a la central. As por ejemplo, un servidor de
ventas de la central est recogiendo por la noche los resmenes de las ventas
realizadas ese da por la red de vendedores.

La comunicacin sin respuesta exige del servidor garanta total de
funcionamiento (full-tolerance).

6. 2. Comunicacin 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 comunicacin
sncrona 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 peticin de otro cliente.

Las vas sncronas del Middleware se
implementan con este modelo de comunicacin.

Servidor
Cliente

Figura 27. Comunicacin sin respuesta
Servidor Cliente
Respuesta

Figura 28. Comunicacin con respuesta
directa
6. 3. Comunicacin con respuesta por cola.

Es el verdadero modelo de
comunicacin asncrona a travs de
colas. Permite al servidor trabajar
simultneamente con ms de un
cliente y a estos escoger el
momento en el que quieren obtener
y analizar la respuesta.

Existen dos versiones segn se
desea trabajar o no con la misma
cola para anotar las peticiones y las
respuestas.

La solucin con dos colas es ms eficiente desde el punto de vista de tiempo
de respuesta, pero en la mayora 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 comunicacin ms verstil
permitiendo que adems de varios
clientes, varios servidores la ataquen
simultneamente.

Los servidores que comparten la cola
pueden ser de servicios diferentes
(diferenciados normalmente por el
calificador de la anotacin) o
instancias del mismo servidor.

Esta arquitectura permite montar
aplicaciones distribuidas muy robusta y adaptables a las variaciones y
aumentos de carga (basta arrancar ms instancias del servidor cuando se
necesita ms cantidad de proceso).

6. 5. Representacin de la comunicacin con servidores de cola.

Para diferenciar en los esquemas cuando la
comunicacin con un servidor de cola es
asncrona o desacoplada utilizaremos la
notacin de la figura.

7. Peticin 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
ms amplio.

Servidor Cliente
Cola nica de peticin/respuesta
Servidor
Cliente
Colas separadas para la peticin y la respuesta

Figura 29. Comunicacin con respuesta por cola
Cliente
Cliente
Cliente
Servidor
Servidor

Figura 30. Arquitectura de colas
multicliente y multiservidor.
Desacoplada
Asncrona

Figura 31. Representacin de la
comunicacin desacoplada y
asncrona por medio de una
cola
El cliente pide ese servicio de forma transparente al
sistema aprovechando que el Middleware le libera
de conocer la localizacin. El formato habitual de la
llamada es de API, con un cdigo de retorno y un
cdigo de error. Por ello, el programa cliente utiliza
al servidor como si fuera una rutina clsica, sin
olvidar, por descontado, de tratar la no respuesta del
servidor. Un servicio este tipo lo representaremos en
los esquemas con el smbolo de la figura.

Si la comunicacin es sncrona o asncrona depende
de la implementacin que el fabricante ha hecho del servicio. De cualquier forma,
son mucho ms habituales los
servicios sncronos que los
asncronos.

La especializacin del servicio puede
incluirse dentro del smbolo tal como
se muestra en la figura de la derecha.
De cualquier forma, para los servicios ms habituales que presentaremos a
continuacin utilizaremos smbolos especficos.

Se presentan a continuacin los servicios estndar ms habituales disponibles en
un entorno de Middleware. No se explicarn con detalle las prestaciones de cada
uno de ellos. Si no se conocen se deber consultar documentacin especfica.

7. 1. OLE y ACTIVE X

OLE y ACTIVE X son
estndares de Microsoft
desarrollado para la
integracin de los objetos de
su paquete de ofimtica
Office y su intercambio entre
las diferentes aplicaciones que forman el paquete (Word, Excel, PowerPoint,
etc.). Hoy da se han convertido en estndares de facto para la gestin e
intercambio de objetos entre diferentes aplicaciones.

Tienen recursos para trabajar de forma sncrona, asncrona y desacoplada.

7. 2. ODBC.

ODBC es, como todo el mundo sabe, el estndar
de Microsoft para el acceso a las BD va SQL.
Hoy da, se ha convertido en el estndar de
facto para la gestin 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
smbolo de la figura.

ODBC es una va sncrona.

Incluiremos como ODBC el uso de JDBC en una arquitectura J2EE.

n de la peticin
genrica de un
servicio.
S-ODBC S-OLE

Figura 33. Especializacin de la peticin de
servicio

Figura 34. Representacin de la comunicacin por
OLE y ACTIVE X

n de la
comunicacin
por ODBC

Si usted ya conoce que es ODBC, sltese el resto de este apartado.

Normalmente se implementa
con un servidor localizado
en la parte de la BD,
normalmente sobre la
misma mquina fsica. En la
parte cliente existe un stub
de conexin (driver local de
trasporte de parmetros del
cual hablaremos ms
adelante). El programa linka
estticamente 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 programacin utilizado. En la figura se
muestra la arquitectura de servicio del ODBC.

7. 3. ADO.

Si el acceso a los datos es a travs de ADO, la
representacin del servicio la haremos por el icono
de la figura.

Su Vd. Ya conoce que es ADO, sltese es resto de
este apartado.

Sobre una plataforma Windows, ActiveX Data
Objects (ADO) permite acceder
a bases de datos compatibles
con ODBC y orgenes 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 mtodos que puede
utilizarse para abrir y cerrar conexiones con bases de datos, y para enviar
consultas de actualizacin de la informacin.

Con el mtodo Execute del objeto Connection se envan 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

n de la
comunicacin
por ADO
Maquina
Cliente
Programa
Objetos ADO
Maquina Servidora
Servidor
ODBC
BD ODBC
Proveedor
OLE DB
BD OLE DB

Figura 38. Arquitectura de ADO
El objeto Recordset tiene las funciones necesarias para recuperar y presentar
un conjunto de filas, o registros, de una base de datos en funcin 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 aplicacin que se ejecute en cualquier plataforma.

La pieza central de una solucin 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 conexin 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 slo
cuando lee o escribe
en la base de datos.
Durante la ejecucin,
los datos pasarn de
la base de datos a un
objeto de negocio de
la capa intermedia y
despus a la interfaz
de usuario.

Para alojar el
intercambio de datos,
ADO.NET utiliza un
formato de
persistencia y de transmisin basado en XML. Para transmitir los datos de una
capa a otra, una solucin ADO.NET expresa los datos en memoria (el conjunto
de datos) como XML y, a continuacin, enva el XML al otro componente.

La ilustracin, bajada de la Web de Microsoft, demuestra la arquitectura de
ADO.NET.

Figura 39. Arquitectura de ADO.NET
7. 4. ODBC o ADO. Servidores de Bases de Datos.

La decisin de utilizar ODBC o ADO es
bsicamente de programacin y no de diseo.

Por esa razn, en los esquemas puede utilizarse el
smbolo de la figura para referirnos a un servidor de
base de datos en general, independientemente de
la tcnica de implementacin utilizada.

7. 5. Servidores de SQL.

Son servicios de datos genricos en los cuales la configuracin de la lgica de
datos se configura en el momento del
arranque del servicio mediante un SQL
embebido. Presentan la ventaja de que puede
cambiarse la semntica del servicio sin tocar
el servidor. Se representaran por el smbolo
de la figura.

Es necesario disponer de un repositorio donde
registrar la descripcin 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 lgica 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 bsica en
sistemas C/S para conseguir rendimientos
ptimos y por esa razn se tratarn ms
adelante ampliamente.

Un procedimiento catalogado, que
representaremos por el smbolo de la figura, es
una va sncrona.

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

7. 7. Vas de acceso a Internet.

Como ya se ha explicado en la primera parte,
usaremos en los diseos dos vas o modelos
diferentes para gestionar servicios de Internet.

Web.
Servicio WEB.

n del servicio
genrico de
acceso a datos
relacionales

n de un
servidor SQL

de la llamada a
procedimiento
catalogado.

los accesos a
Internet.
8. Remote Procedure Call (RPC).

RPC es la va sncrona por antonomasia. Fue la primera va histrica de conexin
entre un cliente y un servidor. Cuando, al principio de los tiempos C/S apareci la
necesidad de conectarlos, se aprovech, adaptndolo, el Remote Job Control (RJE)
que permita encolar trabajos Batch desde terminales transaccionales no
inteligentes.

RPC es un mecanismo genrico mediante el cual un
cliente pide un servicio, codificado en un mensaje cuya
semntica conocen cliente y servidor pero ignora el
transportista, y se suspende hasta que recibe la
respuesta. Es, pues, una va sncrona. Este servicio lo
representaremos en nuestros esquemas con el smbolo
de la figura.

RPC, como va sncrona, se parece mucho en su concepcin al mecanismo llamada
a una rutina normal ya que el cliente (programa principal) llama al servidor (rutina)
invocndolo por su nombre y colocando los parmetros en la cabecera de la
llamada. RPC (mecanismo de llamada a rutina) recoge los parmetros 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 stubs que se
muestra en la figura. Conviene repasar este mecanismo, no por su inters para el
diseo ya que es transparente a cliente y servidor si no porque proporciona una
visin muy til de como montar Middleware. Si usted tiene algn da 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 (interfcie) en
un lenguaje simblico
sobre un fichero de
texto. A continuacin
esta descripcin se
compilar para los
dos entornos, el
cliente y el servidor,
creado dos stubs que
permitirn que los dos
se entiendan en
tiempo de ejecucin.

Para la descripcin de
la interfcie 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 descripcin de la interfcie sea independiente de
la implementacin de cada componente.

n del acceso
por RPC
Middleware
Descripcin
de la interfcie
Compilador
IDL
Stub +
cdigo
cliente
RPC
Run
Time
RPC
Run
Time
Stub +
cdigo
servidor

Figura 45. Network Interface Definition Language (NIDL).

El funcionamiento en tiempo de ejecucin se muestra el la siguiente figura.

Bsicamente el funcionamiento en tiempo de ejecucin es el siguiente:

1. Cuando el servidor arranca, en el Middleware se anota la localizacin 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
localizacin donde lo ha hecho. A partir de ese momento es posible saber la
localizacin de cliente y servidor independientemente de la programacin de
ambos programas.
3. Durante su trabajo el cliente necesita del servidor y prepara la cabecera de la
llamada para la peticin 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 mquina donde est localizado el
servidor.
6. El transportista lleva los parmetros de la llamada a la mquina servidora.
7. El RPC de la mquina servidora recibe la llamada.
8. El Stub de la parte servidora convierte los parmetros al formato que entiende
el servidor.
9. El servidor realiza el trabajo preparando los parmetros del mensaje de
respuesta.
10. El mensaje de respuesta es pasado al Stub de la parte servidora, que lo
codifica en el formato comn y lo pasa al servicio RPC de la parte servidora.
11. El RPC de la parte servidora enva la respuesta al RPC de la mquina
cliente.
12. El transportista retorna la respuesta a la mquina cliente.
Arrancada
del cliente
2.Localizacin
del servidor
Cliente
3.Preparacin
de transaccin
Stub del
cliente
4.Preparacin
de argumentos
Cliente
Runtime
5.RPC
Arrancada
servidor
Servidor
Stub del
servidor
Servidor
Runtime
1.Anotacin
de la
situacin
7.Recibe el
RPC
8.Analiza
parmetros
9.Realiza el
trabajo
10.Envo 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 ejecucin
13. El RPC de la mquina cliente recibe la respuesta y la pasa al Stub de la
mquina cliente.

14. El Stub de la mquina cliente convierte los parmetros al formato del
programa cliente y devuelve la respuesta al cdigo cliente.

Note que este sistema es tan general que lo hace transparente tambin al
lenguaje de programacin.

RPC tiene fama de ser una va muy cmoda para establecer la comunicacin entre
el cliente y el servidor. Pero, por qu es tan cmodo RPC?

RPC hace la vida muy fcil al cliente ya que delega muchos temas al Middleware:

O La localizacin de clientes y servidores.
O El paso de parmetros de forma transparente a las plataformas.
O El tratamiento de las cadas del servidor.
O Seguridad, encriptacin, autentificacin, etc.

Adems, la forma de uso emula el mecanismo call-return, muy fcil de programar,
y el uso es siempre igual, independientemente de la semntica de la rutina.

Sin embargo, su gran facilidad de uso y sus posibilidades no debe esconder su
gran limitacin, es una va sncrona.

9. Comparacin entre colas (MOM) y RPC.

Colas y RPC han sido durante aos las dos formas tradicionales de resolver la
comunicacin asncrona y sncrona entre cliente y servidor. Por esa razn, la
comparacin entre las dos vas se ha realizado comparando las ventajas e
inconvenientes de utilizar colas o RPC.

Vamos a respetar est costumbre histrica. La comparacin entre comunicacin
sncrona y asncrona se realiza a continuacin centrada en RPC y colas, aunque,
evidentemente, la mayora de los argumentos son generalizables para cualquier
otro va sncrona o asncrona.

Criterio Colas (MOM) RPC
Metfora Asncrona: servicio de
correos
Sncrona: telfono
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
Quin mantiene la
sesin de
comunicaciones?
El gestor de colas El RPC run time ya que
hay conexin directa.
Load balancing Una sola cola puede
implementar FIFO con o
sin prioridades.
Necesita un Monitor TP
independiente.
Soporte transaccional Dentro de algunos
productos la cola de
mensajes puede
participar en la
sincronizacin de los
commits.
No. Necesita un Monitor
TP independiente.
Filtro de mensajes Si No
Rendimiento (Perfomace) Lenta (matizadle) Rpida
Dificultad de
programacin
En funcin del modelo de
comunicacin que se ha
escogido y de las
alternativas necesarias
Mnima
Posibilidad de que el
cliente haga trabajo en
paralelo con el servidor.
Fcil Complicado y limitado.

10. Simple Object Access Protocol (SOAP).

SOAP es, bsicamente, un transportista de
funcionamiento sncrono.

Hace transparente la conexin local de la remota.
Es la va habitual que se utiliza para intercambiar
informacin 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 travs de un modelo de objetos distribuidos
usaremos los dos iconos de la figura segn se trate
de J2EE o .Net.

En este modelo, clases especializadas ocultan la
topologa de la comunicacin y los objetos se comunican normalmente por
llamadas sncronas y/o eventos

12. La comunicacin por eventos.

Un evento es la notificacin de una situacin o de un cambio de estado. Cliente y
servidor pueden utilizar eventos para realizar su comunicacin en el momento
necesario: envo de la peticin, servicio realizado y respuesta preparada, hay algn
problema, etc.

n de la
comunicacin
por SOAP

Figura 48. Modelos de
objetos
distribuidos

La comunicacin es bsicamente sncrona. Su
utilizacin es fundamental cuando el diseo y/o la
implementacin se basan en objetos distribuidos. La
comunicacin por eventos la representaremos por el

La comunicacin 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 implementacin de la aplicacin
distribuida.

Analizar a fondo un modelo de objetos distribuidos queda fuera de los objetivos de
este documento dedicado al diseo. Sin embargo, le recomiendo que consulte
informacin especializada sobre este tema, ya sea DCOM o CORBA.

Este modelo de comunicacin es til en aquellas comunicaciones con terceros en
que el envi y/o recepcin 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
programacin en general, es un mecanismo
comodsimo para reaccionar.

ECA es la abreviacin de Event (E), Condition
(C), Action (A).

Bsicamente, el mecanismo es una reaccin a
un evento generado normalmente por un
trigger:

O Se produce el evento en un punto de la
aplicacin y / o sistema.
O Otro elemento de la aplicacin y/o
sistema lo recibe.
O Evala una condicin con los
parmetros del evento recibido y su
propio estado.
O Si el resultado de la evaluacin es cierto,
reacciona al evento ejecutando una accin. En caso contrario, el evento es
ignorado y / o diferido.

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

n de la
comunicacin
por eventos
Regla: (E,C) A
Situacin Reaccin
Regla: (E,C) A
Situacin Reaccin
Evento
CUANDO el evento ocurre
SI se se satisface la condicin
CUANDO el evento ocurre
SI se se satisface la condicin
Situacin
HACER_ejecutar la accin
HACER_ejecutar la accin
Reaccin

Figura 50. Mecanismo ECA.

14. Comunicaciones remotas.

Ya se ha comentado que la presencia de comunicaciones remotas supone, si no
hay una plataforma de comunicaciones muy rpida, la introduccin de un punto de
heterogeneidad que suele condicionar decisivamente en diseo del sistema
distribuido si se quiere disponer de tiempos de respuesta adecuados.

Es por esa razn por la que conviene marcar en los
esquemas la presencia de ese punto de heterogeneidad.
Para hacerlo utilizaremos el smbolo de la figura,
incluyendo junto al la va de conexin establecida entre el
cliente y el servidor.

Es obvio que el concepto rpido es siempre relativo y
depende, bsicamente de las necesidades de la
aplicacin distribuida que se disea.

Aunque este tema se tratar ms adelante con mayor detalle, conviene optimizar la
comunicacin para conseguir tiempos de respuesta aceptables.

Son criterios a utilizar:

O Disear la lgica 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 ms corta posible.
O Comprimir los mensajes.

Si la informacin transportada se considera critica, la
informacin se encriptar. Adicionalmente, se
incorporarn criterios de autentificacin.

Cuando queremos marcar que al otro extremo hay un
dispositivo mvil, telfono o PDA, lo diferenciaremos por
una M en lugar de una R.

Ms que otra cosa nos marcar que hay un punto de
heterogeneidad en el componente de presentacin.

15. Comunicaciones inalmbricas.

Nos referiremos a dispositivos en red local inalmbrica. Lo representaremos en el

Al otro extremo puede haber:

O Una asistente personal, lo que supone un punto de
heterogeneidad de programacin.
O Un telfono de ltima generacin.
O Un PC porttil con lo cual el carcter de inalmbrico
es solo informativo y puede obviarse.

Figura 51. Indicativ
o de
conexin
remota

o de
conexin
remota
con
dispositi
vo mvil

o de
conexin
inalmbr
ica
16. Un ejemplo de utilizacin.

Aunque la eleccin entre las diferentes vas de conexin entre cliente y servidor se
trabajar ms adelante, observemos, a modo de ejemplo, el siguiente proceso en el
que se gestionan servicios. Obsrvese la utilizacin de los smbolos identificativos
de las diferentes vas en el esquema final resultante.

En el siguiente diagrama de flujo se muestra un proceso de contratacin de un viaje
en una compaa area.

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
estn en un servidor de
datos local en la
agencia de viajes.
O Hay ms de un puesto
de venta en la agencia.
O La actualizacin de los
datos del vuelo se hace
en la compaa area.

Con todo ello se identifican
los siguientes servicios:

O Servidor remoto va RPC en la compaa area para la reserva de plazas. La
agencia de viajes no conoce como es el ordenador de la compaa area, 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 mquina. Los programas cliente de
contratacin pedirn los datos de cliente a este servidor mediante una
conexin va colas. El servidor de clientes atacar los datos va SQL.
O El cargo de la venta a las cuentas de cliente se realizar tambin mediante un
servidor que encapsular la funcin.
O La venta de directa desde casa del cliente se har por una aplicacin WEB.
O La consulta de vuelos del personal de la agencia se realizar por la Web de la
compaa area.
O La informacin de los vuelos desde la WEB de venta se tomar a travs de un
Servicio WEB de la compaa area.

Usuario
en tienda
Peticin del cliente
Actualiza
los datos de
la compaa
area
Datos Compaa area
Cuenta Cliente
Registro
de datos del
Cliente
Anotacin
en la cuenta
del Cliente
Registro
de datos del
Viaje
Identificacin
Cliente
Consulta
Vuelos
Acceso
Datos
Compaa
area
Consulta
Datos
Vuelos

Figura 54. Diagrama de flujo de una contratacin de viaje.

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

Y para las funciones de la aplicacin de venta directa:
Componente activo de la WEB
Consulta
Datos
Compaa
area
Datos Compaa area
Obtener
Datos
Cliente
Presentacin de la WEB
Identificacin
Cliente
Consulta
Vuelos
Registro
Vuelos
Identificacin
Cliente
Registro
Venta
Cliente Cuenta Cliente
RPC
Proceso
Compaa
Area
R
Cuenta Cliente
Proceso
Cuenta
Cliente

Figura 56. Arquitectura de las funciones de venta directa

Esta aproximacin intuitiva a la identificacin de servidores se sustituir ms
adelante por otra metdica.

Usuario
Peticin cliente
Datos Compaa Area
Cuenta Cliente
Registro
Datos
Cliente
Anotacin
Cuenta
Cliente
Registro
Datos
Viaje
Peticin
Datos
Cliente
Datos
Cabecera
Cliente
RPC
Actualiza
datos
Compaa
area
Obtener
Datos
Cliente
Proceso
Compaa
Area
Proceso
Cuenta
Cliente
R
Consulta
Datos
Vuelos

Figura 55. Arquitectura de servidores
XML

1. Introduccin.

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 diseo, como he insistido e insistir en repetidas ocasiones, y
XML es una herramienta. Sin embargo, creo que, para poder seguir un curso de
diseo distribuido, debe tenerse mnimo conocimiento del mundo XML. Es el nico
objetivo que me planteo en este captulo.

Aunque la utilizacin de XML es cada vez ms la
opcin habitual, cuando queramos especificar que
hay XML utilizaremos el smbolo de la figura.
Al final de captulo 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. Introduccin al XML.

Ya presentamos XML en a primera parte. Si no lo recuerda, repase el captulo
dedicado a la interrelacin entre sistemas centralizados, C/S e Internet.

XML (Extensible Markup Language) nace del xito de HMTL que necesit pronto
una extensin de prestaciones que empez a hacerse de forma anrquica por las
limitaciones implcitas en su propia definicin que solo permite definir documentos
con reglas preestablecidas. Para evitar esta anarqua el Wide Web Consortium
defini y propuso en 1998 XML.

XML es, bsicamente, un metalenguaje de marcas que permite definir semnticas
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 configuracin bases de datos, intercambios y un largo etc.

Con XML definimos la idea de una entidad, un cliente por ejemplo de forma que la
abstraccin sea independiente del sistema de informacin donde va a utilizarse.
Con este objetivo, la definicin de la entidad puede incluirse en el mismo
documento XML.

XSL (Extensible Stylesgheet Language) se encarga de transformar este documento
en una presentacin en concreto. XSL permite que la misma entidad, definida por
XML pueda presentarse de tantas maneras diferentes como sea necesario.

XML se basa en bloques definidos por etiquetas, ilimitadas y que definen a si
mismas, con las que las aplicaciones pueden pactar como intercambiarse datos o
pedirse procesos.

de XML
XML no es un mecanismo de peticin de servicios: es la descripcin del servicio
que se pide.

La comunicacin de los procesos, que piden y dan el servicio, entre si necesita,
pues, de un mecanismo de peticin.

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 travs de SOAP
(Simple Object Access Protocol) que proporciona el Middleware para pedir de forma
segura y autorizada los servicios a travs de los cortafuegos de seguridad.

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

O Siguiendo las reglas del propio XML.
O Aadiendo, descritas con la sintaxis del propio XML, las reglas pactadas o
estandarizadas para cada caso.

La definicin del documento se hace con una DTD (Document Type Definition) de
forma compleja o con XML Schema Definition Language de forma simple. Hoy da
hay multitud de entidades definiendo DTD estndar.

Una vez definido el documento debe capturarse de forma que los programas de
gestin puedan interpretarlos lo que se consigue con los parsers XML que no son
ms que analizadores sintcticos que transformar la informacin 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 actan siguiendo los nodos del rbol. XSL acta tambin as.

Existen productos, estndares, y especificaciones creados sobre XML y XSML que
quedan fuera del abasto del mbito de este captulo.

3. Componentes de un documento XML.

Se utilizan para definir el contenido del elemento. Los componentes bsicos de un
documento XML son:

3. 1. Marcas.

Una marca es una descripcin que colocamos en el documento para que nos
de informacin de lo que contiene.

Con un conjunto de marcas se construyen los elementos de XML

3. 2. Elementos.

<NombreDelElemento> Contenido </NombreDelElemento>.

La descripcin de cada elemento se entiende como bloque, es decir, debe
tener un inicio y un final </>.

Los elementos pueden anidarse.

Ejemplo:

<cliente>
<nombre>Llus</nombre>
<dni>34567890T</dni>
<fechaNacimiento>19850203</fechaNacimiento>
</cliente>

3. 3. Atributos.

Es un componente para aadir descripciones a un elemento.

Por ejemplo:

<fechaNacimiento formato= AAAAMMDD >19850203</fechaNacimiento>

3. 4. Comentarios.

Su formato es <! ------------------------------------>

4. Creacin de lenguajes.

Usted puede crear su propio lenguaje empezando por definir su propio vocabulario
incorporando la gramtica necesaria para construir el lenguaje.

Como ya se ha dicho, existen dos formas de hacerlo.

La forma compleja es a travs de la validacin de documentos por DTD. Consiste
en agregar al documento descrito reglas de validacin 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 validacin consulte un manual especfico de XML.

Hay un atajo mucho ms fcil a travs del XML Schema Definition Language

5. Utilidad de XML

El inters por XML en los sistemas distribuidos se centra en varios mbitos:

O Separacin y auto descripcin de los datos con independencia de la
plataforma.
O Peticin de servicios en general con independencia de la plataforma. Ideal
para la comunicacin con terceros.
O Llamada a servicios a travs de servidores de seguridad de forma
transparente a la plataforma.
O Configuracin.
O Estandarizacin de los interfaces de datos.
O Estandarizacin de las descripciones de las entidades ms habituales.
O Definicin de un lenguaje propio para las aplicaciones de un determinado
sistema de informacin o compaa.
O Repositorio de servicios SQL como ya hemos citado anteriormente.

6. Utilizacin 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 descripcin inicial de los datos y a continuacin una
ocurrencia para cada uno de los registros que se quieren traspasar. Pactando esta
descripcin entre los dos procesos, emisor y receptor, tenemos la interfase
resuelto.

Qu ventajas tiene este sistema? Libertad absoluta para aadir cosas sin
necesidad de modificar las semnticas ya pactadas. Fundamental para desarrollo
de nuevas aplicaciones o procesos.

Adems, en una escena con muchos actores, cada interlocutor puede coger la
parte que le interesa de una informacin.

Y no se preocupe por el tamao. Cuando pase un fichero *.XML por ZIP se quedar
sorprendido de la reduccin del tamao.

7. Ficheros de configuracin y administracin.

Los ficheros INI convencionales y las anotaciones en el registro de Windows son
sustituidos mucho ms eficientemente por ficheros XML donde pueden
establecerse y validarse cada uno de los elementos de la inicializacin.

XSL permitir mantener sin esfuerzos estos ficheros de configuracin.

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 fcilmente 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 genrica.

Muchos proveedores ya ofrecen XMLQL (XML Query Language) para interactuar
con esa filosofa.

9. Internet y XML.

La interaccin y potenciacin mutua entre Internet y XML es tremenda.

Empecemos por separarla en dos grandes, la WEB convencional y los Servicios
WEB.

La utilizacin de XSL permite personalizar la presentacin de acuerdo con el perfil,
nivel e incluso idioma del usuario que de ha autentificado. Observe, adems, 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 funcin y que el navegador ya
reciba la pgina HMTL formada.

En cuanto a los Servicios WEB, no se imaginan sin XML ya que este estndar
permite la peticin y recepcin del servicio con independencia de la plataforma.

Y cuando el servicio es de una aplicacin 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 aplicacin original.

10. XML y conexiones con terceros.

Por su propia naturaleza XML se presenta como un herramienta bsica con la que
armar la comunicacin con terceros de forma transparente a las plataformas
implicadas. Temas como el comercio electrnico 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 adopcin de estndares como ebXML.

11. XML e integracin de sistemas.

XML se convierte en la herramienta ideal para la integracin de sistemas
heterogneos. Consulte el concepto de EAI, Integracin de aplicaciones
corporativas, del que se habla ms adelante en el tema de Reingeniera, y ver que
parece pensado para XML.

12. XML y Workflow.

La utilizacin de XML para definir los flujos de los procesos WorkFlow es del todo
natural debido a la generalizacin y caractersticas de XML.

Se aprovecharn a fondo las posibilidades de:

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

Arquitectura de la comunicacin en un
sistema distribuido.

1. Dilogo y complejidad de un sistema distribuido.

Imaginemos que estamos en un sistema distribuido con gran nmero de servicios y
clientes. En un sistema donde todos ellos hablarn entre s sin ningn tipo de
organizacin la arquitectura de la comunicacin resultante sera muy compleja y,
probablemente, poco consistente.

Es necesario, pues, establecer limitaciones y modelos que organicen y, porqu no,
limiten el dilogo y que lleven a arquitecturas de comunicaciones claras y robustas.
Las relaciones entre clientes y servidores se estructuran por niveles y se establecen
segn modelos estudiados y conocidos.

La restriccin habitual es trabajar con un mtodo cuasi-jerrquico de dilogo por
niveles o capas, presentado a continuacin, en conjuncin con modelos
establecidos de relaciones entres servidores, arquitectura de servidores, que se
presentar ms adelante, restringiendo drsticamente, sino prohibiendo, la
comunicacin directa entre clientes.

Dejaremos para un captulo posterior los diferentes modelos de comunicacin entre
servidores presentados dentro del tema Arquitectura de Servidores.

2. Organizacin cuasi-jerrquica de dilogo.

El sistema puede imaginarse
organizado en tres niveles o capas
lgicas integradas en un nico
Middleware:

O Nivel exterior o nivel cliente,
donde se sitan los clientes.
O Nivel Intermedio o servidor de
aplicacin, donde se sitan los
servidores de aplicacin. Este
nivel es donde se incluyen los
servidores especficos de una
aplicacin en concreto. Como
se ver en el captulo dedicado
a la integracin conviene que
este grupo funcione con las
mismas reglas de integracin que el resto del Middleware.
O Nivel interno o servidor de Middleware, donde se sitan los servidores de
Middleware. En este nivel coexistirn servidores comprados como
Middleware estndar y servidores genricos desarrollados por la propia
instalacin pero utilizados por ms de una aplicacin.

Estructurado en estas tres capas, se organiza el dilogo entre los componentes del
sistema distribuido con los siguientes criterios:
Servidor de sistema
Servidor de aplicacin
Cliente
Sistema Nivel Servidor
de aplicacin
Nivel Cliente
Nivel Servidor
de Middleware

Figura 58. Organizacin por capas.

O Obviamente, pero recordmoslo, 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 dilogo entre dos clientes.
Cuando se necesite, situacin
absolutamente anormal fuera de
intercambios por interfases, un servidor
debe hacer de buzn de intercambio y
reducir el problema a una simple interfase.
O Analice el dilogo entre servidores de
aplicacin. Probablemente, si un servidor de
aplicacin ha de ser usado por otro del
mismo nivel de aplicacin es un aviso de
que puede ser til para otras aplicaciones y
le interesa integrarlo en la capa del
Middleware
O La relacin entre los servidores del
Middleware le ser la mayora 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 comunicacin son muchas:

O La arquitectura de esa comunicacin queda organizada con reglas claras.
O Las interacciones dentro de la capa de Middleware quedan controladas
internamente con lo que, en la prctica, el nmero de interacciones a
controlar es menor.
O Hay ventajas claras para:
O La gestin de errores, que puede ser de arrastre hacia arriba y
gestionadas por el cliente.
O Para la administracin del sistema.

3. El problema de la congestin.

Puede haber situaciones, por fortuna cada vez menos habituales, en las cuales si
muchos clientes comparten un servidor y/o el dilogo necesita un trfico importante,
el tiempo de respuesta puede ser tan grande que el cliente puede llegar a pensar
que el servicio no est disponible asumiendo, errneamente, un time-out de
respuesta.

Como si esto ocurre el cliente se obliga a disparar el proceso de recuperacin, el
rendimiento quedar gravemente perjudicado. Este es el problema conocido como
congestin del dilogo.

Afortunadamente, las posibilidades y la potencia de las plataformas actuales estn
minimizando el problema. Sin embargo, no lo menosprecie y evale los
rendimientos en caliente cuando tras el arranque inicial de la aplicacin, el sistema
empiece a trabajar en un rgimen normal de carga.

Si le aparece el problema, pude intentar diversas tcnicas para resolverlo. La
primera, y que le recomiendo explcitamente, aumente la potencia de la
plataforma servidora.
Nivel Cliente
Nivel Servidor
de aplicacin
Nivel servidor
de Middleware

Figura 59. Dilogo cuasi-jerrquico

Si aun as, el problema persiste, o el coste es demasiado alto, o el problema es
demasiado puntual para justificar una inversin son tcnicas habitualmente
utilizadas:

O Realizar una recuperacin de errores eficiente. Vase, por ejemplo, la
gestin 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
captulo de arquitecturas de servidores. Actualmente, esto equivale a disear
el servidor como multihilo.
O Utilizar tcnicas de comunicacin Pull en lugar de las habituales Push.

Si al final nada funciona, habr que modificar el diseo inicial.

4. El estilo Pull de comunicaciones.

El estilo Push es el clsico cliente / servidor. Con l, el cliente
lleva la iniciativa.

El estilo Pull de dilogo, representado por el smbolo de la figura,
se organiza as:

O El cliente enva una peticin de atencin al servidor.
O Si el servidor est ocupado, notifica o no al cliente que ha
de esperar pero siempre se guarda la referencia y peticin
del cliente.
O Cuando el servidor est en condiciones de atenderla lo
notifica al cliente.
O El cliente enva entonces el mensaje completo.

En el estilo Pull el servidor controla el dilogo ya que decide cuando ha de
comunicar. Observe que el dilogo Pull permite encapsular muy fcilmente dentro
del servidor un sistema de prioridades.

Existe la posibilidad de organizar un modelo de comunicacin conocido como Pull
conversacional que consiste en:

O El cliente enva una peticin de conexin. Si pasado un tiempo (time-out) no
tiene respuesta lo vuelve a intentar.
O El servidor mira de forma cclica (scanning) si tiene peticin de un cliente. Si
es as, la acepta y le da el servicio.
O Cuando el servidor ha acabado el servicio, vuelve a la exploracin cclica.

n del dilogo
Pull
Una desventaja importante del mtodo es que el
servidor ha de conocer que clientes tiene que
escuchar. Una forma cmoda de hacerlo es
colocarlos en una tabla que el servidor consulta
cuando arranca (veremos ms adelante que
esta tabla es la ficha de enviroment del
servidor).

Evidentemente si hay posibilidad de
comunicacin asncrona, cosa hoy da casi
siempre cierta, este dilogo 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
terminologa Pull y Push ha
reaparecido. Y con una semntica
que es, en cierta forma, contraria
a la clsica C/S.

Pull se puede entender como el
sistema habitual en la navegacin:
el cliente pide la informacin a los
servidores WEB, el servidor se
anota la direccin de cliente, este
se queda en espera, y cuando
dentro del servidor le toca turno,
ste remite la informacin al
cliente origen de la peticin.

La tecnologa Push en Internet, denominada habitualmente POP-UP, se piensa
como una forma de que el servidor tenga pre-anotados que clientes estn
interesados en una informacin y cuando esta se genera, el servidor inicia el envo.
Por ejemplo, si Vd. se suscribe a una informacin de Bolsa, podra pactar que
cuando una determinada accin bajar por debajo de un valor, se le notificar
automticamente. El servidor Web de la Bolsa iniciara la transmisin cuando esta
situacin ocurriera.

La notificacin podra ser puntual (aperidica) o peridica.

Como todos conocemos, el sistema puede tener una alta tasa de peligrosidad:
pueden bombardearle con informacin no necesaria a que nos conectamos a
alguna Web de uso gratuito.

6. El dilogo entre clientes.

Aunque como ya le he dicho le recomiendo que tome como criterio de diseo que
dos clientes no intercambien mensajes que no sean interfases, en la prctica
Estilo PUSH
Estilo PULL
P

Figura 61. Push versus Pull
PULL
Peticin
Respuesta
PUSH

Figura 62. Push y Pull en Internet
establecer comunicaciones entre clientes puede ser necesario en algunas contadas
ocasiones.

En estos casos, el dilogo entre clientes ha de hacerse con filosofa store and
forward, es decir, se ha de actuar como correo en filosofa de interfase... Utilice,
pues, un servidor de correo o una cola desacoplada.

Si no recuerda bien la filosofa de un servidor de correo ni de la conexin
desacoplada, repase los captulos dedicados a ellos.

De cualquier forma, no confunda dilogo entre clientes con integracin de
aplicaciones, concepto que desarrollaremos ms adelante.

Programacin de Aplicaciones Distribuidas.
Metodologa Puzzle

1. Introduccin.

Este es un documento de diseo tecnolgico. Parte de la existencia de un anlisis
funcional y de la necesidad de implementar la aplicacin como distribuida utilizando
adems de los sistemas convencionales tcnicas cliente/servidor basadas en
sistema operativo o Internet. Desarrollar los mtodos y las tcnicas para llegar
desde el funcional a los programas y rutinas necesarias para conseguir la
arquitectura distribuida. Y acabar donde empieza la programacin (no confundir,
por favor, con codificacin en un lenguaje de programacin) de los componentes
resultantes. Y con ese criterio est desarrollado.

Parto de la base de que usted, amigo lector, sabe perfectamente de la
programacin y sus tcnicas. Y, por descontado, conoce a la perfeccin las
diferencias que hay entre diseo tecnolgico y programacin.

As, la programacin es un paso posterior al diseo distribuido e independiente de
ese diseo. Cada organizacin la gestionar segn su metodologa habitual de
trabajo.

De todas las tcnicas que Vd. conoce para disear y implementar programas, voy
en este captulo a proponerle las que a mi juicio se adaptan mejor aplicaciones
distribuidas, para si usted no usa ninguna, puede buscar informacin ms completa
y empezar a hacerlo. Adems, son las que utilizar cuando tenga que referirme, a
efectos didcticos, a la continuacin del diseo tecnolgico a travs de la
programacin.

2. Internet y piezas/componentes de software.

Este apartado debera estar al final de esta seccin. Sin embargo y en previsin de
que ya conozca lo que aqu se explica, o Vd. simplemente le aburra y se lo salte,
quiero recordarle la bendicin que supone para los desarrolladores la
generalizacin de la compra y administracin de piezas por Internet.

En los tiempos histricos de este tema, ayer, las piezas se haban de localizar y
comprar a travs de distribuidores locales con todas las deficiencias de servicio y
coste que ello supona. Nunca tenas soporte sobre que hacia y como lo haca la
pieza, muchas veces el propio distribuidor lo ignoraba, si ayuda en los problemas
iniciales. Y hablar de tener la ltima versin ya era un reto inabordable.

Internet ha actuado como un Sant Jordi contra el dragn eliminando todos los
problemas de soporte, actualizacin y localizacin de componentes. No hace falta
que diga nada ms. Todo esto es su historia de cada da.

Solo una reflexin. Me declaro de corazn partidario del software libre. Pero la
experiencia dice que hay que ser precavido. Sobre este tema tome Vd. su propia
decisin.


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

El diseo de aplicaciones distribuidas supone bsicamente el diseo de una
arquitectura de aplicacin.

Hoy da se estn utilizando bsicamente tres paradigmas para construir
aplicaciones distribuidas:

O Programacin estructura, secuencial o por eventos.
O Tcnicas 4GL.
O Orientacin a Objetos bajo UML.

La arquitectura no puede quedar condicionada a los paradigmas de programacin
sino que el mtodo propuesto ha de ser general e independiente.

En esta lnea se introduce el concepto de pieza.

4. Implementacin por programacin de piezas.

Las caractersticas de las aplicaciones distribuidas, y en especial si la solucin 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 dilogo entre cada rutina y el componente que la usa son los
argumentos que la llamada proporciona y que sustituyen a los
parmetros 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
programacin. 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 combinacin 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 temticos.

Son ejemplos de clusters:

O Cluster para la gestin del acceso a un entorno.
O Cluster de gestin de fabricacin.
O Cluster de gestin de la entidad producto despus de un Upsizing.

6. Piezas y Middleware comprado.

Desgraciadamente, mucho del software de Middleware que existe en el mercado
como estndar utiliza variables globales adems de parmetros.

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, valrese seriamente la
posibilidad de encapsularlo por su cuenta. El mnimo trabajo necesario no le
reportar a la larga nada ms que ventajas.

A modo de ejemplo, considere el atributo visible de cualquier componente grfico
de una interfcie 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 opcin.

7. Piezas y Middleware de mundo del software libre.

Vale todo lo dicho en el apartado anterior con la salvedad de la modificacin:
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 metodologa Puzzle.

Esta visin de un programa como la integracin de un conjunto de piezas que se
integran armnicamente para resolver la aplicacin la denominaremos
genricamente como desarrollada con una metodologa Puzzle.

Esta visin tiene la gran ventaja de que deja el diseo
absolutamente independiente de la programacin 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 diseo especifica una pieza, si ya se tiene una con esa especificacin 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 inversin 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, integrndola
con el resto de las piezas ya utilizables con las reglas que haya convenidas en su
entorno para la integracin de Middleware y programas.

El origen de las piezas puede ser, pues:

O Middleware comprado.
O Piezas reutilizadas construidas con recursos propios.
O Fabricadas por la aplicacin que se esta construyendo:
O Como reutilizables, mayor esfuerzo.
O Especificas de la aplicacin, 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, mtodos, eventos, comportamiento ante los errores, etc.).

Obviamente, si trabaja as la metodologa puzzle garantiza independencia del
diseo con el paradigma y las tcnicas de programacin.

9. Tcnicas para construir piezas.

Le recomiendo dos tcnicas para construir piezas con todas las ventajas que
necesita:

O Orientacin a Objetos (OO).
O Tipos Abstractos de Datos (TAD).

Recuerde en este momento los comentarios realizados sobre estas dos tcnicas en
el captulo 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 fabricacin y para
verificar y certificar el comportamiento a la salida del proceso de fabricacin. Y si es
comprada, a la llegada del pedido.

La redaccin del contrato se har con la metodologa de especificacin que se haga
servir en la instalacin. Si no se dispone de ninguna es conveniente establecerla
antes de empezar. Sea cual sea, ha de permitir que la especificacin del contrato
sea total, clara, precisa y fiable.

Se habr de establecer un modelo de especificacin del contrato de la pieza comn
a toda la instalacin. 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 ms de una
vez en la organizacin; y a veces, con efectos no exactamente iguales.

Es conveniente que el contrato de software se formalice en un modelo fsico que se
pueda imprimir y consultar mediante un formulario sobre el paquete de ofimtica
que utilice la organizacin. 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 cmodamente informar, de entre todo
lo posible, slo lo que interese.

Y tambin 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 ms que se sea muy evidente, y amplelo progresivamente. Y
si encuentra alguno que le guste, utilcelo; no hace falta que lo invente si ya existe.

La definicin y el uso de plantillas que permiten los paquetes de ofimtica le sern
de gran utilidad.

11. Cuatro ideas sobre especificacin de piezas.

Recordemos de entrada que la especificacin 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 ms
habituales con algunos comentarios muy personales sobre ellos.

11. 1. Lenguajes de especificacin.

11.1.1. Mtodos de anlisis.

Utilizando elementos de esa etapa como diagramas jerrquicos, flujos,
clases, esquemas de datos, etc. Personalmente creo sirven ms para
explicar como trabaja la pieza que para explicar que debe hacer y que
slo son tiles para piezas de muy alto nivel.

11.1.2. Mtodos formales.

Utilizan postulados lgicos para expresar las ideas. Son de una gran
exactitud, pero necesitan de una gran formacin para establecerlos
correctamente. Y para leerlos y entenderlos.

Por ejemplo, si Vd. quiere expresar que un vector (tabla o array de una
dimensin) declarado como:

tipus VECTOR: tabla [1..50] de entero ftipus
var a: VECTOR fvar

Despus de la ejecucin de una rutina tiene todos sus elementos a
cero, puede escribir:

{ k: 1k50 : a [k]=0}

Es frecuente que especificacin formal muy bien hecha por personal
muy formado no sea entendida por otros informticos que han de usar
la pieza debido a que no tienen esa formacin lgica.

Dentro de este grupo, adems de los mtodos formales basado en le
lgica de predicados pueden incluirse tambin los mtodos algebraicos
(todava menos populares).

11.1.3. Mtodos de texto libre.

La descripcin se hace con lenguaje natural. As, el postulado anterior
podra expresarse como:

{Todas las posiciones de la tabla a estn a 0}

El texto libre es, con mucho, el lenguaje de especificacin ms utilizado.
Pero es tambin la fuente ms importante de generacin de problemas
de comunicacin 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 mtodo no hay que perder de vista las
cualidades de toda especificacin que ha de ser total, precisa, clara y
fiable.

Autores como Meyer han definido Los Pecados del especificador
formal:

Ruido. Incluir informacin innecesaria o redundante.
Silencio. Falta de informacin.
Sobre especificacin. Detallar ms de lo necesario.
Contradiccin. Una misma propiedad especificada de dos formas
diferentes en dos partes de la misma especificacin.
Ambigedad. Por falta de precisin. Un ejemplo habitual es utilizar
una palabra sinnima para definir un concepto.
Referencia hacia adelante. Utilizar trminos y conceptos no
definidos anteriormente.
Remordimiento. Hacer precisiones o introducir restricciones sobre
declaraciones anteriores.

11.1.4. Mtodos semiformales.

Mezclan el texto libre con smbolos de los mtodos formales. El texto
libre facilita la inteligibilidad y los smbolos formales hacen los
postulados ms concisos y precisos.

Es un muy buen recurso.

11. 2. Partes de la especificacin de una pieza.

La especificacin de una pieza ha de tener dos partes:

11.2.1. Global.

Cada pieza se caracteriza por un nombre y una descripcin.

Cada pieza dar uno o ms servicios. Cada servicio se habr de
especificar independientemente.

Si hay ms de un servicio en la pieza se definirn globalmente:

Los tipos de los datos afectados.
Las restricciones generales de uso y las incompatibilidades entre
los servicios que aporta la pieza.
Los eventos que recibe (obviamente si los hay).
Las caractersticas 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 comunicacin.
Posibilidad o no de paralelismo.
Condiciones de arranque.
Etc.

En un Objeto se habr de especificar las caractersticas de la clase.

Los atributos de propiedad.
Los controles de administracin.
Referencia dentro del sistema.
Requerimientos del sistema.
Restricciones de uso.
Usuarios.
Nodos.
Horarios.
Etc.
Los estndares 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. Parmetros del mensaje de peticin.

Variables que constituyen los parmetros: nombre y descripcin.
Categora o modo de esos parmetros: entrada, salida, entrada /
salida.
Paso de los parmetros: por valor, por referencia (o direccin), por
tipo.
Precondiciones de los parmetros de entrada y la parte de entrada
de los de entrada / salida.
Poscondiciones de los parmetros de salida y la parte de salida de
los de entrada / salida.
Invariantes. Son condiciones globales que se han de mantener
antes y despus de ejecutar el servicio. Es recomendable
formalizarlos de la misma forma que las precondiciones y las
poscondiciones. Un ejemplo de invariante puede ser: despus de
ejecutar un grupo de modificaciones de sueldo, la masa salarial de
un departamento no puede sobrepasar un incremento porcentual
del valor anterior.
Especificacin del comportamiento de errores, que trataremos a
continuacin.
Especificacin de eventos y triggers, que tambin trataremos a
continuacin.

11.2.3. El formato de cabecera de una rutina como mtodo de especificacin
de un servicio.

Una forma habitual de especificar los parmetros es el formato
cabecera de rutina:
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 establecern que condiciones
tienen los valores de los parmetros 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 parmetros
afectados. La diferencia entre ambos es el efecto esperado del
servicio.

Veamos algunos ejemplos de especificacin formal:

Descripcin rutina: colocar a ceros un vector de dimensin
variable:

accin ceros_vector(ent valor n: entero; sort ref a: tabla de enteros)

/* n: nmero de casillas */
/* a: direccin de la tabla */

precondicin: {n>0}
postcondicin: { k: 0k<n : a [k]=0}

Descripcin rutina: Busca de un valor en vector de caracteres.

accin busqueda_matriz(ent valor x: entero; ent ref a[1..50] de carcter;
sort ref esta: booleano; sort ref pos: entero)

/* x: valor a buscar */
/* a: tabla donde se ha de buscar */
/* esta: resultado de la bsqueda */
/* si est, pos tiene la posicin si no el valor de pos es indefinido */

Precondicin: {a=A x=X}
Poscondicin: {esta k: 1k50: a [k]=X esta a [pos]=X}

11.2.4. Especificacin 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 descripcin, que puede ser general asociada al tipo de error.
Una tipologa (aviso, error,..)
Un grado de reaccin (inmediata, demorada,..)
Las causas que lo producen.
Informacin si el tratamiento de error es interno a la pieza (no
recuperable desde el exterior) o se ha de gestionar externamente.

La gestin de errores en un entorno distribuido es suficientemente
importante como para que la tratemos ms adelante en detalle.

Sin embargo, adelantemos que tambin hay que dar especificacin 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 gestin de errores es delegada al algoritmo que llama a la
rutina:
El formato del error dentro de la respuesta.
Descripcin semntica del error.
En este segundo caso, la operativa y las posibilidades de
recuperacin del error sern responsabilidad del algoritmo
que usa la pieza y no de sta.

11.2.5. Especificacin de eventos y triggers.

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

Se especifican segn un mecanismo ECA para tratarlos. Es muy
recomendable que la accin del mecanismo ECA sea un servicio de
la pieza. Si se hace as, la especificacin del servicio referenciado ya
describir la reaccin 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 descripcin.
Se explicar la causa.
Si ha lugar, se detallar el destino.

12. Implementacin de la pieza y paradigma de programacin.

Como ya se ha dicho, la implementacin de la pieza se har segn el paradigma y
las tcnicas de programacin existentes en la organizacin de desarrollo.

No hay que olvidar, sin embargo, las reglas bsicas fundamentales para que la
pieza funcione correctamente en la metodologa puzzle y que se han explicado con
anterioridad.

Repasemos a continuacin algunas de las reglas ms bsicas a seguir segn el
paradigma de programacin utilizado.

12. 1. Programacin estructurada.

En programacin convencional, lo mnimo exigible es programacin
estructurada. Si utiliza este paradigma, recuerde que:

Cada servicio ser una rutina pblica.
No ha de haber ni variables ni constantes globales. El nico dilogo 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 parmetros para optimizar el
rendimiento. Por ejemplo, aunque una matriz muy grande sea un
parmetro de entrada se pasar siempre por referencia.
Respetar al mximo el mecanismo ECA. La reaccin de un evento
conviene que sea siempre una nica rutina.
Generalizar al mximo utilizando siempre que sea posible el paso de
parmetros por tipo. es decir, en lugar de pasar un vector de 1 a 50,
pasar un parmetro de tipo tabla y la dimensin de 50 elementos.
recuerde que en este caso, y en la mayora de lenguajes de
programacin, dentro de la rutina la primera posicin se referenciar por
la posicin 0.

12. 2. Programacin orientada a objetos y tipos abstractos de datos.

Adems de todo lo del apartado anterior aplicable a estos dos paradigmas:

Cada pieza ser un objeto o un TAD.
Cada servicio ser un mtodo o una rutina pblica.
Posibilidad de asignar los servicios a controladores que despus
delegaran a las clases que realmente proveen el servicio de forma
opaca al cliente.
Encapsular en funciones la gestin de atributos. En lectura bastar una
funcin. En modificacin, le permitir controlar la integridad (valores
vlidos) y la coherencia (dentro de los valores vlidos cuales son
actualmente admisibles en funcin del estado de la pieza) de los
atributos. Si deja a los clientes gestin directamente los atributos puede
llegar a tener graves problemas en este sentido. Incorpore a la rutina de
gestin modificacin del atributo, un parmetro de salida para informar de
posibles errores, detallando al mximo la causa.
Respetar el mecanismo ECA. recuerde que la reaccin a un evento sea
un mtodo.
Evitar al mximo la gestin de errores dentro del objeto o TAD. Si es
inevitable (pocas veces lo ser) y ha de haber dilogo desde dentro de la
pieza, actuar en el dilogo tambin con los criterios de pieza.

13. Implementacin 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
tcnicas:

O Tratarlos como un elemento ms de la respuesta.
O Aprovechar la gestin de eventos generando un trigger.

Pueden aprovecharse recursos especficos de cada rea informtica. 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. Integracin de las piezas.

El tema se tratar en profundidad ms adelante. Adelantemos slo que puede ser
de dos tipos:

O Esttica, linkada con el programa.
O Dinmica, por ejemplo, en un servidor.

15. Certificacin de una pieza.

15. 1. Necesidad de certificar.

La fiabilidad de la metodologa puzzle es basa en la absoluta fiabilidad de la
pieza. La naturaleza misma de la metodologa obliga a que el que utiliza la
pieza desconozca su implementacin 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. Adems, 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 certificacin de calidad que nada
ms puede garantizar la prueba exhaustiva de que la pieza cumple su contrato.
O por la utilizacin de mtodos de desarrollo que utilicen programacin
metdica y verificacin analtica, mtodos y tcnicas que difcilmente se
utilizarn por falta de formacin del personal o por inviabilidad econmica.

La certificacin 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. Metodologa de certificacin.

La certificacin se ha de contemplar como una tarea por si sola. Pasar
necesariamente por pensar y desarrollar entornos de prueba para cada pieza.

La verificacin que ha de certificar el comportamiento de la pieza segn su
contrato de comportamiento no se puede improvisar sobre la marcha. Cuando
se est diseando la pieza se ha de pensar como se ha de probar de forma
metdica segn los pactos del contrato. Y cada acuerdo del contrato ha de ser
probado en toda su extensin.

Si la pieza es general, no es recomendable aprovechar la misma aplicacin que
la usar para probarla. El recurso sera poco gil, no se probarn
probablemente todos los casos y los errores de la propia aplicacin pueden
desvirtuar la prueba.

Es mejor desarrollar un entorno propio, basado seguramente en una interfcie
GUI, que haga la prueba gil y cmoda y permita tratar toda la casustica
completamente y punto a punto.

La verificacin de las piezas genricas puede suponer, de hecho debe, una
carga de trabajo importante que no puede ser obviada en la planificacin 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 certificacin la realice personal
que no haya participado en la construccin, hecho que aumentar la fiabilidad.
Evidentemente, esto difcilmente es viable en organizaciones pequeas.

En piezas compradas que tengan ms opciones de las que vamos ha utilizar,
puede utilizarse la tctica de certificar slo las que necesitamos. En esta caso,
en la documentacin ha de quedar perfectamente estipulado que se ha
certificado y que no.

15. 3. Certificacin y verificacin analtica.

La utilizacin de tcnicas de programacin metdica y/o de verificacin
analtica puede ser de gran ayuda para la certificacin de piezas complicadas.

Su gran problema es la formacin y el tiempo necesario para hacerlo bien.

Hay dos caminos:

Utilizar programacin metdica completa.
Utilizar programacin convencional, eso si, con postulados, simplificar la
arquitectura del programa con anlisis descendente (programacin
estructura) y verificar analticamente a posteriori. En este caso habr que
reducir el nmero de sentencias utilizadas al mnimo y conocer
claramente cuales son las reglas de inferencia de la que se utilicen. Con
una composicin secuencial, una composicin alternativa, otra alternativa
y un mecanismo de llamada a rutina tendr suficiente.

15. 4. Comentario final.

Si estos ltimos apartados sobre programacin metdica y verificacin analtica
le han sonado a chino, olvdelos. Si le han despertado curiosidad busque
documentacin apropiada. Ni este es el documento apropiado ni yo s
suficiente para explicrselo.

Gestin y Reusabilidad de Piezas y
Componentes.

1. Introduccin.

La gestin de piezas es un caso particular de la gestin de componentes. Y la
construccin y gestin correcta de componentes es fundamental para conseguir
ndices altos de reusabilidad, necesidad perentoria si una organizacin de software
quiere ser competitiva y trabajar bien.

En cualquier curso de diseo incluir las ideas bsicas sobre este tema es
fundamental.

SI usted amigo lector ya sabe suficiente sobre este tema, salte al captulo siguiente
ya que aqu solo encontrar las ideas bsicas sobre este tema.

2. Construccin de componentes.

La construccin de componentes de software debera tener siempre como segundo
objetivo su reusabilidad; el primero es obviamente que cada componente funcione
como sea pensado.

Vaya por delante la contradiccin bsica de la reusabilidad: generalidad del
componente versus esfuerzo de desarrollo, y por tanto coste, para construirlo.
Volveremos ms adelante sobre este importantsimo 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 especificacin bien definida, sintcticamente y
semnticamente.
Ha de ser fiable y robusto.
Independiente del entorno.
Trabajar dentro de lo posible con estndares.
Adaptable a nueva situaciones y plataformas.
General, es decir, vlido a ms de una aplicacin.
Tener buenas condiciones de reusabilidad.

2. 2. Componentes arquitectnicos (Framework).

Un componente arquitectnico o Framework, es un componente de alto nivel
que encapsula comportamientos tpicos de diferentes arquitecturas de
programas.

Por ejemplo, puede pensarse en disear un Framework para resolver el
mantenimiento de ficheros.

Con solo citar este ejemplo ya se aprecia que los componentes arquitectnicos
han de ser generales y tener una gran capacidad de adaptacin. Es decir, para
aprovechar el polimorfismo y la herencia, en su diseo e implementacin est
fuertemente potenciado el paradigma orientado a objetos.

El desarrollo de Framework se convierte as en un elemento bsico 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 ms 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, disear y construir componentes reutilizables es importantsimo 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 inversin.

Sin olvidar que cargar el coste del componente reutilizable al proyecto que lo
ha detectado puede ser terriblemente injusto por la penalizacin de costes y
plazos de entrega.

Donde est el lmite o cual es el criterio para encontrar el punto de equilibrio?
El limite es conseguir el ratio prestaciones / inversin ptimo. Lo siento pero no
conozco ninguna formula para calcularlo. De cualquier forma, hay un criterio
que si funciona: el sentido comn.

Y hacer una buena criba inicial con una sencilla decisin. Distinguir si el
componente es interesante como reutilizable fuera del entorno del proyecto
actual o no.

Recuerde tambin que el concepto de componente universal no existe ms que
en la teora. Y que buenos componentes reutilizables con fuerte contenido
semntico obligan a consultar con expertos en los temas que resuelven.
Incluidos temas informticos. Usted es seguro un buen informtico, pero es
tambin seguro que no lo sabe todo.

2. 4. Documentacin.

La documentacin del componente debe incluir tres tipos de informacin:

Informacin de clasificacin y localizacin. permite localizar el
componente. Debe incluir los entornos tecnolgicos sobre los que opera.
Informacin de uso: permite saber como debe usarse, es decir, como
llamarlo y como obtener y analizar los resultados obtenidos. Debe incluir
los estndares que usa o soporta.
Informacin tcnica. Permite saber como est implementado el producto.
Debe incluir informacin sobre su diseo.

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


3. Gestin de componentes (Component Management).

La gestin de componentes es el conjunto de actividades dirigidas a controlar,
documentar y administrar los componentes (piezas) de una organizacin de
desarrollo de software.

La gestin de componentes es un mundo por si mismo y es vital para una buena
gestin de la reusabilidad. Cuantos ms componentes haya, ms difcil ser su
especificacin, localizacin y calificacin.

Todo el conjunto se basa en:

O Un estndar de especificacin y documentacin.
O Un repositorio donde se registra toda la informacin disponible.
O Un sistema de consulta y localizacin.

Como estndar de especificacin y documentacin 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 mnimo
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 clasificacin para los componentes: temas, palabras clave,
entornos, origen, etc.

Las actividades propias de la gestin de componentes son:

3. 1. Actividades ligadas con el desarrollo.

Marcar estndares.
Especificacin.
Seleccin.
Adquisicin, compra o fabricacin.
Coordinacin del desarrollo de nuevos componentes.
Garantizar la certificacin de calidad (no hacerla!).
Seguir las compras a terceros.

3. 2. Actividades de administracin.

La administracin de componentes la realiza el bibliotecario.

Son actividades propias de este grupo:

Gestin del repositorio
Normalizacin de las especificaciones.
Clasificacin.
Registro.
Documentacin
Administracin del ciclo de vida.

4. El Comit de Componentes.

Con todo lo que hemos visto, se advierte en seguida la necesidad en las
actividades ligadas al desarrollo de que exista alguien que decida los estndares de
reusabilidad, que se compra, que se construye y a que nivel de generalizacin se
llega en cada componente.

Aqu parece un problema diferente segn el tamao de la organizacin de
desarrollo.

En las actividades de administracin, la figura del bibliotecario, que debe existir
inexcusablemente, no presenta problemas. Si la organizacin no tiene suficiente
volumen para tener un especialista la funcin puede asumirla a tiempo parcial
cualquier otro elemento de la organizacin.

No pasa as con las actividades de desarrollo que necesitan formacin para tomar
las importantes decisiones de este mbito.

Y, claro est, aqu el
volumen de la organizacin
es primordial. Si no hay
suficiente volumen habr
que responsabilizar a una
persona y que subcontrate
funciones cuando no llegue.

Si la organizacin 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 organizacin de la
gestin 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 tcnica y de organigrama.
O El responsable tcnico de los componentes.
O El bibliotecario.
O Jefes de proyecto (pocos) con experiencia.
O Expertos rotativos sobre la funcionalidad de componentes especficos.
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 bsicas que debe asumir el comit son:

Proyectos
de
Aplicacin
Comit de
Componentes
Construccin
de
Componentes
Compra
de
Componentes
Libreria de
Componentes
REPOSITORIO
Comite de
Componentes
Bibliotecario
Expertos
Director Proyecto
Jefes de aplicacin
Comite de
Componentes
Bibliotecario
Expertos
Director Proyecto
Jefes de aplicacin
Evaluacin
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
O Decidir y garantizar las plataforma de reusabilidad de la compaa
O Establecer los estndares.
O Evaluar cada peticin a partir de la especificacin recibida.
O Aprobarla o rechazarla.
O Decidir el nivel de reusabilidad de cada componente.
O Autorizar la compra o la fabricacin.

Se establece as un flujo de propuesta / decisin que se muestra en la figura
anterior.

Los jefes de proyecto realizan las propuestas de componentes despus 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, decisin que es
del jefe de proyecto.

A partir de aqu, empieza el proceso de compra y / o fabricacin sobre el cual el
comit ya no interviene.

El proceso acabar con la incorporacin del nuevo componente o del cambio o
ampliacin al repositorio, funciones que ya son especficas del bibliotecario.

5. La gestin 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 razn, al
hablar de reusabilidad hay que
ver tambin 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
instalacin, a travs de la
especificacin de los componentes, para ver si ya dispone de componentes que le
resuelvan su problema.

Especificacin
Repositorio
Gestor Proyecto
Catlogo
Fabricados
por terceros
Orden de
Compra
Reutilizables
Apl.
Fabricacin
prpia
Especificacin
Orden de
Fabricacin
Certificacin
de Calidad
Consulta
componentes
disponibles
Contrato de
Software
Recepcin
Alta en el
Repositorio
Fin Pruebas

Figura 64. La reusabilidad gestionada por el
Director de Proyectos
Si ocurre, es probable que tenga que modificar ligeramente su diseo 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 catlogos 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 estndares de la organizacin, o en su defecto, le propondr una
solucin alternativa. A continuacin lanzar, personalmente, a travs del Comit o
travs del Dpto. de Compras, la orden de compra. Cuando llegue el producto
deber pasar la certificacin de calidad, tras lo cual se incorporar en el repositorio
de la organizacin.

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 especificacin del contrato de software, se decidir el equipo de
desarrollo y se lanzar la orden de fabricacin. Despus de las pruebas de
programacin el componente deber pasar la certificacin 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
instalacin.
O No caiga nunca en el error de modificar un componente comprado; si dispone
de las fuentes evidentemente. Clavar su compra en la versin actual.
Cuando cambie, deber repetir parte del esfuerzo.
O Encapsule las diferentes interfcies del software comprado si tiene algn
estndar en su instalacin.
O Siempre que le sea posible trabaje con estndares, aunque el producto que
compre no sea el mejor tcnicamente.

6. El ciclo de vida de un componente.

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

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

El primer estado de
la vida de un
componente es su
especificacin que
va a definir como
ser y que es
sometida al comit
de componentes. Si
es aceptado se
generar la peticin
de compra o
fabricacin.

Al final del proceso
de fabricacin o a
la llegada de la
compra el
componente
quedar en un
estado de en certificacin tras el cual el componente quedar listo para distribuir y
se incluir en la librera, anotndose en el repositorio.

El componente estar en uso hasta que pase una de dos situaciones. La primera es
que necesite cambios o ampliaciones que necesitarn una nueva especificacin y
una vuelta al comit de componentes con lo que se reiniciar el circuito.

La segunda situacin es que, por sustitucin o actualizacin, 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 librera
y descatalogarlo del repositorio.

Especificacin
Nuevo
En
construccin
Listo para
distribucin
En uso
Pendiente de Borrar
(no hacer-lo servir)
Rechazo
Peticin
Construido
Nueva versin
a la librera
Marca de borrar
Borrar
Cambio de especificacin
En Proceso
de Compra
En
Certificacin
Certificado
Recibido

Figura 65. Ciclo de vida de un componente
Distribucin del peso de la aplicacin entre
clientes y servidores.

1. Introduccin.

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 aplicacin entre clientes y servidores es
importante en la arquitectura distribuida resultante.

Todava es muy prematuro para exponer criterios de distribucin. Pero no lo es para
introducir el concepto de distribucin de la funcionalidad, que ser uno de los
puntos claves del diseo.

2. Distribucin del peso de la aplicacin.

Los sistemas
distribuidos pueden
ser cualificados por
como se distribuye el
peso de la aplicacin
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 introduccin, hay funciones que son claramente de
cliente, como las interfcies GUIs. Por el contrario, otras son tpicamente
servidoras, como la localizacin de los servidores de las bases de datos (por favor,
no confunda servidores de BD con servidores de lgica de datos).

Debido a lo extendida que esta (y de lo mal que suena la traduccin en castellano),
voy a respetar los trminos 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 aplicacin esta en los clientes.

Son las arquitecturas ms tradicionales en el mundo cliente/servidor donde en
muchas aplicaciones la lgica de programa se incrusta en una interfcie GUI que
accede nicamente a servidores de datos y de impresin. Se utilizan ampliamente

Figura 66. La balanza de distribucin del peso C/S.
en aplicaciones de consulta y personales. Normalmente son el modelo resultante
de las aplicaciones de diseo rpido (RAD).

As, en el cliente se incluyen, adems de la lgica de presentacin, la lgica de
control, la mayora de la lgica de proceso y de negocio (toda en muchsimos
casos) y toda la lgica de datos excepto algn procedimiento catalogado.

Los sistemas fat client necesitan mquinas clientes muy potentes. Son fciles de
programar y de administrar. Sin embargo son escasamente distribuibles con todos
los inconvenientes que ello supone. Adicionalmente, hacen que las mquinas
cliente se queden obsoletas ms rpidamente por rendimiento. Ello es debido a que
como la mayora de funciones se linkan en el cliente, cada vez que se compila el
programa con una versin nueva de compilador y/o sistema, el programa se hace
ms pesado. Adems, aadir funciones sencillas desde el punto de vista funcional
puede suponer un aumento importante de las necesidades del cliente sobre su
mquina.

Proporcionan flexibilidad y oportunidades para crear aplicaciones con herramientas
de alto nivel (programacin visual, 4GLs, 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
deberan ser avanzadas y estn, por desgracia, mal diseadas.

Cuando la carga del proceso se delega en servicios se habla de clientes ligeros
como tcnica para integrar las funciones cliente. Hablaremos de este tema al final
del la metodologa de diseo en el capitulo dedicado a la integracin de la parte
cliente.

4. Fat Server.

Aqu, los servidores asumen el mayor peso de la aplicacin.

Exigen personal mucho ms formado, pero son ms fciles de manejar y ms
adaptables. Obviamente son ms difcil de disear y integrar que las aplicaciones
fat client. Pero, es mucho ms 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 bsicamente la lgica de presentacin y minimiza las lgicas
de proceso y datos.

Finalmente la presencia de muchos servidores facilita de reingeniera de sistemas y
la reutilizacin y adaptabilidad a la evolucin.

Son ejemplos de aplicaciones fat server: sistemas de venta al pblico, transporte,
Workflow, multimedia, transacciones distribuidas, integraciones de Servicios WEB,
etc.

5. Fat Client o Fat Server?

La distribucin del peso de la aplicacin entre clientes y servidores no es
axiomtica. Cada modelo tiene su uso y la presencia de sistemas hbridos en lo
normal.

Como ya hemos hablado, las aplicaciones de consulta y en general los modelos de
datos sin demasiada lgica 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 mtodo de diseo avanzado.

Muchas veces deber elegir segn la formacin de su personal. No intente crear
aplicaciones fat server si su organizacin no est formada.

En general las aplicaciones fat server son ms caras inicialmente pero ms baratas
a la larga si se trabaja convenientemente la reusabilidad. Si usted intuye o sabe que
su aplicacin tendr evoluciones importante, prime fat server; al final seguramente
ahorrar costes. Por el contrario si su aplicacin es de usar rpidamente y no ha
de tener evolucin, prime fat client.

Puede haber condicionamientos que marquen una arquitectura determinada. Por
ejemplo, si Vd. tiene PCs cliente no muy potentes y no puede cambiarlos o su no
conoce exactamente como sern sus mquinas cliente, habr de primar fat server.
En el primer caso, sin cambiar los clientes podr colocar un par de mquinas
servidoras potentes donde localizar los servicios. En el segundo caso, exigir
menos mquina a sus desconocidos clientes.

El coste de administracin es algo mayor en aplicaciones fat server, pero queda
compensado por la agilidad que proporciona, factor de difcil cuantificacin.

A modo de resumen global, fat client permite obtener resultados ms rpidos a
cambio de diseos muy convencionales y fat server permite un diseo mucho ms
gil y modular a cambio de un nivel ms alto de los desarrolladores y de una mayor
inversin inicial. No es una eleccin de blanco y negro sino de tonos de gris.

Diseo y Programacin de Clientes.

1. El cliente y sus atributos bsicos.

Recordemos que el cliente es el elemento que pide el
servicio para obtener la funcionalidad o los datos. Su
posicin en la comunicacin C/S es preactiva, es decir,
que hace la peticin y recibe la respuesta. Y que
normalmente lo representaremos por el smbolo de la
figura.

Recordemos que la ficha de sus atributos bsicos es:

Atributo Comentarios
Actitud Preactiva, inicia el dilogo
Ejecucin Arrancar y acabar.
Diseo Segn la lgica de la aplicacin
Finalidades bsicas Mantener el dilogo con el usuario:
Mens.
Gestin de las GUIs.
Validacin del dilogo con el usuario.
Ayudas a la operacin.
Ayudas de sistemas expertos.
Gestin y recuperacin de los errores.
Construccin de las salidas por pantalla e
impresora.
Manipulacin de datos.
Etc.
Utiliza Los servicios del Middleware.
Los servicios de los servidores genricos.
Los servicios de los servidores de aplicacin
Ha de evitar Comunicaciones entre clientes.
Cualidades deseables Transparencia.

2. Diseo del Cliente.

El diseo del cliente ser el pegamento que utilizando los servidores y la
especificacin de la parte de la funcionalidad que el diseo 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 creacin, diseo y reutilizacin de
Framework. Estos Framework se utilizarn como armazn para incrustar el resto de
piezas y las llamadas a los servidores. Potncielos siempre que pueda ya que,
como se ya visto en el captulo de reusabilidad, tiene todas las ventajas hacerlo as.

Vamos a dedicar a continuacin algunos apuntes de como disear y programar
clientes dentro de un entorno C/S.

Figura 67. Smbolo
del
Cliente

3. Las lgicas en el diseo del cliente.

Dentro de la primera parte hemos trabajado con la clasificacin convencional de
considerar un programa distribuido en tres lgicas: presentacin, proceso y datos.

En las aplicaciones actuales, en las que la programacin por eventos es muchas
veces la base, es mejor trabajar el programa con cuatro lgicas: presentacin,
datos, control y negocio, siendo estas ltimas el desglose por su funcin de la
tradicional lgica de proceso.

3. 1. Lgica de Presentacin.

Se encarga de interaccionar con el usuario. Implementada normalmente por
tcnicas GUI.

3. 2. Lgica de Datos.

Se encarga de gestionar los datos. Es muy habitual que si la lgica de datos no
est encapsulada en servidores especializados, acte a travs de ODBC y
SQL.

3. 3. Lgica de proceso.

Se encarga de proporcionar la funcionalidad. Incluye la lgica de control y la
lgica de proceso.

3. 4. Lgica 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
lgicas de proceso y de datos. Puede delegar mucha funcionalidad en
servidores (fat server) o poca (fat client).

3. 5. Lgica 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 ms
generales, como por
ejemplo, una
encriptacin.

Usuario
CLIENTE
Lgica de Presentacin
Lgica de Proceso
Lgica de Datos
Lgica de Control
Lgica de Negocio

Figura 68. Lgicas y Programas Cliente
Es muy habitual que la lgica de negocio acabe llamando en muchas
ocasiones a la de datos.

Los conceptos ligados a estas lgicas 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 disee su programa cliente separe y encapsule claramente las cinco
lgicas. Las cinco lgicas han de ser independientes entre si, incluyendo la de
proceso que incluyen las de control y negocio

La relacin entre las lgicas ha de ser con filosofa transaccional. Tiene dos vas
para conseguirlo:

O Llamada a rutina, intercambiando el mensaje en los parmetros 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 metodologa puzzle.

Qu conseguir adems de la satisfaccin de trabajar bien?

Razonmoslo. Como ya hemos presentado anteriormente, en algn momento habr
de decidir que parte de la aplicacin se instala en clientes y cual en servidores. Y ya
hemos visto y adelantado que la decisin estar llena de matices grises que
inclinarn con muy poca fuerza en un sentido o en otro.

Trabajar con lgicas independientes y comunicadas transaccionalmente le permitir
corregir fcilmente decisiones equivocadas. O decisiones en las cuales el paso del
tiempo y/o la evolucin de su empresa han cambiado el tono del gris y ahora le
inclinan a colocar la funcin en la otra parte.

Podramos 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 lgica de seleccin 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 muchsimos) que tienen esa seleccin. Si ha hecho una pieza
le bastar modificar la pieza y volver a compilar los programas clientes que la
usen.
O Cuando cre una aplicacin, la lgica de eliminacin de un producto de la BD
(que no tenga pedidos pendientes, que no tenga movimientos de stock, que
no tenga stock, etc.) slo se utilizaba una vez y por esa razn 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 delegacin 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
lgica 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 Delegacin.
O Su instalacin trabaja con una placa de encriptacin por hardware. Cuando
usted est diseado 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 fantstica aplicacin le ensean el entorno y cae en la cuenta de
que habr ms de un ordenador ejecutando el mismo programa y que slo ha
comprado una de esas carsimas placas de encriptacin. Rpidamente
convierte la pieza de la rutina de encriptacin en un servidor y, con suerte,
nadie se habr dado cuenta. Naturalmente que este caso es anecdtico 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 confesin pblica de mi pecado.

4. Metodologas para disear la arquitectura del cliente.

Aunque el tema se tratar con mucha profundidad ms adelante al hablar de la
integracin del cliente, es conveniente tener unas nociones sobre este tema antes
de hablar de metodologas de diseo. Este es el objeto de este apartado.

Segn que lgica tome la iniciativa hay tres formas o metodologas de enfocar el
diseo de cliente:

4. 1. Basado en la lgica de presentacin

La iniciativa la toma el usuario a travs de una interfcie GUI. La lgica de
proceso se va llamando al ritmo que marca el usuario. La lgica de datos es
controlada por la de proceso.

Las interacciones del usuario sobre la lgica de presentacin son las que
marcan la secuencia de ejecucin. Las interfcies grficas se construyen por
integracin de controles. Y los controles se gestionan por eventos. Por esa
razn, es un modelo de diseo basado en una sucesin de eventos. As, las
tcnicas de programacin basadas en eventos estn fuertemente favorecidas
en clientes de este tipo.

Como el control de la secuencia de ejecucin la lleva el usuario, el diseo ha
de encapsular comportamientos y secuencias de ejecucin inadecuadas,
liberando al usuario de esa responsabilidad. Por ejemplo, una tcnica habitual
ser poner los controles de la interfcie grfica que en ese momento no sean
semnticamente activos en deseable y los controles que no tengan sentido
para ese proceso o usuario en hide.

El programa debe proporcionar ayudas y guas al usuario para facilitarle su
trabajo y minimizar el trabajo de documentacin escrita. Si lo hace bien, y se
apoya en la operativa estndar 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 recuperacin de los errores dramticos.

4. 2. Basado en la lgica de proceso o de control.

La iniciativa la toma la lgica de control que slo pide la actuacin del usuario,
a travs de la lgica de presentacin, cuando se necesita. La lgica de datos
es controlada por la de proceso.

La lgica de procesos determina el ritmo de ejecucin de los diferentes
procesos, clientes o servidores, y realiza la preparacin y salida, grfica o no,
de los resultados.

Dentro de este modelo de integracin de las funciones del cliente estn Batch,
Publicacin / Suscripcin y Workflow, que se tratarn en otros captulos
posteriores dedicado a la integracin de la parte cliente y que tiene un enfoque
muy superior a la visin simple de un programa.

4. 3. Basado en la lgica de datos.

Son metodologas basadas en bases de datos activas de alto contenido
semntico y el diseo del cliente se basa en la lgica 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 impresin.

5. Diseo de la lgica de presentacin.

Este es un tratado de diseo distribuido, no de interfcies grficas. Pero no se
puede obviar el hecho de que la mayora de los programas cliente / servidor e
Internet estn basados en la gestin de una interfcie grfica. Por esa razn,
dedicar ms adelante unos captulos ha explicarle como veo yo el tema.

Sin embargo, para atacar la parte de diseo en condiciones conviene hace algunas
pequeas reflexiones sobre como organizar una GUI en condiciones.

La lgica de presentacin se implementa en todos los caso en interfcies grficas,
Windows o Internet. Como ambos entorno presentan en la base las mismas
prestaciones nos referiremos en general simplemente como interfcie grfica o GUI.
Particularmente no me gusta la terminologa castellana IGU (interfcie grfica de
usuario).

Hay dos formas bsicas de hacerlo:

5. 1. Tcnicas GUI (Grafic User Interface).

Son las habituales y sobradamente conocidas.

Hay dos modelos:

Windows.
Internet.

5. 2. Tcnicas OOUI (Object Oriented User Interface).

Las lgicas de presentacin y proceso pueden montarse juntas o no.

OOUI es una tcnica que consiste en separar la lgica de presentacin como
una pieza independiente, generalmente OO, separada de la lgica de proceso
como un cliente

La lgica de presentacin y la de datos puede estar localizada incluso en otras
mquinas fsicas, locales o remotas. Si los programas OOUI y el, o los, que
llevan la lgica de proceso han de correr en la misma mquina, es obligatorio la
presencia de un sistema multitarea eficiente. Tranquilo, hoy da todos los
habituales lo son.

Es prcticamente obligatorio usar tcnicas OO para montarlo.

Es un montaje muy interesante dentro de aplicaciones fat server.

Dentro de la lgica de presentacin, un tema interesantsimo es la verificacin de
los datos registrados por el usuario en la interfcie.

Qu le parece, la verificacin, es lgica de proceso o lgica de presentacin?
Segn la respuesta que d a esta pregunta deber incluir en una u otra lgica de su
programa.

O Si la incluye en la lgica de presentacin:
O Ventaja: La transaccin de entrada sale validada.
O Inconveniente: Parte de la lgica de proceso, que puede repetirse en
otros programas queda ligada a la interfcie.
O Si la incluye en la lgica de proceso:
O Ventajas: La verificacin puede encapsularse en una pieza. Se
corresponde al modelo MVC de OO.
O Inconveniente: La transaccin no sale validada de la interfcie.

Que hacer, pues? Le voy a dar un consejo basado en la experiencia. Dado que es
muy difcil dar criterios para decidir cual es la mejor solucin (tcnicamente es
mejor la segunda pero es ms clara la primera), vacnese cogiendo el camino del
medio. Incluya todas las verificaciones en piezas. Y llmelas desde la lgica
de presentacin.

El camino es todava mejor si trabaja en OO. La verificacin se encapsula en
mtodos asociados a los objetos gestionados por la interfcie. Adems con la
herencia y el polimorfismo podr obtener un grado altsimo de reusabilidad.

6. Clientes Background y Agentes.

Un programa Background es un programa, que una vez arrancado, realiza su
trabajo sin establecer dilogo con un usuario. Recibe sus parmetros de ejecucin
desde otros programas o desde el sistema.

Parece difcil 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 ejecucin
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 activacin 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 facturacin en el cual el cliente recibe ordenes de facturar por
diferentes vas:
O Una cola con las confirmaciones de salida de almacn.
O Venta directa desde punto de atencin directa al cliente.
O Los porttiles 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 ms, en muchas ocasiones, los clientes Background sirven como interfcies 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 podra ser perfectamente un servicio. Le suena? Efectivamente,
acabamos de encontrar un Agente.

La diferencia entre clientes background y agentes no es radical y se disean 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
ms, muy confuso).
O El agente est siempre activado. El cliente puede estarlo o no (confuso).
O El cliente Background puede llevar un mnimo de lgica de presentacin. Este
criterio si que es claramente diferenciador ya que la imagen grfica que puede
asociarse a un servidor no supone en ningn caso la presencia de lgica.
O El cliente back-ground realiza la gestin de errores interactivamente, el agente
informa un loging de errores y los enva al centro de control de errores del
centro de administracin que tiene asignado (diferencial)
O El servidor da respuesta a una peticin. El cliente Background normalmente
no (otro criterio claro).

Cuando hay comunicacin desacoplada para la peticin de un servicio la llamada la
recibe casi siempre un agente ya al ser la comunicacin desatendida el modo de
trabajo del agente tambin debe serlo.

De cualquier forma, los clientes background no son ms que una forma de
obtener servicios por lo que la discusin para distinguir entre ellos y los
agentes en las aplicaciones distribuidas modernas en las cuales se trabaja
con servicios que, en muchas ocasiones, no sabes donde estn ni quien los
suministra, parece como mnimo banal.

7. Que necesita el programa cliente del Netware Operating System (NOS).

El programa cliente necesita del sistema operativo de red como mnimo los
siguientes servicios:

O Sistema de localizacin, dilogo y comunicacin con los servidores.
O Formatos estndar.
O Mecanismos de transferencias de ficheros y datos.
O Siempre que sea posible, y muchas veces de forma obligada, multitarea en la
mquina cliente.
O Soporte grfico.
O Etc.

8. Transportabilidad y transparencia del cliente.

La transportabilidad y transparencia del cdigo cliente se deriva habitualmente de la
transportabilidad del lenguaje de programacin utilizado. Existe un peligro
inesperado y sorprendente que nunca debera 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 idneo para la mayor parte de los
programas cliente y haga muchos nmeros antes de utilizarlo. Le quedarn otros
productos que si sern transportables dentro del paraso del Sr. Gates. Con eso, y
con las cuotas de mercado de Microsoft, probablemente tendr bastante.

Una opcin cada vez ms pujante es utilizar JAVA que permite programas desde
programas cliente a servidores y hasta terminales mviles 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. Ms que suficiente, sin embargo, en muchsimos casos.

9. Herramientas de desarrollo para la parte cliente.

No pretendo aqu, bajo ningn concepto, hacer una lista exhaustiva de estas
herramientas. Solo quiero familiarizarle con la tipologa de las ms habituales. En
este sentido lea este apartado. Evidentemente los grupos no son excluyentes y
existe un solape cada vez ms importante entre ellos.

9. 1. Herramientas profesionales.

9.1.1. Herramientas de desarrollo rpido (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 confeccin 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 gestin de datos. Tienen
productos de este tipo INFORMIX y ORACLE. Tambin puede usar el
histrico 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 informacin de
consulta con autonoma del los sistemas informticos estables.

9.2.1. Hojas de clculo y otros recursos de los paquetes de ofimtica.

Es sorprendente la universalidad del EXCEL.

9.2.2. Bases de datos tipo Access.

Que adems de poder definir sus propias bases de datos relacionales,
permiten adjuntar tablas de otros motores relacionales donde estn los
datos corporativos o departamentales a consultar.

En mi opinin es una opcin confusa. Necesitan un mnimo de
conocimientos de lgica de programacin. Formacin de la que no
dispone un usuario avanzado. Y un informtico 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 lnea de ORACLE y SAP.

Poco usados ya que, aunque potentes, no compensan la falta de
formacin y especialistas en contra de la universalidad de la Ofimtica
del Microsoft.

Diseo y Programacin de Servidores.

1. El servidor y sus atributos bsicos.

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 bsicos es:

Atributo Comentarios
Actitud Reactiva, espera la llamada.
Ejecucin Continuada
Diseo Especializado
Finalidades bsicas Proporcionar servicios funcionales y de datos.
Datos corporativos.
Tratamientos especficos.
Reglas de negocio
Comunicaciones compartidas.
Ficheros.
Servicios de impresin.
Fecha y hora, etc
Distribuir el sistema
Ha que est obligado A esconder su implementacin
Utiliza Los servicios del Middleware.
Ha de evitar Comunicaciones con otros servidores de forma
anrquica.
Cualidades deseables
Transparencia.
Reusabilidad.
Re-localizacin.

Conviene tener presente tambin en este momento el concepto de localizacin.

2. Fundamentos del diseo de servidores.

2. 1. Fundamentos del diseo de servidores.

Es especializado a la tarea asignada.
A efectos C/S no importa el diseo interno. Se coge como una pieza
construida que esconde los detalles de su implementacin.
Ha de establecer un modo de comunicacin con sus clientes.
Se ha de controlar la gestin de errores.
La forma de ejecucin puede ser:
Est arrancado siempre, opcin normal.

Figura 69.
Smbolo
del
Servido
r
Arranca a peticin.
La forma de arranque puede ser:
Dinmica: por otros programas.
Esttica: por parametrizacin del sistema, opcin normal.

2. 2. Condicionamientos de diseo.

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 diseo, 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 lgicas y el diseo de servidores.

Al hablar de programas clientes, presentamos las cinco lgicas necesarias para
disear un programa, presentacin, datos y proceso, incluyendo esta ltima la
lgica de control y la lgica de negocio.

En ningn momento hay que olvidar que la gran mayora de servicios son
programas y que por tanto tendran posibilidad de participar de las todas las
lgicas.

Por el concepto de servicio, la lgica de presentacin no es aplicable a servidores.

Las lgicas de datos y negocio son muchas veces la justificacin del propio servicio
que se ha diseado para proporcionarlas.

Pero, cuando un servidor necesite de otros servicios para completar su funcin,
cosa muy habitual y que es el fundamento de la Arquitectura de Servidores, el
propio servicio usar lgica de control.

4. Multiservidores y paralelismo.

La utilizacin de multiservidores ya hemos
dicho que es una herramienta potente y
escalable de la capacidad de servicio.

El diseo de un servidor como multiservidor
supone darle la capacidad de que pueda
trabajar ms de una instancia o copia
simultneamente del servidor.

La posibilidad y la facilidad tcnica para
hacerlo es hoy da notable si se utilizan las
tcnicas multihilo que proporcionan la
mayora 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 sincronizacin entre procesos, que como cualquier informtico que se precie
sabe, no es ninguna simpleza.

Figura 70. Servidores multicliente
multiservidor

Si el servicio es idempotente, es decir, la peticin 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
fcil y relajado. Si el servicio no es idempotente, la travesa puede convertirse en
una turbulenta experiencia si el programador del servidor no conoce la problemtica
y tecnologa de la programacin concurrente.

Estas tcnicas 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 programacin: los modernos disponen de l.
O Un sistema operativo multitarea: todos los son.
O Mecanismos implementados en cada servidor para coordinar la ejecucin
simultnea de los servicios no idempotentes de los hilos.

5. Qu necesita el servidor del NOS + DSM?

O Disponer de gestin multitarea, incluyendo mecanismos de interconexin de
programas, en el nodo.
O Tiempo compartido.
O Prioridades
O Semforos
O Comunicaciones interprocesos (IPC), local y remota.
O Interrupciones por eventos para gestionar las esperas.
O Proteccin intertareas.
O Gestin eficiente de la memoria.
O Linking dinmico.
O Servicios extendidos (Extended Services).
O Comunicaciones transparentes.
O Servidores de ficheros y de impresin transparentes.
O Servicios globales de naming, directorio y localizacin.
O Autentificacin y autorizaciones.
O Disponibilidad y parametrizacin.
O Gestor de objetos distribuidos.

Finalmente citar que cuando faltan servicios de sistema puede optarse por dos vas:

O Valorar la posibilidad de substituirlos por otros.
O Substituirlos por programacin propia. En este caso se ha de trabajar con el
modelo real de Middleware que se present en el captulo de la integracin.

6. Implementacin y programacin de servidores.

6. 1. Programacin.

Los servidores distribuidos (universales) se implementan habitualmente en
entornos C++. Tamben el viable la utilizacin de Java.

Los servidores distribuibles mediante la utilizacin 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 ms del
Middleware.

6. 2. La cara del servidor.

Aunque por definicin, un servidor no debe interaccionar con los operadores,
es bueno que en entornos grficos, 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 Logs.
Estadsticas de uso.
Etc.

Le recomiendo, por el grado altsimo de utilizacin de un servidor, que haga su
GUI espectacular. Pero siempre en los momentos de no ocupacin o de inicio
o final de un proceso. Si no lo hace as, perder un tiempo de proceso
innecesariamente.

Puede delegar la actualizacin a un hilo con la prioridad ms baja.

6. 3. La ficha de enviroment del servidor.

Una tcnica muy til para parametrizar las caractersticas estticas y dinmicas
de trabajo de un servidor es asignarle una ficha de enviroment.

En la ficha se incluirn todos los parmetros de funcionamiento del servidor
susceptibles de ser parametrizados.

Le recomiendo dos niveles por parmetro:

Un primer nivel ligado a una variable lgica para decir si la opcin est
activa o no
Si el parmetro est activo, los mrgenes cualitativos y cuantitativos de
funcionamiento.

Por ejemplo, usted desea personalizar si un servidor debe estar
permanentemente activo consultado una cola de comunicacin 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 mquina donde reside el servidor.

En el primer nivel habr una variable lgica con la semntica de vigilia
permanente o no. Si la opcin est personalizada a que el servidor no debe
estar permanentemente activo, necesitar dos parmetros ms de
parametrizacin: tiempo sin trabajar para ponerse a dormir y tiempo de
inactividad durante el cual es servidor dormir. Una opcin tambin podra ser,
si su Middleware lo permite, despertar con un evento de trabajo pendiente
lanzado por el cliente o por el servidor de cola de comunicacin.

De forma resumida, se coloca en la ficha todo aquello de inters para la
configuracin, localizacin y administracin del servidor.

Se pueden incluir parmetros del tipo:

Localizacin por defecto.
Tipo de arrancada permitida.
Tiempos de sleep cuando no esta operativo (recuerde el ejemplo
anterior).
Tipos de desconexin.
Dispositivos fsicos por defecto.
Parmetros funcionales por defecto.
Criterios de los parmetros de recuperacin de errores.
Niveles de accesibilidad.
Grabacin opcional de un loging de funcionamiento para analizar
problemas y / o rendimientos, etc.

La implementacin 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 opcin combinndola con al segunda. Por ejemplo puede
montar la jerarqua:

Si hay fichero de inicializacin manda su parametrizacin.
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 especificacin.

Para mantener el fichero *.INI o *.XML puede usar un editor, o si la semntica
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
parametrizacin ser as esttica.

Puede pensarse tambin en un parametrizacin dinmica, es decir, que el
servidor lee `permanentemente su ficha para rescatar algunos parmetros
que pueden cambiar en caliente. Esta tcnica es ms costosa en perdida de
rendimiento que en coste de programacin y solo debe usarse en situaciones
que realmente lo requieran y con control y medida.

6. 4. Como conseguir independencia del sistema.

Para conseguir que un servidor sea distribuido no basta con que est escrito en
C. Es conocido que hay funciones (como modificar la fecha y la hora del
sistema o el tratamiento de los canales serie) que tienen APIs 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 problemtica utilice un
diseo del servidor de forma que la parte dependiente se
incluya en rutinas encapsuladas. As, podr pasar de unos
sistemas otros sin ms que cambiar la implementacin de
esas rutinas.

Existen diversas formas de integrar la parte dependiente:

Una versin para cada sistema personalizada en
fase de link.
Una versin nica para todos los sistemas personalizados. Una variable
de la fecha de enviroment (si no es posible hacerlo automticamente)
decidir que sistema es el que localiza al
servidor.
Una versin nica del servidor que delega a otro
servidor la parte dependiente. En cada sistema
se instalar la versin distribuidle a ese sistema
de la parte dependiente. Ha organizado una
arquitectura de delegacin que le presentar
seguidamente.

Si me deja escoger, prime la segunda opcin.

Cdigo independiente
del sistema
Cdigo dependiente
del sistema

Figura 71. Servidores
dependie
ntes del
sistema
Cdigo
independiente del
sistema
Cdigo
dependiente
del sistema
D

Figura 72. Implementacin
por delegacin.
Arquitectura de Servidores/Servicios.

1. Introduccin.

Conviene recordar antes de empezar este captulo, que hace ya muchas pginas
que hemos dejado de tratar a los servidores como proveedores nicos de servicios.
Existen tambin los agentes.

Sin embargo, por razones histricas, de brevedad y por que la comunicacin con
agentes acostumbra a ser desacoplada y por traspaso de responsabilidad, se sigue
hablando de servidores. Excepto que se diga lo contrario, en este captulo, un
servidor es cualquier suministrador de un servicio y utilizaremos el trmino servidor
en este contexto ampliado.

Por ello, los trminos Arquitectura de Servidores y Arquitectura de Servicios sn
equivalentes.

Los clientes se comunican con los servidores para pedir sus servicios. Pero los
servidores tambin se apoyan en otros servidores para conseguir proporcionar esos
servicios. Se convierten as en clientes realizando un polimorfismo de roles.

En la filosofa de especializacin que supone el diseo basado en servicios es poco
menos que esperable que esto ocurra.

Pero la comunicacin entre los servidores, como ya se ha visto, no puede ser
anrquica. Ha de estar estructurada y modelada. Y dentro de los posible, cuasi-
jerrquica.

Que modelos pueden utilizarse es el tema que vamos a tratar en este captulo.

2. Multiserver Data Flow.

Sucede frecuentemente que:

O Un servidor necesita de otro para completar su funcin. Por ejemplo, un
servidor de comunicaciones necesita de otro de encriptacin antes y despus
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 ms alta. Por ejemplo, un para conocer la fechas de entrega
estimadas de un albarn

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
informacin (peticiones y respuestas) que se genera entre ellos.

La arquitectura de servidores constituye el componente esttico y fundamental
siendo la plataforma sobre la que se genera el flujo, componente dinmico, que
superpuesto a la arquitectura da lugar a hablar del concepto de Multiserver Data
Flow.

Hay dos modelos bsicos.

2. 1. Modelo dirigido por el cliente.

El cliente lleva el control de la relacin entre los servidores y, por tanto, de los
mensajes que han de intercambiarse.

Obliga al cliente a conocer la arquitectura del dilogo, lo que va fuertemente en
contra de la transparencia, la modularidad, la reutilizacin 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 contraposicin con el modelo interservidores, se sola recomendar
en aplicaciones con servidores muy independientes.

Yo no voy a entrar en este modelo. Mi opinin personal es que no debe
utilizarse nunca.

2. 2. Modelo dirigido por los servidores (interservidores).

En la idea de transparencia y reutilizacin, 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 estructuracin de los servidores entre si es lo que da
lugar a hablar de Arquitectura de Servidores.

El cliente solo tiene que conocer la especificacin de un solo servidor: aquel al
pide el servicio completo.

Adems, si se disea as, la adaptabilidad a los cambios y la modificacin son
mucho ms fciles.

Las ventajas me parecen tan obvias, que no quiero extenderme ms.

3. Concepto de Arquitectura de Servidores.

Este ltimo punto no difiere de los modelos de comunicacin entre clientes y
servidores que ya se han tratado ampliamente con anterioridad.
Hablar de Arquitectura de Servidores es, pues, hablar de:

O La tipologa de su comunicacin.
O La estructura funcional que las llamadas establecen entre ellos.
O Del modelo de comunicacin que utilizan.

La arquitectura de servidores constituye el componente esttico y fundamental
siendo la plataforma sobre la que se genera el flujo, componente dinmico, 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
lgica de control en el servidor.

Le presento a continuacin las tipologas de comunicacin ms frecuente.

4. Delegacin de Servicio o Orquestacin

La Delegacin de Servicio (Subrrogate Clients) es una tipologa de
relacin consistente en que un servidor llama a otro desde la misma
posicin y con las mismas reglas que utilizara un cliente en su
posicin. Hoy dia, en el mundo SOA, esta arquitectura se conoce
tambin como orquestacin.

El servidor simplemente asume el rol de cliente y establece un dialogo
Cliente/Servidor convencional.

La funcin del servidor delegado es aadida a la del servidor llamado por el cliente
de forma totalmente transparente a aquel.

Dilogo
cliente/servidor
Servidor
A
Servidor
B
Cliente
D

Figura 73. Delegacin de Servicio

La delegacin de servicio es la relacin por defecto entre dos servidores, de
forma que si es un esquema no se incluye la relacin se asume que es por
Delegacin.

D

La arquitectura entre servidores se define en dos componentes:

O Esttica, el modelo de arquitectura establecido en el diseo.
O Dinmica, el formato de los mensajes de comunicacin que se establecen
y la secuencia en que se intercambian.
En la figura se muestra
un ejemplo de
Delegacin 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 delegacin
con varios niveles. Se conoce como profundidad de la delegacin el nmero de
capas delegadas. Particularmente, creo que es un dato sin ningn inters. Disee
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 gestin de errores. Como conceptualmente los
errores han de ser tratados en los clientes, los errores generados en las capas
ms profundas han de ser trasladados hacia arriba ordenadamente y sin
perdida de contenido semntico e integrando por afinidad. Esto exige siempre
un esfuerzo del diseador.

Hablamos de mantener contenido semntico en el sentido que si una capa da error
de conexin 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 cdigos, idiomas o textos diferentes, el
error generado debe ser nico.

Adems del flujo hacia arriba de los errores, las tcnicas de delegacin o
subrogacin, tiene ms o menos problemas es funcin de la complejidad del
proceso.

Por ejemplo, dentro de una arquitectura de modificacin de datos, un servidor local
de datos, paralelo al de altas del ejemplo anterior, modifica su copia e inicia, por
delegacin, la actualizacin de la copia de la central. Garantizar la coherencia de
los datos con esta delegacin de servicio no es trivial. Por el contrario, si la
delegacin se hace para pedir, por ejemplo, una encriptacin, la complejidad de
este proceso es prcticamente nula.

Si la delegacin de servicio se hace de forma asncrona el problema puede
complicarse aun ms ya que el servidor en la posicin cliente ha podido hacer
muchas ms 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 delegacin de Servicio
El tema no es fcil pero, por favor, no caiga en la trampa de los malos informticos
y eluda el problema no utilizando delegacin (cargar de proceso innecesario y
replicado a sus clientes) o haciendo siempre la delegacin sncrona.

5. Arquitecturas con mensaje anexo.

En una arquitectura de delegacin la peticin y la respuesta viajan
entre el cliente el/los servidor/es. Si el tamao de los datos de la
respuesta o la peticin es grande o de tamao 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 delegacin. La utilizacin
de la peticin y la respuesta para codificar completamente el mensaje proporciona
tambin una cierta rigidez al diseo ya que, en caso de tener que cambiar algo, hay
que modificar cdigo.

La solucin pasa por establecer una arquitectura de mensaje anexo entre los
servidores de forma que la respuesta o la peticin viaje directamente hasta o desde
el cliente.

Obviamente, este tipo de comunicacin puede utilizarse con cualquier otra
arquitectura por lo que el mensaje anexa cualificaro a la arquitectura base y en los
esquemas aparecern dos iconos, la notacin de respuesta anexa (X) y la que
corresponda a la arquitectura base.

El flujo de informacin en el caso de
respuesta anexa es:

1. Peticin del cliente al servidor.
2. El servidor realiza su trabajo y
coloca la respuesta en un
almacn temporal de
respuestas (a).
3. El servidor enva la respuesta al
cliente con un localizador:
3.1. El almacn 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 localizacin del almacn puede estar pactada en la configuracin del servicio.
(c) El nombre puede ser la referencia de la peticin o un criterio preestablecido

Obviamente, el caso de peticin por mensaje anexo es totalmente paralelo y el
mensaje puede ser anexo tanto en peticin como en respuesta.

La opcin ms interesante, actual y fcil de implementar una arquitectura de
mensaje anexo es que el mensaje almacene la respuesta y/o la peticin en una
zona de memoria (implementacin bsicamente temporal) o disco (implementacin
bsicamente persistente) visible por todos los actores que se traspasan un
localizador como parte de la respuesta o peticin.
1. Peticin
Servidor Cliente
2. Servidor
coloca
respuesta
3. Respuesta
Almacn
respuestas
4. Cliente
decide si le
interesa la
respuesta
5. Cliente
recoge
respuesta si
le interesa

Figura 75. Arquitectura de Respuesta Anexa
X

La arquitectura de mensaje anexo es especialmente interesante en situaciones en
las cuales un servidor necesita dirigir una respuesta de un volumen alto a otro
servidor antes de enviarla al cliente.

Para que el cliente decida si la respuesta le interesa o no, puede incluirse en la
respuesta un mecanismo para cualificar la respuesta o la peticin. Este modelo se
conoce como respuesta anexa condicionada. As, si queremos dar posibilidad al
cliente de recoger o no, en funcin de su inters o necesidad, la parte extensa del
mensaje, podemos incluir en la respuesta normal la informacin necesaria para
saber si el resto de la respuesta, almacenada en el almacn, 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 trficos de lnea y el
rendimiento. Si el almacn de respuestas tiene permanencia, el cliente deber
eliminar la respuesta o el servidor deber disponer de un mecanismo de eliminacin
por caducidad.

Por ejemplo, imagine que quiere saber si hay cambio de tarifas en un solo paso.
Lanzar una arquitectura de delegacin 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 opcin
muy interesante: la
arquitectura de respuesta
anexa condicionada en la
cual el contenido de la
respuesta se calcula una sola
vez y es vlido entre dos
fechas de vigencia.
Imaginemos el ejemplo
anterior y que muchos
clientes estn pidiendo la
misma tarifa. Es obvio que conseguir la tarifa y todo lo que la envuelve no es rpido.
El servicio puede disearse 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 tambin que el servidor de correo utiliza arquitectura de mensaje anexo.

6. Traspaso de Responsabilidad.

El Traspaso de Responsabilidad es una topologa de relacin
que consiste en que un servidor traspasa a otro servidor, o
incluso a un programa cliente, la responsabilidad total del
servicio pedido. La semntica de la relacin 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 Delegacin con Mensaje
Anexo
T

Esto es as debido a que, por la tipologa de la relacin, el servidor que traspasa
pierde el control del servicio.

El traspaso de responsabilidad es como una especie de interfcie resuelta por
una comunicacin asncrona desacoplada.

Es la opcin por defecto cuando se llama un servicio como agente a travs de
comunicacin desacoplada. Por esta razn 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 delegacin.

En la figura se
muestra un ejemplo
de traspaso de
responsabilidad
donde se modela una
aplicacin de recogida
de pedidos.

La captacin de los
pedidos se hace por
Internet o por telfono
y se registra sobre un
Servidor de Pedidos
que delega a otro
servicio, normalmente
un agente, la funcin
de traspasar el pedido
a la tienda ms
cercana a la situacin
del cliente. Este
servidor localiza esa tienda y traspasa el pedido a su cola de pedidos.

La delegacin 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 asncronamente de llevarlo a buen fin.

Se habla a veces de traspaso de responsabilidad sncrona. Ese caso lo vamos a
denominar redireccin y la tratamos en el apartado siguiente.

7. Redireccin.

La redireccin se produce cuando el cliente llama a un solo servidor
que decide que servicio fuera de l debe llamar. La eleccin se
realiza mediante lgica de control ya que puede depender del
estado del programa.
Servidor
Aceptacin
Pedido
Cliente
Captura de
Pedido
Directo
Cliente
R
R
D
Servidor
Aceptacin
Cliente RPC
T
Cola
Tienda 1
Cola
Tienda N
R
R
T
T
Cliente
Entrega
Pedido
Agente
Localizacin
Tienda ms
Cercana
Cliente
Captura de
Pedido
Telefnico
Servidor
Web

Figura 77. Ejemplo de una arquitectura de Traspaso de
Responsabilidad

A

Cuando ha tomado la
decisin, 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.

Obsrvese que una
redireccin tampoco es
una arquitectura de
distribucin ya que el
mensaje ya no vuelve al
servidor original.

En la figura se muestra dos ejemplos de redireccin. 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 validacin de los parmetros en
funcin del estado del sistema.

Es obvio que los dos ejemplos pueden combinarse entre ellos.

La redireccin en cascada consiste en una modificacin mediante
la cual los servidores se van pasando la peticin hasta que uno de
ellos la reconoce como suya y la atiende. La notaremos por el

8. Servidores Interceptores.

Es otra forma de indirecccin. 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
aceptacin, del estilo de verificaciones de seguridad, adaptacions de
formatos, etc, y lo traspasa a su representado.

9. Servidores Pasarela.

El servidor pasarela recibe la peticin de otro servidor o un cliente y
la traspasa en bloque a otro servidor.

El servidor pasarela realiza la adaptacin, de forma transparente a
quien lo utiliza y de la llamada, independizndolo del entorno. La pasarela puede
recibir llamadas y traspasarlas a entornos diferentes segn alguno de los
parmetros de la peticin.

Son una tipologa de arquitectura muy til para salvar heterogeneidades de
Middleware, principalmente sintcticas, pero tambin semnticas. La pasarela
encapsula esa heterogeneidad y dirige la llamada a otros servidores que hacen la
Servidor
A
Respuesta normal
Cliente
Gestin del error
Servidor
de
errores
Respuesta de error
Servidor
de filtro de
parmetros
A
Error de parmetros
Cliente
Parmetros correctos
Servidor
1
Respuesta correcta
Servidor
n
A

Figura 78. Ejemplo de una arquitectura de Redireccin

P

AC
I
misma funcin pero en entornos diferentes. Y siempre de forma transparente al
cliente que no llama.

Una utilizacin de inters es permitir el uso asncrono de servicios sncronos en
origen. El servidor recibe la llamada de forma asncrona y la traspasa y recibe de
forma sncrona.

En cuanto a la gestin de la respuesta y/o los errores, la pasarela realiza la funcin
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
informacin que
permite consultar la
catalogacin de
bibliotecas
dispersas
geogrficamente a
travs de una WEB.

La consulta, que se
implementa sobre
un programa cliente
integrado en un
componente de
presentacin Internet, dispone de dos servicios: una consulta a los ndices y una
ampliacin de la informacin. Un ndice actualizado peridicamente permite
disponer localmente de los libros catalogados en las diferentes bibliotecas. Cuando
el usuario localiza un libro de su inters, el sistema est pensado para que acceda
remotamente a la biblioteca en cuestin para conocer informacin ms detallada y
saber la disponibilidad de libro.

El usuario realiza sus peticiones a travs de una aplicacin 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 distribucin). La peticin de consulta ampliada
al servidor de localizacin se realiza con un formato de parmetros nico. El
servidor localizador realiza la pasarela hacia cada biblioteca, adaptando parmetros
y modo de comunicacin.

No hay que confundir delegacin y pasarela. Un servidor que delega tratamientos a
otro tiene incluida lgica 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 peticin, la dirige al servidor adecuado realizando
solo la adaptacin de los parmetros y / o el transportista. La lgica funcional
aadida por el servidor pasarela es mnima o inexistente. La lgica de control solo
gestiona la pasarela.
Servidor
Localizador
Cliente
Programa
ndice
Bibliotecas
Catlogo UPC
Catlogo VIC
Catlogo Colegio
P
R
R
R
P
P
Vas a los Catlogos
Servidor
Distribuidor
Servidor
de Consulta
a los
ndices
ndices
D
D

Figura 79. Ejemplo de una arquitectura de Pasarela

10. Broadcast Data Flows.

Es un tipo de arquitectura que consiste en enviar la peticin de
servicio a todos los servidores. Todos ellos examinan la peticin 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 informacin puede resumirse, pues, en los siguientes
pasos:

O El cliente lanza una
peticin 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 rpido. Es difcilmente escalable y poco seguro (todo el mundo ve todo). Y en
el fondo, no es ms que una forma encubierta de montar una comunicacin entre
iguales (pear-to-pear).

La tcnica puede ser de inters en tareas de sincronizacin, como por ejemplo, una
sincronizacin masiva de fecha y hora.

11. Arquitectura de Filtro (Filtered Data Flows).

B

Dilogo
Broadcast
Servidor
A
Servidor
C
Cliente
Servidor
B

Figura 80. Arquitectura de Broadcast.
F

En una arquitectura de delegacin en la cual la peticin o la respuesta respuesta
debe de pasar un filtro entre el servidor y el cliente. Normalmente el tamao 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 definicin del servicio. Todo lo dicho antes para este modelo de
comunicacin vale aqu.

Observe la figura donde se aplica un filtro a la
respuesta. El flujo de informacin es bsicamente as:

1. Peticin del cliente al servidor.
2. El servidor localiza la informacin.
3. Gestin de la respuesta
3.1. El servidor pasa la informacin o informa de
la localizacin de la respuesta al filtro.
3.2. El filtro enva la informacin al cliente.
4. El filtro avisa al servidor que ha acabado.
5. El servidor enva la notificacin 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
imgenes tiene la
informacin comprimida.
El servidor de obtencin
de imgenes al que llama
el cliente las obtiene del
servidor de imgenes y la
pasa a travs de una
arquitectura de filtro al
servidor de
descompresin.

12. Servidores Master-
Slave.

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

1. Peticin
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. Confirmacin
Almacn
respuesta
6. Cliente
recoge
respuesta

Figura 81. Arquitectura de Filtro
Servidor
Obtencin
Imgenes
Cliente
Tratamiento
de Imgenes
Imagen Compactada
BD
Imgenes
X
D
Servidor
Descom-
presin
Imgenes
S
F
Imagen Descompactada
D

Figura 82. Ejemplo de Arquitectura de Filtro
M

El flujo de datos en esta arquitectura es el
siguiente:

O El cliente enva la peticin a un
servidor que asume la posicin de
master.
O El servidor vlida la peticin e inicia
la ejecucin 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.

Adems, actualmente, montar estas tcnicas es muy fcil con las tcnicas 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 comunicacin
asncrona.

Un ejemplo de utilizacin
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
tcnica:

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 mquina servidora por el lanzamiento de un nmero
excesivo de Slaves en momentos de punta de servicio. Ello obliga en la
prctica a limitar el nmero de copias dentro de la ficha del servidor.

La tercera limitacin tradicional de la tcnica ya no lo es en la prctica. Master y
Slaves deben estar en la misma mquina lo que exige un sistema operativo
multitarea. Pero hoy da todos los sistemas lo son ya.

Aunque salgamos del tema de este capitulo, observe que la tcnica de Master-
Slave es aplicable a agentes para:

O Aumentar el nmero de instancias que trabajan simultneamente.
Cliente
Servidor
Master
Servidor
Slave
Peticin
Respuesta

Figura 83. Arquitectura Master-Slave
Servidor
Distribucin
listados
Cliente
Obtencin
Estadstica
D
M
Datos Listados
Servidor
Confeccin
Listado
Servidor
Impresin

Figura 84. Ejemplo de Arquitectura Master-Slave.
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 Distribucin.

Ya vimos una
arquitectura de
distribucin en el
captulo
dedicado a
Internet de la primera parte.

La distribucin se basa en que el
cliente pide servicios diferentes
a un nico servidor que se
responsabiliza de enviar la
peticin a cada servidor
especializado. La respuesta
vuelve de la misma manera.

Recuerde como ejemplo de distribucin 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
distribucin se usa para
resolver puntos de
singularidad. Por ejemplo:

O La conexin entre dos
entornos
interconectados pero
no interoperables.

La distribucin facilita el
diseo de situaciones como en control centralizado de accesibilidad de usuarios a
un grupo de servicios.

El uso de esta arquitectura tambin 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 Distribucin
R

Servidor
Distribucin
Cliente
Cambio
Tarifas
Servidor
Cambio
Tarifas al
Local
Tarifas Local
Cliente
Entrada
Cdigo
Cola
Peticiones
Servidor
de
Ficheros
R
Tarifas en Central
BD
Local
R
Servidor
Check de
cdigo
F
R
R
R

Figura 86. Ejemplo de Arquitectura de Distribucin
14. Arquitectura de Pre-Condicin.

Una arquitectura de
pre-condicin se
establece entre dos
servidores cuando la ejecucin del
servicio proporcionado por uno de ellos
est condicionada por una condicin
ligada al estado del otro. Pre-C es una
referencia de la especificacin de la
precondicin.

Por ejemplo, un sistema dispone de un
servidor de actualizacin de stock y de
otro de consulta de stock.
Cuando el de consulta
recibe una peticin para
consultar el stock de un
producto deber de
asegurarse de que no
hay ninguna peticin de
modificacin de stock
para ese producto en el
servidor de actualizacin.
Si es as, deber retener
la consulta hasta que la
actualizacin se realice.
Es habitual que en una
arquitectura de
precondicin, se
disponga de un
mecanismo para cambiar
la prioridad de la anotacin de actualizacin de un producto cuando hay una
consulta pendiente del mismo producto.

Hay diversas formas de implementar una arquitectura de pre-condicin segn sea
la necesidad y el tipo de la condicin.

Una forma muy habitual es que la relacin 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 deteccin de una relacin de pre-condicin,
esta espera puede ser notificada o no al cliente. El criterio es avisar siempre que la
demora pueda ser importante.

La arquitectura de precondicin es muy potente pero nada simple de implementar
por lo que conviene no abusar de ella y utilizarla slo cuando no sea posible otra
solucin.

Servidor Cliente
Servidor
Pre-
condicin
Pre-C
Servidor Cliente
Servidor
Pre-
condicin
Pre-C

Figura 87. Arquitectura de Pre-Condicin
Pre-C
Servidor
Actualiza-
cin Stocks
Cliente
Movimientos
Almacn
Servidor
Consulta
Stocks
Cola
Cambios
Cliente
Facturacin
Cola
Consultas
Stocks
No cambios
Pendientes
del Producto
Cambio Prioridad

Figura 88. Ejemplo de Arquitectura de Pre-Condicin
15. Arquitectura de configuracin.

La arquitectura de configuracin 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 dinmicamente en funcin de la situacin actual
del sistema de informacin.

Por ejemplo, imaginemos un sistema en el cual las reglas de validacin del stock de
los productos cambien con la evolucin del mercado.

Para evitar trfico y demoras innecesarias, suele ser conveniente que la lista de
productos a verificar se haga llegar cada da a los puestos de venta consiguiendo
as que solo se pierda
tiempo verificando stock de
aquellos productos que
realmente lo necesiten.

En esta situacin, lo
normal es que un
departamento de la
organizacin centralice la
decisin de que productos
hay que gestionar,
normalmente con procesos
tambin informatizados, y
que, por tanto sea
necesaria la creacin de
un servicio para conocer
cada da que stock de
productos hay que
confirmar y cuales no.

Cuando el servidor de validacin de stock arranque, o una vez al da si est
perpetuamente arrancado, acceder al servici servidor de configuracin para
registrar la situacin de ese da. Ms adelante comentaremos que posiblemente el
servidor afectado tendr una arquitectura de representante.

Si el sistema de stock est basado en el propio almacn y un almacn 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 tambin cuando el tiempo de
trasporte sea largo y se pueden hacer validaciones previas antes de pedir la
definitiva. Esta situacin es frecuente en arquitecturas basadas en Servicios WEB
de Internet.

Imaginemos que la validacin 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 estticas:

C

Servidor
Stock
Almacn
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 Configuracin
O Formatos sintcticos de los campos: por ejemplo, no se admiten
entradas sin asignar zona o DNI.
O Reglas de restriccin entre los campos: por ejemplo, un cliente de
extranjero no puede admitir la forma de pago a 60 das.
O Etc.
O Reglas dinmicas.
O De concurrencia: por ejemplo, la asignacin de cdigo.
O De gestin: 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 viajaran 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 dinmicas.

Puede establecerse una
arquitectura que, en el
momento del arranque, el
programa de alta de clientes
solicite al banco las reglas
estticas de validacin para
que se verifiquen in situ
antes de pedir remotamente
la validacin de las
dinmicas.

La arquitectura resultante
sera la de la figura.
Obsrvese que puede ser
habitual que se comparta una
arquitectura de delegacin y
configuracin a travs de una
entrada de distribucin.

Esta arquitectura se monta fcilmente a travs de Servicios WEB utilizando Internet
como transportista y objetos como tcnica de implementacin donde el servidor de
configuracin suministra un objeto que modela el cliente del banco con un mtodo
de validacin esttica.

El programa de altas pide el objeto a travs del servici de configuracin en el
momento del arranque y lo instancia dentro de si mismo. Todas las verificaciones
estticas se realizan en local y solo se piden al banco las dinmicas.

Obsrvese 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 Configuracin para el
alta de clientes remota.

En el se
muestra una
posible
arquitectura de
un agente que
gestione
PDAs que han
de trabaja de
forma
sincronizada.

Sobre la PDA
se instancia un
cliente de
presentacin
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 travs de un agente
master-slave. El agente, donde se llevar control y coordinacin 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 autentificacin. Este
servicio de autentificacin puede montarse sncrono o asncrono (recomendable) a
travs de una cola implementada en un hilo del agente.

La configuracin de la PDA como parte del proceso de autentificacin puede
hacerse:

O Accediendo en ese momento a los servicios y/o datos del sistema.
O A partir de su propia configuracin creada en el momento del arranque del
agente.

En la primera opcin cada PDA funcionar con la ltima versin de la configuracin
y en la segunda todas lo harn con la misma versin debindose rearrancar el
agente para actualizar la configuracin. Obviamente cada aplicacin deber
escoger que es lo que ms 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 presentacin es pedir
al agente su autentificacin.

Finalmente, est tcnica puede utilizarse para rebajar el grado de concurrencia ya
que permite reducir el nmero de peticiones al servicio remoto.
Cliente de
Presentacin
Agente de
supervisin
M
Servidor
de trabajo
Resto de
Servicios
Autentificacin
I
I
I
C
D
Trabajo
I
I
D
D
D
C

Figura 91. Ejemplo de arquitectura de configuracin con una PDA

16. Arquitectura de Representante o Proxy.

La arquitectura de representante o proxy consiste almacenar dentro del
servicio los datos necesarios para proveerlo. De esa forma, y siempre que
interese, el servidor podr resolver el mismo la peticin evitando acceder a
la fuente primaria.

Esos datos, que pueden inicializarse con una arquitectura de configuracin, pueden
tener o no persistencia.

Hay que estudiar la importancia de que los datos cambien durante la ejecucin del
servicio

Observe que, segn la aplicacin 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 peridica lanzada por el mismo servidor.
O Por un proceso peridico con calendario pactado.
O Aprovechando el servicio remoto. Por ejemplo, arbitrando en la
respuesta la informacin de cambios.
O Un almacn para los datos situado en
O Memoria, dentro del mismo servidor. Bsicamente cuando los datos no
tienen persistencia autnoma. Esta es la opcin recomendada ya que
los datos originales ya la tendrn.
O Disco, bsicamente para dotar al servicio de persistencia. Si se utiliza
esta solucin, 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
compaa tienen problemas de roturas de stock y
que esa situacin se prev dentro de un proceso
peridico donde se genera la lista de productos
con problemas.

Durante el periodo entre proceso y proceso esa
lista no cambia. Por esa razn, podramos
mejorar el rendimiento de la aplicacin si el
servidor se configura cuando arranca con la lista
de productos con problemas y cuando sea
preguntado slo 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
16. 2. Poliformar la fuente del servicio.

Imaginemos que disponemos de un sistema de identificacin de clientes por
tarjeta y que queremos llevar un control de las tarjetas anuladas.

La opcin habitual ser disponer de un servicio situado sobre el nodo de la
organizacin donde se gestione esa funcionalidad y que los programas que
necesiten validar las tarjetas accedan a l.

Imaginemos que la organizacin dispone de vendedores mviles con filosofa
de nmadas. Cuando los vendedores tengan conexin, el servicio de Proxy
acceder al servicio centralizado, pero cuando el vendedor no disponga de
conexin, el servicio usar su propia informacin para validar la tarjeta. Todo
de forma transparente a los programas clientes.

El diseo deber prever una forma de actualizar la informacin del servidor.
Podemos usar dos recursos:

Un proceso asncrono peridico,
Actualizacin dinmica. Por ejemplo, disear que cuando el vendedor
est en lnea 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 podra ser la fecha de la
ltima actualizacin de la lista.

16. 3. Incluir consistencia.

El ejemplo anterior nos vale tambin para mostrar como disear anlisis de
consistencia en servicios sobre clientes no nmadas aprovechando
arquitecturas de Proxy. Cuando el cliente no reciba respuesta del servicio
central, usar la informacin local de forma transparente al cliente que no
deber prever ningn tipo de proceso adicional.

17. La estructura del mensaje.

Cuando se hable de la estructura del mensaje estamos hablando de las la
especificacin 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 descripcin del servicio est en el propio
mensaje y por tanto no necesita modificarse la parte cliente si se aaden nuevas
prestaciones al servidor. No hace falta explicar, pues, porque este tipo de sistemas
se estn estandarizadazo bajo XML.

La propuesta de sistemas dbilmente ligados, contrapuesta a un sistema
fuertemente ligado, de Microsoft para servicios de Internet es una arquitectura de
distribucin, donde un servidor de mensajes recoge las peticiones de servicios en
XML, las analiza y las pasa al componente especializado en dar el servicio pedido.

18. Arquitectura completa del ejemplo del capitulo anterior.

Se incluyen a continuacin la arquitectura de datos completa del ejemplo final del
captulo dedicado a la comunicacin.

Usuario
Peticin cliente
Datos Compaa Area
Cuenta Cliente
Registro
Datos
Cliente
Anotacin
Cuenta
Cliente
Registro
Datos
Viaje
Peticin
Datos
Cliente
Datos
Cabecera
Cliente
RPC
Actualiza
datos
c.area
Obtener
Datos
Cliente
Proceso
Compaa
Area
Proceso
Cuenta
Cliente
R
Consulta
Datos
Vuelos
D
D
D

Figura 93. Arquitectura de servidores completa

Gestor de la WEB
Consulta
Datos
d.area
Datos Compaa area
Obtener
Datos
Cliente
Presentacin de la WEB
Identificacin
Cliente
Consulta
Vuelos
Registro
Vuelos
Identificacin
Cliente
Registro
Venta
RPC
Proceso
Compaa
Area
R
Cuenta Cliente
Proceso
Cuenta
Cliente
D
D
R
D
D

Figura 94. Arquitectura de las funciones de venta directa completo

Una posible alternativa sera convertir el proceso de cuenta de cliente en una Agente y
establecer una arquitectura de traspaso de responsabilidad en ese punto.

@EMG/05 - Enric Martnez Gomriz 133
Arquitectura Orientada a Servicios - SOA

1. Los servicios como base del diseo distribuido.

A lo largo de toda la primera parte hemos concluido tema tras tema que toda visin
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.

Disear el sistema distribuido no ser nada ms, ni nada menos, que construir los
servicios, integrarlos en una arquitectura y utilizarlos.

Pero para que esto sea posible ser necesaria rigurosidad en el diseo de esos
servicios.

Con la aparicin de los Servicios WEB, este enfoque se ha popularizado y se ha
plasmado en un estilo de disear aplicaciones conocido como Arquitectura
Orientada a Servicios, SOA (Service Oriented Architecture). Como sus mismos
ponentes establecen, esta arquitectura va ms all de los Servicios WEB que se
convierten nicamente en una forma de proveer servicios.

Vamos a dedicar este captulo a presentar las bases de esta arquitectura SOA
basada en servicios que es, a mi juicio, el enfoque vlido para atacar un diseo
distribuido.

Vaya de entrada la idea de que SOA es anterior a SOA. Es decir, el diseo por
servicios es anterior a que esta palabra se popularizara y esta basado en algo tan
antiguo como la informtica: disponer de funciones encapsuladas que pueden
usarse con fiabilidad sin conocer su implementacin y con independencia de
la plataforma donde estn localizadas. Una vez ms los informticos hemos
vuelto a poner nombre a algo que ya exista. Sin embargo hay un aspecto nuevo.

El hecho diferenciador es la idea, no estrictamente informtica, de que los
servicios se publican, se venden y se usan sin que proveedor y consumidor
se conozcan.

Y es ms que probable que cada vez ms el software se venda y se consuma como
servicio y que se necesario disearlo 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 especificacin y el uso a travs de la
implementacin del servidor del servicio.
O El servicio combina datos y comportamiento a travs de funcionalidad. Es
obligado, sin embargo, encapsular al mximo y por esa razn, todos los
atributos deberan ser privados y accesibles solo a travs de mtodos.

As, un servicio es un componente capaz de realizar una funcin o tarea a travs de
un interfase, un vehiculo a travs del cual la necesidad del consumidor es
satisfecha por un proveedor de acuerdo con un contrato negociado de forma
genrica o particular. El servidor ser el componente que proporcionar el
servicio. Normalmente la comunicacin se realiza intercambiando mensajes en una
estrategia cliente/servidor conocida tambin como peticin/respuesta.

Todos servicio tiene dos visiones muy diferenciadas:

O Diseo:
O Establece qu proporciona el servicio y la calidad de la funcionalidad
que aporta valorada por el grado de adaptacin a nuestros procesos de
negocio.
O Nivel de reusabilidad y adaptabilidad funcional.
O Adaptabilidad a la evolucin, tanto tcnica como funcional.
O Facilidad de gestin.
Publicacin y localizacin
Contrato de servicio.
Eficiencia de la localizacin cuando se utilice.
O Implementacin tecnolgica.
O Independencia de la plataforma.
O Independencia cuando se use del lenguaje y/o herramienta en que este
desarrollado.
O Nivel de adaptacin a estndares.

Bajo este enfoque, la ejecucin de la implementacin 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. Anlisis orientado a servicios de las aplicaciones (nuestra idea desde el
principio) que permita la identificacin de los servicios necesarios para
conseguir la funcionalidad buscada.
2. Diseo del servicio es decir, el desarrollo del componente que va a hacer de
servidor.
3. La administracin y gestin (management) del servicio incluyendo el
housing o localizacin.
4. La compra o subcontratacin del servicio segn la visin del usuario si no
es el propio constructor

3. Principios del diseo de servicio.

Los principios de diseo 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. Abstraccin.

Hace referencia a que el uso del servicio es independiente de la
implementacin y la localizacin. El servicio esta obligado al 100% en este
tema por lo que la encapsulacin debe ser total.

3. 2. Generalizacin.

Este principio hace referencia al hecho que el servicio debe poder usarse en un
nmero muy amplio de escenarios, incluso escenarios desconocidos en el
momento de su diseo, evitando as la necesidad de adaptar el servicio a cada
necesidad. Eso har los sistemas giles en su adaptacin al cambiante mundo
de las necesidades de los negocios.

3. 3. Seguimiento de estndares.

Eso permitir adaptabilidad tcnica 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.
Gestin de errores compleja e interdependiente.
Mensajes de gran tamao.
Facilidad de manejo.
Encapsulacin de reglas de negocio o de proceso complejas.

3.4.2. Ventajas de la granularidad Fine Graneid.

Pequeos mensajes que permiten gestionar datos simples.
Proporcionan
Mayor control.
Mayor facilidad de recuperacin.
Posibilidad de arquitectura entre los servicios.
En tiempo de ejecucin permite afinar mejor lo que se pide en
funcin 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 aplicacin. 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 debern verificar las interdependencias
y los condicionamientos de la aplicacin heredada para cada servicio
suministrado al exterior.

Sin embargo, un buen criterio es trabajar con una granularidad muy fina
internamente y montar los servicios al exterior con mayor agrupacin
utilizando los internos mediante modelos de arquitectura de servicios que
veremos enseguida. Conseguiremos as mayor agilidad y adaptabilidad.

4. Puntos de articulacin.

La posibilidad de disponer de diferentes implementaciones o proveedores de un
mismo servicio introduce el concepto de puntos de articulacin donde deben
contestarse preguntas del tipo:

O Cual de los servicios debe usar la aplicacin cliente?
O Qu proveedor debe suministrarlo?
O Qu implementacin debe usarse?

Estas preguntas deben contestarse en puntos de articulacin que son gestionados
fuera de la aplicacin cliente que siempre lanza la peticin contra el mismo sitio. La
solucin ser trabajar con arquitecturas de redireccin.

5. Principios de SOA.

World Wide Web Consortium (W3C) se refiere a SOA como un conjunto de
componentes que pueden ser invocados y cuya especificacin, descripcin y
interfase, pueden ser publicadas y descubiertas.

CBDI Service Oriented Architecture Practice Portal va ms all. Considera SOA
como toda una forma de trabajo: polticas, prcticas y Frameworks que permiten
que la funcionalidad de una aplicacin pueda ser proporcionada, total o
parcialmente, y consumida como un conjunto de servicios pblicos y que el
consumidor utiliza con la granularidad que necesita. Los servicios pueden ser
publicados, descubiertos e invocados con total transparencia de la implementacin
y localizacin. El ciclo de vida de los servicios debe de basarse en estndares.
SOA es el estilo de trabajo resultante de todo ello.

Observe ya de entrada que en esta definicin no se habla para nada de
Internet. Los Servicios WEB son una forma ms de obtener los servicios de una
forma muy estndar y general. Pero nada impide disponer de servicios a travs de
sistema operativo, sobre todo si parte o todo el sistema de informacin es interno a
la compaa 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 permtame aclarar un concepto. A mi juicio el concepto de
proveedor que se utiliza en el mundo SOA es incompleto. Deberamos diferenciar el
fabricante, el diseador y programador del servicio, del suministrador u
organizacin que suministra el servicio cuando la aplicacin lo usa en el da a da.
Obviamente, fabricante y suministrador puede ser personas o corporaciones
diferentes. Utilizar el trmino proveedor cuando quiera referirme indistintamente a
ambos y cada uno de los trminos 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 especificacin, 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 captulo de la primera parte dedicado a Servicios WEB. Observe, sin
embargo, que un grupo de proveedores y/o consumidores podran montar sus
propios directorios, ya sean internos a sus organizaciones o sectoriales.

En la figura se muestra la interaccin 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
Aplicacin.

Es la parte de la
lgica de negocio.
Es all donde se
consumen los
servicios. Yo
incluira 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 visin lgica del servicio.

Puede asimilarse a un bus lgico donde se conectar servidores y
consumidores con unas reglas de juego pactadas a travs de estndares.
Cada sector de negocio o de actividad puede pactar las reglas de un bus a
partir de las herramientas estndar.

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
Localizacin y
suscripcin
Publicacin
Uso

Figura 95. Interacciones en un modelo SOA

Entornos de housing y consumo y conectividad entre ellos.
Middleware para disear y administrar.
Entornos de desarrollo y de administracin.
Recursos de publicacin, descubrimiento y suscripcin.
Protocolos estndares del estilo de Servicios WEB.
Infraestructura de seguridad y autentificacin.
Monitoring.
Deteccin y seguimiento de fallos.
Certificacin.
Control de versiones.
Gestor de eventos.
Posibilidad de Workflow.
Desindeterminacin, es decir la automatizacin de informacin no crtica
que facilite la gestin de los usuarios. Por ejemplo, recoger las fechas
automticamente, implementar las condiciones habituales por defecto,
identificacin 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 aadir, desconocidos, para el consumidor.

Djeme opinar. Esta clasificacin no aporta nada nuevo que sea de demasiado
inters para diseadores.

7. Ventajas de SOA.

Ahora debera hablar aqu de las inmensas y maravillosas ventajas de
estandarizacin, adaptabilidad, generalizacin, transparencia, robustez y tantas
otras cosas positivas de SOA.

Supongo que estamos de acuerdo que si lo hiciera estara 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
lnea 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 filosofa basada en servicios para
conectar sistemas y aplicaciones heterogneas ya que se basan en estndares que
se encuentran en la inmensa mayora 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 travs de un estndar y una plataforma,
Internet, de extensin universal. Con ellos se ha creado una arquitectura de
servicios aceptada como un estndar por todos.

Repase, si no recuerda, el captulo 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 conclusin final.

SOA es un estilo de trabajo que obliga a pensarlo todo como servicios y a
crear la aplicacin como una integracin 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 armazn donde la funcionalidad se integra a travs de servicios que
colaboran con la aplicacin de usuario y entre ellos. Diferentes reas de negocios
pueden pactar marcos de ese armazn.

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 terminologa, hoy universalmente conocida, es muy til para
formalizar la idea que hemos estado proponiendo desde el primer momento para
enfocar el diseo de aplicaciones distribuidas basndolo todo en servicios.

Diseando Servicios

1. Introduccin.

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 disear
y programar. En este punto hay poco ms a decir, mandan los conceptos tcnicos
de programacin de piezas de software.

Pero el concepto de servicio crea un nivel de abstraccin por encima del
componente que conviene analizar. No se trata tanto de presentar todos los
desafos que el diseo de servicios crea sino de introducir los criterios tcnicos
bsicos a tener en cuenta. En el resto de este libro saldrn otros criterios que bien
podran estar en este captulo pero que presentaremos en su momento dentro de
su entorno natural de aparicin

Adems, muchos de estos aportan buenos ejemplos de las arquitecturas de
servicios que hemos presentado.

2. Especificacin del servicio.

Recordemos que la especificacin del servicio determina que funcionalidad da, con
que granularidad, cual es su interfase y que estndares sigue. Es el primer y critico
paso en al construccin de un servicio.

Una vez determinada la necesidad de un servicio en una aplicacin y la voluntad de
un proveedor de ofrecerlo a potenciales consumidores, debe intentarse que el
servicio sea lo ms general posible dentro de un coste razonable.

Se siguen tres pasos:

2. 1. Racionalizacin del servicio.

Supone un profundo anlisis de las necesidades de los consumidores ya
localizados y de los potenciales. Si el servicio no es estrictamente tcnico, hay
que consultar tanto a los consumidores detectados como a expertos sectoriales
si el servicio lo requiere.

2. 2. Consolidacin del servicio.

Se escogen las funcionalidades que se desean ofrecer y se define la
granularidad interna y externa. Debe incluirse aqu la decisin de la
arquitectura de servicios necesaria para conseguir las granularidades gruesas
a partir de las finas.

A partir de aqu se decide en que catlogo o catlogos se publica.

2. 3. Agrupacin por dominios o temas.

Los servicios se agrupan por afinidades. Dentro de cada afinidad puede haber
arquitecturas de precondicin que se debern resolver.

Pueden ser criterios de afinidad:

Afinidad de negocio.
Verificacin de la accesibilidad.
Aplicaciones heredadas.
Bases de datos compartidas.
Proximidad.
Entornos de sistema operativo

Es un criterio difcil de atacar de forma sistemtica.

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

SOA plantea varios tipos de servicios:

O Peticin / respuesta: obtiene informacin, realiza clculos 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 acta en lugar de notificar.
O Intermediario: intercepta una peticin de servicio de forma transparente, la
transforma y la enva al destino original.
O Agregador: combina los resultados de diversos servicios o fuentes de datos.
O Proceso: agregador de larga duracin, normalmente un proceso de negocio.

4. Adaptacin a la arquitectura de datos distribuida.

Los servicios actan sobre datos. Idealmente, el lugar ideal para situar los
servidores es el mismo entorno donde estn esos datos.

Es muy frecuente que esto no pueda ser as por algunas de las mltiples razones
por las que la arquitectura de datos pueden estar repartida por la plataforma
distribuida: particin horizontal o vertical, consolidacin de datos heterogneos,
upsizing, federacin, puntos de responsabilidad en las decisiones de negocio, etc.
En esta situacin la sincronizacin y coherencia es una responsabilidad del
servicio. Esto, como ya hemos visto y ampliaremos ms adelante, puede ser un
problema complejo.

El diseo del servicio deber adaptarse a esa obligacin utilizando cualquiera de
las tcnicas que hemos visto y veremos. Veamos un ejemplo con una particin
horizontal.

Imaginemos una organizacin donde la gestin de personal es responsabilidad de
cada centro de trabajo y donde la aplicacin heredada de personal no permite
consolidar datos en tiempo real. En esa situacin, los datos de los empleados
estarn 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
solucin 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 solucin por
redireccin pero
otra solucin vlida podra ser la de pasarela.

Otra solucin, a mi juicio menos aconsejable, es mantener un modelo de replicacin
con foco de mantenimiento distribuido en el cual los datos de todos los empleados
estn en todos los centros aunque mantengan en el centro que corresponda. De las
posibilidades en esta lnea hablaremos ampliamente en el captulo dedicado a
replicacin.

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 diseo se ataca por pasos:

O Agrupacin por reas de negocio y funcionalidades que se quieren dejar
disponibles.
O Localizacin de la funcionalidad en las aplicaciones heredadas.
O Empaquetamiento y especificacin 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 particin horizontal
Por ejemplo, imagine que tiene una aplicacin de gestin administrativa y otra de
facturacin. Y desea montar un servicio que a partir de un albarn calcule la
factura, realice la anotacin 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 funcin a la
respectiva aplicacin.
La forma en que cada
servicio especializado
acta depende de la
aplicacin existente. En
el ejemplo se ha
supuesto que:

O Existe una rutina
que calcula a
partir del albarn
la factura y los
documentos de
cobro o recibos.
Esta rutina se ha
linkado como un servicio pasivo con el servidor para el clculo 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 imputacin de los recibos se hace al final de da 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 atrs toda la
operacin o dejar pendiente de actualizar lo que no se haya podido hacer.

6. Service routing.

Este aspecto hace referencia a como la peticin del consumidor se dirige al servidor
de forma absolutamente transparente.

Pueden utilizarse varias tcnicas.

6. 1. Utilizar los recursos estndares del Middleware.

Prime esta opcin siempre que pueda. Un consejo, intente poder siempre.

6. 2. Localizacin en el propio servicio.

El mismo servicio lleva informacin de donde esta localizado. Interesante
cuando no se conoce a los potenciales consumidores.

Consumidor
Imputacin
albarn
D
D
Imputacin
de la
factura
Contabilidad
F
Clculo
de la
factura
Facturacin
D
Imputacin
del
Recibo
Gestin de
Cobro
T
D

Figura 97. Servicio de facturacin.
6. 3. Routers.

Existe un servicio que se
responsabiliza de esa
funcin. Acta con
arquitectura de
configuracin. 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 informacin de los servicios que estn en su entorno.
Recibe la peticin y si el servicio no es de su dominio devuelve un
cdigo de error lgico.

6.3.3. Servidor de localizacin.

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
delegacin o de master slave para realizar todas las peticiones
simultneamente.

Este nivel puede estar asumido por el consumidor o tambin es posible
que un router le pase la peticin a otro por una arquitectura de
redireccin.

El servicio JNDI de la arquitectura J2EE es un ejemplo aplicado de Router.

Consumidor
Servidor
de
localizacin
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
Arquitectura Conducida por Eventos (EDA)
y Arquitectura en Tiempo Real.

1. Introduccin.

Una arquitectura SOA es por concepto pasivo, es decir, ofrece unos servicios que
los diseos aprovechan.

Pero durante el da a da de la gestin 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
evolucin de mercados, redes de ventas, cadenas de suministro, procesos internos,
etc.

Hace falta un recurso para reaccionar de forma automtica a esa evolucin. Esta
posibilidad la proporciona la Arquitectura Conducida por Eventos, EDA, del
nombre en ingls, 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 previsin de ventas en una delegacin no se est cumpliendo.
O Un pedido critico se esta retrasando.
O Un grupo de matriculacin se esta completando.
O Un buen cliente hace tiempo que no compra.
O Un empleado se retrasa constantemente.
O Un camin de reparto ha sufrido una avera o va retrasado.
O Ha subido el precio de una materia prima importante.
O Un departamento est gastando ms 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 explotacin

Y en:

O Habituales (vigilar la evolucin de las ventas).
O Imprevistas (se ha estropeado un camin).

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 reaccin 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 mayora de los casos distribuido.

Ambas reacciones han de poder transmitirse a una pluralidad de sistemas y/o
personas.

La combinacin 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. Metodologa 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 debern seguirse los
siguientes pasos:

1. En la etapa de especificacin:
1.1. Identificar los cambios e incidencias y asignarles un evento.
1.2. Decidir que reaccin necesitan: mensaje y/o proceso.
1.3. Especificar la reaccin
2. Disear la reaccin.
3. Implementar la reaccin. Debe entenderse como

Estas etapas suponen que una vez especificada la arquitectura EDA en la primera
etapa, el resultado queda integrado como una funcionalidad ms a resolver en el
diseo tecnolgico distribuido y que por tanto los tres pasos previos deberan
hacerse como parte del anlisis funcional o especificacin del sistema.

4. Recursos tecnolgicos.

La mayora ya se ha presentado o se presentaran en los prximos captulos:

O Los mecanismos ECA permiten filtran les reacciones.
O El viga puede escuchar los eventos.
O El cartero puede ser un buen sistema de distribucin de mensajes.
O El disparador puede lanzar procesos de reaccin automticamente.
O Los agentes pueden escuchar eventos habituales.
O Las tcnicas de publicacin suscripcin pueden ser de mucho inters para
gestionar mensajes.

En fin, aada aqu todo lo que ha visto y ver en nuestro viaje y que puede ser
interesante para implementar una arquitectura EDA.


Integracin de Clientes y Servidores en el
Middleware.

1. Introduccin y final.

Recuerde los captulos 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.

Ingeniera de Software y Proyectos
Cliente/Servidor.

1. Introduccin.

Este no es un libro de Ingeniera de Software (IS).

Sin embargo, todo desarrollador de software es un Ingeniero.

Este hecho, que para los lectores que tengan una formacin Informtica reglada de
nivel superior o medio es una obviedad, para lectores que provengan es otras
lneas de formacin informtica 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 mnimos de Ingeniera de
Software.

He dudado en incluir este captulo en este libro. La decisin que he tomado es
evidente: Vd. esta leyendo la introduccin a este captulo.

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

Para aquellos que no los poseen, leerlos aqu puede resultar motivador para
profundizar consultando documentacin especfica. Adems les ayudar a seguir
con mayor fluidez los captulos de anlisis y diseo que se avecinan.

2. Caractersticas de las actividades de IS.

El desarrollo de software es Ingeniera ya que participan de todas las actividades
que definen en trabajo de un Ingeniero.

2. 1. Disponibilidad de Modelos, Mtodos y Herramientas.

El desarrollador dispone de modelos, mtodos y
herramientas para hacer su trabajo.

Delante de un problema, lo analiza, reconoce un modelo,
aplica un mtodo 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 mtodo y, si es necesario, disea la herramienta. El nuevo
modelo y/o mtodo y/o herramienta queda disponible para resolver nuevos
problemas.

2. 2. Utiliza un proceso de fabricacin.

Para la creacin del producto final el desarrollador de
software utiliza (o desgraciadamente en muchos casos
debera utilizar) un proceso de fabricacin: hay una
etapa de anlisis; para cubrirla hay unos datos a
recoger, unas actividades a cumplimentar, una metodologa y unas
herramientas a utilizar, unos plazos a estimar y cumplir, etc.

2. 3. Controla la Calidad.

Se debera medir la calidad del producto resultante, nuestra
gran asignatura pendiente. Sin embargo se pueden hacer
muchas cosas a un coste razonable. Ms delante se
introducirn algunos conceptos de Control de Calidad del
Software.

2. 4. Mejora continua del proceso.

El proceso de produccin 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 ms alto
posible.

Los Informticos somos los reyes de intentar coger todos los casos posibles.
Esto es una utopa absoluta y adems un coste innecesario en la mayora de
proyectos. Hay que analizar los casos probables y aplicar las soluciones
ms rentables. No olvide que ahorrar una hora por da de gestin de usuario o
de tiempo de proceso es bajar costes, adelantar un plazo de facturacin puede
suponer ahorrar costes de tesorera, etc. Y muchsimos ejemplos ms. Vamos,
el concepto de componentes y reutilizacin que ya hemos trabajado.

Muchas veces no analizar este ratio supone una delacin de funciones por
parte de desarrollador, por desconocimiento o poca profesionalidad, que puede
tener graves consecuencias econmicas para la empresa.

Si usted es Informtico de una empresa con tiendas de venta, no olvide que
cobra cada mes porque las tiendas venden. Su funcin no ser crear un
sistema de informacin 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 Qumico en una
fabrica se dar cuenta que bsicamente no hay ninguna diferencia con las de un
Ingeniero de Software.

3. Ingeniera de los Proyectos de Software.

Las caractersticas generales de los proyectos de ingeniera son:

O Diseo mediante modelos, metodologa y tcnicas sistemticas.
O Planificacin y seguimiento de la fabricacin.

O Utilizacin de materia prima, el proyecto aporta valor aadido.
O Certificacin de la calidad.
O Necesidad de fabricar el mejor proyecto al menor coste.

Es evidente que los proyectos de software participan de
todas estas caractersticas. Y evidentemente, los
proyectos de software distribuidos tambin.

Dentro de estas caractersticas generales de los
proyectos de ingeniera, los proyectos de software
tienen otras caractersticas especficas:

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 habra ningn tipo de problema (fuera de las
averas de maquina) despus.
O A pesar de que el software se desarrolla para cubrir unas funciones
determinadas, la utilizacin de componentes prefabricados, reusabilidad, es
fundamental, como ya se ha visto anteriormente, para obtener costes y
calidades razonables.
O No es nada fcil medir ms all del tiempo real invertido, lo que conlleva que
no hay ninguna costumbre de hacerlo. Y sin mediciones no hay ni mtricas 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 difcil de evaluar de forma absoluta. Y un
factor, el coste de mantenimiento, es desconocido en la fase de desarrollo
inicial. Y al final resulta crtico en coste total.

En cuanto a software y costes, hoy da 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 formacin y motivacin del personal humano.
O La fiabilidad de la especificacin y del anlisis funcional. En general no
muy alto.
O El grado de reutilizacin. 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 evolucin y adaptabilidad a menor
coste.
O El coste del reciclaje del personal a evolucin contina de la tecnologa.

La conclusin es, de cualquier forma, evidente: la fabricacin del software de ha
de entender como una disciplina de ingeniera ya que engloba los cuatro
factores principales:

Proyectos de Ingeniera
Proyectos
de Software
Proyectos
Distribuidos

Figura 99. Los proyectos
distribuidos como
proyectos de
Ingeniera
O Los modelos permiten identificar problemas y soluciones.
O Los mtodos dan las tcnicas de fabricacin.
O Las herramientas suministran el soporte a los mtodos.
O Los procedimientos unen mtodos y herramientas y permiten desarrollar en
el tiempo y la calidad deseados.

4. Gestin de un proyecto de software.

4. 1. Concepto de proyecto.

Proyecto es el conjunto de tareas necesarias para alcanzar un objetivo
general al coste mnimo (tiempo y dinero) y calidad mxima.

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 tcnicos que hay que gestionar.
Hay un responsable, el Director del Proyecto.

4. 2. Direccin de un proyecto de Software.

La direccin de un proyecto es la suma de tres actividades:

4.2.1. Especificacin.

4.2.1.A. Tcnica.
Definicin de los objetivos.

4.2.1.B. Planificacin
Definicin de las tareas.
Asignar un tiempo y unos recursos a cada tarea.
Identificar los trabajos crticos.
Crear una planificacin de recursos (compras e incorporaciones) y
tiempos (agenda).

4.2.2. Seguimiento.
Agenda
Compras e incorporaciones.
Revisin

4.2.3. Certificacin de la calidad.

En todo el proceso tienen una importancia bsica las mtricas. Es imposible
una buena estimacin de la carga sin una metodologa basada en mtricas.

Y para unas buenas mtricas es fundamental la medicin histrica y el anlisis
de los errores para identificar y eliminar sus causas

4. 3. Gestin.

La gestin del proyecto de software es el primer nivel de la IS. La gestin ha
de cubrir todo el proceso, desde el principio al final del ciclo productivo.

Las fases de la
fabricacin 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 gestin debe incluir todo el
proceso, desde la especificacin, al arranque y el mantenimiento. Y que, en
todo momento, la gestin debera controlarse con mediciones y mtricas.

He subrayado tambin las
etapas, que como vimos en
la primera parte, estn ms
influidas por el hecho de ser
el sistema distribuido. La
distribucin de los cambios
generados por el
mantenimiento es una
actividad ms de la
administracin del sistema
que, como vimos, est
condicionada tambin por el
hecho de ser el sistema
distribuido.

Conviene resaltar que la
gestin del proceso tiene dos aspectos, tcnico y administrativo.

El aspecto tcnico incluye los mtodos, tecnologas y herramientas para
construir.
El aspecto administrativo comprende la planificacin y el seguimiento.

Remarcar que, independientemente de las fases tcnicas en un proyecto de
software hay siempre (o debera haber) un pre-estudio, un estudio de
viabilidad, una planificacin, una ejecucin y una conclusin.

5. Gestin tcnica del proyecto.

Es la destinada a definir la funcionalidad del proyecto y definir la solucin tcnica
para conseguirla. Es la fundamental en IS.
Gestin del Proyecto
Anlisis Funcional /
Especificacin
Diseo Tecnolgico
Codificacin
Prueba
Integracin
Arranque
Mantenimiento
Mediciones
+
Mtricas

Figura 100. Fases de la gestin del Proyecto
Pre-estudio
Estudio de
viabilidad
Planificacin
Conclusin
Ejecucin
=
Seguimiento
+
Control
+
Revisiones
Dos aspectos:
Tcnico
Administrativo
Aspectos de la gestin del Proyecto

No hace falta insistir en la
necesidad de disponer de
una metodologa funcional.
Y recordar que el diseo de
la arquitectura distribuida,
etapa tecnolgica, comienza
slo cuando se dispone del
funcional. La metodologa de
diseo distribuido que
propondr servir para
cualquier mitologa funcional.
Pero, ha de usar una!

Si no la tiene, puede usar
como mnimo la de RDA que
le presentar ms adelante y
que usaremos en los
ejemplos.

Utilizaremos dos elementos presentes en todas las metodologas:

O Una descripcin del modelo de datos.
O Una descripcin de los procesos de transformacin y el orden en que los
procesos los ejecutan.

Adelantemos que, en la metodologa que propondremos en RDA, la propuesta para
especificar los datos ser la realizacin de un esquema relacional o un modelo de
objetos y que para dar los procesos se utilizarn diagramas de flujo modificados.

Utilice lo que utilice, recuerde que la etapa de anlisis 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
mtodos, las herramientas y los procedimientos.

Estos pasos de conocen como paradigmas de IS. La eleccin del paradigma se
hace en funcin del proyecto y de la aplicacin, los mtodos y las herramientas que
se han de utilizar y de los controles y entregas que se han de hacer.

6. Paradigmas de la Ingeniera de Software.

No es mi objetivo hablar de este tema. Si quiero hacer mencin a los ms
habituales para poder hacer un comentario final sobre cuales son ms apropiados a
los proyectos distribuidos.

6. 1. El Ciclo de Vida Clsico.

Cada etapa obtiene unos resultados que se entregan a la etapa siguiente como
punto de partida. Por esa razn el ciclo de vida clsico se denomina tambin
como ciclo de vida en Cascada.

Este ciclo supone que hasta que no se acaba una etapa no empieza la
siguiente. Por esta razn este ciclo es, a mi juicio, obsoleto y desfasado ya que
Requerimientos
de usuario
Anlisis de
requerimientos
Anlisis Funcional
/ Especificacin
Diseo
Codificacin
Prueba
Integracin
Instalacin
Administracin
del sistema Mantenimiento

Figura 101. Ciclo de Vida Clsico o en Cascada
hoy da las aplicaciones no son lineales, el usuario ha de intervenir en la mayor
parte del ciclo de vida y la evolucin es una constante. Y la adaptabilidad
rpida una necesidad.

6. 2. El prototipaje.

El prototipaje es un
paradigma que consiste en
montar una simulacin
operativa rpida 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 crticas y aportaciones.

El primer producto resultante sirve normalmente para obtener especificaciones
fiables y, en la mayora de los casos es descartable y es un grave error
utilizarlo como software de explotacin. En el mundo distribuido especialmente,
evite la tentacin de hacerlo ya que el prototipo inicial ya de ser operativo lo
ms rpidamente posible y por tanto no puede ser robusto.

El prototipaje es una tcnica de inters cuando:

El usuario no es capaz de definir exactamente cuales son sus
necesidades.
Cuando se han de evaluar rendimientos.
Cuando se han de definir GUIs y de quieren mostrar al usuario en fase
de diseo.

Las tcnicas de prototipaje no incluyen anlisis de riesgo (del que hablar ms
tarde).

Las tcnicas de prototipaje son interesantsimas en el mundo distribuido por
varias razones.

La existencia de gran nmero de piezas fabricadas (si sigue la
metodologa puzzle) permite obtener prototipos potentes en poco tiempo.
Liga muy bien con las aplicaciones RAD.
La mayora de las aplicaciones distribuidas, avanzadas o RAD, acaban
integrando sus clientes con GUIs. El prototipaje de las GUIs puede
utilizarse como herramienta de diseo tecnolgico. Si se utiliza la idea de
componente de presentacin (con poca o inexistente lgica de datos y de
proceso) el prototipaje de GUIs es una excepcin ya que puede
aprovecharse para la aplicacin definitiva.
Especificacin
de requisitos
Diseo
rpido
Construir el
prototipo
Evaluacin del
prototipo
Depuracin
prototipo
Producto
Ingeniera
Inicio
Final

Figura 102. Prototipaje.

Existen tres alternativas para realizar prototipaje:

6.2.1. Construccin de una maqueta.

Se construye una maqueta de una primera solucin de la aplicacin.
Esa maqueta incluye las GUIs y los mens. El usuario puede navegar
por ella pero el comportamiento ser simulado. Integra todas las piezas
ya construidas que se van a reutilizar en la aplicacin.

6.2.2. Construccin 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 distribucin que
ms 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 ms 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 simulacin del comportamiento final ya que
parte de un programa operativo completo y real. Estoy de acuerdo con
una importante excepcin. Si usted dispone de una buena coleccin 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 opcin que puede salirle mucho ms
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 clsico
y de prototipaje
permitiendo
introducir la gestin
del riesgo que no
se usa con
prototipaje y que es
necesaria en los
modelos
distribuidos
avanzados para los
que es muy
Planificacin Anlisis del riesgo
Evaluacin del
usuario
Ingeniera
Requerimientos Iniciales
Planificacin basada en la
evaluacin del usuario
Evaluacin del usuario
Anlisis segn
requerimientos
iniciales
Anlisis basado en la
evaluacin del usuario
Prototipo Inicial
Prototipo del segundo nivel
Avance hacia el
Sistema Final

Figura 103. Ciclo de vida en Espiral
interesante este ciclo.

El modelo en espiral realiza cuatro tareas cclicamente:

Evaluacin y planificacin.
Anlisis del riesgo.
Construccin.
Evaluacin del producto.

As de en cada vuelta de van aadiendo prestaciones y la aplicacin 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 mtodo aporta seguridad.

Observe que cada vuelta puede hacerse utilizando cualquiera de los otros
paradigmas y que necesita Gestin del Proyecto.

6. 4. Las tcnicas 4GL.

Las tcnicas 4GL se basan en la adaptacin a la funcionalidad especfica
necesaria de gran nmero 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 semntico. Para realizar la
modificacin de un fichero en concreto se partir del Framework general y se
incorporar la sintaxis y la semntica de ese fichero en concreto.

As el entorno de 4GL se convierte en el soporte del diseo.

Estas tcnicas tienen su origen, y estn basadas muy frecuentemente, en las
herramientas 4GL, del tipo PowerBuilder. Estas herramientas disponen de
Framework que permiten resolver rpidamente todo lo relacionado con la
gestin y consulta de datos en soporte relacional, la base de los datos
distribuida. Aporten adems muchas herramientas de construccin de GUIs,
listados y funciones de todo tipo. Y, en general, un lenguaje de usuario
avanzado.

Las ventajas de las tcnicas de 4GL son:

La gran ventaja en que la funcionalidad, la lgica del proceso y la
operativa, que constituyen la parte complicada de probar, ya estn
probadas en su mayor parte.
Eficacia probada por los aos en aplicaciones pequeas e intermedias
basadas en los datos.
Estandarizacin de la operativa.
Rapidez en obtener resultados.

Las desventajas ms claras son:

Aunque la idea de Framework es independiente de una herramienta en
concreto, lo habitual es utilizar una. Ello comporta que el software creado
queda ligado a esa herramienta.
Es muy difcil modificar el comportamiento del Framework para cubrir
necesidades operativas especiales.

6. 5. La orientacin a objetos.

No voy a repetir aqu todo lo explicado de OO en captulos anteriores.

Solo recordar que:

La OO. y C/S tienen una
interaccin
prcticamente total y que
OO. es la tcnica
fundamental en
aplicaciones distribuidas
avanzadas y en las
integraciones cliente por
GUIs.
Las tcnicas 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
formacin para
trabajar OO.
Se puede disear
convencional e
implementar OO.

Como la orientacin a objetos se
base en la construccin 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 problemtica
concreta. As, un cluster no es
ms que una agrupacin de
clases afines.

Cluster 3
Especificacin
Diseo/
Implementacin
Validacin/
Generalizacin
Cluster 2
Especificacin
Diseo
Implementacin
Validacin/
Generalizacin.
Cluster 1
Especificacin
Diseo/
Implementacin
Validacin/
Generaliacin

Figura 104. Ciclo de vida de clase de Meyer
Sistemas del mundo real
Mantenimento
Uso
Programa
Ms Desarrollo
Anlisis de requerimentos
Especificacin de los
Requerimientos de
Software
Especificacin de los
Requerimentos
de Usuario
Diso del sistema
Diseo del programa
Codificacin
Prueba Unitria
Prueba de Sistema

Figura 105. Ciclo de vida OO de Henderson -
Sellers
Al ser una clase un componente simple, el ciclo de vida de una clase no es
complicado y como se puede ver en la figura (ciclo de vida del paradigma OO)
basado en clase propuesto por Meyer en 1989) es lineal cubriendo tres etapas:

Especificacin.
Construccin: Diseo e Implementacin.
Validacin y Generalizacin.

Y adems, gran ventaja, no hay sincronizacin entre los ciclos de vida de cada
clase o cluster.

Las cosas son ms complejas si estudiamos el ciclo de vida de la construccin
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 interaccin y una significativa
fusin de las etapas del modelo clsico. Y, por descontado, que es desarrollo
es incremental.

7. Gestin administrativa del proyecto.

Como ya se ha dicho, el aspecto administrativo del proyecto comprende la
planificacin y el seguimiento de la gestin tcnica.

La gestin tcnica acaba
generando especificaciones
de cada una de las etapas
que es la informacin que
se toma como base para
administrar el proyecto.

Un esquema de la gestin
administrativa de un
proyecto y de sus acciones
se muestra en la figura de
la derecha.

Repasaremos a
continuacin conjuntamente
el ciclo revisando el
contenido de cada una de
las acciones que se
muestran en la figura.

7. 1. Estimacin.

La estimacin es la actividad de la administracin de un proyecto enfocada a
valorar, a partir de la especificacin, la carga de trabajo y los recursos
necesarios para completar el proyecto.

Como resultados de la estimacin del proyecto se obtienen:

Los componentes de software, hardware y Middleware.
El esfuerzo humano.
Estimacin
Planificacin
Agenda
Seguimiento
Revisin
Certificacin de Calidad Puesta en Marcha Cierre
Gestin Tcnica

Figura 106. Esquema de Administracin de un Proyecto
Las fechas cronolgicas del proyecto que se habrn de cumplir.
El coste

Cmo se realiza la estimacin? Mediante tcnicas de estimacin basadas en
mediciones, refrendadas y corregidas con la experiencia y reflejadas en
mtricas obtenidas por aquellas mediciones.

Las estimaciones se revisan y planifican ajustndolas con el anlisis de
riesgos del que le hablar ms tarde.

Hay parmetros comunes a todas las tcnicas de estimacin:

No se puede estimar sin establecer antes muy claramente el mbito del
proyecto: qu, cmo, 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 mtricas de software basadas en datos
histricos.
Las mtricas generales deben ser ajustadas con parmetros de
correccin resultantes de cada organizacin y de cada cliente. No
debera ser as pero, lo siento, si que lo es.

7. 2. Planificacin y agenda.

La estimacin lleva a la planificacin. Y la planificacin se concreta en una
agenda.

Se entiende por planificacin la determinacin de objetivos, las alternativas, las
restricciones, la determinacin de los recursos humanos y tcnicos y la
concrecin de la agenda.

El objetivo bsico de la planificacin es dar una estructura que permita al
Director del proyecto hacer una previsin razonable de recursos, costos y
agenda.

La planificacin se hace mediante una cuantificacin de recursos y esfuerzos a
partir de la estimacin. La planificacin 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 planificacin temporal de un proyecto de software no es diferente de una de
cualquier otro proyecto de Ingeniera. Hay que:

Identificar las tareas.
Establecer las dependencias entre ellas.
Estimar el esfuerzo en recursos tcnicos y humanos
Asignar personal y recursos.
Crear la red de tareas.
Asignar fechas objetivo
Establecer la agenda donde queda reflejada la planificacin temporal.
Informar a los afectados y conseguir su consenso (fundamental).

7. 3. Seguimiento, Control y Revisin.

El seguimiento comienza cuando se dispone de la agenda y es la herramienta
de control del Director del Proyecto.

Se realiza siguiendo la evolucin de cada tarea y comparndola con la
planificacin. Si una tarea no se desarrolla segn las previsiones se ha de
analizar el porqu y decidir como se puede corregir. Las acciones a realizar
para hacerlo constituyen una revisin del proyecto.

Una revisin supone, si es necesario, asignar o reorganizar los recursos,
reorganizar las tareas o modificar los compromisos, que debera ser la ltima
solucin por razones obvias.

Para que todo el proceso sea operativo y no utilice ms 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 certificacin de calidad de la parte a arrancar. Y en los proyectos
distribuidos, es de especial importancia certificar el plan de integracin.

La teora 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. Hgame caso, es peor
sufrir la tortura lenta de una puesta en marcha mal hecha que la bofetada
rpida de una negociacin para retrasar un plazo.

En la puesta en marcha, y para cada tarea que se arranca, hay que hacer las
siguientes actividades:

Valoracin de la especificacin con el usuario responsable.
Formacin de los usuarios.
Seguimiento de la calidad y las reacciones de plataforma y usuarios.
Anotacin de las pequeas mejoras operativas (malo si no son
pequeas).
Puesta en marcha de esas mejoras.
Aprobacin final del usuario responsable y de los usuarios operativos. La
primera necesaria, la segunda poltica.

7. 5. Conclusin de la etapa de desarrollo.

Las actividades a cubrir en ese momento son:

Confirmacin de las prestaciones globales con el usuario.
Seguimiento de las primeras explotaciones de todo el sistema acabado.
Confirmacin de la calidad.
Aprobacin completa del usuario responsable.
Recoleccin de las medidas para las mtricas.
Catalogacin y revisin final de la documentacin.
Informe de finalizacin de la etapa de desarrollo.
Traspaso del proyecto al personal de mantenimiento.


8. Anlisis de riesgos.

8. 1. Qu se entiende por Anlisis de Riesgos?

Analizar los riesgos es una sana actividad de administracin, 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 concretndose
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. Metodologa.

Por raro que le parezca existen metodologas para analizar el riesgo. La
primera de ellas es identificar reas de duda.

Hay reas de duda estndares:

Se ha entendido realmente lo que el usuario necesita?
Qu especificaciones no parecen del todo fiables a pesar del esfuerzo
del anlisis?
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 tcnicos escondidos?
Tenemos capacidad y recursos para hacer revisiones ante los
problemas y cambios que, seguro, aparecern?
Qu compras y subcontrataciones pueden tener retrasos?

El anlisis 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 bsicamente cuatro:

8.3.1. Identificacin 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 continuacin los riesgos potenciales dentro de cada grupo,
marcando en negrita los riesgos, que a mi juicio, son ms peligrosos en
el mundo distribuido.

8.3.1.A. Riesgos de proyecto.

Complejidad del proyecto.
Tamao.
Fiabilidad de la especificacin.
Problemas presupuestarios.
De personal, en especial formacin, pero tambin motivacin.
De cambio de plazos.
De cambio de Personal
De recursos.
De usuario.

8.3.1.B. Riesgos tcnicos.

Problemas u omisiones de diseo.
Implementacin.
Pruebas.
Integracin.
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 organizacin preparada?
La calidad buscada es la realmente necesaria? No olvide que los
informticos somos en muchas ocasiones demasiado
perfeccionistas.
Grado de adaptacin del proyecto a la estrategia global de la
empresa. Mejor no ir contracorriente...
Es el producto vendible?
Riesgo de gestin o prdida de soporte por los usuarios que han
promocionado el proyecto. Incluya aqu la opcin de cambio de
personas que se produce cclicamente en las empresas.
Riesgo de presupuesto o prdida de presupuesto monetario y/o
recursos.
Es el coste asumible por la organizacin? O nos hemos metido
en un volumen de gasto que no nos podemos permitir. No menos
precie este riesgo ya que la solucin fcil es cortar prestaciones o
actividades. Y esta opcin conduce el fracaso. Vale ms que revise
los objetivos, corte lo que supone menos retorno de inversin y
recalcule todo de nuevo. Vale ms un proyecto posible pequeo
realizable que uno grande no asumible.

8.3.1.D. Riesgos imprevisibles.

Desgraciadamente existirn aunque esta lista quedar vaca en su
identificacin de riesgos: si un riesgo imprevisible es previsible ya no
es imprevisible. Perdneme el juego de palabras, no me he podido
resistir.

8.3.2. Clculo del riesgo.

Una vez identificados los riesgos hay que ver como afectan a los plazos
y recursos, cuantificar como afectan a las tecnologas, recursos
humanos y resto de factores del proyecto.

8.3.3. Proyeccin.

La siguiente actividad ser establecer el impacto en el proyecto de la
cuantificacin calculada, decidir las soluciones alternativas y ver como
afectaran al proyecto si han de ser activadas.

La proyeccin intenta evaluar el riesgo de dos formas:

Probabilidad de que el riesgo sea real.
Consecuencias en caso de que aparezca. Tambin llamado grado
de desastre.

El gestor ha de hacer cuatro subactividades bsicas:

Establecer una escala de medida.
Definir las consecuencias.
Estimar el impacto en el proyecto.
Anotar todo lo necesario para la gestin.

8.3.4. Gestin.

Finamente, habr que realizar las actividades de gestin estableciendo
las estrategias de control del riesgo, resolucin o momento en que se
activan las soluciones alternativas y supervisin de esas soluciones.


Las ventajas de considerar el software como un proceso industrial son
incuestionables.

Tambin es incuestionable que el software est desarrollado normalmente con
procesos de fabricacin artesanales o, el los casos ms favorables, con criterios
industriales mnimos. Y que prcticamente nadie mide y aplica procesos de mejora
de calidad como resultado del anlisis de esas mediciones.

Los factores fundamentales son a mi juicio:

1. La poca formacin de algunos directores de proyecto.
2. El alto coste del proceso de fabricacin 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 fabricacin).

El factor compensador es el menor coste de fabricacin, mantenimiento,
ampliacin y gestin 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 diseador industrial
tambin he intervenido en muchas conversaciones de industriales que afirman la
tontera 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 ms caro
que su competencia que ignora la gestin industrial de proyectos o, simplemente,
pasa de ella. Y como muchos de los clientes potenciales no distinguen un diseo de
un cdigo en un lenguaje de programacin, su oferta no ser la escogida. Y si no le
contratan proyectos no cobrar. Y si no cobra no comer....

Cmo se cambia la tendencia? No tengo ni idea! Ojala lo supiera.....

Del Anlisis Funcional/Especificacin al
inicio del diseo de los Sistemas
Distribuidos

1. Posibilidades de utilizacin de servicios.

Como hemos presentado en la primera parte, hay tres posibilidades para utilizar
servicios:

Desde la especificacin: Especificacin por servicios:
o El sistema se contempla como una integracin de servicios.
o Los servicios estn 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 integracin en la composicin de servicios.
En el diseo: Diseo por/con servicios.
o Hay que identificar y disear servicios de datos y procesos.
o Es una etapa interpuesta en el diseo clsico.
Solucin hibrida: Servicios como agentes externos.
o Es una situacin habitual.

1. 1. Especificacin por servicios.

Los procesos de negocios se muestran como una interaccin del servicios.

Necesitamos un documento que muestre la interaccin de servicios:

Proporcionado directamente por el organizador.
Creado por el informtico: Un recurso puede ser el diagrama de
actividades.

1. 2. Diseo 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 diseo empieza a partir de la documentacin de especificacin.
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 especificacin es asumida
por servicios.
o Por servicios: Todos son servicios.
Obviamente, las dos posibilidades se disean de forma parecida:
identificando por servicios todo o solamente una parte de la
funcionalidad.
La parte que quede responsabilidad de los servicios, no ha de permitir
diferenciar entre:
o Servicios construidos para la aplicacin.
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 especificacin 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. Introduccin al diseo distribuido.

Como ya se ha dicho anteriormente, el diseo distribuido que supone la existencia
de un sistema distribuido influye bsicamente en el diseo tecnolgico del sistema
de informacin.

As pues, las tcnicas de diseo distribuido van a desarrollarse para esa etapa. Sin
embargo, es evidente que para que sea posible la existencia de un diseo
tecnolgico es necesaria la existencia de un anlisis funcional o especificacin que
determine que se desea del sistema de informacin que se est creando.

Usar los trminos Anlisis Funcional (denominacin clsica) o Especificacin
(Orientacin a Objetos UML) indistintamente para referirme a la definicin de las
funcionalidades que debe cumplir el sistema de informacin que se disea. Para no
repetir continuamente los dos trminos usar slo uno de ellos, primando anlisis
funcional.

Usaremos el trmino diseo tecnolgico en ambos casos para referirnos a la etapa
en que a partir del diseo funcional se crea la arquitectura de sistema y se disean
los programas y procesos para acabar implementando la funcionalidad sobre
herramientas de desarrollo.

La metodologa que se propone para el diseo distribuido es independiente de la
metodologa utilizada en los diseos funcional y tecnolgico.

Esto es as porque se basa en tres patas que proporcionan todas las metodologas
funcionales y tecnolgicas:

O Una descripcin de los datos.
O Diagramas de transformacin.
O Una secuencializacin de los procesos.

Las aplicaciones avanzadas necesitarn, como todas, de una metodologa de
diseo funcional. Escoja la que quiera. Particularmente mi voto es por Orientacin a
Objetos.

Para las aplicaciones de RAD le voy a proponer una metodologa propia, MAFDRA,
que utilizaremos tambin para documentar la funcionalidad de los ejemplos que
disearemos despus tecnolgicamente en este documento. En organizaciones
que no dispongan de una metodologa propia para RDA pueden usar la propuesta
MAFDRA.

Va a ser una precondicin que el lector esta versado en los elementos bsicos del
diseo funcional y tecnolgico como modelos de datos, diagramas de flujo,
diagramas jerrquicos, diagramas de estados, diagramas de secuencia, casos de
uso, etc.

Aunque este captulo y los siguientes proporcionan suficientes conocimientos sobre
estas herramientas para seguir las explicaciones, el lector puede consultar
documentacin especializada si desea mayor nivel de conocimientos.

3. Elementos comunes a cualquier metodologa de diseo.

Cara a la presentacin de la metodologa de diseo distribuido es conveniente
hacer una reflexin previa.

A lo largo de la evolucin de las metodologas de diseo es contrastable que,
independientemente de la forma y herramientas propuestas cualquier metodologa
de tiene los siguientes bloques comunes:

3. 1. La descripcin de los datos.

En la que siempre hay una descripcin de las entidades de datos afectados y
las relaciones estticas y dinmicas que se establecen entre ellas.

3. 2. Descripcin de los procesos de transformacin.

Un sistema de informacin trasforma la informacin 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
diseado. As un sistema de informacin puede ser contemplado como un
conjunto de Procesos de Transformacin.

Todas las metodologas funcionales recogen estos procesos de una forma u
otra. En las metodologas convencionales, una de las herramientas
comnmente utilizadas para hacerlo son los diagramas de flujo. Mi
metodologa RDA se va a basar en ellos. En las orientadas a objetos, esta
informacin puede extraerse de los casos de uso, los diagramas de
secuencia y los diagramas de comunicacin/colaboracin cuando se
incluyen

3. 3. Secuencia en que se ejecutan los procesos de transformacin.

En las metodologas convencionales, esta informacin esta repartida entre el
funcional, los diagramas de flujo y la descripcin de los programas.
Bsicamente, mi metodologa de diseo distribuido aplicada a RDA
aprovechar la segunda va analizando dentro de los programas cliente y los
servidores en que orden se ejecutan internamente los procesos de
transformacin.

En las metodologas OO., esta informacin se contempla en los diagramas de
secuencia y colaboracin y de aqu partiremos.

Reparemos, finalmente, que como estos tres elementos estn presentes en
cualquier metodologa de desarrollo, las tcnicas que se presentarn sern vlidas
para cualquiera de ellas.
Como se ver en el captulo dedicado al diseo de la arquitectura distribuida habr
dos formas bsicas de identificar servicios ser analizar:

O Revisar la localizacin y gestin de las entidades de datos.
O Analizar la secuencualizacin.

4. Encaje de la etapa de diseo tecnolgico en el ciclo de desarrollo del
software.

Las metodologas de diseo de aplicaciones avanzadas como UML realizan la
etapa de anlisis funcional/especificacin y a partir de ah inician una etapa de
diseo tecnolgico que acaba con la construccin de la arquitectura de sistema o
del software segn la terminologa de cada una.

Las metodologas de diseo RAD, como MAFDRA, realizan la etapa de diseo
funcional e incluyen como ltima etapa de esta fase una descripcin de los
programas ms complejos que sustituye a la inexistente etapa de diseo
tecnolgico. La arquitectura del sistema en tan trivial que normalmente se omite en
la documentacin o se incluye al final del anlisis funcional.

En la metodologa que
le voy a proponer, la
etapa de diseo
distribuido se encaja
delante de la conclusin
de la arquitectura del
sistema, tal como se
muestra en la figura de
la derecha. En las dos
metodologas, en ese
punto se dispone ya de
la documentacin
necesaria para
proporcionar las tres
patas en que me
basar: descripcin de
los datos, procesos de
transformacin y
secuencializacin.

5. Resumen de puntos
de partidas segn la metodologa empleada.

En los captulos siguientes se incluye la descripcin de los elementos utilizados en
el diseo de sistemas convencionales y en los orientados a objetos.

Si, como espero, Vd. ya los conoce, le recomiendo que se salte esos captulos
excepto aquellos puntos donde se explica la metodologa MAFDRA para el diseo
de aplicaciones de desarrollo rpido. Conviene que revise esos apartados porque
ese ser el marco (por su sencillez y claridad didctica) que voy a utilizar para la
descripcin de los ejemplos que acompaarn a las presentaciones tericas.

Etapa Tecnolgica Etapa Funcional
Anlisis Funcional /
Especificacin
Diseo Tecnolgico
Diseo Distribuido
Descripcin 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 diseo distribuido en el ciclo de desarrollo del
software
Por si no visita completamente cada uno de esos captulos, incluyo a continuacin
un resumen de los puntos de partida de partida de cada metodologa.

O Metodologas convencionales:
O Datos: Modelo relacional
O Procesos de transformacin: Diagramas de flujo.
O Secuencia de transformacin: Descripcin de los procesos y programas
tras el tecnolgico.
O Metodologa RDA - MAFDRA
O Datos: Diagrama de Datos OO Modelo conceptual de especificacin.
O Procesos de transformacin: Diagramas de flujo.
O Secuencia de transformacin: Secuencializacin de los procesos dentro
de los diagramas de flujo.
O Metodologa OO UML.
O Datos: Modelo conceptual de diseo.
O Procesos y secuencia de transformacin:
Diagramas de Secuencia de diseo.
Diagramas de Actividades de diseo.
Diagramas de Colaboracin de diseo.
O Integracin de la parte cliente: Casos de Uso y Diagramas de
Colaboracin (cuando existen)

Ver ms adelante que en MAFDRA el funcional y el reducido tecnolgico que
necesita una aplicacin RDA se desarrollan simultneamente. En los otros dos
casos es necesario disponer como mnimo de la arquitectura del sistema para
poder atacar la etapa de diseo tecnolgico distribuido.

Elementos funcionales y tecnolgicos para
la descripcin de los procesos en
metodologas convencionales

1. Introduccin.

Se incluyen en este capitulo la descripcin de los elementos funcionales de las
metodologas convencionales que voy a utilizar para escribir los procesos en la
metodologa funcional RAD.

2. Descripcin de los procesos de transformacin. Diagramas de Flujo.

Un sistema de informacin trasforma la informacin 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 diseado. As un
sistema de informacin puede ser contemplado como un conjunto de Procesos de
Transformacin.

Todas las metodologas
funcionales recogen
estos procesos de una
forma u otra. Una de las
herramientas
comnmente utilizadas
para hacerlo son los
diagramas de flujo.

En la figura de la
izquierda de muestran
tres procesos de
transformacin
reflejados en un
diagrama de flujo.

Como cualquier lector
familiarizado con este
tipo de diagramas podr
ver fcilmente el de la
figura presenta algunos componentes que no son habituales y que presento y
justifico en el apartado siguiente.

3. Extensin de los diagramas de flujo.

Para poner definir y utilizar la metodologa de diseo RAD voy a proponerle tres
extensiones de los diagramas de flujo. Los dos primeros, iconos especializados y
secuencializacin, los voy a presentar aqu. La tercera, dedicada a la
representacin de los procesos de consistencia, la presentar en el capitulo
dedicado a esa parte de diseo distribuido.
Peticin cliente
Actualiza
datos
Datos Compaa aera
Clientes
Entrada
Peticin
Cliente
Clientes
Vuelos por cliente
Reserva
Cliente
Impresin
Reserva
Crdito estandar

Figura 108. Ejemplo de diagrama de flujo.

3. 1. Iconos.

A continuacin le presento los iconos que utilizar dentro de los diagramas de
flujo. La mayora de ellos son estndar. Unos pocos son especficos de
metodologa que desarrollaremos despus.

3.1.1. Agente externo.

Elemento que proporciona o recibe informacin
a o del sistema.

3.1.2. Entidad.

Agrupacin de datos que representa
una unidad de informacin. En estos
diagramas de flujo una entidad es un
concepto lgico independiente de localizacin u organizacin.

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 despus
implementar, aunque en muchas ocasiones la localizacin y
organizacin de la entidad ser obvia y, frecuentemente, en BD.

3.1.3. Proceso de transformacin.

Corresponde al componente habitual de
los diagramas de flujo que transforma,
total o parcialmente, unas entidades en
otras. La transformacin puede afectar
a campos o a la totalidad de la entidad.
En algunos diagramas de flujo se
identifican los atributos que cambian.
En nuestra metodologa no utilizaremos esa opcin.

3.1.4. Salida impresa.

Entidad representada sobre un
soporte de papel. Suele
corresponder a la representacin
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

Entidad representada sobre base de datos.

3.1.7. Servicio.

Representacin que conocemos desde los
primeros captulos. Mas adelante
incluiremos tambin iconos especficos
para representar los agentes y los clientes
background y reservremos este slo para servidores.

3.1.8. Modelos de comunicacin C/S.

Recuerde y repase los presentados en el captulo dedicado a este tema.

3. 2. Secuencializacin.

Un diagrama de flujo tradicional
muestra los procesos de
transformacin, 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 metodologa que propondremos, para indicar el orden de ejecucin de los
procesos de transformacin utilizaremos una extensin 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
secuencializacin de los
procesos, tal como se
muestra en la figura. Esto
nos permitir, entre otras
cosas, detectar puntos
donde la comunicacin
asncrona puede permitir
mejorar el rendimiento del
proceso.

Observe el ejemplo de la
figura. En ella se muestra un
proceso de captacin de un
pedido de un cliente en un
puesto de venta. El proceso
necesita verificar el crdito
accediendo a un servidor de
crdito localizado en la
central y accesible solo a
travs de una va remota
lenta. Observe que, despus

Actualizar
Crdito

Actualiza
datos
Entrada
Peticin
Cliente
Pedido
Comprobar
Crdito Peticin
Cliente
Acceso
al
Cliente
Pedir
Productos
Tomar
Datos
Clientes
Clientes
Servidor de
Crdito
R
Cuentas Clientes
Imprimir
factura
Contado
Aviso
al
Cliente
Factura
Sin
Crdito
Con
Crdito

Figura 109. Ejemplo de la utilidad de la
secuencializacin
de identificar al cliente, se accede aun servidor de datos de cliente local que
tiene que acceder al crdito de la central. La comunicacin se ha diseado
asncrona, mediante colas, para permitir que, mientras el servidor de clientes
accede a al central, el proceso cliente pida al cliente los productos que desea.
Despus de entrarse los productos del pedido el proceso recoge o espera la
respuesta. Como lo normal es que el cliente tenga crdito (cierre el negocio en
caso contrario) el tiempo de espera del cliente ante el puesto de venta se ha
reducido al mnimo. Observe que las flechas de secuencializacin de entrada y
salida al servidor de clientes llegan y van a procesos de transformacin del
programa cliente diferentes.

3. 3. Decisiones.

Cuando hay secuencializacin 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 decisin lo
representaremos con la salida desde un proceso de transformacin de ms de
una flecha, colocando en la fecha la condicin que lleva a seguir esa va.

Observe el
ejemplo de la
figura. Un
acceso a
clientes puede
acabar
encontrando el
cliente o no. La
va de No
Existe lleva a
un proceso de
alta en el cual
se pedirn al
cliente sus
datos, mientras
que la va 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 tambin la representacin de una decisin, el anlisis de si un
cliente tiene crdito o no.

3. 4. Enlace entre diagramas.

Y la ltima consecuencia de la secuencializacin es que, muy
excepcionalmente, un diagrama de flujo a de empalmar con otro. Ver que,
en mi metodologa y debido a la utilizacin del anlisis descendente del que
hablar a continuacin, este caso es absolutamente opcional.

Dar de
Alta
Acceso a
Clientes
Pedir
Productos
Cliente
Clientes
No Existe
Existe

Figura 110. Ejemplo de Decisin dentro de la Secuencia de
Ejecucin.
Cuando esto ocurra, utilizaremos el mtodo de crear una entidad que sea de
salida del de origen y de entrada del de destino.

4. Anlisis descendente.

4. 1. Introduccin.

Como parte de la metodologa propuesta, y como explicaremos ms adelante,
para detallar los procesos se va a utilizar Anlisis Descendente. Si el lector
conoce este concepto puede omitir la lectura de este apartado.

4. 2. Concepto de accin, parmetro, efecto y estado.

Aqu asimilaremos accin a proceso de transformacin

4. 3. Especificacin.

La especificacin de una accin define el efecto del proceso de transformacin.

Para que una especificacin defina claramente el efecto debe contener:

La declaracin de parmetros.
Los estados inicial y final.
El nombre asignado al proceso, cabecera y como se utiliza.

Ha de ser concreta, precisa, unvoca y clara.

4. 4. Metodologa de especificacin.

Para obtener la especificacin de un proceso deben seguirse los siguientes
pasos:

Identificar los parmetros 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 parmetros
representan los datos encontrados.
Determinar los tipos de esos parmetros.
Se intentar asignar un tipo de datos entre los estndar. 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 categora o modo de los parmetros: entrada, salida o de
entrada / salida.
Definir la precondicin y la poscondicin.
Definiremos uno o ms postulados en la precondicin para cada
parmetro de entrada o de entrada / salida. El efecto esperado del
proceso se reflejar en la poscondicin incluyendo uno o ms postulados
por cada parmetro de salida o de entrada salida.
Asignaremos un nombre al proceso y el orden en que se le pasan los
parmetros. Es lo que normalmente se conoce como cabecera de la
llamada al proceso.

4. 5. Descomposicin de procesos. Concepto de primitiva.

Es intuitivo que para conseguir el efecto de un proceso ser necesario
descomponer el proceso que se ha de disear en otros ms 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
ms simples.

La descomposicin 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
prcticos siempre toman cuatro formas:

4.5.1. Sentencias.

Proporcionadas por los lenguajes de programacin.

4.5.2. Rutinas ya programadas.

Cuyo comportamiento estar perfectamente definido a travs de su
especificacin. El programador podr utilizarlas sin saber como se han
programado interiormente.

Para que las rutinas primitivas sean cmodas de utilizar, evitando
efectos colaterales no deseados, es necesario que las rutinas se
programen con tcnicas de encapsulamiento, se decir su nica
comunicacin 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 aplicacin del anterior ya que la utilizacin
de una pieza se realiza siempre a travs de rutinas.

4.5.4. Servicios.

Adquiridos o construidos.

4. 6. Metodologa del anlisis descendente.

Es necesario establecer una tcnica para realizar el refinamiento que permite
descomponer los procesos. Esta tcnica ser el anlisis descendente.

El anlisis descendente esta basado en el Teorema de la Composicin
Secuencial. Se entiende por composicin secuencial el efecto producido por la
combinacin de los efectos de dos o ms procesos que se ejecutan
secuencialmente.

Si se tiene un proceso S1 que lleva de una precondicin {P} a una
poscondicin {R} y otro proceso S2 que lleva de la misma precondicin {R} a
una poscondicin {Q}, el efecto combinado de S1;S2, que representaremos por
S, es llevar de la precondicin {P} a la poscondicin {Q}.

Algebraicamente el teorema de composicin secuencial de procesos adopta la
forma:

{P}
S1 {P}
{R} S donde SS1;S2
S2 {Q}
{Q}

La utilizacin inversa del teorema de composicin proporciona la tcnica
simple, robusta y muy potente para descomponer procesos.

Si se tiene un proceso S que ha de llevar de la precondicin {P} a la
poscondicin {Q} podemos descomponerla en otras dos S1; S2 encontrando un
estado intermedio {R} que sea poscondicin de la primera y precondicin de la
segunda. El teorema de composicin secuencial garantiza la validez de la
descomposicin.

Evidentemente, el teorema y la tcnica pueden generalizarse al caso en que S
sea composicin de ms de un proceso: SS1; S2;.......; Sn.

As la metodologa de anlisis descendente como tcnica de descomposicin
de procesos adopta la metodologa siguiente.

Se especifica el proceso que se quiere disear.
El proceso de descompone en dos o ms procesos que se ejecutan
secuencialmente obteniendo estados intermedios que sean precondicin
del anterior y poscondicin del siguiente.
Evidentemente el estado inicial es la precondicin y el final es la
poscondicin del proceso a disear.
El proceso se aplica recursivamente y el refinamiento acaba cuando
todos los procesos finales son primitivas o ya han salido anteriormente.
Todos los parmetros del proceso a disear han de aparecer como
entradas o salidas, segn su categora, de como mnimo un proceso de
los obtenidos por descomposicin. Es habitual que por el camino se
obtengan otros objetos intermedios de trabajo que siempre quedarn
internos, locales, al proceso que se est diseando.

Es habitual representar
grficamente el resultado
de la descomposicin con
un grafo como es de la
figura.

Sin embargo la experiencia
demuestra que esta
representacin grfica, que
es muy clara, en ejemplos
simples queda gravemente
limitada es casos reales ya
que la profundidad del rbol
yo hace de muy difcil representacin grfica y adems puede haber procesos
elementales utilizados en ms de un nivel y a diferentes profundidades.

S
S1
S2
S11
S12
S13
S12a
S12b

Figura 111. Anlisis Descendente
4. 7. Ejemplos.

Veamos la utilizacin de anlisis descendente a dos ejemplos muy simples.

4.7.1. Contar consonantes despus de la aparicin de una vocal en un texto.

La especificacin del proceso a disear es:

var S: texto de carcter; compt: entero
{S est informado}
contar(ent S, sal compt)
{compt tiene el nmero de consonantes despus de la primera vocal del
texto}.

Aplicando anlisis 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 nmero de consonantes despus de la primera
vocal del texto}.

Los procesos de buscar_la_primera_local y contar_consonates no son
primitivas. La asignacin del valor 0 a compt si lo es.

Habr que aplicar de nuevo anlisis 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 funcin vocal ser:

funcin vocal(ent valor c: carcter)
retorna (c=A o c=E o c=I o c=O o c=U)
ffuncin

La funcin contar_consonante es

contar_consonante (S,compt)
{S esta situado en la primera vocal}
compt:=0
mientras no fi(S) hacer
si no vocal(caracter_actual(S)) entonces
compt:=compt+1 fsi
situar_el_caracter_seguient(S)
fmientras
{compt tiene el nmero de consonantes despus de la primera
vocal del texto y fi(S)}

4.7.2. Pedir un cdigo de cliente y sacarlo por la pantalla

La especificacin 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.cdigo}.

Si obtener_datos_cliente es un servidor y la gestin de pantallas son
servicios del sistema (primitivas), el diseo ya ha acabado.

4. 8. Porqu utilizar anlisis descendente?

Adems de su simplicidad y potencia, es aplicable a todos los mbitos, datos y
procesos.

Supone una metodologa de general a detalle (top-down) fcil de aplicar y
sistematizar. La claves es una buena eleccin del estado intermedio con el cual
se rompe el proceso que estamos diseando y disponer de buenas primitivas
en cantidad y calidad. El divide y vencers siempre es una buena tctica.
Adems, el concepto de primitiva liga perfectamente con el de reutilizacin.

La tcnica de anlisis descendente puede potenciarse con otras que permitan
especificacin formal y verificacin analtica. Sin embargo entrar en ellas queda
fuera del mbito de este libro. El lector podr consultar documentacin
especfica se desea ampliar los conceptos expuestos aqu.

5. Diagramas Jerrquicos.

Los diagramas jerrquicos permiten el anlisis de la funcionalidad por reas. Los
procesos de transformacin se agrupan por temas y grupos de ejecucin.

Marcan la jerarqua de control y ejecucin, conocida, a veces, como jerarqua de
programa. No representan aspectos procedimentales del tipo secuencia de
procesos, decisin de procesos, etc.

Al ser jerrquicos, permiten establecer relaciones entre mdulos como: mdulo
superior, subordinado,
visibilidad,
conexiones, etc. En
efecto, observe el
diagrama jerrquico
de la figura. La
aplicacin se ha
dividido en cuatro
subsistemas. Cada
subsistema tendr
mdulos y los
mdulos integrarn
funciones.

No son, pues, de inters para el diseo distribuido de forma directa. Pero si lo son
de forma indirecta ya que la mayora de los procesos cliente en las arquitecturas
distribuidas son programas con interfaces GUIs, especialmente en RDA, y los
diagramas jerrquicos son, por su naturaleza, la forma ms cmoda de establecer
la jerarqua de
pantallas y mens en
que se organiza la
aplicacin.

Aunque no hay una
regla de obligado
cumplimento, el
diagrama jerrquico
de la figura llevara a
una pantalla principal
asociada a la
aplicacin en la que
habra un men cada
uno de los subsistemas. Un submen asociado a cada subsistema desplegara los
mdulos de ese subsistema. La llamada al mdulo llevara, probablemente, a una
nueva GUIs donde se trataran un men o por botones cada funcin.

Los diagramas jerrquicos no obligan a que todas las funciones que desarrollan
cada mdulo sean independientes entre si. Puede ocurrir, y de hecho pasa
habitualmente, que ms de un mdulo compartan una nica funcin, tal como se
representa en el diagrama de la figura. Evidentemente, este hecho no supone
ninguna complicacin adicional a la hora de plantear los mens.

Finalmente, en la
figura de la derecha
se muestra un
ejemplo de un
diagrama jerrquico
aplicado a una
aplicacin de
produccin y stock.

Subsistema 1
Mdulo A
Funcin 1 Funcin 2 Funcin 3 Funcin 4
Mdulo B Mdulo C
Subsistema 2 Subsistema 3 Subsistema 4
APLICACIN

Figura 112. Diagrama Jerrquico
Mdulo A
Funcin 1 Funcin 2
Mdulo B
Subsistema 1 Subsistema 3
Mdulo C Mdulo D
Funcin 3
Subsistema 4
APLICACIN

Figura 113. Diagrama Jerrquico con funciones compartidas
Gestin
Almacenes
Inventario
Valorado
STOCKS
Ofertas
Lanzamiento
Control
Calidad
Entrada
a Stocks
Recepcin
Pedidos
COMPRAS
Planificacin Seguimiento Rebajar
de Stocks
PRODUCCIN
FABRICACIN

Figura 114. Ejemplo de Diagrama Jerrquico.
Descripcin de los Datos en un Modelo
Relacional

1. Introduccin.

Le voy a presentar en esta parte del libro las dos formas bsicas, que a mi juicio,
pueden utilizarse para describir los datos en los diseos de las aplicaciones
distribuidas:

El Modelo Relacional
El Modelo de Objetos de las metodologas OO.

El segundo es el adecuado para las aplicaciones avanzadas. Para las aplicaciones
rpidas, puede utilizarse el modelo relacional, aunque no desprecie la posibilidad
de utilizar tambin 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 captulo posterior
implementar un modelo de objetos sobre un SBDR relacional supone la aplicacin
de unas reglas de mapeo de una facilidad extraordinaria. Por esa razn, describir
OO aprovechando las ventajas de su mayor potencia semntica, e implementar
relacional se convierte en una va muy interesante.

Este captulo est dedicado a dos temas:

O Establecer una terminologa base de datos para que usted y yo nos
entendamos.
O Recordar (slo recordar!) los fundamentos bsicos del modelo relacional.

Dejaremos para un captulo posterior el recordatorio del modelo de datos en una
metodologa OO.

2. Terminologa bsica para la descripcin de los datos. El Modelo de
Datos.

Establezcamos una terminologa bsica 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 adems de datos comportamiento.

La descripcin de las entidades se realiza a travs de sus atributos. As, una
Persona tiene un Nombre, un DNI, una altura...., un Coche tiene un color, un motor,
un fabricante....

Los atributos de una entidad se representan por un tipo de dato. Por ejemplo, la
altura de una persona es un real, su edad un entero, su nombre un string.... Los
atributos de una entidad toman un valor del domino o rango de valores que
caracterizan al tipo.

En la inmensa mayora de los casos, los atributos no pueden tomar cualquiera de
los valores del dominio de su tipo, sino que los valores posibles estn limitados y
acotados por restricciones; as, la altura de una persona su puede ser cuatro
metros ni la edad mayor que 140 aos, al menos que usted lector no sea un
extraterrestre. Si es usted un vulcaniano como el Sr. Spoc esta restriccin deber
ampliarse. Es fcil, 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 combinacin de valores de sus atributos que cumplen las restricciones (valores
vlidos). Usar el trmino instancia.

Entre las entidades se establecen relaciones. As, una instancia de la entidad
Factura es de una instancia de la entidad Cliente. La relacin se establece entre
instancias de la entidad a travs de atributos comunes; en el ejemplo anterior el
cdigo de cliente.

Existen dos tipos de relaciones, estticas y dinmicas.

As la relacin pertenece a que se establece entre Persona y Raza es esttica ya
que es indisoluble. De otra parte, la relacin pareja que se establece entre dos
miembros de la entidad Persona es dinmica ya que puede cambiar sin afectar a la
naturaleza de las instancias afectadas.

La diferenciacin entre ambos tipos de relaciones no es sencilla y en algunos
atributos puede ser ambigua. As la relacin entre una factura y su cliente, es
esttica o dinmica?

Ms adelante se establecer una clasificacin de las relaciones en especializacin
o herencia, agrupacin y asociacin.

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 organizacin de datos estructurado segn un modelo matemtico
(lgebra Relacional) que establece una separacin y una relacin entre los
modelos lgicos y fsicos.

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 coleccin de tablas que representan entidades. Las
tablas tienen un nmero de columnas que se corresponden con los atributos de la
entidad. Las filas de las tablas se denominan tuplas y se corresponden con
registros. Un valor se almacena en la interseccin 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 ms atributos. La clave principal se utiliza para
mantenimiento y las claves secundarias para mejorar los tiempos de acceso.

Una vez diseadas las tablas quedan definidas unas relaciones entre las
entidades. Estas relaciones se representan por medio de un esquema grfico que
se conoce como Diagrama Entidad-Relacin (E-R). Cada cuadro del diagrama
representa una relacin y cada lnea una clave fornea que no es ms que una
relacin establecida entre dos entidades por uno o ms atributos comunes.

ejemplo de un diagrama
E-R

Cada relacin 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
organizacin de las tablas. Hay mltiples niveles de formas normales, cada una un
paso ms restrictivo del anterior. Consulte documentacin especializada si desea
ms informacin. Pero recuerde: cuanto ms profundo baje, ms problemas de
rendimiento encontrar. Busque el punto de equilibrio.

4. ANSI/SPARC three schema architecture.

Es una arquitectura estndar de tres niveles propuesta por ANSI/SPARC, un comit
de DBMS. La idea bsica es que es diseo de la BD se estructura a tres niveles:

Empleado
Oficina
Trabaja en
Perfil
Experto en
Experiencia
Departamento
Ligado a
Jefe
1
M
M
M
1 1
1
M

Figura 115. Ejemplo de Modelo Relacional
4. 1. Esquema externo (External Schema).

Es la visin de la
aplicacin. 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 lgico, define la
estructura de la
informacin de forma
genrica, desde la
perspectiva del inters general.

4. 3. Esquema Interno (Internal Esquema).

Es el nivel fsico. Implementa el modelo conceptual segn las reglas del DBMS
escogido. Este nivel traduce el esquema conceptual a un cdigo 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 unvoca
a cada fila.

5. 2. Validity Check Constraints.

Las restricciones de integridad de valores vlidos (Validity Check Constraints)
limitan los valores que pueden aparecer en una columna adems 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 modificacin (UPDATE).

5. 3. SQL-92 domains and assertions.

Estos dos tipos de restricciones de integridad fueron introducidos por la
revisin del SQL realizada en 1992.
Esquema Conceptual
Esquema
Externo 1
Esquema
Externo N
Esquema
Externo 2
Aplicacin 1 Aplicacin 2 Aplicacin 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

Un dominio (domain) es una restriccin adicional de los valores de los datos
que pueden aparecer en una columna y que proporciona una forma ms
precisa de definir el tipo. Un dominio puede crearse, alterarse y eliminarse.

Las aserciones (assertions) son un mecanismo que permiten asociar reglas de
restriccin 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 vlidas.

Les regles son especificadas dentro del comando CREATE TABLE mediante
los dos conjuntos de claves relacionales, primarias y forneas: las claves
forneas han de existir dentro de las claves primarias de las tablas
referenciadas.

5. 5. Referencial triggered actions.

Se conocen tambin como reglas de modificacin o borrado y especifican como
tratar filas que dependen entre s cuando se borra o modifica una de esas filas
relacionadas.

Por cada clave fornea se pueden especificar una entre cuatro clases de este
tipo de acciones:

NOACTION rule: no borrar o no modificar si hay una restriccin de
integridad.
SET NULL rule: las claves forneas se colocan automticamente a
NULL.
CASCADE rule: se borran o modifican automticamente 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 lgicos producidos por la vulneracin de
las relaciones de integridad producen acciones diferentes segn el Middleware
utilizado.

La situacin ideal sera que se produjera un retorno de error lgico que el
programa pudiera interceptar siempre y tratar segn su conveniencia. Pero,
desgraciadamente, algunos de los productos de Middleware reaccionan
automticamente produciendo un error que aparece y necesita aceptacin en
el punto donde se ha producido el acceso a la BD que ha producido la
violacin. Si la lgica de datos est en el cliente, el nico efecto ser folklrico:
aparece un mensaje indescifrable para el usuario, que despus del susto,
producir una llamada al departamento de soporte la primera vez que
aparezca.

Eso si el usuario llama claro est. Le cuento una ancdota: un programa de
entrada de datos creado por una persona de mi equipo produca un error en
cada alta que no apareci en fase de pruebas. Un usuario se paso toda la
maana entrando datos y aceptando un mensaje en ingls que el sistema
presentaba tras cada alta para avisarle que el alta no se haba llegado a
producir por la violacin de una restriccin de integridad. Durante la comida, y
comentndolo con un compaero ms experto, el usuario descubri que haba
perdido la maana.

Y eso en el mejor de los casos. Si usted es un buen diseador y encapsula en
servidores su lgica de datos compleja puede localizar el servidor en una
mquina 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 da todas lo son) si su diseo ha sido
activo o pasivo; es este segundo caso, a efectos prcticos es evidente que
la base de datos se ha de tratar como pasiva.

Y siempre existe una posibilidad: no delegar a la BD la comprobacin de las
restricciones de integridad y verificarlas como parte de la lgica de datos
de la aplicacin.

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, lgicos y fsicos,
detectados y producidos.

Ello obliga a que todos los programas
verifiquen las condiciones de integridad.

Este hecho hace fundamental un diseo
cuidadoso que encapsule totalmente en
piezas esas verificaciones. Si las piezas se linkan con los clientes las aplicaciones
resultantes tendern a ser fat client en datos. Si se montan en servidores de lgica
de datos, las sern ms fat server. La primera solucin es la escogida en
aplicaciones de desarrollo rpido, mientras que la segunda en la solucin adoptada
en las aplicaciones avanzadas. Haga lo que haga, por favor, encapsule en piezas
para garantizar un tratamiento nico y fcilmente 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 situacin
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 diseo del esquema incorpora estros
mecanismos que se ocultan al programa facilitando la programacin, centralizando
parte de la lgica de datos y mejorando los tiempos de respuesta.

Schema
Results
Operations
DBMS

Figura 117. Bases de datos pasivas
Sin embargo, el inconveniente es que todos estos mecanismos estn ligados al
motor y dejan las aplicaciones distribuidas en lugar de distribuibles. Y eso es, hoy
da, 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 adems de
resultados triggers que disparan
eventos que se tratan internamente a la
base de datos y oculto de los
programas.

Trataremos a continuacin algunos de
los mecanismos que incorporan las
bases de datos activas y comentaremos
su impacto en los diseos distribuidos.

7. Triggers.

Los triggers son, en general, reacciones del sistema delante de una determinada
situacin. 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 accin ya sido ampliamente
popularizado por las interfcies grficas, aunque se primera aplicacin masiva se
produjo en el mundo
de las bases de
datos.

La reaccin de un
evento disparado
por un trigger es
recomendable, tanto
en BD como en
GUIs, 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 segn su
propsito:

7. 1. Control de Acceso.

Monitorizacin de acceso a datos.
Deteccin 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

7. 2. Control de Integridad.

Comprobacin de las restricciones de integridad y disparo de las
acciones de restauracin.
Verificacin de las restricciones de integridad entre bases de datos
heterogneas, de gran inters en los entornos distribuidos donde se han
producido Upsizing.

7. 3. Soporte de datos.

Propagacin de modificaciones sobre datos derivados.
Actualizaciones inmediatas, peridicas o producidas por un
acontecimiento.

7. 4. Notificacin de cambios y transiciones de la BD.

Reconocimiento de condiciones complejas sobre estados de las bases
de datos
Identificacin de transiciones entre estados y lanzamiento de acciones
asociadas.

7. 5. Medidas de rendimiento.

Control y traza de eventos.
Estadsticas para posteriores optimizaciones.
Inicio de tcnicas de balance de la carga.

7. 6. Reglas.

Una regla es un tipo especial de trigger que se utiliza para realizar checkings
de datos. Pueden realizar muchas acciones complejas mediante la potencia de
un lenguaje procedural ligado a la base da datos.

7. 7. Gestin de triggers de la BD en entornos distribuidos.

Para que los diseos 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
travs de la transaccin, debe devolver un error lgico con suficiente contenido
semntico para que sea capaz de gestionar ese error convenientemente.

8. Vistas.

Una vista es una abstraccin 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 dinmicamente
cuando se abre.

La utilidad de las vistas es muy amplia:

O Definir visiones simplificadoras de la BD que la acerquen a la visin que se
necesita en cada momento.
O Eliminar las desventajas de la evolucin manteniendo, a efectos de gestin, el
esquema anterior.
O Una forma de implementacin 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 Integracin de esquemas de datos
distribuidos.

Esta ltima utilidad slo puede aplicarse s:

O Las dos bases de datos son relacionales.
O Las tablas estn repartidas entre los
esquemas, y obviamente sola hay una de
cada entidad en el total de esquemas.

La vista define el esquema comn. Como
opcin adicional puede encapsularse el acceso
a la vista en una pieza.

En todo caso, recuerde, la vista slo 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 ms. A efectos de
programacin ODBC y ADO no son ni ms ni menos que una puerta SQL estndar
e independiente del motor que permite un acceso unificado y homogneo.

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
Aplicacin

Figura 120. Vistas e Integracin de
BD's
Mtodo de Anlisis Funcional para
Aplicaciones de Desarrollo Rpido.

1. Introduccin.

Con los elementos funcionales y de descripcin de datos expuestos en los captulos
anteriores estamos ya en condiciones de establecer el mtodo de anlisis funcional
que le propongo aplicar a las aplicaciones de desarrollo rpido y a los ejemplos de
este libro.

Slo una salvedad. El modelo de datos puede establecerse segn el modelo
relacional, ya presentado, o segn un modelo de objetos que le presentar en el
captulo siguiente al hablar del anlisis de aplicaciones avanzadas. Si no lo conoce,
creo que es mejor que lea primero este captulo y ya lo visitar en el siguiente.

2. Mtodo de Anlisis Funcional de Desarrollo Rpido de Aplicaciones
(MAFDRA).

MAFDRA est basado en el anlisis del flujo de la informacin. Toma como base
los diagramas de flujo ampliados y como metodologa anlisis descendente.

Desde la especificacin, MAFDRA propone cinco etapas con pasos a cumplir en
cada etapa:

2. 1. Diseo de los datos.

1. Identificacin de las entidades.
2. Identificacin de los atributos de esas entidades.
3. Identificar las claves primarias y secundarias.
4. Asignacin de tipos a esos atributos.
5. Establecer los criterios de codificacin.
6. Creacin del Diccionario de Conceptos con la explicacin de los atributos (s
la necesitan). Ms adelante, y durante el desarrollo de los procesos se irn
incorporando todos aquellos que vayan surgiendo cono conceptos derivados,
conceptos de operacin, etc. La idea es incorporar de forma centralizada y
unificada todo aquello que sea necesario precisar.
7. Identificacin de las restricciones de integridad.
8. Identificacin de las relaciones entre las entidades y con ello las claves
forneas.
9. Diseo del modelo de datos mediante:
9.1. Modelo Relacional.
9.2. Modelo de Objetos OO. Si se escoge este segundo mtodo habr que
mapear el modelo de objetos al modelo relacional.

2. 2. Identificacin de los procesos bsicos.

1. Se identifican sobre la especificacin los procesos lgicos bsicos.
2. Estos procesos bsicos se organizan por unidades lgicas.
3. Se crea un diagrama jerrquico con un primer nivel formado por las unidades
lgicas y un segundo por los procesos bsicos que integran. Si el rbol
resultante es muy ancho o profundo utilice la tcnica de desarrollar hojas en
diagramas jerrquicos independientes.
4. Las funciones de cada unidad lgica se explican en una Descripcin
Funcional de la Aplicacin.
5. Todo ello se puede organizar en un documento con una estructura del tipo:
5.1. Introduccin: mbito, especificacin, objetivos bsicos de la aplicacin,
bibliografa, justificacin, etc.
5.2. Diccionario de Conceptos.
5.3. Descripcin funcional: unidades lgicas, procesos identificados, visin
funcional conjunta, operativas de explotacin y, en general, cualquier otra
funcional adicional de inters para explicar y entender el funcional.
5.4. Codificacin.
5.5. Descripcin de los datos.
5.6. Volmenes y condicionamientos tecnolgicos, si los hay: tiempos
mximos de respuesta, infraestructura, etc.
5.7. Un capitulo por cada unidad lgica que incluye descripcin de sus
procesos. Incluye el diseo de la lgica de presentacin, listados e
integracin de los procesos cliente.

Los puntos 1 a 3 es documentacin compartida con el usuario y, por esa razn,
debe estar redactada en trminos que una persona no informtica pueda
entender. El resto de puntos es informacin tcnica.

2. 3. Diseo de los procesos.

1. Asimilar cada proceso bsico a un nico proceso de transformacin en que
cada una de las entradas y salidas del sistema se asimila a un parmetro.
Con ello se dibuja el primer diagrama de flujo.
2. Se aplica anlisis descendente a este proceso de transformacin bsico
descomponindolo en dos o ms procesos. Las entradas y salidas de
proceso inicial se distribuyen entre los nuevos procesos obtenidos. Se
marca la secuencia de ejecucin con los recursos de los diagramas de flujo
extendidos.
3. Se incorporan al diagrama de flujos resultante los parmetros intermedios
necesarios para interconectar los procesos de transformacin resultantes.
4. El proceso se repite hasta que se obtienen:
Procesos de transformacin ya diseados.
Acceso directo a datos.
Procesos que usen de forma directa primitivas sin aportar lgica
adicional.
Procesos de presentacin o de listado.

2. 4. Diseo de la lgica de presentacin.

1. La lgica de presentacin se incorpora en GUIs. Ms adelante encontrar un
captulo sobre este tema.
2. Se propone el formato de los listados.

2. 5. Organizacin de la explotacin.

Se integran en el diagrama jerrquico inicial los puntos de entrada directos, si
los hay, de los procesos de transformacin obtenidos por descomposicin.

3. Desarrollo de un ejemplo.

3. 1. Reflexin previa.

Este no es un libro de anlisis. Los anlisis funcionales utilizados no sern
completos, slo incluirn aquello necesario para preparar los ejemplos
utilizados para implementar el diseo distribuido.

Si usted desea practicar completamente los mtodos funcionales, extienda lo
aqu expuesto empezando por completar la especificacin inicial y desde ah
desarrollar el funcional completo.

3. 2. Especificacin inicial.

Se ha de crear un sistema de venta de viajes areos conjuntamente con
pernoctaciones en hoteles si el cliente lo necesita. El sistema se gestionar
mediante una red de delegaciones de venta. Cada delegacin es una tienda u
oficina de atencin al pblico.

La tienda ha de atender a los clientes, venderles sobre catlogo 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 estadsticas de venta por cliente y por vuelos, no por hoteles. Estas
estadsticas se utilizan solo en la central.

El proceso de venda debe proporcionar al cliente un albarn de reserva de la
contratacin realizada.

El cobro se realiza por domiciliacin bancaria mediante una factura mensual
que agrupa todos los albaranes de ese mes. La facturacin se realiza un
sistema de facturacin centralizado ya diseado. El sistema a crear debe
realizar una interfase con el sistema de facturacin ya creado.

Cada cliente tiene un crdito asignado que se gestiona en la central. El
algoritmo de asignacin de crdito 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 crdito 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 compaas areas disponen de un servicio RPC remoto para pedir
reservas de vuelos. Este servicio reserva las plazas pedidas o devuelve aviso
de que no estn disponibles.

Las consultas sobre los vuelos se realizan a travs de la WEB de cada
compaa.

La consulta de disponibilidad de hoteles y la reserva de habitaciones se realiza
a travs de un servicio centralizado para toda la organizacin donde se
autorizan los hoteles con que se puede trabajar.

3. 3. Diseo de datos.

De la especificacin se identifican las siguientes entidades:

Clientes.
Cuentas analticas de clientes.
Movimientos de cuentas analticas de clientes.
Compaas areas.
Vuelos.
Hoteles.
Plazas de hoteles

Las entidades Cuentas Analticas y Movimientos de Cuentas Analticas
implementan la entidad lgica de Cuentas de Clientes, las entidades
Compaas Areas y Vuelos implementan la entidad Datos Compaa Area 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
Direccin String 4x40 La direccin no tiene estructura
prefijada
Grupo Contable String 6 Clave fornea. Ver Diccionario de
Conceptos
Cuenta Contable String 10 Clave Fornea.
Etc.

Cuentas Analticas de Clientes
Grupo Contable String 6 Ver Diccionario de Conceptos
Cuenta Contable String 10
Descripcin String 50
Grupo de
Balance
String 1 Ver Diccionario de Conceptos
Crdito asignado Nmero 10,2
Etc.

Movimientos de Cuentas Analticas de Clientes
Grupo Contable String 6 Ver Diccionario de Conceptos
Cuenta Contable String 10
Fecha de la
anotacin
Fecha 8
Concepto String 30
Importe Real 10,2
Etc.

Compaas Areas
Compaa String 4
Nombre String 50
Numero para
pedir reservas
Vase diccionario de conceptos
Etc.

Vuelos
Compaa String 4 Clave fornea
Nmero Vuelo String 4
Etc.

Hoteles
Hotel String 20
Nombre String 50
Etc.

Plazas de hotel
Hotel String 20 Clave fornea
Da Fecha 8
Numero de
habitaciones
Small
Integer
5
Habitaciones
reservadas
Small
Integer
5
Etc.

Restricciones de Integridad.

Se deberan identificar en este punto las restricciones de integridad. Dado el
carcter docente de este ejemplo, dejo este trabajo para el lector.

Relaciones.

Se identifican las relaciones:

Corresponde a: los clientes se asocian a una cuenta analtica a travs de
las claves forneas grupo y cuenta contable.
Es movimiento de: los movimientos de ventas y cobros se relacionan con
las cuentas analticas a travs de las claves forneas grupo y cuenta
contable.
Servido por: Los Vuelos se asocian a Compaas a travs de la clave
fornea.
Habitacin de: Las habitaciones se asocian a Hoteles a travs de la clave
fornea.
Viaje Comprado por: Los vuelos se relacionan con los clientes que los
han contratado mediante una relacin con atributos implementada en una
tabla:

Vuelos por Cliente
Cliente String 14 Clave fornea
Compaa String 4 Clave fornea
Vuelo String 4 Clave fornea
Fecha del vuelo Fecha 8
Nmero de
plazas vendidas
Small
Integer
3
Etc.

Esta tabla tiene como claves primarias cliente, compaa y vuelo. Necesitar
unas claves secundarias por compaa, vuelo y cliente para gestionar una de
las estadsticas pedidas.

Codificacin.

La clave primaria del cliente es su DNI.
La clave primaria de cada compaa rea es su pre-cdigo de vuelos.
La clave primaria de vuelos en una clave doble formada por el cdigo de
la compaa y el nmero del vuelo dentro de la compaa.
Los hoteles se referencian secuencialmente.
La clave primaria de habitaciones es una clave doble formada por el
cdigo del hotel el da.
La fecha se codifican en formato String: AAAAMMDD donde AAAA es el
ao, MM es el mes y DD es el da. 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
ms 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 ms habituales de gestin de fecha:
verificacin, comparacin, das entre dos fechas, obtencin de forma
separada del ao, mes y da de forma, etc.
Un formato de nmero 10,2 indica 10 cifras de las cuales 2 son
decimales.
Conviene matizar la precisin de los enteros entre Small y Long.

Diccionario de Conceptos:

Concepto Descripcin
Cuenta Contable Vase la descripcin 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 explotacin donde se
acumula el saldo de la cuenta.
Nmero de reservas Nmero telefnico proporcionado por cada
Compaa area para pedir el servicio RPC de
reserva de plazas en sus vuelos.

Con todo ello ya estamos en condiciones de proponer un modelo de datos que
reflejaremos en el esquema relacional de la figura.

3. 4. Identificacin de los procesos bsicos.

En la especificacin se identifican tres procesos lgicos bsicos agrupados en
dos unidades lgicas, Proceso de Ventas y Estadsticas. En el diagrama
jerrquico de la figura se muestra la primera organizacin de procesos.

El mantenimiento de los ficheros bsicos se realiza a travs de programas de
mantenimiento interactivo con presentacin GUI. El diseo de estos procesos
se realiza directamente
dentro del apartado de
componente de
presentacin
proponiendo un
Framework que se
personaliza para cada
uno de los ficheros
bsicos.

El diseo de los
procesos de Ventas y
Estadsticas se
desarrolla a
continuacin.

3. 5. Diseo del Proceso de Venta de Viajes Areos y Hotel.

Cliente
Cuenta
Analtica
Vuelos
Viajes
Comprados
por
Vuelos
por
Cliente
1
M
1
N
Corresponde a
Anotaciones
Cuenta
Analtica
1
M
Es movimiento de Compaa
Servido por
M 1
Plazas
Hotel
Hoteles
Habitacin de
M 1

Figura 121. Modelo de datos.
Venta de Vuelos en
Delegaciones
Proceso de Ventas Estadsticas
Obtencin
Estadsticas
Mantenimiento de
ficheros bsicos
Venta Viaje Areo
y Hotel

Figura 122. Diagrama Jerrquico inicial de unidades y
procesos lgicos
El proceso se asimila
inicialmente al
proceso de
transformacin del
diagrama de flujo de
la figura.

Las entradas y
salidas esperadas de
los procesos se
distribuyen alrededor
del proceso de
transformacin
bsico.

Aplicando de forma
reiterada anlisis
descendente en el
primer refinamiento el proceso bsico inicial se descompone en otros cuatro:

Registro de la
Peticin del
Cliente.
Actualizacin de
Datos en la
compaa area.
e internos.
Impresin de la
Reserva del
cliente.
Consulta datos
de vuelos.

Para enlazar
internamente los tres
primeros aparece un
almacn interno para
registrar la peticin del
cliente. Distribuyendo
las entradas y salidas
del proceso de transformacin 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
Webs de las Compaas

Refinando seguidamente el proceso de Entrada de la Peticin se obtiene el
diagrama de flujo la figura en el cual se identifican los procesos Pedir al Cliente
su identificacin, Acceder a los Datos del Cliente, Registro de los Datos del
Cliente en la peticin, Pedir el Viaje elegido, Consultar el Crdito del Cliente
para verificar si tiene crdito 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 Areo
y Hotel
Datos Compaa Area
Cuentas Clientes
Clientes
Vuelos por cliente
Reserva
Cliente
Crdito estndar
Datos Hotel

Figura 123. Proceso de Venta de Viaje Areo
Peticin Cliente
Actualiza
Datos
Datos Compaa Area
Clientes
Entrada
Peticin
Cliente
Clientes
Vuelos por Cliente
Reserva
Cliente
Impresin
Reserva
Crdito Estndar Datos Hotel
Consulta
datos de
vuelos

Figura 124. Primer proceso de refinamiento de Venta Viaje y Hotel a
Cliente

Cliente
Peticin Cliente
Registro
Datos
Cliente
Peticin
Cliente
Acceso
Datos
Cliente
Registro
Datos
Viaje
Consulta
Cuenta
Cliente
Cuenta Clientes
Rechazar
Venta
Alta
Cliente
Cliente
Re-intentar
Crdito Estndar
No crdito
Sin hotel

Figura 125. Refinamiento de Entrada de la Peticin

Una opcin alternativa sera aprovechar la propia GUI para implementar la
entidad Peticin Cliente. La entrada para Reintentar se tratar ms adelante y
la salida de sin hotel se obtiene del refinamiento del proceso Registro de los
datos del Viaje del cual se habla a continuacin.

Si refinamos el
proceso de Registro
de Datos del Viaje
tendremos el
diagrama siguiente
donde se ha previsto
la posibilidad de que
los hoteles estn
completos.

En este caso se
preguntar al cliente
y si no necesita
forzosamente la
habitacin 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
peticin de cliente el hecho de que la operacin es sin hotel.

Vendedor
Peticin Cliente
Registrar
Datos
Vuelo
Registro
Datos
Hotel
Datos Compaa Area
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
Todos los procesos de entrada de peticin pueden considerarse ya primitivas
ya que usarn operaciones simples y bien definidas. Todas excepto el proceso
de Alta de Clientes, que vamos a disear a continuacin.

Si aislamos este proceso, obtendremos el proceso de transformacin de la
parte superior
de la figura.
Aplicando
anlisis
descendente,
el proceso de
alta puede
dividirse en
tres: Peticin
de los Datos al
cliente,
Incorporar los
datos al fichero
de Clientes y
Asignar el
Crdito para
generar la
Cuenta
Analtica 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 tambin primitivas a
efectos de la metodologa.

Diseemos,
finalmente, el proceso
de Actualizar Datos.
Aplicando anlisis
descendente se
obtienen, en principio
los procesos:
Actualizar Compaa
Area, para reservar
las plazas en el vuelo
elegido, Actualizar los
datos del Hotel con la
reserva de la
habitacin, Anotacin
en la Cuenta del
Cliente, para iniciar el
proceso de cobro y
aumentar el riesgo, y
Anotacin 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
Crdito
Crdito Estndar
Alta
Cliente
Cliente
Cliente
Cuenta Cliente
Crdito Estndar

Figura 127. Proceso de Alta de Clientes
Peticin Cliente
Actualiza
reserva
c.area
Datos Compaa Area
Datos Hotel
Actualiza
datos
hotel
Vuelos por Cliente
Anotacin
del vuelo por
Cliente
Aviso
al
Cliente
Anular
Venta
Re-intentar
Cliente
No hay plazas
Hay plazas
Anotacin
Cuenta
Cliente
Cuenta Clientes

Figura 128. Proceso para Actualizar Datos.
peticin de nuevo del vuelo al cliente. Esta salida se asimila a una entidad Re-
intentar que conecta este diagrama de flujo con el de Peticin 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 aadido.

3. 6. Diseo del Proceso de Estadsticas.

El diseo del proceso de
Estadsticas puede
representarse por el
diagrama de flujo de la
figura.

La entidad Vuelos por
Clientes generada a partir
del proceso de Venta de
Viajes Areos es la entrada
principal de este proceso de
estadsticas.

Aparece como parmetro a
proporcionar al proceso el
periodo a listar.

Aplicando anlisis
descendente al proceso
bsico de estadsticas
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. Diseo de los
componentes de presentacin.

A las pantallas GUI identificadas se asignarn un cdigo y se disearn con la
metodologa de cada instalacin. Aunque el diseo GUI no tiene nada a ver con
el diseo distribuido, como la integracin GUI es frecuente en el mundo
distribuido dedicaremos un tiempo ms adelante a presentar criterios y
consejos.

3. 8. Diseo de los listados.

Estadsticas
Datos Compaa rea
Clientes
Vuelos por cliente
Venta por
Cliente
Periodo a Listar
Venta por
Vuelo

Figura 129. Proceso de Estadsticas
Entrada
Periodo a
Listar
Datos Compaa 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 Estadsticas
Se realizarn mediante un esquema donde se relacione la cabecera, los totales
de agrupacin y la lnea de detalle.

No los desarrollar aqu. Usted amigo lector, puede realizarlos se decide
completar el ejercicio.

3. 9. Organizacin de la explotacin.

Finalmente, conviene aadir al diagrama jerrquico inicial el proceso bsico de
alta como de primer nivel y desglosar los procesos bsicos en los obtenidos en
el diseo de esos procesos bsicos.
Venta de Vuelos en
Delegaciones
Obtencin Estadsticas
Mantenimiento de
ficheros bsicos
Alta de Clientes Venta Viaje Areo
Registro de la peticin
Actualizaciones
Compaa Area
Hotel
Cuenta cliente
Venta por cliente
Venta por vuelo Datos Vuelo
Datos Hotel
Vuelos por cliente

Figura 131. Diagrama jerrquico ampliado

@@EMG/10- Enric Martnez Gomriz
203
Diseo Funcional de Aplicaciones
Avanzadas Introduccin a la Orientacin a
Objetos

1. Introduccin.

El diseo funcional de las aplicaciones distribuidas avanzadas debe atacarse con
metodologas OO. Lo creo firmemente.

Aunque puede usarse cualquier otra metodologa funcional completa, la ntima
relacin entre distribucin y OO de la que ya hemos hablado anteriormente, hace
que esa solucin sea, a mi juicio, la mejor con diferencia.

Y evidentemente, la amplitud de una metodologa OO basada en UML queda fuera
del abasto de este libro.

De cualquier forma, voy a introducir a continuacin, cuatro ideas sobre una
metodologa OO con dos finalidades:

O Presentar el Modelo de Objetos, que como ya he dicho, es un mtodo muy
eficiente para describir los modelos de datos.
O Presentar los conceptos mnimos para programar en OO aunque el diseo
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 bsicos de OO (clase, instancia,
herencia, polimorfismo, etc.) y los del modelo conceptual de datos. Para eso es
este captulo. Si necesita informacin adicional consulte bibliografa apropiada. Si
conoce estos conceptos, slteselo.

Los dos captulos siguientes al que est empezando a leer estn dedicados
tambin a orientacin a objetos.

El captulo 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 integracin de la metodologa distribuida
que voy a proponerle con especificacin y diseo de sistemas modelados por
orientacin a objetos en UML (Unified Modeling Language).

Dada la extensin de UML, no creo que este libro sea el lugar apropiado para
presentarlo. Partir de la base de que Vd. tambin 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 documentacin sobre UML antes de seguir. O que salte el
captulo siguiente y atquelo cuando tenga tiempo de documentarse OO.

2. Conceptos bsicos.

204
2. 1. Introduccin del Concepto OO.

En su forma ms
intuitiva, un objeto
consiste en coger
los dos
componentes
bsicos de un
sistema de
informacin, datos y
procesos, reducir el
nfasis en los procesos y fortalecer el encapsulamiento en un mdulo
autnomo de datos y funciones juntos, aadiendo una especificacin clara y
precisa de la interfcie.

El sistema pasa a describirse como una integracin y una interaccin entre
estos objetos.

El anlisis y el diseo de alto nivel se realizan en dos fases:

1. Identificacin de los objetos.
2. Anlisis de como interactan los objetos entre si mediante mensajes que
piden a los objetos que ejecuten un procedimiento o informen de su estado.
El anlisis y el diseo se retardan dentro del ciclo de vida y los detallen de la
implementacin se esconden.

Para el desarrollo del sistema informtico el paradigma orientado a objetos se
base en la construccin de un modelo informtico del sistema real de donde se
extrae la informacin que interesa. Por el contrario, el enfoque clsico parte del
concepto de crear un sistema para obtener una informacin concreta. Este
enfoque clsico 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 implcita una altsima reusabilidad.

2. 2. Terminologa bsica.

Desgraciadamente no hay una terminologa bsica unificada y consolidada. Sin
embargo los trminos ms generalmente utilizados son:

Clase: encapsulacin 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. Lus y Enric son objetos de la clase
persona. Instancia y objeto son, de hecho, trminos equivalentes.
Atributo: dato interno de una clase.
Servicio o mtodo: procedimiento (funcin o accin) accesible de un
objeto.
Estado: situacin de una instancia o objeto determinada por una
combinacin de todos o parte de sus atributos.
Evento: notificacin de un cambio de estado.
Mensaje: forma de comunicacin entre dos objetos para pedir la
ejecucin de algn servicio o mtodo. El mensaje esta formado por
parmetros y esta ligado a la llamada a un mtodo o por el disparo de
algn evento.

Figura 132. Concepto de Objeto
205

2. 3. El tringulo orientado a objetos.

Tcnicamente OO se basa en tres bases
representadas por el tringulo de la figura.

2.3.1. Encapsulacin.

A estas alturas ya conocemos
perfectamente el concepto de
encapsulacin. En OO hace referencia
a agrupar en un objeto datos y
proceso. La encapsulacin por si
misma no garantiza la ocultacin de la
informacin. Es necesario un
mecanismo de private para garantizar que la informacin queda
realmente escondida en el interior del objeto. En los lenguajes OO es
obligatorio aplicar estos conceptos por la propia sintaxis.

2.3.2. Abstraccin y clasificacin.

La modelizacin utiliza el concepto de TAD (tipo abstracto de datos) y la
de tipos definidos por el usuario.

La abstraccin 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 clasificacin ser la agrupacin de ideas en clases de cosas que se
podrn concretar en instancias y objetos, manipularlos y destruirlos.

La abstraccin de las clases no se hace solo con los conceptos de bajo
nivel sino en conceptos de alto nivel como la gestin completa de un
producto, una lista o un Framework de mantenimiento de archivos.

La primera etapa ser siempre la identificacin y abstraccin de las
clases del modelo del mundo real que vamos a crear.

2.3.3. Polimorfismo a travs de la herencia.

Ms 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 comn (operaciones o mtodos),
las mismas relaciones con otros objetos y una semntica comn.

Cada objeto conoce su clase ya que es una propiedad implcita a su
instanciacin. Esta propiedad es accesible desde los lenguajes OO.

Si pensamos, por ejemplo, en una cola, vemos que es un concepto muy
genrico y que una clase que la represente podra ser aplicable a muchos tipos
de elementos organizados en colas.

Figura 133. El tringulo OO
206

Podramos pensar en hacer una abstraccin de una cola genrica, crear una
clase genrica que modele el comportamiento de una cola y especializarla
despus en cada situacin concreta en el momento de la instanciacin
mediante polimorfismo. Este es el concepto de clase genrica, contenedora o
parametrizada.

Una clase abstracta o diferida es aquella en la cual falta algn elemento,
atributo o mtodo, por definir y que por tanto no puede ser instanciable
directamente.

Hay diferentes razones para crear una clase abstracta. Dos de bsicas son:

Crear una superclase para reflejar aquello que tienen de comn dos
clases.
Se quiere forzar que
todas las subclases
tengan atributos y/o
mtodos comunes.

Por ejemplo, si tenemos
diferentes clientes, cada uno
con una forma de clculo del
descuento, podemos crear una
clase abstracta Cliente donde
colocamos un servicio
Descuento que definiremos
ms tarde en la subclase.

ejemplo de clase.

La notacin y representacin de
clases se realiza mediante el
cuadrado de la figura donde en la
parte superior se representan los
atributos, en medio se colocan los
mtodos y en la parte inferior los
eventos.

El comportamiento (behaviour) de
un objeto queda determinado por las
prestaciones de los mtodos
disponibles para tratarlo.

Ya hemos hablado de que es una
instancia (Instance) de una clase y de
la cierta ambigedad del
trmino objeto. Por esa
razn 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
Tamao de la rueda
Cadena
Material
OMtodos:
Cambiar de marxa
Pedalear
Reparar
EInstancias:
OLa bicicleta de Carlos
OLa biclicleta de Mara
Abstraccin

Figura 134. Representacin de una clase bicicleta

Figura 135. Representacin de una
Clase

Figura 136. Notacin de Clase e Instancia
207
2. 5. Concepto de Herencia.

La herencia (Inheritance) es una nueva idea introducida por OO que se
corresponde a una analoga para software de la idea biolgica: el hijo hereda
las caractersticas (atributos y mtodos) del padre mediante una relacin
jerrquica.

Si usted compara clientes y proveedores ver que comparten gran cantidad de
atributos y comportamiento: defina una clase analtica y especialice las clases
cliente y proveedor por herencia.

Las ventajas de la herencia son claras:

Reusabilidad.
Adaptabilidad.
Extensibilidad.
Bajo coste de mantenimiento.
Potencia semntica.
Compartir cdigo.

La herencia es un tipo de relacin jerrquica que se
representa con el icono de la figura.

La herencia representada en la figura es la habitual,
conocida tambin como herencia simple en la cual el hijo
hereda de un solo padre. En la otra figura se representa la herencia mltiple en
que un hijo hereda de ms de un padre. Este tipo de
herencia no esta soportada en todos los lenguajes OO.

La relacin is-a es la que representa la relacin 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 mtodo
genrico a la semntica de su comportamiento.

El primer, y bsico, tipo de polimorfismo se obtiene ligado a la herencia de la
posibilidad del hijo de modificarse, a partir de las caractersticas del padre a su
propia necesidad.

El polimorfismo por herencia se conseguir:

Aadiendo todo aquello que le es propio y que no tena el padre.
Modificando, por redefinicin, aquello que tiene alguna caracterstica
diferencial de lo heredado.
Nunca eliminado atributos del padre, actuacin imposible en OO.

Por ejemplo, en una jerarqua 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 aadiendo el proveedor que la suministra.

Figura 137. Herencia

Figura 138. Herencia
mltiple.
208
Hay otro tipo de polimorfismo entre clases diferentes.
Un mtodo mover, puede adaptarse en una clase
archivo secuencial a cambiar de directorio y en una
clase listado a salir por una impresora. Un mtodo
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
mtodo, 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 mtodo a las caractersticas de una
clase es una herramienta tan potente que slo se puede apreciar cuando se
utiliza habitualmente. Permite compartir propiedades de forma genrica 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 compilacin o de ejecucin la llamada al
mtodo se resolver segn las caractersticas especficas del objeto
instanciado.

Y eso es una herramienta potentsima para la ampliacin de programas con
nuevas semnticas. En la clase producto que hemos hablado antes, si se
introduce una especializacin creando una subclase envase, todo lo
programado hasta ese momento para la clase producto se puede utilizar para
la clase envase con coste de programacin cero.

Veamos un ejemplo prctico y simple de utilizacin de polimorfismo.

En el diagrama de objetos de la figura se muestra una jerarqua de herencia de
una clase genrica Polgono. Aparte de los atributos, de los cuales y
evidentemente slo se ha representado una muestra simblica, existen los
mtodos de la figura.

Es evidente que, representando los vrtices por una tabla de puntos, los
mtodos de crear, mover y dibujar pueden crearse de forma genrica en la
clase polgono. Esto no pasa as en el mtodo clculo del rea, que se
poliforma para cada subclase.

Para calcular el rea en programacin convencional deberamos programar
una secuencia alternativa del tipo:

a: polgono
IF a.tipo_polgono = Tringulo THEN clculo_del_rea_tringulo()
ELSIF a.tipo_polgono = Rectngulo THEN clculo_del_rea_rectngulo()
ELSIF a.tipo_polgono = Pentgono THEN clculo_del_rea_pentgono()
ENDIF

En OO bastar hacer:

a: polgono
a = CREATE (Subclase polgono)
a.clculo_del_rea()

Figura 139. Clase
mover.
209

Si ahora deseamos
ampliar las subclases
con otros polgonos, en
programacin clsica
deberemos aadir una
rama a la composicin
alternativa. En
programacin OO
bastar con redefinir el
mtodo clculo_del_rea
para el nuevo polgono.

Si se extrapola este
sencillo ejemplo a toda
una programacin,
incluyendo los
Framework, se hace evidente la importancia del polimorfismo.

2. 7. Visibilidad de atributos y mtodos.

El concepto de visibilidad est ligado a la accesibilidad que la clase da a sus
atributos y mtodos.

Un atributo o un mtodo pueden ser:

2.7.1. Pblico.

Visible desde el exterior o el interior de la clase.

2.7.2. Privado.

Nada ms puede consultarse o utilizarse desde dentro de la clase.

2.7.3. Protegido.

Nada ms puede consultarse o utilizarse desde dentro de la clase y
desde sus subclases derivadas por herencia.

Existe una polmica abierta en el mundo OO. Han de ser los atributos
pblicos? Hay autores que sostienen que no y otros que s. Para poder
formarse su opinin, si no es un experto OO, recuerde todos los atributos de
una clase visual. Por ejemplo, uno de clsico es el visible, que suele ser una
variable lgica que se coloca a cierto o falso segn convenga a la lgica del
programa. Este atributo suele tener dos mtodos asociados Show() y Hide()
que realizan la misma funcin. Observe que esta tctica el habitual en las
clases comerciales y de hecho, es ms habitual todava que los atributos sean
pblicos y no tengan mtodos para asignarles valores o leerlos.

Los que defienden los atributos como pblicos argumentan que las clases son
ms 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 acrrimo de esta
Polgono
Vertices
Color de aristas
Color del fondo
Crear
Cculo del rea
Mover
Dibujar
Tringulo
Clculo del rea
Rectngulo
Clculo del rea
Pentgono
Clculo del rea

Figura 140. Jerarqua de una Clase Polgono
210
segunda corriente de opinin: los atributos han de ser siempre privados. Y,
a mi juicio, las razones son tan obvias que no hace falta hablar ms.
Encapsular la modificacin de un atributo en el mtodo vacuna contra
manipulaciones no vlidas. Y como la opcin de dejar un atributo pblico de
lectura no existe...

Si usted lector se decanta por esta opcin deber definir:

Un mtodo pblico, normalmente una funcin, de lectura del atributo.
Un mtodo pblico, normalmente una accin, para verificar si un valor es
correcto.
Un mtodo pblico, normalmente una accin, para modificar el atributo y
que internamente llamar al de verificacin.

Mayor trabajo, pero mayor seguridad.

3. Los fundamentos de una metodologa de diseo OO.

El diseo OO es una forma de pensar software basada en hacer abstracciones de
las cosas que existen en el entorno que se est diseando.

La esencia del diseo es la identificacin y organizacin de los conceptos del
dominio de la aplicacin, 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
despus se disean los procesos.

De hecho lo que modela la realidad en algo ms que entidades: son los atributos y
del modelo de comportamiento que proporcionan mtodos y eventos. El nfasis es
la abstraccin de objetos y su estructura, no los procesos. El esfuerzo ms
importante se hace en las modelizacin de los conceptos, no en la implementacin.

4. Etapas de una metodologa de construccin de software OO en UML.

4. 1. Especificacin.

La especificacin construye un modelo del mundo real mostrando sus
propiedades ms importantes.

El moldeo es una concisa y precisa abstraccin de que queremos que el
sistema contemple, no de como lo har. La teora puede hacer pensar que hay
que modelar totalmente la realidad. Obviamente, la fase de anlisis no
comporta ninguna decisin de implementacin. Por ejemplo, una clase persona
es descrita en trminos de sus atributos, de los mtodos pblicos que modelan
su comportamiento y de los eventos; externos a los que puede reaccionar e
internos que puede lanzar.

Evidentemente los conceptos de ingeniera que obligan a considerar la relacin
prestaciones / coste lleva a que la modelizacin se haga en los trminos que el
entono a disear necesita no de la totalidad del modelo. Pero la gracia de
analizar OO es que las ampliaciones del modelo, si ms tarde se necesitan y
211
se ha trabajado bien, sern muy fciles y, sobre todo, no traumticas con lo ya
implementado.

En UML, durante la especificacin todas las operaciones funcionales
detectadas se asignan a una clase nica denominada Sistema.

Partiremos de la base de que esta etapa genera como mnimo:

El modelo conceptual de clases de especificacin.
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 colaboracin.

4. 2. Diseo del sistema.

El diseador toma decisiones de alto nivel sobre la arquitectura. El sistema es
organizado en subsistemas basndose en el anlisis de la estructura y de la
arquitectura propuesta.

El diseador ha de decidir:

Las caractersticas de las cuales ha de optimizar el rendimiento.
Escoger una estrategia para atacar.
Hacer una propuesta para la localizacin de los recursos.

Las operaciones de sistema de la especificacin acaban asignndose a las
clases.

Partiremos de la base de que de esta etapa se obtiene como mnimo:

El modelo conceptual de clases de diseo.
Los casos de uso concretos.
Las interfcies 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
especificacin.
Los diagramas de estado completos.
Los patrones arquitectnicos propuestos para desarrollar la arquitectura
del sistema..

4. 3. Diseo de los objetos.

Construye un modelo de diseo basado en el modelo de anlisis pero
incluyendo detalles de implementacin de los objetos detectados. Los objetos,
representados por las clases, son especificados y descritos en trminos de
sistema operativo, hardware y resto de elementos de la plataforma.

4. 4. Implementacin (Implementation).

212
Las clases de objetos y las relaciones detectadas a lo largo del anlisis son
trasladadas a un lenguaje de programacin, base de datos y plataforma.

A lo largo de la implementacin es importante seguir buenas prcticas de
ingeniera de software ya que debe conducir a una implementacin flexible y,
sobre todo, extensible.

5. Los tres modelos de la metodologa OO.

Una metodologa OO se basa en describir la realidad mediante tres modelos:

Modelo de Objetos.
Modelo Dinmico.
Modelo Funcional.

Cada modelo es aplicable a todas las etapas del diseo y se hace ms rico a
medida que avanza. Una descripcin completa del sistema necesita de los tres
modelos.

5. 1. Modelo de Objetos.

Describe la estructura esttica de los objetos en el sistema y sus relaciones.

Se empieza identificando las clases, sus atributos, mtodos y eventos bsicos.
A partir de aqu, se establecen las relaciones estticas entre las clases.

Existen tres tipos de relaciones.

Herencia.
Agregacin.
Asociacin.

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

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 organizacin de eventos y estados.

El modelo dinmico se utiliza para especificar e implementar los aspectos de
control del sistema.

213
El modelo dinmico 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
operacin y que mtodos necesita utilizar de otras clases. Estos diagramas son
utilizados como base de la metodologa de diseos 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 explcitas.

El modelo de objetos describe la estructura de los datos sobre la cual operan los
modelos dinmico y funcional.

El modelo dinmico 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 dinmico.

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

En los siguientes puntos vamos a presentar algo ms de los tres modelos bsicos,
especialmente del modelo de objeto, que como ya hemos dicho anteriormente tiene
mucha mayor potencia semntica que el modelo relacional y que puede ser
utilizado como forma alternativa de descripcin de datos.

7. Descripcin del modelo de objetos.

7. 1. Plantilla de definicin de Clases y Objetos.

Nombre y Descripcin.
Visibilidad.
Instanciable: SI/NO.
Esttica, es decir, si solo hay una clase en el sistema: SI/NO.
Genrica y lista de parmetros 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 nmero de instancias simultneas que puede haber en el
sistema.
Persistencia: SI/NO.
Restricciones de clase.
214
Observaciones de clase.
Lista de los atributos. Por atributo:
Nombre, descripcin y tipo.
Visibilidad: Pblico, privado, protegido (slo 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 notacin formal grfica 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
anlisis y diseo
se utilizan,
obviamente, los
Diagramas de Clases.

Las relaciones entre las clases son:

Herencia.
Asociacin
Agregacin.

La herencia ya ha sido tratada anteriormente. La asociacin y la agregacin se
presentan a continuacin.

7. 3. Asociaciones y links.

Una asociacin
(association) es
una relacin entre
clases de objetos.
Un link es una
conexin entre
instancias que
define una tupla.
Es decir, un link es
una instancia de la
Pas
Nombre
Ciudad
Nombre
Tiene_ciudades
Diagrama
de Clase
(Pas)
Francia
(Ciudad)
Pars
Tiene_ciudades
(Ciudad)
Lin
(Ciudad)
Montpelier
Tiene_ciudades
Tiene_ciudades
Diagrama
de
Instancia

Figura 141. Ejemplo de Diagramas de Clases e Instancias

Figura 142. Notacin de las asociaciones
215
correspondiente asociacin. A cada asociacin 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 asociacin y de link. (tiene_ciudades).
En la figura de la izquierda se muestra la notacin empleada y un ejemplo.

Las asociaciones son bidireccionales. El nombre se lee normalmente en una
direccin, pero la asociacin 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
asociacin ternaria y su
correspondiente link.

La multiplicidad
(Multiplicity) de una
asociacin especifica
cuantas instancias de
una clase pueden ser
relacionadas con una
instancia de la otra.

Existen dos formas
bsicas de notar en un
diagrama de objetos la
multiplicidad de una
asociacin:

Colocar la
multiplicidad
como un entero
en cada extremo
de la asociacin.
El entero positivo
(cardinal) indica
cuantas
instancias puede
haber de la clase
de ese lado de la
relacin. Observe
que es una notacin parecida a la relacional. Esta notacin fue propuesta
inicialmente por Cood/Yourdon.
Representar la multiplicidad por smbolos grficos, notacin iniciada por
el grupo promotor de OMT.
Proyecto
Lenguaje
Persona
(Persona)
Mara
(Proyecto)
Programa CAD
(Lenguaje)
C
(Proyecto)
Contabilidad
(Lenguaje)
Cobol
Diagrama
de Clase
Diagrama de
Instancia

Figura 143. Ejemplo de Asociacin Ternaria
Pas
Nombre
Ciudad
Nombre
Tiene-capital
1 1
Pas
Nombre
Ciudad
Nombre
Tiene-ciudades
1 N
Lnea
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
Nmero-1 Nmero-2
Exemplos

Figura 144. Notacin de la Multiplicidad por un cardinal.
216

Exactamente una (Exactly one)

Cero o ms (Many)

Cero o una (Optional)

Una o ms (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 notacin
anterior para poder
comparar las dos
anotaciones.

Es habitual que una asociacin tenga atributos. As en el ejemplo de
accesibilidad de
la figura anterior,
se puede asociar
a la relacin
Accesible_por el
atributo de Permiso_de_acceso por usuario.

Una asociacin 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

Pas
Nombre
Ciudad
Nombre
Tiene-capital
Pas
Nombre
Ciudad
Nombre
Tiene-Ciudades
1+
Se-cruzan
Lnea
Nombre
Punt
Nombre
2+
Workstation
Nombre
Window
Nombre
Consola_de errores
Archivo
Nombre
Usuario
Nombre
Accesible por

Figura 145. Notacin Simblica de la Multiplicidad

Figura 146. Ejemplo de Asociacin con atributos

Figura 147. Ejemplo de Asociacin con Atributos modelada
como una clase.
217
La Agregacin (Agregation) es una
relacin 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 notacin y un ejemplo de
agregacin.

Observe que hay una
diferencia fundamental entre
una asociacin y una
agregacin. En una
agregacin, si se cambia un
componente de la instancia,
cambia el objeto; en una
asociacin 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 ms de
agrupaciones.

7. 5. Algunos ejemplos de Modelos de Objetos.

Con todos los componentes presentados, se muestran a continuacin algunos
ejemplos de modelos de objetos.
Trmino
Expresin
Operador Binario
Variable
Nombre
Constante
Valor
Primer Operando
Segundo Operando

Figura 150. Modelo de Objetos de una
Expresin
Lnea
Texto
Columna
Coordenada X
Coordenada Y
Ancho
Largo
Pgina
Ancho
Largo
Margen izquierdo
Margen derecho
Margen superior
Margen inferior

Figura 151. Modelo de Objetos de un texto.

Figura 148. Notacin y
ejemplo de
Agregacin
Documento Parrafo
Palabra
PC
Monitor
Caja
de sistema
Mouse Teclado
Chasis CPU RAM Ventilador
1+
Discp
1+
Figura 149. Ejemplos de Agregaciones
218
Pas
Nombre
Fronteras
(Pas)
Australia
(Pas)
Italia
Diagramas de instancias
(Pas)
Francia
(Pas)
Suiza
(Pas)
Italia
(Pas)
Italia

Figura 152. Diagrama de Objetos de fronteras
de pases
Coleccin de cartas
Jugador
Res
5
Cartas
Palo
Nmero
Pareja Trio Full Poquer Color
EEvidentemente, faltan jugadas ....

Figura 153. Modelo de Objetos de una mano
de poker.

8. Reflexin final.

Si usted ya conoca los fundamentos de OO este captulo se ha supuesto una
prdida (total?) de tiempo.

Si no los conoca, no le habr servido para nada ms que para motivar su inters.
Eso espero al menos.

Pero como ve la metodologa OO aporta los dos componentes bsicos que
necesitamos: la descripcin de los datos y la descripcin del flujo de informacin
mediante los diagramas de flujo. Por tanto todo lo que desarrollaremos a
continuacin vale para cualquier sistema distribuido independientemente del
mtodo de anlisis empleado.

Ciudad
Nombre
Aeropuerto
Nombre
Aerolnea
Nombre
Pilot
Nombre
Vuelo
Fecha
Nmero
Origen
Llegada
Avin
Modelo
Nmero
Horas vuelo
Pasagero
Nombre
Asiento
Localizacin

Figura 154. Modelo de Objetos de un sistema
de transporte areo
Empleados
Compaa
Ordenador
Persona
Propietaris
Asignado a

Figura 155. Uso de ordenadores por
empleados
@@EMG/10-Enric Martnez Gomriz 219
Implementacin de un modelo de objetos
sobre un modelo relacional

1. Introduccin.

Hoy da los gestores de bases de datos utilizados estn basados en el modelo
relacional.

Recordemos que pasa con las metodologas de anlisis de datos. El modelo OO
permite, de forma estndar, 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 adems, para que complicarse la vida si el modelo de
objetos OO ya dispone en su base de la potencia semntica que le falta al
relacional y adems ya es un estndar!

Mi consejo es muy claro y directo: utilice el modelo OO para describir los datos.
Adems 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
tecnologas 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 implementacin
es relacional.

No se preocupe. Existe una metodologa muy simple para mapear el modelo de
objetos OO sobre un modelo relacional. Es el objetivo de este captulo 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

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 focalizacin 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 gestin
de bases de datos
relacionales.
Recordemos que el
modelo interno no es
ms 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 asociacin de tablas y cuatro de mapear una generalizacin.

Cuando se realiza el mapeo hay que aadir detalles que no estn en el modelo de
objetos como claves primarias, secundarias y forneas, 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 prctica
es frecuente que una clase pueda convertirse en una o ms tablas.

El caso contrario tambin es habitual, una tabla puede ligar ms de una clase s
stas estn conectadas por una asociacin o una jerarqua.

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 razn 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 slo 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
tambin la particin.

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 interfcies
de programas
mapping rules
Conceptual
Object
Model
mapping rules

Figura 157. Equivalencia de de niveles entre OO y relacional
As, se habla de dos tipos de particin de clase:

O Particin Vertical, en la cual las instancias se dividen en ms de una tabla.
O Particin Horizontal, en la cual los atributos se dividen en ms de una tabla,
repitiendo la clave en cada tabla.

Obviamente, la particin puede hacerse en las dos dimensiones.

Cada tabla derivada ha de tener una clave primaria que debe escogerse entre los
atributos que identifiquen unvocamente a cada instancia. Debern definirse las
claves secundarias necesarias para conseguir rendimiento en los accesos
previstos. Este tema es fundamental en aplicaciones distribuidas.

Todas las claves resultantes no debern permitir nulos. La existencia o no de nulos
en el resto de campos que implementen el resto de atributos quedar a decisin del
diseador.

4. Mapeo de asociaciones a tablas.

Las asociaciones pueden mapearse, segn los casos, en tablas o definirse
directamente en las tablas de las clases ligadas.

Las ventajas de implementar en tablas son:

O Tablas ms reducidas.
O Mayor rendimiento y facilidad de navegacin.

Las desventajas son:

O Esquemas resultantes ms complejos.
O Mayor dificultad de ampliacin.
O Menor aproximacin del modelo conceptual OO a resultante relacional.

Quedar a criterio del diseador ponderar los aspectos de cada modelo y escoger
la solucin que ms convenga.

Asociaciones N a N.

Cada asociacin de N a N se implementa en una tabla relacional. La clave
primaria de la tabla son los atributos que definen la asociacin. En esta tabla,
esas claves principales son claves forneas de las tablas en las que se han
mapeado las clases ligadas por la asociacin. Normalmente se implementan
claves secundarias por cada una de las clases asociadas.

Una asociacin N a N entre una clase producto y una clase proveedor que
tenga como atributo el las condiciones de compra se resolvera con una tabla
que implementara la asociacin donde:

El identificador de producto y el identificador de proveedor seran las
claves principales.
Los identificadores de producto y de proveedor seran las claves forneas
de las respectivas tablas.
Las condiciones de compra seran los campos.
Habr claves secundaras por cada uno de los identificadores.

Asociaciones 1 a N.

Las asociaciones de 1 a N se pueden implementar en una tabla o pueden ser
escondidas como un atributo de la tabla que mapea la clase de la que parte la
relacin de cardinalidad N. El atributo es clave fornea de la clase de
cardinalidad 1. Habr que definir tantos parmetros adicionales defina la
relacin.

Por ejemplo, sea una asociacin entre un local de una compaa y las
personas que trabajan en la cual el atributo sea el despacho que ocupan.

Existen dos posibilidades.

Una solucin paralela a la anterior.
Colocar en la tabla de personas dos tributos, uno para indicar en que
local estn (clave fornea de la tabla de locales) y otro para el despacho.

Asociaciones 1 a 1.

Cada relacin 1 a 1 puede mapearse en una nueva tabla independiente o
puede ser establecida mediante una clase fornea 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 asociacin se incorpora como parte del nombre del
atributo de la clave fornea.

5. Agregaciones.

La implementacin de agregaciones es paralela a la de las asociaciones.

Sin embargo la solucin ms usada es la de aadir atributos a la clase construida
con los identificadores de las clases componente. Estos identificadores son claves
forneas de las correspondientes tablas de los componentes.

As la clsica agregacin de un coche construido a partir de un chasis y de un
motor se resuelva aadiendo 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 especializacin de productos en materia prima y producto de venta, este nuevo
atributo, que podramos llamar tipo_de_producto, tendr dos valores, un para cada
especializacin.

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, adems es clave fornea a la tabla padre.
En cada tabla se colocan los atributos de cada nivel. En la tabla que mapea la
clase padre hay que colocar el atributo que indica el tipo de instancia
informada.

Este enfoque permite mantener la lgica de datos y da gran extensibilidad. Sin
embargo la navegacin 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 funcin 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 solucin de gran rendimiento de navegacin a cambio de una perdida
razonable de espacio. La perdida ser tanto ms razonable cuando menor sea
el nmero de atributos comunes.

Encontrar un ejemplo de mapeo de jerarquas en el ejemplo del captulo Ejemplo
de Diseo de los Componentes Grficos de una aplicacin RDA de la parte de
diseo de interfcies grficas y su uso en aplicaciones RDA.

Diseo de Aplicaciones Avanzadas por UML
integrado con la metodologa de diseo
distribuido

1. Introduccin.

Le recuerdo que hemos trabajado en captulos anteriores que el diseo distribuido:

O Es una etapa adicional al diseo tecnolgico del sistema.
O Es una etapa independiente de la metodologa utilizada para el anlisis y el
diseo tecnolgico de la aplicacin.
O Partir de que se dispone de:
O Un modelo conceptual de datos.
O Las funciones del sistema.
O La sequencializacin de las funciones del sistema.

Dedicaremos este captulo a presentar la integracin entre UML y diseo distribuido
explicando bsicamente:

O De donde sale la informacin anterior.
O Como se integran en el diseo UML los resultados de la etapa de diseo
distribuido.

Recuerde que partimos de la base de que Vd. conoce las herramientas bsicas de
UML.

2. Diseo de Sistemas por UML.

(a) Especificacin.

Equivale a la etapa de anlisis funcional de las metodologas convencionales.

Como rasgos caractersticos del proceso de especificacin 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 metodologa excepto
demorar al diseo la asignacin 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 especificacin se obtienen:

El modelo conceptual de especificacin:
225
Est formado por los diagramas estticos de las clases del dominio,
incluyendo las relaciones.
La descripcin 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 Colaboracin (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) Diseo Tecnolgico.

Su objetivo es definir un Sistema de Software con la suficiente precisin para
permitir su construccin fsica (implementacin).

El punto de partida son los resultados de la especificacin.

Los resultados obtenidos despus de realizar el proceso de diseo son,
bsicamente:

La Arquitectura del Sistema de Software.
El Diseo de los Datos a travs del Modelo Conceptual de Diseo donde
las clases incluyen las operaciones diseadas para implementar las
operaciones de sistema de la especificacin.
El Diseo de la Arquitectura del Software.
El Diseo de las Interfcies GUI, como normalmente se integra la parte
cliente.
El Diseo de los Flujos de proceso (Batch, Workflow, etc.)
El Diseo de los Programas a travs de los Diagramas de Seqncia.

El proceso para obtener el diseo a partir de la especificacin se apoya en:

Utilizar Patrones de Arquitectura.
Aplicar la Metodologa de diseo adoptada para cada patrn
arquitectnico utilizado.
Adaptacin de soluciones genricas de diseo basadas en la utilizacin
sistemtica de patrones de diseo.

La Arquitectura de Software es para UML lo mismo que para las metodologas
convencionales la Arquitectura del Sistema: la descripcin de los subsistemas y
componentes del sistema de software y las relaciones entre ellos.

En uno de los primeros pasos del diseo habr que definir la arquitectura de
software. Para hacerlo nos basamos en:

La eleccin y aplicacin de Patrones de Arquitectura.
226
La aplicacin sistemtica en todo momento del Patrn OO (obvio si es
UML)

No es necesario incluir aqu una lista exhaustiva de los patrones
arquitectnicos disponibles. A modo de ejemplo, veamos algunos de los ms
habituales en el mundo de aplicaciones distribuidas:

Arquitectura de capas:
Arquitectura de tres capas:
Presentacin.
Dominio
Datos.
Arquitectura de dos capas:
Presentacin.
Datos.
Flujo de datos:
Cadenas Batch.
Procesos de Workflow.
Etc.

Obviamente, en una misma arquitectura de software compleja pueden convivir
varios patrones arquitectnicos. 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 normalizacin del modelo
conceptual de datos de diseo. Se puede atacar como una etapa previa al
diseo 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 slo habr que
trabajar las ampliaciones surgidas en el diseo.

Recuerde que, partiendo del modelo conceptual de especificacin, para
normalizar hay que realizar las:

Transformaciones cannicas
Eliminacin de asociaciones n-arias y clases asociativas.
Traspaso de las restricciones de integridad.
Materializacin y/o clculo de las asociaciones y atributos
derivados.
Trasformaciones relacionales.
Se suelen hacer en el diseo de la capa de datos e incluyen:
Mapeo de jerarquas de herencia.
Mapeo de las relaciones: agrupaciones y/o composiciones.

Las transformaciones relacionales forman parte del diseo de la base de datos
y se atacaran normalmente en la etapa de diseo 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 diseo nuevo.
Parte o todas las clases ya existen en la base de datos.
Deber proporcionar un metaesquema de equivalencia. El caso
ms simple ser establecer la equivalencia clase-tabla.
227
Si no hay equivalencia directa, pueden aparecer problemas
idnticos a los de un Upsizing que resolveremos de la misma
forma. Ms adelante presentar cmo hacerlo.

La metodologa genrica a aplicar en el diseo incluye:

Eleccin de los patrones arquitectnicos a utilizar.
Asignacin de los casos de uso a cada patrn arquitectnico.
Aplicar la metodologa apropiada a cada patrn arquitectnico

Obviamente, la metodologa especifica de cada patrn arquitectnico 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 jerrquicas que interaccionan nicamente con sus capas inferior y
superior a travs de servicios que la inferior proporciona a la superior.

La arquitectura de tres capas es la que se aplica normalmente a aplicaciones
con interfcie grfica que se distribuyen en tres niveles:

Presentacin, que recibe los eventos del sistema a travs de GUIs
Dominio, que implementa la funcionalidad
Datos, que proporciona la persistencia.

La capa de presentacin slo puede interactuar con la de dominio y siempre a
travs de servicios. La capa de dominio solicita tambin servicios a la de datos.

La metodologa a aplicar a una arquitectura de tres capas es, bsicamente:

Asignacin de la comprobacin de las restricciones de integridad a las
operaciones.
Anlisis de la interfcie grfica. A partir de los casos de uso y las
operaciones de sistema afectadas se proponen:
Las maquetas de las Interfcies Grficas necesarias.
El flujo de dilogo propuesto dentro de cada interfcie.
Los casos de uso concretos.
Los mapas navegacionales.
Distribucin de las responsabilidades de las operaciones de sistema por
capas.
La comunicacin entre capas es siempre por servicios.
La respuesta a los eventos del sistema y de los errores se hace
siempre en la capa de presentacin.
Determinacin de los servicios que cada capa ha de suministrar a la
superior.
Agrupndolos por controladores.
Proporcionando los contratos de las operaciones resultantes.
Determinacin de la respuesta a los eventos bsicos de la capa de
presentacin que puede necesitar servicios adicionales de la capa de
dominio.
Diseo posterior e independiente de cada capa.

(c) Documentacin resultante del diseo.

228
De la etapa de diseo UML se obtienen:

El modelo conceptual de diseo:
Diagramas estticos de las clases del dominio y las clases de
diseo aparecidas.
Las clases incluyen las operaciones de diseo.
Aportan la informacin de los datos.
El modelo de Casos de Uso:
Casos de uso concretos.
Diagramas de Secuencia de los Casos de uso concretos.
Interfcies Grficas.
Diseo.
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 diseo.
Contratos de las Operaciones de diseo.
Diagramas de Colaboracin (pocas veces desarrollados)
Diagramas de Actividades (si existen).
Aportan descripcin de las funciones del sistema y
secuencializacin.
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 diseo distribuido.

Recordemos de donde obtendremos los puntos de partida para aadir al diseo
de la arquitectura de software los pasos adicionales del diseo distribuido:

La descripcin de datos:
Modelo conceptual de diseo.
Determinacin de la arquitectura de datos.
Servicios de Lgica de Datos.
Descripcin de las funciones del sistema.
Operaciones asignadas a las clases de diseo.
Secuencializacin de procesos.
Integracin del cliente.
Casos de uso de diseo, normalmente solo para identificar:
- Los eventos del sistema a los que responde la parte
cliente.
- La forma de integracin.
- Descripcin de los flujos de las cadenas de diseo
229
Identificacin de Servicios.
Diagramas de
secuencia de las
operaciones de
diseo.
Diagramas de
actividad.
Diagramas de
colaboracin.

En la figura de la derecha se muestra
un esquema de la metodologa de
diseo UML y su integracin con el
diseo distribuido.

3. Diagramas de despliegue.

En UML, los diagramas de despliegue muestran la disposicin de los distintos
materiales, denominados tambin nodos, que entran en la composicin de un
sistema y el reparto de los componentes sobre esos materiales o nodos.

Los nodos pueden:

O Estereotiparse: servidores, bases de datos, PCs, impresoras, dispositivos de
tipos concretos, etc.
O Relacionarse entre ellos incluyendo la cardinalidad, el tipo de la relacin
(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 situacin fsica.

En la figura se muestra la
representacin grfica de un nodo en
un diagrama de despliegue.

Una observacin prctica. Es muy
frecuente que la relacin de
materiales incluidos en un nodo no
quepa dentro del cuadro reservado
en la representacin grfica del
nodo. Cuando esto ocurre, la relacin se incluye en una lista aparte bajo un
epgrafe con la referencia del nodo.

Especificacin
Datos
(Modelo Conceptual)
Funcionalidad
(Casos de uso /
operaciones de sistema)
Diseo UML
no distribuido
Modelo de Clases
Sequencializacin
(Casos de uso de diseo +
Flujos de diseo +
Diagramas de secuencia +
Diagramas de actividad +
Diagramas de colaboracin)
Atributos
Mtodos
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. Evolucin del diseo UML a distribuido
<<Estereotipo>> + Referencia
Materiales o nodos que
incluye
Referencia del material donde se
sita fsicamente
Figura 159. Representacin grfica 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 caractersticas genricas de
la plataforma de sistema.

Constituye de facto una representacin de la arquitectura de plataforma de
sistema incluida en el Plan Estratgico Distribuido de la Compaa.

un ejemplo de diagrama
de sistema. Observe
que se ha aprovechado
la cardinalidad para
prever un mximo de
100 directores de zona,
cada uno de ellos
hacindose cargo de un
mximo de 5 locales. La
conexin por Terminal
Server se utilizar para
que cada director de
zona pueda acceder y
controlar los locales de
venta que tenga
asignados. La conexin
por Internet a la central
le permitir acceder, por
ejemplo, al servicio de
correo y a los resultados
de explotacin 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 Porttil
Aplicacin 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.

un ejemplo de un
diagrama de
infraestructura
correspondiente al
ejemplo de diagrama de
sistema anterior.

Piense en una
organizacin con 70
locales y 15 directores de
zona e intente
imaginarse un diagrama
grfico con estos
nmeros. Deducir
fcilmente porque no es
habitual desarrollar este
diagrama de forma grfica.

(a) Diagrama de niveles fsicos

Normalmente se utiliza como tal el Diagrama de Sistema. Solo se desarrolla un
diagrama especfico cuando hay algn matiz del modelo que se cree necesario
particularizar

(b) Diagrama de niveles lgicos.

Corresponde a la situacin de los niveles lgicos sobre los fsicos. A cada nodo
lgico se asigna un nombre, que puede ser el mismo que el nodo fsico, y en la
localizacin se especifica el nodo del diagrama de niveles fsicos / sistema en
el que se aloja.

ejemplo de diagrama de
niveles lgicos basado en el
diagrama de sistema del
ejemplo anterior. Observe
que sobre los niveles fsicos
se estable un doble nivel
lgico:

Locales:
Primer nivel
lgico: HOST.
Segundo nivel
lgico: Servicios
del local,
localizados sobre
el nivel fsico 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 TPVs
Puesto
de Venta
5 TPVs
Puesto
de Venta
2 TPVs
Servidor
Local
Puerta
del sol
Servidor
Local
Moratalaz
Puesto
de Venta
4TPVs
Puesto
de Venta
2 TPVs
Sevidor
WEB
Barcelona
Supervisor
Llus 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 Lgicos
232
Tercer nivel lgico: cliente, con tres perfiles:
Mando del local, situado sobre el nivel fsico del servidor de
local.
Puesto de venta, situado sobre le nivel fsico del puesto de
venta.
Supervisor, situado sobre el nivel fsico del mismo nombre.
Servicios WEB:
Primer nivel lgico: HOST.
Segundo nivel lgico: Servidor WEB situado sobre el nivel fsico del
mismo nombre.
Tercer nivel: Supervisor, utilizando un navegador situado en el nivel
fsico 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 diseo distribuido. Sobre el diagrama de despliegue
resultante deberemos incluir el tipo de comunicacin y la arquitectura de
servicios:

Asignando un nombre a la relacin
que incluya el tipo de comunicacin,
el tipo de arquitectura entre los dos
servicios y posibles puntos de
heterogeneidad como la presencia de
una comunicacin remota (opcin
UML pura)
Utilizando iconos como los
presentados de este libro para la
notacin MAFDRA, opcin no
estndar dentro de UML, pero a mi
juicio mucho ms 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 relacin para documentar si la
comunicacin 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 nmero indeterminado de clientes. Podramos forzar una cardinalidad
concentra N si quisiramos 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
Delegacin

Figura 163. Diagrama de Arquitectura de
Servicios Notacin.
233
N si queremos indicar que el servicio es multinstancia. Observe que
la cardinalidad muchos (*) no es realmente factible ya que indicara
que la mquina donde se aloja el servidor del servicio es infinita en
recursos.

En la figura se incluye un
ejemplo de utilizacin de
los diagramas de
despliegue para
documentar la
arquitectura de servicios.
He incluido la notacin
MAFDRA para describir
de forma rpida el
servicio objeto del
ejemplo.

Otra posibilidad para
implementar el diagrama
de Arquitectura de
Sistemas es un Diagrama
de
Colaboracin. En la
figura se muestra una
propuesta de notacin. Si
utiliza un diagrama de
colaboracin para
documentar la arquitectura
de servicio no es necesario
que utilice la posibilidad de
numerar cada paso de
colaboracin: es diagrama
de arquitectura de servicios
no necesita esa
informacin ya que refleja
la relacin estructural entre
los servicios, no la
dinmica.

(a) Diagrama de Localizaciones.

Los elementos, servicios, agentes y clientes del Diagrama de Arquitectura de
Servicios y los programas obtenidos en la fase de integracin del cliente se
sitan sobre el Diagrama de la Infraestructura lgica.

Servidor
Alta
Clientes
Cliente Clientes en la Central
R D
Servidor
Alta
Cliente en
la Central RPC
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
Delegacin
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
Colaboracin
234
En la figura se muestra el
diagrama de localizaciones
del ejemplo de arquitectura
de servicios anterior.
Observe que este
diagrama es prcticamente
igual que el de servicios
incluyendo el nivel lgico
donde se aloja cada
servicio.

Dadas las pocas
diferencias entre los
diagramas de despliegue
de la arquitectura de
servicios y de localizacin,
incluir en la
documentacin
nicamente uno de ellos.

4. Fuentes de servicios sobre un diseo UML.

Una vez concluida la etapa de diseo de sistema del software no distribuido, los
resultados se analizarn para detectar servicios aplicando todos los criterios que
hemos visto hasta ahora y los que incluiremos ms adelante. En la metodologa
integrada de diseo distribuido que presentar ms adelante, veremos que esta
etapa est muy hacia el principio. No hay problema, pues, para aplicarla sobre un
diseo UML para identificar servicios.

(a) Diagramas de clases.

El diagrama de clases de diseo, en cuanto a atributos y relaciones, se
mapear sobre el modelo relacional. A partir de aqu se aplicaran los criterios
de anlisis de datos distribuidos que veremos ms adelante.

La Arquitectura de Datos Distribuida resultante deber enlazarse con el
diagrama de clases de diseo al dotarlo de persistencia mediante servicios de
lgica de datos, posiblemente con la gestin de un metaesquema que mapee el
esquema conceptual de diseo sobre la arquitectura distribuida.

(b) Diagramas de actividad.

Representan y describen el estado de ejecucin 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 ejecucin de un sistema, sin profundizar en los detalles
internos de los mensajes.

Equivalen a los diagramas de flujo de metodologas tradicionales, incluyendo la
secuencializacin 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 identificacin de servicios a esas actividades se
detectarn cuales de ellas han de ser servicios. Las actividades estarn
asignadas a clases, que se podrn integrar completamente a servicios o
dividirlas o especializarlas por herencia y polimorfismo en clases.

Veamos un ejemplo. En
la figura se muestra
una aplicacin de
ventas en la que el
pedido se registra en
una tienda, la
facturacin es diferida y
centralizada y los
pedidos se preparan y
envan 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 obtencin de
riesgo se
localizar en la
central por
criterios de
localizacin
funcional.
Necesitaremos
un servicio.
Necesitaremos
una agente en el
entorno de la
aplicacin de
facturacin para
la recepcin del
pedido a facturar.
La facturacin se realizar en la central por ser la aplicacin heredada. El
proceso de facturar ser un servicio suministrado por un agente que
envolver a la aplicacin corporativa.
La impresin del albarn se realizar utilizando Word como servidor de
Impresos.
Central Almacn Tienda
Registrar
Cliente
Obtener
Riesgo
Rechazar
Cliente
Registrar
Pedido
[Sin crdito]
Facturar
[Con crdito]
Preparar
Envo
Imprimir
Albarn
Enviar al
Cliente
Figura 167. Ejemplo de Diagrama de Actividades como fuente de
servicios
Central Almacn Tienda
Registrar
Cliente
Obtener
Riesgo
Rechazar
Cliente
Registrar
Pedido
[Con crdito]
Facturar
[Sin crdito]
Preparar
Envo
Generacin
del Albarn
Enviar al
Cliente
Comprobar
Riesgo
Imprimir
Albarn
Enviar para
facturacin
Recibir
Facturacin
Enviar
Albarn
Recepcin de
Albaranes
Figura 168. Ejemplo de Diagrama de Actividades adaptado tras el diseo
distribuido
236
Necesitaremos un servicio de agente para traspasar la responsabilidad
de entrega del material al almacn.

Con todo ello y realizando el diseo distribuido informalmente, el diagrama de
actividades distribuido ser el que se muestra en la figura anterior.

En la integracin 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 almacn para Servir Pedidos que no detallar.
La aplicacin heredada proporciona en la central un servicio envolvente
de Facturacin para facturar a travs de la aplicacin corporativa.

Con todo ello, el
diagrama de
despliegue que
representar la
arquitectura de
servicios resultante,
presentado como
diagrama de
localizacin, 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 interaccin 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 posicin sobre el eje vertical.

Se usan bsicamente para:

Documentar los casos de uso.
Descripcin y diseo de las operaciones de las clases.

Son documentos que, a diferencia de los diagramas de actividad y
colaboracin, existen siempre y que por tanto son fuente primaria para la
identificacin de servicios aplicando los criterios de distribucin y ruptura de la
funcionalidad.
Recepcin
Albaranes
Servidor
Almacn
Captura de
Pedidos
TPV Tienda
Obtener
Riesgo
Servidor de
Servicios Host
Recepcin
Facturacin
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
Almacn
Servicio de
Facturacin
Host
T
D
Figura 169. Arquitectura de Servicios del Diagrama de Actividades
adaptado tras el diseo distribuido
237

Por todo ello, son la herramienta bsica que se identifican servicios.

He utilizado los diagramas de secuencia como herramienta de diseo en el
pequeo ejemplo con que acaba este captulo. Utilcelo como ejemplo de
identificacin de servicios sobre diagramas de secuencia.

(b) Diagramas de colaboracin.

Los diagramas de colaboracin muestran interacciones entre objetos
insistiendo en la estructura esttica organizada y basada en los objetos que
toman parte en la interaccin 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 ejecucin.

A diferencia de los diagramas de secuencia, los diagramas de colaboracin
muestran las relaciones entre los roles de los objetos.

La identificacin de servicios se hace de forma anloga a los diagramas de
actividades y de secuencia. Hay, sim embargo, un importante matiz. Por su
naturaleza, los diagramas de colaboracin 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
colaboracin que
refleja el
intercambio entre
dos agentes de
una entidad
encriptada. El
anlisis
distribuido es tan
simple que
incluyo la
arquitectura de
servicios sin ms
explicacin
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 idnticos. En este ltimo, el servicio
Encriptador nada ms aparecera una vez y sera llamado por los dos agentes.

(a) Primera versin de la integracin de servicios en clases.

Agente de
envo
Agente de
Recepcin
Encriptador
2. Transporte
1. Encriptacin
3. Desencriptacin
Agente de
envo
Servidor del
Local
Encriptador
Servidor del
local
D
Agente de
envo
Servicios en
Central
Encriptador
Servicios en
Central
D
T

Figura 170. Identificacin de servicios en un Diagrama de Colaboracin
238
Adelantemos una parte de la explicacin de cmo 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
identificacin de servicio puede determinar que:

Toda la clase se incluya en el servicio.
Haya que especializar la clase en dos o ms subclases.
Haya que dividir la clase.
Haya que utilizarse un patrn de diseo controlador en arquitectura de
distribucin para conectar los dos o ms 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
notacin MAFDRA.
Las opciones
master/slave y de
redireccin
permitiran mayor
eficiencia.
La clase acte como
modulo de
integracin de varios
servicios.

Ms adelante ampliaremos este punto.

5. Vistas de la arquitectura del Software.

Los subsistemas y componentes se especifican normalmente en vistas:

O Vista lgica.
O Muestra la organizacin 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 diseo en mdulos.
O Se corresponde con nuestros conceptos de:
Servicios linkados, donde cliente y servicio se lindan en un solo
mdulo.
Patrn
Controlador
(Master)
Clase
Cliente
Clase
Proveedora
del Servicio
1
Clase
Proveedora
del Servicio
N
Patrn
Controlador
(Slave)
D
D
R M
Patrn
Controlador
Clase
Cliente
Clase
Proveedora
del Servicio
1
Clase
Proveedora
del Servicio
N
D
D
R
Patrn
Controlador
Clase
Cliente
Clase
Proveedora
del Servicio
i
A
R
Figura 171. Posibilidades de integracin de servicios entre entornos
239
Servicios pasivos y activos, donde el servicio, slo o junto a otros
afines, comparten un servidor o agente.
Integracin de la parte cliente, o mdulos donde se lindan las
funciones clientes.
O Vista de despliegue.
O Muestra la distribucin de los mdulos de la vista de desarrollo por la
plataforma.
O Se conoce tambin como vista fsica, terminologa de la que huir aqu
para evitar equvocos.
O Se corresponde con nuestro concepto de localizacin.
O Vista de escenarios o casos de uso.
O Muestra los usos ms 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 distribucin a las separaciones fsicas 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 distribucin condicionan las vistas de desarrollo y despliegue y
estn determinadas por la infraestructua del sistema distribuido, actuando como
precondiciones del diseo.

Un sistema absolutamente general debera disearse en la hiptesis de que todos
los nodos estn aislados por fronteras remotas. El evidente que si se acta as, el
sistema podr adaptarse a cualquier evolucin de las fronteras de remotes a
locales y viceversa.

Pero tambin es evidente que el esfuerzo de aplicar esta hiptesis es mucho mayor
que si se parte de una situacin menos generalista en la cual solo se identifican
algunas de las fronteras como remotas. En cada caso el diseador habr de tomar
las decisiones que el entorno aconseje reflejando las fronteras remotas como
precondiciones del diseo distribuido..

En los ejemplos que siguen actuaremos como si todas las fronteras entre los nodos
fueran remotas. En la prctica, cuando no sea as, podr simplificarse el diseo
actuando como si fuera no distribuido en las fronteras locales.

7. Otros factores de inters en el diseo UML distribuido.

O Uso del patrn representante para minimizar el acceso a nodos remotos. Por
ejemplo, no cargar todas las imgenes remotas si no son consultadas.
O Uso del patrn 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 aplicacin de este patrn es bsica 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 artculo a artculo, recoger el pedido completo antes de
saltar la frontera remota.

8. Arquitectura de Objetos Distribuidos en la prctica.

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 funcin 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 anlisis de arquitectura de servicios, consistencia y
administracin.
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 diseo 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 ms de una plataforma y/o ausencia en algunos de los nodos.
O Consecuencia terica: slo hay que utilizar modelos de comunicacin
entre servicios convencionales en los saltos entre los nodos
heterogneos.
O Consecuencia real: todos los servicios se comunican
convencionalmente (sino habr que repetir servicios o no tendramos
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 sncronas entre clases.
Las clases engloban y
encapsulan uniformemente las
diferentes topologas de
comunicacin.

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
responsabilizarn de la
comunicacin con casustica de
la peticin / respuesta por el
modelo escogido.

Veamos un ejemplo con el servicio de datos sobre un modelo de replicacin como
el que se presenta
en la figura de la
figura. Para resolver
la situacin del lugar
donde realizamos la
instancia podemos
utilizar un patrn
estrategia
superpuesto a otro
de plantilla donde se
delega a la subclase
la implementacin
del acceso a la
central mediante la
operacin
AltaCentral() donde
se realizar desde el
nodo el alta en la
copia de la central.

Obviamente, si la
situacin de la
instancia es la
Central, la subclase correspondiente implementar vaca la operacin.

Si la instanciacin 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
automticamente (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 aplicacin quedar distribuible y no distribuida. Ni no podemos
En presencia de un modelo OO distribuido: sncrono/eventos.
Las clases encapsulan uniformemente caca tipo de comunicacin.
:objeto
cliente
:objeto
servidor
En ausencia de un modelo OO distribuido: sncrono/asncrono/eventos/etc.
Nuevas operaciones en la clases o nuevas classes encapsulan y resuelven
cada una de las tipologas de comunicacin convencionales.
:objeto
cliente
:objeto
servidor
Figura 172. Influencia de la arquitectura OO en el modelo de
comunicacin
Servidor
Alta
Clientes
Cliente Clientes en la Centr
R D
Servidor
Alta
Cliente en
la Central RPC
Cliente
Alta()
Situacin
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()
Resolucin si hay heterogeneidad en
la comunicacin

Figura 173. Ejemplo de implementacin de un servicio de datos
242
permitirnos esa limitacin, deberemos considerar tambin que hay un punto de
heterogeneidad. En la figura se muestra tambin una posible solucin para
resolverlo en que cada servidor, local o central, instancia su propia clase.

9. Implementacin de la arquitectura distribuida sobre un modelo OO.

Como consecuencia de todos los puntos que hemos analizado, podemos concretar
y ampliar la integracin 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 ms adelante al hablar del anlisis de consistencia) a
travs de patrones controlador y arquitecturas de distribucin.
O Es necesario aadir el anlisis de consistencia que puede considerarse un
paso incremental de la especificacin y el diseo.
O La administracin, excepto el cuadro de mandos, es posible que quede fuera
del diseo del modelo OO ya que incluir el uso de muchas herramientas
heterogneas no necesariamente orientadas a objetos. Conviene, sin
embargo, implementar en OO.
O La localizacin es un diagrama de despliegue.
O Si existe una heterogeneidad en la comunicacin y queremos mantener un
modelo de comunicacin por eventos podemos aprovechar filosofas de viga
/ disparador, ya vistas, o de publicacin / suscripcin, que veremos ms
adelante.

10. Un ejemplo.

Para aplicar la metodologa, le propongo un ejemplo muy sencillo sin grandes
prestaciones funcionales que acten como ramas que no escondan el tronco.

Imagine que tiene un caso de uso de asignacin 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 nmero de proveedores
que suministra la materia prima. No hace falta matizar que una misma materia
prima puede suministrarla ms de un proveedor.

Empecemos por especificar el sistema en UML

De forma muy simple, el caso de uso esencial de la especificacin sera:

caso de uso esencial: Asignacin de proveedor a materia prima
actores: Usuario, Sistema
precondicin: 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 nmero 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 ningn proveedor con el nombre informado (2)
6.1. El Sistema avisa al Usuario que no existe ningn 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 especificacin, 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
analticas con el
mismo NIF.
O No existen dos
ocurrencias de la
relacin Suministra
con la misma materia
prima y proveedor.

Para cumplir con el caso de
uso se necesitar una
operacin de sistema con un
contrato informal del estilo:

asignarProveedor(ent mp: String, ent pr: String)
Retorno: Entero
Precondiciones:
Postcondiciones:
2. En la operacin:
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 diseo.

Se decide utilizar un patrn arquitectnico de tres capas para implementar este
caso de uso a travs de una interfcie grfica.

*
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
Analtica
Proveedor Cliente
costeComp:Real
Suministra
Figura 174. Modelo conceptual de especificacin
:Usuario
:Sistema
asignarProveedor(mp, pr): entero

Figura 175. Diagrama de secuencia del caso de uso
244
Empezaremos por
realizar la
normalizacin del
esquema
conceptual de
especificacin y
obteniendo as el
de diseo que se
muestra en la
figura.

Observe que las
relaciones binarias
y ternarias se en
implementado
como nuevas
clases.

Despus de
realizar la
normalizacin
revisamos si las
restricciones de
integridad afectan a las operaciones que vamos a disear. En este caso, el contrato
de la operacin assigarProveedor debe ser modificado aadiendo las
comprobaciones:

asignarProveedor(ent mp: String, ent pr: String, out totalPrv: entero)
Retorno: Booleano
Precondiciones:
Postcondiciones:
1. La operacin devuelve falso y no hace hada si:
1.1. mp no corresponde a una materia prima vlida.
1.2. pr no corresponde a un proveedor vlido.
1.3. el proveedor pr ya suministra la materia prima mp.
2. En caso contrario la operacin es correcta, devuelve cierto y:
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 parmetro 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
Analtica
Provedor Client
costComp:Diner
Suministra
*
1

Figura 176. Modelo conceptual de diseo
245
A continuacin realizaremos el anlisis de la interfcie grfica para la que se
propone la maqueta de la figura con el objetivo de filtrar el mayor nmero de errores
posibles en la capa de presentacin.

En la interfcie grfica se incluyen los siguientes componentes:

O LMP - Materia Prima: una
lista desplegable con todas
las materias primas de la
empresa (la precondicin del
caso de uso supone que no
hay altas mientras se ejecuta
la asignacin).
O LPR - Proveedor: una lista
desplegable con todos los
proveedores que todava no
suministran la materia prima
situada en la cima del
desplegable de materias
primas.
O PMP - Nmero actual de
proveedores: un cuadro de
texto donde se mostrar el
nmero total de proveedores
que suministrarn la materia
prima.
O Registrar - Botn para
registrar la nueva relacin.
O Acabar Botn para finalizar el caso de uso.
O Dialogo - Un cuadro de edicin multilnea para mostrar los mensajes de
dilogo 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 todava no la suministran.
O El operador elige un proveedor de la lista.
O El operador pulsa Registrar
O El sistema establece la relacin.
O El sistema muestra el nmero total de proveedores que suministran la materia
prima.
O El proceso se repite hasta que el operador pulsa Acabar.

Con este flujo de dilogo y la interfcie grfica diseada, el caso de uso concreto
ser:

caso de uso concreto: Asignacin de proveedor a materia prima
actores: Usuario, Sistema
precondicin:
1. Todas las materias primas entre las que puede elegir el Usuario son vlidas.
2. No se realizan altas de materias primas mientras se asignan proveedores de
compras
curso principal:
Materia Prima:
Proveedor:
(cuadro de dilogo con el operador)
Registrar Acabar
Nmero actual de proveedores :

Figura 177. Interfcie grfica de la operacin
asignarProveedor()
246
1. El Usuario indica al Sistema el nombre de la materia prima a la que quiere
asignar un nuevo proveedor eligindola de la lista desplegable.
2. El Sistema presenta al Usuario la lista con los proveedores que todava no
sirven la materia prima elegida.
3. El Usuario indica al Sistema el nombre del proveedor eligindolo de la lista
desplegable.
4. El Usuario pulsa el botn Registrar.
5. El Sistema asigna la materia prima al proveedor.
6. El Sistema muestra al Usuario el nmero 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 interfcie grfica.

En estas condiciones el servicio que la capa de dominio ha de suministrar a la capa
de presentacin para cumplir con la operacin ser:

asignarProveedor(ent mp: String, ent pr: String, out totalPrv: entero)
Retorno:
Precondiciones
1. mp corresponde a una materia prima vlida.
2. pr corresponde a un proveedor vlido.
3. el proveedor pr no suministra la materia prima mp.
Postcondiciones:
2. La operacin se ejecuta y:
2.2. En el argumento totalPrv se devuelve el total de proveedores que

Opcionalmente, y ya que ha desaparecido la necesidad de controlar errores,
podramos haber devuelto el parmetro totalPrv a retorno en lugar de mantenerlo
como parmetro de salida.

Para cumplir su funcin, la capa de presentacin necesita nuevos servicios de la
capa de dominio:

listaMateriasPrimas(): Set(String)
Retorno: Devuelve los nombres de las materias primas de la Compaa.
Postcondiciones:
2. Se devuelve un conjunto con las materias primas vlidas.

listaProveedores(ent mp: String): Set(String)
Precondiciones
Postcondiciones:
2. Se devuelve un conjunto con los proveedores que todava no suministran la
materia prima mp.

finCasoDeUso()

As pues, la capa de presentacin comunicar con la capa de dominio a travs de
un controlador con los servicios:

O asignarProveedor() lanzado con el evento de clikado del botn Registrar
247
O listaMateriasPrimas() lanzado con el evento de creacin de la interfcie grfica
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 botn 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 vlidas.

obtenerPR(ent mp: String)
Retorno: Set(String).
Precondiciones
Postcondiciones:
2. Se devuelve un conjunto con los proveedores que todava no suministran la
materia prima mp.

asignarPR(ent mp: String, ent pr: String)
Retorno:
Precondiciones
2. pr corresponde a un proveedor vlido.
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
Postcondiciones:
2. Se devuelve el nmero total de proveedores que suministran la materia prima
mp.

Es decir, la capa de dominio comunicar con la capa de presentacin a travs de
los servicios:

O obtenerMP(): utilizado para implementar la operacin listaMateriasPrimas().
O obtenerPR(): utilizado para implementar la operacin listaProveedores().
O asignaPR(): utilizado para implementar la operacin asignarProveedor().
O totalPR(): utilizado para implementar la operacin asignarProveedor().

Finalmente, para completar el flujo de dilogo diseado, la interfcie grfica ha de
disponer como mnimo 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 sern las propias primitivas
proporcionadas por la clase lista desplegable.
248
O pulsado() el botn registrar para realizar la asignacin.
O poneTexto() en el cuadro PMP para informar del total de proveedores que
O pulsado() el botn 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 continuacin atacaramos el diseo de completo de cada capa.

Diseamos el controlador de
la capa de dominio con el
patrn controlador
transacional que se muestra
en la figura.

Las llamadas y relaciones
entre todos estos servicios
quedaran detalladas en los
respectivos diagramas de
secuencia del diseo
completo. Una posible
solucin se desarrolla en los
diagrama de secuencia que
se muestran a continuacin.

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()
Transaccin
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 presentacin y de dominio
249

El programa que realiza
la interaccin con el
usuario deber empezar
por instanciar la ventana
(APMP) que implementa
la interfcie grfica
diseada. El diagrama
de secuencia
correspondiente se
muestra en las dos
figuras de la derecha.

APMP: Ventana
LMP: Desplegable
(cx1, cy1, ..., LMP)
(dim, Asignacin de proveedor a materia prima, ...)
Registrar: Botn
(cx4, cy4, ..., Registrar)
Acabar: Botn
(cx5, cy5, ..., Acabar)
CP: Programa
creacin()
aadirComponenteVisual(LMP)
Dilogo: rea de texto
(cx6, cy6, ... Dilogo)
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 creacin 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
Dilogo: rea de Texto
limpiaTexto()

Figura 181. Diagrama de secuencia de la creacin de la ventana.
Inicializacin
250
Tal como hemos
diseado, al
cambiar la cima de
la lista desplegable
de materias primas
habr de cargarse
en el desplegable
de proveedores la
lista de los que
todava 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
reaccin al botn
de Acabar. No est
desarrollado el
proceso de
finalizacin ya que depender del total del sistema en que est incluido y no
aportara nada significativo al ejemplo.

La reaccin al botn
de Registrar ser
realizar la asignacin
del nuevo proveedor a
la materia prima
escogida. El diagrama
de secuencia de la
operacin de la
ventana que
reacciona se muestra
en la figura de la
derecha.

Finalmente, habr que
completar el diseo de
los servicios de la
capa de dominio que
interaccionarn con la
capa de datos.

Puede optarse por
dos soluciones:

O Disear un
controlador para
agrupar los servicios de datos a dominio de forma anloga a como hemos
hecho entre presentacin y dominio.
alt
APMP :Ventana
cambiaLMP()
tx: TxListaProveedores
(mp)
Coloca lp en la lista
Coloca lp[1] en la cima
ejecutar()
[lp est vaco]
lp
obtieneResultado()
LPR: Desplegable
inicializar(lb)
LMP :Desplegable
cambia()
APMP :Ventana
pulsadoAcabar()
Acabar :Botn
pulsado()
Acabar el caso de uso solicitado
el servicio finCasoDeUso()
LMP: Desplegable
obtieneCima()
mp
[lp no est vaco]
Dialogo: rea de texto
poneTexto(no hay proveedores)

Figura 182. Diagrama de secuencia de la actualizacin del desplegable de
proveedores al cambiar la cima del desplegable de materia
prima
APMP :Ventana
pulsadoRegistrar()
tx: TxAsignarProveedor
(mp,pr)
ejecutar()
tx
Registrar :Botn
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 reaccin al botn 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 solucin por dos razones:

O La operacin del ejemplo es tan sencilla que de hecho podra montarse en
dos capas.
O Mostar otra opcin de integracin entre capas.

En la figura de la
derecha se
muestran los
diagramas de
secuencia de la
interaccin 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 prximos
pasos hablaremos
de diferentes formas
de integracin y este
montaje genrico
nos dar ms juego.

Ya estamos en
condiciones de
atacar ahora el diseo distribuido. Supondremos que

O Disponemos de una arquitectura fsica de tres niveles: central, servidor
departamental y mquinas cliente.
O La arquitectura de datos es centralizada y el gestor relacional esta situado en
el nodo de la central.
O El anlisis de consistencia deber prever el fallo de los servicios que se
decida montar como activos. Para simplificar, supondremos que la decisin
ser simplemente esperar que el servicio se recupere y volver a pedir el
registro.

Vamos a analizar a continuacin diferentes soluciones para la vista de desarrollo.

(a) Presentacin 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 lgica de dos
niveles: cliente y central.

Con esta decisin:

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
asignacin de la relacin
Servicio que devuelve todos
los proveedores que no
suministran todava 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 comunicacin 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) Presentacin y dominio separados sin mantener el controlador.

Si suponemos ahora que hay tambien frontera entre las capas de presentacin
y de dominio, obtenemos una arquitectura lgica de tres niveles: cliente,
servidor departamental y central.

Con esta decisin todos los servicios son activos:

Suministrados por servidores:
asignarProveedor.
listaMateriasPrimas.
listaProveedores.
finCasoDeUso (podra valorarse dejarlo como pasivo segn cual
fuera el proceso a realizar para acabar el caso de uso.
Son servicios suministrados por el motor de la base de datos:
Con comunicacin ODBC-SQL:
asignarPr.
totalPR.
Con procedimiento catalogado:
ObtenerMP.
obtenerMP()
listaProveedores()
obtenerPR()
asignarProveedor()
asignarPR()
LMP::cambia()
escogeProveedor()
Acabar:: pulsado ()
PMP::poneTexto()
LPR::inicializar()
LMP::inicializar()
finCasoDe Uso()
R
totalPR()
R
R
R

Figura 185. Implementacin 1.
253
ObtenerPR.

(a) Presentacin y dominio separados manteniendo el controlador.

Supongamos ahora que hay frontera entre las capas de presentacin y dominio
pero no entre sta y la de dagtos. Es una variacin de la anterior en la cual el
controlador se mantiene como servidor en una arquitectura de distribucin y los
servicios de la capa de dominio son linkados y estn incluidos en el
controlador.

Desarrollemos, finalmente, los diagramas de despliegue suponiendo que elegimos
la implementacin del apartado 5.2.

En ese supuesto:

O La integracin de la parte cliente nos proporcionara el programa Asignacin
de Proveedor de integracin grfica.
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 asignacin sobre la base de datos.
obtenerMP()
listaProveedores()
obtenerPR()
asignarProveedor()
asignarPR()
LMP::cambia()
escogeProveedor()
Acabar:: pulsado ()
PMP::poneTexto()
LPR::inicializar()
LMP::inicializar()
finCasoDe Uso()
R
totalPR()
R
R
R
D
D
D
D

Figura 186. Implementacin 2.
254
O TotalPR para obtener el nmero 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 fsica de tres
niveles.

Sobre ella construiremos la
arquitectura lgica 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 PCs.
Aunque es este ejemplo no es
necesario, conviene remarcar que,
como se muestra en el diagrama de
niveles lgicos, la aplicacin de
compras heredada sobre el HOST
estara envuelta por una capa de
servicios para dejarla integrada en el
<<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
Aplicacin de compras
Servicios de
envolvente
Servicios de
Compras
Servidor de Compras
1 1
Gestin de
Compras
Puesto de trabajo de
Compras
1
*

Figura 188. Diagrama de Niveles Lgicos de
Asignar Proveedor.
255

Sobre est arquitectura lgica
realizaremos la localizacin
de los servicios de la vista de
despliegue. En la figura de la
derecha se establece la
arquitectura de servicios
resultante del diseo, 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
Localizacin.
Asignar
Proveedor
Servicios de
Compras
Programa de
Asignacin de
Proveedor
Gestin 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 Localizacin de Asignar
Proveedores.
Datos y Diseo Distribuido

1. Introduccin.

Todo lo que encontrar sobre datos y distribucin en este y los captulos siguientes
es una continuacin del tema desarrollado en la primera parte dedicada a introducir
los principios bsicos 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 diseos distribuidos. Basta tener
presente el cuadro de clasificacin de los datos presentado en la primera
parte.
O Hay una gran alternativa inicial: datos centralizados, fciles de administrar
pero con trfico de lneas, versus datos distribuidos, con menor trfico de
lneas pero ms difciles de administrar.
O El Upsizing de sistemas de informacin obliga normalmente a un esfuerzo
adicional de diseo para resolver las diferencias semnticas y sintcticas.
Recuerde que hay otras situaciones asimilables al Upsizing.

En este y los siguientes captulos vamos a desarrollar temas relacionados con el
modelo de datos para completar lo que necesitamos sobre este asunto para el
diseo distribuido.

3. Centralizar versus distribuir: Resumen de modelos lgicos del datos.

Centralizar datos (aprovechando todas las ventajas de la integridad, seguridad,
back-up, etc.) o distribuirlos (aprovechando las ventajas de accesibilidad y
minimizacin de trfico de redes y comunicaciones) es la gran polmica y el mayor
problema del diseo distribuido.

No hay varitas mgicas. Cada aplicacin es diferente y sus necesidades
condicionan y conducen hacia la solucin ms adecuada. En particular el anlisis
de consistencia marcar en gran manera muchas de las posibles soluciones si hay
que garantizar servicio en caso de cada de los servidores de datos de la red.

Adems con anchos de banda apropiados se puede disponer de un modelo
distribuido muy centralizado fsicamente por lo que la administracin puede hacerse
en local.

Pero como en todo lo dems, se puede disponer a priori de modelos, estrategias y
mtodos entre los cuales se elegir para crear la solucin final.

Es importante darse cuenta que desde el punto de vista de la lgica de proceso de
los programas hay 4 casusticas bien diferenciadas:

3. 1. Datos en servicios en nube.

No existen para los clientes y usuarios. La responsabilidad es de los
constructores (diseo) y suministradores (administracin).

3. 2. Datos centralizados.

A la hora de programar son un nico bloque lgico.

A la hora de administrar y segn el tipo del modelo:

Unificados: un nico bloque fsico.
Sin problemas de diseo ni administracin.
Repartidos: ms de un bloque fsico.
Posibles problemas de diseo, resueltos habitualmente por el motor
de la base de datos, de:
Tiempo de acceso.
Anlisis de consistencia.
Necesidad de anlisis de administracin 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 disean como distribuidos.

Si el motor se comporta, adems, solo habr que gestionar las polticas de
copias de seguridad para garantizar la consistencia de las copias.

3. 3. Datos distribuidos.

Deben agruparse dos casos:

3.3.1. Homogneos.

A la hora de programar son un nico bloque lgico con puntos de
heterogeneidad de velocidad de acceso si alguna de las copias fsicas
est accesible slo por una va de baja velocidad.

Necesitan trabajar la consistencia e integridad de los datos en del
diseo y en la administracin

A la hora de administrar con ms de un bloque fsico lo que obliga a
trabajar el anlisis de administracin de sistema.

Los modelos gestionados a efectos de diseo como datos distribuidos
homogneos son:

Centralizados repartidos en que el motor de BD no se comporta
igual en todos los nodos. Hoy, y desde la unificacin de los
servidores de datos bajo SQL, prcticamente desaparecido.
Particionados:
Verticalmente.
Horizontalmente. En diseo hay que disponer de un criterio
para la localizacin de los registros.
Integrado homogneo.
Replicado.
Debe aadirse una poltica de replicacin.

3.3.2. Datos distribuidos heterogneos.

A la hora de programar hay ms de un bloque lgico lo que obliga a
sofisticar la lgica de datos que habr que encapsular en su totalidad

A la hora de administrar son ms de un bloque fsico con las mismas
incidencias que cualquier otro modelo con estas caractersticas.

Solo pertenecen a este grupo aqu los modelos integrados
heterogneos incluyendo el Upsizing.

Recuerde, finalmente, que en la realidad conviven en un solo sistema
de informacin ms 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 travs
del Middleware y las copias fsicas quedan accesibles a travs de l.

Cuando los modelos eran simples, el
esquema era visualmente muy vlido.
Pero si intenta hacer un esquema de
todos los casos que le present en la
clasificacin 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 visin
lgica para la programacin y la
visin fsica para administrar y gestionar la consistencia.

De cualquier forma, en la profundizacin de los modelos de datos que visitaremos
en los siguientes captulos 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 funcin de la visin lgica que el diseo tiene de los datos y en funcin de la
localizacin fsica necesaria.

Los modelos de datos, como en cualquier rama de la ingeniera permiten:

O Tipificar comportamientos.
O Normalizar soluciones aplicables a problemas parecidos.
O Asimilar el comportamiento de cada modelo a una visin lgica de proceso.

Figura 190. Esquematizacin de la
arquitectura de datos

6. Arquitectura de datos distribuidos.

Tradicionalmente se haca una
presentacin de los modelos
de datos distribuidos como la
que se muestra en la figura.
Con ella se pretenda ayudar a
conocer que contenido tena
cada modelo. Est tan obsoleta
que no la present ni en la
introduccin. La adjunto aqu
como curiosidad.

De hecho, hay dos formas
bsicas de distribuir datos:
replicar y particionar.

Las arquitecturas distribuidas
suponen como mnimo 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 interaccin entre el primer y segundo
nivel depende del tipo de distribucin.
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 da sera 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
documentacin especializada antes de seguir.

Trabaje siempre sobre estndares ya que as sus aplicaciones sern totalmente
transportables desde la perspectiva de la lgica de datos.

La nica excepcin son los procedimientos catalogados que ligan el programa al
motor escogido. Sin embargo, an as siempre tendr la opcin de reprogramarlos
cuando cambie de motor.

Podr as, utilizar desde grandes motores ORACLE e INFORMIX, a intermedios
como SQL Server y pequeos 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. "Visin" de los modelos de datos

Figura 192. Arquitectura de datos distribuidos

8. Arquitectura de los Datos del Sistema Distribuido.

Una vez acabado el anlisis funcional se tiene el diseo lgico de los datos
reflejado en un esquema conceptual de especificacin. En algunas metodologas,
como UML, el modelo se ajusta en la etapa de diseo para obtener el modelo lgico
de diseo que, a efectos de datos no suele variar mucho en la mayora de los
casos. Eso hace que en muchos casos se siga hablando siempre de modelo
conceptual de datos en todo el proceso de diseo distribuido. En general, vamos a
seguir aqu ese criterio.

Desde ese punto de partida, al disear la arquitectura distribuida de datos, si el
modelo escogido es centralizado el esquema conceptual se implementa en un
esquema interno que corresponde al diseo fsico.

En un entorno distribuido las cosas no son tan simples. Por factores de eficacia,
coste y disponibilidad el esquema lgico se trocea y reparte por la arquitectura
distribuida segn 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 lgica de datos. Y la estructura de los datos
ser una de las causas de que esa lgica se encapsule o no en servidores. Los
otros dos grandes motivos sern 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
diseo de la arquitectura distribuida.

De forma resumida, la estrategia para construir la arquitectura de los datos del
sistema distribuido a partir del esquema conceptual lgico del funcional es:

O Distribuir los datos segn los modelos eliminado las caractersticas
especificas: centralizado: distribuido homogneo, distribuido heterogneo y
replicacin.
O Identificar, analizar y modelar los datos que no estn en BD
O Realizar la localizacin fsica.
O Ajustar los recursos de conectividad y Middleware.
O Reajustar la arquitectura para minimizar el trfico.
O Identificar los servidores de lgica 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 anlisis de la consistencia veremos que como resultados de
l, pueden proponerse cambios en la arquitectura inicialmente propuesta.

9. Upsizing.

Recuerde el problema que le present con los datos resultantes de un proceso de
Upsizing.

Hoy da, la gestin por Middleware de los esquemas de datos de las BD
heterogneas son muy pobres y poco estndares.

El problema ha de ser resuelto por Middleware de usuario. La forma habitual es
encapsular las heterogeneidades semnticas y sintcticas en servidores de lgica
de datos.

10. Recordatorio importante.

A partir de este punto trabajaremos para conducir todos los casos a los conceptos
lgicos de arquitectura de datos presentados en del apartado: Centralizar versus
distribuir: Resumen de modelos lgicos del datos

Modelo Centralizado

1. Introduccin.

El modelo centralizado fue el primero. Repase si no recuerda lo que hablamos en la
primera parte.

Poca cosa ms podemos aadir aqu.

2. Modelo centralizado de datos.

Recordemos que desde el punto de vista de administracin y programacin son el
modelo ms cmodo pero que presentan el problema del trfico de lneas y de la
ventana de disponibilidad.

Recordemos tambin que hay varias combinaciones. En particular conviene citar
los modelos centralizados con ms de un esquema fsico y los modelos
centralizados de nivel departamental.

Recordemos que puede haber dos situaciones:

2. 1. El modelo pequeo.

Suele tener un solo esquema fsico y solo
accesos en red local. No suele tener
puntos de heterogeneidad por
conexiones lentas.

El diseo y la administracin en simple.

2. 2. Modelo grande.

La terminologa grande suele obedecer a uno o combinacin de ms de uno
de estos factores:

Nmero alto de usuarios.
Conexiones lentas.
Ms de un esquema
fsico.

Suele apoyarse sobre gestores
de bases de datos de gran potencia transaccional capaces de soportar gran
nmero de clientes.

El diseo en fcil ya que la presencia de monitores transaccionales de gran
potencia suele minimizar la presencia de heterogeneidades por conexiones
lentas. La nica complicacin, aunque mnima con las herramientas
administrativas de hoy da, suele ser la administracin cuando existe ms de un
esquema fsico.

Figura 193. Modelo centralizado
pequeo.

Figura 194. Modelo centralizado grande.
Corresponden habitualmente a aplicaciones de tipologas jerrquicas y modelos de
presentacin de datos. En el mbito de diseo se ataca un slo esquema
conceptual y la nica salvedad es controlar los puntos de heterogeneidad por
comunicaciones lentas si hay algn esquema interno fsico conectado por una va
de baja capacidad.

3. Gestin de ms de un esquema fsico.

El tratamiento de ms de un esquema fsico 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 programacin, para mantener la
coherencia de los datos, y de administracin, el problema estar resuelto desde el
punto de vista del diseo.

Si no es as, el diseo habr de aportar la lgica de datos necesaria para gestionar
la distribucin fsica. La arquitectura habitual es un servidor en la parte cliente que
trabaja por delegacin de trabajo con otro situado encima de cada base de datos.
Obviamente habr un servidor por cada esquema fsico.

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 continuacin
sern vlidas aqu.

El formato del mensaje sern 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 gestin de datos particionados por lo que muchas de las tcnicas que
veremos ms adelante podrn utilizarse aqu si el problema se complica.

Replicacin

1. Una observacin inicial.

Hablar de replicacin suena a pasado. La replicacin tuvo su origen y auge, en
funciones y problemas, en la poca en que los sistemas distribuidos no disponan
de las facilidades de conectividad actuales.

Se dice que la replicacin est en claro retroceso. Nada ms cierto y nada ms
falso. La cantidad de replicaciones debe disminuir espectacularmente por la
supresin de la causa que supuso su expansin: las limitaciones en las
comunicaciones.

Pero no olvidemos que cuando estamos haciendo una concentracin 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 autonoma estamos replicado, aunque al final esos datos de guarden
en un fichero XML. Y que cuando concentramos servicios fsicamente para abaratar
la administracin sin modificar arquitecturas de software seguimos replicando.

En pocas palabras la replicacin sigue siendo un tema, aunque duro, plenamente
necesario y actual aunque haya disminuido la frecuencia de utilizacin.

2. Arquitectura de Datos Replicados.

La arquitectura de datos replicados consiste en la coexistencia de mltiples copias
de parte de los datos del entorno distribuido: una o ms fuentes a uno o ms
destinos, llamados tambin 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 replicacin puede
ser por copia, reorganizacin o sumarizacin.

Revise, si no lo recuerda, todo lo dicho all para este tema. No voy a repetirlo.

El hecho de que sea por copia, sumarizacin o reorganizacin 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 solucin fcil, 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 solucin alternativa a la replicacin sean las aplicaciones
Internet. En este punto el solape de mbito entre las aplicaciones de tecnologa C/S
basado en sistema operativo e Internet es claro. A final de este captulo, cuando
hayamos desarrollado en su totalidad el tema de la replicacin valoremos cuando
utilizar una u otra solucin.

3. Gestin de datos replicados.

Las razones ms frecuentes para replicar datos son:

O Velocidad de la conexin frente al volumen transportado
O Resolver conexiones lentas.
O Tener autonoma de trabajo en el puesto cliente.
O Disminuir el trfico de datos por la red, local o remota.
O Resolver diferencias semnticas y sintcticas.
O Limitar accesos por criterios de seguridad.

La gran desventaja es el mantenimiento. Cualquier modificacin de los servidores
de primer nivel ha de ser propagada a todas las replicas.

Uno de los parmetros bsicos a establecer es la periodicidad de esa replicacin
que se ha de montar en un proceso de forma desatendida con intervencin del
administrador slo en caso de incidencias. El control mediante tickets es muy
cmodo y flexible.

La proteccin y coherencia de los datos no son triviales. Eso hace necesario la
planificacin de procesos de auditoria y recuperacin de la coherencia y
consistencia de los datos.

4. Terminologa de datos replicados.

4. 1. Replicacin sncrona o asncrona.

En la replicacin sncrona cada transaccin de mantenimiento modifica todas
las copias existentes tan rpido como se pueda. Pero recuerde, nunca
inmediatamente!

Asncronamente la replicacin se realiza peridicamente de forma planificada
segn un calendario.

Es evidente que las dos necesitan anlisis de consistencia para garantizar la
integridad y la consistencia de los datos.

De los procesos de auditoria de las replicas se hablar de forma especfica
ms adelante.

4. 2. Tipologa de la forma de transmitir los cambios.

4.2.1. Emisin.

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 transmisin pero tiene el
inconveniente que solo puede utilizarse cuando no es necesario
retroceder los cambios si una de las replicas falla.

4.2.3. Replicacin bidireccional.

En ocasiones el mantenimiento est distribuido sobre ms de una copia,
y la replicacin debe hacerse desde ms de una fuente. Correspondera
a una situacin en la cual, por ejemplo, todos los clientes estn 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 ms de dos
copias. Sin embargo, esta situacin solo es operativa cuando el nmero
de copias es muy bajo.

Observe que en los datos particionados habr problemas parecidos.

4.2.4. Replicacin entre iguales.

Es una forma diferente de hablar de replicacin bidireccional cuando
hay ms de dos copias. El hecho el nombre viene de que al hacer el
mantenimiento todas las copias, estas se hacen iguales a efectos de
replicacin.

4. 3. Replica incremental.

Hay un tipo de replica caracterizado porque los datos se incrementan a saltos.
Un ejemplo clsico son las replicas dedicadas a analizar los resultados de
ventas y/o gestin 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 automtica o manual.

La replica incremental conlleva ligado el concepto de caducidad y eliminacin
histrica. Si solo se realizan procesos de replica incremental, ms tarde o ms
temprano, el disco se desbordar. Hay que pensar, como parte del diseo, en
los procesos de eliminacin histrica, procesos que seguramente no se
utilizarn hasta mucho tiempo despus, al vencer la caducidad establecida
para la informacin.

Un lugar muy interesante para localizar los procesos de eliminacin histrica es
el mismo proceso de actualizacin en la replica de la copia incremental
recibida: se borrar de forma automtica toda la informacin 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 informacin es definitivamente vlida,
momento en que puede generarse la replica que, al estar ya cerrada no
cambiar nunca ms.

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 mximo la disponibilidad de la
informacin.

La forma de habilitar la idea de cierre, provisional y definitivo, es el uso de
tickets jugando con los estados.

4. 4. Mecanismos de replicacin.

El mecanismo de replicacin es la forma que se realiza tecnolgicamente las
copias.

En la replicacin sncrona se habla de mecanismo de replicacin en caliente.

En la replicacin asncrona se habla de mecanismos de replicacin en fro:

Replicacin por extraccin.
Replicacin por log's
Replicacin por mensajes.
Replicacin por eventos.
Replicacin por suscripcin / publicacin.

Los trataremos en detalle ms adelante ya que muchas de estas tcnicas con
tiles tambin en servidores de programas.

5. Copia principal y foco del mantenimiento.

La copia principal o master de un sistema de replicacin es la copia desde donde
se recupera la informacin en caso de cada de algn nodo.

La localizacin de la copia principal debe tener una poltica perfectamente definida
de administracin de copias y restauraciones para garantizar la coherencia e
integridad de la informacin.

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
localizacin son diversas las aplicaciones en que esto no ocurre y el diseo lo
deber tener en cuenta.

La influencia de la no coincidencia de ambos focos depende de cada aplicacin
pero hay problemticas comunes a todos los casos. Entre ellas estn:

268
O Controlar la posibilidad de mantenimiento simultneo de una misma entidad
en puntos diferentes de la plataforma distribuida.
O Necesidad de transmisin de los cambios sncronamente a todos los nodos.
O Problemas de codificacin distribuida que abordaremos ms tarde.

6. Agrupaciones de replicacin.

Es frecuente que una serie de entidades estn relacionadas entre si y que sus
condiciones de trabajo permitan replicarlas simultneamente.

Por ejemplo:

O Los productos, proveedores y sus condiciones de compra.
O Productos y composicin.
O Productos, clientes y condiciones de venta.

Y un largo etc. que depende de cada aplicacin.

Cada una de estos bloques se conoce como una agrupacin de replicacin.

La identificacin de agrupaciones de replicacin clarifica y facilita el diseo y la
administracin.

El aumento de la potencia de la plataforma distribuida, en particular del ancho de
banda, ha hecho que el uso de este concepto de replicacin sea de gran inters en
los actuales sistemas distribuidos

7. Replicacin sncrona.

Como ya se ha dicho en la replicacin sncrona las copias se actualizan tan rpido
como se pueda y, como en cualquier replicacin, es necesario auditar
peridicamente la consistencia de los datos entre todas las replicas.

Sin embargo, para la replicacin
sncrona pueden utilizarse otros
mecanismos adicionales para
garantizar la consistencia. Uno
de los ms cmodos, fiables y
utilizados es el protocolo de
confirmacin 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 actualizacin de
las replicas. Para garantizar la
full tolerance el mecanismo de
modificacin 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 replicacin lanza una peticin de preparacin y reserva a cada
una de las copias que van contestando que estn preparadas y reservadas.
Slo 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 enve, pasado un tiempo, la notificacin de que esta
reservado. En ese caso hay que liberar las copias previamente reservadas y
reintentar ms tarde.

7. 2. Modificacin de todas las copias.

A continuacin se realiza la actualizacin en todas las copias. Si una de las
actualizaciones falla hay que decidir en diseo una estrategia:

7.2.1. Mismo nivel en todas las replicas.

Si esta es la estrategia, el fallo de una actualizacin obliga a retroceder
todas las copias que haban acabado con xito. Es la opcin ms
recomendable.

7.2.2. Admitir diferentes niveles en las copias.

En este no se habrn de retroceder las actualizaciones con xito y se
podr lanzar las que todava no se han hecho.

No hace falta decir la importancia que tiene aqu el uso de tickets como
elemento de registro y control.

Es ms eficiente pero ms difcil 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. Confirmacin y liberacin

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 liberacin de la replica.

Si la informacin es muy crtica puede realizarse una confirmacin adicional
leyendo la modificacin y comprobando que coincide con los datos del origen.

Pueden utilizarse tambin mecanismos de cheksum o recuperacin de campos
concretos o valores acumulados si hay cantidades numricas implicadas.

270
Cuando se utilizan
mecanismos de
replicacin sncrona, es
fcil darse cuenta que la
actualizacin de todas
las copias puede llevar
un tiempo. Por esa
razn la arquitectura de
la solucin no es
recomendable que
delegue al programa de
mantenimiento de la
fuente primaria la
actualizacin 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
modificacin 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 trfico de lneas que genera el mecanismo
para garantizar la full tolerance puede no interesar la replicacin sncrona en
redes complejas o lentas (normalmente remotas). Y si la replicacin se hace en
muchos casos para disminuir el trfico de lneas, es tambin muy evidente que la
replicacin sncrona esta muy penalizada y que es mucho ms interesante y
prctica la asncrona.

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. Replicacin asncrona.

Como ya se ha dicho, la replicacin asncrona se realiza en bloques cada cierto
tiempo.

El lanzamiento de la replicacin puede hacerse:

O Peridicamente, a intervalos de tiempo pactados. Es la opcin escogida casi
en todos los casos.
O Cuando hay un nmero predeterminado de modificaciones pendientes.

La replicacin asncrona es ms escalable que la sncrona pero la coherencia y la
sincronizacin de las copias es mucho ms difcil de conseguir. Sin embargo,
permite distribuir los cambios en bloque, lo que minimiza los tiempos de
comunicacin. 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
replicacin
sncrona
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 Replicacin Sncrona
271
La relacin entre la utilizacin de replicacin sncrona o asncrona y el uso que se
hace de la informacin se refleja en una esquema conocido como la escala copia /
replica. Copia hace referencia a asncrona y replica a asncrona.

En el extremo de la
copia asncrona est
la informacin de
soporte a la decisin y
en el extremo de la
derecha la
disponibilidad
inmediata.

Repasemos la escala
de izquierda a
derecha.

9. 1. Replicacin
asncrona a peticin.

La replicacin la
inicia el propio
usuario cuando
necesita los
datos.

Corresponden a replicas que se dedican a soportar dos tipos de procesos:

Procesos aperidicos de soporte a la decisin. Corresponden al mbito
de la denominada informtica de investigacin, especializada en ayudar
a montar nuevos procesos operativos o estrategias dentro de la
compaa. Un ejemplo clsico es la exploracin de ventas para decidir
nuevas lneas de productos.
Cambios puntuales en ficheros replicados que tienen cambios
aperidicos. Un ejemplo clsico son los cambios de tarifas en ficheros de
productos con pocas altas y bajas.

9. 2. Replicacin asncrona planificada.

La replicacin se realiza por copia segn un calendario prefijado. La
informacin replicada se utiliza para los denominados procesos de anlisis. Un
proceso de anlisis clsico es el estudio del resultado de las ventas del mes
anterior.

Es la replicacin ms habitual. En particular cubre un caso muy frecuente:
replicacin de ficheros en puestos clientes para conseguir autonoma en caso
de fallo de la conexin. Por ejemplo, replicar un fichero de productos con los
precios de venta en los TPVs para conseguir que puedan seguir vendiendo
aunque caiga el servidor.

9. 3. Asncrona entre iguales y bidireccional.

Es el modelo de trnsito entre los dos tipos de replicacin.

La replicacin es peridica por copia pero de frecuencia muy alta.
Asincrona
Puntual por
peticin
Asincrona
Planificada
Asincrona
entre
iguales
Bidireccio-
nal
Sincrona
Confirma-
cin en dos
fases
Copia en
Caliente
Full
Tolerance
Alta disponibilidad Soporte a la decisin
Investigacin Anlisis
Consulta y
Mantenimiento
no crtico
Aplicaciones
tiempo real
Replicacin
de seguridad
ante fallos de
servidores

Figura 198. La escala copia / replica.
272

Es utilizada para informacin de anlisis en continuo o para procesos de
mantenimiento no crtico. Este concepto hace referencia a mantenimientos de
entidades de baja volatilidad y en la cual los cambios no se necesitan
rpidamente actualizados.

Un ejemplo habitual es el mantenimiento de la entidad cliente: un cambio en la
direccin de envo de la mercanca se ha de actualizar pronto pero no es
crtico: 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 direccin de envo es prcticamente nula. Sin embargo, para este tipo de
proceso es recomendable la escala siguiente.

Es interesante tambin 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 ms interesante el siguiente
tipo.

9. 4. Replicacin sncrona con confirmacin en dos fases.

Es el tipo de replicacin sncrona en el cual los cambios se transmiten tan
rpido como es posible. Se utiliza para los procesos de mantenimiento no
crtico contemplados en el punto anterior.

9. 5. Replicacin sncrona inmediata y el caliente.

La idea de esta escala de replicacin es que el cambio se transmite
inmediatamente a todas la replicas. Intenta parecerse a un mantenimiento
clsico que reserva el registro a modificar y cuando lo libera el cambio ya es
vigente. Usted podra mantener el stock de sus almacenes as.

Personalmente pienso que es una quimera irrealizable y peligrossima. Si
usted tiene replicas es porque no tiene acceso fcil a la fuente. Y si no tiene
acceso fcil, los cambios llevarn un tiempo y pueden fallar por la cada de la
conexin! Hgame caso: si tiene tentacin de utilizar esta escala, es que ha
diseado mal; piense otra solucin.

Existen mecanismos como la replica por instantneas (snapshots) pensadas
para esta escala y aplicables, obviamente, a la filosofa de tan rpido como se
pueda.

273
10. Uso de tcnicas Master-Slave en replicacin.

El uso de tcnicas master/slave implementadas por
multihilo puede ser una solucin muy eficaz en
replicacin, sobre todo si el modelo de replicacin es
sncrono.

Si la replicacin es sncrona el master recibe el
cambio y delega a cada slave la modificacin de un
nodo. En este caso, cada hilo puede no ser
idempotente ya que, como se ha dicho antes, si la
actualizacin de un nodo no acaba bien, lo normal es
no deshacer los que han acabado bien. El problema
de la sincronizacin de la concurrencia y el
paralelismo no es trivial y debe tratarse con cuidado
si se quiere conseguir la replicacin con la rapidez y
eficacia que ha justificado este tipo de replicacin.

Si la replicacin es asncrona, 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 atrs si una de los nodos falla, cada hilo es idempotente con los otros y
los problemas de concurrencia y paralelismo son mnimos.

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 asncronas es el
uso de tickets.

Las estrategias pueden ser muy diferentes en funcin de los diferentes
condicionantes de cada aplicacin.

A modo de ejemplo, imagine que quiere controlar el buen fin de todas las
replicaciones cuando no importa que todas las copias estn 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
replicacin donde las situaciones son los nodos a replicar y los estados la
situacin del proceso de replicacin.
O Cada vez que se emite o recoge una copia a o desde un nodo se coloca el
estado de iniciado para la posicin 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 automtica 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 automticos del estilo de avisar
automticamente cuando un nodo acaba con error, o pasado un tiempo, que nodos
estn todava pendientes, etc.

Figura 199. Replicacin
por
master/slave.
274
12. Mecanismos de replicacin.

12. 1. Replicacin por protocolo de dos fases.

Es el mecanismo de replicacin sncrona que se ha presentado anteriormente.

12. 2. Replicacin por extraccin.

Es el sistema asncrono por definicin: la copia, sumarizacin o reorganizacin
se extrae de la fuente y se enva a las replicas.

Es muy habitual que se utilice como plataforma el servidor de correo en tres
pasos:

Extraccin de la fuente y anotacin en el buzn del servidor de correo.
Transporte por el servidor de correo de la copia al lado de la replica.
Sustitucin o actualizacin de los cambios en la replica extrayndolos de
la copia del buzn, posiblemente con un sistema de viga-disparador
sobre la lista de recepcin.

Existe tambin la posibilidad de encargar el trabajo a un procesador distribuido
de los que se presentan en el captulo de integracin de la parte cliente.

12. 3. Replicacin por log's.

Es un modelo indistinto para sncrono y asncrono.

Cuando se utiliza este
mecanismo, el
programa de
mantenimiento de la
fuente primaria graba
un log con los cambios.
El sistema de
replicacin transmite
los cambios a los
nodos de las replicas.

Este mtodo es
especialmente til
cuando la periodicidad
es baja o los
volmenes son altos.
Evita la extraccin.

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 seleccin sobre el log original,
enviarlo a la replica y cargarlo con las herramientas del Middleware del motor
de BD. La sumarizacin o reorganizacin penalizan gravemente la utilizacin
de esta tcnica.

Fuente de
datos primara
Mantenimiento
Copia
1
Copia
2
Copia
N
Sistema de
replicacin
Log

Figura 200. Replicacin 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. Replicacin por mensajes.

Normalmente la replicacin por mensajes sncrona. Cada mensaje lleva la
informacin de un cambio que se transmite por un mecanismo cliente /
servidor. Es la tpica replicacin sncrona a travs de servidores. Observe,
como curiosidad que la replicacin sncrona por mensajes suele hacerse a
travs de colas, mecanismo de comunicacin asncrono.

12. 5. Replicacin por eventos.

Cuando hay un cambio se avisa con un evento a cada nodo.

El aviso puede ser de un cambio para replicacin sncrona en cuyo caso los
parmetros del evento llevan la informacin del cambio.

El aviso puede ser tambin de la existencia de una nueva versin de la replica
en replicacin asncrona iniciada desde la banda de la replica.

12. 6. Replicacin por instantneas (snapshots).

La transaccin de modificacin de la fuente actualiza al mismo tiempo las
replicas. La idea del snapshot (instantnea en ingls), es que se copia la
informacin tal como est en ese instante en todas las copias. La idea es
mantener origen y destinos instantneamente 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 opcin vlida.

Una de sus caractersticas diferenciales en mantenimiento sncrono es que la
sincronizacin 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 instantneos mantenidos on-line.

12. 7. Replicacin por Publicacin / Suscripcin.

Utilizando este mecanismo, que hemos presentado en la primera parte y
detallaremos ms adelante, puede obtenerse un sistema muy fiable de
mantener replicar en caliente o en fro.

As, cuando la base de datos sobre la cual se realiza el cambio detecta una
modificacin, 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 slo de unas determinadas tablas, con particin horizontal o
vertical.

Hay varias de formas de trabajar:

276
Aprovechando los mecanismos automticos que suministran los gestores
de bases de datos.
Publicando los cambios desde los programas de modificacin y
suscribiendo con clientes background o agentes que se despiertan con
los eventos de cambio.
Utilizar un mecanismo especfico de Publicacin / Suscripcin.

12. 8. Usar los mecanismos de replicacin de los gestores de la base de
datos.

Si el gestor de la base de datos ofrece la posibilidad de replicacin automtica
siempre puede usarla.

Sin embargo, sea muy precavido en dos sentidos:

Compruebe que realmente funciona.
La aplicacin quedara distribuible en lugar de distribuida al estar cautiva
de los recursos de un modelo especfico de gestor.

13. Utilidad del Viga y del Disparador en gestin de replicas asncronas.

Permiten automatizar la carga en la parte replicada.

El Viga escuchar el directorio, cola, mail o cualquier otro recurso donde
aparezcan las copias y el Disparador lanzar el proceso que corresponda.

14. Replicacin Cach.

Hablamos de datos replicados temporalmente o cach cuando la replicacin se
realiza mediante una copia en una zona de acceso rpido que cuando deja de ser
usada se destruye.

Se consigue as una mejora importantsima en la velocidad de respuesta cuando se
necesitan esos datos. La mejora es todava mayor si se aprovecha la copia para
organizar los datos con un tipo de organizacin de acceso ms eficiente de acuerdo
con el uso que se va hacer de los datos.

Es evidente que para que esta replicacin se pueda utilizar es necesaria la certeza
de que los datos no cambiarn mientras estn en cach.

Pude haber cuatro formas de hacer la replicacin 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 ms rpidas 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 replicacin 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 replicacin queda a disposicin de todos los programas usuarios del nodo
donde se localiza la cach.

Las tcnicas cach se usaron tambin en tiempos histricos para datos
particionados que se mantenan en caliente. Hoy da las tcnicas en ese contexto
estn 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 replicacin con los
mecanismos de persistencia automtica que proporcionan algunos lenguajes OO.

15. Data Warehouse y replicacin.

Una forma habitual de implementar una replicacin es usar un Data Warehouse del
que ya he hablado en la primera parte. Si no lo recuerda, por favor, relalo.

Slo recordar que como soporte de la replicacin un Data Warehouse proporciona
dos caractersticas adicionales importantes:

Soporte de datos con heterogeneidades semnticas y sintcticas en las
fuentes.
Escalabilidad al aumento de clientes.

16. Replicacin virtual o Data Warehouse virtual.

La idea de replicacin conlleva dos necesidades bsicas: el proceso de replicacin
en si y que la disponibilidad de los datos no es instantnea.

Estos dos inconvenientes pueden solventarse mediante una tcnica conocida por
algunos autores como replicacin virtual o Data Warehouse virtual. Consiste en
acceder directamente a las fuentes de datos a travs de servicios que realizan la
unificacin semntica y sintctica de los datos en cada fuente a travs de un
metaesquema. Los servicios pueden implementarse con tcnicas de Servicios WEB
para conseguir estandarizacin y generalizacin.

En mi opinin, esta estrategia no tiene nada que ver con replicacin, si no que est
en la lnea de servicios de datos. Qu opina Vd.?

17. Auditoria de datos replicados.

Si la replicacin se hace asncronamente por sustitucin, es decir, enviando
peridicamente 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 recordmoslo, llegar con full
tolerance) garantizar la igualdad de la fuente y replica. Pero recordemos que esta
va de replicacin slo puede usarse para copias de volmenes pequeos o cuando
la sumarizacin y / o reorganizacin disminuyen de forma importante el volumen de
los datos a replicar. Y que adems las conexiones lentas, causa importante de la
existencia de las replicas, disminuyen el nmero de casos en que la replica por
sustitucin puede usarse.

Si el mantenimiento es sncrono o asncrono 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 aplicacin lo necesita, que fuente y replicas estn 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 algn 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 sustitucin. Se
produce, pues, un verdadero abrazo mortal.

La auditoria puede ser en caliente o en fro. Si es posible hacerla en fro fuera de
los periodos de servicio pactados con los usuarios, debe primarse esa opcin.

Si no es posible, se habr de hacer el caliente, reservado temporalmente la
entidad auditada si es necesario; est ltima circunstancia depender de las
caractersticas y uso de cada entidad.

Si hay datos numricos involucrados (por ejemplo, un fichero de ventas) una opcin
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 arreglarn en la replica con el valor de la fuente y solo en caso
extremo se enviar una copia total nueva, opcin 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 comparacin
que proporcione
informacin de las
diferencias.
O Y otro de reparacin.

Basta para ello tener un
parmetro que diga si el
proceso de auditoria se
pide slo de comparacin
Servidor de
referencia
Servidor
replicado
Comparacin
Diferencias
Actualizacin
Automtica
Conforme
Anlisis de diferencias

Figura 201. Esquema de Auditoria de Datos Replicados
279
(la verdadera auditoria) o tambin de reparacin. Observe que a efectos de
programa solo supone la ejecucin 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 fsicas (plataforma), lgicas (de programas) o de operacin (usuario) aadir
las mejoras para que las causas desaparezcan. En particular, si la causa en un
error de operacin, blinde la aplicacin para que el usuario no pueda repetirla.

18. Factores a considerar en la poltica de replicacin.

La organizacin que tiene datos replicados debe establecer una poltica de
replicacin que hay que implementar en el diseo de la aplicacin.

Para establecer la poltica hay que ponderar diferentes factores:

18. 1. Localizacin de las copias.

El primer factor a determinar es la localizacin fsica de las replicas. Recuerde
que solo podr utilizar los nodos de los niveles lgicos.

Se ponderarn bsicamente dos criterios:

Localizar los datos tan cerca de los usuarios como sea posible.
Garantizar el trabajo en caso de cada cuando est situacin sea
necesaria.

18. 2. Situacin de la replicacin en la escala copia-replica.

Se determinar el uso de la copia: investigacin, anlisis, mantenimiento no
crtico, etc. Y con este factor se har una primera situacin segn la escala
que tipo replicacin, sncrona o asncrona, debe de usarse.

18. 3. Volatilidad.

La volatilidad (frecuencia de los cambios) de los datos tiene una importancia
fundamental para determinar el modelo de replicacin (sncrono o asncrono) y
el calendario.

18. 4. Tamao de los datos.

Ver que se necesita copiar determina el tamao 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
extraccin.

18. 5. Tipologa de la forma de transmitir los datos.

Se analizar si el mantenimiento se realiza en un nico punto (situacin que
debe primar) o no. Si no es as, deber hacer replica bidireccional. En caso
contrario deber elegir, en funcin de su aplicacin, si hace emisin 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 crtico o no.

18. 7. Plan de auditoria.

El plan de auditoria est, lgicamente relacionado con la fiabilidad. Habr que
decidir hacerla en fro o en caliente y cmo, cuando y donde se har.

18. 8. Disponibilidad.

La disponibilidad de las dadas en horario y acceso influir bsicamente en la
localizacin. Por ejemplo, si un usuario es nmada, por acceso deber tener la
replica en su porttil. Si una delegacin trabaja fuera de los horarios de los
ordenadores centrales, por horario de acceso

18. 9. Calendario y horario.

En replicaciones asncronas habr que decidir cada cuando se actualizan las
copias (factor muy ligado a la volatilidad) y encajar estas copias en el
calendario si la dispersin geogrfica es importante. Finalmente habr que
decidir el horario.

18. 10. Copiar, Reorganizar o Sumarizar.

Escoja la combinacin de los tipos de replicacin que le conviene. Recuerde,
que si puede sumarizar o reorganizar minimizar volmenes 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 replicacin.

Si el modelo de replicacin es asncrono, 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 disposicin del destino un semforo
o un ticket que le informe si la copia ya est disponible. Es una opcin
muy til para resolver la problemtica del calendario y el horario y el
acceso desde usuarios nmadas.

18. 13. Caducidad de la replica.

Cuando la replica es incremental recuerde que debe decidir la caducidad
histrica y si la eliminacin se hace manual o automtica (prime esta segunda
opcin).

281
18. 14. Preguntas de inters.

Antes de tomar decisiones definitivas hgase las preguntas:

Si ha elegido esa opcin, es realmente necesaria la replicacin
sncrona?
Cmo es el mantenimiento y cual es la copia master?
Los criterios de mantenimiento crtico (necesidad de actualizacin
permanente) son correctos?
Las prdidas de rendimiento por procedimientos de dos fases son
tolerables?
La no sincronizacin de las copias es peligrosa?
Puedo sumarizar y / o reorganizar en lugar de copiar?

19. Cuestiones de inters tcnico.

Existen cuestiones de inters tcnico que pueden influir, aunque se debera evitar,
en la poltica de replicacin ya que muchas son enmascarables desarrollando lgica
de datos.

O Existencia de soportes heterogneos en la fuente primaria y los destinos.
Obliga a realizar los cambios semnticos y/o sintcticos en el proceso de
replicacin. Recuerde que la presencia de puntos replicados en XML supone
una heterogeneidad.
O Que el entorno disponga o no de recursos de programacin y ejecucin de
multihilo (un sistema multitarea) condicionar las soluciones tcnicas. Sin
embargo, la realidad actual lo da prcticamente siempre resuelto.
O Posibilidad de basar la replicacin en el motor de la base de datos. SQL
Server, por ejemplo, mantiene la replicacin entre diferentes copias fsicas de
forma automtica. Ventajas: economa y comodidad. Desventajas: solo
replicacin por copia y no es segura la consistencia.
O Presencia de nodos remotos lentos y de usuarios nmadas.
O Alternativas por Internet, de las que se hablar a continuacin.

20. Poltica de replicacin.

La respuesta que de todas estas cuestiones establecer la poltica de replicacin
que deber quedar definida y documentada en el anlisis 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 replicacin.

Cada vez ms los gestores de BD proporcionan con el motor herramientas de
Middleware para replicacin de datos y sincronizacin de esquemas entre copias
fsicas diferentes.

Las posibilidades replicacin de este Middleware, inexistente hace pocos aos,
debe conocerse por los diseadores y administradores para implementar la poltica
de replicacin.

282
El camino es el de siempre: marcar nuestra poltica de replicacin, 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 administracin.

Conviene hacer unas reflexiones sobre esta va.

La solucin quedar ligada al gestor que utilice. Es decir, ser distribuida, no
distribuible.

Asegrese de que el producto aporta de verdad full tolerance.

Las soluciones tcnicas mejor resueltas son las asncronas peridicas, por
extraccin y propagacin por emisin. Repitiendo la emisin se obtiene la cascada.

22. Aplicaciones C/S basadas en sistema operativo trabajando sobre
datos replicados versus aplicaciones Internet.

Evidentemente, una primera situacin rpida lleva a centrar el mbito de la
comparacin sobre las aplicaciones de consulta.

Si la volatilidad de los datos es alta o los volmenes son grandes, las aplicaciones
Internet tendrn todas las ventajas sobre las C/S. En particular, la existencia de uno
o ms puntos de heterogeneidad por conexiones lentas (normalmente remotas)
hace que el nivel de volmenes altos est ms bajo.

En el otro extremo, replicaciones peridicas de datos poco voltiles o que no tienen
sentido hasta la replicacin (como, por ejemplo, replicas para estudiar los
resultados de ventas de una periodo) y los usuarios nmadas priman las
aplicaciones C/S sobre la Internet.

Y un factor claro a favor de Internet: la generalizacin de la conexin y la
independencia de la aplicacin de la mquina cliente.

En medio, un amplio gris de difcil sistematizacin. Pero me deja darle una
impresin: 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 replicacin 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 organizacin, hay varias soluciones que hay que
comparar y valorar:

O Un modelo replicado entre iguales mantenido de forma sincrona
bidireccionalmente. Normalmente utilizar servicios de lgica de datos para
encapsular la integridad y consistencia.
O Un modelo centralizado, o al menos de las entidades afectadas.
O Si la aplicacin distribuida esta basada en sistema operativo, el acceso
se har en tiempo real a travs de una conexin 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 aplicacin es Internet o utiliza Servicios WEB para la gestin de los
servicios de datos, el modelo resuelve el problema ya que la gestin 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 solucin.
Bsicamente, facilidad de administracin contra independencia del puesto.

Una solucin intermedia es trabajar con servidores de programas replicados.

La idea es mantener por administracin manual la ltima versin en un servidor y
mantener automticamente las replicas en los puesto de trabajo o en los servidores
intermedios. Se combinan as las ventajas de las dos soluciones. Obviamente la
solucin puede arrancarse automticamente 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 cmoda 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 versin con
fecha de vigencia alcanzada. Si la hay, la copia en el servidor de programas
replicado y despus pasa control al programa solicitado desconectndose a si
mismo. Si no hay nueva versin arranca la actual.

Si el servidor de programas no est disponible arranca la copia actual.

Esta tcnica tiene un inconveniente si el programa, como puede ser un servidor,
est arrancado perpetuamente. Rpidamente ver varias soluciones para este
problema que se basan en preguntar de tanto en tanto si hay nueva versin
disponible y en caso afirmativo autollamarse a travs del ejecutor.

Hay
nueva
versin?
Servidor de
programas de
referencia
Servidor de
programas
local
Copiar
nueva
versin
Arrancar
Programa
pedido
Auto
desconexin
Si
No

Figura 202. Arquitectura de un ejecutor
Datos Particionados

1. Introduccin.

Como ya se ha dicho en varias ocasiones, hay dos formas de distribuir datos:
replicar y particionar.

En el captulo anterior hemos hablado ampliamente de la replicacin. Vamos a
tratar ahora la particin.

Va a observar un resultado muy curioso. La gestin de datos particionados parece
a priori ms compleja que la replicacin. Pero observar que este captulo es
sorprendentemente ms corto que el correspondiente a la replicacin.

Despierte de su asombro. Es lo lgico. 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 replicacin.

2. Modelo particionado de datos.

Dentro de la arquitectura
de datos particionados,
los servidores A y B no
tienen datos en comn.
El servidor C hace de
manager: si A necesita
informacin de B la
consigue a travs de C.

El servidor C no tiene datos, solo sabe como localizarlos. La forma en que C
implementa est opcin es a travs 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 sncrono.

En caliente: cada vez que hay un cambio en A y B, este se actualiza en el
ndice tan rpido como sea posible en C.

2. 2. Mantenimiento asncrono

En fro: los cambios de A y B se actualizan peridicamente en C.

3. Tcnica.

Puede utilizarse dos formas bsicas para localizar cada registro:

Figura 203. Arquitectura de datos particionados
3. 1. ndice.

Mantener un ndice en C de los datos de A y B. Observe que no es ms que
un caso especial de replicacin en que slo se replica la clave de cada
registro y su localizacin.

Son aqu vlidas todas las tcnicas presentadas en el captulo anterior, y que,
por tanto, no repetir aqu.

3. 2. Regla de negocio.

Existe alguna regla de negocio o sistema de codificacin para saber a que
nodo hay que acceder.

Ponga especial inters en mantener la consistencia y totalidad de los datos si el
mantenimiento del ndice es sncrono.

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 tcnicas de auditoria son, una vez ms, las mismas que en la replicacin.

Hay, sin embargo, una diferencia fundamental. El volumen de datos para mantener
un ndice es muchsimo ms pequeo que el de una replica. Ello hace que en lugar
de la auditoria por comparacin, sea muy viable hacer actualizacin por copia de
las claves principales de cada entidad.


Los datos particionados son muy eficientes ya que estn muy cerca de donde se
necesitan. No son mucho ms difciles de mantener que los replicados; quizs,
incluso, menos. La administracin es muy sencilla ya que la auditoria se hace
prcticamente siempre por sustitucin y la administracin de cada particin es
centralizada.

Siempre que la aplicacin lo permita, por ejemplo casos en que los clientes estn
muy localizados en las delegaciones de venta, por qu no se usan ms? Por
miedo?, por falta de formacin?

Codificacin distribuida

1. Introduccin.

Tanto el modelo replicado con focos de mantenimiento diferentes del nodo primario
o master como en datos particionados, se platea un problema de codificacin cada
vez que hay que hacer un alta.

Cmo hacer que el cdigo 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 cdigo. Y tras hacerlo empieza a
utilizar el registro.

Si cuando la informacin se concentra resulta que el cdigo est duplicado, se
deber, adems de avisar al usuario remoto, cambiar todos los cdigos de los
registros de las entidades donde ya se haya utilizado. En fin, un verdadero
problema.

Y no imaginemos un entorno en que el cdigo se ha intercambiado ya con terceros,
situacin cada vez ms frecuente.

Este es el emergente concepto de codificacin distribuida: como asignar cdigos
en un sistema distribuido sin que haya colisiones. El problema afecta tanto a
replicaciones como a datos particionados.

Deber empezar por dotar a la organizacin de un criterio claro de asignacin de
cdigos remotos.

La decisin de dejar la eleccin del cdigo al usuario utilizando esas reglas es
peligrosa ya que tarde o temprano se va ha equivocar. No la use.

La solucin organizativamente vlida pasa por delegar la codificacin distribuida a
la propia aplicacin. Este es el tema que vamos a tratar en este capitulo.

2. Criterios de asignacin de cdigos.

Usted que conoce su organizacin sabr cual es el mejor criterio para codificar de
forma distribuida en su aplicacin.

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 cdigo del tipo:

O Serie, opcional
O Referencia de nodo.
@@EMG/10 - Enric Martnez Gomriz

287
O Numero secuencial dentro del nodo.

Veamos dos ejemplos.

O Productos:
O Referencia de nodo: dos dgitos 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 dgitos siempre informados.
O Pedidos y albaranes.
O Serie: un digito, A o P.
O Referencia de nodo: dos dgitos.
O Nmero formado por:
Dos dgitos para el ao.
Cuatro dgitos para un numero secuencial

3. Gestin de la codificacin distribuida.

La asignacin de referencias de nodo y series se hace normalmente de forma
centralizada y se distribuye como parte de los datos de configuracin.

Cuando un mantenimiento necesita un nuevo cdigo, la propia aplicacin sugiere el
siguiente al ltimo utilizado.

La verificacin de no duplicidad de ese cdigo debe comprobarse siempre como
medida adicional de seguridad.

Aqu hay muchas posibilidades. Son opciones clsicas:

3. 1. Verificacin sncrona

Cuando se acepta el alta se accede a la copia master, en el caso de
replicacin, o al ndice en el caso de datos particionados, y se verifica.

Puede hacerse:

Atacando la base de datos directamente travs del servidor de base de
datos.
Estableciendo un servicio especifico implementados en un servidor sobre
la base de datos master.

Segn sea la entidad habr que hacer o no una prerreserva del cdigo. Hay
varias formas de hacerlo.

Alta condicional de forma que si pasado un plazo no se ha confirmado se
elimina.
Tabla temporal de cdigos en curso donde se mirar para saber si una
peticin de verificacin o peticin de nuevo de cdigo pueda comprobarlo
aunque todava no exista en la base de datos porque todava no se ha
realizado la transaccin de alta.

3. 2. Verificacin asncrona.

@@EMG/10 - Enric Martnez Gomriz

288
La verificacin se hace cuando se consolidan las copias. Solo la recomiendo en
los casos de probabilidad muy baja de errores.

Con estos criterios, en una codificacin distribuida de cdigos de artculos se
tiende a verificacin sncrona y en una de albaranes a asncrona.

La solucin es ms un proceso organizativo que informtico. Puede consistir
simplemente copiar el registro con otro cdigo y pasar el programa de cambio
en bloque de cdigos del que se habla a continuacin.

3. 3. Asignacin dinmica.

Un servicio centralizado dar el cdigo. No hace falta decir que ya no tenemos
problema de verificacin.

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 asignacin provisional de cdigo para cuando
se trabaje en emergencia.

4. Cambios de cdigo en bloque.

Como vacuna final le aconsejo que disponga siempre de una funcin en la
aplicacin distribuida que le permita cambiar los cdigos asignados en una
codificacin 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 opcin es muy fcil implementar ya que no necesita ser eficiente sino
nicamente eficaz y de fcil operativa. Y adems podr obligar a pasarla en fro.

Aplicacin del Patrn DTO

1. Introduccin.

Imaginemos que existe una frontera entre un nodo donde se realiza la gestin 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 restitucin de cada atributo sobre
la base de datos deberia acceder a la base de datos. La consecuencia sera muy
clara: perdida importante del rendimiento. La solucin, aplicar el patrn DTO (Data
Transferir Object).

Observemos que la aplicacin de ese patrn en evidente en aplicaciones de
consulta pero mucho ms problemtica en aplicaciones de mantenimiento ya que
obliga a reservar la entidad en la base de datos mientras el modifica en el nodo
remoto.

La aplicacin puede realizarse sobre un nico registro o un conjunto de regristros
en la lnea de una selec.

2. Aplicacin del patrn DTO.

La aplicacin del patrn siempre supone DTO siempre supone los siguientes pasos
que se muestran en la figura de la derecha:

2. 1. Obtencin 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 aplicacin ha de
modificar el registro, deber
reservarlo en la base de
datos.

2. 2. Gestin del DTO.

La gestin del registro o
conjunto de registros se
realiza sobre el DTO, local
para el cliente.

2. 3. Modificacin 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
Recuperacin del/de los registros
:Controlador Remoto de Datos
Gestin de los datos sobre el DTO
Actualizacin del DTO
Nodo Cliente Nodo de datos
F
r
o
n
t
e
r
a

Figura 204. Aplicacin del patrn DTO para mejorar rendimiento
290
Servicios de Agrupacin de Entidades de
Datos

1. Introduccin.

A lo largo del estudio y el diseo 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 distribucin de
los datos, con esquemas homogneos o heterogneos, puede obligar a la
reconstruccin de la entidad yendo a buscar los atributos a ms de una
localizacin y teniendo que resolver diferencias sintcticas y semnticas entre los
atributos comunes.

La idea bsica 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 solucin el problema. Estos servicios son los
que se denominan Servicios de Agrupacin de Entidades, que incluyen:

O Agregacin. Por ejemplo, un pedido y todos los albaranes en que se ha
servido.
O Integracin. Por ejemplo juntar los atributos de producto de las aplicaciones
de fbrica y de facturacin.
O Agregacin e integracin simultnea.

Es evidente que con todas las herramientas ya presentadas Vd., amigo lector,
podra atacar el diseo de estos servicios por si slo. Pero dada la importancia de
esta tipologa de servicios vamos a dedicarle un captulo especfico.

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 travs de
servicios de lgica de datos. En ningn caso el servicio de agrupacin 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 autentificacin inicial y una clave de autentificacin del permiso
que se incorporara a cada peticin.
O Autentificacin a cada acceso.
O Responsabilizndose la aplicacin de uso. Esta solucin es admisible en
aplicaciones internas pero no en relaciones con terceros.
O Conocer los esquemas lgicos de origen y de los servicios de acceso de los
que hemos hablado.
O Disponer del criterio de particin horizontal en caso de existencia de esta
situacin.

Toda esta informacin estar presente en el metaesquema del que hablaremos
ms adelante.

3. Sistematizacin de la casustica.

Si analizamos con cuidado todos los ejemplos que han salido de heterogeneidades
de datos podemos clasificarlas en la siguiente casustica:

3. 1. Visin unificada de una entidad.

Integrando en una sola vista todos los atributos dentro del sistema distribuido
de una nica entidad. Obliga a resolver diferencias semnticas y sintcticas
entre los atributos comunes.

3. 2. Particin horizontal.

Obliga a localizar cada registro en la localizacin en que se encuentra. Es
prerrequisito conocer el criterio de particionado, no siempre la distribucin
geogrfica.

3. 3. Escenarios de agregacin.

Tambin conocidos como escenarios Cross-Join. Agrupan datos de entidades
diferentes proporcionados.

Hay dos casos muy diferenciados.

Todas las entidades comparten localizacin.
Hay dispersin de localizaciones, donde puede haber problemas de
rendimientos al tener que hacer y montar joins distribuidas.

Un ejemplo clsico de esta ltima situacin es analizar la situacin del stock en
un sistema de almacenes distribuido donde la responsabilidad de cada saldo la
lleva el propio almacn 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 visin nica del modelo de datos integrado a travs
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 ms de una fuente.
O Todas las equivalencias necesarias para resolver las diferencias semnticas y
sintcticas entre atributos compartidos. Incluye las reglas de transformacin.
O Equivalencia de claves principales, secundarias y auxiliares.
O El criterio de particin horizontal si esta presente esa casustica.
O La descripcin 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 creacin o modificacin conviene actualizar todas las copias
del atributo.

A efectos de rendimiento, siempre que sea posible, debera trabajarse con una
copia master de la entidad y solo buscar los atributos que no estn all en las
alternativas

Los atributos que se utilizan como referencias principales pueden ser diferentes en
diferentes esquemas de origen. Un ejemplo clsico pude ser un fichero de clientes
que en contabilidad se identifique por el NIF y en facturacin por un cdigo. Como
todos los atributos descritos en el metaesquema, este incluir tambin los criterios
de mapeo de referencias.

Ntese que la presencia de claves alternativas pude obligar en caso de
modificacin y en caso de que no sea la fuente de origen la master de los atributos
afectados, a procesos de baja y alta. Esa informacin tambin ira en el
metaesquema.

La equivalencia de claves puede llegar a ser imposible de detectar de forma
automtica y exigir la intervencin de algn usuario responsable que tenga
conocimientos y experiencia para hacer la propuesta. Esta problemtica, 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 replicacin.

El metaesquema debe representarse siempre de forma descriptiva y no estar
incluido dentro de una zona ejecutable. Ello
permitir generalizacin, adaptabilidad y
extensibilidad. Un servicio de
interpretacin o interpretador,
generalmente un servicio pasivo, atacar el
metaesquema desde los servicios de
agrupacin de entidades.

Dos formas habituales de guardar el
metaesquema son:

Interpretador
Metaesquema

Figura 205. El servicio de interpretacin
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 agrupacin.

5. Servicio de Agrupacin de Entidades.

Como ya hemos dicho, el objetivo bsico 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 semnticas y
sintcticas y acceder a los servicios de origen.

Existen dos formas bsicas de disear el servicio de agrupacin:

5. 1. Por servicios.

A travs de servicios proporcionados por los entornos de origen y utilizndolos
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 simultneamente para optimizar los tiempos de respuesta:

Si la comunicacin
con los servicios de
origen es
asncrona bastar
aprovechar este
recurso.
Si es sncrona,
cosa habitual en
servicios de datos,
habr que utilizar
alguna de las dos
arquitectura que se
muestran en la
figura:
Master/slave.
Delegacin
de dos capas
donde la
segunda resuelve de forma asncrona el acceso sncrono al origen.

El servicio genrico representado por la S simboliza cualquier mtodo de
acceso sncrono.

5. 2. Por replicacin.

Utilizando normalmente una arquitectura de replicacin sncrona. Esta
arquitectura se deber primar en los casos analizados que justifican
replicacin:

Servidor
de
agrupacin
Servicio
de
Conexin
D
P
S
Servidor
de
agrupacin
M
Servicio
de origen
P
S

Figura 206. Arquitectura de servidor de agrupacin con servicios
sncronos en origen
294
Presencia de usuarios aislados o nmadas.
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 agrupacin sea de replicacin debe quedar
totalmente escondida al usuario del servicio.

Por otra parte vale tambin el principio genrico de que el servicio de
agrupacin 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 replicacin. Si esto es
as, deber crearlos como parte del primer diseo que los necesite.

La replicacin suele ser por copia ya que se necesitan todos los atributos y
registros de la entidad disponibles, pero puede valorarse tambin copias
selectivas, como la particin horizontal, segn cual sea la necesidad y el
entorno de la aplicacin. De hecho desde un punto de vista riguroso, es
reorganizacin ms que copia ya que la copia replicada se mantiene en el
formato unificado proporcionado por el metaesquema.

Un punto fundamental ser la decisin de:

El tipo de mantenimiento: distribuido, centralizado, desde cada nodo o
distribuido entre los nodos.
El lugar donde reside el master de la replicacin.

Una opcin interesante es que la replicacin se haga por reorganizacin
guardando solo las referencias y/o los campos de acceso ms habituales. Esta
posibilidad, con un buen metaesquema, donde el lugar de origen de cada
atributo esta perfectamente marcado, es muy fcil de montar.

En la figura se
muestra una
posible
arquitectura de
un servicio de
agrupacin de
entidades en un
diseo de
replicacin.

Observe la
presencia de un
servicio
asncrono
implementado
por un agente y
que
denominaremos
el
sincronizador.

Para el diseo del sincronizador utilizaremos cualquiera de los recursos para
replicacin sncrona que hemos visto en el captulo dedicado a replicacin.
P
S
Servidor de agrupacin
M
D
S
Punto de
entrada
Entidades afectadas
Sincronizador
Servicio
de origen
Gestin
a las
entidades
Acceso
Registro
de
cambios
M
Punto de
salida

Figura 207. Arquitectura del servicio de agrupacin basado en
replicacin
295

El proceso para la gestin de las entidades afectadas puede ser en paralelo.
En la figura se muestra una solucin Master-Slave. Sin embargo es muy
frecuente que, al ser la copia replicada local, no sea necesario complicar el
diseo y el acceso se realice a directamente a la base de datos. La cola de
comunicacin entre el sincronizador y el servicio en s debe tener
persistencia.

5. 3. Por servicios y replicacin.

Es obvio que en muchos casos ambas arquitecturas pueden combinarse. La
arquitectura resultante ser la agrupacin de ambas.

6. Semntica CRUD (Create-Read-Update-Delete).

Una primera decisin a tomar puede ser dividir el servicio en dos basndose en el
criterio de que la lectura es idempotente. As aparecern dos tipologas de servicio:

O Servicio de lectura donde no tendremos problemas de consistencia,
Recordemos que un servicio de lectura se usa en muchas ms ocasiones.
O Servicio de mantenimiento para las altas, modificaciones y bajas.

El comportamiento es diferente si la arquitectura del servicio de agrupacin de
entidades es por servicios o por replicacin.

Veamos cada caso por separado partiendo de la base que el interpretador resuelve
todas las diferencias y en particular las equivalencias de claves.

7. Semntica CRUD en la arquitectura por servicios.

La operacin de lectura no presenta ms problemtica que decidir que se hace en
el caso de que parte de los atributos no se recupera. Siempre que pueda, mi
consejo es que acte por blanco o
negro, o todo o nada. Si eso no es
una opcin posible en el anlisis de
consistencia, deber marcar que
campos son vlidos y cuales no. No
coloque nunca los valores por defecto:
puede consumir a sus usuarios a
graves errores de operacin.

Una forma de implementar esta
opcin es aadir a la respuesta, en
caso de incompleta, un XML con los
campos vlidos. Observe lo que le
complica la gestin admitir
informacin parcialmente recuperada.
Hgalo solo si realmente lo necesita
en su anlisis de consistencia.

He elegido para el paralelismo de
acceso la solucin master-slave. En la
Punto de
entrada
D
Servicio
de origen
M
Acceso
Agregacin
de
resultados
Interpretador
Metaesquema
Punto de
salida

Figura 208. Lectura por servicios
296
prctica es la ms utilizada por los mecanismos multihilo.

En la figura de la derecha se muestra un esquema del posible diseo. Observe que
la las transformaciones las realiza el paso de agregacin de resultados a partir de
los datos que le proporciona el Interpretador que encapsula el metaesquema.

La semntica de la operacin de modificacin 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
modificacin.

Para el mensaje de actualizacin puede escogerse entre:

Enviar de nuevo todo el registro.
Enviar solo una lista con los valores modificados. En este caso una solucin
XML puede ser muy til.

Los procesos de alta y baja son muy parecidos por lo que creo que no necesitan
explicacin adicional.

8. Semntica CRUD en la arquitectura por replicacin.

En la arquitectura basada en replicacin 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 modificacin, el servicio de agrupacin de lectura
puede evitar la arquitectura interna master/slave y actuar con mecanismos SQL
convencionales.

Analicemos las otras
semnticas. En el proceso de
alta, despus de realizarla en
local, se anota en la cola del
sincronizador el nuevo registro.
El sincronizador se cuidar de
registrarlo sncronamente en la
central desde donde se
propagar la resto de las copias.
Recuerde una vez ms que
replicacin sncrona debe leerse
en el sentido de tan rpido
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 modificacin 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. Modificacin por servicios.
297
Esta espera
puede
resolverse
de varias
formas:

O El
servici
o de
agrupa
cin
ofrece
a la
central
un
servici
o de
actuali
zacin
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 peridicamente a buscarlos.

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

O Como un hilo ms del sincronizador.
O Como un agente independiente incluido en el servicio de agrupacin y que
trabaja con una de las filosofas anteriores.

En la figura se muestra una ampliacin de la arquitectura del servidor de
agrupacin por replicacin donde se usa un hilo para vigilar una cola donde la
central registra los cambios. Observe que en este caso la comunicacin de la
replicacin es por mensajes.

Las semnticas de modificacin y baja son parecidas y creo que no hace falta a
estas alturas que las tratemos especficamente.

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 lnea de otras que vemos en este libro.
O Utilizar el servicio de replicacin para recibir uno a uno los registros.

No hace falta decir que es ms eficiente la primera que solucin que puede usarse
tambin para implementar los procesos de auditoria y reconstruir rpidamente el
nodo. La ventaja de la segunda es que ya esta programa.

Servicio
de origen
P
S
Servidor de agrupacin
Registro de
los cambios
recibidos
desde el
exterior
M
D
S
Punto de
entrada
Entidades afectadas
Sincronizador
Gestin
a las
entidades
Acceso
Registro
de
cambios
M
Punto de
salida
Servicio
replicacin
origen

Figura 210. Servidor de agrupacin por replicacin ampliado
298
9. Implementacin utilizando los recursos del motor de la base de datos.

Pude utilizarse como parte de la solucin los mecanismos de replicacin
proporcionados por los motores de las bases de datos.

En general, realizan procedimientos de publicacin/suscripcin utilizando snapshot
como mecanismo de replicacin sncrona.

Si decide utilizar estos recursos deber consultar la documentacin de cada motor,
y si puede, a alguien con experiencia real en su uso.

Metodologa de Diseo Distribuido

1. Introduccin.

Ha llegado el gran momento! Vamos a encajar todos los conceptos y todas las
piezas presentadas hasta ahora en una metodologa integrada de diseo.

Como ya se explic en la primera parte hay dos formas bsicas de disear
aplicaciones distribuidas.

O Aplicaciones de Desarrollo Rpido
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 diseo de las aplicaciones
avanzadas. Recuerde que el mtodo a aplicar en las de tipo RAD supone,
bsicamente, eliminar o minimizar etapas.

Ya ha quedado claro a lo largo de los captulos 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 razn,
voy a usar en lo que sigue de forma genrica el trmino distribuido con
independencia de que la tcnica de implementacin sea una u otra.

2. Recordatorio de las Etapas de Diseo.

Para que las recuerde le propongo que consulte estos dos esquemas. Si no
recuerda alguna de las etapas, vuelva a repasar el captulo de la primera parte.

2. 1. Aplicaciones avanzadas.

Anlisis/Diseo funcional.
Diseo de la Arquitectura Distribuida
Diseo de Consistencia.
Diseo de la Administracin del Sistema.
Diseo Distribuido

Figura 211. Etapas de diseo de las aplicaciones avanzadas

2. 2. Aplicaciones RAD.

3. Metodologa Integrada de Diseo.

Las etapas del diseo distribuido se organizan en la metodologa integrada que se
muestra en la siguiente figura:
Anlisis/Diseo funcional.
Diseo de la Arquitectura Distribuida
(nulo en RAD).
Diseo de Consistencia.
Diseo de la Administracin del Sistema
(mnimo en RAD).
Diseo Distribuido

Figura 212. Etapas de diseo de aplicaciones RAD
Diseo
Funcional
Diseo de la
Arquitectura distribuida
Anlisis de los
Datos
Distribucin del
Proceso Aplicacin
Crear Arquitectura
de servicios
Map to reality
Diseo
Administracin
Diseo Distribuido
Diseo de
Consistencia
Metodologa Puzzle
Especificacin
servicios
Especificacin
resto piezas
Plan de
Integracin
Plan Estratgico
Distribuido de la
Compaa
Completar Diseo
de los clientes
Integracin
funcional
Lgica presentacin
y/o flujo de procesos
Lgicas de
proceso y datos
Especificacin
piezas cliente
Ampliar el cuadro
control admistracin
Disear el cuadro
control del negocio
Diseo
Tecnolgico
Identificacin fronteras
Precondiciones de
Plataforma
Identificacin de puntos
de heterogeneidad

Figura 213. Metodologa Integrada de Diseo Distribuido.

A continuacin detallaremos el contenido de cada una de las etapas. Observe, sin
embargo, que como ya se ha dicho anteriormente, la etapa de diseo es una etapa
del diseo tecnolgico que se intercala entre el funcional y/o el tecnolgico y la
etapa de programacin convencional.

Y observe tambin la utilizacin del Plan Estratgico Distribuido de la Compaa
como documento de consulta, y obligaciones a cumplir, que en todo momento ha de
estar presente en el momento de tomar decisiones. Su situacin en la figura
superior a la entrada del proceso entre el diseo funcional y el diseo distribuido
alude a ese rol.

4. Contenido de cada una de las etapas.

4. 1. Anlisis Funcional /Especificacin Diseo de la arquitectura del
tecnolgico.

El anlisis tecnolgico o especificacin establece las prestaciones funcionales
bsicas que se piden al Sistema de Informacin que se va a crear. Recuerde
que se ha de hacer sin pensar que despus la arquitectura ser
distribuida.

Si la aplicacin es de desarrollo rpido, este paso proporciona habitualmente
todo lo necesario para la etapa de desarrollo tecnolgico. En este tipo de
aplicaciones, adems, lo normal es que no haya etapa de diseo tecnolgico
convencional.

SI la aplicacin distribuida que se va a construir es un modelo avanzado
existir una etapa de diseo tecnolgico para construir la arquitectura del
sistema de software. Tras ella se iniciar la etapa de diseo distribuido.

Como ya he remarcado, por una u otra va, los resultados de estas etapas
previas proporcionan siempre:

La descripcin de los datos, contenido, relaciones y estructura.
Procesos de transformacin de la informacin.
Integraciones de ejecucin que tienen en cuenta roles, circuitos, etc.

Las diferentes metodologas se diferencian en el mtodo, las herramientas y la
forma en que reflejan esos contenidos, pero todas dan como mnimo esa
informacin. La metodologa de diseo distribuido se basar en ellos.

Para simplificar la notacin de los ejemplos y centrarnos en los conceptos de
diseo distribuido, en los ejemplos que acompaan a las exposiciones
usaremos MAFDRA, el mtodo de diseo funcional RDA presentado
anteriormente.

4. 2. Determinacin de las precondiciones de la plataforma.

4.2.1. Identificacin de las fronteras.

Estudiando la infraestructura de la plataforma distribuida, la
identificacin de las fronteras realizar en las siguientes etapas.

1. Incluir, si ha lugar el incremento de plataforma que supondr la
nueva aplicacin.
2. A partir de los niveles lgicos 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 localizacin de todos los nodos sobre la
plataforma.
5. Identificar las fronteras. Si una misma funcin 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 diseo.

4.2.2. Determinacin de los puntos de heterogeneidad.

A partir del Plan Estratgico de la Compaa averiguaremos que puntos
de heterogeneidad hay que considerar en la diseo que empezamos a
desarrollar.

Esta fase puede impulsar una primera actuacin si se detecta que
alguno de estos puntos puede y debe ser resuelto con aumento de la
plataforma: se prever eliminarlo, se planificar la inversin y el timming
y se actuar en el diseo como si ya estuviera resuelto.

Para evitar contratiempos se incluir en el anlisis de riesgos el
seguimiento de este punto.

4. 3. Diseo de la Arquitectura Distribuida.

Partiendo del anlisis funcional, el diseo 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. Anlisis 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 funcin de los criterios aplicables a los datos se decide el modelo
que ms conviene al sistema distribuido. La arquitectura de datos se
construye combinando los modelos de datos entre los presentados
en los captulos dedicados a los datos.

4.3.1.B. La lgica de datos del sistema distribuido.

Encapsulan la lgica de datos que se decide implementar en
servidores convencionales o en procedimientos catalogados.

4.3.2. Distribucin del Proceso de la Aplicacin.

Se distribuye la funcionalidad de los procesos en el sistema distribuido
identificando los servicios de proceso.

En un captulo posterior repasaremos los criterios para identificar y
separar los servicios.

4.3.3. Creacin de la Arquitectura de Servicios.

Una vez identificados los servicios, se crea la arquitectura de servicios
aadiendo:

4.3.3.A. El modelo de comunicacin.

De cada servicio con sus clientes,

4.3.3.B. El formato del mensaje.

Especificacin y cabecera del mensaje de comunicacin o del fichero
XML involucrado.

4.3.3.C. Las dependencias entre servicios.

Cuando uno o ms servicios utilizan a su vez otros servicios, habr
que elegir como se establece esa dependencia.

En principio, la relacin entre dos servidores es, por defecto, la
delegacin de servicio. Y con un agente el traspaso de
responsabilidad. Pero recuerde que hay otras formas de establecer
esas dependencias. Ms adelante recordaremos los criterios para
elegir la ms conveniente.

4.3.3.D. Modo de ejecucin y de arranque.

Aunque el modo de ejecucin habitual de un servidor es continuado y
la forma de arrancarlo esttica, recuerde que un servidor puede
arrancarse dinmicamente a peticin y ejecutarse temporalmente.

4.3.4. Map to reality.

No he conseguido nunca una traduccin clara al castellano tan grfica
como el trmino ingls. Por lo tanto voy a seguir utilizndolo. La funcin
bsica de esta etapa es comprobar si el modelo de arquitectura
distribuida es tcnicamente viable en la plataforma de sistema prevista y
si el rendimiento estar dentro de los parmetros deseados.

Puede sorprender que esta etapa, ms propia del final de la aplicacin
que del diseo, haya de adelantarse. No debera 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 localizacin de los servicios sobre la plataforma lgica,
que como ya sabemos, lleva implcita una plataforma fsica.

Hacerlo as, permitir identificar con tiempo suficiente problemas del
estilo de:

Demasiada carga para un nodo: la mquina puede no tener
suficiente capacidad de proceso, memoria, disco, etc.
Demasiado trfico de lneas que dificulta alcanzar los tiempos de
repuesta necesarios.
Necesidad de localizar servicios en puntos de la arquitectura de
niveles fsicos en los que no hay nivel lgico asociado.
Etc.

Y tomar decisiones para solucionar los problemas detectados. Las
decisiones pueden ser tres tipos:

Ampliaciones de la plataforma, decidiendo, por ejemplo, cambiar
una mquina servidora de un nodo por otra ms potente.
Modificacin de la plataforma lgica, aadiendo, por ejemplo,
administracin de sistema a un nivel fsico y incorporando as un
nuevo nodo a un nivel lgico o incluso creando un nivel lgico
totalmente nuevo.
Modificacin del diseo, modificando la arquitectura de datos o de
servicios creada. Cuando se elige esta solucin, se justifica el
bucle que habr observado dentro de la casilla de arquitectura
distribuida en el esquema de la metodologa de diseo integrada
presentada antes. Pero no se engae, si tiene que dar ms de una
segunda vuelta (dos en raras ocasiones), revise su solucin,
probablemente hay algn punto en que ha tomado decisiones
equivocadas. Busque donde. Pero no caiga en el otro extremo: la
solucin fcil, ampliar la plataforma, no siempre es la buena en
prestaciones / coste. As, por ejemplo, para resolver la cogestin de
un nodo la mejor solucin puede no ser una ampliacin del nodo
sino arrancar parte de los servicios a peticin; 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. Diseo de consistencia.

Aade resistencia contra errores y cadas y establece los procesos automticos
de recuperacin y como hay que trabajar (si es necesario) cuando algunos de
los servicios no estn disponibles. Esta situacin de trabajo bajo servicios
cados la denominar trabajo en situacin de emergencia pero en su visa
profesional llmela trabajo off line es menos dramtico y ms 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 diseo de la consistencia supone definir procesos especficos para
gestionarlo. Estos procesos de control han de aadirse a los ya construidos lo
que supone volver a la etapa de diseo de la arquitectura distribuida. Este
hecho justifica la flecha que vuelve en el esquema de la metodologa de diseo
integrada de la casilla de la consistencia a la de arquitectura distribuida.

Normalmente el proceso es limpio ya que supone cambios mnimos o
inexistentes en la arquitectura construida. Y en ningn caso debe suponer
hacer ms de una nueva vuelta al bucle de diseo de la arquitectura distribuida.

4. 5. Diseo de la administracin del sistema.

Aade las funciones de administracin para ayudar al Administrador de
Sistema a gestionarlo de forma distribuida.

Se focaliza a travs del cuadro centralizado de control y gestin que se
presentar ms adelante.

La introduccin a esta parte del diseo ya se ha realizado en la primera parte
del este libro al introducir la administracin del sistema distribuido. Repselo
all si no lo recuerda ahora.

Recuerde, sin embargo, que esta etapa del diseo proporciona las polticas de
administracin. Si las herramientas de Middleware no aportan toda la
funcionalidad necesaria, esta etapa del diseo complementar esas funciones
de Middleware con herramientas creadas especficamente. Dada la naturaleza
de esas nuevas herramientas, lo ms probable es que queden disponibles para
aplicaciones posteriores como nuevos elementos del Middleware, el de usuario
en este caso.

Recuerde tambin que diseo tecnolgico debe asegurar y verificar la
seguridad y que para que un sistema sea seguro debe garantizar las
siguientes caractersticas:

Identificar a los usuarios.
Autentificarlos.
Controlar el acceso a todos los recursos.
Anotar dinmicamente 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 aadidas por el anlisis de
administracin dentro del sistema distribuido.

4. 6. Identificacin y especificacin de piezas.

Despus de realizar las etapas de diseo especficas del sistema distribuido, la
aplicacin de la metodologa Puzzle permitir identificar piezas que se aadirn
a las obtenidas en la etapa de diseo tecnolgico convencional y preparar la
implementacin del sistema distribuido como un conjunto integrado de todas
las piezas.

Se identificarn dos tipos de piezas:

Piezas ya construidas que se reutilizarn.
Nuevas piezas que habr que construir y decidir, con criterios de coste, si
se dejan reutilizables o simplemente ligadas a la aplicacin. En las
organizaciones en que exista, esas piezas debern someterse al Comit
de Reusabilidad.

Es difcil marcar criterios genricos a esta etapa. Hay, sin embargo, algunos
que s conviene seguir:

Los servidores sern siempre piezas que se encapsularn junto con
un mecanismo de llamada. Ya hemos hablado en otros momentos de la
gran ventaja que esto supone para la adaptabilidad de la aplicacin y
para la minimizacin de los efectos de los errores del diseo.
Las piezas aportadas por las etapas de administracin acostumbran a ser
piezas de alto nivel de Middleware de Usuario.
Todas las piezas nuevas debern especificarse mediante su contrato de
software tal como se ha explicado en el captulo correspondiente. Las
piezas a comprar debern iniciar el proceso de adquisicin de cada
compaa. Recuerde la importancia de la certificacin del contrato de
software tanto de las construidas como de las compradas.

4. 7. Diseo de los Clientes.

Una vez separados e identificados los servicios, el resto de las piezas se han
de disear e integrar en programas clientes.

Disear un programa cliente ya es un trabajo convencional. Para integrar las
funciones cliente en programas hay diversas posibilidades o modelos de
integracin.

Aunque la integracin grfica, GUI o Internet, es, de largo, la ms utilizada,
recuerde que no es la nica y que un buen diseador elegir la que ms le
convenga.

Los procesos de negocio resultantes se habrn de introducir en el cuadro de
control del sistema distribuido y en el cuadro de control del negocio que
presentaremos ms delante.

Finalmente, remarcar que en la parte cliente es tambin muy recomendable
utilizar metodologa Puzzle. Ello supondr la identificacin y especificacin de
un nuevo bloque de piezas a construir o comprar.

A nivel cliente es normal la aparicin de piezas de alto nivel tipo Framework
que modelan un comportamiento. Utilizar aqu OO como herramienta de
implementacin puede aumentar espectacularmente la reutilizacin.

Y recuerde que en aplicaciones RAD, que son muy fat client, trabajar bien
supone tambin reutilizar.

4. 8. Plan de Integracin.

Ya hemos hablado anteriormente de que la fase de integracin, posterior a la
certificacin de piezas y prueba de los programas, es fundamental y crtica en
los sistemas distribuidos. Ese plan de integracin es fundamental cuando la
aplicacin aporte servicios de nueva fabricacin, de los que habr que probar
cuidadosamente y productos de Middleware de Usuario para sistemas
heterogneos en los que habr que verificar el comportamiento.

Es muy necesario pues, pues, que el diseador piense y planifique
cuidadosamente cual ha de ser el plan de integracin y lo formalice en un
documento.

El plan de integracin 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 reaccin 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.
Localizacin.
Fallos a provocar.
Procesos de administracin de las piezas a verificar.
Dependencias entre las piezas, o servicios, a verificar.

Diseo de la Arquitectura Distribuida de
Servicios

1. Introduccin.

En este captulo y en los siguientes vamos a describir detalladamente cada una de
las etapas de la metodologa general integrada presentada en el anterior.

El contenido de este captulo es una aplicacin sistemtica e integrada de todo
aquello que se ha presentado anteriormente y que tiene influencia en el diseo de
la arquitectura distribuida. Por ello, todos los temas bsicos sobre modelos de
comunicacin, peticin / respuesta, arquitectura de servidores, modelos de datos y
procesos, etc..., se usarn directamente y por esa razn hay que recordarlos en
todo momento!

2. Etapas del Diseo de la Arquitectura de servicios del Sistema
Distribuido.

El detalle de las etapas de esta fase del diseo se muestran en la figura siguiente
donde se detallan las etapas presentadas en la metodologa general.

Vamos a hablar con detalle de cada una de estas etapas.

3. Anlisis de los datos

La identificacin y separacin 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 lgicos
Separar funciones
entre clientes y
servidores
Identificar servicios
Distribucin del
Proceso de la
Aplicacin
Definir comunicacin
cliente-servidor.
Definir arquitectura
servicios.
Definir arquitectura
cliente/servidor
Analizar
Crear la
Arquitectura
Distribuida
Localizacin
Configuracin
Analizar rendimiento
Map to Reality
Anlisis
Funcional
Completar
el Diseo
Arquitectura
de datos
Adaptar
diseo
funcional
Diseo lgica
de datos
Especificar
Analizar
rendimiento
Anlisis de
Datos
Anlisis
Tecnolgico

Figura 214. Etapas del Diseo de la Arquitectura Distribuida
sistema distribuido es tan condicionante que conviene hacer en primer lugar la
identificacin de los servidores de datos.

A grandes rasgos esta etapa, a partir del modelo de datos y de los
condicionamientos de implementacin del sistema distribuido, escoger en modelo
de datos distribuido ms adecuado plasmndolo en una Arquitectura de Datos
Distribuidos, adaptar el Diseo Funcional con los nuevos procesos resultantes,
identificar los servidores de lgica de datos necesarios para gestionar
correctamente el sistema distribuido, plasmndola en una Lgica 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
diseo de datos y posteriormente una evaluacin de rendimiento que puede llevar a
aceptar el modelo o ha modificarlo en una segunda vuelta.

Comentemos a continuacin, y con detalle, cada una de las etapas.

3. 1. Prerrequisitos.

El anlisis funcional y el plan estratgico establecen (o al menos deberan
hacerlo!) una serie de prerrequisitos que van ha tener una importancia bsica a
la hora de tomar decisiones.

3.1.1. Puntos de heterogeneidad.

A lo largo de los captulos anteriores hemos ido encontrando y
relacionando diversas causas que generan puntos de heterogeneidad.
En particular hay tres que conviene remarcar:

Localizacin
Modelizacin
Analizar Rendimiento
Anlisis
Funcional /
Tecnolgico
Arquitectura de Datos - Valorar y Decidir
Identificacin
del resto de
Servidores
Modelo, esquema acceso
Piezas, servidores y procedimientos catalogados
Especificar la Arquitectura de Datos
Localizacin obligada
Aplicar criterios y escoger la Arquitectura Distribuida
Diseo Arquitectura de Datos Distribuida
Decidir el modo de acceso entre accesos directos SQL y
encapsulamiento de la lgica de datos.
Identificar servicios de agrupacin de datos.
Identificar patrones DTO.
Elegir modelo encapsulamiento (ex: pr.catalogados)
Establecer la arquitectura de servidores de datos.
Identificar posibles arquitecturas de pre-condicin
Diseo de la Lgica de Datos Distribuida
Localizacin del mantenimiento y codificacin distrb.
Criterios de auditoria
Mantenimiento y Auditoria
Aadir nuevas funciones datos
Adaptar Diseo Funcional
Puntos de
acceso
heterogneo
Niveles lgicos
Tamao,
accesibilidad y
volatilidad
Tiempos de
respuesta
necesarios
Localizacin de
los puntos de
mantenimiento
Codificacin Dis.
Pre-requisitos

Figura 215. Etapas del Anlisis de los datos
3.1.1.A. Conexiones lentas.

Entenderemos por conexiones lentas, tanto la velocidad como la
necesidad de levantar la lnea. Normalmente ocurre en conexiones
remotas. Condicionan costes de comunicaciones (cada vez menos) y
tiempos de respuesta. En general son generadores de arquitecturas
de replicacin.

3.1.1.B. Diferencias semnticas y sintcticas entre entidades.

En general se resuelven con un metaesquema que conduce a
piezas, servidores independientes o no, que encapsulan la lgica 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 lgica de datos.

3.1.2. Niveles Lgicos.

De la arquitectura fsica, que condiciona los puntos de localizacin de
los datos por la existencia en ellos de servicios de administracin,
copias entre otros. De hecho, este prerrequisito no viene del funcional
sino del plan informtico de la compaa.

3.1.3. Factores de gestin y proceso.

Tratados ampliamente al hablar de la replicacin. Se enumeran en este
grupo factores del tipo:

Tamao de los datos.
Actividad o nmero de accesos.
Volatilidad versus estabilidad, en referencia al nmero de cambios.
Servicios de administracin disponibles.
Etc.

Repase en aquel captulo las implicaciones de cada uno de los factores
si no las recuerda.

La idea es muy clara: revisar la lista en cada diseo y comprobar, en
ese diseo, las implicaciones de cada uno de los factores.

3.1.4. Tiempos de respuesta admisibles.

3.1.5. Codificacin distribuida.

Repasar el captulo anterior dedicado a este tema.

3. 2. Diseo de los Datos.

Esta etapa tiene como objetivo valorar todos los condicionantes funcionales y
tecnolgicos recogidos, aplicar los criterios tericos y decidir la arquitectura de
los datos y de su lgica de tratamiento.

Se organiza en cinco subetapas.

3.2.1. Diseo de la Arquitectura de Datos Distribuida.

Se deber proponer la arquitectura de datos distribuidos eligiendo la
combinacin de modelos de datos que ms convengan a la aplicacin
que se est diseando.

Los modelos y criterios ya se han visto anteriormente. No voy a caer
aqu en el error de repetirlos. Repase en esos captulos, consulte la
agrupacin de criterios que le presento en el apartado siguiente y
aplquelos aqu.

Solo recordar que, adems resolver el problema planteado, se deben
conseguir los costes mnimos de administracin y comunicaciones que
garanticen los tiempos de respuesta necesarios.

3.2.2. Mantenimiento y auditoria.

Aunque es un parte de la adaptacin del diseo funcional, la
importancia que este tema tiene dentro de la identificacin de servicios
de datos, hace necesario realizar de forma especfica la reflexin sobre
estos dos temas, que en el fondo, no son ms 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 codificacin distribuida.

3.2.2.C. Definir la poltica de auditoria.

Permitir conocer como hay que controlar la propagacin de los
cambios y como se auditarn peridicamente. Todo ello se reflejar
en las polticas de seguridad e integridad.

3.2.3. Adaptar el Diseo Funcional.

En funcin de los resultados obtenidos en el diseo de la arquitectura
de datos distribuida y de la implementacin de esa arquitectura
resultante, se habr de modificar el anlisis funcional para adaptarlo al
modelo escogido, incluyendo los procesos necesarios para gestionarlo.

3.2.4. Diseo de la Lgica de Datos Distribuida.

Esta etapa puede hacerse ahora o retrasarla a la identificacin de los
servidores de procesos. Por coherencia de exposicin voy a
desarrollarla aqu.

3.2.4.A. Decidir el modo de acceso.

Habr que decidir que accesos se hacen por SQL directo y cuales se
encapsulan en la lgica de datos. Esto permitir identificar servicios
de datos que despus habr linkar en fase de programacin o
implementar con servidores convencionales, servidores SQL o
procedimientos catalogados.

Le aconsejo que cmo criterio general, encapsule todos los accesos
en piezas. Estas piezas podrn linkarse o independizarse en
servidores segn otros criterios que ya hemos visto anteriormente.
Recordemos algunos.

La localizacin obligada condicionar los procesos. Si hay accesos
desde entornos cliente situados fuera de la localizacin se habrn de
gestionar por servidores localizados sobre la zona de la base de
datos.

Si la lgica de datos integra ms de una entidad (por ejemplo, los
datos descriptivos de cliente y su crdito), 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 mquinas no locales que es lo
normal, defnalos 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 anlisis de consistencia (las consultas en general no
lo necesitan).
Facilitar la programacin del paralelismo, fcil en los servicios de
consulta, estadsticamente muchsimo ms utilizados que los de
mantenimiento.

Recuerde otros criterios ya aparecidos:

Reglas de negocio fijas, priman modelo esttico.
Seguridad alta priman modelos dinmicos.
Replicaciones sncronas fuerzan a servidores.

Y finalmente, que en todo momento se ha de garantizar la coherencia
y la integridad de los datos y recuerde la importancia que en este
tema tiene el uso de tickets.

3.2.4.B. Identificar los servicios de agrupacin de datos.

Ya hemos hablado de este tema en el capitulo correspondiente. Si no
los recuerda, repselo.

3.2.4.C. Identificar los patrones DTO.

A partir de las fronteras, decida cuando aplicarlos. Siempre que
pueda, hgalo.

3.2.4.D. Escoger el modo de encapsulamiento.

Una vez identificados los servicios de lgica 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 delegacin de servicio.

Ms adelante se recordarn los criterios para decidir las
arquitecturas entre servidores. En el caso de datos, existe uno de
especfico 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
delegacin por otros servidores de datos.

3.2.4.F. Identificar posibles arquitecturas de precondicin.

Aunque la precondicin es una forma ms de arquitectura, dada su
importancia conviene identificarlas de forma precisa e
individualizada. Decida como implementa la precondicin,
escogiendo siempre que pueda la solucin por colas.

La implementacin de precondiciones obliga a implementar los
servicios de datos con servidores convencionales.

3.2.5. Especificar la Arquitectura y la Lgica de los Datos.

Finalmente habr que especificar y documentar la arquitectura de datos
distribuida en sus dos componentes.

3.2.5.A. Modelo distribuido y esquema acceso.

Para documentar el modelo se incluirn 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
replicacin y auditoria, si los hay, y los criterios de codificacin
distribuida.

Los planes se completarn tras el anlisis de administracin.

3.2.5.C. Piezas, servidores, procedimientos catalogados y servidores de
SQL.

Se utilizarn los recursos normales de la instalacin para especificar
piezas. En la descripcin habr que incluir de forma clara y precisa
que lgica 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
aplicacin distribuida hay que analizar el rendimiento de la solucin escogida.
El tema es fundamental antes de seguir con las otras etapas del diseo
distribuido.

Para realizar este anlisis la mejor referencia es evaluar los tiempos de
respuesta para confirmar que estn dentro de los parmetros previstos y hacer
una evaluacin de los costes de comunicacin, si hay conexiones remotas
claro est.

Realizar este estudio en este momento del diseo no es ninguna tontera.
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 evaluacin de rendimientos reales.

Una vez cargado el modelo, hay dos soluciones para evaluar el rendimiento:

Implementar una maqueta de la lgica de datos en que solo se evalen
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 garanta del rendimiento esperado.

Y por favor, pruebe siempre con la situacin de la plataforma ms
desfavorable. Un consejo, conserve mquinas obsoletas para implementar los
modelos de evaluacin de rendimiento. La razn en obvia, as cualquier
situacin real ser ms favorable a la de la prueba.

Los resultados pueden obligar a retocar el modelo de datos inicialmente
previsto. En casos de problemas, se hace difcil tipificar las correcciones a
realizar, aunque hay soluciones clsicas para mejorar el rendimiento:

Cambiar por mquinas ms potentes los servidores de las bases de
datos. La experiencia dicta que difcilmente va a conseguir mejoras
substanciales de rendimiento con ampliaciones de las mquinas
actuales.
Definir claves secundarias para habilitar vas rpidas de acceso. Ojo!, no
introduzca claves secundarias innecesariamente, relantiza los procesos
de alta y modificacin. El criterio es ponerlas siempre, qu sea
realmente necesario! Y el realmente necesario solo lo puede marcar
una evaluacin prctica del rendimiento.
Incluir en el modelo de datos distribuido replicacin, en muchos casos de
sumarizacin.
Sustituir lgica 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 diseo de anlisis de datos; de ah la flecha de retorno
que observar en la figura del esquema general de diseo de los datos.

4. Criterios para disear la arquitectura de datos.

Tenga en todo momento presente las fronteras que ha decidido establecer en el

Conviene marcar dos pasos:

4. 1. Localizacin Obligada.

Localice primero aquellas entidades en la que no pueda elegir por estar
localizadas como precondicin, tanto fsica como de proceso o
condicionamiento organizativo. Vigile en cualquier caso, que una aparente
localizacin obligada no pueda, en una diseo concreto, ser mejorada con otro
modelo de replicacin o particionado.

4. 2. Criterios funcionales.

Se habr de resolver a continuacin, para el problema concreto que estemos
diseado, el problema clsico: los datos han de estar lo ms cerca posible de
los usuarios, impulso hacia arquitectura distribuida, versus facilidad de
administracin y mantenimiento, impulso hacia la centralizacin.

Recuerde que para decidir la localizacin deber respetar los niveles lgicos de
la compaa y que la arquitectura resultante ser, normalmente, una
combinacin de ms de un modelo de datos.

Aunque ya he comentado antes que no voy a repetir la lista de criterios, existen
unos criterios genricos utilizables a modo de plantilla. Se agrupan en dos
grandes bloques:

4.2.1. Criterios independientes de la optimizacin del rendimiento a la
plataforma.

Son criterios que pueden aplicarse sin considerar las caractersticas de
la plataforma fsica.

4.2.1.A. Por las caractersticas de la aplicacin.

Si tiene datos de mantenimiento centralizado y conexiones
rpidas podr decidirse por modelos centralizados.
Si tiene mantenimiento centralizado y conexiones lentas o
nmadas, habr de replicar y decidir todos los factores de la
poltica de replicacin (repselos).
Si tiene mantenimiento descentralizado podr decidirse por
modelos distribuidos, horizontal o verticalmente.

4.2.1.B. Por la tipologa 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 tamao medio y pequeo en el servidor de red
departamental, si ste es un nudo lgico, y en el nivel inferior
si el servidor departamental no es ms que nodo fsico.
De gran volumen y/o con requerimientos estrictos de
seguridad, dentro del HOST o en servidores
departamentales especializados, que en muchas ocasiones,
sirven a ms 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 tamao y/o estrictos
requerimientos de seguridad dentro del servidor corporativo,
localizado muchas veces en un HOST, y bajo un modelo
centralizado.
De tamao 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
replicacin sncrona 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 nmadas

Aqu hay que tener presente tambin los casos de usuarios
nmadas. Este tema afecta tanto a datos como procesos y, por
tanto, puede desarrollarse aqu o all. He preferido hacerlo en el
apartado de procesos.

4.2.1.C. Mantener los datos ms usados en zonas de rpido
acceso.

Hay dos posibilidades bsicas de conseguir almacenamientos de
acceso rpido:

Localizndolos lo ms cerca posible de los usuarios:
utilizando tcnicas de replicacin o particionado de los datos.
Utilizar tcnicas cash.

4.2.1.D. Agrupar datos afines en la misma localizacin.

Criterio aplicable en modelos particionados y en menor medida en
replicacin.

4.2.1.E. Emplear al mximo tcnicas 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 localizacin de la base de
datos. En la prctica se disea como un caso particular del anterior.

4.2.1.G. Utilizar empaquetamiento.

4.2.2. Criterios dependientes de la optimizacin del rendimiento a la
plataforma.

Son criterios que pueden aplicarse para optimizar el rendimiento en
funcin de las caractersticas de la infraestructura y la localizacin.
Tienen el inconveniente que estn afectados por los cambios en estos
dos componentes. Sin embargo, en la prctica, los cambios en la
infraestructura son para mejor y los cambios en las localizaciones de
datos son muy poco frecuentes.

4.2.2.A. Adaptacin 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 localizacin de los
datos.

Imagine que tiene que obtener los datos bsicos 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 estn en una
segunda base de datos en el nodo B. Puede establecer una
arquitectura en que el cliente pida el servicio a un servido en A que
obtenga los datos del cliente en A y delegue a otro servidor en B
obtener los pedidos.

4.2.2.C. Minimizar la lactancia.

Normalmente, el tamao 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 gestin 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 lgico de la base de datos?

Es un muy interesante dilema con defensores en cada una de las dos posturas.

La implementacin de las restricciones por la base de datos obliga a romper esas
restricciones antes de muchos procesos.

Hacerlo desde los programas facilita la programacin pero deja la responsabilidad a
la aplicacin.

Me pide opinin? Ponga las restricciones en la base de datos aunque eso le
produzca algn problema ms de programacin.

La necesidad de soluciones robustas en un tema tal vital y difcil como los datos
justifican el uso de cualquier mecanismo que ayude a garantizarlos.

6. Distribucin del Proceso de la Aplicacin.

Una vez realizado el anlisis de los datos, puede iniciarse el anlisis de los
procesos en el sistema distribuido.

Notar que algunas de las etapas que aqu se citarn ya se han explicado en el
apartado anterior ya que los datos llevan a la identificacin de servidores de lgica
de datos, procesos al fin de cuentas. Procurar no repetirme, citando nicamente
en secuencia las etapas coincidentes.

En los captulos de introduccin ya se habl cual va ha ser la base de la estrategia:

O Identificar funciones, obtenida en las etapas de anlisis y diseo tecnolgico.
O Distribuirlas identificando servicios.
O Integrarlas.
O Organizar la explotacin.

De las dos primeras etapas se cuida esta fase de Distribucin de la Proceso de la
Aplicacin (Balancing Aplication Processing). De las dos ltimas se cuida la
etapa de diseo siguiente dedicada a montar la arquitectura distribuida integrando
los servicios con los clientes.

El primer paso para crear la arquitectura distribuida es decidir, llanamente
hablando, que hacen los servidores y que hacen los clientes. En este momento hay
que recordar todos lo que le he ido presentando hasta aqu sobre este tema y que
en este apartado nos limitaremos a relacionar.

En particular cabe recordar en primer lugar la distribucin de funcionalidad fat
server o fat client que marca un criterio bsico: la aplicacin 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

6. 1. Identificar Funciones.

Se realiza dentro de funcional / especificacin y/o el diseo tecnolgico y son,
por tanto, precondiciones en esta fase del diseo. En mi metodologa se
reflejar en diagramas de flujo secuencializados o herramientas que den
informacin equivalente.

6. 2. Distribuirlas por Niveles Lgicos.

Las funciones habrn de distribuirse por niveles lgicos. Esta distribucin se
har en dos fases:

Una inicial por localizaciones obligadas. Por ejemplo:
La existencia de un proceso especifico de un punto de la
organizacin.
Servicios reutilizados.
Servicios comprados
Una posterior a la identificacin de servidores y dentro del map to
reality. Prime siempre que pueda esta segunda opcin que pueden usar
prcticamente siempre en los sistemas distribuidos modernos y que no le
pone ningn impedimento a la localizacin.

6. 3. Separar funciones entre clientes y servidores.

Los criterios para distribuir funciones se han ido trabajando a lo largo de los
captulos anteriores. Vamos a realizar aqu una relacin clasificada de los ms
importantes.

Recuerde adems que:

La mayora de los criterios de este apartado depende de cada aplicacin
y son difciles de generalizar de forma abstracta.
Pocos de estos criterios son de blanco o negro: la mayora son tonos
grises que habr que analizar contra las necesidades y
condicionamientos de nuestra aplicacin antes de tomar una decisin.
Si utiliza la tcnica 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 valoracin de esos
criterios, podrn modificarse sin cambios importantes.

6.3.1. Por la localizacin de las clases y las instancias de los objetos.

Este bloque solo tiene sentido en modelos avanzados analizados
funcionalmente por Orientacin a Objetos. Al tener los objetos atributos
(datos) y mtodos (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 metodologa de
anlisis funcional hubiera sido convencional.

6.3.2. Por la tipologa 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 comunicacin
asncrona 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 filosofa de servicio, la alternativa son clientes back-ground o
darles categora de servicios y asignarlas a agentes.

Son tareas intensivas en tiempo que se localizan siempre en cliente:

La gestin de dibujo grfico.
Ordenaciones.
Las bsquedas en tablas grandes.
Interpretacin de reglas de negocio.
Preparacin y postratamiento de querys.
Proceso de texto.
Anlisis estadstico.
Etc.

Son tareas que, aunque intensivas en tiempo, pueden distribuirse por
otros criterios:

Compresin y descompresin por software. Si el algoritmo es un
siempre el mismo, la pieza se linka en el cliente. Si el algoritmo
puede variar dinmicamente, prime los servidores.
Encriptacin y desencriptacin por software. Vale lo mismo del
punto anterior.
Captura Multimedia. Sirve lo mismo de los dos apartados
anteriores. Recuerde que si hay delegacin de servicio, es una
delegacin potencial de arquitectura de filtro entre los servidores
afectados.

Hay funciones propias del cliente y funciones para compartir entre
clientes y servidores.

Son funciones propias del cliente:

La lgica de presentacin.
Dilogo con los usuarios.
Validaciones de las entradas.
Ayudas en lnea.
Dilogo de la gestin de errores.
Etc.

Son funciones a repartir entre clientes y servidores:

La lgica de proceso especfica de la aplicacin.
La gestin y recuperacin de errores, aunque en general, el cliente
lleva la iniciativa de la gestin y el servidor de la recuperacin.
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
comunicacin conversacional.
Los recursos fsicos de localizacin obligada han de tratarse
siempre por servidores. Por ejemplo, una placa de encriptacin por
hardware, que al ser caras, son piezas singulares en los nodos del
esquema de niveles lgico.

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

Pueden ser muy variados y de difcil clasificacin. Son buenos ejemplos:

La localizacin operativa. Por ejemplo, la gestin de riesgo de un
cliente se suele llevar centralizada lo que obliga de definir un
servidor de riesgo localizado en el nodo lgico del Dpto. que lo
gestiona.
Polticas de administracin del sistema. Por ejemplo, la compaa
no desea administracin en un nodo lgico.
Condicionantes de proveedores y clientes.
Etc.

6.3.7. Por la administracin del sistema.

Como se cita en el apartado anterior, dentro de los criterios de
organizacin hay parte de los criterios para la administracin del
sistema: aquellos que marca la poltica de administracin de la
compaa.

Dentro de este bloque pueden incluirse:

Jerarqua de la administracin establecida para la compaa.
Propagacin de los cambios (datos y programas) por el sistema
distribuido.
Diseo y control de la administracin remota.
Definicin de la poltica y los parmetros de seguridad.
Etc.

El tema se tratar especficamente y a fondo dentro de los captulos
dedicados a la administracin del sistema. Sin embargo, en diseadores
expertos, aqu se suele adelantar mucho trabajo.

6.3.8. Usuarios remotos y nmadas.

La presencia de usuarios remotos donde las velocidades de transmisin
son lentas aporta otro bloque de criterios. Adems, el tema de los
nmadas aporta en muchas ocasiones la no disponibilidad de conexin
en periodos normales de trabajo.

Aunque de este tema ya hemos hablado, conviene relacionar aqu
brevemente las soluciones y precondicionamientos aportados por esta
situacin:

Utilizacin de replicacin de datos.
Uso de comunicaciones asncronas para utilizar los tiempos
muertos en los programas cliente. Ello obliga a servidores en las
dos bandas y modelos de comunicacin por colas.
Las conexiones sncronas y el particular el RPC quedan
penalizadas.
Esquemas de conexin, peticin de servicio, obtencin de la
respuesta y desconexin para minimizar el coste de las
comunicaciones. Este ciclo hace la conexin todava ms lenta
potenciando todava ms la comunicacin asncrona.
Utilizacin exhaustiva de procedimientos catalogados en la
implementacin de los servicios de la lgica 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 conexin 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 comunicacin asncrona desacoplada

Hay una arquitectura de servidores prcticamente obligada cuando
existe una conexin lenta y se quiere aprovechar el tiempo de la
llamada asncrona para hacer proceso en el programa cliente, es decir,
un modelo de trabajo asncrono. Razonmosla.

Si se realiza la llamada a travs, por ejemplo de colas, el criterio es
localizar la cola en el lado del servidor. Si se hace as la conexin del
cliente con la cola ser lenta (solucin 1 en la figura).

Si el cliente ha de repetir ms de una vez la pregunta a la cola para
saber si ya tiene el servicio disponible ser ms eficiente que el cliente
hable con una cola local y que un servidor para Pasar la Peticin se
encargue del dilogo con la cola remota (solucin 2 en la figura).

La solucin,
recomendable en vas
lentas, es obligada si la
lnea se ha de levantar
para cada peticin de
servicio. El tiempo entre
la finalizacin 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
Peticin habr bajado
la lnea tras recibir la
respuesta. Esta
arquitectura permite tambin optimizar costes cuando hay multicliente
(obviamente lo normal) ya que el servidor de paso solo bajar la lnea
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, segn
corresponda:

Se identificarn los procesos que han de ser servicios a los que
asignamos un nombre.
Se aadir un proceso de transformacin, 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 sncrona o asncrona. Si es sncrona, el proceso aadido para
implementar la llamada recibe tambin la respuesta. Si es asncrona, e
interesa aprovechar el tiempo de espera, un segundo proceso aadido
diferente del de la llamada recibe la respuesta.

Deber decidirse tambin aqu si implementamos servicios pasivos, servidores
o agentes.

Tomar
Respuesta
Llamada
Pasar
Peticin
Servidor
de Trabajo
Tomar
Respuesta
Llamada
Servidor
de Trabajo
R
R
Solucin 1
Solucin 1
Solucin 2
Solucin 2

Figura 216. Arquitectura de una llamada asncrona a
travs de una va lenta.
6. 5. Un pequeo ejemplo en MAFDRA.

Ms adelante aplicaremos todo este nuevo paso de la metodologa al ejemplo
de la agencia de viajes. Sin embargo, y para clarificar esta etapa vamos a
aplicar todo esto a un pequeo ejemplo.

El sistema de informacin 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
almacn para entregar el
gnero al cliente. La
naturaleza de los
productos vendidos no
produce roturas de stock.
El almacn se repone
cada semana con un
proceso que queda fuera
del SI que tratamos.
Al cliente se le
entrega un albarn de
los productos
retirados. Estos
albaranes de recogen
en la Delegacin y se
envan cada noche a
la Central donde se
realiza un proceso de
facturacin y cobro
centralizado. El
riesgo del cliente se
mantiene, pues,
centralizado.

Aplicando anlisis
descendente al
proceso de
transformacin que
representa al SI se obtiene el primer refinamiento de la figura.

Observe la aparicin de las entidades intermedias, pedido en curso para
almacenar los datos que se estn 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 estn
secuencializados ya que se ejecutan uno detrs de otro para cada pedido, pero
Cliente
Venta
Productos
Productos
Cuentas Clientes
Clientes
Albaranes
Albarn

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

Figura 218. Primer Refinamiento
no as el de enviar albaranes a la central ya que slo se ejecuta una vez al final
del da.

Aplicando otro nivel de refinamiento a los dos primeros se obtienen los
diagramas de flujo secuencializados de las figuras siguientes.

Una aproximacin al modelo de datos nos permite decidir la arquitectura de los
datos:

Los clientes solo existirn en la central ya que se identifican por tarjeta.
Los productos estarn replicados en la central y en el local.
Los albaranes se mantendrn en un modelo replicado con la copia
master en la central y el foco de mantenimiento en el local.
Adelantando el anlisis 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 lgica de datos se identifica un
servidor para Leer Datos del Cliente en la Central.
2. Para utilizar las posibilidades de impresin 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 Recepcin e Incorporacin de los Albaranes a las
bases de datos corporativas. Lo montaremos con un agente

Colocando estos servidores en los diagramas de flujo de obtendrn los
siguientes diagramas evolucionados.
Pedido en Curso
Verificar
Crdito
Registro
Productos
Pedido
Cliente
Clientes
Cuentas Clientes
Productos
Identificacin
Cliente
Leer
Datos
Cliente
Aviso
al
Cliente
No hay Crdito

Figura 219. Refinamiento de Registro de Pedido
Pedido en Curso
Imprimir
Albarn
Albaranes
Preparar
Entrega
Albarn
Acumular
Albaranes

Figura 220. Refinamiento de Servir Pedido

Observe en el
primer
refinamiento que
la utilizacin del
servidor de correo
comporta que el
proceso de Enviar
Albaranes a la
Central se ha
convertido en una
simple anotacin
a la cola del
servidor de correo
que es el que
realizar el envo
de forma
autnoma con los
parmetros con
los cuales se
haya
parametrizado.

El servicio para Incorporar a BD Corporativa ser una envolvente de la
aplicacin 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 peticin y tomar la respuesta, proceso que como se
observa en la figura se trabaja de forma asncrona. Observe la necesidad de
definir un nuevo servidor en el parte de la Delegacin para poder realizar
correctamente la llamada asncrona salvando la heterogeneidad de la conexin
lenta, tal como se ha comentado anteriormente.

Pedido en Curso
Servir
Pedido
Albaranes Local
Registro
Pedido
Cliente
Clientes
Cuentas Clientes
Albarn
Productos
Anotar
Envo
Albaranes
Albaranes Central
Servidor
de correo
R
Incorporar
a BD
corporativa

Figura 221. Arquitectura Distribuida del primer refinamiento
Respuesta
Tomar
Crdito
Clientes
Cuentas Clientes
Leer
Datos
Cliente
Cdigo Cliente en Peticin

Figura 222. Refinamiento del Servidor para Leer los Datos del
Cliente
Pedido en Curso
Tomar
Datos
Cliente
Registro
Productos
Pedido
Cliente
Productos
Identificacin
Cliente
Pedir
Datos
Cliente
Aviso
al
Cliente
No hay Crdito
Verificar
Credito
Pasar
Peticin 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
comunicacin entre cliente y
servidor que trataremos en el
apartado siguiente. Lo he hecho
as para minimizar mi trabajo, y
porque creo que no debera
suponer ningn problema, si he
hecho bien mi exposicin, hasta
este momento.

7. Creacin de la Arquitectura Distribuida.

Una vez identificados los servidores, ya es posible la completar la construccin de
la arquitectura distribuida.

Habremos de analizar y concretar:

O El modelo de comunicacin entre cada servicio y sus clientes. Agrupa.
O Tipo de comunicacin.
O Formato del mensaje
O Las relaciones entre los servicios, reflejada en la tipologa de la arquitectura
de servicios.
O Flujo de mensajes.
O La modalidad y el momento del arranque.
O La implementacin de cada servicio.
Pedido en Curso
Pedir
Imprimir
Albarn
Albaranes
Preparar
Entrega
Albarn
Acumular
Albaranes
Impresin
Albarn

Figura 224. Arquitectura Distribuida de Servir
Pedido.

Para conseguirlo seguiremos los siguientes pasos:

7. 1. Definir el tipo de comunicacin.

Para cada servicio identificado en la etapa anterior habr que decidir el modelo
de comunicacin con sus clientes.

Lo primero que habr que mirar es si el servicio utiliza algn recurso de
Middleware que obligue a un modelo de comunicacin determinado. Por
ejemplo la utilizacin de ODBC marca el modelo de comunicacin sncrono
ligado a este tipo de servicio de datos.

A continuacin habr que preguntarse si el servicio necesita ser reservado de
forma que el cliente sepa que lo tiene. Si es as el modelo de comunicacin a
escoger ser el conversacional. Recuerde que hoy da 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 compaas, una buena
eleccin ser RPC o Servicio WEB.

A continuacin, y para el resto, queda la eleccin clsica: RPC o Colas?,
Sncrono o Asncrono? Repase las ventajas e inconvenientes de unos y otros
desarrolladas en el captulo dedicado a
los modelos de comunicacin. Aunque ya
conoce mi forma de pensar: prime la
comunicacin asncrona sobre la
sncrona. Y siempre que pueda,
implemente la comunicacin asncrona
con colas con el conocido esquema
multicliente y multiservidor.

Hay otra situacin en que puede valorarse seriamente la utilizacin de RPC, o
cualquier otra modalidad sncrona, en lugar de cola: cuando hay
comunicaciones lentas y el cliente ha de esperarse siempre a la respuesta, es
decir, la comunicacin es por aplicacin sncrona.

Pero por favor, no elija nunca sncrono solo porque es fcil de programar!

En todos los casos, habr que definir el formato del mensaje de cabecera para
el mecanismo de peticin / respuesta de servicio.

Y finalmente habr que tomar decisiones en comunicaciones remotas sobre s:

Encriptar o no la comunicacin.
Empaquetar o no el mensaje.
Time-out si la comunicacin es sncrona y el Middleware no proporciona
ese mecanismo.
Checkpoints de calidad de la transmisin en mensajes largos, etc.

7. 2. Definir la arquitectura entre los servicios.

Figura 225. Servidores multicliente
y multiservidor
Esta etapa se habr empezado en la etapa de identificacin 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 bsicos.

Recuerde que la arquitectura por defecto entre dos servidores es la
delegacin de servicio. Si el contenido del mensaje es muy grande,
valore la utilizacin de una arquitectura de filtro.
Recuerde tambin que la arquitectura de comunicacin 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 tcnicas del multihilo.
Si tiene una conexin entre dos puntos heterogneos por una va lenta
por la que han de viajar peticiones de servicio diferentes para varios
servidores, valore una arquitectura de distribucin.
Si tiene una funcin nica que ha de ser atendida por servidores
diferentes en entornos heterogneos, encapsule la llamada con una
arquitectura de pasarela para utilizar una sola llamada lgica desde los
clientes y encapsular la heterogeneidad de la prestacin de servicio.
Y busque cuidadosamente las relaciones precondicin que puedan
haber surgido en su arquitectura de servidores. No hacerlo, puede ser
muy peligroso y conducir a grandes problemas en tiempo de explotacin.

7. 3. Documentar la Arquitectura Distribuida.

Finalmente habr que documentar y especificar todo en la metodologa
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 comunicacin.

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 solucin obtenida.

La importancia de las decisiones que ha tomado es tal que le recomiendo en
este punto de su diseo que haga una pausa, revise la arquitectura obtenida y
reflexione y valore sobre la bondad, eficacia, eficiencia y viabilidad de la
solucin adoptada.

Obviamente, si se decide algn cambio, se habr de volver al punto de la
metodologa afectado.

7. 5. Creacin de la Arquitectura Distribuida del ejemplo de venta de
productos.

Como ejemplo corto de aplicacin de esta parte de la metodologa comentemos
la arquitectura distribuida del anterior ejemplo de venta de productos en
Delegaciones.

7.5.1. Eleccin del Modelo de comunicacin.

Repasando servidor por servidor vamos a elegir el modelo de
comunicacin.

Servidor de Correo. La comunicacin por colas es obligada ya que
es un producto de Middleware.
Servidor de BD. Todos los accesos a las BD son sncronas ODBC
de forma obligada ya que utilizamos este estndar para
independizar los accesos del motor.
Servidor para pasar la peticin de clientes a la Central. La
comunicacin es asncrona por colas por decisin de diseo.
Servidor de Leer Datos de Cliente. Como ha de trabajar junto con el
anterior elegimos, tambin colas.
Servidor de Impresos de albaranes. Al utilizar Word para
implementar este servidor, la comunicacin ser asncrona
desacoplada por OLE. Al elegir este modelo, el programa cliente
que integre esta parte de la aplicacin deber pedir conformacin
de que el albarn ha salida correctamente o dar posibilidad de
repetir la impresin del albarn a voluntad del operador. Prime esta
segunda opcin ya que lo normal es que salga siempre bien (sino,
mal vamos!) y evitar acciones no necesarias de operacin.

7.5.2. Arquitectura de servidores.

Entre el Servidor para Pasar la Peticin y el Servidor para Leer Datos
del Cliente se establece una arquitectura de delegacin de servicio.

Al final documentaramos la solucin elegida aadindola a los diagramas de
flujo o de secuencia segn corresponda, accin, que como ya he dicho en el
apartado anterior ya haba adelantado para ahorrarme trabajo.

Obviamente, y por tratarse de un ejemplo corto didctico, no realizo el map to
reality que se explica a continuacin, aunque si propongo una localizacin:

Servidor de Correo. Una parte en el servidor de la delegacin y otra en la
Central.
Servidor de BD. Donde se localicen los motores. Habr un en la
Delegacin y otro en la Central.
Servidor para pasar la peticin de clientes a la Central. En el servidor
departamental.
Servidor de Leer Datos de Cliente. En la Central
Servidor de Impresin de albaranes. En cada mquina cliente.

8. Map to Reality.

Ya hemos comentado anteriormente el por qu es tan interesante adaptar la
solucin lgica a la plataforma en este punto de la metodologa: se adelanta un
trabajo que habr que acabar realizando para ganar fiabilidad de rendimiento y
operatividad.

La adaptacin se realiza en tres pasos:

8. 1. Localizacin.

De los servicios sobre la plataforma fsica. La decisin se habr de concensuar
con el Administrador de Sistema.

Ya se han visto muchos criterios de localizacin. En los captulos dedicados al
diseo de la administracin del sistema se ver el resto (en realidad, pocos
ms de los que ya conoce).

8. 2. Configuracin.

De los servicios, esttica o dinmica.

Se decidir, entre otros factores:

La parametrizacin de los motores de bases de datos (bferes, tamao
de las zonas de trabajo y loging, etc.), de importancia fundamental para
el rendimiento.
La configuracin de los productos de Middleware.
El plan de arranque de los servidores y su configuracin a travs de la
ficha de enviroment.

8. 3. Analizar rendimiento.

Este apartado es bsicamente igual que el correspondiente de los datos.

Es caso de duda se ha de asegurar, por prueba, la interoperatividad y el
rendimiento. La valoracin de la interoperatividad es ms importante en los
procesos que en los datos.

Uno de los factores a asegurar aqu de forma especfica en el rendimiento de
las colas. Este factor est en funcin del tiempo medio de respuesta de una
anotacin por el nmero 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 vlido 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 ms instancias simultneas.

Recuerde que el tiempo de respuesta de una cola es el tiempo de gestin de
sus anotaciones, pero principalmente, el tiempo de servicio de los servidores
que la utilizan.

Conviene medir con dos parmetros:

Nmero mximo de usuarios simultneo.
Nmero medio de accesos simultneos.

Se valorar con el segundo, pero se asegurar que el primero es aceptable
como excepcin puntual.

En cualquier caso, recuerde que la prueba ha de ser medida y que como
resultado de la prueba, quizs se deber volver atrs para cambiar alguna
decisin o aadir algn proceso. O cambiar algn recurso de la plataforma. Y
que ambas decisiones, que son muchas veces alternativas, han de valorarse
econmicamente.

9. Diseo de la Arquitectura distribuida del ejemplo de la venta de viajes
areos y hotel.

Apliquemos todo el contenido al ejemplo que desarrollamos para presentar
MAFDRA. Repase el anlisis funcional y, adelante! Le avanz que necesitar
definir el concepto de cliente habitual.

Le recomiendo que desarrolle el ejemplo sin mirar la solucin y la consulte
despus.

9. 1. Anlisis de datos.

En la especificacin se han recogido dos puntos que sern de inters 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 crdito.

Estos dos factores permiten tomar decisiones en el equilibrio costes versus
administracin.

En cada tienda estarn 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 gestin es necesario cuantificar la relacin cliente habitual de
una tienda. La estableceremos como el cliente que ha realizado al menos una
operacin en la tienda en los ltimos tres aos. Observe que esta decisin
supone que puede haber clientes replicados en ms 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 tambin que pasados tres aos desde una
compra ocasional desde una tienda no habitual, el cliente desaparecer del
fichero de esa tienda.

Para implementar esta nueva relacin cliente habitual de se utilizar una nueva
tabla de formato:

Relacin Tienda-Cliente
Tienda String 4
DNI String 14
Fecha de la
ltima operacin
Fecha 8

Lo que obliga a considerar una tabla de tiendas que hasta ahora, aunque
obvia, no haba sido necesaria.

Tiendas
Tienda String 4
Nombre String 50
Etc.

Este cambio,
trasladado al
modelo de
datos, lleva al
esquema de
datos
modificado de
la figura de la
izquierda.

A la tabla de
clientes se
aadir un
nuevo atributo
para controlar
que clientes
son solventes
y no
necesitan
verificacin
del crdito antes de venderles:

Clientes
DNI String 14
Nombre String 50
Direccin String 4x40 La direccin no tiene estructura
prefijada
Grupo Contable String 6 Clave fornea. Ver Diccionario de
Conceptos
Cuenta Contable String 10 Clave Fornea.
Necesita control
de riesgo?
String 1 S: lo necesita, N: no lo necesita. En la
prctica se aadira 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 localizacin obligada:

El modelo de datos modificado se implementar totalmente en la
Central. Los clientes sern el total de clientes de la Compaa. Ser
la copia master, aunque su mantenimiento se har desde las
tiendas.
En cada tienda se implementarn slo las tablas de clientes de esa
tienda, la de compaas areas y de los hoteles para tener en las
tiendas el telfono de llamada para reservas. El fichero de
Clientes
Central
Cuenta
Analtica
Vuelos
Viajes
Comprados
por
Vuelos
por
Cliente
1
M
1
N
Corresponde a
Anotaciones
Cuenta
Analtica
1
M
Es movimiento de
Compaa
Servido por
M 1
Cliente
habitual
de
Tiendas
Relacin
Tienda-
Cliente
N M
Plazas
Hotel
Hoteles
Habitacin de
M
1

Figura 226. Esquema de datos modificado
compaas 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 replicacin
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
Analtica
Vuelos
Viajes
Comprados
por
Vuelos
por
Cliente
1
M
1
N
Corresponde a
Anotaciones
Cuenta
Analtica
1
M
Es movimiento de
Compaa
Servido por
M 1
Cliente
habitual
de
Tiendas
Relacin
Tienda-
Cliente
N M
Plazas
Hotel
Hoteles
Habitacin de
M
1

Figura 227. Arquitectura de datos de la Central

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

Los volmenes de clientes en una tienda en el mbito de un negocio de
este estilo no pueden ser grandes por lo que parece clara la decisin de
establecer una poltica de replica mensual por extraccin 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 compaas areas 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 cdigo del cliente ser su DNI por lo que no necesita criterios de
codificacin distribuida.

Los pedidos se numeran dentro de cada DNI por tienda, fecha y un
nmero secuencial por si un cliente compra ms de una vez el mismo
da. No necesita, pues, criterios de codificacin distribuida adicionales.

9.1.3. Adaptacin del diseo.

Observemos que esta implementacin de la arquitectura distribuida de
datos obliga a pensar en nuevas situaciones ligadas a la lgica de
datos:

Modificar el proceso de lectura y acceso a clientes.
Modificar el proceso de alta de cliente.
Mantener la fecha de la ltima operacin 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
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
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 especificacin 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.
Alta
Cliente
Cliente
Clientes Local
Cuenta Cliente
Crdito Estndar
Clientes Central
Cliente por Tienda
Pedir
Datos
Cliente
Cliente
Clientes Local
Crdito Estndar
Incorporar
a Clientes
Local
Asignar
Crdito
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 diseo de Entrada de la Peticin que queda
redefinido como se muestra en la figura.

En el proceso de actualizacin de datos en la central hay que aadir un
proceso nuevo para actualizar la operatividad del cliente en cada tienda.
El proceso modificado se muestra en la figura.

Cliente
Peticin Cliente
Registro
Datos
Cliente
Peticin
Cliente
Acceso
Datos
Cliente
Registro
Datos
Viaje
Consulta
Cuenta
Cliente
Cuenta Clientes
Rechazar
Venta
Alta
Cliente
Clientes Central
Re-intentar
Crdito Estndar
No crdito
Clientes Local
Clientes por Tienda
No existe Cliente
Sin hotel

Figura 1. Entrada de la Peticin modificada.
Peticin Cliente
Actualiza
reserva
c.area
Datos Compaa Area
Cuenta Clientes
Anotacin
Cuenta
Cliente
Vuelos por Cliente
Anotacin
del vuelo por
Cliente
Aviso
al
Cliente
Anular
Venta
Re-intentar
Cliente
No hay plazas
Hay plazas
Clientes por Tienda
Anotacin
Fecha
Operacin
Actualiza
datos
hotel
Datos Hotel

Figura 231. Proceso de Actualizacin de Datos modificado.

Aparece un nuevo proceso de Replicacin de los Clientes de la Tienda
desde la Central. El proceso de Replicacin de Hoteles seguir la
misma operativa

El proceso
implementar la
poltica de replicacin
que se quiera
establecer.
Analicemos cual
puede ser esa
poltica. 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 da. Escogemos, como ya se ha dicho, un modelo de
propagacin de la replica sncrona pero un proceso de replicacin por
copia mensual para evitar la auditoria.

Este proceso de replica por extraccin, 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 automtica a cada tienda
donde sustituir a la replica de clientes local. Un diagrama de flujo
secuencializado del proceso se muestra en la figura anterior.
Seleccin
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 Replicacin de Clientes

La replicacin mensual se har de forma automtica y desatendida la
noche entre los dos primeros das laborables consecutivos del mes.
Para ello se habr de llevar en la Central un calendario de los das
festivos de cada tienda.

9. 2. Diseo de la Arquitectura Distribuida.

9.2.1. Diseo de la lgica de datos distribuida e identificacin de servicios.

Las comunicaciones estn resueltas por el Middleware por lo que los
servicios diseados utilizarn 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 lgica de
datos.

Todos los accesos de datos directos utilizarn SQL.

Se relacionan a continuacin los servicios de datos identificados, desde
donde han aparecido en el funcional, su funcin y el tipo de
implementacin, por servidores o por procedimiento catalogado.

9.2.1.A. Leer Datos Cliente.

Funcin: 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 Peticin.

9.2.1.B. Leer Datos Cliente en la Central.

Funcin: 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 crdito. Como el cliente se
tomar habitualmente del fichero de clientes del local, en la
mayora de los casos el acceso a la Central solo ser para
saber el estado del crdito en aquellos clientes que
necesiten verificacin de crdito. Por esa razn, es
conveniente que se prevea la opcin de pedir slo los
datos de crdito en el mensaje de peticin de servicio.
Origen: Estudio del diagrama de flujo del servidor Leer Datos
Cliente.

9.2.1.C. Alta Cliente en la Central.

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

Funcin: 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. Actualizacin de Datos de la Compaa area.

Funcin: Pedir la reserva de las plazas vendidas a ala compaa
area.
Origen: Estudio del diagrama de flujo de Actualizar Datos de
Venta.

9.2.1.F. Consulta de Hoteles.

Funcin: Consulta de las disponibilidades de habitaciones en los
diferentes hoteles.
Origen: Estudio del diagrama de flujo de Registro Datos Viaje

9.2.1.G. Actualizacin de Datos de la Hotel.

Funcin: Confirma reserva de habitaciones.
Origen: Estudio del diagrama de flujo de Registro Datos Viaje

Los datos de hotel se gestionarn a travs de Servicios WEB. Todo el
resto de la lgica de datos se implementa en servidores convencionales
y no es necesaria la creacin de ningn procedimiento catalogado.

Se identifican, adems dos servidores de proceso:

9.2.1.H. Impresin de la Reserva para el cliente.

Funcin: Impresin del documento de reserva de las plazas de avin
de la venta realizada al cliente. Se utilizar como servidor
de impresos Word para aprovechar las ventajas de
creacin de formularios (multidioma incluido) de un
procesador de textos.
Origen: Estudio del diagrama de flujo de Entrada de la Peticin.

9.2.1.I. Servidor de Correo.

Funcin: Traspaso de ficheros.
Origen: Estudio del diagrama de flujo de Replicacin de Clientes.

9.2.2. Eleccin del modelo de comunicacin.

9.2.2.A. Leer Datos Cliente.

Modelo: Cola. Acceso a los datos del local por SQL.
Uso: Asncrono para utilizar el tiempo de acceso a la Central
para registrar los vuelos solicitados.
Parmetros Mensaje: De entrada: cdigo cliente y tipo de peticin
(completa o solo de crdito).
De salida: indicativo de existencia y atributos
del cliente y de crdito.

9.2.2.B. Leer Datos Cliente en la Central.

Modelo: Cola remota. Acceso a los datos de la central por SQL
Uso: Sncrono.
Parmetros Mensaje: De entrada: cdigo cliente
De salida: indicativo de existencia y atributos
del cliente y de crdito.

9.2.2.C. Alta Cliente en la Central.

Uso: Sncrono.
Parmetros 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.

Uso: Sncrono.
Parmetros Mensaje: De entrada: datos de la venta
De salida: indicativo de servicio completo.

9.2.2.E. Actualizacin de Datos de la Compaa area.

Modelo: RPC.
Uso: Sncrono.
Parmetros Mensaje: De entrada: Compaa, 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 nmero de plazas
libres en ese momento.

9.2.2.F. Consulta de Hoteles.

Modelo: Servicio WEB.
Uso: Sncrono.
Parmetros Mensaje: De entrada: Ciudad, Categora del hotel, da
De salida: indicativo de s existen
habitaciones pedidas. En caso afirmativo,
Lista de hoteles posibles con enlace a su
pgina WEB.
.
9.2.2.G. Actualizacin de Datos del Hotel.

Modelo: Servicio WEB.
Uso: Sncrono.
Parmetros Mensaje: De entrada: Hotel, da, datos cliente
De salida: indicativo de confirmacin.

9.2.2.H. Impresin de la Reserva para el cliente.

Modelo: Active X.
Uso: Asncrono desacoplado.
Parmetros 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: Asncrono desacoplado.
Parmetros Mensaje: De entrada: fichero a trasladar y tienda destino
De salida: indicativo de servicio recibido.

Todas las colas se implementarn como servidores autnomos,
localizadas en el lado del servidor.

9.2.3. Creacin 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 Impresin de la Reserva se convierte en una llamada Word.
Como la comunicacin es
asncrona desacoplada es
necesario preguntar si la
impresin ha sido correcta
o no. Este proceso deber
incluirse como llamada
independiente en el
diagrama jerrquico de la
aplicacin para permitir
copias adicionales. Dar la
posibilidad de reimpresin
de la Reserva de Cliente
supone dar a la Peticin de
Cliente persistencia y, por
tanto, la necesidad de
crear un nuevo proceso de
Eliminacin de Peticiones
que se aadir al jerrquico definitivo para que el usuario lo ejecute de
tanto en tanto.

Existe una precondicin 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 crdito consumido. El efecto, si hay una actualizacin del
crdito de un cliente por una venta, puede ser que antes de registrarse
en el servidor de actualizacin se pida consulta a travs del de lectura y
que se d un valor equivocado.

La precondicin entre ambos servidores se establecer de forma que
cuando se realice una consulta del cliente se mire si hay una
actualizacin de venta de ese cliente pendiente y, si es as, no dando la
respuesta hasta haber completado la actualizacin.

La precondicin se establecer compartiendo ambos servidores la cola
de comunicacin con
sus clientes, tal como
se muestra en la
figura. Esta cola la
denominaremos en el
contesto del ejemplo
Cola de Clientes. La
precondicin la
deber revisar el
servidor de lectura.

Hay que hacer una
aclaracin importante.
En el contesto de
este ejemplo la
Peticin Cliente
Impresin
Reserva
Reserva
Cliente
Servidor de
Impresos
WORD
Pregunta
Impresin
Correcta
Repetir
Formularios
Eliminacin
Histrica
Peticiones
Fecha

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

Figura 234. Precondicin en la gestin del Crdito de
Cliente
precondicin 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 crdito es muy remota. Unido al hecho de que,
el problema sera realmente grave si se hiciera desde otra tienda donde
no hay ningn conocimiento de la venta no registrada, hace que la
probabilidad de ocurrencia sea prcticamente nula. De cualquier forma
mantendremos la precondicin a efectos docentes.

El servidor para
Actualizar Datos de
Cliente en la Central
implementar esas
funciones del proceso
de actualizar datos y
su diseo se muestra
en la figura. Observe
que la nica funcin
de Actualizar Datos
de Venta no
implementada es la
de peticin de la
reserva del vuelo a la
compaa area 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 diseo interno.
Datos cliente
Coger
Crdito
Coger
Datos
Cliente
Clientes Central
Preparar
respuesta
Coger
Peticin
Actualizar
Clientes en
la Central
Cuenta Cliente
Parmetros
Cola
Clientes
Pre-C
S
o
l
o

C
r
d
i
t
o
Actualizacin
Pendiente

Figura 236. Refinamiento del Servidor de Leer Datos de Cliente
en la Central

En este diagrama de flujo hay un proceso, Coger Crdito, que puede ser
desglosado mediante anlisis descendente en el siguiente diagrama de
flujo:

Referencia Cliente
Cuenta Cliente
Anotacin
Cuenta
Cliente
Vuelos por Cliente
Anotacin
del vuelo
por Cliente
Anotacin
fecha
Operacin
Clientes por Tienda
Colocar
respuesta
Coger
Peticin
Cola
Clientes

Figura 235. Servidor de Actualizar Datos de Cliente en la Central
El diagrama
implementa una
accin muy
habitual en este
tipo de
precondiciones: el
cambio de
prioridad de los
movimientos de
actualizacin
pendientes de las
referencias que
se quieren
consultar.

El proceso
devuelve al
anterior una
salida
condicionada si
no ha podido tratar la peticin actual para que trate el siguiente
movimiento. Obviamente, la implementacin ha de controlar que se trate
realmente la peticin 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
solucin A, se muestra en la
figura.

La arquitectura se ha construido
con la identificacin de
servidores que se ha realizado
anteriormente.

Existe, sin embargo, otra solucin que denominaremos B, un poco ms
compleja pero ms limpia de diseo que se muestra en la figura
siguiente. Observe la aparicin de dos servidores nuevos:
Datos Clientes
Leer
Crdito
Cuenta Cliente
Coger
Peticiones
del Cliente
Verificar si
hay cambios
Pendientes
Cambiar
Prioridad
Actualizacin Pendiente
Cliente (Parmetro)
Cambios Saldo Pendientes
Cola
Clientes
Hay Actualizaciones Pendientes
Sin Actualizaciones Pendientes

Figura 237. Refinamiento del servidor de lectura del crdito.
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. Solucin A para la arquitectura del
servidor de Leer Datos del Cliente
en el servidor de la Tienda.

Acceder a Clientes en la Central, que permite mediante una
arquitectura de distribucin llamar a las dos funciones de obtener
datos descriptivos de cliente y obtener el crdito.
Leer Crdito del Cliente, que
lee de forma especializada
slo el crdito.

Y de una modificacin, ya que el
servidor de Leer Datos de
Cliente en la Central slo tomar
los datos descriptivos.

Dejo al lector como ejercicio el
diseo interno de estos dos
nuevos servidores y del
modificado.

Cul es mejor? Por temas de
rendimiento son equivalentes, la
diferencia de coste de
programacin es mnima y la
solucin B es ms 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
Crdito
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. Solucin A para la arquitectura del
servidor de Leer Datos del Cliente
en el servidor de la Tienda.

Desarrollemos ahora la arquitectura de los procesos para el alta de
clientes. El diseo del servidor para el Alta del Cliente en la Central se

Finalmente, el
proceso de
Entrada de la
Peticin del
cliente queda
como se muestra
en la siguiente
figura. Observe,
comparndolo 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
Peticin: Cdigo Cliente
Cuentas Clientes
R
Tomar
Datos
Cliente
Tomar
Crdito
R
Hay que
tomar
Crdito

Figura 240. Refinamiento del servidor de lectura de datos de clientes en la Tienda
Clientes Central Cuentas Cliente
Incorporar
a Clientes
Central
Parmetro: Datos Cliente
Asignar
Crdito
Crdito estndar
Incorporar
a Clientes
por Tienda
Clientes por Tienda

Figura 241. Arquitectura del servidor de Alta de Clientes
en la Central.
Cliente
Peticin Cliente
Registro
Datos
Viaje
Peticin
Cliente
Acceso
Datos
Cliente
Registro
Datos
Cliente
Verificar
Crdito
Cliente
Rechazar
Venta
Alta
Cliente
Re-intentar
No crdito
Leer Datos
Cliente
No existe
el Cliente
Sin hotel

Figura 242. Arquitectura del proceso de Entrada de la Peticin.

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
Peticin Cliente
Registrar
Datos
Vuelo
Registro
Datos
Hotel
Datos Compaa Area
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.

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
compaa area y
otro al servidor de
la central que
actualiza la venta
en los ficheros de
cliente.

La actualizacin
de datos de cliente en la central puede montarse con filosofa de agente
para liberar antes el programa de actualizacin.

Incluyendo el servidor de Correo dentro del proceso de replicacin de
clientes, la arquitectura resultante es la de la figura.

La
comunicacin
con el servidor
de correo es
asncrona
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 automtica el proceso de generacin de la replica sobre la BD
de la tienda.

El proceso de Estadsticas de Venta se pasa en la Central y por esa
razn los nicos servicios que utilizarn ser ODBC - SQL, para
acceder a los datos, y los servicios de impresin de la red. No se
incluye, por su poca significacin en diagrama. En la figura se muestra
el diagrama de flujo de la arquitectura resultante.
Peticin cliente
Actualiza
Reserva
C.Area
Anotar
en la
Central
No hay plazas
Actualizar
Datos
Clientes en
la Central
R
Datos Compaa Area
RPC
Actualizar
Datos
Compaa
Area
R
Cola
Clientes
Actualiza
datos
hotel
Datos Hotel
R

Figura 244. Arquitectura del proceso de Actualizacin de Datos de
la Venta
Seleccin
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 Replicacin de Clientes

9.2.4. Map to Reality.

Obviamente, en un libro este apartado ha de ser meramente teorizante
y fuera de todo contesto de evaluacin de rendimiento. Se incluye
nicamente a efectos descriptivos.

Suponemos que todas las tiendas tienen suficiente volumen para
disponer de un servidor propio (precondicin de organizacin).

La configuracin 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.
Ofimtica: Microsoft Office, el particular Word como servidor de
impresos. Word se instalar en cada puesto de trabajo para
conseguir autonoma y seguridad en el servidor de impresin de las
reservas.
Servidor de Correo. GEYCE-Link (producto de Middleware
comprado).
Middleware de fabricacin propia: Sistema de colas.
Middleware estndar: Servicio WEB, RPC, TCP/IP y recursos de
administracin de red.

Los servidores se arrancarn estticamente en el momento del
arranque de las mquinas respectivas.

La localizacin 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 Compaas areas son transparentes a nuestro
sistema de informacin.

9. 3. El diseo de los Servicios WEB.

Podemos suponer que
la Compaa de
nuestro ejemplo quiere
ofrecer estos servicios
de consulta y reserva
de hoteles para otros
clientes mediante una
cuota econmica y que
es por eso por lo que
se ha decidido por la
tcnica de Servicio
WEB para la
implementacin.

Prescindiendo de la
implementacin de los
servicios, recuerde que
este es un libro de
diseo, observe que la
arquitectura de los
servicios ser la de la figura.

El Servicio WEB no ser ms que una arquitectura de pasarela hacia los
sistemas de informacin de los hoteles publicados.

9. 4. Diagrama jerrquico modificado.

Como resultado de esta parte del diseo se llega al diagrama jerrquico
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 Actualizacin de Datos
de la Venta
Venta de Vuelos en
Delegaciones
Obtencin
Estadsticas
Mantenimiento de
ficheros bsicos
Alta de Clientes Venta Viaje Areo
Registro de la
peticin
Actualizaciones
Compaa Area
Hotel
Cuenta cliente
Venta por cliente
Venta por vuelo Datos Vuelo
Datos Hotel
Vuelos por cliente
Impresin Reserva Eliminacin Peticiones

Figura 247. Diagrama Jerrquico tras el diseo de la Arquitectura distribuida.

Polticas de Administracin de un Sistema
Distribuido.

1. Introduccin.

Para poder desarrollar los anlisis de consistencia y de administracin del sistema
es necesario desarrollar previamente las polticas posibles en la administracin del
sistema distribuido. Y estas polticas estn basadas en las actividades a cubrir.

Este conocimiento nos permitir establecer plataformas y procesos de
administracin. Y la plataforma se utilizar como componente de la gestin de
anlisis de consistencia.

No partimos de cero. En la primera parte hemos dedicado un capitulo a introducir la
administracin del sistema distribuido. No vamos a repetirlo aqu. Repselo, 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 bsicos.

Recuerde, eso s, que la administracin es uno de los puntos dbiles y que, por
tanto, debe ser cuidado especialmente. Aqu hablaremos de polticas. Ms adelante
estableceremos los criterios del anlisis de la administracin del sistema que ha de
aportar lo necesario al DSM del Middleware para desarrollar la poltica elegida.

Recordemos tambin que el Plan Estratgico de Gestin del Sistema Distribuido
acta tambin como fuente de precondiciones al diseo de la administracin del

2. La administracin de sistemas distribuidos.

Administrar sistemas distribuidos supone gestionar centenares de recursos y
componentes dentro de entornos muy heterogneos y con dispersin geogrfica.

El factor humano es tambin un punto a considerar ya que los administradores y los
administrados muchas veces ni se conocen y cualquiera que tenga mnimos
conocimientos de las relaciones humanas (ese s que es un tema complejo!) sabe
que el contacto personal facilita muchsimo 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 solucin que dejara satisfechos a
administradores y administrados solo es viable econmicamente en grandes
instalaciones. Pero en cualquier caso, el error ms grave que puede cometer es
no planificarlo. Seguro que ms tarde o ms pronto le estallar en la cara.

Por favor, antes de seguir repase los procesos bsicos a administrar detallados en
el captulo correspondiente de la primera parte.

3. reas de actividades en la administracin de un sistema distribuido.

Es muy difcil catalogar y estructurar todas las actividades de administracin
presentes en un sistema distribuido por la dispersin 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 clasificacin y del flujo
que se muestran en la figura.

Recoleccin Informacin
Anlisis de la gestin
Planificacin de estrategias
Consola de gestin y control
Almacn del conocimiento
Asistencia a los usuarios
Nuevos elementos y cambios
Anlisis de rendimientos
Inventario de activos
Datos
reas de administracin
Planificacin
Anlisis
Gestin y control
Inventario y Monitoring
Soporte a usuarios
Datos
Automatizar tareas intensivas
Area de Costes
Repercusin de costes
Auditoria Interna y Externa
Instalacin, configuracin i parametrizacin

Figura 248. Clasificacin de las actividades de administracin

Las actividades de primer nivel que se muestran en la figura se agrupan en reas
genricas:

O rea de planificacin, destinada a definir los criterios de gestin del sistema
distribuido. Incluye:
O La inclusin de nuevos elementos y cambios. Como parte del diseo
distribuido habr que decidir como se interaccionan los nuevos
elementos o cambios realizados con la plataforma de administracin del
O La planificacin de las estrategias de acuerdo con las polticas de
negocio de la empresa o empresas afectadas.
O rea de gestin y control, desde donde se gestiona el da a da.
O rea de administracin de los datos. Engloba todas las actividades de
administracin de los datos de las que hemos hablado ampliamente a lo largo
de nuestro viaje.
O rea de anlisis, donde se analiza los resultados obtenidos y se proponen
las mejoras. Incluye, bsicamente dos aspectos:
O Anlisis de rendimientos, para ayudar a la gestin del da a da.
O Anlisis de la gestin, que analizar la gestin en relacin a los costes,
la calidad del servicio y el seguimiento con la lnea de negocio de la
compaa. Sirve de realimentacin en la planificacin 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 proteccin de datos, procesos de
blanqueo de dinero, etc... ) y tcnica..
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 estn dedicadas a
recoger las medidas del sistema y almacenarlas como soporte a la decisin.
Incluye tres actividades bsicas:
O Recoleccin de la informacin.
O Inventario de activos.
O Archivo de conocimiento adquirido.

Excepto en el caso del rea de anlisis que se trata dentro de cada una de las otras
reas, a continuacin trataremos ms a fondo cada una de estas actividades
bsicas.

Y antes de hacerlo vamos a introducir algunos conceptos que nos sern de inters.

4. Organizacin de la administracin.

Antes de entrar a fondo en la descripcin de las actividades concretas de cada rea
conviene pensar sobre que elementos de organizacin se configuran esas
actividades:

4. 1. El Centro de Direccin del Sistema Distribuido (CDSD).

La funcin bsica del CDSD es responsabilizarse de las actividades del rea
de planificacin para definir los criterios de gestin del entorno distribuido,
negocindolos con:

La direccin.
Los usuarios.
Los responsables de aplicacin
Los administradores de sistema.

Lo representaremos por el smbolo de la figura.

Ha de ser nico en el mbito de la compaa, pero puede apoyarse a la hora de
establecer los criterios tcnicos en empresas externas especializadas.

4. 2. El Centro de Administracin del Sistema Distribuido (CASD).

La funcin bsica del CASD es gestionar la administracin del sistema, el da a
da, a partir de la las directrices del CDSD. Lo representaremos por el smbolo
de la figura.

Hay un CASD central que puede delegar en CASD locales.

Los CASDs pueden estar subcontratados a empresas
especializadas.
CDSD
CASD

Son funciones genricas del CASD:

Llevar a la prctica, apoyar y supervisar las estrategias de administracin
establecidas por el CDSD.
Gestionar la configuracin en general y la plataforma estndar en
particular.
Gestionar y controlar el sistema distribuido.
Mantener el repositorio de administracin.
Dar soporte y controlar los centros de soporte.

4. 3. El Centro de Soporte a usuarios del Sistema Distribuido (CSSD).

La funcin bsica del CSSD es dar soporte y asistencia a los usuarios del
sistema distribuido. Lo representaremos por el smbolo de la figura.

Los CSSD pueden estar integrados dentro de los CASD o
actuar como unidades organizativas autnomas.

Los CSSDs pueden estar subcontratados a empresas
especializadas.

Son funciones del CSSD:

Dar el soporte a los usuarios a travs de la Hot-Line.
Reuniones planificadas o puntuales con los usuarios.
Recolectar la informacin de la actividad de Monitoring para determinar el
nivel de satisfaccin de los usuarios.

Estos centros se organizan segn un organigrama operativo que se presenta en el
apartado posterior dedicado al soporte a los usuarios.

5. Estrategias de administracin.

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

Recordemos que La Biblioteca de Infraestructura de Tecnologas de Informacin,
abreviada ITIL (del ingls Information Technology Infrastructure Library), es un
marco de trabajo de las buenas prcticas destinadas a facilitar la entrega de
servicios de tecnologas de la informacin (TI). ITIL resume un extenso conjunto de
procedimientos de gestin 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 gua que
abarque toda infraestructura, desarrollo y operaciones de TI.

Pues bien, ITIL propone una estrategia basada en tres bloques de actuaciones:

Gestin de incidencias. Los tcnicos dedicados a este bloque de
actividades slo se preocupar de la recuperacin del servicio e informar
en el repositorio de incidencias de su actividad.
CSSD
Gestin de problemas. Los tcnicos asignados a este bloque analizaran
las incidencias, buscaran las causas y propondrn las soluciones.
Gestin de cambios. Finalmente, los tcnicos de este bloque de
actividades implementaran las soluciones a los problemas.

En cualquier caso, la estrategia en cada entorno es fruto de un anlisis profundo de
las necesidades y los hbitos.

6. La plataforma estndar.

El concepto de plataforma estndar es simple pero potente: definir una forma
nica de instalar y configurar la plataforma bsica del cliente.

La utilizacin de la plataforma estndar permite administrar el sistema distribuido
mejor y ms fcilmente.

6. 1. Definicin de la plataforma estndar.

La definicin de la plataforma estndar tiene dos factores:

Relacin de Componentes: sistemas operativos, redes, hardware,
servidores locales,...
Configuracin de esos componentes.

Dentro de la plataforma estndar debe incluir la conectividad y la ofimtica,
factor este ltimo de gran dispersin. Por desgracia, es habitual que un
documento de ofimtica se cambie de cliente y presente problemas de formato
por la diferencia entres plantillas con el mismo nombre (y tericamente
estndares).

Normalmente hay ms de una implementacin del estndar en el entorno
distribuido en funcin de las configuraciones presentes en los diferentes nodos.
Est diversificacin, hasta cierto punto normal, debe tenerse controladamente y
trabajar con el mnimo de modelos posibles de la plataforma estndar.

El contenido de la plataforma estndar detalla la relacin y configuracin de:

Prestaciones mnimas 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.
Configuracin de red.
Estndar de enviroment de sistema, teclado, impresora y Mouse.
Contenido de los ficheros de configuracin del startup.
Configuracin de los canales serie.
Valores mnimos de los parmetros de configuracin ligados a
rendimiento: bferes, cach, reas de trabajo de las BD, etc.
Usuarios por defecto y sus derechos.
Carpetas y contenido de esas carpetas.
Configuracin y estndares del entorno de ofimtica.
Configuracin por defecto de las diferentes aplicaciones distribuidas.

6. 2. Administracin de la plataforma estndar.

La plataforma estndar es definida por el CDSD y gestionada por el CASD
central. Se guarda dentro del repositorio de administracin.

Dentro del repositorio de administracin debe de existir la informacin de que
plataforma estndar corresponde a cada nodo.

Se define un procedimiento estndar de instalacin y configuracin, elemento
fundamental en una buena gestin de la plataforma estndar ya que su
ejecucin garantiza la regeneracin en caso de degradacin o avera.

Desde el CASD central se ha de hacer llegar a cada nodo la configuracin
estndar que corresponde a su plataforma, el procedimiento automtico de
instalacin y configuracin, las instrucciones para arrancarlo y resolver las
incidencias ms habituales que pueden salir al hacerlo. El soporte ltimo
siempre es el CSSD a travs de la Hot-Line.

Conviene que los procesos para la instalacin y para la configuracin estn
separados y puedan arrancarse independientemente. Si se acta as, el
resultado es ms operativo. Por ejemplo, si hay problemas y se duda del
estado actual de la configuracin es recomendable reconfigurar ejecutando
slo el procedimiento de configuracin. En caso de avera o cada destructiva
del sistema de habr de reinstalar desde el principio. En este caso, el usuario
ha de ser consciente que la configuracin propia sobre la estndar no
catalogada en procedimientos se perder capa vez que se reinstale.

6. 3. Organizacin de la administracin del cliente sobre la plataforma
estndar.

La plataforma estndar de instalacin y parametrizacin del puesto cliente se
instala sobre la plataforma de sistema del puesto cliente. Sobre ella se
construyen dos plataformas ms:

La plataforma de las
aplicaciones distribuidas,
creada junto a los jefes de diseo
de cada aplicacin, y sobre la que
se organiza la explotacin de
esas aplicaciones. Se integra
dentro de la plataforma estndar
y es, por tanto, definida por el
CDSD (junto a los jefes de
diseo) y administrada por el
CASD Central.
La plataforma de usuario, en la
que se incluyen las aplicaciones y
ficheros especficos de cada usuario.

6. 4. Delimitacin de responsabilidades.

La delimitacin y reparto de responsabilidades entre los CASD
y los usuarios se establece en el contrato de administracin
y servicio de un cliente.

Este contrato no es ms que un pacto de los compromisos y obligaciones
que cada parte, usuario y administrador, adquieren. Es de vital importancia, no
Plataforma Estndar
Sistema Cliente
Plataforma
Aplicaciones
Distribuidas
Plataforma
de Usuario

Figura 249. Niveles de configuracin del
puesto cliente

para buscar culpables a posteriori, sino permitir a cada parte prepararse para el
trozo de contrato que asume y saber como hay que actuar en todas las
actividades de la administracin del sistema, desde la instalacin y
parametrizacin al soporte directo a los usuarios.

El contrato debe contener una clusula, bsica, que contemple la existencia
de la plataforma estndar, que hay que explicar y justificar a los usuarios ya
que puede parecerles una intromisin en la intimidad de su ordenador.

El usuario debe entender la importancia, para sus propios intereses, de que la
plataforma estndar 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 recuperacin automtica de forma
anloga a la de la plataforma estndar. Cualquier cosa que haya instalado o
modificado en cualquier parte de las plataformas estndar o de aplicacin 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 Estratgico Distribuido de la Compaa le permita para que el usuario
pueda instalar correctamente su plataforma estndar y para que disponga en
todo momento de procesos de reconstruccin automtica para pasarlos
despus de reinstalar la plataforma estndar.

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 estndar
cuando sea necesario.

Otra clusula fundamental en el contrato es la delimitacin de la
responsabilidad de las copias de seguridad. Es usuario deber entender
claramente que tenerlas siempre al da es fundamental ya que despus de la
reconstruccin de las plataformas siempre habr que instalar los datos de
usuario en el puesto cliente. A est mentalizacin 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 maana. Un consejo,
recomiende a sus usuarios que se habiten a hacer copias, como mnimo, por
la maana.

El contrato administracin y servicio no est casi nunca oficializado y en,
muchas ocasiones no est ni escrito. Sin embargo, mi opinin personal es que
debera estar siempre redactado, consensuado y presentado y aprobado por
Direccin.

7. rea de planificacin.

Las actividades especficas incluidas en esta rea son:

O Coordinacin de las polticas de administracin del sistema distribuido con los
objetivos de direccin para alinearse con la evolucin y el desarrollo del
negocio. Las polticas de negocio y el nivel de servicio necesario actan
de precondiciones.
O Definir el nivel de servicio y de asistencia, en particular delimitar horarios y
condiciones de servicio.
O Definir las estrategias tcnicas de inclusin de los nuevos elementos o de los
cambios que se realizan.
O Intentar conseguir el mejor resultado con el mnimo coste. Este objetivo es
una poltica contina optimizacin de procesos para el aumento de la calidad
y la reduccin de costes. Se parte de:
O La informacin de proporcionada por el anlisis de la gestin.
O La propuesta de los centros de administracin tras el anlisis de
rendimientos.
O La evolucin de la tecnologa.
O Establecer las polticas de distribucin de costes, si la poltica 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 planificacin se concretan en:

O Definir las polticas de administracin.
O Definir las estrategias de administracin.
O Definir las operativas estndares.
O Definir la plataforma estndar.
O Definir las plataformas de las aplicaciones distribuidas junto a los
responsables de aplicacin.
O Pactar y aprobar el contrato de servicio.
O Establecer el ltimo nivel de resolucin de incidencias en el sentido de avisar
a expertos en el tema objeto del problema.

8. rea de administracin de datos.

Los datos son uno de los activos ms valiosos de la compaa ya que incluyen la
informacin y por tanto el conocimiento que tiene de su negocio en todas sus reas:
administracin, productos, mercado, clientes, proveedores, produccin y un amplio
etc.

El abaratamiento de las unidades de almacenamiento y el aumento espectacular de
sus capacidades ha hecho que el la mayora de las empresas los datos
almacenados hayan aumentado de forma espectacular pero en la mayora de los
caos anrquicamente y sin ningn tipo de catalogacin ni administracin solo
siguiendo la conocida teora 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 ms complejos y cambiantes donde conviven inevitablemente los datos
centralizados y distribuidos. Las interrupciones son costosas y las perdidas
impensables. Dicho de otra forma la administracin, y la planificacin de esa
administracin 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
heterogneos. Causa de esa heterogeneidad son bases datos especializadas y de
usuario pero con importancia corporativa en la parte de esquemas lgicos y,
aunque estamos en un mundo donde SQL es el rey, los proveedores presentan
matizaciones importantes en cuanto a esa implementacin, los procedimientos
catalogados no son estndares y hay mucha informacin de intercambio,
configuracin e incluso de soporte en XML. Cada uno es una isla que hay que
integrar. Es una versin nueva y actual de nuestro tradicional Upsizing.

Para administrar esos datos se necesitan polticas 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
heterogneas y de diferentes fabricantes, datos no incluidos en esas bases de
datos como ficheros XML y en una arquitectura distribuida.

Deben primarse al mximo los automatismos y las polticas preventivas ya
que el objetivo es dar el mejor servicio con el mnimo de interrupciones.

Hay que reducir al mnimo el mantenimiento en fro y gestionar en caliente todo lo
que se pueda.

Es posible establecer automatismos en actividades del tipo:

O Gestin de versiones.
O Comparacin de esquemas.
O Nivelacin de esos esquemas.
O Marcha atrs.
O Sincronizacin de datos.
O Recuperar datos.
O Integridad fsica.
O Replicacin y todos sus factores.
O Reorganizacin de ndices etc.

Es necesaria una postura proactiva sobre la tradicional de reaccin ante
problemas.

La administracin 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 polticas de administracin.

La poltica de administracin de datos es marcar pautas y seguimiento en cada
actividad. Se acabar plasmando en una poltica de gestin integrada.

8. 2. Gestin de la localizacin, planificacin de la capacidad y planificacin
de migraciones.

Donde y porque se sitan los datos y que capacidad se le asigna.

8. 3. Gestin de uso.

Para determinar y eliminar entidades y zonas que no se han usado nunca. Este
anlisis lleva resultados que seguro le sorprendern sobre la cantidad de
informacin en esta situacin.

8. 4. Gestin 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 anlisis de la gestin.

El estudio del rendimiento es importante para evitar la congestin de:

La base de datos.
El gestor que la soporta.
La maquina servidora.
La aplicacin, la causa ms frecuente del problema.

Hay que potenciar el uso de recursos de autodiagnstico y autocorrecin, por
ejemplo aumentar la capacidad de la BD automticamente, resolver
inconsistencias de forma desatendida, etc.

Del anlisis pueden implicarse acciones de reorganizacin fsica del tipo:

Colocar las entidades y archivos segn grado de utilizacin. Por ejemplo:
los ms usados con los menos.
Striping de datos accin que consisten en repartir el dispositivo lgico
entre varios dispositivos fsicos para que ms de un cabezal actu sobre
la misma entidad o que la entidad pueda tener un volumen muy grande.
Gestin jerrquica de los almacenamientos colocando lo ms usado en
los dispositivos ms rpidos.

Y actividades de mejora de las aplicaciones del tipo:

Cambios en el diseo o los programas.
Nuevos ndices.
Uso de procedimientos catalogados.

8. 5. Gestin de la disponibilidad de los datos.

Cuando estn disponibles y como se gestionan las alternancias de fuentes en
caliente para mantener los datos siempre accesibles.

8. 6. Gestin de la coherencia, seguridad y el back-up y recuperacin.

En el captulo siguiente hablaremos ampliamente de este tipo

8. 7. Monitoring de datos.

Recogida de la informacin necesaria para el anlisis de la gestin de datos.

8. 8. Gestin de eventos y alertas de datos.

Se incluirn normalmente dentro del cuadro de control de administracin,

9. Actividades del rea de soporte a usuarios.

Los sistemas distribuidos necesitan dar soporte a sus usuarios como cualquier otro
sistema informtico, pero, por su naturaleza, tienen una problemtica diferente
debido a:

O La dispersin geogrfica y, a veces, horaria.
O El nmero de usuarios.
O La heterogeneidad de sus perfiles y formacin.
O La variedad de sus aplicaciones.
O La presencia de ms 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 Dnde se da ese soporte.
O Quien lo da.
O Cundo se da.
O Cmo es el pacto de servicio establecido.

Estos trminos se definen en el contrato de servicio y la gestin de la plataforma
estndar que tratar ms adelante.

9. 1. Organizacin operativa del soporte.

Para cumplir sus funciones el
CASD, los CASDs y los CSSD
se organizan segn un
organigrama operativo cuyo
modelo general se muestra en
la figura. Cada organizacin
especializar este
organigrama segn sus
necesidades.

Los CASDs se organizan
jerrquicamente. El CDSD se
constituye en staff del CASD
central. Cada CASD local da
soporte a la plataforma de su
zona de influencia.
Si la organizacin tiene CSSD
diferenciado del CASD, suele
ser general para toda la
organizacin. 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 ms adelante.

Observe la paricin 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 aplicacin o aplicaciones que se utilizan en ese entorno.

Suele ser una persona no informtica salida de los entornos de aplicacin de la
compaa. Es una persona motivada, con formacin informtica originalmente
emprica 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 ms segn las estadsticas de servicio)
descargando de mucho trabajo a los CSSD.
Central
CASD
CDSD
Local
CASD
CSSD
Local
CASD
Vendedores
Especialistas
de producto
Especialistas
Informticos
Usuario
Avanzado

Figura 250. Organizacin operativa del soporte a usuarios.

La utilizacin de un usuario avanzado como primer nivel de soporte tiene,
adems, 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 tambin Call Center o Help Desk, se basa en que
el usuario llama a un nmero telefnico cuando tiene un problema. Si
hay un tcnico disponible, atiende inmediatamente la llamada. En caso
contrario, se anota para contestarla en cuanto haya un tcnico
disponible. La localizacin 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 tcnico, pero las caractersticas del servicio no cambian
por ese hecho.

El usuario explica su problema y el tcnico realiza el diagnstico. En
funcin de ese diagnostico pueden ocurrir varias situaciones.

En primer lugar, el tcnico puede resolver el problema por si solo con lo
cual la llamada queda cerrada. El nmero de llamadas que el
diagnstico puede cerrar depende de la formacin del tcnico que
atiende la llamada. Aqu se produce el conocido problema de que
tcnicos buenos y formados no pueden atender el diagnstico ya que
deben ser promocionados por bien de la compaa y de su propia
satisfaccin profesional.

Cuando el tcnico no puede resolver la incidencia, debe pasar el
problema a los especialistas quedando la avera pendiente de
resolucin.

Si el diagnstico es avera de hardware, se notificar a los responsables
de resolverla, generalmente el proveedor. El personal de la Hot-Line
deber controlar que la avera se resuelve en los plazos acordados. Hoy
da, la estandarizacin 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 gestin de este tipo de incidencias.

Cuando el diagnstico 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 da las inmensas posibilidades que la
administracin remota proporciona. En caso de que la persona que
realiza el diagnstico no sea capaz de resolver la incidencia, lo normal
es que consulte al CASD y cuando ste no sea capaz de resolverlo, se
avise a los especialistas y proveedores externos.

Si el problema es de aplicacin puede tener un triple origen:

El primer lugar est la parametrizacin de la aplicacin. En este
caso, conviene que el personal de diagnostico disponga de una
buena documentacin y de un mnimo de formacin sobre este
tema para poder resolver un mximo de incidencias.
Una segunda situacin aparece cuando el problema es de operativa
de uso. En este caso, lo normal que se traspase la resolucin al
especialista de la aplicacin.
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 adaptacin del servicio a las necesidades reales de la organizacin
es un trabajo continuo, adems de sufrido y poco gratificante. Para
poder mejorarlo, el CASD central y el CDSD deben disponer de
estadsticas de utilizacin que solo pueden salir de una aplicacin de
soporte que, adems de ayudar a gestionar el servicio en los trminos
que hemos hablado hasta ahora, debe dar la informacin de uso. La
aplicacin de soporte debe aportar sus datos a la aplicacin de
Monitoring.

De esta informacin, y dentro de la actividad de anlisis de la gestin, el
estudio del nmero de incidencias por usuario debe ayudar a detectar
lugares en que hay que hacer actuaciones de formacin o
intervenciones, nunca agradables, de llamada al orden a usuarios no
motivados o histricos. El estudio del nmero de incidencias por tramos
horarios ayudar a adaptar los recursos del servicio a las necesidades
reales. La tipologa de las incidencias ayudar a mejorar los programas
reforzando la aplicacin en aquellos aspectos que presentan ms
incidencias. El estudio de los tiempos medios de resolucin permitir
conocer si los compromisos pactados de tiempo de diagnostico y
resolucin se estn cumpliendo.

Aunque la justificacin bsica del servicio de Hot-Line es ayudar al
usuario ante problemas, es evidente que tambin puede utilizarse para
consultas de operativa, posibilidades del entorno y formacin puntual.

Djeme darle un consejo final en este tema. El perfil del personal de
Hot-line que da el primer nivel de soporte no debera ser
mayoritariamente informtico, sino administrativo, con ilusiones
informticas, eso s.

Con ello conseguir dos importantes objetivos:

Qu el personal de hot-line no se le queme ya que un informtico
arde rpidamente en este puesto: ha estudiado informtica para
algo ms que resolver problemas y aguantar usuarios
desagradecidos y desagradables (aunque muchas veces tengan
motivos para serlo).
Que se trabaje con documentacin y que los programas de
administracin funcionen. Obviamente, como el personal
administrativo no tendr formacin informtica avanzada, no podr
seguir atajos que despus 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 formacin de los usuarios y asesorarles en temas como ofimtica,
agendas electrnicas, correo electrnico, etc.

Las reuniones, adems, permiten que usuarios y tcnicos 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 lnea.

Puede ser de varios tipos:

9.3.1.A. Generales.

E incluidas en la instalacin de los productos de sistema. Por
ejemplo, las posibilidades de Windows y los productos de Office.

9.3.1.B. De operacin estndar.

Vlidas para toda la instalacin.

9.3.1.C. De uso de las aplicaciones.

Son desarrolladas e incorporadas en el momento de la instalacin.
Le recomiendo que para desarrollarlas utilice herramientas estndar.
Si desea desarrollar software especial pinseselo dos veces; hgalo
slo cuando sea claramente justificable y cree siempre componentes
reutilizables.

Particularmente no creo nada en este tipo de ayudas. Y la recusacin
no viene de la calidad tcnica sino del uso. Las que nos vienen hechas
no nos cuestan nada, pero a nivel del usuario son ininteligibles y es
dificilsimo encontrar rpidamente lo que buscas. Las que creamos
nosotros, cuestan un montn de esfuerzos y dinero, y como son
internas, el usuario coge antes el telfono para pedir soporte a la Hot-
Line que se pone a navegar con la ayuda.

9.3.2. Definicin de procedimientos de actuacin.

Mtodos, consejos, operativas para detectar, diagnosticar y resolver
incidencias y problemas. Esta informacin va enriquecindose
continuamente con la experiencia del da a da.

Definir procedimientos supone:

Reconocimiento de problemas e incidencias.
Seguimiento y anlisis de esas incidencias.
Aislamiento de los problemas.
identificacin y tipificacin.
Resolucin guiada de los problemas tipificados.
Criterios para decidir cuando se pide ayuda al escaln superior de
asistencia.

Y no olvide que es fundamental realimentar las facilidades de soporte
con los resultados de la experiencia de cada da.

9.3.3. Estandarizacin 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 estandarizacin de operativas,
dilogos, mensajes de error, recuperaciones, etc. para vacunarnos
contra incidencias. Pienso firmemente que este punto es bsico.

9. 4. Nivel de aceptacin del servicio.

Si aspira a obtener un 100% de usuarios contentos, olvdese. 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 razn es muy alta.
Adems, como su servicio seguro que tiene problemas (puntas, tiempos
de resolucin, incidencias perdidas, y un amplio etc.) siempre habr algo
a lo que esos usuarios podrn agarrarse para atacarle. Solo conozco una
defensa: demostrar que su estadsticas de problemas son repetitivas y
por encima de la media. Necesitar, sin embargo, un sistema de
Monitoring fiable si desea usar esta informacin.
Los que se quejan constructivamente. Los notar porque sus quejas
aparecen en ms de uno de ellos y su tono suele ser constructivo, si no
estn muy quedados, claro est.
Y finalmente, los que realmente tienen razn porque, de una forma u
otra, han sufrido carencias en el servicio, en tiempo de respuesta o en
calidad de servicio.

Para conocer la opinin se estos usuarios organice de forma sistemtica una
actividad de Monitoring encaminada a conocer el grado de satisfaccin. La
forma de hacerlo es a travs de una Encuesta de Calidad de Servicio
peridica y lo ms codificada posible.

Para conseguir una aceptacin razonable de la calidad del servicio es bsico:

La rapidez en el diagnostico.
El seguimiento de las resoluciones en los tiempos pactados
Potenciar la resolucin automtica de incidencias.

Organice el seguimiento como una actividad ms del anlisis de la gestin. 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 informtico debe ser medida aplicando mtricas.
A partir de esas medidas hay que analizar los resultados y conseguir gestionar y
planificar mejor la administracin.

En los sistemas distribuidos esta actividad es especialmente importante ya que,
como hemos hablado en otros captulos, la dispersin de elementos hace muy
complejo saber en que puntos hay que actuar para mejorar el funcionamiento.

Inventario de activos, rendimiento, capacidades, parametrizacin, instalacin y uso
han de ser medidos y modelados en funcin de la evolucin del sistema.
Obviamente, todos estos datos han de salir del sistema de Monitoring.

Las actividades bsicas de esta rea son:

O Monitoring o recoleccin de informacin.
O Medir.
O Recoger las mediciones (recolectar en el argot).
O Transformarla.
O Integrar la informacin centralizndola en el archivo nico.
O Catalogacin por temas.
O Archivar en el repositorio de administracin.
O Gestin del repositorio.

A partir de aqu se podrn disparar las actividades de anlisis de la actividad que
permitir detectar los puntos dbiles y proponer las mejoras necesarias en la
actividad tcnica y en la econmica (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 automticas. Cada elemento de la
plataforma, los clientes, los servidores, los agentes y el transportista habran de
disponer de recursos para monitorizar su actividad.

Aqu, y una vez ms, surge la pregunta: sale a cuenta la inversin en un sistema
de Monitoring para mejorar el rendimiento del sistema? Lo que me puedo ahorrar,
retornar la inversin en la implementacin del sistema de Monitoring?

La respuesta, como siempre: no hay varitas mgicas, depende del sistema y de la
organizacin y hay que estudiar cada caso. Pero en este tema, yo soy determinista:
medir siempre es bueno. La experiencia de cada da me ha enseado que tarde o
temprano, la aplicacin de mtricas a un sistema distribuido siempre acaba
mejorarlo notablemente el sistema en su conjunto.

11. 1. El modelo de Monitoring.

El modelo o arquitectura del Monitoring se ha de montar sobre la estructura
operativa del soporte del CASD. Es, por tanto, de arquitectura bsicamente
jerrquica.

La actividad se monitoriza y se mide in situ. El primer paso es transformarla a
un formato comn. Normalmente se generan archivos secuenciales, si es
posible en formatos XML o tablas en bases de datos locales.

La informacin medida se concentra en los centros de administracin locales y
de all se traspasa al Central. El objetivo bsico del modelo es hacer llegar la
informacin que necesitan a los centros de administracin y direccin. La
plataforma de transporte de la informacin recogida suele ser el servidor de
correo a quien se le entrega una copia secuencial de los ficheros (locales o
remotos) donde se rene la informacin recogida.

All se cataloga y se archiva en una base de datos o archivo de conocimiento
sobre los que se realiza el anlisis.

11. 2. La actividad de medir.

El componente o lugar de trabajo va generando una informacin secuencial
que se graba en un fichero o en una tabla de una BD local, pero siempre con
filosofa 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 informacin medida ha de reflejar los datos bsicos del elemento y contiene
las caractersticas, resultados, cliente y tiempos de trabajo.

La generacin 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 informacin.

El log de actividad puede tener dos formatos:

Exhaustivo. Normalmente se activar para realizar estudios puntuales.
De paso, con los datos mnimos. Normalmente estar permanentemente
activado y dar la informacin mnima para el anlisis peridico.

Planteemos un ejemplo clsico: la monitorizacin de la actividad de un servidor.
Cuando el servidor arranca anota el da, 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 monitorizacin de
su actividad puede mejorarse midiendo sobre la cola, adems de los datos
anteriores, la fecha y la hora de la anotacin de peticin de servicio.

Si el servidor es remoto al cliente, el cliente puede anotar la hora en que ha
lanzado la peticin y la hora en que le ha llegado la respuesta (informacin que
puede ser irrelevante s la comunicacin es sncrona). Este dato permitir
valorar la eficiencia del transportista.

Estos datos suelen anotarse sobre un fichero secuencial y transportarse ms
tarde a una base de datos donde se dispone de herramientas para obtener
reportes y grficos con los que analizar la actividad.

Es fcil derivar de informacin del tipo:

Tanto por ciento de ocupacin por cada cliente.
Tiempo de transporte de las peticiones.
Tiempos de espera del cliente y tiempos medios de respuesta.
Distribucin de peticiones por tramos horarios, etc.

Del anlisis de est actividad pueden derivarse acciones de mejora del tipo:

Localizacin del servidor cerca de los clientes de mayor actividad.
Arrancar ms 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 ocupacin de discos, cogestin
de la plataforma de conectividad, ocupacin de CPU o memoria, etc. si no se
usa software especfico de DSM, se suelen implementar y disear agentes que
peridicamente 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
aplicacin de soporte, normalmente por un proceso peridico. Una opcin
vlida es no integrar esta informacin con el resto de datos, realizando la
gestin 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 satisfaccin de los usuarios.

Esta encuesta puede realizarse sobre un impreso WEB u ofimtico y a partir de
aqu incluirlo en la recolecta del proceso de Monitoring.

Estos impresos tendrn dos partes:

Valoracin cuantitativa. Por ejemplo, valorar de 1 a 10 la opinin sobre
el cumplimiento del tiempo de respuesta.
Valoracin subjetiva. Conviene aadir un apartado de varios para que
el usuario incluya de forma textual otras opiniones adicionales que sean
de su inters.

El anlisis de gestin ligado a la calidad de servicio se establece en dos
niveles:

Cuantitativo: encuestas por debajo de mnimos. Se confrontan con los
datos de las mediciones automticas y la medicin del soporte
deduciendo si el problema es de servicio o de usuario y actuando en
consecuencia.
Revisando los comentarios subjetivos. Es la tarea ms ardua pero que
ayuda muchas veces a descubrir cosas que ni sabamos que pasaban.
Puede generar la incorporacin de nuevas valoraciones subjetivas.

12. Registro del Inventario de activos tecnolgicos.

Se registrar descripcin, 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 automtico.
O Facturas de compra y/o servicio.
O Albaranes del servicio de soporte.

Hay que intentar inventariar el bien, no su composicin 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 nmero de serie de esos componentes.

13. La gestin del repositorio de administracin.

Para conseguir una buena gestin de los recursos del sistema distribuido es
necesario, como ya hemos citado reiteradamente, disponer del repositorio de
administracin donde se archivan el inventario de activos y los resultados del
inventario y del Monitoring:

O Catalogo de servicios.
O Aplicaciones.
O Datos de rendimiento
O Datos de soporte, etc.

El punto de partida es referenciar, asignar un nombre lgico (Naming), catalogar
(Directory) y registrar las caractersticas y parmetros de cada uno de los recursos.

La responsabilidad de la estructura, contenido y formato del repositorio es del
CDSD. La gestin de los valores de la informacin codificada dentro del repositorio
es del CASD Central, aunque delegar puntualmente en CASD locales.

La implementacin 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 integracin. Por ejemplo,
los recursos lgicos de las impresoras los gestionar a travs de los
administradores de impresoras, los recursos que corresponden a los directorios
compartidos a travs de las herramientas de directorios y ficheros, la seguridad de
BD a travs de sus gestores, la de los ficheros a travs de las herramientas de
gestin de directorios y ficheros, los clientes y servidores se catalogarn en
directorios del gestor de ficheros, etc.

Y, lo ms 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 opcin es utilizar una aplicacin de gestin del conocimiento.

La mejor solucin es hoy da, utilizar los recursos de los paquetes de administracin
integrada que se han citado en la primera parte, que, por cierto, no son nada
baratos.

Djeme ser, por un momento, pesimista. Pocas veces se lleva un repositorio
medianamente vlido ya que nadie aprecia las ventajas y solo ve los costes.

14. Area de Anlisis de la gestin: Auditoria del Outsourcing

Las actividades del rea de gestin, culminacin 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 especfica: la auditoria de los
procesos de Outsourcing. En la figura de la derecha se muestra un ejemplo de
cmo actuar en esta rea.

Cualquier actividad de
Outsourcing ha de estar
acordada en contratos entre
proveedor y cliente. En la
redaccin de estos
contratos han de intervenir
los departamentos
Informtico y Legal de
ambas partes. Los
contratos deben ser
asumidos por la Direccin
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 sofistificacin que haga imposible la fiabilidad de la medicin y por tanto
la aplicacin de las penalizaciones.

No hace falta que aada que la medicin en fase de explotacin de los indicadores
se obtiene del rea de Anlisis de la Administracin del Sistema.

Cliente
Proveedor
Servicios
Contratos
Pactos de nivel de Servicio
Indicadores del nivel de
servicio pactado
rea de Administracin
Medida de los Indicadores del
nivel de servicio pactado
Auditoria Externa
Comparacin para el
seguimiento del nivel de
servicio pactado

Figura 251. Auditora de los procesos de Outsourcing.
15. rea de costes.

Ser fundamental detectar las tareas intensivas en tiempo. Recordemos que una
tarea puede ser intensiva en tiempo por dos razones:

Por que dure mucho tiempo.
Por que se repita muchas veces.

Una vez detectadas habr que definir procesos automticos para resolverlas. En el
segundo de los casos, un valor aadido importante ser la eliminacin de errores
que la reiteracin de un mismo proceso puede producir.

Ser tambin 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 ms 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 dinmico:
O Transacciones.
O Soporte, etc.

16. Anlisis de la gestin de errores.

Esta actividad del rea de anlisis consiste en analizar las causas de los errores
producidos en el sistema y buscarle solucin.

Bsicamente los errores se acaban clasificando y analizando en reas.

O Errores en la obtencin de servicios. Ms adelante, y en el capitulo de
consistencia hablaremos como. Permite detectar puntos dbiles por diseo,
congestin o plataforma y tomar las acciones oportunas para resolverlos.
O Errores de operativa. Afectan bsicamente al rea del usuario y los
programas cliente. Llevan a detectar:
O Fallos de formacin, 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 gestin y control.

La gestin del sistema se realizar a partir de herramientas de DSM o recursos
proporcionados por el anlisis de administracin de cada una de las aplicaciones
distribuidas.

La configuracin de la plataforma se hace a travs de los recursos para:

O Planificacin de procesos y servicios.
O Automatizacin de eventos.
O Planificacin y gestin de cambios y configuraciones. En particular la
administracin de las fichas de enviroment de los servicios.
O Gestin de problemas.
O Gestin de recursos de almacenamiento.
O Gestin de activos y directorios.
O Administracin de clientes y servidores y localizacin de recursos de las que
se habla especficamente ms adelante.

Nunca debe olvidarse que lo importante es la aplicacin, que es el elemento que
realiza el trabajo, y no la infraestructura en s que est a su servicio.

Una vez el sistema en explotacin, 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 explotacin de
los procesos de negocio y sus incidencias.

El cuadro de mandos de un sistema distribuido es una extensin y una
generalizacin de un concepto tan antiguo como la informtica y que, como
ensima versin de nuestra mana de inventar nombres para conceptos
similares, se ha llamado de diversas formas: control de objetivos, gestin del
rendimiento, etc...

Recordemos que el cuadro de mandos del sistema distribuido tiene dos partes
que ha veces se solapan:

Cuadro de mandos de explotacin o administracin (extensin del mbito
de clsico centrado en los negocios).
El cuadro de mandos de seguimiento del estado del negocio.

Un sistema distribuido, que como tal permite disponer en lnea de un porcentaje
altsimo de la informacin y los recursos de la empresa, permite que los
cuadros de mandos dispongan de recursos y actitudes que de los que no se
disponan anteriormente.

La alta disponibilidad permite, entre otras ventajas, disgregar la
complejidad de organizaciones grandes. Se manifiesta en dos grandes
lneas:
o Volumen e instantaneidad de la informacin.
o Usuarios responsables conectados, lo que permite traspasar la
responsabilidad a primera lnea.
Poder trabajar con planificacin 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 funcin de la evolucin de la situacin.
Sin olvidar, obviamente, que los objetivos variables han de estar
alineados con los fijos. Por ejemplo, detectamos una desviacin
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 planificacin, normalmente anuales.
Pasar de actitudes reactivas a proactivas, probando los efectos de las
decisiones antes de ponerlas en prctica.
Aumentar la trasparencia.
Disminuir los riesgos.

17.1.1. Filosofas de integracin.

Existen dos formes bsicas de consolidar el cuadro de mandos que
pueden utilizarse de forma conjunta:

17.1.1.A. Esttica.

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 actualizacin tan rpida como sea
posible, mal llamada, en mi opinin, DW en tiempo real.
Sistema de gestin integrada de la informacin Empresarial.

17.1.1.B. Dinmica.

Basada en utilizar y combinar les tcnicas:

Los procesos que construyen el cuadro de mandos van a
buscar la informacin a las fuentes originales, idealmente con
tcnicas SOA y agentes en la zona del cuadro de mandos.
Web Services, cuando los datos estn en terceros. No deja
de ser un caso especial del anterior.
Las aplicaciones originales envan los datos al cuadro de
mando, frecuentemente con agentes o un proceso de
recoleccin.

17.1.2. Cuadro de mandos de explotacin o administracin.

El cuadro de mandos de explotacin, conocido tambin como cuadro de
administracin, puede ser definido por los diseadores informticos
junto a los administradores de sistema consultando a los responsables
de explotacin de cada una de las aplicaciones.

Reflejar la situacin de la explotacin en caliente de temas como:

Mapa de comunicaciones:
Estado de comunicaciones.
Nodos con problemas.
Mapa de negocio.
Estado de los procesos de negocio.
Estado de flujo de archivos.
Control de los procesos Bach.
Control de llegada.
Estado de ejecucin.
Control de incidencias pendientes de resolver.
Estado de los procesos de replicacin.
Situacin de los back-ups.
Integrar el centro de errores.
Incidencias sin resolver de Hot-Line.
Etc.

Observe que dentro del cuadro de mandos de explotacin del sistema
distribuido hay dos visiones:

La de sistema, que acostumbra a ser nica.
La aplicacin para el responsable de explotacin de cada aplicacin,
que depende de la organizacin de cada compaa y puede ser
personal no informtico. ES habitual que esta parte sea
responsabilidad de los usuarios avanzados de cada entorno.

Le recomiendo que haga un diseo nico y especialice por la
autentificacin de cada usuario.

De hecho hay funciones que ya se podrn pensar en este momento y
otras, bsicamente en el mbito de los procesos de negocio, que
aparecern despus de la integracin de la parte cliente.

Para obtener el cuadro de mandos hay que potenciar los
procedimientos automticos que acaben alimentando un Framework
que consolide la informacin.

Las funciones del cuadro de mandos deben visualizarse en funcin del
perfil del usuario identificado. Esta sencilla posibilidad permite montar
cuadros de mandos por lneas 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 descripcin.

Pueden definirse estados del sistema a controlar y asociar un semforo
a cada uno de ellos. A partir de aqu la informacin ser jerrquica.

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 lnea se colocar en rojo.
Haciendo doble clic sobre el semforo se obtendr una coleccin de
semforos asociados a cada uno de los nodos de la plataforma de
comunicaciones que nos afinarn la informacin.

Otro ejemplo puede ser la recepcin diario de los ficheros de ventas de
las tiendas de una organizacin de venta directa al cliente. Se asocia un
semforo al proceso y se define que si, por ejemplo, a las 9 de la
maana del da siguiente quedan an locales por enviar la informacin,
se coloque el semforo en mbar y si a partir de las 12 todava hay
cosas pendientes se coloque en rojo.

En segundo nivel se puede asociar un ticket mutihoja a cada tipo de
informacin 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 conformacin de documentos de stock
de un nodo donde hay un almacn. Si pasado un da de la fecha de
llegada el albarn est por confirmar el semforo del estado se coloca a
mbar y pasado 2 das a rojo.

Cada aplicacin debera, en su diseo de administracin, incluir su
informacin en este Framework. No hace falta decir que cada caso se
habr de disear teniendo en cuenta sus propias caractersticas y que
la personalizacin a travs 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 disear el cuadro de mandos de seguimiento del estado del
negocio los diseadores necesitan conocer el mapa estratgico del
negocio, donde direccin reflejara los objetivos a cubrir por cada
persona y/o departamento de la compaa.

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 debera comparar el total de venta previsto con el
cubierto, y los costes de personal y materia prima actuales respecto a la
previsin objetivo. Ser bueno incluir porcentajes y cdigos de colores
del estilo:

Verde: objetivo en vas de cubrirse.
mbar: vamos por debajo.
Rojo: vamos muy por debajo.

Cuando una unidad de ventas est en rojo se podra enviar un aviso a la
central.

Obsrvese que la idea del cuadro de mandos del negocio y el de
explotacin es en el fondo la misma. As, todo lo que hemos dicho y
diremos para el cuadro de mandos de explotacin es traspasable al
cuadro de mandos del negocio.

17. 2. Consola nica

Desde donde se puede acceder de forma remota a cualquier punto del sistema
distribuido.

Suele integrarse en el cuadro de control.

Ha de permitir dos filosofas:

Pantalla compartida, tipo PC Anywhere
Entrada sin interferir con el trabajo habitual del nodo, tipo Terminal
Server.

18. Caractersticas de las actividades de Administracin de clientes.

La administracin 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 intervencin absoluta sobre la plataforma los que es
inviable e impopular.

Para resolver este dilema y librarse de la tenaza, existen tres lneas de actuacin:

O Estandarizacin controlada de la plataforma mediante la definicin de una
plataforma estndar.
O Delimitacin de responsabilidades con el usuario.
O Administracin remota.

A continuacin desarrollaremos algunos de los puntos de este apartado.

19. Administracin de servidores.

Los servidores pueden estar distribuidos por toda la organizacin pero, a pesar de
ello, la responsabilidad de la administracin es siempre del CASD Central, el cual, a
efectos operativos, puede delegar en el CASD local. En particular, la
parametrizacin 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 caractersticas del servidor lo requieren hay que prever visitas de
mantenimiento preventivo o procedimientos automticos, de los que ya hemos
hablado anteriormente, para hacerlo, Las visitas no necesariamente fsicas: no
olvide las inmensas posibilidades de la administracin remota.

Para llevar una buena administracin de servidores es necesario:

O Llevar un inventario fiable y referenciado de los servidores, normalmente
dentro del repositorio de administracin.
O Documentacin fiable y precisa del contrato de software del servidor,
incluyendo de forma especfica la parametrizacin 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 gestin remota.

20. Gestin remota y desatendida de clientes y servidores.

Ya hemos hablado suficientemente de la importancia de la administracin remota
que permite el acceso in situ a clientes y servidores. Sencillamente fundamental.

Pero, adems de la gestin remota, la dispersin y cantidad de usuarios, es
necesario montar procesos de administracin automtica.

Para la gestin desatendida ya hemos visto herramientas a lo largo de los captulos
anteriores:

O Procesos de checking automticos.
O Logs de trabajo.
O Recuperaciones automticas y/o iniciadas por el usuario, etc.

Montarlas es rentable hasta en instalaciones muy pequeas en las cuales disponer
de un servicio de administracin consolidado puede ser inviable econmicamente.

Un ejemplo de proceso de checking automtico puede ser el siguiente, pensado
para evitar problemas de disco lleno:

O Cuando la mquina arranca, se accede al nivel de ocupacin del disco.
O Si la ocupacin es superior a la mxima de alerta, se enva un mensaje de
aviso al CASD.
O Si la ocupacin es superior al mximo de parada, es suspende el arranque, se
avisa al usuario y se enva un mensaje de emergencia al CASD. Si el sistema
es crtico y no puede pararse se deben disear procesos automticos de
recuperacin como, por ejemplo, la limpieza de las reas de trabajo y
eliminacin de datos histricos con la caducidad superada.

Observe que los procesos de checking deben montarse, siempre que sea posible,
como piezas reutilizables para ms de una aplicacin.

21. Localizacin de recursos.

A efectos de administracin, la localizacin 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 diseo y los criterios de administracin del sistema dejarn los recursos lo ms
distribuibles posible: es decir, independientes de la plataforma.

La gestin de la localizacin de recursos es un tema muy disperso. El CDSD habr
de establecer criterios y el CASD y los responsables de aplicacin debern decidir
la localizacin de los recursos en las etapas del diseo como hemos hablado en los
captulos anteriores. Esta localizacin inicial deber optimizarse con el anlisis de
los primeros resultados del arranque de la explotacin. La localizacin de recursos,
adems, deber adaptarse a la evolucin de la organizacin y de la tcnica y a los
resultados de los estudios de rendimiento de las actividades de Monitoring.

Aunque, como ya hemos dicho antes, la localizacin es un tema muy disperso,
recuerde todos los criterios de localizacin que hemos visto en captulos anteriores
y que no voy a repetir aqu.

En cualquier caso, debe escogerse el modelo de ejecucin ms 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 estn, sus polticas de
uso y explotacin, su rendimiento, su utilizacin 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 ms que una aplicacin de los procesos del rea de
dministracin 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 produccin, para administrar, en el concepto amplio de la palabra.

Podemos aprovechar herramientas y plantearnos la solucin en el mbito del
diseo de la administracin 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 informacin en tiempo de produccin y la envan al centro
de mando del sistema distribuido. All se gestionan como cualquier otra actividad de
Monitoring.

23. Estrategias de actuacin en la administracin.

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
administracin no est sobre dimensionado, son demasiado frecuentes las
puntas que desacreditan el servicio de administracin.

23. 2. Administracin desde el usuario.

El usuario se guiar por manuales, guas y procedimientos, pero intentar
resolverlo solo cuando tenga el problema acudiendo a los CASD slo en casos
extremos.

Puede ser una opcin muy vlida que supone:

Un esfuerzo fuerte de normalizacin.
Alta probabilidad de llegar a incompatibilidad de plataformas.

Puede utilizarse soporte de terceros, que el usuario contratar o no
directamente.

23. 3. Administracin remota.

Desde los CASD se llega a todos los elementos por administracin remota.

23. 4. Que le recomiendo.

Difcil cuestin a la que me atrevo a contestar solo por los resultados de mi
experiencia:

23.4.1. Soporte de la plataforma y distribucin e instalacin del software de
aplicacin:

Administracin remota. Recuerde, sin embargo, que entre un 20% y un
30% de las actuaciones necesitan soporte local.

23.4.2. Parametrizacin y soporte del software de aplicacin:

Administracin de la gestin desde el usuario pero con un servicio de
apoyo remoto a partir de los problemas de nivel medio.

24. Repercusin del coste.

Es bueno que es usuario tenga idea de lo que cuesta darle servicio.

Nada ms dejo el tema en el aire. Decida si en su organizacin conviene o no
repercutir del coste del soporte al usuario.

25. Clasificacin de las actividades de administracin por su naturaleza.

Las actividades de administracin de los sistemas distribuidos pueden clasificarse
desde una visin no de servicio sino de naturaleza en cuatro grandes disciplinas:

O Catalogacin, Instalacin y Configuracin.
O Gestin 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 perifricos.

Esta relacin en dos dimensiones suele
representarse con el cubo de la figura. Dentro de
cada celda se incluyen una o varias actividades
de administracin. A partir de aqu se puede
obtener una clasificacin.

Le dejo como ejercicio (muy evidente) que
clasifique las actividades de detalladas en la
primera parte dentro de cada celda. EN mi opinin
es mejor trabajar con la visin de servicio.

26. Diseo de la administracin del sistema.

Se hace muy difcil proponer una metodologa sistemtica y completa para
desarrollar el diseo de la administracin del sistema pero podemos intentarlo en el
diagrama de la figura.

Grupos de
actividades de
administracin
Clientes
Servidores
Middleware
Conectividad
Hardware y
Perifricos
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. Clasificacin de las
actividades de
administracin
Diseo de Administracin
Diseo
Consistencia
Funciones de
DSM
Identificar lo que falta
Diseo e
Implementacin
Plan de
Integracin
Monitoring
Definir funciones
Diseo e
Implementacin
Procesos
intensivos en
tiempo
Identificacin
Diseo e
Implementacin
Cuadro de
mandos
Cuadro de mandos
para el seguimiento
del negocio
Diseo e
Implementacin
Cuadro de mandos de
explotacin
Consensuar
contenidos
Mapa
Estratgico
del negocio

Figura 253. Diseo de la administracin de sistema

27. Que dice la experiencia....

Montar un sistema de administracin y soporte como el que hemos visto, y
completaremos en el captulo siguiente, es caro de establecer y gestionar. No tanto
por el importe en s, si no porque es un coste fijo.

Hoy da, todas las compaas usan la informtica a tope para minimizar costes y
ganar calidad de servicio. El coste de parada por avera o falta de soporte es por
ello muy alto y, aunque es muy difcil de valorar, seguro que justifica los costes de
organizar un mnimo sistema de administracin.

Sin embargo, decidir cual es la mejor opcin es complicado. La tarea de los
diseadores y administradores para conseguir una relacin prestaciones/costes de
eficiencia ptima es muy difcil.

Siempre esta justificado, y lo que es ms importante, sale a cuenta, trabajar con la
idea de la plataforma estndar.

Disponer de una completa ficha de configuracin de cada servicio es primordial.

Administrar con recursos propios, y delegar en terceras compaas especializadas
en soporte es una muy buena solucin. Lo mismo que apoyarse en compaas
especializadas a la hora de establecer polticas basadas en las posibilidades del
sistema. Esto ltimo evita el coste de reciclaje tcnico en compaas pequeas y
medias. En este sentido, si la estandarizacin es muy alta, un sistema posible es
que los usuarios contraten el soporte directamente a compaas cercanas a su
situacin geogrfica. Sin embargo, a mi no me parece la mejor solucin hoy da con
las extraordinarias posibilidades de administracin remota disponibles, las use Vd.
o las compaas a las que subcontrate.

Normalizar operativas, y utilizar al mximo los estndares de mercado, es otro gran
recurso.

Y, finalmente, hoy da si no dispone de administracin remota mntela lo ms
rpido que pueda. Y mantngala siempre con la plataforma de comunicaciones ms
rpida que la evolucin de las prestaciones versus costes le permita.

Diseo e Implementacin de Actividades de
Administracin de Sistemas.

1. Introduccin.

En el captulo anterior hemos revisado las polticas de administracin. Este captulo
est dedicado a explorar algunos de los componentes para disear e implementar
las actividades necesarias para desarrollar esas polticas.

Como ya se ha dicho anteriormente, la mayora de las actividades de
administracin han de ser apoyadas por las herramientas de DSM y el diseo ha de
complementar aquellas actividades a las que no llegue aquel.

Son objetivos adicionales de este captulo es:

O Presentar diferentes estrategias para aquellas actividades que tienen un
tratamiento claramente diferencial dentro de un entorno distribuido.
O Presentar posibilidades de implementacin de herramientas pseudo-DSM
cuando el entorno DSM no las tenga.

Recuerde que las estrategias de las que hablaremos en esta seccin se montarn
ms fcilmente y/o quedarn obsoletas a medida que los estndares de DSM+NOS
sean ms potentes y amplios.

2. Captura de las direcciones variables de IP.

Es frecuente que las direcciones de IP varen en cada conexin cuando la
plataforma de comunicaciones contratada en cada nodo no garantiza IP fija.

Si la IP vara 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 telfono al centro para averiguarla sobre la
mquina.

Y la respuesta deber drsela un usuario que es probable que no sepa donde
buscarla. Y, an en el mejor de los casos, se perder un tiempo precioso y con
impacto directo sobre el coste del servicio de soporte.

La direccin IP estar sobre el registro de cada nodo en el repositorio de
administracin. Bastar un simple proceso, que cada vez que arranque el nodo
enve su IP al centro de administracin para solucionas este problema.

Para implementar esta actividad de administracin puede darse diversas soluciones
tecnolgicas a partir de un cliente back-ground que se arranca cada vez que se
levanta lnea y que enva a la central la informacin:

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 administracin que recibe la informacin y
modifica direccin del nodo.

3. Copias de Seguridad (Back-up y Restore).

El sistema de copias de seguridad ha de establecer procedimientos de back-up y
restore para el total de la arquitectura de datos distribuida. Como ya se ha hablado
anteriormente, el problema no es trivial y adicionalmente, tiene que garantizarse la
igualdad de nivel entre todas las copias de los nodos de forma que en caso de
recuperacin pueda garantizarse la coherencia de todos los datos.

El diseador 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 mxima de los dispositivos de los dispositivos de back-up
puede llegar a ser una gran limitacin. Para hacernos una idea, revisar
unos nmeros de capacidad necesaria: en un sistema de 50 usuarios
(pequeo) en el cual cada usuario tiene asignado 100MB de disco (no
demasiado), la capacidad total del dispositivo de back-up debera ser de
50 * 100 = 5000MB (5GB).

3.1.2. Tiempo necesario para hacer la copia.

Si el tiempo necesario para hacer la copia en fro (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 diseo de administracin debe preverlo.

Una opcin vlida para resolver este problema es hacer copias en
lnea (on line) con discos espejo (mirrors). Si son removibles, pueden
utilizarse como copias de back-up fuera de lnea (off line)

3.1.3. Dispersin de lgica de informacin.

Del condicionante derivado de la dispersin de informacin 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. Dispersin geogrfica.

En paralelo al punto anterior, supone la dispersin fsica, y muchas
veces, comunicaciones lentas entre los nodos.

3.1.5. Diferencias de calendario y horario.

Tambin 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
segn seis coordenadas: calendario, momento, lugar, rotacin, almacn y tipo
de gestin. La estrategia se establecer determinando un criterio para cada
coordenada.

Por ejemplo:

rea: datos de usuario.
Calendario: cada da.
Momento: una vez al da, a las 8 de la tarde.
Lugar: los servidores departamentales.
Rotacin: se guardan dos generaciones.
Almacn: una caja de seguridad ignfuga.
Tipo de gestin: 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:

Informacin centralizada.
Informacin departamental.
Informacin de usuario.

Y tres reas:

Programas y tablas de parametrizacin.
Ficheros con volatilidad mnima (los productos acostumbra a ser un
buen ejemplo).
Datos con volatilidad alta.

3.2.2. Gestin de cada una de las reas.

3.2.2.A. rea de programas.

Se mantendr una copia de seguridad que nada ms se actualizar
cuando haya un cambio de versin o de configuracin. La
recuperacin se har fcilmente volviendo a copiar los programas
desde la copia. Si el tiempo no es muy grande, tiene tambin el
recurso de no hacer copias y reinstalar en caso de cada.

3.2.2.B. rea de datos no voltiles.

Se actualizar la copia slo 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
recuperacin de unas pocas tablas no voltiles colisionar con el
nivel de datos de todas las tablas voltiles! Utilice siempre el
segundo mtodo y, si es necesario, haga la recuperacin con los
recursos de recuperacin de la propia base de datos.

3.2.2.C. rea de datos.

Es la parte ms 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 rotacin (hablaremos ms tarde de este aspecto) que
el CASD debe pactar con los responsables de aplicacin.

Aqu tiene tambin la opcin de utilizar los recursos de la base de
datos y copiarla toda como un fichero ms. La decisin se la habr
de estudiar en funcin de cada caso. Sin embargo, y sabra
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
tambin utilizar los de restore para recuperacin.

3.2.3. Responsabilidad de cada mbito.

3.2.3.A. Informacin centralizada.

Supone siempre la presencia de bases de datos y en algunos casos
incluso heterogneas. La responsabilidad de su administracin es del
CASD. Estas bases de datos son potentes en recursos y
herramientas de administracin y son muy fciles de administrar.

3.2.3.B. Informacin departamental.

Supone, normalmente, la coexistencia de bases de datos
departamentales y de ficheros convencionales. Como ya hemos visto
anteriormente, existe el concepto de servidor lgico que puede estar
implementado en ms de una base de datos, situadas en una o ms
mquinas, y que puede tener problemas de heterogeneidad.

Remarcar, finalmente, que lo normal es que la informacin
departamental incluya ms de un Dpto. con informacin compartida
y/o individualizada por Dpto.

La responsabilidad de su administracin 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 informacin departamental.

3.2.3.C. Informacin de usuario.

Formada por ficheros convencionales (mucha ofimtica) y
espordicamente alguna base de datos propia tipo Access.
Fsicamente la informacin 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 informacin es del
usuario.

Hay dos estrategias:

La copia se saca sobre la mquina del usuario (responsabilidad
total el usuario).
La informacin o esta en el servidor o se enva 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 da y la hora (momento, factor del que hablaremos a continuacin)
en el cual se hacen las copias.

Conviene establecer un calendario con mltiplos naturales: cada da,
cada dos das, cada 6 horas, por la noche, etc.

Recuerde aqu el problema que para la sincronizacin de copias supone
los diferentes das festivos de las zonas geogrficas.

3.2.5. Momento.

Si es posible, hay que escoger uno en el cual se puedan hacer las
copias en fro. Y recuerde que parar a los usuarios para hacerlas no es
una buena estrategia ni poltica (es impopular) ni econmicamente (hoy
da todos los puestos de trabajo tienen un ordenador y pararlos a todos
supone un dispendio econmico enorme).

Si la empresa hace un horario rgido, aproveche los huecos, aunque,
desgraciadamente para los administradores, cada vez hay menos
empresas (yo creo que ya no existen) en las cuales haya momentos en
horas razonables en los cuales nadie trabaje. En las oficinas un buen
momento suele ser a ltima hora de la noche, aunque es este caso, le
recomiendo hacer una copia en caliente sobre el medio da ya que toda
una jornada es demasiado periodo entre copias.

Recuerde tambin aqu, los problemas que los husos horarios pueden
aportan para la sincronizacin 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 localizacin
no suele ser polmica.

Sin embargo, la dispersin de los componentes del sistema distribuido
puede ser tan variada que puede convenir establecer una normalizacin
focalizando cuatro lugares:

Puestos cliente.
Servidores departamentales bajo la administracin de un CASD
local o de los responsables de aplicacin.
Servidores compartidos por varios departamentos y bajo la
administracin de un CASD local.
Servidores centrales bajo la responsabilidad del CASD central.

3.2.7. Rotacin.

La coordenada rotacin 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 da.

Y, perdneme, no soy capaz sistematizar ms este punto.

3.2.8. Almacn.

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 aplicacin, el
departamento de informtica, una caja ignfuga, etc.

3.2.9. Tipos de gestin.

Hace referencia a la forma en la que se generan las copias. Hay varios
aspectos.

3.2.9.A. Segn la forma de arrancar:

Automtica.
Manual.

3.2.9.B. Como est el sistema de informacin:

Trabajando: en caliente.
Parado: en fro.

Obviamente, son preferibles las copias en fro que en caliente.

En sistemas distribuidos, las copias automticas 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. Bsquelas: le resolvern todos los problemas que pueda
imaginar.
Los recursos de las bases de datos: tienen lo necesario para salvar y
restauran sus datos.

3. 4. Implementacin de copias automatizadas.

Hay tres formes de implementar copias automticas.

Mediante montajes Batch que utilizan recursos de DSM y lanzados por
reloj de forma automtica.
Mediante clientes back-ground especficos.
Utilizar programas de terceros (los hay fabulosos).

Cuando las copias son automticas, un buen lugar para llevar los parmetros
de la copia es el repositorio de administracin.

3. 5. Algunas estrategias habituales de back-up.

3.5.1. Back-up distribuido.

Cada mbito se
gestiona de forma
autnoma e
independiente.

El arranque de la
informacin central
y departamental
puede ser manual o
automtico

La gran ventaja es
la independencia
entre cada
administracin y su
gran inconveniente
garantizar el mismo
nivel de copias en todos los nodos.

Informacin
de usuario
Usuario
Informacin
Central
Central
CASD
Informacin
Departamental
Local
CASD

Figura 254. Back-up Distribuido
3.5.2. Back-up de usuario sobre el entorno departamental.

Se aprovechan
las ventajas de
capacidad de
back-up del
entorno
departamental. La
responsabilidad
es del usuario.

El proceso se
muestra de forma
bastante auto
explicativa en la
figura.

El arranque por el
usuario de los
procesos de
inclusin y
generacin de la copia puede ser automtico, pero en cualquier caso ha
de ser consensuado con el CASD.

3.5.3. Back-up departamental.

La informacin
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 automtico, pero la
responsabilidad es del CASD
local o del usuario avanzado
delegado. El usuario puede
incluir su informacin de forma
manual, mediante un trabajo
Batch o una opcin de men.

Local
CASD
Informacin de
usuario
Usuario
Informacin
Departamental
Informacin
temporal de
usuario
Proceso para incluir la
informacin deusuario
en el entorno
departamental
Proceso de
generacin de la
copia de seguridad

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

Figura 256. Back-up Departamental

Figura 257. Formato del ticket de control de un
back-up departamental
Un back-up de este tipo ha de ser controlado y garantizado. Si se
quiere tener control de s el usuario hace su copia y del estado del
proceso puede usarse un ticket para controlarlo. Un posible formato se
muestra en la figura. La gestin del ticket de control puede ser del tipo:

El usuario es el responsable, directamente o travs 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 gestin es
automtica, ha de verificar que todos los usuarios han enviado la
informacin antes de disparar la copia.
El programa de copia habr de modificar, en funcin del resultado,
la columna de grabado. Conviene, adems del Si / No tener otros
estados de informacin como: error, anulada, hoy no se copia, etc.
Se ha de establecer una poltica de administracin en caso de que
falte alguna copia.

No hace falta mucha imaginacin para pensar otros procesos basados
en el ticket que avisen minutos antes de la copia a los usuarios que
todava no la hayan hecho, protejan contra quejas de perdida de
informacin, fuercen la copia de usuario, etc.

La gestin del control de procesos de administracin mediante tickets
de control es generalizable a otros procesos de administracin. La
existencia dentro del entorno de administracin de una pieza que
implemente el uso de estos tickets es altamente recomendable.

La gestin completa del ticket necesitar de los habituales procesos de
consulta, consulta por excepcin, eliminacin histrica, etc.

3.5.4. Back-up departamental centralizado.

Se trata de
aprovechar al
mximo 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
gestin muy
parecida al
anterior.

El arranque de la incorporacin departamental es aqu siempre
automtico, iniciada por el CASD local o por el CASD central.
Informacin
Departamental
centralizada
Central
CASD
Informacin
depertamental
Informacin
departamental
Local
CASD

Figura 258. Back-up departamental centralizado

Existe un peligro que se ha de vigilar: los volmenes de las BD pueden
ser muy grandes y el traslado de los datos puede no ser la solucin,
sino que el sistema de back-up central ha de ir a buscarlos a los
servidores departamentales. Aun as, el traslado de l informacin llevar
tiempo. No hace falta insistir que el proceso ha de estar controlado y
garantizado.

Una opcin es colocar el servidor de seguridad en una central y
concentrar en ella las copias remotas de todos o parte de los nodos. Es
obvio que necesitaremos una ancho de banda que permita realizar las
copias en un tiempo apropiado, y si es posible, disponer de la
posibilidad de hacerlas en caliente, situacin que reducira el impacto
del ancho de banda.

3.5.5. No back-up y reconstruccin.

La estrategia es clara: en lugar de copiar, reconstruir desde cero.
Obviamente, nada ms se puede utilizar con arquitectura de replicas.

4. Consolidacin de datos.

Consiste en asegurarse que los datos generados por el sistema distribuido se
reciben y consolidan en los nodos master de datos o se intercambian en los plazos
previstos y con coherencia de cdigos y contenidos.

Se controlan bsicamente con dos recursos.

O Tickets multihoja.
O Auditorias de datos.

Es muy importante la definicin de procesos peridicos de cierre.

5. Administracin de impresoras.

5. 1. La impresin en entornos distribuidos.

Desde el punto de vista de la administracin, la gestin de las impresoras es
muy diferente en entornos distribuidos que en sistemas centralizados. En un
entorno centralizado, las colas de impresin y las impresoras cuelgan del
Mainframe; en su sistema distribuido las impresoras estn conectadas a
diferentes servidores, de diferentes dominios y de diferentes redes.

Desde el punto de vista de programacin, la impresin es ya absolutamente
transparente a la situacin y el modelo de las impresoras. As, pues, hablar de
las impresoras en un entorno distribuido se reduce a hablar de administracin.

5. 2. Formas de conectar las impresoras.

Hay tres posibilidades de conectar impresoras a una red.

5.2.1. A un servidor dedicado.
Disponibilidad siempre que este el servidor arrancado. El inconveniente
es que los servidores acostumbran a estar situados en zonas de poca
accesibilidad a los usuarios. Y problemas tan triviales como vigilar el
papel y cambiar la tinta se convierte en temas conflictivos.

5.2.2. A una mquina cliente.

Disponibilidad solo cuando la mquina del cliente est encendida. La
ventaja es que esta muy accesible a los usuarios. Otro inconveniente es
que consume recursos de la mquina cliente.

5.2.3. A un Printer Server.

Un Printer Server es un recurso que permite conectar directamente la
impresora a la red. Y adems es barato.

Grandes ventajas:

Disponibilidad en todo momento.
Accesibilidad de los usuarios ya que se pueden situar cerca de
grupos de trabajo.

El inconveniente es que son algo ms difciles de administrar.

5. 3. Estrategias.

La poltica de que todo el mundo accede a todo el mundo se ha demostrado
errnea a poco que el entorno tenga un cierto volumen. Y curiosamente, mi
experiencia me ha hecho vivir que nadie establece estrategias. Y la solucin
fcil es comprar una impresora por usuario. Y como hay tantas impresoras, son
baratas y lentas. Y cuando hay que imprimir volmenes intermedios, el tiempo
de espera de los usuarios traducido a pesetas paga en poco tiempo las
impresoras ms caras. Por favor, no menosprecie este coste escondido.

Una buena gestin de impresoras pasa por:

Definir grupos de impresin con los usuarios. No hay criterios rgidos.
Pueden valer del tipo: proximidad, afinidad, dependencia, etc. Y uno muy
vlido es el departamento: la camaradera y la presencia de un jefe, son
dos puntos de mucha fuerza para este criterio.
Organizar esos grupos de forma jerrquica.
Tipificar los modelos de impresin, independientemente de las
impresoras fsicas que se instalen despus. Tipificar un modelo supone
escoger una velocidad, una tecnologa y un driver estndar, no usando
opciones de impresoras especializadas si no es estrictamente necesario.
Definir los back-ups operacionales en caso de avera o saturacin.
Definir los responsables de consumibles:
Encargados de la reposicin del stock en almacenes centralizados
por zonas de la empresa.
Encargados de colocarlos en las impresoras compartidas.

5. 4. Organizacin jerrquica de los grupos de impresin.

Los usuarios individuales se organizan en Grupos de Impresin.

Una vez definidos los grupos, estos estructuran jerrquicamente en grupos de
Impresin Departamental
y estos, a su vez, en
grupos de Impresin
Centralizada.

5.4.1. Nivel Usuario.

Corresponde a
impresoras
asignadas de
forma exclusiva a
usuarios
individuales. Estos
usuarios suelen
estar dotados de
impresoras lentas
(el concepto lento
evoluciona hacia
arriba segn el
mercado).

La responsabilidad de operacin y de reposicin de consumibles es del
usuario. La de configuracin del CASD local. El soporte se lo da al
usuario el responsable del grupo de impresin, que como veremos a
continuacin, suele ser un usuario avanzado.

5.4.2. Nivel grupo de usuarios.

Los grupos de
usuarios, que
comparten entorno
de trabajo, deberan
disponer de, como
mnimo, una
impresora de
velocidad media-
alta, conectada
mejor a un Printer
Server que a un
usuario o un
servidor.

Obviamente, todas
las impresoras
compartidas son
visibles por todos
los usuarios del
grupo. Ha de asumir toda la capacidad de impresin habitual del grupo.

Los cambios de consumibles son realizados por los miembros del
grupo.
Impresin
Centralizada
Impresin
Departamental
Impresin
Departamental
Impresin
Departamental
Grupos de Usuarios Grupos de Usuarios
Usuarios Individuales

Figura 259. Organizacin jerrquica de los grupos de impresin
Nivel Departamental
Nivel Grupo
Usuario
Nivel Grupo
Local
CASD
Usuario
Avanzado
Central
CASD
Nivel Centralizado

Figura 260. Distribucin jerrquica de los recursos de
impresin

El soporte lo da habitualmente un usuario avanzado, y sino, el CASD
local.

5.4.3. Nivel Departamental.

En la impresin departamental pueden incluirse varios departamentos.
Si incluye ms de un grupo de usuarios, solo deberan colocarse
impresoras muy rpidas o, simplemente, no tener recursos de
impresin. Si coinciden los grupos de usuarios con el departamento,
vale lo escrito en el prrafo anterior para aquellos.

Esta dentro del entorno del CASD local. La configuracin y
mantenimiento de consumibles es de su responsabilidad.

Acta tambin como back-up de los niveles de usuario.

5.4.4. Nivel Centralizado o Corporativo.

En la Impresin Centralizada slo se colocarn impresoras
especializadas (por ejemplo, una fotocopiadora-impresora de color de
alta calidad) o muy, muy rpidas. Necesitan, adems, administracin del
CASD para controlar consumos y gastos por usuarios.

Est dentro del entorno del CASD local o central, segn su situacin. La
configuracin y mantenimiento es, obviamente, de su responsabilidad.

5.4.5. Impresin entre ramas.

La impresin entre dos ramas (por ejemplo, dos departamentos) es, en
principio, espordica. Cuando se necesite es mejor intercambiar
ficheros.

Sin embargo, para poder pasar ficheros es necesario que el destinatario
disponga del programa necesario para obtener el listado del fichero.
Cuando el intercambio sea de ofimtica esto va a ocurrir siempre (ojo
con los formatos de estilos, marcos, etc.).

Si es un programa de aplicacin, la cosa ya no es tan clara ya que,
adems del programa, el usuario destino deber tener acceso y
derechos sobre los ficheros auxiliares para obtener el listado (por
ejemplo, en un listado de ventas, el fichero de vendedores). En este
caso, habr que disponer de acceso a la impresora del usuario.

Es evidente que puede ser muy pesado de gestionar que sea la
impresora de cada usuario la visible desde el entorno exterior ya que,
con varios usuarios interconectados, habra que definir cada impresora
destino en cada usuario origen.

El conjunto queda bastante poco operativo. La solucin es hacer
visibles desde el exterior las impresoras de nivel departamental, ya que
as, de un solo tiro se matan todos los pjaros. Y si es posible, no
siempre lo es, colocar el destinatario en la cabecera del listado. Si el
listado lo genera un programa de la aplicacin distribuida que se esta
programando, el diseador debe dar la posibilidad de colocar un destino
en el momento de que el usuario origen pida el listado.

Y recuerde, que hoy da, no hay ningn problema para compartir
impresoras remotas.

El nico problema que se puede encontrar es compartir impresoras de
entonos heterogneos. No es un problema trivial. Trtelo puntualmente
al administrar el entorno. Y verifique lo que dicen los manuales: no
siempre funciona tan fcil como dicen.

Finalmente, un uso habitual de la impresin entre ramas es el back-up
de impresoras departamentales.

5. 5. Implementacin de las estrategias de administracin de impresoras.

Hoy da todo el necesario esta disponible a travs de los recursos que
proporcionan en NOS y el DSM. As, pues, se han de usar siempre los recursos
de los servidores de impresin de la red.

Recuerde que la impresin se organiza en colas que corresponden a un
nombre de impresora lgica. Cada una de estas colas las gestiona un servidor
de impresin.

Los recursos de DSM permiten instalar y configurar con facilidad las colas e
impresoras. Otro tema es la gestin de listados. Cosas como cambiar listados
de colas, no son (increblemente!) posibles todava en los sistemas de red ms
populares. Recomiendo encarecidamente a los fabricantes de herramientas
DSM para gestionar listados que hagan una visita a las posibilidades que los
gestores de spool de los Mainframe han dado siempre. Amigo lector, no se
desanime, seguro que el Sr. Gates lee este libro y me hace caso.....

Uno de los problemas que tambin existen en los entornos de red modernos es
la poca o nula facilidad para archivar en el repositorio los parmetros de
instalacin y de configuracin y los derechos de los usuarios, y as, poderlos
reproducir en casos de instalaciones iguales o de recuperacin de averas.
Esperemos que en poco tiempo, este problema nos lo arreglen tambin para
facilitar la vida a los administradores. Esta grave carencia debe ser suplida por
una buena documentacin; si, eso que nunca existe. Por favor, en este tema,
antelo todo, no sabe la de tiempo que ganar y las tensiones que se evitar.

6. Administracin de usuarios y derechos.

En cualquier sistema pedir la identificacin del usuario para autentificarlo antes de
darle acceso al sistema es fundamental. Y en un entorno distribuido, la
preocupacin debe ser todava mayor ya que los usuarios estn bastante ms
descontrolados. Y la identificacin permitir darle acceso solo a lo que tenga
derecho.

Existen dos entornos en los que hay que delimitar derechos y restricciones:

O Recursos del sistema; en este tema, no incluya los datos como recurso del
sistema.
O Informacin, es decir datos, a travs de tres vas:
O Derechos de acceso a las BD determinados sobre el gestor de la base
de datos.
O Visibilidad a travs de las aplicaciones.
O Visibilidad de directorios con informacin restringida.

El objetivo ideal seria que hubiera un solo repositorio de derechos y restricciones de
los usuarios en todo el sistema. Desgraciadamente, en entornos heterogneos esta
posibilidad no es siempre viable por DSM.

6. 1. Organizacin de usuarios y gestin de los derechos.

Los usuarios se organizan en grupos, por afinidad funcional. A cada grupo se
le asignan derechos y restricciones de las que participan de forma genrica
todos los usuarios del grupo. Estos grupos, en general, ya son suficientes para
gestionar los derechos sobre los recursos del sistema. La relacin entre grupos
y recursos se establece con las herramientas de DSM.

Para la gestin de la informacin el criterio de grupo se queda corto ya que
dentro de un mismo grupo, puede haber usuarios con derechos de lectura,
otros con derechos de mantenimiento y otros con acceso a solo una parte de
los atributos de una entidad.

Para gestionar la informacin es necesario, pues, distribuir los usuarios por
perfiles a los que se asignan los derechos de visibilidad y mantenimiento de
los datos.

Los programas de las diferentes aplicaciones debern determinar el perfil del
usuario identificado, obtener su perfil de un repositorio y, a partir de aqu,
personificar GUIs con los derechos y restricciones genricas del perfil.

La relacin grupo-perfil, aunque se pueda ver operativamente como jerrquica,
es conceptualmente ortogonal ya que el mismo perfil puede repetirse en dos
grupos diferentes. Sin embargo, y en la prctica, como unos grupos de
usuarios suelen utilizar informacin diferente de los otros, la relacin deviene
jerrquica.

El concepto de perfil no suele existir en los repositorios gestionados por el DSM
por lo que se hace necesario implementar una pieza que lo gestione.

Para gestionas los accesos a la informacin dentro de la BD, los grupos
marcan el entorno general que despus habr que acabar de afinar usuario por
usuario. En este tema puede ser tambin interesante utilizar los perfiles. El
nico problema viene del hecho de que la mayora de los gestores de BD no
permiten definir este concepto directamente lo que obliga a utilizar los perfiles
como grupos en la base de datos perdindose la presin jerrquica de la
relacin grupo-perfil.

En todo este tema recuerde una trivialidad. De cada informacin hay que
determinar un responsable, perfiles de mantenimiento y de consulta.

La recomendacin es que si tiene un problema no trivial de restricciones no
monte nada sofisticado basado directamente en gestionar los usuarios
individualmente ya que se vuelve rpidamente ineficaz y pesado de
administrar.

Y no olvide que cuando un usuario cambia de grupo o se marcha, deben
eliminarse rpidamente sus derechos actuales.

Una cuestin adicional, hay que pedir autentificacin de acceso a la base de
datos a un usuario que se ha identificado previamente en la red cada vez que
inicia un programa que accede a la BD? Un purista le dir que no, que con una
vez ya vale. Sin embargo, no menosprecie el valor de seguridad adicional que
supone la identificacin por inici de sesin en la red y repetirla cada vez que
un programa inicia una sesin (login) en la BD. Evitar que un usuario deje
abierta una sesin de red, situacin muy habitual, y que otro no autorizado se
aproveche para acceder a informacin a la que no tiene acceso.

6. 2. Gestin de directorios con informacin restringida.

La explosin en el uso de la ofimtica ya llevado a que informacin de acceso
restringido se ha implementado sobre ella. Y como la ofimtica gestiona
ficheros, estos se agrupan por directorios. Los directorios y los ficheros los
gestionan usuarios diferentes que difcilmente se van a coordinar entre ellos. Y,
por desgracia en este tema, los accesos a directorios se gestionan con
herramientas de DSM que no tienen el concepto de perfil.

Todo ello ha llevado a un bloque de gestin de derechos muy conflictivo porque
los ficheros son muchos y la anarqua con que se agrupan es grande.

En este tema tambin existe un responsable, perfiles de mantenimiento y de
lectura. Pero las herramientas de DSM no disponen de perfiles por tipo de
fichero. O sea, que como dira un famoso astronauta en problemas: Houston,
tenemos un problema.

Como la inexistencia de perfiles en el DSM solo hay una solucin:
organizacin.

Le recomiendo:

Defina un directorio como un recurso compartido en algn servidor de
ficheros y mapee ese recurso como una unidad lgica con el mismo
nombre para todos los usuarios.
Organice una jerarqua de directorios ligada a los perfiles sobre esa
unidad lgica.
Asocie un grupo de usuarios a cada perfil.
Gestione los permisos de esos directorios en funcin de esos grupos
dndoles permiso de lectura.
Responsabilice de cada directorio a un/os usuario/s del grupo y dles
control total sobre los directorios base y todos los derivados. Sern los
nicos que podrn crear nuevos directorios.
Decida que usuario/os mantiene/n los ficheros y dles permiso de
mantenimiento sobre sus ficheros.
A los documentos ms confidenciales, introdzcales una contrasea de
acceso que solo sepan los usuarios que pueden visualizarlos.
No de permisos a los administradores. Cuando un administrador debe
gestionar algo, debe estar presente el responsable de esos directorios,
picar su clave y supervisar el trabajo de los administradores. Como
mucho, define dos niveles de confidenciabilidad, cree un usuario
administrador especial y dle permisos solo a los de segundo nivel. Y la
clave de ese usuario solo debe saberla en jefe de administradores y,
como mucho, otro administrador de confianza.

6. 3. Gestin de los derechos de impresin.

La gestin de los derechos de impresin no debe confundirse con los derechos
de usar una impresora. Estamos hablando de los derechos de un usuario a
volcar por una impresora unos datos. Y tambin recuerde que no
necesariamente todos los usuarios con derecho de consulta los han de tener
tambin de impresin.

El control de los derechos de impresin desde programas de aplicacin debe
llevarlos los mismos programas. Los de ofimtica no se puede controlar: quien
consulta puede listar.

6. 4. Implementacin del permetro de seguridad.

Como ya se ha dicho, la base de la implementacin de permetro de
seguridad es siempre el DSM de la red.

Si la red es homognea la implementacin de ese permetro de seguridad se
hace sin problemas con las herramientas del DSM.

Si la red es heterognea, hay que definir el permetro sobre cada red. Hay tres
opciones:

6.4.1. Permetro de seguridad mltiple.

Hay dos opciones:

Repositorio
Red 1
Repositorio
o Red 2
Administrador
Sesin de
red
Sesin de
red
Gestin de
usuarios
Gestin de
usuarios

Figura 261. Permetro de seguridad mltiple con
identificacin mltiple
6.4.1.A. Identificacin mltiple.

La definicin de usuarios se realiza en cada red con sus
herramientas de DSM. El usuario se identifica cada vez que inicia
una sesin en cada red.

6.4.1.B. Identificacin nica.

La definicin de
usuarios se realiza
en cada red con sus
herramientas de
DSM. El usuario se
identifica cada vez
que inicia una sesin
en cada red.

Supone la existencia
de un repositorio de
administracin
unificado y de
herramientas de
DSM, compradas o
fabricadas, para
gestionar de forma
automtica desde l
cada red.

6.4.2. Permetro de seguridad nico.

Supone la
administracin
nica como en el
caso anterior, pero
adems el usuario
solo se identifica
una vez. Es
necesaria la
existencia de
herramientas
adicionales de
DSM, compradas o
fabricadas y de un
servidor de
identificacin para
autentificar el
acceso.

6. 5. Una posible arquitectura de un servicio de identificacin.

Un servicio de autentificacin puede montarse fcilmente con un servidor.

Repositorio
administracin
Repositorio
Red 1
Repositorio
Red 2
Gestin
de
usuarios
Administrador
Traspaso
automtico
Traspaso
automtico
Sesin de
Red
Sesin de
Red

Figura 262. Permetro de seguridad mltiple con
identificacin nica
Repositorio
administracin
Repositorio
Red 1
Repositorio
Red 2
Gestin
de
usuarios
Administrador
Traspaso
automtico
Traspaso
automtico
Servidor
de
acceso

Figura 263. Permetro de seguridad nico
La idea es bien simple. En un fichero XML se guardan los entornos contra los
que hay que validarse y las condiciones y reglas de autentificacin de cada uno
de ellos.

El programa cliente que necesita autentificarse lo hace contra el servicio que a
partir del fichero XML se valida contra cada entorno.

Para completar el cuadro, bastar aadir un programa para administrar los
ficheros XML y una forma de hacerlos llegar a los puestos cliente.

7. Gestin del software.

7. 1. Distribucin y control del software.

La gestin del software dentro de un entorno distribuido presenta
caractersticas no presentes en un entono centralizado debido a la multiplicidad
de copias:

Necesidad de controlar la versin cada nodo.
Necesidad de distribuir nuevas versiones.
Necesidad de sincronizar los cambios de los esquemas de BD con el
cambio de versin de los programas que los tratan, o en su defecto,
pensar en situaciones transitorias entre versiones y, por tanto, posible
coexistencia de diferentes versiones en los nodos.
Necesidad, en algunos casos (a evitar) de arrancar versiones
sincronizadas.

Administrar el software supone, pues marcar la estrategia a seguir en dos
temas:

7.1.1. Localizacin de los programas.

Los programas se sitan en los servidores de programas. Recuerde
aqu todo lo que se ha hablado con anterioridad de este tema con la
dualidad: un solo servidor es fcil de administrar pero frgil ante cadas
de sistema versus colocar la copia en el cliente, poltica segura pero
difcil de administrar. Y, recuerde tambin, que el mejor sistema suele
ser una solucin hbrida: colocar en los clientes los programas
imprescindibles para que el nodo siga activo aunque caiga el servidor y
en los servidores de programas el resto.

7.1.2. Control y distribucin de versiones.

Controlar es, en principio, fcil. Solo hay que ser metdico en la
asignacin de versiones al software y en anotar la versin que tiene
cada nodo, de programa y de esquema de base de datos.

El problema es la distribucin, de esquema de datos y de programas.
Huya de la necesidad de arrancar sincronizadamente versiones;
siempre el mejor pensar en un transitorio que permita evitar el colapso y
la tensin que produce un arranque sincronizado.

Piense por ejemplo que tiene una aplicacin de ventas en una red de
tiendas que envan los datos de facturas cada noche a la central. Si ha
de cambiar el formato de las facturas puede montar un transitorio muy
fcil disponiendo de una tabla que diga que versin tiene cada tienda.
Cuando se decida a arrancar el cambio, cambiar los programas de la
central y colocar todos los nodos en la versin antigua. Los programas
de recepcin debern estar preparados para recibir los dos formatos.
Podr iniciar entonces el cambio de los nodos con rapidez pero sin
urgencias; bastar que cada vez que cambie un nodo, informe en la
tabla que ya est en la nueva versin para que el programa de
recepcin conozca que los datos que le llegan estn en el nuevo
formato. En cualquier caso, haga el cambio tan rpido como pueda no
sea que aparezca una tercera versin antes de que todos los nodos
tengan ya la tercera. Montar un transitorio con tres versiones ya es
demasiado! Y cuando el cambio de versin no afecta a la BD todo es
mucho ms simple.

Cuando el cambio de versin a de ser sincronizada no hay ms remedio
que introducir el concepto de fecha de vigencia, o da, y a veces hora,
en que la nueva versin ha pasar a ser la activa. De esta forma la
distribucin de puede hacer antes del arranque. Recuerde que en este
caso ha de montar un sistema de consistencia, un ticket bastar, para
que cuando el nodo tenga la versin disponible avise al centro de
distribucin de forma que el administrador pueda saber con antelacin si
todos los nodos estn preparados, y en caso contrario, resolver el
problema en los que no lo estn antes de la entra en vigencia de la
versin que se est distribuyendo.

Cuando se alcance la fecha de vigencia, un programa automtico,
normalmente en el momento del arranque del nodo, verificar si hay una
versin que arranca ese da y, en caso afirmativo, la pondr en
explotacin. Conviene que avise al ticket de control de la central de
forma que los administradores puedan comprobar que en todos los
nodos se ha realizado el cambio, y en caso contrario, realizar acciones
puntuales, y urgentes, para resolver el problema. Puede estudiarse, si la
naturaleza del cambio lo permite, guardar la versin anterior y
recuperarla en caso de error mientras se analiza que ha impedido la
entrada en vigor de la nueva versin.

En la gestin de cambios puede tener muchsimas ventajas la utilizacin
de interfases basadas en XML ya que, al poder llevar incorporada la
semntica de la interfase, facilitar la identificacin de la versin que ha
generado la interfase que se ha recibido.

7. 2. Distribucin de replicas de ficheros fijos.

Recordemos que entendemos por ficheros fijos los de parametrizacin y los
ficheros de datos de volatilidad peridica como, por ejemplo, las tarifas de
productos en restauracin.

La distribucin de los ficheros de parametrizacin ha de ir ligada a la de los
programas. Los ficheros de datos pueden gestionarse con polticas de
replicacin (ya vistas) o como programas.

7. 3. Herramientas disponibles.

Hay dos opciones muy claras:

7.3.1. Utilizar paquetes.

7.3.2. Utilizar herramientas de DSM.

Integrndolas o no en una herramienta de nivel superior mediante un
desarrollo especfico.

As, el repositorio de administracin puede utilizarse para catalogar las
versiones, el servidor de correo puede utilizarse para la distribucin, un
cliente back-ground puede utilizarse pasar las versiones pendientes a
actuales al alcanzar la fecha y la hora de vigencia como alternativa a
una accin manual, etc.

Valore aqu la posibilidad de hacer software propio: puede salirle rentable.

8. Aportaciones del Diseo de Administracin del Sistema al NOS+DSM.

Como ya se ha dicho antes, el diseo de administracin supone, en realidad, aadir
nuevas opciones a los NOS y el DSM, muy especialmente al segundo.

Se pueden hacer dos tipos de aportaciones:

O Piezas para implementar recursos necesarios no presentes en el NOS+DSM.
O Piezas para facilitar la operacin, basadas en encapsular recursos ya
existentes de NOS+DSM.

De cualquier forma, es importante resaltar que esta etapa aade al sistema
distribuido funciones que no afectan a la arquitectura del sistema distribuido
sino a su administracin.

9. Algunas ideas ms.

A lo largo de estos dos ltimos captulos he ido presentando algunas ideas de como
complementar el NOS+DSM para conseguir una mejor administracin del sistema.

Finalmente, y como despedida de los captulos dedicados a la administracin del
sistema distribuido, djeme relacionarle algunas ms:

O Un repositorio de administracin puede montarse fcilmente en entorno
ofimtico con una BD tipo Access.
O Un sistema de referenciar recursos que el NOS+DSM no incluya es siempre
un archivo, un programa de mantenimiento y consulta de ese archivo y rutinas
que hay que incluir dentro de los programas que utilizan esos recursos.
O Un inventario de elementos puede llevarse dentro del repositorio de
administracin. Aqu, por favor, recuerde que el inventario no puede ser
cuantitativo, ha de ser cualitativo y con los datos mnimos necesarios para
administrar. Incluya los parmetros de garanta y mantenimiento.
O La forma de montar todas las piezas construidas debe ser el esquema del
Middleware real, de forma que a medida que los DSM avancen puedan
sustituirse las piezas construidas por las funciones estndar.

Diseo de Consistencia

1. Objetivos del Diseo de Consistencia.

Como ya hemos comentado anteriormente,

El diseo de consistencia hace a las aplicaciones distribuidas robustas, es
decir, resistentes a fallos y cadas. Dicho en otras palabras, hace las aplicaciones
fiables. Supone una etapa incremental de la especificiacin inicial.

El diseo de la consistencia viene motivado por las circunstancias excepcionales o
los fallos de servicios en el sistema distribuido.

Cuatro son los temas a estudiar dentro del anlisis del diseo de la consistencia:

1. Gestin de errores.
2. Gestin de la concurrencia.
3. Semntica de servidores para la recuperacin de las cadas.
4. Previsin de situaciones alternativas de trabajo cuando caen los servicios en
lo que denominaremos situacin o trabajo en emergencia.

Notas de marketing:

O Sondee a su cliente antes de hablar anlisis de consistencia, puede que no
entienda que ha de prepararse por si un servicio cae (sobre todo si la
competencia se lo esconde para construir una oferta ms barata o por simple
desconocimiento).
O Si no es receptivo tendr un dilema:
Si lo incluye, lo pagar Vd.
Si no lo hace, no quedar satisfecho profesionalmente.
O Delante de sus clientes no utilice el trmino trabajo en emergencia si no otros
del estilo de trabajo off line.
O Voy a seguir utilizando el trmino emergencia para referirme a la situacin de
trabajo sin el/los servicios disponible/es ya que el me parece muy adaptado a
la situacin que define. Sin embargo, es un trmino polticamente incorrecto
desde el punto de vista de marketing por lo que le recomiendo que delante de
sus clientes use sinnimos del tipo trabajo off line.

Aunque voy a tratar cada uno de los puntos con detalle a lo largo de este capitulo,
conviene tener de entrada una visin global de la estrategia a seguir.

Cuando el cliente detecte un problema, ejecutar los procesos de recuperacin de
los servidores. Las funciones del cliente que los harn sern nuevas funciones, no
detectadas, en principio, en el funcional ni el tecnolgico hasta ese momento, y que
sern independientes del flujo principal.

Para gestionar el proceso de recuperacin, se establecern unas reglas de
comportamiento (semntica de los servidores) para que cliente y servidor tengan
claro como han de actuar.

Si el cliente no puede recuperar el servicio entrar en situacin de emergencia, en
la que deber trabajar, si es necesario, sin el/los servicio/os que ha/han cado.
Finalmente, ser necesario un proceso, manual o automtico, que detecte cuando
el servicio se ha recuperado y un proceso de reconexin del cliente cuando esto
ocurra.

La importancia del anlisis de consistencia dentro de un sistema distribuido ser
tanto mayor cuanto ms sofisticada sea la arquitectura distribuida, ms
actualizaciones de datos realice el sistema y ms caro sea tener el sistema parado.

Toda aplicacin distribuida debera contemplar esta etapa del
diseo. Por desgracia, o por desconocimiento del diseador o por
coste, finalmente no se implementa. Grave error! Al final, tarde o
temprano, pero inexorablemente, el usuario, y de rebote el
diseador, tendr la sensacin de que el sistema le domina, la presin del usuario
se har angustiosa y la aplicacin se habr convertido en la peor de sus pesadillas.

Si va corto de tiempo y dinero, el diseador debe identificar como mnimo los
problemas y pensar soluciones, aunque estas sean manuales de forma que,
cuando aparezcan los problemas, se sepa que hacer y no se inicie la histeria a la
que conduce la indeterminacin.

Recuerde que la mayor parte de los fracasos, que han trado una cierta mala fama
a los sistemas distribuidos, se ha debido a la omisin de esta etapa del diseo.

Finalmente, ver que en la mayora de los casos solo hablo de comportamiento de
servidores: recuerde que un agente necesita certeza absoluta de funcionamiento
(full-tolerence). Y esta semntica de comportamiento tendr una gestin muy
concentra y definida dentro del anlisis de consistencia. Por esa razn, Por se
suele hablar siempre en este apartado como si los proveedores de servicios fueran
siempre servidores.

2. Por qu y como caen los servidores?

Un servidor esta localizado en un nodo. Y para llegar a ese nodo, hay que utilizar
un transportista que utiliza una va de la plataforma de conectividad.

Si el nodo donde est el servidor cae, por ejemplo por avera de la mquina, caer
el servicio.

Si la va utilizada por el transportista cae, el cliente tampoco tendr acceso al
servicio.

Un servicio tambin puede dar el efecto de que ha cado por congestin cuando,
puntualmente muchos clientes lo piden simultneamente. Este error debe
recuperarse siempre por el sistema distribuido, siempre que est bien diseado,
obviamente.

Observe dos hechos fundamentales:

O Difcilmente el cliente puede saber si ha cado el nodo o el transportista. Y,
adems, normalmente no necesita saberlo. Su operativa de consistencia est
ligada simplemente a la no obtencin del servicio.

O Cuando un servicio cae, normalmente caen tambin otros. Si lo que se ha
estropeado es nodo, caern todos los servicios localizados en el nodo. Si cae
una va del transportista, caen todos los servicios que utilicen la misma va.

Si el programa sabe que varios servicios estn ligados al mismo nodo o va de
transporte (por ejemplo, un servidor de datos), podr poner en emergencia todos
los servicios relacionados. Esto permitir minimizar el tiempo para pasar el sistema
de trabajo normal a emergencia. Observe que si los servidores van cayendo de uno
en uno cada cual har su propio proceso de recuperacin y la conmutacin
emergencia puede alargarse sin ninguna necesidad.

Finalmente, observe que si cae un servidor sin caer todo el resto la causa ser
probablemente de congestin y/o diseo o programacin, y no de cada real.

3. La consistencia por plataforma redundante.

Una forma de conseguir que la plataforma no caiga, y que por tanto minimizar, y hasta suprimir, el diseo
de la consistencia por software, es trabajar con una plataforma redundante en que, en caso de la cada de
un nodo o una lnea, se pueda trabajar con una alternativa.

Esta posibilidad, atractiva desde el punto de vista terico, choca directamente con el criterio econmico
de la ingeniera: es cara, muy cara si quiere ser completa. Solo puede justificarse en unos pocos y
escogidos sistemas.

Para conseguir consistencia por plataforma redundante hay que prever como mnimo:

Clusters en los servidores.
Puestos clientes alternativos. Este suele ser el menor de los problemas debido a la
proliferacin de PCs.
Disco redundante. Un sistema SAN puede ser apropiado.
Vas alternativas en la plataforma de conectividad. Vital. Aqu es tambin importante huir de
las soluciones, hardware y software, en estrella y potenciar las arquitecturas en red.
Sistemas que garanticen el suministro de energa elctrica el 100% del tiempo de
funcionamiento.

Todo ellos comporta, adems de mayor rigidez en la adaptabilidad, un mayor coste de inversin,
funcionamiento (consumo y mantenimiento) y administracin de la plataforma. Este puede ser el gran
problema, la gran trampa: puede ocurrir que el software de consistencia proporcione una solucin ms
barata y flexible.

Obviamente, si esta es la solucin escogida, aqu acaba el capitulo. Si la consistencia es por software, en
lo que resta encontrar diversas, y espero interesantes, propuestas.

4. Ciclo del Anlisis de Consistencia.

Las etapas que un
diseo de
consistencia debe
contemplar se
resumen en el
cuadro de la figura,
en el cual, adems
se han secuenciado
en el tiempo.

El sistema trabaja la
inmensa mayora del
tiempo normalmente
(sino es as, apaga y
vmonos). Si en
algn momento del
trabajo se produce
un error en la
utilizacin de algn
servicio, lo primero que el programa debe hacer es analizar el error. Una primera
criba se realiza separando los errores lgicos (no existe cliente, no hay stock, etc.)
de los fsicos, normalmente representados por la no recepcin, total o parcial, de un
servicio solicitado.

Lo segundo que hay que hacer es intentar recuperar el error. Si la recuperacin
acaba con xito, el trabajo se reiniciar sin mayor problema. Lo mximo que notar
el usuario es que esa peticin ha tardado ms que las otras. No le recomiendo
sacar ningn tipo de aviso de que el sistema est haciendo un reintento. El usuario
no sacar ninguna informacin til de ese aviso y por contra le transmitir
desconfianza y desprestigio injusto sobre una aplicacin tan bien diseada que es
capaz de recuperar los errores sin que el trabajo se resienta.

Si finalmente el error no se puede recuperar, se habr de avisar al usuario e iniciar,
si tiene sentido, un proceso para pasar el sistema a emergencia, es decir a trabajar
sin la disponibilidad del servicio que ha cado. De hecho es ms que probable que
cuando cae un servicio, caigan tambin otros muchos a los que se llega por el
mismo transportista.

Es recomendable, si el sistema distribuido lo permite, lanzar un aviso al centro de
administracin del cual dependa el servicio. No debe basarse nada en esta
notificacin ya que ser muy habitual que la cada haya producido tambin la
desconexin del transportista que conecta con el CASD. Si la cada necesita de la
accin del CASD, el programa debe prever que si el mensaje no se puede enviar
automticamente, se avise al operador de que avise telefnicamente al CASD.

Una vez iniciado el trabajo en emergencia, el sistema trabajar en esta situacin
hasta que, automtica o manualmente, se detecte la recuperacin del sistema.

Durante el trabajo en emergencia deber generarse un log con el trabajo realizado.
Este log ha de permitir la recuperacin de la informacin generada en emergencia
cuando el sistema se recupere. En ese momento, se iniciar un proceso de
recuperacin, que puede incluir el proceso o la transmisin del log (otra opcin es
hacerlo ms tarde) y el sistema volver a trabajar normalmente.

En el resto del captulo se analizan cada una de estas etapas.
Anlisis
del Error
Intentos de
recuperacin
Inicio de la
Situacin de
Emergencia
No recuperable
Trabajo en
Emergencia
Trabajo
Normal
Error
Recuperacin
de la Situacin
Normal
Recuperacin del
sistema
Log
CASD
Aviso
Error fsico

Figura 264. Ciclo de trabajo del Anlisis de Consistencia.

5. Gestin de errores en un sistema distribuido.

La gestin de errores en un entorno distribuido presenta caractersticas claramente
diferenciadas de las de un entorno centralizado: plataformas diferentes, dispersin
geogrfica, dispersin horaria, perfiles de usuarios muy diferentes, etc. Al final, y de
hecho, la gestin de errores es ms compleja y crtica.

Muchos de los criterios citados aqu se han presentado ampliamente al hablar del
servidor de correo. Si no los recuerda bien, por favor, relalos.

Los errores se debern informar, como criterio que debe omitirse en contadas y
muy justificadas ocasiones, en los clientes, que son los puntos donde estn los
usuarios. Cuando existe una delegacin de servicio entre servidores, o cualquier
otra arquitectura de comunicacin entre servidores, el error debe arrastrarse hacia
arriba y trasladarlo hasta el cliente.

Cuando el error sea recibido por un agente deber hacerse cargo de l y notificarlo
a su CASD. Recuerde que un agente es desatendido y que por tanto no es vlida la
opcin de mostrar un mensaje por pantalla: es ms que probable que nadie lo vea.

La gestin de errores se basa en dos parmetros: el nmero de reintentos a
hacer y el tiempo entre ellos (tiempo de sleep). Este ltimo parmetro es
fundamental, es el as escondido en la manga. Si la cada del servicio se ha debido
a una sobrecarga de clientes o transportista, si los reintentos se hacen
rpidamente, ocuparn un tiempo mnimo y no esperaran a que la punta pase,
produciendo una cada del sistema que nunca debera producirse.

Recuerde, una vez ms, lo que sobre los parmetros de gestin de errores
hablamos en el servidor de correo.

Conviene que los
parmetros sean
personificables y deben
colocarse en la ficha de
entorno del servidor, del
agente o del cliente y
los administradores
deben tener posibilidad
de modificarlos. El
programa los tomar al
principio,
parametrizacin
esttica, o cuando ha
de usarlos,
parametrizacin
dinmica.

Una vez detectado que
hay un error fsico, el programa entrar en un ciclo de gestin del error que se
muestra en la figura y que puede acabar con la recuperacin del error y la
continuacin del trabajo normal, o con la imposibilidad de hacerlo y la entrada en
emergencia de ese servicio.

Reintentos=N
Tiempo_sleep=M
Error
Reintentos
del servicio
Ficha del
servidor o del
cliente
N,M
Trabajo
Normal
Recuperacin
Reintentos
Reintentos - 1
= 0
Entrar en
emergencia
Sleep M
segundos
> 0
Error fsico

Figura 265. Ciclo de la gestin de errores.
Como ha de ser el reintento depende de la semntica del servidor. Ms adelante
trataremos este tema. Pero recuerde que, como criterio general, el reintento ha de
ser controlado evitando ejecuciones no controladas. Por ejemplo, si actualiza un
stock, el servidor ejecuta el servicio pero se pierde la respuesta, si el cliente
reintenta sin ms y la semntica de comportamiento cliente / servidor no est bien
definida, puede llegarse a rebajarse dos veces el mismo stock. Ms adelante
hablaremos de semntica, y en ese momento recuerde que la gestin de errores
debe tenerla en cuenta.

5. 1. Elementos para el anlisis de los errores.

Para analizar los errores en una aplicacin distribuida hay que tipificar los
errores, asignarles un destinatario y un nivel de gravedad. Y hacerlos llegar al
centro de control del sistema distribuido:

En caliente para el centro de errores de control de administracin.
En fro a travs de las actividades de Monitoring para anlisis.

Vamos a exponer, recordar de hecho, algunos puntos de inters sobre cada
tema.

5.1.1. Tipos de errores.

Conviene diferenciar entre tres tipos de errores:

5.1.1.A. Errores lgicos.

O aquellos, como se ha dicho antes, que se generan por la lgica de
aplicacin y no por la cada de un servicio.

El servidor los devolver codificados al cliente dentro de la respuesta
y el cliente los gestionar.

5.1.1.B. Errores fsicos.

Generados por cadas, cogestin del transportista y concurrencia de
muchos clientes en un servicio.

Ha de haber un proceso de recuperacin que se implementa en el
cliente o el agente. El servidor ha de colaborar intentando, en lo
posible, que la concurrencia no produzca un error fsico, cosa que no
es ninguna trivialidad, razn por la cual la gestin del error se suele
dejar para el cliente. Cuando el error no se recupera, se ha de
notificar al usuario, y si est previsto, iniciar el proceso de
emergencia.

5.1.1.C. Errores de administracin.

Del tipo falta papel en una impresora. Hay que hacerlo llegar hasta el
responsable sea el mismo usuario o un administrador. Si la
comunicacin es asncrona desacoplada, la gestin la realizar el
servidor o cliente back-ground afectado. Si no lo es, el programa
esperar normalmente a la resolucin y continuar normalmente.

5.1.2. Destinatario.

El error se ha de notificar al usuario responsable de resolverlo, que en
un entorno distribuido, puede estar alejado del punto en que se ha
detectado que a su vez puede estar alejado del punto donde se ha
producido.

Cuando la notificacin hay que enviarla a un punto diferente del usuario
que al que se ha notificado, es conveniente normalizar los centros de
gestin de errores. Y es recomendable que estos centros coincidan con
la organizacin de administracin. Recordemos que esta organizacin
es jerrquica y que puede localizarse en usuarios avanzados, en el
CASD local o el CASD central.

Un buen lugar donde enviar los errores en el cuadro de control de
explotacin del sistema distribuido.

5.1.3. Nivel de gravedad.

5.1.3.A. Crtico.

La notificacin del error debe interrumpir el trabajo del responsable
de gestionarlo.

5.1.3.B. Urgente.

Se ha de notificar visualmente al responsable pero no hay que
interrumpir su trabajo. Conviene que si pasado un tiempo no ha sido
resuelto el error cambie de urgente a critico para que el responsable
no se olvide de gestionarlo.

5.1.3.C. Aviso.

Los errores se guardan en una lista para que el responsable los
consulte cuando le interese. Conviene tambin en este caso que
pasado un tiempo el error pase de aviso a urgente y a crtico si no es
resuelto.

6. Anlisis histrico de los errores.

Para una buena gestin del sistema distribuido es muy til realizar estudios de la
frecuencia y localizacin de los errores. Pueden analizarse, y resolverse, factores
de gran inters:

O Localizar puntos donde las cadas son demasiado frecuentes y donde puede
haber una avera.
O Puntos de servicio que motivan cadas y que pueden ser resueltas por time-
out.
O Deteccin de puntos desprotegidos delante de errores de operativa y que
pueden protegerse por software
O Puntos de alta concurrencia, etc.

Para hacerlo solo es necesario dar persistencia y caducidad al sistema de
almacenar los errores con las herramientas de Monitoring y registrarlo en el sistema
de Anlisis de la Gestin de la administracin del sistema distribuido.

7. Implementacin de la gestin de errores.

Si en la instalacin hay sistema de Monitoring, o en su ausencia servidor de correo
o el cartero, para distribuir los errores se utilizarn estos componentes. Si no los
hay puede utilizarse el mail. Otra opcin es utilizar la plataforma de mensajes del
Middleware encapsulndola en una pieza.

Una vez los errores han llegado a destino han de almacenarse, consultarse,
gestionarse y analizarse.

Si Vd. lector revisa lo que hemos dicho de errores, ver que su gestin es
fcilmente implementable en piezas de reutilizacin prcticamente total.

Una buena implementacin de una gestin de errores empieza por una
normalizacin en que raras veces se piensa cuando se inicia una aplicacin
distribuida: los errores han de ser codificados.

Es una vuelta al pasado. Cuando slo existan los grandes Mainframe, recuerdo
que cuando el sistema generaba un error, lo hacia con un cdigo de referencia y un
mensaje muy crptico. Con el mensaje de error haba que consultar unos manuales
gigantescos donde, tras un entrenamiento apropiado, se encontraba el error
perfectamente documentado: donde y cuando se produca y como se resolva y/o
evitaba. Los programas de aplicacin copiaban esta filosofa, y como haba tiempo,
los equipos de desarrollo continuaban esta inercia en sus aplicaciones.

Con la llegada de los sistemas abiertos, y la facilidad con que se poda avisar por
pantalla del error, llev a la eliminacin de los manuales de errores y por tanto a la
codificacin de estos.

Este fue, a mi juicio, un paso atrs. La gestin del error se limit a dar un mensaje
en el momento y lugar donde se detectaba, no cuando y donde se produca. Y
como el nivel de documentacin baj, se dejo de documentar. Y apareci, adems,
el efecto torre de babel: el mismo error se informaba con mensajes diferentes que
hacan creer a los usuarios que eran diferentes. Existe un caso muy clsico, dar
aviso que no existe una referencia, por ejemplo de cliente; mensajes del tipo: NO
EXISTE CDIGO DE CLIENTE, CLIENTE NO DISPONIBLE, ERROR EN EL
ACCESO A CLIENTES, hasta ERROR DE E/S, etc., se utilizaban para avisar de
este error.

Y la llegada de los sistemas distribuidos fue el remate final. La distribucin del
desarrollo entre diferentes equipos de trabajo y la extensin de los lugares de
origen acab de agravar el problema.

Soy un firme defensor de que los errores deben estar codificados e informados en
un repositorio de errores, donde a dems de un cdigo, cada error debe tener su
origen, su destino, su nivel de gravedad, etc. Y desde aqu, hacer la gestin de
errores multidioma es muy simple.

Las piezas necesarias para gestionar este repositorio sern:

O Un sistema de mantenimiento del repositorio de tipificacin de errores.
O Un modulo de gestin de errores desde los programas de aplicaciones
con las prestaciones que hemos visto desde aqu. En particular habr un
mtodo para, dado un cdigo de error, localizar su descripcin y tratamiento.
Puede existir tambin un mtodo que permita al operador obtener informacin
on line del error para evitarle consultar manuales.
O Un modulo de administracin que permita cambiar sobre la marcha los
parmetros dinmicos: gravedad, destinatario, etc.
O Un sistema rpido de consulta on line. Cuando un programador deba dar
un error, consultar el repositorio: si el error ya existe lo usar identificndolo
por su referencia. Si no existe, lo aadir. Codificar nuevos errores puede
dejarse a libertad del programador u obligar a pasar por un filtro unificador.
Cada organizacin elegir la solucin que ms le convenga.
O Un transportista de mensajes de error del que ya se ha hablado.
O Un sistema de archivar los errores producidos.
O Un mdulo para de anlisis de los errores archivados. Dispondr de las
opciones necesarias de consulta y notificacin a los responsables de los
errores de que ya se ha hablado. Si se le da persistencia permitir el anlisis
histrico

Siempre que pueda, aproveche al mximo la plataforma de anlisis de la gestin de
la administracin del sistema integrando la gestin de errores en ella.

Una recomendacin final. Recordarle que dentro del capitulo dedicado al servidor
de correo se aportan criterios sobre la gestin de errores que no voy a repetir aqu.
Por favor, si no los recuerda, consltelos.

8. Gestin de la concurrencia, el paralelismo y la recuperacin.

La necesidad de controlar la concurrencia surge del hecho de que diversos clientes
accedan de forma simultnea al mismo servicio produciendo una congestin
puntual reflejada en una deterioracin del tiempo de respuesta que puede llegar a
producir en el cliente la notificacin errnea de cada del servicio. El tema suele ser
importante en los servicios de datos, especialmente de consulta.

La necesidad de controlar el paralelismo surge del hecho de que ms de un
servidor atienda el mismo servicio, solucin habitual para el tema de la congestin
en la concurrencia. Recuerde que hay dos formas de hacerlo: con ms de una
instancia del servidor y con un servidor multihilo. En cualquier caso, el problema es
aqu evitar que los diferentes servidores o hilos colisionen entre s.

Estos temas deben ser contemplados en el diseo del sistema distribuido, en
particular, dentro del diseo de la arquitectura distribuida. Es un error pensar que el
esfuerzo importante se ha de hacer dentro del anlisis de consistencia.

La necesidad de la recuperacin surge de la posibilidad de que alguno de los
servicios que se ejecutan fallen por causes lgicas, fsicas, de concurrencia o de
paralelismo.

La concurrencia ha de ser contemplada en el diseo en dos sentidos. En primer
lugar diseando la arquitectura distribuida en funcin de la ocupacin prevista para
cada servicio. En segundo lugar proporcionando las herramientas de administracin
necesaria para gestionarla correctamente.

Concurrencia y recuperacin estn ligadas por el hecho de que la congestin pueda
inducir al cliente a la cada. La recuperacin de la congestin necesitar
normalmente slo de la gestin de errores; difcilmente una congestin resistir una
buena gestin de recuperacin de errores.

Si la gestin de errores no llega a recuperarla, se producir la cada en emergencia
y el inicio de la situacin de trabajo de ese estado. Tampoco aqu habr problemas
para seguir si la situacin de emergencia est bien resuelta. En cualquier caso, los
administradores debern ajustar los parmetros de la gestin de errores (nmero
de reintentos y espacio entre ellos) para conseguir evitar la cada.

Si an as hay ocasiones en que el sistema cae, debe dirigir el problema a los
diseadores que debern mejorar la arquitectura del sistema o los recursos de
hardware para resolver el origen del problema. Por favor, no abuse del aumento de
potencia de la plataforma: si realmente hay un problema de congestin, originado
en un fallo de diseo o en un aumento de las necesidades del sistema distribuido,
se ha demostrado que la solucin del hardware es siempre provisional y que al
final, el problema siempre acaba reapareciendo.

El paralelismo es un tema totalmente de desarrollo y una aplicacin bien
diseada y bien implementada no debera presentar problemas de este tipo en fase
de explotacin.

Recuerde, finalmente, que los problemas del paralelismo suelen agruparse
alrededor de dos grandes ejes:

O Sincronizacin de las instancias y/o de los hilos.
O Acceso simultneo a la cola y recursos compartidos por las instancias o hilos.

Por ltimo, remarcar que el problema de la concurrencia es especialmente
importante en las aplicaciones cliente/servidor basadas en Internet. Aunque
aqu, la naturaleza transaccional de la WEB facilita en gran manera la solucin. Se
cualquier forma, los diseadores de las aplicaciones Web deben ser especialmente
sensibles en este tema.

9. Tipificacin del comportamiento del servidor: semntica de servidores.

Con los agentes la comunicacin es desacoplada y que el servicio se interrumpa
temporalmente, siempre que se pueda certificar la certeza de la anotacin en curso
(implementacin de la full tolerante), no supone un problema especialmente grave.

Por el contrario, los servidores, que son especializados, encapsulan los servicios y
caen, son el punto fundamental sobre el que debe girar el anlisis de la
consistencia ya que provocan el cuelgue de los clientes que los han solicitado.

Por eso, si el anlisis de consistencia gira a su alrededor, ser interesante tipificar
el comportamiento de un servidor en caso de cada de una conexin entre un
servidor y un cliente.

La clasificacin del comportamiento de un servidor segn sea su compromiso de
servicio en caso de cada se conoce como semntica del servidor.

As se habla de las siguientes semnticas de comportamiento de un servidor:

9. 1. Servidor may be (quizs).

Es un servidor sin garanta de servicio. Su comportamiento es inseguro.

El cliente no puede recuperar nada porque no tiene informacin de que ha
pasado. Observe que la nica forma de asegurar el servicio es consultar algn
parmetro que permita asegurar que ha acabado bien; por ejemplo, si es una
modificacin, consultar que el valor est cambiado en destino. Si el dato es
poco voltil, puede ser una solucin, pero se imagina esto en una gestin de
stocks distribuida.... Y en cualquier caso el sistema es altamente ineficaz.

No hay que decir, pues, que es un comportamiento no admisible en un servicio.
Pero, no se fe! ya que desgraciadamente, aunque no se lo digan, puede
encontrar servicios de Middleware que se comporten as.

9. 2. Servidor at least once (al menos una vez).

Son servidores de ejecucin segura. Esta semntica garantiza que, si el
servidor ha sido llamado, el servicio se ha ejecutado. Observe que con esta
semntica, si el servicio se ha pedido ms de una vez, por ejemplo por una
recuperacin de cliente ante una cada aparente del servicio, este se ha
ejecutado dos veces; de ah lo de ejecucin segura.

El mecanismo de recuperacin del cliente enva la peticin de servicio tantas
veces como tenga parametrizado en su gestin de errores hasta conseguir
respuesta, y si finalmente no se recuperar caer en emergencia.

Observe que para que un servidor pueda tener esta semntica de
comportamiento, el servicio a de ser idempotente.

9. 3. Servidor at most once (como mximo una vez).

Ejecucin segura y slo una vez. El servidor es capaz de reconocer que el
servicio ya de ha pedido antes, no lo procesa pero lanza la respuesta como si
lo hubiera hecho. De ah, que la ejecucin sea segura y slo una vez.

Garantiza que el servicio no ha quedado a medias y se ha completado siempre
y que si hay una nueva peticin del mismo servicio, se recupera el estado
anterior sin ejecutar de nuevo la peticin y se transmite al cliente, que de est
forma da el servicio por acabado correctamente.

De esta forma, el cliente para recuperar el servicio, slo tiene que reintentarlo
hasta conseguir respuesta.

Es el comportamiento deseable y recomendado en un servidor de
aplicacin. Invertir en conseguirlo, es abaratar a tope los costes de
explotacin y administracin.

9. 4. Servidor exactly once (exactamente una vez).

Fiabilidad total (full tolerance). El cliente no necesita controlar la ejecucin
del servicio. Es un nivel de comportamiento exigible en una comunicacin
asncrona desacoplada.

Es, naturalmente el servidor ideal ya que garantiza la ejecucin nica en
cualquier circunstancia. Es un comportamiento que, obviamente, no es fcil de
implementar y que difcilmente encontrar en un servicio de Middleware.

9. 5. Implementacin de semntica en servicios montados sobre colas.

Existe una forma muy fiable de implementar un comportamiento at most once
y full tolerence en servidores que se comunican con sus clientes por una cola,
situacin por otra parte muy habitual. Consiste en trabajar correctamente con la
referencia de cliente (que proporciona ste) y la referencia de anotacin (que
proporciona la cola) en las anotaciones de peticin de servicio. Antes de seguir,
si no recuerda este tema repselo en los apartados dedicados a las colas en el
captulo dedicado a los componentes operacionales; en particular, recuerde el
apartado dedicado a la Dinmica de las Referencias.

Recuerde tambin que un dilogo cliente/servidor es un protocolo de dos
mensajes, uno de peticin y otro de respuesta.

Para que la consistencia sea posible, dentro de cada mensaje deber de tener
dos pasos.

En la peticin: envo del cliente
y notificacin del servicio de que
la anotacin se ha recibido.
En la respuesta: envo del
servidor y notificacin del cliente
de que se ha recibido.

La implementacin de una semntica
at most one o full tolerante deber
seguir los siguientes pasos.

9.5.1. Atributos de la comunicacin.

Incluir en todas las comunicaciones las referencias de cliente y
anotacin el mecanismo de confirmacin. Y en las comunicaciones
cola/servidor la referencia del servidor que atiende el servicio.

9.5.2. Anotacin del servicio por el cliente:

El cliente aportar la referencia de cliente y en la cola devolver en la
confirmacin a referencia de anotacin. El cliente sabr que el mensaje
se ha anotado cuando reciba su referencia de cliente junto a una de
anotacin. A partir de aqu todas las comunicaciones incluirn ambas
referencias.

Si la cola recibe otra peticin de anotacin con la misma referencia de
cliente sobre grabar la anterior si no est en ejecucin (por si ha
habido algn cambio) y devolver la referencia de anotacin que ya
tena asignada a esa peticin. Puede incluirse en la respuesta un aviso
del estado de tratamiento de la anotacin para mejor control del cliente.

9.5.3. Comunicacin cola/servidor.

Cuando el servidor pida una anotacin pendiente, la cola anotar la
referencia del servidor. Si el servidor no puede anotar la respuesta en la
cola, cuando vuelva a pedir una nueva anotacin, la cola ha de detectar
que ese servidor tiene una en proceso le ha de proporcionar la misma
referencia. El servidor detectar que ya la ha gestionado por coincidir
las dos referencias y volver a anotar la respuesta sin hacer otra vez el
servicio.

Como el servidor tendr ms de un cliente, deber crear una tabla
dinmica de ltimos servicios, con un nmero mximo de clientes y
un nmero mximo de llamadas recibidas por cliente, donde anotar las
ltimas referencias de cliente y anotacin gestionadas. Cuando el
servidor arranque, esta tabla se vaciar; cada vez que un nuevo cliente
realice la primera peticin, se le dar de alta en la tabla con el mximo
de servicios que hay que almacenar; dentro de la zona de cada cliente,
la gestin de sus anotaciones ser de cola circular.

9.5.4. Respuesta de la cola al cliente.

Si el cliente pierde la respuesta, la cola se la reenviar sin ningn
problema. Cuando la cola reciba la confirmacin del cliente de que ha
Cola Cliente
Peticin
Envo
Confirmacin
Cola Cliente
Respuesta
Envo
Confirmacin
Servidor
Recogida
Devolucin

Figura 266. Mecanismo de comunicacin C/S
con confirmacin
recibido la respuesta ya estar en condiciones de poder borrar la
anotacin en el momento que tenga planificado.

Si lo que se pierde en la confirmacin del cliente de que ha recibido la
respuesta, la anotacin de la respuesta quedar en la cola como
pendiente de servir y deber ser eliminada por caducidad.

Conviene estudiar las respuestas pendientes de recoger para detectar
puntos dbiles en el sistema.

9. 6. Servidores de datos y comportamiento at most one.

Dentro del diseo de la arquitectura de servidores he defendido que las
funciones de modificacin y consulta se separen en servidores separados.

Utilizando este criterio, los servicios de consulta son idempotentes y la
semntica al menos una vez ya les va bien. Igual pasa en los servicios de
mantenimiento idempotentes. La recuperacin puede centrarse en los de
mantenimiento no idempotentes (lo habitual) en los que hay que garantizar
comportamiento al most one.

Para dar este comportamiento a los servidores de datos, es muy til disponer
de dos mecanismos adicionales en los servidores de las BD.:

Recuperacin dinmica hacia atrs del estado del sistema tal cual estaba
antes de la peticin del servicio, pocas veces utilizado si existe un control
como el anterior.
Rearraque de emergencia de forma que, cuando el servidor vuelva a
arrancar despus de la cada de su nodo, sea capaz de saber que le ha
quedado una transaccin pendiente y acabarla o retrocederla.

Para conseguir estas funciones, las BD suelen dar los recursos necesarios a
travs del Middleware que las envuelve.

Existen cuatro mecanismos clsicos que pueden utilizarse para garantizar la
integridad de los datos modificados:

9.6.1. Protocolo de dos llamadas.

El protocolo de tiene los siguientes pasos:

El cliente lanza una peticin de servicio asncrona y recibe la
confirmacin de la aceptacin de la peticin por el servidor.
Cuando el servidor acaba deja notificacin al cliente de que tiene
la respuesta preparada y queda a la espera de la segunda llamada.
El cliente pregunta si tiene la respuesta disponible.
El cliente pide al servidor la respuesta en la segunda llamada.

Aunque el mecanismo es clsico de datos, obviamente puede utilizarse
para cualquier servidor.

Observe de cualquier forma que esta forma de implementar la
consistencia de llamada por la dinmica de referencias.

9.6.2. Mecanismo de Call-back (llamada al origen).

Es una solucin alternativa en la cual el servidor llama al cliente para
enviarle la respuesta cuando la tiene.

El servidor necesita saber la localizacin del cliente que le ha hecho la
llamada. No es un sistema que yo le recomiende ya que estropea del
criterio bsico que establece que la peticin la inicia el cliente de forma
transparente.

9.6.3. Mecanismo de Confirmacin por Lectura.

Solo en situaciones muy crticas (problemas de eficiencia) y con flujos
de modificacin bajos podra recurrirse a verificar con una lectura
posterior la modificacin.

Puede mejorarse la eficacia confirmando por sumarizacin.

9.6.4. Mecanismos de control de la replicacin.

Repselos en el captulo correspondiente.

9. 7. Arrancadas alternativas.

Una opcin vlida para garantizar el funcionamiento es arrancar el servidor en
otro nodo cuando el que est trabajando cae y desviarle en trfico pendiente en
ese momento.

Esta solucin suele montarse con una arquitectura de distribucin. Un servidor
de distribucin se localiza en el mismo nodo que el cliente. Todas las
peticiones del cliente se dirigen a este servidor, que obviamente nada ms
caer si cae el nodo y por tanto tambin el servidor. El servidor de distribucin
redirige la llamada al servidor especializado.

En caso de cada, el servidor de distribucin puede pasar la llamada a otro
nodo, arrancando el servidor si es necesario. Observe que segn el volumen
de la respuesta habr que complementar la solucin con una arquitectura de
filtro y que el servidor debe saber si la peticin que se recibe es una cada en
otra instancia y, si es necesario, verificar que, si el servicio no es idempotente,
el otro servidor no hubiera finalizado ya el servicio antes de caer. Es importante
conocer tambin si la cada del servicio ha sido por fallo del nodo o por cada
del transportista.

La tcnica puede ser utilizada tambin en caso de congestin, arrancando
otras instancias del servidor que cooperen en el trabajo. No tengo que
recordarle que los servidores han de ser concurrentes y con arquitectura
multicliente-multiservidor.

La tcnica es de un alto coste de programacin.

10. Utilizacin de arquitecturas Proxy.

Recuerde que una de las formas de disear consistencia incluyndola en el propio
servicio es la utilizacin de arquitecturas de Representante o Proxy.

Si no la recuerda, repase este tipo de arquitectura de servicios en el capitulo
dedicado a ese tema.

11. El problema de los hurfanos.

Hasta ahora hemos visto la cada siempre desde la ptica del cliente: el que cae es
el servidor.

Pero, por favor, pensemos un poco desde la perspectiva del sufrido servidor. Si el
cliente cae, el servidor puede encontrarse con una respuesta que no tiene quien la
recoja. El proceso servidor se ha quedado hurfano. Este problema se referencia
por eso como el problema de los hurfanos.

Si la comunicacin es asncrona el problema prcticamente no existe ya que el
servidor habr colocado la respuesta en la cola de comunicacin. El cliente podr
consultarla si hay reintento.

Si es sncrona, el servidor la ignorar o guardar, junto a la referencia del cliente,
por si hay reintento. Se escoger una opcin u otra segn la semntica del servidor.

Si el modo de comunicacin, por ejemplo colas, guarda respuestas hurfanas,
peridicamente hay que preveer un proceso de eliminacin.

Mucho cuidado en comunicaciones sncronas, sobre todo si son piezas de
Middleware comprado, ya que un servidor hurfano puede quedarse clavado
esperando la disponibilidad del cliente para enviarle su respuesta. El efecto de esta
situacin sera una parada drstica del servicio en todo el sistema distribuido.

Y observe tambin que un sistema sncrono con full tolerance y con control de
hurfanos se parece descaradamente a un servicio asncrono.

Finalmente hacer notar que el problema de los hurfanos es especialmente
importante en Internet, donde el cliente es desconocido del servidor y puede ser
cancelado, por accin de operador o por time-out, en cualquier momento.

12. Arrancada del servidor desde el cliente.

Si el entorno y la aplicacin lo permiten, parte del proceso de recuperacin del
servicio puede ser arrancar el servidor desde el cliente por si por la causa que fuera
el programa servidor ha desaparecido

Si se utiliza este recurso debe asegurarse como mnimo que:

O El cliente tiene forma de conocer donde se debe arrancar el servicio.
O El servidor debe auto controlar en su arrancada que:
O No hay otra instancia arrancada si no es el multinstancia.
O Coordinarse con las ya arrancadas si lo es.

13. Gestin de la situacin de emergencia.

Como ha se dicho anteriormente, si el servicio no se recupera, habr que decidir
que hay que hacer.

Si el sistema lo permite, puede simplemente esperarse a que el servicio se
recupere; un caso tpico es una aplicacin de consulta con crtica cuando cae el
servidor de datos.

Si el sistema de informacin ha de seguir trabajando (un caso tpico es una oficina
de ventas), habr que poner el sistema en emergencia y definir una estrategia para
seguir trabajando.

Pueden utilizarse dos estrategias:

O Cancelar la operativa de los servidores y hacer que el sistema deje de trabajar
con ese servicio. Por ejemplo si cae un servidor de crdito de clientes, puede
decidirse que en la situacin de emergencia no se verifique el crdito.
O Sustituir el servicio del servidor por otro de emergencia, y encolar los servicios
no realizados para recuperarlos cuando el servidor vuelva a estar disponible.
Si la estrategia es recuperar, han de disearse funciones paralelas que se
han de responsabilizar de hacerlo cuando el servidor vuelva a estar
disponible. En funcin de las caractersticas del servicio, el cliente saldr de
emergencia antes o despus de procesar las peticiones pendientes.

Los criterios para la gestin de la situacin de emergencia son organizativos (que
se puede hacer, donde y como) y econmicos (coste, directo e indirecto, de no dar
servicio).

13. 1. Componentes de la gestin de la situacin de emergencia.

El diseo de los procesos de trabajo en emergencia puede atacarse de una
forma genrica. Si se hace as, se detecta rpidamente la existencia de
componentes reutilizables. A continuacin le presento estos componentes
dejando para el final un esquema de funcionamiento conjunto.

13.1.1. Una agrupacin de trabajo de servidores.

Es decir, agrupar todos los servidores unidos por afinidad. La
agrupacin puede ser:

Estrictamente fsica:
Todos los servidores que atacan la misma base de datos.
Agrupar servidores por el uso seguro de un recurso fsico
obligado; por ejemplo, todos los servidores que atacan un
nodo remoto por la misma va fsica.
Basada en la localizacin. Por ejemplo, todos los servidores
localizados en la misma mquina servidora.
Funcional. Todos los agentes, la comunicacin con los cuales es
desacoplada pueden formar una agrupacin ya que la recuperacin
es por reintento despus del tiempo de sleep y el log de trabajos
pendientes es la misma cola de espera o el mecanismo equivalente
que se utilice para pasarle el trabajo.

Como observar, los dos primeros criterios son muy claros, pero el
ltimo est condicionando fuertemente la administracin del sistema ya
que un servidor, que puede parecer muy claro que estar en un nodo
junto a otros, puede, con el transcurso del tiempo y por las
circunstancias de consumo y evolucin tecnolgica, pasar a estar en
otro nodo. Le aconsejo, pues, que utilice a fondo los dos primeros pero
huya del tercero.

13.1.2. Semforo de disponibilidad.

Cuando en servidor cae en emergencia, debe conocer que en la
siguiente llamada no debe intentar usar el servicio ya que si lo hace
volver a repetir todo el proceso de recuperacin y la respuesta del
sistema se ralentizar innecesariamente.

Para controlar si el servicio est en uso o no, asocie un semforo por
cada grupo de servidores lgico.

Si el servidor no pertenece a ningn grupo, el semforo estar
implementado en su interior. La activacin del servicio puede recibirse
por un evento o preguntarse peridicamente a travs de un hilo. Note
que en este caso el cliente siempre llama al servicio que es el que le
devuelve si esta en emergencia o no.

Si es de un grupo, el semforo deber ser un recurso compartido por el
grupo, esttico (fichero) o dinmico (servidor independiente).

El servidor, cuando detecte que el servicio ha cado pondr el semforo
en rojo. Y antes de cada llamada lo consultar. Por esta razn, el
semforo deber montarse de forma que su respuesta sea muy
eficiente, lo que prima mucho su implementacin esttica sobre la
dinmica.

Es conveniente utilizar semforos de tres posiciones ya que el amarillo
puede utilizarse para funciones de control durante la recuperacin.
Hablaremos ms adelante de est posibilidad.

Observe que en este caso, la consulta de situacin de emergencia se
puede hacer tanto desde el cliente como desde el servidor lo que
permite decidir quien gestiona la situacin de emergencia, el cliente o el
servidor.

Si la alternativa es utilizar otro servicio prime la opcin del servidor. Si la
alternativa es hacer otros procesos para cubrir la situacin de
emergencia, es mejor responsabilizar al cliente.

13.1.3. El vigilante.

Vigilar si el servicio sigue cado o no. Deber activarse cuando el
servicio haya cado, y peridicamente, con el tiempo que tenga
parametrizado, har comprobaciones de s el servicio est recuperado o
no. Cuando detecte la recuperacin colocar el semforo en amarillo o
verde segn convenga a la funcionalidad de la aplicacin.

Para comprobar si el servicio se ha recuperado puede utilizarse:

Una peticin especializada del tipo peticin de conexin.
Una peticin de servicio particular e inocuo para el sistema. Por
ejemplo, en una base de datos, acceder a una entidad con una
referencia que no exista; si el servidor ya est disponible responder
con un no existe suficiente para saber que ya est activo.

El vigilante debe disponer de un mecanismo para lanzar programas. Se
utilizar para lanzar los procesos de recuperacin. El proceso de
recuperacin est ligado al semforo y deber ser, obviamente,
parametrizable.

En principio, se asocia un vigilante a cada semforo. Sin embargo, si
hay muchos semforos puede haber un problema de eficacia y es mejor
que un solo vigilante controle ms de un semforo.

Un vigilante se implementa como un cliente back-ground y es un firme
candidato a ser empaquetado en una pieza reutilizable. Cuando lo
disee y programe piense siempre en darle esa posibilidad.

Los semforos a controlar deben ser tambin parametrizables. En
particular, el vigilante debe conocer la localizacin del servidor. Observe
que vigilante y semforos deben compartir la informacin del recurso
que controlan. Esa razn hace recomendable que compartan el fichero
de parametrizacin.

13.1.4. Logs para registrar el trabajo en emergencia.

La implementacin siempre es por fichero, sobre la BD o simplemente
secuencial. Obviamente, la presencia de log's slo es necesaria si el
sistema ha de recuperar sobre el servidor el trabajo en emergencia,
situacin, por otra parte, muy normal.

La implementacin de logs se encapsula en una pieza genrica que se
especializa en rutinas especficas para cada log.

13. 2. Ciclo de trabajo en emergencia.

Los semforos de disponibilidad y los vigilantes permiten controlar la situacin
de emergencia con el ciclo genrico de trabajo en emergencia se muestra en la
figura. En l se detalla el funcionamiento dinmico conjunto de los
componentes anteriores.

La figura es bastante clara y no necesita, una vez conocidas las funciones de
cada componente, de demasiadas aclaraciones adicionales.

Cuando el cliente est trabajando normalmente y se produce la cada de un
servicio, realizar el proceso de recuperacin de errores. Si es sistema no se
recupera se iniciar el proceso de funcionamiento en emergencia que colocar
el semforo en rojo, iniciar el log y si no lo est ya, arrancar tambin el
vigilante correspondiente.

A partir de este momento cliente y vigilante funcionarn simultneamente.
Como el cliente consultar el semforo antes de utilizar el servicio, cuando
detecte que est en verde, volver a la situacin normal o lanzar el proceso
de recuperacin segn este ltimo este integrado en l o no.

Cuando el vigilante detecte la subida del servicio:

Colocar el semforo en verde o mbar.
Iniciar, si as est diseado, el proceso de recuperacin.
Si no tiene ningn semforo ms a controlar, se auto suspender.

El estado de mbar se utilizar para indicar a los programas cliente que el
servicio ya est activo pero que el proceso de recuperacin de log no se ha
acabado todava. Cada servidor har uso de est informacin como convenga
a su trabajo.

Finalmente, cuando el proceso de recuperacin del log acabe, pondr el
semforo en verde pasando la totalidad del sistema a trabajar normalmente.

Desde los clientes existen dos formas bsicas de gestionar el estado de
emergencia:

Coger el estado del semforo antes de cada acceso al servidor.
Log
Proceso Vigilancia
Checking de
Recuperacin
Sleep
Inicio Proceso
de Recuperacin
Error
Recuperacin
Recuperacin
Gestionar Log
Recuperar
Situacin normal
Error
Trabajo Cliente
En Emergencia
Trabajo Normal
Recuperacin?
No Si
Inicio Situacin
Emergencia
Activar Log
y Status
Arrancar Proceso
de Vigilancia de
Recuperacin
Poner
Rojo
Poner
Ambar
Poner
Verde
Verde?

Figura 267. Ciclo de trabajo en emergencia.
Que cada cliente lleve un semforo interno y que el vigilante avise de la
recuperacin a todos los servidores afectados por el evento.

14. Anotacin del diseo de consistencia sobre los diagramas de flujo en
MAFDRA.

El anlisis de consistencia supone la
incorporacin de nuevos proceso y / o la
modificacin de otros ya existentes para
recoger las nueva funciones necesarias para
implementarlo.

La metodologa MAFDRA que utilizamos
propone describirlos de la misma forma y los
mismos elementos, que ya se han presentado,
que el resto del sistema. Y como es muy til
diferenciar en diagramas de flujo ampliados
que procesos son funcionales y cuales de
consistencia le propongo utilizar para la
descripcin de los flujos de consistencia del
criterio de control de esos diagramas: utilizar el
trazo discontinuo para diferenciarlos.

15. Metodologa del Anlisis de Consistencia.

Podemos agrupar todo lo expuesto en este captulo en una metodologa cuya
secuencia se ilustra en la siguiente figura:

Diseo de Consistencia
Diseo de la
Arquitectura
Distribuida
Semntica de
Servidores
Definicin y Anlisis
Diseo de la
Implementacin
Plan de
Integracin
Anlisis de los
Errores
Identificacin
Gestin
Administracin
Diseo de
Administracin
Diseo
Tecnolgico
Disear Procesos
Preparar el Plan de
Integracin
Anlisis Situacin
de Emergencia
Poltica General
Anlisis de la Cada
Anlisis del Trabajo
en Emergencia
Anlisis Vigilancia
Anlisis
Recuperacin
Negociacin

Figura 269. Metodologa del Diseo de la Consistencia

Proceso
Datos
Almacn de
Datos
Direccin
del Flujo
Direccin de
Transformacin

Figura 268. Extensin de los
diagramas de flujo
para recoger el
anlisis de
consistencia.
Partiendo del Diseo de la Arquitectura Distribuida, le propongo marcar cuatro
etapas bien diferenciadas:

1. Definir la Semntica de los Servidores, encaminada a definir el
comportamiento de recuperacin de cada uno de los servidores identificados
en la etapa anterior.
2. Anlisis de los Errores, encaminada a identificar y normalizar los errores de
cada del sistema.
3. Anlisis de la Situacin de Emergencia, pensada para definir como se
quiere trabajar en esta situacin, y, una vez analizado, definir los procesos de
Cada, Trabajo, Vigilancia y Recuperacin.
4. Diseo Tecnolgico del Anlisis de la Consistencia, con una primera
aproximacin al Plan de Integracin.

El proceso continuar con el Diseo de la Administracin del Sistema Distribuido.

A continuacin se detallan con mayor precisin cada una de estas etapas.

15. 1. Definir la Semntica de Comportamiento de los Servidores.

Para cada uno de los servidores identificados en el sistema se realizarn dos
etapas:

15.1.1. Definicin y Anlisis.

Se analizar la semntica necesaria en el comportamiento del servidor
segn su funcin. Se har uso la semntica presentada anteriormente.

Es a mi juicio la etapa clave de toda la consistencia.

15.1.2. Diseo de la Implementacin.

Se buscar la solucin informtica para implementar la semntica y se
dejar documentada para su implementacin.

15. 2. Anlisis de los errores.

15.2.1. Identificacin.

Se revisarn todos los errores generados en la relacin entre clientes y
servidores. Los errores se referenciarn, se separaran en lgicos y
fsicos, se les asignar prioridad y destinatario funcional.

Poner especial cuidado en que dentro de las arquitecturas de servidores
los errores se arrastren correctamente hacia arriba.

15.2.2. Gestin.

La gestin se establecer con todas las ideas reflejadas con
anterioridad, decidiendo las soluciones tecnolgicas necesarias.

15.2.3. Administracin.

Finalmente, se establecern los criterios de administracin, paso que
conviene adelantar y que equivale al map to reality de otras etapas del
diseo. Conviene hacerlo para verificar que se disponen de los recursos
de plataforma para conseguir la gestin deseada.

En particular se decidirn aqu nmero y espacio entre los reintentos y
que usuarios sern los destinatarios fsicos de los errores.

15. 3. Anlisis de la Situacin de Emergencia.

Si utilizamos, parte o totalmente, el ciclo de trabajo en emergencia propuesto
habr que marcar hasta cinco etapas.

15.3.1. Definir la Poltica General.

Pensar de forma genrica una opcin alternativa a la cada del servicio.
Se utilizar como opcin por defecto para definir el trabajo en
emergencia de los clientes que lo usan. Es bueno adelantar aqu la
decisin de los grupos de vigilancia ya que los servidores de cada grupo
tienen polticas de emergencia ligadas.

Repasar, despus, cada conexin de servicio proveyendo la situacin
de trabajo en emergencia. Ver si la opcin alternativa prevista para el
servidor sirve para la cada en ese cliente. Si no es as definir una de
nueva e incluirla en la documentacin del servidor.

15.3.2. Negociacin.

Los diseadores informticos debern presentar a los responsables de
las aplicaciones las soluciones adoptadas y obtener su validacin.

El objetivo es triple:

Que el usuario valore el alcance de cada decisin.
Validar todo lo previsto.
Obtener su compromiso

15.3.3. Anlisis de la Cada en Emergencia.

Poco habr que hacer aqu ya que las funciones suelen estar, como ya
se ha visto, bien definidas.

15.3.4. Anlisis del Trabajo en Emergencia.

Habr que ver si los cambios introducidos por la situacin de
emergencia no vulneran ninguna funcionalidad.

15.3.5. Anlisis de la Vigilancia.

Habr que confirmar definitivamente los grupos de vigilancia y
personalizar a los vigilantes.

15.3.6. Anlisis de la Recuperacin.

Estudiar la viabilidad de la recuperacin prevista y ajustar el
funcionamiento de los clientes durante ese periodo.

15. 4. Diseo Tecnolgico.

15.4.1. Diseo de los Procesos.

Disear los nuevos procesos y/o incluir en los ya existentes, las nuevas
funciones de consistencia (gestin de errores, cada en emergencia,
trabajo en emergencia y recuperacin). Actualizar la documentacin,
principalmente los diagramas de flujo

15.4.2. Preparar el Plan de Integracin.

Es un buen momento para iniciar la preparacin del Plan de Integracin,
revisando cada cada e incluyendo que se ha de probar en la
recuperacin de errores y la situacin de emergencia.

16. El proceso paralelo como tcnica de consistencia.

En servicios crticos puede disearse que la ejecucin de la misma peticin del servicio se realice por ms
de una instancia del servicio ejecutndose en localizaciones fsicamente distintas. Todas las ejecuciones
se coordinan al principio y al final para asegurar que el servicio solo se ejecuta una vez para cada peticin
del cliente. Si una de la ejecuciones falla las otras acabaran y el servicio ser de semntica de ejecucin
segura.

Esta tcnica permitira un diseo muy seguro a costa de dificultar la programacin y la administracin y
usar ms recursos de la infraestructura.

17. Diseo de Consistencia de la aplicacin de Viajes Areos y Hoteles.

Vamos a aplicar est metodologa a la aplicacin de viajes areos que estamos
diseado como ejemplo en paralelo a la presentacin terica.

17. 1. Semntica de servidores.

17.1.1. Leer Datos Cliente.

Semntica: Al menos una vez (At least one).
Implementacin: Bastar asegurarse que la confirmacin de anotacin
en la cola y de captacin por el servidor funciona
correctamente.

17.1.2. Leer Datos Cliente en la Central.

Semntica: Al menos una vez (At least once).
Implementacin: Bastar asegurarse que la confirmacin de anotacin
en la cola y de captacin por el servidor funciona
correctamente.

17.1.3. Alta Cliente en la Central.

Semntica: Como mximo una vez (At most once).
Implementacin: Si al dar el alta servidor encuentra que el cliente ya
existe, supondr ya se ha ejecutado con anterioridad.
No se prev ninguna verificacin ms debido a que se
supone que un mismo cliente no puede estar al mismo
tiempo en dos oficinas. Si se quisiera seguridad
adicional podra montarse un control chequeando las
referencias de cliente y anotacin.

17.1.4. Actualizar Datos de Venta de Clientes en la Central.

Implementacin: Se montar un control dentro del servidor con tabla de
referencias de los ltimos servicios.

17.1.5. Actualizacin de Datos de la Compaa area.

Implementacin: El servidor es implementado por la Compaa area.
Si no nos inspira confianza y disponemos de la
posibilidad, podemos confirmar por lectura de la
reserva realizada.

17.1.6. Consulta de Hoteles.

Semntica: Al menos una vez (At least one).
Implementacin: El servicio es implementado por el Servicio WEB.

17.1.7. Actualizar Datos de Hoteles.

Implementacin: El servicio es implementado por el Servicio WEB.

17.1.8. Impresin de la Reserva para el cliente.

Semntica: Quizs (May be).
Implementacin: Como la impresin se hace sobre una impresora en
cada puesto de venta, confirmacin de impresin es
visual. Se deber montar una pregunta para confirmar
la impresin y, en caso negativo, reintentar.

17.1.9. Servidor de Correo.

Semntica: Exactamente una vez (Exacty once), ya que la
comunicacin en asncrona desacoplada.
Implementacin: Entre cliente y servidor de correo se deber asegurar
la certeza de la anotacin. Entre las dos partes del
servidor de correo (origen y destino) los bloques de
ficheros se intercalarn con nmero de secuencia que
garantiza que no se pierde ningn bloque (que se
incluir en la respuesta) y un check por software que
garantiza la calidad interna de cada bloque. Al final de
la transmisin se incluir un check engloba y el
nmero de paquetes transmitidos para garantizar que
la informacin es completa. La parte del servidor de
corre de destino deber garantizar que la anotacin en
la cola de destino es segura.

17.1.10. Servidor de Cola.

Semntica: Exactamente una vez (Exacty once), ya que la es la
pieza fundamental del dilogo.
Implementacin: Bastar normalmente con el dilogo de intercambio de
referencias.

17. 2. Anlisis de errores.

17.2.1. Identificacin.

Para poder identificar los errores hay que llegar a una profundidad de
diseo e implementacin que queda fuera de abasto de este ejemplo
centrado en la parte de arquitectura del sistema del tecnolgico.

17.2.2. Gestin.

Se montar totalmente con el esquema general propuesto en este
documento.

17.2.3. Administracin.

Los errores se tratarn dentro de la tienda, que actuar como CASD
local.

Se montar una persistencia de tres meses para los logs de error. No
se prev un paquete especfico de gestin de errores; en caso de que
se necesite algo en esta lnea, se utilizarn los recursos de Office, en
particular Excel y Access.

17. 3. Diseo de la Situacin de Emergencia.

El trabajo en emergencia no afectar a los procesos de estadsticas, que
esperaran en caso de cada a la recuperacin del servicio.

17.3.1. Definicin de la poltica general.

Se analizamos las conexiones cliente/servidor de la localizacin
propuesta, observamos la presencia de cuatro grupos de vigilancia muy
diferenciados:

17.3.1.A. Servidores localizados en la Central.

Si el cliente se ha de ir a buscar a la Central y el servicio ha cado, se
supondr que es alta. Posteriormente el proceso de recuperacin
habr de confirmarlo:

Si realmente es un alta, se har en la Central.
Si ya exista, no se har nada.

Si el importe de la venta es menor de una cantidad (parametrizable)
se supondr que tiene crdito y la venta se realizar. Si es superior,
se pedir confirmacin por telfono. La aplicacin deber pedir esa
confirmacin al usuario que registra la venta. Si el telfono tambin
ha cado, de supondr en todos los casos que el cliente tiene crdito.

Habr que guardar las ventas y enviarlas a la Central cuando se
recupere, o en caso de que la cada dure mucho tiempo, se volcarn
a CD y se enviarn por mensajero.

Como medida adicional de seguridad, las ventas se guardarn
tambin en el PC del puesto de venta para que en caso de error no
recuperable en el servidor, poderlas recuperar de all. En este caso
se utilizar el CD o un mail segn que el servidor de la tienda est en
funcionamiento o no.

17.3.1.B. Compaa Area.

Si cae la WEB de la compaa area, la gestin se har sobre el
catlogo de programacin de vuelos impreso.

Cuando caiga la conexin con la Compaa Area, la confirmacin se
har telefnicamente.

Si el telfono no funciona, la venta no se confirmar en ese
momento. Si el cliente esta de acuerdo, en cuanto sea posible, se
confirmar y avisndose al cliente del xito o fracaso de la gestin.
En caso de que haya plazas, el cliente deber confirmar que sigue
interesado con el viaje enviando una aceptacin por mail o fax.

17.3.1.C. Datos Hoteles.

Cuando caiga los servicios de Servicio WEB se actuar de igual
forma que en el caso de la compaa area.

Por esa razn, en el resto del captulo se tratar nicamente el caso
de la compaa area.

17.3.1.D. Servidores localizados en el servidor de la tienda.

Si caen esos servidores, la venta se har a mano, montndose un
programa de data entry para registrarlo en el puesto cliente y
gestionar la venta ms adelante. Se habrn de registrar todos los
datos del cliente si el que registra la venta no tiene la certeza
absoluta de que ese cliente ya es de la empresa.

Note que habr de hacerse el circuito de emergencia de la Compaa
Area.

17.3.1.E. Servidores localizados en el puesto cliente.

El procesador de textos est localizado en la mquina cliente. Solo
puede caer por avera de la mquina. As, si cae tambin lo har el
programa de venta por lo que no se prev ninguna situacin de
emergencia.

Si cae la impresora del puesto cliente, se dirigirn los impresos hacia
la impresora de otro puesto utilizando los recursos de la red. De
cualquier forma, se prever la existencia de preimpresos por si
finalmente no queda ninguna impresora disponible o por si ha cado
la red junto con la avera de la impresora.

17.3.2. Anlisis de la cada en emergencia.

En la cada en emergencia:

Se habr de iniciar el log de trabajo y/o la confirmacin telefnica
de reserva y/o crdito o el proceso de venta manual segn
corresponda.
Si lo que ha cada es la central o la Compaa Area, habr que
arrancar el proceso de vigilancia.

17.3.3. Anlisis del trabajo en emergencia.

No hay nada ms a aportar ya que la poltica general vale para todos los
casos y no vulnera ninguna funcionalidad.

17.3.4. Anlisis de la vigilancia.

El control de la situacin de emergencia se montar con la operativa de
vigilante propuesta anteriormente.

Se utilizarn dos semforos:

Uno para el grupo de servidores localizados en la Central.
Otro para el servidor de la Compaa Area.

La recuperacin del servidor de la tienda se controlar manualmente.

La implementacin de los semforos ser sobre archivos sobre el
servidor de la tienda y localizados en un subdirectorio del directorio del
vigilante.

Un nico vigilante controlar los dos semforos. Los semforos y el
vigilante se localizarn en el servidor de la tienda.

17.3.5. Anlisis de la recuperacin.

Los clientes pueden rearrancar sin espera a la recuperacin del log.
Esta recuperacin se har de forma automtica con un cliente back-
ground.

17. 4. Diseo Tecnolgico.

17.4.1. Diseo de los procesos.

Empecemos por refinar el
vigilante. Aplicando un primer
nivel de diseo, y una vez
arrancado, su
funcionamiento se muestra
en la figura.

El tiempo de espera ser
parametrizable dentro de la
ficha de configuracin del
vigilante y diferenciar
valores diferentes para la
Central y la Compaa
Area.

Obviamente, cuando los dos semforos estn en verde el vigilante se
auto parar.

Realizando un
refinamiento del
proceso de
Verificacin de
Conexin con la
Central, se obtiene
el diagrama de flujo
de la figura. Para
verificar si hay
conexin se
utilizar el servicio
de consulta de
clientes realizando
una peticin para
un cliente
inexistente y
esperando una
respuesta con el
error lgico no
existe.

Finalmente, en la
figura de la
izquierda se
muestra el
refinamiento de la
Verificacin de la
Conexin con la
Compaa Area.
Como peticin de
prueba se har
servir en este caso
una reserva de un
vuelo que no existe.

Verificar
Conexin
con
la Central
Tiempo de espera
Verificar
Conexin
con la
Compaa
Area
Sleep

Figura 270. Diagrama de flujo inicial del
Vigilante
Conexin
Central
Estado
Conexin
Central
Rojo
Comprobar
Conexin
Central
Respuesta
Poner
Semforo
en Verde
Acceso a
Clientes en
la Central
R
Cola
Clientes

Figura 271. Refinamiento del proceso para Verificar la
Conexin con la Central
Conexin
Compaa
Area
Estado
Conexin
C.Area
Rojo
Comprobar
Conexin
C.Area
Respuesta
Poner
Semforo
en Verde
Proceso
Compaa
Area
R RPC

Figura 272. Refinamiento del proceso para Verificar la
Conexin con la Compaa Area.

Observe que, como el vigilante controla los dos semforos ha de
preguntar si el grupo
est cado antes de
reintentar. Observe
tambin el acceso con
bloqueo al semforo ya
que es un recurso
compartido montado
sobre un fichero en
disco.

Analicemos ahora
como afecta el proceso
de vigilancia a los
servidores. En la figura
se muestra la
adaptacin del servidor
para Leer Datos Cliente
de la Central. De la arquitectura completa de la parte de la Central se
ha representado nicamente el servidor para Leer Datos de Cliente en
la Central.

Si incluimos este proceso en el refinamiento del servidor llegamos al
diagrama de flujo de la figura inferior.

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
Peticin: Cdigo Cliente
Cuentas Clientes
R
Tomar
Datos
Cliente
Tomar
Crdito
R
Hay que
tomar
Crdito
Emergencia?
No
Si
Poner
en Rojo
Cada del
Servidor
Conexin
Central

Figura 274. Consistencia del servidor de leer datos de cliente en la tienda

El proceso de para actualizar datos en la central y en la compaa area
quedar modificado de la siguiente forma:

Clientes local
Leer
Datos
Cliente
Clientes central
R
Leer Datos
Cliente en
la Central
Poner
en Rojo
Cada del servicio
Conexin
Central
Cola
Clientes

Figura 273. Consistencia del Servidor para Leer Datos Cliente
Observe la aparicin de una nueva cola sobre disco con las
actualizaciones pendientes de realizar y de la copia en local (maquina
cliente) de las ventas.

Aparece un proceso completamente nuevo para recuperar la
informacin de la central despus de la recuperacin o por CD si sta
no se produce a tiempo. El diagrama de flujo de este nuevo proceso se
muestra en la siguiente figura:
Anotar
en la
Central
Actualizar
Datos
Clientes
en la Central
R
Pedir
Alta en la
Central
Alta de
Clientes en
la Central
R
Acceder
a Cliente
Central
Leer Datos
Clientes en
la Central
R
Cola de Actualizaciones
Pendientes
ya existe
no existe
Grabar
Ventas
Pendiente
a Floppy
Copia Ventas Local
Grabar
Ventas de
una jornada
a Floppy
Eliminacin
Histrica
Periodo a Eliminar

Figura 276. Nuevo proceso de Recuperacin de la Situacin de Emergencia

Peticin Cliente
Actualiza
reserva
c.Area
Anotar
en la
Central
No hay plazas
Actualizar
Datos
Clientes
En Central
R
Datos Compaa Area
RPC
Proceso
Compaa
Area R
Poner no
Conexin
a C.Area
Cada
Conexin
Compaa
Area
Consulta
Telefnica
Emergencia
Compaa
Area?
Emergencia
Central?
Poner no
Conexin
con Central
Conexin
Central
Encolar
Peticin
Cola de Actualizaciones
Pendientes
Cola
Clientes
Anotar
en la
Central
Copia en Local de Ventas

Figura 275. Diagrama de Consistencia del proceso para Actualizar Ventas.
Este proceso de recuperacin se montar como un cliente back-ground
con posibilidad de arrancarse manualmente o de forma automtica
desde el vigilante.

Observe tambin la aparicin del proceso de seleccin en CD de las
ventas pendientes y de recuperacin de ventas de una jornada desde
cada puesto de trabajo. Obviamente, en este ltimo caso, habr que
sacar un CD de cada puesto de trabajo. Si la copia se enva por mail se
utilizar el paquete de correo electrnico de la instalacin.
Evidentemente la aplicacin de la Central debe tener un proceso back-
ground que lea del CD y llame al servidor de actualizacin.

Finalmente, debe preverse
un proceso de eliminacin
histrica de las copias de
ventas. Este proceso se
puede integrar en un
cliente back-ground que se
pase de forma automtica
cada vez que se arranque
el puesto cliente
parametrizado con la
fecha del da como tope
superior y que elimine todo
lo anterior.

El proceso de Data-Entry
permitir simplemente
imprimir la reserva. Se
guardar una copia de la
reserva para, junto con la
relacin de ventas
realizadas, hacer la venta
posteriormente, y con los
programas habituales sin
tener el cliente delante,
cuando el servidor de la
tienda se recupere.

17.4.2. Preparar el Plan de Integracin.

El plan de integracin deber contener como mmico las siguientes
pruebas de consistencia:

Desconexin de la lnea de telefnica con la compaa area.
Volverla a conectar antes del ltimo reintento de recuperacin:
comprobar que el proceso recupera correctamente.
Esperar a que se inicie el proceso de emergencia. Comprobar
que se arranca el vigilante y que el proceso de emergencia (la
peticin de telefnica funciona).
Reconectar la lnea: comprobar que el vigilante lo detecta,
notifica correctamente y se auto detiene.
Desconexin de la comunicacin con la Central y actuar de la
misma forma que en el apartado anterior. Probar con la situacin de
Entrada
Manual
Relacin de Ventas
Albarn
Impresin
Albarn
Cliente
Albarn
Proceso
Normal
de Venta
Cliente

Figura 277. Proceso de Data Entry para la Venta
Manual
emergencia con clientes nuevos y ya existentes. Probar y
comprobar el proceso de recuperacin de forma exhaustiva.
Probar conjuntamente las dos situaciones de emergencia.
Comprobar que los CDs de recuperacin se procesan
correctamente en la Central.
Probar la cada del servidor del Local y probar el programa de data-
entry.
Comprobar que con la copia de la reserva puede recuperar el
proceso a posteriori.

En fin, no intento ser aqu muy exhaustivo ya que la profundidad del
anlisis del ejemplo tampoco lo permite. Baste esta pequea lista para
que Vd. lector se haga una idea del contenido de que deber dotar al
plan de integracin.

18. Diseo de Administracin de la aplicacin de Viajes Areos.

El diseo de administracin de un ejemplo docente es de muy difcil realizacin
sobre el papel ya que necesita enfrentarse a una situacin organizativa y operativa
real. Pero entrar en describir una situacin real no es nada que mejore
substancialmente la calidad didctica de una metodologa de diseo como la que
estamos desarrollando. Por tanto, me voy a limitar aqu a apuntar un simple boceto.

O El Centro de Administracin Central (CASD) y el Centro de Direccin (CDSD)
estn en la Central.
O El Centro de Administracin Local es la oficina de venta.
O La Gestin remota se har mediante un programa especializado.
O Adems de las mtricas de gestin de redes, se dispondrn, para medir,
valorar y mejorar el rendimiento del sistema, de todas las trazas de
funcionamiento de los servidores, que podrn activarse a voluntad del CASD.
El diseador deber tenerlo en cuenta cuando disee e implemente los
servidores.
O El soporte de usuario se dar jerarquizado con la estructura de
administracin. Se prev montar ayudas en los programas para minimizarlo.
O El servicio de Hot-Line est subcontratado.
O La gestin de copias de seguridad ser de back-up departamental.
O Dentro de cada tienda todas las impresoras estarn disponibles para todo el
mundo. La administracin de impresoras se realizar con los recursos de red.
O Se montar un servidor de programas en el servido de la tienda. Se replicarn
los programas necesarios para cubrir la situacin de emergencia en cada
puesto de venta.
O Para la gestin de versiones se utilizar un paquete especializado.
O Se instalar un firewall en el servidor del local y antivirus en todas las
mquinas con mantenimiento de versin centrada en el servidor del local.

Integracin funcional del Cliente.

1. Introduccin.

En la metodologa que estamos desarrollando, una vez separados los servidores, el
resto de funciones deben implementarse en los clientes.

Recuerde que deber integrar en la parte como una parte ms de la funcionalidad:

O El anlisis de consistencia.
O La parte delegada a los clientes del anlisis de administracin.

De las diferentes formas de hacerlo trata este captulo.

2. La implementacin del cliente.

El desarrollo de esta parte de una aplicacin
distribuida es, en el fondo, convencional. Se
trata de integrar las funciones no
contempladas como servicio en un programa
cliente que utiliza los servicios a travs de
llamadas con las reglas pactadas.

Le recomiendo que utilice tambin aqu la
metodologa puzzle identificando el mximo
nmero de piezas. Ya hemos hablado de las
ventajas de todo tipo que ello comporta. En
particular, djeme recordarle la ms
importante: la facilidad para cambiar
decisiones para separar funciones servidoras
y clientes, que ya sean por error o por
evolucin del sistema deben reconsiderarse.

Los pasos a seguir son:

2. 1. Decidir del modelo de Integracin Funcional.

Se deber definir el modelo de integracin funcional que conviene al proceso
que se est programado.

Este es, en el fondo, el punto fundamental de este captulo y es por eso que se
tratar con detenimiento ms adelante.

2. 2. Crear la lgica de presentacin y/o los flujos de los procesos.

Evidentemente la lgica de presentacin slo deber crearse si el modelo de
integracin escogido la necesita.

Ya sabemos que aunque el modelo de integracin no sea propiamente guiado
por el cliente a travs de una GUI, en general, existe siempre. Por esa razn,
Completar Diseo de
los clientes
Integracin funcional
Lgica de presentacin
y/o flujos de procesos
Lgicas de proceso y
datos
Especificacin piezas
cliente
Ampliar el cuadro
control administracin
Disear el cuadro de
control del negocio

Figura 278. Integracin del
Cliente
cuando no hay GUIs lo normal es que haya que definir los flujos de proceso.
Esto es lo que ocurre en batch y workflow, por ejemplo.

2. 3. Crear las lgicas de proceso y de datos del cliente.

Es aqu donde se incluirn las llamadas a los servicios y donde deber brillar
su dominio de la metodologa puzzle.

2. 4. Especificacin de las piezas cliente.

Habr que especificar y catalogar las piezas creadas durante la
implementacin del cliente. En realidad, convengamos que esto debera
hacerse en el punto anterior. Pero, permtame, remarcarlo como fase
independiente por la importancia que estas alturas ya ha visto que le doy a todo
lo que huela a reutilizacin.

2. 5. Modificar y ampliar el cuadro de control del sistema distribuido.

Debern incluir en zona del cuadro todos los procesos de negocio obtenidos en
esta parte del diseo.

En particular, es frecuente que como parte de la integracin hayan salido
nuevos tickets de control que habr que supervisar.

2. 6. Disear el cuadro de mandos del negocio.

La idea es paralela al cuadro de mandos de administracin pero trasladado al
negocio. Se trata de resumir en una sola presentacin el estado de negocio.

Aunque los formatos y contenidos dependen de cada negocio, se incluirn con
toda probabilidad tems del tipo:

Comparacin actualizada de previsiones contra la realidad. Un ejemplo
clsico es la comparacin entre previsiones de venta y grado de
cumplimiento a nivel de jornada de trabajo y de periodo, normalmente el
mes, de evaluacin.
Alertas y avisos de negocio: costes de personal disparados, precios de
compra por encima de lo esperado, roturas de stock crticas, etc.

Se primarn al mximo las presentaciones grficas.

La granularidad de la informacin depender del punto de acceso. As, por
ejemplo, ser habitual una estructura jerrquica en la cual el cuadro de mandos
de negocio tenga una vista para cada centro de coste, por ejemplo una tienda
de venta, y que en la central haya dos vistas ortogonales:

La de direccin, que integra todo el negocio.
La de cada departamento especializado, en la que se presentan solo los
indicadores de los que es responsable.

Desde estos niveles integradores se podr navegar hasta la informacin de
cada centro de coste.

Observe que la implementacin visual y tecnolgica es la misma que en el
cuadro de mandos de administracin pero en la esfera de los objetivos de
negocio por lo que lo que todo lo que hemos dicho, y diremos en el ejemplo de
la tercera parte, es vlido para los dos entornos y no hace falta duplicar
explicaciones para incluir ambas casusticas.

3. Perfiles de usuario e integracin.

Cuatro lneas para recordarle que el modelo de integracin elegido habr de tener
en cuenta los perfiles de los usuarios identificados.

Recuerde, que como ya se ha dicho anteriormente, el modelo de integracin deber
tener en cuenta:

O Los derechos de cada usuario segn el perfil de los grupos de usuarios a los
que pertenecen.
O Las opciones especficas de los programas codificados por perfiles
especficos a los que el usuario puede tener o no derecho.

Sea como sea, recuerde que los perfiles marcan derechos y restricciones para cada
usuario que el modelo de integracin deber reflejar y respetar.

Dispondr, o deber crear, de una serie de servicios de seguridad que deber
utilizar como cualquier otro servicio para gestionar la seguridad.

4. Modelos de Integracin.

Existen diversos modelos de integrar el cliente:

O Modelos en los que la iniciativa la lleva el usuario:
O Con una interfcie convencional.
Integracin no grfica, prcticamente obsoleta fuera de los
procesos en lnea.
Integracin grfica.
Integracin GUI.
Integracin WEB.
O Portal.
O Clientes ligeros.
O Transaccional.
O Integraciones basadas en Internet.
O Clientes back-ground.
O Trabajos Batch
O Integracin por estereotipos.
O Integracin en Workflow.
O Trabajo cooperativo.
O Flujo de procesos.
O Integracin por publicacin / suscripcin.
O Integracin por objetos distribuidos
O Pura
O Como plataforma de distribucin.

A continuacin se desarrollan cada uno de los modelos. Notar que prcticamente
de todos ya se ha hablado directa o indirectamente antes de llegar aqu. Como
siempre, no voy a repetir cosas. En el resto del captulo voy a relacionarlos
remarcando los aspectos ms importantes y le dejo como prctica aadir lo de que
cada uno hemos hablado a lo largo del texto.

5. Modelos en los cuales la iniciativa la lleva el usuario con una interfcie
convencional.

Son aquellos en los cuales la secuencia de los acontecimientos la marca el usuario
escogiendo los procesos que quiere ejecutar entre las posibilidades que le ofrece el
programa en cada momento.

Es la forma ms habitual de integracin en la cual el usuario escoge que quiere
hacer entre el men de opciones que le ofrece el sistema.

A pesar de ser el modelo ms habitual de integracin de la parte cliente, es,
curiosamente, el ms complicado ya que el programa debe cerrar en todo momento
al usuario caminos no vlidos en funcin de la evolucin de la secuencia de
ejecucin seguida por el usuario y filtrar sus actuaciones en cada momento.
Adems debera dar opcin a recuperar posibles acciones errneas, en particular,
si son muy destructivas.

Eso es lo que debe pasar. Otra cosa es lo que realmente pasa: las integraciones
cliente se hacen rpidamente y mal; ni se cierran caminos, ni se dan opciones de
recuperacin y, a duras penas, se filtran errores.

Estamos, pues, ante modelos de integracin guiados por la lgica de presentacin.
He eludido hasta aqu esta palabra para que Vd., amigo lector, no confunda este
modelo de integracin con una interfcie grfica, la forma prcticamente universal
con la cual se integra hoy da este modelo.

Sin embargo, no confunda la forma con el fondo. Puede resolver este modelo con
una integracin no grfica, tipo dilogo por lneas. Imagine aqu una pantalla, de
una mquina herramienta por ejemplo, trabajando lnea a lnea, en la cual las
opciones del men se sacan por lneas y el operador escoge a travs de la consola.

De cualquier forma, es evidente que hoy da todo son interfcies grficas y que esta
es la opcin a utilizar siempre con excepcin de muy contadsimas ocasiones,

Una de las excepciones que todava se encuentra son los procesos industriales en
los cuales, por razn de la dureza del puesto de trabajo, hay elementos de dilogo
con visores no grficos de pocas lneas y caracteres.

Dentro de la integracin grfica hay dos posibilidades, la integracin con el
estndar Windows y la de Internet. Esta segunda tiene la gran ventaja de la
estandarizacin con independencia de la plataforma, el gran sueo de todos los
informticos.

Son modelos en general de clientes pesados.

Recuerde que las caractersticas de la interdice grfica cambian segn el mbito a
que va dirigida en uno de los subbloques:

O Administracin.
O Gestin.
O Explotacin.

Consulte, sino lo recuerda el capitulo de la primera parte dedicado a la
administracin donde hablamos de este tema.

Finalmente acurdese de diferenciar en el diseo las GUIs de:

O Navegacin, donde prima de uso del ratn.
O Registro de datos, donde prima la gestin
automtica de la posicin del campo actual y
el uso de los tabuladores para moverse entre
campos vecinos.

La integracin grfica la representaremos como se

6. Integracin grafica multivista.

Surge de la necesidad de adaptar la vista las caractersticas del dispositivo que la
pide i/o del perfil del usuario tipo del dispositivo.

El componente grafico se monta en dos partes:

Obtencin de los datos de la vista.
Adaptacin al dispositivo o perfil de usuario.

Hoy da existen estndares para conocer cual es el tipo de dispositivo del terminal
que hace la peticin.

El perfil tipo del usuario puede estar parametrizado en funcin de la referencia del
terminal que hace la peticin.

7. Portal.

La integracin por portal es la idea que ha
popularizado la WEB y que da entrada a toda la
informacin y procesos de negocio disponibles
desde un nico punto. La integracin en Portal la
representaremos como se muestra en la figura.

En la pgina de despliegue existir, adems de
toda la informacin que se desea dejar pblica,
recursos para autentificar usuarios, internos o
externos, y permitirles introducirse hasta el nivel y contenidos a los que tengan
derechos.

No hay que decir que exige un alto esfuerzo en controlar los derechos y deberes de
cada usuario en todas las funciones afectadas a partir de su autentificacin.

El mbito de los portales puede ser:

O Generalista o temtico segn se acceda a informacin general o de un tema o
rea especfica
O Vertical u horizontal segn se gestionen datos de una nica fuente o de varias

la integracin GUI

la integracin por
Portal
Evidentemente, las dos dimensiones son ortogonales. Observe que en cualquier
caso la idea central es la misma: un punto de entrada nico.

Existen de hecho tres tipos de portales que se corresponden histricamente con su
evolucin. Los tres tipos estn activos y muchas veces coinciden en un nico portal.

7. 1. Portales de contenidos.

El portal abre acceso a repositorios pasivos de informacin o a publicaciones
activas.

7. 2. Portales de aplicacin.

El portal se utiliza como punto de entrada a servidores de aplicaciones ya
existentes, adaptando las funciones visibles al usuario identificado pero
trabajando las aplicaciones de forma independiente. Si es necesaria
coordinacin se realiza por interfases automticas u operadas directamente por
los operadores.

7. 3. Portales de proceso.

El portal gua al usuario travs de diferentes escenarios y le proporciona la
informacin y la ayuda para tomar decisiones. Todas las aplicaciones se ven
como una sola. El portal se puede convertir en un punto de acceso intuitivo a la
informacin y los procesos de la totalidad de la empresa, colaboradores,
proveedores y clientes.

Observe la importancia que en este tipo de portales tienen los problemas
derivados de la dispersin de criterios de autentificacin de usuarios.

Existen dos posibilidades de enfocar el portal:

Por roles, que es la habitual.
Por dispositivos.

Aqu es fundamental separar la lgica de presentacin de las de proceso y
datos que deben crearse o evolucionar a servicios. Este objetivo debe ser una
prerrequisito en las nuevas aplicaciones y obligar a reingeniera en las
heredades.

En muchas ocasiones los portalesw de proceso conllevan problemas de
Upsizing que complican la integracin.

Son portales con necesidad de consistencia, tanto de recuperacin de errores
como de trabajo en emergencia, con las limitaciones que conlleva este punto si
el portal esta desarrollado bajo Internet.

En efecto, imaginemos que el portal integra varias formas de datos o procesos
de forma transparente al usuario. Y que una de ellas falla. El portal debe
reintentar y en caso de no conseguirlo avisar al usuario, suplir la informacin
que falta o buscar vas alternativas.

La arquitectura de un portal de proceso se basa en cuatro componentes:

Los servidores de aplicacin vistos como servicios.
Servicios creados ya como tales.
Motores de procesos de negocio que permitan definir Workflow de
procesos y datos.
El portal en s, que se responsabilizar de:
La autentificacin de usuarios y la personificacin derivada.
El dilogo interactivo con el usuario a travs de una GUI.
La definicin de los modelos de los procesos de negocio y hacer de
motor ejecutor de esos modelos.
La integracin de los servicios.
Realizar en lo posible tratamientos asncronos para optimizar
tiempos.

8. Clientes ligeros.

Los clientes ligeros o modelos de presentacin activos son montajes,
normalmente muy fat server, en los cuales el cliente suele ser un componente de
presentacin que se implementa la lgica de negocio utilizando gran cantidad de
servicios proporcionados su misma compaa o
por terceros. Los representaremos por el smbolo
de la figura.

Aunque son modelos, como los anteriores en los
cuales la iniciativa la lleva el usuario, estn
basados en reducir el programa cliente a un
componente de presentacin especializado que
controla la mayor parte de la lgica de negocio o la delega en un solo servicio.

Este montaje es el habitual para la utilizacin de Servicios WEB en plataforma de
transporte Internet por lo que en la inmensa mayora de los casos, son un caso
particular de ese tipo de integracin.

La integracin en cliente ligero frente a la de cliente pesado tiene muchas
opiniones a favor y en contra, muchas veces condicionadas por las necesidades
comerciales de los productos que se estn ofreciendo.

Veamos las posibles ventajas e inconvenientes, aunque ya le sonarn de otras
partes del libro.

8. 1. Ventajas.

Mnima configuracin del puesto cliente, pudindose usar simplemente
un navegador.
Especializacin del cliente mucho ms fcil y rpida. Ventaja
fundamental.
Reutilitzacin daplicacions ya existentes.
Ofrecer beneficios muy rpidamente.
Bajar el volumen de servicio de Hot-Line al estar los servicios muy
probados y ser la parte cliente muy pequea y especializada.
Facilidad de mantenimiento de versiones.
Adaptabilidad a la plataforma actual de hardware.
Estamos prcticamente en situacin de always on sobre cualquier punto
del sistema de informacin, es decir, la disponibilidad es alta.

Figura 281. Representacin de un
cliente ligero
8. 2. Inconvenientes.

Que existan los servicios que necesito.
Necesidad de ancho de bando importante.
Las herencias pueden motivar descoordinacin entre los servicios
que se ofrecen.
La tcnica de clientes ligeros no se lleva nada bien con procesos del
anlisis de consistencia.

Al final, lo de siempre: valorar pros y contras y decidir como ingenieros que somos.

Observe que hay condicionantes de precondicin muy importantes:

O La presencia de servicios que resuelvan mi problema y que adems sea
posible coordinar entre si de forma cmoda.
O La fuerte dependencia de la red obliga a valorar de entrada la Importancia del
anlisis de consistencia en el sistema de informacin.

Donde est el lmite? No lo s. Pero tengo un sueo; llevarme mi informtica
conmigo sin cargar con mi PC porttil.

Igual que hace unos aos llambamos por telfono a una casa y no a una persona
y la telefona mvil ha revolucionado totalmente el concepto de la comunicacin,
por qu no puedo pensar que en un futuro prximo podr tener mi informtica
disponible en cualquier PC del mundo o terminal de mano sin ms que
autentificarme?

Habremos vuelto al proceso centralizado. Ni hablar! Muy buenos diseadores
distribuidos habrn hecho muy bien su trabajo para permitirnos esa comodidad
apoyndose en el trabajo de los ingenieros de plataformas.

Una posible arquitectura de este tipo son las Aplicaciones Dinmicas de Internet
(RIAs) basadas en AJAX (Asynchrnous JavaScript and XML) como capa de
presentacin.

9. Integracin transaccional.

Recuerde el esquema y la explicacin desarrollada al principio de la primera parte.
Observe que necesita un monitor transaccional, una arquitectura de servidor de
aplicaciones o una plataforma Internet.

Recuerde tambin que es una muy buena solucin cuando el nmero de clientes
ser muy alto, con puntas o, simplemente, imprevisible.

La integracin transaccional la representaremos
por el smbolo de la figura.

Veamos un ejemplo de aplicacin transaccional
que es posible que Vd. utilice con frecuencia: una
red de cajeros automticos de cualquier caja o
banco.

La arquitectura de
funcionamiento de una red de
cajero acostumbra a tener el
diseo de la figura donde un
monitor de transacciones hace
de puente entre los cajeros, que
llevan el peso de la aplicacin
en filosofa de fat client, y los
servicios de cuentas de cliente
que ofrecen los servicios
centrales, normalmente
localizados en un mainframe.

10. Integracin basada en Internet.

Gestor de
Transacciones
Procesador
Componente
de
presentacin
Componente
de
presentacin
Arquitectura Transaccional
Datos
Memoria
Datos Disco

Figura 282. Integracin transaccional

una Integracin
Transaccional
Entorno Corporativo
Maquina Servidora
Servicios
de
Cuentas
Cajero 1
BD
Cajero n
Monitor de
teleproceso
R
R
Servicios
de
envolvente

Figura 284. Ejemplo de integracin trasaccional de una
red de cajeros automticos.
Permite muchas combinaciones tal como se
muestra en la arquitectura habitual de estas
soluciones, muy cercanas a la red global que
todos hemos soado, que se
presenta de forma global en la
figura.

Son arquitecturas, como hemos
visto reiteradamente a lo largo de
nuestro viaje, muy flexibles en las
cuales muchas veces coexisten y
cooperan elementos basados en
Sistema Operativo e Internet y en
la
cuale
s
Internet no es ms, ni menos, que la plataforma de
transporte.

Hay presencia de arquitecturas de configuracin para
que el cliente se pueda autoconfigurar con reglas de
negocio opacas o dinmicas y la situacin actual del sistema de informacin.

Se caracteriza porque gran parte de la verificacin remota se realiza en la parte
cliente par rebajar la concurrencia y/o el trfico de
lneas.

Observe la total opacidad de la parte de servicios
remotos, aprovechando os estndares de Internet, la
coexistencia de plataformas Windows, Linux y WEB.

Recordemos, en particular, la integracin como cliente WEB que representaremos
tal como se muestra en la figura de la derecha.

Cuando queramos representar una WEB convencional usaremos la figura de la
derecha.

11. Clientes Back-Ground.

Son clientes que, como ya hemos dicho anteriormente, trabajan sin interactuar con
el usuario e implementan procesos desatendidos, es decir, que no necesitan
entradas del usuario una vez iniciados.

Pueden confundirse con agentes. Repase el apartado donde se hizo la
diferenciacin entre servidores implementados en agentes y clientes Back-Ground.

La mayora de los agentes son clientes back-ground por lo que esta integracin y la
encapsulacin en servicios implementados por agentes son muy parecidas.

de un cliente WEB
Otros
Servicios
Clientes
Servidor
Reglas de
Negocio
C
D
R
T
W
E
B
S
E
R
V
I
C
E
S
Cliente
Windows
WEB
Browser
R T
R
T
Otros
Servicios
Internos
APIS
Reglas de
Negocio
Cliente
LINUX
R
T
Otros Web Services

Figura 286. Presentacin Activa y plataforma Servicios
WEB

una WEB
convencional

n de clientes
Back-ground
Un cliente Back-Ground puro lo representaremos como se muestra en la figura.

12. Integracin Batch.

Es la agrupacin clsica de programas en una cadena que se ejecuta de forma
automtica. Repase, por sabor, el captulo de la primera parte en el cual se hablo
de este tema.

Parmetros de
filtro y
configuracin
Definicin del
flujo
Proceso n
Proceso i
Proceso i+1
Arquitectura Batch
Proceso 1
Gestor
RJE
Parmetros
control de la
cadena
Resultados
Proceso
Iniciador
Interactivo
Proceso
Iniciador
Desacoplado

Figura 289. Integracin batch

Recuerde que puede utilizarse un componente de presentacin para pedir los
parmetros de la cadena.

Una cadena batch la representaremos como se

La nica limitacin de esta integracin, que debera
utilizarse ms veces de lo que se hace, es que las
cadenas resultantes son distribuibles y no distribuidas
ya que quedan ligadas al lenguaje Batch para la
descripcin de la cadena de cada sistema operativo ya que nunca se ha
desarrollado un estndar en este sentido.

Cuando naci el proceso Batch, all por la cercana prehistoria de nuestra profesin,
los procesos de negocio cubiertos eran pocos y muy bsicos, se ejecutaban sobre
las mquinas de la central y se actuaba por calendarios pactados. Todo el mundo
saba cuando la informacin estaba disponible.

En los sistemas distribuidos actuales las cadenas Batch se pueden ejecutar en
cualquier nodo, muchas veces se inician automticamente cuando la informacin
necesaria ya ha llegado de todos los nodos afectados, es necesario incluir como
parte del diseo de la cadena Batch tres funciones adicionales.

de cadena Batch
12. 1. Control de llegada de toda la informacin necesaria.

Puede resolverse, por ejemplo, por un ticket multihoja asociado a cada
proceso. Consultando manual o automticamente el ticket mediante un agente
pueden generarse funciones del tipo:

Reclamaciones automticas a los retrasados.
Arranque automtico de los procesos batch.
Notificacin a los responsables del lanzamiento manual de que la
informacin ya ha llegado completamente o de que hay nodos que estn
fuera de plazo, etc.

Para la gestin de avisos se har servir el Cartero.

La supervisin del control de llegada debe ser un elemento ms del cuadro de
control de explotacin del sistema distribuido.

12. 2. Control de ejecucin.

El estado de ejecucin de los proceso batch han de ser un elemento ms del
cuadro de mandos de administracin.

12. 3. Notificacin de resultados

Cuando la cadena se ha ejecutado, los usuarios afectados por su trabajo
deben ser informados de ello. La forma de conseguirlo puede ser, por ejemplo:

Dirigir sus listados a sus impresoras.
Utilizar el Cartero.

12. 4. Formas de montar una arquitectura batch.

12.4.1. Ejecucin centralizada.

Es la arquitectura tradicional. Toda la cadena se ejecuta en un nica
maquina, generalmente un HOST.

Observe que si el proceso objetivo de la cadena batch es distribuido,
toda la informacin debe estar disponible en el HOST antes de iniciar la
ejecucin de la cadena batch. Existen dos formas de conseguirlo:

Recoleccin. Desde el HOST se lanzan los procesos de captura a
los nodos distribuidos mediante:
Una arquitectura master-slave.
Eventos.
Comunicacin desacoplada.
Interfase. Los diferentes procesos distribuidos envan a la central
los datos cuando los tienen disponibles.

En ambos casos el uso de ticket para controlar y sincronizar el proceso
se hace fundamental.

12.4.2. Ejecucin distribuida.

Esta arquitectura evita el trasiego de datos si los volmenes son altos.

Obliga a anlisis de consistencia.

Existen dos posibilidades:

12.4.2.A. Captura de datos distribuida.

La cadena batch va a buscar los datos a cada uno de los nodos
originales a travs de servicios.

En una forma de mundo al revs ya que normalmente es el nodo el
que envia o busca los datos en la central.

12.4.2.B. Ejecucin de procesos distribuida.

La cadena batch se estructura en una arquitectura master-slave de
de delegacin donde el master, localizado en el HOST asume la
direccin y las cadenas esclavas se ejecutan en los nodos
distribuidos.

13. La integracin por estereotipos o agentes.

Cada cliente asume una funcin o estereotipo funcional. Cada estereotipo funcional
es asumido por un agente. La integracin
por estereotipos la representaremos como
se muestra en la figura.

OJO: Este agente no es el mismo concepto
que el agente proveedor de servicios,
aunque muchas veces un estereotipo
es un servicio desacoplado y en ese
caso si que coinciden ambas
acepciones de la palabra agente.

As, en un proceso de traspaso de informacin pueden existir los estereotipos o
agentes: generador, transportista, facturador, cobrador, distribuidor, incorporador,
recodificador, etc.

Figura 291. Representacin de una
integracin por estereotipos
En la figura se
muestra un
ejemplo de
integracin por
estereotipos en el
cual un
generador se
cuida de extraer
la informacin de
una BD origen,
un distribuidor la
coloca en la de
envo para varios
nodos donde la
lleva un
transportista. En
uno de los nodos
un recodificador
cambia cdigos diferentes entre las dos bases de datos y, finalmente, un
incorporador la incluye en la base de datos destino.

En este montaje, el generador puede ser una cadena Batch que anota en una cola
y que utiliza el distribuidor como un servicio pasivo. El transportista ser un servidor
de correo. El recodificador y el incorporador sern probablemente agentes en el
concepto de servicio.

La integracin por estereotipos es una utilizacin final de la metodologa de diseo
por estereotipos muy de boga en los primeros aos del proceso distribuido pero
cada hoy da en desuso por sus grandes limitaciones en aplicaciones grandes. Sin
embargo, como forma de integracin funcional del cliente puede ser til y
clarificadora.

Cada estereotipo se implementa con un cliente o en un servicio proporcionado por
un servidor o por un agente. Los clientes son de integracin guiada por el usuario o
Back-Ground, con preferencia de este segundo modelo sobre el primero. En los
pasos intermedios suelen estar los servicios.

Es fcil confundir el modelo de estereotipos con Workflow. No caiga en el error. La
integracin de estereotipos supone proceso secuencial en el cual los agentes
asumen funciones, modeladas en estereotipos, especializadas y claramente
diferenciales.

14. Procesador distribuido.

El procesador distribuido es un ejemplo de
integracin por estereotipos montados en
agentes que diferenciaremos grficamente tal
como se muestra en la figura.

Empecemos por presentar el concepto de
procesador distribuido. Normalmente el
traspaso de informacin entre nodos suele
establecerse con filosofa de interfase. En un
BD
Origen
BD
Destino 1
BD
Destino 2
Generador Distribuidor
Transportista Recodificador
Incorporador Incorporador

Figura 292. Integracin por agentes

Figura 293. Representacin de un
procesador distribuido
momento en que los nodos tienen comunicaciones punto a punto permanentemente
abiertas a costes razonables, se plantea la posibilidad de intercambiar informacin
entre nodos con la filosofa de la replicacin sncrona, es decir, tan rpido como sea
posible. La arquitectura del procesador distribuido responde a esa necesidad.

En una aplicacin suele haber una serie de funciones que se necesitan ejecutar
tanto en local como el remoto. Estas funciones se agrupan conceptualmente bajo
un agente que llamaremos Procesador.

Las opciones del procesador son piezas, objetos o rutinas, que se especializan en
una funcin de la aplicacin integradas como servicios pasivos.

Estas piezas, que forman el corazn del procesador, pueden estar tambin
integradas tanto en los programas clientes como en servidores, Estos clientes y/o
servidores los referenciaremos en el esquema simplemente como Aplicacin.

Si estas funciones se quieren ejecutar independientemente de que la base de datos
es local o remota estaremos ante un procesador distribuido.

Empezamos por necesitar una forma de situar la base de datos
independientemente de su localizacin fsica.

Para conseguirlo podemos asociar un nodo a cada una de esas localizaciones y
ligar a cada nodo su direccin IP. De esta forma podremos dejar operativa una
plataforma SOAP y podremos actuar con ADO si nos conviene.

Montaremos los servidores y agentes siguientes:

O Un servidor de cola de procesos pendientes con ficheros XML para
describirlos y actuando en arquitectura de filtro.
Base datos
local
Base datos
remota
Aplicacin
Procesador Transporte
Viga
Procesador Transporte Transporte
Viga
Procesador
Cola de
procesos
Cola de
procesos
Entorno
Local
Entorno
Remoto

Figura 294. Arquitectura de un procesador distribuido.
O Un viga que explorar la cola de procesos pendientes y, si el trabajo es para
el nodo local le pasar control al agente procesador local y si es para un nodo
remoto al agente de transporte.
O Un agente procesador que recibe por traspaso de responsabilidad el trabajo
del viga, realizndolo y devolviendo el estado de error o xito, que anota en
la cola local.
O Un agente de transporte que recoge el aviso del viga y contacta con el
trasporte de la parte remota, reintentndolo tantas veces como sea necesario.
El transporte de la parte remota revisar la cola de procesos remota y cuando
vea que la anotacin ya est procesada devolver ese estado al agente de
transporte de origen, que anotar el resultado en la cola local. Observemos
que este mecanismo asegura ejecucin segura (full tolerance).

Como se ve esta funcin se puede utilizar por la aplicacin tanto asncrona como
sncronamente, aunque todo el conjunto es de arquitectura asncrona y simtrica
y cualquier nodo se puede comunicar con cualquier nodo de forma simultnea
quedando resuelta la concurrencia y el paralelismo.

Una variante de esta arquitectura es permitir la posibilidad de que la aplicacin, si
necesita hacer muchas conexiones sncronas, incorpore ella misma el transporte de
forma que minimice el nmero de pasos, evitando la cola y consiguiendo as un
tiempo de respuesta mucho ms rpido.

Conviene remarcar, finalmente, que las funciones de transporte no son, en el fondo,
ms que otro conjunto de piezas que hace totalmente posible su integracin
esttica en la aplicacin.

La arquitectura del procesador distribuido pude construirse tambin con una
solucin no tan exigente tecnolgicamente. En la parte local, el viga integra al
procesador y al transporte siendo el funcionamiento en esta parte muy parecido al
caso anterior.

La novedad est en la parte
remota donde existe un
nico agente, que
llamaremos el ejecutor,
donde se integran el
transporte y el procesador y
en que la comunicacin
entre los dos transporte es
sncrona.

Para permitir un mnimo de
concurrencia, dentro del
ejecutor se integran una
pequea cola y el
transporte y el procesador
se montan en dos hilos
diferentes. De esta forma,
el trasporte puede trabajar
de forma desacoplada con
el procesador y se pueden atender, siempre sncronamente, varios clientes,
transporte o aplicacin. Observe que en cualquier caso, debe proporcionarse un
aviso de ejecutor ocupado para el caso de que su cola interna se llene.

Base datos
local
Aplicacin
Viga
Cola de
procesos
Entorno
Local
Base datos
remota
Ejecutor
Transporte
Procesador
Entorno Remoto

Figura 295. El Procesador distribuido sncrono

15. Integracin por Workflow.

La integracin por Workflow se basa en distribuir las funciones cliente entre
programas, muchas veces agentes, distribuidos que
se ejecutan segn una arquitectura de Workflow
que representaremos como se muestra en la figura.

Al Workflow, por su importancia, ya dedicamos en
la primera parte un captulo entero. Si no lo
recuerda, por favor, repselo.

Recordemos que hay dos tipos de procesos de Workflow que se traducen en dos
tipos de integracin:

15. 1. Trabajo Cooperativo.

En el que varios clientes colaboran en un mismo trabajo, normalmente un
documento. Es paralelo al Workflow ad hoc. Por ejemplo, la gestin de un
informe obliga a que anoten diferentes reas de la compaa.

15. 2. Workflow de procesos.

Los clientes distribuidos se agrupan en flujos Workflow que modelan procesos
de negocio de la compaa.

Para que vea como
puede integrarse
una aplicacin
distribuida siguiendo
un modelo de
Workflow
recordemos el
ejemplo, que se
vuelve a mostrar en
la figura, de captulo
de la primera parte
dedicado a este
tema.

una integracin
Workflow
Peticin
de compra
del cliente
VENTAS
Anlisis
del risgo
del
crdito
CRDITOS
Rechazo
CRDITOS
Aprobacin
CRDITOS
Aviso del
rechazo del
crdito
VENTAS
Reserva
producto
ALMACN
Confirmacin
de la venta
VENTAS
Aviso del
rechazo al
cliente
VENTAS

Figura 297. Ejemplo de Workflow.
En la siguiente figura se muestra una posible integracin de una solucin
construida con clientes bajo una arquitectura distribuida para la aceptacin o no
del crdito.

Se supone que existe
una BD histrica con
datos de morosidad
disponible de forma
pblica y un servidor
externo a la empresa,
y una base de
crditos concedidos
en la empresa.

Se propone un cliente
Back-ground con tres
procesos:

O Evaluar, que con la
llamada a un
servidor localizado
en la mquina de la
Base de Datos de Crditos decide si el pedido ha de ser aceptado o
rechazado. El proceso llama por RPC a la Base de Datos externa.
O Rechazar, que con la ayuda del servidor de correo devuelve el pedido al Dpto.
comercial.
O Aceptar, que con el mismo servidor de correo enva el pedido a almacn.

15. 3. Workflow de datos: Sistema de Gestin de documentos.

Recordemos el ejemplo de
SGD que presentamos en la
primera parte como un
ejemplo de Workflow. No es
muy difcil ver que es una
integracin de tipo Workflow
donde se distinguen los
elementos:

El agente de
Reconocimiento y
clasificacin puede ser activado por un conjunto de Viga + Disparador.
La eliminacin histrica es implementada por un agente.

16. Integracin por publicacin y suscripcin.

Peticin
Rechazo
Peticin
Aprobacin
Peticin
Evaluar
Sistema
experto
Base
Histrica
Rechazar
Aprobar
BD
Crditos
RPC
R
Actualizar
Crditos
R
R
Servidor
de correo
Servidor
de correo
R
R

Figura 298. Implementacin del proceso de Aceptacin del Crdito.
SGD (sistema de gestin de datos) o ECM (Gestin de contenidos empresariales)
Proceso
Ofimtica
Fuentes de
documentos
Agente de
Reconocimiento
y Clasificacin
Correo
Directorio (indice)
Repositorios
Eliminacin
del original
Archivo del original
s pel SD
Eliminacin
Histrica
Destinatarios
Proceso

Figura 299. Implementacin de un Sistema de Gestin de
documentos.

una integracin por
publicacin/suscripcin
La integracin por publicacin y suscripcin en un sistema muy potente de integrar
funciones que traspasa el mbito interno de aplicaciones y se convierte en una
forma de integrar aplicaciones muy heterogneas entre si o de terceros, basadas
en local o remoto y con diseo distribuido, Cliente / Servidor o Internet.

Este tipo de integracin lo representaremos tal como se muestra en la figura

La idea es simple y potente. Cuando uno de los mdulos tiene alguna informacin o
cambio de estado que puede ser de inters para otros participantes del escenario lo
"publica" para conocimiento general.

Por otro lado, los mdulos que necesitan estar informados de unos determinados
acontecimientos se "suscriben" a la lista de suscripcin donde se publican esos
acontecimientos. Cuando el distribuidor recibe una publicacin genera un evento
para avisar a todos los suscriptores de ese tipo de informacin registrados en la
lista de suscripcin. En suscriptor, que est ocupado en su trabajo normal,
interrumpe su trabajo para responder al evento o se lo guarda para actuar ms
adelante.

Por su importancia, dedicar a la publicacin y suscripcin un captulo especfico.
Sin embargo, le propongo un ejemplo sencillo para que vea el funcionamiento
general de est forma de integrar.

Imaginemos que un grupo de compaas de seguros quieren controlar clientes
"poco rentables" que cambian de compaa para evitar penalizaciones. Podran
organizar una lista de suscripcin en la que se publicaran los datos de estos
clientes. Cada vez que una de ellas tuviera un percance con uno de ellos, lo
publicara en el tabln que se encargara de generar un evento de aviso al resto de
compaas suscritas. Si una nueva compaa se incorpora al sistema, solo deber
registrarse.

Como ya le he comentado, trataremos enseguida el tema en profundidad. Sin
embargo, amigo lector, se le ocurrirn rpidamente infinidad de usos de esta
tcnica.

17. Integracin por objetos distribuidos.

Si la utilizacin de objetos distribuidos es pura, los componentes del sistema se
conectan al bus de modelo de objetos distribuidos elegido y se comunican entre
ellos. Los objectos que asumen el rol cliente utilizan la interface de los servicios que
proporciona la plataforma y los servidores proporcionan los servicios definidos a las
interfaces.

Sin embargo, una plataforma de objetos distribuidos puede utilizarse tambin, y es
el caso ms frecuente, como plataforma de comunicacin entre las clases en un
dialogo C/S convencional.

18. Los papeles mltiples.

La posibilidad de que un cliente pueda tener, con una sola versin de programa,
diferentes modos de funcionamiento es un aspecto muy importante en la
integracin del cliente que muchas veces es menospreciado o ignorado pese al
poco esfuerzo que supone disponer de l.

No hay ninguna razn tcnica que impida que un solo ejecutable pueda, por
ejemplo, estar en una cadena batch, participar de un flujo de Workflow o ejecutarse
desde una interfcie grfica. Siempre que el programa cumpla una funcin en que
este adaptabilidad tenga sentido, claro est.

Imaginemos, por
ejemplo, un
agente de
facturacin, que a
partir de un fichero
de albaranes y
una impresora,
pude generar
todos los
documentos
implcitos a una
facturacin: la
factura en si, su
impresin, su
inclusin en el
diario de ventas y
la cuenta de
cliente, etc.

Nos puede
interesar arrancar
este facturador:

O Desde una cadena Batch, tomando los parmetros del flujo de la cadena.
O Desde un flujo de Workflow cuando se generar una autorizacin de compra
pro forma.
O Una venta directa en tienda con el cliente presente.
O Lanzar desde una opcin del men la facturacin de todos los albaranes
pendientes.

Y no queremos hacer cuatro montajes de programa, que aunque compartan la
mayora de las piezas, nos obligara a mantener y distribuir cuatro versiones de
ejecutable

Montaremos el programa con una arquitectura como la que se presenta en la figura
gestionando:

O Un parmetro inicial de arranque que nos permitir saber cual es el modo
de trabajo de la ejecucin. Por ejemplo, el modo puede estar asignado a un
parmetro del comando de ejecucin del programa. Si se ejecuta desde
men, desde un proceso de Workflow o desde un escritorio Windows se
aadir en las propiedades del programa y si se llama como servicio se le
pasar como parmetro en el comando de llamada desde el programa cliente
que solicita su trabajo. Si no hay parmetro de configuracin, se asume por
defecto que la ejecucin es batch.
O El resto de parmetros se pasarn dentro de un fichero XML. El nombre de
este fichero se tomar en batch de un parmetro de la cadena, en el flujo
Workflow y el la llamada como servicio de una cola de comunicacin y en la
llamada GUI se pedirn al operador como parte de la interdice grfica.
Parmetros
de la
cadena
Parmetros de configuracin e ejecucin
Captura
Batch
Captura
WorkFlow
Captura de
servicio
Configuracin
Inicial
Captura Gui
Componentes de proceso y datos
Comando de
ejecucin

Figura 301. Papeles mltiples.
O Para los parmetros de resultados se seguirn estrategias parecidas.

Los parmetros se gestionan transaccionalmente, es decir, unas piezas de captura
filtrarn la heterogeneidad del modo de ejecucin, los colocarn en una zona
interna del programa y partir de aqu el resto de piezas que formen el programa
comenzar a trabajar.

Observe que en esta arquitectura el programa original se ha convertido de
facto en un servicio de alto nivel, que es posible independizar como un servicio
ms como intenta simbolizar el marco de la figura anterior.

La guinda final se la imagina en seguida. Esta tirado convertir los componentes de
captura en reutilizables para todos los programas por lo que en el fondo, hacer su
programa adaptable no le costar nada. Fuera de disear bien, claro est.

19. La integracin basada en sistema operativo desde Internet.

Las aplicaciones basadas en sistema operativo, bsicamente Windows, son
perfectamente operables desde Terminal Server lo que plantea una interesante
disyuntiva:

O Integrar sobre sistema operativo y extender a Internet por Terminal Server.
O Integrar sobre Internet y extender al sistema operativo por Intranet.

Ms gris, ms temas sin decisiones claras, pero ms posibilidades de
adaptabilidad!

Y como siempre, el caso real como factor bsico de la decisin.

@EMG-08 - Enric Martnez Gomriz 460
Integracin por publicacin y suscripcin.

1. Introduccin.

La integracin de funciones distribuidas tiene en la publicacin y suscripcin (P/S)
una tcnica muy potente y flexible que trasciende el mbito de la integracin
corporativa y abarca la extra corporativa.

Permite tanto la integracin entre mdulos, que vamos a llamar en lo sucesivo
interlocutores, de una misma aplicacin como la de aplicaciones diferentes, en
local o en remoto, de la misma compaa o de diversas, y en el apoteosis de la
integracin, en arquitectura cliente/servidor, Internet o centralizada. La Integracin
de aplicaciones empresariales o EAI (Enterprise Application Integration) se hace
muchas veces por un modelo de publicacin y suscripcin.

Vamos a hablar dentro de este capitulo de esta idea simple, potente y general.

2. Qu es integrar por publicacin y suscripcin?

Hagamos, de entrada, una rpida introduccin a este concepto. En el sistema
habitual, que se muestra en la parte superior de la figura, los interlocutores se
comunican cara a cara o por interfase.

En una
comunicacin
cara a cara,
sncrona o
asncrona, cada
interlocutor
conoce a priori
que mdulos
necesita utilizar o
necesitan de su
trabajo. Para una
comunicacin por
interfase, es decir
desacoplada, las
necesidades de
conocer
puntualmente
donde est la
otra parte es
menos crtica, pero persiste.

Sea de forma sncrona, asncrona o desacoplada, los interlocutores se intercambian
mensajes directamente cuando se necesitan mutuamente.

Cuando se establece una comunicacin que no exista hay que actuar sobre los
dos interlocutores afectados. Si hay ms de un interlocutor, habr que desarrollar
un modelo de comunicacin para cada uno de los modelos de desarrollo de los
componentes del escenario. Y adems hay que tener posibilidad de hacerlo ya que
Mdulo
Mdulo Mdulo
Mdulo
Comunicacin cara a cara
Comunicacin cara a cara
Mdulo Mdulo Mdulo Mdulo
Comunicacin por bus
Comunicacin por bus

Figura 302. Comunicacin cara a cara versus comunicacin por
bus.
necesitamos informacin de cmo son esos interlocutores con los que nos
queremos integrar. Y en muchas ocasiones el entorno de desarrollo de cada
aplicacin es muy heterogneo.

Si son dos mdulos de organizaciones diferentes, una organizacin debe conocer a
la otra, lo cual exige una negociacin tcnica y poltica porque los sistemas que
soportan los mdulos a comunicar puede ser muy heterogneos al haberse
desarrollado con plataformas, infraestructuras y lenguajes muy diferentes.

Adems, a medida que aumenta el nmero de interlocutores, se hace ms
complicado desarrollar y mantener todas las relaciones.

En fin, los problemas de flexibilidad, escalabilidad, costes y rapidez en disponer de
la solucin pueden ser tan importantes que hasta imposibiliten obtener una
arquitectura integrada.

Pero podemos pensar en otra forma de hacerlo en la que todos los mdulos se
conectan a un bus capaz de hacer circular mensajes. Cuando un mdulo necesita
de un servicio de otro mdulo o desea enviarle una informacin la coloca en un
mensaje sobre un bus donde se han ensamblado los interlocutores como se
muestra en la parte inferior de la figura anterior. El bus lo hace circular entre todos
los interlocutores. Cuando un interlocutor recibe un mensaje averigua si es para l,
y en caso afirmativo, lo recoge. Le suena?, efectivamente, es la arquitectura de
comunicacin entre servidores por Broadcast Data Flow que presentamos en el
captulo dedicado a Arquitectura de Servicios. Con una diferencia que mejora
notablemente la eficiencia: los mensajes no se dirigen a todos, sino solo a los
interesados.

La gran ventaja es que el emisor y el receptor no estn comunicados directamente.
Cualquiera que conozca las reglas de juego del bus, puede publicar o suscribirse a
una informacin.

El problema principal es la ineficacia, ya que se establece mucho trfico
innecesario.

Hay que buscar, pues, una solucin ese problema, combinado las ventajas del bus,
independencia entre los mdulos, y del cara a cara, minimizacin del trfico.

La arquitectura de la solucin pasa una vez ms por la idea de Middleware. Cada
interlocutor hablar con unas reglas pactadas, que sern un estndar para todos
los interlocutores. Para integrar un nuevo mdulo slo habr que conocer y usar las
reglas de juego. El Middleware ser el responsable de proporcionar eficacia al
conjunto de la integracin resolviendo el Broadcast con una conexin virtual cara a
cara. Inmediatamente le explicar cmo.

3. Caracterizacin del mensaje y la suscripcin.

El mensaje puede ser:

O Auto descriptivo llevando toda la informacin del evento.
O De aviso, conteniendo nicamente la notificacin de que ha ocurrido el
evento y la direccin, un archivo o un servidor, donde est toda la informacin
completa.

Segn su personalizacin, la suscripcin puede ser:

O Esttica, establecida por las herramientas del Middleware P/S de
administracin.
O Dinmica modificada en tiempo de ejecucin por las APIs de desarrollo. Debe
evitarse siempre que sea posible.

En funcin del destino:

O General: a todos los suscriptores.
O Especializada: slo a los interesados en un tema

En funcin del criterio, la suscripcin puede ser:

O A un conjunto de publicadores.
O A un conjunto de publicaciones, escogiendo todas las noticias o slo las de
una determinada

4. Paradigmas.

4. 1. Publicacin Broadcast.

Un interlocutor publica una informacin sin saber que interlocutores la
necesitan. Observe que es la opcin convencional de un modelo de publicacin
y suscripcin.

4. 2. Solicitud y respuesta.

Un interlocutor interesado pregunta al sistema por una informacin y el sistema
le devuelve la respuesta generada por el interlocutor que la tiene.

4. 3. Solicitud y respuesta Multicast.

Llamada tambin Broadcast/Manycast, es un caso particular del anterior en que
hay ms de un interlocutor capaz de proporcionar el servicio. La peticin se
hace circular entre todos los publicadores capaces de proporcionar el servicio y
responde el primero que est disponible. Estos interlocutores pueden ser
instancias de un mismo interlocutor.

4. 4. Transaccional.

Varios eventos, relacionados entre si, se encapsulan en una transaccin para
minimizar el trfico. Es obvio que el sistema transaccional puede utilizarse
conjuntamente con cualquiera de los dos paradigmas anteriores.

Es muy recomendable cuando una informacin no es til sin el resto.

5. Arquitectura de publicacin y suscripcin.

En la figura que se muestra ms adelante se muestra la arquitectura bsica de los
componentes de un Middleware de este tipo.

En ella se integran los siguientes elementos:

5. 1. Los interlocutores.

Mdulos integrados en el sistema. Los hay de dos tipos:

Publicador.
Suscriptor.

Obviamente la situacin de publicador o suscriptor de un interlocutor es
dinmica y un mismo interlocutor adopta, habitualmente, los dos perfiles en una
sesin de trabajo.

Cada interlocutor se identifica por un nombre.

5. 2. El Bus

Queda representado por las APIs de la capa P/S. Como en todo Middleware,
hay APIs de:

Desarrollo.
De administracin.

5. 3. La publicacin.

Diario o revista donde se publican las noticias y al que se suscriben los
interlocutores interesados.

5. 4. La noticia.

Evento o informacin que cambia dentro de cada publicacin. Se pueden
tipificar.

5. 5. El mensaje.

La notificacin de la noticia que se pasa o recibe del bus. Cada mensaje se
coloca en el bus una sola vez.

5. 6. La lista de distribucin.

Donde se anota la tipologa de eventos a controlar y los suscriptores
interesados.

Debe proporcionar tambin una forma para disponer de ms de una lista de
distribucin para tener posibilidad de llevar ms de una publicacin.

5. 7. El adaptador.

Es el componente desarrollado dentro de cada interlocutor para conectarse al
bus. Utilizar las APIs del Middleware P/S.

El adaptador ser un mero exportador/importador de datos que sern visibles
por todos los interlocutores conectados al sistema de publicacin y suscripcin.

5. 8. El distribuidor.

El agente encargado de recibir y distribuir los mensajes.

5. 9. La memoria.

Observe que el Middleware de P/S debe tener memoria histrica ya que es
ms que posible que cuando una noticia se publica, haya suscriptores que no
estn escuchando. Esta memoria histrica se traduce, generalmente, en una
tabla cruzada de noticias y suscriptores con una tributo para conocer si ha sido
entregada o no.

Es fcil imaginar el funcionamiento conjunto. Las noticias se publican en
mensaje por los publicadores sobre el bus con una referencia de publicacin.
El Distribuidor del Middleware enva el mensaje a todos los suscriptores de esa
publicacin que estn escuchando. Si hay suscriptores fuera del bus es ese
momento, se guarda el mensaje hasta que se conectan.

Para conseguir este funcionamiento se habrn de usar:

O Con las APIs de administracin:

Se establecen,
por temas, las
publicaciones
necesarias.
Se codifican las
tipologas de
noticias y
eventos a
gestionar
Se crea una lista
distribucin por
cada publicacin
que se necesite.
Se referencian, si
es necesario, los
publicadores
responsables de
cada tipologa de
noticia.
Se establecen las suscripciones estticas.

O Con las APIs de desarrollo:

Paradigma de publicacin Broadcast.
Los interlocutores publican las noticias de cada publicacin.
El Distribuidor recibe las noticias, consulta la lista de distribucin y
la enva a los suscriptores.
Paradigma de solicitud / respuesta.
El interlocutor enva el mensaje de peticin.
El Distribuidor pregunta a los publicadores.
El publicador enva la respuesta.
El distribuidor hace llegar la respuesta al solicitante.

O Con las APIs de monitorizacin seguiremos el funcionamientos dinmico
del sistema:
Distribuidor
Lista de
Distribucin
BUS
BUS
Interlocutor
A
Adaptador
Interlocutor
C
Adaptador
Interlocutor B1
Interlocutor
D
Adaptador
Memoria
Interlocutor B2
Adaptador
Servidor de
Pasarela
T

Figura 303. Arquitectura bsica de publicacin suscripcin

Rendimiento.
Mensajes pendientes de entregar, etc.

El Distribuidor puede verse, pues, como un servidor P/S con semntica de
comportamiento full tolerance.

Observe tambin que la filosofa de un adaptador es de una arquitectura de
pasarela. Si se monta como un servidor la comunicacin con el bus ser con esa
arquitectura.

La arquitectura de pasarela resolver
tambin la no existencia de un
estndar P/S. Los interlocutores
delegarn la conexin en un servidor
P/S que actuar como pasarela a los
diferentes buses P/S que haya que
adaptar.

Y si ve claro que est ante un
servidor y disea la capa P/S,
recuerde de hacerlo con todas las
cualidades que exigimos a nuestros
servidores. En particular, el
paralelismo que le permitir arrancar
ms de una instancia del Distribuidor
y dar gran escalabilidad ante
aumento de trfico.

En el Map to Reality de un servicio P/S debe analizarse el ancho de banda del bus
para evitar demoras no deseadas.

Note que un Middleware de este tipo es dos capas:

O Una capa especifica de publicacin / suscripcin.
O Otra de mensajera o transporte.

Entre las dos se establece una arquitectura de delegacin. La segunda es ya un
estndar. La primera no lo es tanto y en muchas ocasiones sale a cuenta montarla
como Middleware de usuario. No hay que decir que la capa de mensajera ha de
ser independiente de la va como cualquier transportista que se precie.

Tanto los adaptadores como el distribuidor, que en el fondo generan eventos,
pueden potenciarse con mecanismos ECA que permiten implementar reglas de
negocio. Al ser las reglas de negocio particulares de cada instalacin, es mejor
implementarlas dentro de los adaptadores que en el distribuidor.

6. Tipologa de adaptadores.

6. 1. Adaptadores de mensaje completo.

El mensaje es auto explicativo conteniendo los datos involucrados. Se utilizan
las APIs del Middleware P/S.

Interlocutor 1 Interlocutor 2
Adaptador A
Servidor de Pasarela
T
Adaptador B Adaptador C
BUS
P/S 1
BUS
P/S 2
BUS
PS/3
T T

Figura 304. Acceso a P/S heterogneos.
6. 2. Adaptadores de archivo con mensaje de aviso.

El mensaje se reduce a un aviso. El traspaso de los datos se realiza a travs
de un archivo plano. Normalice el formato.

Le recomiendo:

Como primera opcin, ficheros XML.
Como segunda, ficheros de texto con los atributos separador por un
carcter de control y los registros por <CR,LF>.

Perder algo de eficacia en ocupacin pero ganar en independencia de
representacin y podr leerlos con un simple editor.

6. 3. Adaptadores de archivo sin mensaje de aviso.

Es una variacin del anterior en la cual no hay mensaje de aviso. El adaptador
reconoce el aviso por la aparicin del fichero en un directorio pactado. El
distribuidor genera el evento. Simplifica el diseo del adaptador ya que no ha
de preocuparse de la comunicacin. Es cmodo para la publicacin pero poco
eficiente para la suscripcin ya que obliga al suscriptor a escuchar el bus. Le
recomiendo que reduzca su uso a la publicacin.

Obviamente, puede utilizar aqu mecanismos de Viga y Disparador.

6. 4. Adaptadores sobre BD.

Es una variacin de los anteriores en que el intercambio de informacin se
realiza directamente sobre BD. Exige como mnimo el uso de ODBC-SQL. La
solucin es algo ms eficaz al evitar la grabacin del fichero plano pero queda
distribuible en lugar de distribuida.

6. 5. Adaptadores basados en correo electrnico.

Para la salida se genera un mensaje de correo electrnico que debe ser
capturado por el adaptador y desencadenar un evento.

6. 6. Adaptadores basados objetos distribuidos.

Optimo en aplicaciones OO., puede utilizarse tambin en aplicaciones
convencionales ya que la implementacin OO se reduce al adaptador.

El modelo de comunicacin suele ser por eventos.

6. 7. Adaptadores fabricados por proveedores de componentes.

Es una buena solucin que solo tiene un pequeo problema: no hay
estndares.

7. Publicacin y Suscripcin versus comunicacin cara a cara.

La mayora de las ventajas P/S son inherentes al concepto de Middleware en que
est basado:

O Transparencia de la localizacin.
O Disponibilidad ya que es muy rpido conectar nuevos interlocutores.
O Escalabilidad ya que pueden arrancarse varias instancias del Distribuidor y de
los publicadores (en paradigma solicitud / respuesta).
O Reduccin del trabajo ya que slo hay que desarrollar el adaptador al bus.
O Reduccin de los costes de adaptacin y mantenimiento.

Puede parecerle que este modelo de integracin es la panacea de todos los
modelos. Por favor, no caiga en ese error. Es mucho ms ineficiente que la cara a
cara. Mucho ms. Y ms caro. Como buen diseador, selo slo en los casos que
potencian sus ventajas: sistemas heterogneos, interlocutores de terceros,
comunicaciones fuertemente desacopladas, etc.

Adems trabajando en SOA se tienen acoplamientos mnimos, y eso desmonta
parte de las ventajas de la P/S.

8. Herramientas para la capa de mensajera o transporte.

Han de permitir el desacoplamiento total de los interlocutores evitando que deban
conocerse entre si y que permitan la parametrizacin dinmica permitiendo aadir o
retirar interlocutores dinmicamente.

Podemos usar:

8. 1. Herramientas de Middleware de mensajes (MOM).

Aunque en un sistema de publicacin y suscripcin no existen clientes o
servidores en el concepto tradicional, es evidente que esta herramienta de
aplicable. En captulos anteriores hemos discutido ampliamente sobre ventajas
e inconvenientes de utilizar MOM como Middleware estndar o de usuario. En
una arquitectura de publicacin y suscripcin es obligado el uso del estndar.

Permite todos los paradigmas P/S.

8. 2. Herramientas de RPC.

Igual que el anterior pero con las limitaciones de ser sncrona y la ventaja de
ser ms estndar que el Middleware MOM.

8. 3. Modelos de objetos distribuidos.

El mecanismo a utilizar en el gestor de eventos. Muy potente y flexible, permite
todos los modelos de paradigmas P/S

8. 4. Gestores de Colas.

Se puede decir aqu lo mismo que en MOM.

8. 5. Correo electrnico.

Ventajas de amplitud y estandarizacin.

8. 6. Monitores de transacciones.

Recomendable, obviamente, para el paradigma transaccional.

8. 7. Software propio en integracin intracorporativa.

Dado el estado del arte, no le recomiendo esta va ms que en casos muy
claros en que la publicacin y suscripcin se inicie cuando en la instalacin ya
existan herramientas de integracin previamente desarrolladas y utilizadas en
el Middleware de usuario.

8. 8. Bus basado en Internet.

Las ventajas de P/S se aplican a Internet por tcnicas de push. No voy a volver
a comentar esta tcnica. Si no la recuerda, revise el captulo dedicado a la
Arquitectura de la Comunicacin en un Sistema Distribuido.

Las soluciones de este tipo entran en el marco de los modelos que he
presentado en el captulo dedicado a las relaciones entre C/S e Internet.

La aplicacin Internet ha de ser activa ya que necesita interactuar con el
sistema local.

Hay varias formas de montarlo.

8.8.1. Cliente HTML puro localizado en la WEB.

La informacin se publica en un formulario HTML y se utilizan tcnicas
de push para avisar a los suscriptores.

8.8.2. Cliente HTML usando otro mdulo del sistema WEB.

Recordemos que el cliente puede interactuar con el sistema en el que
est localizada la WEB. Existen diversas formas de conseguirlo:

Por CGI/ISAPI/NSAPI o APIs especiales a un mdulo del sistema
donde esta localizada la WEB. Las APIs P/S se incluyen en la
llamada.
A travs de un Servicio WEB localizado en la WEB. El servidor
realiza la llamada a las APIs del Middleware P/S. Esta
implementacin tiene la ventaja sobre la anterior de que puede
usarse tambin por los procesos locales.

8.8.3. Uso de Applet.

Es un montaje paralelo al anterior en que la diferencia est en la
implementacin. Cuando el interlocutor se conecta al sistema P/S
arranca un applet que lo liga al sistema por uno de los dos sistemas
anteriores

El Servidor de Versiones

1. Qu es un servidor de versiones?

En un sistema distribuido, en los diferentes nodos hay programas y datos.

Como hemos hablado reiteradamente, sincronizar todos los elementos del sistema
no es una tarea banal.

A lo largo de nuestro viaje hemos presentado y explicado los elementos y criterios
necesarios para gestionar este tema. Sin embargo, dada su importancia, podemos
plantearnos un ejercicio. Disearemos la arquitectura de un servidor de versiones
que permita mantener al da todos los nodos sincronizados en datos no voltiles y
programas. En general los datos voltiles suelen tener sus propias vas de
replicacin especializadas.

Llamaremos servidor de versiones a la arquitectura resultante que nos resuelve el
problema.

Obviamente, la plataforma sobre la que hay que actuar depende de cada caso. Sin
embargo, las funciones son siempre las mismas:

O Empezaremos por fijar los niveles lgicos de la arquitectura sobre la que
vamos a actuar.
O Seguiremos por definir que elementos queremos sincronizar.
O A continuacin definiremos el modelo de datos relacionado.
O Finalmente propondremos la arquitectura del servidor de versiones que la
desarrolla.

2. Especificacin de los niveles lgicos de la plataforma.

A efectos de centrar el ejemplo, vamos a trabajar con una plataforma de tres niveles
lgicos:

O Central.
O Nodo servidor
O Clientes de dos tipos.
O Los que no necesitan autonoma de trabajo. Vamos a suponer que la
autonoma de trabajo se puede conseguir con ficheros XML.
O Los que la necesitan.

Los programas deben estar en todos los nodos y los datos solo en la central y en
los nodos servidores.

3. Elementos a sincronizar.

Nos planteamos mantener de forma automtica versiones de:

O Programas
O Servidores.
O Agentes.
O Clientes.
O Datos.
O Modelo a travs de SQL que contienen las modificaciones del modelo
de datos y las acciones necesarias para pasar del antiguo al nuevo.
Pueden estar aqu:
Inicializacin de nuevos campos.
Migracin de contenidos.
Resolucin de restricciones de integridad, etc.
O Parametrizacin en BD o definicin de comportamiento incluida en
tablas de la BD.
O Contenido de las entidades de la BD.
O Fecha y hora del sistema distribuido.

En programas, aunque a afectos de versiones no hay diferencias entre clientes,
agentes y servidores, el matiz est en prever que el servidor y el agente pueden
estar arrancados permanentemente y que hay que prever un mecanismo de
notificacin de nueva versin que puede ser:

O Un evento.
O Una pregunta peridica planificada en la ficha de Enviroment del servidor.
O Una peticin al servidor de auto actualizacin prevista en el flujo de mensajes,
O Una rearrancada peridica automtica o manual, etc.
.
Algo absolutamente paralelo ocurre con la modificacin del modelo de datos, las
tablas de parametrizacin contenidas en BD y el contenido de las entidades.
Tambin vamos a generalizarlas como datos.

En lo que sigue hablar en general de programas y datos, dejando el matiz
diferenciador entre los actores para un ejercicio adicional del lector.

4. Arquitectura del servidor de versiones.

El modelo de datos debe ser ampliado para contener el registro de los elementos y
versiones que hay en cada nodo.

Podemos registrar, por ejemplo, una entidad en la BD o en fichero XML con:

O Nodo.
O Elemento.
O Versin actual del elemento.
O Fecha y hora de actualizacin, etc.

Lo que vamos a tratar aqu es una extensin de la replicacin de programas
presentada en el captulo de la replicacin.

Es peligroso actualizar demasiado automticamente ya que puede crearse
inconsistencia en la coordinacin del sistema.

Por esa razn es bueno disponer de la posibilidad de aadir a las versiones
pendientes de actualizar fechas para controlar:

O Cuando hay que transmitir el cambio de la central a los nodos perifricos.
O Cuando se ha de hacer efectivo en el nodo de destino.

La filosofa de trabajo ser hacer que cuando cada programa arranque:

O Verifique si ha de hacer efectivos cambios ya registrados en su nodo.
O Compruebe con el nodo superior en jerarqua si hay cambios pendientes de
ser registrados. Una vez traslados hasta el nodo, deber verificarse si se han
de hacer efectivos con los recursos del punto anterior.

En la plataforma lgica que hemos planteado el servidor de versiones tendr dos
mdulos:

O La actualizacin servidor del nodo contra central.
O La actualizacin del cliente contra el servidor del nodo.

En la siguiente figura se muestra una posible arquitectura de un servidor de
versiones para gestionar, en la especificacin que hemos planteado, la
actualizacin del servidor de nodo contra la central.

Servidor
de
Configuracin
Servidor
de fecha
y hora
Servidor
de
archivos
Versiones
datos y
programas
Servidor
Verificacin
versiones
Servidor
de correo Datos
Versiones
datos y
programas
Datos
Programas
Configuracin
Servidor
de
Versiones
Arranque
programa
Servidor
Arranque
Servidor
de correo
Programa
en
servidor
Servicio de
carga de
archivos
Programas
R
Fecha y Hora
Procesador
distribuido
Procesador
distribuido
D
D
C
D
T
R
D
R
R
T
T
T
Fecha y Hora
Central
Nodo

Figura 305. Arquitectura de un servidor de versiones.

Un programa que se ejecute en el servidor de nodo no se iniciar nunca
automticamente sino a travs de un programa de arranque que recibir como
parmetro el nombre y localizacin del programa definitivo.

Esta funcin de ejecucin llamar a un servidor de arranque que verificar si hay
versiones en el mismo nodo cuya fecha de vigencia ya se ha alcanzado. Si es as,
pasar control al servidor de carga de ficheros para realizar la actualizacin.

A continuacin realizar una llamada al servidor de versiones de la central que le
pasar:

O Los posibles cambios de configuracin.
O La sincronizacin de fecha y hora.
O Verificar que la versin que le pasa el nodo es la ltima. Si no es as se lo
notificar,

Para realizar el movimiento de las versiones entre la central y el nodo, hay varias
soluciones:

O Que el servidor de carga de archivos comunique con un servidor de archivos
de la central se enve las nuevas versiones a travs del servidor de correo.
O Aprovechar una arquitectura de procesador distribuido parecida a la que
hemos visto anteriormente.

En cualquier caso debe arbitrase una forma, normalmente la consulta de las colas,
para saber si los procesos de transporte y carga se han acabado ya,

La consistencia se resuelve con los siguientes criterios.

O Si el servidor de arranque no responde, se trabajar con la ltima versin
registrada en el nodo.
O Si el servidor de versiones de la central no responde, se supondr que no hay
nueva versin.
O Si pasado un time out no han llegado los ficheros, se arranca tambin con la
ltima versin.

Aunque en el ejemplo se plantea, para simplificar el esquema, que es en el
arranque de cada programa cuando se verifica la versin contra la central, la forma
habitual de hacerlo es que sistemtica un agente verifique todos los cambios de
versin contra la central y los actualice sobre el nodo.

El agente ocupa el lugar del servidor de arranque y puede incluir el servidor de
carga de archivos. Un semforo puede avisar que hay una actualizacin en curso.

El mismo agente puede gestionar la entrada en vigencia o dejar esa funcin para el
arranque de cada uno de los programas tal como se ha planteado en el ejemplo.

En la figura inferior se muestra una posible arquitectura de un servidor de versiones
para gestionar, en la especificacin que hemos planteado, la actualizacin de los
puestos clientes contra del servidor de nodo.

Arranque
Programa
BD
Servidor
Arranque
Cliente
BD
Servidor
Programas
Servidor
de fecha
y hora
Versiones
datos y
programas
Programas
Fecha y Hora
Datos
Programas
Copias XML
de datos
bsicos
Arranque
Programa
XML
Cliente
XML
Fecha y Hora
Emergencia
D
T
Cliente
Cliente
Servidor
del nodo

Figura 306. El servidor de versiones de los puestos cliente.

Los programas cliente que trabajan contra la base de datos tienen un
comportamiento bsicamente parecido.

En los programas cliente en los que se ha previsto consistencia por XML, se
regrabarn en esos ficheros XML cada vez que haya cambios.

En caso de cada del servidor del nodo, el programa cliente trabajar contra los
ficheros XML en lugar de contra la BD.

5. La actualizacin a travs de Internet,

Otra opcin para montar esta arquitectura es la conocida actualizacin a travs de
Internet, disponiendo un servicio que avise al cliente que hay nuevas versiones
disponibles y dejando al usuario la responsabilidad de hacerlo.

Esta solucin en un sistema distribuido administrado debe gestionarse con
muchas precauciones que puede conllevar inconsistencias de versin entre
los nodos.

Si se utiliza, debe asegurarse que cuando el agente avisa al usuario de la nueva
versin realmente puede actualizarse. No est dems prever la opcin de forzar el
cambio de versin no permitiendo al programa trabajar en caso contrario.

6. Generalizacin.

Le recuerdo que hemos querido hacer un ejemplo. Como puede ver, esta
arquitectura es totalmente adaptable a las diferentes funciones y arquitectura de
niveles que pueda tener cada plataforma en concreto por lo que sera un buen
ejemplo que la pensara y adaptara para caso concretos que le son conocidos.

7. Arquitectura de replicacin,

Recuerde tambin que en le captulo dedicado a la replicacin de datos es han
visto tcnicas que permiten montar lo servidores de programas por replicacin ya
que un distribucin de versiones no es ms que un caso especial de replicacin.

Tcnicas de diseo por Modelos de
Aplicacin.

1. Cuadro de tcnicas por modelos de diseo.

Simplemente, djeme presentarle en un cuadro resumen de tcnicas se emplean
en cada caso.

Modelo de Diseo Anlisis
Funcional
Arquitectura
Distribuida
Anlisis de
Consistencia
Anlisis de
Administracin
Presentacin RAD No No tiene sentido No tiene sentido
Datos centralizados
con lgica en los
Clientes
RAD No No es necesario
ya que solo hay
consultas
No es necesario
ya que la
administracin
es centralizada
Datos centralizados
actualizables y con
lgica en los
Clientes
RAD No Importante a
pesar de que la
mayora de los
casos no se hace
No es necesario
ya que la
administracin
es centralizada
Datos distribuidos
con lgica en los
servidores
RAD /
Avanzado
Si Si Si
Datos distribuidos y
con lgica en los
Clientes
Avanzado Si Si Si (fundamental)
Tratamientos
Distribuidos
Orientado
a Objetos
Si Si Si
Procesos
Distribuidos
Orientado
a Objetos
Si Si Si

Interfcies Grficas de Usuario

1. Introduccin.

El diseo de la Lgica de Presentacin no es un tema de diseo distribuido. Existe
diseo distribuido sin interfcies grficas. Si en este momento de su lectura no he
sido capaz de convencerle, he fracasado en mis objetivos bsicos.

Sin embargo, es indudable que la mayor parte de las aplicaciones distribuidas
acaban fabricando clientes que interactan con los usuarios mediante interfcies
grficas.

Y es tambin un hecho ineludible que en la mayora de los casos, la lgica de
presentacin implementada en la interfcie es, simplemente, inexistente. Y el grado
de reutilizacin cero. Su construccin se reduce a tirar los componentes sobre un
contenedor de objetos grficos.

Por todo ello, creo que sera un grave error proponerle una metodologa de diseo
de aplicaciones distribuidas sin hacer una propuesta de diseo de interfcies
grficas que prevenga contra los dos males, no estar diseadas y no generar
componentes reutilizables.

Vamos a plantear el tema en dos partes:

O Presentacin del concepto de interfcies grfica y de sus componentes. Si Vd.,
amigo lector domina el tema, slteselo. No intentar ser exhaustivo ya que
controles los hay de todo tipo y color. Solo hablar de los habituales a efectos
de apoyarme en ellos para presentar las ideas bsicas objeto de esta breve
excursin opcional en nuestro viaje.
O Diseo de la lgica de presentacin. En este, si domina el tema, haga una
lectura rpida para comparar sus ideas con las mas.

Y un comentario previo para la lectura estos captulos. Recuerde me comentario
incluido en la presentacin de esta segunda parte sobre las capturas de pantalla
que encontrar para ilustrar los ejemplos hay muchas versiones anteriores de
Windows. Por favor, no piense por ello que el mensaje est anticuado. No confunda
la forma con el fondo. Simplemente, un da me cans de trabajar intilmente
actualizando la imagen a cada cambio de versin del sistema operativo.

2. Qu es una Interfcie Grfica de Usuario.

Por Interfcie Grfica de Usuario (IGU en castellano) o Graphic User Interface (GUI
en ingls, y abreviacin que yo utilizar) es una forma estandarizada, inventada por
Apple y extendida y popularizada por Windows, de interactuar con los usuarios para
pedir datos y decisiones y proporcionarle resultados.

Como Vd. las conoce perfectamente, solo quiero remarcar sus caractersticas
bsicas:

O Utilizacin de componentes visuales con comportamiento estandarizado y
conocido por todo el mundo, lo que ahorra costosos esfuerzos de
documentacin y formacin de usuarios.
O Alta calidad de presentacin.
O Facilidad de programacin y utilizacin.
O Uso exhaustivo del Mouse.

Las GUIs estn basadas en la tcnica de ensear y escoger.

Ofrecen gran nmero de ventajas al usuario:

O Pueden visualizar diferentes tipos de informacin simultneamente.
O Permiten a los programadores implementar un nivel de comunicacin con el
usuario muy alto que le ayuda a conocer mejor en todo momento lo que ha de
hacer y lo que recibe.
O La utilizacin de botones, mens y listas desplegables permiten realizar mejor
y de forma ms sencilla tareas de control y dilogo.
O Le evita tener que aprender una operativa de comunicacin diferente para
cada aplicacin.
O La utilizacin de componentes visuales facilita la navegacin y aumenta la
eficacia, reduciendo la utilizacin del teclado a la entrada de datos.

Es importantsimo recordar una caracterstica bsica ya citada en otros puntos de
este libro: la gestin de una GUI es transaccional. El usuario prepara el trabajo
navegando por la GUI, acepta o cancela el trabajo, el programa procesa la entrada
y presenta los resultados; el usuario los estudia y navega para preparar el siguiente
ciclo.

Una GUI es, en el fondo, un contenedor de objetos grficos integrados por una
lgica de presentacin. Este contenedor recibe diferentes nombre segn los
lenguajes, pero existe en todos. Y no es solo una ventana, tambin es, como
veremos ms adelante, una integracin que puede insertarse en bloque en otro
contenedor, ventana o no.

3. Elementos de una Interfcie Grfica.

Los elementos o componentes de una interfcie grfica son perfectamente
conocidos por Vd. En la pantalla le presento una ficha con los componentes
bsicos, sin ms objetivo que unifiquemos nomenclatura para todo lo que sigue en
este captulo y el siguiente.

Los elementos de una
GUI se obtienen y
sitan a partir de
Generadores de
Recursos, que son
herramientas que
permiten a los
programadores definir
interactivamente y con
gran facilidad la parte
grfica (componentes
visuales) de una GUI.

Pero, hay otra parte,
adems de la grfica,
en una GUI? Claro que
s!, el diseo de la
lgica de
presentacin. La gran
facilidad aportada a por los generadores de recursos es la causa, en manos
inexpertas claro est, del mal diseo de las GUIs. Es tan fcil tirar los
componentes sobre el contenedor grfico nada ms empezar y sin disear nada!

Estos recursos tienen, como ya se ha dicho, un formato y comportamiento
estandarizado y conocido por programadores y usuarios. Todos los entornos
de programacin aportan uno que permiten gestionarlos esttica, instanciados de
entrada, o dinmicamente, instanciados en fase de ejecucin segn las
necesidades del programa. No desprecie esta potente opcin de programacin que
puede permitirle cosas muy guapas, como personificar la GUI en funcin del
contexto de la aplicacin en cada momento de la ejecucin.

Todos los componentes son Objetos y conocer los fundamentos de OO para
gestionar GUIs no es imprescindible, pero si muy til para conseguir reusabilidad y
aprovechar al mximo las posibilidades de esos componentes. En este contexto,
dejo una pregunta en el aire: cuantos diseadores y programadores de interfcies
grficas tienen conocimientos mnimos (de verdad) de OO? Segn la respuesta que
d a esta pregunta entender muchas cosas...

4. Tipos de Ventanas.

Las ventanas son el contenedor final de la GUI. Existen diferentes tipos de
ventanas con contenido semntico diferente. No creo necesario hablar de ventanas
pero si de sus tipos y uso.

4. 1. Principal (Main).

Es la ventana asociada al programa principal. Se instancia automticamente
cuando el programa arranca, personificndose antes de la primera interaccin
del programa con el usuario.

4. 2. Hija (child).

Aplicacin
Ventana
Principa
Ventana Hija
Controles
Botones de
redimensionamiento
Men de
control
Extremos de
redimensionamiento
Aceleradores
de teclado
Men de Conexto
Men de usuario

Figura 307. Componentes de una interfcie grfica de usuario
Se llaman desde otra ventana, referenciada como madre, y que no es
necesariamente la principal. Le recomiendo que no abuse de una jerarqua
demasiado profunda, puede crear confusin en los usuarios. Se cierran
automticamente cuando se cierra la madre. Pueden desplazarse fuera del
rea de la madre.

Suelen utilizarse para iniciar un proceso de detalle que puede convivir con
otros procesos de detalle iniciados desde la misma ventana madre. Poder
desplazarlas fuera de la madre ayuda a tener a la vista ms de una
simultneamente. Una alternativa vlida es personificar una zona de una nica
ventana en funcin del estado del flujo de dilogo.

4. 3. Pop-Up.

Son ventanas que se abren tambin dentro de la madre pero no pueden salir
de su interior. Cuando se cierra la madre se cierran todas las Pop-Up abiertas.
Su utilizacin es literalmente jerrquica: no hay que volver a la madre hasta
que se ha acabado el trabajo para el que se ha iniciado la hija.

4. 4. Response.

Son ventanas Pop-Up que cogen en exclusividad del foco de la aplicacin;
dicho de otra forma, el usuario solo puede interactuar con ellas. Se utilizan para
dilogos en los que no se puede seguir sin que el usuario los cumplimente. Un
ejemplo habitual es las elecciones entre diversas opciones, las cajas de
eleccin de archivo y las de informe y solucin de errores.

5. Controles.

Son los objetos visuales integrados en la GUI.

Los hay de dos clases:

O Activos: suponen gestin del usuario. Son ejemplos de controles activos
botones, listas despegables, check-box. etc.
O Pasivos, u objetos de dibujo (Drawing Objects): se utilizan slo para hacer la
GUI ms atractiva y dividirla por zonas operativas. No generan eventos. Son
ejemplo de controles de este tipo textos, lneas, rectngulos, crculos, etc.

Una de las grandes aportaciones de Windows fue la estandarizacin de los
controles ms habituales, y, aunque hay diferentes controles segn las
herramientas de diseo utilizadas, los fundamentales se comportan y se usan igual
en todas ellas.

Los controles, implementados siempre por una clase OO quedan definidos, como
cualquier otra clase por:

Un estado a travs de los valores de sus atributos.
Un comportamiento a travs de sus mtodos y de los eventos que es capaz de
producir.

Hay unos atributos que son comunes a todos los controles: control, tamao,
posicin, visibilidad, activo o no, etc. Y otros que son especficos a cada control. La
gracia de los comunes es que puede tratarse independientemente del tipo de
control.

Una especial atencin merece los atributos visible y activo (enabled). Un control
puede estar visible o no, segn convenga; si se pone no visible, desaparece de la
GUI.

Un control puede estar activado o no. Si est activado puede recibir instrucciones
del usuario; si no est se muestra, generalmente en gris, pero no se puede
gestionar.

Los atributos de un control suelen ser pblicos pero tener adems mtodos que los
gestionan. Un ejemplo habitual es el atributo visible, que tiene los mtodos hide()
para esconderlo y show() para hacerlo visible. La disponibilidad de los atributos
desde los programas permite una cosa que, a mi juicio, es peligrossima: se puede
tocar sin control de la clase. Sea precavido con este hecho y utilice, siempre que le
sea posible, los mtodos en lugar de leer o modificar directamente los atributos.

La utilizacin de estos dos atributos permite personalizar GUIs escondiendo
informacin no autorizada a un usuario y dejar no disponibles opciones que segn
el contexto del momento no se pueden pedir o modificar. Adems pueden ayudarle
a navegar con mayor comodidad por la pantalla. Colocando el control visible y no
activo se puede mostrar informacin a usuarios que no pueden modificarlas

Otro concepto interesante en el de control que tiene el foco, es decir, el control
que en ese momento recibe la accin del usuario.

El foco puede cambiarse de diferentes formas:

O Con el Mouse.
O Con la tecla TAB.
O Forzndolo directamente por programa.

El concepto de foco tambin es aplicable a la ventana que est recibiendo en ese
momento la accin de usuario.

Los eventos ms comunes de un control son:

O Clicked, cuando el control es marcado por el botn del Mouse. Puede ser
generado con doble o simple click o por el botn izquierdo (lo estndar),
central o izquierdo del Mouse.
O Getfocus, cuando el control recibe el foco.
O LoseFocus, cuando el control pierde el foco.
O Drag&Drop, cuando el control es arrastrado y soltado sobre otro.
Hablaremos ms tarde de estas tcnicas.

Vamos a exponer a continuacin los ms habituales, no para enserselos, que
seguro ya los conoce, sino para repasar su comportamiento bsico y utilizacin.

5. 1. Botones (Command Button).

Cuando se les pulsa, producen un evento dentro del cual, normalmente, se
dispara una accin.

Normalmente se agrupan para cubrir todo el abanico de una eleccin.

5. 2. Botn de imagen (Picture Button).

Tienen un comportamiento igual que los anteriores pero en el interior en lugar
de un texto hay una imagen. Suelen usarse de forma esttica en las ventanas
para permitir al usuario opciones que puede ejecutar en cualquier momento.

5. 3. RadioButton.

Son controles que tiene dos estados: seleccionado o no. Representan opciones
que se excluyen mutuamente.

Siempre se presentan en grupos dentro de un GroupBox. Nada ms que un
botn es seleccionable dentro de cada grupo; la seleccin de uno supone la no
seleccin automtica de todos los dems.

El usuario clikea con el Mouse el que le interesa y el programa los consultan
cuando lo necesita.

5. 4. CheckBox.

Son utilizables de forma parecida a los RadioButton pero se puede seleccionar
ms de uno simultneamente. Representan opciones que pueden pedirse al
mismo tiempo, y que slo se agrupan a efectos de claridad.

Normalmente slo se trabajan dos estados: seleccionado o no, pero puede
existir un tercer estado que indica indefinicin de la opcin o no disponibilidad
en ese momento de control.-

5. 5. Lista desplegable (ListBox).

Tienen diferentes formatos, pero en el fondo, todos tienen el mismo
comportamiento.

El programa carga, esttica o dinmicamente una lista de valores entre los
cuales el usuario ha de escoger una.

5. 6. Lnea de edicin (SingleLineEdit).

Permiten gestionar una lnea de texto por el usuario. Pueden trabajar
simultneamente con el portapapeles.

El usuario dispone de los recursos de edicin habituales en la gestin de textos
de Windows.

5. 7. Lnea de edicin mltiple.

Se comportan de forma parecida a los anteriores pero permiten editar ms de
una lnea.

Conjuntamente con las barras de desplazamiento permiten gran flexibilidad
para gestionar textos del tamao muy grande, aunque en la prctica tengan un
lmite de tamao.

5. 8. Barras de desplazamiento.

Se utilizan normalmente junto a otros controles para indicar al usuario que la
informacin no cabe en la zona visible del control. Su utilizacin permite al
usuario desplazar la zona visible del control por toda la informacin contenida
en l

Pueden hacerse servir tambin de forma autnoma para escoger un rango de
valores.

Recuerde que el desplazamiento tiene dos ritmos: lento (lnea en textos) y
rpido (pgina en textos).

5. 9. Pestaas (TabSet).

Permite agrupar un conjunto de vistas relacionadas entre s y hacerlas
accesibles de una en una utilizando pestaas.

Un uso muy habitual en la agrupacin de las diferentes posibilidades de los
parmetros de una parametrizacin.

5. 10. Rejillas (Grids).

Hay rejillas de muchos tipos, pero la idea de las rejillas es proporcionar un
componente de imagen y utilizacin parecidas a las de una hoja de clculo.

La informacin se organiza en una matriz donde cada celda proporciona una
unidad de informacin. Es la imagen habitual de una hoja de clculo.

5. 11. Cajas de Dilogo.

Son objetos visuales construidos por integracin de otros ms simples y que se
utilizan para informar al usuario de acontecimientos y darle opcin de eleccin
entre las diversas opciones que ese acontecimiento da.

Una clasificacin interesante de los controles es por el uso que se hace de ellos:

O Controles que inician acciones:
O CommandButton
O PictureButton
O Controles que gestiona datos.
O ListBox
O StaticText
O SingleLineEdit
O MultiLineEdit
O Grids.
O Tabset.
O Controles que indican eleccin.
O RadioButton
O CheckBox
O Controles para decorar.
O Drawing Objects

6. Men.

Ya s que Vd. sabe que es un men. Slo quiero unificar terminologa.

Los mens son listas de comandos u opciones (menu items) entre las que el
usuario puede escoger. A cada opcin del men se le asigna una accin.

Los mens pueden anidarse jerrquicamente (mens desplegables).

Cada opcin del men puede estar, segn la necesidad del momento:

O Seleccionada.
O No seleccionada.
O Deshabilitada.

Existe la posibilidad de definir teclas de aceleracin asociadas a un tem de un
men y que provocan la misma accin que la seleccin por el Mouse.

Existen mens de contexto, es decir, mens que activados por el botn derecho
del Mouse sobre un objeto, proporcionan la lista de opciones que el usuario tiene
sobre ese objeto.

7. Los mensajes.

Unos de los elementos importantes en una GUI y por otro lado uno de los que
menos se racionalizan son los mensajes.

Existen mensajes de varios tipos:

7. 1. Indicadores de accin.

Informan al usuario que un proceso ligado a una accin se ha iniciado. Estn
basados normalmente en un texto.

7. 2. Indicadores de progresin.

Basados en un componente grfico, indican al usuario el avance de un proceso
de larga duracin.

Es importante que se muevan ya que su seguimiento dar al usuario menos
sensacin de espera. Hoy da encontrar componente de progresin ya
prefabricados y muy espectaculares que podr incorporar a sus GUIs sin
costes de desarrollo adicionales.

Recuerde que en procesos largos:

Deben deshabilitarse el resto de opciones.
Debe darse siempre opcin de cancelacin.

7. 3. Mensajes informativos.

Informan al usuario del resultado de la ejecucin de una accin a conjunto de
acciones. Se basan en un texto o en un una caja de dilogo cuando interesa
que el usuario informe a la GUI de forma explcita que conoce que el proceso
se ha realizado.

7. 4. Mensaje de Aviso.

Informan al usuario de que un proceso delicado comienza y le pide
confirmacin. Por ejemplo, cuando se lanza un proceso que puede suponer
perdida de informacin (una baja de fichero por ejemplo), de pedir
confirmacin al usuario.

Se basan normalmente en una caja de dilogo.

No conviene abusar de los mensajes de aviso porque se genera en el usuario
el efecto contrario, inseguridad antes los efectos que una respuesta
equivocada a tanta pregunta puede causar.

7. 5. Mensajes de Error o Anomala.

Informan al usuario de que un error o una situacin excepcional se han
producido. El usuario ha de realizar acciones para recuperar (s es posible) el
error o la anomala.

Se gestiona normalmente con una caja de dilogo en que cada botn
corresponde a una posible accin. Con viene aadir un botn de ayuda con las
diferentes posibilidades de que el usuario dispone.

8. Tcnicas Drag&Drop.

Permiten simulaciones grficas basadas en:

O Coger con el Mouse un objeto visual.
O Arrastrarlo sobre otro.
O Dejarlo caer sobre l.

Esta simulacin grfica permite representar acciones de forma muy intuitiva: copia
de un fichero de un directorio a otro, pasar contenido de un objeto de edicin a otro,
etc.

Arrastrar un control sobre la GUI habilita en todo momento un mnimo de dos
objetos visuales, controles o no:

O El Drag Control, que es el que se est arrastrando.
O El Target, que es el control sobre el cual est pasando el anterior.

Cuando el objeto visual se coge, se activa un Drag Icon que representa al objeto
que se empieza a arrastrar.

La gestin del proceso se controla mediante los Drag Events:

O DragDrop Even, cuando el Drag Icon est sobre el Target y se suelta del
Mouse.
O DragEnter Even, cuando el Drag Icon entra dentro de los lmites del Target.
O DragLeave Even, cuando el Drag Icon deja los lmites del Target.

Identificacin de Objetos Visuales y Diseo
Tecnolgico de GUIs.

1. Introduccin.

La programacin de GUIs se ha hecho tradicionalmente de forma anrquica: los
objetos visuales se colocan sobre los contenedores con criterios nicamente
estticos. Sin menospreciar el alto valor de la esttica aportada por el diseo
artstico de la GUI, lo primero que se ve, ste no debera ser el criterio nico. Mi
objetivo en este captulo es hacer apostolado en este sentido.

Vamos a ver:

O Cuales son los objetos identificables.
O Cuales son sus atributos y mtodos habituales.
O Como se construyen objetos derivados.
O Como se combinan entre los objetos visuales.
O Criterios de diseo tecnolgico.

Por criterios docentes, me parece importante venderle primero la importancia de
disear bien el tecnolgico de la GUI, he puesto este captulo antes del de diseo
funcional de la GUI que trataremos en el captulo siguiente. Me parece fundamental
convencerle de que debe trabajar bien antes de presentarle los criterios funcionales
que le permiten componer tecnolgicamente las GUIs.

2. Objetos Visuales y Orientacin a Objetos.

La implementacin de objetos visuales se hace siempre por OO. De este tema ya
hemos hablado anteriormente y voy a intentar no repetirme.

Sin embargo quiero hacer un recordatorio de varios puntos que me parecen bsicos
antes de continuar:

O Las herramientas de desarrollo que aportan objetos visuales todas son OO.
O Los conocimientos OO necesarios para tratar los objetos visuales segn este
paradigma son mnimos y conviene saberlos para programar GUIs.
O Si adems se saben tcnicas de herencia y polimorfismo, y se aplican, la
calidad, visual, operativa y reutilizable, es enorme.

3. Identificacin de Clases Visuales relacionadas con una GUI.

Si examinamos e intentamos identificar clases de objetos visuales con el criterio
estndar de identificacin clases OO, obtenemos una jerarqua de clases del estilo
que se muestra en la figura:

Esta jerarqua se concreta en cada entorno de una forma determinada pero siempre
existe. Trabajaremos con esta simplemente para poder concretar la explicacin.

Todos las clases proporcionan los habituales atributos, mtodos y eventos
comunes a todos los objetos visuales de los que ya hemos hablado en el captulo
anterior y que no voy a repetir aqu.

Relacionar a continuacin las clases identificadas y sus atributos y mtodos
diferenciales de su estado y su comportamiento.

3. 1. Aplicacin.

La clase aplicacin es la que implementa el programa que contiene la GUI.
Recibe diferentes nombre segn el lenguaje o la forma del programa: Aplication
en PowerBuilder, Formulario en DELPHI, etc.

Evidentemente esta clase es bastante ms que un objeto visual, pero sea cual
sea su implementacin, si el programa ha de interaccionar con el usuario,
siempre aporta o se asocia un contenedor GUI de objetos visuales donde el
programador colocar los objetos grficos especializados que van a forma la
GUI. Este contenedor suele estar ligado a una ventana principal que es a la
que la aplicacin pasa control una vez arrancada. Desde esta ventana principal
se desencadena todo el dilogo GUI.

Adems de los mtodos, atributos y eventos necesarios para gestionar y
controlar la ejecucin de la aplicacin, esta clase proporciona:

3.1.1. Atributos.

Nombre y titulo.
Contenedor GUI.
Lista de Eventos.

3.1.2. Mtodos.

APLICACIN
Nombre
Contenedor GUI
Ventana principal.
Cola de eventos.
Iniciador de aplicacin
Gestor del Contenedor
GUI.
Gestor de la instancia
Gestor de Eventos.
OBJETO VISUAL
Nombre
Posicin.
Padre
Atributos visuales
Visible y habilitado.
Dibujo e inicilizacin
Obtener atributos
Gestin de hijos
Relacin con el padre
Gestin atributos visuales
Sistema gesti eventos
ACTIVO
EDICIN
Contenido
Inicializacin contenido
Utilizacin per el usuario
Tomar estado
Relaciones con el
portapapeles
Dibujo
CAJA SELECCIN
Contenido.
Valor selecciondo.
Gestin de la seleccin
Seleccin por el usuario
Dibujo
MEN
Nombre
Descripcin
Padre
Notificaciones de
seleccin
Gestin del estado de
las opciones
Dibujo
BOTN
Estado de seleccin
Gestin de selecci
Dibujo
PASIVO
FIGURA
Una subclase por
figura
Dibujo
TEXTO
Dibujo
ICONO
Nombre
Descripcin
Dibujo
VENTANA
Titulo.
Tipo de ventana.
Men de control.
Men de contexto.
Consulta y modificacin
del titulo.
Gestin de la dimensin
con los botones de
redimensionamiento.
Gestin de los mens de
principal y de contexto.
CONTROL
MEN DE
CONTEXTO
MEN
PRINCIPAL

Figura 308. Identificacin de Clases Visuales.
Iniciador de aplicacin.
Gestor del Contenedor GUI
Gestor de la ejecucin de la Instancia.
Gestor de Eventos.

3. 2. Objeto Visual.

Existe una jerarqua formada por todos los objetos visuales que hemos visto en
el captulo anterior.

En la cima de la jerarqua est una clase genrica de objeto visual. En esta
clase se engloban todos los atributos y mtodos comunes a cualquier objeto
visual:

3.2.1. Atributos.

Nombre
Posicin.
Atributos visuales: Tamao, Color, Fuente, Fondo etc.
Visible y habilitado.
Objeto padre

3.2.2. Mtodos.

Dibujo e inicializacin.
Obtener atributos
Gestin de hijos
Relacin con el padre
Control de estado
Gestin de los atributos visuales
Sistema gestin eventos.

3. 3. Especializaciones de la Clase Objeto Visual.

Existen dos especializaciones de esta clase:

3.3.1. Ventana.

Es la clase que implementa este tipo de componente visual. Aporta:

3.3.1.A. Atributos.

Ttulo.
Tipo de ventana.
Mens principales y de contexto.

3.3.1.B. Mtodos.

Consulta y modificacin del titulo.
Gestin de la dimensin con los botones de redimensionamiento.
Gestin de los mens principal y de contexto.

3.3.2. Control.

O simplemente control. Tiene las dos especializaciones que ya hemos
visto: control activo y control pasivo.

3. 4. Control Activo.

Tiene diversas especializaciones genricas enfocadas por su utilidad.

3.4.1. Clases de Edicin.

Como lneas de edicin simples y mltiples, rejillas, etc. Dispone de
atributos para implementar el contenido y de mtodos para consultarlo y
modificarlo y para interaccionar con el portapapeles.

3.4.2. Botones.

Para pedir acciones.

3.4.3. Cajas de seleccin.

Para elegir entre opciones: listas desplegables, radio botones, checks
box, etc.

Obviamente, este ltimo nivel de especializacin puede tener
variaciones en su jerarqua y diferentes especializaciones segn la
herramienta. Sin embargo, observe que en todos los casos, la
clasificacin existe y es muy parecida.

3. 5. Control pasivo.

Tienen dos especializaciones por su contenido:

3.5.1. Textos.

3.5.2. Figuras.

3. 6. Iconos.

No hace falta recordar que los iconos se utilizan para representar otros objetos,
visuales o no.

3. 7. Mens.

Con dos especializaciones:

3.7.1. Men principal.

Asociado normalmente a ventanas.

3.7.2. Men de Contexto.

Asociado a otros objetos para orientar al usuario sobre las opciones
disponibles sobre l.

4. Programacin de interfcies grficas.

La inmensa potencia y facilidades que aportan las herramientas de desarrollo para
crear interfcies grficas se convierten en manos inexpertas o poco profesionales en
una trampa mortal.

En efecto, esas personas confunden el diseo de las GUIs con coger de las
paletas los componentes grficos y tirarlos sobre el contenedor, haciendo la
distribucin esttica antes de atacar a fondo el comportamiento. La gravedad de las
consecuencias de este acto irresponsable es inmensa. Las tres consecuencias
fundamentales y trgicas son:

O Grado de reusabilidad de las GUIs = 0. La misma vista de una entidad, por
ejemplo producto, se programa tantas veces como programas la usan
aumentando desmesuradamente los costes y los plazos de desarrollo.
O La estandarizacin de semntica y uso de las GUIs brilla por su ausencia,
complicando la vida a los usuarios y al personal de soporte.
O La tercera consecuencia es la bajsima calidad del diseo interno de los
programas que dificulta enormemente su mantenimiento y ampliacin.
O Para solventarlo slo hay dos antdotos:
O Disear la GUI antes de sentarse a programarla, tema que trataremos en el
captulo siguiente.
O Utilizar a fondo las tcnicas OO para construir a partir de los objetos bsicos
otros objetos derivados que encapsulen comportamiento y visin y que
puedan reutilizarse.

En esta ltima lnea resulta fundamental del concepto de objetos visuales derivados
que vamos tratar a continuacin.

5. Objetos visuales derivados.

A partir de los objetos visuales simples pueden construirse otros que encapsulen
comportamiento y visin.

Existen dos formas bsicas de hacerlo.

5. 1. Especializacin.

La tcnica de la especializacin
consiste en derivar por herencia un
componente visual de otro, estndar o
derivado, para:

Especializar su comportamiento.
Por ejemplo, puede especializar
una lista desplegables para que
muestre la lista de los productos
de su empresa.

Aumentar su visin. Es decir,
puede hacer cosas ms
complejas, como derivar de una
vista general de productos otra
que visualice las materias primas; o los productos de venta.
Ampliacin
Objecto Visual
Nuevo Objecto
Funcin bsica
Definir objectos
visuales con
comportamientos
especializados
o visin ampliada

Figura 309. Derivacin por especializacin.

5. 2. Integracin.

La derivacin por integracin
consiste en agrupar objetos
visuales para definir otro de mayor
complejidad que visualiza,
normalmente, una entidad.

Por ejemplo, Vd. puede construir
una vista de un cliente agrupando
en un componente visual derivado
todos los objetos visuales que
representan cada uno de los
atributos.

Permtame, dentro de la lnea de
apostolado pro buen diseo de
GUIs, insistir en las ventajas de reutilizacin y estandarizacin que trabajar as
comporta.

A partir de aqu, las posibilidades son inmensas:

Puede esconder atributos, poniendo no visibles sus correspondientes
objetos visuales, si el usuario identificado no tiene permisos para verlos.
Puede colocar todo el componente derivado en modo no habilitado (que
mal suena, me sigue sonando mejor not enable).
Permitir solo modificar los atributos sobre los que tiene derechos el
usuario, etc.

6. Composicin de Objetos Visuales.

Una GUI puede modelarse
desde una perspectiva OO
como una composicin
representada por un modelo
conceptual de objetos como
el de la figura.

A una aplicacin puede
asociarse o integrarse un
icono. La aplicacin integra
una ventana principal. Desde
esta ventana se puede
navegar por otras
normalmente agrupadas pero
tambin en ocasiones
relacionadas.

Una ventana puede integrar
un men principal. La
ventana es una agrupacin de controles u objetos derivados. Un objeto derivado es
la agrupacin de otros estndares o derivados. Y un objeto puede tener asociado
un men de contexto. Etc, etc, etc.
Integracin
Objecto Visual
Nuevo Objecto
Funcin bsica
Agrupacin de uno o
ms elementos pera
definir un nuevo
objecto visual que
los gestione como
un todo. En
particular, integrarlo
como componente
de otro
Objecto Visual

Figura 310. Derivacin por integracin.
VENTANA
1,1
MEN
0,n 0,n
MENU CONTEXTO
0,1
ICONO
0,1
CONTROL
0,n 0,n
1,0
0,1
0,n
OB.DERIVADOS
APLICACIN

Figura 311. Modelado de una GUI.

7. Recomendaciones.

7. 1. De uso de los objetos.

Utilcelos siempre que sea posible (siempre?) a partir del modelo:
tendr independencia de muchas cosas.
Asocie la terminologa de objetos visuales de su herramienta de
desarrollo al modelo general.
Utilice a fondo la tcnica derivar objetos para encapsular comportamiento
y operativa y mejorar la claridad del cdigo.
Asocie objetos derivados a las entidades.
Definir un objeto que modele el enviroment que se integre en la GUI de
forma que todos los objetos integrados lo tengan disponible. Se
instanciar en el constructor de la GUI.

7. 2. De tratamiento de los eventos.

Asociar la gestin de cada evento a un mtodo, de la GUI o de sus
componentes. Primar fuertemente, y en aras de la reutilizacin, la
integracin de esos mtodos en los objetos visuales. La gestin de
evento simplemente la llamada al mtodo.
Definir en cada objeto visual derivado, y de forma general, cuales son los
eventos que puede recibir y enviar, y que respuesta hay que dar a cada
evento interno.
Si se crean subclases, establecer en cada subclase cuales de ellos se
tratan y como. Para ello, en la llamada al mtodo se usar un mecanismo
Evento - Condicin - Accin (ECA).


Vd. puede estar muy o poco de acuerdo con este modelo conceptual de Interfcies
grficas. Respeto su opinin. Lo nico que he pretendido es explicarle mi visin de
un posible modelo y, por encima de todo, forzarle, si no lo ha hecho nunca, a
meditar que el diseo tecnolgico de una GUI no debe ser anrquico sino
organizado y estructurado para conseguir fuertes cotas de reutilizacin y de
normalizacin de uso y operacin.

Diseo Funcional de la Lgica de
Presentacin.

1. Introduccin.

Como ya hemos dicho retiradamente aqu, la lgica de presentacin se representa
hoy da con una GUI.

Y esa lgica ha de ser diseada funcional y tecnolgicamente. En el captulo
anterior hemos hablado del diseo tecnolgico. Vamos a abrir aqu del funcional.

2. Diseo funcional de interfcies grficas.

El diseo funcional de la lgica de presentacin lleva al paradigma de la
comunicacin visual.

Es fundamental tener presente que:

O La interfcie grfica (GUI) desarrolla un modelo conceptual de como el
usuario trabaja con la aplicacin.
O El flujo del dilogo ha de ser controlado por el diseo.
O El usuario marca la iniciativa. Eso hace que la GUI ha de cerrarle los
caminos no vlidos.
O La presencia de ayudas es muy til.
O Siempre que sea posible, hay que dar al usuario la posibilidad de deshacer
una accin errnea.

3. Elementos del diseo funcional.

3. 1. Perfil.

Identifica un rol dentro de la aplicacin, cuales son los derechos y cuales las
restricciones.

3. 2. Identificacin de usuario.

El usuario ha de identificarse para definir claramente cual es su perfil y, por
tanto, su rol de derechos y restricciones.

3. 3. Metfora o Analoga.

El modelo que la GUI implementa ha de ser claro para el usuario.

3. 4. Modelo de Conocimiento.

Los datos, funciones, tareas y perfiles han de ser organizadas de forma
correcta, respetando en todo momento los perfiles del usuario identificado. Se
dice as, que la GUI implementa el modelo de conocimiento que el usuario ha
de obtener de la GUI.

3. 5. Ergonoma.

Ha de existir un esquema eficiente de navegacin por los componentes de la
GUI.

3. 6. Imagen (Look).

La presentacin ha de ser de calidad. La relacin imagen / tiempo de desarrollo
ha de ser correcta (otra vez este ratio tan complicado de establecer).

3. 7. Comodidad.

La interaccin ha de ser cmoda, agradable y efectiva para el usuario.

3. 8. Tcnicas grficas disponibles.

Objetos visuales de las herramientas de desarrollo.
Normas de formatos, ventanas, proporciones, etc.
Criterios tipogrficos: tipos de fuentes, tamao, colores, etc.
Las imgenes que se utilizan: signos, iconos, etc.
La secuencia de navegacin por la pantalla y la organizacin de los
controles.
Las tcnicas de animacin para la visualizacin dinmica.
Tcnicas para hacer consistente la interfcie grfica.

4. Principios Bsicos del Lenguaje Visual.

4. 1. Organizacin.

Proporciona al usuario una estructura conceptual ntida, consistente y
navegable.

4.1.1. Principio de consistencia.

Utilizar reglas de
organizacin de los
diferentes objetos visuales
y establecer relaciones
ntidas entre ellos con el fin
de ayudar al usuario en la
navegacin por los
diferentes componentes de
la interfcie grfica.

Es fruto de la unin de
cuatro factores:

GUI
estructurada
GUI no
estructurada

Figura 312. Principio de Consistencia.
4.1.1.A. Interno.

Garantiza que se mantienen las mismas normas y criterios para
todos los elementos de la GUI.

4.1.1.B. Externo.

Considerando la Plataforma GUI que estamos haciendo servir (en la
mayora de los casos el Windows o Internet) y las consideraciones
culturales dominantes, hemos de hacer servir los mismos signos para
los mismos mensajes visuales.

4.1.1.C. Los referentes al entorno del mundo real.

En la composicin del mensaje visual pueden, y deben, utilizarse
objetos, procesos y eventos que son familiares y que forman parte de
su cultura y experiencia visual. Por ejemplo, si se arrastra un
producto que ha ocupar la posicin de ser un envase, el icono
utilizado puede ser una botella.

4.1.1.D. Inconsistencia.

Las desviaciones de la norma, en algunos casos, pueden aportar un
valor aadido muy claro al usuario. Particularmente, no soy muy
partidario de este criterio si la contrapartida no es
extraordinariamente clara. En muchas ocasiones, la necesidad de la
inconsistencia es solo aparente y se debe a una operativa no
suficientemente estudiada.

4.1.2. Normas de visualizacin.

La organizacin se refuerza siguiendo normas de visualizacin:

Agrupando los objetos visuales por grupos conceptuales y
tipologa.
Normalizando la composicin de objetos.
Distribuyendo los objetos visuales sobre la base de sus posibles
relaciones, evitando saltos en la navegacin por la pantalla.
Organizando correctamente el salto de un objeto al siguiente.
Cerrando caminos inapropiados en funcin del estado de la GUI.

En pocas palabras, las relaciones entre los objetos han de ser claras,
consistentes y apropiadas.

4.1.3. La composicin espacial.

La organizacin de la composicin espacial ha de distribuir los
elementos del mensaje visual en grupos principales y secundarios
suministrando un foco inicial que fije la atencin del usuario (atencin
directa) y los focos secundarios o perifricos que le ayuden en la
navegacin.

4. 2. Economa.

Consigue las mximas prestaciones con el mnimo de elementos visuales:
mximo ratio de prestaciones / coste.

El principio de la economa es la unin de diversos factores.

4.2.1. Simplicidad.

Nada ms se han de incluir aquellos objetos que son esenciales a la
comunicacin.

4.2.2. Claridad.

Los componentes que se incorporen al mensaje visual no han de ser
ambiguos.

4.2.3. Diferenciacin.

El mensaje visual ha de distinguir y remarcar todas aquellas
propiedades ms importantes de los componentes.

4.2.4. nfasis.

En un mensaje visual hay elementos importantes que se han de resaltar
y hacer fcilmente distinguibles.

4. 3. Comunicacin.

Ajusta el modelo y tipologa de la presentacin a las capacidades y formacin
de los usuarios.

4.3.1. Factores.

Ha de buscar equilibrar diversos factores:

4.3.1.A. Legibilidad.

Criterios escogidos para el diseo de los caracteres, smbolos y
componentes visuales han de ser obvios y fciles de distinguir para
los usuarios.

4.3.1.B. Comprensibilidad.

La visualizacin de la GUI ha de ser comprensible para el usuario, es
decir, fcil de identificar e interpretar y tener, adems, capacidad
para captar la atencin del usuario.

4.3.1.C. Utilizacin tipogrfica.

En al comunicacin del mensaje visual es recomendable utilizar un
nmero reducido de tipos de fuente, estilos y medida de los
caracteres. Hacerlo as, hace la presentacin de la GUI ms
descansada y agradable al usuario.

4.3.1.D. Simbolismo.

La eleccin de iconos, smbolos, diagramas e imgenes fotogrficas
y/o dibujadas ha de ser cuidadosa para comunicar mejor el mensaje
deseado.

El simbolismo tiene un alto componente subjetivo. Cada
organizacin, departamento dentro de la organizacin e, incluso,
cada usuario puede tener preferencia por sus propios smbolos. Es
evidente que la lucha debe ser por crear una cultura nica. Los
intentos toparan siempre de entrada con reticencias en los usuarios
que han de cambiar. Sin embargo, la experiencia dice que
rpidamente todo el mundo se acomoda al lenguaje comn. Sea
poltico, si tiene que escoger smbolos para unificar varias culturas,
escoja un poco de todo; como ya le he dicho, lo importante en la
unificacin y la comprensibilidad, no el smbolo en si, ya que
rpidamente todo el mundo se acostumbra.

Conviene utilizar a fondo la cultura dominante y mantener una
posicin conservadora; con ello se facilitar que el usuario reconozca
de entrada el contenido de una parte del mensaje visual y se
identifique ms fcilmente con l.

4.3.2. Divisin del mensaje.

Un mensaje complejo ha de ser dividido en varios de ms simples o
submensajes.

La utilizacin de esta tcnica no es ninguna trivialidad.

El mensaje se ha de dividir en otros ms simples con criterio
coherentes, respetando siempre las unidades bsicas del mensaje. As,
una vista compleja de clientes puede dividirse en submensajes parciales
que detallen direcciones, formas de pago, etc. Pero la divisin no
puede dejar los atributos de la forma de pago en dos submensajes
diferentes. Aqu las tcnicas de derivar objetos visuales e instanciacin
dinmica son fundamentales.

La navegacin entre los submensajes ha de ser coherente. El panel
de presentacin de los submensajes ha de ser muy cuidado.
Se deben cerrar caminos errneos. Aqu la utilizacin de los
atributos habilitado y visible es fundamental.

4.3.3. Vistas mltiples.

Una de las tcnicas ms importantes para mejorar la comunicacin en
entornos grficos es la utilizacin de vistas (perspectivas) mltiples en
la visualizacin de estructuras y procesos complejos.

Esta tcnica ha de utilizarse en reas como:

Los formatos de presentacin.
Los niveles de abstraccin.
La presentacin de situaciones alternativas.
Los procesos secuenciales.
Las referencias cruzadas.

La utilizacin de perspectivas no debe abusar de cambio de la pantalla
de foco lo que acabara causando cansancio visual al usuario.

Utilice hbilmente los atributos habilitado y visible, la gestin del foco e
instanciacin dinmica segn la situacin de objetos visuales derivados.
Por ejemplo, si est gestionando materias primas, si el producto actual
es una envase puede instanciar en una zona de la vista en objeto visual
derivado que presente sus atributos diferenciales. Cuando la materia
prima sea un lquido cambiar dinmicamente la zona de los atributos
diferenciales. Complementando todo ello con imgenes e iconos que
visualmente muestren que tipo de materia prima est en pantalla
pueden conseguirse perspectivas con alto nivel de comunicacin sin
demasiado esfuerzo.

4.3.4. Color y textura.

Es un factor muy complejo de la comunicacin visual y tan subjetiva
como el simbolismo.

El color es una de las herramientas ms potentes para la comunicacin
visual si se utiliza correctamente: la cultura dominante asocia el rojo a
peligro o camino prohibido, el verde a adelante, el amarillo a precaucin,
el azul a relajacin, etc.

La utilizacin adecuada del color proporciona diversas posibilidades:

Poner nfasis en determinadas informaciones del mensaje. Por
ejemplo, un crdito sobrepasado puede ponerse en rojo y uno muy
cercano a cero en amarillo.
Identificar estructuras y subsistemas.
Asignar los colores naturales a los objetos visuales. As, si un
lquido es verde, su smbolo ser de ese color.
Reducir los riesgos de interpretacin. Un mensaje en rojo no deja
lugar a dudas de que hay que tener precaucin con algo.
Se pueden aumentar los niveles de entendimiento, claridad y
credibilidad.
Se pueden simplificar los niveles de abstraccin.

El uso incorrecto de estas tcnicas puede llevar a efectos contrarios a
los buscados:

Hay combinaciones de colores poco atractivas. Ojo con este factor
que es altamente subjetivo.
Algunos colores pueden causar incomodidad y provocar cansancio
visual.
Hay colores que pueden tener significado diferentes en diversas
zonas del mundo. Es conocido que el negro se asocia en occidente
al luto y el blanco a la pureza y que oriente el blanco es el color el
luto.

4. 4. Normativas y recomendaciones.

Utilice a fondo las normativas y recomendaciones dominantes, no invente si no
es necesario. Facilitar la vida al usuario y a Vd. mismo ahorrndose formacin
y asistencia.

Dentro de este apartado, que de hecho ya se ha ido citando en los anteriores,
quiero remarcarle la
importancia de una
distribucin lgica y
coherente de las zonas de la
pantalla. Cada mensaje debe
ir en la zona adecuada.

ejemplo de una posible
organizacin zonal de una
pantalla. No intenta ser un
axioma, sino solamente una
motivacin para que Vd.
tenga en cuenta este
principio de la comunicacin
a mi juicio fundamental.

4. 5. Los flujos de dilogo.

Los flujos de dilogo entre el usuario y la GUI marcan el camino o caminos que
el usuario debe seguir para completar una determinada tarea. Quedan
determinados por las caractersticas de cada una de las aplicaciones.

Pueden resolverse segn dos modelos:

GUIs tradicionales: modelos men / botones para dar la eleccin,
eleccin / peticin del usuario y accin. Dos versiones:
Windows.
rea de Ttulo Controles de Ventana
Men
Zona de acciones
rea cliente
reas de
Desplazamiento
rea
Informtiva

Figura 313. Divisin por reas de una ventana.
Internet
OOUIs: modelo objeto, accin.

GUIs es el sistema convencional que seguro Vd. conoce sobradamente.
OOUIs es un enfoque basado en la gestin de objetos visuales complejos.
OOUI puede asimilarse a componente de presentacin.

Para m no hay demasiada diferencias entre las dos tcnicas si las GUIs se
disean correctamente ya que la utilizacin de objetos derivados no difiere
demasiado de una tcnica OOUI. Esta es la razn por la que no me parece
ahora demasiado didctico hablar de este tema ya que puede distraerle del
verdadero e importante objetivo de este capitulo, que como ya hemos dicho, es
explicar los criterios de diseo funcional de una interfcie grfica
independientemente de s el OOUI o GUI.

Volviendo a los flujos de dilogo, la interfcie grfica no deber nunca
interferirlos, sino todo lo contrario facilitarlos. Segn la aplicacin puede haber
diferentes caminos para un determinado trabajo.

Es dilogo debe basarse en el principio de ver y apuntar: se presentan las
opciones actualmente accesibles segn el rol del usuario y el estado de
ejecucin del trabajo. Deben existir procesos de mantenimiento instantneo de
este principio en funcin de las acciones que va realizando el usuario.

No deben presentarse pantallas innecesarias.

Los mensajes han de ser breves y claros. Suele decirse que esos mensajes
han de usar una terminologa accesible al usuario, omitiendo tecnicismos
informticos y de aplicacin. Me van a permitir que difiera un poco (slo un
poco) de ese principio general. Lo que se debe omitir son tecnicismos
innecesarios. No se puede caer en el error con el fin de evitar usar esos
tecnicismos, usar mensajes que sean largos y utilicen trminos no tcnicos que
desvirten el contenido semntico del mensaje. Soy un firme defensor que el
usuario ha de poner algo de su parte, aprendiendo los tecnicismos bsicos del
entorno donde trabaje. Si es necesario monte un plan de formacin (siempre
corto) para lgralo.

Por otro lado, si que me parece fundamental otro aspecto: el flujo de dilogo ha
de ser tolerante con los errores. Las acciones han de tener, dentro de lo
posible (casi siempre), la posibilidad de deshacer y recuperar una accin
equivocada. En los casos extremos que eso no sea posible, el usuario ha de
tener notificacin expresa.

La utilizacin de ventanas secundarias es importante en el flujo de dilogo.
Como ya se ha dicho, y Vd. ya conoca, existen:

4.5.1. Ventanas nodales.

Cogen de forma exclusiva el foco de su aplicacin. Obliguen al usuario
a completar todas las acciones establecidas en la ventana antes de
abandonarlas.

4.5.2. Ventanas no nodales.

Dejan al usuario interaccionar simultneamente con todas las ventanas
abiertas. Las ventanas estn activas mientras no completen su funcin
o no se cierren explcitamente.

Ambos tipos de ventanas han de combinarse de la forma que ms convenga a
las necesidades del flujo del dilogo.

5. Metodologa de Diseo de interfcies Grficas.

Una vez presentados todos los conceptos, le voy a proponer una metodologa de
diseo de GUIs.

El punto de partida es la especificacin del trabajo que el diseo de la explicacin
ha delegado en la GUI. Como en todo otro proceso, la precondicin establecer la
informacin que se proporciona a la GUI y la poscondicin lo que se espera recibir.

No olvidemos que el dilogo de una GUI es transaccional y que la GUI no es el
proceso sino la interfcie de interaccin del proceso con el usuario.

Esto ha de estar claro para Vd. incluso en los procesos GUIs ms simples, las
consultas. Para que se convenza de ello, repasemos el ciclo de un trabajo de ese
tipo.

La aplicacin empieza presentando un GUI de la que el usuario saldr con una
peticin de informacin o una cancelacin. Si la peticin es de informacin, la
transaccin de salida llevar las claves que determinan el acceso a la informacin
que el usuario desea. La aplicacin obtendr esa informacin y la devolver a la
GUI en otra parte del mensaje de la transaccin.

En el caso ms simple, este proceso de consulta se implementar en el evento del
botn de aceptar la peticin. La transaccin no existir fsicamente ya que los
campos clave se tomarn directamente de la GUI y la informacin obtenida se
colocar directamente sobre la GUI. Pero observe que aun en este caso, el
concepto de transaccin se mantiene aunque el mensaje se codifique en la misma
GUI. Y en cualquier caso, recuerde que en el evento solo debe hacer una llamada a
un mtodo que implemente la consulta a la base de datos.

El ciclo de trabajo es:

O Activacin de la GUI. La GUI recibe en la precondicin una seal de que es la
primera entrada. Puede tener ya datos a mostrar o no. Segn la pantalla sea
de presentacin, peticin de datos o combinacin de ambas.
O Salida de la GUI. El mensaje de salida depende de la finalidad de la GUI. En
GUIs de presentacin, el mensaje de salida es simplemente la aceptacin del
usuario de la informacin recibida. En pantallas de peticin, los datos
solicitados.
O Proceso del mensaje de salida, que puede volver a originar una entrada en la
GUI.
O Aceptacin por la GUI de esta precondicin de entrada colocando la
informacin recibida en la interfcie grfica y volviendo al segundo paso.

Teniendo este aspecto claro ataquemos el diseo en s.

En primer lugar, una reflexin y un consejo. Atendiendo a las caractersticas del
trabajo a las herramientas disponibles, para documentar el anlisis de la GUI
pueden utilizarse tcnicas de prototipaje para que el usuario vea como quedar y el
programador que se ha de hacer. Recuerde que si para documentar utiliza
prototipos, son prototipos, no la primera versin de la GUI definitiva.

5. 1. Definicin de los modelos.

Los modelos son las visiones ha tener en cuenta en el diseo. Cuando se
comienza ese diseo hay que tener en cuenta cuatro visiones o modelos
diferentes.

5.1.1. Modelo de diseo.

Creado por el ingeniero de software segn las necesidades de la
aplicacin. No contiene la imagen grfica, sino los contenidos de la GUI
a travs de su precondicin y poscondicin. Es un resultado del anlisis
funcional de los procesos.

Aporta las entidades y atributos de los datos, procedimientos y
estructuras de software que han de ir ligadas a la interfcie o en su
interior. Aporta tambin las posibles restricciones.

5.1.2. Modelo grfico de usuario.

Llamado tambin en algunas metodologas diseo externo. Es creado
por el diseador de interfcies grfica, que obviamente, puede ser el
mismo ingeniero de software. Es la adaptacin grfica que se cree
adecuada al modelo de diseo en funcin de los estndares, normas,
caractersticas de la aplicacin y perfil del usuario, y utilizando todos los
principios del lenguaje visual que hemos visto anteriormente.

Incluye el perfil de los usuarios finales del sistema. Para construir una
interfcie eficaz hay que empezar por conocer a los usuarios.

Los perfiles de usuario puede agruparse en:

Noveles con pocos conocimientos de la aplicacin y/o los
ordenadores. Se les ha de guiar mucho.
Usuarios intermitentes con capacidad de aprendizaje. Tienen
conocimientos razonables, pero como el uso que harn es
intermitente, tendrn poca memoria de la interfcie.
Usuarios frecuentes con buenos conocimientos. Se les ha de
proporcionar formes abreviadas de interaccin. Hay un subgrupo
peligroso, los hackers o buscadores de agujeros: suelen descubrir
trucos no cubiertos por la interfcie.

La importancia del diseo externo puede llegar a ser grande que existen
verdaderos especialistas en la materia, ms relacionados con el mundo
del diseo grfico que con la informtica.

5.1.3. Modelo del usuario o percepcin del usuario.

Es la imagen mental que el usuario imagina de la interfcie. Soy de los
firmemente convencidos de que debe ser recogida antes de concretar el
modelo grfico de usuario. Respeto, pero no comparto, la opinin de los
que piensan que la perspectiva del usuario no debe influir en el diseo
inicial y que solo debe ser requerida al final del proceso. Tres
argumentos avalan mi opinin: el usuario conoce su trabajo, sabe lo que
mejor le conviene y hoy da dispone de una formacin informtica
bsica producto de la utilizacin masiva de aplicaciones a travs de
interfcies grficas.

La percepcin y la imagen que el usuario se haga del sistema de forma
mental dependern de su perfil y experiencia anterior.

5.1.4. La imagen del sistema.

Es el resultado final que los diseadores quieren dar al sistema y que es
producto de la interaccin de los tres modelos.

La imagen del sistema combina la manifestacin externa de toda la
informacin que describe la sintaxis y la semntica del sistema. Cuanto
ms coinciden la imagen del sistema y la percepcin del usuario ms
efectiva es la comunicacin y ms eficiente es el uso que se hace el
software.

Establecer la relacin entre los tres modelos no es simple. Desgraciadamente,
las cuatro visiones pueden diferir significativamente. El papel del diseador es
reconciliarlas y generar una representacin consistente, eficaz y consensuada
de la interfcie.

No es difcil deducir que lo conveniente es que participen en el proceso de
diseo todas las partes
implicadas trabajando
cooperativamente.

La interaccin entre los
tres modelos es tan
obvia como se muestra
en la figura. El diseador
grfico recoge como
precondiciones las
especificaciones del
modelo de diseo y, a mi
juicio, la perspectiva del
usuario, y utilizando los
componentes del
lenguaje visual, las
normas y
recomendaciones, analiza y modela las tareas formalizando la GUI en la
imagen grfica del usuario.

Esta imagen se evala en rendimiento y se muestra al usuario que la contrasta
con su perspectiva de usuario y el proceso se realimenta hasta crea la imagen
final del sistema.

5. 2. Anlisis y modelacin de las tareas para crear el modelo grfico de
usuario.

Modelo
de
Diseo
Imagen del
Sistema
Modelo
grfico
de
usuario
Diseador Grfico
Usuario
Percepcin
del
sistema
Diseo
Externo
Diseo
Interno
Programador

Figura 314. Interaccin entre los modelos.
Las tareas que el modelo de diseo ha decidido que la interfcie debe realizar
han de ser diferenciadas claramente, modeladas segn la percepcin del
usuario y formalizadas con los componentes visuales. En todo el proceso se
han de tener en cuenta los principios del lenguaje visual detallados
anteriormente en este captulo.

Una vez realizado este proceso, se han de evaluar los tiempos de respuesta a
travs de sus dos factores:

Tiempos de espera / respuesta.
Variabilidad de la espera.

A continuacin hay que incorporar la integridad y consistencia para proteger a
los usuarios de los errores y caminos inadecuados. En esta etapa se
implementaran las opciones de deshacer para recuperar errores.

Finalmente se incorporaran las ayudas y facilidades para el usuario.

5. 3. Formalizacin del diseo en la interfcie.

Una vez concensuado el diseo externo de la GUI habr que realizar su
programacin informtica, conocida tambin como diseo interno. Aqu
vuelve a actuar el programador, y recomendablemente, con tcnicas OO.

La formalizacin de la modelo grfico de usuario se realizar en la herramienta
de diseo del equipo de desarrollo.

5. 4. Evaluacin de la interfcie.

Como ya he comentado, a
partir del modelo de diseo
el diseador grfico realiza
un diseo inicial reflejado
en un prototipo del modelo
grfico de usuario.

Este primer diseo se
evala tcnicamente en
cuanto a tiempos de
respuesta y navegacin.

Se realiza a continuacin
una primera evaluacin
con el usuario. Los
resultados de esta
evaluacin se estudian por
el diseador y se incorpora
la modelo grfico. Si se
considera que los cambios
son suficientemente importantes para hacerlo, se modifica el diseo, se adapta
el prototipo de la interfcie y se evala de nuevo con el usuario. El ciclo se
repite hasta que el diseador grfico y el usuario consideran que la interfcie ya
esta acabada.

Prototipo del
modelo
grfico
Evaluacin
con el
usuario
Modificacin
del diseo
Adaptar el
prototipo de la
interficie
Estudio por el
diseador de
la evaluacin
Diseo final
de la imagen
del sistema
Evaluacin
Tcnica
Diseo Inicial

Figura 315. Ciclo de evaluacin de una interfcie.
5. 5. Entrega de la interfcie.

Finalmente, el diseador grfico entrega la GUI a los desarrolladores para su
incorporacin a la aplicacin. Aprovecha este momento para explicarles los
criterios utilizados en el diseo. El objetivo de esta accin es doble. Por una
parte el programador participa de la semntica de la pantalla y por la otra es
informado de los criterios que pueden influir en la gestin de los procesos de la
GUI.

6. Criterios a tener en cuenta en el diseo.

Evidentemente, todos los presentados al desarrollar el lenguaje visual.

A modo de resumen, pueden agruparse en tres grupos:

6. 1. Criterios de interaccin con el usuario.

Ser consistente con todo lo explicado en el lenguaje visual.
Ofrecen una realimentacin significativa. Es decir, adaptar la GUI a la
evolucin de la accin del usuario.
Pedir verificacin de cualquier accin destructiva no trivial.
Permitir acciones de deshacer.
Reducir el esfuerzo de memorizacin del usuario. Es decir evitarle tener
que recordar operativa no expresada explcitamente en la GUI.
Buscar eficacia en el dilogo. Este es otro de aquellos criterios de difcil
medida.
Proteger la GUI de errores de usuario cortando los caminos no deseados.
Conseguir una navegacin eficiente. Otro criterio difcil de medir.
Proporcionar facilidades de ayuda sensibles al contexto. Importante para
guiar al usuario.
Utilizar verbos de acciones simples y lo ms adaptados posible a la
cultura general.

6. 2. Criterios de visualizacin de la informacin.

Mostrar nada ms la informacin importante en el contexto actual.
No ahogar al usuario con datos.
Hacer servir nombres consistentes y unificados y formatos claros y
estndares.
Permitir al usuario mantener el foco inicial.
Producir mensajes significativos.
Hacer buenos modelos de los diferentes tipos de informacin mediante el
uso apropiado de objetos visuales derivados.
Hacer una buena composicin visual de los componentes en la GUI de
forma que no produzca al usuario cansancio visual.

6. 3. Criterios de entrada de datos.

Minimizar el nmero de acciones.
Mantener consistencia entre la informacin visualizada y los datos que se
estn pidiendo.
Permitir al usuario la personalizacin, si es posible, de la entrada de
datos.
La interaccin ha de ser flexible y adaptarse lo ms posible al modelo
deseado por el usuario.
Organizar una buena secuencializacin de los controles que representan
los campos a entrar. El orden ha de ser lo ms cercano posible al de la
fuente de datos.
Desactivar opciones no disponibles en el contexto actual.
Permitir al usuario controlar el flujo.
Proporcionar ayudas de contexto.
Eliminar entradas innecesarias.


Si Vd. ha desarrollado GUIs, le propongo que se haga una pregunta simple y
busque una respuesta verdica. Cuntas veces ha diseado sus GUIs de esta
forma? Si me hace Vd. a m la pregunta, le ser sincero: poqusimas.

Quiere ello decir que este captulo sobra? Creo firmemente que no. El problema,
como otros muchos de nuestra profesin, es que hacerlo bien es caro y las ventajas
solo se ven a medio plazo. Adems los plazos que nos piden suelen ser para ayer.
Las ventajas se miden en fase de explotacin en un menor tiempo de trabajo para
los usuarios. Y cuando han de hacerse mejoras y ampliaciones del sistema y nos
ira bien reutilizar. Y eso es dinero, y del bueno!, del que se gana da a da y para
siempre.

Pero, cmo medirlo en fase de diseo? Yo lo veo imposible. Nuestro cliente habr
de hacer acto de fe en nuestro apostolado de que las GUIs han de disearse bien.

Hago aqu constancia de que en mi siguiente aplicacin grfica voy a intentar
disearla bien. Y, desgraciadamente, tambin confieso que difcilmente voy a
conseguirlo.

Construccin de Frameworks.

1. Introduccin.

En los captulos anteriores dedicados a las GUIs hemos visto la importancia de
trabajar con objetos visuales derivados que encapsulan la vista de una entidad
compleja.

Para conseguir una reutilizacin importante, minimizando costes y plazos, y
normalizar al mximo la operativa, minimizando la formacin y las incidencias, es
necesario dar un paso ms.

Se trata de encapsular proceso. Por ejemplo, toda la gestin del mantenimiento de
una entidad. Este nuevo objeto visual derivado, complejo por lo que se quiere de l,
vamos a reverenciarlo como Framework.

En este captulo voy a darle unas nociones bsicas sobre construccin de
Framework. Para hacerlo, voy a tener que utilizar ms nivel de orientacin a objetos
del que he utilizado (intencionadamente) en este libro. Siento hacerlo as, pero creo
firmemente que si no lo hago, explicara pobremente el tema, faltando a mi
obligacin con Vd. de explicar las cosas lo mejor que mi formacin y experiencia me
hace capaz.

2. El Paradigma MVC.

MVC es el acrnimo de Model-View-Controller propuesto al mundo OO por los
creadores de Smalltalk.

La idea bsica consiste en separar la funcionalidad de la interfcie:

O El Modelo (Model) es la clase del objeto.
O La Vista (View) es objeto grfico (prcticamente siempre un objeto derivado)
que proporciona la imagen visual de la clase. Obviamente puede haber ms
de una vista por clase.
O El Controlador (Controller) es el encargado de interpretar la entrada de la vista
y gestionar la grabacin y lectura del modelo en disco, es decir, la
Persistencia del modelo. En lo sucesivo, nos referiremos siempre al
Controlador como Persistencia.

La implementacin del controlador como gestor de la persistencia har que, a partir
de este punto, me refiera al paradigma MVC como MVP.

Un Framework modelar el comportamiento global de la accin realizada por el
usuario (por ejemplo, un mantenimiento de instancias de la clase), incorporar los
controles adicionales para facilitar la operacin de las diferentes opciones ligadas a
la accin (alta, baja, modificacin, consulta) y llevar la gestin de los mensajes
necesarios para el flujo del dilogo.

La construccin de un Framework utilizar este paradigma. Adems de los objetos
visuales ligados a las opciones y a los mensajes, el Framework integrar los
componentes MVP que colaborarn entre s para implementar el Framework.

O El Modelo implementar la clase, atributos y restricciones de integridad como
mnimo.
O La Vista interaccionar los atributos con el usuario.
O La Persistencia interpretar la entrada del producto y actualizar el modelo en
el almacn de datos persistente.

En todo este captulo voy a seguir siempre con conceptos OO. Pero observe que la
idea MVP, aunque originara del mundo OO, puede ser aplicada a piezas, que si no
recuerda a estas alturas del libro, no son ms que clases sin herencia ni
polimorfismo. Sin embargo, las ventajas y facilidades OO son demasiado
importantes como prescindir de ellas como confirmar a medida que avance en la
lectura de este captulo.

Las ventajas del paradigma son MVP son muchas. Ha demostrado ser muy eficaz
ya que independiza la interfcie, muy voltil, de la verdadera naturaleza del objeto o
entidad gestionada: se puede cambiar la vista, sin cambiar el modelo.

La misma pelcula puede rodarse con la persistencia que permite la independencia
del acceso cualquiera que sea finalmente la implementacin de la base de datos
(relacional SQL-ODBC, orientada a objetos, jerrquica, etc.)

3. Multivistas, especializacin y jerarqua de vistas.

Como ya hemos dicho, un objeto puede tener ms de una vista.

O Por transportabilidad. Por ejemplo, una para Windows y otra para X-
Windows en UNIX.
O Por necesidad de aplicacin, el caso ms habitual. Por ejemplo, una vista
puede dar acceso a todos los atributos y otra especializada en solo a una
parte.

As, pues, es muy evidente que la vista de un objeto no suele ser nica y acaba
teniendo ms de una implementacin segn las necesidades. Sin embargo, hay
que evitar caer en la trampa de tener demasiadas vistas ya que la reutilizacin
sera muy baja y este es uno de los factores ms interesantes aportados por el
paradigma MVP. La especializacin de la vista con el uso adecuado e imaginativo
de los atributos visible y habilitado ayudar muchsimo. Tambin ayudar el uso de
la especializacin por herencia de la que hablaremos enseguida.

Sin embargo, no debe confundirse el concepto de ms de una vista con el de vista
adaptada al perfil y derechos del usuario. En el primer caso, la multivista se
implementa en objetos visuales diferentes adaptados por criterios como espacio,
nivel del usuario, uso, etc. En el segundo caso, una nica vista se particulariza al
perfil del usuario jugando con los mecanismos de instanciacin dinmica y los
atributos de visible y habilitado.

Un caso especial e interesantsimo de multivista es el caso de las vistas asociadas
a una jerarqua de clases. Es muy recomendable que la organizacin de las vistas
de una jerarqua de clases se haga segn la misma jerarqua de la clase modelo. Si
se hace as, la aplicacin ser mucho ms organizada, gestionable y podr
aprovechar las ventajas del paralelismo entres la herencia del modelo y de la vista.

El concepto de mantener una jerarqua de clases modelo es aplicable tambin a la
persistencia, aunque con mucho menos inters. As como en el caso de las vistas
debera ser casi una obligacin de diseo, en el caso de la persistencia la
obligacin es ms tenue.

4. Arquitectura de Diseo de un Framework.

A efectos docentes, le voy a
presentar una arquitectura de
Framework en la lnea de
utilizacin de un slo modelo
y una sola vista. Sin
embargo, como ver la
arquitectura es totalmente
generalizable al caso general
que involucre a varios de
estos elementos.

esquema de bloques de la
arquitectura de un Framework
grfico.

4. 1. Arquitectura de
bloques.

En esta arquitectura se identifican diferentes bloques.

4.1.1. La interfcie grfica (GUI) del Framework.

Es el contenedor grfico asociado al Framework dentro del cual se
instanciarn la vista, los objetos visuales de las opciones y la zona de
mensajes.

4.1.2. El modelo.

Que aporta los atributos y comportamiento de la entidad gestionada.

4.1.3. La persistencia.

Que aporta su lectura y grabacin en disco.

4.1.4. Los atributos del Framework.

Que aportan los datos especficos de trabajo del Framework.

4.1.5. La Lgica de proceso del Framework.

Que aporta los mtodos que implementan el comportamiento del
Framework.

Framework de aplicacin
Modelo
Persistencia
Lgica de proceso del Framework
Vista
Zona de Mensajes
GUI
O
p
c
i
o
n
e
s
Entorno
Atributos del Framework

Figura 316. Arquitectura de un Framework grfico.
4.1.6. El entorno (enviroment).

Ledo en el proceso de construccin durante la instanciacin del
Framework, aportar, entre otros, las caractersticas de la plataforma,
de la parametrizacin y del usuario. Servir para particularizar el
aspecto y comportamiento del Framework.

4. 2. Modelo de Objetos del Framework.

El modelo de objetos
que representa a un
Framework se
presenta en la figura.

La clase que modela
el Framework,
adems de disponer
de los atributos y
mtodos necesarios
para modelar su
propio estado y
comportamiento,
agrupa e instancia un
objeto del modelo,
vista y persistencia,
adems de otro de la
clase entorno.

La clase Framework
integra tambin una clase visual que modela la GUI, que tendr su propio
modelo de objetos con los criterios que hemos mostrado en los captulos
anteriores.

A estas agrupaciones, se aaden cinco asociaciones dinmicas:

La Vista con el Modelo.
La Persistencia con el Modelo.
El Entorno con la Vista.
La Vista con la GUI.
El Entorno con la GUI

La asociacin dinmica la establece el Framework pasando en el constructor
de la persistencia la instancia de la clase modelo, en el constructor de la vista
la instancia del modelo y la del entorno, y en el constructor de la GUI la vista y
el entorno.

Vista y GUI utilizarn el entorno para especializarse.

4. 3. La Clase Entorno.

En todas las aplicaciones, y particularmente en aquellas en las cuales la
integracin del cliente es mediante una GUI, la definicin del entorno es
fundamental.

Clase Fremework
objeto clase_modelo
vista clase_vista
es clase_persistencia
entorno clase_entorno
Atributos del Framework
Metodos de proceso del Framework
Clase Vista
objeto clase_modelo
constructor(objeto,
entorno)
Clase Persistencia
objeto clase_modelo
constructor(objeto)
Clase Modelo
Clase Entorno
Atributos Entorno
GUI
vista clase_vista
entorno clase_entorno
constructor(objeto,
entorno)

Figura 317. Modelo de Objetos de un Framework.
La gestin del entorno no es un problema de complejidad, sino de hacerlo bien.
Su descripcin ha de ser clara, precisa y compartida por todos los mdulos.

Por esa razn, el entorno en los Framework se implementa en un objeto que se
traspasa y/o inicializa entre los mdulos.

Cada parmetro del entorno ser un atributo de la clase. Todos los atributos
sern privados y accesibles nada ms que por mtodos lo que garantizar su
integridad. Los programas los consultarn y cambiarn mediante estos
mtodos.

Los orgenes de los valores de los parmetros del entorno son dos:

Los parmetros estticos definidos en los ficheros de inicializacin
esttica del tipo *.INI o XML donde se colocan sus valores por defecto.
Se personalizan por el administrador de sistema o en responsable de la
aplicacin con los criterios establecidos por el diseador.
Los parmetros dinmicos que se obtiene o piden en el momento de la
instanciacin del objeto. El perfil de usuario es un caso claro de este
grupo.

Cuando se instancia el objeto se cargan los parmetros estticos y se piden los
dinmicos, si el objeto entorno recibido no los tiene ya registrados.

Para traspasar el objeto entorno entre mdulos se utilizan las dos tcnicas
clsicas: pasar la instancia o dotar de persistencia a la clase entorno.

4. 4. Consejos para hacer Framework de uso general.

Imagine que quiere crear un Framework de mantenimiento de uso general que
ha de servir para cualquier entidad.

Para conseguirlo deber crear el Framework como una clase abstracta que se
adaptar por herencia y polimorfismo a cada entidad.

Para que eso sea posible, deber crear jerarqua de clases para los modelos,
las vistas y las persistencias. En la raz de estas jerarquas estar una clase
abstracta de cada tipo. La clase Framework abstracta integrar por agrupacin
estas clases abstractas. Las clases abstractas definirn el comportamiento
mediante mtodos genricos que se adaptarn por herencia y polimorfismo a
cada entidad.

La clave es esa, la abstraccin del comportamiento en la raz de la
jerarqua.

Como ya se ha dicho anteriormente, la jerarqua de las vistas y, en menor
medida la de las persistencias, debe imitar a la del modelo.

Encapsule las opciones y la zona de mensajes en clases visuales derivados,
que, en general, sern independientes de las entidades. En cualquier caso, si
debe hacer una especializacin de estas dos clases para alguna entidad, se
ser mucho ms fcil hacerlo, una vez ms, por herencia y polimorfismo.

La Comunicacin por eventos como va
para obtener servicios.

1. Introduccin.

Voy a pagar en este captulo una deuda.

He estado afirmando desde el principio que iba a proponerle un modelo de diseo
independiente de la metodologa de diseo de aplicaciones utilizada. Y hasta ahora,
a parte del capitulo dedicado a introducir la metodologa OO aplicada al diseo de
aplicaciones, no he hecho ninguna mencin ms. Pero observe que, a la pasiva,
tampoco en toda la metodologa expuesta he presentado nada que exija que la
aplicacin se haya diseado convencionalmente.

Con esta presentacin, no le sorprender que le diga que en este captulo voy a
extender la metodologa a modelos orientados a objetos.

Voy a centrarme en el caso de comunicacin C/S pero como ver los conceptos
son aplicables a cualquier entorno distribuido en que los eventos tengan sentido.

2. La comunicacin por eventos como va para pedir servicios.

Recuerde que un evento no es ms que la notificacin de un cambio de estado. Por
favor, repase (como siempre si no lo recuerda) lo que comentamos sobre eventos
anteriormente.

El modelo de comunicacin que define un evento es, por naturaleza, asncrono
desacoplado. El lugar o el componente que sufre el cambio de estado genera el
evento para que lo recoja quien este escuchando y, en principio, no espera
respuesta.

Nada impide, sin embargo, que el oyente que captura el evento realice su trabajo y
responda con otro evento. Segn el emisor se haya quedado a la espera de la
respuesta o no tendremos implementado un modelo de comunicacin sncrono o
asncrono.

Una forma muy eficiente de implementar el mecanismo para utilizarlo como va para
obtener servicios es que el potencial cliente implemente un semforo.

As pues, con eventos podr realizar una peticin de servicios, en una
comunicacin con un estilo cliente / servidor de peticin respuesta, siguiendo estos
pasos:

1. El cliente genera la peticin del servicio emitiendo un evento con los
parmetros del mensaje. Si el modelo de comunicacin implementado es
desacoplado, ya hemos acabado. Si no, coloca el semforo en rojo. Si el
cliente continua trabajando desear un modelo de comunicacin asncrono y
si espera la respuesta desear comunicarse con el servidor de forma
sncrona.
2. El servidor o una cola recibirn el evento y prestarn su servicio. Cuando
hayan acabo generarn un evento con la respuesta.
3. El cliente recibir el evento, recoger la respuesta de los parmetros y
colocar el semforo en verde.
4. Cuando el cliente lo necesite consultar el semforo y, cuando lo encuentre
verde, continuar.

sta es slo una forma, muy frecuente, de implementar el dilogo pero,
obviamente, pueden pensarse otras. Por ejemplo, implicando una cola que registre
la llegada de peticiones eliminado el semforo y convierta el servicio en multicliente.

Un entorno de eventos exige la presencia de un Gestor de Eventos entre los
diferentes componentes que desarrollan los procesos. Analicemos el
funcionamiento de un gestor de eventos consultando la figura.

El origen de los
eventos puede ser
el sistema o un
componente del
sistema. Cada
componente puede
generar eventos
contra s mismo o
contra otros
componentes. Cada
sistema dispone de
un gestor de
eventos que recoge
tanto sus propios
eventos como los
de sus
componentes. Si
los eventos no
pueden pasarse a otro sistema el gestor de eventos es de bajo nivel; si puede
enviarlos a otros sistemas, el gestor se dice que es de alto nivel.

Veamos ahora que hemos de pedirle a un gestor de eventos para que nos permita
usarlo para implementar una aplicacin distribuida.

O Posibilidad de pasar eventos entre componentes independientes
ejecutndose simultneamente. No se da esta posibilidad cuando Vd. utiliza,
por ejemplo, eventos en una interfcie grfica ya que todas las partes de la
gestin estn integradas en el mismo ejecutable.
O Posibilidad de pasar parmetros entre sistemas.
O Posibilidad de pasar parmetros en el evento. Si no deber hacer trampas
utilizando un rea de uso comn como zona intermedia. Mal asunto a poco
que medite.

Observe que los gestores de eventos convencionales no dan ese servicio. Si lo
dan, y forma parte de su naturaleza, los gestores de eventos de los modelos de
objetos distribuidos y que son gestores de eventos de alto nivel.

EVENTO
Gestor de
bajo nivel
Gestor de
alto nivel
EVENTO
SISTEMA
Captura los eventos de
sistema
Identifica el destinatario .
Los envia al destinatario-
Gestor de
eventos
SISTEMA 1
COMPONENTE
COMPONENTE
SISTEMA 2
COMPONENTE
COMPONENTE

Figura 318. Esquema de funcionamiento de un Gestor de Eventos.
Carga del programa
Entrada de datos
Proceso de datos
Registro de resultados
Seguir?
Salida del programa

Figura 319. Esquema de programacin
secuencial.

Inicio Aplicacin
Captura eventos
Notificacin de
los eventos
Evento
Gestin EVENTO 1
Gestin EVENTO i
Gestin EVENTO n
Gestin eventos
Cola eventos
pendientes
Fin Aplicacin

Figura 320. Esquema de programacin por eventos

No voy a detallarlo, pero consulte las figuras para recordar la diferencia entre la
programacin secuencial y la programacin por eventos.

3. Inclusin de los eventos en los diagramas de flujo.

La metodologa MAFDRA que
hemos utilizado en los
captulos anteriores usa los
diagramas de flujo para
identificar servidores.

La propuesta para introducir
los eventos en los diagramas
de flujo se muestra en la figura
de la izquierda. Observe la
posibilidad que da la notacin
de proteger la llegada de un
evento con un mecanismo ECA
(Evento-Condicin-Accin).

A modo de ejemplo,
desarrollaremos a continuacin
un pequeo ejemplo basado en la implementacin por eventos de control de
conexin con la Central y la compaa area del anlisis de consistencia de la
aplicacin de la agencia de viajes que hemos desarrollado en paralelo con la
metodologa.
Salida
Evento
o
Destino.Evento
Proceso
que lo
genera
Entrada
Mecanismo ECA
Proceso
que
responde
Evento
o
Origen.Evento

Figura 321. Notacin de los eventos en los diagramas
de flujo.

El proceso de
tomar cliente
quedar como
se muestra en
la figura.

Observe que
cuando se
detecta la
cada de un
servicio la
notificacin se
hace lanzando
un evento.
Este montaje
permitira
arrancar a los
vigilantes
dejndolos
permanentem
ente
dormidos hasta que llegada del evento que los despierte.

El refinamiento de verificar conexiones no cambia y ser:

Tiempo de espera
Verificar
Conexin
Central
Verificar
Conexin
C.Area
Sleep
Emergencia_Central
Emergencia Central
Anotar no
conexin
en Central
Emergencia_C_Area
Emergencia C. Area
Anotar no
conexin
en C.Area

Figura 323. Refinamiento verificar conexiones por eventos.

Y, finalmente, el refinamiento de la conexin con la central ser el de la figura
donde la restauracin de la conexin con la central se notifica por un evento.

Cliente local
Tomar
Cliente
R
Acceso a
Clientes en
la Central
Posar no
Conexin
en Central
Time-out
Emergencia_Central
Emergencia Central
Anotar no
Conexin
en Central
Conexin_Central
Emergencia Central
Anotar
Conexin
en Central
Clientes central

Figura 322. Consistencia del proceso de conexin con la central por
eventos.

Estado
Conexin
Central
Comprobar
Conexin
Central
Respuesta
Acceso a
Clientes a
la Central
R
Emergencia Central
Posar
conexin
con Central
Conexin_Central
Anotar
conexin
con Central

Figura 324. Reconstruccin de la conexin con la central por eventos.
Reingeniera de Sistemas.

1. Introduccin al concepto de Reingeniera.

Reingeniera es un trmino muy utilizado (queda muy guai en conferencias y
libros) pero muy ambiguo. Conviene que centremos en primer lugar en que contexto
vamos a utilizarlo.

Es evidente que la informtica no lleg a las organizaciones ayer. La inmensa
mayora de ellas disponen de aplicaciones informticas desde hace mucho tiempo.

Las aplicaciones no pueden seguir el ritmo de avance en las posibilidades que los
sistemas van incorporando da. Tres son las razones bsicas:

O El coste de las aplicaciones en s.
O El tiempo necesario para desarrollarlas.
O El coste organizativo de adaptacin al cambio.

Y, adems, no hay que caer en el error de cambiar por cambiar: si un sistema de
informacin est trabajando perfectamente aunque no utilice tecnologa punta, no
se debe cambiar y hay que dedicar los esfuerzos a otras reas.

Observe que no pasa lo mismo con los avances de hardware: a nadie le amarga
ms velocidad y espacio en disco.

Pero volviendo a las aplicaciones, tambin es evidente que aquellas que son muy
estables tambin deben de evolucionar para dar mejor servicio aprovechando las
nuevas posibilidades de las plataformas.

La Reingeniera de sistemas se encarga de analizar, valorar e implementar esa
evolucin. La evolucin se concreta en:

O Mejorar la utilizacin de las aplicaciones.
O Complementar una aplicacin con nuevas prestaciones.
O Sustituir parte de una aplicacin por mdulos nuevos.
O Evolucionar de una aplicacin antigua a otra nueva de forma progresiva y no
traumtica.
O Sustituir aplicaciones antiguas por otras nuevas sin evolucin y traspasando
slo los datos.

De hecho, el trmino Reingeniera tiene dos niveles:

O Reingeniera de aplicaciones con todos los matices anteriores.
O Reingeniera de sistemas de informacin con la integracin de las
aplicaciones y plataformas antiguas con las nuevas.

De todo ello vamos a tratar en este captulo. Ver que muchos de estos temas ya
los hemos tratado a lo largo del libro. Sin embargo, no est de dems recapitularlos
aqu.

He introducido tambin algunos apartados dedicados a procesos de reingeniera
que son ms presentacin comercial que tcnicas en si mismas. Lo hago para que
Vd. pueda ligar esos trminos comerciales con las tcnicas y estrategias de diseo
distribuido que hemos presentado en nuestro viaje.

2. Los beneficios del efecto 2000 y del EURO.

Nos pasamos cinco aos hablando del terrible efecto 2000. Los artculos, libros y
conferencias sobre el tema fueron un aluvin. Y el histerismo de los medios de
comunicacin en diciembre del 99 ya fue el acabose.

Y lleg el 1 de Enero del 2000 y prcticamente no pas nada. Y nos pasamos
cuatro meses ms oyendo que el problema haba sido exagerado y magnificado. Le
aseguro que muchos de los que haban hablado antes del problema, repitindose
ms que el ajo, se reconvirtieron despus a apstoles que fustigaron a los
catastrofistas: la pela es la pela que decimos en mi tierra. O deberamos decir ya
el euro es el euro.

Pero, dejndonos de broma, analicemos tcnicamente el asunto. El efecto 2000
consista bsicamente en dos puntos:

O Los aos de las fechas se haban codificado con 2 dgitos en lugar de cuatro.
O Existan razonables sospechas de como se iban de comportar las rutinas de
gestin de fechas y periodos con el cambio de siglo y el mes de febrero del
2000 que era bisiesto.

El segundo punto era mucho menos preocupante ya que se trata de un proceso y si
se detecta un error se cambia la rutina y volviendo a distribuir los programas
problema resuelto. Poda acarrear tensiones y problemas pero era fcil de simular,
detectar y resolver.

El cuanto al primero, djeme hacer un comentario previo. Fue muy fcil decir el 1 de
Enero del 2000, a las 12 del medioda: qu malos eran aquellos informticos
histricos del siglo pasado que colocaban solo dos dgitos en los aos!

Yo, que me enorgullezco de ser un informtico actual muy histrico, quiero
defender a aquellos heroicos tcnicos que con poca informacin reglada y pocos
medios montaban aplicaciones que funcionaban (y todava funcionan en algunos
casos) con 4 KB de memoria (si KB), cassettes (si cintas) y ms tarde con
evolucionados ordenadores con floppys de 8 de 256 KB memoria externa.
Recuerde que los primeros PCs de los jvenes aos 80 tenan 256 KB de memoria
y uno o dos floppys de 512 KB. Dos bytes por cada aparicin de un campo tan
frecuente como una fecha era una enormidad. Hoy da con mquinas que ya ni
sabes que disco tienen, memoria por un tubo, capacidad de proceso distribuida
ilimitada y conectividad a tope es muy fcil hablar.

Sin embargo, como siempre ha habido y habr tcnicos malos, en el dficit de
nuestra profesin, si que hay que decir que, increblemente, hubo aplicaciones
diseadas primeros de los 90 que cayeron en el error. El caso extremo que yo
conozco es una aplicacin que diseada en 1998. Pero la mayora de los
profesionales ya atacaron el problema desde finales de los 80 cuando las
plataformas de sistema nos empezaron a liberar de las restricciones de disco y
memoria.

Y finalmente a mediados de los 90 se tom conciencia de que haba un tercer factor
que, como un caballo de Troya, haba permanecido escondido: eran las plataformas
de hardware y sistema las que no pasaban el efecto 2000.

Los problemas de las plataformas y las aplicaciones obligaron a las compaas a
realizar un plan de inversiones para adaptarse. Y como, debido a un efecto muy
positivo de las campaas catastrofistas, las direcciones de las compaas no
discutieron los medios, los informticos pudimos:

O Adaptar y modernizar las plataformas de sistema.
O Hacer Reingeniera o sustituir las aplicaciones dejndolas modernizadas.

Fue como si pasramos los sistemas de informacin por un taller y un tnel de
lavado del que salieron un aire de frescor renovado. No es extrao, pues, que la
llegada del 2000 se redujera solo a una gran fiesta planetaria. No fue por que se
hubiera exagerado el problema sino por el esfuerzo de los profesionales y las
inversiones de las compaas.

Este es el gran logro del efecto 2000, fundamental hasta tal punto que pienso que
la informtica deber levantarle un monumento.

En Europa otro caballo tir tambin del carro, la introduccin del EURO. Sin
embargo, su influencia fue muchsimo menor.

3. La evolucin por escenarios y el flujo de los sistemas de informacin
hacia la integracin.

Es fundamental que antes de seguir vuelva a leer el captulo de la primera parte,
Dos gotas de Reingeniera, en el cual se tratan estos temas. Y, por favor, hgalo
con los ojos de todo lo que ha aprendido en el viaje por el diseo.

Y tenga claro que el flujo de los sistemas de informacin hacia la integracin es
imparable.

4. La migracin de los datos.

En ocasiones el proceso de reingeniera se traduce en la necesidad de una
migracin de datos, proceso nada trivial i que debe ser abordadazo rigurosamente.

En primer lugar hay que valorar la influencia en nuestro entorno de los problemas
clsicos de este proceso de reingeniera:

4. 1. Problemas clsicos.

Inexperiencia interna. Lo normal es que en la empresa no se tenga
experiencia: busque asesores.
Volumen brutal de datos histricos que relantizan los procesos: depure
previamente, pero guarde copia de todo lo que elimina, nunca se sabe.
Desconocimiento del modelo de datos. Lo normal es que quien los mont
ya no est con nosotros. Tiene un problema de narices. Reconstruya el
modelo como paso previo a la migracin.
Llevar tiempo y los procesos del da a da no pueden pararse. Ni la
intente en fro. Planifique la migracin siempre en caliente.
Los plazos se agotan sin acabar el proceso. Lo siento, este es el
problema clsico de cual no le puedo aportar ms ayuda que recordarle que
planifique bien, de forma pesimista y que no admita trabajos intermedios no
previstos inicialmente (cosa que, me temo, no conseguir).
Calidad de los datos. Como usted es un buen tcnico, sus aplicaciones no
lo permitirn, verdad? Pero, si no se fina, depure los datos antes de iniciar
la migracin.

4. 2. Pasos a seguir.

Unificar la plataforma.
Disear el nuevo modelo de datos, que probablemente ser
distribuido.
Gestionar y planificar el proceso de migracin como un proyecto de
ingeniera de software critico.
Disear el proceso de migracin; Etapas: anlisis, planificacin,
extraccin, cambio de formato, transferencia, limpieza, validacin, carga
(estas dos ltimas fases pueden intercambiarse) y pruebas.

5. Maquillaje de aplicaciones existentes.

Ya sabe que en los primeros tiempos de las interfcies grficas hubo intentos para
cambiar las interfcies tradicionales de las aplicaciones HOST por interfcies
grficas sin cambiar el rediseo. Estos intentos, ms o menos automticos, no
llevaron a nada ya que no se ganaba nada ms que esttica.

El verdadero maquillaje se obtiene cortado la presentacin, encapsulado en un
servidor el proceso y desarrollando una componente de presentacin con GUI
nuevo. No hace falta decir que el modelo de diseo a emplear en el modelo de
presentacin desarrollado por tcnicas GUI.

Esta va de Reingeniera se ha visto potenciada con la llegada de Internet que ha
permitido el maquillaje sin necesidad de ir a los puestos cliente, es decir, sin
necesidad de administrar a los clientes. La utilizacin de Mainframe para el Housing
no ha hecho ms que potenciarlo.

Recuerde, finalmente, que para poder hacer maquillaje la aplicacin heredada debe
ser transaccional.

6. Upsizing de sistemas.

Ya hemos hablado mucho del Upsizing de datos que se produce cuando un sistema
aislado se integra en el sistema distribuido.

Como siempre, no voy a repetirme, pero recuerde que no es un tema trivial, y ms
por la integracin de los datos que de los procesos.

Por esa razn, el trabajo ha de ser evaluado, medido y planificado. Muchas veces
necesitar de tcnicas avanzadas para materializar la integracin. O de procesos
radicales de sustitucin total del entorno informtico de la unidad a integrar.

Dentro de este capitulo, hay que incluir la integracin de sistemas de compaas
independientes ya sea por minimizar costes de negocio o para dar servicios. Como
los sistemas a integrar no se conocen entre s, la utilizacin de estndares y de
Internet es aqu fundamental.

El tema del Upsizing de procesos aparecer dentro de este capitulo.

7. El papel de los Mainframe.

Tambin hemos hablada ya de este tema. Las opiniones de que los Mainframe
desapareceran la erraron de todas, todas. La bajada de precios y el aumento
todava mayor de sus prestaciones han vuelto a ensearlos en la lnea operativa de
donde, de hecho, no haban salido nunca.

El HOST se ha convertido en una parte integrada en los sistemas interoperables
montados sobre las plataformas distribuidas. Y en un lugar ideal para colocar el
Housing de las WEBs.

Con todo ello, son contadas las instalaciones que han apagado sus Mainframe o
planean hacerlo.

Las funciones asumidas por los Mainframe dentro del sistema integrado son
principalmente:

O Servidor de bases de datos centralizadas.
O Concentrador / distribuidor, en particular en conexiones con otros HOST de la
misma u otras compaas.
O Lugar de localizacin de recursos y servidores compartidos por funcin, coste
o localizacin obligada. Obviamente, los servicios quedan distribuidos y no
distribuibles.
O Localizacin de aplicaciones tradicionales a las que se accede como siempre
por emulacin de pantallas desde los PCs en un escenario HOST/escritorio.
O Encapsular aplicaciones heredades como servidores de altsimo nivel. Son las
denominas tcnicas de envolvente del HOST.
O Housing / hosting WEB.
O Localizacin de Servicios WEB.
O Servidores de aplicaciones de segunda generacin Internet/intranet.

8. Tcnicas de envolvente del HOST.

Hay un hecho: el cdigo heredado de un HOST es demasiado importante como
para reproducirlo, es gigantesco, complejo y est poco o nada documentado.

Hay una opcin terica: reconstruccin con una base de datos, una interfcie
grfica y una arquitectura distribuida.

Hay una realidad prctica: la opcin terica es cara, peligrosa y se hace difcil de
atacar ya que funciona y vale millones sustituirla.

Y hay, finalmente, una solucin: envolver al Mainframe.

Las tcnicas de envoltura del HOST consisten en rodear al sistema heredado de
una envoltura de software que esconde los problemas del cdigo heredado con
aplicaciones distribuidas C/S sobre sistema operativo o Internet.

Para desarrollar esa envolvente hay varios caminos:

O Utilizar una herramienta que permita acceder directamente al HOST
(COBOL, C++, SMALLTALK, 4GLs,...).
O Atacar va Internet. Est opcin ha sido fundamental que organizaciones que
no haban querido distribuir sus sistemas cuando solo disponan de
soluciones Cliente / servidor ya fuera por costes o, simplemente, por falta de
formacin y cultura para hacerlo. El componente Internet suele ser de
presentacin
O Encapsular el cdigo heredado como un servidor de alto nivel. Aqu el
maquillaje es fundamental. Una solucin muy recurrida es utilizar Servicios
WEB

Las ventajas de las tcnicas de envoltura son inmediatas:

O Permite acceder al HOST, integrarlo en el sistema distribuido global y
utilizarlos en aplicaciones distribuidas eliminado la complejidad del HOST.
O La solucin es relativamente rpida y eficaz.
O Permite, una vez hecha la integracin, la sustitucin paulatina de las partes
obsoletas del HOST sin influencia en el funcionamiento global del sistema
distribuido.

La nica desventaja real es que por debajo todava est la aplicacin antigua con
sus problemas de siempre. Sin embargo, se ha conseguido congelarla y ya sea por
Reingeniera o por nuevo desarrollo, hacerla evolucionar a pesar de esos
problemas.

Los envolventes pueden tipificarse en tres grupos:

O Envolvente de bases de datos. Encapsulacin por servidores de datos.
O Envolvente de servicios.
O Encapsulamiento mediante servidores propios de Mainframe, por
ejemplo, grandes impresoras.
O Gestores de transacciones.
O Correo electrnico.
O Envolvente de aplicaciones, mediante aplicaciones de presentacin.

Y utilizar dos vas:

O Cliente / servidor basado en:
O Sistema operativo.
O Internet.
O Internet / Intranet / Extranet convencional sobre servidores WEB.

La arquitectura de la
envoltura es la que se
muestra en la figura, que se
explica por s sola.

Solo remarcar la aparicin
de las APIs que se han
desarrollado para
implementar la envoltura
encapsulando el HOST.

Las tcnicas de envoltura
de aplicaciones a travs de
un componente de
presentacin presentan la
ventaja de que la aplicacin
heredada no sufre cambios.
Como ya he dicho, es muy
fcil de implementar en
aplicaciones transaccionales aprovechando el formato del mensaje de la
transaccin para implementar el mensaje y la respuesta del nuevo componente de
presentacin. El protocolo se implementa en la API.

Se montan con la arquitectura de
tres niveles de la figura.

El BT Server es comn para todo
el sistema heredado. Acepta
transacciones de los niveles
distribuidos y las descompone en
los elementos especficos de cada
aplicacin heredada.

Permite paralelismo. Contiene la
lgica de la aplicacin para
gestionar condiciones de error,
puntos de decisin, reglas de
negocio, etc.

La capa de LT Server convierte la
transaccin de componentes a un flujo de caracteres 3270, 5250, VT 100, etc.
emulando la sesin de usuario final de un terminal no inteligente, es decir,
implementando el protocolo de la transaccin.

Comporta diferentes problemas tcnicos:

O Debe conectarse al sistema heredado y mantener la conexin por tiempo
indefinido.
Nuevo Sistema Distribuido
Envoltura de aplicacin
APIs
Envoltura de datos
APIs
Aplicacin heredada
Envoltura de servicios
APIs
AS/400
Base de Datos

Figura 325. Arquitectura de Envolvente.
Lgica de presentacin
LT Server
BT Server
Aplicacin heredada
Base de Datos
LT Server
Aplicacin heredada

Figura 326. Envolvente de presentacin de tres
niveles
O Debe establecer el modo de emulacin del terminal.
O La interaccin del LT Server con el sistema heredado puede dar diferentes
errores y / o excepciones. El BT Server debe reconocerlos y resolverlos.
O Ha de gestionar los fallos del servidor (en que se ha convertido el sistema
heredado) o del transportista y resolverlos.

9. Downsizing.

Downsizing de la tcnica de pasar las aplicaciones HOST a mquinas ms
pequeas eliminado la parte no rentable de los sistemas de informacin.

En los sistemas HOST se comprob que una parte importante de los recursos, y
por tanto de los costes, de utilizaba para obtener una informacin con poco valor
aadido. Si eliminamos esa parte abaratamos los costes informticos sin prdidas
importantes de prestaciones prcticas. En esta tesitura, el sistema de informacin
puede montarse sobre plataformas ms pequeas y por tanto de menos coste tanto
de inversin como, y fundamentalmente, de explotacin.

La razn principal del Downsizing no es hoy bajar costes sino mejorar los sistemas
informticos y conseguir una mayor adaptabilidad a los cambios tcnicos y
organizativos.

Y adems, y segn el tipo de negocio y la situacin inicial, al final tambin puede
conseguirse un ahorro de costes.

Un Downsizing ha de ser un proceso gradual que siga reglas bsicas:

O Realizar un entrenamiento con una parte pequea del sistema, que no sea
estratgica, para rodar a las personas, las herramientas y la metodologa.
O Planificacin: comenzar el proceso de migracin por las aplicaciones
generadoras de beneficios (ventas, marketing, etc.). Aquellas que dan soporte
a la operativa interna de la empresa se ha de dejar para el final (contabilidad,
recursos humanos, etc.). La migracin de los procesos Batch difcilmente
aportan beneficios. Obviamente la prioridad deber cambiarse si la situacin
en las aplicaciones internas est deteriorada.
O Decidir la integracin de la informacin de anlisis y de investigacin en un
almacn de datos. Esto le permitir integrar de forma cmoda la informacin
histrica de las aplicaciones que dejar atrs con la nueva.
O Ya puede realizar la sustitucin de las aplicaciones internas generadoras de
beneficio por el nuevo sistema. Para estas aplicaciones debe primarse el uso
de paquetes, personalizaciones y aplicaciones perifricas. Repase aqu lo que
hablamos en la primera parte sobre ERPs.
O Concentrarse en los procesos de negocio, no en los datos.


Djeme, finalmente, hacer algunas reflexiones sobre un proceso de Downsizing.

1. No lo inicie si no es necesario para su negocio, y aun as, est muy
convencido antes de iniciarlo.
2. Redacte un plan estratgico de la arquitectura distribuida que desea e incluya
el plan de migracin.
3. No haga cambios masivos e intente seguir bastante rigurosamente el
esquema propuesto arriba.
4. No confe en conseguir grandes ahorros, busque mejorar sus procesos y
adaptabilidad a los cambios.
5. Intente que el plazo de cada etapa no sea muy largo y que el proceso avance
de forma gradual.
6. No empiece hasta que no est preparado evitando que en el arranque y los
primeros meses de funcionamiento hayan muchos problemas que
desprestigien el proceso y den pie a los detractores que siempre existirn ya
que las personas tenemos la inercia de oponernos a cambiar las cosas que
llevamos haciendo mucho tiempo y, que por tanto, dominamos.
7. Tenga en cuenta que el proceso total puede durar ms de dos aos por lo que
deber estar atento a los cambios tecnolgicos de forma que al final del
proceso consiga el sistema ms actual posible.
8. Tenga en cuenta que el renacimiento de los Mainframe y e Internet como
herramienta de aplicaciones perifricas puede desaconsejar Downsizing, en
principio, muy claros.

10. EAI: Integracin de aplicaciones corporativas.

Es frecuente que en una compaa existan diferentes aplicaciones conviviendo en
reas de trabajo diferentes y que en cada una la aplicacin este resolviendo
satisfactoriamente su funcin no habiendo necesidad de cambiarlas.

Trainnig con una
aplicacin pequea
y no crtica
Host
Planificacin
Trasladar los
sistemas de toma
de decisin a un
almacn de datos
Arrancar las aplicaciones
generadoras de beneficio
con paquetes y
aplicaciones perifricas
Traspasar el resto de
aplicaciones
Desconectar
la aplicacin
del
Mainframe
Sistema
Distribuido

Figura 327. El camino del Downsizing.
Y que como parte de la evolucin normal del sistema de informacin haya llegado el
momento de integrarlas, tanto por procesos de negocio internos como externos.
Acaba de aparecer la necesidad de iniciar un proceso EAI, trmino ingls de la
integracin de aplicaciones corporativas. O dicho en otras palabras, nuestro
conocido Upsizing aplicado a datos y procesos de negocio.

Aparecen todos los problemas que ya hemos hablado ampliamente dentro de
Upsizing, en particular las heterogeneidades sintcticas y semnticas.

EAI engloba el conjunto de tcnicas que permiten el acceso sin restriccin pero con
autentificacin a los datos y procesos de negocio de cualquier aplicacin y/o fuente
de datos de la compaa.

El concepto puede extenderse, obviamente, a la integracin con clientes,
proveedores y terceros con un matiz no tcnico sino poltico: la necesidad de
negociar y pactar.

El concepto es extensible a dos conceptos ms:

O La integracin de empresas fusionadas.
O La necesidad de ofrecer servicios corporativos operativos en la actualidad al
exterior.

En el lenguaje comn de EAI, cada sistema constituye un nodo o isla de
informacin.

El sistema convencional tradicional ha sido:

O Integrar por intercambio de interfases.
O Integrar punto a punto estableciendo un conducto especializado entre cada
nodo. Aqu la integracin de datos se ha conseguido de vara formas:
O Replicacin uni o bidireccional segn se decida que la fuente de
mantenimiento sea compartida o unificada. La sincronizacin de la
replicacin puede ser:
Sncrona, en el concepto de replicacin: tan rpido como se
pueda.
Asncrona con calendarios pactados.
O Integrar los datos en un modelo nico y adaptar las aplicaciones de
origen. Es decir un Upsizing de datos.

Con las herramientas de integracin de plataformas apareci la posibilidad de
integrar de forma transparente los sistemas a travs de Middleware que algunos
llaman businessware. Qu mana de inventar trminos nuevos para otros ya
existentes que tenemos!

Las funciones bsicas que necesitamos de este Middleware son:

O Transparencia de acceso a los datos.
O Mecanismos de sincronizacin de los datos del modelo de datos distribuido
resultante.
O Un mecanismo de intercambio de eventos en el concepto general del tema:
cosas que pasan en un entorno y que se han de notificar a otros.
O Integracin de las plataformas de intercambio de mensajes.
O Posibilidad de intercambiar servicios.
O Disponer de una herramienta de generacin de informes integrados.

Para resolver todas estas necesidades puede utilizar cualquiera de las tcnicas que
ha aprendido, eso espero, en este libro.

As:

O Los mecanismos de publicacin / suscripcin pueden resolver perfectamente
la sincronizacin de datos e el intercambio de eventos
O La realizacin de servidores de distribucin es ideal para integrar servicios
internos.
O Las tcnicas de envolvente le pueden resultar muy tiles si necesita hacen
publicas funciones en aplicaciones heredadas de Mainframe.
O Los procesos de Workflow pueden ser la clave para integrar nuevos procesos
de negocio que integren varias aplicaciones.
O Los Servicios WEB son un procedimiento estupendo para intercambiar con
terceros.
O La utilizacin de XML, por su estructura y posibilidades que se han visto
ampliamente en este libro, es una necesidad.
O La tcnicas de Donwsizing o sustituir parte de los sistemas antiguos por un
ERP suelen incluirse como de EAI. Yo particularmente pienso que no lo son.
Aunque es una opinin particular.

Cuando la tcnica utilizada es de Servicios WEB se suelen marcar los siguientes
pasos:

O Experimentacin con Servicios WEB en la plataforma y en la organizacin.
O Recubrimiento de las aplicaciones actuales con Servicios WEB. El uso se deja
a la iniciativa de los propios usuarios.
O Integracin de todo el sistema.

10. 1. Etapas.

En la figura
siguiente se
muestra un
esquema de las
etapas necesarias
para un proceso
EAI.

10.1.1. Definici
n clara de los objetivos que motivan la necesidad.

Definicin e
identificacin
de objetivos
Integracin de Datos
Definicin del Metaesquema
Diseo:
Replicacin.
Sincrona.
Asincrona.
Servicios.
Identificacin, diseo y
publicacin de servicios
de proceso
Implementacin de los
procesos de negocio
motivadores
Revisin del resto de
procesos internos
Integracin de
procesos de
negocio con
terceros

Figura 328. Etapas de un proceso EAI.
Es muy importante hacerlo para no embarcarse en aventuras sin meta
clara. Recuerde valorar tanto las motivaciones internas como las
externas.

10.1.2. Integracin de datos.

Por estrategias de Upsizing, resolviendo las heterogeneidades
sintcticas y semnticas con un metaesquema. Necesitara tambin la
publicacin como servicios de datos desde las fuentes originales de
todo lo necesario para consulta y/o mantenimiento. Hgalo as, no
acceda nunca directamente a los gestores originales.

Recuerde que dispone de dos modelos de gestin:

Replicacin.
Sncrona
Asncrona.
Servicios, actuando sobre las fuentes originales, tcnica que hemos
dicho antes que se conoce como replicacin virtual.

10.1.3. Identificacin, diseo y publicacin de los servicios de proceso.

Obviamente, desde las aplicaciones originales. Escoja un sistema
estndar, como puede ser Servicios WEB, aunque en principio no
necesite interactuar con el exterior: quedar preparado para el futuro.

10.1.4. Implementacin de los procesos de negocio involucrados.

Es decir, los que han motivado el proceso de EAI.

10.1.5. Revisin de los procesos de negocio internos.

En funcin de las nuevas funcionalidades seguro que puede conseguir
un gran retorno de inversin rediseando la mayora de los procesos de
negocio de su empresa.

10.1.6. Integracin de procesos externos con terceros.

En este punto habr de pactar con sus clientes, proveedores o
colaboradores.

Finalmente, permtame que no incluya aqu ningn esquema de arquitectura de un
sistema EAI: escoja entre todos los que hemos visto, la parte de la solucin que
decida para cada tema.

11. La consolidacin de recursos de plataforma.

El aumento espectacular de la banda de comunicaciones permite la consolidacin
de los recursos de la compaa, especialmente los mquinas ervidoras,
eliminando niveles fsicos en primer lugar y lgicos como segundo paso.

La idea es simple: aprovechando la mejora de las comunicaciones, concentrar los
servidores y simplificar las aplicaciones eliminado costes de administracin y
mejorando la coherencia e integridad del sistema.

Observemos que la aplicacin continua siendo distribuida aunque seguramente
ms simple de arquitectura.

La consolidacin de servidores tiene diversas ventajas claras:

O Control del crecimiento de la granja de servidores y optimizacin del
crecimiento evitando la presencia de mquinas pequeas o infrautilizadas.
O Posibilidad de trabajar con clusters y recursos afines para garantizar al
mximo del tiempo de servicios.
O Optimizacin de la inversin.
O Centralizacin de la gestin en unos pocos servidores fsicos que conlleva:
O Optimizacin de los recursos humanos, menos, ms formados y mejor
pagados.
O Posibilidad de establecer procesos metodolgicos y automatizados.
O Reduccin de los elementos de la infraestructura a administrar.
O Reduccin del tiempo de respuesta ante problemas y mejora conjunta
del nivel de servicio.
O Reduccin del nmero de licencias.
O Reduccin del nmero de servidores de programas.
O Mayor estabilidad.
O Facilidad para controlar la seguridad de acceso.
O Mejor control de software daino.
O Facilidad para mantener las versiones del software de la plataforma
actualizadas.
O Facilidad de Back-up con posibilidad de tener mejores dispositivos de
copia.
O Mayor coherencia del sistema y las aplicaciones.
O Control de crecimiento.
O Mayor facilidad en la renovacin, simplificando y agilizando, en tiempo y
dinero, el proceso.
O Mejora de la oferta, proporcionado mayor capacidad de proceso y de
almacenamiento de datos.
O Liberacin de espacio, ventaja indirecta nada desdeable.

Solo con consultar esta lista es fcil reparar en que los beneficios econmicos,
directos por ahorro y optimizacin, e indirectos, por mejora del nivell de servicio,
son inmediatos.

La realizacin de un plan de consolidacin pasa por tres fases:

11. 1. Preparacin.

Debe analizarse la situacin actual y realizar la propuesta.

Las etapas a seguir son:

Inventario de los recursos actuales.
Redefinicin de comunicaciones y servidores con la propuesta de ancho
de banda necesaria.
Replanteamiento de los servicios de back-up de datos y procesos.
Redefinicin de los procesos de administracin afectados.

El resultado final es el plan de migracin.

11. 2. Desarrollo.

Las etapas a cubrir son:

Consolidacin de comunicaciones.
Concentracin de servidores fsicos e implementacin de las nuevas
maquinas previstas. Note que al final de un proceso de concentracin
puede resultar que hay ms niveles lgicos que fsicos.
Poner en marcha la nueva poltica de administracin.

11. 3. Mejora.

Que consiste en estudiar, especificar, disear, implementar y poner en marcha
los procesos para simplificar y mejorar el sistema distribuido aprovechando las
nuevas mejoras de la plataforma y su menor nivel de dispersin.

No hace falta decir que esto es ni ms ni menos que un proyecto de diseo
distribuido.

12. Reingeniera de procesos de negocio.

Hablar de este tema a estas alturas, en que hemos tratado a fondo y desde
mltiples puntosa de vista la integracin de sistemas, ya no aporta nada nuevo.

Pero si que es bueno resaltar que la reingeniera de procesos de negocio, conocida
como BPF en este mundo delirante de siglas que es nuestro entorno, es una
tcnica de reingeniera (permtame repetir la palabra) de amplas posibilidades y
que hay que potenciar ya que puede afectar tanto al mbito externo como al interno
mejorando los costes de explotacin y potenciando y mejorando la gestin.

Por esa razn voy a reproducir los criterios de Garther Grup sobre este tema.
Segn esta consultora, hay seis factores indispensables para alcanzar esta fusin.

1. Conocimiento y documentacin de los procesos de negocio a integrar.
2. Arquitectura orientada a servicios en las aplicaciones.
3. Utilizacin de XML.
4. Estndares de definicin de las entidades compartidas: facturas, albaranes,
productos, servicios bancarios y un amplio etc. tan largo como quiera.
5. Integracin basada en el modelo portal.
6. Sistemas de almacenamiento de datos compartidos.

Le suena? Llevo un montn de pginas hablando de ello por lo que me parece
innecesario aadir nada ms. Me repetira.

Observe, finalmente los pre-requisitos que se necesitaran:

O Integracin de infraestructura de la plataforma.
O Mecanismo de integracin de aplicaciones.
O Mecanismos de integracin de datos.

Vamos, volver a inventar el Middleware

INDICE DE LA SEGUNDA PARTE

Presentacin 3
Condicionamientos de organizacin. 4
1. Introduccin. 4
2. Los estndares de la plataforma. 4
3. El estndar ofimtico 4
4. La unificacin de la ofimtica. 5
4. 1. Ser un trabajo impopular. 5
4. 2. Ser un trabajo largo y pesado. 6
5. La dispersin de formatos y contenidos. 7
5. 1. Imposicin o libertad. 7
6. Unidad de versin. 7
7. Necesidad de Multidioma. 8
8. La codificacin histrica heredada. 8
9. Otros condicionamientos de datos. 9
9. 1. Las obligaciones de la empresa respecto a la Ley de proteccin de datos. 9
9. 2. Necesidad de registro. 9
10. El factor humano. 10
10. 1. El estado anmico de la organizacin. 10
10. 2. El nivel de los usuarios. 10
10. 3. La resistencia al cambio. 10
11. Una reflexin final. 10
Componentes Operacionales 11
1. Qu es un componente operacional? 11
2. Porqu usar componentes operacionales? 11
2. 1. Tipificar comportamiento. 11
2. 2. Unificar criterios de diseo y administracin. 11
2. 3. Bajar costes de desarrollo. 11
2. 4. Estn probados. 11
3. Limites. 11
4. Una clasificacin. 12
5. Componentes operacionales ms importantes en el diseo. 12
6. Tecnologa de implementacin de Componentes Operacionales. 13
7. Modelos de integracin de componentes operacionales de primer nivel. 13
7. 1. Esttica. 13
7. 2. Dinmica. 13
8. Semforos. 14
8. 1. Qu es un semforo. 14
8. 2. Uso de los semforos 14
8. 3. Servicios habituales. 14
8. 4. Semforos con etiqueta. 15
9. Ticket. 15
9. 1. Qu es un Ticket? 15
9. 2. Un nombre desafortunado? 16
9. 3. Uso de los tickets. 16
9.3.1. Conocer es estado de cada proceso. 16
9.3.2. Coordinar lgica de ejecucin de procesos. 16
9.3.3. Asegurar coherencia y garantizar integridad. 16
9. 4. Elementos fundamentales de un ticket. 16
9. 5. Servicios habituales. 17
9.5.1. Estructurales. 17
9.5.2. De gestin. 17
10. Tickets multihoja. 17
10. 1. Qu es un ticket multihoja? 18
10. 2. Organizacin de un ticket multihoja. 18
10. 3. Mtodos adicionales para tratar los tickets multihoja. 18
10.3.2. Gestin. 18
11. Colas. 18
11. 1. Qu es una cola? 18
11. 2. Utilidad de las colas. 18
11. 3. Utilizar colas de Middleware o crear colas propias? 19
11. 4. Estructura bsica de una cola. 19
11. 5. Atributos bsicos de una cola. 20
11.5.1. Referencia de la anotacin. 20
11.5.2. Destino (servicio). 20
11.5.3. Servidor o agente que la atiende. 20
11.5.4. Origen (cliente). 20
11.5.5. Referencia del cliente. 20
11.5.6. Referencia del servidor o agente. 20
11.5.7. Fechas y horas. 21
11.5.8. Prioridad. 21
11.5.9. Estado. 21
11.5.10. Calificador. 21
11.5.11. Caducidad y forma de eliminacin de la anotacin. 21
11.5.12. Longitud del mensaje. 22
11. 6. Dinmica de las referencias. 22
11. 7. Recomendaciones de implementacin. 22
11. 8. Formas de implementacin: persistencia y organizacin interna. 23
11. 9. Implementacin parcial sobre memoria. 23
11. 10. Mtodos del comportamiento bsico. 24
11.10.2. De gestin. 24
11.10.3. Tratamiento de la persistencia. 24
11. 11. Colas multihilo: multicliente y multiservidor. 25
12. Las colas como servidores. 25
13. Servidores de Impresin. 29
Componentes Operacionales implementados por Agentes 29
1. El Viga y el Disparador. 29
2. Qu es un Servidor de Correo? 30
3. Caractersticas bsicas de un servidor de correo. 31
4. Arquitectura del servidor de correo. 31
5. Operativa bsica de un servidor de correo. 32
5. 1. Envo. 33
5. 2. Recepcin. 33
5. 3. Captura. 34
6. Posibilidades de parametrizacin. 34
7. Posibilidades de administracin. 34
8. Caractersticas del transporte. 35
9. El Servidor de Notas y Avisos. 35
10. El cartero. 36
11. Gestin de errores en un servidor de correo. 37
11. 1. Recuperacin de errores. 37
11. 2. Facilidad de localizacin y seguimiento. 38
11.2.1. Loging de errores. 38
11.2.2. Control centralizado de errores. 38
11.2.3. Jerarqua de errores. 39
11.2.4. Mdulo de seguimiento y anlisis. 39
12. Otras posibilidades. 39
13. Semntica de comportamiento. 40
14. Modos de trabajo habituales de un servidor de correo. 40
14. 1. Push. 40
14. 2. Recogida. 41
14. 3. Notificacin. 41
14. 4. Oportunista. 41
15. Implementacin. 42
15. 1. Programacin propia. 42
15.1.1. Aprovechar una plataforma de objetos distribuidos. 42
15.1.2. La plataforma TCP/IP + SOAP. 42
15.1.3. Basarse en los mdulos de gestin de mensajes del Middleware. 42
15.1.4. Aprovechar el mail. 42
15. 2. Aprovechar paquetes fabricados por terceros. 43
16. Como y cuando utilizar el servidor de correo. 43
La Comunicacin entre el Cliente y el Servidor. 44
1. Introduccin. 44
2. Caractersticas de la comunicacin. 44
2. 1. Cooperativa. 44
2. 2. Transaccional. 44
2. 3. No necesariamente sincronizada. 44
3. Tipos de comunicacin. 44
3. 1. Comunicacin sncrona. 44
3. 2. Comunicacin asncrona. 45
3. 3. Comunicacin por eventos. 47
4. Las diferentes vas de comunicacin 47
5. El modelo conversacional. 47
6. Colas. 49
6. 1. Comunicacin sin respuesta o desacoplada. 49
6. 2. Comunicacin con respuesta directa. 50
6. 3. Comunicacin con respuesta por cola. 51
6. 4. Arquitectura de colas multicliente y multiservidor. 51
6. 5. Representacin de la comunicacin con servidores de cola. 51
7. Peticin de servicio al Middleware. 51
7. 1. OLE y ACTIVE X 52
7. 2. ODBC. 52
7. 3. ADO. 53
7. 4. ODBC o ADO. Servidores de Bases de Datos. 55
7. 5. Servidores de SQL. 55
7. 6. Procedimiento catalogado. 55
7. 7. Vas de acceso a Internet. 55
8. Remote Procedure Call (RPC). 56
9. Comparacin entre colas (MOM) y RPC. 58
10. Simple Object Access Protocol (SOAP). 59
11. Modelos de objetos distribuidos. 59
12. La comunicacin por eventos. 59
13. Mecanismo ECA. 60
14. Comunicaciones remotas. 61
15. Comunicaciones inalmbricas. 61
16. Un ejemplo de utilizacin. 62
XML 64
1. Introduccin. 64
2. Introduccin al XML. 64
3. Componentes de un documento XML. 65
3. 1. Marcas. 65
3. 2. Elementos. 65
3. 3. Atributos. 66
3. 4. Comentarios. 66
4. Creacin de lenguajes. 66
5. Utilidad de XML 66
6. Utilizacin de XML para interfaces. 67
7. Ficheros de configuracin y administracin. 67
8. El binomio XML + SQL. 68
9. Internet y XML. 68
10. XML y conexiones con terceros. 68
11. XML e integracin de sistemas. 69
12. XML y Workflow. 69
Arquitectura de la comunicacin en un sistema distribuido. 70
1. Dilogo y complejidad de un sistema distribuido. 70
2. Organizacin cuasi-jerrquica de dilogo. 70
3. El problema de la congestin. 71
4. El estilo Pull de comunicaciones. 72
5. Push y Pull en Internet. 73
6. El dilogo entre clientes. 73
Programacin de Aplicaciones Distribuidas. Metodologa Puzzle 75
1. Introduccin. 75
2. Internet y piezas/componentes de software. 75
3. Influencia del paradigma y las tcnicas en Cliente/Servidor basado en Sistema Operativo o
Internet. 76
4. Implementacin por programacin de piezas. 76
5. Piezas y Clusters. 76
6. Piezas y Middleware comprado. 77
7. Piezas y Middleware de mundo del software libre. 77
8. La metodologa Puzzle. 77
9. Tcnicas para construir piezas. 78
10. El contrato de comportamiento de una pieza. 78
11. Cuatro ideas sobre especificacin de piezas. 79
11. 1. Lenguajes de especificacin. 79
11.1.1. Mtodos de anlisis. 79
11.1.2. Mtodos formales. 79
11.1.3. Mtodos de texto libre. 79
11.1.4. Mtodos semiformales. 80
11. 2. Partes de la especificacin de una pieza. 80
11.2.1. Global. 80
11.2.2. Los servicios. 81
11.2.3. El formato de cabecera de una rutina como mtodo de especificacin de un servicio. 81
11.2.4. Especificacin del comportamiento de los errores. 82
11.2.5. Especificacin de eventos y triggers. 83
12. Implementacin de la pieza y paradigma de programacin. 83
12. 1. Programacin estructurada. 83
12. 2. Programacin orientada a objetos y tipos abstractos de datos. 84
13. Implementacin de Invariantes. 84
14. Integracin de las piezas. 85
15. Certificacin de una pieza. 85
15. 1. Necesidad de certificar. 85
15. 2. Metodologa de certificacin. 85
15. 3. Certificacin y verificacin analtica. 86
15. 4. Comentario final. 86
Gestin y Reusabilidad de Piezas y Componentes. 87
1. Introduccin. 87
2. Construccin de componentes. 87
2. 1. Cualidades que debe cumplir un buen componente. 87
2. 2. Componentes arquitectnicos (Framework). 87
2. 3. Reusabilidad y costes de proyecto. 88
2. 4. Documentacin. 88
3. Gestin de componentes (Component Management). 89
3. 1. Actividades ligadas con el desarrollo. 89
3. 2. Actividades de administracin. 89
4. El Comit de Componentes. 90
5. La gestin de componentes desde el proyecto. 91
6. El ciclo de vida de un componente. 92
Distribucin del peso de la aplicacin entre clientes y servidores. 94
1. Introduccin. 94
2. Distribucin del peso de la aplicacin. 94
3. Fat Clients. 94
4. Fat Server. 95
5. Fat Client o Fat Server? 95
Diseo y Programacin de Clientes. 97
1. El cliente y sus atributos bsicos. 97
2. Diseo del Cliente. 97
3. Las lgicas en el diseo del cliente. 98
3. 1. Lgica de Presentacin. 98
3. 2. Lgica de Datos. 98
3. 3. Lgica de proceso. 98
3. 4. Lgica de Control. 98
3. 5. Lgica de negocio. 98
4. Metodologas para disear la arquitectura del cliente. 100
4. 1. Basado en la lgica de presentacin 100
4. 2. Basado en la lgica de proceso o de control. 100
4. 3. Basado en la lgica de datos. 101
5. Diseo de la lgica de presentacin. 101
5. 1. Tcnicas GUI (Grafic User Interface). 101
5. 2. Tcnicas OOUI (Object Oriented User Interface). 102
6. Clientes Background y Agentes. 102
7. Que necesita el programa cliente del Netware Operating System (NOS). 104
8. Transportabilidad y transparencia del cliente. 104
9. Herramientas de desarrollo para la parte cliente. 104
9. 1. Herramientas profesionales. 104
9.1.1. Herramientas de desarrollo rpido (RDA). 105
9.1.2. Herramientas de desarrollo avanzado 105
9.1.3. Entornos integrados 4GL orientados a objetos y cliente / servidor. 105
9.1.4. Monitores de transacciones 105
9.1.5. Herramientas de desarrollo en Internet. 105
9. 2. Herramientas de usuario final. 105
9.2.1. Hojas de clculo y otros recursos de los paquetes de ofimtica. 105
9.2.2. Bases de datos tipo Access. 105
9.2.3. Lenguajes de usuario ligados a los 4GL. 105
Diseo y Programacin de Servidores. 107
1. El servidor y sus atributos bsicos. 107
2. Fundamentos del diseo de servidores. 107
2. 1. Fundamentos del diseo de servidores. 107
2. 2. Condicionamientos de diseo. 108
3. Las lgicas y el diseo de servidores. 108
4. Multiservidores y paralelismo. 108
5. Qu necesita el servidor del NOS + DSM? 109
6. Implementacin y programacin de servidores. 109
6. 1. Programacin. 109
6. 2. La cara del servidor. 110
6. 3. La ficha de enviroment del servidor. 110
6. 4. Como conseguir independencia del sistema. 111
Arquitectura de Servidores/Servicios. 113
1. Introduccin. 113
2. Multiserver Data Flow. 113
2. 1. Modelo dirigido por el cliente. 114
2. 2. Modelo dirigido por los servidores (interservidores). 114
3. Concepto de Arquitectura de Servidores. 114
4. Delegacin de Servicio o Orquestacin 115
5. Arquitecturas con mensaje anexo. 117
6. Traspaso de Responsabilidad. 118
7. Redireccin. 119
8. Servidores Interceptores. 120
9. Servidores Pasarela. 120
10. Broadcast Data Flows. 122
11. Arquitectura de Filtro (Filtered Data Flows). 122
12. Servidores Master-Slave. 123
13. Servidores de Distribucin. 125
14. Arquitectura de Pre-Condicin. 126
15. Arquitectura de configuracin. 127
16. Arquitectura de Representante o Proxy. 130
16. 1. Mejorar el rendimiento. 130
16. 2. Poliformar la fuente del servicio. 131
16. 3. Incluir consistencia. 131
17. La estructura del mensaje. 131
18. Arquitectura completa del ejemplo del capitulo anterior. 132
Arquitectura Orientada a Servicios - SOA 133
1. Los servicios como base del diseo distribuido. 133
2. Concepto de servicio. 133
3. Principios del diseo de servicio. 134
3. 1. Abstraccin. 134
3. 2. Generalizacin. 135
3. 3. Seguimiento de estndares. 135
3. 4. Granularidad. 135
3.4.1. Ventajas de la granularidad Coarse Graneid. 135
3.4.2. Ventajas de la granularidad Fine Graneid. 135
4. Puntos de articulacin. 136
5. Principios de SOA. 136
6. Arquitectura de SOA. 137
6. 1. Arquitectura de Aplicacin. 137
6. 2. Arquitectura de Servicios. 137
6. 3. Arquitectura de Componentes. 138
7. Ventajas de SOA. 138
8. Los Servicios WEB dentro de SOA. 138
9. Uso de XML en SOA. 139
10. La conclusin final. 139
Diseando Servicios 140
1. Introduccin. 140
2. Especificacin del servicio. 140
2. 1. Racionalizacin del servicio. 140
2. 2. Consolidacin del servicio. 140
2. 3. Agrupacin por dominios o temas. 141
3. Arquitectura entre los servicios. 141
4. Adaptacin a la arquitectura de datos distribuida. 141
5. Servicios para hacer publicas funcionalidades ya existentes (packaging). 142
6. Service routing. 143
6. 1. Utilizar los recursos estndares del Middleware. 143
6. 2. Localizacin en el propio servicio. 143
6. 3. Routers. 144
6.3.1. Servicio de router. 144
6.3.2. Servidor de router de dominio. 144
6.3.3. Servidor de localizacin. 144
Arquitectura Conducida por Eventos (EDA) y Arquitectura en Tiempo
Real. 145
1. Introduccin. 145
2. Arquitectura EDA. 145
3. Metodologa para establecer una Arquitectura EDA. 146
4. Recursos tecnolgicos. 146
Integracin de Clientes y Servidores en el Middleware. 148
1. Introduccin y final. 148
Ingeniera de Software y Proyectos Cliente/Servidor. 149
1. Introduccin. 149
2. Caractersticas de las actividades de IS. 149
2. 1. Disponibilidad de Modelos, Mtodos y Herramientas. 149
2. 2. Utiliza un proceso de fabricacin. 149
2. 3. Controla la Calidad. 150
2. 4. Mejora continua del proceso. 150
2. 5. Ratio Calidad / coste. 150
3. Ingeniera de los Proyectos de Software. 150
4. Gestin de un proyecto de software. 152
4. 1. Concepto de proyecto. 152
4. 2. Direccin de un proyecto de Software. 152
4.2.1. Especificacin. 152
4.2.2. Seguimiento. 152
4.2.3. Certificacin de la calidad. 152
4. 3. Gestin. 152
5. Gestin tcnica del proyecto. 153
6. Paradigmas de la Ingeniera de Software. 154
6. 1. El Ciclo de Vida Clsico. 154
6. 2. El prototipaje. 155
6.2.1. Construccin de una maqueta. 156
6.2.2. Construccin de una parte del sistema. 156
6.2.3. Adaptar un programa existente. 156
6. 3. El modelo en espiral. 156
6. 4. Las tcnicas 4GL. 157
6. 5. La orientacin a objetos. 158
7. Gestin administrativa del proyecto. 159
7. 1. Estimacin. 159
7. 2. Planificacin y agenda. 160
7. 3. Seguimiento, Control y Revisin. 160
7. 4. Puesta en marcha. 161
7. 5. Conclusin de la etapa de desarrollo. 161
8. Anlisis de riesgos. 162
8. 1. Qu se entiende por Anlisis de Riesgos? 162
8. 2. Metodologa. 162
8. 3. Actividades. 162
8.3.1. Identificacin de los riesgos. 162
8.3.2. Clculo del riesgo. 164
8.3.3. Proyeccin. 164
8.3.4. Gestin. 164
Del Anlisis Funcional/Especificacin al inicio del diseo de los Sistemas
Distribuidos 166
1. Posibilidades de utilizacin de servicios. 166
1. 1. Especificacin por servicios. 166
1. 2. Diseo por/con servicios. 166
1. 3. Servicios como agentes externos. 167
2. Introduccin al diseo distribuido. 167
3. Elementos comunes a cualquier metodologa de diseo. 168
3. 1. La descripcin de los datos. 168
3. 2. Descripcin de los procesos de transformacin. 168
3. 3. Secuencia en que se ejecutan los procesos de transformacin. 168
4. Encaje de la etapa de diseo tecnolgico en el ciclo de desarrollo del software. 170
5. Resumen de puntos de partidas segn la metodologa empleada. 170
Elementos funcionales y tecnolgicos para la descripcin de los
procesos en metodologas convencionales 172
1. Introduccin. 172
2. Descripcin de los procesos de transformacin. Diagramas de Flujo. 172
3. Extensin de los diagramas de flujo. 172
3. 1. Iconos. 173
3.1.1. Agente externo. 173
3.1.2. Entidad. 173
3.1.3. Proceso de transformacin. 173
3.1.4. Salida impresa. 173
3.1.5. GUI. 173
3.1.6. Entidad implementa en BD. 173
3.1.7. Servicio. 174
3.1.8. Modelos de comunicacin C/S. 174
3. 2. Secuencializacin. 174
3. 3. Decisiones. 175
3. 4. Enlace entre diagramas. 175
4. Anlisis descendente. 176
4. 1. Introduccin. 176
4. 2. Concepto de accin, parmetro, efecto y estado. 176
4. 3. Especificacin. 176
4. 4. Metodologa de especificacin. 176
4. 5. Descomposicin de procesos. Concepto de primitiva. 176
4.5.1. Sentencias. 177
4.5.2. Rutinas ya programadas. 177
4.5.3. Piezas y / o Objetos. 177
4.5.4. Servicios. 177
4. 6. Metodologa del anlisis descendente. 177
4. 7. Ejemplos. 179
4.7.1. Contar consonantes despus de la aparicin de una vocal en un texto. 179
4.7.2. Pedir un cdigo de cliente y sacarlo por la pantalla 180
4. 8. Porqu utilizar anlisis descendente? 180
5. Diagramas Jerrquicos. 180
Descripcin de los Datos en un Modelo Relacional 182
1. Introduccin. 182
2. Terminologa bsica para la descripcin de los datos. El Modelo de Datos. 182
3. El Modelo Relacional. 183
4. ANSI/SPARC three schema architecture. 184
4. 1. Esquema externo (External Schema). 185
4. 2. Esquema Conceptual (Conceptual Schema). 185
4. 3. Esquema Interno (Internal Esquema). 185
5. Restricciones de integridad. 185
5. 1. Entity Integrity Constraints. 185
5. 2. Validity Check Constraints. 185
5. 3. SQL-92 domains and assertions. 185
5. 4. Referencial Integrity. 186
5. 5. Referencial triggered actions. 186
5. 6. Control de las restricciones de integridad en un sistema distribuido. 186
6. Bases de datos activas y pasivas. 187
7. Triggers. 188
7. 1. Control de Acceso. 188
7. 2. Control de Integridad. 189
7. 3. Soporte de datos. 189
7. 4. Notificacin de cambios y transiciones de la BD. 189
7. 5. Medidas de rendimiento. 189
7. 6. Reglas. 189
7. 7. Gestin de triggers de la BD en entornos distribuidos. 189
8. Vistas. 189
9. ODBC/JDBC y ADO. 190
10. Procedimientos catalogados. 190
Mtodo de Anlisis Funcional para Aplicaciones de Desarrollo Rpido. 191
1. Introduccin. 191
2. Mtodo de Anlisis Funcional de Desarrollo Rpido de Aplicaciones (MAFDRA). 191
2. 1. Diseo de los datos. 191
2. 2. Identificacin de los procesos bsicos. 191
2. 3. Diseo de los procesos. 192
2. 4. Diseo de la lgica de presentacin. 192
2. 5. Organizacin de la explotacin. 192
3. Desarrollo de un ejemplo. 193
3. 1. Reflexin previa. 193
3. 2. Especificacin inicial. 193
3. 3. Diseo de datos. 194
3. 4. Identificacin de los procesos bsicos. 197
3. 5. Diseo del Proceso de Venta de Viajes Areos y Hotel. 197
3. 6. Diseo del Proceso de Estadsticas. 201
3. 7. Diseo de los componentes de presentacin. 201
3. 8. Diseo de los listados. 201
3. 9. Organizacin de la explotacin. 202
Diseo Funcional de Aplicaciones Avanzadas Introduccin a la
Orientacin a Objetos 203
1. Introduccin. 203
2. Conceptos bsicos. 203
2. 1. Introduccin del Concepto OO. 204
2. 2. Terminologa bsica. 204
2. 3. El tringulo orientado a objetos. 205
2.3.1. Encapsulacin. 205
2.3.2. Abstraccin y clasificacin. 205
2.3.3. Polimorfismo a travs de la herencia. 205
2. 4. Clase de Objetos. 205
2. 5. Concepto de Herencia. 207
2. 6. Polimorfismo. 207
2. 7. Visibilidad de atributos y mtodos. 209
2.7.1. Pblico. 209
2.7.2. Privado. 209
2.7.3. Protegido. 209
3. Los fundamentos de una metodologa de diseo OO. 210
4. Etapas de una metodologa de construccin de software OO en UML. 210
4. 1. Especificacin. 210
4. 2. Diseo del sistema. 211
4. 3. Diseo de los objetos. 211
4. 4. Implementacin (Implementation). 211
5. Los tres modelos de la metodologa OO. 212
5. 1. Modelo de Objetos. 212
5. 2. El modelo dinmico. 212
5. 3. El modelo funcional. 213
6. Las relaciones entre los tres modelos. 213
7. Descripcin del modelo de objetos. 213
7. 1. Plantilla de definicin de Clases y Objetos. 213
7. 2. Diagramas de Clases y de Instancias. 214
7. 3. Asociaciones y links. 214
7. 4. Agregaciones. 216
7. 5. Algunos ejemplos de Modelos de Objetos. 217
8. Reflexin final. 218
Implementacin de un modelo de objetos sobre un modelo relacional 219
1. Introduccin. 219
2. Traspaso de esquemas. 219
3. Mapeo de clases. 220
4. Mapeo de asociaciones a tablas. 221
Asociaciones N a N. 221
Asociaciones 1 a N. 222
Asociaciones 1 a 1. 222
5. Agregaciones. 222
6. Herencia para definir especializaciones y generalizaciones. 222
Cada clase y cada subclase se mapea en una tabla diferente. 222
La clase padre y todas subclases se mapean en una nica tabla (todo en una sola tabla). 223
Cada subclase se mapea en una tabla diferente. 223
Diseo de Aplicaciones Avanzadas por UML integrado con la metodologa
de diseo distribuido 224
1. Introduccin. 224
2. Diseo de Sistemas por UML. 224
(a) Especificacin. 224
(b) Diseo Tecnolgico. 225
(c) Documentacin resultante del diseo. 227
(d) Puntos de partida de la etapa de diseo distribuido. 228
3. Diagramas de despliegue. 229
(a) Diagrama de Sistema. 230
(a) Diagrama de la infraestructura. 230
(a) Diagrama de niveles fsicos 231
(b) Diagrama de niveles lgicos. 231
(a) Diagrama de la Arquitectura de Servicios. 232
(a) Diagrama de Localizaciones. 233
4. Fuentes de servicios sobre un diseo UML. 234
(a) Diagramas de clases. 234
(b) Diagramas de actividad. 234
(a) Diagramas de secuencia. 236
(b) Diagramas de colaboracin. 237
(a) Primera versin de la integracin de servicios en clases. 237
5. Vistas de la arquitectura del Software. 238
6. Concepto de Frontera. Fronteras y nodos. 239
7. Otros factores de inters en el diseo UML distribuido. 239
8. Arquitectura de Objetos Distribuidos en la prctica. 240
9. Implementacin de la arquitectura distribuida sobre un modelo OO. 242
10. Un ejemplo. 242
(a) Presentacin y dominio agrupados. 251
(a) Presentacin y dominio separados sin mantener el controlador. 252
(a) Presentacin y dominio separados manteniendo el controlador. 253
Datos y Diseo Distribuido 256
1. Introduccin. 256
2. Criterios generales de partida. 256
3. Centralizar versus distribuir: Resumen de modelos lgicos del datos. 256
3. 1. Datos en servicios en nube. 257
3. 2. Datos centralizados. 257
3. 3. Datos distribuidos. 257
3.3.1. Homogneos. 257
3.3.2. Datos distribuidos heterogneos. 258
4. Esquemas de niveles de datos. 258
5. Por qu definir y usar modelos de datos? 258
6. Arquitectura de datos distribuidos. 259
7. Bases de datos y sistemas distribuidos. 259
8. Arquitectura de los Datos del Sistema Distribuido. 260
9. Upsizing. 260
10. Recordatorio importante. 261
Modelo Centralizado 262
1. Introduccin. 262
2. Modelo centralizado de datos. 262
2. 1. El modelo pequeo. 262
2. 2. Modelo grande. 262
3. Gestin de ms de un esquema fsico. 263
Replicacin 264
1. Una observacin inicial. 264
2. Arquitectura de Datos Replicados. 264
3. Gestin de datos replicados. 265
4. Terminologa de datos replicados. 265
4. 1. Replicacin sncrona o asncrona. 265
4. 2. Tipologa de la forma de transmitir los cambios. 265
4.2.1. Emisin. 265
4.2.2. Cascada. 266
4.2.3. Replicacin bidireccional. 266
4.2.4. Replicacin entre iguales. 266
4. 3. Replica incremental. 266
4. 4. Mecanismos de replicacin. 267
5. Copia principal y foco del mantenimiento. 267
6. Agrupaciones de replicacin. 268
7. Replicacin sncrona. 268
7. 1. Reserva de todas las replicas. 269
7. 2. Modificacin de todas las copias. 269
7.2.1. Mismo nivel en todas las replicas. 269
7.2.2. Admitir diferentes niveles en las copias. 269
7. 3. Confirmacin y liberacin 269
8. Replicacin asncrona. 270
9. La escala copia / replica. 270
9. 1. Replicacin asncrona a peticin. 271
9. 2. Replicacin asncrona planificada. 271
9. 3. Asncrona entre iguales y bidireccional. 271
9. 4. Replicacin sncrona con confirmacin en dos fases. 272
9. 5. Replicacin sncrona inmediata y el caliente. 272
10. Uso de tcnicas Master-Slave en replicacin. 273
11. Full Tolerance y tickets. 273
12. Mecanismos de replicacin. 274
12. 1. Replicacin por protocolo de dos fases. 274
12. 2. Replicacin por extraccin. 274
12. 3. Replicacin por log's. 274
12. 4. Replicacin por mensajes. 275
12. 5. Replicacin por eventos. 275
12. 6. Replicacin por instantneas (snapshots). 275
12. 7. Replicacin por Publicacin / Suscripcin. 275
12. 8. Usar los mecanismos de replicacin de los gestores de la base de datos. 276
13. Utilidad del Viga y del Disparador en gestin de replicas asncronas. 276
14. Replicacin Cach. 276
14. 1. Cach interna al programa. 277
14. 2. Cach compartida. 277
15. Data Warehouse y replicacin. 277
16. Replicacin virtual o Data Warehouse virtual. 277
17. Auditoria de datos replicados. 277
18. Factores a considerar en la poltica de replicacin. 279
18. 1. Localizacin de las copias. 279
18. 2. Situacin de la replicacin en la escala copia-replica. 279
18. 3. Volatilidad. 279
18. 4. Tamao de los datos. 279
18. 5. Tipologa de la forma de transmitir los datos. 279
18. 6. Importancia de las copias y necesidades de fiabilidad. 279
18. 7. Plan de auditoria. 280
18. 8. Disponibilidad. 280
18. 9. Calendario y horario. 280
18. 10. Copiar, Reorganizar o Sumarizar. 280
18. 11. Como es el foco de mantenimiento. 280
18. 12. Desde donde se inicia la replicacin. 280
18. 13. Caducidad de la replica. 280
18. 14. Preguntas de inters. 281
19. Cuestiones de inters tcnico. 281
20. Poltica de replicacin. 281
21. Los gestores de BD como Middleware de replicacin. 281
22. Aplicaciones C/S basadas en sistema operativo trabajando sobre datos replicados versus
aplicaciones Internet. 282
23. Aplicaciones con mantenimiento distribuido de replicas. 282
24. Servidores de programas replicados. 283
Datos Particionados 284
1. Introduccin. 284
2. Modelo particionado de datos. 284
2. 1. Mantenimiento sncrono. 284
2. 2. Mantenimiento asncrono 284
3. Tcnica. 284
3. 1. ndice. 285
3. 2. Regla de negocio. 285
4. Auditoria de datos particionados. 285
Codificacin distribuida 286
1. Introduccin. 286
2. Criterios de asignacin de cdigos. 286
3. Gestin de la codificacin distribuida. 287
3. 1. Verificacin sncrona 287
3. 2. Verificacin asncrona. 287
3. 3. Asignacin dinmica. 288
4. Cambios de cdigo en bloque. 288
Aplicacin del Patrn DTO 289
1. Introduccin. 289
2. Aplicacin del patrn DTO. 289
2. 1. Obtencin de registro o registros. 289
2. 2. Gestin del DTO. 289
2. 3. Modificacin de la base de datos. 289
Servicios de Agrupacin de Entidades de Datos 290
1. Introduccin. 290
2. Precondiciones. 290
3. Sistematizacin de la casustica. 291
3. 1. Visin unificada de una entidad. 291
3. 2. Particin horizontal. 291
3. 3. Escenarios de agregacin. 291
4. El metaesquema. 291
5. Servicio de Agrupacin de Entidades. 293
5. 1. Por servicios. 293
5. 2. Por replicacin. 293
5. 3. Por servicios y replicacin. 295
6. Semntica CRUD (Create-Read-Update-Delete). 295
7. Semntica CRUD en la arquitectura por servicios. 295
8. Semntica CRUD en la arquitectura por replicacin. 296
9. Implementacin utilizando los recursos del motor de la base de datos. 298
Metodologa de Diseo Distribuido 299
1. Introduccin. 299
2. Recordatorio de las Etapas de Diseo. 299
2. 1. Aplicaciones avanzadas. 300
2. 2. Aplicaciones RAD. 300
3. Metodologa Integrada de Diseo. 300
4. Contenido de cada una de las etapas. 301
4. 1. Anlisis Funcional /Especificacin Diseo de la arquitectura del tecnolgico. 301
4. 2. Determinacin de las precondiciones de la plataforma. 302
4.2.1. Identificacin de las fronteras. 302
4.2.2. Determinacin de los puntos de heterogeneidad. 302
4. 3. Diseo de la Arquitectura Distribuida. 302
4.3.1. Anlisis de los datos. 303
4.3.2. Distribucin del Proceso de la Aplicacin. 303
4.3.3. Creacin de la Arquitectura de Servicios. 303
4.3.4. Map to reality. 304
4. 4. Diseo de consistencia. 305
4. 5. Diseo de la administracin del sistema. 305
4. 6. Identificacin y especificacin de piezas. 306
4. 7. Diseo de los Clientes. 307
4. 8. Plan de Integracin. 307
Diseo de la Arquitectura Distribuida de Servicios 309
1. Introduccin. 309
2. Etapas del Diseo de la Arquitectura de servicios del Sistema Distribuido. 309
3. Anlisis de los datos 309
3. 1. Prerrequisitos. 310
3.1.1. Puntos de heterogeneidad. 310
3.1.2. Niveles Lgicos. 311
3.1.3. Factores de gestin y proceso. 311
3.1.4. Tiempos de respuesta admisibles. 311
3.1.5. Codificacin distribuida. 311
3. 2. Diseo de los Datos. 311
3.2.1. Diseo de la Arquitectura de Datos Distribuida. 312
3.2.2. Mantenimiento y auditoria. 312
3.2.3. Adaptar el Diseo Funcional. 312
3.2.4. Diseo de la Lgica de Datos Distribuida. 312
3.2.5. Especificar la Arquitectura y la Lgica de los Datos. 314
3. 3. Analizar el rendimiento (Perfomance). 315
4. Criterios para disear la arquitectura de datos. 316
4. 1. Localizacin Obligada. 316
4. 2. Criterios funcionales. 316
4.2.1. Criterios independientes de la optimizacin del rendimiento a la plataforma. 317
4.2.2. Criterios dependientes de la optimizacin del rendimiento a la plataforma. 318
5. Un interesante dilema sobre la gestin de las restricciones de integridad. 319
6. Distribucin del Proceso de la Aplicacin. 319
6. 1. Identificar Funciones. 320
6. 2. Distribuirlas por Niveles Lgicos. 320
6. 3. Separar funciones entre clientes y servidores. 320
6.3.1. Por la localizacin de las clases y las instancias de los objetos. 321
6.3.2. Por la tipologa de las tareas. 321
6.3.3. Por los datos. 322
6.3.4. Por los recursos. 322
6.3.5. Por la oferta de los servicios. 322
6.3.6. Por los condicionamientos de organizacin. 322
6.3.7. Por la administracin del sistema. 323
6.3.8. Usuarios remotos y nmadas. 323
6. 4. Identificar servicios. 324
6. 5. Un pequeo ejemplo en MAFDRA. 325
7. Creacin de la Arquitectura Distribuida. 328
7. 1. Definir el tipo de comunicacin. 329
7. 2. Definir la arquitectura entre los servicios. 329
7. 3. Documentar la Arquitectura Distribuida. 330
7. 4. Analizar la solucin obtenida. 330
7. 5. Creacin de la Arquitectura Distribuida del ejemplo de venta de productos. 330
7.5.1. Eleccin del Modelo de comunicacin. 331
7.5.2. Arquitectura de servidores. 331
8. Map to Reality. 331
8. 1. Localizacin. 332
8. 2. Configuracin. 332
8. 3. Analizar rendimiento. 332
9. Diseo de la Arquitectura distribuida del ejemplo de la venta de viajes areos y hotel. 333
9. 1. Anlisis de datos. 333
9.1.1. Arquitectura distribuida de los datos. 334
9.1.2. Mantenimiento y auditoria. 335
9.1.3. Adaptacin del diseo. 336
9. 2. Diseo de la Arquitectura Distribuida. 339
9.2.1. Diseo de la lgica de datos distribuida e identificacin de servicios. 339
9.2.2. Eleccin del modelo de comunicacin. 341
9.2.3. Creacin de la Arquitectura Distribuida. 343
9.2.4. Map to Reality. 350
9. 3. El diseo de los Servicios WEB. 350
9. 4. Diagrama jerrquico modificado. 351
Polticas de Administracin de un Sistema Distribuido. 353
1. Introduccin. 353
2. La administracin de sistemas distribuidos. 353
3. reas de actividades en la administracin de un sistema distribuido. 354
4. Organizacin de la administracin. 355
4. 1. El Centro de Direccin del Sistema Distribuido (CDSD). 355
4. 2. El Centro de Administracin del Sistema Distribuido (CASD). 355
4. 3. El Centro de Soporte a usuarios del Sistema Distribuido (CSSD). 356
5. Estrategias de administracin. 356
6. La plataforma estndar. 357
6. 1. Definicin de la plataforma estndar. 357
6. 2. Administracin de la plataforma estndar. 357
6. 3. Organizacin de la administracin del cliente sobre la plataforma estndar. 358
6. 4. Delimitacin de responsabilidades. 358
7. rea de planificacin. 359
8. rea de administracin de datos. 360
8. 1. Definir las polticas de administracin. 361
8. 2. Gestin de la localizacin, planificacin de la capacidad y planificacin de migraciones. 361
8. 3. Gestin de uso. 361
8. 4. Gestin del rendimiento. 361
8. 5. Gestin de la disponibilidad de los datos. 362
8. 6. Gestin de la coherencia, seguridad y el back-up y recuperacin. 362
8. 7. Monitoring de datos. 362
8. 8. Gestin de eventos y alertas de datos. 362
9. Actividades del rea de soporte a usuarios. 362
9. 1. Organizacin operativa del soporte. 363
9. 2. Formas del soporte a usuarios. 364
9.2.1. Hot-Line. 364
9.2.2. Reuniones. 366
9. 3. Facilidades para el soporte a usuarios. 366
9.3.1. Ayudas en lnea. 366
9.3.2. Definicin de procedimientos de actuacin. 366
9.3.3. Estandarizacin de la operativa de los programas. 367
9. 4. Nivel de aceptacin del servicio. 367
10. rea de Inventario y Monitoring. 368
11. Actividades de Monitoring. 368
11. 1. El modelo de Monitoring. 368
11. 2. La actividad de medir. 369
11. 3. Los datos de calidad de servicio. 370
12. Registro del Inventario de activos tecnolgicos. 371
13. La gestin del repositorio de administracin. 371
14. Area de Anlisis de la gestin: Auditoria del Outsourcing 372
15. rea de costes. 373
16. Anlisis de la gestin de errores. 373
17. rea de gestin y control. 373
17. 1. Cuadro de mandos del sistema distribuido. 374
17.1.1. Filosofas de integracin. 375
17.1.2. Cuadro de mandos de explotacin o administracin. 375
17.1.3. Cuadro de mandos de seguimiento del estado del negocio. 377
17. 2. Consola nica 377
18. Caractersticas de las actividades de Administracin de clientes. 378
19. Administracin de servidores. 378
20. Gestin remota y desatendida de clientes y servidores. 378
21. Localizacin de recursos. 379
22. SOA Governance. 380
23. Estrategias de actuacin en la administracin. 380
23. 1. Esperar a que pase el problema. 380
23. 2. Administracin desde el usuario. 380
23. 3. Administracin remota. 381
23. 4. Que le recomiendo. 381
23.4.1. Soporte de la plataforma y distribucin e instalacin del software de aplicacin: 381
23.4.2. Parametrizacin y soporte del software de aplicacin: 381
24. Repercusin del coste. 381
25. Clasificacin de las actividades de administracin por su naturaleza. 381
26. Diseo de la administracin del sistema. 382
27. Que dice la experiencia.... 383
Diseo e Implementacin de Actividades de Administracin de Sistemas.385
1. Introduccin. 385
2. Captura de las direcciones variables de IP. 385
3. Copias de Seguridad (Back-up y Restore). 386
3. 1. Condicionantes. 386
3.1.1. Capacidad de los dispositivos de Back-up. 386
3.1.2. Tiempo necesario para hacer la copia. 386
3.1.3. Dispersin de lgica de informacin. 386
3.1.4. Dispersin geogrfica. 386
3.1.5. Diferencias de calendario y horario. 386
3. 2. Estrategias de copias de seguridad. 387
3.2.1. reas y mbitos de datos. 387
3.2.2. Gestin de cada una de las reas. 387
3.2.3. Responsabilidad de cada mbito. 388
3.2.4. Calendario. 389
3.2.5. Momento. 389
3.2.6. Lugar. 390
3.2.7. Rotacin. 390
3.2.8. Almacn. 390
3.2.9. Tipos de gestin. 390
3. 3. Las herramientas. 391
3. 4. Implementacin de copias automatizadas. 391
3. 5. Algunas estrategias habituales de back-up. 391
3.5.1. Back-up distribuido. 391
3.5.2. Back-up de usuario sobre el entorno departamental. 392
3.5.3. Back-up departamental. 392
3.5.4. Back-up departamental centralizado. 393
3.5.5. No back-up y reconstruccin. 394
4. Consolidacin de datos. 394
5. Administracin de impresoras. 394
5. 1. La impresin en entornos distribuidos. 394
5. 2. Formas de conectar las impresoras. 394
5.2.1. A un servidor dedicado. 395
5.2.2. A una mquina cliente. 395
5.2.3. A un Printer Server. 395
5. 3. Estrategias. 395
5. 4. Organizacin jerrquica de los grupos de impresin. 395
5.4.1. Nivel Usuario. 396
5.4.2. Nivel grupo de usuarios. 396
5.4.3. Nivel Departamental. 397
5.4.4. Nivel Centralizado o Corporativo. 397
5.4.5. Impresin entre ramas. 397
5. 5. Implementacin de las estrategias de administracin de impresoras. 398
6. Administracin de usuarios y derechos. 398
6. 1. Organizacin de usuarios y gestin de los derechos. 399
6. 2. Gestin de directorios con informacin restringida. 400
6. 3. Gestin de los derechos de impresin. 401
6. 4. Implementacin del permetro de seguridad. 401
6.4.1. Permetro de seguridad mltiple. 401
6.4.2. Permetro de seguridad nico. 402
6. 5. Una posible arquitectura de un servicio de identificacin. 402
7. Gestin del software. 403
7. 1. Distribucin y control del software. 403
7.1.1. Localizacin de los programas. 403
7.1.2. Control y distribucin de versiones. 403
7. 2. Distribucin de replicas de ficheros fijos. 404
7. 3. Herramientas disponibles. 404
7.3.1. Utilizar paquetes. 405
7.3.2. Utilizar herramientas de DSM. 405
8. Aportaciones del Diseo de Administracin del Sistema al NOS+DSM. 405
9. Algunas ideas ms. 405
Diseo de Consistencia 406
1. Objetivos del Diseo de Consistencia. 406
2. Por qu y como caen los servidores? 407
3. La consistencia por plataforma redundante. 408
4. Ciclo del Anlisis de Consistencia. 408
5. Gestin de errores en un sistema distribuido. 410
5. 1. Elementos para el anlisis de los errores. 411
5.1.1. Tipos de errores. 411
5.1.2. Destinatario. 412
5.1.3. Nivel de gravedad. 412
6. Anlisis histrico de los errores. 413
7. Implementacin de la gestin de errores. 413
8. Gestin de la concurrencia, el paralelismo y la recuperacin. 415
9. Tipificacin del comportamiento del servidor: semntica de servidores. 416
9. 1. Servidor may be (quizs). 416
9. 2. Servidor at least once (al menos una vez). 416
9. 3. Servidor at most once (como mximo una vez). 417
9. 4. Servidor exactly once (exactamente una vez). 417
9. 5. Implementacin de semntica en servicios montados sobre colas. 417
9.5.1. Atributos de la comunicacin. 418
9.5.2. Anotacin del servicio por el cliente: 418
9.5.3. Comunicacin cola/servidor. 418
9.5.4. Respuesta de la cola al cliente. 418
9. 6. Servidores de datos y comportamiento at most one. 419
9.6.1. Protocolo de dos llamadas. 419
9.6.2. Mecanismo de Call-back (llamada al origen). 420
9.6.3. Mecanismo de Confirmacin por Lectura. 420
9.6.4. Mecanismos de control de la replicacin. 420
9. 7. Arrancadas alternativas. 420
10. Utilizacin de arquitecturas Proxy. 420
11. El problema de los hurfanos. 421
12. Arrancada del servidor desde el cliente. 421
13. Gestin de la situacin de emergencia. 421
13. 1. Componentes de la gestin de la situacin de emergencia. 422
13.1.1. Una agrupacin de trabajo de servidores. 422
13.1.2. Semforo de disponibilidad. 423
13.1.3. El vigilante. 423
13.1.4. Logs para registrar el trabajo en emergencia. 424
13. 2. Ciclo de trabajo en emergencia. 424
14. Anotacin del diseo de consistencia sobre los diagramas de flujo en MAFDRA. 426
15. Metodologa del Anlisis de Consistencia. 426
15. 1. Definir la Semntica de Comportamiento de los Servidores. 427
15.1.1. Definicin y Anlisis. 427
15.1.2. Diseo de la Implementacin. 427
15. 2. Anlisis de los errores. 427
15.2.1. Identificacin. 427
15.2.2. Gestin. 427
15.2.3. Administracin. 427
15. 3. Anlisis de la Situacin de Emergencia. 428
15.3.1. Definir la Poltica General. 428
15.3.2. Negociacin. 428
15.3.3. Anlisis de la Cada en Emergencia. 428
15.3.4. Anlisis del Trabajo en Emergencia. 428
15.3.5. Anlisis de la Vigilancia. 428
15.3.6. Anlisis de la Recuperacin. 428
15. 4. Diseo Tecnolgico. 429
15.4.1. Diseo de los Procesos. 429
15.4.2. Preparar el Plan de Integracin. 429
16. El proceso paralelo como tcnica de consistencia. 429
17. Diseo de Consistencia de la aplicacin de Viajes Areos y Hoteles. 429
17. 1. Semntica de servidores. 429
17.1.1. Leer Datos Cliente. 429
17.1.2. Leer Datos Cliente en la Central. 429
17.1.3. Alta Cliente en la Central. 429
17.1.4. Actualizar Datos de Venta de Clientes en la Central. 430
17.1.5. Actualizacin de Datos de la Compaa area. 430
17.1.6. Consulta de Hoteles. 430
17.1.7. Actualizar Datos de Hoteles. 430
17.1.8. Impresin de la Reserva para el cliente. 430
17.1.9. Servidor de Correo. 430
17.1.10. Servidor de Cola. 431
17. 2. Anlisis de errores. 431
17.2.1. Identificacin. 431
17.2.2. Gestin. 431
17.2.3. Administracin. 431
17. 3. Diseo de la Situacin de Emergencia. 431
17.3.1. Definicin de la poltica general. 431
17.3.2. Anlisis de la cada en emergencia. 433
17.3.3. Anlisis del trabajo en emergencia. 433
17.3.4. Anlisis de la vigilancia. 433
17.3.5. Anlisis de la recuperacin. 433
17. 4. Diseo Tecnolgico. 433
17.4.1. Diseo de los procesos. 433
17.4.2. Preparar el Plan de Integracin. 437
18. Diseo de Administracin de la aplicacin de Viajes Areos. 438
Integracin funcional del Cliente. 439
1. Introduccin. 439
2. La implementacin del cliente. 439
2. 1. Decidir del modelo de Integracin Funcional. 439
2. 2. Crear la lgica de presentacin y/o los flujos de los procesos. 439
2. 3. Crear las lgicas de proceso y de datos del cliente. 440
2. 4. Especificacin de las piezas cliente. 440
2. 5. Modificar y ampliar el cuadro de control del sistema distribuido. 440
2. 6. Disear el cuadro de mandos del negocio. 440
3. Perfiles de usuario e integracin. 441
4. Modelos de Integracin. 441
5. Modelos en los cuales la iniciativa la lleva el usuario con una interfcie convencional. 442
6. Integracin grafica multivista. 443
7. Portal. 443
7. 1. Portales de contenidos. 444
7. 2. Portales de aplicacin. 444
7. 3. Portales de proceso. 444
8. Clientes ligeros. 445
8. 1. Ventajas. 445
8. 2. Inconvenientes. 446
9. Integracin transaccional. 446
10. Integracin basada en Internet. 447
11. Clientes Back-Ground. 448
12. Integracin Batch. 449
12. 1. Control de llegada de toda la informacin necesaria. 450
12. 2. Control de ejecucin. 450
12. 3. Notificacin de resultados 450
12. 4. Formas de montar una arquitectura batch. 450
12.4.1. Ejecucin centralizada. 450
12.4.2. Ejecucin distribuida. 450
13. La integracin por estereotipos o agentes. 451
14. Procesador distribuido. 452
15. Integracin por Workflow. 455
15. 1. Trabajo Cooperativo. 455
15. 2. Workflow de procesos. 455
15. 3. Workflow de datos: Sistema de Gestin de documentos. 456
16. Integracin por publicacin y suscripcin. 456
17. Integracin por objetos distribuidos. 457
18. Los papeles mltiples. 457
19. La integracin basada en sistema operativo desde Internet. 459
Integracin por publicacin y suscripcin. 460
1. Introduccin. 460
2. Qu es integrar por publicacin y suscripcin? 460
3. Caracterizacin del mensaje y la suscripcin. 461
4. Paradigmas. 462
4. 1. Publicacin Broadcast. 462
4. 2. Solicitud y respuesta. 462
4. 3. Solicitud y respuesta Multicast. 462
4. 4. Transaccional. 462
5. Arquitectura de publicacin y suscripcin. 462
5. 1. Los interlocutores. 463
5. 2. El Bus 463
5. 3. La publicacin. 463
5. 4. La noticia. 463
5. 5. El mensaje. 463
5. 6. La lista de distribucin. 463
5. 7. El adaptador. 463
5. 8. El distribuidor. 463
5. 9. La memoria. 464
6. Tipologa de adaptadores. 465
6. 1. Adaptadores de mensaje completo. 465
6. 2. Adaptadores de archivo con mensaje de aviso. 466
6. 3. Adaptadores de archivo sin mensaje de aviso. 466
6. 4. Adaptadores sobre BD. 466
6. 5. Adaptadores basados en correo electrnico. 466
6. 6. Adaptadores basados objetos distribuidos. 466
6. 7. Adaptadores fabricados por proveedores de componentes. 466
7. Publicacin y Suscripcin versus comunicacin cara a cara. 466
8. Herramientas para la capa de mensajera o transporte. 467
8. 1. Herramientas de Middleware de mensajes (MOM). 467
8. 2. Herramientas de RPC. 467
8. 3. Modelos de objetos distribuidos. 467
8. 4. Gestores de Colas. 467
8. 5. Correo electrnico. 467
8. 6. Monitores de transacciones. 467
8. 7. Software propio en integracin intracorporativa. 468
8. 8. Bus basado en Internet. 468
8.8.1. Cliente HTML puro localizado en la WEB. 468
8.8.2. Cliente HTML usando otro mdulo del sistema WEB. 468
8.8.3. Uso de Applet. 468
El Servidor de Versiones 469
1. Qu es un servidor de versiones? 469
2. Especificacin de los niveles lgicos de la plataforma. 469
3. Elementos a sincronizar. 469
4. Arquitectura del servidor de versiones. 470
5. La actualizacin a travs de Internet, 473
6. Generalizacin. 473
7. Arquitectura de replicacin, 474
Tcnicas de diseo por Modelos de Aplicacin. 475
1. Cuadro de tcnicas por modelos de diseo. 475
Interfcies Grficas de Usuario 476
1. Introduccin. 476
2. Qu es una Interfcie Grfica de Usuario. 476
3. Elementos de una Interfcie Grfica. 477
4. Tipos de Ventanas. 478
4. 1. Principal (Main). 478
4. 2. Hija (child). 478
4. 3. Pop-Up. 479
4. 4. Response. 479
5. Controles. 479
5. 1. Botones (Command Button). 480
5. 2. Botn de imagen (Picture Button). 481
5. 3. RadioButton. 481
5. 4. CheckBox. 481
5. 5. Lista desplegable (ListBox). 481
5. 6. Lnea de edicin (SingleLineEdit). 481
5. 7. Lnea de edicin mltiple. 481
5. 8. Barras de desplazamiento. 482
5. 9. Pestaas (TabSet). 482
5. 10. Rejillas (Grids). 482
5. 11. Cajas de Dilogo. 482
6. Men. 483
7. Los mensajes. 483
7. 1. Indicadores de accin. 483
7. 2. Indicadores de progresin. 483
7. 3. Mensajes informativos. 483
7. 4. Mensaje de Aviso. 484
7. 5. Mensajes de Error o Anomala. 484
8. Tcnicas Drag&Drop. 484
Identificacin de Objetos Visuales y Diseo Tecnolgico de GUIs. 485
1. Introduccin. 485
2. Objetos Visuales y Orientacin a Objetos. 485
3. Identificacin de Clases Visuales relacionadas con una GUI. 485
3. 1. Aplicacin. 486
3.1.1. Atributos. 486
3.1.2. Mtodos. 486
3. 2. Objeto Visual. 487
3.2.1. Atributos. 487
3.2.2. Mtodos. 487
3. 3. Especializaciones de la Clase Objeto Visual. 487
3.3.1. Ventana. 487
3.3.2. Control. 487
3. 4. Control Activo. 488
3.4.1. Clases de Edicin. 488
3.4.2. Botones. 488
3.4.3. Cajas de seleccin. 488
3. 5. Control pasivo. 488
3.5.1. Textos. 488
3.5.2. Figuras. 488
3. 6. Iconos. 488
3. 7. Mens. 488
3.7.1. Men principal. 488
3.7.2. Men de Contexto. 488
4. Programacin de interfcies grficas. 489
5. Objetos visuales derivados. 489
5. 1. Especializacin. 489
5. 2. Integracin. 490
6. Composicin de Objetos Visuales. 490
7. Recomendaciones. 491
7. 1. De uso de los objetos. 491
7. 2. De tratamiento de los eventos. 491
Diseo Funcional de la Lgica de Presentacin. 492
1. Introduccin. 492
2. Diseo funcional de interfcies grficas. 492
3. Elementos del diseo funcional. 492
3. 1. Perfil. 492
3. 2. Identificacin de usuario. 492
3. 3. Metfora o Analoga. 492
3. 4. Modelo de Conocimiento. 492
3. 5. Ergonoma. 493
3. 6. Imagen (Look). 493
3. 7. Comodidad. 493
3. 8. Tcnicas grficas disponibles. 493
4. Principios Bsicos del Lenguaje Visual. 493
4. 1. Organizacin. 493
4.1.1. Principio de consistencia. 493
4.1.2. Normas de visualizacin. 494
4.1.3. La composicin espacial. 494
4. 2. Economa. 494
4.2.1. Simplicidad. 495
4.2.2. Claridad. 495
4.2.3. Diferenciacin. 495
4.2.4. nfasis. 495
4. 3. Comunicacin. 495
4.3.1. Factores. 496
4.3.2. Divisin del mensaje. 496
4.3.3. Vistas mltiples. 497
4.3.4. Color y textura. 497
4. 4. Normativas y recomendaciones. 498
4. 5. Los flujos de dilogo. 498
4.5.1. Ventanas nodales. 499
4.5.2. Ventanas no nodales. 499
5. Metodologa de Diseo de interfcies Grficas. 500
5. 1. Definicin de los modelos. 501
5.1.1. Modelo de diseo. 501
5.1.2. Modelo grfico de usuario. 501
5.1.3. Modelo del usuario o percepcin del usuario. 501
5.1.4. La imagen del sistema. 502
5. 2. Anlisis y modelacin de las tareas para crear el modelo grfico de usuario. 502
5. 3. Formalizacin del diseo en la interfcie. 503
5. 4. Evaluacin de la interfcie. 503
5. 5. Entrega de la interfcie. 504
6. Criterios a tener en cuenta en el diseo. 504
6. 1. Criterios de interaccin con el usuario. 504
6. 2. Criterios de visualizacin de la informacin. 504
6. 3. Criterios de entrada de datos. 504
Construccin de Frameworks. 506
1. Introduccin. 506
2. El Paradigma MVC. 506
3. Multivistas, especializacin y jerarqua de vistas. 507
4. Arquitectura de Diseo de un Framework. 508
4. 1. Arquitectura de bloques. 508
4.1.1. La interfcie grfica (GUI) del Framework. 508
4.1.2. El modelo. 508
4.1.3. La persistencia. 508
4.1.4. Los atributos del Framework. 508
4.1.5. La Lgica de proceso del Framework. 508
4.1.6. El entorno (enviroment). 509
4. 2. Modelo de Objetos del Framework. 509
4. 3. La Clase Entorno. 509
4. 4. Consejos para hacer Framework de uso general. 510
La Comunicacin por eventos como va para obtener servicios. 511
1. Introduccin. 511
2. La comunicacin por eventos como va para pedir servicios. 511
3. Inclusin de los eventos en los diagramas de flujo. 513
Reingeniera de Sistemas. 516
1. Introduccin al concepto de Reingeniera. 516
2. Los beneficios del efecto 2000 y del EURO. 517
3. La evolucin por escenarios y el flujo de los sistemas de informacin hacia la integracin. 518
4. La migracin de los datos. 518
4. 1. Problemas clsicos. 518
4. 2. Pasos a seguir. 519
5. Maquillaje de aplicaciones existentes. 519
6. Upsizing de sistemas. 519
7. El papel de los Mainframe. 520
8. Tcnicas de envolvente del HOST. 520
9. Downsizing. 523
10. EAI: Integracin de aplicaciones corporativas. 524
10. 1. Etapas. 526
10.1.1. Definicin clara de los objetivos que motivan la necesidad. 526
10.1.2. Integracin de datos. 527
10.1.3. Identificacin, diseo y publicacin de los servicios de proceso. 527
10.1.4. Implementacin de los procesos de negocio involucrados. 527
10.1.5. Revisin de los procesos de negocio internos. 527
10.1.6. Integracin de procesos externos con terceros. 527
11. La consolidacin de recursos de plataforma. 527
11. 1. Preparacin. 528
11. 2. Desarrollo. 529
11. 3. Mejora. 529
12. Reingeniera de procesos de negocio. 529
INDICE DE LA SEGUNDA PARTE 530
INDICE DE FIGURAS DE LA SEGUNDA PARTE 552

INDICE DE FIGURAS DE LA SEGUNDA PARTE

Figura 1. Representacin de semforos......................................................................... 14
Figura 2. Representacin de un Ticket........................................................................... 16
Figura 3. Tickets Multihoja.............................................................................................. 18
Figura 4. Representacin de una cola............................................................................ 19
Figura 5. Dinmica de referencias.................................................................................. 22
Figura 6. Colas multicliente y multiservidor .................................................................... 25
Figura 7. Servidor de Cola.............................................................................................. 26
Figura 8. Ejemplo de utilizacin de un servidor de cola: Anotacin y Replicacin
asncrona ............................................................................................................ 26
Figura 9. Consulta de un ticket multihoja........................................................................ 27
Figura 10. Parametrizacin de una cola......................................................................... 28
Figura 11. Consulta de una cola..................................................................................... 28
Figura 12. Gestin de la anotacin en una cola............................................................. 29
Figura 13. Servidor de Impresin ................................................................................... 29
Figura 14. Representacin del viga............................................................................... 30
Figura 15. Representacin del disparador...................................................................... 30
Figura 16. Representacin del Servidor de Correo ........................................................ 30
Figura 17. Arquitectura bsica de un servidor de correo................................................ 31
Figura 18. Funcionamiento bsico de un Servidor de Correo ........................................ 33
Figura 19. Posibilidades de parametrizacin de un Servidor de Correo ........................ 34
Figura 20. Representacin del servidor de Notas y Avisos............................................ 35
Figura 21. Representacin del cartero ........................................................................... 37
Figura 22. Esquema de comunicacin sncrona............................................................. 45
Figura 23. Esquema de comunicacin asncrona........................................................... 46
Figura 24. Representacin del modelo conversacional.................................................. 48
Figura 25. Relacin conversacional entre cliente y servidor .......................................... 48
Figura 26. Representacin de una cola.......................................................................... 49
Figura 27. Comunicacin sin respuesta ......................................................................... 50
Figura 28. Comunicacin con respuesta directa ............................................................ 50
Figura 29. Comunicacin con respuesta por cola .......................................................... 51
Figura 30. Arquitectura de colas multicliente y multiservidor.......................................... 51
Figura 31. Representacin de la comunicacin desacoplada y asncrona por medio de
una cola .............................................................................................................. 51
Figura 32. Representacin de la peticin genrica de un servicio. ................................ 52
Figura 33. Especializacin de la peticin de servicio ..................................................... 52
Figura 34. Representacin de la comunicacin por OLE y ACTIVE X.......................... 52
Figura 35. Representacin de la comunicacin por ODBC............................................ 52
Figura 36. Arquitectura del servicio de ODBC................................................................ 53
Figura 37. Representacin de la comunicacin por ADO............................................... 53
Figura 38. Arquitectura de ADO..................................................................................... 53
Figura 39. Arquitectura de ADO.NET ............................................................................. 54
Figura 40. Representacin del servicio genrico de acceso a datos relacionales ......... 55
Figura 41. Representacin de un servidor SQL ............................................................. 55
Figura 42. Representacin de la llamada a procedimiento catalogado.......................... 55
Figura 43. Representacin de los accesos a Internet. .................................................. 55
Figura 44. Representacin del acceso por RPC ............................................................ 56
Figura 45. Network Interface Definition Language (NIDL).............................................. 56
Figura 46. Comportamiento del RPC en tiempo de ejecucin........................................ 57
Figura 47. Representacin de la comunicacin por SOAP ............................................ 59
Figura 48. Modelos de objetos distribuidos .................................................................... 59
Figura 49. Representacin de la comunicacin por eventos.......................................... 60
Figura 50. Mecanismo ECA............................................................................................ 60
Figura 51. Indicativo de conexin remota....................................................................... 61
Figura 52. Indicativo de conexin remota con dispositivo mvil ..................................... 61
Figura 53. Indicativo de conexin inalmbrica................................................................ 61
Figura 54. Diagrama de flujo de una contratacin de viaje. ........................................... 62
Figura 55. Arquitectura de servidores............................................................................. 63
Figura 56. Arquitectura de las funciones de venta directa.............................................. 63
Figura 57. Representacin de XML................................................................................ 64
Figura 58. Organizacin por capas................................................................................. 70
Figura 59. Dilogo cuasi-jerrquico................................................................................ 71
Figura 60. Representacin del dilogo Pull .................................................................... 72
Figura 61. Push versus Pull............................................................................................ 73
Figura 62. Push y Pull en Internet .................................................................................. 73
Figura 63. El Comit de Componentes........................................................................... 90
Figura 64. La reusabilidad gestionada por el Director de Proyectos.............................. 91
Figura 65. Ciclo de vida de un componente ................................................................... 93
Figura 66. La balanza de distribucin del peso C/S. ...................................................... 94
Figura 67. Smbolo del Cliente ....................................................................................... 97
Figura 68. Lgicas y Programas Cliente......................................................................... 98
Figura 69. Smbolo del Servidor ................................................................................... 107
Figura 70. Servidores multicliente multiservidor ........................................................... 108
Figura 71. Servidores dependientes del sistema.......................................................... 112
Figura 72. Implementacin por delegacin................................................................... 112
Figura 73. Delegacin de Servicio............................................................................... 115
Figura 74. Ejemplo de delegacin de Servicio ............................................................. 116
Figura 75. Arquitectura de Respuesta Anexa............................................................... 117
Figura 76. Ejemplo de Arquitectura de Delegacin con Mensaje Anexo...................... 118
Figura 77. Ejemplo de una arquitectura de Traspaso de Responsabilidad.................. 119
Figura 78. Ejemplo de una arquitectura de Redireccin............................................... 120
Figura 79. Ejemplo de una arquitectura de Pasarela ................................................... 121
Figura 80. Arquitectura de Broadcast. .......................................................................... 122
Figura 81. Arquitectura de Filtro ................................................................................... 123
Figura 82. Ejemplo de Arquitectura de Filtro ................................................................ 123
Figura 83. Arquitectura Master-Slave........................................................................... 124
Figura 84. Ejemplo de Arquitectura Master-Slave. ....................................................... 124
Figura 85. Arquitectura de Distribucin ........................................................................ 125
Figura 86. Ejemplo de Arquitectura de Distribucin ..................................................... 125
Figura 87. Arquitectura de Pre-Condicin .................................................................... 126
Figura 88. Ejemplo de Arquitectura de Pre-Condicin ................................................. 126
Figura 89. Ejemplo de Arquitectura Configuracin....................................................... 127
Figura 90. Ejemplo de Arquitectura Configuracin para el alta de clientes remota...... 128
Figura 91. Ejemplo de arquitectura de configuracin con una PDA............................. 129
Figura 92. Ejemplo de Arquitectura de Proxy para mejorar rendimiento...................... 130
Figura 93. Arquitectura de servidores completa........................................................... 132
Figura 94. Arquitectura de las funciones de venta directa completo............................ 132
Figura 95. Interacciones en un modelo SOA................................................................ 137
Figura 96. Arquitectura de un servicio con particin horizontal .................................... 142
Figura 97. Servicio de facturacin. ............................................................................... 143
Figura 98. Servicio de Router ....................................................................................... 144
Figura 99. Los proyectos distribuidos como proyectos de Ingeniera........................... 151
Figura 100. Fases de la gestin del Proyecto .............................................................. 153
Figura 101. Ciclo de Vida Clsico o en Cascada ......................................................... 154
Figura 102. Prototipaje. ................................................................................................ 155
Figura 103. Ciclo de vida en Espiral ............................................................................. 156
Figura 104. Ciclo de vida de clase de Meyer................................................................ 158
Figura 105. Ciclo de vida OO de Henderson - Sellers.................................................. 158
Figura 106. Esquema de Administracin de un Proyecto............................................. 159
Figura 107. Encaje del diseo distribuido en el ciclo de desarrollo del software ......... 170
Figura 108. Ejemplo de diagrama de flujo. ................................................................... 172
Figura 109. Ejemplo de la utilidad de la secuencializacin .......................................... 174
Figura 110. Ejemplo de Decisin dentro de la Secuencia de Ejecucin. ..................... 175
Figura 111. Anlisis Descendente................................................................................ 178
Figura 112. Diagrama Jerrquico ................................................................................. 181
Figura 113. Diagrama Jerrquico con funciones compartidas ..................................... 181
Figura 114. Ejemplo de Diagrama Jerrquico. ............................................................. 181
Figura 115. Ejemplo de Modelo Relacional .................................................................. 184
Figura 116. Arquitectura ANSI/SPARC de tres niveles ................................................ 185
Figura 117. Bases de datos pasivas............................................................................. 187
Figura 118. Bases de datos activas.............................................................................. 188
Figura 119. Mecanismo de trigger ................................................................................ 188
Figura 120. Vistas e Integracin de BD's ..................................................................... 190
Figura 121. Modelo de datos. ....................................................................................... 197
Figura 122. Diagrama Jerrquico inicial de unidades y procesos lgicos.................... 197
Figura 123. Proceso de Venta de Viaje Areo ............................................................. 198
Figura 124. Primer proceso de refinamiento de Venta Viaje y Hotel a Cliente............. 198
Figura 125. Refinamiento de Entrada de la Peticin .................................................... 199
Figura 126. Refinamiento de Registro Datos del Viaje................................................. 199
Figura 127. Proceso de Alta de Clientes ...................................................................... 200
Figura 128. Proceso para Actualizar Datos. ................................................................ 200
Figura 129. Proceso de Estadsticas............................................................................ 201
Figura 130. Refinamiento del Proceso de Estadsticas................................................ 201
Figura 131. Diagrama jerrquico ampliado................................................................... 202
Figura 132. Concepto de Objeto................................................................................... 204
Figura 133. El tringulo OO.......................................................................................... 205
Figura 134. Representacin de una clase bicicleta...................................................... 206
Figura 135. Representacin de una Clase ................................................................... 206
Figura 136. Notacin de Clase e Instancia................................................................... 206
Figura 137. Herencia .................................................................................................... 207
Figura 138. Herencia mltiple....................................................................................... 207
Figura 139. Clase mover. ............................................................................................. 208
Figura 140. Jerarqua de una Clase Polgono.............................................................. 209
Figura 141. Ejemplo de Diagramas de Clases e Instancias......................................... 214
Figura 142. Notacin de las asociaciones.................................................................... 214
Figura 143. Ejemplo de Asociacin Ternaria................................................................ 215
Figura 144. Notacin de la Multiplicidad por un cardinal. ............................................. 215
Figura 145. Notacin Simblica de la Multiplicidad ...................................................... 216
Figura 146. Ejemplo de Asociacin con atributos......................................................... 216
Figura 147. Ejemplo de Asociacin con Atributos modelada como una clase. ............ 216
Figura 148. Notacin y ejemplo de Agregacin............................................................ 217
Figura 149. Ejemplos de Agregaciones........................................................................ 217
Figura 150. Modelo de Objetos de una Expresin ....................................................... 217
Figura 151. Modelo de Objetos de un texto.................................................................. 217
Figura 152. Diagrama de Objetos de fronteras de pases............................................ 218
Figura 153. Modelo de Objetos de una mano de poker. .............................................. 218
Figura 154. Modelo de Objetos de un sistema de transporte areo............................. 218
Figura 155. Uso de ordenadores por empleados ......................................................... 218
Figura 156. ANSI/SPARC three schema architecture .................................................. 219
Figura 157. Equivalencia de de niveles entre OO y relacional ..................................... 220
Figura 158. Evolucin del diseo UML a distribuido..................................................... 229
Figura 159. Representacin grfica a de los nodos en un diagrama de despliegue.... 229
Figura 160. Ejemplo de diagrama de Sistema.............................................................. 230
Figura 161. Ejemplo de diagrama de Sistema.............................................................. 231
Figura 162. Diagrama de Niveles Lgicos.................................................................... 231
Figura 163. Diagrama de Arquitectura de Servicios Notacin................................... 232
Figura 164. Ejemplo de diagrama de Arquitectura de Servicios................................... 233
Figura 165. Diagrama de Arquitectura de Servicios implementado como diagrama de
Colaboracin..................................................................................................... 233
Figura 166. Diagrama de Localizaciones ..................................................................... 234
Figura 167. Ejemplo de Diagrama de Actividades como fuente de servicios............... 235
Figura 168. Ejemplo de Diagrama de Actividades adaptado tras el diseo distribuido 235
Figura 169. Arquitectura de Servicios del Diagrama de Actividades adaptado tras el
diseo distribuido.............................................................................................. 236
Figura 170. Identificacin de servicios en un Diagrama de Colaboracin.................... 237
Figura 171. Posibilidades de integracin de servicios entre entornos ......................... 238
Figura 172. Influencia de la arquitectura OO en el modelo de comunicacin .............. 241
Figura 173. Ejemplo de implementacin de un servicio de datos ................................ 241
Figura 174. Modelo conceptual de especificacin........................................................ 243
Figura 175. Diagrama de secuencia del caso de uso................................................... 243
Figura 176. Modelo conceptual de diseo.................................................................... 244
Figura 177. Interfcie grfica de la operacin asignarProveedor()................................ 245
Figura 178. Diagrama de secuencia del caso de uso concreto.................................... 248
Figura 179. Controlador transaccional para comunicar las capas de presentacin y de
dominio ............................................................................................................. 248
Figura 180. Diagrama de secuencia de la creacin de la ventana............................... 249
Figura 181. Diagrama de secuencia de la creacin de la ventana. Inicializacin ........ 249
Figura 182. Diagrama de secuencia de la actualizacin del desplegable de
proveedores al cambiar la cima del desplegable de materia prima.................. 250
Figura 183. Diagrama de secuencia de la reaccin al botn Registrar para asignar el
proveedor a la materia prima. ........................................................................... 250
Figura 184. Diagrama de secuencia de los servicios de la capa de datos................... 251
Figura 185. Implementacin 1. ..................................................................................... 252
Figura 186. Implementacin 2. ..................................................................................... 253
Figura 187. Diagrama de Sistemas de Asignar Proveedor. ......................................... 254
Figura 188. Diagrama de Niveles Lgicos de Asignar Proveedor. ............................... 254
Figura 189. Diagrames de Servicios y de Localizacin de Asignar Proveedores. ....... 255
Figura 190. Esquematizacin de la arquitectura de datos............................................ 258
Figura 191. "Visin" de los modelos de datos .............................................................. 259
Figura 192. Arquitectura de datos distribuidos ............................................................. 259
Figura 193. Modelo centralizado pequeo. .................................................................. 262
Figura 194. Modelo centralizado grande. ..................................................................... 262
Figura 195. Esquema de datos replicados. .................................................................. 264
Figura 196. Protocolo de dos fases (Tho-phases Commit) .......................................... 268
Figura 197. Arquitectura de Replicacin Sncrona ....................................................... 270
Figura 198. La escala copia / replica. ........................................................................... 271
Figura 199. Replicacin por master/slave. ................................................................... 273
Figura 200. Replicacin por log's ................................................................................. 274
Figura 201. Esquema de Auditoria de Datos Replicados............................................. 278
Figura 202. Arquitectura de un ejecutor ....................................................................... 283
Figura 203. Arquitectura de datos particionados.......................................................... 284
Figura 204. Aplicacin del patrn DTO para mejorar rendimiento ............................... 289
Figura 205. El servicio de interpretacin ...................................................................... 292
Figura 206. Arquitectura de servidor de agrupacin con servicios sncronos en origen293
Figura 207. Arquitectura del servicio de agrupacin basado en replicacin ................ 294
Figura 208. Lectura por servicios ................................................................................. 295
Figura 209. Modificacin por servicios. ........................................................................ 296
Figura 210. Servidor de agrupacin por replicacin ampliado ..................................... 297
Figura 211. Etapas de diseo de las aplicaciones avanzadas..................................... 300
Figura 212. Etapas de diseo de aplicaciones RAD .................................................... 300
Figura 213. Metodologa Integrada de Diseo Distribuido. .......................................... 301
Figura 214. Etapas del Diseo de la Arquitectura Distribuida ...................................... 309
Figura 215. Etapas del Anlisis de los datos............................................................... 310
Figura 216. Arquitectura de una llamada asncrona a travs de una va lenta. ........... 324
Figura 217. SI para la Venta de Productos en Delegaciones....................................... 325
Figura 218. Primer Refinamiento.................................................................................. 325
Figura 219. Refinamiento de Registro de Pedido......................................................... 326
Figura 220. Refinamiento de Servir Pedido.................................................................. 326
Figura 221. Arquitectura Distribuida del primer refinamiento ....................................... 327
Figura 222. Refinamiento del Servidor para Leer los Datos del Cliente...................... 327
Figura 223. Arquitectura Distribuida de Registro del Pedido........................................ 328
Figura 224. Arquitectura Distribuida de Servir Pedido.................................................. 328
Figura 225. Servidores multicliente y multiservidor ...................................................... 329
Figura 226. Esquema de datos modificado .................................................................. 334
Figura 227. Arquitectura de datos de la Central ........................................................... 335
Figura 228. Arquitectura de datos de la Tienda............................................................ 335
Figura 229. Proceso para Leer los datos del Cliente.................................................... 336
Figura 230. Proceso de Alta de Cliente Modificado...................................................... 337
Figura 231. Proceso de Actualizacin de Datos modificado. ....................................... 338
Figura 232. Nuevo Proceso de Replicacin de Clientes .............................................. 338
Figura 233. Proceso de impresin de la reserva del cliente......................................... 343
Figura 234. Precondicin en la gestin del Crdito de Cliente..................................... 343
Figura 235. Servidor de Actualizar Datos de Cliente en la Central .............................. 344
Figura 236. Refinamiento del Servidor de Leer Datos de Cliente en la Central ........... 344
Figura 237. Refinamiento del servidor de lectura del crdito. ...................................... 345
Figura 238. Solucin A para la arquitectura del servidor de Leer Datos del Cliente en el
servidor de la Tienda. ....................................................................................... 345
Figura 239. Solucin A para la arquitectura del servidor de Leer Datos del Cliente en el
servidor de la Tienda. ....................................................................................... 346
Figura 240. Refinamiento del servidor de lectura de datos de clientes en la Tienda ... 347
Figura 241. Arquitectura del servidor de Alta de Clientes en la Central. ...................... 347
Figura 242. Arquitectura del proceso de Entrada de la Peticin. ................................. 348
Figura 243. Arquitectura del proceso de Registro Datos Viaje..................................... 348
Figura 244. Arquitectura del proceso de Actualizacin de Datos de la Venta.............. 349
Figura 245. Arquitectura del proceso de Replicacin de Clientes................................ 349
Figura 246. Arquitectura del proceso de Actualizacin de Datos de la Venta.............. 351
Figura 247. Diagrama Jerrquico tras el diseo de la Arquitectura distribuida. ........... 352
Figura 248. Clasificacin de las actividades de administracin ................................... 354
Figura 249. Niveles de configuracin del puesto cliente .............................................. 358
Figura 250. Organizacin operativa del soporte a usuarios. ........................................ 363
Figura 251. Auditora de los procesos de Outsourcing................................................. 372
Figura 252. Clasificacin de las actividades de administracin ................................... 382
Figura 253. Diseo de la administracin de sistema.................................................... 383
Figura 254. Back-up Distribuido ................................................................................... 391
Figura 255. Back-up de usuario sobre entorno departamental .................................... 392
Figura 256. Back-up Departamental ............................................................................. 392
Figura 257. Formato del ticket de control de un back-up departamental ..................... 392
Figura 258. Back-up departamental centralizado......................................................... 393
Figura 259. Organizacin jerrquica de los grupos de impresin ................................ 396
Figura 260. Distribucin jerrquica de los recursos de impresin................................ 396
Figura 261. Permetro de seguridad mltiple con identificacin mltiple...................... 401
Figura 262. Permetro de seguridad mltiple con identificacin nica ......................... 402
Figura 263. Permetro de seguridad nico ................................................................... 402
Figura 264. Ciclo de trabajo del Anlisis de Consistencia............................................ 409
Figura 265. Ciclo de la gestin de errores.................................................................... 410
Figura 266. Mecanismo de comunicacin C/S con confirmacin................................. 418
Figura 267. Ciclo de trabajo en emergencia................................................................. 425
Figura 268. Extensin de los diagramas de flujo para recoger el anlisis de
consistencia. ..................................................................................................... 426
Figura 269. Metodologa del Diseo de la Consistencia .............................................. 426
Figura 270. Diagrama de flujo inicial del Vigilante........................................................ 434
Figura 271. Refinamiento del proceso para Verificar la Conexin con la Central ........ 434
Figura 272. Refinamiento del proceso para Verificar la Conexin con la Compaa
Area. ............................................................................................................... 434
Figura 273. Consistencia del Servidor para Leer Datos Cliente................................... 435
Figura 274. Consistencia del servidor de leer datos de cliente en la tienda ................ 435
Figura 275. Diagrama de Consistencia del proceso para Actualizar Ventas................ 436
Figura 276. Nuevo proceso de Recuperacin de la Situacin de Emergencia ............ 436
Figura 277. Proceso de Data Entry para la Venta Manual ........................................... 437
Figura 278. Integracin del Cliente............................................................................... 439
Figura 279. Representacin de la integracin GUI....................................................... 443
Figura 280. Representacin de la integracin por Portal ............................................. 443
Figura 281. Representacin de un cliente ligero.......................................................... 445
Figura 282. Integracin transaccional .......................................................................... 447
Figura 283. Representacin de una Integracin Transaccional ................................... 447
Figura 284. Ejemplo de integracin trasaccional de una red de cajeros automticos.. 447
Figura 285. Representacin de un cliente WEB........................................................... 448
Figura 286. Presentacin Activa y plataforma Servicios WEB..................................... 448
Figura 287. Representacin de una WEB convencional .............................................. 448
Figura 288. Representacin de clientes Back-ground.................................................. 448
Figura 289. Integracin batch....................................................................................... 449
Figura 290. Representacin de cadena Batch ............................................................. 449
Figura 291. Representacin de una integracin por estereotipos................................ 451
Figura 292. Integracin por agentes............................................................................. 452
Figura 293. Representacin de un procesador distribuido........................................... 452
Figura 294. Arquitectura de un procesador distribuido................................................. 453
Figura 295. El Procesador distribuido sncrono............................................................ 454
Figura 296. Representacin de una integracin Workflow........................................... 455
Figura 297. Ejemplo de Workflow................................................................................. 455
Figura 298. Implementacin del proceso de Aceptacin del Crdito. .......................... 456
Figura 299. Implementacin de un Sistema de Gestin de documentos. .................... 456
Figura 300. Representacin de una integracin por publicacin/suscripcin .............. 456
Figura 301. Papeles mltiples. ..................................................................................... 458
Figura 302. Comunicacin cara a cara versus comunicacin por bus. ........................ 460
Figura 303. Arquitectura bsica de publicacin suscripcin......................................... 464
Figura 304. Acceso a P/S heterogneos. ..................................................................... 465
Figura 305. Arquitectura de un servidor de versiones. ................................................. 471
Figura 306. El servidor de versiones de los puestos cliente......................................... 473
Figura 307. Componentes de una interfcie grfica de usuario.................................... 478
Figura 308. Identificacin de Clases Visuales. ............................................................. 486
Figura 309. Derivacin por especializacin. ................................................................. 489
Figura 310. Derivacin por integracin......................................................................... 490
Figura 311. Modelado de una GUI. .............................................................................. 490
Figura 312. Principio de Consistencia. ......................................................................... 493
Figura 313. Divisin por reas de una ventana. ........................................................... 498
Figura 314. Interaccin entre los modelos.................................................................... 502
Figura 315. Ciclo de evaluacin de una interfcie......................................................... 503
Figura 316. Arquitectura de un Framework grfico. ..................................................... 508
Figura 317. Modelo de Objetos de un Framework. ...................................................... 509
Figura 318. Esquema de funcionamiento de un Gestor de Eventos. ........................... 512
Figura 319. Esquema de programacin secuencial. .................................................... 513
Figura 320. Esquema de programacin por eventos.................................................... 513
Figura 321. Notacin de los eventos en los diagramas de flujo. .................................. 513
Figura 322. Consistencia del proceso de conexin con la central por eventos............ 514
Figura 323. Refinamiento verificar conexiones por eventos......................................... 514
Figura 324. Reconstruccin de la conexin con la central por eventos. ...................... 515
Figura 325. Arquitectura de Envolvente. ...................................................................... 522
Figura 326. Envolvente de presentacin de tres niveles.............................................. 522
Figura 327. El camino del Downsizing.......................................................................... 524
Figura 328. Etapas de un proceso EAI......................................................................... 526

DissenyoAplicacionesDistribuidas EnricMartinez

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

DissenyoAplicacionesDistribuidas EnricMartinez

Cargado por

Copyright:

Formatos disponibles

Enric Martnez Gomriz

También podría gustarte