domingo, 28 de septiembre de 2008

Aplicaciones Enterprise

Una aplicación enterprise es un sistema fuertemente orientado a un negocio determinado, que debe cumplir ciertos requerimientos no funcionales. En general, las aplicaciones enterprise:
  • persisten datos de forma masiva
  • suelen ser multiusuarios (varios usuarios pueden acceder de forma concurrente)
  • cuentan con muchísimas interfaces de usuario
  • se integran con otros sistemas
  • presentan disonancia conceptual (usuarios con vistas contrapuestas)
  • tienen lógica de negocio
¿Una aplicación enterprise es aquella que cumple con todas las características recién enunciadas? No necesariamente. En mi opinión personal, la única característica importante e imprescindible es la última. Una aplicación enterprise es aquella que tiene lógica de negocio, por eso empecé el post afirmando que es un sistema fuertemente orientado al negocio y por eso en mucha bibliografía a las aplicaciones enterprise se las suele llamar aplicaciones de negocio (business applications).

En general, que tengamos una lógica de negocio acarrea que debamos guardar el estado (los conceptos o las entidades) de esa lógica para poder recuperarlo en todo momento. También implica que esos conceptos puedan ser mostrados de alguna manera a los usuarios del negocio, a los clientes, y en general, los clientes suelen ser muchos, y suelen ejecutar consultas en paralelo. Así es como un requerimiento no funcional lleva a otro y nos encontramos con que, cuando nos enfrentamos a una aplicación enterprise que va creciendo en tamaño y complejidad, son necesarias casi todas las características antes enumeradas.

Casi se podría decir que cualquier aplicación compleja y grande es una aplicación enterprise. Yo diría que no es tan así, pero tampoco la afirmación está tan lejos de la verdad.

El concepto de aplicación enterprise nació con el fin de modularizar y organizar el desarrollo de aplicaciones complejas de negocio, cuyo número de desarrolladores, analistas, diseñadores crecía exponencialmente al paso que se multiplicaban los requerimientos no funcionales. Como la posibilidad de automatizar negocios cada vez más complejos se hizo posible gracias al escalamiento de hardware y de paradigmas y técnicas de programación más efectivas (como la orientación a objetos y las metodologías de desarrollo), se necesitó una forma de separar lo que es la lógica de negocio (requerimientos funcionales) de lo que es la lógica de la aplicación (requerimientos no funcionales). Entonces comenzaron a surgir algunos frameworks, primero en el mundo de Java, que intentaban lograr esta separación. Surgió la especificación de Sun Microsystems para los Enterprise Java Beans (EJB) y un tiempo después Microsoft se metió en el mercado para hacerle frente con una plataforma bastante más sencilla llamada .NET, pero que demoró mucho en madurar.


Durante demasiados años, tanto la plataforma enterprise de Java (J2EE) como .NET tuvieron muchísimos problemas. Las especificaciones no eran del todo felices y, en el afán de abstraer al programador de los requerimientos no funcionales comunes a todas las aplicaciones enterprise (la lógica de aplicación), las herramientas para diseñar una buena lógica de negocio se vio limitada, brutalmente recortada, logrando que la programación orientada a objetos retrocediera unos cuantos pasos. Hasta se habló de anti-patrones en J2EE y se publicaron varias tesis y artículos al respecto. ¡Pero era lo que había!

Recién hace tres o cuatro años que el panorama está mejorando. No fue hasta que comenzaron a surgir los famosos frameworks livianos (como Spring por ejemplo) que los programadores pudieron volver a aplicar la programación orientada a objetos en todo su esplendor para construir lógicas de negocio más robustas, escalables y parecidas a la realidad. Sun Microsystem tomó muchas de las ideas de los frameworks livianos y lanzó una nueva especificación: EJB 3.0, a la vez que cambió el nombre de su plataforma J2EE a JavaEE.

Arquitectura de 4-tiers

Los requerimientos no funcionales más comunes en una aplicación enterprise son:
  • Bajo Tiempo de Respuesta
  • Alta Interactividad con el Usuario
  • Baja Latencia
  • Muchas Transacciones por segundo (throughput)
  • Alta Carga (número de usuarios concurrentes)
  • Baja Degradación (variación del Tiempo de Respuesta con la Carga)
  • Alta Eficienta (performance)
  • Alta Capacidad (máxima entre el throughput y la carga)
  • Alta Escalabilidad (horizontal: + servidores; vertical: +CPU,+memoria)
  • Alta Disponibilidad o Nivel de Servicio
Para satisfacer este tipo de requerimientos, en general, las aplicaciones enterprise han adoptado un tipo de arquitectura casi estándar, que consiste en dividir el sistema en cuatro capas físicas (tiers):
  • Presentación
  • Acceso al Negocio
  • Negocio o Dominio
  • Persistencia

El Cliente, por ejemplo un browser (si hablamos de una aplicación web) o una ventana gráfica del sistema operativo (si hablamos de una aplicación desktop), accede a la capa de Presentación. La capa de presentación es responsable del formateo de los datos para la visualización y de la interpretación de los comandos del usuario. En la capa de presentación podrían vivir los servlets, por ejemplo, si hablamos de una aplicación web en Java.

Esta capa podría acceder directamente a la capa de negocio o dominio, de hecho muchos autores proponen eso. Pero en realidad, lo más correcto sería contar con una capa (que a veces es muy delgada) entre la de presentación y la de dominio, para que desacople ambas y podamos construir distintas presentaciones que accedan concurrentemente y se abstraigan del uso de la lógica de negocio. Esta capa de la que hablo es la de Acceso al Negocio o Capa de Aplicación o Capa de Servicio (Martin Fowler la llama Service Layer). En la capa de Acceso al Negocio vivirán los casos de uso del sistema, los requerimientos funcionales, los servicios de la lógica de dominio, de la lógica de negocio, que deben ser expuestos. Esta capa tendrá permiso para manipular los objetos de negocio que viven en la Capa de Negocio, en el dominio de la aplicación. Podría decirse que se trata de un facade del dominio.

La Capa de Negocio es la más importante, ya que aquí es donde vive el modelo, donde vive la lógica de negocio y, como antes mencioné, la lógica de negocio es lo más importante en una aplicación enterprise. Prefiero no hablar mucho ahora del dominio ni de la clase de modelos que uno puede insertar ahí dentro, ya que planeo dedicar varios post en el futuro a su construcción y las implicaciones filosóficas y técnicas que ésta acarrea.

Por último, tenemos una capa de Persistencia, cuya función principal es la de desacoplar la aplicación de la base de datos para no depender de un SGBD específico y gestionar el acceso a la misma de forma eficiente. Esta capa debería hacernos menos dolorosa una posible migración futura de base de datos.

Si prestan atención al gráfico de arquitectura pueden ver que la capa de Acceso al Negocio apunta a la capa de Dominio, y a su vez, la capa de Persistencia también apunta a la capa de Dominio. Estas flechas que parecen tan inocentes están simbolizando dependencia. Según cómo el framework implemente la capa de Persistencia, el dominio apuntará a la de Persistencia o al revés. Lo que trata de hacer un ORM como Hibernate, por ejemplo, es invertir la dependencia del flujo normal de tiers para que el dominio no tenga que conocer absolutamente nada de la aplicación. De esta forma, logramos desacoplar por completo la lógica de negocio, para usarla en cualquier otra aplicación o plataforma.

En post futuros profundizaré sobre este tema.