¿Qué es la arquitectura Java?
Como concepto, la arquitectura de software se refleja tanto en aspectos tecnológicos como comerciales.
Desde un punto de vista técnico, la arquitectura del software actualiza continuamente su contenido con innovación tecnológica. La arquitectura del software se basa en la tecnología actual y en algunos principios básicos.
Hablemos de algunos principios básicos:
Principio de capas: la capa es una idea clave que se utiliza para reducir la profundidad y la complejidad del software. Así como la sociedad tiene clases, el software también tiene una estructura jerárquica.
Principio de modularización: la modularización es un medio inevitable para resolver la amplitud y complejidad del software. El propósito de la modularización es dividir el software.
Principio de separación de implementación de interfaces Con la mejora continua de la modularización del software, reemplazar la programación orientada a la implementación con programación orientada a la interfaz puede reducir el acoplamiento entre módulos en un software cada vez más complejo, haciendo así que cada módulo sea más fácil de mejorar. Partiendo de este principio, el software también se ha estandarizado cuidadosamente desde una perspectiva micro.
Hay dos principios pequeños pero importantes:
El principio de ocultar detalles es obviamente simplificar problemas complejos y ocultar detalles desagradables, lo que puede aclarar la estructura del software. De hecho, este principio se usa ampliamente. Tanto el principio de encapsulación en el lenguaje Java/C++ como el modo Fachada en el patrón de diseño encarnan el espíritu de este principio.
Principio de inversión de dependencia Con el mayor desarrollo de la estructura del software, las dependencias entre capas y módulos se profundizan gradualmente. Al mismo tiempo, los requisitos para la capacidad de conexión dinámica de capas y módulos también aumentan. El principio de inversión de dependencia puede verse como una profundización del principio de separación de implementación de interfaces. Siguiendo el espíritu de este principio, el software ha entrado en la era de las herramientas. Este principio es algo similar a la conocida ley de Hollywood: no nos llames, nosotros te llamaremos.
Estos principios proporcionan la base para el índice de valor de nuestra arquitectura de software. Pero, después de todo, la arquitectura del software se basa en la tecnología actual. Cada generación de tecnología tiene un modelo arquitectónico. Olvídese del pasado, echemos un vistazo a las tecnologías que son populares hoy en día y las arquitecturas que están disponibles actualmente.
Debido a que la orientación a objetos es actualmente la tecnología de desarrollo más popular, el uso generalizado de patrones de diseño ha hecho que la orientación a objetos madure, y la base de datos es actualmente la estructura de almacenamiento más efectiva y la interfaz web es actualmente la La interfaz de usuario más popular, por lo que en la actualidad, la arquitectura de tres niveles más típica se basa en la tecnología anterior, con la base de datos como capa de almacenamiento, la orientada a objetos como capa empresarial y la web como capa de interfaz de usuario. Comencemos con la arquitectura de tres niveles:
Debido a la falta de coincidencia entre la tecnología orientada a objetos y la tecnología de base de datos, hemos agregado una capa de persistencia de datos a la arquitectura estándar de tres niveles para administrar el mapeo bidireccional O-R, pero Aún no es la tecnología de implementación ideal. Las tecnologías Cmp y Entity Bean están a punto de volverse obsoletas debido a su compleja implementación y sus limitadas perspectivas de funcionalidad. JDO e hibernación son las generaciones más jóvenes de mapeo o, especialmente hibernación, que tiene funciones bastante completas. Recomendado como primera opción para la capa de persistencia.
En la capa empresarial, debido a la creciente carga empresarial actual y a los frecuentes cambios, debemos contar con suficiente tecnología ágil para garantizar nuestra capacidad de adaptarnos a los cambios. En el sistema j2ee estándar, el bean de sesión es responsable del procesamiento comercial y tiene un buen rendimiento. Sin embargo, el sistema ejb cambia demasiado el modelo de arquitectura comercial, es complejo y costoso y tiene poca portabilidad del código comercial. Como arquitectura liviana, Spring tiene una configuración de beans y una hermosa implementación del modo IOC. Tiene poco impacto en la arquitectura empresarial y se recomienda como marco empresarial de nivel medio.
En la capa de estructura del usuario, aunque servlet/jsp/jstl/javaBean puede implementar la arquitectura MVC, después de todo es demasiado tosco. Struts es una implementación perfecta de la arquitectura MVC y Taperstry también es una excelente implementación de la arquitectura MVC. El enfoque basado en eventos es muy atractivo, pero no lo suficientemente maduro. Seguimos recomendando Struts como infraestructura de capa de interfaz de usuario.
Debido a que la capa empresarial es la más decisiva de la arquitectura de tres niveles, todavía volvemos a la capa empresarial para un análisis detallado. En empresas complejas, a menudo necesitamos uno o más de los siguientes servicios básicos: servicio de coherencia de transacciones ácido (herramienta: jta/jts) y servicio de bloqueo concurrente Bloqueo concurrente, caché del servicio de administración de grupos, servicio de control de acceso (herramienta: jta/jts ) :jaas), flujo de trabajo del servicio de control de procesos, servicio de implementación dinámica IOC, servicio de mensajes serializados (herramienta: jms), servicio de equilibrio de carga blance, etc. Si no utilizamos servidores de aplicaciones pesados (como weblogic, websphere, jboss, etc.) y componentes pesados (EJB), debemos implementar algunos de estos servicios nosotros mismos. Aunque en la mayoría de los casos no necesitamos todos estos servicios, implementarlos no es fácil. Afortunadamente, tenemos una gran cantidad de código de implementación de código abierto, pero adoptar código de fuente abierto a menudo no es fácil.
A medida que xml se vuelve cada vez más importante como transmisión y almacenamiento de información estructurada, se utilizan algunas herramientas de manipulación de documentos xml (DOM, Digester, SAX, etc.). ) se está volviendo cada vez más importante y a medida que las herramientas de enlace de Java (jaxb, xmlbean, etc.) maduran. ), el esquema xml se utiliza para diseñar el formato del documento xml.
Luego, el uso del enlace java para generar beans java se convertirá en el método de programación principal, lo que cambiará aún más el centro de datos a xml, haciendo que las bases de datos xml con xquery como lenguaje de consulta se inclinen cada vez más hacia datos pequeños y medianos. Hay una tendencia recientemente, Microsoft, IBM, etc. Se ha desarrollado una gran cantidad de software intermedio, como Infopath de Microsoft Office, que puede generar directamente páginas de entrada a partir de esquemas xml y otras funciones muy prácticas. La aplicación generalizada de servicios web tendrá un impacto muy significativo en la arquitectura del software. En cuanto a las perspectivas de la arquitectura orientada a servicios (SOA) y cuándo la arquitectura de tres niveles pasará a la historia, todavía es difícil sacar una conclusión.
El desarrollo de aop también tendrá un profundo impacto en la arquitectura de software. Sin embargo, en la arquitectura orientada a objetos, ya sea aspectoJ, jboss-aop, aspectoWerks y Nanning, todos tienen sus propios problemas graves: mala mantenibilidad, por lo que será difícil llegar lejos. Quizás sea una buena idea y desempeñará un papel importante en los servicios web.
RDF y OWL son lenguajes simbólicos del modelo semántico del w3c. Es difícil imaginar cuánto impacto pueden tener en la arquitectura empresarial actual. Pero si cambia la estructura de la información tan ampliamente como afirma. Esto tendrá un profundo impacto en la arquitectura del software.
Algunas sugerencias para el diseño arquitectónico:
Intente construir una capa de objetos persistentes completa. Se pueden obtener altos rendimientos.
Intenta superponer y fragmentar cada característica, con cada módulo dependiendo de otros módulos para su apariencia supuesta.
Para implementar el modo IOC, no puede confiar en datos estáticos, sino en la interfaz de funciones de datos. Los datos estáticos son solo una de las formas de implementar la interfaz de funciones de datos.
Xml es un soporte más que una dependencia en el diseño arquitectónico, pero puede proporcionar una única versión de xml.
Desde una perspectiva empresarial, la arquitectura de software debe ser una arquitectura empresarial que refleje profundamente las reglas internas de la empresa. Sin embargo, debido a los frecuentes cambios comerciales, es difícil mantener la arquitectura de software sin cambios. Sin embargo, los cambios comerciales frecuentes no deberían ser motivo de cambios frecuentes a gran escala en la arquitectura del software.
Una empresa tiene razones para su existencia estable durante un período de tiempo (no hablemos de ello por ahora). Hay muchos casos de uso en los negocios y cada caso de uso tiene reglas fijas. Cada regla tiene algunos elementos que se pueden juzgar y cada elemento se puede medir desde una determinada dimensión. Nuestra arquitectura debe, en primer lugar, garantizar una perfecta adaptación a cada proyecto y a cada método de medición. Muchas arquitecturas fallidas se deben a pequeños cambios en los métodos de medición de muchos proyectos.
Cada caso de uso tiene reglas. Cuando analizamos casos de uso empresarial, a menudo asumimos que algunas reglas son a priori y duraderas, pero los cambios empresariales posteriores suelen demostrar que esta opinión es errónea. Sin embargo, a menudo nuestra arquitectura ha pagado un precio irreparable por ello. Una gran cantidad de hechos demuestran que los cambios en las reglas suelen ser la causa fundamental de los cambios en los casos de uso. Por lo tanto, nuestra arquitectura debe adaptarse a los cambios de reglas tanto como sea posible y establecer plantillas de reglas tanto como sea posible.
Cada caso de uso está asociado a un rol diferente. Cada caso de uso es inevitablemente causado por un cambio en el rol (nota: no reemplazo, sino mejora o debilitamiento), por lo que prestar atención a las diversas situaciones posibles del rol es de gran importancia para el diseño de la arquitectura. En nuestra arquitectura actual de tres niveles, los conceptos de rol e interfaz se corresponden exactamente.
En un sistema, muchos casos de uso están interrelacionados. Teniendo en cuenta que cada caso de uso puede tener diferentes casos especiales, intente adoptar el principio de inversión de dependencia en el diseño arquitectónico. Si la arquitectura lo permite, se puede utilizar el modelo de mensajería (JMS). Esto reduce el acoplamiento.
Ahora hablemos del impacto que tienen los motivos de la estabilidad empresarial en el negocio. La existencia es razonable, lo que ciertamente es cierto en este caso. Los negocios existen para las personas, por lo que preguntar por qué existe un negocio significa preguntar a diferentes roles por qué necesitan este negocio y por qué les gusta o no el caso de uso empresarial actual. Todas estas funciones deben conservarse en el sistema. Continuará
Hay varios principios a considerar en el diseño arquitectónico:
Segmentar los casos de uso tanto como sea posible.
Usa casos lo más abstractos posible.
Lo más independiente posible
Principio de independencia de medición de artículos
Buscar la simplicidad
No se proporcionan ejemplos aquí, pero estarán disponibles en actualizaciones.
La relación entre negocio y patrones
La relación entre algunos casos de uso en el negocio suele ser muy similar a algunos patrones regulares. Pero con el tiempo se fue alejando poco a poco del modelo anterior. Esto es normal. Pero esto requiere una arquitectura de sistema muy alta, y la arquitectura del sistema debe adaptarse a algunos cambios de modelo. Aquí, notamos cambios de roles entre casos de uso lo antes posible para prepararnos para las actualizaciones de arquitectura.