ARQUITECTURA DE APLICACIONES Y ARQUITECTURA DE SISTEMAS

ARQUITECTURA DE SISTEMAS Es la organizacin fundamental de un sistema, que incluye sus componentes, las relaciones entre s y el ambiente, y los principios que gobiernan su diseo y evolucin (IEEE). Tipos de arquitecturas existentes

Arquitectura centralizada: sta se centra en un mainframe principal y una serie de terminales, ms conocidas como terminales brutas, pues no realizan ningn proceso, estas terminales solo reciben lo que se teclea y esto es mandado al mainframe, donde se procesa la informacin y se enva a la pantalla para ser mostrada. Arquitectura de servidor de archivos: es la arquitectura en la que se basan las bases de datos como SQL Server, Access y Paradox, consiste en solo un archivo de base de datos, donde solo se requiere un servidor de archivos, y el motor de base de datos se puede ejecutar tanto en el cliente como en el servidor, muy estrechamente unida a la aplicacin cliente. Para Access, Visual Basic y FoxPro este motor se conoce como JET y se compone de varios DLLs que residen en la mquina cliente. Arquitectura cliente-servidor: en esta arquitectura, todas las peticiones realizadas a la base de datos son resueltas por la mquina servidora, no por la mquina cliente. Arquitectura de dos capas: la mayora de las aplicaciones cliente-servidor funcionan bajo una arquitectura de dos capas, esta arquitectura se divide en: frontend (la interfaz del usuario, llamadas a SQL, aplicacin de escritorio, etctera) y Back-end (servidor de Bases de datos SQL, Sistema operativo multitareas, etc.). La capa front-end es la capa en la que el usuario interacta con el computador, y la capa back-end es el servidor de base de datos que reside en un servidor central en un entorno controlado. Desventajas: y La dificultad para manipular los cambios en el front-end al realizar cambios en la base de datos. si se efecta un cambio, varias estaciones de trabajo

y y

clientes tendran que actualizarse con una nueva versin del front-end simultneamente al cambio en la base de datos. lo cual no es nada sencillo y menos cuando las aplicaciones cliente estn geogrficamente dispersas. La dificultad de compartir procesos comunes. La seguridad, el back-end otorga privilegios a todos los objetos de la base de datos y a los usuarios, y el front-end, aunque los usuarios pueden acceder a la base de datos por medio de su identificacin, sta tiene dos problemas: como ninguno de los objetos en la base de datos es segura, cualquier usuario pudiese tener acceso total a la misma con alguna otra herramienta de front-end (Como Excel, Access, etctera.), y la implantacin de la seguridad deber ser desarrollada, probada y mantenida en absolutamente toda la red (no importa dnde se encuentren las estaciones cliente).

Arquitectura de tres capas: o de N capas, se define como un modelo de servicios, esta arquitectura provee una capa adicional explcita para las reglas de los negocios que se sita entre las capas front-end y back-end, donde se encapsula el proceso de negocios asociado con el sistema, y lo separa de la presentacin y del cdigo de la base de datos. Modelo de servicios: una capa puede hacer solicitudes o devolver respuestas a un proceso desde su propia capa, inmediatamente arriba de su capa o inmediatamente abajo de su capa. Normalmente, la nica comunicacin que nunca ocurre es la de una aplicacin con el servicio de datos. En una arquitectura tradicional, una capa puede comunicarse slo con otra directamente arriba o abajo de ella. En este otro caso los servicios de usuarios, de negocios y de datos pueden comunicarse con ellos mismos. Este modelo se conoce como el modelo de servicios, dado que, lejos del comportamiento de un modelo de capas, cualquier servicio puede invocar a otro dentro de su capa.

ARQUITECTURA DE APLICACIONES Es el diseo de aplicaciones particularmente de tipo cliente-servidor, y la manera como stas estn diseadas tanto fsica como lgicamente. En el diseo fsico se especifica donde se encontrarn las piezas de la aplicacin como computadores, discos, cables de red, entre otros.

El diseo de la parte lgica o conceptual es la que especifica la estructura de la aplicacin y sus componentes, incluyendo el orden de procesamiento, mantenimiento y seguimiento comunes en sistemas organizacionales.

Arquitectura lgica: Para este diseo se recomienda una arquitectura de tres capas o de N capas, esta arquitectura provee una separacin entre la lgica de presentacin, lgica de negocios y lgica de acceso a datos.

Lgica de presentacin:

Los componentes de interfaz de usuario manejan la interaccin con el usuario, estos componentes despliegan informacin al usuario, adquieren datos del usuario, e interpretan los eventos que el usuario genera para ejecutar alguna accin en los datos de negocio, cambiar el estado de la interfaz de usuario o ayudar al usuario a realizar las tareas. Los componentes de interfaz de usuario pueden llevar a cabo el rol de vista o controlador utilizando el patrn modelo vista controlador (MVC). El componente desempea el rol de vista cuando despliega datos a los usuarios. Las funciones de tipo controlador son llamadas cuando el usuario desempea una accin y cambia el estado de datos de negocios relacionados en el proceso de interfaz de usuario. La lgica de presentacin se compone de: y Componentes de interfaz de usuario: estn compuestos por las pantallas, controles y otras tecnologas para dar formato a los datos presentados a los usuarios y validar la informacin ingresada por ellos. Componentes de procesos de usuario: ayudan a orquestar el flujo de interacciones con el usuario, manejando la secuencia de los dilogos o pginas, flujos de estado y proveer de un mecanismo ms simple de implantacin para aplicaciones donde se requiere manejar interacciones de usuarios ms complejas, separadas de los datos del negocio.

Al disear componentes para realizar interfaces de usuario, se deben tomar en cuenta las siguientes consideraciones: y y Facilitar la captura de datos utilizando elementos visuales, validacin y controles apropiados. Capturar los eventos que genera el usuario y llamar a las funciones del controlador que permiten que los componentes de la interfaz de usuario modifiquen la manera en que se presentan los datos. Restringir los tipos de datos que los usuarios pueden introducir.

Realizar el mapeo y transformaciones de la informacin suministrada por los controladores de usuario a los valores que necesitan los dems componentes para ejecutar las acciones. Interpretar las acciones del usuario y convertirlos en un estado en el proceso del usuario o llamar a la funcin que realiza la accin.

Lgica de negocios: Una aplicacin realiza un proceso de negocio que requiere de una o ms tareas, en el caso ms simple, cada tarea puede ser encapsulada en un mtodo y ser llamado de forma sncrona o asncrona, pero para procesos de negocios ms complejos, donde se requieren mltiples tareas y transacciones, es necesario que la aplicacin tenga alguna manera de orquestar las tareas de negocio y guardar el estado hasta que el proceso se haya terminado. Como por ejemplo el uso de un componente de orquestacin llamado BizTalk Server, el cual puede ser utilizado para definir un flujo para el proceso de negocio, y con su funcionalidad de mensajera puede llamar a los componentes de lgica de negocios de la aplicacin para realizar cada tarea a medida que se requiere. La lgica de negocio puede ser diseada para ser utilizada directamente o encapsulada como un servicio y llamada a travs de una interfaz de servicio basada en mensajes, que coordina la conversacin entre las aplicaciones que llaman al servicio y llama al proceso de negocio en herramienta de orquestacin o a los componentes de negocio. Esta capa tambin puede hacer llamados a servicios externos, implantando agentes de servicio para manejar la conversacin requerida para la tarea en particular que es ejecutada por cada servicio que se necesita utilizar. La lgica de negocios se compone de: y Componentes de negocio: implantan la lgica necesaria para llevar a cabo las tareas relacionadas con las reglas del negocio a travs de llamados a funciones. Flujos de procesos de negocios: definen el flujo de conversacin entre los componentes del negocio de la aplicacin y servicios externos, estos procesos pueden ser internos de la aplicacin o pueden involucrar servicios externos en intercambios predefinidos. Agentes de servicios: aslan la necesidad de llamar diferentes servicios desde la aplicacin y pueden proveer de servicios adicionales como transformacin entre lo que la aplicacin necesita consumir y lo que el

