Diseño de aplicaciones y servicios

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 describe la arquitectura de alto nivel de una aplicación o servicio .NET distribuido.

Arquitectura de aplicaciones de .NET: Diseño de aplicaciones y servicios proporciona instrucciones sobre el nivel de arquitectura y diseño para arquitectos y desarrolladores de aplicaciones que necesitan generar soluciones distribuidas con Microsoft® .NET Framework.

Debe leer esta guía si:

  • Diseña arquitectura de alto nivel para aplicaciones o servicios.

  • Recomienda tecnologías apropiadas para aspectos específicos de su aplicación o servicio.

  • Toma decisiones de diseño que cumplen requisitos funcionales y no funcionales (operativos).

  • Elige los mecanismos de comunicaciones adecuados para su aplicación o servicio.

Esta guía identifica las decisiones de diseño clave que necesita tomar durante las primeras fases del desarrollo y proporciona instrucciones a nivel de diseño que le ayudarán a elegir entre distintas opciones de diseño. Asimismo, le ayuda a desarrollar un diseño global mediante la presentación de una arquitectura coherente construida con distintos tipos de componentes que le ayudarán a lograr un buen diseño y beneficiarse de la plataforma Microsoft. Aunque esta guía no pretende proporcionar instrucciones a nivel de implementación para cada aspecto de la aplicación, ofrece referencias a determinadas guías Microsoft Patterns & Practices, artículos de MSDN y sitios de comunidad que debaten con detalle varios aspectos del diseño de aplicaciones distribuidas. Puede considerar este documento como una guía básica de los aspectos más importantes relativos al diseño de aplicaciones distribuidas con los que se encontrará al utilizar la plataforma Microsoft.

Esta guía se centra en aplicaciones distribuidas y servicios Web que puede que sean necesarios para proporcionar capacidades de integración para varios orígenes de datos y servicios, así como que requieran una interfaz de usuario para uno o varios dispositivos.

El artículo asume que está familiarizado con el desarrollo de componentes .NET y los principios básicos del diseño de aplicaciones distribuidas con capas.

En esta página

Objetivos del diseño de aplicaciones distribuidas  Objetivos del diseño de aplicaciones distribuidas
Servicios e integración de servicios Servicios e integración de servicios
Componentes y niveles en aplicaciones y servicios Componentes y niveles en aplicaciones y servicios
Escenario de ejemplo Escenario de ejemplo
Escenario de ejemplo Escenario de ejemplo

Objetivos del diseño de aplicaciones distribuidas

El diseño de una aplicación distribuida implica la toma de decisiones sobre su arquitectura lógica y física, así como sobre la tecnología e infraestructura que se emplearán para implementar su funcionalidad. Para tomar estas decisiones, debe tener un conocimiento claro de los procesos empresariales que realizará la aplicación (sus requisitos funcionales), así como los niveles de escalabilidad, disponibilidad, seguridad y mantenimiento necesarios (sus requisitos no funcionales, funcionales u operativos).

El objetivo consiste en diseñar una aplicación que:

  • Solucione el problema empresarial para el que se diseña.

  • Tenga en consideración la seguridad desde el principio, teniendo en cuenta los mecanismos adecuados de autenticación, la lógica de autorización y la comunicación segura.

  • Proporcione un alto rendimiento y esté optimizada para operaciones frecuentes entre patrones de implementación.

  • Esté disponible y sea resistente, capaz de implementarse en centros de datos de alta disponibilidad y redundantes.

  • Permita la escalabilidad para cumplir las expectativas de la demanda y admita un gran número de actividades y usuarios con el mínimo uso de recursos.

  • Se pueda administrar, permitiendo a los operadores implementar, supervisar y resolver los problemas de la aplicación en función del escenario.

  • Se pueda mantener. Cada parte de funcionalidad debería tener una ubicación y diseño predecibles teniendo en cuenta distintos tamaños de aplicaciones, equipos con conjuntos de habilidades variadas y requisitos técnicos y cambios empresariales.

  • Funcione en los distintos escenarios de aplicaciones y patrones de implementación.

Las instrucciones de diseño que se ofrecen en los siguientes capítulos persiguen estos objetivos y explican los motivos para las decisiones de un diseño en particular siempre que sea importante para entender su fondo.

Servicios e integración de servicios

