Documento de arquitectura de aplicaciones que había definido en el 2008 para todos los proyectos web. En ese momento utilizábamos un patrón MVP en ASP.Net con Spring.Net y algunos conceptos de AOP.

1. © 2008 Telmex S.A.
Arquitectura de Aplicaciones
Gerencia de Analisis y Desarrollo de Sistemas

3. All rights reserved. No parts of this work may be reproduced in any form or by any means - graphic, electronic, or
mechanical, including photocopying, recording, taping, or information storage and retrieval systems - without the
written permission of the publisher.
Products that are referred to in this document may be either trademarks and/or registered trademarks of the
respective owners. The publisher and the author make no claim to these trademarks.
While every precaution has been taken in the preparation of this document, the publisher and the author assume no
responsibility for errors or omissions, or for damages resulting from the use of information contained in this
document or from the use of programs and source code that may accompany it. In no event shall the publisher and
the author be liable for any loss of profit or any other commercial damage caused or alleged to have been caused
directly or indirectly by this document.
Printed: Octubre 2008 in (whereever you are located)
Arquitectura de Aplicaciones
© 2008 Telmex S.A.

4. Arquitectura de Aplicaciones4
© 2008 Telmex S.A.
Lista de contenidos
Foreword 6
Apéndice A - Objetivos 8
................................................................................................................................... 81 Contexto
................................................................................................................................... 82 Del presente documento
................................................................................................................................... 83 Del código fuente
................................................................................................................................... 84 De la arquitectura
................................................................................................................................... 85 Historia de Revisiones
Apéndice B - Arquitectura interna 11
................................................................................................................................... 111 Orientación a Objetos
................................................................................................................................... 112 Lógica distribuida en capas
..........................................................................................................................................................12Capa de Persistencia
..........................................................................................................................................................13Capa de Acceso a datos
..........................................................................................................................................................13Capa Tipos Comunes
..........................................................................................................................................................14Capa de Servicios
..........................................................................................................................................................14Capa Presenter de interfaz
..........................................................................................................................................................14Capa de interfaz de usuario
................................................................................................................................... 143 Del mantenimiento de la vista
................................................................................................................................... 144 Patron MVP
................................................................................................................................... 155 Mínimo acoplamiento
................................................................................................................................... 156 Abstraccion del modelo de persistencia
................................................................................................................................... 167 Simplicidad del código
Apéndice C - Arquitectura externa 18
................................................................................................................................... 181 De la división estructural de las aplicaciones
..........................................................................................................................................................18Vantive
..........................................................................................................................................................18Desarrollos adicionales al estándar
..........................................................................................................................................................18Herramientas CORE
..........................................................................................................................................................19Grafica de división
................................................................................................................................... 192 De los componentes estándar
................................................................................................................................... 193 De los requerimientos técnicos
................................................................................................................................... 204 De los puntos críticos a considerar
Apéndice D - De la metodología de instalación 22
................................................................................................................................... 221 De la escalabilidad y estabilidad en la instalación
................................................................................................................................... 222 Del proceso de deployment
................................................................................................................................... 223 Del control de versiones
................................................................................................................................... 224 De las estrategias de migración

5. 5Contents
5
© 2008 Telmex S.A.

6. Foreword6
© 2008 Telmex S.A.

7. Apéndice A

8. Arquitectura de Aplicaciones8
© 2008 Telmex S.A.
1 Objetivos
1.1 Contexto
El área de sistemas de TELMEX se dispone a ofrecer servicios de desarrollos a la misma
empresa productos para facilitar diversos procesos, bajo los siguientes objetivos
· Rápida velocidad de respuesta en la solución
· Aprovechar el acceso y la existencia de información transversal de VANTIVE
para agilizar diversos procesos, y ofreciendo soluciones especificas.
· Generar un ahorro en los presupuestos de migración reutilizando módulos
desarrollados o a desarrollarse.
· Alineación con normas de desarrollo de TELMEX.
1.2 Del presente documento
Documentar la arquitectura general de toda aplicación .NET para los presentes y futuros
desarrollos.
Identificar los posibles puntos débiles a mejorar en próximas etapas de desarrollo.
Documentar las estrategias de migración progresiva y convivencia con las actuales
aplicaciones ASP/PHP.
1.3 Del código fuente
Buen nivel de reutilización, código simple y de fácil mantenimiento. Clara identificación del
negocio que desea resolver. Desarrollo progresivo. Patrones de desarrollo y applications
blocks. Abstracción completa de la persistencia.
Asi mismo, se generó un documento de buenas practicas para inducir al desarrollador a
mejorar sus habitos.
1.4 De la arquitectura
Escalable, estructura de aplicaciones empresariales, con capacidad para implementación
en diferentes ambientes con ciclos de desarrollo de diferentes tiempos. Uso de
componentes de arquitectura SOA controlado.
Puntos críticos identificables. Uso de componentes homologados.
Flexibilidad para implementación en diferentes infraestructuras.
Optimización y control del uso de memoria y ancho de banda, capacidad para soportar
gran nivel de concurrencia.
1.5 Historia de Revisiones
Fecha Versión Descripción Autor

