Arquitectura de los Sistemas de Informacin.

______________________________________________________________________

______________________________________________________________________

Arquitectura de los Sistemas de Informacin Empresariales.

Una visin basada en Patrones. 1.- Introduccin. 2.- Requisitos y Pocesos Principales de los Sistemas de Informacin. 3.- Componentes Comunes. 4.- Arquitectura. ______________________________________________________________________ ... you can see a predefined structure that remains from the source content to the resulting content... Moiss D. Daz. 1.- Introduccin. Definicin. Existen muchos sistemas software, y en todos ellos la informacin est presente, sin embargo en los sistemas de los que aqu vamos a hablar la informacin es el elemento fundamental ya que su cometido principal radica precisamente en la gestin de este intangible elemento. Es por ello por lo que los problemas fundamentales que estos sistemas tienen que resolver estn relacionados con la representacin de la informacin, su persistencia, la recepcin y transmisin de los datos, y los medios que nos sirven para transmitirla y comunicarla. Qu es por tanto un sistema de informacin? Podemos definir un sistema de informacin como un conjunto de componentes (o elementos) que operan conjuntamente para capturar, procesar, almacenar y distribuir informacin. Esta informacin se utiliza generalmente para la toma de decisiones, la coordinacin, el control, y el anlisis en una organizacin. En muchas ocasiones la gestin de dicha informacin es el objetivo primario del sistema. Caractersticas Concretando un poco ms, cules son las caractersitcas fundamentales de los Sistemas de Informacin?: ? Gestionan grandes cantidades de datos persistentes. (Precisamente los datos que ? almacena). ? Gestionan el acceso concurrente a la informacin de muchos usuarios. (Usuarios ? que producen o consumen datos que gestiona el sistema). ? Sus interfaces grficos vienen en gran medida ? definidos por la informacin que el sistema gestiona (por cierto en innumerables pantallas de formularios e informes). ? Se integran con muchas otras aplicaciones empresariales y ofimticas. ? ______________________________________________________________________ Moiss Daniel Daz Toledano. Pg. 1 WebSite: www.moisesdaniel.com

Arquitectura de los Sistemas de Informacin. ______________________________________________________________________

