Exportar (0) Imprimir
Expandir todo
Expandir Minimizar

Implementación física y requisitos operativos

Publicado: 26 de junio de 2006

Patterns & Practices
Microsoft Corporation
Diciembre de 2002

imagen

http://msdn.microsoft.com/practices/

Resumen: en este capítulo se describen las distintas opciones que se encuentran disponibles al implementar una aplicación en un entorno físico; asimismo, se sugieren estrategias para cumplir con los requisitos operativos (no funcionales) de la aplicación.

Capítulo 4 de Arquitectura de aplicaciones de .NET: Diseño de aplicaciones y servicios. Comience por aquí para obtener una visión general completa.

En esta página

Implementación de los componentes de la aplicación  Implementación de los componentes de la aplicación
Patrones comunes de implementación  Patrones comunes de implementación
Requisitos operativos Requisitos operativos
Comentarios y compatibilidad Comentarios y compatibilidad

Implementación de los componentes de la aplicación

Hasta el momento, en esta guía la arquitectura de aplicaciones se ha descrito desde el punto de vista de las capas lógicas. Es importante recordar que estas capas constituyen simplemente una forma adecuada de describir los tipos de funcionalidad de la aplicación. Se trata más bien de divisiones conceptuales que de un patrón de implementación física. La forma en que las capas físicas de la aplicación se implementan en los niveles se basa en el modo de interacción de las capas entre sí y en los requisitos de los que disponen desde el punto de vista de la seguridad, las operaciones y la comunicación.

Finalmente, la aplicación se instalará en una infraestructura física. En algunos casos, el arquitecto podrá definir la infraestructura física, pero en muchos otros, el departamento de tecnologías de la información será el que la establezca. Los patrones de implementación física se suelen decidir mediante una negociación entre el departamento de tecnologías de la información y los desarrolladores de la aplicación motivados por el arquitecto de la solución.

En cualquier escenario de implementación, se debe:

  • Conocer desde un principio el entorno de implementación físico de destino, desde la fase de planeamiento del ciclo de vida.

  • Establecer claramente qué restricciones del entorno condicionan el diseño del software y la toma de decisiones relativas a la arquitectura.

  • Transmitir con claridad qué decisiones acerca del diseño del software requieren determinados atributos de infraestructura.

Entornos físicos de implementación

Estos entornos varían dependiendo de varios factores: tipo de aplicación que se implemente, base de usuario de la aplicación, escalabilidad, requisitos de rendimiento, directivas de organización, etc. Se pueden identificar una serie de patrones de infraestructura con características similares para tipos de aplicación específicos, en concreto soluciones basadas en Internet. Por ejemplo, en la documentación de Microsoft® Systems Architecture Internet Data Center se describe un patrón de implementación física recomendado para las aplicaciones basadas en Web, tal y como se muestra en la figura 4.1. Para obtener más información, consulte "Microsoft Systems Architecture: Internet Data Center" en el sitio Web de Microsoft TechNet

imagen

Figura 4.1. Arquitectura de Internet Data Center

Al igual que una aplicación consta de componentes y servicios, la infraestructura que la aloja se puede considerar como una serie de unidades de creación de infraestructura, denominadas niveles físicos. Estos niveles representan las divisiones físicas que existen entre los componentes de la aplicación y pueden o no asignarse directamente a los niveles lógicos utilizados para abstraer los distintos tipos de funcionalidad de la aplicación. Los niveles físicos pueden estar separados por servidores de seguridad u otras medidas de seguridad para crear diferentes unidades de confianza o contextos de seguridad. Existen dos familias principales de niveles físicos: baterías y clústeres. Las baterías están compuestas por conjuntos de servidores ampliables y configurados de idéntico modo que comparten la carga de trabajo. Los clústeres son conjuntos de equipos especializados que controlan un recurso compartido como, por ejemplo, un almacén de datos, que se encuentran diseñados para controlar correctamente los errores de nodos individuales.

En diversos entornos de implementación de aplicaciones se pueden encontrar varias unidades de creación de infraestructura común.

Batería de servidores Web

Una batería de servidores Web es una matriz con equilibrio de carga de servidores Web. Se pueden emplear una serie de tecnologías para implementar el mecanismo de equilibrio de carga, entre las que se incluyen soluciones de hardware como las que ofrecen los enrutadores y conmutadores de Cisco y Nortel, así como soluciones de software como el Equilibrio de la carga en la red. En cualquier caso, el principio en el mismo: un usuario realiza una solicitud para un recurso de Internet utilizando una dirección URL y uno de los servidores de la batería gestionará dicha solicitud entrante. Debido a que las solicitudes presentan equilibrio de carga entre los servidores de la batería, un error del servidor no hará que el sitio Web deje de funcionar. Las solicitudes pueden presentar equilibrio de carga sin afinidad (es decir, cualquiera de los servidores de la batería puede gestionar cada solicitud), o bien, con afinidad basada en la dirección IP del equipo que realiza la solicitud, en cuyo caso las solicitudes de un intervalo determinado de direcciones IP siempre estarán equilibradas en el mismo servidor Web. En general, se debe intentar implementar el equilibrio de carga sin afinidad para proporcionar el nivel más elevado de escalabilidad y disponibilidad.

Para obtener más información sobre el modo de implementación de las baterías de servidores Web en Microsoft Systems Architecture Internet Data Center, consulte la Guía de arquitectura de referencia de Internet Data Center en el sitio Web de Microsoft TechNet

Al diseñar una interfaz de usuario basada en Web que se implementará en una batería de servidores Web, se deben tener en cuenta los siguientes puntos:

  • Estado de sesión. En las aplicaciones basadas en páginas Active Server (ASP), se debe evitar la dependencia del objeto Session de ASP para los datos de estado entre las solicitudes, ya que puede que las nuevas solicitudes se envíen a un servidor distinto. ASP contiene los datos de sesión en proceso, por lo que los mismos datos de sesión no estarán presentes en todos los servidores de la batería. Con las soluciones basadas en Microsoft ASP.NET, se elimina esta limitación. Las aplicaciones basadas en ASP.NET se pueden configurar de modo que almacenen su estado de sesión fuera del proceso en un servidor remoto de los Servicios de Internet Information Server de Microsoft (IIS), o bien, en una base de datos de Microsoft SQL Server™. Asimismo, ASP.NET proporciona una forma sencilla de configurar las sesiones "sin cookies", de forma que el objeto Session se puede utilizar incluso cuando el explorador del usuario no admita cookies. Para obtener más información sobre el uso del objeto Session en las aplicaciones basadas en ASP.NET, consulte "ASP.NET Session State" en MSDN

  • ViewState. ViewState se utiliza en las páginas ASP.NET para mantener la coherencia de la interfaz de usuario entre las solicitudes de devolución. Por ejemplo, una página puede contener una lista desplegable que devuelva automáticamente los datos de la página al servidor Web para el procesamiento del servidor. ViewState se emplea para asegurar que los demás controles de la página no se restablezcan a sus valores predeterminados originales tras la devolución. Se implementa como un campo de formulario oculto y se puede asegurar mediante cifrado. En un entorno de batería de servidores Web, es necesaria la coherencia de la configuración del archivo machine.config en todos los servidores de la batería. Para obtener más información sobre el uso de ViewState en una batería de servidores Web, consulte el artículo "Introducción a ViewState de ASP.NET" de MSDN

  • Comunicaciones SSL. Si está utilizando Secure Sockets Layer o SSL (nivel de socket seguro) para cifrar el tráfico entre el cliente y la batería de servidores Web, debe garantizar un mantenimiento de la afinidad entre el cliente y el servidor Web concreto con el que establece la clave de sesión SSL. Para obtener la máxima escalabilidad y rendimiento, puede optar por utilizar una batería independiente para las conexiones HTTPS, con el fin de poder equilibrar la carga de las solicitudes HTTP sin afinidad, pero mantener las "sesiones dificultosas" para las solicitudes HTTPS.

Baterías de aplicaciones

Desde un punto de vista conceptual, las baterías de aplicaciones son similares a las de servidores Web, aunque se utilizan para equilibrar la carga de las solicitudes para los componentes empresariales en varios servidores de aplicaciones. Las baterías de aplicaciones se utilizan para alojar componentes empresariales, en concreto aquellos que utilizan servicios .NET Enterprise Services (COM+) como, por ejemplo, administración de transacciones, eventos de acoplamiento flexible y otros servicios de componentes. Si los componentes están diseñados para no tener estado, se puede implementar el mecanismo de equilibrio de carga de la batería de aplicaciones utilizando el Equilibrio de carga en la red (NLB), ya que cada solicitud puede ser gestionada por los servidores de la batería configurados de forma idéntica. Otra posibilidad consiste en implementar una batería de aplicaciones empleando el equilibrio de carga de componentes (CLB), una función que proporciona Microsoft Application Center 2000. Para obtener más información sobre CLB, consulte la página principal de Application Center

Clústeres de base de datos

Estos clústeres se utilizan para proporcionar una elevada disponibilidad de un servidor de base de datos. La Organización por clústeres de Windows ofrece la base para una solución agrupada basada en SQL Server y admite clústeres de dos y cuatro nodos. Los clústeres se pueden configurar en modo activo/pasivo (un miembro del clúster actúa como nodo de conmutación por error), o bien, como modo activo/activo (cada miembro del clúster controla su propia base de datos al mismo tiempo que actúa como nodo de conmutación por error para el otro miembro).

Para obtener más información sobre la implementación de soluciones agrupadas basadas en SQL Server, consulte el capítulo 5 de la Guía de arquitectura de referencia de Internet Data Center

Al diseñar una aplicación basada en .NET que realizará una conexión con una base de datos alojada en un clúster, se debe prestar especial atención a la hora de abrir y cerrar las conexiones conforme se necesiten y no esperar a abrir los objetos de conexión. Con ello se asegurará que ADO.NET se pueda volver a conectar con el nodo activo de servidor de la base de datos en caso de conmutación por error en el clúster.

