Arquitectura de aplicaciones y servicios

Después de participar como oradores de una charla de arquitectura de aplicaciones y servicios, mi amigo Luis y yo reflexionamos sobre las preguntas que nos hicieron algunos de los asistentes, y de cómo algunas respuestas eran bastante simples, y en otros casos, no tanto.

 

Como charla introductoria de arquitectura de aplicaciones y servicios, cubrimos al menos las tres capas básicas que debe tener alguna aplicación de mediana o gran envergadura. El diagrama arquitectónico de una aplicación consta de las siguientes capas, componentes y agentes.

 



 

Para un desarrollador novato o con algo de experiencia, que tradicionalmente ha construido aplicaciones monolíticas y aplicaciones que tienen una interfaz y un nivel de aislamiento logrado con un componente, esta separación de capas a primera vista lo llena de confusión.

 

Para simplificar el proceso de aprendizaje de la arquitectura en cuestión, nuestra presentación y la demostración realizada fueron simplificadas a un esquema como el siguiente, complementándolo con la explicación y existencia de las entidades de negocio (omitidas en el diagrama por simplificación). La demostración modificaba una aplicación monolítica hasta dejarla en al menos tres capas.

 


 

Dentro de los temas explicados en la charla, puedo destacar los siguientes:

 

·         Justificación de la existencia de al menos tres capas. Es necesario que cualquier aplicación de mediana o gran envergadura esté separada en las capas de Presentación, Negocio y Datos. Esto es para delimitar responsabilidades entre quien debe realizar ciertas tareas, y por que las capas no deben ni tienen por que saber de cómo y con quien interactúan las otras capas.

 

·         Existencia de las entidades de negocio. Las entidades de negocio representan elementos del mundo real, y que son utilizados por los procesos que componen nuestra aplicación, como por ejemplo ordenes de compra, usuarios o un grupo de permisos.

 

·         Formato de las entidades de negocio. Dentro de las opciones revisadas se presentaron el uso de XML, Datasets tipificados o no y clases desarrolladas en algún lenguaje como C# o VB. Los criterios de definición nos hacen decidirnos teniendo en cuenta necesidades como de ordenación de estas o buscar sobre un grupo, si se requiere hacer bind sobre controles o el nivel de acceso que tendrán (local o remoto – web services). Hay que considerar que no existe un formato único. Cada entidad requiere un estudio propio.

 

·         Comunicación entre las capas. Las distintas capas se comunican en gran medida utilizando entidades de negocio. Hay algunas veces que no es necesario o en definitiva no es posible. Por ejemplo, para realizar eliminaciones no es necesario utilizar una entidad. Con entregar los elementos que identifican el elemento basta. Igual sucede al buscar algún elemento.

 

·         Visibilidad entre las capas. La visibilidad se da desde cualquier capa a la capa inmediatamente inferior. No es posible desde una capa ver a la capa superior ni tampoco saltarse alguna capa hacia abajo y poder acceder a alguna que se encuentre dos o más niveles por abajo, como por ejemplo que interfaz puede acceder a datos directamente. Si bien la propuesta original lo permite, no creo que sea correcto. Esta restricción impuesta generó consultas durante la presentación, la que serán expuestas mas adelante.

 

·         Visibilidad dentro de las capas. Cada capa tiene sus reglas de visibilidad interna. Los casos importantes son la capa de datos y negocio. Es evidente que entre elementos de negocio debe haber comunicación pero no así dentro de los elementos de datos. No es posible que un elemento de datos llame a otro de datos. La razón es simple. La ejecución de algún método de datos que se encuentre dentro de una orquestación realizada desde negocios requiere ciertas validaciones. La orquestación y validación se hace en negocio, por lo tanto,  la capa de datos no puede realizar más acciones que la estrictamente solicitada.

 

·         Ventajas y desventajas de las versiones monolíticas, de dos capas y de tres. Si bien se puede argumentar que desarrollar aplicaciones monolíticas requiere menos tiempo y que en la mayoría de los casos funcionan más rápido, las desventajas que aparecen hacen que no sea factible para aplicaciones de un tamaño importante. En el caso de aplicaciones monolíticas no es posible distribuirla entre varias máquinas, para obtener mejor rendimiento. Las aplicaciones de menos de 3 capas requieren largos y costosos tiempos de mantención o modificación.

 

Algunas de las preguntas que nos llevan a reflexionar sobre la arquitectura están presentadas acá. Las respuestas son equivalentes a las entregadas en la charla, pero se han extendido para su mejor comprensión.

 

Pregunta 1. ¿Si tengo que realizar búsquedas con varios parámetros, pero que no necesariamente se ejecutan en el mismo formulario de UI, donde algunas veces ocupo algunos y en otras ocasiones otros, como debo implementar las funciones de negocio y datos?

 

Respuesta. Estas opciones se nos presentan en la capa de presentación, por lo que debiera ser resuelta en ese mismo lugar. Para eso existe una división en la capa de presentación llamada componentes de proceso de UI (UIPC). La capa de negocios debiera presentar un único método de búsqueda con un set de parámetros fijos o algún parámetro más poderoso parecido a una entidad. La UIPC será la encargada de armar este set de parámetros o esta entidad dependiendo de los datos que posea para esa ejecución específica y posteriormente realizar la llamada a negocio.

 

