현재 참여하고있는 프로젝트는 약 60 개의 포틀릿 개발이 필요합니다. 포틀릿 WAR에는 숫자가 포함될 수 있으므로 WAR에 얼마나 많은 포틀릿을 포함해야하는지 잘 모르겠습니다.WAR에 얼마나 많은 포틀릿을 포함해야합니까?
극단적 인 상황은 WAR에 의해 하나의 포틀릿 만있을 것입니다. 이러한 접근 방식을 통해 포틀릿 독립성을 얻을 수 있지만 배포 아티팩트의 수는 관리하기가 매우 어려울 것입니다. 다른면에서 60 개의 포틀릿에 대해 하나 또는 두 개의 WARS 만 있으면 배포 아티팩트는 두 개 뿐이지 만 하나의 포틀릿에 대한 사소한 변경 사항이라도 많은 포틀릿의 재배포를 의미합니다.
모범 사례가 있습니까? 아니면 권장 사항이 있습니까?
효율성을 높이기 위해 WAR 당 많은 포틀릿을 묶어 야합니다. 실제로 중요한 것은 EAR의 개수이지만 각 WAR에 대해 별도의 EAR을 작성한다고 가정합니다. 따라서 원래의 진술은 여전히 유효합니다.
모든 60을 하나의 WAR로 묶는 것이 극단적이므로 배포 및 재 테스팅 요구 사항에 다른 문제가 발생할 것입니다. 필자는 포틀릿을 논리적으로 비슷한 기능의 그룹으로 패키징하는 것이 좋습니다. 예를 들어, 단일 기능을 제공하기 위해 함께 협력하는 포틀릿은 함께 변경해야하며 함께 변경해야하고 다시 배포해야하는 경우가 많습니다. 분명히 WAR 당 10 개의 포틀릿을 관리 할 수 있으며 앱을 6 개의 EAR로 분할하는 것도 관리할만한 번호입니다. 각 EAR에는 일정한 오버 헤드가 있으므로 개발 라이프 사이클에 대해 생각해보십시오. 일단 EAR이 너무 많으면 dev 서버의 재시작 시간이 터무니 없습니다. 큰 EAR은 작은 것보다 시작할 때 너무 오래 걸리지 않습니다. 이는 배포 시간에도 적용됩니다.
빌드/배포 유연성 (많은 EAR)과 런타임 메모리 사용, 배포 및 재시작 횟수 (EAR 수 감소) 사이의 행복한 매개체가되었습니다.