9. Objetivos
© 2008 Telmex S.A.
9
13/10/2008 1.0 Creación del Documento José Franco

10. Apéndice B

11. Arquitectura interna
© 2008 Telmex S.A.
11
2 Arquitectura interna
2.1 Orientación a Objetos
En el código resultante se aplicarán los principios de la POO haciendo especial énfasis en
los siguientes ítems:
· Abstracción completa del modelo de persistencia: Esto se logra con objetos en la
capa de negocios que provean métodos para recuperar los datos y modificarlos.
· Objetos de bajo de acoplamiento
2.2 Lógica distribuida en capas
Se identifican las siguientes capas con sus límites claramente definidos
La ubicación de lógica aplicada en la capa incorrecta esta prohibida.

12. Arquitectura de Aplicaciones12
© 2008 Telmex S.A.
La interoperabilidad con los Servicios Web, se muestra a continuación.
2.2.1 Capa de Persistencia
Se refiere a la base de datos, bajo las siguientes premisas:
· Acceso a los datos sólo por SP.
· No puede existir lógica del negocio en el Store Procedure, la complejidad sólo será
admitida para optimizar el resultado de la consulta.

13. Arquitectura interna
© 2008 Telmex S.A.
13
· Se priorizará restringir los paquetes a un set de 4 métodos.
· GetList: selección de todos los campos, descripciones de claves foraneas incluidas,
ordenamiento por parámetro de los campos, busqueda por like en campos de texto,
paginación de resultado. En el Anexo I, template de selección.
· GetByPk: selección por clave primaria.
· Insert.
· Delete.
· Update: Con control de concurrencia.
· No utilización de SQL dinámico: a fin de permitir el uso de un plan de ejecución.
· Funciones: Restringidas a auxiliar consultas de selección para optimizar resultado,
no se admite otra lógica aplicada.
· Triggers: No, restringidas a los estandares de VANTIVE.
· Seguridad: Autenticación de usuario único con acceso al esquema particular del
negocio, acceso a los datos a través de vistas, seguridad de acceso a los datos
controlada por la aplicación.
· Paginación: No pueden existir Store Procedures de busqueda de datos sin limitar el
resultado y ofrecerlo por páginas.
· Tracking: Para lógica compleja necesaria para interactuar con VANTIVE, se usará
un SP para abrirse de la arquitectura de las aplicaciones.
2.2.2 Capa de Acceso a datos
Provee el acceso a los datos, dividida en tres secciones, esta capa no puede contener
ninguna referencia de lógica de negocio.
· Componente de Acceso a Datos: DataAccess homologado por TELMEX y otros
componentes de acceso a datos (VANTIVE, SAP, driver nativos).
· Interfase de comunicación con los componentes: Basada sus métodos en MS
DataAccess Application Block, principalmente hace de un wrapper con los
diferentes componetes de acceso a datos
· Clases de comunicación con el componente: Implica la declaración de los
parámetros, en una forma independiente al componente de acceso a datos, a esta
llegan tipos de datos abstractos propios del lenguaje (Dataset, tipos nativos)
2.2.3 Capa Tipos Comunes
Capa de tipo colaboradora, se hace hincapié en que la comunicación entre capa debe
efectuarse con tipos de datos abstractos. Esta capa posee acoplamiento con el negocio
de la aplicación, su existencia y separación es para simplificar la estructura del código.
Entre las características de la misma encontramos
· Tipos abstractos de datos: Sin lógica de negocio asociada, generalmente
derivaciones de tipos provistos del framework con mayores funcionalidades o
clases contenedoras de datos asociados a circuitos de negocio para comunicarse
entre capas.

