Arquitectura Aplicaciones

Arquitectura de aplicaciones .
NET: Diseño de
aplicaciones y servicios
Patterns & Practices

Microsoft Corporation
Diciembre de 2002
Arquitectura de aplicaciones .NET: Diseño de
Tabla de Contenido
Guía Básica ............................................ vii

Contenido del capítulo ix
Profesionales a los que se destina la guía ix
Contenido de la guía x
Información básica xi
Colaboradores xi
Comentarios y soporte xii
Capítulo1: Introducción .............................................. 1
Contenido del capítulo 3
Objetivos del diseño de aplicaciones distribuidas 4
Servicios e integración de servicios 4
Componentes y niveles en aplicaciones y servicios 7
Escenario de ejemplo 9
Capítulo 2: Diseño de los componentes de una aplicación o
servicios ............................................ 11
Tipos de componentes 11
Recomendaciones generales relativas al diseño de aplicaciones y
servicios 14
Diseño de capas de presentación 15
Diseño de componentes de interfaz de usuario 16
Diseño de componentes de proceso de usuario 29
Diseño de capas empresariales 40
Componentes y flujos de trabajo empresariales 41
Diseño de una interfaz de servicios 51
Representación de datos y pasarlos a través de niveles 54
Recomendaciones relativas al diseño de entidades empresariales 57
Diseño de capas de datos 58
Almacenes de datos 60
Componentes lógicos de acceso a datos 60
Diseño de componentes de ayuda de acceso a datos 68
Integración con servicios 69
Capítulo 3: Directivas de seguridad, administración operativa y
comunicaciones ............................................ 73
Diseño de la directiva de seguridad 76
Principios generales sobre seguridad 76
Autenticación 77
Autorización 83
Comunicación segura 92
Administración de perfiles 95
Auditoría 95
Diseño de la directiva de administración operativa 96
Administración de excepciones 97
Supervisión 101
Configuración 103
Metadatos 105
Ubicación de servicios 108
Diseño de la directiva de comunicaciones 110
Elección del modelo de comunicación correcto 110
Sincronización 116
Recomendaciones para comunicaciones 120
Formato, esquema y protocolo de comunicaciones 121
Un vistazo al futuro 122
Capítulo 4: Implementación física y requerimientos operativos
.......................................... 123
Implementación de los componentes de la aplicación 125
Entornos físicos de implementación 125
Planeamiento de la ubicación física de los componentes de la
aplicación 130
Límites de distribución entre componentes 134
Partición de la aplicación o el servicio en ensamblados 137
Empaquetado y distribución de los componentes de la aplicación139
Patrones comunes de implementación 140
Escenarios de interfaz de usuario basados en Web 141
Escenarios de interfaz de usuario de cliente enriquecido 143
Escenarios de integración de servicios 145
Entornos de producción, prueba y ensayo 149
Requerimientos operativos 150
Escalabilidad 150
Disponibilidad 152
Capacidad de mantenimiento 153
Seguridad 154
Facilidad de uso 155
Rendimiento 155
Apéndices y Glosario .......................................... 157
Apéndice 1: Mapa de productos 159
Apéndice 2: Glosario 161
Ensamblado 161
Transacción atómica 161
Conmutatividad 162
Componente 162
Contrato 162
Conversación 162
CRUD 162
Zona desmilitarizada (DMZ) 162
Enrutamiento dinámico de datos (DDR) 162
Emisario 163
Feudo 163
Servidor de seguridad 163
Idempotencia 163
Capa 163
Transacción de ejecución larga 163
Mensaje 163
Organización 164
Directiva 164
Servicio 164
Agente de servicios 164
Interfaz de servicios 164
Con estado 164
Sin estado 164
Confirmación en dos fases 164
Flujo de trabajo 164
Zona 165
Apéndice 3: Arquitecturas por capas 165
Guía Básica
Diciembre de 2002
Guía Básica
Resumen: en esta guía se proporcionan las instrucciones a nivel de diseño para la arquitectura y el
diseño de aplicaciones y servicios de .NET Framework, basados en Windows 2000 y en la versión 1.0
de .NET Framework. Se analizará la partición de la funcionalidad de las aplicaciones en componentes, se
describirán sus principales características de diseño, se explicará cómo se aplica la seguridad,
administración y comunicación a cada capa; asimismo, se proporciona información sobre el modo de
implementación de los componentes. Durante la localización de este artículo, la versión en español de
BizTalk 2002 no estaba disponible, por este motivo aparecen varias capturas de pantalla y opciones de
software en inglés. En estos casos, se ha agregado la opción de software en español entre paréntesis.
Contenido del capítulo
Profesionales a los que se destina la guía
Contenido de la guía
Información básica
Colaboradores
Comentarios y compatibilidad
Profesionales a los que se destina la guía
La guía está dirigida a arquitectos y responsables de desarrollo, o bien, para quien necesite:
• Determinar cómo se divide una aplicación en distintos componentes.
• Seleccionar las tecnologías que se utilizarán en una línea transaccional de servicio o aplicación
empresarial.
• Diseñar las directivas de administración y seguridad que se deben aplicar.
• Decidir el modo de implementación de la aplicación.
Esta guía se aplica a las aplicaciones transaccionales u OTLP que se ajusten a un diseño en capas y se
puedan distribuir en diversos niveles físicos con las siguientes tecnologías: ASP.NET, Servicios Web,
Enterprise Services (COM+), Remoting, ADO.NET y SQL Server. Algunos de los principios de diseño
incluidos en esta guía pueden ser útiles en escenarios similares.
El diseño de aplicaciones distribuidas no es una tarea sencilla. Es necesario tomar un gran número de
decisiones a nivel de arquitectura, diseño e implementación. Estas decisiones tendrán un impacto en las
"capacidades" de la aplicación (seguridad, escalabilidad, disponibilidad y mantenimiento, entre otras), así
como en la arquitectura, el diseño y la implementación de la infraestructura de destino. La guía le ayudará
a comprender las distintas opciones que se presentan a la hora de diseñar las capas de una aplicación
distribuida; estas opciones se presentan como un conjunto de capas de componentes que se podrán
utilizar para modelar la aplicación. En la figura 1 se muestran las capas de los componentes lógicos que
este documento utiliza para estructurar sus instrucciones. En el capítulo 2 se describe la mayor parte de
estas capas.
Arquitectura de aplicaciones .NET: Diseño de aplicaciones y servicios ix

Guía Básica
Figura 1.0. Capas de componentes de servicios y aplicaciones distribuidas creadas con .NET
Contenido de la guía
Capítulo 1: Introducción
Este capítulo describe el objetivo principal del diseño de aplicaciones distribuidas. Asimismo, se explica la
relación de los servicios y la integración de éstos con el desarrollo tradicional de aplicaciones, mostrando
un escenario comercial sencillo utilizado como tema para mostrar ejemplos en la guía.
Capítulo 2: Diseño de los componentes de una aplicación o servicio
En este capítulo se analizan todos los aspectos de una aplicación distribuida, comenzando por la interfaz
de usuario. También se identifican los distintos tipos de componentes o capas que se suelen utilizar en
aplicaciones eficaces. Se describen las principales decisiones que se deben tomar en relación con la
tecnología y el diseño, así como los principios básicos para el diseño de estos componentes.
Capítulo 3: Directivas de seguridad, administración operativa y comunicaciones
En este capítulo se analizan los diferentes aspectos, tales como la autorización y administración de
excepciones, que afectan al diseño de las capas de la aplicación, así como el modo en que las decisiones
de diseño se pueden aplicar a la misma. Asimismo, se describe la selección de los mecanismos de
comunicación.
x Arquitectura de aplicaciones .NET: Diseño de aplicaciones y servicios

Guía Básica
Capítulo 4: Implementación física y requisitos operativos
Este capítulo explica el modo de implementación de las capas de componentes lógicos en una
infraestructura compuesta por diversos niveles físicos. Se muestran patrones comunes de implementación
eficaces que se presentan cuando se combinan las capas de componentes lógicos, los niveles físicos y los
requisitos operativos.
Capítulo 5: Apéndices
Los apéndices incluyen un glosario, un mapa de productos y tecnologías de Microsoft que permiten
implementar o mejorar las capas de componentes de la aplicación, descritas en el capítulo 2, así como una
lista de nombres y patrones relacionados que la industria aplica a estas capas.
Información básica
Para sacar el máximo partido de la guía, debe tener experiencia en el uso de tecnologías y técnicas de
desarrollo .NET. Debe estar familiarizado con los temas generales de la arquitectura de aplicaciones
distribuidas y, si ya ha implementado soluciones de aplicaciones Web de .NET, debe conocer la propia
arquitectura de la aplicación y el patrón de implementación.
Colaboradores
Arquitecto de la solución y Administrador de programas: Edward A. Jezierski
Nuestro agradecimiento a los siguientes colaboradores, patrocinadores y revisores:
Keith Short, Mike Pizzo, Johannes Klein, Rodney Limprecht, Chris Anderson, Anders Hejlsberg, David
Treadwell, Jonathan Hawkins, Erik Olson, Brad Rhodes, Rob Howard, Ron Jacobs, John Shewchuck, Luca
Bolognese, David Schleifer, Riyaz Pishori, Pablo Castro, Brian Pepin, Mark Boulter, Shawn Burke, Michael
Platt, Maarten Mullender, Mike Burner, Dino Chiesa, John Montgomery, Richard Burte, Steve Kirk, Richard
Irving, Srinath Vasireddy, Steve Newbury, Sharon Bjeltich, Tom Devey, Kurt Schenk, Bryan Lamos, Paddy
Srinivasan, Yves Dolce, Rob Macdonald, Mark Phillips, Blair Shaw, Jeremy Rule, Paul Gomes, Dale Michalk,
Martin Petersen-Frey, Angela Crocker, Kenny Jones, Ilia Fortunov, Shantanu Sarkar, Rossen Blagoev, the
Think Tank, Bijan Javidi, Bob Jarvis, Aaron Margosis, Maurice Magnier, Doug Orange, Eugenio Pace, Carlos
Billy Reynoso, Anthony Menio, Karl Schulmeisters, Ingo Ramner, Bernard Chen (Sapient), Dimitris
Georgakopoulos (Sapient), Michael Monteiro (Sapient), Roger Sessions (ObjectWatch), Andrew Roubin,
Diego Gonzalez (Lagash), Adrie Geelhoed (CMG), Gerke Geurts (CMG), Sasha Siddhartha y Franco Ceruti
(VBNext).
Guías de arquitectura prescriptiva y equipo de contenido:
Redactores técnicos: Graeme Malcolm (Content Master Ltd) y Lin Joyner (Content Master Ltd).
Filiberto Selvas Patiño, Michael Kropp, Per Vonge Nielsen, Shaun Hayes, J.D. Meier, Rick Maguire, Philip
Teale, Ken Perilman, David Trowbridge, Mohammad Al-Sabt, Lars Laakes, Sharon Smith, Chris Sfanos,
Claudia Iebbiano (Wadeware) y el comité de revisión de la arquitectura de Satyam Computer Services Ltd.
Arquitectura de aplicaciones .NET: Diseño de aplicaciones y servicios xi

Guía Básica
Comentarios y soporte
Si desea formular alguna pregunta sobre la guía o realizar algún comentario o sugerencia, envíe un
mensaje de correo electrónico a devfdbck@microsoft.com.
Puede ponerse en contacto con el grupo de noticias para realizar consultas a colegas, compañeros y
profesionales de soporte de Microsoft en un foro abierto en línea. Los demás usuarios también se
beneficiarán con sus preguntas y comentarios; nuestro equipo de desarrollo supervisa el grupo de noticias
periódicamente:
Grupo de noticias: Web-Based Reader
http://msdn.microsoft.com/newsgroups/loadframes.asp?icp=msdn&slcid=us&newsgroup=microsoft.public
.dotnet.distributed_apps (en inglés)
Grupo de noticias: NNTP Reader
news://msnews.microsoft.com/microsoft.public.dotnet.distributed_apps (en inglés)
El código de ejemplo y las instrucciones se proporcionan tal cual. Aunque este material ha sido sometido a
comprobaciones y se considera un conjunto sólido de procedimientos y recomendaciones, no se ofrece
soporte como con otros productos de Microsoft.
© 2003 Microsoft Corporation. Reservados todos los derechos. Condiciones de uso.
xii Arquitectura de aplicaciones .NET: Diseño de aplicaciones y servicios

Capítulo1: Introducción
Diciembre de 2002
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.
Este capítulo incluye las siguientes secciones:
• Objetivos del diseño de aplicaciones distribuidas
• Servicios e integración de servicios
• Componentes y niveles en aplicaciones y servicios
• Escenario de ejemplo
Arquitectura de aplicaciones .NET: Diseño de aplicaciones y servicios 3

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.
4 Arquitectura de aplicaciones .NET: Diseño de aplicaciones y servicios

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.
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 sus 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.
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.
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.

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).

Capítulo 2: Diseño de los componentes de una aplicación o

servicios
Diciembre de 2002
Capítulo 2: Diseño de los componentes de una aplicación o servicios
Resumen: en este capítulo se describen los distintos tipos de componentes que se pueden encontrar en
una aplicación o servicio .NET distribuido, así como las prácticas más efectivas para su diseño.
• Tipos de componentes
• Recomendaciones generales relativas al diseño de aplicaciones y servicios
• Diseño de capas de presentación
• Diseño de capas empresariales
• Diseño de capas de datos
Tipos de componentes
El análisis de la mayoría de las soluciones empresariales basadas en modelos de componentes por capas
muestra que existen varios tipos de componentes habituales. En la figura 2.1 se muestra una ilustración
completa en la que se indican estos tipos de componentes.
Nota El término componente hace referencia a una de las partes de la solución total, como los
componentes de software compilado (por ejemplo, los ensamblados de Microsoft .NET) y otros elementos
de software, como las páginas Web y los programas de Microsoft® BizTalk® Server Orchestration.
Aunque la lista que se muestra en la figura 2.1 no es completa, representa los tipos de componentes de
software más comunes encontrados en la mayoría de las soluciones distribuidas. A lo largo de este
capítulo describiremos en profundidad cada uno de estos tipos.

Figura 2.1. Tipos de componentes utilizados en el escenario comercial de ejemplo
Los tipos de componentes identificados en el escenario de diseño de ejemplo son:
1. Componentes de interfaz de usuario (IU). La mayor parte de las soluciones necesitan ofrecer al
usuario un modo de interactuar con la aplicación. En el ejemplo de aplicación comercial, un sitio Web
permite al cliente ver productos y realizar pedidos, y una aplicación basada en el entorno operativo
Microsoft Windows® permite a los representantes de ventas escribir los datos de los pedidos de los
clientes que han telefoneado a la empresa. Las interfaces de usuario se implementan utilizando
formularios de Windows Forms, páginas Microsoft ASP.NET, controles u otro tipo de tecnología que
permita procesar y dar formato a los datos de los usuarios, así como adquirir y validar los datos
entrantes procedentes de éstos.
2. Componentes de proceso de usuario. En un gran número de casos, la interacción del usuario con
el sistema se realiza de acuerdo a un proceso predecible. Por ejemplo, en la aplicación comercial,
podríamos implementar un procedimiento que permita ver los datos del producto. De este modo, el
usuario puede seleccionar una categoría de una lista de categorías de productos disponibles y, a
continuación, elegir uno de los productos de la categoría seleccionada para ver los detalles
correspondientes. Del mismo modo, cuando el usuario realiza una compra, la interacción sigue un
proceso predecible de recolección de datos por parte del usuario, por el cual éste en primer lugar
proporciona los detalles de los productos que desea adquirir, a continuación los detalles de pago y,
por último, la información para el envío. Para facilitar la sincronización y organización de las

interacciones con el usuario, resulta útil utilizar componentes de proceso de usuario individuales. De
este modo, el flujo del proceso y la lógica de administración de estado no se incluye en el código de
los elementos de la interfaz de usuario, por lo que varias interfaces podrán utilizar el mismo "motor"
de interacción básica.
3. Flujos de trabajo empresariales. Una vez que el proceso de usuario ha recopilado los datos
necesarios, éstos se pueden utilizar para realizar un proceso empresarial. Por ejemplo, tras enviar los
detalles del producto, el pago y el envío a la aplicación comercial, puede comenzar el proceso de
cobro del pago y preparación del envío. Gran parte de los procesos empresariales conllevan la
realización de varios pasos, los cuales se deben organizar y llevar a acabo en un orden determinado.
Por ejemplo, el sistema empresarial necesita calcular el valor total del pedido, validar la información
de la tarjeta de crédito, procesar el pago de la misma y preparar el envío del producto. El tiempo que
este proceso puede tardar en completarse es indeterminado, por lo que sería preciso administrar las
tareas necesarias, así como los datos requeridos para llevarlas a cabo. Los flujos de trabajo
empresariales definen y coordinan los procesos empresariales de varios pasos de ejecución larga y se
pueden implementar utilizando herramientas de administración de procesos empresariales, como
BizTalk Server Orchestration.
4. Componentes empresariales. Independientemente de si el proceso empresarial consta de un único

paso o de un flujo de trabajo organizado, la aplicación requerirá probablemente el uso de
componentes que implementen reglas empresariales y realicen tareas empresariales. Por ejemplo, en
la aplicación comercial, deberá implementar una funcionalidad que calcule el precio total del pedido y
agregue el costo adicional correspondiente por el envío del mismo. Los componentes empresariales
implementan la lógica empresarial de la aplicación.
5. Agentes de servicios. Cuando un componente empresarial requiere el uso de la funcionalidad

proporcionada por un servicio externo, tal vez sea necesario hacer uso de código para administrar la
semántica de la comunicación con dicho servicio. Por ejemplo, los componentes empresariales de la
aplicación comercial descrita anteriormente podría utilizar un agente de servicios para administrar la
comunicación con el servicio de autorización de tarjetas de crédito y utilizar un segundo agente de
servicios para controlar las conversaciones con el servicio de mensajería. Los agentes de servicios
permiten aislar las idiosincrasias de las llamadas a varios servicios desde la aplicación y pueden
proporcionar servicios adicionales, como la asignación básica del formato de los datos que expone el
servicio al formato que requiere la aplicación.
6. Interfaces de servicios. Para exponer lógica empresarial como un servicio, es necesario crear
interfaces de servicios que admitan los contratos de comunicación (comunicación basada en mensajes,
formatos, protocolos, seguridad y excepciones, entre otros) que requieren los clientes. Por ejemplo,
el servicio de autorización de tarjetas de crédito debe exponer una interfaz de servicios que describa
la funcionalidad que ofrece el servicio, así como la semántica de comunicación requerida para llamar
al mismo. Las interfaces de servicios también se denominan fachadas empresariales.
7. Componentes lógicos de acceso a datos. La mayoría de las aplicaciones y servicios necesitan

obtener acceso a un almacén de datos en un momento determinado del proceso empresarial. Por
ejemplo, la aplicación empresarial necesita recuperar los datos de los productos de una base de datos
para mostrar al usuario los detalles de los mismos, así como insertar dicha información en la base de

datos cuando un usuario realiza un pedido. Por tanto, es razonable abstraer la lógica necesaria para
obtener acceso a los datos en un capa independiente de componentes lógicos de acceso a datos, ya
que de este modo se centraliza la funcionalidad de acceso a datos y se facilita la configuración y el
mantenimiento de la misma.
8. Componentes de entidad empresarial. La mayoría de la aplicaciones requieren el paso de datos

entre distintos componentes. Por ejemplo, en la aplicación comercial es necesario pasar una lista de
productos de los componentes lógicos de acceso a datos a los componentes de la interfaz de usuario
para que éste pueda visualizar dicha lista. Los datos se utilizan para representar entidades
empresariales del mundo real, como productos o pedidos. Las entidades empresariales que se utilizan
de forma interna en la aplicación suelen ser estructuras de datos, como conjuntos de datos,
DataReader o secuencias de lenguaje de marcado extensible (XML), aunque también se pueden
implementar utilizando clases orientadas a objetos personalizadas que representan entidades del
mundo real necesarias para la aplicación, como productos o pedidos.
9. Componentes de seguridad, administración operativa y comunicación. La aplicación

probablemente utilice también componentes para realizar la administración de excepciones, autorizar
a los usuarios a que realicen tareas determinadas y comunicarse con otros servicios y aplicaciones.
Estos componentes se describen en detalle en el capítulo 3: "Directivas de seguridad, administración
operativa y comunicaciones".
Recomendaciones generales relativas al diseño de aplicaciones y servicios
Tenga en cuenta las siguientes recomendaciones al diseñar una aplicación o servicio:
• Identifique los distintos tipos de componentes que necesitará utilizar en la aplicación. Ciertas
aplicaciones no requieren el uso de determinados componentes. Por ejemplo, puede que las
aplicaciones de menor tamaño que no necesitan integrarse con otros servicios no requieran flujos de
trabajo empresariales ni agentes de servicios. Así mismo, puede que las aplicaciones que sólo
disponen de una interfaz de usuario y un número pequeño de elementos no requieran componentes
de proceso de usuario.
• Intente que el diseño de todos los componentes pertenecientes a un mismo tipo sea coherente. Utilice
un único modelo de diseño o un volumen bajo de modelos. Esto facilita la conservación de la
previsibilidad y el mantenimiento del diseño y la implementación por parte de todos los equipos. En
determinados casos, puede resultar difícil mantener un diseño lógico debido a entornos técnicos (por
ejemplo, si desarrolla interfaces de usuario basadas tanto en ASP.NET como en Windows). No
obstante, debe esforzarse al máximo en mantener la coherencia dentro de cada entorno. En
ocasiones, puede utilizar una clase base para todos los componentes que sigan un patrón similar,
como los componentes lógicos de acceso a datos.
• Analice el modo en que los componentes se comunican entre sí antes de elegir los límites físicos de
distribución. Mantenga un nivel bajo de agrupación y un alto grado de cohesión. Para ello, elija
interfaces de carácter general, en lugar de tipo "chatty", para las comunicaciones remotas.

• Mantenga la coherencia en la aplicación o el servicio en cuanto al formato utilizado para el

intercambio de datos. Si a pesar de todo debe utilizar varios formatos de representación de datos,
utilice el menor número que pueda. Por ejemplo, puede devolver datos en un elemento DataReader
de los componentes lógicos de acceso a datos para llevar a cabo el procesamiento rápido de los datos
en Microsoft ASP.NET, pero hacer uso de conjuntos de datos para el consumo en los procesos
empresariales. No obstante, tenga en cuenta que utilizar cadenas XML, conjuntos de datos, objetos
serializados, elementos DataReader y otro tipo de formatos en la misma aplicación dificultará el
desarrollo, la extensibilidad y el mantenimiento de la misma.
• Abstraiga el código que aplica las políticas (como la de seguridad, administración operativa y
restricciones de comunicación) de la lógica empresarial de la aplicación. Intente basarse en atributos,
interfaces de programación de aplicaciones (API) de plataforma o componentes de utilidades que
proporcionen acceso de una "única línea de código" a la funcionalidad relacionada con las políticas,
como la publicación de excepciones y la autorización de usuarios, entre otras.
• Determine en la fase inicial del proceso el tipo de capas que desea aplicar. En un sistema de capas
estricto, los componentes de la capa A no pueden llamar a los componentes de la capa C; siempre
llaman a los componentes de la capa B. Sin embargo, en un sistema de capas con un nivel más alto
de flexibilidad, los componentes de una capa pueden llamar a los componentes de otras capas que no
se encuentran inmediatamente por debajo de ella. En cualquier caso, intente evitar las llamadas y
dependencias ascendentes, en las que la capa C invoca a la capa B. Implemente un sistema de capas
flexible para evitar los efectos cascada que tienen lugar cuando una capa de los niveles inferiores
cambia, o para evitar tener componentes que sólo realizan llamadas hacia adelante a capas inferiores.
Diseño de capas de presentación
La capa de presentación contiene los componentes necesarios para habilitar la interacción del usuario con
la aplicación. Las capas de presentación más simples contienen componentes de interfaz, como
formularios de Windows Forms o formularios Web de ASP.NET. Las interacciones más complejas conllevan
el diseño de componentes de proceso de usuario que permiten organizar los elementos de la interfaz y
controlar la interacción con el usuario. Los componentes de proceso de usuario resultan especialmente
útiles cuando la interacción del usuario sigue una serie de pasos predecibles, como al utilizar un asistente
para realizar una tarea determinada. En la figura 2.2 se muestran los tipos de componentes presentes en
la capa de presentación.

Figura 2.2. Capa de presentación
En el caso de la aplicación comercial, son necesarias dos interfaces de usuario: una para el sitio Web de
comercio electrónico que utiliza el cliente y otra para las aplicaciones basadas en formularios de Windows
Forms utilizados por los representantes de ventas. Ambos tipos de usuario realizan tareas similares a
través de estas interfaces. Por ejemplo, ambas interfaces deben permitir ver todos los productos
disponibles, agregar productos a una cesta de compra y especificar los detalles de pago como parte de un
proceso de desprotección. Este proceso se puede realizar a parte en un componente de proceso de usuario
independiente para facilitar el mantenimiento de la aplicación.
Diseño de componentes de interfaz de usuario
La implementación de interfaces de usuario se puede llevar a cabo de varias formas. Por ejemplo, la
aplicación comercial requiere una interfaz basada en el Web y otra basada en Windows. Otros tipos de
interfaces de usuario incluyen procesamiento de voz, programas basados en documentos y aplicaciones de
cliente móviles, entre otros. Los componentes de la interfaz de usuario administran la interacción con el
usuario. Muestran los datos al usuario, obtienen los datos del mismo e interpretan los eventos generados
por el usuario para actuar en los datos empresariales, cambiar el estado de la interfaz o facilitar la tarea al
usuario.
Las interfaces de usuario constan normalmente de una página o formulario con varios elementos que
permiten mostrar datos y aceptar la entrada del usuario. Por ejemplo, una aplicación basada en Windows

puede contener un control DataGrid que muestre una lista de categorías de productos y un control de
botón de comando que indica que el usuario desea ver los productos de la categoría seleccionada. Cuando
un usuario interactúa con un elemento de la interfaz, se genera un evento que llama al código de una
función de control. Ésta, a su vez, llama a componentes empresariales, componentes lógicos de acceso a
datos o componentes de proceso de usuario para implementar la acción deseada y recuperar los datos que
se han de mostrar. A continuación, la función de control actualiza los elementos de la interfaz. En la figura
2.3 se muestra el diseño de una interfaz de usuario.
Figura 2.3. Diseño de interfaz de usuario
Funcionalidad de los componentes de interfaz de usuario
Los componentes de la interfaz de usuario deben mostrar datos al usuario, obtener y validar los datos
procedentes del mismo e interpretar las acciones de éste que indican que desea realizar una operación
con los datos. Asimismo, la interfaz debe filtrar las acciones disponibles con el fin de permitir al usuario
realizar sólo aquellas operaciones que le sean necesarias en un momento determinado.
Los componentes de interfaz de usuario:
• No inicializan, participan ni votan en transacciones.
• Presentan una referencia al componente de proceso de usuario actual si necesitan mostrar sus datos
o actuar en su estado.
• Pueden encapsular tanto la funcionalidad de visualización como un controlador.
Al aceptar la entrada del usuario, los componentes de la interfaz:
• Adquieren los datos del usuario y atienden su entrada utilizando guías visuales (como informaciones
sobre herramientas) y sistemas de validación, así como los controles necesarios para realizar la tarea
en cuestión.
• Capturan los eventos del usuario y llaman a las funciones de control para indicar a los elementos de
la interfaz de usuario que cambien el modo de visualización de los datos, bien inicializando una acción
en el proceso de usuario actual, o bien, modificando los datos del mismo.
• Restringen los tipos de entrada del usuario. Por ejemplo, un campo Quantity puede limitar las
entradas del usuario a valores numéricos.
• Realizan la validación de entrada de datos, por ejemplo, restringiendo el intervalo de valores que se
pueden escribir en un campo determinado, o garantizando que se escriben los datos obligatorios.

• Llevan a cabo la asignación y transformación simple de la información proporcionada por los controles
del usuario en los valores necesarios para que los componentes subyacentes realicen su trabajo (por
ejemplo, un componente de interfaz de usuario puede mostrar el nombre de un producto pero pasar
el Id. del mismo a los componentes subyacentes).
• Interpretar las acciones del usuario (como las operaciones de arrastrar y colocar o los clics de
botones) y llamar a una función de control.
• Pueden utilizar un componente de utilidad para el almacenamiento de datos en caché. En ASP.NET,

puede especificar el almacenamiento en caché de la salida de un componente determinado de la
interfaz de usuario para evitar el continuo procesamiento del mismo. Si la aplicación contiene
elementos visuales que representan datos de referencia que no cambian con frecuencia y no se
utilizan en contextos transaccionales, y un gran número de usuarios comparte dichos elementos, se
recomienda que los almacene en caché. Se aconseja almacenar en caché aquellos elementos visuales
compartidos por un gran número de usuarios, que representan datos de referencia que no cambian
con frecuencia y no se utilizan en contextos transaccionales.
• Pueden utilizar un componente de utilidad para realizar la paginación. Es frecuente, especialmente en

las aplicaciones Web, mostrar largas listas de datos como conjuntos paginados. Asimismo, se suele
disponer de un componente de ayuda para realizar el seguimiento de la página actual en la que se
encuentra el usuario y, por tanto, invocar a las funciones de consulta paginada de los componentes
lógicos de acceso a datos con los valores adecuados relativos al tamaño de página y página actual. La
paginación se puede realizar sin la interacción del componente de proceso de usuario.
Al procesar datos, los componentes de interfaz de usuario:
• Adquieren y procesan los datos de los componentes empresariales o de los componentes lógicos de
acceso a datos de la aplicación.
• Realizan el formato de valores (como el formato adecuado de las fechas).
• Realizan las tareas de localización de los datos procesados (por ejemplo, utilizando cadenas de
recursos para mostrar los encabezados de las columnas de una cuadrícula en el idioma
correspondiente a la configuración regional del usuario).
• Normalmente, procesan los datos de una entidad empresarial. Estas entidades se suelen obtener del
componente de proceso de usuario, aunque también se pueden obtener de los componentes de datos.
Los componentes de IU pueden procesar datos a través del enlace a datos de su visualización con los
atributos y colecciones adecuados de los componentes de la entidad, sí ésta se encuentra disponible.
Si se encuentra administrando los datos de una entidad como conjuntos de datos, esta tarea resulta
bastante sencilla. Si ha implementado objetos de entidad personalizados, tal vez sea preciso
implementar código adicional para facilitar el enlace a datos.
• Proporcionan la información de estado al usuario, por ejemplo, indicando cuando una aplicación se
encuentra en modo "desconectado" o "conectado".

• Pueden personalizar el aspecto de la aplicación en función de las preferencias del usuario o el tipo de
dispositivo de cliente utilizado.
• Pueden utilizar un componente de utilidad para proporcionar funcionalidad de deshacer. Un gran

número de aplicaciones deben permitir al usuario deshacer determinadas operaciones. Esto se realiza
normalmente manteniendo una pila de datos de longitud fija de tipo "valor antiguo, valor nuevo" para
elementos específicos de datos o entidades completas. Cuando una operación conlleva un proceso
empresarial, se recomienda que no exponga la compensación como una función de deshacer simple,
sino como una operación explícita.
• Pueden utilizar un componente de utilidad para proporcionar funcionalidad de portapapeles. En gran

parte de las aplicaciones basadas en Windows, resulta útil proporcionar capacidades de portapapeles
no sólo para valores escalares; por ejemplo, tal vez desee permitir a los usuarios que copien y
peguen un objeto completo de cliente. Esta funcionalidad se implementa normalmente colocando
cadenas XML en el Portapapeles de Windows, o bien, disponiendo de un objeto global que mantiene
los datos en memoria si el portapapeles es específico de la aplicación.
Interfaces de usuario del Escritorio de Windows
Las interfaces de usuario de Windows se utilizan cuando es necesario proporcionar capacidades de

desconexión o fuera de línea, o interacción enriquecida de usuario, o incluso integración con las interfaces
de usuario de otras aplicaciones. Las interfaces de usuario de Windows pueden beneficiarse de una amplia
gama de opciones de administración y persistencia de estado y pueden hacer uso de la potencia de
procesamiento local. Existen tres familias principales de interfaces de usuario independientes: aplicaciones
basadas en Windows "completas", aplicaciones basadas en Windows que incluyen contenido HTML
incrustado y complementos de aplicación que se utilizan en la interfaz de usuario de las aplicaciones host:
• Interfaces de usuario completas de PC de escritorio o Tablet PC incorporadas en Windows

Forms
La creación de una aplicación basada en Windows conlleva la inclusión en dicha aplicación de

formularios de Windows Forms y controles a través de los cuales la aplicación ofrezca toda o la mayor
parte de la funcionalidad de procesamiento de datos. Esto le proporciona un alto nivel de control
sobre la interfaz de usuario y el control total sobre la apariencia y el funcionamiento de la aplicación.
No obstante, este hecho le ata a una plataforma de cliente y hace necesario implementar la aplicación
a los usuarios (incluso si la implementación de la aplicación se realiza a través de la descarga de la
misma desde una conexión HTTP).
• HTML incrustado
Puede implementar la interfaz de usuario completa utilizando Windows Forms, o bien, en las
aplicaciones basadas en Windows, puede utilizar HTML incrustado adicional. El contenido HTML
incrustado aporta un mayor nivel de flexibilidad en tiempo de ejecución (ya que dicho contenido se
puede cargar desde recursos externos o incluso, en escenarios conectados, desde una base de datos)
y permite personalizar la aplicación en función de las necesidades del usuario. Sin embargo, debe
considerar detenidamente el modo de evitar que secuencias de comandos malintencionadas penetren

en el HTML. Asimismo, será preciso hacer uso de código adicional para cargar el HTML, mostrarlo y
enlazar los eventos del control con las funciones de la aplicación.
• Complementos de aplicación
La experiencia puede sugerir que la implementación de la interfaz de usuario es más adecuada si se

realiza como un complemento de otras aplicaciones, como Microsoft Office, AutoCAD, las soluciones
de los servicios de administración de relaciones con los clientes (Customer Relationship Management,
CRM), herramientas de ingeniería, etc. En este caso, puede hacer uso de la lógica de adquisición y
visualización de datos de la aplicación host y ofrecer sólo el código necesario para recopilar los datos
y trabajar con su lógica empresarial.
La mayoría de las aplicaciones modernas admiten complementos, bien como objetos COM (Modelo de
objetos componentes) u objetos .NET compatibles con una interfaz específica, o bien, como entornos
de desarrollo incrustados (como el sistema de desarrollo Microsoft Visual Basic®, compatible con la
mayor parte de las aplicaciones basadas en Windows más utilizadas), que pueden, a su vez, invocar a
objetos personalizados. Determinados entornos incrustados (como Visual Basic) ofrecen incluso un
motor de formularios que permite agregar a la interfaz de usuario más funcionalidad que la
proporcionada por la aplicación host. Si desea obtener más información sobre el uso de Visual Basic
en aplicaciones host, consulte "Microsoft Visual Basic for Applications and Windows DNA 2000" (en
inglés) en MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/dndna/html/vba4dna.asp).
Si desea obtener más información sobre el uso de .NET desde Microsoft Office, consulte "Microsoft
Office and .NET Interoperability" (en inglés) en MSDN
(http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/dnofftalk/html/office11012001.asp).
Tenga en cuenta las siguientes recomendaciones al crear aplicaciones basadas en Windows Forms:
• Básese en el enlace a datos para mantener la sincronización de los mismos en varios formularios
abiertos de forma simultánea. De este modo, disminuirá la necesidad de escribir código complejo de
sincronización de datos.
• Intente evitar las relaciones de modificación entre formularios y básese en el componente de proceso
de usuario para abrirlos y sincronizar los datos y eventos. Sea especialmente cuidadoso en evitar este
tipo de relaciones entre los formularios secundarios y primarios. Por ejemplo, la ventana de detalles
de un producto determinado se puede volver a utilizar en otras ubicaciones de la aplicación, no sólo
en un formulario de entrada de pedido, por lo que debe evitar la implementación de funcionalidad en
el formulario de detalles del producto que enlaza directamente al formulario de entrada del pedido.
Esto aumenta el nivel de reutilización de los elementos de la interfaz de usuario.
• Implemente controladores de errores en sus formularios para evitar que el usuario vea una ventana
de excepciones .NET no descriptiva y que la aplicación dé error si las excepciones no se controlan en
ninguna otra ubicación. Todos los controladores de eventos y las funciones de control deben incluir