Clústeres EAI

Microsoft BizTalk® Server se basa en cuatro bases de datos de SQL Server para almacenar sus datos de organización y mensajería. Estas bases de datos se pueden beneficiar de la Organización por clústeres de Windows para obtener una elevada disponibilidad. Para obtener información general sobre la creación de clústeres en BizTalk Server, consulte el artículo "High-Availability Solutions Using Microsoft Windows 2000 Cluster Service" de la documentación de BizTalk Server 2002 de MSDN (en inglés). Para obtener información sobre la creación de clústeres en BizTalk Server en la infraestructura de Internet Data Center, consulte la Guía de arquitectura de referencia de Internet Data Center.

BizTalk Server Orchestration mantiene sus datos de programación en una base de datos de SQL Server. Debido a que el nivel de integración de aplicaciones empresariales (Enterprise Application Integration, EAI) es una unidad de confianza, este almacén de datos se debe considerar privado y no se debe tener acceso directo al mismo en ningún componente de software fuera del nivel. Será necesario decidir si se desea implementar la funcionalidad de integración en una red perimetral (también denominada zona desmilitarizada o DMZ) que pueda interactuar con Internet, o bien, en la red interna, lo cual proporciona una mejor conectividad con los servicios y aplicaciones de la organización. En la Guía de arquitectura de referencia de Internet Data Center se analizan estos temas de forma más amplia.

Mediante la introducción de varios servidores BizTalk "Receive" y "Worker" en una única cola de trabajo compartida (alojada en un entorno SQL Server agrupado), se puede aumentar el rendimiento del clúster BizTalk según sea necesario, así como obtener una elevada disponibilidad.

Es probable que su entorno físico incluya algunas de estas unidades de creación de infraestructura, si no todas, en las que se pueden implementar los componentes de la aplicación.

Clientes enriquecidos

Otra posibilidad consiste en implementar componentes en clientes enriquecidos. Se asume que los clientes enriquecidos ejecutan el sistema operativo Microsoft Windows® y que pueden ejecutar componentes .NET. Asimismo, se puede crear una interfaz de usuario enriquecida mediante la integración con aplicaciones tales como las que integra Microsoft Office.

En la mayor parte de los entornos empresariales, el uso de clientes enriquecidos implica:

  • Capacidad para autenticar a los usuarios con el servicio de directorio de Microsoft Active Directory® (con lo que se tiene acceso, de este modo, a Windows Identity y Principal).

  • Obtener acceso a opciones de administración de estado más enriquecidas, incluyendo el mantenimiento en memoria del estado relacionado con la sesión. (En escenarios con un alto grado de escalabilidad y disponibilidad, no resulta muy adecuado mantener el estado en memoria en el servidor.)

  • Capacidad para trabajar sin conexión.

Los clientes enriquecidos también son mejores destinos para la interfaz de usuario de operaciones complejas.

Es importante realizar una comprobación rigurosa de las aplicaciones de cliente enriquecido, ya que el contexto de seguridad en el que se ejecutan suele estar restringido por la directiva de usuario y cualquier directiva de seguridad de acceso al código presente en el equipo.

Clientes ligeros

Generalmente, este tipo de clientes administra modelos de interfaz de usuario más sencillos o HTML, por lo que se suelen considerar como un destino de implementación de los componentes. Los controles de .NET se pueden incluir en páginas HTML, aunque en este caso simplemente se está utilizando un explorador como vehículo de implementación y la interfaz de usuario se debe considerar enriquecida.

Planeamiento de la ubicación física de los componentes de la aplicación

Una de las decisiones más importantes que debe tomar un arquitecto de aplicaciones consiste en determinar el lugar donde se implementarán los componentes de la aplicación. Al igual que sucede en todos los aspectos de la arquitectura de aplicaciones, las decisiones de implementación física implican un equilibrio entre el rendimiento, la reutilización y la seguridad, entre otros factores. Las directivas organizativas relativas a la seguridad, las comunicaciones y la administración operativa también afectan a las decisiones de implementación que se lleven a cabo.

Es habitual cuestionarse si las distintas partes del software que interactúa se deben implementar de forma conjunta, especialmente si forman parte del mismo servicio o aplicación. No existe una respuesta correcta a la pregunta sobre si distribuir los componentes en niveles físicos independientes. No obstante, hay una serie de factores que pueden ser útiles a la hora de tomar una decisión sobre si la implementación de componentes se debe realizar de forma conjunta o por separado.

Al tomar decisiones relativas a la arquitectura física de la aplicación, se debe considerar lo siguiente: la distribución de los componentes se traduce en problemas de rendimiento. Existen buenas razones para llevar la cabo la distribución de componentes, aunque ello incide de forma negativa en el rendimiento. Con la distribución se puede mejorar la escalabilidad y la facilidad de uso de la aplicación, reducir costes financieros, etc.

En general, la selección de una implementación consta de tres fases en las que intervienen tanto los arquitectos de la aplicación como los de la infraestructura:

  1. Identificación de las topologías mínimas. Desde un primer momento en la fase de diseño, se debe determinar qué condiciones requiere la aplicación para entrar en funcionamiento. Por ejemplo, los agentes de servicio pueden necesitar llamar a servicios Web en Internet. La aplicación no funcionará si no se puede establecer la comunicación saliente adecuada. Se debe elaborar una lista donde se incluyan estos tipos de requisitos "imprescindibles".

  2. Aplicación de restricciones y requisitos. Un requisito del diseño de la aplicación (por ejemplo, el uso de transacciones del Coordinador de transacciones distribuidas de Microsoft [DTC]) se traduce en un conjunto de requisitos para la infraestructura (por ejemplo, DTC utiliza puertos de llamadas a procedimientos remotos [RPC] para realizar la comunicación, por lo que dichos puertos se deben encontrar abiertos en los servidores de seguridad internos).

    El arquitecto de la infraestructura debe elaborar una lista de requisitos "imprescindibles" para su centro de datos, similar a la realizada en la fase anterior. Posteriormente, se debe comenzar en la infraestructura y seguir el mismo proceso de aplicación de restricciones e identificación de requisitos. Una característica de diseño de la infraestructura se puede considerar invariable y puede afectar al modo de diseño de la aplicación. Por ejemplo, puede que la infraestructura no proporcione acceso a los usuarios de dominio corporativo en una batería externa de servidores Web debido a la seguridad. Se trata de una restricción de diseño que impide autenticar a los usuarios de la aplicación con la autenticación de Windows.

    Tal y como sucede en el paso anterior, estos requisitos y restricciones se deben plantear desde un primer momento en el ciclo de diseño y antes de crear la aplicación. En ocasiones, los requisitos de la aplicación y los pertenecientes a la infraestructura entrarán en conflicto. El arquitecto de la solución será el responsable de arbitrar en la decisión.

  3. Optimización de la infraestructura y la aplicación. Una vez establecidos los requisitos y las restricciones de la infraestructura y la aplicación y tras haber resuelto todos los conflictos, es probable que no se hayan especificado muchas características pertenecientes a la aplicación y la infraestructura. Por consiguiente, tanto la aplicación como la infraestructura se deben optimizar para mejorar sus características respectivas en estas áreas. Por ejemplo, si el arquitecto de la infraestructura ha proporcionado acceso mediante los puertos del servidor de seguridad para el componente Message Queue Server, pero la aplicación no lo está utilizando, la seguridad se puede mejorar cerrando estos puertos. Por otra parte, puede que la infraestructura no presente un criterio definido frente al mecanismo de autenticación empleado en la base de datos, por lo que se puede optar por utilizar la autenticación integrada de Windows o SQL Server dependiendo del modelo de seguridad de la aplicación.

Factores que afectan a la implementación de componentes

Existe una serie de factores cuantitativos y cualitativos que influyen en la decisión de implementar los componentes de forma conjunta o distribuida. Se pueden agrupar en función de las capacidades de la aplicación y están estrechamente relacionados con las directivas: seguridad, administración operativa y comunicación.

Seguridad

A la hora de decidir el modo de implementación de los componentes, se deben tener en cuenta los siguientes factores de seguridad:

  • Ubicación de recursos e información importante. La directiva de seguridad puede determinar que ciertas bibliotecas, claves de cifrado u otros recursos no se puedan implementar en contextos de seguridad determinados (por ejemplo, en un servidor Web o en los equipos de escritorio de los usuarios).

    Asimismo, se puede evitar el acceso a recursos importantes desde los componentes en zonas físicas de menor confianza. Por ejemplo, puede que no se desee permitir el acceso a la base de datos desde una batería de servidores Web y, en cambio, requerir una capa separada de componentes tras un servidor de seguridad que efectúe el acceso a la base de datos.

  • Límites de seguridad ampliados. Mediante la distribución física de los componentes en diversos niveles, se aumenta el número de obstáculos que un intruso potencial debe superar para comprometer el sistema.

  • Contexto de seguridad de código en ejecución. La distribución física de los componentes puede hacer que éstos se ejecuten en contextos de seguridad completamente distintos. Por ejemplo, un nivel de componente remoto se suele ejecutar en una cuenta de servicio, mientras que los componentes de nivel Web pueden ejecutarse en la cuenta de usuario autenticado. Si se distribuyen los componentes, se deberá decidir cómo se administrará el flujo de identidad, la representación y la auditoría de acciones realizadas en las cuentas de servicio.

Administración

