Instituto del Sur. Curso: Diseño de Sistemas Diseño de Arquitectura. Elaborado por: Marco Arce Enriquez

Transcripción

1 Instituto del Sur Curso: Diseño de Sistemas Diseño de Arquitectura Elaborado por: Marco Arce Enriquez

2 Diseño de Soluciones Empresariales A. Consideraciones Generales Los objetivos de diseño de una aplicación empresarial, deben considerar varios aspectos como son: Implantar la funcionalidad requerida por los usuarios. Seguridad en todos los aspectos tanto en la autenticación, autorización y comunicación entre los diferentes componentes de la aplicación. Proveer de un alto desempeño a través de los diferentes esquemas de implantación. La solución debe permitir ser implantada en ambientes redundantes y de alta disponibilidad. Proveer de la escalabilidad necesaria para soportar un número creciente de usuarios y transacciones. Facilidad de administración y operación de la solución. Fácil de mantener. Estos objetivos al estar claramente definidos y enumerados por la prioridad que tiene cada uno, permiten establecer los parámetros o criterios en las cuales se basará la arquitectura a Implantar. Igualmente permite que los arquitectos encargados del diseño de la aplicación puedan tomar mejores decisiones en cuanto al diseño de los diferentes servicios de la aplicación que cumplan con los requerimientos funcionales y operacionales planteados, tomando en cuenta las restricciones en cuanto a infraestructura y tecnologías disponibles. Si la seguridad de la aplicación es un aspecto de mayor prioridad sobre otros, el diseño de los componentes de la aplicación estará pensado siempre en esta dirección aunque implique un precio a pagar en cuanto a desempeño, infraestructura adicional o facilidad de mantenimiento. Las aplicaciones empresariales que se desarrollen deben cumplir con los siguientes requerimientos generales: Modelo de Operación o Las aplicaciones deben ser concebidas para trabajar vía Web en dos modalidades de acceso: a través de la Intranet y de Internet para los clientes externos, bajo los parámetros de seguridad y respaldo definidos por el área de informática. o Diseño de las aplicaciones en modelo de tres capas (presentación, lógica de negocios y acceso a datos) para facilitar el mantenimiento de las mismas. Estandarización o Estándares de desarrollo de aplicaciones corporativas. o Reutilización de componentes de código. o Utilización de estándares de la industria. Facilidad de Administración o Administración de notificaciones y excepciones: A través de la generación automática de eventos debido a excepciones que puedan ser monitoreados por las áreas de administración de las aplicaciones. o Las aplicaciones deben proveer fácil acceso a la información que generen (reportes, estadísticas, controles, etc.). o Facilidad y consistencia en los procesos de instalación. Seguridad

3 o Autenticación y Autorización a través de opciones de Auditoría y log de transacciones. o Seguridad en los canales de comunicación, usando SSL. o Protección de datos. Acceso a las fuentes de datos a través de un usuario específico. Disponibilidad o De la plataforma. o De la aplicación per se. o Tolerancia a fallas y capacidad de recuperación de desastres. B. Arquitectura Lógica La arquitectura recomendada es una arquitectura de tres capas. Esta arquitectura lógica permite diferentes esquemas de implantación a nivel físico, desde un solo servidor hasta múltiples servidores por medio de una granja de servidores Web (Web Farm), granja de servidores de Aplicaciones y clusters de base de datos. Se recomienda la construcción de las aplicaciones como una arquitectura de 3 capas compuesta de los siguientes elementos: Figura 1. Arquitectura Lógica de una Aplicación Empresarial Componentes de Interfaz de Usuario. Están compuestos por las pantallas, páginas Web, controles y otras tecnologías utilizadas para desplegar y dar formato a los datos presentados a los usuarios y para capturar y validar la información ingresada por estos. Dependiendo de