capturas de excepciones. Asimismo, tal vez desee crear una clase de excepción personalizada para la
interfaz de usuario que incluya metadatos para determinar si la operación errónea se puede recuperar
o cancelar.
• Valide la entrada del usuario en la interfaz de usuario. La validación debe tener lugar en las fases de
la tarea o del proceso del usuario en las que se permiten las validaciones a un momento dado (lo que
posibilita al usuario escribir los datos necesarios, continuar con otra tarea y volver a la tarea actual).
En determinados casos, se recomienda habilitar o deshabilitar de forma proactiva los controles y guiar
de modo visual al usuario en caso de que se escriban datos no válidos. La validación de la entrada del
usuario en la interfaz evita recorridos de ida y vuelta innecesarios a los componentes del lado del
servidor al escribir datos no válidos.
• Si crea controles de usuario personalizados, exponga sólo las propiedades y los métodos públicos que
realmente necesita con el fin de facilitar el mantenimiento de los componentes.
• Implemente las funciones de control como funciones independientes en los formularios de Windows
Forms o en las clases .NET que se van a implementar con el cliente. No implemente la funcionalidad
de control directamente en los controladores de eventos de control. Si escribe la lógica de control en
controladores de eventos, reducirá la facilidad de mantenimiento de la aplicación, ya que en el futuro
tal vez sea necesario invocar a la misma función desde otros eventos.
Por ejemplo, el controlador de eventos de un botón de comando, denominado evento de clic de

addItem, debe llamar a un procedimiento más general para realizar su tarea, tal y como se muestra
en el siguiente código.
private void addItem_Click(object sender, System.EventArgs e)
AddItemToBasket(selectedProduct, selectedQuantity)
public void AddItemToBasket(int ProductID, int Quantity)
// código para agregar el artículo a la cesta
Interfaces de usuario de exploración de Internet

La aplicación comercial descrita en esta guía requiere una interfaz de usuario basada en el Web que
permita a los clientes realizar pedidos a través de Internet. Las interfaces de usuario basadas en el Web
permiten el uso de interfaces de usuario basadas en estándares en un gran número de dispositivos y
plataformas. Para desarrollar interfaces de usuario basadas en el Web para aplicaciones basadas en .NET
se utiliza ASP.NET. Éste ofrece un entorno enriquecido en el que se pueden crear interfaces complejas
basadas en el Web con compatibilidad para características importantes, como por ejemplo:
• Un entorno de desarrollo coherente que también se utiliza para crear otros componentes de la
aplicación.
• Enlace a datos de interfaz de usuario.
• Interfaces de usuario basadas en componentes con controles.
• Acceso al modelo de seguridad .NET integrado.
• Almacenamiento en caché enriquecido y opciones de administración de estado.
• Disponibilidad, rendimiento y escalabilidad del procesamiento Web.
Cuando necesite implementar una aplicación para un explorador, ASP.NET ofrece la funcionalidad
necesaria para publicar una interfaz de usuario basada en páginas Web. Considere las siguientes
recomendaciones relativas al diseño de interfaces de usuario de ASP.NET:
• Implemente una página de error personalizada y un controlador de excepciones global en Global.asax.

De este modo, dispondrá de una función completa de detección de excepciones que evitará que el
usuario vea páginas no descriptivas en caso de que ocurra algún problema.
• ASP.NET presenta un marco de validación enriquecido que optimiza la tarea de garantizar que los
datos escritos por el usuario se ajusten a determinados criterios. No obstante, la validación de
clientes que se realiza en el explorador se basa en que JavaScript está habilitado en el cliente, por lo
que también debe validar los datos en las funciones de control, en caso de que un usuario disponga
de un explorador no compatible con JavaScript (o tenga JavaScript deshabilitado). Si su proceso de
usuario dispone de una función de control de validación, llámelo antes de pasar a otras páginas para
llevar a cabo la validación a un momento dado.
• Si crea controles de usuario Web, exponga sólo las propiedades y los métodos públicos que realmente
necesita. De este modo, aumentará la facilidad del mantenimiento.
• Utilice el estado de vista de ASP.NET para almacenar el estado específico de las páginas y mantener
el estado de sesión y aplicación de los datos con un alcance más amplio. Este enfoque facilita el
mantenimiento y aumenta el nivel de escalabilidad.
• Las funciones de control deben invocar a las acciones del componente de proceso de usuario para
guiar al usuario a través de la tarea actual, en lugar de redireccionarlo a la página directamente. El
componente del proceso de usuario puede llamar a la función Redirect para que el servidor muestre
una página diferente. Para ello, debe hacer referencia al espacio de nombres System.Web desde los
componentes de proceso de usuario. (Tenga en cuenta que, por tanto, el componente de proceso de

usuario no se podrá volver a utilizar en aplicaciones basadas en el Web, por lo que resulta adecuado
implementar llamadas de redirección en una clase diferente).
• Implemente las funciones de control como funciones independientes en las páginas ASP.NET o en las
clases .NET que se distribuirán con las páginas Web. Si escribe la lógica empresarial en los
controladores de eventos proporcionados por ASP.NET, reducirá la facilidad de mantenimiento del
sitio, ya que tal vez sea necesario en el futuro invocar a la misma función desde otros eventos. Para
ello, se requiere una mayor capacidad por parte de los desarrolladores que escriben código exclusivo
de IU.
Suponga, por ejemplo, que el sitio Web comercial contiene una página en la que se puede hacer clic
en un botón de comando para agregar un producto a la cesta de compra del usuario. El marcado
ASP.NET del control podría tener el aspecto de la siguiente línea de código.
<asp:Button id="addItem" OnClick="addItem_Click"/>
Como puede observar en el código, la función addItem_Click controla el evento OnClick del botón. No
obstante, el controlador de eventos no debe contener el código que realiza la acción requerida (en
este caso, agregar un elemento de la cesta), sino que debe llamar a otra función general, como se
muestra en el siguiente fragmento de código.
private void addItem_Click(object sender, System.EventArgs e)
AddItemToBasket(selectedProduct, selectedQuantity)
public void AddItemToBasket(int ProductID, int Quantity)
// código para agregar el artículo a la cesta
Esta capa de abstracción adicional garantiza que otros elementos de la interfaz de usuario puedan
utilizar el código requerido para realizar las tareas de control.