servicio externo provee, adems de otras optimizaciones necesarias para consumir el servicio externo. Componentes de entidades de negocios: La mayora de las aplicaciones requieren que los datos sean pasados entre los diferentes componentes o capas. Los datos son utilizados para representar entidades de negocios, como productos u rdenes. Las entidades de negocios utilizadas internamente en las aplicaciones son usualmente estructuras de datos, como DataSets, DataReaders o XML, pero tambin pueden ser representadas como clases dentro de la aplicacin.

Componentes de lgica de negocios y flujo de procesos: A la hora de implantar funcionalidad de negocios es necesario decidir si es necesario orquestar procesos de negocio o si un conjunto de componentes de lgica de negocio ser suficiente. Los flujos de procesos de negocios deben utilizarse para: y y y Manejar procesos que requieren mltiples pasos y transacciones de larga duracin. Integrarse con otros servicios a travs de interfaces basadas en mensajes (Por ejemplo: Recepcin de archivos). Exponer una interfaz que implanta un proceso de negocio que permite que la aplicacin pueda establecer comunicaciones complejas con otros servicios. Construir servicios que necesitan ser expuestos va mltiples tecnologas (como objetos COM, colas de mensajes, archivos, bases de datos, etc.) con lgicas complejas de procesamiento de los mensajes incluyendo mltiples aplicaciones u organizaciones. Tomar ventaja de la amplia variedad de adaptadores y conectores para mltiples tecnologas disponibles para las herramientas de orquestacin.

Se utilizan solo componentes de lgica de negocios cuando: y y y No es necesario exponer una interfaz basada en mensajes o implantar un proceso de negocio asncrono. Es necesario encapsular la funcionalidad y lgica de forma que pueda ser reutilizada desde varios procesos de negocio. La lgica de negocios que necesita implantarse puede requerir un procesamiento bastante intensivo o necesita un control minucioso de las estructuras de datos y APIs.

Es necesario tener un control minucioso de las estructuras de datos y flujo de la lgica.

Diseo de componentes de la lgica de negocios: Los componentes de la lgica de negocios son el origen de las transacciones, estos componentes implantan las reglas de negocio en patrones diversos, adems aceptan y devuelven estructuras de datos complejas. Estos componentes son independientes a las fuentes de datos y servicios de necesarios para realizar una tarea, tambin permiten manejar transacciones de compensacin si el servicio provee una interfaz basada en servicios de mensajera. Al disear componentes de la lgica de negocios se deben tener en cuenta las siguientes recomendaciones: y y y Contar con el uso de comunicaciones asncronas siempre que sea posible. Asegurarse de que los procesos expuestos como interfaces de servicio mantengan la consistencia aunque el mismo mensaje se reciba dos veces. Escoger cuidadosamente los lmites de la transaccin de forma que los reintentos sean posibles. Tambin puede considerarse el uso de reintentos para sistemas basados en mensajes, especialmente cuando proveen de la funcionalidad de aplicacin como un servicio. Los componentes de procesos de negocio deben ser ejecutados en el contexto de cualquier servicio de usuario, no necesariamente utilizando el contexto de un usuario especfico de la aplicacin (impersonation). Esto permite invocar componentes utilizando mecanismos que no transmitan o deleguen la identidad del usuario. Mantener un formato consistente para el estado utilizado en los procesos de negocios, como DataSets o un documento XML. Fijar los niveles transaccionales apropiados. Considerar si es necesario implantar entidades de negocio utilizando modelos de objetos y clases. En muchos casos es ms simple utilizar representaciones estndar de los datos como son los DataSets.

y y y