14. Arquitectura de Aplicaciones14
© 2008 Telmex S.A.
2.2.4 Capa de Servicios
Contiene un proveedor de servicio, pudiendo acceder a cada servicio de cada entidad
existente en nuestro proyecto.
· Objetos de lógica: Clases instanciables que permiten resolver problemáticas
concretas del negocio, por lo general tendrán una correspondencia con lo requerido
por el objeto visual. Concentra la totalidad de la funcionalidad del negocio
(validaciones, campos calculados, etc). Los objetos de negocio son serializables
para poder ser persistidos en caso de que sea necesario.
2.2.5 Capa Presenter de interfaz
Por aplicación del patrón MVP, se encargará de transformar la información entre la capa
de servicio y la interfaz de usuario, dominará la traducción de los contenidos, la
transformación de datos para proveerla a la interfaz.
Actúa como controlador de interfaz de usuario, de fuerte acoplamiento con las páginas a
las que asiste. Cada página obligatoriamente contendrá una interfaz.
La pagina hablara exclusivamente con su controlador, salvo que la funcionalidad requerida
no implique presentación o envio de datos.
2.2.6 Capa de interfaz de usuario
Compuestas por los paginas aspx que conformarán el sitio web, el código del codebehind
se restringirá al consumo de las funcionalidades y los datos provistos por la capa
controladora
El flujo de ejecución de la aplicación es dominado por la interfaz pero regla de negocios
tendrá la decisión final acerca de si se provee funcionalidades y datos para la
funcionalidad solicitada.
El control del flujo será monitoreado desde funciones core invocadas desde el global.asax
antes de resolverse cada petición de datos. En ella se llevará registro de la navegación
del usuario.
2.3 Del mantenimiento de la vista
El presenter será instanciado en cada petición, no siendo guardado ni serializado en
ningún componente, para guardar estados.
2.4 Patron MVP
La implementación de este patrón se debe principalmente a los siguientes aspectos:
· Reducir al mínimo el código alojado en el aspx y restringirlo simplemente a código
de presentación y de configuración de los componentes visuales.
· Prever modificaciones en la visualización que tengan mínimo impacto en el resto del
código.
· Evitar toda lógica no propia de la vista en los aspx para poder efectuar soluciones
con capas de presentación en otras tecnologías (flash, winform)

15. Arquitectura interna
© 2008 Telmex S.A.
15
MVP Pattern:
2.5 Mínimo acoplamiento
Dentro del código que se va desarrollando se obtienen un conjunto de clases de alta
reutilización asociadas al manejo de datos tales como buscadores y objetos de alta, baja,
modificación y consulta de datos, los cuales se corresponden con una o varias entidades
existentes en el modelo de datos.
Estas clases desarrolladas en forma independiente a la especificación puntual de negocio
son utilizadas en varios subproyectos del sitio, razón por la cual, son alojadas en un
ensamblado diferente al de cada aplicación.
2.6 Abstraccion del modelo de persistencia
El objetivo de esta implementación es independizarse del medio de almacenamiento.
Se logra accediendo a las entidades del modelo de datos a través de las clases
representativas en regla de negocio.
Cada entidad podría estar almacenada en diferentes modelos de persistencia (SAP, Oracle,
SQL Server, PeopleNet (m4objects), VANTIVE ).
Al obligar acceder exclusivamente a través de las clases de servicio para recuperar los
datos, nos independizamos completamente del medio y hasta podríamos controlar
procesos transaccionales entre diferentes plataformas.
Ademas de la inclusión de conceptos de AOP. Como IoC, y Service Factory.

16. Arquitectura de Aplicaciones16
© 2008 Telmex S.A.
2.7 Simplicidad del código
Se logra a través de la utilización de clases instanciables.
Se evita la utilización de métodos estáticos con una gran cantidad de parámetros para
lograr establecer el contexto antes de resolver el negocio.
Al utilizarse variables de instancia, los métodos se simplifican, el objeto tiene mayor
control del negocio y se logran encapsular muchas funcionalidades
La desventaja de esta implementación es el uso que hacen estos objetos de la memoria,
es por ello que se aplican reglas en todas las capas para evitar saturaciones de la misma.
Asimismo, con el fin de lograr mayor simplicidad, existen normas específicas de
nomenclatura, longitud de los métodos, nombre de métodos, templates de clases, etc.

17. Apéndice C