Si desea obtener información general sobre ASP.NET, consulte la sección de ASP.NET (en inglés) de MSDN
(http://msdn.microsoft.com/library/default.asp?url=/nhp/default.asp?contentid=28000440) y el sitio
oficial de ASP.NET (en inglés) (http://asp.net).
En un gran número de aplicaciones, resulta importante proporcionar un marco extensible en el que se

muestren varios paneles con diferentes objetivos. En las aplicaciones basadas en el Web, también es
preciso proporcionar una página principal o interfaz de usuario raíz en la que se muestren las tareas y la
información relevante al usuario en función del contexto y dispositivo utilizado. Microsoft proporciona los
siguientes recursos para facilitar la implementación de portales basados en el Web:
• Microsoft Content Management Server (en inglés)

(http://msdn.microsoft.com/library/default.asp?url=/nhp/Default.asp?contentid=28001368)
• Microsoft SharePoint Portal™ Server 2001 (en inglés)

us/spssdk/html/_welcome_to_tahoe.asp)
• IBuySpy Portal (en inglés)
(http://msdn.microsoft.com/library/en-us/dnbda/html/bdasampibsport.asp)
Interfaces de usuario de dispositivos móviles
Los dispositivos móviles, como los PC de mano, los teléfonos WAP (protocolo de aplicaciones inalámbricas)
y los dispositivos iMode, están adquiriendo cada vez una mayor popularidad. La creación de interfaces de
usuario para un factor de forma móvil presenta sus propios retos.
En general, la interfaz de usuario de un dispositivo móvil necesita ser capaz de mostrar la información en
una pantalla de un tamaño considerablemente menor al de las aplicaciones habituales y debe ofrecer un
nivel aceptable de uso para los dispositivos de destino. Debido a que la interacción del usuario puede
resultar un tanto incómoda en un gran número de dispositivos móviles, sobre todo en el caso de los
teléfonos móviles, procure diseñar las interfaces de usuario minimizando al máximo los requisitos de
entrada de datos. Una estrategia comúnmente utilizada consiste en combinar el uso de los dispositivos
móviles con una aplicación de tamaño completo basada en el Web o en Windows, permitir a los usuarios
que registren datos previamente a través del cliente basado en el escritorio y, a continuación,
seleccionarlos utilizando el cliente móvil. Por ejemplo, una aplicación de comercio electrónico puede
permitir a los usuarios que registren los datos de sus tarjetas de crédito a través del sitio Web. De este
modo, el usuario puede seleccionar una tarjeta de crédito previamente registrada de una lista cuando
realice un pedido desde un dispositivo móvil (evitando de este modo la necesidad de escribir los detalles
completos de la tarjeta de crédito a través del teclado numérico del teléfono o el lápiz de una agenda
personal digital [PDA]).
Interfaces de usuario Web
Una amplia gama de dispositivos móviles admiten la exploración de Internet. Algunos dispositivos utilizan
microexploradores que admiten un subconjunto de HTML 3.2, otros requieren el envío de datos en

lenguaje de marcado inalámbrico (WML) y otros admiten estándares como Compact HTML (cHTML). Puede
utilizar Microsoft Mobile Internet Toolkit para crear aplicaciones Web basadas en ASP.NET que envíen el
estándar de marcado adecuado a cada cliente en función del tipo de dispositivo, tal y como se identifica en
el encabezado de la solicitud. Esto permite crear una única aplicación Web dirigida a un gran número de
clientes móviles diferentes, incluidos Pocket PC, teléfonos WAP y teléfonos iMode, entre otros.
Al igual que con otros tipos de interfaz de usuario, debe intentar minimizar la posibilidad de que los
usuarios escriban datos no válidos en una página Web móvil. Mobile Internet Toolkit incluye controles de
validación del lado del cliente, como CompareValidator, CustomValidator, RegularExpressionValidator y
RequiredFieldValidator, que pueden utilizar varios tipos de dispositivos de cliente. Asimismo, puede utilizar
las propiedades de los campos de entrada, como los controles Textbox, para limitar el tipo de entrada
aceptada (por ejemplo, aceptando sólo entradas numéricas). No obstante, siempre debe permitir el uso de
dispositivos de cliente que puedan no ser compatibles con la validación del lado del cliente y realizar
comprobaciones adicionales una vez que los datos se han expuesto al servidor.
Si desea obtener más información sobre Mobile Internet Toolkit, consulte la página de Microsoft Mobile
Internet Toolkit (en inglés) en MSDN (http://msdn.microsoft.com/vstudio/device/mitdefault.asp).
Interfaces de usuario de dispositivos inteligentes
Pocket PC es un dispositivo basado en el sistema operativo Windows CE. Ofrece una gran número de
características y permite desarrollar interfaces de usuario desconectadas y conectadas (normalmente de
forma inalámbrica). La plataforma Pocket PC incluye dispositivos PDA de mano y teléfonos inteligentes,
que combinan las características de los PDA y los teléfonos convencionales.
Microsoft ofrece .NET Compact Framework para Pocket PC y otras plataformas Windows CE. Compact
Framework contiene un subconjunto de .NET Framework completo y permite el desarrollo de aplicaciones
completas basadas en .NET para dispositivos móviles. Los desarrolladores pueden utilizar Smart Device
Extensions para Visual Studio .NET con el fin de crear aplicaciones dirigidas a .NET Compact Framework.
Al igual que las interfaces de usuario tradicionales basadas en Windows, en el dispositivo móvil se debe
proporcionar control de excepciones para informar al usuario en caso de que se produzca una operación
errónea, y permitir a éste que pueda volver a intentar o cancelar la acción según sea necesario.
Smart Device Extensions for Microsoft Visual Studio® .NET no ofrece controles de validación de entrada,
por lo que debe implementar su propia lógica de validación del lado del cliente para garantizar que todas
las entradas de datos son válidas.
Si desea obtener más recursos para el desarrollo de la plataforma Pocket PC y .NET Compact Framework,
consulte la página de Smart Device Extensions (en inglés) en MSDN
(http://msdn.microsoft.com/vstudio/device/smartdev.asp).
Otro factor de forma móvil para clientes enriquecidos cuyo uso puede considerar es Tablet PC. Se trata de
un tipo de dispositivo portátil basado en Windows XP que admite la interacción del usuario a través de una
metáfora de "bolígrafo y tinta" en la que el usuario "dibuja" y "escribe" en la pantalla. Debido a que Tablet
PC se basa en Windows XP, se puede hacer uso completo de .NET Framework. También hay disponible

una API adicional para el control de las interacciones de "bolígrafo y tinta". Si desea obtener más
información sobre el diseño de aplicaciones para Tablet PC, consulte las recomendaciones de diseño de
Pocket PC (en inglés) en MSDN (http://msdn.microsoft.com/library/en-
us/tpcsdk10/html/whitepapers/designguide/tbconuxdgformfactorpenandink.asp).
Interfaces de usuario basadas en documentos
En lugar de crear una aplicación de escritorio personalizada basada en Windows para facilitar la
interacción del usuario, tiene más sentido en determinadas circunstancias permitir a los usuarios que
interactúen con el sistema a través de los documentos creados en herramientas de productividad comunes,
como Microsoft Word o Microsoft Excel. Los documentos son una metáfora común para el trabajo con
datos. En determinadas aplicaciones, se puede beneficiar del hecho de que los usuarios escriban o vean
datos en forma de documento en las herramientas que utilizan normalmente. Considere las siguientes
soluciones basadas en documentos:
• Informe de datos. La aplicación (basada en Windows o en el Web) puede ofrecer al usuario una
característica que le permita ver los datos de un documento del tipo adecuado; por ejemplo,
mostrando los datos de facturación como un documento de Word o una lista de precios como una
hoja de cálculos de Excel.
• Recopilación de datos. Puede permitir a los representantes de ventas que escriban la información
de venta para clientes telefónicos en hojas de cálculo de Excel para crear un documento de pedidos y,
a continuación, enviar el documento a su proceso empresarial.
Existen dos formas habituales de integrar un servicio de documentos en las aplicaciones, cada una de ellas
dividida en dos escenarios comunes: la recopilación de datos del usuario y el informe de los datos al
mismo.
Uso de documentos externos
Puede trabajar con documentos "externos", tratándolos como una entidad. En este tipo de escenarios, el
código funciona en un documento ajeno a la aplicación. Este enfoque presenta la ventaja de que el archivo
del documento se puede conservar tras una sesión específica. Este modelo resulta útil cuando se dispone
de zonas de "forma libre" en el documento que la aplicación no requiera pero que tal vez necesita
conservar. Por ejemplo, puede utilizar este modelo para permitir a los usuarios que escriban información
en un documento en un dispositivo móvil y se beneficien de las capacidades de ActiveSync de Pocket PC
para sincronizar los datos entre el documento de dicho dispositivo móvil y un documento mantenido en el
servidor. En este modelo de diseño, la interfaz de usuario realizará las siguientes funciones:
• Recopilación de datos. Un usuario determinado puede escribir información en un documento,

inicialmente un documento en blanco, o más frecuentemente, una plantilla predefinida que presenta
campos específicos.
El usuario envía a continuación el documento a una aplicación basada en Windows, o la carga en una
aplicación basada en el Web. La aplicación busca los datos y campos del documento a través del
modelo de objetos del mismo y realiza posteriormente las acciones necesarias.

Llegados a este punto, puede decidir conservar el documento tras el procesamiento o deshacerse de
él. Normalmente, los documentos se conservan para mantener un historial de seguimiento, o para
almacenar los datos adicionales que el usuario ha escrito en las zonas de forma libre.
• Informe de datos. En este caso, una interfaz de usuario basada en Windows o en el Web proporciona
una forma de generar un documento en el que se muestran datos determinados, como una factura de
venta. Normalmente, el código de informe toma datos del proceso de usuario saliente, proceso
empresarial y/o componentes lógicos de acceso a datos. Asimismo, el código llama a macros de la
aplicación del documento para insertar los datos y darles formato, o guarda un documento con el
formato adecuado y lo devuelve al usuario. Puede devolver el documento guardándolo en disco y
proporcionando un vínculo al mismo (necesitaría almacenar el documento en un almacén central en
baterías de servidores Web con equilibrio de carga), o bien, incluyéndolo como parte de la respuesta.
Al devolver documentos en aplicaciones basadas en el Web, es necesario decidir si mostrar el

documento en un explorador para que lo vea el usuario o presentar a éste una opción para guardar el
documento en disco. Esto se suele controlar definiendo el tipo MIME adecuado en la respuesta de una
página ASP.NET. En los entornos Web, debe seguir cuidadosamente las siguientes convenciones de
nombres de archivo para evitar que varios usuarios sobrescriban sus archivos correspondientes.
Uso de documentos internos
Si desea proporcionar una experiencia de usuario integrada dentro del documento, puede incrustar la
lógica de la aplicación en el propio documento. En este modelo de diseño, la interfaz de usuario realizará
las siguientes funciones:
• Recopilación de datos. Los usuarios pueden escribir datos en documentos con formularios
predefinidos y, a continuación, se pueden invocar macros específicas en la plantilla para recopilar los
datos adecuados e invocar a sus componentes empresariales o de proceso de usuario. Este enfoque
proporciona una experiencia de usuario más integrada, ya que el usuario sólo necesita hacer clic en
un botón personalizado u opción de menú en la aplicación host para realizar el trabajo, en lugar de
tener que enviar el documento completo.
• Informe de datos. Puede implementar entradas de menú y botones personalizados en los documentos
para recopilar datos determinados del servidor y posteriormente mostrarlos. También puede utilizar
tarjetas inteligentes para proporcionar funcionalidad de integración en línea enriquecida para todas
las herramientas de productividad de Microsoft Office. Por ejemplo, puede proporcionar una etiqueta
inteligente que permita a los usuarios visualizar la información completa de contacto de cliente de la
base de datos de CRM cuando un representante de ventas escriba el nombre del cliente en el
documento.
Independientemente de si trabaja con un documento externo o interno, debe proporcionar una lógica de
validación para garantizar que todas las entradas de usuario son válidas. Esto lo puede conseguir, en
parte, limitando los tipos de datos de campos, pero en la mayoría de los casos necesitará implementar
funcionalidad personalizada para comprobar la entrada del usuario y mostrar mensajes de error si se
detectan datos no válidos. Los documentos basados en Microsoft Office pueden incluir macros
personalizadas para ofrecer esta funcionalidad.

Si desea obtener más información sobre el modo de integrar una IU basada exclusivamente en Office en
sus procesos empresariales, consulte "Microsoft Office XP Resource Kit for BizTalk Server Version 2.0" (en
inglés) (http://msdn.microsoft.com/downloads/default.asp?url=/downloads/sample.asp?url=/msdn-
files/027/001/743/msdncompositedoc.xml).
Si desea obtener más información sobre el uso de Office y .NET, consulte MSDN. Los siguientes dos
artículos le ayudarán a familiarizarse con el desarrollo de aplicaciones basadas en Office y .NET:
• "Introducing .NET to Office Developers" (en inglés)

us/dnofftalk/html/office10042001.asp)
• "Microsoft Office and .NET Interoperability" (en inglés)

us/dnofftalk/html/office11012001.asp)
Puede administrar flujos de trabajo basados en documentos beneficiándose de las ventajas que aportan
los servicios que proporciona Microsoft SharePoint Portal™. Este producto puede administrar el proceso de
usuario y proporcionar metadatos enriquecidos y capacidades de búsqueda.
Acceso a componentes lógicos de acceso a datos desde la interfaz de usuario
Las interfaces de usuario de determinadas aplicaciones necesitan procesar los datos disponibles como
consultas expuestas por los componentes lógicos de acceso a datos. Independientemente de si los
componentes de la interfaz de usuario invocan directamente a los componentes lógicos de acceso a datos,
se recomienda no mezclar la lógica de acceso a datos con la lógica de procesamiento empresarial.
El acceso directo a los componentes lógicos de acceso a datos desde la interfaz de usuario parece
contradecir el concepto de disposición en capas. No obstante, resulta útil en este caso considerar a la
aplicación como un servicio homogéneo; se llama a la aplicación y ésta decide cuáles son los componentes
internos más adecuados para responder a una solicitud determinada.
Se recomienda permitir a los componentes lógicos de acceso a datos el acceso directo a los componentes
de la interfaz de usuario cuando:
• Está dispuesto a relacionar estrechamente los métodos y esquemas de acceso a datos con la
semántica de la interfaz de usuario. Esta relación requiere el mantenimiento conjunto de los cambios
de la interfaz de usuario y de los esquemas.
• La implementación física coloca juntos a los componentes lógicos de acceso a datos y a los
componentes de interfaz de usuario, lo que permite obtener datos en formatos de secuencias (como
DataReader) de los componentes lógicos de acceso a datos, que se pueden enlazar directamente a la
salida de las interfaces de usuario ASP.NET para obtener un mayor rendimiento. Si implementa la
lógica de acceso a datos y de los procesos empresariales en servidores diferentes, no podrá
beneficiarse de esta capacidad. Desde el punto de vista del funcionamiento, permitir el acceso directo
a los componentes lógicos de acceso a datos para poder hacer uso de las capacidades de transmisión

conlleva la necesidad de proporcionar acceso a la base de datos en la que se distribuyen los

componentes lógicos de acceso a datos; incluido probablemente el acceso a través de puertos de
servidores de seguridad. Si desea obtener más información, consulte el capítulo 4: "Implementación
física y requisitos operativos".
Diseño de componentes de proceso de usuario
La interacción del usuario con la aplicación puede seguir un proceso predecible. Por ejemplo, puede que la
aplicación comercial requiera que los usuarios escriban los datos de los productos, vean el precio total,
escriban los detalles de pago y, finalmente, escriban la información relativa a la dirección del pedido. Este
proceso conlleva la visualización y aceptación de la entrada de un número de elementos de interfaz de
usuario, y el estado del proceso (los productos solicitados y los detalles de las tarjetas de crédito, entre
otros) se debe mantener en la transición de un paso a otro del proceso. Para facilitar la coordinación del
proceso de usuario y controlar el mantenimiento del estado requerido al visualizar varias páginas o
formularios de la interfaz de usuario, puede crear componentes de proceso de usuario.
Nota La implementación de una interacción con el usuario a través de componentes de proceso de

usuario no es una tarea sencilla. Antes de decidirse por este método, evalúe detenidamente si la
aplicación requiere o no el nivel de organización y abstracción que proporcionan este tipo de componentes.
Los componentes de proceso de usuario se implementan normalmente como clases .NET que exponen
métodos a los cuales pueden llamar las interfaces de usuario. Cada método encapsula la lógica necesaria
para realizar una acción específica en el proceso de usuario. La interfaz de usuario crea una instancia del
componente del proceso de usuario y la utiliza para efectuar la transición a través de los pasos del
proceso. Los nombres de los formularios particulares o de las páginas ASP.NET que se deben visualizar
para cada uno de los pasos del proceso se pueden insertar en el código del componente de proceso de
usuario (enlazándolo estrechamente por tanto a implementaciones específicas de la interfaz de usuario) o
se pueden recuperar de un almacén de metadatos, como un archivo de configuración (facilitando la
reutilización del componente de proceso de usuario por parte de varias implementaciones de interfaz de
usuario). El diseño de componentes de proceso de usuario para su uso por parte de varias interfaces da
lugar a una implementación más compleja, debido al aislamiento de los problemas específicos de los
dispositivos. No obstante, puede facilitar la distribución del trabajo de desarrollo de la interfaz de usuario
entre varios equipos, cada uno de ellos utilizando el mismo componente de proceso de usuario.
Los componentes de proceso de usuario coordinan la visualización de los elementos de la interfaz. Se

abstraen de la funcionalidad de procesamiento y adquisición de datos proporcionada por los componentes
de la interfaz de usuario. Debe diseñarlos con el concepto de globalización en mente, para permitir la
implementación de la localización en la interfaz. Por ejemplo, debe esforzarse en utilizar formatos de
datos neutrales con respecto a la cultura y utilizar formatos de cadena Unicode de forma interna para
facilitar el consumo de los componentes de proceso de usuario por parte de una interfaz de usuario
localizada.
El siguiente código muestra el aspecto de un componente de proceso de usuario para un proceso de

comprobación.

public class PurchaseUserProcess
public PurchaseUserProcess()
// crear un GUID para realizar un seguimiento de esta actividad
userActivityID = System.Guid.NewGuid();
private int customerID;
private DataSet orderData;
private DataSet paymentData;
private Guid userActivityID;
public bool webUI; // indicador para señalar que el IU del cliente es

un sitio
// Web (o no)
public void ShowOrder()
if(webUI)
// Código para mostrar la página de detalles del pedido
System.Web.HttpContext.Current.Response.Redirect

("http://www.myserver.com/OrderDetails.aspx");
else // debe ser una IU de Windows
// código para mostrar la ventana de detalles del pedido.
OrderDetails = new OrderDetailsForm();
OrderDetails.Show();
public void EnterPaymentDetails()
// aquí va el código para mostrar la página o ventana de detalles

de pago
public void PlaceOrder()
// aquí va el código para hacer el pedido
ShowConfirmation();
public void ShowConfirmation()
// aquí va el código para mostrar la página o ventana de

confirmación

public void Finish()
// aquí va el código para regresar a la página o ventana principal
public void SaveToDataBase()
// aquí va el código para guardar la información de pedido y de

pago de las variables
// privadas en una base de datos
public void ResumeCheckout(System.Guid ProcessID)
// aquí va el código para volver a cargar el estado del proceso

desde la base de datos
public void Validate()
// aquí debería colocar el código para asegurarse de que las

variables de
// instancia del proceso tienen la información adecuada para el

paso actual

La separación de la funcionalidad de interacción del usuario en componentes de interfaz y proceso de

usuario conlleva las siguientes ventajas:
• El estado de la interacción de usuario de ejecución larga se mantiene más fácilmente, lo que permite
el abandono y la reanudación de la interacción, probablemente incluso utilizando una interfaz de
usuario diferente. Por ejemplo, un cliente podría agregar varios elementos a una cesta de compra
utilizando la interfaz de usuario basada en el Web y, a continuación, llamar a un representante de
ventas para completar el pedido.
• Varias interfaces de usuario pueden utilizar el mismo proceso. Por ejemplo, en la aplicación comercial,
se puede utilizar el mismo proceso de usuario para agregar un producto a una cesta de compra tanto
desde la interfaz de usuario basada en el Web como desde la aplicación basada en Windows Forms.
El uso de un enfoque sin estructura para diseñar la lógica de la interfaz de usuario puede dar lugar a
situaciones no deseadas, debido al aumento del tamaño de la aplicación o la incorporación de nuevos
requisitos. Si necesita agregar una interfaz de usuario específica para un dispositivo determinado, tal vez
deba volver a diseñar el flujo de datos y la lógica de control.
La partición del flujo de interacción de usuario de las actividades de procesamiento y recolección de datos
puede aumentar la facilidad del mantenimiento de la aplicación y proporcionar un diseño limpio al que se
puedan agregar fácilmente características aparentemente complejas, como la compatibilidad con el
trabajo fuera de línea. En la figura 2.4 se muestra el modo en que la interfaz y el proceso de usuario se
pueden abstraer el uno del otro.
Figura 2.4. Interfaces de usuario y componentes de proceso de usuario
Los componentes de proceso de usuario ayudan a resolver los siguientes problemas de diseño de
interfaces de usuario:
• Control de actividades de usuarios concurrentes. Determinadas aplicaciones permiten a los

usuarios realizar varias tareas a la vez poniendo a su disposición más de un elemento de interfaz. Por
ejemplo, una aplicación basada en Windows puede mostrar varios formularios, o una aplicación Web
puede abrir una segunda ventana de exploración.

Los componentes de proceso de usuario simplifican la administración del estado de varios procesos
salientes encapsulando todo el estado necesario para el proceso en un solo componente. Puede
asignar cada elemento de interfaz a una instancia determinada del proceso de usuario incorporando
un identificador de procesos personalizado en el diseño.
• Uso de varios paneles para una actividad. Si utiliza varias ventanas o paneles en una actividad
de usuario determinada, es importante mantenerlos sincronizados. En una aplicación Web, una
interfaz de usuario normalmente muestra un conjunto de elementos en una misma página (que
puede incluir marcos) para una actividad de usuario dada. No obstante, en las aplicaciones de cliente
enriquecidas, puede disponer de varias ventanas no modales que afectan a un solo proceso. Por
ejemplo, puede disponer de una ventana flotante de selección de categorías de productos en la
aplicación que permita especificar una categoría determinada, los productos de la cual se mostrarán
en otra ventana.
Asimismo, los componentes de proceso de usuario facilitan la implementación de este tipo de interfaz
a través de la centralización del estado de todas las ventanas en una única ubicación. Puede
simplificar aún más la sincronización en varios elementos de la interfaz utilizando formatos de enlace
a datos para los datos de estado.
• Aislamiento de las actividades de usuario de ejecución larga del estado empresarial.

Determinados procesos de usuario se pueden poner en pausa y posteriormente reanudar. El estado
intermedio del proceso de usuario se debe almacenar por lo general en una ubicación distinta a la de
los datos empresariales de la aplicación. Por ejemplo, un usuario puede especificar cierta información
necesaria para realizar un pedido y, a continuación, reanudar el proceso de desprotección. Los datos
de pedido pendiente se deben mantener en una ubicación distinta a la de los datos de los pedidos
completados, lo que permite realizar operaciones empresariales con los datos de los pedidos
completados (por ejemplo, contar el número de pedidos realizados en el mes actual) sin tener que
implementar reglas complejas de filtrado para evitar el uso de pedidos no completados.
Las actividades de usuario, al igual que los procesos empresariales, pueden presentar un "tiempo de
espera" específico cuando es necesario cancelar la actividad y se deben llevar a cabo las acciones de
compensación adecuadas en el proceso empresarial.
Puede diseñar los componentes de proceso de usuario para que se puedan serializar, o almacenar su
estado en una ubicación distinta a la de los datos empresariales de la aplicación.
Separación de un proceso de usuario de la interfaz de usuario
Para separar un proceso de usuario de la interfaz de usuario:
1. Identifique el proceso o los procesos empresariales que el proceso de interfaz de usuario ayudará a
realizar. Identifique el modo en que el usuario ve este proceso como una tarea (normalmente lo
puede hacer consultando los diagramas de secuencia creados como parte del análisis de requisitos).
2. Identifique los datos que necesitan los procesos empresariales. El proceso de usuario necesitará ser
capaz de enviar datos cuando sea necesario.

3. Identifique el estado adicional que necesitará mantener a lo largo de la actividad del usuario para
ayudar al procesamiento y la captura de datos en la interfaz de usuario.
4. Diseñe el flujo visual del proceso de usuario y el modo en que cada elemento de la interfaz recibe o
da flujo de control.
Asimismo, necesitará implementar código para asignar una sesión de interfaz de usuario determinada al
proceso de usuario relacionado:
• Las páginas ASP.NET tendrán que obtener el proceso de usuario actual a través de una referencia del
objeto Session o utilizando el proceso desde otro medio de almacenamiento, como una base de datos.
Necesitará esta referencia en los controladores de eventos para los controles de la página Web.
• Las ventanas y controles necesitan mantener una referencia al componente de proceso de usuario
actual. Puede mantener esta referencia en una variable de miembro. Sin embargo, se recomienda
que no mantenga la referencia en una variable global, ya que, si lo hace, la composición de interfaces
de usuario pasará a ser una tarea bastante compleja a medida que aumenta el tamaño de la interfaz.
Funcionalidad de los componentes de proceso de usuario
Los componentes de proceso de usuario:
• Proporcionan un modo simple de combinar los elementos de la interfaz de usuario en los flujos de
interacción del usuario sin que sea necesario volver a desarrollar el flujo de datos ni la lógica de
control.
• Separan el flujo de la interacción del usuario conceptual de la implementación o dispositivo en el que

ocurre.
• Encapsulan el modo en que las excepciones pueden afectar al flujo de proceso de usuario.
• Realizan el seguimiento del estado actual de la interacción del usuario.
• No deben inicializar ni participar en transacciones. Mantienen los datos internos relacionados con la
lógica empresarial de la aplicación y su estado interno, manteniendo los datos del modo adecuado.
• Mantienen el estado empresarial interno, normalmente aferrándose a una o varias entidades

empresariales afectadas por la interacción del usuario. Puede mantener varias entidades en variables
privadas o en una matriz interna o tipo de colección adecuado. En el caso de las aplicaciones basadas
en ASP.NET, puede mantener las referencias a estos datos en el objeto Session, pero ello limitará la
vida útil del proceso de usuario.
• Pueden proporcionar una característica de tipo "guardar y continuar más adelante" por la cual se
puede reiniciar la interacción de un usuario en otra sesión. Puede implementar esta funcionalidad
guardando el estado interno del componente de proceso empresarial de forma persistente y
proporcionando al usuario el modo de continuar una actividad determinada en un momento posterior.
Puede crear un componente de utilidad de administración de tareas personalizado para controlar el
estado de activación actual del proceso. El estado del proceso de usuario se puede almacenar en una
de las siguientes ubicaciones:

• Si el proceso de usuario puede continuar desde otros dispositivos o equipos, deberá almacenarlo
de forma central en una ubicación como, por ejemplo, una base de datos.
• Si se encuentra en un entorno desconectado, el estado del proceso de usuario se deberá

almacenar de forma local en el dispositivo del usuario.
• Si, por el contrario, el proceso de la interfaz de usuario se ejecuta en una batería de servidores
Web, deberá almacenar el estado requerido en una ubicación de servidor central, de modo que
se pueda continuar desde cualquiera de los servidores de la batería.
• Puede inicializar el estado interno llamando a un componente del proceso empresarial o a

componentes lógicos de acceso a datos.
• No se implementan normalmente como componentes de Enterprise Services. La única razón para

hacerlo sería utilizar las capacidades de autorización basadas en funciones de Enterprise Services.
• Se pueden inicializar por parte de un componente de utilidad personalizado que administra los menús
de la aplicación.
Diseño de interfaces de componentes de proceso de usuario
La interfaz de los componentes de proceso de usuario pueden exponer los siguientes tipos de
funcionalidad, como se muestra en la figura 2.5.
Figura 2.5. Diseño de componentes de proceso de usuario
• "Acciones" de proceso de usuario (1). Se trata de la interfaz de acciones que suele activar un
cambio en el estado del proceso de usuario. Las acciones se implementan en los métodos de
componentes del proceso de usuario, como demuestran los métodos ShowOrder,

EnterPaymentDetails, PlaceOrder y Finish en el código de ejemplo mostrado anteriormente. Debe

intentar encapsular las llamadas a los componentes empresariales en estos métodos de acción (6).
• Métodos de acceso a estado (2). Puede obtener acceso al estado específico de la empresa y al
estado independiente de la misma del proceso de usuario utilizando propiedades Get y Set detalladas
que exponen un valor, o exponiendo un conjunto de entidades empresariales con las que trata el
proceso de usuario (5). Por ejemplo, en el código de ejemplo anterior, el estado del proceso de
usuario se puede recuperar a través de propiedades de conjuntos de datos públicas.
• Eventos de cambio de estado (3). Estos eventos se activan cuando el estado específico o ajeno a
la empresa del proceso de usuario cambia. A veces será necesario implementar uno mismo estas
notificaciones de cambio. Sin embargo, en otros casos, puede almacenar los datos a través de un
mecanismo que realice esta tarea de forma intrínseca (por ejemplo, los conjuntos de datos activan
eventos siempre que sus datos cambian).
• Funciones de control que permiten iniciar, poner en pausa, reiniciar y cancelar un proceso
de usuario determinado (4). Estas funciones se deben mantener de forma independiente, pero se
pueden mezclar con las acciones del proceso de usuario. Por ejemplo, el código de ejemplo anterior
contiene métodos SaveToDataBase y ResumeCheckout. Los métodos de control podrían cargar los
datos de referencia necesarios para la IU (como la información necesaria para rellenar un cuadro
combinado) desde los componentes lógicos de acceso a datos (7) o delegar esta tarea al componente
de la interfaz de usuario (formularios, controles y páginas ASP.NET, entre otros) que necesita los
datos.
Recomendaciones generales relativas a los componentes de proceso de usuario
Tenga en cuenta las siguientes recomendaciones al diseñar componentes de proceso de usuario:
• Decida si necesita o no administrar los procesos de usuario como componentes independientes de la

implementación de la interfaz de usuario. Los procesos de usuario independientes son más necesarios
en aplicaciones con un gran número de cuadros de diálogo de interfaz de usuario, o en las
aplicaciones en las que los procesos de usuario pueden estar sujetos a personalización y se pueden
beneficiar de un enfoque de complementos.
• Elija la ubicación en la que almacenar el estado del proceso de usuario:
• Si el proceso se ejecuta de forma conectada, almacene el estado temporal de los procesos de

ejecución larga en una base de datos SQL Server central. En los escenarios desconectados, sin
embargo, almacénelo en archivos XML locales, en una ubicación aislada o en bases de datos
Microsoft SQL Server™ 2000 Desktop Engine (MSDE) locales. En los dispositivos Pocket PC,
puede almacenar el estado en una base de datos SQL Server CE.
• Si el proceso no es de ejecución larga y no es necesario recuperarlo en caso de que ocurra algún

problema, mantenga el estado en la memoria. En el caso de las interfaces de usuario creadas
para clientes enriquecidos, mantenga también el estado en memoria. Para las aplicaciones Web,
almacene el estado del proceso de usuario en el objeto Session de ASP.NET. Si se encuentra en
una batería de servidores Web, se recomienda que almacene la sesión en un servidor de estado

central o en una base de datos SQL Server. ASP.NET limpiará la sesión almacenada en SQL
Server para evitar la aglomeración de datos de estado.
• Diseñe los componentes de proceso de usuario de modo que se puedan serializar. De este modo,
facilitará la implementación de los esquemas de persistencia.
• Incluya control de excepciones en los componentes de proceso de usuario y propague las excepciones
a la interfaz de usuario. Los componentes de interfaz de usuario deben detectar las excepciones
generadas por los componentes de proceso de usuario y se deben publicar como se describe en el
capítulo 3: Directivas de seguridad, administración operativa y comunicaciones".
Conectividad de red y aplicaciones fuera de línea
En un gran número de casos, la aplicación requiere compatibilidad con operaciones fuera de línea cuando
la conectividad de red no está disponible. Por ejemplo, numerosas aplicaciones móviles, incluidos los
clientes enriquecidos para los dispositivos Pocket PC o Table PC, deben ser capaces de funcionar cuando el
usuario está desconectado de la red corporativa. Las aplicaciones fuera de línea deben basarse en datos
locales y en el estado del proceso de usuario para desempeñar su función. Siga las directrices generales
que se indican a continuación al diseñar aplicaciones fuera de línea.
El estado en línea y fuera de línea se debe mostrar al usuario. Esto se suele hacer en barras de estado o
de título, o con guías visuales en torno a los elementos de la interfaz de usuario que requieren una
conexión con el servidor.
Desarrolle la mayor parte de la interfaz de usuario de la aplicación de modo que pueda volver a utilizarla,
sin que sea necesario realizar modificaciones, o muy pocas, para admitir escenarios fuera de línea. En
estado fuera de línea, la aplicación no dispondrá de:
• Acceso a los datos en línea devueltos por los componentes lógicos de acceso a datos.
• Capacidad para invocar procesos empresariales de forma sincrónica. Por tanto, la aplicación no sabrá
si la llamada se realizó correctamente ni será capaz de utilizar los datos devueltos.
Si la aplicación no implementa en los servidores una interfaz basada completamente en mensajes pero se
basa en la adquisición sincrónica de los datos y en el conocimiento de los resultados de los procesos
empresariales (como hacen la mayor parte de las aplicaciones actuales), se recomienda realizar lo
siguiente para proporcionar el efecto óptico de conectividad:
• Implemente una caché local para los datos de referencia de sólo lectura relacionada con las
actividades del usuario. A continuación puede implementar un componente lógico de acceso a datos
fuera de línea que implemente exactamente las mismas consultas que los componentes lógicos de
acceso a datos del lado del servidor, pero que tenga acceso al almacenamiento local. Puede
implementar la caché local como una base de datos MSDE de escritorio. De este modo, podrá volver a
utilizar el diseño y la implementación de los principales esquemas SQL Server y procedimientos
almacenados. No obstante, MSDE afecta al estado global del equipo en el que se encuentra instalado,
y puede tener problemas para obtener acceso a él desde aplicaciones configuradas para confianza

moderada. En un gran número de escenarios, el uso de MSDE puede sobrepasar los requisitos de
persistencia de estado, por lo que puede resultar una mejor solución almacenar los datos en un
archivo XML o un conjunto de datos persistente.
• Implemente un componente empresarial fuera de línea que presente la misma interfaz que los
componentes empresariales, pero tome los datos enviados y los coloque en un sistema de mensajería
de almacenamiento y reenvío confiable, como Message Queue Server. Puede que a continuación este
componente fuera de línea no devuelva ningún valor, o un valor predefinido, a su llamador.
• Implemente funcionalidad de IU que proporcione un modo de inspeccionar la "bandeja de salida" de

acciones empresariales y probablemente elimine los mensajes contenidos en la misma. Si Message
Queue Server se utiliza para poner en cola los mensajes fuera de línea, no será necesario establecer
los permisos correspondientes en la cola para realizar esta tarea desde la aplicación.
• Diseñe las transacciones de la aplicación para que se acomode a las interacciones de IU basadas en
mensajes. Deberá prestar especial cuidado en administrar el bloqueo optimista y los resultados de las
transacciones en función de los datos de estado. Una técnica habitual para llevar a cabo
actualizaciones es enviar los datos antiguos y nuevos y permitir que el proceso empresarial o
componente lógico de acceso a datos relacionado resuelva los conflictos eventuales. En el caso de los
procesos empresariales, el envío puede incluir datos de referencia esenciales que la lógica
empresarial utiliza para decidir si se deja pasar o no a los datos. Por ejemplo, al realizar un pedido
puede incluir los precios de los productos junto con el Id. y la cantidad de los mismos. Si desea
obtener información más detallada sobre el bloqueo optimista, consulte "Diseño de componentes de
niveles y traspaso de los datos a través de éstos" en MSDN
(http://www.microsoft.com/spain/msdn/articulos/archivo/221102/voices/BOAGag.asp?.frame=true).
• Permita que el usuario mantenga el estado de los procesos de usuario de la aplicación en el disco y
los reanude más adelante.
La llegada de los dispositivos móviles basados en redes IP, la evolución del estándar de seguridad
inalámbrica, el estándar 802.11, IPv6, Tablet PC y otras tecnologías, aumentará la popularidad de las
redes inalámbricas. El problema que presentan las redes inalámbricas es que, con la tecnológica actual, no
pueden garantizar la conectividad con un alto nivel de confianza en todas las zonas. Por ejemplo, la
estructura de construcción, la maquinaria cercana y otros factores pueden causar "zonas oscuras"
permanentes o temporales en la red. Si diseña una aplicación para utilizarla en un entorno inalámbrico,
considere su diseño como una aplicación fuera de línea basada en mensajes con el fin de evitar una
experiencia llena de excepciones y reintentos. Por ejemplo, puede diseñar una aplicación de modo que un
usuario fuera de línea pueda escribir datos a través de la interfaz conectada, y que los datos se puedan
almacenar en una base de datos local, o poner en cola y sincronizar más adelante, cuando el usuario se
vuelva a conectar. SQL Server admite la réplica, que se puede utilizar para automatizar la sincronización
de datos de modo que queden acoplados de forma flexible, lo que permite la descarga de éstos al
dispositivo fuera de línea mientras está conectado, la modificación de los mismos cuando está
desconectado y su resincronización cuando se vuelve a conectar. Microsoft Message Queue Server permite
la encapsulación de los datos en un mensaje y la puesta en cola de los mismos en el dispositivo
desconectado para su envío a una cola del lado del servidor cuando se encuentra conectado. A
continuación, los componentes del servidor leerán el mensaje de la cola y lo procesarán. El uso de colas
locales o la réplica de SQL Server para controlar la comunicación de la entrada del usuario con el servidor

puede ayudar a mitigar los problemas de conectividad, incluso cuando la aplicación está conectada de
forma nominal. En los casos en los que sea necesario un enfoque de acoplamiento menos flexible, se
recomienda utilizar transacciones y un inicio de sesión personalizado para garantizar la integridad de los
datos.
Cuando la sincronización de los datos tiene lugar entre una aplicación desconectada (o de acoplamiento
flexible) y un servidor, debe tener en cuenta las siguientes consideraciones de seguridad:
• Message Queue Server proporciona su propio modelo de autorización, basado en la autenticación de

Windows. Si la aplicación se basa en una autenticación administrada por aplicaciones personalizadas,
los componentes del lado del cliente deberán firmar los documentos enviados al servidor.
• El cliente no se puede suplantar en el servidor si los datos se envían a través de una cola.
• Si utiliza la réplica de SQL Server, tal vez deba especificar una cuenta con permiso de acceso a las
bases de datos SQL Server del servidor. Al replicar desde SQL Server CE en un dispositivo móvil, es
necesario establecer una conexión segura al sitio de los Servicios de Internet Information Server (IIS)
que contiene el agente de servidor de SQL Server CE Server. Si desea obtener más información sobre
la configuración de la réplica de SQL Server, consulte la documentación suministrada con SQL Server
y SQL Server CE.
• Si la comunicación de red tiene lugar a través de una conexión HTTP, utilice el nivel de socket seguro
(SSL) para garantizar la seguridad del canal.
Notificación a los usuarios y comunicación empresarial de proceso a usuario
La función de la aplicación puede ser notificar a los usuarios sobre eventos específicos. A medida que
aumentan las capacidades de comunicación de Internet, dispondrá de más opciones para notificar a los
usuarios. Las tecnologías habituales incluyen actualmente el correo electrónico, la mensajería instantánea,
la mensajería de teléfono móvil y la paginación, entre otros.
En la notificación instantánea pueden intervenir un gran número de tecnologías de notificación diferentes y

el uso de servicios de presencia para detectar el modo adecuado de ponerse en contacto con un usuario.
Microsoft Patterns & Practices ha lanzado al mercado una arquitectura de referencia que cubre este
escenario.
Diseño de capas empresariales
La parte más importante de la aplicación es la funcionalidad que proporciona. Una aplicación realiza un
proceso empresarial que consta de una o varias tareas. En los casos más simples, cada tarea se puede
encapsular en un método de un componente .NET y llamar de forma sincrónica o asincrónica. Para los
procesos empresariales más complejos que requieren varios pasos y transacciones de ejecución larga, la
aplicación necesita disponer de un modo de organizar las tareas empresariales y almacenar el estado
hasta que el proceso se haya completado. En este tipo de escenario, puede utilizar BizTalk Server
Orchestration para definir el flujo de trabajo del proceso empresarial. El programa BizTalk Server que
implementa el flujo de trabajo puede utilizar a continuación la funcionalidad de mensajería de BizTalk

Server o llamar a los componentes empresariales .NET para llevar a cabo cada una de las tareas del modo
requerido.
Puede diseñar la lógica en las capas empresariales para su uso directo por parte de componentes de
presentación o su encapsulación como servicio y llamada a través de una interfaz de servicios, que
coordina la conversación asincrónica con los llamadores del servicio e invoca el flujo de trabajo de BizTalk
Server o los componentes empresariales. La parte principal de la lógica empresarial se suele denominar
lógica de dominio. Los componentes empresariales también pueden realizar solicitudes de servicios
externos, en cuyo caso tal vez sea preciso implementar agentes de servicios para administrar la
conversación requerida para la tarea empresarial específica realizada por cada uno de los servicios que
necesita utilizar.
En la figura 2.6 se muestran las capas empresariales de una aplicación.
Figura 2.6. Capas de componentes empresariales
Componentes y flujos de trabajo empresariales
Al implementar lógica empresarial, es necesario decidir si es preciso organizar o no el proceso empresarial,

o si será suficiente con disponer de un conjunto de componentes empresariales.
Se recomienda el uso de flujos de trabajo empresariales (implementados con BizTalk Orchestration) para:

• Administrar un proceso que conlleve varios pasos y transacciones de ejecución larga.
• Exponer una interfaz que implemente un proceso empresarial que habilite la aplicación para
establecer una conversación o un contrato con otros servicios.
• Beneficiarse de la amplia gama de adaptadores y conectores de numerosas tecnologías disponibles

para BizTalk Server.
Puede implementar el proceso empresarial utilizando sólo componentes empresariales cuando:
• No necesite mantener el estado de la conversación más allá de la actividad empresarial, y la

funcionalidad empresarial se pueda implementar como una única transacción atómica.
• Necesite encapsular funcionalidad y lógica que se pueda volver a utilizar por parte de numerosos
procesos empresariales.
• La lógica empresarial que se debe implementar necesita una gran cantidad de programación, o el
control detallado de las estructuras de datos y API.
• Necesita disponer del control total de los datos y del flujo de lógica.
En el ejemplo comercial, el pedido conlleva varios pasos (la autorización de la tarjeta de crédito, el
procesamiento del pago y la organización de la entrega, entre otros), los cuales se deben realizar en una
secuencia concreta. El enfoque de diseño más adecuado para este tipo de proceso empresarial es crear
componentes empresariales para encapsular cada uno de los pasos individuales en el proceso y organizar
dichos componentes utilizando un flujo empresarial.
Diseño de componentes empresariales
Los componentes empresariales pueden ser la raíz de las transacciones atómicas. Éstos implementan las
reglas empresariales en diversos patrones y aceptan y devuelven estructuras de datos simples o
complejas. Los componentes empresariales deben exponer funcionalidad de modo que sea independiente
de los almacenes de datos y los servicios necesarios para realizar la tarea, y se deben componer de forma
coherente desde el punto de vista del significado y transaccional.
Normalmente, la lógica empresarial evoluciona y aumenta, proporcionando lógica y operaciones de mayor

nivel que encapsulan la lógica preexistente. En un gran número de casos, necesitará componer
funcionalidad empresarial preexistente con el fin de realizar la lógica empresarial requerida. Al componer
lógica empresarial, debe prestar especial atención a la evolución de las transacciones.
Si el proceso empresarial invocará a otros procesos empresariales en el contexto de una transacción

atómica, todos los procesos invocados deben garantizar que sus operaciones participan en la transacción
existente de modo que las operaciones se deshagan en caso de que la lógica empresarial que realiza las
llamadas se interrumpa. Un técnica muy segura es volver a intentar una operación atómica si ésta da
error, sin miedo a que los datos pierdan su coherencia. Considere el límite de una transacción
determinada como un límite de reintento. Las transacciones de los servidores que ejecutan Windows se
pueden administrar utilizando el Controlador de transacciones distribuidas (DTC), utilizado por .NET
Enterprise Services (COM+). Para administrar transacciones distribuidas en entornos heterogéneos, puede

utilizar COM Transaction Integrator (COMTI) y Host Integration Server 2000. Si desea obtener más
información sobre COMTI y Host Integration Server, consulte http://www.microsoft.com/hiserver (en
inglés).
Si no puede implementar transacciones atómicas, necesitará ofrecer métodos y procesos de compensación.

Tenga en cuenta que una acción de compensación no devuelve necesariamente todos los datos de la
aplicación a su estado anterior, sino que restaura los datos empresariales a un estado coherente. Por
ejemplo, un proveedor puede exponer una interfaz de compra B2B (entre empresas) a sus socios. Una
acción de compensación para cancelar un pedido en proceso puede conllevar la imposición de una
cantidad por la cancelación de dicho pedido. En el caso de las transacciones y procesos de ejecución larga,
la acción de compensación puede variar en función del estado del flujo de trabajo, por lo que es necesario
diseñar dichas transacciones y procesos de forma adecuada para las distintas etapas del proceso.
Si desea obtener más información sobre el control de transacciones y el aislamiento de problemas de nivel,
consulte la sección relativa a transacciones en ".NET Data Access Architecture Guide" (en inglés) en MSDN
(http://msdn.microsoft.com/library/en-us/dnbda/html/daag.asp).
En la siguiente lista se resumen las recomendaciones relativas al diseño de componentes empresariales:
• Básese lo más que pueda en la comunicación basada en mensajes.
• Asegúrese de que los procesos expuestos en las interfaces de servicios no se pueden alterar y que,
por tanto, el estado de la aplicación o el servicio no perderá su coherencia si se recibe el mensaje dos
veces.
• Elija con cuidado los límites de la transacción de modo que se puedan realizar reintentos y
composiciones. Esto se aplica tanto a las transacciones atómicas como a las de ejecución larga.
Asimismo, debe considerar el uso de reintentos para sistemas basados en mensajes, sobre todo al
exponer la funcionalidad de la aplicación como un servicio.
• Los componentes empresariales se deben poder ejecutar en el contexto de cualquier usuario de

servicio; no necesariamente suplantando a un usuario de una aplicación específica. Esto permite su
invocación con mecanismos que ni transmiten ni delegan la identidad del usuario.
• Elija y mantenga un formato de datos coherente (como XML, conjunto de datos, etc.) para los
parámetros de entrada y los valores de devolución.
• Defina los niveles de aislamiento de forma adecuada. Si desea obtener más información sobre el
control de transacciones y el aislamiento de problemas de nivel, consulte la sección relativa a
transacciones en ".NET Data Access Architecture Guide" (en inglés) en MSDN
(http://msdn.microsoft.com/library/en-us/dnbda/html/daag.asp).
Implementación de componentes empresariales con .NET
Puede crear componentes que encapsulen la lógica empresarial utilizando .NET Framework. El código
administrado puede beneficiarse de Enterprise Services (COM+) para las transacciones distribuidas y otros
servicios habitualmente necesarios en las aplicaciones distribuidas.

Los componentes empresariales:
• Son invocados por la capa de proceso de usuario, las interfaces de servicios y otros procesos
empresariales, normalmente con datos empresariales, expresados como una estructura compleja de
datos (un documento).
• Son la raíz de las transacciones y, por tanto, deben votar en las transacciones en las que participan.
• Deben validar la entrada y la salida.
• Pueden exponer operaciones de compensación para los procesos empresariales que proporcionan.
• Pueden llamar a componentes lógicos de acceso a datos para recuperar y actualizar los datos de la
aplicación.
• Pueden llamar a servicios externos a través de agentes de servicios.
• Pueden llamar a otros componentes empresariales e inicializar flujos de trabajo empresariales.
• Pueden enviar una excepción al llamador si se produce algún error al utilizar transacciones atómicas.
• Pueden utilizar características de Enterprise Services para inicializar y votar en transacciones

heterogéneas. Debe considerar el hecho de que las diferentes opciones transaccionales pueden
repercutir considerablemente en el rendimiento. No obstante, la administración de transacciones no
es un mecanismo o una variable de ajuste para mejorar el rendimiento de la aplicación. Si desea ver
comparaciones de rendimiento de diferentes enfoques transaccionales, consulte "Control de
transacciones: Comparación de rendimiento" en MSDN
(http://www.microsoft.com/spain/msdn/articulos/archivo/070602/voices/Bdadotnetarch13.asp). La
configuración transaccional puede ser:
• Required. Utilice esta opción para aquellos componentes que puedan ser la raíz de una
transacción o que participarán en transacciones existentes.
• Supported. Utilice esta opción para aquellos componentes que no requieren necesariamente una
transacción, pero que desea que participen en una transacción existente, si es que hay una.
• RequiresNew. Utilice esta opción si desea que el componente inicie una nueva transacción
independiente de las transacciones existentes.
• NotSupported. Utilice esta opción si no desea que el componente participe en transacciones.
Nota El uso de las opciones RequiresNew y NotSupported afecta a la facilidad de composición de la

transacción. Por tanto, tenga en cuenta la repercusión que puede tener la recuperación de una transacción
primaria.
Los componentes empresariales son llamados por los siguientes clientes:
• Interfaces de servicios
• Componentes de proceso de usuario

• Flujos de trabajo empresariales
• Otros componentes empresariales
En la figura 2.7 se muestra un componente empresarial típico que interactúa con los componentes lógicos
de acceso a datos, las interfaces y los agentes de servicios y otros componentes empresariales.
Figura 2.7. Componentes empresariales
Observe los siguientes puntos en la figura 2.7:
1. Los componentes empresariales pueden ser invocados por los componentes de las capas de
presentación (normalmente los componentes de proceso de usuario) o por flujos de trabajo
empresariales (no se muestra).
2. Los componentes empresariales pueden ser invocados por interfaces de servicios (por ejemplo, un
servicio Web XML o una función de escucha de Message Queue Server).
3. Los componentes empresariales pueden llamar a componentes lógicos de acceso a datos para
recuperar y actualizar datos, y pueden invocar a otros componentes empresariales.
4. Los componentes empresariales también pueden invocar a agentes de servicios. Tenga especial
cuidado al diseñar la lógica de compensación en caso de que el servicio al que desea tener acceso no
esté disponible o lleve demasiado tiempo devolver un respuesta.
Nota Las flechas que aparecen en la figura 2.7 representan el flujo de control, no el flujo de datos.
Cuándo utilizar servicios empresariales para los componentes empresariales
Enterprise Services (COM+) son una clara opción para constituir el entorno host para los componentes
empresariales. Enterprise Services ofrecen a los componentes seguridad basada en funciones, control de
transacciones heterogéneo, agrupación de objetos e interfaces basadas en mensajes a través de
componentes en cola (entre otros). Puede no utilizar Enterprise Services en una aplicación. Sin embargo,
para llevar a cabo operaciones más complejas que las realizadas en un único origen de datos, necesitará

sus servicios, y el uso del modelo que proporciona Enterprise Services en la etapa inicial ofrece una pauta
de crecimiento más adecuada para el sistema.
Determine en la fase inicial del proceso de diseño si utilizará o no Enterprise Services en la

implementación de los componentes empresariales, ya que posteriormente resultará más difícil agregar o
quitar las características de Enterprise Services, así como el código del componente una vez creado éste.
Tenga en cuenta las siguientes características de diseño al implementar componentes con Enterprise
Services:
• Restricción de canales remotos. Sólo se admiten los canales HTTP y DCOM-RPC. Si desea obtener
más información, consulte la sección Diseño de la directiva de comunicaciones del capítulo 3,
"Directivas de seguridad, administración operativa y comunicaciones".
• Componentes de nombres seguros. Debe firmar estos componentes y todos los componentes que
éstos a su vez utilizan.
• Distribución. Los componentes bien se registran automáticamente (en cuyo caso requerirán
derechos administrativos en tiempo de ejecución), o bien, necesitará realizar un paso de
implementación adicional. No obstante, la mayoría de los componentes del lado del servidor requieren
pasos de implementación adicionales (para registrar orígenes de registro de eventos, crear colas de
Message Queue Server, etc.).
• Seguridad. Debe decidir si utilizar el modelo de funciones de Enterprise Services, basado en la

autenticación de Windows, o utilizar simplemente la seguridad basada en .NET.
Si desea obtener más información sobre Enterprise Services, consulte "Descripción de los Enterprise
Services (COM+) en .NET" en MSDN
(http://www.microsoft.com/spain/msdn/articulos/archivo/190702/voices/entserv.asp).
Patrones utilizados frecuentemente para los componentes empresariales
Independientemente de si los componentes empresariales se alojan en Enterprise Services, existe un gran

número de patrones comunes para implementar tareas empresariales en el código. Entre los patrones
utilizados más frecuentemente se incluyen:
• Patrón de canalización. Las acciones y consultas se ejecutan en un componente de forma

secuencial.
Una canalización es una definición de pasos que se ejecutan para realizar una función empresarial
determinada. Todos los pasos se ejecutan de forma secuencial. Cada paso puede conllevar la lectura
y escritura de datos que conforman el "estado de canalización" y puede o no obtener acceso a un
servicio externo. Al invocar un servicio asincrónico como parte de una paso, una canalización puede
esperar hasta que se devuelva una respuesta (si es que se espera) o continuar con el paso siguiente
de la canalización si no se requiere la respuesta para continuar con el procesamiento.
Utilice este patrón cuando:

• Pueda especificar la secuencia de un conjunto conocido de pasos.
• No necesite esperar una respuesta asincrónica en cada paso.
• Desea que todos los componentes indirectos puedan inspeccionar y actuar en los datos
procedentes de la cadena ascendente (pero no al contrario).
Entre las ventajas derivadas del uso de este patrón se incluyen:
• Resulta fácil de comprender e implementar.
• Aplica un procesamiento secuencial.
• Resulta fácil de ajustar en una transacción atómica.
Entre las desventajas derivadas del uso de este patrón se incluyen:
• El patrón puede ser demasiado simple, sobre todo para la organización de los servicios en los que
es necesario dividir la ejecución de la lógica empresarial de formas complejas.
• No controla construcciones condicionales, bucles y otra lógica de control de flujo. La adición de un

paso repercute en el rendimiento de la ejecución de la canalización.
Este patrón se utiliza muy a menudo en aplicaciones basadas en Microsoft Commerce Server. Si
desea obtener más información sobre el uso de las canalizaciones con Commerce Server, consulte
"Pipeline Programming Concepts" (en inglés) en la documentación del SDK de Commerce Server 2000
en MSDN (http://msdn.microsoft.com/library/en-us/comsrv2k/htm/cs_sp_pipelineobj_woce.asp).
• Patrón de eventos. Los eventos se activan en circunstancias empresariales determinadas, y en

respuesta a estos eventos se genera código.
Este patrón se utiliza si desea que tengan lugar un gran número de actividades, las cuales reciban los
mismos datos iniciales y no se puedan comunicar entre sí. Las actividades se pueden ejecutar en
paralelo o de forma secuencial. Puede que funcionen o no diferentes implementaciones, en función de
la información de filtrado. Si las implementaciones se han definido para ejecutarse de forma
secuencial, no se puede garantizar el pedido.
Utilice este patrón cuando:
• Desee administrar implementaciones independientes y aisladas de una "función" específica de

forma independiente.
• Las respuestas de una implementación no afectan al funcionamiento de otra implementación.
• Todas las implementaciones son de sólo escritura o de tipo "activar y olvidar", donde la salida del
proceso empresarial no está definida por ninguna de las implementaciones, o sólo por una
implementación empresarial específica.
Entre las ventajas derivadas del uso de este patrón se incluyen:

• Se aumenta la facilidad de mantenimiento gracias a la independencia de los procesos

empresariales no relacionados.
• Incentiva el procesamiento paralelo, lo que puede dar lugar a ventajas en cuanto a rendimiento.
• Resulta fácil de ajustar en una transacción atómica.
• Funciona independientemente de si las implementaciones se realizan de forma asincrónica o

sincrónica, ya que no se espera respuesta.
Entre las desventajas derivadas del uso de este patrón se incluyen:
• No permite crear respuestas complejas para la función empresarial.
• Un componente no puede utilizar los datos o el estado de otro para realizar su tarea.
Enterprise Services proporcionan el servicio de eventos, que ofrece un buen punto de inicio para la
implementación del patrón de eventos. Si desea obtener más información sobre los eventos de
Enterprise Services, consulte "COM+ Events" (en inglés) en la documentación del SDK de COM+ en
MSDN (http://msdn.microsoft.com/library/en-us/cossdk/htm/pgservices_events_2y9f.asp).
Implementación de flujos de trabajo empresariales con BizTalk Server
Cuando los procesos empresariales requieren varios pasos o transacciones de ejecución larga, es
necesario administrar el flujo de trabajo, controlando el estado de la conversación e intercambiando
mensajes con diversos servicios según sea necesario. BizTalk Server incluye servicios de organización que
facilitan el ajuste a estos retos.
Puede diseñar procesos empresariales utilizando los servicios de BizTalk Server Orchestration y crear
programas XLANG que implementen la funcionalidad empresarial. Los programas XLANG se crean
gráficamente utilizando el diseñador de BizTalk Server Orchestration y pueden utilizar BizTalk Messaging
Services, componentes .NET y COM, Message Queue Server o secuencia de comandos para realizar las
tareas empresariales. Estos programas se pueden utilizar para implementar transacciones de ejecución
larga, y mantienen automáticamente su estado en una base de datos SQL Server.
Puede utilizar BizTalk Server Orchestration para implementar la mayoría de los tipos de funcionalidad
empresarial. No obstante, resulta muy adecuado cuando el proceso empresarial conlleva proceso de flujo
de trabajo de ejecución larga en los que se intercambian documentos empresariales entre varios servicios.
Los documentos se pueden enviar a BizTalk Server mediante programación, o bien, se pueden enviar una
carpeta de un sistema de archivos supervisado o una cola de mensajes conocida como función de
recepción. Las funciones de recepción garantizan que los documentos enviados coinciden con la
especificación definida para documentos empresariales esperados, y si es así, consumen el documento y lo
envían al canal de proceso empresarial adecuado de BizTalk Server. Desde este punto de vista, una
función de recepción se puede considerar como una forma simple de interfaz de servicios.
Si desea ver un ejemplo detallado acerca de cómo implementar un proceso empresarial utilizando BizTalk
Server Orchestration y Visual Studio .NET, consulte "Building a Scalable Business Process Automation

Engine Using BizTalk Server 2002 and Visual Studio .NET" (en inglés) en MSDN
(http://msdn.microsoft.com/library/en-us/dnbiz2k2/html/BizTalkVSautoeng.asp).
Cuando el proceso empresarial conlleva interacciones con los sistemas existentes, como aplicaciones de
gran sistema, BizTalk Server puede utilizar adaptadores para integrarse con ellos. Si desea obtener más
información sobre la integración de BizTalk Server con sistemas existentes, consulte "Legacy File
Integration Using Microsoft BizTalk Server 2000" (en inglés) en MSDN
(http://msdn.microsoft.com/library/en-us/dnbiz/html/legacyfileint.asp).
Implementación de BizTalk Server Orchestration
En la figura 2.8 se muestra la interacción de un proceso empresarial organizado con las interfaces de
servicios, los agentes de servicios y los componentes empresariales.
Figura 2.8. Un proceso empresarial organizado
1. Los flujos de trabajo empresariales se pueden invocar desde otros servicios o desde los
componente4s de presentación (normalmente de componentes de proceso de usuario) utilizando la
interfaz de servicios.
2. Un flujo de trabajo empresarial invoca a otros servicios a través de un agente de servicios o

directamente a través de interfaces de servicios. Los mensajes salientes no tienen que coincidir
necesariamente con un mensaje entrante. Puede implementar interfaces y agentes de servicios en el
código o, si sólo requiere operaciones simples, puede utilizar la transformación de mensajes y las
características de función de BizTalk Server.
3. Los flujos de trabajo empresariales invocan a componentes empresariales. El flujo de trabajo

empresarial o los componentes que éste invoca pueden inicializar transacciones atómicas.

4. Los flujos de trabajo empresariales invocan a componentes lógicos de acceso a datos para realizar
actividades relacionadas con los datos.
5. Al diseñar flujos de trabajo empresariales, debe tener en cuenta los tiempos de respuesta
prolongados o las invocaciones a métodos sin respuesta. BizTalk Server permite automáticamente las
conversaciones de ejecución larga con servicios externos.
Los programas de BizTalk Server Orchestration se crean de forma gráfica utilizando el diseñador de
BizTalk Server Orchestration. En la figura 2.9 se muestra el aspecto de un flujo de organización de la
figura anterior procesado por el software de dibujo y diagrama de Microsoft Visio®. Observe la gran
similitud existente entre el diagrama conceptual de la figura 2.9 y el flujo que un analista o desarrollador
empresarial necesita.
Figura 2.9. Flujo de organización en el diseñador de BizTalk Server Orchestration
A continuación el dibujo se compila en un programa XLANG, un archivo con formato XML que contiene las
instrucciones necesarias para que BizTalk Server realice las tareas requeridas en el proceso empresarial.
Una vez compilado, el programa se puede inicializar de una de las siguientes formas:
• Se puede enviar mediante programación un mensaje de BizTalk Server a BizTalk Server o a través de
un sistema de archivos o función de recepción de Message Queue Server.

• Se puede inicializar un programa mediante programación desde código basado en COM utilizando el
moniker sked.
Si desea obtener más información sobre BizTalk Server Orchestration, lea BizTalk Server: The Complete
Reference por David Lowe et al (publicado por Osborne/McGraw Hill) y "Designing BizTalk Orchestrations"
en la documentación de BizTalk Server 2000 (en inglés) (http://msdn.microsoft.com/library/en-
us/biztalks/htm/lat_sched_intro_xiju.asp).
Si desea obtener más información sobre los adaptadores de BizTalk:
http://www.microsoft.com/biztalk/evaluation/adapters/adapterslist.asp (en inglés)
Puede encontrar la guía del desarrollador de BizTalk Server Adapter en:
http://www.microsoft.com/biztalk/techinfo/development/wp_adapterdevelopersguide.asp (en inglés)
Diseño de una interfaz de servicios
Si expone funcionalidad empresarial como un servicio, es necesario proporcionar un punto de entrada

para que llamen los clientes que abstraiga a la implementación interna. Asimismo, puede que también
necesite exponer funcionalidad similar a llamadores diferentes con requisitos de autenticación y contratos
de nivel de servicio (SLA) distintos. Puede proporcionar un punto de entrada al servicio creando una
interfaz de servicios.
Una interfaz de servicios es una entidad de software implementada normalmente como una fachada que
controla los servicios de asignación y transformación para permitir la comunicación con un servicio y aplica
un proceso y una política de comunicación. Una interfaz de servicios expone métodos, a los que se puede
llamar de forma individual o en una secuencia específica para formar una conversación que implemente
una tarea empresarial. Por ejemplo, el servicio de tarjetas de crédito del escenario de la aplicación
comercial podría proporcionar un método denominado AuthorizeCard que comprueba los detalles de las
tarjetas de crédito y un segundo método llamado ProcessPayment que transfiere los fondos de la cuenta
del titular de la tarjeta al distribuidor. Estos pasos se realizarían en el secuencia adecuada para procesar el
pago de un pedido.
Los requisitos de formato de comunicación, esquema de datos, seguridad y el proceso necesarios se

determinan como parte de un contrato publicado por el servicio. Este contrato proporciona la información
que necesitan los clientes para localizar y comunicarse con la interfaz de servicios.
Tenga en cuenta las siguientes recomendaciones al diseñar interfaces de servicios:
• Considere una interfaz de servicios como un límite de confianza de su aplicación.
• Si sus interfaces de servicios se exponen a organizaciones y consumidores externos o se hacen

públicas, se recomienda diseñarlas de modo que los cambios a la implementación interna no requiera
un cambio en la interfaz de usuarios.

• Puede que sea necesario que clientes diferentes consuman de formas distintas la lógica empresarial
del servicio, por lo que tal vez sea preciso publicar varias interfaces de servicios para la misma
funcionalidad.
• Las interfaces de servicios distintas pueden definir canales de comunicación, formatos de mensajes,
mecanismos de autenticación, acuerdos de nivel de servicio de rendimiento y capacidades
transaccionales diferentes. Los acuerdos de nivel de servicio habituales se definen a tiempo para
responder con una cantidad determinada de información.
Puede implementar las interfaces de servicios de varias formas, en función del modo en que desea
exponer la funcionalidad de la aplicación o servicio:
• Para exponer la lógica empresarial como un servicio Web XML, puede utilizar las páginas de servicios
Web ASP.NET o exponer determinados componentes a través de .NET Remoting utilizando SOAP y
HTTP.
• Para exponer la funcionalidad del servicio a clientes enviando mensajes Message Queue Server,
puede utilizar los desencadenadores de Message Queue Server o los componentes en cola de
Enterprise Services, o bien, puede escribir sus propios servicios de recepción de mensajes.
Si desea obtener más información, consulte la sección Diseño de la directiva de comunicaciones del
capítulo 3, "Directivas de seguridad, administración operativa y comunicaciones".
Características de interfaces de usuario
Tenga en cuenta las siguientes características de diseño de las interfaces de servicios:
• A veces la infraestructura .NET permite utilizar una interfaz de servicios transparente (por ejemplo,
puede exponer objetos de Enterprise Services como servicios Web en Windows .NET Server) y otras
puede necesitar agregar elementos específicos a la aplicación, como servicios Web XML, flujos de
trabajo de BizTalk Orchestration o puertos de mensajería. Considere la repercusión del uso de
interfaces de servicios transparentes, ya que pueden no proporcionar el nivel de abstracción
necesario para facilitar los cambios en la funcionalidad empresarial en una fecha posterior sin que ello
afecte a la interfaz de servicios. La implementación de fachadas conlleva un costo de desarrollo, pero
facilita el aislamiento de los cambios y el aumento de la facilidad del mantenimiento de la aplicación.
• Las interfaces de servicios pueden implementar almacenamiento de datos en caché, asignación y

transformación de esquemas y formatos simples; sin embargo, estas fachadas no deben implementar
la lógica empresarial.
• La interfaz de servicios puede conllevar un transporte transaccional (por ejemplo, Message Queue
Server) o no transaccional (por ejemplo, servicios Web XML a través de HTTP), lo que repercute en la
estrategia de administración de transacciones y errores.
• Se recomienda que diseñe las interfaces de servicios de modo que se obtenga el nivel máximo de
interoperabilidad con otras plataformas y servicios, basándose siempre que se pueda en los
estándares del sector para los sistemas de comunicación, seguridad y formatos, formatos de mensaje

estándar o simple (por ejemplo, esquemas XML simples para servicios Web XML) y mecanismos de
autenticación específica de no plataforma.
• En determinadas ocasiones la interfaz de servicios dispondrá de su propia identidad de seguridad y

autenticará los mensajes entrantes pero no podrá suplantarlos. Tenga en cuenta el uso de este
enfoque al llamar a componentes empresariales distribuidos en un servidor distinto a la interfaz de
servicios.
Uso de fachadas empresariales con interfaces de servicios
El canal o mecanismo de comunicaciones que utilice para exponer la lógica empresarial como un servicio
puede tener una forma asociada de implementar el código de la interfaz de servicios. Por ejemplo, si
decide crear servicios Web, la mayor parte de la lógica de la interfaz de servicios residirá en el propio
servicio Web, concretamente los archivos asmx.cs. También podría exponer el servicio a través de
Message Queue Server, en cuyo caso pudría utilizar los componentes en cola de Enterprise Services,
escuchas personalizadas o desencadenantes de Message Queue Server para "activar" el componente que
actúa como interfaz de servicios.
Si pretende crear un sistema que se pueda invocar a través de mecanismos diferentes, debe agregar una
fachada entre la lógica empresarial y la interfaz de servicios. Al implementar esta fachada, puede
consolidar en una ubicación el código relacionado con las políticas (como la autorización, la auditoria y las
validaciones, entre otros) de modo que se pueda utilizar por parte de varias interfaces de servicios que
traten con diversos canales. Esta fachada ofrece una mayor facilidad de mantenimiento debido a que aísla
los cambios en los mecanismos de comunicación de la implementación de los componentes empresariales.
A continuación el código de la interfaz de servicios trata con los detalles del mecanismo o el canal de
comunicación (por ejemplo, analizando los encabezados SOAP del servicio Web u obteniendo información
de los mensajes de Message Queue Server) y define el contexto adecuado para la invocación del
componente de fachada empresarial. En la figura 2.10 se muestra una fachada empresarial que se utiliza
de este modo.
Figura 2.10. Uso de una fachada empresarial con interfaces de servicios

En la figura 2.10 se muestra un ejemplo de cómo una fachada empresarial se utiliza con las interfaces de
servicios de un sistema determinado. IIS y ASP.NET reciben una llamada HTTP (1) e invoca a la interfaz
de servicios Web MyWebService.asmx (2). Esta interfaz de servicios inspecciona varios encabezados de
mensajes SOAP y define el objeto principal adecuado en función de la autenticación del servicio Web. A
continuación invoca a un componente de la fachada empresarial (3) que valida, autoriza y audita la
llamada. La fachada invoca posteriormente a un componente empresarial que realiza el trabajo
empresarial (4). El sistema debe a continuación admitir Message Queue Server, de modo que se crea una
escucha personalizada (5) que selecciona mensajes e invoca un componente de interfaz de servicios
denominado MyMSMQWorker (6). Este componente extrae los datos de las propiedades de los mensajes
de Message Queue Server (como Body, Label, etc.) y define el objeto principal adecuado en el subproceso
en función de la firma de mensaje de Message Queue Server. A continuación invoca a la fachada
empresarial. La división del código de la fachada empresarial de la interfaz de servicios, permitió que la
aplicación pudiera agregar un mecanismo de comunicación con un esfuerzo considerablemente menor.
Administración de transacciones en las interfaces de servicios
La interfaz de servicios deberá tratar con un canal que proporcione capacidades transaccionales (como
Message Queue Server) o no lo haga (como servicios Web XML). Es muy importante que diseñe los límites
transaccionales de modo que las operaciones se puedan volver a intentar en caso de error. Para ello,
asegúrese de que todos los recursos que utilizan son transaccionales, marque su componente raíz como
"requiere transacción" y todos los subcomponentes como "requiere transacción" o "es compatible con las
transacciones".
Con los mecanismos de mensajería transaccionales, la interfaz de servicios comienza la transacción en

primer lugar y, a continuación, selecciona el mensaje. Si la transacción se deshace, el mensaje no se
recibe automáticamente y se vuelve a poner en la cola para un nuevo intento. Al utilizar Message Queue
Server, los componentes en cola de Enterprise Services o los desencadenantes de Message Queue Server,
puede definir una operación de tipo "poner en cola y recibir mensaje" como transaccional para conseguir
este objetivo de forma automática.
Si utiliza un mecanismo de mensajería no transaccional (como los servicios Web XML), necesitará llamar a
la raíz de la transacción desde el código de la interfaz de servicios. En caso de error, puede diseñar el
código de la interfaz para volver a intentar la operación o devolver una excepción adecuada al llamador o
presentar los datos que representan un error.
Representación de datos y pasarlos a través de niveles
Cuando los componentes lógicos de acceso a datos devuelven datos, pueden hacerlo en varios formatos.
Los formatos pueden variar desde un formato centrado en datos (por ejemplo, una cadena XML) hasta un
formato más orientado a objetos (por ejemplo, un componente personalizado que encapsula una instancia
de una entidad empresarial). Formatos de devolución de datos frecuentes son:
• XML
• DataReader

• Conjunto de datos
• Conjunto de datos con tipo
• Objeto personalizado con propiedades que asignan a campos de datos y métodos que realizan
modificaciones de datos a través de componente lógicos de acceso a datos.
Si desea obtener más información sobre los distintos tipos de formatos de datos disponibles para el diseño
de aplicaciones, consulte "Diseño de componentes de niveles y traspaso de los datos a través de éstos" en
MSDN
(http://www.microsoft.com/spain/msdn/articulos/archivo/221102/voices/BOAGag.asp?.frame=true).
El formato de datos que elija dependerá del modo en que quiera trabajar con los mismos. Se recomienda
que evite los diseños que requieran la transferencia de datos en un formato orientado a objetos
personalizado, ya que ello requiere la implementación de serialización personalizada y puede repercutir
negativamente en el rendimiento. Generalmente, debería utilizar un formato más centrado en datos, como
conjunto de datos, para pasar los datos de los componentes lógicos de acceso a datos a las capas
empresariales y, a continuación, utilizarlos para hacer uso de una entidad empresarial personalizada si
desea trabajar con los datos de un modo orientado a objetos. En un gran número de casos, sin embargo,
resultará más fácil trabajar sólo con los datos empresariales contenidos en un conjunto de datos.
Representación de datos con componentes de entidades empresariales personalizadas
En la mayoría de los casos, se recomienda que trabaje directamente con datos, utilizando los conjuntos de
datos ADO.NET o documentos XML. Esto permite también pasar los datos estructurados entre las distintas
capas de la aplicación sin tener que escribir código personalizado. No obstante, si desea encapsular todos
los detalles del uso de un formato en particular o si desea agregar comportamientos a los datos, tal vez
deba desarrollar componentes personalizados. De este modo, obtendrá control total sobre lo que los
componentes de la aplicación pueden hacer con los datos, permitiéndole abstraer formatos internos de los
esquemas de datos utilizados por la aplicación, así como agregar comportamiento a los datos. En esta
guía se hace referencia a los componentes que se utilizan para representar datos como entidades
empresariales.
Por ejemplo, el proceso de pedido descrito anteriormente en esta guía podría utilizar un objeto Order, que
presenta un objeto Customer asociado, y una colección de objetos LineItem. Estos componentes forman
parte de las capas empresariales de la aplicación y otros componentes empresariales o de representación
pueden consumirlo.
Los componentes de entidad contienen datos de instantánea. Se trata de una caché de información local
efectiva, por lo que la coherencia de los datos sólo se puede garantizar si se leen en el contexto de una
transacción activa. Se recomienda no asignar una entidad empresarial a cada una de las tablas de la base
de datos; normalmente una entidad empresarial dispondrá de un esquema que es una desnormalización
de esquemas subyacentes. Tenga en cuenta que la entidad puede representar datos agregados de
numerosos orígenes.
Debido a que almacena los valores de los datos y los expone a través de sus propiedades, el componente
proporciona acceso programático con estado a los datos empresariales y la funcionalidad relacionada.

Evite el diseño de los componentes de entidad empresarial de modo que se obtenga acceso al almacén de
datos cada vez que una propiedad cambia y, e n su lugar, proporcione un método Update que propague
todos los cambios locales de nuevo a la base de datos. Los componentes de entidad empresarial no deben
tener acceso directo a la base de datos, pero deben utilizar componentes lógicos de acceso a datos para
realizar las tareas relacionadas con datos a medida que se invocan sus métodos. Las entidades
empresariales no deben inicializar ningún tipo de transacciones ni utilizar API de acceso a datos; son
meramente una representación de datos, potencialmente con comportamiento. Debido a que las entidades
se pueden invocar desde componentes empresariales e interfaces de usuario, deberían permitir el flujo de
transacciones de forma transparente y no deberían votar en transacciones salientes.
Es una buena idea diseñar componentes de entidad empresarial serializables, permitiéndole almacenar el
estado actual (por ejemplo, para almacenar en un disco local si se trabaja fuera de línea o en un mensaje
de Message Queue Server).
Los componentes de entidad empresarial simplifican la transición entre la programación orientada a

objetos y los modelos de desarrollo basados en documentos. El diseño orientado a objetos es habitual en
entornos con estado, como el diseño de interfaz de usuario, mientras que la funcionalidad y las
transacciones empresariales se pueden expresar normalmente de forma más clara en términos de
intercambios de documentos.
Nota Los componentes de entidad empresarial personalizados no son una parte obligatoria de todas las
aplicaciones. Un gran número de soluciones (sobre todo las aplicaciones basadas en ASP.NET y los
componentes empresariales) no utilizan representaciones personalizadas de entidades empresariales, sino
que en su lugar utilizan conjuntos de datos o documentos XML, ya que proporcionan toda la información
necesaria y el modelo de desarrollo se basa más en tareas y documentos que el orientado a objetos.
Diseño de interfaces de componentes de entidad empresarial
Los componentes de entidad empresarial exponen:
• Descriptores de acceso a propiedades (funciones Get y Set) para los atributos de la entidad.
• Descriptores de acceso a colecciones para subcolecciones de datos relacionados. (Las colecciones no

dan a lugar necesariamente a colecciones de entidades empresariales, por lo que puede diseñar la
entidad de servicio para exponer directamente conjuntos de datos o tablas de datos no relacionados
con la transversal de modelo de objetos).
• Las funciones y propiedades de control que se utilizan normalmente en la administración de entidades,

por ejemplo, Load, Save, IsDirty y Validate.
• Métodos de acceso a los metadatos de la entidad, que puede resultar útil para aumentar la facilidad
del mantenimiento de la interfaz de usuario.
• Eventos para señalar los cambios en los datos subyacentes.

• Métodos para realizar tareas empresariales u obtener datos para consultas complejas. Estos métodos
pueden actuar sólo en los datos locales (por ejemplo, Order.GetTotalCost) ni en los componentes o
procesos empresariales (por ejemplo, Order.Place).
• Métodos e interfaces necesarios para el enlace a datos.
Entre los clientes de los componentes de entidad empresarial se incluyen:
• Componentes de interacción de usuario para clientes enriquecidos. Estos componentes se pueden

enlazar a los datos de las entidades empresariales o los datos expuestos por las consultas expuestas
por el componente. Las funciones de control de IU pueden definir y obtener propiedades de entidades
empresariales para la entrada y visualización de datos.
• Componentes de proceso de usuario. Los componentes de proceso de usuario pueden mantener una o
varias entidades empresariales como parte de su estado interno específico de la aplicación.
• Componentes empresariales. Los componentes empresariales pueden pasar una entidad empresarial
como un parámetro a un método de componente lógico de acceso a datos (por ejemplo, se podría
pasar un objeto Order a un método InsertOrder en un componente lógico de acceso a datos).
Asimismo, los componentes empresariales pueden utilizar entidades empresariales para obtener
acceso al comportamiento de datos (por ejemplo, llamando a un método Place del objeto Order, que
a su vez pasa los datos de pedido a un componente lógico de acceso a datos), pero este enfoque es
menos habitual que pasar directamente la entidad empresarial a un método de componente lógico de
acceso a datos porque mezcla un modelo funcional orientado a documentos con un modelo basado en
objetos.
Recomendaciones relativas al diseño de entidades empresariales
Estas recomendaciones le ayudarán a implementar el mecanismo adecuado para la representación de

datos:
• Considere cuidadosamente si necesita codificación de entidades personalizadas o si otras

representaciones de datos se ajustan a sus requisitos. La codificación de entidades personalizadas es
una tarea compleja cuyo costo de desarrollo aumenta con el número de características que
proporciona. Las entidades personalizadas se suelen implementar para aplicaciones que necesitan
exponer una macro personalizada o un modelo de objetos de secuencias de comandos fácil de utilizar
para el desarrollador para personalización.
• Implemente entidades empresariales derivándolas de una clase base que proporciona funcionalidad
repetitiva y encapsula tareas habituales.
• Básese en el mantenimiento de conjuntos de datos internos o documentos XML para datos complejos
en lugar de colecciones y estructuras internas, entre otros.
• Implemente un conjunto habitual de interfaces en las entidades empresariales que exponen conjuntos
comunes de funcionalidad:
• Métodos y propiedades de control, como Save, Load, Delete, IsDirty y Validate.

• Métodos de metadatos, como getAttributesMetadata, getChildDatasetsMetadata y

getRelatedEntitiesMetadata, que resultan especialmente útiles para el diseño de interfaces de
usuario.
• Aísle las reglas de validación como metadatos, por ejemplo, exponiendo esquemas XSD (lenguaje de
definición de esquemas XML). Asegúrese, sin embargo, de que los llamadores externos no pueden
modificar estas reglas de validación.
• Las entidades empresariales deberían validar los datos que encapsulan a través de la aplicación de
reglas de validación continuas y a un momento dado.
• Implemente una aplicación implícita de relaciones entre entidades basada en los esquemas de datos y
las reglas empresariales en torno a los datos. Por ejemplo, un objeto Order podría disponer de un
número máximo de referencias LineItem.
• Diseñe entidades empresariales para que se basen en componentes lógicos de acceso a datos para la
interacción con las bases de datos. De este modo, podrá implementar todas las políticas de acceso a
datos y la lógica empresarial relacionada en una ubicación. Si las entidades empresariales tienen
acceso directo a bases de datos SQL Server, será indicio de que las aplicaciones implementadas a los
clientes que utilizan entidades empresariales necesitarán conectividad SQL y permisos de conexión.
Si desea obtener recomendaciones de diseño detalladas y código de ejemplo que le ayudará a desarrollar
los componentes de las entidades empresariales, consulte "Diseño de componentes de niveles y traspaso
de los datos a través de éstos" en MSDN
(http://www.microsoft.com/spain/msdn/articulos/archivo/221102/voices/BOAGag.asp).frame=true).
Diseño de capas de datos
Casi todas las aplicaciones y servicios necesitan almacenar y obtener acceso a un determinado tipo de
datos. Por ejemplo, la aplicación comercial descrita en esta guía necesaria almacenar datos de productos,
clientes y pedidos.
Al trabajar con datos debe determinar:
• El almacén de datos que utiliza.
• El diseño de los componentes utilizados para obtener acceso al almacén de datos.
• El formato de los datos pasados entre componentes y el modelo de programación necesario para ello.
La aplicación o servicio puede disponer de uno o varios orígenes de datos, los cuales pueden ser de tipos
diferentes. La lógica utilizada para obtener acceso a los datos de un origen de datos se encapsulará en
componentes lógicos de acceso a datos que proporcionan los métodos necesarios para la consulta y
actualización de datos. Los datos con los que la lógica de la aplicación debe trabajar están relacionados
con entidades del mundo empresarial que forman parte de la empresa. En determinados escenarios,
puede disponer de componentes personalizados que representan estas entidades, mientras que en otros
puede decidir trabajar con datos utilizando directamente conjuntos de datos ADO.NET o documentos XML.

En la figura 2.11 se muestra cómo la capa de datos lógicos de una aplicación consta de uno o varios
almacenes de datos y describe una capa de componentes lógicos de acceso a datos utilizados para
recuperar y manipular los datos en dichos almacenes.
Figura 2.11. Componentes de datos
La mayoría de las aplicaciones utilizan una base de datos relacional como almacén principal de los datos
de la aplicación. También se puede utilizar el almacén de Web Microsoft Exchange Server, bases de datos
heredadas, el sistema de archivos o servicios de administración de documentos.
Cuando la aplicación recupera datos de la base de datos, puede hacerlo utilizando un formato de conjunto
de datos DataReader. A continuación los datos se transfieren entre las capas y los distintos niveles de la
aplicación y, finalmente, uno de los componentes los utilizará. Tal vez desee utilizar formatos de datos
diferentes para recuperar, pasar y utilizar datos; por ejemplo, puede utilizar los datos de un conjunto de
datos para llenar las propiedades de un objeto de entidad personalizado. No obstante, debería intentar
mantener una coherencia en cuanto al tipo de formato utilizado, ya que mejorará probablemente el
rendimiento y la facilidad de mantenimiento de la aplicación para presentar sólo un conjunto limitado de
formatos, evitando así la necesidad de capas de traducción adicionales y de familiarizarse con API
diferentes.
En las siguientes secciones se describe la elección de almacenes de datos, el diseño de los componentes
lógicos de acceso a datos y las distintas posibilidades disponibles de representación de datos.

Almacenes de datos
Entre los tipos de almacenes habituales se encuentran:
• Bases de datos relacionales. Las bases de datos relacionales, como las bases de datos SQL Server,
proporcionan funcionalidad de administración de un gran volumen de datos transaccionales de alto
rendimiento con capacidades de seguridad, operaciones y transformación de datos. Las bases de
datos relacionales también alojan instrucciones y funciones complejas de lógica de datos en forma de
almacenamientos almacenados que se pueden utilizar como un entorno eficaz para los procesos
empresariales con un gran volumen de datos. SQL Server también proporciona una versión de
escritorio tipo Palm que permite utilizar implementaciones transparentes para los componentes
lógicos de acceso a datos. El diseño de bases de datos está más allá del alcance de esta guía. Si
desea obtener más información sobre el diseño de bases de datos relacionales, consulte "Database
Design Considerations" (en inglés) en el SDK de SQL Server 2000
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/createdb/cm_8_des_02_62ur.asp).
• Bases de datos de mensajería. Puede almacenar datos en el almacén Web de Exchange Server, lo
que resulta especialmente útil si la aplicación está centrada en el grupo, el trabajo en grupo o
mensajes y no desea basarse en otros almacenes de datos que pueden necesitar que se administren
de forma independiente. Sin embargo, los almacenes de datos de mensajes suelen presentar
menores capacidades de rendimiento, escalabilidad, disponibilidad y administración que los sistemas
de administración de bases de datos relacionales completas (RDBMS) y, por tanto, es relativamente
no habitual que las aplicaciones que utilicen el almacén de datos proporcionado por un producto de
mensajería. Si desea obtener más información sobre el desarrollo de un almacén de datos basado en
Exchange Server, consulte "Developing Web Storage System Applications" (en inglés) en MSDN
(http://msdn.microsoft.com/library/en-us/dnmes2k/html/webstorewp.asp).
• Sistema de archivos. Puede decidir almacenar los datos en sus propios archivos en el sistema de
archivos. Estos archivos pueden presentar su propio formato o el formato XML con un esquema
definido para los propósitos de la aplicación.
Hay un gran número de otros almacenes (como bases de datos XML, servicios de procesamiento analítico
en línea y bases de datos de almacenamiento de datos, entre otros) pero no son el objeto de análisis de
esta guía.
Componentes lógicos de acceso a datos
Independientemente del almacén de datos utilizado, la aplicación o el servicio utilizará componentes

lógicos de acceso a datos para obtener acceso a los datos. Estos componentes abstraen la semántica del
almacén de datos subyacente y la tecnología de acceso a datos (como ADO.NET) y proporcionan una
interfaz simple de programación para la recuperación y realización de operaciones con datos.
Los componentes lógicos de acceso a datos suelen implementar un patrón de diseño sin estado que separa
el procesamiento empresarial de la lógica de acceso a datos. Cada uno de estos componentes suele
proporcionar métodos para realizar operaciones Create, Read, Update y Delete (CRUD) relacionadas con
una entidad empresarial determinada de la aplicación (por ejemplo, Order). Los procesos empresariales

pueden utilizar estos métodos. La interfaz de usuario pueden utilizar las consultas específicas para
procesar los datos de referencia (como una lista de tipos de tarjetas de crédito válidos).
Cuando la aplicación contiene varios componentes lógicos de acceso a datos, puede resultar útil utilizar un
componente de ayuda de acceso a datos genéricos para administrar las conexiones de las bases de datos,
ejecutar comandos y almacenar parámetros en caché, entre otros. Los componentes lógicos de acceso a
datos proporcionan la lógica necesaria para obtener acceso a datos empresariales específicos, mientras
que el componente de ayuda para el acceso a datos centraliza el desarrollo de API de acceso a datos y la
configuración de la conexión a éstos, permitiendo de esta forma la reducción de código duplicado. Un
componente de ayuda de acceso a datos bien diseñado no debe repercutir negativamente en el
rendimiento y proporciona una ubicación central para el ajuste y optimización del acceso a datos.
Microsoft proporciona Data Access Application Block para .NET (http://msdn.microsoft.com/library/en-
us/dnbda/html/daab-rm.asp (en inglés)), que se puede utilizar como un componente de ayuda de acceso
a datos genéricos en la aplicación al utilizar bases de datos SQL Server.
En la figura 2.12 se muestra el uso de componentes lógicos de acceso a datos para obtener acceso a
datos.
Figura 2.12. Componentes lógicos de acceso a datos
1. Los componentes lógicos de acceso a datos exponen métodos para insertar, eliminar, actualizar y
recuperar datos, incluyendo la provisión de funcionalidad de paginación al recuperar grandes
cantidades de datos.
2. Puede utilizar un componente de ayuda de acceso a datos para centralizar la administración de la

conexión y todo el código relacionado con un origen de datos específico.
3. Se recomienda implementar las consultas y operaciones de datos como procedimientos almacenados

(si es compatible con el origen de datos) para mejorar el rendimiento y la facilidad de mantenimiento.

Nota El uso de componentes lógicos de acceso a datos se recomienda para todas las aplicaciones que
requieren obtener acceso a datos empresariales (como productos y pedidos, entre otros). No obstante,
otros productos y tecnologías pueden utilizar bases de datos para almacenar sus propios datos
operacionales, sin tener que hacer uso de este tipo de componentes.
Los componentes lógicos de acceso a datos proporcionan acceso simple a funcionalidad de bases de datos
(consultas y operaciones de datos), devolviendo estructuras de datos simples y complejas. Ocultan las
idiosincrasias de la invocación y el formato del almacén de datos de los componentes empresariales y las
interfaces de usuario que las consumen. La implementación de una lógica propia de acceso a datos en los
componentes lógicos de acceso a datos permite encapsular toda la lógica de acceso a datos de la
aplicación completa en una única ubicación central, lo que facilita el mantenimiento y la extensibilidad de
la aplicación.
Se recomienda que diseñe cada uno de los componentes lógicos de acceso a datos para trabajar con un
único almacén de datos. (Esto significa que los componentes no realizan consultas ni agregan datos de un
gran número de orígenes; esta función la realizan los componentes empresariales).
Al utilizar transacciones heterogéneas, los componentes lógicos de acceso a datos deben participar en
ellas, aunque constituir la raíz de las mismas. Resulta más adecuado que un componente empresarial
desempeñe esta función y que uno o varios componentes lógicos se utilicen para realizar las
actualizaciones de la base de datos.
Funcionalidad de los componentes lógicos de acceso a datos
Cuando se llaman, los componentes lógicos de acceso a datos realizan lo siguiente:
• Llevan a cabo asignaciones y transformaciones simples de argumentos de entrada y salida. De este

modo, se abstrae la lógica empresarial de los esquemas de la base de datos y las formas de
procedimientos almacenados.
• Obtienen acceso de un único origen. De este modo, aumenta la facilidad del mantenimiento
desplazando toda la funcionalidad de agregación de datos a los componentes empresariales, donde
los datos se pueden agregar en función de la operación empresarial específica que se está realizando.
• Actúan en una tabla principal y realizan operaciones en tablas relacionadas. (Los componentes lógicos
de acceso a datos no tienen por qué encapsular necesariamente operaciones sólo en una tabla de un
origen de datos subyacente.) De este modo, se aumenta la facilidad de mantenimiento de la
aplicación.
De forma opcional, pueden realizar las siguientes tareas:
• Utilizan un componente de utilidad personalizado para administrar y encapsular esquemas de bloqueo

optimistas.
• Utilizan un componente de utilidad personalizado para implementar una estrategia de

almacenamiento de datos en caché para los resultados de consultas no transaccionales.

• Implementan el enrutamiento dinámico de datos de sistemas de gran escala que proporcionan

escalabilidad a través de la distribución de datos en varios servidores de bases de datos.
Los componentes lógicos de acceso a datos no deben:
• Invocar a otros componentes lógicos de acceso a datos. Un diseño en el que los componentes lógicos
de acceso a datos no invocan a los otros componentes del mismo tipo facilita mantener la
previsibilidad de los datos y, por tanto, aumenta la facilidad del mantenimiento de la aplicación.
• Inicializar transacciones heterogéneas. Debido a que cada uno de los componentes lógicos de acceso
a datos sólo trata con un único origen de datos, no puede existir un escenario en el que uno de estos
componentes constituya la raíz de una transacción heterogénea. En determinados casos, sin embargo,
un componente lógico de acceso a datos puede controlar una transacción que conlleve varias
actualizaciones en un único origen de datos.
• Mantener el estado entre llamadas a métodos.
Diseño de la interfaz de componentes lógicos de acceso a datos
Los componentes lógicos de acceso a datos suelen requerir una interfaz para los siguientes clientes:
• Componentes y flujos de trabajo empresariales. Los componentes lógicos de acceso a datos

necesitan ofrecer E/S de documentos empresariales desconectados y escalares en métodos de estilo
funcionales sin estado, como GetOrderHeader().
• Componentes de interfaz de usuario. Los componentes de interacción de usuario pueden utilizar

componentes lógicos de acceso a datos para E/S de documentos empresariales desconectados para el
procesamiento de datos en clientes enriquecidos y escenarios de cliente desconectados, o para la
transmisión de salida (por ejemplo, obteniendo un elemento DataReader) para ASP.NET y clientes
que se benefician del procesamiento de secuencias. Considere el uso de componentes lógicos de
acceso a datos directamente de la interfaz de usuario si desea beneficiarse de las ventajas que aporta
el mayor rendimiento de este diseño y no necesita hacer uso de lógica empresarial adicional entre la
interfaz de usuario y el origen de datos.
Los componentes de acceso a datos pueden conectarse a la base de datos utilizando directamente una API
de acceso a datos como ADO.NET, o bien, puede decidir proporcionar un componente de ayuda de acceso
a datos adicional en aplicaciones más complejas para abstraer las complejidades que entraña el acceso a
la base de datos. En cualquier caso, intente utilizar procedimientos almacenados para realizar la
recuperación o modificación real de los datos al utilizar una base de datos relacional.
Los métodos que expone un componente lógico de acceso a datos puede realizar los siguientes tipos de
tareas:
• Funcionalidad habitual relacionada con la administración de "entidades", como las funciones CRUD.
• Consultas que pueden conllevar la obtención de datos de un gran número de tablas con propósitos de
sólo lectura. Los datos se pueden devolver como paginados o no paginados, en función de los

requisitos específicos, y los resultados se pueden transmitir o no dependiendo de si el llamador se

puede beneficiar de ellos.
• Acciones que actualizarán y, potencialmente, devuelven datos.
• Devolución de metadatos relacionados con los esquemas de entidades, parámetros de consulta y

esquemas de conjuntos de resultados.
• Paginación de las interfaces de usuario que requieran subconjuntos de datos, como el desplazamiento
a través de una lista extensa de productos.
Entre los parámetros de entrada a los métodos de componentes lógicos de acceso a datos se suelen
encontrar los valores escalares y documentos empresariales representados por cadenas XML o conjuntos
de datos. Los valores de devolución pueden ser escalares, conjuntos de datos, DataReader, cadenas XML
u otro tipo de formato de datos. Si desea obtener información sobre el diseño e implementación al elegir
un formato de datos para sus objetos, consulte "Diseño de componentes de niveles y traspaso de los
datos a través de éstos" en MSDN
(http://www.microsoft.com/spain/msdn/articulos/archivo/221102/voices/BOAGag.asp).frame=true).
Ejemplo de componente lógico de acceso a datos
El siguiente código en C# muestra un esquema parcial del esqueleto de un componente lógico de acceso a
datos simple que se podría utilizar para el acceso a los datos del pedido. Este código no se proporciona
como plantilla para el código, sino para ilustrar algunos de los conceptos descritos en este artículo.
public class OrderData
private string conn_string;
public OrderData()
// obtener la cadena de conexión de una ubicación segura o
// cifrada y asignarla a conn_string
public DataSet RetrieveOrders()

// Código para recuperar un conjunto de datos que contiene los

datos de los pedidos
public OrderDataSet RetrieveOrder(Guid OrderId)
// Código para devolver un conjunto de datos introducido llamado

OrderDataSet
// que representa un pedido específico.
// (OrderDataSet tendrá un esquema que se ha definido en Visual

Studio)
public void UpdateOrder(DataSet updatedOrder)
// código para actualizar la base de datos en función de las

propiedades
// de los datos del pedido enviados como parámetro de tipo conjunto

de datos
Recomendaciones relativas al diseño de componentes lógicos de acceso a datos
Tenga en cuenta las siguientes recomendaciones generales relativas al diseño de componentes lógicos de
acceso a datos:
• Devuelva sólo los datos que necesita. Mejorará el rendimiento y aumentará el nivel de escalabilidad.
• Utilice procedimientos almacenados para abstraer el acceso a datos del esquema de datos
subyacentes. No obstante, preste atención a no hacer un uso excesivo de este tipo de procedimientos,

ya que ello repercutirá negativamente en la facilidad de mantenimiento de la aplicación en cuanto a

código y reutilización. Un síntoma de uso excesivo de procedimientos almacenado es disponer de
grandes árboles de procedimientos almacenados que se llaman entre sí. Evite el uso de
procedimientos almacenados para implementar el control de flujo, manipular valores individuales (por
ejemplo, realizar manipulaciones de cadenas) o implementar otro tipo de funcionalidad que resulte
difícil de implementar en Transact-SQL.
• Básese en la funcionalidad RDBMS para las tareas que conlleven el uso de un gran volumen de datos.
Siga el siguiente principio: "Desplace el procesamiento a los datos, no al contrario". Encuentre un
equilibrio en el uso de los procedimientos almacenados y la facilidad de mantenimiento y reutilización
de la lógica de datos.
• Implemente un conjunto estándar o esperado de procedimientos almacenados proporcionando

funcionalidad habitualmente utilizada, como funciones de inserción, lectura, actualización y
localización. Ello ahorrará tiempo al desarrollar componentes empresariales. Si toma una actitud
proactiva hacia la implementación de esta funcionalidad, podrá realizar las implementaciones de
forma coherente y aplicar estándares internos. Si el diseño parece repetitivo, puede incluso utilizar
generadores de código para crear procedimientos almacenados repetitivos básicos y lógica de
componentes lógicos de acceso a datos.
• Exponga la funcionalidad esperada habitual en todos los componentes lógicos de acceso a datos en
una interfaz definida de forma independiente o clase base.
• Diseñe interfaces coherentes para clientes diferentes:
• Los componentes empresariales se pueden implementar de diversos modos, entre los que se
incluye el uso de código .NET personalizado, reglas BizTalk Orchestration o un motor de reglas
empresariales de terceros. El diseño de la interfaz para los componentes lógicos de acceso a
datos debe ser compatible con los requisitos de implementación de sus componentes
empresariales actuales y potenciales para evitar interfaces, fachadas o capas de asignación
adicionales entre ambos.
• Las interfaces de usuario basadas en ASP.NET se beneficiarán en cuanto a rendimiento del

procesamiento de datos expuestos como elementos DataReader. Estos elementos son muy
adecuados para operaciones de avance de sólo lectura en las que el procesamiento de cada fila
es bastante rápido. Si implementa los componentes lógicos de acceso a datos junto con la
interfaz de usuario, debería exponer un gran volumen de resultados de consulta para el
procesamiento en las funciones de componentes lógicos de acceso a datos que devuelven
elementos DataReader. Si pretende utilizar datos durante un largo período de tiempo, puede
mejorar la escalabilidad del sistema basándose en un conjunto de datos en lugar de en un
elemento DataReader.
• Haga que los componentes lógicos de acceso a datos exponga metadatos (por ejemplo, esquemas y
títulos de columnas) para los datos y operaciones con los que trata. De este modo, aumentará el nivel
de flexibilidad de las aplicaciones en tiempo de ejecución, sobre todo al procesar datos en interfaces
de usuario.

• No cree necesariamente un componente lógico de acceso a datos por tabla. Se recomienda diseñar
los componentes lógicos de acceso a datos para representar un nivel de abstracción y
desnormalización ligeramente superior que los procesos empresariales puedan consumir. No es
frecuente exponer una tabla de relaciones como tal. En su lugar, se debería exponer la funcionalidad
de la relación como operaciones de datos con los componentes lógicos de acceso a datos relacionados.
Por ejemplo, en una base de datos en la que una tabla TitleAuthor facilita una relación de varios a
varios entre libros y autores, no debe crear un componente lógico de acceso a datos para TitleAuthor,
sino proporcionar un método AddBook a un componente lógico de acceso a datos Author o un método
AddAuthor a un componente lógico de acceso a datos Book. Desde el punto de vista semántico,
puede agregar un libro a un autor o un autor a un libro, pero no puede "insertar autores".
• Si almacena datos cifrados, los componentes lógicos de acceso a datos deberían realizar el descifrado
(a no ser que desee que los datos cifrados vayan directamente al cliente).
• Si aloja los componentes empresariales en Enterprise Services (COM+), cree los componentes lógicos
de acceso a datos como componentes de servicios e impleméntelos en Enterprise Services como una
aplicación de biblioteca. De este modo, podrán participar y votar de forma explícita en las
transacciones Enterprise Services y utilizar autorización basada en funciones. Los componentes
lógicos de acceso a datos no necesitan alojarse en Enterprise Services si no va a utilizar ninguno de
los servicios o se van a cargar en el mismo elemento AppDomain que un llamador de Enterprise
Services. Si desea obtener más información sobre el uso de los Servicios de Enterprise Server,
consulte la sección "Componentes y flujos de trabajo empresariales" incluida en este capítulo.
• Habilite transacciones sólo cuando las necesite. No marque todos los componentes lógicos de acceso
a datos como requiere transacciones, ya que ello utilizaría recursos y resulta innecesario para las
operaciones de lectura realizadas por la interfaz de usuario. En su lugar, márquelas como es
compatible con las transacciones agregando el siguiente atributo:
• [Transaction (TransactionOption.Supported)]
• Considere el ajuste de los niveles de aislamiento para las consultas de datos. Si crea una aplicación
con requisitos de rendimiento alto, tal vez sea necesario realizar operaciones de datos especiales a
niveles de aislamiento inferiores que el resto de la transacción. La combinación de los niveles de
aislamiento puede repercutir de forma negativa en la coherencia de los datos, por lo que debe
analizar con cuidado esta opción en función de cada caso en concreto. Se recomienda definir los
niveles de aislamiento de transacciones sólo en la raíz de la transacción (es decir, los componentes de
los procesos empresariales). Si desea obtener más información, consulte la sección Diseño de capas
empresariales incluida en este capítulo.
• Utilice componentes de ayuda de acceso a datos. Para obtener más información sobre este enfoque,
así como las ventajas que éste aporta, consulte la sección Diseño de componentes de ayuda de
acceso a datos incluida en este capítulo.

Si desea obtener más información sobre el diseño de componentes lógicos de acceso a datos, consulte
".NET Data Access Architecture Guide" (en inglés)
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/daag.asp). Microsoft
también proporciona Data Access Application Block (en inglés) (http://msdn.microsoft.com/library/en-
us/dnbda/html/daab-rm.asp), un componente de ayuda de datos de alto rendimiento probado que puede
utilizar en la aplicación.
Diseño de componentes de ayuda de acceso a datos
Cuando una aplicación requiere una gran cantidad de componentes lógicos de acceso a datos para tener
acceso al mismo origen de datos, tal vez sea preciso implementar código de datos genéricos similar en
cada uno de los componentes lógicos de acceso a datos. Esta duplicación de la lógica puede conllevar
problemas de mantenimiento, así como dificultad la solución de problemas relativos al acceso a datos. La
centralización de la funcionalidad de acceso a datos genéricos en un componente de ayuda de acceso a
datos da lugar a un diseño más limpio que resulta más fácil de administrar. Los componentes de ayuda de
acceso a datos proporcionan un modelo de invocación sencillo para el origen de datos subyacente. Puede
considerar los componentes de ayuda de acceso a datos como fachadas genéricas del lado del cliente en el
origen de datos. Estos componentes suelen ser independientes a la lógica empresarial de la aplicación que
se está ejecutando. Normalmente, sólo dispondrá de uno o dos componentes de ayuda en un origen de
datos determinado. Cada uno de ellos puede implementar conjuntos diferentes de funcionalidad técnica
para el acceso al servicio. Por ejemplo, un componente de ayuda de acceso a datos de una base de datos
puede permitir invocar procedimientos almacenados, mientras que otro puede permitir la transmisión de
grandes cantidades de datos.
Para diseñar una aplicación independiente del tipo de origen de datos (por ejemplo, para que pueda
cambiar entre una base de datos Oracle y una base de datos SQL Server), puede disponer de dos
componentes sencillos de acceso a datos que expongan una interfaz similar. Tenga en cuenta sin embargo
que el cambio del origen de datos debe garantizar las pruebas adicionales de la aplicación y que la
transparencia de origen de datos no es un objetivo dudoso para la mayoría de las aplicaciones,
probablemente con la excepción de las aplicaciones "ajustadas" desarrolladas por ISV.
El objetivo de utilizar un componente de ayuda de acceso a datos es:
• Abstraer el modelo de programación API de acceso a datos de la lógica empresarial relacionada con
los datos encapsulados en los componentes lógicos de acceso a datos y, por tanto, reducir y
simplificar el código de dichos componentes.
• Aislar la semántica de administración de conexión.
• Aislar la ubicación del origen de datos (a través de la administración de las cadenas de conexión).
• Aislar la autenticación del origen de datos.

• Aislar la inclusión en lista de las transacciones (ADO.NET lo hace automáticamente cuando se utiliza
para obtener acceso a los datos de una base de datos SQL Server o al utilizar ODBC o OLEDB).
• Centralizar la lógica de acceso a datos para facilitar el mantenimiento, al tiempo que se minimiza la
necesidad de hacer uso de capacidades de codificación específicas del origen de datos a través del
equipo de desarrollo y se facilita la solución de problemas de acceso a datos.
• Aislar las dependencias de versión de API de acceso a datos de los componentes lógicos de acceso a
datos.
• Proporcionar un único punto de interceptación para el seguimiento y comprobación del acceso a datos.
• Utilizar al acceso a código y la autorización basada en usuario o función para restringir el acceso a
todo el origen de datos.
• Traducir las excepciones que no pertenecen a .NET devueltas por el origen de datos en excepciones
que la aplicación pueda controlar con métodos tradicionales.
Para ver un ejemplo de un componente de ayuda de acceso a datos, incluido el código de origen y la
documentación, descargue Data Access Application Block para .NET (en inglés) de MSDN
(http://msdn.microsoft.com/library/en-us/dnbda/html/daab-rm.asp).
Acceso a varios orígenes de datos
Si obtiene acceso a una base de datos Oracle u otros orígenes de datos, tal vez prefiera abstraer al
máximo la API con la que obtiene acceso a dichos orígenes de los componentes lógicos de acceso a datos.
Microsoft proporciona implementaciones de Oracle y OLE DB de Data Access Application Block y las ha
probado en el contexto de la cota de rendimiento Nile. Puede descargar estas implementaciones en MSDN,
siguiendo los vínculos que se incluyen en este artículo:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/manprooracperf.asp (en
inglés).
Conseguir la transparencia de RDBMS es un objetivo de diseño bastante complejo, por lo que el uso de
componentes de ayuda de acceso a datos puede mitigar un tanto los esfuerzos de desarrollo, solución de
problemas y mantenimiento. No obstante, deberá comprobar la aplicación con cada uno de los orígenes de
datos debido a las diferentes formas en las que los sistemas de administración de bases de datos
relacionales controlar los procedimientos almacenados, cursores y otros artefactos de bases de datos.
Si lo que pretende es que la aplicación se distribuya en entornos diferentes con sistemas de

administración de bases de datos relacionales, puede implementar los componentes de ayuda de acceso a
datos con una interfaz común y proporcionar el componente que obtiene realmente el acceso a los datos a
un origen de datos determinado en un patrón predeterminado. Puede cambiar el código fuente
suministrado para los bloques de aplicación para .NET mencionados anteriormente para satisfacer estos
requisitos específicos.
Integración con servicios

Si en su proceso empresarial intervienen servicios externos, será necesario controlar la semántica de la

comunicación con cada servicio al que sea necesario llamar. En concreto, deberá utilizar la API de
comunicación adecuada para llamar al servicio y realizar las traducciones necesarias entre los formatos de
datos utilizados por el servicio y los utilizados por el proceso empresarial. Si el contrato de servicio consta
de una conversación de ejecución larga, también deberá mantener el estado intermedio mientras espera
una respuesta.
Se recomienda utilizar un componente de agente de servicios que encapsule la lógica necesaria para
encapsular estas tareas e inicializar y administrar una conversación basada en mensajes para cada uno de
los servicios que debe consumir la aplicación. Los agentes de servicios se pueden considerar como los
componentes lógicos de acceso a datos para los servicios distintos a los almacenes de datos, o como
servidores proxy o emisarios para otros servicios. Determinados publicadores de servicios pueden
proporcionar a los llamadores un agente de servicios incorporado. En otros casos, por el contrario, puede
que sea necesario que desarrolle el suyo propio.
El objetivo de utilizar un agente de servicios es:
• Encapsular el acceso a un servicio.
• Aislar la implementación de los procesos empresariales de la implementación de formato de datos o

cambios de esquema.
• Proporcionar los formatos de datos de entrada y salida compatibles con los componentes
empresariales que llaman al servicio.
Los agentes de servicios también puedan realizar los siguientes tipos de tareas habituales si es necesario:
• Llevar a cabo la validación básica de los datos intercambiados con el servicio.
• Almacenar en caché los datos necesarios para realizar consultas habituales.
• Autorizar el acceso al servicio, proporcionando una forma granular de comprobar la seguridad antes
de obtener acceso al servicio desde el punto de vista de la aplicación que realiza la llamada.
Normalmente, el servicio también suele autenticar y autorizar las solicitudes.
• Definir la seguridad adecuada u ofrecer las credenciales necesarias al servicio para la autenticación.
Por ejemplo, para definir las credenciales para un servicio Web XML que se está invocando, puede
utilizar HTTPCredentialCache.
• Asegurarse de que las partes adecuadas del mensaje están cifradas o de que se puede establecer un
canal de seguridad si es necesario.
• Proporcionar información de supervisión que posibilite la interacción con el servicio que se va a

implementar, lo que permite determinar si sus socios cumplen con sus contratos de nivel de servicio
(SLA).
Administración de conversaciones asincrónicas con servicios

En determinados casos, es necesario integrar la aplicación con otros servicios, enviando y recibiendo
llamadas asincrónicas. En este caso, las interfaces de servicios recibirán llamadas de los servicios externos
y se realizarán llamadas a dichos servicios desde los agentes de servicios. Si estos intercambios de
mensajes se implementan de modo asincrónico, tal vez sea preciso realizar el seguimiento de la
conversación a la que pertenece un determinado conjunto de intercambios de mensajes. Se recomienda
que utilice una de las dos siguientes opciones para realizar el seguimiento del estado de la conversación:
• Utilice los datos empresariales de los mensajes para identificar la conversación. Por ejemplo, puede
hacer uso del número de Id. de un producto determinado en todos los mensajes para identificar el
pedido que se está procesando en un intercambio de mensajes concreto. Este el modo más sencillo
de correlacionar mensajes.
• Proporcione un componente o utilidad de infraestructura que genere GUID o Id. para conversaciones
específicas y los adjunte a los mensajes. Los agentes e interfaces de servicios deberán tener acceso a
esta información con el fin de determinar el modo de interpretar una llamada asincrónica determinada.
Asimismo, es necesario disponer de una base de datos persistente para realizar el seguimiento del
estado y el Id. de cada conversación. Todo esto requiere trabajo de desarrollo adicional. Tenga en
cuenta que el contexto del mensaje se pederá si éste se debe interpretar fuera del servicio. No
obstante, resulta adecuado utilizar Id. de correlación propios si desea mantener la confidencialidad de
la información.
Si desea obtener más información sobre este tema, consulte el capítulo 3, "Directivas de seguridad,
administración operativa y comunicaciones".

Capítulo 3: Directivas de seguridad, administración

operativa y comunicaciones
Diciembre de 2002
Resumen: en este capítulo se describen las directivas relativas a la seguridad, administración operativa y
comunicaciones que afectan al diseño de una aplicación o un servicio .NET distribuidos.
Las directivas de organización definen las reglas que determinan la forma en que se protege una
aplicación, el modo en que se administra, así como la forma en que los distintos componentes de una
aplicación se comunican entre sí y con los servicios externos. Las directivas afectan al diseño de cada capa
de la aplicación o servicio, tal como se muestra en la figura 3.1.
Figura 3.1. Efecto de las directivas organizativas en el diseño de aplicaciones
Las directivas no sólo se determinan a nivel organizativo, sino que también se pueden establecer dentro
de las organizaciones. En ciertos casos, resulta útil recurrir al concepto de zonas: todas las aplicaciones,
servicios o incluso niveles de la aplicación se encuentran en la misma zona si comparten un subconjunto
de las directivas. Por ejemplo, un centro de datos de Internet puede tener un conjunto de directivas
distinto al del resto de infraestructura de una compañía y definir una zona especial con unas restricciones
de seguridad más estrictas que las de otras partes de la aplicación. De este modo, las aplicaciones y
servicios de este centro de datos se encontrarán en una zona diferente a la de las aplicaciones y servicios
de la intranet. El conocimiento de las directivas de cada componente, lo que permite definir las zonas en
las que éste se ejecutará, constituye un aspecto fundamental a la hora de determinar dónde se
implementarán los componentes.

Este es el capítulo 3 de Arquitectura de aplicaciones de .NET: Diseño de aplicaciones y servicios. Comience

por aquí para obtener una visión general completa.
• Diseño de la directiva de seguridad
• Diseño de la directiva de administración operativa
• Diseño de la directiva de comunicaciones
Diseño de la directiva de seguridad
La directiva de seguridad se ocupa de la autenticación, autorización, comunicación segura, auditoria y

administración de perfiles, tal como muestra la figura 3.2.
Figura 3.2. Aspectos de la directiva de seguridad
Principios generales sobre seguridad
Existen ciertos principios generales sobre seguridad que se deben tener en cuenta a la hora de desarrollar
una directiva de seguridad. Tenga en cuenta las siguientes directrices:
• Siempre que sea posible, debe recurrir a sistemas de seguridad que se hayan comprobado y
demostrado su eficacia en lugar de generar su propia solución personalizada. Utilice los algoritmos,
técnicas e infraestructura suministrada con la plataforma que se hayan probado dentro del sector, así
como tecnologías compatibles y comprobadas por los proveedores. Si decide realizar un desarrollo
personalizado de la infraestructura de seguridad, valide su enfoque y técnicas mediante auditoria con
expertos y organizaciones que se dedican a la revisión de la seguridad, antes y después de su
implementación.
• Nunca confíe en las aportaciones externas. Deberá validar todos los datos que introduzcan los
usuarios o envíen otros servicios.
• Considere por principio que los sistemas externos no son seguros. Si su aplicación recibe datos
confidenciales sin cifrar desde un sistema externo, asuma que dicha información no es segura.

• Aplique el principio del menor privilegio. No habilite más atributos en las cuentas de servicios que los
que resulten estrictamente necesarios para la aplicación. Obtenga acceso a los recursos con cuentas
que tengan los mínimos permisos necesarios.
• Reduzca el área de superficie. El riesgo se incrementa según aumenta el número de componentes y

datos que haya expuesto a través de la aplicación y, por lo tanto, deberá exponer únicamente la
funcionalidad que crea que otros van a utilizar.
• Establezca como predeterminado un modo seguro. No habilite servicios, tecnologías y derechos de

cuenta que no sean absolutamente necesarios. Cuando implemente la aplicación en equipos cliente o
servidor, la configuración predeterminada de ésta deberá ser segura.
• No confíe en la seguridad a través del ocultamiento. El cifrado de los datos implica disponer de claves
y de un algoritmo de cifrado demostrado. El almacenamiento de los datos seguros evitará el acceso a
ésta en cualquier circunstancia. No se puede considerar seguridad la mezcla de diversas cadenas, el
almacenamiento de la información en rutas de archivo inesperadas y demás técnicas similares.
• Siga los principios de STRIDE. (STRIDE responde a las siglas inglesas de Simulación, Alteración,
Repudio, Revelación de información, Denegación de servicio y Elevación de privilegios). Todas estas
son clases de vulnerabilidades de la seguridad contra los que un sistema se debe proteger. Si desea
obtener más información sobre STRIDE, consulte "Designing for Securability" (en inglés) en MSDN en
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/vsent7/html/vxcondesigningforsecurability.asp.
• Realice la comprobación desde la misma puerta. No permita que los procesos vayan más allá del
lugar para el que los usuarios están autorizados.
• Bloquee su sistema interna y externamente: los usuarios y operadores internos pueden representar
un riesgo igual que los intrusos externos.
Autenticación
La autenticación se define como identificación segura, que básicamente quiere decir que dispone de un
mecanismo para identificar con seguridad a los usuarios que se adecua a los requisitos de seguridad de su
aplicación.
La autenticación se debe implementar en la capa de la interfaz de usuario para proporcionar funciones de

autorización, auditoría y personalización. Esto generalmente requiere que el usuario escriba sus
credenciales (como por ejemplo, nombre y contraseña) para demostrar su identidad. Entre otros tipos de
credenciales se incluyen las lecturas biométricas, tarjetas inteligentes, claves físicas, certificados digitales,
etc.
Si su aplicación se expone como servicio, probablemente desee autenticar también en ciertas interfaces de
servicio para asegurarse de que se compromete en un intercambio con un socio conocido y de confianza,
así como que otros servicios externos no simulan su aplicación para hacer creer que quien llama es otra
persona.

Nota Para obtener más información sobre la autenticación de llamadores con Microsoft® ASP.NET,
consulte "Autenticación en ASP.NET: Directrices de seguridad para .NET" en MSDN

(http://www.microsoft.com/spain/msdn/articulos/archivo/261001/voices/authaspdotnet.asp).
En su diseño, debe perseguir como objetivo disponer de una lógica empresarial que sea transparente en el
proceso de autenticación. Por ejemplo, no es aconsejable tener un parámetro adicional en los métodos de
componentes sólo para pasar información del usuario, a menos que la función empresarial lo requiera.
Flujo de la identidad entre los niveles
Cuanto más lejos del usuario se encuentra una parte de la funcionalidad, menos significativa se vuelve la
identidad de éste. En una solución basada en servicios, puede que algunas actividades ni siquiera las inicie
un usuario. El objetivo de su diseño debe ser reducir la relevancia del usuario llamador cuanto más lejos
de la interfaz de usuario esté la actividad.
Puede que necesite establecer un flujo de las identidades de los llamadores originales (usuarios o
servicios) a través de las capas de la aplicación para realizar la autorización o auditoria. La identidad
puede ser la de un llamador original (usuario o servicio), o bien una cuenta de servicio de un nivel de
aplicación. Para establecer el flujo de la identidad, puede permitir que el mecanismo de comunicación
establezca el flujo del contexto de seguridad (por ejemplo, mediante el uso de la delegación de Kerberos
junto con la interacción remota de DCOM), puede pasar símbolos (tokens) o vales de autenticación, o bien
el Id. o las credenciales del usuario.
Considere los siguientes escenarios:
• El llamador y la aplicación a la que se llama no comparten el subsistema de seguridad de la

plataforma o un mecanismo de autenticación común. En este escenario, no puede "fluir" un contexto
de seguridad existente; deberá volver a autenticar pasando las credenciales apropiadas.
• El llamador y la aplicación a la que se llama se encuentran en dominios de Microsoft Windows® de

confianza, o bien la aplicación realiza la autorización basada en identidades de Windows o utiliza
funciones de Microsoft .NET Enterprise Services. En este escenario, necesitará elegir un mecanismo
de comunicación que establezca el flujo de vales de Kerberos o símbolos de NTLM. DCOM-RPC
proporciona esta capacidad. Mediante el uso de la información que proporciona el canal, puede volver
a crear su principal personalizado y adjuntarlo al subproceso basado en la información de la
autenticación. Tenga en cuenta que los símbolos de NTLM sólo se pueden utilizar a través de un solo
salto de red para la autenticación y que la delegación de Kerberos requiere directivas en los niveles
de equipo, usuario y dominio. Si desea obtener más información, consulte "Diseño de la directiva de
comunicaciones" en este mismo capítulo, o bien, los siguientes artículos:
• "Windows 2000 Kerberos Delegation"

(http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/prodtechnol/windows200
0serv/deploy/kerberos.asp) (en inglés)
• "Impersonating and Reverting" (http://msdn.microsoft.com/library/default.asp?url=/library/en-

us/cpguide/html/cpconimpersonatingreverting.asp) (en inglés)

• El llamador y la aplicación a la que se llama comparten un mecanismo de autenticación que no

pertenece a Windows como, por ejemplo, una solución con un inicio de sesión único o un servicio Web
centralizado que autentica a los usuarios. En este escenario, establece el flujo de símbolos o tokens
que proporciona el servicio de autenticación. Debe pasar estos símbolos en mecanismos fuera de
banda (no en parámetros de funciones) como, por ejemplo, en encabezados SOAP. El mecanismo de
autenticación debe autenticar al usuario cuando se le presenta un símbolo válido; lo que implica que
los símbolos que autentica no tienen afinidad con el equipo de origen. Asimismo, se debe asegurar de
que los símbolos se pueden autenticar en una ventana de tiempo suficientemente amplia,
especialmente en transacciones de ejecución larga. Los símbolos se producen a menudo con un hash
de las credenciales del usuario y un valor salt. Para obtener la definición del valor salt, consulte el
glosario sobre seguridad en MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/security/Security/s_gly.asp) (en inglés).
• El llamador y la aplicación a la que se llama se ejecutan en el mismo contexto. En este escenario,

Microsoft .NET realiza la llamada, manteniendo el objeto CurrentPrincipal existente en el subproceso.
Este es el caso de todas las actividades dentro del mismo dominio de aplicación y para las llamadas a
las aplicaciones basadas en Enterprise Services con la activación de biblioteca.
Autenticación con otros servicios
Puede que su aplicación necesite invocar diferentes servicios en nombre de un determinado usuario. Los
esquemas de servidor de inicio de sesión único asignan símbolos y/o credenciales de un usuario
determinado para un conjunto de servicios o almacenes de datos. Por ejemplo, su aplicación podría
autenticar a un usuario llamado "Jose", quien podría obtener acceso a un almacén de datos heredados en
el que iniciase sesión como "Pepe". Se recomienda que diseñe la aplicación o servicio de forma que tenga
acceso a otros almacenes de datos y otros servicios mediante cuentas de servicio (por ejemplo,
"SalesApplication") en lugar de representar al usuario original; sin embargo, los estrictos requisitos de
seguridad que impone la organización pueden hacer imposible esta opción. El desarrollo de características
de asignación de cuentas puede resultar complejo, especialmente si necesita administrar credenciales, ya
que, por lo general, las cuentas de usuario se deben mantener sincronizadas. No obstante, se pueden
utilizar con gran eficacia algunos mecanismos de asignación de cuentas, como por ejemplo la asignación
de los certificados de cliente a cuentas de Windows mediante el uso de Servicios de Internet Information
Services (IIS) de Microsoft.
Si necesita representar cuentas de usuario con su propio código, el proceso actual deberá poder realizar
una llamada a LogonUser, lo que en Windows 2000 requiere que la cuenta de usuario de proceso tenga
privilegios "que actúen como parte del sistema operativo". Se trata de un privilegio muy fuerte y plantea
un gran riesgo si el proceso se ve en peligro. No se recomienda que utilice este privilegio para las
identidades de las aplicaciones basadas en ASP.NET o Enterprise Services, excepto en casos excepcionales.
Mecanismos de autenticación personalizada
Puede que necesite un mecanismo de autenticación personalizada en su aplicación si ha comprobado que

no puede aprovechar un mecanismo de autenticación proporcionado por la plataforma o por terceros. El
uso de un mecanismo de autenticación personalizada implica poder almacenar cuentas de usuario, así

como tener un algoritmo para comprobar si el sistema autentica las credenciales que se proporcionan.
Cuando implemente su propia autenticación de usuario, tenga en cuenta las siguientes directrices
generales:
• Implemente la autenticación de usuario en un objeto Identity personalizado. Deberá disponer de un

constructor que tome las credenciales de usuario y establezca el indicador interno de
IIdentity.IsAuthenticated según el resultado. También puede tener un constructor que tome un
símbolo de autenticación.
• No almacene las contraseñas de usuario. En su lugar, almacene un hash de las credenciales del
usuario junto con los valores salt en la base de datos. Cuando autentique, aplique el mismo algoritmo
a las credenciales que proporciona el usuario. Si la cadena resultante coincide con la que ha
almacenado en la base de datos, el usuario habrá suministrado las credenciales correctas.
• Realice una auditoria de los intentos de autenticación que han producido errores.
• Agregue un atributo StrongNameIdentityPermission a los métodos cuando desee asegurarse de que

únicamente los ensamblados de la aplicación puedan crear e invocar su objeto de identidad.
• Exponga el símbolo de autenticación como propiedad del objeto Identity. El símbolo de autenticación
debe ser un hash que incluya el nombre de usuario y otros datos. Incluya datos de origen (como, por
ejemplo, el nombre del equipo o el ensamblado de llamada) si desea impedir que el símbolo se utilice
en otro lugar. Para limitar la validez del símbolo a un cierto límite de tiempo, puede agregar una
marca de hora al valor en hash. La complejidad del valor hash y del cifrado dependerá del grado de
riesgo que tenga el símbolo.
Autenticación en la capa de presentación
Los componentes de la interfaz de usuario deben autenticar al usuario si la aplicación necesita realizar la
autorización, auditoría o personalización. Existe una amplia gama de mecanismos de autenticación
disponibles para las interfaces de usuario basadas en Web. Para elegir la más adecuada a su escenario,
consulte "Autenticación en ASP.NET: Directrices de seguridad para .NET" en MSDN
(http://www.microsoft.com/spain/msdn/articulos/archivo/261001/voices/authaspdotnet.asp). Las
aplicaciones basadas en ASP.NET establecen el principal actual en el evento OnAuthenticate de
Global.asax.
Las interfaces de usuario basadas en Windows generalmente confían en un mecanismo de autenticación

personalizado (en el que la aplicación solicita un nombre de usuario y una contraseña), o bien autentican
al usuario con el inicio de sesión de Windows. Si utiliza un mecanismo de autenticación personalizado,
deberá implementar su propia interfaz de usuario para permitir al usuario iniciar sesión, así como
establecer el Principal correcto en el subproceso principal y en cualquier subproceso que cree la aplicación.
Los componentes del proceso de usuario no realizan autenticación; confían en el contexto de seguridad
que se establece al inicio de la aplicación, tal como se ha descrito anteriormente (por ejemplo, en el
evento OnAuthenticate de una aplicación basada en ASP.NET).

Los componentes de proceso de usuarios se deben ejecutar en el mismo contexto de usuario que la propia
interfaz de usuario, de forma que todas las tareas de autenticación se deleguen a la interfaz de usuario o
incluso a la infraestructura de procesamiento. Por ejemplo, en ASP.NET cualquier solicitud de una página
ASPX provoca que IIS solicite las credenciales de autenticación, o bien que ASP.NET redirija al usuario a
una página de autenticación basada en formularios. Esta operación se realiza con transparencia en
cualquier capa de proceso de usuario y no interrumpe el flujo de estado, ni siquiera cuando caduca y se
debe volver a establecer una sesión autenticada.
Autenticación en los componentes empresariales
Los componentes empresariales deben autenticar al llamador o delegar la autenticación a una interfaz de
servicios. El llamador puede ser de distintos tipos, por ejemplo:
• Un componente de interfaz de usuario.
• Un componente de proceso de usuario.
• Un flujo de trabajo empresarial (por ejemplo, una programación XLANG de Microsoft BizTalk
Server®).
• Otro componente de proceso empresarial.
La identidad del llamador puede ser:
• Un usuario particular.
• Una cuenta de servicio que represente la identidad en tiempo de ejecución de una determinada parte
de la aplicación o de un sistema externo. Por ejemplo, podría autenticar una llamada que provenga
del nivel de IU Web.
• Un socio externo para el que tiene una "cuenta de servicio" especial.
Si los componentes empresariales autentican a los llamadores, deberá considerar cómo se pueden
autenticar las tres identidades de llamadores anteriores y de qué modo afectan a la autorización.
Autenticación en los componentes de acceso a datos
Los componentes de acceso a datos están diseñados para que los utilicen otros componentes de la
aplicación o servicio. Generalmente, no están ideados para la exposición para las llamadas desde
secuencias de comandos o desde otras aplicaciones, de modo que puede diseñarlos para que se basen en
el contexto de seguridad establecido por el llamador (el objeto Principal del subproceso) o en el
mecanismo de autenticación de la estrategia remota.
Los componentes de acceso a datos pueden autenticar con la base de datos de dos formas principales:
• Mediante el uso de cuentas de servicios.
• Representando al llamador.

En este caso, utiliza una cuenta de servicios, o un conjunto limitado de ellas, que representa funciones o
el tipo de usuario. En la mayor parte de los casos, será únicamente una cuenta de servicios, aunque
puede utilizar más si necesita un control más estricto en la autorización. Por ejemplo, en la aplicación de
procesamiento de pedidos puede tener acceso a la base de datos como "TheOrderApplication", o bien
iniciar sesión de forma selectiva como "OrderProcessingManager" u "OrderProcessingClerk" de acuerdo
con la función de la identidad del llamador.
Utilice cuentas de servicios si:
• Se conecta al origen de datos subyacente de un entorno en el que la representación del llamador

inicial no esté disponible (por ejemplo, BizTalk Server).
• Dispone de un control de cambios muy limitado sobre las cuentas que pueden iniciar sesión en el otro
sistema (por ejemplo, conectarse a un sistema de administración de bases de datos relacionales, que
administra estrictamente el administrador de la base de datos).
• El almacén de datos al que tiene acceso dispone de un mecanismo de autenticación diferente al del
resto de la aplicación (por ejemplo, inicia sesión en un servicio Web a través de Internet).
• El acceso al almacén de datos a través de un gran número de cuentas niega la agrupación de

conexiones y, por lo tanto, reduce el rendimiento y la escalabilidad.
No utilice cuentas de servicios si:
• No dispone de una forma segura de almacenar y mantener las credenciales del servicio.
• Necesita tener acceso al almacén de datos con recursos del usuario específicos debido a las directivas
de seguridad (por ejemplo, si necesita tener acceso a los datos u objetos en Microsoft SQL Server™
en nombre de los usuarios).
• El almacén de datos realiza la auditoria de actividades y estas auditorias se deben asignar a usuarios
individuales.
Estará representando al llamador cuando tenga acceso a un almacén de datos con un conjunto de cuentas
que se asignan una a una con la base de usuarios de la aplicación. Por ejemplo, si "Juan" inicia sesión en
la aplicación y los componentes de acceso a datos tienen acceso a una base de datos, estará
representando a Juan si inicia sesión en esta base de datos con las credenciales de Juan.
Necesita la representación del llamador si:
• El almacén de datos realiza la autorización basada en el usuario con sesión iniciada.
• El almacén de datos necesita realizar la auditoría de las actividades de cada usuario final individual.
Se utilizan normalmente dos mecanismos de implementación para representar a los llamadores:
• Servicios de representación de plataforma. Windows 2000 y versiones posteriores ofrecen la

representación de usuario mediante Kerberos a través de la red. Esto significa que si Juan tiene

acceso a su aplicación Web, y usted ha utilizado la autenticación de Windows, podrá representar a

Juan a través de la red hasta su base de datos.
La representación generalmente sólo se admite si dispone del mismo mecanismo de autenticación a

través de toda la red o un mecanismo de autenticación estándar compatible (como, por ejemplo,
Kerberos).
En Windows 2000, el nivel de representación proporcionado por la plataforma a través de varios

saltos de red se denomina delegación. Para poder delegar el contexto de seguridad, el dominio,
equipo y cuenta de usuario deben estar habilitados para la delegación. Windows .NET Server
proporciona delegación de restricción, que agrega una mayor flexibilidad de administración.
• Soluciones de servidor de inicio de sesión único. Los mecanismos de servidor de inicio de sesión único
le proporcionarán las credenciales (por ejemplo, nombre de usuario y contraseña) de un usuario para
iniciar sesión en un origen de datos cuando les proporciona pruebas de que ha autenticado a ese
usuario mediante otro mecanismo. Este tipo de enfoque es una forma de "representación débil", ya
que requiere una asignación que generalmente no puede propagar más de un salto lógico.
Para obtener directrices generales sobre la conexión a SQL Server desde las aplicaciones distribuidas,
consulte ".NET Data Access Architecture Guide" en MSDN
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/daag.asp) (en inglés).
Nota Las consideraciones para la implementación de autenticación en los agentes de servicios son
similares a las relacionadas con los componentes de acceso a datos anteriormente descritas.
Autenticación en los componentes de entidad empresarial
Los componentes de entidad empresarial se ofrecen a menudo para el desarrollo personalizado como un
SDK o un modelo de objeto para la aplicación para su utilización desde una secuencia de comandos o
desde el sistema de desarrollo de Microsoft Visual Basic® en los clientes.
Si no hay otros componentes de la aplicación o secuencias de comandos personalizadas que vayan a

utilizar sus entidades empresariales, éstas no necesitan presentar un límite de autenticación. En este caso,
se deben basar en el contexto de seguridad actual (el objeto Principal conectado al subproceso actual)
para la autenticación.
Si está pensando en exponer las entidades empresariales para permitir la secuencia de comandos
personalizada o el consumo desde otras aplicaciones, puede que deba proporcionar un componente
adicional que ayude al cliente a "iniciar sesión" desde el código y establecer el contexto de seguridad que
requieren estos objetos si no se basa en la autenticación de plataforma. No debe diseñar entidades
empresariales que se basen en la posesión de un contexto de seguridad de Windows para un usuario
humano determinado si las entidades empresariales se invocarán por mecanismos que no son de
representación (por ejemplo, un proceso empresarial que se inicia asincrónicamente).
Autorización

El aspecto de la autorización de la directiva de seguridad se ocupa de la identificación de las acciones

permitidas para cada principal de seguridad autenticado. En otras palabras, la directiva de seguridad
determina quién puede hacer qué. Para determinar la directiva de autorización, deberá tener en cuenta
dos factores principales:
• Los permisos y derechos de usuario.
• La seguridad de acceso al código.
Los permisos y derechos de usuario determinan lo que se permite hacer en una cuenta de usuario en el
contexto de la aplicación. Técnicamente, el término "permisos" se refiere a las acciones permitidas en un
recurso (como por ejemplo, un archivo o una tabla de base de datos), mientras que los "derechos" hacen
referencia a las tareas del sistema que se permite realizar al usuario (como por ejemplo, configurar la
hora del sistema o apagar el equipo). Los permisos y derechos de usuario se pueden asignar de forma
individual para cada usuario, si bien resultan más fáciles de administrar cuando los usuarios se organizan
de una manera lógica en grupos o funciones. La mayor parte de los recursos tienen algún tipo de lista de
permisos relacionada, en la que se indican los permisos asignados a los usuarios para ese determinado
recurso. Por ejemplo, en el entorno de Windows, los recursos se aseguran mediante el uso de una lista de
control de acceso (ACL), que muestra los permisos asignados a los principales de seguridad en el recurso,
así como cuáles son esos permisos. Los permisos son generalmente acumulativos, por lo que un usuario
que tiene permiso de "lectura" en un archivo y que se encuentra en un grupo que tiene permiso de
"modificación" en ese mismo archivo, tendrá un permiso de red de "modificación". La excepción a esta
regla ocurre cuando se asigna un permiso de "denegación". Si a un usuario, o a cualquiera de los grupos
de los que este usuario es miembro, se le deniega explícitamente el acceso a un recurso, no podrá tener
acceso a dicho recurso, independientemente de los permisos que se hayan asignado a cualquier otro
usuario o grupo.
La seguridad de acceso al código, que presentó por primera vez .NET, ofrece a los desarrolladores y
administradores una dimensión adicional de control de acceso, así como la posibilidad de comprobar de
nuevo la configuración de seguridad correcta. A diferencia de los permisos y derechos de usuario, la
seguridad de acceso al código se ocupa de lo que puede hacer un ensamblado. Por ejemplo, un
ensamblado de .NET se podría configurar de tal modo que el código no pueda tener acceso a los recursos
del sistema de archivos y cualquier código que intente hacerlo desencadenará una excepción de infracción
de acceso. Puede establecer zonas de confianza que apliquen directivas de seguridad de acceso al código
diferentes de acuerdo con una serie de factores.
Debe incluir los resultados en la siguiente matriz en el diseño de control de acceso:
Seguridad de acceso de usuario

La seguridad de acceso de usuario se utiliza para determinar lo que puede hacer la identidad actual. Se
puede comprobar lo que puede hacer un llamador mediante numerosos mecanismos. En aplicaciones con
una interfaz de usuario, puede que la lógica empresarial represente al llamador, pero en la mayor parte de
los servidores y especialmente en los servicios sin interfaces de usuario, el código generalmente utilizará
una cuenta de "servicios" determinada.
En lugar de utilizar la cuenta en la que el proceso actual se está ejecutando, puede establecer su propia
identidad de manera manual en un subproceso que se esté ejecutando si modifica el objeto Principal.
Lo que el usuario puede hacer al entorno y a la plataforma se controla normalmente mediante las ACL,
que se contrastan con la identidad de Windows del proceso o subproceso actual. Los recursos que
generalmente se contrastan con la identidad de Windows son archivos NTFS, API del sistema,
componentes (COM+) de .NET Enterprise Services y servicios configurados para la autenticación de
Windows.
Windows proporciona una gran variedad de características de grupo, derechos de usuario y administración
de seguridad. Ciertos servicios pueden implementar su propia abstracción sobre estas características como,
por ejemplo, la autorización basada en funciones en Enterprise Services. Por ejemplo, Enterprise Services
realiza la autorización en relación a funciones, donde cada función es en realidad una ACL.
.NET proporciona un marco amplio y extensible para la administración de la seguridad de acceso de

usuario, incluidas identidades, permisos y la noción de un principal y funciones.
Para asegurarse de que los usuarios en una determinada función llaman a un método específico,
establezca un atributo en el método de clase, como se muestra en el siguiente código.
[PrincipalPermission(SecurityAction.Demand, role="Managers")]
public void PlaceOrder(DataSet Order)
// Este código no se ejecutará si el principal conectado
// al subproceso devuelve falso cuando se invoca a IsInRole
// con "Managers" como argumento
Para obtener más información, consulte "Constructor PrincipalPermissionAttribute" en .NET Framework

SDK en MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-

us/cpref/html/frlrfsystemsecuritypermissionsprincipalpermissionattributeclassctortopic.asp?frame=true)
(en inglés).
Si su componente se basa en la implementación en Enterprise Services y autentica a los usuarios a través

de Windows, puede utilizar la administración de funciones de Enterprise Services tal como se muestra en
el siguiente código.
[SecurityRole("HelpDesk")]
public DataSet GetCancelledOrders(System.Guid CustomerID)
{ //… }
Si tiene acceso a los componentes de forma remota, el uso de la administración de funciones de

Enterprise Services requiere que este acceso se realice a través del canal DCOM-RPC.
Seguridad de acceso al código
La seguridad de acceso al código se ocupa de lo que el ensamblado puede realizar, si bien también puede
decidir personalmente si el código se ejecuta o no, dependiendo del código que intente tener acceso a él.
Por ejemplo, esto evita que sus objetos puedan ser llamados desde secuencias de comandos que alguien
con suficientes privilegios pueda ejecutar sin su conocimiento. Tenga en cuenta que la directiva de
seguridad de acceso al código no funcionará a través de .NET Remoting: todas las comprobaciones se
realizarán cuando se invoque desde el mismo dominio de la aplicación.
Puede comprobar el acceso al código según los siguientes factores:
• El directorio de instalación de la aplicación.
• El hash criptográfico del ensamblado.
• La firma digital del publicador del ensamblado.
• El sitio desde el cual se origina el ensamblado.
• El nombre seguro criptográfico del ensamblado.
• La dirección URL desde la que se origina el ensamblado.
• La zona desde la que se origina el ensamblado.
Las directivas de seguridad se pueden aplicar para la empresa, el equipo, el usuario y la aplicación. Las
zonas definidas por .NET son: Internet, intranet, Mi PC, NoZone, segura y no segura. Si desea obtener
más información sobre estos elementos, consulte los siguientes artículos en MSDN Library:

• "Code Access Security" (http://msdn.microsoft.com/library/default.asp?url=/library/en-

us/cpguide/html/cpconcodeaccesssecurity.asp) (en inglés)
• "Introduction to Code Access Security"

us/cpguide/html/cpconintroductiontocodeaccesssecurity.asp) (en inglés)
• "SecurityZone Enumeration" (http://msdn.microsoft.com/library/default.asp?url=/library/en-

us/cpref/html/frlrfsystemsecuritysecurityzoneclasstopic.asp) (en inglés)
Implementación de comprobaciones de autorización complejas
En ciertos casos, la aplicación deberá realizar comprobaciones de autorización complejas. Por ejemplo,
considere el siguiente conjunto de condiciones: "Permitir que se realice este pedido si el llamador se
encuentra en la función de Vendedor, o si se trata de un servicio que llama desde un socio y el pedido no
sobrepasa 1000 dólares, o bien si el llamador tiene una función de Administrador o superior". Esta
directiva de autorización requiere unas combinaciones de permisos mediante AND, OR, y "menor que" y
"mayor que", además del conocimiento del precio del pedido que se realiza. Estos tipos de
comprobaciones de autorización se realizan mejor en el código de su propia aplicación como
comprobaciones mediante programación y requieren un desarrollo considerable para separarlas como
reglas puras. En otros escenarios más sencillos, puede implementar la lógica de la autorización de forma
declarativa mediante el uso de atributos o parámetros de configuración.
Diseño de esquemas de autorización de nivel de aplicación personalizados
Disponer de un esquema de autorización personalizado constituye un requisito habitual cuando un

subconjunto de la autorización de la aplicación la administran los usuarios y no los operadores, y los datos
de la autorización se almacenan en su base de datos o en otro almacén externo. En estos casos, su
aplicación generalmente proporcionará una interfaz de usuario para la administración de seguridad y un
esquema de base de datos para administrar la pertenencia a funciones. Cuando desarrolle esta clase de
marco, tenga en cuenta las siguientes directrices:
• Exponga toda la lógica de autorización a través de un objeto principal. Su principal se creará con una
identidad particular como argumento de constructor. Compruebe la propiedad IsAuthenticated de la
identidad y utilice el nombre de su identidad para ubicar los datos de autorización correctos. Exponer
la lógica de autorización a través de la función IsInRole permite a la aplicación utilizar atributos de
PrincipalPermission, al tiempo que ofrece un modelo de desarrollo coherente que le permitirá utilizar
otros esquemas de autenticación y autorización en el futuro. Para obtener un ejemplo de este uso,
consulte "Creating WindowsIdentity and WindowsPrincipals Objects" en MSDN
us/cpguide/html/cpconcreatingwindowsidentitywindowsprincipalobjects.asp?frame=true) (en inglés).
• Autentique la comunicación con el almacén de datos de autorización. Asegúrese de que el almacén de

datos de autorización no se vea afectado y de que únicamente las cuentas apropiadas pueden leer y
escribir estos datos. Su aplicación debe tener acceso a este almacén con una cuenta de sólo lectura y

únicamente las partes de la aplicación que modifican estos datos deben tener acceso de lectura y
escritura.
• Cuando no utilice la autenticación de Windows, separe las credenciales de usuario y los

identificadores de autenticación del esquema de datos de autorización. Sus datos de autorización
deben hacer referencia internamente a los usuarios mediante un Id. privado. Esto le permite
modificar los esquemas de autenticación en el futuro, al tiempo que permite que las reglas de
autorización se utilicen desde aplicaciones con distintos mecanismos de autenticación y que los
usuarios puedan modificar sus Id. de usuario.
• Almacene en caché para el rendimiento. Puede elegir almacenar en caché la información de

autorización (por ejemplo, la pertenencia a funciones) en el objeto principal en lugar de tener acceso
al almacén en cada ocasión. Si almacena en caché los datos de autorización, deberá firmar o utilizar
un hash para asegurarse de que no han sido alterados.
• Proporcione capacidades sin conexión para los clientes desconectados. Esto puede implicar la
incrustación de la lógica de autorización con el propio cliente o el almacenamiento en caché local de
una copia firmada digitalmente.
• Diseñe la lógica del almacén de datos de autorización para que sea acoplable. Esto le permitirá elegir
distintas ubicaciones y productos sin modificar el diseño del marco.
• Establezca el acceso al código llamando a los atributos de ensamblado mediante un atributo

StrongNameIdentityPermission si desea asegurarse de que únicamente los ensamblados de la
aplicación pueden crear e invocar su objeto principal.
Nota Windows .NET Server proporciona nuevas características que ayudan a simplificar la
implementación de la funcionalidad de autorización personalizada.
Usuarios, funciones y aplicaciones y servicios de confianza
Las aplicaciones y servicios que interactúan generalmente tienen cuentas de usuario y definiciones de
funciones independientes, a menos que se implementen en una organización en la que los usuarios y
grupos se puedan definir para toda la organización. Incluso en este caso, no debe confiar en la definición
de funciones y usuarios de otro servicio, sino en las definiciones de funciones y usuarios de su
organización y en las definidas para su servicio.
Cuando controle servicios que interactúan, se recomienda que autentique y autorice a los llamadores con
una granularidad que abarque todo el servicio. Por ejemplo, su servicio puede interactuar con otros
servicios en organizaciones de socios, en cuyo caso resultará útil definir funciones como, por ejemplo,
"Standard Partner" y "Premier Partner". El uso de funciones para realizar la autorización de servicios
externos y socios permitirá a su aplicación crecer y funcionar con numerosos socios en el futuro sin
afectar al código o diseño.
Si su servicio comparte cuentas de usuario con servicios de llamada y requiere realizar la autorización en
la granularidad de usuario, la información de usuario se debe incluir como parte de los datos
empresariales intercambiados. Si necesita asegurarse de que un determinado usuario ha enviado los datos

empresariales, deberá incluir un símbolo de autenticación o firmar el documento para mostrar que provino
del usuario o de un servicio en el que confía.
Establecimiento del contexto de seguridad en los límites del sistema
Un principal personalizado en un determinado subproceso no establece un flujo a través de los procesos o

los canales remotos, por lo que normalmente deberá establecer personalmente el sistema de seguridad en
los límites del sistema.
Para establecer un principal personalizado en el subproceso actual deberá:
1. Crear el objeto Identity adecuado, pasando las credenciales, el símbolo de usuario o el Id. de usuario
(u otro tipo de identificador) al constructor. Si dispone de una implementación personalizada del
objeto Identity, deberá mantener un indicador interno que muestre si la identidad se ha autenticado.
2. Crear su objeto principal, pasando la instancia de identidad como un argumento para el constructor.
El objeto principal deberá conservar este objeto Identity para poder devolverlo cuando se llame a
Iprincipal:Identity.
Los principales de Windows establecen un flujo con interacción remota si utiliza DCOM-RPC como canal
remoto.
Si desea obtener más información sobre los objetos Principal e Identity de .NET y ejemplos de código que
muestren este patrón para principales personalizados y de Windows, consulte "Principal and Identity
Objects" en MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/cpguide/html/cpconprincipalidentityobjects.asp?frame=true) (en inglés).
Autorización en componentes de interfaz de usuario
Los componentes de interfaz de usuario muestran los datos a los usuarios y reciben datos de ellos.
Ejecute la autorización en este nivel si necesita:
• Ocultar o mostrar determinados campos de datos al usuario.
• Habilitar o deshabilitar controles para la intervención del usuario.
Si el usuario no debe ver una determinada información, la opción más segura consiste en no pasar esa
información a los componentes de la presentación en primer lugar.
Lo normal es realizar algún nivel de representación de la interfaz de usuario raíz o menú para que el
usuario sólo pueda ver los elementos Web, las entradas de menú o los paneles sobre los que pueda actuar
según las funciones que tengan.

Normalmente un archivo .exe de interfaz de usuario inicia la aplicación. Debe establecer permisos de
acceso al código en los ensamblados de la interfaz de usuario si no desea que ésta (o los componentes
locales a los que llama) tenga acceso a recursos importantes como, por ejemplo, archivos.
Deberá considerar el contexto de seguridad en el que se ejecutarán los componentes de presentación de

la aplicación y comprobarlos en un entorno adecuadamente restringido.
Autorización en componentes de proceso de usuario
Los componentes de proceso de usuario administran datos y controlan el flujo entre los procesos de
usuario. Deberá ejecutar la autorización en este nivel si necesita:
• Controlar si un usuario puede iniciar un proceso de interacción de interfaz de usuario.
• Agregar y eliminar "pasos" o componentes de interfaz de usuario completos en un flujo de interacción

de usuario según quién lo ejecute. Por ejemplo, un vendedor podría ver datos únicamente de su
región, por lo que no sería necesario mostrarle un paso del asistente en el que tenga que elegir la
región de un informe de ventas.
Lo ideal sería que el cuadro de diálogo principal fuera activo y ocultara o deshabilitara los elementos de la
interfaz de usuario necesarios para iniciar un cuadro de diálogo que un usuario no está autorizado a
utilizar. Si el cuadro de diálogo principal es el cuadro de diálogo "raíz", esto implicaría ocultar de forma
activa las entradas de menú apropiadas, los elementos Web de escritorios digitales, etc.
Puede establecer la autorización de forma declarativa para los procesos de usuario si agrega atributos
PrincipalPermission a las clases o métodos que los implementan.
Los componentes de proceso de usuario normalmente sólo se emplean desde los componentes de interfaz
de usuario. Puede utilizar la seguridad de acceso al código para restringir quién los llama. Asimismo,
puede utilizar la seguridad de acceso al código para restringir la forma en que los componentes de proceso
de usuario interactúan entre sí. Este enfoque resulta de especial relevancia en los escenarios de portales
en los que es fundamental que un proceso de usuario que se implementa como complemento no pueda
obtener información para la que no está autorizado desde los procesos y elementos de otro usuario.
Autorización en componentes empresariales
Tenga en cuenta las siguientes recomendaciones para la autorización en componentes empresariales:
• Procure que la autorización de procesos empresariales sea independiente del contexto de usuario,
especialmente si va a utilizar numerosos mecanismos de comunicación como colas y servicios Web,
que impedirán que el proceso represente al llamador.
• Utilice seguridad basada en funciones siempre que sea posible en lugar de confiar en cuentas de
usuario. Esto proporciona una mejor escalabilidad, facilita la administración y evita problemas con los
nombres de usuario que admiten numerosas representaciones canónicas. Puede definir funciones
para los componentes facilitados como servicios en una aplicación basada en Enterprise Services, o

bien, utilizar grupos de Windows o funciones personalizadas para los componentes .NET que no se
ejecutan en Enterprise Services.
• Si decora un método con el atributo PrincipalPermission, compruebe siempre el tipo de autenticación

especificado por el objeto Identity. El objeto PrincipalPermissionAttribute de .NET asegura que su
principal es una función, pero no especifica un mecanismo de autenticación.
Autorización en agentes e interfaces de servicios
Los agentes de servicios son la puerta de enlace a través de la cual se realizan las llamadas a los servicios
externos, así que debe agregar funcionalidad de autorización para estos componentes siempre que desee
evitar que determinados usuarios o funciones tengan acceso a ellos. Tenga en cuenta que el servicio
externo también puede implementar sus propias comprobaciones de autorización adicionales.
Puede implementar autorización en componentes de la interfaz de servicio mediante el uso de la

autenticación de IIS y ASP.NET para los servicios Web, o bien a través de las ACL de Windows si la
interfaz de servicio se expone a través de Microsoft Message Queue Server.
Autorización en componentes de acceso a datos
Los componentes de acceso a datos son los últimos componentes que exponen la funcionalidad
empresarial antes de los datos de la aplicación, por lo que deben realizar todas las comprobaciones de
autorización minuciosas que sean necesarias. Ejecute la autorización en este nivel si necesita:
• Compartir componentes de acceso a datos con desarrolladores de procesos empresariales en los que
no confíe plenamente.
• Proteger el acceso a las funciones importantes expuestas por los almacenes de datos.
Debido a que los componentes de acceso a datos exponen una interfaz minuciosa en los sistemas
subyacentes, la seguridad sólo se puede administrar en un nivel detallado y no tiene en cuenta la
agregación necesaria para una determinada operación de proceso empresarial. De este modo, si
implementa comprobaciones de autorización en este nivel, la concesión o denegación de permisos para
ejecutar un proceso empresarial de alto nivel en una identidad puede implicar también la modificación de
los permisos para los componentes de acceso a datos.
Para realizar la autorización, puede basarse en las funciones de Enterprise Services y en los atributos
PrincipalPermission de .NET si utiliza la autenticación de Windows, o bien en las funciones y atributos
de .NET si no se basa en un contexto de seguridad de Windows.
Si establece un flujo del mismo contexto de usuario a su almacén de datos, puede utilizar la funcionalidad
de autorización de la base de datos (por ejemplo, para otorgar o revocar el acceso a los procedimientos
almacenados). Esto se podrá realizar únicamente si:
• Utiliza un conjunto de cuentas de servicio para tener acceso a la base de datos que representa
distintas combinaciones de funciones.

• Representa a los llamadores hasta su base de datos.
Nota El flujo de contextos de usuarios representados hasta la base de datos afecta al rendimiento y
escalabilidad debido a que las conexiones están agrupadas por usuario. Por otra parte, los procesos
empresariales que se inician asincrónicamente no representarán automáticamente al usuario de origen y,
por tanto, no estará disponible un principal de Windows (a menos que tenga acceso al nombre y
contraseña del usuario, que en la mayor parte de los diseños sería menos seguro y nada deseable).
Como los componentes de acceso a datos generalmente sólo se llaman por otros componentes de la
aplicación, resultan ideales para restringir los llamadores al conjunto de ensamblados necesario:
normalmente, una combinación de ensamblados con componentes de la capa de interfaz de usuario,
componentes de procesos empresariales y entidades empresariales (si existen).
Autorización en componentes de entidad empresarial
Los componentes de entidad empresarial pueden exigir reglas de autorización de acuerdo con el contexto
de seguridad del llamador (tanto para los usuarios como para las cuentas de servicios). Por ejemplo,
puede asegurarse de que los usuarios en una función determinada no tienen acceso a la información
privada de un objeto Cliente. Para implementar esta funcionalidad, deberá:
• Asegurarse de que los contextos de seguridad son coherentes en todos los niveles físicos de la
aplicación; distintos niveles físicos que utilizan entidades empresariales deben tener objetos Principal
equivalentes en el contexto de ejecución.
• Realizar las comprobaciones adecuadas a través de los atributos PrincipalPermission y las llamadas
PrincipalPermision.Demand en las llamadas a entidades empresariales.
Puede exigir la autorización en los componentes de entidad empresarial para comprobaciones activas,
pero la comprobación final la deben realizar los componentes del proceso empresarial y los de acceso a
datos allí donde tiene lugar la operación. Tenga en cuenta que disponer de dos ubicaciones que exigen
autorización sobre una funcionalidad relacionada puede implicar un mayor mantenimiento a fin de
conservar las directivas de autorización sincronizadas.
Puede que desee restringir el acceso a los componentes de entidad empresarial desde el ámbito del
acceso al código. De este modo, le permite asegurarse de que sólo el código de confianza invocará las
entidades empresariales. Puede decidirse por esta opción para evitar que usuarios avanzados escriban
secuencias de comandos personalizadas en estos objetos a fin de obtener acceso a información no
autorizada.
Comunicación segura
Además de autenticar usuarios y autorizar solicitudes, debe asegurarse de que la comunicación entre los
niveles de la aplicación es segura a fin de evitar ataques en los que los datos se "sondeen" o alteren
mientras se transmiten o se almacenan en una cola.

Las comunicaciones seguras implican proteger las transferencias de datos entre componentes y servicios
remotos.
La comunicación segura no implica el uso de un mecanismo de autorización, pero se puede asociar al

empleo de un mecanismo de autorización unidireccional o bidireccional que se asegura de que los
extremos de la comunicación son quienes afirman ser.
Dispone de las siguientes opciones para comunicaciones seguras:
• Asegurar todo el canal:
• Secure Sockets Layer (SSL). Esta es la opción recomendada para los canales HTTP, se trata de
un estándar ampliamente aceptado y generalmente se acepta para abrir puertos SSL en los
servidores de seguridad. Esta opción se recomienda cuando se expone una interfaz de servicio en
Web.
• IPSec. Este mecanismo resulta una buena elección cuando ambos extremos de la comunicación
son conocidos y están bajo su control. IPSec se utiliza principalmente cuando se realizan
llamadas entre servicios o niveles de aplicación físicos dentro de un centro de datos o entre
centros de datos de la misma organización.
• El canal remoto personalizado realiza el cifrado. Este enfoque no se recomienda normalmente. La

programación de comunicaciones seguras resulta una tarea compleja que requiere unos
profundos conocimientos sobre seguridad y numerosas comprobaciones.
• Redes privadas virtuales (VPN). Una red virtual le permite establecer un transporte IP punto a
punto en Internet (u otras redes). Resulta idónea para proporcionar a un conjunto de empleados
o socios acceso a una red interna desde Internet. La implementación de VPN requiere una gran
compatibilidad de la infraestructura.
• Asegurar los datos:
• Firmar un mensaje. Esto permite reconocer si el mensaje ha sido alterado. Las firmas se pueden
utilizar para la autenticación en el mismo proceso.
• Cifrar el mensaje completo. Esto hace que todo el mensaje resulte ilegible si los paquetes de red
se ven afectados. Cifrar un mensaje con los algoritmos adecuados también permite reconocer si
se ha alterado.
• Cifrar las partes confidenciales del mensaje. Utilice esta opción sólo cuando una pequeña parte
del mensaje no se pueda exponer.
La firma digital generalmente implica calcular un valor hash de la parte firmada del mensaje, cifrar el hash
con la clave privada del firmante e incluir el hash cifrado en el encabezado. El receptor descifra la firma
recibida con el mensaje utilizando la clave pública del firmante y compara el hash resultante con el que
calcula de las partes firmadas del mensaje. Si los valores hash coinciden, significa que el mensaje no se
ha alterado. Si no coinciden, el mensaje se ha dañado, con lo que deberá realizar una auditoria del
mensaje con el error y la información del llamador y devolver una excepción.

Nota Los mensajes con firma digital y hash se pueden seguir utilizando en un ataque repetitivo, en el
que el mismo mensaje se envía repetidamente al servidor. Puede que necesite generar una lógica de
reducción de riesgos adicional en la capa de mensajería para hacer frente a este tipo de ataques. Por
ejemplo, puede agregar una marca de hora al cuerpo del mensaje o diseñar el proceso de forma que los
mensajes sean idempotentes.
Por ejemplo, con los servicios Web XML, puede implementar firmas digitales XML en SOAP si utiliza la
clase SignedXml y los encabezados SOAP. Para obtener más información sobre la clase SignedXml,
consulte "SignedXml Class" en MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/cpref/html/frlrfSystemSecurityCryptographyXmlSignedXmlClassTopic.asp) (en inglés). Si desea obtener
más información sobre los encabezados SOAP, consulte "Using SOAP Headers" en MSDN
us/cpguide/html/cpconusingsoapheaders.asp?frame=true) (en inglés).
La protección del canal de comunicación afectará al rendimiento, así que siempre que evalúe las técnicas
anteriormente descritas, deberá limitar la seguridad del canal a las áreas específicas que la requieran
como, por ejemplo, asegurar los URI de servicios Web específicos, determinadas páginas ASP.NET o las
partes confidenciales de los datos empresariales. Los distintos mecanismos tendrán implicaciones de
rendimiento diferentes según los datos que la aplicación intercambie, el número de extremos y el tipo de
seguridad necesaria.
Para obtener más información sobre los canales que admiten canales de comunicación segura, consulte
"Diseño de la directiva de comunicaciones" en este capítulo.
Comunicación segura en componentes de la interfaz de usuario
Los componentes de la interfaz de usuario únicamente se comunican con el usuario. Por lo general, deberá
evitar mostrar información confidencial sin una advertencia. Las contraseñas nunca se deben mostrar o
transmitir en texto sin formato. Para las aplicaciones Web, deberá utilizar SSL siempre que se
intercambien datos confidenciales con el usuario como, por ejemplo, cuando se envíen formularios de
inicio de sesión o se muestre información financiera personal.
Los componentes de proceso de usuario normalmente residen junto con los componentes de la interfaz de
usuario, por lo que no es necesario proteger el canal entre ellos.
Comunicación segura en agentes e interfaces de servicios
Es la función del agente de servicios establecer el mecanismo de seguridad del canal adecuado entre él
mismo y el servicio invocado. Por ejemplo, si los mensajes se deben firmar o si se requiere una conexión
SSL, el agente de servicios deberá implementar esta lógica para aislar estos requisitos de los
componentes empresariales y flujos de trabajo.
Una interfaz de servicios como, por ejemplo, un servicio Web XML puede exigir unas comunicaciones
seguras y rechazar aquellas conexiones y mensajes que no cumplan los requisitos. Tanto Message Queue
Server como los servicios Web XML facilitan el establecimiento de un canal de comunicación seguro. Si

desea obtener más información, consulte "Diseño de la directiva de comunicaciones" en este mismo
capítulo.
Comunicación segura en componentes de acceso a datos
Los componentes de acceso a datos generalmente se basan en los componentes de ayuda para el acceso
a datos a la hora de realizar las conexiones con el almacén de datos. Son estos componentes los que
deben tratar cualquier clase de directiva de cifrado de la comunicación con el almacén de datos. Además,
determinados almacenes de datos pueden admitir diversos protocolos de comunicaciones (por ejemplo,
SQL Server admite canalizaciones con nombre, TCP/IP, IPX/SPX, entre otros). La directiva de
comunicaciones de la organización podría afectar a este aspecto del diseño si establece un protocolo
concreto.
Los distintos orígenes de datos admiten diferentes tipos de seguridad de comunicación o incluso pueden
no admitir ninguno de forma nativa. En ocasiones deberá proteger la comunicación con el servicio a través
de un mecanismo de seguridad proporcionado por la plataforma o estándar, como por ejemplo SSL.
Los componentes de ayuda para el acceso a datos deben administrar los parámetros de la conexión a fin
de aplicar la seguridad de comunicación. Por ejemplo, los componentes de ayuda para el acceso a datos
pueden encapsular:
• La lógica para elegir el proveedor de seguridad adecuado para SQL Server.
• La implementación de mecanismos de cifrado SOAP.
• El código para establecer una conexión a través de SSL.
Administración de perfiles
Los perfiles de usuario consisten en información sobre el usuario que puede utilizar la aplicación para
personalizar su comportamiento. Un perfil de usuario puede incluir preferencias de la interfaz de usuario
(por ejemplo, colores de fondo) y datos sobre el usuario (por ejemplo, la región en que se encuentra,
información sobre su tarjeta de crédito, etc). La información del perfil la puede exponer el objeto Principal
como una colección. Puede elegir almacenar en caché la información del perfil para las aplicaciones sin
conexión. Si la información del perfil contiene información confidencial, puede optar por cifrarla o utilizar
un valor hash para asegurarse de que no se podrá leer y de que no se ha modificado.
Auditoría
En muchos casos, necesitará implementar la funcionalidad de auditoria para realizar el seguimiento del
usuario y la actividad empresarial en la aplicación por motivos de seguridad. Para realizar la auditoria de
las actividades empresariales, necesita una ubicación de almacenamiento segura; de hecho, la auditoria
se puede considerar como un "registro seguro". Si implementa su propia solución de auditoria, se deberá
asegurar de que las entradas de auditoria no se puedan modificar o al menos permitan reconocer si han
sido alteradas (mediante el uso de firmas digitales) y de que la ubicación de almacenamiento sea segura
(por ejemplo, no se pueden modificar las cadenas de conexión o sustituir los archivos de almacenamiento).
El mecanismo de auditoria puede utilizar la firma de documentos, la autenticación de plataforma y la

seguridad de acceso al código para asegurarse de que no haya código malintencionado que registre
entradas falsas.
La interfaz de auditoria en la aplicación se puede exponer como una función de utilidad o como un método
del objeto Principal de la aplicación si la acción auditada se debe correlacionar con el usuario.
Auditoría en la interfaz de usuario y en los componentes de proceso de usuario
La actividad que ocurre en los componentes de interfaz de usuario no se suele auditar. Una aplicación de
interfaz de usuario puede demandar la auditoria de eventos generales como, por ejemplo, inicio de sesión,
cierre de sesión, cambios de la contraseña y todas las excepciones de seguridad en general.
Como los componentes de proceso de usuario representan actividades de usuario (que se pueden detener,
abandonar, etc.) no es común auditarlos. Como siempre, puede que desee auditar excepciones
relacionadas con la seguridad.
Auditoria en componentes de procesos empresariales
Los procesos empresariales son objetivos prioritarios de la auditoria. Deseará saber quién realizó las
actividades empresariales clave y cuándo tuvieron lugar dichas actividades.
Si realiza la auditoria dentro del contexto de una transacción, a un administrador de recursos

transaccional como, por ejemplo, SQL Server, deseará que el componente de auditoria inicie una nueva
transacción de modo que los errores en el árbol de la transacción original no deshagan también la entrada
de auditoria.
Auditoria en componentes de acceso a datos
Los componentes de acceso a datos constituyen la capa de lógica empresarial personalizada más cercana
al almacén de datos. Al igual que ocurría para la autorización minuciosa, la capa de los componentes de
acceso a datos es una ubicación idónea para implementar una auditoria minuciosa.
Los componentes de acceso a datos generalmente invocarán procedimientos almacenados que realmente
llevan a cabo el trabajo relacionado con los datos, por lo que puede que desee auditar también dentro de
RDBMS. Para obtener información sobre cómo implementar la auditoria en SQL Server, consulte "Auditoria
de la actividad en SQL Server" en SQL Server 2000 SDK en MSDN
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adminsql/ad_security_2ard.asp) (en
inglés).
Diseño de la directiva de administración operativa
La directiva de administración operativa se ocupa de la ejecución constante y diaria de la aplicación y

abarca aspectos como la administración de excepciones, la supervisión, la supervisión empresarial, los
metadatos, la configuración y la ubicación del servicio, tal como se muestra en la figura 3.3.

Figura 3.3. Aspectos de la directiva de administración operativa
Administración de excepciones
La administración de excepciones incluye la detección y generación de excepciones, el diseño de éstas, el

flujo de información de las mismas y la publicación de información de las excepciones a diversos usuarios.
Todas las aplicaciones deben implementar algún tipo de control de las excepciones para detectar errores
en tiempo de ejecución. Las excepciones se deben detectar y resolver si es posible. Si no se puede
resolver un estado de error, la aplicación deberá mostrar un mensaje descriptivo para el usuario y
proporcionar algún medio para el registro o publicación de la información de la excepción para la
depuración.
Nota Para obtener más información sobre el control de excepciones en aplicaciones basadas en .NET,
consulte "Exception Management in .NET" en MSDN

(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/exceptdotnet.asp) (en
inglés).
Para obtener un bloque de generación de referencia proporcionado por Microsoft para la administración de
excepciones que implementa el diseño descrito, consulte "Exception Management Application Block
for .NET" en MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/emab-
rm.asp) (en inglés).
Detección y generación de excepciones
Su código deberá detectar excepciones si puede agregar relevancia a la información de la excepción o

realizar una decisión de flujo empresarial de acuerdo con el tipo de excepción y los datos. Se recomienda
que detecte excepciones en los límites de la capa para ajustarlas a tipos de excepciones que sean
relevantes para los llamadores. Puede generar una nueva excepción, y de manera opcional conservar la
excepción detectada original como un miembro InnerException del nuevo objeto de excepción que está
generando.
Diseño de las clases de excepción
Las clases de excepción de la aplicación se deberán derivar de ApplicationException. Puede decidir generar
su propia clase de excepción que proporcione más características, como por ejemplo la disponibilidad para
agregar datos arbitrarios a la excepción. El bloque de aplicación de administración de excepciones
para .NET proporciona una clase base que puede utilizar que ofrece estas características adicionales.

Es habitual derivar a dos ramas principales de excepciones: excepciones empresariales y técnicas. Este
diseño facilita la detección y publicación del tipo de excepciones adecuado en diferentes partes de la
aplicación.
Flujo de la información de excepción
Las excepciones proporcionan un flujo de información ascendente. Las excepciones se deben poder
serializar para fluir en dirección ascendente a través de los niveles. Esto adquiere particular relevancia
cuando se alcanza una interfaz de servicios o de usuario con la que no desea establecer un flujo de la
excepción literalmente, sino más bien traducirla a algo que el llamador pueda procesar, y sin exponer
información confidencial empresarial o técnica acerca de su aplicación o servicio (como por ejemplo, una
cadena de conexión a una base de datos en caso de un error de conexión) que se pueda utilizar contra el
sistema o la organización.
Las excepciones establecerán un flujo únicamente si la comunicación es bidireccional. En el caso de

Message Queue Server y de mecanismos de comunicación unidireccionales, deberá implementar su propio
mecanismo para permitir que el llamador sepa que el mensaje ha producido un error. El cliente también
debe ser capaz de controlar los errores que impiden que los mensajes lleguen al servidor.
Publicación de la información de excepción
Si ocurre una excepción, deseará que su aplicación lo notifique a las personas adecuadas. El personal de
operaciones y soporte técnico debe conocer las excepciones técnicas y puede que los administradores y
los usuarios de la ayuda de escritorio también necesiten conocerlas. Cada tipo de audiencia necesitará
información del entorno adicional acerca de la excepción para realizar su función como, por ejemplo, los
objetos OrderIDs o los equipos origen.
Deberá publicar la información importante para cada audiencia a través de los canales que se comunican
con las herramientas que éstos utilizan. Esto significa que la aplicación puede publicar ciertos eventos de
Windows Management Instrumentation (WMI) en caso de un excepción técnica, ponerse en contacto con
un servicio Web de asistencia en caso de una excepción empresarial y registrar las excepciones en el
registro de eventos en todos los casos.
Para obtener código probado que implemente estas características, consulte "Exception Management
Application Block for .NET" en MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/dnbda/html/emab-rm.asp?frame=true) (en inglés).
Administración de excepciones en los componentes de interfaz de usuario
Los componentes de proceso de usuario deberán controlar las excepciones que provengan de los procesos
empresariales y de los componentes de acceso a datos y decidir si:
• Vuelven a intentar la operación.
• Exponen el problema al usuario.
• Detienen, reinician o continúan con el flujo de la aplicación de la interfaz de usuario.

Puede que los componentes de proceso de usuario requieran ocultar las excepciones al usuario,
dependiendo de la operación. Si es necesario mostrar la excepción, el proceso de usuario probablemente
bifurcará la ejecución del control a alguna representación visual del error y no la propagará a su llamador
(que puede ser una página ASP.NET o un formulario de Windows, por ejemplo).
ASP.NET proporciona algunas capacidades de flujo de interfaz de usuario de estado de error básicas que
podrá aprovechar en tales aplicaciones. Para obtener más información, consulte "Exception Management
in .NET" en MSDN (http://msdn.microsoft.com/library/en-us/dnbda/html/exceptdotnet.asp) (en inglés).
Los componentes de interfaz de usuario deben publicar sus excepciones para ayudar a aislar los
problemas, especialmente en aplicaciones de cliente enriquecido. Resulta habitual publicar las excepciones
en un servidor central (por ejemplo, a través de servicios Web) y en un archivo local o un registro de
eventos en el caso de aplicaciones sin conexión.
Administración de excepciones en componentes de procesos empresariales
El control de excepciones en los componentes empresariales requiere normalmente que se detecten las
excepciones y errores devueltos por los objetos empresariales y se abstraigan en una excepción que
pueda entender el que realiza la llamada. Los componentes empresariales necesitan controlar las
excepciones que provienen de los componentes de acceso a datos. Entre estos se incluyen:
• Excepciones técnicas (por ejemplo, un error en la conexión a la base de datos).
• Excepciones empresariales (por ejemplo, la infracción de una restricción de clave externa).
Los componentes empresariales no deberán ocultar estas excepciones del código de llamada y deberán
propagar las excepciones que reciben. Microsoft recomienda la propagación de las excepciones tal cual,
pero puede elegir realizar ajustes, especialmente si sólo dispone de un tipo de cliente que se pueda
beneficiar de la información de excepción de los niveles más altos.
Los componentes empresariales deberán detectar nuevas excepciones cuando:
• El llamador está intentando realizar una operación con datos insuficientes o incorrectos (por ejemplo,
una llamada al método Save en un objeto Customer para el que no se ha proporcionado el nombre).
• Se produce una infracción de restricción al realizar una operación.
Los componentes empresariales necesitan propagar todas las excepciones de componentes de acceso a
datos; por ejemplo, si:
• Hay problemas técnicos en el acceso a datos o se producen errores en los componentes de acceso a
datos del servidor. La mayoría de estas excepciones se pueden propagar sin que se tengan que volver
a realizar ajustes.
• Está utilizando un esquema de bloqueo optimista (esto es frecuente cuando las entidades
empresariales se utilizan desde las capas de interfaz del usuario) y una actualización sobrescribiría los
datos que se han actualizado desde la última lectura.

Por lo general, los componentes empresariales no deberían ocultar ninguna excepción procedente de las
capas que éstos llaman. La ocultación de excepciones podría llevar a errores a los procesos empresariales
en términos de estado transaccional y hacer creer al usuario que determinadas operaciones se han
realizado correctamente.
Las excepciones se deberán publicar en las capas empresariales, ya que es aquí donde se conoce el
resultado de una transacción y se definen los acuerdos de niveles de servicios internos.
Administración de excepciones en componentes de acceso a datos
Los componentes de acceso a datos normalmente necesitan controlar dos clases principales de
excepciones:
• Las excepciones derivadas de errores técnicos que se conectan a e invocan el almacén de datos.
• Las excepciones empresariales que se derivan de procedimientos almacenados que implementan la

lógica empresarial basada en datos.
Si las actividades en ejecución son transaccionales, todas las excepciones cancelarán la transacción actual.
Es importante que los componentes de acceso a datos consideren explícitamente la transacción actual de
Enterprise Services en caso de que algo vaya mal.
El control de excepciones en los componentes de datos requiere con frecuencia la detección de

excepciones y errores devueltos por el origen de datos subyacente (o API de acceso a datos) y su
asignación al esquema de excepciones utilizado en el resto de la aplicación. Los componentes de acceso a
datos deberían propagar excepciones, ajustándolas a los tipos de excepciones que entienden sus clientes.
Al ajustar las excepciones en dos tipos de excepciones principales (empresariales y técnicas) mejora la
estructura del control de excepciones y la lógica de publicación de las mismas para los distintos
llamadores posibles.
La funcionalidad para asignar las excepciones de orígenes de datos (por ejemplo, SqlExceptions, que
representa los errores de SQL Server producidos con RAISERROR en los procedimientos almacenados) al
esquema de excepciones de la aplicación basada en .NET se debería implementar en los componentes de
acceso a datos. El proceso de asignación puede incluir una o varias de las siguientes acciones:
• Traducción o asignación de un código de error específico del servicio o HResult a una excepción del
tipo correspondiente en .NET.
• Ajuste de una excepción .NET de bajo nivel con una excepción más importante.
• Extracción de información detallada del error a través de la API de servicios y adición de información
en los campos adecuados de la excepción que se está creando.
Nota Si la API de acceso a datos está diseñada para .NET (como lo está ADO.NET), la mayoría de esta
traducción y ajuste se realiza automáticamente, por lo que las operaciones de detección y regeneración no
resultan necesarias en los componentes de acceso a datos. ADO.NET, por ejemplo, genera una excepción
SqlException cuando SQL Server devuelve un error. Sin embargo, en la mayoría de los casos, debería

ajustar estas excepciones específicas de la API de acceso a datos en excepciones personalizadas que
tengan más relevancia en la aplicación.
Los componentes de acceso a datos deberían publicar sus excepciones escribiendo los detalles de las
mismas en un archivo de registro, enviando una alerta o publicando la excepción. Las excepciones
técnicas y empresariales se pueden publicar empleando distintos mecanismos (por ejemplo, podría enviar
alertas a los operadores a través de WMI cuando se produce un problema técnico, aunque registre
excepciones empresariales en una base de datos o registro de errores específico de la aplicación).
Administración de excepciones en componentes de entidades empresariales
Las entidades empresariales se pueden llamar desde la interfaz de usuario o los componentes de procesos
empresariales, por lo que es importante que produzca y propague excepciones que pueden emplear
ambos.
En los casos especiales en los que las entidades empresariales se exponen para el uso de los
desarrolladores de secuencias de comandos como en un SDK en un sistema de mayor tamaño, puede
elegir ajustar todas las excepciones en los tipos de excepciones más descriptivos que contengan la
excepción original como un miembro InnerException.
Supervisión
Necesita instrumentar la aplicación de forma que proporcione al personal de operaciones información

sobre el mantenimiento de la aplicación, compatibilidad con los acuerdos de nivel de servicios (SLA), así
como administración de la escalabilidad y capacidad. Para obtener instrucciones detalladas sobre la forma
de agregar instrumentación a la aplicación, consulte "Monitoring in .NET Distributed Application Design" en
MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/dnbda/html/monitordotnet.asp?frame=true) (en inglés).
Su aplicación se puede beneficiar de los siguientes tipos de supervisión:
• Supervisión del mantenimiento: ¿se ejecutan correctamente los componentes? ¿Se producen
bloqueos transitorios, cuelgues, salidas de procesos, colas bloqueadas y demás?
• Compatibilidad con SLA: ¿se ejecutan los procesos empresariales dentro de los parámetros
esperados? ¿Cumplen las expectativas esperadas los servicios que integra? ¿Cumple la aplicación o
servicio las expectativas de respuesta y rendimiento del llamador?
• Administración de la escala: ¿está correctamente diseñado el equipo, batería de servidores o red en

los que se están implementando los componentes para la tarea que deben realizar? ¿Se puede
predecir el rendimiento de los recursos disponibles?
• Supervisión empresarial: ¿puede mejorar la eficacia de los procesos empresariales? ¿Se pueden
tomar decisiones fundamentales con tiempo? ¿Cuáles son los cuellos de botella en un proceso
empresarial eficaz?

Estas diversas preguntas se pueden responder supervisando las partes adecuadas de la aplicación o
servicio. No todos los tipos de supervisión necesitan estar activos a todas horas. Por ejemplo, puede que
decida supervisar los factores empresariales antes de planear la próxima versión de la aplicación.
Supervisión empresarial
Este tipo de supervisión tiene como objetivo proporcionar una capacidad reactiva para aquellos que
dirigen la empresa en relación al mantenimiento de la empresa, compatibilidad con SLA a nivel de
empresa y administración de la capacidad organizativa. En lugar de indicarle los errores de la red, este
tipo de supervisión ofrece una perspectiva con respecto a la estructura empresarial y a la eficacia de los
procesos. Por ejemplo, puede determinar que procesos empresariales se detengan durante días cada vez
que un determinado socio forme parte del envío y control.
La supervisión empresarial es un componente de la inteligencia empresarial, pero no sustituye otras

técnicas como, por ejemplo el análisis OLAP y extracción de datos, que derivan sus datos de los procesos
ETL (extraer, transformar, cargar) de los almacenes del servicio o aplicación para informar de decisiones
activas basadas en tendencias de datos pasados. El principal factor diferenciador es que la métrica
empresarial es transitoria y puede incluso que no se refleje en los datos de las aplicaciones.
Supervisión en componentes de proceso de usuario
Los componentes de proceso de usuario pueden proporcionar interesantes estadísticas empresariales para
mejorar el diseño de la IU de la aplicación e interactuar de forma eficiente con los usuarios. Estos son
ejemplos de indicadores que se pueden obtener de componentes de procesos de usuarios:
• Duración media total para un proceso de usuario determinado.
• Si los procesos de usuario tienden a detenerse cada cierto punto, normalmente indica que la interfaz
de usuario podría proporcionar información empresarial más completa o instrucciones más claras.
• Los procesos de usuario que se han iniciado y no han terminado nunca, así como la etapa en la que
pasó al estado incompleto. Puede que sea capaz de utilizar esta información para diseñar interfaces
que permitan al usuario decidir si desean iniciar el proceso en una etapa posterior.
Supervisión en los componentes de procesos empresariales y flujos de trabajo
La supervisión del mantenimiento de los componentes empresariales y flujos de trabajo resulta

fundamental, ya que es donde se conoce en última instancia el resultado de la transacción y donde se
canalizan los problemas de compensaciones, servicios y almacén de datos. Debería instrumentar las clases
según se describe en "Monitoring in .NET Distributed Application Design" en MSDN
La mayoría de la supervisión a nivel empresarial (si no toda) se realiza normalmente en las capas
empresariales. Si las capas empresariales se implementan con Enterprise Services (COM+), puede utilizar
AppMetrics para COM+ de XTremesoft (http://www.xtremesoft.com/) (en inglés). Para la supervisión de

flujos de trabajo de BizTalk, también puede utilizar BizTalk Document Tracking. XTremesoft también
ofrece un producto denominado AppMetrics para BizTalk Server.
Para obtener más información sobre el seguimiento de documentos en BizTalk Server, consulte "Using
BizTalk Document Tracking" en MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/biztalks/htm/lat_track_docs_gsra.asp) (en inglés).
Supervisión en componentes de acceso a datos
Los componentes de acceso a datos participan en transacciones y se comunican con los componentes de
la API de acceso a datos que controla la conexión con los servicios de datos. Estos componentes son
candidatos importantes para la supervisión para realizar el seguimiento de la duración de operaciones de
datos de larga ejecución, duración del objeto, rendimiento y latencia de la actividad, uso de la memoria,
así como otros indicadores técnicos del mantenimiento.
Las cancelaciones de transacciones resultan costosas para la aplicación en general. La supervisión de

estos componentes y disponer de una buena directiva de publicación de excepciones le ayudará a aislar
componentes que tiendan a producir errores desde una perspectiva técnica o de lógica empresarial.
Cada vez que se conecta a una base de datos, debe también supervisar el uso de la conexión, las
estadísticas de agrupación de conexiones, así como las estadísticas de seguridad de conexión.
También es frecuente supervisar el tiempo de respuesta de los datos externos si SLA está asociado al uso
de datos u origen de datos externos.
Para obtener instrucciones detalladas sobre la forma de agregar capacidades de supervisión a los
componentes, consulte "Monitoring in .NET Distributed Application Design" en MSDN
Si implementa las capas empresariales con Enterprise Services, puede utilizar AppMetrics para COM+ de
XTremesoft, o bien utilizar las clases de instrumentación según se describe en "Monitoring in .NET
Distributed Application Design".
Configuración
Las aplicaciones requieren datos de configuración para funcionar técnicamente. Los valores que modifican
el comportamiento de las directivas (seguridad, administración operativa y comunicaciones) se consideran
datos de configuración.
Los datos de configuración se conservan en los archivos de configuración de .NET a nivel de usuario,
equipo y aplicación. La configuración personalizada almacenada aquí se puede definir con cualquier
esquema y se puede tener fácil acceso mediante el uso de la clase ConfigurationSettings en su aplicación.
Es muy importante tener en cuenta la confidencialidad de seguridad de la conexión; por ejemplo, no debe
almacenar cadenas de conexión SQL en texto no cifrado en los archivos de configuración XML,

especialmente si contienen credenciales SQL. Debería limitar el acceso a la información de seguridad a los
operadores adecuados y a fin de disponer de una mayor seguridad, debería considerar la firma digital de
la información para asegurarse de que los datos de configuración no se han modificado.
Los datos de configuración se pueden almacenar en varios lugares, cada uno de ellos con sus ventajas e
inconvenientes:
• Archivos de configuración XML: el almacenamiento de los datos de configuración aquí permite a los
clientes de su aplicación trabajar sin conexión y este modelo resulta fácil de implementar. Con
aplicaciones de cliente enriquecido, este enfoque puede suponer un aumento en los costos de
administración de los cambios, ya que requiere que todos los clientes dispongan de la misma
información de configuración. En los entornos de servidor, resulta fácil incluir los cambios de
configuración a través del servidor Application Center o los servicios de directorio de Microsoft Active
Directory, o bien mediante la copia de los archivos por lotes. Tenga en cuenta que la carga de nuevo
de los datos de configuración de la aplicación requiere un reinicio de AppDomain. No obstante,
ASP.NET reiniciará AppDomain cuando detecte un cambio en los archivos de configuración. Los
archivos de configuración de la aplicación se almacenan en texto sin formato, lo que puede resultar
un riesgo de seguridad inaceptable. Por ejemplo, en la mayoría de los casos no debería almacenar las
cadenas de conexión que contengan nombres de usuario y contraseñas en los archivos de
configuración de la aplicación.
• SQL Server o el almacén de datos de la aplicación: se trata de la ubicación de almacenamiento

normal para los datos de configuración administrados por la aplicación, pero aún más para los
metadatos de las aplicaciones. Si almacena aquí la configuración, se recomienda que guarde los
metadatos en una base de datos de SQL Server distinta de la de los datos empresariales. El acceso a
la base de datos supone a menudo una mejora en el rendimiento, por lo que debería considerar el
almacenamiento en caché.
• Active Directory: dentro de una organización, puede decidir almacenar los metadatos de la aplicación
en Active Directory. De este modo, los clientes del dominio pueden disponer de los metadatos.
También puede asegurar la información en Active Directory con ACL de Windows, asegurando que
sólo los usuarios y las cuentas de servicio autorizadas podrán tener acceso al mismo.
• Cadenas del constructor: si utiliza componentes basados en Enterprise Services, puede agregar datos
de configuración a la cadena del constructor para los componentes.
• Otras ubicaciones para casos especiales: éstas incluyen el Registro de Windows, el almacén de
Windows Local Security Authority (LSA) y las implementaciones personalizadas. Se utilizan en casos
muy especiales y agregan requisitos para los privilegios de aplicaciones en el equipo y los
mecanismos de implementación.
• Soluciones de administración de configuración de terceros que pueden proporcionar también

características de control de versiones e implementación.
El acceso a los datos de configuración y metadatos a menudo pueden producir, especialmente si los datos
están almacenados de forma remota. Para evitar esto, puede almacenar en la memoria caché los datos y

metadatos de la configuración administrada por la aplicación. Sin embargo, necesita asegurarse de que no
se abre una brecha en la seguridad al exponer información confidencial en el código de aplicación
incorrecto. Si almacena en caché los datos de configuración, resulta útil especificar las velocidades y
frecuencias de actualización para que los datos en caché se actualicen a horas predeterminadas en lugar
de a intervalos relativos (por ejemplo, exigir que la caché de configuración se actualice cada hora a la
hora, no "una hora desde la última actualización"). De este modo, ayuda a que los operadores entiendan
en qué datos de configuración se basan las aplicaciones en un punto del tiempo especificado.
Configuración en las capas de presentación
Los componentes de proceso de usuario generalmente requieren los siguientes valores de configuración:
• Información de la ubicación para llegar a los componentes de procesos empresariales y los

componentes de acceso a datos.
• Datos de conexión (como una cadena de conexión o una ruta de archivo) para el recurso que controla
los datos de procesos de usuario persistentes para procesos de larga ejecución.
Configuración en agentes de servicios
Los agentes de servicios necesitan disponer de información de configuración para conectarse al servicio
externo a través de los servicios Web, colas de mensajes u otros medios. El esquema y los datos de
configuración dependen del servicio específico al que se está teniendo acceso.
Configuración en los componentes de acceso a datos
Los componentes de acceso a datos normalmente necesitan lo siguiente:
• Necesitan tener la capacidad de asignar nombres de orígenes de datos lógicos a parámetros de la

conexión física (por ejemplo, para asignar la base de datos "Ventas" a una cadena de conexión real).
• Si los componentes de acceso a datos realizan un enrutamiento dinámico de datos, necesitará contar
con datos de configuración que expresen los parámetros (por ejemplo, región del cliente), algoritmos
(por ejemplo, hash) y destinos del enrutamiento (por ejemplo, cadenas de conexión para las bases de
datos). Es común incluir la lógica del enrutamiento dinámico de datos en un componente de utilidad
distinto.
Metadatos
Para que su aplicación sea más flexible en relación a los cambios en las condiciones de tiempo de
ejecución, puede que desee proporcionarle información sobre él mismo. El diseño de la aplicación para
que utilice metadatos en determinados lugares puede facilitar el mantenimiento y permitir su adaptación
al cambio sin costosos procesos de implementación o modificaciones en el desarrollo.
Hay dos momentos principales en los que puede utilizar metadatos en la aplicación:

• Tiempo de diseño: por ejemplo, puede utilizar información sobre la base de datos para generar
código, procedimientos almacenados, clases .NET o incluso componentes de la interfaz de usuario
para patrones que se repitan con frecuencia. El uso de metadatos durante el desarrollo ahorra tiempo
de desarrollo reactivo, disminuye la necesidad de comunicación entre los equipos, se concentra y
"mantiene" conjuntos de habilidades especiales y aplica los estándares de diseño, nomenclatura e
implementación. Los componentes resultantes se comportan de forma más predecible y tienden
menos a errores, con lo que aumenta la productividad del desarrollador. Sin embargo, este enfoque
requiere conocimientos especializados y un esfuerzo inicial adicional de desarrollo al crear las
plantillas y el código que los combina con los metadatos.
• Tiempo de ejecución: la aplicación puede ser más fácil de mantener si aprovecha la ventana de los
metadatos adecuados para los aspectos de cambio más frecuentes. Por ejemplo, puede que decida
adoptar encabezados para una lista de IU o cuadrícula de metadatos, para que sean modificables en
la aplicación. La aplicación también puede beneficiarse de los metadatos cuando establezca relaciones
entre los componentes o cuando se procesen patrones predecibles, como reglas de validación. Sin
embargo, el uso de metadatos en tiempo de ejecución suele ser más costoso en términos de
rendimiento, por lo que debería probar y crear un perfil del diseño de la aplicación al principio del
ciclo de vida de la aplicación. Puede diseñar los componentes para exponer los metadatos sobre ellos
mismos, pero debería hacerlo así sólo si la aplicación lo va a utilizar; de lo contrario, los metadatos
podrían ser una brecha en la seguridad.
Puede evitar los problemas de rendimiento al utilizar los metadatos en tiempo de ejecución utilizando
técnicas avanzadas como la generación de código sobre la marcha y la compilación utilizando las clases de
reflejo de .NET mientras se está ejecutando la aplicación. Esta técnica de diseño es compleja y
únicamente se recomienda para los casos más complejos debido a las habilidades necesarias y a las
implicaciones de seguridad de la compilación del código en tiempo de ejecución y al almacenamiento de
los metadatos. La personalización en tiempo de ejecución se puede lograr más fácilmente en la mayoría
de los casos con las secuencias de comandos de .NET. Para obtener más información sobre las secuencias
de comandos de .NET, consulte "Script Happens .NET" en MSDN
us/dnclinic/html/scripting06112001.asp?frame=true) (en inglés).
Los metadatos se pueden almacenar en varias ubicaciones tal como se ha mencionado anteriormente en el
apartado "Configuración". Para almacenes centralizados, puede utilizar bases de datos de SQL Server o
Active Directory. Si desea distribuir los metadatos entre los ensamblados, puede implementarlo en los
archivos XML o incluso en los atributos de .NET.
Para obtener una buena base conceptual sobre el uso de metadatos en el diseño de software (una técnica
denominada a veces metaprogramación, que está relacionada con la programación basada en la intención),
lea Generative Programming: Methods, Tools and Applications por Krzysztof Czarnecki y Ulrich Eisenecker
(ISBN: 0201309777).
A continuación, se muestran los posibles usos de los metadatos.
Metadatos en los componentes de interfaz de usuario

Normalmente los metadatos se utilizan en las interfaces de usuario para especificar los encabezados de
columna, el texto de ayuda del usuario, mensajes de error, jerarquías de menú, así como otros tipos de
información que normalmente no afectan a los datos empresariales de la aplicación.
Si su aplicación requiere algún nivel de personalización, lo normal es utilizar metadatos para administrar
las opciones de personalización simples. En el caso de personalizaciones más complejas, se recomienda
utilizar secuencias de comandos .NET.
Metadatos en los componentes de procesos de usuario
Si crea modelos de los procesos de usuario de una forma sistemática, puede que encuentre que los
siguientes metadatos le ayudarán a crear un diseño con una mejor capacidad de mantenimiento:
• Los procesos de usuario que existen y los elementos de menú que los desencadenan.
• El estado empresarial interno que es necesario para el proceso de IU y los valores predeterminados.
• Una representación del comportamiento del proceso de usuario como, por ejemplo, el componente de
la IU que se mostrará cuando el cliente haga clic en "Confirmar compra".
Metadatos en los componentes empresariales
Los procesos empresariales se pueden beneficiar del uso de metadatos para crear modelos de patrones o
reglas sencillas. Por ejemplo, se puede implementar un patrón de canalización como un motor que utilice
los metadatos para determinar las clases y métodos que llamará en cada secuencia, tal como muestran
las canalizaciones de compra de Microsoft Commerce Server 2002. También puede utilizar metadatos para
ayudar a los componentes de llamada a identificar los métodos de compensación para determinadas
actividades empresariales.
Metadatos en los componentes de acceso a datos
Si el componte de acceso a datos expone una interfaz que proporciona la funcionalidad de creación,
lectura, actualización y eliminación (CRUD), sería útil exponer el esquema de los datos y metadatos
devueltos que utiliza. De forma similar, resulta útil exponer esquemas XSD de parámetros de entrada y
salida complejos para acciones o consultas especiales.
Los componentes de acceso a datos se pueden basar en metadatos en lugar de código de procedimiento
para realizar las transformaciones y asignaciones de datos. Puede utilizar los documentos XSL para
transformar un esquema XML en otro, utilizar un enfoque basado en reglas para realizar la asignación o
utilizar los esquemas de anotación SQLXML para asignar los documentos XML a datos en la base de datos
subyacente. El enfoque basado en metadatos puede resultar especialmente útil si esta asignación tiende a
cambiar con frecuencia.
Metadatos en los componentes de entidades empresariales

Se recomienda que exponga metadatos de entidades empresariales a los consumidores, especialmente en

los componentes de interfaz de usuario, donde resulta útil disponer de información sobre las entidades
empresariales disponibles para ayudar en tareas como:
• Rellenar encabezados de columna en tablas.
• Mostrar descripciones de atributos para información sobre herramientas y descripción de la interfaz

de usuario.
• Utilizar relaciones entre las entidades lógicas de la aplicación para permitir que la interfaz de usuario
las exponga y permita su exploración.
• Validar valores de datos de entidades empresariales, para que la interfaz de usuario pueda de forma
activa aplicarlas (por ejemplo, el número máximo de direcciones por cliente o los formatos de datos).
Puede exponer metadatos en forma de documentos XSD o XML con un esquema personalizado.
También se recomienda que cambie con frecuencia las reglas de validación como metadatos. Al diseñar las
reglas de validación como metadatos le permite cambiarlas sin que se vea afectada la implementación o
cambio de distribución de los componentes de entidades empresariales. Esto resulta especialmente
importante ya que las entidades empresariales puede que se utilicen desde los escritorios de clientes
donde la administración de cambios resulta costosa. Las reglas de validación para las entidades se podrían
expresar en un esquema XSD implementado con la aplicación.
Ubicación de servicios
En las llamadas a servicios remotos, es necesario determinar dónde están situados los objetos y servicios
externos de .NET que pueden procesar su solicitud y cómo tener acceso a ellos. Esto resulta
especialmente importante a la hora de utilizar servicios Web alojados por otras organizaciones o terceros.
Localización de ensamblados locales
.NET ofrece características extensivas que le permiten especificar los ensamblados a los que se puede
vincular en tiempo de ejecución. Para obtener información técnica más detallada sobre la forma en
que .NET localiza ensamblados locales cuando crea objetos, consulte "How the Runtime Locates
Assemblies" en MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/cpguide/html/cpconhowruntimelocatesassemblies.asp) (en inglés).
Localización de las clases para .NET Remoting
.NET Remoting le permite realizar llamadas a objetos ubicados en otro dominio de aplicación, proceso o
equipo. Puede exponer los objetos que se van a utilizar por el sistema remoto y localizar los objetos que
desea llamar de forma remota especificando la información de configuración o escribiendo código en la
aplicación. Asimismo necesita que su aplicación conozca los canales que va a utilizar para la comunicación
remota.

Para obtener más información sobre el uso de la configuración de .NET Remoting para exponer tipos,
buscar tipos y registrar canales, consulte "Registering Remote Objects Using Configuration Files" en MSDN
us/cpguide/html/cpconregisteringremoteobjectsusingconfigurationfiles.asp?frame=true) (en inglés).
Localización de colas de Message Queue Server para mensajería asincrónica
Para enviar un mensaje de la cola de mensajes Message Queue Server, necesita conocer a qué cola lo
están enviando. La forma en que hace referencia a las colas de Message Queue Server varía según la
configuración de Message Queue Server y si se está enviando mensajes por Internet.
Si Message Queue Server se ha instalado en la configuración de un dominio, puede localizar las colas por
nombre, identificador u otros atributos. Con MSMQ 2.0 (en Windows 2000), esta capacidad requiere que
los clientes y servidores en cola hagan referencia al mismo controlador de dominio que mantiene un
registro de colas existentes en Active Directory. En las configuraciones de dominio, puede especificar una
etiqueta o FormatName para identificar la cola.
Si ha instalado Message Queue Server en una configuración de grupo de trabajo del remitente, necesita
especificar la ruta completa de la cola. Para obtener más información sobre el uso de Message Queue
Server, consulte los siguientes artículos de MSDN:
• "MessageQueue.Path Property" (http://msdn.microsoft.com/library/default.asp?url=/library/en-

us/cpref/html/frlrfSystemMessagingMessageQueueClassPathTopic.asp?frame=true) (en inglés)
• "MessageQueue.QueueName Property" (http://msdn.microsoft.com/library/en-

us/cpref/html/frlrfsystemmessagingmessagequeueclassqueuenametopic.asp) (en inglés)
Localización de servicios Web en Internet y dentro de una organización
El URI para un servicio Web XML se puede recuperar dinámicamente en tiempo de ejecución desde el
archivo de configuración de la aplicación. Este enfoque mejora la capacidad de mantenimiento de la
aplicación. Para obtener más información sobre el almacenamiento de la información de la ubicación de
servicios Web en el archivo de configuración, consulte "Web References" en MSDN
us/vsintro7/html/vxconWebReferences.asp?frame=true) (en inglés).
Existe una iniciativa industrial denominada UDDI (Descripción, descubrimiento e integración universales)
para ayudar a los servicios y empresas a encontrar otros servicios y exponer los servicios y sus interfaces
a llamadores interesados. UDDI está basado en estándares como SOAP, WSDL y DNS, lo que lo convierte
intrínsecamente en independiente de la plataforma. Puede utilizar un registro UDDI internacional para
exponer su servicio a socios y servicios externos. Asimismo, puede realizar una implementación de la
especificación UDDI en su empresa para ayudar a localizar e integrar servicios internos.
Microsoft proporciona servicios de UDDI de forma nativa con Microsoft Windows .NET Server. Para obtener
más información sobre esta característica, consulte el sitio Web de Windows .NET Server
(http://www.microsoft.com/windows.netserver/developers/default.mspx) (en inglés). Si no dispone de

Microsoft .NET Server, también puede utilizar Microsoft UDDI SDK

(http://www.microsoft.com/downloads/release.asp?ReleaseID=35940) (en inglés) para instalar UDDI en
un equipo local.
Para obtener más información sobre UDDI, consulte el sitio Web de UDDI (http://www.uddi.org/) (en
inglés) y los siguientes artículos de MSDN:
• "UDDI: Un servicio Web acerca de XML"

(http://www.microsoft.com/spain/msdn/articulos/archivo/160301/voices/xml12182000.asp)
• "Uso de UDDI en tiempo de ejecución"

(http://www.microsoft.com/latam/msdn/articulos/2002/04/art04/default.aspframe=true)
Diseño de la directiva de comunicaciones
La directiva de comunicaciones define la forma en que los componentes de la aplicación se comunicarán

entre sí. Esta directiva trata cuestiones como la sincronización de la comunicación, el formato y el
protocolo, tal como se muestra en la figura 3.4.
Figura 3.4. Aspectos de la directiva de comunicaciones
Elección del modelo de comunicación correcto
Debe considerar minuciosamente si los componentes de la aplicación se comunicarán a través de

mensajes o utilizando un enfoque conectado totalmente acoplado como DCOM o .NET Remoting. La
comunicación conectada resulta más fácil de diseñar e implementar, pero tiene limitaciones en términos
de escalabilidad, disponibilidad y administración.
Separación de la comunicación entre aplicaciones y dentro de la misma aplicación
La comunicación entre aplicaciones (es decir, la comunicación con servicios externos) se debería
implementar con un modelo basado en mensajes como los servicios Web XML basados en SOAP o
Microsoft Message Queue Server. Internamente, los componentes de la aplicación pueden requerir de
mecanismos de comunicación que proporcione un alto rendimiento y capacidades específicas como el flujo
del contexto de seguridad o transacciones. Puede lograr esto mediante el uso de los modelos de
comunicación conectada como DCOM. Sin embargo, cuando no es necesario el flujo de identidad o
transacción, puede utilizar los servicios Web XML entre las capas de la aplicación. Se recomienda que
utilice un mecanismo de comunicación basado en mensajes siempre que sea posible en la aplicación. Esto

incluye la comunicación entre las capas de interfaz de usuario, procesos empresariales y la interfaz de
usuario y entre las interfaces de servicios y las capas empresariales.
Nota Los servicios Web XML no admiten actualmente el flujo de identidades o transacciones basado
en estándares. Global XML Web Services Architecture (GXA) tratará estos problemas mediante la
definición de especificaciones para las transacciones y seguridad. Encontrará más información sobre GXA
en http://msdn.microsoft.com/library/en-us/dnglobspec/html/wsspecsover.asp (en inglés).
Los distintos requisitos y limitaciones de la comunicación entre aplicaciones y dentro de la aplicación

guiarán en la mayoría de las decisiones tecnológicas. En muchos casos, puede que no sea un problema de
mantenimiento tener los componentes bien acoplados que se generan, implementan y administran como
una unidad. Sin embargo, en muchos casos puede que sea útil ver las distintas capas de aplicaciones
como servicios y esforzarse por tener el mismo poco acoplamiento entre capas de aplicaciones que se
encuentran entre servicios no relacionados. La figura 3.5 muestra este concepto.
Figura 3.5. Implementación de la comunicación entre las capas de presentación y empresarial

utilizando el bus de mensaje
En la figura 3.5 se muestra que la aplicación está diseñada como un servicio (1) al que se tiene acceso a
través de un bus de mensaje (2). La capa de presentación (3) utiliza la misma comunicación que otros

servicios de llamada (4), con posibilidades también de invocar directamente otros servicios (6). Los
agentes de servicios (5) invocan otros servicios utilizando también el bus de mensaje (6). La
comunicación con los componentes de datos se implementa de forma más realista mediante el empleo de
otros mecanismos de comunicación (7), a menos que los datos necesiten exponerse en los casos de datos
a datos o de procesos a datos, en cuyo caso los orígenes de datos también se podría tener acceso a ellos
a través del bus de mensaje.
El uso del mismo bus de comunicación entre las capas y servicios produce un diseño más modular del
sistema, mientras que otros servicios pueden elegir partes más minuciosas de funcionalidad con los que
integrarse. También produce un nivel más alto de independencia entre los equipos y las plataformas
utilizadas para cada capa.
La visualización de capas como servicios puede resultar una visión convincente a largo plazo para un
sistema, pero puede suponer varios retos en cuando al diseño:
• Las capas empresariales se pueden basar en tener un contexto con información de seguridad que
proporciona la interfaz de usuario, que puede que no esté disponible al intentar invocar la misma
lógica de una aplicación.
• El bus de mensaje o comunicación debe admitir todos los requisitos de la comunicación dentro de la
aplicación, como un flujo de transacciones, transferencia eficiente de grandes nóminas, alto
rendimiento y baja latencia y transferencia de variada información de excepciones. Los estándares
están evolucionando en todas estas áreas, pero el modelo de desarrollo todavía requiere que su uso
no sea transparente.
• Resulta difícil diseñar el mismo nivel de resistencia y disponibilidad entre la IU y las capas
empresariales como el nivel esperado entre servicios. La comunicación entre la interfaz de usuario y
los niveles empresariales es probablemente el mejor lugar para diseñar la comunicación basada en
los mismos estándares utilizados entre servicios. La comunicación entre los niveles empresariales y
datos de una aplicación sigue siendo territorio para mecanismos de comunicación eficientes pero no
genéricos.
Si su objetivo es tener un diseño de aplicación más tradicional y si la integración de servicios constituye

sólo un pequeño aspecto de la arquitectura global, puede que desee utilizar los servicios Web,
intercambios de mensajes basados en estándares con la finalidad de la integración sólo y utilizar DCOM
o .NET Remoting para la comunicación dentro de la aplicación, tal como muestra la figura 3.6.

Figura 3.6. Uso del bus de mensajes sólo para la integración
En la figura 3.6, los niveles de presentación, empresarial y de datos se comunican entre sí a través de
mecanismos de comunicación eficaces pero probablemente no estándares. El uso de la comunicación
basada en mensajes y en estándares sólo se utiliza para la integración, donde las interfaces de servicios
aceptan las llamadas de posibles llamadores externos (3 y 4) y agentes de servicios realizan las llamadas
a otros servicios (5 y 6).
La comunicación basada en mensajes, especialmente cuando se implementa asincrónicamente en un

transporte de almacenamiento y reenvío, ofrece la mejor alternativa de comunicación para la integración,
pero lo que se obtiene no es gratuito: debe considerar muchos problemas de diseño antes de poder
implementarlo correctamente.
Ventajas de la comunicación basada en mensajes asíncronos
El uso de un mecanismo de comunicación basada en mensajes asíncronos ofrece las siguientes ventajas:
• Escalabilidad y disponibilidad: la comunicación basada en mensajes ofrece una mejor escalabilidad y

disponibilidad (ambos en términos de solidez y resistencia) para la aplicación y el servicio. Con la
comunicación basada en mensajes, puede utilizar mejor los recursos de hardware y aislar la
aplicación de los errores de software o infraestructura.
• Transparencia de la ubicación: la comunicación basada en mensajes también proporciona una

auténtica transparencia de la funcionalidad remota, ya que no asume que hay presente una conexión
y que un mensaje siempre se puede enviar.

• Similaridad con los modelos empresariales: los procesos empresariales reales se modela
principalmente de forma asincrónica, en términos de intercambios entre partes y usuarios. El uso de
comunicaciones basadas en mensajes pueden proporcionar una asignación más limpia entre los
requisitos y el comportamiento de la aplicación.
• Aislamiento de SLA: es más fácil definir y mantener SLAs en términos de intercambios de mensajes.
El uso de la comunicación basada en mensajes también permite aislar cuellos de botella internos en
los procesos empresariales internos o servicios externos de SLAs de rendimiento que desea garantizar
a sus usuarios.
• Transport agnostic: una aplicación o servicio diseñado correctamente para la comunicación basada en
mensajes puede beneficiarse fácilmente de las nuevas tecnologías de mensajería a medida que
surgen.
Desventajas de la comunicación basada en mensajes
La comunicación basada en mensajes escasea. A medida que lea esta lista de consideraciones sobre el
diseño, tenga en cuenta las ventajas mencionadas anteriormente: el esfuerzo en el diseño de las
comunicaciones basadas en mensajes merece la pena durante la duración del servicio o aplicación. Las
desventajas de la comunicación basada en mensajes son:
• Resultado determinista: en un escenario conectado, sabrá si la solicitud se realizó correctamente o no

al final de la misma. En la comunicación basada en mensajes, necesita tener en cuenta estados
adicionales en los que no se han recibido mensajes de devolución. Esto significa que debe administrar
el estado de conversación además de la lógica normal empresarial (por ejemplo, puede que tenga
que registrar mensajes enviados para su procesamiento posterior en el caso de que no se reciba una
respuesta).
• Correlación de mensajes: debido a que no hay no un emparejamiento automático de los mensajes

enviados y recibidos, necesitará implementar un mecanismo de correlación que identifique que un
determinado mensaje incluye una instancia concreta de una conversación o proceso empresarial.
Puede implementar esta correlación en el transporte de mensajería (por ejemplo, estableciendo los
identificadores de la correlación en los mensajes de Message Queue Server) o en los datos
empresariales. La implementación de la correlación en los datos empresariales le ayudarán a cambiar
con mayor facilidad el transporte de mensajería y lograr más fácilmente la idempotencia de los
procesos empresariales.
• Retraso de los mensajes: los mensajes pueden llegar más tarde de lo esperado. Debe implementar la
lógica empresarial de modo que pueda tratar mensajes que nunca llegan. También deberá diseñar la
lógica de recepción de mensajes para asegurarse de que el mensaje sigue siendo válido cuando se
recibe. Por ejemplo, si está recibiendo un pedido, podría especificar un tiempo de inactividad tras el
cual el pedido no se procesará. Considere el caso en el que los precios del catálogo han cambiado
entre el envío del pedido por el llamador y el recibo del mensaje. En este caso, necesitará especificar
si el pedido se procesa con los nuevos precios, los precios de ese momento o no se procesa
directamente. Puede resultar útil en algunos casos para el mensaje incluir datos de referencia
esenciales en los que se basa (como, por ejemplo, los precios de los productos) de modo que la lógica

empresarial pueda realmente comparar y tomar decisiones más minuciosas sobre lo que debe hacer
con el mensaje.
• Flujo de transacciones: la comunicación basada en mensajes implica un modelo de transacción

distinto. Si está utilizando un transporte transaccional (como colas transaccionales de Message Queue
Server), una confirmación de transacción asegurará que se realiza la operación enviar. No podrá
enviar un mensaje transaccional y recibir su respuesta en el contexto de una sola transacción atómica.
Esto significa que necesitará administrar conversaciones que incluyan varios intercambios en una
transacción de ejecución larga y exponer las actividades de compensación adecuadas.
• Mensajes repetidos: la lógica necesitará controlar un caso especial en el que los mensajes pueden
llegar más de una vez. Puede implementarla mediante el diseño de los procesos y la lógica de forma
que sean idempotentes al recibir el mismo mensaje más de una vez. Por ejemplo, en un servicio de
procesamiento de pagos que carga los fondos de la cuenta de un cliente y los abona en la cuenta del
proveedor, debe evitar transferir el importe de una compra en particular varias veces si el mensaje de
solicitud de pago se recibe más de una vez. Puede evitar este problema solicitando que se suministre
un Id. de transacción con la solicitud de pago e ignorar las siguientes solicitudes con el mismo Id. de
transacción. También puede lograr la idempotencia mediante la especificación de los datos anteriores
y nuevos para las operaciones que actualizarán la base de datos. En este caso, la recepción de un
mensaje para cambiar el atributo de envío de un pedido de No a Sí dos veces no es un problema (si
la lógica empresarial lo determina así).
• Secuencia de mensajes: si espera más de un mensaje entrante, puede que no reciba los mensajes en
la secuencia esperada. En este caso, puede controlar esto en el estado de conversación o en la lógica
empresarial. Puede obligar la secuencia en la lógica empresarial haciendo que la conversación
dependa de las confirmaciones. Por ejemplo, podría determinar que todos los mensajes de
actualización de pedidos tengan un Id. que haya proporcionado al emisor. Esta técnica de diseño
derrota algunas de las ventajas de la comunicación basada en mensajes, por lo que deberá utilizarla
únicamente cuando sea necesaria.
Escenarios para la comunicación basada en mensajes
Debería diseñar una interfaz para la aplicación o servicio que se va a basar en mensajes (como cuando se
utiliza SOAP) y se base en mecanismos de almacenamiento y reenvío asincrónico como Message Queue
Server cuando:
• Esté implementando un sistema empresarial que representa una inversión media a largo plazo; por
ejemplo, al crear un servicio que se expondrá y será utilizado por los socios durante un período largo
de tiempo.
• Está implementando sistemas a gran escala con características de alta escalabilidad.
• Está generando un servicio que desea aislar de otros servicios que utiliza y de servicios en los que se
expone.
• Espera que la comunicación de ambos puntos finales no estén disponibles esporádicamente, como en
el caso de aplicaciones o redes inalámbricas que se puedan utilizar sin conexión.

Sincronización
Es frecuente pensar en la comunicación basada en mensajes como modelo asincrónico. Por ejemplo, es
evidente que dos aplicaciones que se comunican entre sí a través de Message Queue Server lo están
haciendo utilizando mensajes. Sin embargo, la comunicación basada en mensajes también se puede
encapsular en un modelo de programación asincrónico (por ejemplo, utilizando servidores proxy de
servicios Web generados por Microsoft Visual Studio® .NET), en el que el cliente espera un mensaje de
respuesta. En este caso, el desarrollador de la aplicación puede beneficiarse de las ventajas de la
comunicación basada en mensajes sin tener que tratar las complejidades de la programación en un
modelo asincrónico.
Para obtener más información, consulte "Architectural Options for Asynchronous Workflow" en MSDN
us/dnbda/html/bdadotnetarch12.asp?frame=true) (en inglés).
Elección de tecnologías para las comunicaciones asincrónicas
Se pueden utilizar distintos enfoques para la comunicación asincrónica, incluidos los enfoques basados en
mensajes como Message Queue Server y XML Web Services y tecnologías conectadas como .NET
Remoting y DCOM. De estos enfoques, las tecnologías de cola ofrecen el nivel de flexibilidad y de variedad
de características más alto. Message Queue Server proporciona un transporte de mensajería de
almacenamiento y reenvío para su uso en aplicaciones. Además de la escalabilidad y disponibilidad,
Message Queue Server proporciona varias opciones de desarrollo para ayudar al desarrollo e
implementación de la aplicación en distintos escenarios.
Message Queue Server proporciona las siguientes opciones y características:
• Mensajes con servicio de almacenamiento y reenvío por Internet.
• Mensajería transaccional con exactamente garantía de entrega una vez del mensaje.
• Almacenamiento basado en clúster para una alta disponibilidad.
Puede consultar más información sobre la siguiente versión de Message Queue Server en
http://www.microsoft.com/msmq/MSMQ3.0_whitepaper_draft.doc (en inglés).
Al utilizar Message Queue Server, necesitará determinar la tecnología del extremo y el formato del
mensaje. Se encuentran disponibles los siguientes extremos y formatos:
• Envío y recepción de extremos
Puede desarrollar código que utilice los objetos en el espacio de nombres System.Messaging, o bien
utilizar el servicio de desencadenadores de Message Queue Server para la escucha de los mensajes.
Si controla ambos extremos y no tiene ningún requisito para el formato de los mensajes, puede
utilizar Enterprise Services Queued Components, que encapsula totalmente el desarrollo relacionado
con Message Queue Server. Los extremos también pueden incluir aplicaciones basadas en COM,
puertos de BizTalk Server y puentes a MQSeries y otras tecnologías de mensajería.

• Formatos
Puede utilizar formatos de SOAP, binarios y de Microsoft ActiveX®. SOAP se utiliza para obtener un
máximo de interoperabilidad, el binario para obtener una eficacia en el tamaño de los mensajes y
ActiveX para la interoperabilidad con remitentes y agentes de escucha basados en COM. Debido a que
está basado en COM, los activadores de MSMQ requieren el uso del formato de ActiveX. Queued
Components envían mensajes en un formato DCE RPC opaco, que se mantiene transparente para el
desarrollador.
Enterprise Services Queued Components
Puede utilizar Enterprise Services Queued Components cuando:
• Controle tanto el remitente como el receptor del mensaje.
• El componente de recepción es un componente con servicio.
• Es indiferente el formato del mensaje (será un formato binario RPC NDR opaco).
Queued Components cuenta con las siguientes ventajas:
• Puede utilizar la autorización basada en funciones de Enterprise Services sin necesidad de desarrollo
adicional para firmar el mensaje en el remitente.
• Puede utilizar el mecanismo de reintento integrado en Message Queue Server para asegurarse de que
los mensajes se ejecutan finalmente.
• Puede utilizar las clases de excepciones para obtener la notificación de errores de forma que pueda
realizar acciones alternadas.
• Los mensajes se pueden enviar tanto con los remitentes COM como .NET.
• Puede fácilmente trabajar con transacciones de forma transparente con el modelo Enterprise Services.
Desencadenadores de Message Queue Server
Los desencadenadores de Message Queue Server proporcionan un servicio de escucha. Utílicelos cuando:
• No controle los remitentes.
• Necesite desencadenar un archivo .exe o componente COM cuando llegue un mensaje.
• El formato del mensaje puede ser ActiveX.
• Esté preparado para implementar la función del receptor como un componente basado en .NET que se
invocará utilizando la interoperabilidad COM.
Receptores personalizados

Escribir un receptor personalizado ofrece el máximo grado de control con respecto al formato,
comportamiento de reintentos, administración de excepciones, etc. Sin embargo, no se recomienda que
desarrolle su propio servicio de escucha ya que esto requiere habilidades en la administración de
comunicación asincrónica, subprocesamiento múltiple, seguridad y administración de excepciones. Si crea
su propio servicio de receptor, debería probarlo ampliamente antes de implementarlo.
Tecnologías asincrónicas alternativas
Como alternativa al uso de Message Queue Server, puede también crear un proxy de servicios Web XML
con Visual Studio .NET, en cuyo caso cada método expuesto por el servicio Web se puede llamar
asincrónicamente con el método Begin<nombre del método> y especificar una función de devolución de
llamada.
También puede utilizar devolución de llamadas para implementar invocaciones a métodos asincrónicos a
través de los canales de .NET Remoting. Para obtener más información sobre la implementación de
operaciones asincrónicas con .NET Remoting, consulte la sección sobre el entorno remoto asincrónico en la
documentación de .NET Framework en MSDN
us/cpguide/html/cpconasynchronousremoting.asp) (en inglés).
Selección de tecnologías para las comunicaciones sincrónicas
.NET proporciona varias opciones para la comunicación sincrónica. Cada opción está definida como una
combinación de un extremo (por ejemplo, IIS), un protocolo (por ejemplo, HTTP) y un formato (por
ejemplo, SOAP). Cada combinación posible representa un canal a través del cual tiene lugar la
comunicación. También puede implementar los canales personalizados definiendo su propia combinación
de extremo, protocolo y formato.
Los canales tienen numerosos atributos, la importancia de cada depende de los componentes que se están
intercomunicando. Estos atributos incluyen:
• Capacidad de flujo de contexto de transacciones.
• Amplitud de alcance a distintos clientes en diferentes plataformas.
• Capacidades de seguridad (autenticación, autorización y cifrado de canales).
• Requisitos del protocolo sobre la infraestructura de redes.
• Eficacia como función del tipo y tamaño de los datos que se transmiten.
Responder a las siguientes preguntas le ayudará a elegir una tecnología de comunicación sincrónica
basada en sus requisitos:
1. ¿Es necesario un flujo de transacciones o establecer un flujo del contexto de seguridad de Windows?

Si es así, utilice DCOM. Sus extremos se alojarán en Enterprise Services para beneficiarse de las
transacciones. El que realiza la llamada podrá conocer la identidad del llamador original del
componente mediante el uso de la clase SecurityCallContext.
Si no es así, vaya a la pregunta 2.
2. ¿Necesita un mayor alcance?
Si necesita exponer su servicio de una forma estándar para asegurarse el máximo alcance, puede
utilizar SOAP y HTTP para implementar los servicios Web XML. Puede exponer servicios Web de dos
formas en Windows 2000: con los archivos ASP.NET .asmx o el canal remoto HTTP/SOAP. Vaya a la
pregunta 4.
Si no es así, vaya a la pregunta 3.
3. ¿Es necesario autenticar al autor de llamada?
Si no necesita transacciones, flujo de seguridad o un amplio alcance puede utilizar los canales
de .NET Remoting. .NET Remoting se basa en IIS para realizar la autenticación del llamador cuando
realiza la llamada por HTTP, por lo que necesitará disponer de un extremo IIS si necesita la
autenticación.
Si no necesita la autenticación, puede utilizar cualquier canal de .NET Remoting alojado en cualquier
proceso.
4. ¿Necesita implementar el código de fachada para exponer la funcionalidad empresarial?
Si necesita ajustar la lógica empresarial en una fachada adicional, para realizar una validación,
transformación o incluso un almacenamiento en caché adicional, puede utilizar los servicios Web de
ASP.NET para implementar fácilmente funciones que puede llamar SOAP.
Si no necesita una capa de fachada ampliada, puede exponer sus tipos directamente como servicios
Web. Tenga en cuenta que no puede exponer clases Enterprise Services directamente. Si los
componentes empresariales son Serviced Components, necesitará crear una capa de fachada con los
servicios Web de ASP.NET o las clases remotas en Windows 2000.
Nota El uso de DCOM con los últimos arreglos le permitirá establecer comunicación a través de
únicamente un puerto conocido. Para obtener más información, consulte los siguientes artículos de
Knowledge Base:
Q154596—HOWTO: Configure RPC Dynamic Port Allocation to Work with Firewall
(http://support.microsoft.com/support/kb/articles/q154/5/96.asp) (en inglés)
Q312960—Cannot Set Fixed Endpoint for a COM+ Application
(http://support.microsoft.com/default.aspx?scid=kb;en-us;q312960) (en inglés)
Para obtener más información sobre la decisión entre los servicios Web XML y .NET Remoting, consulte
"Choosing Communication Options in .NET" (en inglés) en la documentación de .NET Framework en MSDN

us/cpguide/html/cpconchoosingcommunicationoptionsinnet.asp).
Las siguientes fuentes proporcionan más información sobre .NET Remoting:
• "Exposing Existing Code as a Web Service Using the .NET Framework"

us/dnbda/html/bdadotnetwebservice1.asp?frame=true) (en inglés)
• "An Introduction to Microsoft .NET Remoting Framework"

us/dndotnet/html/introremoting.asp?frame=true) (en inglés)
• Sitio Web de DotNetRemoting.cc (http://www.dotnetremoting.cc) (en inglés)
• "Performance Comparison: Exposing Existing Code as a Web Service"

us/dnbda/html/bdadotnetarch11.asp?frame=true) (en inglés)
• Advanced .NET Remoting por Ingo Rammer (ISBN 1590590252)
Recomendaciones para comunicaciones
Al implementar el servicio y la aplicación, tenga en cuenta estas recomendaciones:
• Corte las cadenas de llamadas con colas y cachés según sea necesario. De este modo, mejorará la
escalabilidad y disponibilidad de la solución en general.
• Acerque los límites asincrónicos al usuario, interfaces de servicios y agentes de servicios, para aislar
el servicio de dependencias externas.
• Si necesita exponer funcionalidad como operación sincrónica, evalúe si puede ajustar una operación
asincrónica internamente tal como se describe en el siguiente apartado.
Encapsulación de la comunicación asincrónica en solicitudes sincrónicas
El diseño de la aplicación debería impulsar el uso de las comunicaciones asincrónicas todo lo posible. Sin
embargo, en algunos casos, es razonable o inevitable que el cliente espere una respuesta sincrónica.
Puede que desee basarse en un diseño totalmente asincrónico solamente si el servicio al que llama no
cumple las expectativas en términos de tiempos de respuesta. Este patrón se aplica principalmente
implementar agentes de servicios.
Puede diseñar los componentes de modo que utilice las operaciones asincrónicas, sin embargo puede
proporcionar una interfaz sincrónica para los llamadores. El diseño básico para lograr esto es el siguiente:
1. El llamador envía una solicitud sincrónica a un componente.

2. El componente recibe la solicitud y, como mínimo, crea o identifica un Id. o cookie para identificar
inequívocamente esta solicitud, al que la entrada de base de datos le realiza una copia de seguridad
óptima.
3. El servidor envía una solicitud asincrónica al servicio.
4. El componente se establece en espera de un mensaje de respuesta, con un tiempo de espera.
5. Si el componente recibe el mensaje a tiempo, genera la respuesta y la devuelve al llamador

sincrónico.
6. Si el componente no recibe el mensaje a tiempo, devuelve una respuesta repetitiva con el Id. de
solicitud al llamador o una excepción que puede controlar el llamador. El componente de servidor se
debería entonces desactivar.
7. A continuación, tiene dos opciones para obtener el resultado en el llamador:
• El llamador puede entonces invocar a un componente de servidor (quizás una función distinta en
el mismo componente) para obtener el resultado después de cierto tiempo (segundos o minutos)
basado en el Id. de solicitud. Si el llamador es un usuario humano, es una práctica frecuente
entretenerlo con alguna animación gráfica.
• El servidor notifica al llamador empleando un mecanismo asincrónico, como una notificación del
usuario (correo electrónico, Windows Messenger o un mensaje de localizador) o bien envía un
mensaje de vuelta al cliente para que pueda visualizar el resultado correcto. En este caso, la
aplicación o el usuario debe tener un receptor de mensajes como un correo electrónico o una
ruta de mensaje a Message Queue Server. Si utiliza Message Queue Server, debería
correlacionar el mensaje de devolución con el Id. de correlación.
Formato, esquema y protocolo de comunicaciones
El formato en que se envían y reciben datos y el esquema de los datos que intercambia son factores
importantes al diseñar la comunicación de la aplicación.
Los siguientes factores influyen en el formato y esquema:
• ¿Controla ambos extremos de la comunicación? Si es así, puede elegir formatos y protocolos que
optimicen el rendimiento y proporcionen características adicionales (como el flujo de seguridad o
transacción) a costa de la amplia interoperabilidad. Este es el caso cuando está comunicando las
capas de la aplicación y considera que todos los niveles están totalmente relacionados o acoplados.
• ¿Desea que llamadores externos dentro y fuera de la organización puedan tener acceso al servicio? Si
es así, debería decidirse por estándares ampliamente aceptados de protocolos (como TCP), formatos
(por ejemplo SOAP) e incluso esquemas (por ejemplo, utilizar esquemas en www.uddi.org),
especialmente para interfaces y agentes de servicios. Si el servicio con el que se pone en contacto o
su propia comunicación no se basa en estándares, puede que necesite utilizar puentes o capas de
traducción adicionales entre los extremos.

Un vistazo al futuro
La comunicación de servicios basada en estándares de la industria está madurando rápidamente y

Microsoft está proporcionando instrumentos en su próxima generación de productos para facilitar aún más
la exposición y consumo de la funcionalidad empresarial a través de los mecanismos estándar.
Los siguientes vínculos proporcionan más información sobre lo que parece deparar el futuro:
• "Servicios Web COM+: La ruta de la casilla de verificación a los servicios Web XML"
us/dndotnet/html/comwscheckb.asp?frame=true) (en inglés)
• "El entorno de aplicación de Windows Server 2003

(http://www.microsoft.com/latam/msdn/articulos/2002/01/art01/default.asp)
• "Introducción a GXA: Global XML Web Services Architecture"

(http://www.microsoft.com/spain/msdn/articulos/archivo/151102/voices/introd_gxa.aspframe=true)
• "Confiabilidad de XML Web Services"

(http://www.microsoft.com/latam/msdn/articulos/2002/02/art06/default.asp)
• http://msdn.microsoft.com/webservices
• http://www.gotdotnet.com/team/XMLwebservices/default.aspx
• http://www.gotdotnet.com/team/XML_wsspecs/
• http://discuss.develop.com/

Capítulo 4: Implementación física y requerimientos

operativos
Diciembre de 2002
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
requerimientos operativos (no funcionales) de la aplicación.
En este capítulo se incluyen las siguientes secciones:
• Implementación de los componentes de la aplicación
• Patrones comunes de implementación
• Requerimientos operativos
• 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 requerimientos 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, requerimientos 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
(http://www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/idc/default.asp) (en
inglés).
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
(http://www.microsoft.com/latam/technet/articulos/idc/idc2/default.asp).
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 (http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/dnaspnet/html/asp12282000.asp) (en inglés).
• 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
(http://www.microsoft.com/spain/msdn/articulos/archivo/140202/voices/Asp11222001.aspAsp11222
001.asp).
• 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
(http://www.microsoft.com/latam/applicationcenter/).
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
(http://www.microsoft.com/latam/technet/articulos/idc/idc5/default.asp).
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
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbiz2k2/html/bts_2002clustering.asp)
(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 requerimientos "imprescindibles".
2. Aplicación de restricciones y requerimientos. 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 requerimientos 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 requerimientos "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
requerimientos. 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 requerimientos 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
requerimientos 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 requerimientos 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
auditoria 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 son similares 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 requerimientos 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 (http://msdn.microsoft.com/library/en-
us/dnbda/html/daag.asp) (en inglés)
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 beneficioso 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
(http://msdn.microsoft.com/library/?url=/library/en-us/dnbda/html/tdlg_rm.asp?frame=true) (en
inglés).
• 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 (http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/dnbda/html/DALGRoadmap.asp) (en inglés)
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
requerimientos.
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
requerimientos, 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).
Figura 4.2. Batería de servidores Web con lógica empresarial local
Entre los requerimientos 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 requerimientos 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.
Figura 4.3. Batería de servidores Web con lógica empresarial remota
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 requerimientos 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.
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
Requerimientos 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.
Figura 4.5. Cliente enriquecido con acceso del servicio Web
Requerimientos 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.
Figura 4.6. Servicio con lógica empresarial local

Entre los requerimientos 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 requerimientos 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 los 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 requerimientos de seguridad.
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
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 requerimientos 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.
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.

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 requerimientos 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.
Requerimientos 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 requerimientos operativos (no funcionales) para la aplicación y los servicios.
Entre estos requerimientos 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 requerimientos 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
requerimientos 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 requerimientos 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 presentan 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 (http://www.microsoft.com/latam/technet/articulos/idc/idc5/default.asp).
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

requerimientos 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 siguiente 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 nombres 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 requerimientos 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:
".NET Framework SDK: Enabling Profiling" (http://msdn.microsoft.com/library/default.asp?url=/library/en-

us/cpguide/html/cpconenablingprofiling.asp?frame=true) (en inglés)

".NET CLR Profiling Services: Track Your Managed Components to Boost Application Performance," MSDN
Magazine, noviembre de 2001 (http://msdn.microsoft.com/msdnmag/issues/01/11/NetProf/NetProf.asp)
(en inglés)

Apéndices y Glosario
Diciembre de 2002
Resumen: este apéndice incluye un mapa de productos que le ayudará a encontrar los productos
Microsoft de más utilidad para generar su solución. También se incluye un glosario de términos relativos a
la arquitectura de aplicaciones .NET.
Este capítulo contiene los siguientes apéndices:
• Apéndice 1: Mapa de productos
Este apéndice proporciona un mapa de alto nivel de los productos Microsoft® que le puede servir de
ayuda para implementar una aplicación .NET distribuida, basada en Microsoft .NET Framework,
organizada en capas lógicas.
• Apéndice 2: Glosario
Este apéndice proporciona un glosario de términos técnicos relativos al desarrollo de aplicaciones

distribuidas.
• Apéndice 3: Arquitecturas por capas
Este apéndice explica la relación entre las capas descritas en esta guía y otros esquemas de
nomenclatura que se utilizan habitualmente en la industria informática.
Éste es el capítulo 5 de Arquitectura de aplicaciones de .NET: Diseño de aplicaciones y servicios. Comience

por aquí para obtener una visión general completa.
Apéndice 1: Mapa de productos
El mapa de productos que se ofrece en este apéndice muestra cómo las diferentes tecnologías y productos
Microsoft proporcionan una plataforma para los niveles de aplicación lógicos que se describen en esta guía.
La figura 5.1 muestra un esquema simplificado de la aplicación y sus niveles, mientras que la figura 5.2
(el mapa de productos) enumera las diferentes tecnologías asociadas con los niveles que se muestran en
la figura 5.1.
Una solución distribuida deberá utilizar únicamente los productos y tecnologías que respondan a sus
requisitos. Sin embargo, la figura 5.2 muestra varios de ellos juntos para indicar la forma en que se
pueden relacionar entre sí. Esta figura muestra cómo los productos se asignan a los componentes lógicos,
y no a un patrón de implementación físico.
Para una mayor claridad, la figura 5.2 no muestra los productos y tecnologías que se utilizan para
implementar las directivas de seguridad, administración y comunicaciones. La mayor parte de las
tecnologías que no se muestran las proporciona el sistema operativo Microsoft Windows®, como por
ejemplo el servicio de directorios Microsoft Active Directory®, Message Queue Server, Windows
Management Instrumentation (WMI), etc.

Figura 5.1. Esquema simplificado de los niveles de una aplicación

Figura 5.2. Mapa de productos
Apéndice 2: Glosario
Ensamblado
Un ensamblado es una unidad de implementación en una aplicación basada en .NET Framework.
Transacción atómica
Una transacción atómica es una operación en la que o bien todos los pasos de la operación tienen éxito, o
todos dan error. Las transacciones atómicas se utilizan habitualmente para realizar modificaciones de los
datos en un almacén de datos, donde todos los datos relativos a la operación se modifican con éxito, o no
se modifica ninguno y los datos permanecen como estaban antes de que se iniciara la operación.

Conmutatividad
Conmutatividad es un patrón de diseño para una implementación en la que los mensajes tendrán el
mismo resultado, independientemente del orden en que se reciban. Por ejemplo, una operación
conmutativa puede implicar dos pasos: "cambiar la categoría del producto dos a 'manufacturas'" e
"incrementar el precio del producto dos en un 10%." No importa en qué orden se realizan estos pasos; el
resultado es que el producto dos está en la categoría "manufacturas" y se ha incrementado su precio en
un 10%. Por el contrario, una operación en la que los dos pasos son "cambiar la categoría del producto
dos a 'manufacturas'" e "incrementar el precio de todas las manufacturas en un 10%" no es conmutativa,
puesto que el precio del producto dos se incrementará únicamente si su categoría se cambia antes de que
se realice el paso del incremento del precio.
Componente
Dicho de forma sencilla, un componente es una parte de un sistema. Una definición más específica de
componente es una unidad de funcionalidad que se puede amortizar a través de diversas
implementaciones. Un componente generalmente se implementa como un objeto de software que expone
una o más interfaces y que implementa la lógica.
Contrato
Un contrato es un acuerdo vinculante entre varias partes que dicta la semántica de comunicación válida.
El contrato determina los protocolos utilizados para comunicarse y el formato de los mensajes, así como el
contrato de nivel de servicio y las declaraciones legales.
Conversación
Una conversación es el intercambio de mensajes entre una aplicación cliente y un servicio que se requiere
para completar una tarea empresarial.
CRUD
CRUD responde a las siglas en inglés de Crear, Leer, Actualizar y Eliminar. Se refiere a las operaciones
que se pueden realizar en un almacén de datos. En la terminología de SQL, Crear, Leer, Actualizar y
Eliminar se refieren a INSERTAR, SELECCIONAR, ACTUALIZAR y ELIMINAR operaciones, respectivamente.
Zona desmilitarizada (DMZ)
Una DMZ es la zona física detrás de un servidor de seguridad de Internet y delante de un servidor de
seguridad de segundo nivel que protege los sistemas y datos del servidor. En un escenario típico de una
aplicación de Internet, la DMZ es la red de área local virtual (VLAN) física en la que se implementan los
servidores Web.
Enrutamiento dinámico de datos (DDR)
El enrutamiento dinámico de datos es la lógica que se utiliza para determinar a qué servidor de base de
datos se enviará una recuperación de datos o una solicitud de modificación cuando los datos se

encuentran particionados entre diversos servidores. El DDR se puede implementar mediante la utilización
de un algoritmo hash, una tabla de reglas o algún otro esquema de partición.
Emisario
Un emisario es un término genérico para un componente de software que se comunica con un recurso
externo en nombre de su aplicación. El emisario resume la semántica de la comunicación con el recurso
externo desde su aplicación, y controla todos los aspectos de la conversación, incluida la persistencia de
estado para los procesos largos.
Feudo
Un feudo es un patrón de diseño para una colección de servicios que encapsula un estado duradero
compartido y se implementan conjuntamente. Un feudo representa un límite de confianza, donde los
componentes de software que se encuentran dentro del feudo no confían en los de fuera.
Servidor de seguridad
Un servidor de seguridad es una implementación de seguridad basada en software (o en hardware) que

aplica reglas de filtrado al tráfico de red entre dos zonas.
Idempotencia
Idempotencia significa la habilidad para realizar una acción determinada varias veces y aun así conseguir
el mismo resultado que se obtendría si se realizase una sola vez. Un mensaje idempotente, como por
ejemplo una instrucción para "cambiar el precio del producto dos a 10,00$", no provocará ningún efecto
secundario si se recibe varias veces, mientras que un mensaje no idempotente, como por ejemplo una
instrucción para "incrementar el precio del producto dos en un 10%", producirá un resultado diferente
según el número de veces que se reciba.
Capa
Una capa se puede concebir como un patrón de arquitectura en el que los componentes utilizan servicios
en las capas inferiores. La utilización de capas facilita el mantenimiento. La comunicación entre dos capas
determina la facilidad con que se podrá particionar la aplicación en ese punto para la distribución física a
través de los niveles. Unos esquemas de capas estrictos no permiten a las capas tener acceso a otras
capas que no sean las inmediatamente inferiores, mientras que unos esquemas de capas más flexibles
permiten a una capa determinada utilizar cualquier otra que esté por debajo de ella.
Transacción de ejecución larga
Una transacción de ejecución larga es una implementación de un proceso empresarial o parte de él que
contiene la lógica para compensar por las actividades que ya se han ejecutado en caso de cancelación.
Mensaje
Un mensaje es una unidad de información que se transmite electrónicamente de un servicio a otro.

Organización
La organización es la automatización de un flujo de trabajo. Microsoft BizTalk® Server proporciona un

motor de organización que se puede utilizar para organizar los flujos de trabajo empresariales.
Directiva
Una directiva es un conjunto de reglas con respecto a la seguridad, administración operativa y

comunicación que se aplican en una zona determinada.
Servicio
Un servicio es un componente de software que se puede utilizar en una parte de un proceso empresarial
completo. Los servicios admiten interfaz de comunicación basada en mensajes, a través de la cual tiene
lugar una conversación. Un servicio encapsula su propio estado y datos empresariales, y la comunicación
con él únicamente se puede realizar a través de las interfaces de servicio que expone.
Agente de servicios
Un agente de servicios es un emisario que se utiliza para controlar una conversación con un servicio
externo.
Interfaz de servicios
Una interfaz de servicios es un punto de entrada para un servicio. Proporciona una interfaz pública que los
llamadores pueden utilizar para consultar el contrato que admite la interfaz y realizar llamadas de método
basado en mensajes al servicio.
Con estado
Con estado es lo contrario a sin estado. En una conversación con estado, la información relativa a los
aspectos de datos que se hayan intercambiado con anterioridad se debe registrar para permitir
posteriormente unos intercambios significativos.
Sin estado
Sin estado se refiere a una conversación en la que todos los mensajes entre las partes se pueden
interpretar independientemente. No se mantiene un estado entre los mensajes.
Confirmación en dos fases
El protocolo de confirmación en dos fases se utiliza para asegurar que varias partes sincronizan sus
estados cuando se realiza una operación transaccional. El protocolo de confirmación en dos fases se puede
utilizar para las transacciones atómicas así como para las transacciones empresariales.
Flujo de trabajo

El flujo de trabajo se refiere a un proceso empresarial en el que los pasos se deben realizar en un
determinado orden, y se deben cumplir unas condiciones predefinidas, antes de avanzar de un paso al
siguiente. Por ejemplo, un flujo de trabajo para la compra de productos podría implicar primero la
validación de la información acerca de la tarjeta de crédito del comprador, a continuación el pedido de los
productos a un proveedor y, por último, la organización de la entrega. No se puede realizar el pedido de
los productos hasta que se autorice la información sobre la tarjeta de crédito, y no se puede organizar la
entrega hasta que los productos se hayan recibido del proveedor.
Zona
Una zona es un límite de confianza, un límite de comunicación y un límite operativo. La zona se puede
asignar a una entidad del mundo real, como por ejemplo una empresa o departamento, o bien puede
definir una determinada área dentro del entorno de implementación físico de la aplicación, como por
ejemplo una batería de servidores Web, o incluso simplemente un proceso. Las zonas son modelos
mentales de gran utilidad a la hora de determinar la implementación de la aplicación y la relación del
diseño de la aplicación con el diseño de la infraestructura.
Apéndice 3: Arquitecturas por capas
Esta guía ha dividido una aplicación en capas con funciones y funcionalidades diferentes con el objetivo de
facilitar el mantenimiento del código, optimizar la forma en que funciona la aplicación cuando se
implementa de modos diferentes y proporcionar una ubicación clara donde se deben tomar ciertas
decisiones respecto a la tecnología o el diseño a la hora de generar aplicaciones distribuidas basadas
en .NET Framework.
La división de la funcionalidad de la aplicación en capas la ha realizado la comunidad de patrones de

diseño. Esta tabla pretende ilustrar de modo general la forma en que las capas de los componentes que se
describen en esta guía se corresponden con la terminología de las capas y los patrones de diseño que
utilizan algunos de estos autores.
Esta guía
Patrones y capas relacionados
Componentes de interfaz de usuario
Capa de presentación
Capa de vistas
Capa de clientes
Procesos de interfaz de usuario
Patrón de controlador de aplicaciones
Capa de controlador/mediador
Capa de modelo de aplicaciones
Interfaces de servicios
Patrón de fachada remota
Flujos de trabajo empresariales
Capa de dominio2
Componentes empresariales

Capa de dominio
Patrón de secuencias de comandos de transacciones
Entidades empresariales
Objeto de transferencia de datos1
Modelo de dominio
Componentes lógicos de acceso a datos3
Capa de orígenes de datos
Capa de infraestructuras
Capa de integración
Agentes de servicios3
Capa de orígenes de datos
Capa de infraestructuras
Capa de integración
Notas a la tabla:
1. La utilización del patrón de diseño de objeto de transferencia de datos para los componentes de la
entidad empresarial implica que utilice las entidades empresariales como la forma de transferir los
datos entre las capas, bien utilizando conjuntos de datos ADO.NET o sus objetos serializables
personalizados. Otro uso de las entidades empresariales que va más allá del patrón de objeto de
transferencia de datos es generar un modelo de objeto o un modelo de dominio para toda la
aplicación, encapsulando tanto el comportamiento empresarial como el estado.
2. Los flujos de trabajo empresariales se pueden considerar como un conjunto de patrones de

secuencias de comandos de transacción que puede realizar un seguimiento y persistir en el estado a
través de las llamadas entrantes de llamadores asincrónicos y sincrónicos. Se agrupa aquí bajo
dominio, puesto que los flujos de trabajo empresariales en definitiva implementan la lógica
empresarial.
3. Los componentes lógicos de acceso a datos y los agentes de servicios se pueden utilizar para
encapsular la asignación de datos y las actividades de agregación y anulación de agregación, en cuyo
caso se pueden denominar "capa de asignación de datos" o "asignador de datos", según el autor.

Arquitectura Aplicaciones

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Arquitectura Aplicaciones

Transféré par

Droits d'auteur :

Formats disponibles

Arquitectura de aplicaciones .

Patterns & Practices

Guía Básica ............................................ vii

Contenido del capítulo

Profesionales a los que se destina la guía

Profesionales a los que se destina la guía

• Determinar cómo se divide una aplicación en distintos componentes.

• Diseñar las directivas de administración y seguridad que se deben aplicar.

• Decidir el modo de implementación de la aplicación.

Arquitectura de aplicaciones .NET: Diseño de aplicaciones y servicios ix

Capítulo 2: Diseño de los componentes de una aplicación o servicio

Capítulo 3: Directivas de seguridad, administración operativa y comunicaciones

x Arquitectura de aplicaciones .NET: Diseño de aplicaciones y servicios

Capítulo 4: Implementación física y requisitos operativos

Arquitecto de la solución y Administrador de programas: Edward A. Jezierski

Nuestro agradecimiento a los siguientes colaboradores, patrocinadores y revisores:

Guías de arquitectura prescriptiva y equipo de contenido:

Arquitectura de aplicaciones .NET: Diseño de aplicaciones y servicios xi

Grupo de noticias: Web-Based Reader

Grupo de noticias: NNTP Reader

news://msnews.microsoft.com/microsoft.public.dotnet.distributed_apps (en inglés)

© 2003 Microsoft Corporation. Reservados todos los derechos. Condiciones de uso.

xii Arquitectura de aplicaciones .NET: Diseño de aplicaciones y servicios

Arquitectura de aplicaciones de .NET: Diseño de aplicaciones y servicios proporciona instrucciones sobre el

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.

Contenido del capítulo

Este capítulo incluye las siguientes secciones:

• Objetivos del diseño de aplicaciones distribuidas

• Servicios e integración de servicios

• Componentes y niveles en aplicaciones y servicios

Arquitectura de aplicaciones .NET: Diseño de aplicaciones y servicios 3

Objetivos del diseño de aplicaciones distribuidas

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

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

Servicios e integración de servicios

4 Arquitectura de aplicaciones .NET: Diseño de aplicaciones y servicios

Figura 1.1. Proceso empresarial implementado utilizando servicios

Arquitectura de aplicaciones .NET: Diseño de aplicaciones y servicios 5

Si la aplicación utiliza un servicio externo, la implementación interna del servicio le es indiferente al

Nota El capítulo 3, "Directivas de seguridad, administración operativa y comunicaciones", trata con

6 Arquitectura de aplicaciones .NET: Diseño de aplicaciones y servicios

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

nivel para hacer referencia a los patrones de distribución físicos.

Figura 1.2. Solución basada en servicios

Arquitectura de aplicaciones .NET: Diseño de aplicaciones y servicios 7

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

8 Arquitectura de aplicaciones .NET: Diseño de aplicaciones y servicios

operativa y comunicaciones, consulte el capítulo 3, "Directivas de seguridad, administración operativa y

Arquitectura de aplicaciones .NET: Diseño de aplicaciones y servicios 9

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

© 2003 Microsoft Corporation. Reservados todos los derechos. Condiciones de uso.

10 Arquitectura de aplicaciones .NET: Diseño de aplicaciones y servicios

Capítulo 2: Diseño de los componentes de una aplicación o

Contenido del capítulo

Este capítulo incluye las siguientes secciones:

• Recomendaciones generales relativas al diseño de aplicaciones y servicios

• Diseño de capas de presentación