4 los componentes de interfaz de usuario implantados puede considerarse utilizar caching y otras optimizaciones para mejorar la experiencia del usuario. Componentes de Procesos de Usuario. Estos componentes ayudan a orquestar el flujo de interacciones con el usuario, manejando la secuencia de los diálogos o páginas, flujos de estado y proveen de un mecanismo más simple de implantación para aplicaciones desconectadas o aplicaciones donde se requiere manejar interacciones de usuarios más complejas separadas de los datos de negocio. Por ejemplo, un Asistente de Tareas puede reiniciarse y continuar su ejecución en diferentes sesiones, el proceso de llenar un formulario de maestro detalle en el cliente sin interacción con el servidor, o un proceso complejo de múltiples pasos que debe ser ejecutado desde múltiples dispositivos. Componentes de Negocio. Implantan la lógica necesaria para llevar a cabo las tareas relacionadas con las reglas del negocio a través de llamados a funciones. Flujos de Procesos de Negocios. Los procesos de negocios definen el flujo de conversación entre los componentes de negocio de la aplicación y servicios externos. Los procesos de negocios, a diferencia de los componentes, pueden tomar una gran cantidad de tiempo en ejecutarse (desde segundos hasta meses). Los procesos de negocios pueden ser internos de la aplicación o pueden involucrar servicios externos en intercambios predefinidos. Interfaz de Servicios. Con la finalidad de exponer la lógica de negocio como un servicio, es necesario crear interfaces que soportan los mecanismos de comunicación a través de mensajes, los formatos, protocolos, seguridad, etc., que son requeridos para las aplicaciones que consumen estos servicios. Agentes de Servicios. Estos componentes aíslan la necesidad de llamar diversos servicios desde la aplicación y pueden proveer de servicios adicionales como transformación entre lo que la aplicación necesita consumir y lo que el servicio externo provee, además de otras optimizaciones necesarias para consumir el servicio externo. Componentes de Acceso a Datos. Abstraen las operaciones básicas en los datos. Idealmente un componente de acceso a datos solo debe acceder una sola fuente de datos, pero no necesariamente a una sola tabla o consulta. Componentes de Entidades de Negocios. La mayoría de las aplicaciones requieren que los datos sean pasados entren 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 también pueden ser representadas como clases dentro de la aplicación. Componentes de Servicios Comunes (Seguridad, Comunicaciones, Manejo de Excepciones, etc.). La aplicación utiliza un conjunto de componentes que brindan servicios que son comunes a través de todas las capas y componentes de la misma. Estos componentes realizan ciertas tareas como autorización de usuarios, manejo de excepciones y manejo de la comunicación con otras aplicaciones y servicios. La arquitectura descrita está basada en un modelo de n capas que provee una separación entre la lógica de presentación (interfaz de usuario), lógica

5 de negocios y la lógica de acceso a datos. Esta separación provee una serie de beneficios y ventajas en la implantación, integración y mantenimiento de la aplicación. Al diseñar una aplicación deben considerarse las siguientes recomendaciones: Identificar los tipos de componentes que serán utilizados por la aplicación. En algunos escenarios, no son necesarios los componentes de flujos de procesos de negocio o agentes de servicio. En las aplicaciones que manejan una sola interfaz de usuario (Web) y no requieren de soporte a aplicaciones Windows o dispositivos inteligentes, pueden no requerir de los componentes de procesos de usuario. Aunque el estándar que deben adoptar las organizaciones es Web, la utilización de componentes de procesos de usuario facilita reutilizar el mismo código en el caso de requerir la construcción de interfaces de otro tipo (Por ejemplo: Windows). El diseño de todos los componentes debe ser consistente, utilizando un solo modelo de diseño en donde sea posible. Esto ayuda a que la aplicación sea predecible y facilita el mantenimiento del diseño e implantación. En algunos casos es posible utilizar una clase base para todos los componentes que siguen un patrón similar, por ejemplo para los componentes de acceso a datos. Antes de escoger el esquema de distribución de los componentes es importante establecer los esquemas de comunicación remota entre los mismos y entender como una arquitectura de componentes desacoplados (loosely coupling) facilita la comunicación. Mantener un esquema consistente a través de la aplicación para representar los datos (entidades de negocio) o mantener al mínimo en donde sea posible. Por ejemplo, es posible retornar DataReaders desde los componentes de acceso a datos para obtener un mejor desempeño al presentar datos, y utilizar DataSets para ser consumido por los componentes de lógica de negocios. Sin embargo, utilizar varios formatos para representar los datos como XML, DataSet, DataReaders, valores escalares, etc., hace que la aplicación sea más difícil de desarrollar y mantener. El código relacionado a políticas como seguridad, manejo de excepciones, monitoreo, configuración, metadata, ubicación de servicios y comunicaciones (formatos, protocolos, etc.) debe mantenerse separado de la lógica de negocios de la aplicación. i. Diseño de la Interfaz de Usuario

6 Figura 2. Capa de Presentación o Interfaz de Usuario en una Arquitectura de Aplicación Empresarial. Los componentes de interfaz de usuario manejan la interacción con el usuario. Estos componentes despliegan información al usuario, adquieren datos del usuario, e interpretan los eventos que el usuario genera para ejecutar alguna acción 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 control utilizando el patrón Model View Controller (MVC). El componente desempeña el rol de vista cuando despliega datos a los usuarios. Las funciones de tipo control son llamadas cuando el usuario desempeña una acción y cambia el estado de datos de negocios relacionados en el proceso de interfaz de usuario. Por ejemplo, una página con una lista con categorías y un botón para mostrar documentos tiene una clara separación de los roles: la lista actúa como la vista de los datos y el botón interpreta los gestos del usuario (click) y llama a la función control (un método en la página ASP.NET). Los componentes de interfaz de usuario encapsulan el comportamiento de vista y control. Por ejemplo, un usuario que selecciona el signo + en un control de tipo treeview obtiene una lista de todos los nodos en el árbol sin interacción con el código de la aplicación. De la misma forma, un usuario que selecciona un botón para ver detalles puede causar que la página actual despliegue más información sin necesidad de interactuar con

