Introducción

En esta unidad se presenta el concepto de Back-end, en donde se identifica la capa de lógica de negocio y la capa de acceso a datos, las cuales se conceptualizan siguiendo los lineamientos definidos en la arquitectura.

En lo referente a la capa de acceso a datos, se estudian las alternativas disponibles para el almacenamiento de la información de la aplicación en una base de datos, identificando las diferentes soluciones de integración, dependiendo el tipo de base de datos seleccionada.

Finalmente se profundiza sobre tecnologías java y uno de los frameworks back-end más recientes: node.js, los cuales proveen funcionalidades y características que facilitan la construcción del back-end, así como la integración con el correspondiente front-end.

Propósitos de aprendizaje

Propósito general

Proporcionar los principios de arquitectura y diseño que le permitan al estudiante implementar las funcionalidades correspondientes al procesamiento y almacenamiento de información por parte de las aplicaciones web (back-end), así como identificar cuáles tecnologías son las más adecuadas para cumplir con los criterios establecidos por el usuario.

Propósitos específicos

  • Dar apoyo al estudiante para que pueda establecer cuáles son las características y funcionalidades de las tecnologías que actualmente se usan en la implementación de las capas de lógica de negocio y acceso a datos de una aplicación web.
  • Transmitir al estudiante la información y conocimiento requeridos que le permitan construir el back-end de una aplicación web, aplicando mejores prácticas, tecnologías actuales y respetando los lineamientos definidos en la arquitectura de la misma.
  • Proporcionar al estudiante las herramientas que le permitan integrar de manera adecuada el back-end con el correspondiente front-end, mediante la aplicación de lineamientos y mejores prácticas.

Enfoques para construcción de Back-end

El back-end de una aplicación en comparación al front-end, suele tener un nivel mayor de complejidad, dado que es el encargado de procesar los datos y almacenar la información de manera tal que se pueda tener acceso a ella en tiempo y forma. El procesamiento puede requerir de algoritmos complejos y de interacción con servicios y/o aplicaciones de terceros. Por lo anterior, el back-end suele tener más componentes y requerir de otras habilidades.

Definir la arquitectura del back-end es una de las decisiones más importantes en la etapa de diseño de la aplicación, en la cual se deben definir lineamientos y aplicar mejores prácticas para asegurar que al final de la implementación, la aplicación cumpla con ciertos atributos de calidad.

Ahora bien, teniendo estos conceptos en mente, vamos a hablar de diferentes tipos de arquitecturas para la implementación del back-end, las cuales han ido evolucionando a través del tiempo y han estado estrechamente relacionadas con la evolución de la infraestructura tecnológica y las plataformas de software base (Sistemas Operativos, Motores de Bases de Datos, etc.).

Tanto el front-end como el back-end requieren de diferentes habilidades y herramientas que le exigen a los desarrolladores adquirir y/o fortalecer cierto tipos de capacidades. El front-end tiene un alto enfoque en diseño gráfico y usabilidad, el back-end requiere de algoritmos e integración de componentes de diferentes tecnologías. Sin embargo, los dos son partes de un todo, que deben estar cuidadosamente elaborados e integrados para lograr una aplicación web de calidad.

Enfoques para construcción de Back-end

Arquitectura monolítica

La arquitectura monolítica en su definición original, plantea el sistema o aplicación como un grupo de funcionalidades implementadas en un único módulo o componente, en donde no se identifican capas y existe un alta dependencia entre dichas funcionalidades.

Con la aparición de los computadores personales y la computación distribuida se hizo necesario plantear un esquema más modular, y se evoluciona hacia una arquitectura multicapa, siguiendo patrones como el MVC, que estudiamos en la unidad 1.

Una de las principales ventajas de la arquitectura multicapa es la separación de responsabilidades entre componentes, de tal manera que los componentes de una capa, solo se preocupan por implementar la lógica que pertenece a dicha capa. Esto se apoya en el concepto de aislamiento de capas, el cual busca, que en cada una de estas, se hagan modificaciones, sin tener que afectar las otras.

Otro tema a tener en cuenta, es el crecimiento o escalamiento. Este tipo de aplicaciones pueden llegar a ser difíciles y costosas de escalar, existen esquemas de escalamiento en donde se replica la aplicación en múltiples nodos. También es posible desplegar algunas de las capas en nodos físicamente diferentes; sin embargo, escalar alguna funcionalidad de manera individual, es casi imposible. (Krochmalski, 2017).