18. Arquitectura de Aplicaciones18
© 2008 Telmex S.A.
3 Arquitectura externa
De la división estructural de las aplicaciones
Se detecta tres bloques principales de funcionalidades los cuales tienen ciclos de
desarrollo diferentes, medios de persistencia separados, y que pueden ser afectados por
migraciones en momentos distintos.
3.1 De la división estructural de las aplicaciones
3.1.1 Vantive
<<pendiente>>
3.1.2 Desarrollos adicionales al estándar
Contempla todos aquellos desarrollos que no estén dentro del estándar del sistema de
gestión de TELMEX.
3.1.3 Herramientas CORE
Se refiere al conjunto de clases que proveen funcionalidades para la ejecución del sitio,
resuelve los aspectos de seguridad (autorización y autenticación), navegación (control del
flujo de ejecución), espacios de memoria compartida (objeto SessionManager),
regionalización (traducción de contenidos y presentación), etc.
Estas herramientas requieren acceder a un repositorio de datos especial donde guardar
información de configuración el cual es completamente independiente de los anteriormente
descriptos.
Asimismo, dentro de las herramientas CORE, encontraremos los módulos (controles y
páginas) que dominan el flujo de ejecución de las subaplicaciones de TELMEX y proveen
funcionalidades para comunicarse entre ellos.
El ciclo de desarrollo de las herramientas CORE es mas lento, con ciclos de versiones
amplios, de gran estabilidad.
Estos módulos (ensamblados) deben poder ser accedidos desde cualquier subaplicacion,
razón por la cual deben estar instalados en la GAC del servidor de web.

19. Arquitectura externa
© 2008 Telmex S.A.
19
3.1.4 Grafica de división
<<pendiente>>
La grafica divide los servidores como repositorios de datos distintos, no necesariamente
representan una arquitectura física de esta distribución, aunque al menos si marca
diferentes esquemas de base de datos para cada uno de los grupos.
En el caso de los desarrollos especiales, estos a su vez pueden dividirse en múltiples
esquemas que encierren las entidades particulares de cada negocio.
3.2 De los componentes estándar
No se tiene previsto utilizar componentes de terceras partes, en caso de que así sea se
evaluará conveniencia y se elevará a consideración de responsables de Tecnología.
Se procura utilizar la paleta de componentes estandar incluida en el framework .Net
2.0.50727.
3.3 De los requerimientos técnicos
Conforme a los puntos anteriormente detallado se desprenden los siguientes
requerimientos técnicos
· Servidor IIS con las siguientes caracteristicas:
· Framework .NET v2.0.50727
· .NET Framework 2.0 Software Development Kit (SDK)
Ambientes de Desarrollo, Test, Pre-Producción y Producción para cada paquete.

20. Arquitectura de Aplicaciones20
© 2008 Telmex S.A.
3.4 De los puntos críticos a considerar
<<pendiente>>

21. Apéndice D

22. Arquitectura de Aplicaciones22
© 2008 Telmex S.A.
4 De la metodología de instalación
4.1 De la escalabilidad y estabilidad en la instalación
La separación indicada en 4.1 garantiza líneas de desarrollo separadas con ciclos de
estabilización diferentes.
La estructuración de subproyectos bajo el esquema ejemplificado en 4.1.5.1 garantiza
procesos de instalación independientes y permitirían usar las funcionalidades de rollback
en instalaciones fallidas.
4.2 Del proceso de deployment
Si bien cada desarrollo puede requerir programación en paralelo para abarcar la totalidad
de las funciones solicitadas en el requerimiento, los proyectos pueden tratarse como
líneas de desarrollo independientes las cuales inclusive, pueden tener instalaciones en
distintas etapas, con diferentes requerimientos y con diferentes niveles de testing.
Si, es recomendable, que primero se incorporen las funciones transversales al proyecto
para que al momento de culminar la especificación puntual pueda testearse el desarrollo
en su totalidad.
Las modificaciones a las herramientas CORE son independientes a los módulos a desarrollar
aunque puede resolverse en el mismo proyecto incorporarse funcionalidades nuevas para
mejorar las capacidades de todo el sitio, es por ello que se puede adelantar el proceso de
instalación para testear su funcionamiento con los módulos existentes.
El testing de desarrollos CORE posee niveles más estrictos ya que afectan a todos los
subproyectos.
Los desarrollos sobre proyectos deberían tener test de integración, aunque si las
funcionalidades son genéricas y afectan otros desarrollos puede adelantarse su testing e
instalación en producción.
4.3 Del control de versiones
Los ensamblados se versionarán, se llevará un registro de las funciones incorporadas en
cada versión, los bugs detectados y el estado de los mismos.
Se planificará la incorporación de funcionalidades necesarias para los ensamblados CORE
en versiones posteriores.
La incorporación de nuevas funcionalidades sobre estos ensamblados permitirá un
desarrollo progresivo del sitio.
En caso de que se cuente con software de apoyo a estas metodologías de trabajo se
incorporarán caso contrario se llevarán registros con otros software existente y
disponibles.
4.4 De las estrategias de migración
<<pendiente>>

23. 23
© 2008 Telmex S.A.