A continuación se incluyen los factores de administración que afectan a la implementación de componentes:

  • Administración y supervisión. Para facilitar la tarea de administración y supervisión de una parte de la lógica de la aplicación utilizada por varios consumidores, puede que desee implementarla únicamente en un espacio donde todos los usuarios puedan tener acceso. Por ejemplo, se puede decidir implementar un componente empresarial que utilicen varias interfaces de usuario en una sola ubicación central.

    Puede que las capacidades de copia de seguridad y restauración no estén disponibles para todos los niveles físicos de la aplicación, por lo que es necesario asegurar que se pueda tener acceso a las colas y las bases de datos importantes desde la solución de copia de seguridad y restauración.

  • Dependencias de la ubicación de los componentes. Algunos componentes se pueden basar en el software o hardware existente y se deben ubicar físicamente en el mismo equipo. Por ejemplo, la aplicación puede utilizar una conexión en una red de propietario que sólo se pueda establecer desde un equipo determinado del entorno físico existente. En este caso, parte de la lógica de la aplicación se deberá implementar en ese servidor concreto.

  • Otorgamiento de licencia. Algunas bibliotecas y adaptadores no se pueden implementar libremente sin incurrir en costes adicionales. Asimismo, el uso de algunos productos se autoriza por CPU. El otorgamiento de licencia basado en CPU hace que resulte más eficaz dedicar menos CPU a un producto, en lugar de compartir varias CPU entre diversos productos y tareas.

  • Factores políticos. En algunas organizaciones, existen factores políticos que pueden tener una influencia en el lugar donde se ubique una determinada funcionalidad. Por ejemplo, un grupo de una organización puede desear la propiedad de una parte determinada de un servicio o aplicación.

Rendimiento, disponibilidad y escalabilidad

En la decisión de implementar los componentes de forma conjunta o distribuirlos se deben tener en cuenta los siguientes factores en los que entran en juego el rendimiento, la disponibilidad y la escalabilidad:

  • Complejidad de las interfaces. Resulta más eficaz distribuir componentes siempre que la interfaz entre ellos se diseñe para requerir menos llamadas o intercambios de información con más datos. A una interfaz de este tipo se le suele denominar "sólida" (en contraposición a una interfaz "conversadora"). De este modo, la granularidad de la interacción entre los componentes afecta en gran medida al rendimiento y al modo en que se administra el estado, con el impacto relacionado en la escalabilidad y la disponibilidad.

  • Comunicaciones. Será necesario desplazar la raíz de transacción atómica a un lugar donde se pueda comunicar con todos los administradores de recursos. El Coordinador de transacciones distribuidas (DTC) utiliza la llamada a procedimiento remoto (RPC) para comunicarse a través del puerto 135 y un intervalo dinámico de otros puertos. Puede que no se desee abrir estos puertos en un servidor de seguridad que separe la batería de servidores Web de los componentes empresariales.

  • Disponibilidad. Para mejorar la disponibilidad de la aplicación se pueden separar físicamente las actividades empresariales importantes de otros equipos y componentes que pueden generar errores. Por ejemplo, se pueden implementar procesos empresariales de ejecución larga en un nivel separado de servidores agrupados, de forma que un error de la batería de servidores Web no evite que se completen los procesos empresariales.

  • Rendimiento. Tal y como se mencionó anteriormente, la distribución de componentes supone un problema de rendimiento de serialización y deserialización de datos y en el establecimiento de conexiones de red. No obstante, se puede mejorar la escalabilidad general de la aplicación separando unidades de trabajo que se influyan entre sí.

  • Capacidades de hardware. Existen tipos específicos de servidores que son más apropiados para realizar tareas determinadas y alojar productos y tecnologías concretas. Por ejemplo, los servidores Web suelen ser equipos con amplia memoria y buen rendimiento del procesador. Sin embargo, no tienden a disponer de capacidades de almacenamiento sólidas (como, por ejemplo, reflejado del sistema de almacenamiento RAID, etc) que se pueden reemplazar rápidamente en caso de un error de hardware. Debido a esto, no se debe instalar una base de datos con datos importantes en un equipo destinado como servidor Web.

Límites de distribución entre componentes

Si la aplicación se diseña siguiendo las instrucciones de los capítulos 2 y 3 de esta guía, se observará que resulta más eficaz implementar ciertos tipos de componentes de forma conjunta, mientras que otros tipos de componentes interactúan con sus llamadores de un modo más adecuado para el acceso remoto.

Planeamiento de la implementación de la interfaz de usuario

La decisión sobre una ubicación de implementación para los componentes de la interfaz de usuario es muy sencilla: las aplicaciones basadas en Windows se implementan en los clientes y las páginas ASP.NET en los servidores Web.

Los componentes del proceso de usuario se deben implementar de forma conjunta con los componentes de la interfaz de usuario que organizan. En los entornos Web, esto implica que la implementación de los componentes del proceso de usuario se lleva a cabo en los servidores Web de IIS; para los clientes de Windows la implementación de los componentes del proceso de usuario se realiza con la aplicación basada en Windows Forms. Los componentes del proceso de usuario se deben implementar en un ensamblado .NET que se encuentre separado de la lógica de la interfaz de usuario para facilitar el nuevo uso y un mantenimiento sencillo.

Planeamiento de la implementación de componentes empresariales

El lugar de implementación de la lógica empresarial suele ser un tema muy discutido entre los arquitectos de la infraestructura y la aplicación. Aunque existen diversos patrones de implementación física para los componentes empresariales, se deben tener en cuenta las siguientes recomendaciones:

  • Los componentes empresariales que se utilizan de forma sincrónica mediante las interfaces de usuario o los componentes del proceso de usuario se pueden implementar con la interfaz de usuario para aumentar el rendimiento y facilitar la administración operativa. Este enfoque es más apropiado en las aplicaciones basadas en el Web que las basadas en Windows, ya que probablemente los componentes empresariales no se vayan a implementar en cada escritorio. Sin embargo, incluso en los escenarios Web, si se desea aislar la lógica empresarial para que no esté en el mismo límite de confianza que la interfaz de usuario, o bien, si es necesario volver a utilizar la lógica empresarial para varias interfaces de usuario, se puede optar por implementar los componentes empresariales en un nivel separado de servidores de aplicaciones y utilizar una tecnología de comunicaciones como, por ejemplo, .NET remoting, DCOM o SOAP a través de HTTP para hacerlos accesibles en la lógica de interfaz de usuario. En los escenarios Web, la inclusión de un servidor de seguridad entre la interfaz de usuario y los servidores de aplicaciones puede incorporar una complejidad de administración y configuración.

  • Generalmente, los procesos empresariales que se implementan como servicio y que, por lo tanto, se comunican de forma asincrónica, se deben implementar en un nivel físico independiente. Los servicios asíncronos deben disponer de su propio clúster de aplicaciones, separado de otros servidores de aplicaciones sincrónicos, de modo que puedan formar su propia zona de confianza. Esto resulta cierto al implementar un flujo de trabajo empresarial que utilice componentes .NET. personalizados o BizTalk Server Orchestration. En general, los componentes empresariales que el servicio utiliza "de forma interna" se deben implementar en el mismo nivel físico que los componentes de la interfaz de servicios utilizados para realizar llamadas al servicio.

  • Los componentes de agente de servicios se suelen implementar con los componentes empresariales o los procesos que los utilizan. No obstante, puede que se desean implementar agentes de servicios en niveles físicos separados si dicho nivel administra la comunicación con un servicio externo a través de Internet y se desea aislar la comunicación orientada a Internet en un contexto de seguridad distinto de los componentes empresariales.

  • Los componentes de entidad empresarial y los conjuntos de datos (DataSet) con tipo se suelen implementar con el código que los utiliza. La llamada de forma remota a las entidades empresariales no suele constituir una buena elección de diseño desde el punto de vista del rendimiento, ya que tienden a ser con estado y a exponer las interfaces "conversadoras", lo cual podría causar una gran cantidad de tráfico de red en un escenario de implementación remoto.

Los componentes empresariales no administran el estado persistente, por lo que no habrá restricción alguna a la hora de implementarlos en un clúster o batería física concreta. Potencialmente, se pueden desarrollar en varias interfaces, incluyendo una batería de servidores orientada a la intranet, un clúster EAI y otra batería orientada a la intranet.

Planeamiento de la implementación de la interfaz y agente de servicios

Los componentes de las interfaces de servicios y del agente de servicios efectúan y reciben llamadas desde aplicaciones y servicios externos. Estas aplicaciones y servicios se pueden ubicar en la red de la organización, en una zona que comparta las directivas de seguridad y administración, o bien, se pueden situar fuera de la organización, donde probablemente requieran comunicación a través de la intranet o extranet.

Las interfaces de servicios se pueden implementar junto con los componentes empresariales y flujos de trabajo que exponen, o bien, de forma remota. Los criterios para decidir si realizar la implementación junto con la lógica empresarial es similar a los que se utilizan al decidir el lugar de implementación de la interfaz de usuario. Si la interfaz de servicios requiere una conexión a Internet o un entorno de menor confianza, el salto de red adicional puede proporcionar la seguridad agregada necesaria. La implementación remota de las interfaces de servicio puede permitir que dos baterías de servidores Web (una para las interfaces de usuario basadas en ASP.NET y otra para los servicios Web XML) llamen a la misma batería de aplicaciones que aloja los componentes empresariales.

Los agentes de servicios presentan un conjunto similar de decisiones, excepto que estos componentes llaman a los servicios en lugar de recibir llamadas. Los diseños de infraestructura común pueden limitar a los servidores a las llamadas salientes HTTP que se deben realizar.

Planeamiento de la implementación del flujo de trabajo empresarial

Se recomienda que desarrolle clústeres EAI de BizTalk en un conjunto de equipos separado de los servidores que alojen interfaces de usuario de ASP.NET y componentes empresariales utilizados por la IU. Con ello se podrá optimizar el uso del procesador para las tareas de flujo de trabajo empresarial típicamente asíncronas y se proporcionarán procesos de administración que sean adecuados para BizTalk, Message Queue Server y otras tecnologías específicas en las que se basen los flujos empresariales.