Normalmente en las arquitecturas monolíticas, el equipo de desarrollo se casa con un stack de tecnologías, como lo son los grupos de tecnologías Java o .Net, haciendo que el crecimiento de la aplicación sea totalmente dependiente de estas tecnologías. (Krochmalski, 2017).

Enfoques para construcción de Back-end

Arquitectura orientada a servicios

Con el avance de las tecnologías de la información y su creciente uso en el mundo empresarial, se hizo necesario abordar el diseño de los sistemas de información, desde otros puntos de vista, para facilitar su implementación y administración, así como disminuir costos.

Es aquí donde entra a jugar un papel importante la arquitectura orientada a servicios o SOA (Service Oriented Architecture); donde el primer punto a resaltar, es que SOA es una mejor práctica a implementar en entidades u organizaciones que tienen diferentes tipos de aplicaciones y/o sistemas soportando sus procesos de negocio.

Para lograr que estas soluciones tecnológicas apoyen a la organización en la consecución de sus objetivos misionales y estratégicos, es muy importante definir y adoptar una arquitectura empresarial, la cual se compone de cuatro dominios: negocio, aplicación, información y tecnología.

Interesante, pero ¿qué tiene que ver esto con SOA? Bien, pues la arquitectura orientada a servicios es una práctica que las organizaciones pueden implementar para definir, organizar y mantener su arquitectura empresarial.

De los protocolos y tecnologías para acceso remoto, no todos ofrecen la independencia tecnología prometida, que permita, por ejemplo, que un servicio construido con tecnología java, puede ser consumido por un cliente construido con tecnologías .Net. En esta sección nos enfocaremos en dos de las tecnologías más utilizadas actualmente, para la implementación de servicios, que aseguran independencia de lenguajes y plataformas, así como escalabilidad, SOAP y REST.

En este punto, es inevitable preguntarse ¿cuál de las dos alternativas es mejor?, en la siguiente tabla encontraremos las principales diferencias, que pueden ayudar a tomar la decisión, teniendo siempre presente las necesidades y condiciones de los usuarios.

La adopción de una arquitectura orientada a servicios a nivel empresarial, tiene muchos desafíos, entre ellos se encuentra el manejo de transacciones, la seguridad, la disponibilidad, el mantenimiento de los contratos, etc. Sin embargo, en contra prestación, la plataforma tecnológica crecerá de manera más organizada, las aplicaciones serán más confiables y robustas, y la organización percibirá de manera más contundente los beneficios de la inversión en tecnología. De acuerdo con lo anterior, a continuación se presenta un ejemplo de una arquitectura orientada a servicios en una organización con un tamaño importante.

Material
de apoyo

Enfoques para construcción de Back-end

Arquitectura de microservicios

El término arquitectura de microservicios se ha utilizado para describir una nueva manera de diseñar aplicaciones como conjuntos de servicios que se despliegan de manera independiente. (Fowler, 2017).

Sin embargo, definir el nivel correcto de granularidad, es decir qué tantas funcionalidades u operaciones agrupar en un único servicio, no es tarea fácil. Si el arquitecto define un servicio con granularidad muy fina, puede tener impacto en el desempeño, al requerir llamar varios servicios para completar un requerimiento de negocio, así como en el manejo de transacciones, al tener que incluir varios servicios dentro de una misma transacción. (Richards, 2016)

Por otro lado, hablamos de autonomía. Es decir que el microservicio es una entidad autónoma, que puede desplegarse y escalarse como un servicio independiente, para lo cual dicha arquitectura se basa en el principio de “compartir lo menos posible”, aunque en algunos casos esto implique repetir código o funcionalidad. Veamos las principales características de los microservicios, de acuerdo con Newman (2015) y Torres (2015)

La arquitectura de microservicios es la propuesta desde el área de ingeniería de software para aprovechar los avances en la computación en la nube (Cloud Computing) y las necesidades expuestas por IoT, por ejemplo, aprovechando la primera, un microservicio puede ser desplegado en un esquema de plataforma como servicio (PaaS – Platform as a Service).

Para finalizar, a continuación, presentamos un resumen de las principales características de cada uno de los tipos de arquitectura que hemos estudiado hasta el momento.

Actividad de aprendizaje

Actividad de Aprendizaje

De acuerdo con lo estudiado hasta este punto, relaciona las columnas de los principios de algunas de las arquitecturas vistas.

Capa de lógica de negocio