7 el componente de procesos de interfaz de usuario u obtener datos adicionales de la aplicación. Los componentes de interfaz de usuario deben desplegar datos a los usuarios, obtener y validar los datos proporcionados por el usuario, e interpretar los gestos del usuario que indican que necesita ejecutar una acción sobre los datos. Adicionalmente, la interfaz de usuario debe filtrar las acciones disponibles para dejar a los usuarios realizar solo las operaciones que son apropiadas en algún momento específico. Al diseñar componentes que son utilizados para obtener datos del usuario, se deben tomar en cuenta las siguientes consideraciones: Facilitar la captura de datos utilizando elementos visuales, validación y controles apropiados para la actividad que realiza. Capturar los eventos que genera el usuario y llamar a las funciones de tipo control que permiten que los componentes de interfaz de usuario modifiquen la manera en que se presentan los datos, iniciando una acción en el proceso de usuario que está siendo ejecutado o cambiando los datos en el proceso que está siendo ejecutado por el usuario. Restringir los tipos de datos que un usuario puede introducir. Realizar el mapeo y transformaciones de la información suministrada por los controles de usuario a los valores que necesitan los demás componentes para ejecutar las acciones. Interpretar las acciones del usuario (click en los botones, arrastrar y soltar objetos, etc.) y convertirlos en un estado en el proceso del usuario o llamar a la función que realiza la acción. ii. Diseño de Componentes de Lógica de Negocio y Procesos de Negocio

8 Figura 3. Capa de Lógica de Negocio o de Servicios en una Arquitectura de Aplicación Empresarial. Una aplicación realiza un proceso de negocio que consiste en una o más tareas. En el caso más simple, cada tarea puede ser encapsulada en un método de un componente.net, y ser llamado de forma sincrónica o asíncrona. Para procesos de negocios más complejos que requieren de múltiples pasos y transacciones de larga duración, la aplicación necesita tener alguna manera de poder orquestar las tareas de negocios y guardar el estado hasta que el proceso sea completado. En estos escenarios, el uso del componente de orquestación de BizTalk Server puede ser utilizado para definir un flujo para el proceso de negocio. BizTalk Server a través de los componentes de orquestación puede utilizar la funcionalidad de mensajería de BizTalk y llamar a los componentes de lógica de negocios de la aplicación para realizar cada tarea a medida que se requiere. Es posible diseñar la lógica del negocio para ser utilizada directamente o encapsulada como un servicio y llamada a través de una interfaz de servicio basada en mensajes, que coordina de forma asíncrona la conversación entre las aplicaciones que llaman al servicio y llama al proceso de negocios en BizTalk o a los componentes de negocio. La capa de lógica de negocios puede también hacer llamados a servicios externos, en este caso deben implantarse agentes de servicio para manejar la conversación asíncrona requerida para la tarea particular de negocios que es ejecutada por cada servicio que se necesita utilizar. Componentes de Lógica de Negocio y Flujos de Procesos

9 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 lógica de negocio será suficiente. Deben utilizarse flujos de procesos de negocio (implantados con orquestación de BizTalk) para: o Manejar procesos que requieren múltiples pasos y transacciones de larga duración. o Integrarse con otros servicios a través de interfaces basadas en mensajes (Por ejemplo: Recepción de archivos). o Exponer una interfaz que implanta un proceso de negocio que permite que la aplicación pueda establecer comunicaciones complejas con otros servicios. o Construir servicios que necesitan ser expuestos vía múltiples tecnologías (como objetos COM, colas de mensajes, archivos, bases de datos, etc.) con lógicas complejas de procesamiento de los mensajes incluyendo múltiples aplicaciones u organizaciones. o Tomar ventaja de la amplia variedad de adaptadores y conectores para múltiples tecnologías disponibles para BizTalk. Es posible implantar procesos de negocio utilizando solo componentes de negocio cuando: o No es necesario exponer una interfaz basada en mensajes o implantar un proceso de negocio asíncrono. o Es necesario encapsular la funcionalidad y lógica de forma que pueda ser reutilizada desde varios procesos de negocio. o La lógica de negocios que necesita implantarse puede requerir un procesamiento bastante intensivo o necesita un control minucioso de las estructuras de datos y APIs. o Es necesario tener un control minucioso de las estructuras de datos y flujo de la lógica. Diseño de Componentes de Lógica de Negocio Los componentes de lógica de negocios son el origen de las transacciones (tanto de larga duración como transacciones heterogéneas). Estos componentes implantan las reglas de negocio en patrones diversos, además aceptan y devuelven estructuras de datos complejas. Los componentes de lógica de negocios exponen funcionalidad de manera que son independientes a las fuentes de datos y servicios necesarios para realizar la tarea. También proveen de la funcionalidad necesaria para manejar transacciones de compensación si el servicio provee una interfaz basada en servicios de mensajería. A continuación se presentan algunas recomendaciones para el diseño de componentes de lógica de negocios: o Contar con el uso de comunicaciones asíncronas siempre que sea posible. o Asegurarse de que los procesos expuestos como interfaces de servicio mantengan la consistencia aunque el mismo mensaje se reciba dos veces. o Escoger cuidadosamente los límites de la transacción de forma que los reintentos sean posibles. También puede considerarse el uso de reintentos para sistemas basados en mensajes, especialmente cuando proveen de la funcionalidad de aplicación como un servicio. o Los componentes de procesos de negocio deben ser ejecutados en el contexto de cualquier servicio de usuario, no necesariamente utilizando el contexto un usuario específico de la aplicación ( impersonation ). Esto permite invocar componentes