Es importante decidir si implementar los componentes empresariales y de acceso a datos mediante el flujo de trabajo empresarial en el mismo clúster. Es habitual proceder de este modo debido a que los flujos de trabajo se suelen implementar en un entorno seguro. No obstante, la implementación de los mismos componentes empresariales en varios lugares agrega complejidad a los procesos de administración, por lo que se suele recomendar la separación de los siguientes elementos en ensamblados distintos:

  • Componentes empresariales llamados por componentes de la interfaz de usuario.

  • Componentes empresariales utilizados únicamente desde flujos de trabajo empresariales u otros componentes empresariales.

Posteriormente, se debe implementar el ensamblado adecuado (o conjunto de ensamblados) con los flujos de trabajo empresariales o las baterías de componentes o servidores Web. Con este mecanismo se obtiene una mayor flexibilidad, un mejor rendimiento y una administración más sencilla para las aplicaciones de mayor tamaño. Sin embargo, únicamente resulta adecuado si se pueden identificar fácilmente las actividades y componentes empresariales para su uso desde la interfaz de usuario y desde los flujos de trabajo empresariales.

Planeamiento de la implementación de los componentes de acceso a datos

Los datos de la aplicación se almacenan casi siempre en un servidor de dase de datos dedicado, lo que implica que todas las aplicaciones, incluso la más simple, se deben agrupar para garantizar la mayor disponibilidad. En las aplicaciones Web, este servidor de base de datos debe ser una VLAN situada tras el segundo servidor de seguridad de la red perimetral para proteger los datos.

La implementación de los componentes de acceso a datos con los componentes que los utilizan tiene como resultado las siguientes ventajas:

  • Las transferencias de datos se optimizarán, ya que se evita el ordenamiento de los procesos cruzados.

  • Las transacciones que implican procesos empresariales y componentes de acceso a datos no necesitan desplazarse por los servidores de seguridad, lo cual significa que no será necesaria la apertura de puertos adicionales.

  • La distribución de componentes agrega nodos con error de transacción.

  • La implementación de componentes de forma conjunta garantiza el flujo de contexto de seguridad automático, por lo que no será necesario definir objetos principales ni de volver a autenticar canales remotos. Con ello se podrá aprovechar la seguridad de acceso al código para restringir qué ensamblados pueden llamar a los componentes de acceso a datos.

Los componentes empresariales suelen emplear los componentes de acceso a datos, aunque estos últimos también se pueden utilizar desde componentes de la interfaz de usuario y los del proceso de usuario. En los escenarios Web se recomienda realizar una implementación con la interfaz de usuario si ésta aprovecha la transmisión de DataReader. Sin embargo, puede que no se quiera llevar a cabo esta operación por distintas razones, entre las que se incluyen:

  • Se desea evitar el acceso directo a la red a los orígenes de datos desde las baterías de servidores Web por razones de seguridad (se trata de un motivo frecuente para implementar los componentes por separado). En estos casos, se deben implementar componentes de acceso a datos en un nivel empresarial físico (y por lo tanto, un contexto de seguridad independiente) e invocar a los mismos de forma remota desde el nivel de Web.

  • Los componentes de acceso a datos se van a utilizar desde los componentes empresariales y los de interfaz de usuario, pero no se desean implementar los componentes duplicados en dos ubicaciones.

Cada origen de datos dispondrá de sus propios requisitos de comunicación para tener acceso. Para obtener más información sobre el acceso a SQL Server a través de un servidor de seguridad, consulte ".NET Data Access Architecture Guide" en MSDN

Partición de la aplicación o el servicio en ensamblados

Los ensamblados .NET son unidades de implementación; un ensamblado se implementa y controla versiones, ya que una unidad. .NET ofrece amplias capacidades de implementación y control de versiones que permiten establecer versiones de la aplicación obligatoria de la directiva una vez implementada una aplicación; sin embargo, la partición de ensamblados se deberá planear detenidamente para aprovechar al máximo estas capacidades. Los ensamblados creados y el modo de distribución de los componentes entre sí tiene un impacto a largo plazo en la forma de desarrollo, implementación, administración, actualización y mantenimiento de la aplicación.

Existen diversos factores que afectan al modo en que se distribuyen los componentes en ensamblados separados. Las siguientes recomendaciones ayudarán a tomar las decisiones adecuadas referentes al tamaño de la aplicación, la composición del equipo y la distribución, así como los procesos de administración:

  • Crear un ensamblado independiente para cada tipo de componente. El uso de ensamblados independientes para los componentes de acceso a datos, componentes empresariales, interfaces de servicios, entidades empresariales, etc; proporciona la flexibilidad básica para la implementación y el mantenimiento de la aplicación.

  • Evitar la implementación de un ensamblado en varias ubicaciones. La implementación de los mismos componentes en diversos lugares supone un aumento de la complejidad de los procesos de implementación y administración, por lo que se debe considerar detenidamente si se pueden consolidar todas las implementaciones en un nivel físico, o bien, si se deben emplear varios ensamblados para un tipo de componente concreto.

  • Disponer de varios ensamblados por tipo de componente. No todos los componentes del mismo tipo siguen los mismos ciclos de desarrollo y mantenimiento. Por ejemplo, se puede disponer de varios componentes de agente de servicios mediante la abstracción de las llamadas a servicios para varios socios empresariales. En este caso, puede ser más conveniente crear un ensamblado por socio para simplificar el control de versiones. A la hora de decidir sobre el uso de varios ensamblados por tipo de componente, se debe tener en cuenta lo siguiente:

    • Con qué componentes, servicios y orígenes de datos trata el ensamblado; puede que se desee disponer de un ensamblado distinto para los componentes de agente de servicios que traten con diferentes socios empresariales, para los componentes que traten con un ensamblado de interoperabilidad primario específico, o bien, para los componentes empresariales a los que se invoque desde la interfaz de usuario o el flujo de trabajo empresarial exclusivamente. La separación de componentes en función del lugar desde donde se llaman o el objeto de la llamada mejora la administración de la aplicación, ya que no es necesario volver a implementar los componentes; asimismo, con ello se evita que el código utilizado se implemente en distintos lugares.

    • Los componentes de acceso a datos pueden tratar con varios orígenes de datos. La separación de los componentes de acceso a datos que trabajan con diferentes orígenes de datos en distintos ensamblados puede ser beneficiosa si la implementación que tiene acceso a un origen de datos concreto cambia con frecuencia. De lo contrario, se recomienda que utilice solamente un ensamblado de componentes de acceso a datos para proporcionar la abstracción que se deriva del hecho de estar trabajando con varios recursos.

  • Separar tipos compartidos en ensamblados diferentes. Muchos componentes de la aplicación se pueden basar en los mismos tipos para llevar a cabo su trabajo. Se recomienda que separe los siguientes tipos en distintos ensamblados:

    • Excepciones. Muchos niveles de la aplicación pueden necesitar tratar con los mismos tipos de excepciones. Si se dividen las excepciones en las que basan todas las capas de la aplicación en un ensamblado independiente, no será necesario implementar los ensamblados que contienen lógica empresarial allí donde ésta sea necesaria.

    • Interfaces compartidas y clases base. La aplicación puede definir interfaces para el uso de los demás desarrolladores o para obtener una adición sencilla de la lógica una vez implementada la aplicación. Con la separación de interfaces y clases base empleadas en ensamblados que se encuentran separados de la implementación de la lógica empresarial, se evitarán enlaces complejos de control de versiones en caso de que cambie la implementación; asimismo, se podrán compartir los ensamblados con la definición de interfaz sin tener que compartir el código del ensamblado con la organización con desarrolladores externos.

    • Componentes de utilidad. La aplicación se suele basar en un conjunto de componentes de utilidad o unidades de creación que encapsulan las tecnologías específicas o proporcionan servicios que pueden utilizar diversas capas de la aplicación como, por ejemplo, componentes de ayuda para el acceso a datos, administración de excepciones y marcos de seguridad. La división de los mismos en sus propios ensamblados simplifica el desarrollo, el mantenimiento y el control de versiones.

  • Considerar el impacto en el proceso de desarrollo. Con la presencia de un gran número de ensamblados se incorpora flexibilidad para la implementación y el mantenimiento, aunque puede aumentar la complejidad del proceso de desarrollo debido a que será necesario tener en cuenta más referencias de creación, proyectos y aspectos del control de versiones. No obstante, la utilización de ensamblados separados que traten con una tecnología concreta puede servir de ayuda para distribuir la carga de trabajo en los desarrolladores adecuados que dispongan de los conocimientos necesarios; el uso de varios proyectos de Microsoft Visual Studio® .NET puede facilitar el trabajo de los equipos de desarrollo. Para obtener instrucciones detalladas sobre cómo realizar la partición en los ensamblados en los equipos de desarrollo complejos o en las dependencias de ensamblado, consulte el capítulo 3 "Team Development with Visual Studio .NET and Visual SourceSafe" de MSDN

  • Evitar la implementación de código no utilizado. Si se realiza la partición de ensamblados que se pueden invocar desde varios componentes y se implementan en distintos lugares, se puede acabar implementando código no utilizado. Algunas organizaciones pueden considerar este punto como un riesgo para la seguridad o la propiedad intelectual, por lo tanto se debe volver a considerar si se pueden volver a dividir los ensamblados de modo que un componente se implemente sólo donde sea necesario. Los ensamblados .NET disponen de una cantidad de espacio en disco muy pequeña, por lo que el espacio en disco no es un factor importante.

  • Utilizar un enfoque de división en la partición de ensamblados. Puede que se desee comenzar el proyecto definiendo un conjunto base de ensamblados bien planeados y, a continuación, utilizar las disciplinas comunes de nueva división para liderar la creación de más ensamblados mediante el análisis de frecuencias de cambio, dependencias y los demás factores señalados anteriormente en este capítulo.

  • Aplicación de la partición de ensamblados con plantillas empresariales. Las plantillas de Visual Studio .NET Enterprise permiten definir y aplicar directivas que utilicen los desarrolladores en la creación de la aplicación, incluyendo la estructura y la dependencia de ensamblado. Si se va a implementar una aplicación de gran tamaño o desarrollar varias aplicaciones con una arquitectura similar, se debe considerar la creación o adaptación de una plantilla empresarial que se adapte a sus necesidades.

