sistema que modulos modularizado modularización modularizacion modularidad ejemplos ejemplo definicion java java-ee web-applications module osgi

que - Aplicación Java para Grandes Empresas-Modularización



modulos en java (5)

Trabajo para una empresa en todo el país, por lo que el software que desarrollamos es a gran escala.

Nuestro sistema central se basa en la web, incluidos los servicios webservices . Actualmente estamos rediseñando todo el proyecto y es momento de comenzar la estructura del proyecto.

Tenemos como 7 módulos web, incluido el proyecto web basado en Struts2 y Spring 3.1 . Un núcleo de servicios Webservice basado en JAX-WS y Spring 3.1

Mi pregunta es cuáles son las mejores prácticas para diseñar la estructura del proyecto y la modularización para un proyecto como este:

Definitivamente usaremos Maven y OSGi si es necesario. Estoy pensando en algo así como

WebProject.war |---Web.xml |--- Libs | |--- Web Module1.jar |--- Web Module2.jar |--- Web Module3.jar |--- Web Module4.jar |--- Web Module5.jar |--- Web Module6.jar WebService.war |---Web.xml |--- Libs | |--- Service.jar |--- Service2.jar EJBProject.jar | |--- module.jar |--- module2.jar

Esto es lo que personalmente tengo en mente, pero estamos buscando algo mejor modularizado para que podamos trabajar e implementar WebModule1.jar sin afectar los otros módulos y el proyecto principal WebProject.war . También con esto queremos que los equipos especializados solo tengan el código de sus proyectos, por lo que si un Equipo debe trabajar solo con Service2.jar en su IDE , solo tendrán el código para Service2.jar y un proyecto de recursos con el otro proyecto. compilado.

Gracias

En función de los requisitos de su proyecto, como el desarrollo de módulos independientes y la actualización en tiempo de ejecución, Maven es la mejor solución. Proporciona un excelente soporte de dependencias y complementos, y parece que todo lo que necesita para su proyecto ya está disponible:

  • Spring / Struts / CXF / etc. artefactos de maven,
  • WAR / JAR / etc. complementos,
  • Los servidores de aplicaciones implementan / prueban plugins, etc.
  • Y solo puede proporcionar artefactos de maven comunes para los equipos que desarrollan solo módulos específicos sin compartir toda la base de código.
  • Maven es compatible con todos los servidores de integración continua (Hudson / TeamCity, etc.)

OSGi. Si desea usarlo, debe observar cuidadosamente su diseño actual e intentar adaptarlo a μServices. En general, tendrá módulos con API, consumidores de API y proveedores de API. Te ayuda a dividir el desarrollo entre los equipos (por ejemplo, uno desarrolla un módulo de consumidor de API, otro - módulo de proveedor de API). Si lo necesita, puede dividir el módulo API consumidor / proveedor en 2+ paquetes OSGi (que son módulos Maven).

Recomiendo leer Kirk Knoernschild '' Arquitectura de aplicaciones Java: Patrones de modularidad con ejemplos que usan OSGi'' . Podría comenzar por modularizar la aplicación antes de migrar a OSGi (y definitivamente invertiría en una buena cobertura de prueba si aún no la tiene).

Si está utilizando la especificación de servlet 3.0, entonces analice el uso de fragmentos web.

En términos de la estructura que has mostrado, yo diría que no anides nada (excepto fragmentos web), los WAR pueden convertirse en WAB (paquete de aplicaciones web, básicamente, un WAR flaco). Aproveche también los μServices de OSGi tanto como sea posible, ahí es donde comienza la diversión =)

Los frameworks OSGi de Enterprise como Karaf y Virgo ofrecen mucho soporte mientras estás a caballo entre la división JEE-OSGi (Equinox y Felix por sí solos son un poco descocados).

Tu estructura se ve bien para mí, que es la estructura típica para la mayoría de los proyectos, una recomendación que daría es versionar tus dependencias, así que por ejemplo, deja que tu proyecto web.war dependa de webmodule1-1.3 decir, de esta manera un final potencialmente diferente los proyectos pueden tener diferentes versiones de jarras dependientes.

Usar maven definitivamente simplificaría la gestión de estas dependencias

Si sus requisitos son reemplazar dependencias en el tiempo de ejecución, entonces sí, tendrá que recurrir a tecnologías como OSGI; sin embargo, si no busca la modularización de tiempo de ejecución, le recomendaría no comenzar con OSGi y mantener la pila más simple.

El aspecto clave de la modularidad es que su módulo sabe tan poco como es humanamente posible para que pueda ser reutilizado en muchos contextos diferentes. Los errores solo ocurren cuando se viola una suposición, minimizar las suposiciones es el mayor asesino de errores. OSGi proporciona herramientas como μservicios que son muy buenos para permitir que las suposiciones permanezcan locales.

Su diseño se parece mucho a un proyecto web, lo cual es incorrecto ya que la mayoría del código que tenemos que desarrollar nosotros mismos debe ser independiente de la tecnología utilizada para presentarlo. Toda esta tecnología es probable que cambie en un futuro próximo, ya que las aplicaciones web se están desplazando rápidamente al navegador, los navegadores se están convirtiendo en clientes gordos otra vez. Es decir, las interfaces REST muy modernas ya se sienten anticuadas si ves lo que está haciendo la mensajería pura. Toda esta volatilidad significa que desea hacer sus módulos lo más desacoplados posible.

Así que nunca vincularé ningún código de dominio a nada que esté acoplado a bibliotecas que estén acopladas a la tecnología web. Estas dependencias transitivas te van a hacer daño en el futuro (cercano). Construyó pequeños módulos desacoplados cohesivos y los usó como bloques de lego para construir sus aplicaciones.