Los componentes de procesos de negocio pueden ser llamados por la interfaz de servicio, componentes de procesos de usuario u otros procesos de negocios y componentes. Los procesos de negocios y componentes pueden invocar agentes de servicio, componentes de acceso de datos, servicios Web, u otros componentes de procesos de negocios para llevar a cabo la funcionalidad que proveen.

Los procesos de negocios y componentes pueden exponer operaciones que representan acciones de compensacin para diferentes operaciones, especialmente aquellas que son expuestas a travs de interfaces de servicio.

Interaccin de la lgica de negocios con la capa de datos.

y y

y y

Los componentes de Lgica de Negocio pueden ser llamados por la capa de presentacin (usualmente componentes de procesos de usuario). Los componentes de Lgica de Negocio tambin pueden ser llamados por interfaces de servicio, por ejemplo: un Servicio Web o una funcin que lee una cola de mensajes. El componente de Lgica de Negocio llama a los componentes de Acceso a Datos para recuperar y actualizar datos y otros componentes de Negocio. El componente de Lgica de Negocio puede llamar a Agentes de Servicios. Para esto hay que tomar en cuenta el diseo de la lgica de compensacin en caso de que el servicio que se est tratando de acceder no est disponible o tome demasiado tiempo en responder.

Interfaz de servicio: Es posible exponer como servicios la funcionalidad de negocio disponible en las aplicaciones empresariales. Para esto debe crearse una interfaz de servicio para manejar la comunicacin asncrona con la capa de negocios.

Una interfaz de servicio es una entidad implantada como una fachada que maneja todo el mapeo y transformacin de servicios que permite la comunicacin con un servicio, adems establece un proceso y un estndar para la comunicacin. Hay dos tipos principales de interfaces de servicio: interfaces de servicio funcional e interfaces de servicio de procesos. Una interfaz de servicio funcional provee de mtodos, por ejemplo Renovar Pliza, mientras una interfaz de servicio de procesos involucra implantar un contrato que define varios pasos y operaciones de lectura/escritura para completar una tarea particular de negocio. Las interfaces de servicio proveen de acceso asncrono a los procesos de negocio. El formato de comunicacin, esquema y proceso es determinado como parte del contrato.

Interaccin de la lgica de negocio con otros servicios de negocio.

Los Procesos de Negocio pueden ser llamados desde otros servicios o desde la capa de presentacin (usualmente componentes de procesos de usuario) va una Interfaz de Servicio. El Proceso de Negocio llama a otros servicios va un Agente de Servicio o puede ser invocado va una Interfaz de Servicio (Por ejemplo: un servicio Web, cola de mensajes o recepcin de un archivo). Los Procesos de Negocios llaman a Componentes de Lgica de Negocios y Componentes de Acceso a Datos para realizar su trabajo. El Proceso de Negocio puede iniciar transacciones. Los procesos deben ser diseados considerando tiempos de respuesta largos o para no recibir respuesta.

Lgica de acceso a datos Los componentes de acceso a datos se usan en una aplicacin para tener acceso a los datos, abstraen la semntica de la fuente de datos y tecnologa de acceso a datos y poseen una interfaz de programacin simple para recuperar y realizar operaciones sobre los datos. Los componentes de acceso a datos usualmente implantan un patrn de diseo que separa el proceso de negocio de la lgica de acceso a datos. Cada componente de acceso a datos provee mtodos para realizar las operaciones para Crear, Leer, Actualizar y Eliminar (CRUD) relacionadas con una entidad de negocios especfica. Cuando las aplicaciones tienen varios componentes de acceso a datos, es posible utilizar un componente de acceso a datos genrico para manejar las conexiones a la base de datos, ejecutar comandos, cach de parmetros, entre otros. El componente de acceso a datos provee la lgica requerida para acceder a datos de negocio especficos, mientras que el componente utilitario de acceso a datos genrico ayuda a reducir la duplicidad de cdigo. La lgica de acceso a datos se compone de: y Interfaz de servicios: Con la finalidad de exponer la lgica de negocio como un servicio, es necesario crear interfaces que soporten los mecanismos de comunicacin a travs de mensajes, los formatos, protocolos, seguridad, etc., que son requeridos para las aplicaciones que consumen estos servicios.