Empaquetado y distribución de los componentes de la aplicación

Para distribuir la aplicación, será necesario seleccionar un modo de empaquetarla e implementarla. Visual Studio .NET ofrece varias opciones para empaquetar las aplicaciones, entre las que se incluyen los archivos de Microsoft Windows Installer y los archivos CAB.

Asimismo, se pueden implementar varias aplicaciones basadas en .NET sin empaquetado copiando los archivos apropiados en el destino, enviándolos mediante correo electrónico o proporcionando descargas de FTP.

También existen otras herramientas y servicios de Microsoft que se pueden emplear para distribuir la aplicación. Entre estos se incluyen:

  • Microsoft Application Center

  • Microsoft Systems Management Server

  • Microsoft Active Directory

Para obtener información sobre las instrucciones para la selección del empaquetado adecuado para la aplicación y el uso de la tecnología de distribución adecuada, consulte el artículo "Deploying .NET Applications: Lifecycle Guide" de MSDN

Patrones comunes de implementación

El patrón de implementación que utiliza una aplicación concreta suele estar determinado por el arquitecto en un proceso en el que intervienen los responsables de las operaciones y el desarrollo. Las distintas organizaciones o fabricantes de software abordarán el problema de forma diferente, por lo que no existe un único enfoque a la hora de determinar la infraestructura. En esta sección se analizarán diversos patrones de implementación para los componentes, así como sus ventajas, inconvenientes y requisitos.

Existe una serie de variaciones de patrones de implementación (por ejemplo, puede que sea necesario implementar Microsoft Mobile Information Server en la solución), aunque en esta sección no se describen todos ellos. Para comprender las características de implementación específicas, así como los requisitos, consulte la información sobre Internet Data Center indicada anteriormente en este capítulo y la documentación adecuada del producto.

También se debe tener en cuenta que se puede realizar la combinación de patrones de implementación. Es aconsejable implementar cada componente de la solución únicamente en un nivel físico o batería, aunque por razones de seguridad puede que se desee considerar la implementación del mismo componente en distintas ubicaciones por razones de facilidad de uso.

Nota

En el siguiente análisis, las figuras hacen referencia a los tipos de componente y no a los ensamblados específicos. Para establecer la partición de ensamblado, siga las instrucciones mencionadas anteriormente.

El aspecto de estas figuras difiere ligeramente respecto de la figura 4.1 (donde se muestra la arquitectura de Internet Data Center) en las que se muestran las instancias de servidor de seguridad independientes entre las baterías. Los dispositivos de servidor de seguridad físicos de Internet Data Center pueden alojar varias instancias de servidor de seguridad, lo que, a su vez, hace que el diseño de la red física tenga un aspecto distinto. Todos los patrones de implementación que aparecen en los siguientes diagramas se pueden asignar directamente a pequeñas variaciones de Internet Data Center, tal y como se muestra en la figura 4.1.

Escenarios de interfaz de usuario basados en Web

Los dos escenarios de implementación analizados a continuación son variaciones habituales localizadas al trabajar con interfaces de usuario basadas en Web.

Batería de servidores Web con lógica empresarial local

Una batería de servidores Web con lógica local empresarial es un patrón de implementación frecuente que ubica todos los componentes de la aplicación (componentes de interfaz de usuario (páginas ASP.NET), componentes del proceso de usuario (si se utilizan), componentes empresariales y acceso a datos) en las baterías de servidores Web. El acceso a los datos en la batería de servidores Web permite emplear lectores de datos para realizar un procesamiento veloz de los datos. Este patrón proporciona el rendimiento más elevado, ya que todas las llamadas a los componentes son locales y el acceso a las bases de datos es remoto (figura 4.2).

imagen

Figura 4.2. Batería de servidores Web con lógica empresarial local

Entre los requisitos y consideraciones relativos al uso de una batería de servidores Web con lógica empresarial local se incluyen:

  • Los clientes (1) pueden tener acceso a la batería de servidores Web mediante un servidor de seguridad (2) utilizando HTTP y posiblemente puertos SSL

  • La batería de servidores Web (3) puede alojar páginas ASP.NET y componentes empresariales; probablemente en Enterprise Services.

  • El acceso a la base de datos se concede desde la batería de servidores Web y a través del servidor de seguridad (4). La batería de servidores Web deberá alojar a las bibliotecas cliente y administrar cadenas de conexión, lo cual incorpora importantes requisitos de seguridad.

  • Si los componentes están utilizando transacciones de Enterprise Services, los puertos RPC se abren en (4) para permitir el acceso a los orígenes de datos (5).

Batería de servidores Web con lógica empresarial remota

Otro patrón frecuente de implementación es la batería de servidores Web con lógica empresarial remota. Con ello se ubica a todos los componentes empresariales de la aplicación en otra batería a la que se tiene acceso de forma remota desde las páginas ASP.NET de los servidores de la batería. El rendimiento es menor que en el escenario anterior, pero el patrón permite que varios clientes (por ejemplo, clientes de escritorio en una intranet) compartan una batería de aplicaciones, lo cual simplificará la administración. Asimismo, este patrón proporciona una mejor separación entre los servidores que administran la interfaz de usuario y los que administran transacciones empresariales, lo que supone un aumento de la disponibilidad al aislar puntos de error. La escalabilidad puede mejorar en algunos escenarios donde las operaciones que consumen un gran número de recursos independientes son necesarias tanto en las baterías de servidores Web como de aplicaciones, ya que las mismas no competirán por los recursos: los servidores Web generarán páginas más rápido y los componentes se completarán antes.

La figura 4.3 ilustra este patrón de implementación.

imagen

Figura 4.3. Batería de servidores Web con lógica empresarial remota

Entre los requisitos y consideraciones relativos al uso de una batería de servidores Web con lógica empresarial remota se incluyen:

  • Los clientes (1) pueden tener acceso a la batería de servidores Web mediante un servidor de seguridad (2) utilizando HTTP y posiblemente puertos SSL.

  • La batería de servidores Web (3) puede alojar páginas ASP.NET y componentes del proceso de usuario. Estas páginas no podrán aprovechar los DataReaders para procesar los datos de los componentes de acceso a datos, a no ser que estos componentes se implementen en la batería de servidores Web y permitan que los puertos del servidor de seguridad adecuados tengan acceso a los datos.

  • Todos los componentes empresariales se alojan en una batería de aplicaciones (5) a la que los demás clientes también pueden tener acceso. El acceso a estos componentes se realiza mediante un servidor de seguridad (4). Dependiendo del canal de comunicación que se emplee, puede que sea necesario abrir diferentes puertos. Si los componentes empresariales se alojan en Enterprise Services, deberá abrir los puertos RPC. Para obtener más información sobre los requisitos del puerto, consulte la sección "Diseño de la directiva de comunicaciones" incluida en el capítulo 3, "Directivas de seguridad, administración operativa y comunicaciones".

  • Generalmente, una infraestructura dispondrá de un servidor de seguridad (4) o (6) en su lugar. Internet Data Center proporciona la capacidad de disponer de ambos.

  • El acceso a la base de datos se concede desde la batería de servidores Web y a través del servidor de seguridad (6). La batería de aplicaciones deberá alojar a las bibliotecas cliente y administrar cadenas de conexión.

  • Si los componentes están utilizando transacciones de Enterprise Services, los puertos RPC se abren en (6) para permitir el acceso a los orígenes de datos (7).

Escenarios de interfaz de usuario de cliente enriquecido

Los siguientes escenarios presentan un cliente enriquecido.

Cliente enriquecido con componentes remotos

Un patrón frecuente de implementación para las aplicaciones de cliente enriquecido implementado en una intranet utiliza componentes remotos. El patrón está compuesto por un servidor que aloja los componentes de acceso a datos y los componentes empresariales, junto con todos los componentes de interfaz de usuario y de proceso de usuario implementados en el cliente (figura 4.4).

Figura 4.4. Cliente enriquecido con componentes remotos

Requisitos y consideraciones para el uso de un cliente enriquecido con componentes remotos:

  • Los clientes enriquecidos (1) disponen de componentes de interfaz de usuario implementados localmente (por ejemplo, Windows Forms, controles de usuario, etc.), así como de componentes de proceso de usuario (si se utilizan). Estos componentes se pueden implementar con SMS, a través de Active Directory, o bien, descargándolos con HTTP. Si la aplicación ofrece funcionalidad sin conexión, los clientes enriquecidos también proporcionarán el almacenamiento local y la infraestructura de cola necesaria para el trabajo sin conexión.

  • Aunque se muestran, los servidores de seguridad (2) y (4) sólo están presentes en los centros de datos empresariales de mayor tamaño. Los entornos pequeños dispondrán de clientes, servidores de aplicaciones y orígenes de datos en la intranet sin separación de red. El servidor de seguridad (2) necesitará puertos que se abran para la estrategia remota específica entre los clientes y los servidores (generalmente, un puerto TCP si se utiliza .NET remoting, o bien, puertos DCOM y Message Queue Server). El servidor de seguridad (4) requerirá puertos abiertos para tener acceso a la base de datos y permitir la coordinación de la transacción con los orígenes de datos.

  • Disponer de componentes empresariales remotos en la batería de aplicaciones (3) tal y como se muestra, permite a los demás clientes (por ejemplo, una batería de servidores Web orientada a Internet o intranet) compartir la implementación. Los componentes de acceso a datos también se ubicarán en esta batería y se tendrá acceso a los mismos de forma remota desde los clientes.

Cliente enriquecido con acceso del servicio Web

En algunos casos, se deseará ofrecer experiencia de cliente enriquecido a los usuarios mientras que se tiene acceso a los datos y a la lógica empresarial a través de Internet. En estos casos, se puede exponer la lógica empresarial y de acceso a datos empleada por el cliente en una fachada o interfaz de servicios. Los clientes enriquecidos pueden invocar esta interfaz de servicios directamente con los servidores proxy del servicio Web que genera Visual Studio .NET. Debido a que la funcionalidad enriquecida que necesita la interfaz de usuario se expone a una audiencia mayor, se debe prestar especial atención en las áreas de autenticación, autorización y comunicación segura entre los clientes la interfaz de servicios.

En la figura 4.5 se muestra el cliente enriquecido con el patrón de acceso al Web.

imagen

Figura 4.5. Cliente enriquecido con acceso del servicio Web

Requisitos y consideraciones para el uso de un cliente enriquecido con acceso del servicio Web:

  • Este escenario es similar al uso de un cliente enriquecido con componentes remotos, excepto en que en este caso una interfaz de servicios del servicio Web XML (archivo ASP.NET .asmx) proporciona acceso a las partes adecuadas de la lógica empresarial y de acceso a datos de la aplicación. Tal y como se muestra, este servicio puede tener acceso a los componentes de la aplicación localmente en la batería de aplicaciones (3), o bien, los componentes se pueden invocar de forma remota (no se muestra).

  • Los clientes enriquecidos pueden tener acceso a la funcionalidad del servidor utilizando formatos y protocolos estándar. El uso de SOAP permite que otros usuarios creen otras capas de IU que cumplan con sus necesidades.

Escenarios de integración de servicios

Los siguientes escenarios muestran patrones que se suelen utilizar cuando es necesario exponer e invocar aplicaciones y servicios externos.

Agentes de servicios e interfaces implementadas con componentes empresariales

La implementación de interfaces de servicios (como, por ejemplo, los servicios Web XML) y los agentes de servicios (componentes que puedan llamar a servicios Web o que puedan efectuar la conexión con otras plataformas) con la lógica empresarial constituye un escenario muy similar al de la implementación de interfaces de usuario de ASP.NET y los componentes de lógica empresarial de forma conjunta. La figura 4.6 muestra un patrón de implementación física para una aplicación basada en servicios.

imagen

Figura 4.6. Servicio con lógica empresarial local

Entre los requisitos y las consideraciones para el uso de agentes de servicios e interfaces con lógica empresarial local se incluyen:

  • Los clientes y servicios que llaman a la aplicación (1) pueden tener acceso a la batería de servidores Web mediante un servidor de seguridad (2) utilizando HTTP y posiblemente puertos SSL. La batería de servidores Web (3) puede alojar servicios Web XML, escuchas de Message Queue Server y otros códigos de interfaz de servicios.

  • Las interfaces de servicios de la batería de servidores Web invocan los componentes empresariales que residirán potencialmente en Enterprise Services. A la hora de determinar la infraestructura para los niveles de la aplicación utilizando Message Queue Server, es necesario considerar la escalabilidad y disponibilidad de la aplicación; será necesario crear una batería de servidores Web para poder equilibrar la carga de las llamadas del servicio Web XML, aunque si los componentes están recibiendo mensajes de Message Queue Server, deberá crear un clúster de conmutación por error para asegurar la disponibilidad del almacenamiento de mensajes. Los componentes se pueden establecer en batería, por lo que un clúster de conmutación por error puede que no sea el modo más eficaz desde el punto de vista económico para utilizar los servidores. Se puede optar por dividir el patrón de infraestructura utilizado para los mensajes de Message Queue Server y las llamadas del servicio Web de XML si un pequeño grupo de equipos no puede ofrecer los requisitos de escalabilidad y disponibilidad.

  • Las llamadas a los orígenes de datos (4) y los servicios internos (5) se pueden iniciar desde cualquier lugar de la batería. Esto requiere que el servidor de seguridad (5) permita las llamadas salientes (llamadas HTTP en el caso de los servicios Web). En Internet Data Center, las llamadas salientes realizadas fuera de los servicios se realizan a través de un servidor de seguridad lógico independiente (6). El uso de distintos servidores de seguridad que permiten sesiones HTTP entrantes y salientes en Internet puede aumentar la seguridad si los equipos que efectúan las llamadas y las que las reciben se encuentran en distintas redes VLAN. Contando con las reglas de servidor de seguridad adecuadas, los servidores de seguridad (2) y (6) se pueden combinar.

  • El acceso a los orígenes de datos se concede desde la batería de servidores Web y a través del servidor de seguridad (5). La batería de servidores Web deberá alojar a las bibliotecas cliente y administrar cadenas de conexión, lo cual incorpora importantes requisitos de seguridad.

  • Si los componentes están utilizando transacciones de Enterprise Services, los puertos RPC se abren en (5) para permitir el acceso a los orígenes de datos. Puede que sea necesario abrir los puertos de Message Queue Server en este servidor de seguridad si las colas se utilizan para efectuar la comunicación con los servicios internos.

Componentes empresariales separados de agentes de servicios e interfaces

Otro patrón utilizado en los escenarios de integración de servicios consiste en la separación de componentes empresariales de agentes e interfaces de servicios. Este modelo de infraestructura se emplea para separar los niveles que tienen contacto con Internet (mediante la recepción o la realización de llamadas a otros servidores) desde las baterías que alojan lógica empresarial. Al utilizar este patrón, también es necesario implementar componentes de agentes de servicios en un clúster diferente cuando se utiliza Message Queue Server para recibir mensajes, por lo que se puede obtener disponibilidad y, al mismo tiempo, disponer de una batería con equilibrio de carga que aloje componentes empresariales. La figura 4.7 muestra este enfoque.

Figura 4.7. Aislamiento de los agentes de servicios en una batería independiente(pulse aquí para ver la imagen)

Entre los requisitos y consideraciones relativos al uso de una batería de servidores Web con lógica empresarial remota se incluyen:

  • Con la llamada a los servicios (1) se puede tener acceso a las interfaces de servicios en la batería de servidores Web (3) que aloja servicios Web XML o extremos HTTP de Message Queue Server a través de un servidor de seguridad (2) utilizando HTTP y probablemente puertos SSL.

  • La batería de servidores Web puede alojar servicios Web XML y probablemente componentes de lógica de acceso a datos, tal y como se analiza en el capítulo 2, "Diseño de los componentes de una aplicación o servicio". Los componentes de acceso a datos se pueden implementar en esta batería de servidores Web para aprovechar los DataReaders con el fin de procesar los datos para los resultados de las llamadas del servicio Web. Sin embargo, si se lleva a cabo esta operación, será necesario permitir el acceso a la base de datos a través de un segundo servidor de seguridad (4). Si ello compromete la seguridad, será necesario tener acceso de forma remota a los datos proporcionados por los componentes de nivel de acceso a datos y los componentes empresariales.

  • Todos los componentes empresariales se alojan en una batería de aplicaciones (4) a la que los demás clientes también pueden tener acceso. A estos componentes se obtiene acceso desde la batería de servidores Web a través del segundo servidor de seguridad. Dependiendo del canal de comunicación que se emplee, puede que sea necesario abrir diferentes puertos. Si los componentes empresariales se alojan en Enterprise Services, será necesario abrir los puertos RPC para DCOM. Para obtener más información sobre los requisitos del puerto, consulte la sección "Diseño de la directiva de comunicaciones" incluida en el capítulo 3, "Directivas de seguridad, administración operativa y comunicaciones".

  • Los componentes empresariales llamarán a los componentes de acceso a datos (5) y a los agentes de servicios para servicios internos localmente (6). A las bases de datos y a los servicios internos se tendrá acceso mediante el servidor de seguridad (7).

  • Una infraestructura dispondrá de un servidor de seguridad (4) o (7) en su lugar correspondiente, dependiendo de si los componentes empresariales pueden estar dentro de la red perimetral (DMZ) o necesitan protección adicional. Internet Data Center proporciona la capacidad de disponer de ambos.

  • Si los componentes están utilizando transacciones de Enterprise Services, los puertos RPC se abren en el servidor de seguridad (7) para permitir el acceso a los orígenes de datos.

  • Los agentes de servicios (8) que necesitan realizar llamadas fuera de Internet se pueden implementar en una batería de servidores Web (u otra batería) para aislar el nivel que tiene exposición a Internet desde la lógica empresarial que tiene acceso a las bases de datos y a los servicios internos. Se debe tener en cuenta que existen dos servidores de seguridad que separan la aplicación de Internet; uno para las llamadas entrantes (2) y otro para las salientes (9). Si se está implementando la seguridad mediante el aislamiento, se debe hacer uso de esta implementación para implementar agentes de servicios de forma remota. Si necesita consolidar los servidores que alojan las interfaces y los agentes de servicios, también se puede efectuar la combinación de dos servidores de seguridad en un servidor de este tipo con los puertos de entrada y salida abiertos.

Clústeres EAI y componentes de la aplicación

Los componentes de integración de aplicaciones empresariales (Enterprise Application Integration, EAI) se deben enfocar por separado respecto a la infraestructura que aloja las aplicaciones tradicionales.

