Arquitectura del sistema JAVA
Por ejemplo, desarrollar un sistema de motor de sitio web, desde la herramienta de generación de página de inicio personal de Yahoo hasta el sistema de generación automática de sitios web proporcionado por el proveedor de host virtual, así como las características y limitaciones de IBM Webphere Portal, desde la perspectiva del diseño arquitectónico Establece tu propio posicionamiento de producto.
Un buen diseño requiere un escrutinio repetido, y el ciclo de lo simple a lo complejo es una buena manera de garantizar que el diseño sea correcto.
Dado que se eligió la dirección correcta desde el principio, el proceso de implementación posterior del proyecto también verificó esta elección, pero en algunas sutilezas del diseño arquitectónico, la solución aún debe modificarse, que es ese tipo de espiral, que obviamente se logra a través de la filosofía de probar primero y el enfoque de ingeniería XP.
Si posicionamos el diseño arquitectónico en una plataforma tecnológica con un cierto nivel avanzado mundial desde el principio, entonces el desarrollo del proyecto equivale en realidad a hacer la mitad del experimento, es investigación y desarrollo, y hay riesgo tecnológico considerable.
Por lo tanto, al principio, no podemos cumplir con todos los requisitos, sino que debemos adoptar una forma simple de completar el proceso de arquitectura y simplemente completar toda la arquitectura con los requisitos más simples (agregando intervención manual) para probar. la coordinación de varios vínculos técnicos (dos tecnologías muy buenas y muy avanzadas a veces no pueden cooperar) y también para explorar la profundidad de la tecnología. Al mismo tiempo, también podemos descubrir la profundidad de la tecnología y dominar las dificultades técnicas del proyecto. Después de completar este proceso, realizamos las modificaciones importantes mencionadas anteriormente al plan de diseño, enriqueciendo y mejorando el plan de diseño.
El patrón de diseño es una parte importante de la arquitectura
El diseño arquitectónico también es similar a un flujo de trabajo, es dinámico, a diferencia del diseño arquitectónico, que se puede determinar completamente desde el principio, durante el proceso. Durante todo el proceso de diseño de arquitectura del proyecto, existen dos operaciones específicas que pueden garantizar la correcta finalización del diseño de arquitectura, es decir, el patrón de diseño (estático) y la metodología del proyecto de ingeniería (RUP o XP dinámico). Patrones de diseño (estático) y metodologías de proyectos de ingeniería (RUP o XP dinámico).
El patrón de diseño es una parte importante de la estructura del sistema de soporte. Esto es muy similar a la arquitectura. Un edificio necesita establecer su diseño a través del diseño arquitectónico, y se utilizan muchas reglas arquitectónicas en la construcción y los patrones.
Podemos ver claramente la relación entre la arquitectura de un marco como J2EE y los patrones de diseño de software en la clasificación/blueprints/patterns/catalog.html de patrones de planos J2EE.
El diseño arquitectónico es el esqueleto y los patrones de diseño son la carne.
Por lo tanto, con la ayuda de métodos de ingeniería adecuados, se pueden entregar soluciones de diseño más ricas a los programadores para completar aún más el programa. , asegurando así que el diseño arquitectónico del proyecto se complete de forma correcta y rápida.
Tenga siempre en mente los objetivos del diseño arquitectónico
Dado que el diseño arquitectónico se completa de forma dinámica, es muy importante comprender los objetivos del diseño arquitectónico, por lo que a lo largo del proyecto, incluso en cada uno de los pasos, todos debemos tener presente el objetivo general de nuestro diseño arquitectónico, que se puede resumir en los siguientes puntos:
1. Maximizar la reutilización: esta reutilización incluye la reutilización de componentes y el uso de patrones de diseño y otros aspectos.
Por ejemplo, nuestro proyecto tiene registro de usuario y verificación del sistema de permisos de usuario. Este es en realidad un tema general. Cada proyecto solo tiene su propio contenido y algunas diferencias sutiles si lo hemos hecho antes. Si no, desarrollaremos este subproyecto. Durante el proceso de desarrollo, no solo debemos considerar las necesidades del proyecto, sino también completar el proyecto en función del concepto de arquitectura. "uno "Renacimiento y madurez dos veces". Los conceptos arquitectónicos que completan este subproyecto se pueden denominar componentes.
2. Hágalo lo más simple posible: nuestra dirección general al resolver problemas es simplificar problemas complejos. De hecho, este también es el objetivo fundamental del middleware o la tecnología de sistemas multicapa.
Sin embargo, en la implementación específica del proceso de diseño, podemos complicar problemas simples, especialmente el uso de patrones de diseño puede prevenir fácilmente tales errores, por lo que no es fácil hacer que el diseño sea lo más simple y claro posible.
Creo que la implementación específica de cada clase debería reflejar verdaderamente las características esenciales del sistema, porque solo hay una cosa: cuanto más cerca esté tu código de él, significa que tu diseño es simple y claro. Cuanto más simple y claro, mejor será su sistema. La mayoría de las veces, una clase no puede reflejar la esencia de las cosas. Se necesita una combinación de varias clases para coordinarse, por lo que poder utilizar correctamente el patrón de diseño correcto es una máxima prioridad.
Cuando miramos el código de un sistema con un buen diseño arquitectónico, básicamente podemos ver patrones de diseño. La tienda de mascotas es un ejemplo. En otras palabras, un buen diseño arquitectónico se completa básicamente con múltiples patrones de diseño simples y claros.
3. La escalabilidad más flexible: El diseño de la arquitectura debe tener una escalabilidad flexible para que los usuarios puedan realizar desarrollo secundario o desarrollo más específico sobre su arquitectura.
Si queremos tener una escalabilidad flexible, debemos diseñar la arquitectura desde una perspectiva teórica, como el concepto cada vez más popular de flujo de trabajo, porque muchos de nuestros proyectos reales específicos tienen la sombra de un flujo de trabajo. concepto de configuración de permisos de estructura de árbol, que es común en muchos campos.
La estructura de árbol es la forma básica de organizar la información. Los sitios web o las recepciones de ERP que vemos ahora usan menús de árbol para organizar funciones. Luego, cuando diseñamos la arquitectura, podemos diseñar la estructura de árbol y las funciones. Por separado, y la conexión entre ellos se puede conectar a través de los nodos de la estructura del árbol, al igual que podemos colgar varios pequeños obsequios en las ramas del árbol de Navidad, estos pequeños obsequios son lo que queremos lograr Función. Estos regalos son lo que queremos lograr.
Con este concepto, el control de permisos a nivel de usuario, que generalmente es difícil de implementar, también tiene ideas para vincular usuarios o grupos específicos a nodos en una estructura de árbol, logrando así indirectamente el control del usuario. control de permisos de las funciones correspondientes, un diseño de arquitectura tan básico sin duda tiene una escalabilidad muy flexible.
Diseño de arquitectura Java
La arquitectura de software como concepto se refleja tanto en aspectos tecnológicos como comerciales.
Desde una perspectiva técnica: La arquitectura del software se actualiza constantemente con el desarrollo de la tecnología y se basa en la tecnología actual y algunos principios básicos.
Comencemos con algunos principios básicos:
Capas: las capas son una idea importante que se utiliza para reducir la profunda complejidad del software. Así como la sociedad tiene clases, el software también tiene clases.
Principio de modularidad: la modularización es un medio inevitable para eliminar la complejidad y amplitud del software. El propósito de la modularización es permitir que el software divida el trabajo.
El principio de separación de interfaces e implementaciones A medida que la modularización del software continúa mejorando, la programación orientada a interfaces en lugar de la programación orientada a implementaciones puede hacer que un software cada vez más complejo reduzca el acoplamiento entre módulos, facilitando la mejora de los módulos. Partiendo de este principio, el software también se ha estandarizado meticulosamente desde una perspectiva micro.
Hay dos principios más pequeños pero importantes:
El principio de ocultar detalles es obviamente simplificar la complejidad del problema. Ocultar los detalles que son difíciles de ver puede hacer que la estructura del software. más complejo. De hecho, el uso de este principio es muy común. El principio de encapsulación en el lenguaje Java/C++ y el modo Fachada (apariencia) en el patrón de diseño encarnan bien 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 están profundizando gradualmente, y los requisitos de conectabilidad dinámica de capas y módulos también están aumentando. El principio de inversión de dependencia puede verse como una profundización del principio de separación de interfaces. Según el espíritu de este principio, el software ha entrado en la era de las herramientas. Este principio es algo similar a las conocidas Leyes de Hollywood:
Estos principios definen el valor de nuestra arquitectura de software. Sin embargo, después de todo, la arquitectura del software se basa en la tecnología actual. Cada generación de tecnología tiene sus patrones arquitectónicos. Echemos ahora un vistazo a las tecnologías actualmente populares y las arquitecturas actuales que podemos adoptar.
Debido a que la orientación a objetos es actualmente la tecnología de desarrollo más popular, y 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 interfaz de usuario más popular. Por lo tanto, la arquitectura de tres niveles más típica actual se basa en las tecnologías anteriores, con la base de datos como capa de almacenamiento, la capa empresarial orientada a objetos y la web como capa de interfaz de usuario. La arquitectura de tres niveles más típica se basa en la tecnología anterior. Comencemos con la arquitectura de tres niveles:
Dado que la tecnología orientada a objetos no es compatible con la tecnología de bases de datos, agregamos un mapeo bidireccional para administrar O-R en función de la capa de persistencia de datos de la arquitectura estándar de tres niveles. pero siempre ha sido No existe una tecnología de implementación ideal. cmp y la tecnología de entidad bean están a punto de ser eliminadas debido a su complejidad de implementación y funcionalidad futura limitada. JDO e hibernación son las manifestaciones posteriores del mapeo OR, 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 comercial y los cambios frecuentes, debemos tener suficiente tecnología ágil para garantizar nuestra adaptabilidad. En el j2ee estándar El bean de sesión. el sistema es responsable del procesamiento comercial y tiene un buen rendimiento. Sin embargo, el uso del sistema ejb cambia demasiado el modelo de arquitectura comercial, es complejo y costoso y tiene poca portabilidad del código comercial. Como configuración de bean de arquitectura liviana, Spring implementa un hermoso modelo IOC y tiene menos impacto en la arquitectura empresarial, por lo que 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 tiene una implementación relativamente perfecta de la arquitectura MVC. Taperstry también implementa muy bien la arquitectura MVC y adopta un enfoque basado en eventos, que es muy atractivo, pero no es lo suficientemente maduro. Todavía recomendamos struts como base de la interfaz de usuario. capa. Seguimos recomendando el uso de struts como infraestructura para la capa de interfaz de usuario.
Debido a que la capa empresarial es la capa de toma de decisiones más importante en la arquitectura de tres niveles, todavía volvemos a la capa empresarial para analizarla en detalle. 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), servicio de bloqueo concurrente concurrent&&lock, caché del servicio de gestión de grupos, servicio de control de acceso (herramienta: jaas), flujo de trabajo del servicio de control de procesos, servicio de ejecución dinámica IOC, servicio de mensajes serializados (herramienta: jms), servicio de equilibrio de carga, etc. Si no utilizamos servidores de aplicaciones pesados (como weblogic, websphere, jboss, etc.) y componentes pesados (EJB), tendremos que implementar algunos de estos servicios. Aunque la mayoría de las veces no necesitamos todos estos servicios, no es fácil de implementar. Afortunadamente, tenemos una gran cantidad de código de implementación de código abierto, pero adoptar código fuente abierto a menudo no es una tarea fácil.
A medida que xml se vuelve cada vez más importante como transmisión y almacenamiento de información estructurada, el uso de algunas herramientas de manipulación de documentos xml (DOM, Digester, SAX, etc.) también se vuelve cada vez más importante, y con el modo xml Con la madurez de las herramientas de enlace de Java (jaxb, xmlbean, etc.), cada vez más herramientas utilizan xml. ) las herramientas están maduras, usar el modo xml para diseñar el formato de documento xml y luego usar el enlace java para generar java beans se convertirá en el modo de programación principal, y esto permitirá aún más que el centro de datos cambie a xml, por lo tanto en volúmenes de datos pequeños y medianos. , cada vez más Existe una tendencia creciente a utilizar el lenguaje de consulta xquery para bases de datos xml. Recientemente, hay otra tendencia: Microsoft, IBM, etc. han desarrollado una gran cantidad de software intermedio, como (Microsoft Office de Infopath), que puede generar páginas directamente a partir de patrones XML y otras funciones muy prácticas. También existe una amplia gama de aplicaciones de servicios de red, que tendrán un impacto muy significativo en la arquitectura del software.
En cuanto al futuro de la arquitectura orientada a servicios (SOA), es difícil decir con certeza cuándo la arquitectura de tres niveles será cosa del pasado.
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 aspecto J, jboss-aop, aspecto Werks o nanning, tienen sus propios problemas graves: mala mantenibilidad , por lo que será difícil llegar lejos. Quizás sea una buena idea que llegue a los servicios web.
Como lenguajes icónicos del modelo semántico del W3C, es difícil imaginar cuánto impacto tendrán rdf y owl en la arquitectura empresarial actual. Pero si realmente cambia la estructura de la información tan ampliamente como afirma, tendrá un impacto profundo en la arquitectura empresarial actual. Entonces también 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. Puede obtener altos rendimientos
Pruebe la funcionalidad de capas y fragmentación, donde cada módulo se basa en la apariencia supuesta de otros módulos
No puede confiar en datos estáticos para este modo IOC, debe confiar en la interfaz de características de datos (DCI), que es solo una de las formas de implementar DCI
La arquitectura está diseñada para admitir xml en lugar de depender de él. Sin embargo, se puede proporcionar la implementación de una única versión xml.
Desde una perspectiva empresarial: la arquitectura del software debe ser una arquitectura empresarial que refleje profundamente las reglas internas de la empresa. Sin embargo, debido a los frecuentes cambios empresariales. Es difícil que la arquitectura del software permanezca sin cambios, pero los cambios frecuentes en la arquitectura del software no deberían ser la razón para cambios frecuentes y a gran escala en la arquitectura del software.
Hay razones para que una empresa exista de manera estable (temporalmente) durante un período de tiempo. Hay muchos casos de uso dentro de la empresa. Cada caso de uso tiene una regla fija y cada regla tiene varias reglas determinables. Proyectos, cada proyecto se puede medir desde una determinada dimensión. Nuestra arquitectura primero debe asegurarse de que se adapta perfectamente a cada elemento y a cada medición. Muchas arquitecturas fallan porque la medición de algunos elementos ha cambiado la forma en que se miden las cosas. la forma en que se miden las cosas cambia, etc. Muchas arquitecturas fallidas se deben a cambios microscópicos en la forma en que se miden muchos elementos.
Cada caso de uso tiene reglas, y cuando analizamos los casos de uso empresarial, a menudo asumimos que ciertas reglas son a priori, duraderas y estables, pero los cambios comerciales posteriores a menudo demuestran que esta visión es incorrecta y nuestra la arquitectura a menudo paga un precio irreparable por ello. Algunos datos muestran que los cambios de 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 crear plantillas de reglas tanto como sea posible.
Cada caso de uso está asociado a un actor diferente. Cada caso de uso conduce inevitablemente a un cambio en el rol (nota: no un reemplazo, sino una mejora o debilitamiento), por lo que comprender todos los escenarios posibles para el rol es fundamental para el diseño arquitectónico. En nuestra arquitectura actual de tres niveles, los conceptos de roles e interfaces se corresponden exactamente.
En un sistema con muchos casos de uso interrelacionados, considerando que cada caso de uso puede tener diferentes circunstancias especiales, el principio de inversión de dependencia debe usarse tanto como sea posible en el diseño arquitectónico. Si la arquitectura permite utilizar el modelo de mensajería (JMS). Esto reducirá el acoplamiento.
Ahora hablemos del impacto empresarial de la razón de ser de la estabilización empresarial. La existencia es razonable, y este es ciertamente el caso aquí. Las empresas existen gracias a las personas, por lo que preguntar por qué existe la empresa es preguntar a diferentes roles por qué es necesaria y por qué les gusta o no el caso de uso empresarial actual, todo lo cual debe conservarse en el sistema.
Se deben considerar los siguientes principios en el diseño arquitectónico:
Los casos de uso deben ser lo más detallados posible
Los casos de uso deben ser lo más abstractos posible
p>Los roles deben cumplirse Posiblemente independientes
Principio de independencia de medición
Persiguiendo la simplicidad
No se proporcionan ejemplos aquí y se proporcionarán en una actualización futura .
La relación entre el negocio y los patrones.
La relación entre ciertos casos de uso en el negocio suele ser similar a algunos patrones regulares. Pero con el tiempo, poco a poco se desvían de sus patrones anteriores. Este es un fenómeno normal.
Sin embargo, esto tiene altos requisitos para la arquitectura del sistema, porque la arquitectura del sistema debe adaptarse al reemplazo de ciertos modos. Aquí notaremos los cambios en las funciones mutuas de los casos de uso lo antes posible para prepararnos para las actualizaciones de la arquitectura.