Componentes de acceso a datos: abstraen las operaciones bsicas en los datos. lo ideal sera que un componente de acceso a datos solo acceda a una fuente de datos, pero no necesariamente a una sola tabla o consulta. Componentes de servicios comunes (seguridad, comunicaciones, manejo de excepciones, etc.): la aplicacin utiliza un conjunto de componentes que brindan servicios que son comunes a travs de todas las capas y componentes de la misma. Estos componentes realizan ciertas tareas como autorizacin de usuarios, manejo de excepciones y manejo de la comunicacin con otras aplicaciones y servicios.

Uso de componentes de acceso a datos para obtener los datos de la aplicacin:

En los componentes de Acceso a Datos se tienen mtodos para realizar funciones del tipo CRUD, operaciones especiales y consultas de datos, consultas paginadas y otra funcionalidad relacionada a los datos. Utilizar los componentes de Acceso a Datos genricos (Data Access Helper) para centralizar el manejo de conexiones y todo el cdigo que tiene que ver con tecnologas especficas de la fuente de datos.

Implantar las consultas y operaciones en los datos como procedimientos almacenados para mejorar el desempeo y facilidad de mantenimiento de la aplicacin.

ARQUITECTURA FSICA Para hacer cualquier implantacin de la arquitectura fsica se debe tener en cuenta lo siguiente: y y y Identificar desde las primeras fases del proyecto el ambiente fsico en el cual ser implantada la aplicacin. Comunicar claramente cules son las restricciones del ambiente que debern considerarse en las decisiones de diseo y en la arquitectura. Comunicar claramente que decisiones de diseo de software requieren ciertos atributos a nivel de la infraestructura.

Los ambientes de implantacin fsica varan dependiendo del tipo de aplicacin que est siendo implantada, la base de usuarios de la aplicacin, los requerimientos de escalabilidad y desempeo, polticas organizacionales y otros factores. Una gran cantidad de patrones de infraestructura con caractersticas similares pueden ser identificados para tipos especficos de aplicaciones, particularmente soluciones basadas en Internet. As como una aplicacin est compuesta de componentes y servicios, la infraestructura que mantiene la aplicacin consiste en un nmero de reas o conjuntos llamados capas fsicas. Las capas fsicas estn compuestas de dos reas principales: Granjas y Clusters, las granjas consisten en conjuntos de servidores configurados de forma idntica que son extensibles y que comparten la carga de trabajo, los Clusters son conjuntos especializados de servidores que controlan un recurso compartido como bases de datos, y diseados para manejar de forma transparente las fallas a nodos individuales. Las siguientes capas fsicas son parte de la implantacin de la aplicacin: y Granjas de servidores Web (Web Farms). y Granjas de servidores de aplicaciones. y Clusters de servidores de bases de datos. y Clusters de servidores de integracin (EAI, Enterprise Application Integration).

Granjas de Servidores Web (Web Farms) Una granja de servidores web es un arreglo balanceado de servidores web. Las peticiones a los servidores pueden ser balanceadas sin afinidad, es decir, que cada peticin puede ser atendida por cualquier servidor de la granja, o puede ser basada en afinidad con la direccin ip del cliente, que un rango de direcciones ip sean siempre recibidas por un servidor web, pero se recomienda utilizar el balance de carga entre servidores sin afinidad, pues provee el mayor nivel de escalabilidad y disponibilidad. Al disear una aplicacin basada en web, se debe tener en cuenta lo siguiente: y Manejo de estado a travs de sesiones. Se debe mantener el estado entre los diferentes llamados a las pginas, pues cada nuevo llamado puede ser dirigido a un servidor diferente. ViewState. Para asegurar que otros controles a la pagina no sean iniciados a su valor por defecto despus de un PostBack (envo de datos de la pgina al servidor web para su procesamiento). El ViewState es implantado como un campo oculto en el formulario y para mayor seguridad puede ser encriptado. Comunicaciones a travs de SSL. Si ese est utilizando Secure Sockets Layer (SSL) para encriptar el trfico entre el cliente y la granja de servidores Web, es necesario asegurar que se mantenga la afinidad entre el cliente y el servidor Web particular que establece la sesin SSL. Para maximizar la escalabilidad y desempeo es posible implantar una granja de servidores Web separada para conexiones HTTPS, permitiendo de esta forma balancear la carga para las conexiones HTTP sin afinidad, pero manteniendo afinidad para las sesiones HTTPS.