Arquitectura. Se dice que funcin define a la forma o lo que es lo mismo que la estructura o la , arquitectura de cualquier sistema tiene una relacin muy profunda con aquello que tiene que realizar. Por esta razn el conjunto de los sistemas de informacin 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 informacin) y un conjunto de caractersticas comunes (las enumeradas ms 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 artculo entenderemos arquitectura como la estructura que tienen el conjunto de componentes que forman un sistema, as como la relacin entre los mismos. Es decir una visin estructural de alto nivel (pocos detalles) del sistema. Patrones. Podemos definir un patrn de diseo como la representacin abstracta de una buena solucin (o diseo) a un problema concreto que se produce en uno o ms 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 diseo y por lo tanto del software en s. Los patrones han demostrado ser una forma idnea para transmitir conocimiento estructural, es decir de diseo, como es, por ejemplo, la arquitectura de los sistemas, el tema que aqu estamos tratando. Por todas estas razones en este artculo presentar los diferentes elementos mediante una estructura documental inspirada en los patrones de diseo, 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 travs de los lenguajes de patrones podemos describir de forma completa (o casi completa) los sistemas que se dan en dicho contexto, o vindolo desde otra ptica, resolver los diferentes problemas que aparecen en un contexto especfico. Este artculo constituye en cierta forma un lenguaje de patrones que describe los componentes y procesos bsicos de los sistemas de informacin. ______________________________________________________________________ Moiss Daniel Daz Toledano. Pg. 2 WebSite: www.moisesdaniel.com

Arquitectura de los Sistemas de Informacin. ______________________________________________________________________

2.- Requisitos y Pocesos Principales de los Sistemas de Informacin. Actores Decamos anteriormente que una de las caractersticas de los sistemas de informacin es la gestin que hacen del acceso de los usuarios a los datos del sistema. Este acceso se puede producir por diferentes motivos: para aadir, modificar o borrar datos, para consultarlos o para gestionar el propio sistema de informacin. Segn el tipo de acceso tendremos diferentes usuarios o actores: productores de informacin, consumidores de informacin, y gestores del sistema. Un actor es un elemento externo al sistema que interacta con l, ya sea una persona o un programa de ordenador.

Procesos bsicos Al igual que identificamos 3 tipos de actores tambin tenemos 3 tipos de funciones bsicas a realizar por un sistema de informacin: ? Integrar informacin en el sistema. Los datos originales para esta actividad sern ? proporcionados por los productores de informacin. Este proceso puede conllevar el procesamiento de dichos datos antes de ser almacenados en el sistema . ? Distribuir informacin a los usuarios. Evidentemente a los consumidores de ? informacin. Tambin 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 informacin, estableces permisos respecto a su actividad con respecto al sistema, etc. No olvidemos que cualquier sistema de informacin es un sistema real por lo que requiere administracin, 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 interacta con l. Dejndo esto claro pasemos a analizar con mayor profundidad los dos procesos que tienen mayor impacto arquitectnico.

______________________________________________________________________ Moiss Daniel Daz Toledano. Pg. 3 WebSite: www.moisesdaniel.com

Arquitectura de los Sistemas de Informacin. ______________________________________________________________________

Integracin de la informacin. La integracin de informacin es uno de los procesos fundamentales que debe de realizar un sistema de informacin. 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 informacin significa por lo generar procesar la datos que generan los productores (que podr venir en forma de parmetros de procedimientos, variables, mensajes, ficheros, emails, etc) e incorporarla a nuestros almacenes de datos (por lo general bases de datos relacionales). Desgranndolo un poco ms: ? ? Recepcionar paquete de informacin (que es como vamos a denominar genricamente a los datos agrupados y estructurados). El sistema puede contener mdulos que generen los propios paquetes de informacin a travs de la informacin recogida en la interaccin con los actores ? ? Verificar paquete de informacin (ejemplo en un email: verificar remitentes, restricciones sobre adjuntos, etc). ? ? Verificar validez estructural de los datos enviados (por ejemplo en un xml, sera validarlo contra su xschema), as como verificar permisos (del productor con respecto a los datos). ? ? Integrar (y transformar) la informacin en algn/os almacenes de datos (por lo general significar incorporar dicha informacin en algn conjunto de tablas de alguna base de datos relacional). (Este punto puede incluir procesos de verificacin entre el productor y el tipo de datos que est enviando). ? ? Generar respuestas concernientes al procesamiento de dichos paquetes a los productores de dicha informacin. Este proceso quedara de la siguiente forma si lo documentamos como un patrn: ? Patrn Integrador. Proceso Info-Integrador. Problema: Incorporar al sistema la informacin generada por los actores Productores de informacin. Fuerzas y Contexto: Fuerzas bsicas. Las fuerzas son los propios requisitos funcionales: necesidades de negocio (integrar informacin, requisito funcional primario), validaciones estructurales, de contenido, generacin de respuestas, etc.

______________________________________________________________________ Moiss Daniel Daz Toledano. Pg. 4 WebSite: www.moisesdaniel.com

Arquitectura de los Sistemas de Informacin. ______________________________________________________________________

Solucin: Crear una estructura de componentes que refleje, mapee y cubra los requisitos funcionales (fuerzas bsicas) de incorporar la informacin al Sistema. Existiendo una correspondencia directa entre cada requisito del proceso con un componente.
Interaccin C lien te G estor de Integracin

Receptor M ensajes

Verificador M ensajes

Verificador Datos e Info

G enerador Respuesta

Integrador de Informacin M ensaje [Datos[Info]]

Base de Datos

Distribucin de la informacin. La distribucin de la informacin es uno de los procesos fundamentales que debe de realizar un sistema de informacin. De nada servira recabar grandes (ni pequeas) cantidades de informacin si esta no fuese despus a ser distribuida (despus 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 tendrn ni las mismas necesidades ni los mismos privilegios. Existirn usuarios con capacidad para obtener cualquier tipo de informacin, mientras que otro slo tendrn acceso a una parte de la misma. As mismo los formatos en los que se tendr que distribuir dicha inforamacin, pueden ser muy distintos, al igual que los protocolos que se usen para su transmisin. Por tanto, es la distribucin de la informacin un proceso complejo que puede subdividirse a su vez en varios subprocesos: ? ? Recepcionar peticin de informacin. El sistema puede contener mdulos que representen dicha informacin directamente al consumidor de la misma. ? ? Validacin de la peticin de informacin. ? ? Recoleccin de la informacin. ? ? Formateo-Procesamiento de la misma. ? ? Envo de la informacin al consumidor. Cuyo patrn es el siguiente: ______________________________________________________________________ Moiss Daniel Daz Toledano. Pg. 5 WebSite: www.moisesdaniel.com

Arquitectura de los Sistemas de Informacin. ______________________________________________________________________

? Patrn Info-Distribuidor. Problema: Distribuir informacin a los usuarios. Fuerzas y Contexto: Fuerzas bsicas. Las fuerzas son los propios requisitos funcionales: necesidades de negocio (distribuir informacin, requisito funcional primario), validaciones de usuario y peticin (restricciones), formateo de la informacin, envo de la misma, etc. Solucin:
Interaccin cliente. Representa info Gestor de Distribucin

Receptor Peticin

Verificador Restricciones

Recolector Informacin

Formateador Informacin

. . . Peticin de Informacin

Base de Datos 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 bsicamente 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 interaccin Como nota adicional, har un apunte sobre los modelos de interaccin entre un sistema y sus usuarios: ? ? Sncrono. El mdulo de interaccin cliente y la integracin-distribucin de informacin deben tener una comunicacin sncrona. El conjunto de todas las interacciones entre los componentes tienen que ser de muy baja latencia. Estas soluciones permiten a la perfeccin entornos muy completos de grabacin de datos, envo de grandes cantidades de informacin, etc. Tpica solucin 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 (tambin soap). ? ? Sncrono con latencia. Tipica solucin internet basada en web, o cruces web-activex o Applets java (tambin soap, etc), en la que por lo general se pueden implementar aplicaciones sncronas pero con latencia (debido al ancho de banda, carga de las redes, servidores, etc), y con menor nivel de interactividad. ______________________________________________________________________ Moiss Daniel Daz Toledano. Pg. 6 WebSite: www.moisesdaniel.com

Arquitectura de los Sistemas de Informacin. ______________________________________________________________________

??

??

Asncronos ligeros. Sistemas en los que la comunicacin se basa en sistemas de mensajes asncronos, en los que las respuestas pueden tardar en originarse incluso minutos. Por ejemplo: JMS, MSMQ, etc. Asncronos pesados. Sistemas en los que la comunicacin se basa en correo electrnico, ftp, http, etc. En un primer paso se enva la informacin y cuando esta es procesada, el gestor de integracin enva a su vez un mensaje al remitente.

Estructura comn. Como hemos podido ver en esta seccin ambos patrones tienen similitudes notables en su estructura, compartiendo algunos componentes, que adems se encuentran en bsicamente todos los sistemas de informacin, veamos ahora con ms detalle sus componentes perifricos.

3.- Componentes Comunes. En la seccin anterior hemos hablado de los patrones Integrador y Distribuidor centrndonos sobre todo en su mecnica interna, esto es, los elementos interiores de un sistema de informacin. Aqu hablaremos de los elementos perifricos, es decir aquellos que se encuentran en los lmites del propio sistema, y/o que tienen que interaccionar con el exterior del sistema de informacin. ? Componente Perifrico: Interfaz Productor-Sistema. Problema: Se deben de habilitar mecanismos para que la informacin que existe en el dominio del problema pueda ser incorporada al sistema y as ser procesada por ste. Fuerzas y Contexto: ? El productor produce informacin. ? ? Esta ha de ser recogida y tratada por el sistema. ? ? Se ha de formatear la informacin para su correcto tratamiento por el sistema. ? ? Deben de existir mecanismos que envien estos paquetes de informacin 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. Solucin: Se construye un elemento (subsistema, aplicacin, componente, ...) que asuma este rol teniendo como cometidos bsicos: ? Generar los propios paquetes de informacin a travs de la interaccin con el ? usuario (por lo general a esta actividad se le suele denominar Grabacin de Datos ).

______________________________________________________________________ Moiss Daniel Daz Toledano. Pg. 7 WebSite: www.moisesdaniel.com

Arquitectura de los Sistemas de Informacin. ______________________________________________________________________ ? Establecer mecanismos de interaccin con el productor para que ste pueda ? incorporar al sistema paquetes de informacin ya creados o generados por otros medios. ? Transmitir los paquetes de informacin a los componentes del sistema ? construidos para su gestin 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 aplicacin cliente/servidor, este rol podra ser modelado ? por una aplicacin cliente de escritorio en el que el usuario-productor pudiese realizar la grabacin de datos (es decir la introduccin de los mismos). Por lo general en este tipo de contextos, la plataforma de desarrollo hace que la generacin y transmisin de la informacin a otros componentes del sistema sea casi transparente incluso al programador. ? En un contexto de una aplicacin 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 adems se pueden realizar de una forma bastante automatizada. ? En un contexto con un sistema distribuido por reas geogrficas ms extensas, se ? deben de elegir protocolos de transmisin de los paquetes as como formatos para estructurar dicha informacin para que pueda ser tratada por el sistema. La informacin en muchas ocasiones proviene de algn otro sistema que genera un paquete de informacin (generalmente un fichero) para nuestro sistema y que utiliza los mecanismos habilitados (aplicacin interfaz) para interactuar con el sistema. ? Componente Comn: Interfaz Sistema-Consumidor. Problema: Se deben de habilitar mecanismos para que la informacin que existe en el sistema de informacin pueda ser enviada y procesada por el consumidor. Lo cual significa por lo general tener la posibilidad de visualizar algunas representaciones de la informacin solicituda (grid de datos, listados, informes, grficos, ...) y de poder exportar dicha informacin a otros sistemas.

Fuerzas y Contexto: ? El consumidor solicita y utiliza la informacin que tiene el sistema. ? ? La informacin que se le entrega al consumidor puede ser procesada, filtrada, etc ? antes de su entrega. ? La informacin debe de ser entregada de una forma estructura (ya sea visual o en ? forma de ficheros, etc). ? Deben de existir mecanismos para que la informacin distribuida al consumidor ? pueda ser procesada por ste, ya sea por medio de mecanismos abilitados por el propio sistema, o mediante la exportacin de la informacin a otros entornos. ______________________________________________________________________ Moiss Daniel Daz Toledano. Pg. 8 WebSite: www.moisesdaniel.com

Arquitectura de los Sistemas de Informacin. ______________________________________________________________________

Solucin: Se construye un elemento (subsistema, aplicacin, componente, ...) que asuma este rol teniendo como cometidos bsicos: ? Recibir los paquetes de informacin generados por el sistema. ? ? Establecer mecanismos para que el consumidor pueda interactuar con la ? informacin del sistema. ? Establecer mecanismos para poder exportar la informacin a otros sistemas. ? Comentarios adicionales: Este rol suele ser implementado por componentes que establecen una comunicacin de baja latencia con los mecanismos de distribucin de informacin. Se podra considerar como la parte actuadoradel sistema (nervioso) digital. Ejemplos: (en el siguiente punto todo esto se ver con mayor detalle) ? Partiendo de un contexto con una aplicacin cliente/servidor en las dependencias ? locales de una empresa. La interfaz es una aplicacin de escritorio desarrollada con lenguajes y plataformas que hacen invisible incluso al desarrollador todas las cuestiones de gestin de envo/recepcin de informacin. 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 permitindole a ste realizar algunas labores definidas de procesamiento, as como la exportacin de los datos obtenidos a formatos de Hojas de Clculos y gestores de bases de datos personales o de poca envergadura. ? Partiendo de un contexto basado en tecnologas internet. El componente interfaz ? con el usuario es un navegador que presenta e interpreta la informacin y elementos adicionales de interfaz codificados en html, o algn otro lenguaje de scripts. Podramos aadir plug-ins al navegador para proveer de mayor riqueza el entorno cliente de ejecucin. ? Componente Comn: Almacn Central de Informacin. Problema: Almacenar grandes cantidades de informacin de forma que sea fcil tanto integrar ms informacin (generada por los productores de informacin), como distribuir sta (hacia los consumidores de informacin). Fuerzas y Contexto: ? Almacenar enormes cantidades de informacin. ? ? Modificar la informacin almacenada. ? ? Extraer y distribuir la informacin que poseemos. ? ? Permitir mtiples interacciones simultneas con el conjunto de datos. ? Solucin: 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 (comnmente llamados bases de datos). Estos son un conjunto de programas o componentes que nos permiten almacenar, modificar, y extraer informacin de una base de datos, que no es ms que un conjunto enorme de informacin organizado en registros y ficheros. Existen diferentes tipos de sistemas gestores de bases de datos, (ranging from) recorriendo desde aquellos sistemas pequeos que funcionan en un ordenador personal hasta enormes sistemas que se ejecutan en Mainframes. ______________________________________________________________________ Moiss Daniel Daz Toledano. Pg. 9 WebSite: www.moisesdaniel.com

Arquitectura de los Sistemas de Informacin. ______________________________________________________________________

4.- Arquitectura. Cmo podemos mapear todo lo que llevamos aprendido hasta ahora en las arquitecturas estndar actuales? Empecemos diciendo que vamos a distinguir aqu entre 2 tipos de arquitecturas: lgica , formada por componentes, subsistemas y programas, y fsica, formada por computadores o grupos de ellos. Arquitectura Lgica. Actualmente la arquitectura lgica sigue un esquema bsico formado por 3 capas primarias: interfaz, lgica de dominio, y fuente de datos.
Interfaz de Usuario

Lgica de Dominio

Fuente de Datos

Este esquema, aunque til, se queda corto para reflejar la arquitectura lgica de las aplicaciones empresariales actuales. Podemos, sin embargo, hacerlo evolucionar a uno mucho ms preciso y consistente con la realidad actual. Este segundo esquema tiene 5 capas lgicas: interfaz, lgica de interfaz, lgica de dominio, mapeo sobre datos (interfaz con la fuente de datos), y almacn de datos. Esencialmente, este modelo lo que hace es aadir una capa mediadora entre las capas primarias para obtener mayor indepencia entre estas ltimas y permitir su evolucin o sustitucin de forma autnoma, disminuyendo considerablemente su impacto en el resto del sistema. El siguiente esquema muestra el paso a una arquitectura de 5 capas lgicas:
Presentacin Interfaz Usuario de
Lgica de interfaz

Lgica Dominio

de

Lgica de dominio Mapeo sobre datos Almacn de datos

Fuente de Datos

______________________________________________________________________ Moiss Daniel Daz Toledano. Pg. 10 WebSite: www.moisesdaniel.com

Arquitectura de los Sistemas de Informacin. ______________________________________________________________________

Teniendo ya una arquitectura de 5 capas lgicas, cmo podemos mapear los procesos y componentes vistos hasta ahora en esta arquitectura? El siguiente diagrama muestra la solucin:

En este esquema se representan las 5 capas lgicas 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 informacin que se producen.

Arquitectura fsica. Esta arquitectura de 5 capas lgicas se traduce a la hora de su implantacin fsica en una arquitectura de 1, 2 3 capas. Las soluciones monopuestos (es decir una nica capa fsca, por ejemplo una aplicacin 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 administracin. As que las arquitecturas basadas en 2 y 3 capas fsicas las ms frecuentes en entornos empresariales.

Ahondando en las arquitecturas de 2-3 capas fsicas, diremos que se articulan bsicamente en 2 escenarios, cada uno con su distribucin de capas lgicas, componentes, tecnologas etc. ______________________________________________________________________ Moiss Daniel Daz Toledano. Pg. 11 WebSite: www.moisesdaniel.com

Arquitectura de los Sistemas de Informacin. ______________________________________________________________________

Estos escenarios son: el entorno web, y la arquitectura cliente/servidor. Vamos a representarlo grficamente asumiendo lo siguiente: Cada rectngulo representa un nodo, es decir un ordenador, al que le asociamos un rectngulo de angulos redondeados donde hemos escrito las capas lgicas que contendra, as como las diferentes tecnologas que podemos usar para su implementacin. Las flechas gruesas representan conexiones entre estos nodos, y tienen as mismo escrito los protocolos y sucedneos 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 aadira un servidor de aplicaciones. Las arquitecturas web han representado uno de los ms grandes cambios en las aplicaciones empresariales de esta ltima dcada. stas nos han traido una gran cantidad de beneficios como: acceso universal mediante navegadores internet (IE y Netscape), estandarizacin de protocolos de comunicacin (http, Soap, etc), estandarizacin de lenguajes de representacin de interfaces grficos (html), disminucin de costes al eliminar casi todos los gastos asociados al mantenimiento del software en los PC.

______________________________________________________________________ Moiss Daniel Daz Toledano. Pg. 12 WebSite: www.moisesdaniel.com

Arquitectura de los Sistemas de Informacin. ______________________________________________________________________

-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 aproximacin son variadas, como por ejemplo la posibilidad de crear clientes con interfaces mucho ms ricas (muy tiles para la grabacin y manipulacin 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 estacin cliente. Presenta as mismo varios desventajas en comparacin con las arquitecturas basadas en web: muchsimo 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 tecnologas 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 nmero de ventajas que conllevan. Final. Cada problema es diferente, y tambin cada solucin. Se han presentado aqu una serie de patrones, componente y arquitecturas que poco suponen de nuevo, pero que s que pretenden dar una visin estructura y clara del problema (y la solucin) de crear Sistemas de Informacin Empresariales. Espero que sean de ayuda y sirvan de gua a la hora de afrontar un proyecto, siempre teniendo en cuenta que no hay patrn, arquitectura, herramienta ni artculo que sustituya al cerebro humano (por ahora ;-) ). ______________________________________________________________________ Moiss Daniel Daz Toledano. Pg. 13 WebSite: www.moisesdaniel.com

Arquitectura de los Sistemas de Informacin. ______________________________________________________________________

Bibliografa y lecturas recomendadas: ? ? Metapatrones. Una nueva aproximacin a los patrones de diseo Moiss . Daniel Daz 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/enus/dnbda/html/bdadotnetarch001.asp ? ? J2EE, Java 2 Platform, Enterprise Edition Url: , o http://java.sun.com/j2ee/

______________________________________________________________________ Moiss Daniel Daz Toledano. Pg. 14 WebSite: www.moisesdaniel.com