10 utilizando mecanismos que no transmiten o delegan la identidad del usuario. o Mantener un formato consistente para el estado utilizado en los procesos de negocios, como DataSets o un documento XML. o Fijar los niveles transaccionales apropiados. Para mayor información en el manejo de transacciones ver la sección de Transacciones en el documento Data Access Architecture Guide for.net. o Considerar si es necesario implantar entidades de negocio utilizando modelos de objetos y clases. En muchos casos es más simple utilizar representaciones estándar de los datos como son los DataSets. Implantación de Componentes de Lógica de Negocio con.net Los componentes de lógica de negocios que utilizan el.net Framework pueden tomar ventaja de Enterprise Services (COM+) para transacciones distribuidas y otros servicios que comúnmente se necesitan en las aplicaciones distribuidas. Al inicio del proceso de diseño debe tomarse la decisión de utilizar o no Enterprise Services para implantar los componentes de negocio, ya que se torna más difícil añadir o remover estas características del diseño y código una vez que ha sido construido. Los componentes de negocio tienen las siguientes características: o Son llamados por los componentes de procesos de negocio, interfaces de servicio u otros procesos de negocios, típicamente con algunos datos de negocios, expresados como una estructura de datos compleja (un documento ). o Son el origen de las transacciones, y finalmente deben votar en las transacciones que ellos participan. o Validan la entrada y salida. o Pueden exponer operaciones de compensación para los procesos de negocios que provee. o Pueden llamar a los componentes de acceso a datos para recuperar y/o actualizar datos de la aplicación. o Pueden llamar a servicios externos a través de agentes de servicio. o Pueden llamar a otros procesos de negocios. o Generan excepciones al componente que lo llama, si algo falla al manejar transacciones atómicas. o Utilizan las características de Enterprise Services para iniciar y votar en transacciones heterogéneas. Las diferentes opciones para el manejo de transacciones pueden tener un impacto en el desempeño que debe ser considerado. Enterprise Services (COM+) es el ambiente utilizado para mantener los componentes de lógica de negocios. Enterprise Services provee a los componentes con seguridad basada en roles, control de transacciones heterogéneas, pooling de objetos e interfaces basadas en mensajes a través de los Queued components, entre otros. Es posible decidirse por no implantar Enterprise Services en una aplicación, pero para algo más allá de operaciones simples sobre una sola fuente de datos, son necesarios sus servicios, y tomar ventaja del modelo de Enterprise Services desde el inicio provee de una ruta de crecimiento para la aplicación. Interfaces a los Componentes de Lógica de Negocio

11 Los componentes de procesos de negocio son llamados por los siguientes consumidores: o Interfaz de servicio o Componentes de Procesos de Usuario o 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 compensación para diferentes operaciones, especialmente aquellas que son expuestas a través de interfaces de servicio. El siguiente diagrama muestra un componente de Lógica de Negocio interactuando con componentes de Acceso a Datos, Interfaces de Servicio, Agentes de Servicio y otros componentes de Negocio: Figura 4. Interacción de la lógica de negocio con la Capa de Datos. o Los componentes de Lógica de Negocio pueden ser llamados por la capa de presentación (usualmente componentes de procesos de usuario). o Los componentes de Lógica de Negocio también pueden ser llamados por interfaces de servicio, por ejemplo: un Servicio Web o una función que lee una cola de mensajes. o El componente de Lógica de Negocio llama a los componentes de Acceso a Datos para recuperar y actualizar datos y otros componentes de Negocio. o El componente de Lógica de Negocio puede llamar a Agentes de Servicios. Para esto hay que tomar en cuenta el diseño de la lógica de compensación en caso de que el servicio que se está tratando de acceder no esté disponible o tome demasiado tiempo en responder. Patrones de Diseño utilizados para Componentes de Lógica de Negocio Hay varios patrones comunes de diseño para implantar procesos en el código. Los patrones más utilizados comúnmente: o Tubería (Pipeline): Una secuencia de acciones o consultas a un componente.

12 o Basado en Reglas: Las reglas de negocio son aplicadas al estado del proceso de negocio en un flujo de trabajo. o Eventos: Los eventos son generados bajo condiciones particulares de negocio y se construye el código para atrapar y responder a estos eventos. El patrón de tipo tubería (pipeline) es la definición de pasos a ejecutar para llevar a cabo una función de negocios. Todos los pasos son ejecutados secuencialmente. Cada paso puede requerir leer o escribir datos para confirmar el estado de la tubería, y puede o no acceder servicios externos. Cuando llama a un servicio asíncrono como parte de un paso, la tubería espera hasta que devuelva una respuesta (si espera una respuesta). El patrón de tubería puede utilizarse cuando: o Puede especificarse una secuencia de pasos conocidos. o No es necesario esperar una respuesta asíncrona de cada paso. o Se requiere que los componentes de bajada puedan ser capaces de utilizar y actuar en los datos que provienen de los de arriba (pero no viceversa). Las ventajas de este patrón incluyen: o Es simple de manejar e implantar o Obliga a realizar el proceso en forma secuencial. o Es fácil ejecutar bajo una transacción. Las desventajas de este patrón incluyen: o El patrón es demasiado simple, especialmente para la orquestación de servicios donde no maneja bien condiciones, iteraciones y otra lógica de flujo de control. En el patrón basado en Reglas cada estado en el proceso de negocios es examinado y se ejecutan acciones basadas en un conjunto de reglas del negocio. Las reglas pueden ser expresadas utilizando sentencias de la forma IF THEN ELSE o en otras estructuras de programación como tablas de decisión o utilizando un motor de flujos basados en reglas. Este patrón puede utilizarse cuando el proceso de negocios puede ser expresado en un flujo lineal en el cual diferentes acciones son ejecutadas basadas en diferentes condiciones. El patrón basado en Eventos es utilizado cuando es necesario que varias actividades ocurran al mismo tiempo pero que todas reciban los mismos datos iniciales y no pueden comunicarse entre sí. Estas actividades pueden ser ejecutadas en paralelo o secuencialmente. Diferentes implantaciones del evento pueden o no ejecutarse dependiendo de información específica. Si las implantaciones están configuradas para ejecutarse secuencialmente, el orden en que se ejecutan no puede ser garantizado. Puede utilizarse este patrón cuando: o Es necesario ser capaz de manejar de forma separada implantaciones independientes y aisladas de una función específica. o Las respuestas de una implantación no afectan la forma en que otra implantación trabaja. o Todos las implantaciones son del tipo solo escritura o de solo ejecución, donde la salida del proceso de negocios es definida por ninguna o solo una implantación específica de negocios. Las ventajas del patrón basado en eventos incluyen: o Fácil de mantener ya que mantiene de forma independiente procesos de negocios no relacionados. o Permite el procesamiento paralelo, lo cual puede derivar en beneficios en el desempeño. o Es fácil de ejecutar bajo una transacción.

13 o Es agnóstico a las implantaciones asíncronas o sincrónicas ya que no se espera una respuesta. Las desventajas del patrón basado en eventos incluyen: o No permite construir respuestas complejas para las funciones de negocios. o No se considera la interacción entre implantaciones. Los servicios de COM+ (Enterprise Services) proveen servicios de eventos desacoplados (Loosely coupled), que proveen de un punto de partida para la implantación del patrón basado en eventos. Implantación de Flujos de Procesos de Negocio utilizando BizTalk Server BizTalk Server incluye servicios de orquestación que permiten implantar la lógica de procesos de negocios. La orquestación de BizTalk provee de las siguientes capacidades para el proceso de negocios: o Separación de la definición del proceso de la implantación del mismo. o Procesos dinámicos o Integración del tipo Any to Any o Concurrencia y sincronización o Transacciones de larga duración Los servicios de orquestación pueden ser utilizados para implantar la gran mayoría de funcionalidad de negocio. Aunque, es mayormente útil cuando los procesos de negocios requieren de flujos de procesos de larga duración en los cuales se intercambian documentos de negocios entre varias aplicaciones u organizaciones. El siguiente diagrama muestra como un proceso de negocio interactúa con interfaces de servicio, agentes de servicio y componentes de negocio. Figura 5. Interacción de la lógica de negocio con otros servicios de negocio.

14 o Los Procesos de Negocio pueden ser llamados desde otros servicios o desde la capa de presentación (usualmente componentes de procesos de usuario) vía una Interfaz de Servicio. o El Proceso de Negocio llama a otros servicios vía un Agente de Servicio o puede ser invocado vía una Interfaz de Servicio (Por ejemplo: un servicio Web, cola de mensajes o recepción de un archivo). o Los Procesos de Negocios llaman a Componentes de Lógica de Negocios y Componentes de Acceso a Datos para realizar su trabajo. El Proceso de Negocio puede iniciar transacciones. o Los procesos deben ser diseñados considerando tiempos de respuesta largos o para no recibir respuesta. BizTalk automáticamente permite procesos de larga duración con servicios externos. Diseño de una 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 comunicación asíncrona con la capa de negocios. Una interfaz de servicio es una entidad implantada como una fachada que maneja todo el mapeo y transformación de servicios que permite la comunicación con un servicio, además establece un proceso y un estándar para la comunicación. 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 métodos, por ejemplo Renovar Póliza, 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 asíncrono a los procesos de negocio. El formato de comunicación, esquema y proceso es determinado como parte del contrato. Deben considerarse los siguientes elementos acerca las interfaces de servicio: o Las interfaces de servicio pueden proveer de un interfaz de tipo petición/respuesta a un sistema o pueden encapsular el flujo del proceso que representa un rol en el contrato. o La interfaz de servicio define un límite de servicio hacia fuera. Puede ser llamada por un agente de servicio. o En algunos casos la infraestructura.net permite tener interfaces de servicio transparentes (por ejemplo, los objetos COM+ pueden ser expuestos como servicios Web en Windows Server 2003). En otros casos es necesario incluir en la aplicación, servicios Web de ASP.NET o flujos de procesos a través de orquestación de BizTalk. o Las interfaces de servicio pueden implantar caching, mapeo y transformaciones simples de formato y esquema, sin embargo, estos no deben implantar lógica de negocios que puede ser utilizada por otras interfaces de servicios. o La interfaz de servicio puede requerir de un servicio de transporte transaccional (por ejemplo, MSMQ) o no transaccional (por ejemplo, un servicio Web XML sobre HTTP). o Las interfaces de servicio deben ser diseñadas para poder interoperar con otras plataformas y servicios.

15 o Estándares de la industria para la comunicación, seguridad y formatos. o Formatos de mensaje estándares o simples (por ejemplo, esquemas XML para los servicios Web) Sistemas de autenticación que no sean específicos de la plataforma. o En algunos casos la interfaz de servicio tiene una identidad de seguridad propia y autenticará los mensajes recibidos pero no es capaz de realizar impersonation. iii. Diseño de Componentes de Acceso a Datos La lógica utilizada para acceder datos en una fuente de datos deberá mantenerse en componentes de Acceso a Datos, que proveen métodos para consultar y actualizar datos. Los datos que la lógica de la aplicación necesita manejar están relacionados con entidades reales que tienen algún rol en el negocio. En algunos escenarios, es posible tener componentes propios que representan estas entidades, mientras que en otros escenarios puede decidirse por trabajar con los datos utilizando directamente DataSets de ADO.NET o documentos XML. El siguiente diagrama muestra como la capa lógica de datos de una aplicación consiste de uno o más fuentes de datos y la capa de componentes de acceso a datos, que son utilizados para consultar y manipular estos datos en las fuentes de datos. Figura 6. Capa de Datos en una Arquitectura de Aplicación Empresarial.

16 Independientemente de la fuente de datos, las aplicaciones o servicios utilizan los componentes de acceso a datos para acceder los datos. Esto componentes abstraen la semántica de la fuente de datos y tecnología de acceso a datos (como ADO.NET), y proveen de una interfaz de programación simple para recuperar y realizar operaciones sobre los datos. Los componentes de acceso a datos usualmente implantan un patrón de diseño que separa el proceso de negocio de la lógica de acceso a datos. Cada componente de acceso a datos provee métodos para realizar las operaciones para Crear, Leer, Actualizar y Eliminar (CRUD por sus siglas en inglés) relacionadas con una entidad de negocios específica. Cuando las aplicaciones tienen varios componentes de acceso a datos, es posible utilizar un componente de acceso a datos genérico para manejar las conexiones a la base de datos, ejecutar comandos, caché de parámetros, entre otros. El componente de acceso a datos provee la lógica requerida para acceder datos de negocio específicos, mientras que el componente utilitario de acceso a datos genérico ayuda a reducir la duplicidad de código. Microsoft provee del Data Access Application Block for.net, que puede ser utilizado como un componente utilitario de acceso a datos genérico en las aplicaciones que utilizan bases de datos en SQL Server. El siguiente diagrama muestra el uso de componentes de acceso a datos para obtener los datos de la aplicación: Figura 7. Interacción de acceso a datos o En los componentes de Acceso a Datos se tienen métodos para realizar funciones del tipo CRUD, operaciones especiales y consultas de datos, consultas paginadas y otra funcionalidad relacionada a los datos. o Utilizar los componentes de Acceso a Datos genéricos (Data Access Helper) para centralizar el manejo de conexiones y todo el código que tiene que ver con tecnologías específicas de la fuente de datos. o Implantar las consultas y operaciones en los datos como procedimientos almacenados (stored procedures) para mejorar el desempeño y facilidad de mantenimiento de la aplicación. Manejo de las Conexiones a la Base de Datos

17 Las conexiones a la base de datos representan un recurso limitado, costoso y crítico, particularmente en una aplicación Web de múltiples capas. Es necesario manejar las conexiones de forma correcta ya que la estrategia a utilizar afecta significativamente la escalabilidad de la aplicación. También, debe considerarse cuidadosamente donde son almacenadas las cadenas de conexión. Para esto será necesaria una ubicación segura y fácil de configurar. Al manejar conexiones a bases de datos y cadenas de conexión, debe procurarse lo siguiente: o Ayudar a mejorar la escalabilidad de la aplicación mediante un pool de conexiones a las bases de datos a través de múltiples clientes. o Adoptar una estrategia de alto desempeño y facilidad de configuración para el manejo del pool de conexiones. o Utilizar autenticación de Windows al acceder bases de datos en SQL Server. o Almacenar de forma segura las cadenas de conexión. o Abrir las conexiones a la base de datos lo más tarde que se pueda y cerrarla lo más pronto posible. El pooling de conexiones a la base de datos permite que una aplicación pueda reutilizar una conexión ya existente a partir de un fondo común (pool), en vez de establecer una nueva conexión con la base de datos. Esta técnica puede incrementar significativamente la escalabilidad de una aplicación, ya que un número limitado de conexiones a la base de datos pueden atender a un número mayor de clientes. Esta técnica también mejora el desempeño, ya que se evita el tiempo requerido para establecer una nueva conexión. Las tecnologías de acceso a datos como ODBC y OLE DB proveen mecanismos para el pooling de conexiones, que son configurables en diferentes grados. Ambos son transparentes a la aplicación cliente. El pooling de conexiones de OLE DB es conoce también como pooling de recursos o sesiones. Si se utiliza el SQL Server.NET Data Provider, se recomienda utilizar el soporte que provee el proveedor, es un mecanismo eficiente implantado por el mismo internamente y con soporte a transacciones. Los pools son creados por proceso y no son destruidos hasta que el proceso finaliza. El OLE DB.NET Data Provider hace el pool de conexiones utilizando los servicios subyacentes de pooling de recursos de OLE DB. Para el proveedor de OLE DB, es posible utilizar el pooling de objetos de COM+ como la técnica a utilizar para el pooling de conexiones de bases de datos. Hay dos razones principales para esto: o Los tamaños y límites del pool pueden ser configurados explícitamente (en el catálogo de COM+. o Se mejora el desempeño. La estrategia de pooling de objetos puede superar el pooling nativo por un factor de dos. Seguridad. Aunque el pooling de conexiones a bases de datos mejora la escalabilidad de la aplicación, esto significa que no es posible manejar la seguridad a nivel de base de datos. Esto se debe a que para soportar el pooling de conexiones las cadenas de conexión deben ser idénticos. Si es necesario llevar el control de las operaciones en la base de datos a nivel de usuario, debe considerarse añadir a cada operación un parámetro a través del cual pasar la identidad del usuario a nivel de la aplicación y manualmente llevar la auditoria de las acciones del usuario en la base de datos. Autenticación de Windows Debe utilizarse autenticación de Windows al conectarse a SQL Server ya que provee un sinnúmero de beneficios:

18 o La seguridad es más fácil de manejar ya que se utiliza un solo modelo de seguridad (Windows) en vez de manejar un modelo de seguridad separado (SQL Server). o Evita que se incluyan los nombres de usuario y contraseñas en las cadenas de conexión. o Los nombres de usuario y contraseñas no son pasados a través de la red en texto o Mayor seguridad a través de las políticas como expiración de contraseñas, tamaños mínimos y bloqueo de cuentas después de múltiples intentos inválidos. Manejo de Concurrencia En un ambiente de múltiples usuarios, hay dos modelos para actualizar los datos en la base de datos: concurrencia optimista y pesimista. El modelo de concurrencia pesimista implica que se bloqueen los registros en la fuente de datos para evitar que los usuarios modifiquen los datos de una manera que afecte a otros usuarios. Hasta que el usuario no haya finalizado la actualización y liberado el registro, nadie puede modificar el registro. Este modelo de concurrencia produce contención de los datos y no es escalable cuando los usuarios necesitan interactuar con los datos. El modelo de concurrencia optimista no bloquea el registro al leerlo. Cuando un usuario requiere actualizar un registro, la aplicación debe determinar si otro usuario ha modificado los datos desde que fueron leídos. Este modelo mejora el desempeño al no bloquear los registros y utilizar recursos del servidor adicionales para mantenerlos. Hay varias técnicas para probar la violación de la concurrencia optimista. Una de ellas implica la utilización de una columna timestamp en la tabla. Las bases de datos comúnmente proveen de esta funcionalidad que puede utilizarse para identificar la fecha y hora de la última actualización. Al utilizar esta técnica, debe incluirse una columna de tipo timestamp en la definición de la tabla. Cada vez que se actualiza un registro, se actualiza el timestamp. Para probar las violaciones al modelo de concurrencia optimista, se devuelve el valor del timestamp con cualquier consulta a los datos de la tabla. Al intentar actualizar los datos, el valor en la base de datos se compara con el valor original del timestamp que se mantiene en el registro modificado. Si no coinciden, ha ocurrido una violación a la concurrencia. Otra de las técnicas para probar la violación al modelo de concurrencia optimista es verificar que todos los valores originales del registro son iguales a aquellos que se encuentran en la base de datos. Si ambos coinciden se realiza la actualización de los datos. Es recomendado que los datos siempre incluyan una llave única sino puede actualizarse más de un registro. Manejo de Transacciones Prácticamente todas las aplicaciones que actualizan fuentes de datos requieren soporte a transacciones. Las transacciones son utilizadas para mantener la integridad del estado de la aplicación en una o más fuentes de datos, a través de las siguientes características: Atomicidad, consistencia, aislamiento y durabilidad (ACID por sus siglas en inglés). Hay varias estrategias que pueden ser adoptadas para incorporar el manejo de transacciones en el código de acceso a datos. Cada estrategia se adapta a uno de los dos modelos básicos de programación: o Transacciones Manuales: Donde el código que utiliza las características de soporte a transacciones se construye utilizando

19 ADO.NET o Transact SQL directamente en el código del componente o stored procedures respectivamente. o Transacciones Automáticas (COM+): Se añaden a las clases.net atributos en la declaración que especifican los requerimientos transaccionales de los objetos en modo de ejecución. Este modelo permite que se puedan configurar fácilmente múltiples componentes que se ejecutan en el contexto de una misma transacción. Aunque ambas técnicas pueden ser utilizadas para realizar transacciones locales (que utilizan un solo manejador de recursos como SQL Server) o distribuidas (que utilizan múltiples manejadores de recursos ubicados en máquinas remotas), el modelo de transacciones automáticas simplifica el procesamiento distribuido de las transacciones. Las transacciones son un recurso costoso en las aplicaciones y puede reducir la escalabilidad de la aplicación cuando son utilizadas innecesariamente. Debe considerarse lo siguiente a la hora de utilizar transacciones: o Realizar transacciones solo cuando se necesita adquirir locks a través de una serie de operaciones y garantizar las reglas ACID. o Mantener las transacciones lo más cortas posibles para minimizar la cantidad de tiempo que se mantienen los locks en la base de datos. o El cliente nunca debe tener el control de la duración de una transacción. o No utilizar una transacción para una sentencia SQL individual. SQL Server maneja esto automáticamente. o No mezclar los diferentes modelos de manejo de transacciones en la aplicación. o Aunque el modelo de programación se simplifica debido al uso de transacciones automáticas, particularmente cuando múltiples componentes están realizando actualizaciones a la base de datos, las transacciones manuales son más rápidas al no tener que interactuar con el Microsoft Distributed Transaction Coordinator (DTC). Utilizar transacciones manuales cuando: o Se realizan transacciones en una solo base de datos. Utilizar transacciones automáticas cuando: o Se requiere que una sola transacción pueda abarcar múltiples bases de datos remotas. o Se requiere que una sola transacción pueda abarcar múltiples manejadores de recursos como una base de datos y colas de mensajes de Microsoft Message Queuing (MSMQ). C. Elementos Clave de la Arquitectura i. Escalabilidad La arquitectura de las aplicaciones debe proveer la escalabilidad esperada a través de las siguientes estrategias: Utilizar operaciones asíncronas siempre que sea posible de forma que se reduzca el tiempo de respuesta y la demanda de procesamiento. Utilizar el caché de datos donde es requerido, minimizando el número de peticiones de datos remotas a las bases de datos. Evitar mantener el estado innecesariamente, de forma que se prevenga la contención de recursos, mejorando la consistencia de los

20 datos y permitiendo que la carga sea balanceada a través de múltiples servidores en una granja de servidores. Evitar la contención de recursos. Algunos recursos como las conexiones a las bases de datos son limitados y otros recursos son exclusivos como los locks de la base de datos. La aplicación deberá retener estos recursos en uso por el menor tiempo posible. A través del uso de connection pooling y object pooling es posible lograr esto. Particionar datos, recursos y operaciones. La carga de la aplicación puede ser dividida a través de múltiples servidores utilizando tecnologías de balanceo de carga como Windows Network Load Balancing. Esto permite adoptar una estrategia de scale out donde se obtiene mayor escalabilidad simplemente añadiendo más servidores a la granja. Para las bases de datos deben utilizarse inicialmente la estrategia de scale up, es decir, añadir más recursos de hardware, pero los servidores también pueden utilizar scale out a través del particionamiento de datos a través de múltiples servidores de bases de datos. ii. Disponibilidad La arquitectura provee alta disponibilidad a través de las siguientes estrategias: Evitar puntos de fallo a través de la utilización de software para el balanceo de carga, como el que provee Microsoft Application Center, el cual remueve un servidor que no responde de la granja de servidores sin interrumpir las operaciones de los otros servidores. Los datos deberán ser implantados en bases de datos o colas que utilizan clusters, de forma que si alguno de los servidores que controla el recurso falla, la aplicación pueda seguir funcionando. Proveer rutas de datos redundantes de forma que exista más de una ruta física en la red al servidor de base de datos, permitiendo que la aplicación siga funcionado en el caso de fallo en la conexión de red. Las tecnologías de redundancia de discos (RAID) deberán utilizarse para proteger la aplicación de fallos en los discos. Uso del caché de datos y de las colas de mensajes. Utilizar datos de referencia de tipo solo lectura donde sea necesario, no solo mejora la escalabilidad, si no que reduce la necesidad de estar conectado a la fuente de datos. Igualmente, al utilizar colas de mensajes para las inserciones y actualizaciones de datos, permite que la aplicación pueda seguir atendiendo a otros clientes aunque las fuentes de datos y servicios no estén disponibles. Confiabilidad en el código. A través del manejo adecuado de excepciones generadas por la aplicación. La administración adecuada de cambios en la aplicación por medio de los ambientes apropiados de desarrollo y pruebas. La implantación de código en ambientes de producción que no han sido sometidos a las pruebas correspondientes, incluyendo la implantación de software o componentes de terceros. iii. Administración La política de administración de las operaciones tiene que ver con el manejo día a día de las aplicaciones y cubre áreas como manejo de excepciones, monitoreo y configuración. Manejo de Excepciones y eventos El manejo de excepciones incluye el atrapar y generar excepciones, diseñar excepciones, pasar la información de la excepción y publicar la información de la excepción a los usuarios. Las excepciones deben ser