La capa de lógica de negocio es la columna vertebral de la aplicación, implementa los algoritmos que soportan los procesos del negocio, así como los cálculos y transformaciones, que permiten interactuar con las otras capas y hacer que la aplicación funcione. Así mismo debe atender ciertos requerimientos no funcionales, relacionados con el desempeño, seguridad, entre otros.

Esta capa debe enfrentarse al desafío de implementar la lógica que modela los procesos de negocio que soportan los objetivos misionales y estratégicos de las organizaciones del mundo real. (Esposito & Saltarello, 2008).

A continuación, veremos más en detalle las responsabilidades de cada uno de estos componentes.

Capa de lógica de negocio

Diseño de la capa de lógica de negocio

Existen patrones y por supuesto mejores prácticas, que ayudan en el diseño de la capa de lógica de negocio o capa media (middleware) de una aplicación web. Estos pueden ser:

  • Modelos de dominio.
  • Reglas de negocio.
  • Proceso de negocio.
  • Servicios.
  • Seguridad.
  • Auditoria y trazabilidad.
  • Desempeño.

Material
de apoyo

Capa de lógica de negocio

Implementación de la capa de lógica de negocio

En el mercado existen tecnologías, herramientas y web frameworks que se basan en patrones y buenas prácticas, que facilitan la implementación de la capa de lógica de negocio y que de cierta manera ayudan a cumplir con la arquitectura definida.

En este punto es conveniente hablar del despliegue de nuestra aplicación web, el cual puede realizarse de dos maneras, distribuido y no distribuido.

En la interactividad anterior se observan dos componentes, el servidor de aplicaciones y el servidor web, hablemos un poco sobre este tipo de servidores y cómo podemos hacer uso de estos. Cabe resaltar que la mayoría de servidores de aplicaciones, tienen incluido un servidor web, para el manejo del contenido estático.

Ahora, veamos las herramientas y tecnologías que nos pueden ayudar a resolver muchas de las necesidades de nuestra aplicación web.

Capa de acceso a datos

A este punto de la evolución en las tecnologías de la información, cualquier aplicación productiva por pequeña que sea, requiere almacenar o persistir de manera permanente los datos que maneja. Estos pueden ser: parámetros, estado de la aplicación, datos transaccionales capturados y/o procesados por la aplicación, entre otros.

Existen dos maneras de persistir los datos de una aplicación: en sistemas de archivos o en bases de datos. Cabe resaltar, que esta es una de las decisiones más importantes dentro de la definición de la arquitectura de la aplicación.

Ahora bien, la capa encargada de conectarse, guardar, actualizar, borrar y consultar información en la base de datos, se le llama capa de acceso a datos. Una capa de acceso a datos bien diseñada, va a ser determinante para el mantenimiento y evolución de la aplicación.

Siguiendo el principio de bajo acoplamiento, la implementación de la capa de acceso a datos debe tener en cuenta una serie de parámetros, los cuales se desarrollan en la siguiente interactividad.

En las dos próximas secciones revisaremos el diseño y la implementación de la capa acceso de datos, enfocándonos en el uso de bases de datos relacionales, por ser las más utilizadas actualmente.

Como lo mencionamos al iniciar la sección, hay diferentes tipos de bases de datos, las relacionales, apropiadas para el almacenamiento de datos estructurados, y las no relacionales o Non-SQL, que se clasifican en: Documentales, orientadas a columnas, basadas en grafos y de clave-valor; entre el primer grupo se encuentran: Oracle, Microsoft SQL Server, DB2, MySQL, PosgreSQL, en el segundo grupo sobresalen MongoDB, Cassandra, DynamoDB e Infinite Graph.

Material
de apoyo

Capa de acceso a datos

Diseño de la capa de acceso a datos

El diseño de la capa de acceso a datos, puede abordarse desde dos perspectivas: la construcción de sentencias SQL o la construcción de procedimientos almacenados y funciones.

Ahora bien, existen patrones de diseño que podemos seguir para implementar una capa de acceso a datos, que cumpla con la independencia y bajo acoplamiento deseado.

En la industria, existen diferentes propuestas que se basan en la implementación de estos patrones, uno de ellos es DAO – Data Access Object que hace parte de los patrones sugeridos como buena práctica dentro del diseño de aplicaciones J2EE (Java Platform Enterprise Edition).