Granja de servidores de aplicaciones Las granjas de servidores de aplicaciones son conceptualmente similares a las granjas de servidores Web, pero son utilizadas para balancear la carga de los componentes de negocios a travs de mltiples servidores de aplicaciones. Las granjas de servidores de aplicaciones son utilizadas para mantener los componentes de lgica de negocios, y particularmente los que utilizan Enterprise Services para el manejo de transacciones, eventos y otros servicios de componentes. Clusters de bases de datos Los clusters de bases de datos son utilizados para proveer de alta disponibilidad del servidor de base de datos.

Clusters de servidores de integracin Las herramientas de orquestacin guardan todos sus datos utilizados para los servicios de mensajera y orquestacin en bases de datos, los Clusters de servidores de integracin sirven para almacenar estas bases de datos y obtener una alta disponibilidad. Este repositorio de datos debe ser considerado privado y no debe ser accedido directamente por ningn otro componente fuera de esta capa. Ubicacin fsica de los componentes de la aplicacin Factores que influyen a la hora de implantar los componentes de una aplicacin: y Dependencias en la Ubicacin de Componentes: Algunos componentes pueden necesitar ciertos componentes de software o hardware existentes que deben estar fsicamente ubicados en la misma mquina. Seguridad: La poltica de seguridad puede determinar que ciertas libreras, llaves de encriptacin u otros recursos no puedan ser implantados en ciertos contextos de seguridad (por ejemplo, en un servidor Web o en la estacin de trabajo de un usuario). Adems se requiere prevenir el acceso a recursos sensitivos desde componentes implantados en zonas fsicas menos confiables. Finalmente, mediante la distribucin fsica de componentes a travs de mltiples capas, ante un posible ataque al sistema se ve enfrentado a mltiples obstculos para poder comprometer el sistema. Administracin: La lgica de la aplicacin que es utilizada por mltiples clientes y es implantada en un solo lugar facilita la administracin y monitoreo. Comunicaciones: Es necesario mover el origen de la transaccin a un lugar donde pueda comunicarse con todos los manejadores de recursos. Capacidad del Hardware: Algunos tipos especficos de servidores son mejores para realizar ciertas tareas y mantener diferentes productos y tecnologas. Licenciamiento: Algunas libreras y adaptadores no pueden ser implantados libremente sin incurrir en gastos adicionales. Adems, algunos productos son licenciados con base en la cantidad de procesadores. Esto hace que en algunos casos sea ms eficiente tener menos procesadores dedicados a un producto especfico que tener mltiples procesadores compartidos entre mltiples productos y tareas. Factores polticos: Algunas organizaciones pueden tener polticas y procedimientos definidos que indican cmo y dnde debe implantarse determinada funcionalidad.

y y

Disponibilidad: Es posible mejorar la disponibilidad de la aplicacin separando fsicamente actividades crticas del negocio en otras mquinas y componentes que podran fallar. Tipo de Componentes: Los componentes de acceso a datos, lgica de negocios e interfaz de usuario necesitan ser considerados individualmente para tener una mejor estrategia para la implantacin fsica.

BIBLIOGRAFA y y y Documento queeslaarquitecturadeunaaplicacion.doc. http://www.manualespdf.es/manual-organizacion-empresarial/. http://www.alegsa.com.ar/Dic/arquitectura%20de%20sistemas.php