Weitere ähnliche Inhalte
Ähnlich wie Arquitectura si (20)
Kürzlich hochgeladen (10)
Arquitectura si
- 1. Arquitectura de los Sistemas de Información.
______________________________________________________________________
______________________________________________________________________
Arquitectura de los Sistemas de Información Empresariales.
Una visión basada en Patrones.
1.- Introducción.
2.- Requisitos y Pocesos Principales de los Sistemas de Información.
3.- Componentes Comunes.
4.- Arquitectura.
______________________________________________________________________
“... you can see a predefined structure that remains from the source content to the
resulting content...” Moisés D. Díaz.
1.- Introducción.
Definición.
Existen muchos sistemas software, y en todos ellos la información está presente, sin
embargo en los sistemas de los que aquí vamos a hablar la información es el elemento
fundamental ya que su cometido principal radica precisamente en la gestión de este
intangible elemento. Es por ello por lo que los problemas fundamentales que estos
sistemas tienen que resolver están relacionados con la representación de la información,
su persistencia, la recepción y transmisión de los datos, y los medios que nos sirven
para transmitirla y comunicarla.
¿Qué es por tanto un sistema de información? Podemos definir un sistema de
información como un conjunto de componentes (o elementos) que operan
conjuntamente para capturar, procesar, almacenar y distribuir información. Esta
información se utiliza generalmente para la toma de decisiones, la coordinación, el
control, y el análisis en una organización. En muchas ocasiones la gestión de dicha
información es el objetivo primario del sistema.
Características
Concretando un poco más, ¿cuáles son las caracterísitcas fundamentales de los Sistemas
de Información?:
? Gestionan grandes cantidades de datos persistentes. (Precisamente los datos que
?
almacena).
? Gestionan el acceso concurrente a la información de muchos usuarios. (Usuarios
?
que producen o consumen datos que gestiona el sistema).
? Sus interfaces gráficos vienen en gran medida ‘
? definidos’ por la información que
el sistema gestiona (por cierto en innumerables pantallas de formularios e
informes).
? Se integran con muchas otras aplicaciones empresariales y ofimáticas.
?
______________________________________________________________________
© Moisés Daniel Díaz Toledano. WebSite: www.moisesdaniel.com
Pág. 1
- 2. Arquitectura de los Sistemas de Información.
______________________________________________________________________
Arquitectura.
Se dice que ‘ función define a la forma’ o lo que es lo mismo que la estructura o
la ,
arquitectura de cualquier sistema tiene una relación muy profunda con aquello que tiene
que realizar. Por esta razón el conjunto de los sistemas de información comparten una
arquitectura y unos procesos bien definidos, ya que todos ellos tienen unos objetivos
iguales que cumplir (que no se nos olvide: integrar, procesar, almacenar y distribuir
información) y un conjunto de características comunes (las enumeradas más arriba).
El concepto de arquitectura es usado con mucha frecuencia y en muy distintos
contextos, con lo que su significado se ha tornado algo difuso (la verdad es que no
puedo asegurar que alguna vez fuese claro).
En este artículo entenderemos arquitectura como la estructura que tienen el conjunto de
componentes que forman un sistema, así como la relación entre los mismos. Es decir
una visión estructural de alto nivel (pocos detalles) del sistema.
Patrones.
Podemos definir un patrón de diseño como la representación abstracta de una buena
solución (o diseño) a un problema concreto que se produce en uno o más contextos.
¿Qué es lo que nos aportan los patrones? Éstos nos han dado la posibilidad de organizar
nuestras clases, componentes y subsistemas en estructuras comunes, bien probadas,
cuyo impacto en el sistema se traduce en un incremento de su flexibilidad, modularidad
y extensibilidad. En otras palabras mejoran la calidad del diseño y por lo tanto del
software en sí.
Los patrones han demostrado ser una forma idónea para transmitir conocimiento
estructural, es decir de diseño, como es, por ejemplo, la arquitectura de los sistemas, el
tema que aquí estamos tratando.
Por todas estas razones en este artículo presentaré los diferentes elementos mediante una
estructura documental inspirada en los patrones de diseño, aunque mucho menos
formal.
Los patrones así mismo se agrupan con frecuencia en Lenguajes de Patrones. Por lo
general en estos lenguajes se describen un conjunto de patrones de forma que podemos
identificar toda una serie de roles importantes en el contexto particular en que se aplica,
así como la forman en la que se relacionan. De esta forma, a través de los lenguajes de
patrones podemos describir de forma completa (o casi completa) los sistemas que se dan
en dicho contexto, o viéndolo desde otra óptica, resolver los diferentes problemas que
aparecen en un contexto específico.
Este artículo constituye en cierta forma un lenguaje de patrones que describe los
componentes y procesos básicos de los sistemas de información.
______________________________________________________________________
© Moisés Daniel Díaz Toledano. WebSite: www.moisesdaniel.com
Pág. 2
- 3. Arquitectura de los Sistemas de Información.
______________________________________________________________________
2.- Requisitos y Pocesos Principales de los Sistemas de Información.
Actores
Decíamos anteriormente que una de las características de los sistemas de información es
la gestión que hacen del acceso de los usuarios a los datos del sistema.
Este acceso se puede producir por diferentes motivos: para añadir, modificar o borrar
datos, para consultarlos o para gestionar el propio sistema de información.
Según el tipo de acceso tendremos diferentes usuarios o actores: productores de
información, consumidores de información, y gestores del sistema.
Un actor es un elemento externo al sistema que interactúa con él, ya sea una persona o
un programa de ordenador.
Procesos básicos
Al igual que identificamos 3 tipos de actores también tenemos 3 tipos de funciones
básicas a realizar por un sistema de información:
? Integrar información en el sistema. Los datos originales para esta actividad serán
?
proporcionados por los productores de información. Este proceso puede
conllevar el procesamiento de dichos datos antes de ser almacenados en el
sistema .
? Distribuir información a los usuarios. Evidentemente a los consumidores de
?
información. También este proceso puede conllevar el procesamiento de los
datos almacenados que vamos a distribuir.
? Gestionar el sistema: dar de alta/baja y modificar nuevos productores y
?
consumidores de información, estableces permisos respecto a su actividad con
respecto al sistema, etc. No olvidemos que cualquier sistema de información es
un sistema real por lo que requiere administración, y esta será realizada por los
gestores del sistema.
Como podemos ver se establece una correspondencia directa entre los diferentes actores
y la funcionalidad del sistema que interactúa con él.
Dejándo esto claro pasemos a analizar con mayor profundidad los dos procesos que
tienen mayor impacto arquitectónico.
______________________________________________________________________
© Moisés Daniel Díaz Toledano. WebSite: www.moisesdaniel.com
Pág. 3
- 4. Arquitectura de los Sistemas de Información.
______________________________________________________________________
Integración de la información.
La integración de información es uno de los procesos fundamentales que debe de
realizar un sistema de información.
Este a su vez se puede dividir en una serie de subprocesos, que tendremos o no que
implementar dependiendo de la complejidad de nuestro sistema y de las herramientas
con las que estemos trabajando.
Integrar información significa por lo generar procesar la datos que generan los
productores (que podrá venir en forma de parámetros de procedimientos, variables,
mensajes, ficheros, emails, etc) e incorporarla a nuestros almacenes de datos (por lo
general bases de datos relacionales). Desgranándolo un poco más:
? ? Recepcionar paquete de información (que es como vamos a denominar
genéricamente a los datos agrupados y estructurados). El sistema puede
contener módulos que generen los propios paquetes de información a
través de la información recogida en la interacción con los actores
? ? Verificar paquete de información (ejemplo en un email: verificar
remitentes, restricciones sobre adjuntos, etc).
? ? Verificar validez estructural de los datos enviados (por ejemplo en un
xml, sería validarlo contra su xschema), así como verificar permisos (del
productor con respecto a los datos).
? ? Integrar (y transformar) la información en algún/os almacenes de datos
(por lo general significará incorporar dicha información en algún
conjunto de tablas de alguna base de datos relacional). (Este punto puede
incluir procesos de verificación entre el productor y el tipo de datos que
está enviando).
? ? Generar respuestas concernientes al procesamiento de dichos paquetes a
los productores de dicha información.
Este proceso quedaría de la siguiente forma si lo documentamos como un patrón:
? Patrón Integrador. Proceso Info-Integrador.
Problema:
Incorporar al sistema la información generada por los actores ‘Productores’ de
información.
Fuerzas y Contexto:
Fuerzas básicas. Las fuerzas son los propios requisitos funcionales: necesidades
de negocio (integrar información, requisito funcional primario), validaciones
estructurales, de contenido, generación de respuestas, etc.
______________________________________________________________________
© Moisés Daniel Díaz Toledano. WebSite: www.moisesdaniel.com
Pág. 4
- 5. Arquitectura de los Sistemas de Información.
______________________________________________________________________
Solución:
Crear una estructura de componentes que refleje, mapee y cubra los requisitos
funcionales (fuerzas básicas) de incorporar la información al Sistema. Existiendo una
correspondencia directa entre cada requisito del proceso con un componente.
Interacción G estor de
C lien te Integración
Receptor Verificador Verificador G enerador
M ensajes M ensajes Datos e Info Respuesta
Integrador de
Información
M ensaje
[Datos[Info]]
Base de Datos
Distribución de la información.
La distribución de la información es uno de los procesos fundamentales que debe de
realizar un sistema de información.
De nada serviría recabar grandes (ni pequeñas) cantidades de información si esta no
fuese después a ser distribuida (después de haber sido procesada, o sin haberlo sido) a
aquellos usuarios (personas o componentes) que la requieren para realizar su trabajo.
Sin embargo no todos los usuarios tendrán ni las mismas necesidades ni los mismos
privilegios.
Existirán usuarios con capacidad para obtener cualquier tipo de información, mientras
que otro sólo tendrán acceso a una parte de la misma. Así mismo los formatos en los
que se tendrá que distribuir dicha inforamación, pueden ser muy distintos, al igual que
los protocolos que se usen para su transmisión.
Por tanto, es la distribución de la información un proceso complejo que puede
subdividirse a su vez en varios subprocesos:
? ? Recepcionar petición de información. El sistema puede contener
módulos que representen dicha información directamente al consumidor
de la misma.
? ? Validación de la petición de información.
? ? Recolección de la información.
? ? Formateo-Procesamiento de la misma.
? ? Envío de la información al consumidor.
Cuyo patrón es el siguiente:
______________________________________________________________________
© Moisés Daniel Díaz Toledano. WebSite: www.moisesdaniel.com
Pág. 5
- 6. Arquitectura de los Sistemas de Información.
______________________________________________________________________
? Patrón Info-Distribuidor.
Problema:
Distribuir información a los usuarios.
Fuerzas y Contexto:
Fuerzas básicas. Las fuerzas son los propios requisitos funcionales: necesidades
de negocio (distribuir información, requisito funcional primario), validaciones de
usuario y petición (restricciones), formateo de la información, envío de la misma, etc.
Solución:
Interacción cliente. Gestor de
Representa info Distribución
Receptor Verificador Recolector Formateador
Petición Restricciones Información Información
. . .
Petición de Base de Datos
Información
Base de Dato s I I
Cada uno de los subprocesos lo convertimos en un componente con una funcionalidad
bien definida, y que será o no implementado dependiendo básicamente de dos cosas:
? Primera, que ya venga implementado o no en nuestras herramientas de
?
desarrollo.
? Segunda, que la complejidad del proyecto lo requiera.
?
Modelos de interacción
Como nota adicional, haré un apunte sobre los modelos de interacción entre un sistema
y sus usuarios:
? ? Síncrono. El módulo de ‘ interacción cliente’ y la integración-distribución
de información deben tener una comunicación síncrona. El conjunto de
todas las interacciones entre los componentes tienen que ser de muy baja
latencia. Estas soluciones permiten a la perfección entornos muy
completos de grabación de datos, envío de grandes cantidades de
información, etc. Típica solución es la arquitecturas cliente-servidor de
n-capas con comunicaciones enmarcadas en redes locales en la que los
componentes interaccionan por medio de dcom o corba (también soap).
? ? Síncrono con latencia. Tipica solución internet basada en web, o cruces
web-activex o Applets java (también soap, etc), en la que por lo general
se pueden implementar aplicaciones síncronas pero con latencia (debido
al ancho de banda, carga de las redes, servidores, etc), y con menor nivel
de interactividad.
______________________________________________________________________
© Moisés Daniel Díaz Toledano. WebSite: www.moisesdaniel.com
Pág. 6
- 7. Arquitectura de los Sistemas de Información.
______________________________________________________________________
?? Asíncronos ligeros. Sistemas en los que la comunicación se basa en
sistemas de mensajes asíncronos, en los que las respuestas pueden tardar
en originarse incluso minutos. Por ejemplo: JMS, MSMQ, etc.
?? Asíncronos pesados. Sistemas en los que la comunicación se basa en
correo electrónico, ftp, http, etc. En un primer paso se envía la
información y cuando esta es procesada, el ‘ gestor de integración’ envía
a su vez un mensaje al remitente.
Estructura común.
Como hemos podido ver en esta sección ambos patrones tienen similitudes notables en
su estructura, compartiendo algunos componentes, que además se encuentran en
básicamente todos los sistemas de información, veamos ahora con más detalle sus
componentes periféricos.
3.- Componentes Comunes.
En la sección anterior hemos hablado de los patrones Integrador y Distribuidor
centrándonos sobre todo en su mecánica interna, esto es, los elementos interiores de un
sistema de información. Aquí hablaremos de los elementos periféricos, es decir aquellos
que se encuentran en los límites del propio sistema, y/o que tienen que interaccionar con
el exterior del sistema de información.
? Componente Periférico: Interfaz Productor-Sistema.
Problema:
Se deben de habilitar mecanismos para que la información que existe en el
dominio del problema pueda ser incorporada al sistema y así ser procesada por éste.
Fuerzas y Contexto:
? El productor produce información.
?
? Esta ha de ser recogida y tratada por el sistema.
?
? Se ha de formatear la información para su correcto tratamiento por el sistema.
?
? Deben de existir mecanismos que envien estos paquetes de información a los
?
componentes del sistema adecuados para su tratamiento. En la medida de lo
posible estos mecanismos deben de ser transparentes para el usuario productor.
Solución:
Se construye un elemento (subsistema, aplicación, componente, ...) que asuma
este rol teniendo como cometidos básicos:
? Generar los propios paquetes de información a través de la interacción con el
?
usuario (por lo general a esta actividad se le suele denominar ‘Grabación de
Datos’ ).
______________________________________________________________________
© Moisés Daniel Díaz Toledano. WebSite: www.moisesdaniel.com
Pág. 7
- 8. Arquitectura de los Sistemas de Información.
______________________________________________________________________
? Establecer mecanismos de interacción con el productor para que éste pueda
?
incorporar al sistema paquetes de información ya creados o generados por
otros medios.
? Transmitir los paquetes de información a los componentes del sistema
?
construidos para su gestión y tratamiento.
Comentarios adicionales:
Esta es la parte sensitiva del sistema.
Ejemplos: (en el siguiente punto todo esto se verá con mayor detalle)
? En un contexto de una aplicación cliente/servidor, este rol podría ser modelado
?
por una aplicación cliente de escritorio en el que el usuario-productor pudiese
realizar la grabación de datos (es decir la introducción de los mismos). Por lo
general en este tipo de contextos, la plataforma de desarrollo hace que la
generación y transmisión de la información a otros componentes del sistema sea
casi transparente incluso al programador.
? En un contexto de una aplicación local realizada con un gestor de base de datos
?
como el Access, está implementada ya toda esta funcionalidad y el interfaz en sí
son formularios presentados al usuario por el propio gestor. Éstos además se
pueden realizar de una forma bastante automatizada.
? En un contexto con un sistema distribuido por áreas geográficas más extensas, se
?
deben de elegir protocolos de transmisión de los paquetes así como formatos
para estructurar dicha información para que pueda ser tratada por el sistema. La
información en muchas ocasiones proviene de algún otro sistema que genera un
paquete de información (generalmente un fichero) para nuestro sistema y que
utiliza los mecanismos habilitados (aplicación interfaz) para interactuar con el
sistema.
? Componente Común: Interfaz Sistema-Consumidor.
Problema:
Se deben de habilitar mecanismos para que la información que existe en el
sistema de información pueda ser enviada y procesada por el consumidor. Lo cual
significa por lo general tener la posibilidad de visualizar algunas representaciones de la
información solicituda (grid de datos, listados, informes, gráficos, ...) y de poder
exportar dicha información a otros sistemas.
Fuerzas y Contexto:
? El consumidor solicita y utiliza la información que tiene el sistema.
?
? La información que se le entrega al consumidor puede ser procesada, filtrada, etc
?
antes de su entrega.
? La información debe de ser entregada de una forma estructura (ya sea visual o en
?
forma de ficheros, etc).
? Deben de existir mecanismos para que la información distribuida al consumidor
?
pueda ser procesada por éste, ya sea por medio de mecanismos abilitados por el
propio sistema, o mediante la exportación de la información a otros entornos.
______________________________________________________________________
© Moisés Daniel Díaz Toledano. WebSite: www.moisesdaniel.com
Pág. 8
- 9. Arquitectura de los Sistemas de Información.
______________________________________________________________________
Solución:
Se construye un elemento (subsistema, aplicación, componente, ...) que asuma
este rol teniendo como cometidos básicos:
? Recibir los paquetes de información generados por el sistema.
?
? Establecer mecanismos para que el consumidor pueda interactuar con la
?
información del sistema.
? Establecer mecanismos para poder exportar la información a otros sistemas.
?
Comentarios adicionales:
Este rol suele ser implementado por componentes que establecen una
comunicación de baja latencia con los mecanismos de distribución de información.
Se podría considerar como la parte ‘actuadora’del sistema (nervioso) digital.
Ejemplos: (en el siguiente punto todo esto se verá con mayor detalle)
? Partiendo de un contexto con una aplicación cliente/servidor en las dependencias
?
locales de una empresa. La interfaz es una aplicación de escritorio desarrollada
con lenguajes y plataformas que hacen invisible incluso al desarrollador todas
las cuestiones de gestión de envío/recepción de información. El programa en el
ordenador cliente, accede a las base de datos de la empresa y muestra el
resultado de las consultas en la pantalla del usuario permitiéndole a éste realizar
algunas labores definidas de procesamiento, así como la exportación de los datos
obtenidos a formatos de Hojas de Cálculos y gestores de bases de datos
personales o de poca envergadura.
? Partiendo de un contexto basado en tecnologías internet. El componente interfaz
?
con el usuario es un navegador que presenta e interpreta la información y
elementos adicionales de interfaz codificados en html, o algún otro lenguaje de
scripts. Podríamos añadir plug-ins al navegador para proveer de mayor riqueza
el entorno cliente de ejecución.
? Componente Común: Almacén Central de Información.
Problema:
Almacenar grandes cantidades de información de forma que sea fácil tanto
integrar más información (generada por los productores de información), como
distribuir ésta (hacia los consumidores de información).
Fuerzas y Contexto:
? Almacenar enormes cantidades de información.
?
? Modificar la información almacenada.
?
? Extraer y distribuir la información que poseemos.
?
? Permitir mútiples interacciones simultáneas con el conjunto de datos.
?
Solución:
Utilizar un componente o sistema que pueda asumir este rol. Existen varias
opciones, pero la utilizada casi siempre son los sistemas gestores de bases de datos
(comúnmente llamados bases de datos). Estos son un conjunto de programas o
componentes que nos permiten almacenar, modificar, y extraer información de una base
de datos, que no es más que un conjunto enorme de información organizado en registros
y ficheros. Existen diferentes tipos de sistemas gestores de bases de datos, (ranging
from) recorriendo desde aquellos sistemas pequeños que funcionan en un ordenador
personal hasta enormes sistemas que se ejecutan en Mainframes.
______________________________________________________________________
© Moisés Daniel Díaz Toledano. WebSite: www.moisesdaniel.com
Pág. 9
- 10. Arquitectura de los Sistemas de Información.
______________________________________________________________________
4.- Arquitectura.
¿Cómo podemos mapear todo lo que llevamos aprendido hasta ahora en las
arquitecturas estándar actuales?
Empecemos diciendo que vamos a distinguir aquí entre 2 tipos de arquitecturas: lógica ,
formada por componentes, subsistemas y programas, y física, formada por
computadores o grupos de ellos.
Arquitectura Lógica.
Actualmente la arquitectura lógica sigue un esquema básico formado por 3 capas
primarias: interfaz, lógica de dominio, y fuente de datos.
Interfaz de
Usuario
Lógica de
Dominio
Fuente de Datos
Este esquema, aunque útil, se queda corto para reflejar la arquitectura lógica de las
aplicaciones empresariales actuales. Podemos, sin embargo, hacerlo evolucionar a uno
mucho más preciso y consistente con la realidad actual. Este segundo esquema tiene 5
capas lógicas: interfaz, lógica de interfaz, lógica de dominio, mapeo sobre datos
(interfaz con la fuente de datos), y almacén de datos. Esencialmente, este modelo lo que
hace es añadir una capa mediadora entre las capas primarias para obtener mayor
indepencia entre estas últimas y permitir su evolución o sustitución de forma autónoma,
disminuyendo considerablemente su impacto en el resto del sistema.
El siguiente esquema muestra el paso a una arquitectura de 5 capas lógicas:
Presentación
Interfaz de
Usuario Lógica de
interfaz
Lógica de
Lógica de dominio
Dominio Mapeo sobre
datos
Fuente de Datos Almacén de datos
______________________________________________________________________
© Moisés Daniel Díaz Toledano. WebSite: www.moisesdaniel.com
Pág. 10
- 11. Arquitectura de los Sistemas de Información.
______________________________________________________________________
Teniendo ya una arquitectura de 5 capas lógicas, ¿cómo podemos mapear los procesos y
componentes vistos hasta ahora en esta arquitectura? El siguiente diagrama muestra la
solución:
En este esquema se representan las 5 capas lógicas que hemos explicado, los procesos
Info-Integrador e Info-Distribuidor, el conjunto de componentes que forman parte de los
mismos, así como los flujos de información que se producen.
Arquitectura física.
Esta arquitectura de 5 capas lógicas se traduce a la hora de su implantación física en una
arquitectura de 1, 2 ó 3 capas. Las soluciones monopuestos (es decir una única capa
físca, por ejemplo una aplicación realizada en Access que funcione sobre una base de
datos local), no son frecuentes en los entornos empresariales donde las aplicaciones
suelen ser complejas, multipuestos y donde los datos suelen estar protegidos y requerir
un considerable esfuerzo de administración. Así que las arquitecturas basadas en 2 y 3
capas físicas las más frecuentes en entornos empresariales.
Ahondando en las arquitecturas de 2-3 capas físicas, diremos que se articulan
básicamente en 2 escenarios, cada uno con su distribución de capas lógicas,
componentes, tecnologías etc.
______________________________________________________________________
© Moisés Daniel Díaz Toledano. WebSite: www.moisesdaniel.com
Pág. 11
- 12. Arquitectura de los Sistemas de Información.
______________________________________________________________________
Estos escenarios son: el entorno web, y la arquitectura cliente/servidor.
Vamos a representarlo gráficamente asumiendo lo siguiente: Cada rectángulo representa
un nodo, es decir un ordenador, al que le asociamos un rectángulo de angulos
redondeados donde hemos escrito las capas lógicas que contendría, así como las
diferentes tecnologías que podemos usar para su implementación. Las flechas gruesas
representan conexiones entre estos nodos, y tienen así mismo escrito los protocolos y
sucedáneos que podemos usar en estas comunicaciones.
-Arquitecturas basadas en Web:
En el diagrama se puede observar dos variantes distintas, una formada por navegadores,
servidor web y base de datos, y otra en la que se añadiría un servidor de aplicaciones.
Las arquitecturas web han representado uno de los más grandes cambios en las
aplicaciones empresariales de esta última década. Éstas nos han traido una gran cantidad
de beneficios como: acceso universal mediante navegadores internet (IE y Netscape),
estandarización de protocolos de comunicación (http, Soap, etc), estandarización de
lenguajes de representación de interfaces gráficos (html), disminución de costes al
eliminar casi todos los gastos asociados al mantenimiento del software en los PC.
______________________________________________________________________
© Moisés Daniel Díaz Toledano. WebSite: www.moisesdaniel.com
Pág. 12
- 13. Arquitectura de los Sistemas de Información.
______________________________________________________________________
-Arquitecturas Cliente/Servidor:
En este tipo de arquitectura se supone que los clientes y los servidores se encuentran
dentro de una misma red corporativa.
Las ventajas que proporciona esta aproximación son variadas, como por ejemplo la
posibilidad de crear clientes con interfaces mucho más ricas (muy útiles para la
grabación y manipulación de datos), utilizar la capacidad de procesamiento de los PCs,
una mayor agilidad en las aplicaciones ya que al correr sobre redes privadas suele haber
un mayor ancho de banda para cada estación cliente.
Presenta así mismo varios desventajas en comparación con las arquitecturas basadas en
web: muchísimo mayor coste de mantenimiento debido a las aplicaciones que se tienen
que construir, distribuir etc en las estaciones clientes, mayores restricciones de
conectividad que la web, ya que esta última (y sus tecnologías asociadas) se han
convertido en un medio ubicuo y omnipresente. Por lo general siempre que se puede se
suele optar por arquitecturas web por el gran número de ventajas que conllevan.
Final.
Cada problema es diferente, y también cada solución. Se han presentado aquí una serie
de patrones, componente y arquitecturas que poco suponen de nuevo, pero que sí que
pretenden dar una visión estructura y clara del problema (y la solución) de crear
Sistemas de Información Empresariales. Espero que sean de ayuda y sirvan de guía a la
hora de afrontar un proyecto, siempre teniendo en cuenta que no hay patrón,
arquitectura, herramienta ni artículo que sustituya al cerebro humano (por ahora ;-) ).
______________________________________________________________________
© Moisés Daniel Díaz Toledano. WebSite: www.moisesdaniel.com
Pág. 13
- 14. Arquitectura de los Sistemas de Información.
______________________________________________________________________
Bibliografía y lecturas recomendadas:
? ‘
? Metapatrones. Una nueva aproximación a los patrones de diseño’ Moisés.
Daniel Díaz Toledano. Url
o http://www.moisesdaniel.com/es/wri/metapatrones.html
? ‘
? Patterns of Enterprise Application Architecture’ Martin Fowler. Url:
,
o http://martinfowler.com/isa/index.html
? ‘
? Client/Server: Past, Present and Future’ George Schussel. Url:
,
o http://www.sei.cmu.edu/str/descriptions/clientserver_body.html
? ‘
? Client/Server architectures for Business Information Systems. A pattern
Language’ Renzel y Keller, Plop’ Url:
, 97.
o http://jerry.cs.uiuc.edu/~plop/plop97/Proceedings/renzel.pdf
? ‘
? Architecture Patterns for Business Systems’ por Lorraine Boydj, Plop’ Url:
, 97,
o http://jerry.cs.uiuc.edu/~plop/plop97/Proceedings/boyd.pdf
? ‘ Ball of Mud’ Foote y Yoder, Url:
? Big ,
o http://www.laputan.org/mud/
? ‘
? Application Design Guidelines: From N-Tier to .NET’ by Chappell, Kirk. Url:
,
o http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/dnbda/html/bdadotnetarch001.asp
? ‘
? J2EE, Java 2 Platform, Enterprise Edition’ Url:
,
o http://java.sun.com/j2ee/
______________________________________________________________________
© Moisés Daniel Díaz Toledano. WebSite: www.moisesdaniel.com
Pág. 14