El patrón DAO se basa en los principios de los patrones Table Data Gateway y Data Mapper, buscando total independencia con la tecnología que gestiona el acceso a datos, así como flexibilidad, en caso de que la aplicación utilice diferentes fuentes de datos (bases de datos relacionales, no relacionales, sistema de archivos, etc.).

Capa de acceso a datos

Implementación de la capa de acceso a datos

Basados en los patrones de diseño presentados anteriormente, y respecto a las características que debe cumplir la capa de acceso a datos, a continuación mostraremos dos tipos de tecnologías que se pueden usar para implementar el componente que se comunica directamente con la fuente de datos.

Las bases de datos relacionales son comúnmente llamadas Bases de Datos SQL, por ser este el lenguaje estándar que se utiliza para su creación, administración, operación y mantenimiento.

Para optimizar el manejo de conexiones a la base de datos, existe una técnica llamada pool de conexiones (Connection Pooling), la cual reduce el número de conexiones que deben permanecer abiertas. El pooler es el dueño de las conexiones físicas y se encarga de mantener un conjunto de conexiones activas en un pool. Cuando la aplicación solicita abrir una conexión, el pooler verifica si hay una conexión activa disponible y la retorna en vez de abrir una nueva conexión. Cuando la aplicación cierra la conexión, el pooler la devuelve al conjunto de conexiones activas en vez de cerrarla; la conexión devuelta queda lista para ser reutilizada.

Esta técnica ayuda a gestionar el número de conexiones y a optimizar tiempos, ya que establecer una conexión a la base de datos requiere de varios pasos que consumen tiempo, por lo que abrir y cerrar conexiones frecuentemente no es eficiente. (Microsoft, 2017).

Actividad de aprendizaje

Actividad de Aprendizaje

Resuelve el siguiente crucigrama con los conceptos fundamentales estudiados en la capa de acceso de datos.

Herramientas para implementación Back-end

En esta sección, presentaremos dos tecnologías back-end, que tienen enfoques diferentes y que se pueden utilizar dependiendo de las características y requerimientos no funcionales de nuestra aplicación web.

Sin embargo, antes de profundizar en las tecnologías mencionadas y una vez revisados los diferentes enfoques y el diseño del back-end, vemos algunas opciones de integración entre back-end y front-end, las cuales dependen del tipo de arquitectura de referencia elegida para la aplicación.

Herramientas para implementación Back-end

Spring Framework

Spring es un framework de aplicación open source, basado en plataforma Java, que provee un modelo de programación y configuración para interconectar las diferentes capas de la aplicación, lo que les permite a los desarrolladores concentrarse en los temas propios de la capa de lógica de negocio de la aplicación. (Rajput, 2017).

Spring está basado en el modelo de programación POJO (Plain Old Java Object) y hace uso de patrones como la Inyección dependencias y la programación Orientada a Aspectos (AOP).

El patrón de Inyección de dependencias busca disminuir el acoplamiento entre los objetos de la aplicación, para lo cual propone que un tercero sea el encargado de proporcionarle las dependencias al objeto en el momento en el que se crea, por lo que el objeto no es responsable de crear o buscar sus dependencias. En tal sentido, se invierte la responsabilidad en cuanto a la manera en la que un objeto obtiene la referencia a otro objeto.

La programación orientada a aspectos (AOP), por su parte, Spring la usa para proporcionar aspectos declarativos tales como manejo de transacciones, logging, auditoría, manejo de eventos, seguridad, entre otros. (RV, Soni, & Ganeshan, 2017)

Los aspectos mencionados anteriormente, como lo vimos en la sección de capa de lógica de negocio, se pueden modelar como un conjunto de servicios transversales a los otros componentes de la aplicación.

Ahora bien, a continuación se presenta los módulos que conforman el core de Spring, de acuerdo con el gráfico principal de esta pantalla.

Con base en el core de Spring, el framework ofrece más productos. Entre ellos se encuentran: Spring MVC

  • Spring Webflow
  • Spring Boot
  • Spring Web Services.
  • Spring Security
  • Sping Batch
  • Spring Mobile
  • Spring Social
  • Spring Integration
  • Spring Data: Para uso de bases de datos NoSQL

Material
de apoyo

Herramientas para implementación Back-end

Node.js

Node.js es un entorno de ejecución basado en el motor V8 de Google, creado para interpretar JavaScript. Ustedes se preguntarán ¿Cómo puede ser que JavaScript se utilice en Back-end?, pues JavaScript ha resultado ser un lenguaje muy versátil que se utiliza desde el browser, hasta el lado servidor, incluyendo las aplicaciones móviles.