A medida que crece Internet y las tecnologías relacionadas, y las organizaciones buscan integrar sus sistemas entre límites de departamentos y de organización, ha evolucionado un enfoque de generación de soluciones basado en servicios. Desde el punto de vista del consumidor, los servicios son conceptualmente similares a los componentes tradicionales, salvo que los servicios encapsulan sus propios datos y no forman parte, estrictamente hablando, de la aplicación sino que son utilizados por ésta. Aplicaciones y servicios que necesitan integrarse se pueden generar en distintas plataformas, por distintos equipos, en diferentes programas y se pueden mantener y actualizar de forma independiente. Por tanto, es esencial que implemente la comunicación entre ellos con el mínimo acoplamiento.

Se recomienda que implemente la comunicación entre los servicios empleando técnicas basadas en mensajes para proporcionar altos niveles de solidez y escalabilidad. Puede implementar la comunicación de mensajes de forma explícita (por ejemplo, escribiendo código para enviar y recibir mensajes de Message Queue Server), o bien, puede utilizar componentes de infraestructuras que administran la comunicación de forma implícita (por ejemplo, con un servidor proxy de servicios Web generado por Microsoft Visual Studio® .NET).

Nota

El término servicio se utiliza en esta guía para hacer referencia a los componentes de software externos que proporcionan servicios empresariales. Esto incluye, aunque no exclusivamente, los servicios Web XML.

Los servicios exponen una interfaz de servicios a la que se envían todos los mensajes entrantes. La definición del conjunto de mensajes que se deben intercambiar con un servicio para que éste realice una tarea empresarial específica constituye un contrato. Puede imaginarse una interfaz de servicios como una fachada que expone la lógica empresarial implementada en el servicio para consumidores potenciales.

Por ejemplo, considere una aplicación comercial de venta a través de la cual los clientes solicitan productos. La aplicación utiliza un servicio de autorización de tarjetas de crédito externas para validar los detalles de la tarjeta de crédito del cliente y autorizar la venta. Una vez comprobados los datos de la tarjeta de crédito, se utiliza un servicio de correo para organizar la entrega de los productos. El siguiente diagrama de secuencias (Figura 1.1) muestra este escenario.

imagen

Figura 1.1. Proceso empresarial implementado utilizando servicios

En este escenario, el servicio de autorización de las tarjetas de crédito y el servicio de correo desempeñan cada uno una función en el proceso empresarial global de compra. A diferencia de los componentes ordinarios, los servicios existen en sus propios límites de confianza y administran sus propios datos, fuera de la aplicación. Por tanto, debe estar seguro de establecer una conexión segura y autenticada entre la aplicación de llamada y el servicio cuando utilice un enfoque basado en servicios para el desarrollo de aplicaciones. Además, podría implementar la comunicación mediante el uso de un enfoque basado en mensajes, haciendo el diseño más adecuado para describir procesos empresariales (a veces denominados transacciones empresariales o transacciones de ejecución larga) y para el acoplamiento flexible de sistemas que son frecuentes en soluciones distribuidas de gran tamaño, especialmente si el proceso empresarial implica varias organizaciones y distintas plataformas.

Por ejemplo, si las comunicaciones basadas en mensajes se utilizan en el proceso mostrado en la figura 1.1, el usuario puede recibir la confirmación del pedido segundos u horas después de que se proporcionara la información de venta, dependiendo de la capacidad de respuesta de los servicios de autorización y entrega. La comunicación basada en mensajes permite también realizar el diseño de la lógica empresarial de forma independiente al protocolo de transporte subyacente utilizado entre los servicios.

Si la aplicación utiliza un servicio externo, la implementación interna del servicio le es indiferente al diseño; siempre que el servicio realice lo que se supone que debe realizar. Simplemente necesita saber la funcionalidad empresarial que ofrece el servicio y los detalles del contrato que debe respetar para comunicarse con el mismo (como el formato de comunicación, esquema de datos, mecanismo de autenticación, etc.). En el ejemplo de la aplicación comercial, el servicio de autorización de tarjetas de crédito ofrece una interfaz a través de la cual se pueden pasar al servicio los detalles sobre la venta y la tarjeta de crédito, así como la respuesta indicando si se aprueba o no la venta. Desde la perspectiva del diseñador de la aplicación comercial, lo que sucede dentro del servicio de autorización de tarjetas de crédito es irrelevante; lo único que importa es determinar qué datos es necesario que se envíen al servicio, qué respuestas se recibirán del servicio y cómo comunicarse con el servicio.