La capa de negocios no debiera presentar más de una función o método de búsqueda ya que lo que se está realizado, independiente de la cantidad de parámetros, es una ejecución de una regla de negocio (buscar), y que es idéntica en todos los casos. El resto, sería duplicar código y mantenciones, y lo que se busca acá es lo contrario. Pensar en varias funciones de negocio con distintos parámetros de entrada es exactamente de lo que estamos hablando, pero el que debe presentar las funciones es la UIPC, no negocio. Delimitación de responsabilidades.

 

Pregunta 2. ¿Si debo ejecutar un reporte que no es más que una llamada a la base de datos, por que debiera implementar la capa de negocios, si no cumple ninguna funcionalidad?

 

Respuesta. Si bien la pregunta nos puede llevar a pensar que nuestra capa de negocios no es necesaria acá, hecho que justificaría el poder llamar de la interfaz directamente a datos (conversado con anterioridad), debemos fijarnos en el esquema inicialmente presentado y observar las zonas grises de la izquierda. Una de ellas es seguridad. A mi juicio no es posible que la UI acceda a datos sin realizar al menos ciertos chequeos de permisos para poder hacer lo que está tratando de hacer. Como los permisos de ejecución van desde permisos para la comunicación existentes en el Framework hasta la seguridad que hemos desarrollado especialmente para nuestra aplicación, sí se justifica la existencia de la capa e negocios, ya que debe realizar estas validaciones. Preguntémonos, ¿Puede este usuario ver este reporte?, ¿Quién debiera resolver esto?. Delimitación de responsabilidades.

 

Pregunta 3. ¿Qué sucede si necesito que una entidad de negocio se comporte a veces como clase y otras como XML?

 

Respuesta. Una opción a realizar es definirla tanto como clase para que sea utilizada en los casos que es necesario que se comporte así, como también definirla como XML y que se comporte de esa forma cuando sea requisito. Esto nos lleva a contradecirnos en cierta forma. Estamos duplicando código, generando mantención adicional en el futuro y provocando  posibles inconsistencias durante la ejecución de la aplicación. Eso se debe a que es necesario mantener sincronizada ambas versiones. La solución definitiva es implementar en la entidad la opción de serializarse y deserializarse hacia y desde XML. Si bien requiere codificación adicional solucionamos todos los problemas mencionados con anterioridad.

 

La siguiente pregunta no es de arquitectura, pero es bueno incluirla.

 

Pregunta 4. ¿Cual es una buena forma de separar los proyectos?

 

Respuesta. El aplicar la arquitectura no depende de cómo se armen los proyectos. Se puede tener uno o muchos. Todo dependerá de algunos criterios y necesidades. Yo veo tres formas de armar los proyectos o las soluciones. Todas tienen ventajas y desventajas, y dependen de la calidad de los equipos con que se va a desarrollar, del tamaño de la aplicación y de la distribución que se vaya a hacer en producción, es decir, sobre cuantas máquinas correrá mi aplicación.

 

Una opción es tener cuatro proyectos, uno para la UI, otro para Negocio, otro para Datos y el último para Entidades. Las ventajas de esta forma es que si es necesario distribuir en varias máquinas tu aplicación, puedes dejar negocio en una, datos en otra y la UI en otra u otras (granja de servidores). Además tienes menos proyectos y se evitan las posibles relaciones circulares que aparecen en las otras modalidades. Como desventaja, se debe considerar el tamaño de la aplicación. Si ésta crece mucho, los tiempos de compilación pueden llegar a crecer lo suficiente (2 minutos) para ralentizar por completo a un área de desarrollo. Además, si hay muchos desarrolladores con los mismos proyectos, al hacer cambios sobre estos, los demás se ven afectados (incluso usando Source Safe).

 

Una segunda opción es dividir tu aplicación en zonas funcionales o módulos. Para cada módulo tener dos proyectos. Uno con la UI y otro con los tres restantes. Se requiere que idealmente estén separados en carpetas y namespaces como Negocio, Entidad y Datos, y así estar listo para llevar esta modalidad a cualquiera de las otras dos en caso de ser necesaria. La ventaja es que los desarrolladores al trabajar en un módulo tienen mejores tiempos de compilación y no están sujetos a los cambios que puedan hacer los desarrolladores en los otros módulos, o al menos se minimizan los casos. Como desventaja es que no se pueden distribuir en varias máquinas. Puede ocurrir además que un módulo A requiera al B y el B al A también, produciéndose una referencia circular.

 

La tercera opción es una mezcla de la primera y la segunda. Se dividen cada uno de los módulos mencionados en la opción dos en los cuatro proyectos mencionados en la opción uno. Con esta división se tienen las ventajas del primero y del segundo, pero también algunas desventajas. Pueden existir referencias circulares entre los módulos como tener que manejar directa o indirectamente un número muy alto de proyectos. Se minimizan así los tiempos de compilación, pero se agregan tiempos administrativos.

 

 

 

Algunas preguntas que hubiese sido interesante escuchar.

 

Pregunta. ¿Dónde se registra, cómo y quién consume un web service en una aplicación? Respuesta. Esto lo veremos en la próxima charla.

 

Pregunta. ¿Qué ventajas tengo con esta arquitectura si debo manejar más de un modelo de datos? Respuesta. Esto lo veremos en la próxima charla.

 

Patrick Mac Kay. Octubre 2004.

 

One thought on “Arquitectura de aplicaciones y servicios”

  1. I would like more information about the Capa de Negocios. My name is Claudia and I am from Bolivia . I am a student of system ingeneering . I would like too about of abstract data

    Help me please. Write me

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>