Node.js es una tecnología relativamente nueva que ha ganado adeptos en los últimos tiempos, fue liberada en 2009 por la fundación Node.js, y tiene una comunidad bastante activa. Las características presentadas en el gráfico principal hacen que Node.js tenga un excelente desempeño en el manejo de conexiones concurrentes, por lo que es usado comúnmente en la construcción de aplicaciones web con requerimiento de tiempo real (real-time app), y APIS REST. Sin embargo, también pueden construirse aplicaciones MVC.

Node.js tiene una librería core, responsable de manejar el acceso al disco y a la red, y se le pueden adicionar módulos (paquetes o librerías) a través de npm – node package manager, el cual se encarga de manejar las dependencias e instalar los módulos en el servidor, extendiendo sus capacidades. Incluso podemos construir nuestros propios módulos para adicionarlos al servidor.

En el siguiente video, se puede observar cómo crear un servidor en node.js, publicar un servicio REST y consumirlo desde un front-end ligero.

Es inevitable comparar la alternativa propuesta por Node.js, frente a los servidores de aplicaciones convencionales, de los que hablamos en secciones anteriores. Sin embargo, es importante aclarar que la selección de una u otra opción, va a depender de las necesidades de la aplicación, como ya lo comentábamos.

Actividad de aprendizaje

Actividad de Aprendizaje

A continuación se presentan dos casos para la realización de un back-end. Estúdialos y pon a prueba tus conocimientos.

Material
de apoyo

Resumen

En la parte inicial de la unidad, exploramos diferentes enfoques arquitectónicos para la construcción del back-end, que están estrechamente relacionados con la evolución de las tecnologías a nivel de hardware y su correspondiente respuesta desde el área de ingeniería de software. Analizamos las principales características, que nos ayudan a identificar cuál es la opción más adecuada como arquitectura de referencia, para el diseño de nuestra aplicación web, de acuerdo con los requerimientos funcionales y no funcionales del usuario.

En las siguientes secciones, profundizamos sobre aspectos de diseño e implementación de las capas de acceso a datos y de lógica de negocio, identificando patrones de diseño y estrategias para abordar su implementación, incluyendo las alternativas de integración entre éstas.

Posteriormente, se describen dos escenarios de integración entre back-end y front-end, que nuevamente dependen de la arquitectura de referencia seleccionada y de las necesidades funcionales y no funcionales definidas para la aplicación.

Actividad de aprendizaje

Actividad de Aprendizaje

Continuando con el ejercicio que hemos venido desarrollando en el diseño y construcción de una aplicación web, en esta fase se implementará esta aplicación. Lee atentamente y realiza los entregables.

Bibliografía ()

  • Christudas, B. A., Barai, M., & Caselli, V. (2008). Service Oriented Architecture with Java. Packt Publishing.
  • Erl, T. (2016). Service-Oriented Architecture: Analysis and Design for Services and Microservices. (2da ed). Prentice Hall.
  • Esposito, D., & Saltarello, A. (2008). Microsoft® .NET: Architecting Applications for the Enterprise. Microsoft Press.
  • Fowler, M. (2002). Patterns of Enterprise Application Architecture. Estados Unidos: Pearson.
  • International Organization for Standardization - ISO. (2011). ISO/IEC 25010 - Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) -- System and software quality models.
  • Krochmalski, J. (2017). Docker and Kubernetes for Java Developers. Packt Publishing.
  • Meck, B., Young, A., & Cantelon, M. (2017). Node.js in Action (2da ed). Estados Unidos: Manning Publications.
  • Newman, S. (2015). Building Microservices. O'Reilly Media, Inc.
  • Oppel, A. J. (2009). Databases: A Beginner's Guide. McGraw-Hill Education.
  • Rajput, D. (2017). Spring 5 Design Patterns. Packt Publishing.
  • Richards, M. (2015). Software Architecture Patterns. Estados Unidos: O'Reilly Media, Inc.
  • Richards, M. (2016). Microservices vs. Service-Oriented Architecture. Estados Unidos: O'Reilly Media, Inc.
  • RV, R., Soni, R. K., & Ganeshan, A. (2017). Spring: Developing Java Applications for the Enterprise. Packt Publishing.
  • Walls, C. (2014). Spring in Action (4ta ed). Estados Unidos: Manning Publications.

Referencias Web