Internamente, los servicios contienen varios tipos de componentes comunes a las aplicaciones tradicionales. (El resto de esta guía se centra en los distintos componentes y su función en el diseño de la aplicación.) Los servicios contienen componentes de lógica que organizan las tareas empresariales que realizan, los componentes empresariales que implementan la lógica empresarial real del servicio y los componentes de acceso a datos que tienen acceso al almacén de datos del servicio. Además, los servicios exponen su funcionalidad a través de interfaces de servicio, que controlan la semántica utilizada para exponer la lógica empresarial subyacente. La aplicación también llamará a otros servicios a través de los agentes de servicios, que se comunican con el servicio de parte de la aplicación cliente que realiza la llamada.

Aunque los servicios basados en mensajes se pueden diseñar para que se llamen sincrónicamente, puede resultar ventajoso generar interfaces de servicios asincrónicos, que permiten un enfoque de acoplamiento flexible en el desarrollo de aplicaciones distribuidas. El acoplamiento flexible que ofrece la comunicación asincrónica posibilita la generación de soluciones de alta disponibilidad, escalabilidad y duración formadas por servicios existentes. Sin embargo, un diseño asincrónico no proporciona estas ventajas de forma gratuita: el uso de la comunicación asincrónica indica que el diseño puede necesitar tener en cuenta consideraciones especiales como la correlación de mensajes, la administración de concurrencia de datos optimista, la compensación de procesos empresariales y la no disponibilidad de servicios externos.

Nota

El capítulo 3, "Directivas de seguridad, administración operativa y comunicaciones", trata con mayor detalle los problemas que surgen en la implementación de la comunicación del servicio.