No obstante, es probable que el clúster EAI aloje flujos de trabajo empresariales que utilicen componentes empresariales para implementar etapas en los procesos empresariales. Estos componentes se pueden alojar localmente o de forma remota desde el clúster que ejecuta el flujo de trabajo empresarial. En este caso se cuenta con tres opciones:

  • Los componentes empresariales se pueden alojar localmente en el clúster EAI si éste puede tener acceso a la base de datos y si los componentes sólo se van a utilizar en el contexto de los flujos de trabajo que se ejecutan en este clúster.

  • A los componentes empresariales se les puede llamar a través de .NET remoting, DCOM o los servicios Web XML y tener acceso a los mismos en la batería de servidores Web o aplicaciones donde se implementen. Esto implica que el clúster EAI puede realizar llamadas a la batería de aplicaciones.

  • Finalmente, los ensamblados de los componentes empresariales se pueden implementar tanto en el clúster EAI como en la batería de servidores Web o aplicaciones, con los costes de administración que implica disponer del mismo ensamblado en varias ubicaciones.

La figure 4.8 muestra una opción de configuración para los clústeres EAI, en la que se separan los componentes EAI de los componentes empresariales.

imagen

Figura 4.8. Separación de los componentes EAI de los componentes empresariales

La figura 4.8 muestra los componentes de interfaz en una batería de servidores Web (1) llamando a los componentes empresariales de una batería de aplicaciones (2) que, a su vez, trabaja con el origen de datos de la aplicación (3). El clúster EAI (4) tiene sus propios componentes empresariales necesarios para realizar los pasos en su flujos de trabajo empresariales correspondientes y obtiene acceso a otros servicios (sólo a servicios internos en este ejemplo) a través de un servidor de seguridad (5).

Composición de escenarios de implementación

Los patrones de implementación analizados anteriormente se suelen encontrar en aplicaciones de óptima arquitectura. Es obvio que los escenarios concretos pueden variar y puede que estos ejemplos no coincidan precisamente con sus requisitos y necesidades. En función de estos patrones se puede componer casi cualquier infraestructura necesaria para una aplicación en capas. Lo más importante es adaptarse al modelo conceptual señalado anteriormente para comprender el diseño de la aplicación, de la infraestructura y el modo en que ambos ejercen una influencia entre sí desde el primer momento del ciclo de vida de la aplicación.

Entornos de producción, prueba y ensayo

Se puede disponer de centros de datos independientes para el desarrollo, la prueba, el ensayo y la prueba de carga de la aplicación. Estos centros de datos variarán en el diseño, principalmente porque no resulta rentable disponer de una centro de producción de datos únicamente destinado al ensayo de la aplicación. Si los centros de datos son distintos, se debe considerar lo siguiente:

  • Servidores de seguridad: aunque no se disponga de servidores de seguridad implementados en entornos que no sean de producción, se debe realizar un planeamiento y una comprobación de antemano teniendo en cuenta las restricciones de los puertos y la dirección de la comunicación. Los productos de software que emulan a los servidores de seguridad se encuentran disponibles y resultan un elemento adicional adecuado para la plataforma de prueba.

  • Topología de red: el entorno de ensayo puede ser más pequeño que el de producción, aunque se debe intentar mantener una coherencia en la topología de red. Es decir, se debe asegurar que la comunicación a través de los equipos funcione del modo esperado.

  • Número de procesadores: si el entorno de destino cuenta con varios procesadores, la aplicación se debe probar en varios de ellos para asegurarse de que el código multiproceso no se comporte de forma inesperada.

Requisitos operativos

El objetivo del siguiente tema de análisis consiste en proporcionar las técnicas de diseño y las prácticas que permitirán obtener los requisitos operativos (no funcionales) para la aplicación y los servicios. Entre estos requisitos se incluyen los niveles de escalabilidad, disponibilidad, mantenimiento, seguridad y facilidad de uso que debe obtener la aplicación. Estos factores pueden afectar al diseño de las directivas de la aplicación, aunque también pueden influir en el modo de diseño de la lógica de la aplicación.

En algunos casos, el cumplimiento con algunos requisitos supondrá la aparición de retos para llevar a cabo otros. Por ejemplo, es frecuente reducir la facilidad de uso de una aplicación para mejorar la seguridad. Es importante otorgar prioridad a las características de la aplicación que admiten los requisitos operativos desde un primer momento del ciclo de vida, por lo que estos equilibrios y decisiones se pueden tener en cuenta en la implementación de la aplicación desde un primer momento.

El siguiente análisis no es en absoluto exhaustivo, pero servirá para destacar puntos los claves relativos a los requisitos operativos más relevantes.

Escalabilidad

La escalabilidad de una aplicación es la capacidad de la misma para proporcionar un nivel aceptable de rendimiento general cuando aumentan uno o varios factores de carga. Entre estos factores se incluyen el número de usuarios, la cantidad de datos que administra la aplicación, así como el número de transacciones.

El rendimiento general se puede medir en términos de productividad y tiempo de respuesta. Con el rendimiento se mide la cantidad de trabajo que la aplicación puede realizar en un margen de tiempo establecido; con el tiempo de respuesta la cantidad de tiempo que transcurre entre que un usuario o proceso realizan una solicitud y los resultados de la misma. Existe una serie de factores que pueden afectar tanto al rendimiento como al tiempo de respuesta, entre los que se incluyen el rendimiento del hardware, los recursos físicos como la memoria y la latencia de red (cantidad de tiempo que transcurre para transmitir los datos a través de un vínculo de red) y el diseño de la aplicación. Mientras que muchos problemas de rendimiento y escalabilidad se pueden resolver aumentando los recursos de hardware, una aplicación que no cuente con un diseño enfocado para un funcionamiento eficaz siempre presentará problemas de rendimiento independientemente del hardware que se incorpore.

Para las aplicaciones de gran escalabilidad se deben considerar las siguientes instrucciones de diseño:

  • Utilizar operaciones asíncronas. El tiempo de respuesta y la demanda de rendimiento se pueden reducir con operaciones asíncronas.
    Estas operaciones requieren que el usuario espere hasta que se complete una operación empresarial. Al hacer asíncronas las operaciones empresariales, el control del sistema puede volver al usuario de forma más rápida y el procesamiento de solicitudes se puede poner en cola, con lo que se ayuda a controlar la demanda de rendimiento sin saturar los componentes empresariales. Por ejemplo, un usuario realiza un pedido en un sitio de comercio electrónico. Si el proceso de pedido se realiza de forma sincrónica, el usuario tendrá que esperar hasta que la tarjeta de crédito haya obtenido autorización y el producto se haya solicitado al proveedor antes de recibir confirmación. Si el proceso de pedido se implementa asincrónicamente, el usuario puede obtener confirmación o un mensaje de error por correo electrónico una vez completada la operación. El diseño de aplicaciones asíncronas implica mayor trabajo para el desarrollador (especialmente cuando es necesaria la lógica transaccional), pero la escalabilidad puede mejorar en gran medida.

  • Almacenar datos en la memoria caché cuando sea necesario. Siempre que se pueda, se debe intentar almacenar la información en caché en la ubicación donde sea necesario, con lo que se reducirá el número de solicitudes de datos remotos realizados en el almacén de datos. Por ejemplo, el sitio de comercio electrónico descrito anteriormente proporcionará un mayor nivel de escalabilidad si la información del producto se almacena en la memoria caché en el sitio Web en lugar de recuperarse de la base datos cada vez que un usuario intente ver una lista de productos.

  • Evitar el estado de espera innecesariamente. Siempre que se pueda, las operaciones se deben diseñar para ser sin estado. De este modo, se evitará la contención de recursos, se mejorará la coherencia de los datos y se permitirá que las solicitudes presenten equilibrio de carga a través de varios servidores en una batería. En ciertas ocasiones, el estado se debe mantener; por ejemplo, el carro de la compra de un cliente se debe almacenar a lo largo de las solicitudes HTTP. En estos escenarios, se debe planear detenidamente la persistencia del estado y la lógica de restablecimiento. Únicamente se debe restablecer el estado cuando sea realmente necesario (por ejemplo, cuando un usuario desee ver su carro de la compra o realizar un pago).

  • Evitar la contención de recursos. Ciertos recursos como, por ejemplo, las conexiones de bases de datos, son limitados y otros, como el bloqueo de la base de datos, son exclusivos. El diseño de la aplicación se debe realizar de tal modo que los recursos se mantengan el menor tiempo posible. La agrupación de la conexión de la base de datos se debe realizar de forma eficaz y las operaciones se deben diseñar para abrir los recursos más complejos en último lugar (de modo que no se mantengan durante toda la operación). Especialmente esto sucede con el uso de transacciones atómicas. Por ejemplo, si numerosas partes de la aplicación utilizan la tabla Orders de la base de datos, la inserción de los datos del pedido debe ser el último paso del proceso para evitar un bloqueo de la tabla mientras se espera la autorización de la tarjeta de crédito.

  • Datos de partición, recursos y operaciones. La carpa de la aplicación se puede extender en las baterías de servidores utilizando tecnologías de equilibrio de carga como, por ejemplo, Equilibrio de carga en la red. Esto permite adoptar una estrategia "de escalabilidad hacia fuera" con la que se aumenta la escalabilidad simplemente agregando más servidores a la batería. La escalada hacia fuera suele ser más rentable que la escalabilidad ascendente con la adición de recursos de hardware a los servidores.
    Las bases de datos se deben escalar de forma ascendente agregando fundamentalmente recursos de hardware; no obstante, los datos también se pueden escalar hacia fuera mediante la partición de la base de datos en distintos servidores de bases de datos, donde cada servidor asumirá la responsabilidad de un subconjunto de los datos. La lógica del enrutamiento dinámico de datos se utiliza en el nivel medio para dirigir las solicitudes al servidor de base de datos adecuado. Para obtener más información sobre la partición en una base de datos de SQL Server, consulte el capítulo 5, "Diseño de bases de datos de SQL Server" de la "Guía de arquitectura de referencia de Internet Data Center" en TechNet

Disponibilidad

La disponibilidad es una medida del porcentaje de tiempo en el que la aplicación puede responder a las solicitudes de modo que los autores de la llamada estén en espera. Ocasionalmente incluso las aplicaciones más sólidas no están disponibles, aunque la aplicación se debe diseñar de forma que el riesgo de las interrupciones inesperadas se vean reducidas. Para las aplicaciones empresariales importantes, muchas organizaciones tienen como objetivo alcanzar los "cinco nueves" o 99,999% de disponibilidad; este nivel de solidez requiere un detallado diseño y planeamiento.

En el diseño de la aplicación se deben tener en cuenta las siguientes estrategias de elevada disponibilidad:

  • Evitar indicios de error. En el diseño de la aplicación y la infraestructura de implementación, se debe intentar evitar la presencia de cualquier componente que, sin conexión, podría hacer que la aplicación quedara inutilizable. Para evitar los indicios de error en una batería de servidores Web o aplicaciones, se puede utilizar el software de administración de equilibrio de carga, como el que se proporciona con Microsoft Application Center, con el que se eliminarán los servidores que dejen de responder de una batería con equilibrio de carga sin que las operaciones de los servidores restantes se vean interrumpidas.
    Los datos empresariales se deben almacenar en almacenes de datos (tales como bases de datos o colas) que se implementen en clústeres de conmutación por error, de forma que si se produce un error en un servidor que controla el almacén de información, la aplicación "realice una conmutación por error" en el servidor inactivo.
    Asimismo, se deben proporcionar rutas de datos redundantes para que existan varias rutas de red físicas hacia el servidor de base de datos y para que la aplicación pueda continuar en funcionamiento en caso de un error de cable en la red.
    Para proteger la aplicación de errores en el disco duro, se deben aplicar medidas de redundancia en disco como, por ejemplo, las tecnologías de Matriz redundante de discos económicos (RAID).

  • Utilizar el almacenamiento en memoria caché y la puesta en cola para reducir los requisitos de "mismo tiempo y ubicación". El almacenamiento en la memoria caché de los datos de referencia de sólo lectura cuando resulte necesario no sólo proporciona escalabilidad mejorada, sino que también reduce la dependencia del almacén de datos subyacentes. Si la base de datos no se encuentra disponible, la aplicación puede continuar en funcionamiento debido a que los datos aún se almacenan en la memoria caché.
    Del mismo modo, con la puesta en cola de las solicitudes para insertar o actualizar datos, la aplicación podrá gestionar solicitudes de clientes incluso cuando los orígenes de datos subyacentes y los servicios no estén disponibles. Esto permitirá a una organización de comercio electrónico continuar recogiendo pedidos, aunque la información del pedido no se pueda registrar inmediatamente en la base de datos.

  • Planear una estrategia eficaz de copia de seguridad. Independientemente de las medidas de elevada disponibilidad, se debe asegurar que se dispone una estrategia eficaz de copia de seguridad que reduzca el tiempo empleado en restablecer el sistema a un estado de funcionamiento en caso de error grave.

  • Proceso riguroso de prueba y depuración del código. Es obvio que el código siempre se debe probar y depurar; cuando una elevada disponibilidad se convierte en un requisito, resulta incluso más importante asegurarse de que se hayan eliminado todos los bucles infinitos potenciales, las pérdidas de memoria y las excepciones no controladas que pueden generar errores en la aplicación o que ésta deje de responder.

Capacidad de mantenimiento

En relación con el mantenimiento, la aplicación se debe diseñar e implementar de modo que se pueda mantener y repara con facilidad.

Se deben tener en cuenta las siguientes recomendaciones:

  • Estructuración del código de forma previsible. La presencia de técnicas de codificación coherentes en la aplicación facilita el mantenimiento de la misma. Se debe emplear una convención estandarizada para el espacio de nombres, variables, clases, nombres de constante, límites de matriz coherentes y comentarios entre líneas.

  • Aislamiento de los comportamientos y datos que cambian con frecuencia. La lógica y los datos que cambien con frecuencia se deben encapsular en componentes separados que se puedan actualizar de forma independiente respecto al resto de la aplicación.

  • Uso de metadatos para la configuración y los parámetros del programa. El almacenamiento de los datos de configuración de la aplicación, tales como las cadenas de conexión y las variables de entorno, en depósitos de metadatos externos (p. ej, archivos de configuración XML) facilita el cambio de estos valores en el entorno de producción sin la edición del código y la nueva compilación de la aplicación. Para obtener más información sobre el uso de los metadatos, consulte la sección "Diseño de la directiva de administración operativa" del capítulo 3, "Directivas de seguridad, administración operativa y comunicaciones".

  • Uso de tipos conectables. Si una parte de la lógica de la aplicación se puede implementar de varias maneras, resulta útil definir una interfaz y dejar que la aplicación cargue la clase correcta que implemente la interfaz en tiempo de ejecución. Esto permite "conectar" otros componentes que implementen la interfaz una vez que se haya implementado la aplicación sin tener que modificarla. Los nombre completos de tipos cualificados se pueden almacenar en un almacén de configuración y utilizarse para crear una instancia de los objetos en tiempo de ejecución. Cuando se utiliza este enfoque, se debe asegurar que el almacén de configuración está asegurado correctamente para evitar que los intrusos fuercen la aplicación para utilizar un componente de creación propia.

  • Diseño de la interfaz. El diseño de la interfaz se debe realizar modo que todas las propiedades públicas y los parámetros del método sean de tipos comunes. Con el uso de tipos comunes se reducen las dependencias entre los componentes y sus consumidores.

Seguridad

La seguridad siempre ha sido un aspecto fundamental en el diseño de una aplicación, especialmente cuando la misma se expone en el Web. En gran parte, las decisiones que se adopten en relación a la seguridad dependerán de la directiva de seguridad. Independientemente de los detalles específicos de la directiva de seguridad, siempre se deben tener en cuenta las siguientes recomendaciones:

  • Evaluar los riesgos. Durante el proceso de diseño de la aplicación se debe dedicar algún tiempo para evaluar los riesgos plantea cada decisión de implementación. Se deben tener en cuenta los riesgos internos, así como los que presentan por intrusos externos. Por ejemplo, se pueden utilizan conexiones HTTP seguras para evitar que un número de tarjeta de crédito de un cliente se "vea descubierto" a medida que pasa al sitio a través de Internet, aunque si el número se almacena en texto sin formato en la base de datos, se corre el riesgo de que un empleado sin autorización tenga al acceso al mismo.

  • Aplicar el principio del "menor número de privilegios" . Se trata de una directiva de diseño de seguridad estándar que asegura que cada cuenta de usuario disponga exactamente del mismo nivel de privilegio para realizar las tareas necesarias y ninguna más. Por ejemplo, si una aplicación necesita leer datos de un archivo, a la cuenta de usuario que utiliza se le debe asignar permiso de lectura, pero no de modificación ni de control total. Ninguna cuenta debe tener permiso para realizar ninguna operación que no sea necesaria

  • Realizar comprobaciones de autenticación en el límite de cada zona de seguridad. La autenticación siempre se debe realizar "en la entrada". Un proceso de usuario no debe poder realizar ninguna tarea en una zona de seguridad determinada hasta que se haya establecido una identidad válida

  • Consideración de la función del contexto de usuario en procesos empresariales asíncronos. Si la aplicación realiza tareas empresariales de forma asíncrona, se debe tener en cuenta que el contexto de usuario es menos significativo que la tarea realizada sincrónicamente. Se debe considerara el uso de un modelo de "servidor de confianza" para las operaciones asíncronas, en lugar de un enfoque de representación/delegación.

Facilidad de uso

La directiva de administración operativa de la organización determinará los aspectos de la aplicación que es necesario administrar. La instrumentación se debe diseñar en la aplicación de modo que se exponga la información de administración más importante, necesaria para la realización de una supervisión del correcto funcionamiento, comprobación del contrato de nivel de servicio mínimo (SLA) y planeamiento de la capacidad. Para obtener un análisis más completo sobre la administración de aplicaciones distribuidas basadas en .NET, consulte el capítulo 3, "Directivas de seguridad, administración operativa y comunicaciones".

Rendimiento

El rendimiento del servicio y la aplicación es un factor clave en una buena experiencia del usuario y en la utilización eficaz del hardware. Mientras que el rendimiento es una atributo que se puede mejorar ajustando la implementación y el código del sistema una vez creado, es importante considerarlo en las fases de diseño y arquitectura. Un análisis detallado sobre del perfil excede el ámbito de esta guía. Sin embargo puede seguir este proceso en distintas fases del prototipo de la aplicación, desarrollo, prueba, etc; para asegurar que se cumple con los objetivos de rendimiento o que las expectativas se restablecen lo antes posible:

  1. Defina los requisitos de rendimiento perceptible para las operaciones específicas (por ejemplo, rendimiento y/o latencia en ciertas condiciones de uso como, por ejemplo, "50 solicitudes por segundo con un promedio del 70% de uso de CPU en una configuración de hardware específica").

  2. Realice pruebas de rendimiento: Someta al sistema a una prueba de carga y recopile la información de perfil

  3. Analice los resultados: ¿cumple la aplicación con los objetivos de rendimiento?

  4. Si no es así, identifique los cuellos de botella en la aplicación. (Para obtener información sobre herramientas que pueden ayudarle a aislar los cuellos de botella de rendimiento, consulte los artículos a los que se hace referencia al final de esta lista.)

  5. Repita el paso 2 hasta que los resultados de rendimiento cumplan los objetivos

Los siguientes artículos incluyen información necesaria para llevar a cabo este proceso:

Comentarios y compatibilidad

Si desea formular alguna pregunta sobre la guía, o realizar algún comentario o sugerencia, sobre esta guía, envíe un mensaje de correo electrónico a la siguiente dirección: devfdbck@microsoft.com.

Mostrar:
© 2014 Microsoft