Revisamos completamente cada artículo de nuestro espacio con el objetivo de mostrarte en todo momento la información con la mayor veracidad y actualizada.
Solución:
- Servicios fundamentales: por ejemplo, base de datos, servicios de directorio, servicios de archivo e impresión, abstracción de hardware. Este nivel se llama cada vez más la plataforma.
- Nivel de dominio comercial: un servidor de aplicaciones como JavaEE que incluye objetos de servicio EJB, DCOM o CORBA. Proporcionar funcionalidad empresarial, aumentando el uso de SOA y Microservicios.
- Nivel de presentación: por ejemplo, Java Servlets/JSP, ASP, PHP. Este nivel incluirá cada vez más WebServices como proxies y adaptadores para servicios de nivel empresarial.
- Nivel de cliente: clientes ligeros como páginas HTML en navegadores y clientes enriquecidos como Java WebStart y Flash.
- En Java EE, es común dividir el nivel de dominio comercial en acceso a datos (beans de entidad) y servicios comerciales (beanes de sesión).
- En una SOA empresarial (Arquitectura orientada a servicios), el ESB (Bus de servicios empresariales) normalmente existiría como un nivel adicional entre los niveles 1 y 2. Puede ser parte de la provisión de la plataforma.
- En Mashups podría tener un nivel de agregación entre el nivel 3 y 4.
El paso a llamarse N-Tier es un reflejo del cambio a arquitecturas cada vez más compuestas por componentes del cliente-servidor más antiguo a primero 3-Tier y luego 4-Tier. La característica definitoria de un nivel es una interfaz claramente definida con una separación de preocupaciones.
Hace cinco minutos leí un artículo de este https://www.nginx.com/blog/time-to-move-to-a-four-tier-application-architecture
El cliente es donde lo lee. Api o el back-end de su aplicación es donde lo ensambla.. Agregación de datos.. Pasa por jsons/xmls de cosas subcontratadas o consultas en su base de datos y, por último, el nivel de servicio es donde realmente hace la consulta. en la base de datos o ejecutar la función en big data o leer ubicaciones de GPS y mapas de google … Así es como lo veo en este caso. Simplemente dividió la capa de datos de tres niveles.
Pero este modelo de N niveles es totalmente abstracto, por lo que puede romper su infraestructura hasta que solo tenga algunas partes lógicamente atómicas. Sigue dividiendo la estructura anterior.
Me inclino por una explicación menos abstracta y más práctica que responda a la pregunta: “¿Cómo y por qué quiero dividir mi sistema en niveles y dónde los coloco en los servidores?”
Esencialmente, cuando crea un sitio web simple que usa una base de datos, ya tiene 3 niveles “listos para usar”:
-
nivel de datos – la base de datos. Pero si está utilizando un caché de memoria de corta duración o un sistema de archivos, entonces podríamos discutir si eso puede considerarse un “nivel” o no.
-
nivel de aplicación: el código que se ejecuta en su(s) servidor(es).
-
nivel de presentación (o cliente): el código que se ejecuta en la máquina del cliente y presenta los resultados al cliente
Ahora, ¿cómo obtenemos el cuarto nivel?
Lo más probable es que no haya necesidad de dividir el nivel de cliente. Está en el dispositivo del cliente y queremos que sea lo más simple y eficiente posible.
¿Podríamos dividir el nivel de datos? He visto algunos sistemas con API alrededor de bases de datos, blobs de Azure, sistemas de archivos, etc. para crear algún subsistema que podría considerarse un nivel. Pero, ¿sigue siendo el mismo nivel de datos (también conocido como nivel de servicios fundamentales) o podemos considerarlo una entidad separada? Y si lo separamos, ¿estará en el mismo servidor físico (o virtual) que nuestra base de datos, para que podamos proteger los datos del acceso directo?
Sin embargo, en la mayoría de los casos, es la capa de aplicación la que se divide.
Una parte todavía se denomina nivel de aplicación. Se convierte en una aplicación web API interna y vive en una zona segura donde puede acceder a la base de datos. Nadie puede acceder a la base de datos directamente, sino solo a través de esta capa de aplicación.
La otra parte se convierte en un consumidor de las API de nivel de aplicación a través de algún tipo de conexión (cliente HTTP, etc.). El consumidor podría llamarse nivel de presentación (confuso, ¿no era lo mismo que el nivel de cliente?), Incluso si solo tiene API JSON y no tiene formatos fáciles de usar.
Pero entonces surge la pregunta: ¿en qué casos nosotros, los desarrolladores, podríamos querer complicarnos la vida y dividir nuestra aplicación web en un nivel de presentación y un nivel de aplicación, en lugar de mantenerlos como capas dentro de la misma aplicación web?
En cargas de trabajo serias, un nivel de aplicación separado podría ser bueno para la escalabilidad o podría ser un requisito de seguridad negar la conectividad de la base de datos al servidor web que está expuesto a los usuarios (incluso los de la intranet).
He visto algunos proyectos ambiciosos que van por 4 niveles desde el principio y luego se maldicen a sí mismos por sobrediseñar las cosas. Debe realizar un seguimiento de esas conexiones internas, seguridad, tokens de autenticación, mantener los sockets bajo control (no abrir una nueva conexión HTTP en cada solicitud), evitar el intercambio accidental de datos de múltiples solicitudes paralelas a través de una instancia de cliente HTTP global creada sin cuidado, etc.
Si estás de acuerdo, puedes dejar un post acerca de qué te ha parecido esta noticia.