Para obtener más información sobre los servicios y los conceptos relacionados, consulte "Application Conceptual View" (en inglés) en MSDN (http://msdn.microsoft.com/library/en-us/dnea/html/eaappconland.asp).

Componentes y niveles en aplicaciones y servicios

Se ha convertido en un principio ampliamente aceptado en el diseño de aplicaciones distribuidas la división de la aplicación en componentes que ofrezcan servicios de presentación, empresariales y de datos. Los componentes que realizan tipos de funciones similares se pueden agrupar en capas, que en muchos casos están organizados en forma de apilamiento para que los componentes que se encuentran por "encima" de una capa determinada utilicen los servicios proporcionados por ésta, y un componente especifico utilizará la funcionalidad proporcionada por otros componentes de su propia capa, y otras capas "inferiores", para realizar su trabajo.

Nota

Esta guía utiliza el término capa para hacer referencia a un tipo de componente y el término nivel para hacer referencia a los patrones de distribución físicos.

Esta visión dividida de una aplicación también se puede aplicar a los servicios. Desde un punto de vista de alto nivel, se puede considerar que la solución basada en servicios está formada por varios servicios, los cuales se comunican entre sí pasando mensajes. Desde el punto de vista conceptual, los servicios se pueden considerar como componentes de la solución global. Sin embargo, internamente el servicio está formado por componentes de software, al igual que cualquier otra aplicación, los cuales se pueden agrupar de forma lógica en servicios de presentación, empresariales y de datos, tal y como se muestra en la figura 1.2.

imagen

Figura 1.2. Solución basada en servicios

Los aspectos importantes que se deben tener en cuenta de esta figura son los siguientes:

  1. Los servicios se diseñan generalmente para comunicarse entre sí con el mínimo grado de acoplamiento. El uso de la comunicación basada en mensajes ayuda a desacoplar la disponibilidad y escalabilidad de los servicios, y basarse en los estándares de la industria, como los servicios Web XML, permite la integración con las demás plataformas y tecnologías.

  2. Cada servicio está formado por una aplicación que dispone de sus propios orígenes de datos, lógica empresarial e interfaces de usuario. Un servicio puede presentar el mismo diseño interno que una aplicación tradicional de tres niveles, por ejemplo, los servicios (2) y (4) de la figura anterior.

  3. Puede generar y exponer un servicio que no disponga de una interfaz de usuario directamente asociada (un servicio diseñado para que lo invoquen otras aplicaciones a través de una interfaz de programación). Esto se muestra en el servicio (3). Observe que los componentes que forman un servicio y los componentes que componen las capas empresariales de una aplicación se pueden diseñar de forma similar.

  4. Cada servicio encapsula sus propios datos y administra las transacciones atómicas con sus propios orígenes de datos.

Es importante tener en cuenta que las capas son simplemente agrupaciones lógicas de los componentes de software que conforman la aplicación o servicio. Ayudan a diferenciar entre los distintos tipos de tareas que realizan los componentes, facilitando el diseño de la reutilización en la solución. Cada capa lógica contiene un número de tipos de componentes discretos agrupados en subcapas, cada una de las cuales realiza el mismo tipo de tarea específica. Al identificar los tipos genéricos de componentes que existen en la mayoría de las soluciones, puede construir un mapa coherente de una aplicación o servicio y, a continuación, utilizar este mapa como plano técnico para el diseño.

En la figura 1.3 se muestra una visión simplificada de una aplicación y sus capas.

imagen

Figura 1.3. Componentes separados en capas según sus funciones

Una solución distribuida puede que necesite abarcar varias organizaciones o niveles físicos, en cuyo caso tendrá sus propias directivas en relación a la seguridad, administración operativa y comunicaciones de la aplicación. Estas unidades de confianza, o zonas, pueden ser un nivel físico, un centro de datos o un departamento, sección o empresa que tenga estas directivas definidas. Unidas, estas directivas definen reglas para el entorno en el que se implementa la aplicación y la forma en que los niveles del servicio o aplicación se comunican. Las directivas abarcan toda la aplicación y la forma en que se implementan afecta a las decisiones sobre el diseño en cada nivel. También tienen un impacto entre sí (por ejemplo, la directiva de seguridad determina algunas de las reglas en la directiva de comunicación y viceversa).

Nota

Para obtener más información sobre el diseño de directivas de seguridad, administración operativa y comunicaciones, consulte el capítulo 3, "Directivas de seguridad, administración operativa y comunicaciones".

Escenario de ejemplo

Para ayudar a identificar los tipos frecuentes de componentes, esta guía describe una aplicación de ejemplo que utiliza servicios externos. Aunque esta guía se centra en un ejemplo concreto, las recomendaciones de diseño indicadas se aplican a la mayor parte de las aplicaciones distribuidas, independientemente del escenario empresarial real.

El escenario descrito en esta guía es una extensión de la aplicación comercial descrita anteriormente en este capítulo. En este escenario, una empresa de venta al por menor ofrece a sus clientes la posibilidad de solicitar productos a través de un sitio Web de comercio electrónico o por teléfono. Los usuarios de Internet pueden visitar el sitio Web de la compañía y seleccionar productos de un catálogo en línea. De forma alternativa, los clientes pueden solicitar productos de una catálogo de pedidos por correo mediante una llamada por teléfono a un representante de ventas, que indica los detalles del pedido a través de una aplicación basada en Microsoft Windows. Una vez finalizado un pedido, los detalles de la tarjeta de crédito del cliente se autorizan mediante un servicio de tarjetas de crédito externo y la entrega se organiza a través de un servicio de correo externo.

La solución propuesta para este escenario es un diseño basado en componentes compuesto por una serie de componentes, tal y como se muestra en la figura 1.4.

imagen

Figura 1.4. La aplicación comercial es un conjunto de componentes y servicios relacionados

En la figura 1.4 se muestra la aplicación comercial compuesta por varios componentes de software, que se agrupan en niveles lógicos según el tipo de funcionalidad que proporcionan. Observe que desde el punto de vista de la aplicación comercial, los servicios de autorización de tarjetas de crédito y de correo se pueden considerar componentes externos. Sin embargo, internamente los servicios se implementan más como las aplicaciones normales y contienen los mismos tipos de componentes (aunque los servicios de este escenario no contienen un nivel de presentación, sino que publican su funcionalidad a través de una interfaz de servicios mediante programación).

Escenario de ejemplo

Este capítulo ha ofrecido una presentación de las soluciones basadas en servicios y ha explicado cómo un servicio, al igual que cualquier otra aplicación, está formado por varios componentes de software que se pueden agrupar en niveles lógicos. Los componentes que forman una aplicación o servicio se pueden describir en términos genéricos. El conocimiento de los distintos tipos de componentes que se utilizan con frecuencia en aplicaciones distribuidas le ayudará a diseñar mejores soluciones.

El Capítulo 2, "Diseño de los componentes de una aplicación o servicio", describe los tipos de componentes comunes y ofrece recomendaciones sobre la mejor forma de diseñarlos.

Comentarios y soporte

Si desea formular alguna pregunta, 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: