Java EE 배포 패턴 리소스

Question

Java EE 애플리케이션 배포 패턴에 대한 책/온라인 리소스를 찾고 있습니다. 특히 로컬 인터페이스를 사용할 때 패턴을 알고 싶습니다 (얼마나 많은 노드가 필요한가?). 핵심 질문은 단일 EAR (EJB 및 WAR)을 사용하거나 EJB 및 WAR에 대해 별도의 노드를 사용하는 것입니다.

내가 구한 자원은 쓸모 없으며 EJB2 또는 design patterns에 집중되어 있습니다. EJB3, Spring 또는 Seam과 같은 새로운 기술에 관심이 있습니다.

Answer 1

는 첫째, WebSphere와 같은 응용 프로그램 서버에 하나 (또는 ​​그 이상)의 전쟁과 하나 (또는 ​​그 이상) EJB JAR 파일 및 각 WAR 및 JAR가 다른 서버에 배포 할 수 있습니다 포함하는 하나의 EAR을 가질 수 있습니다. 그러므로 이것이 얼마나 많은 EAR에 관한 질문 일 필요는 없으며 배치 패턴은 별개의 문제입니다. 두 개의 EAR을 생성하기로 결정할 수는 있지만 Java EE 스펙에 의해 강제되는 것은 아닙니다.

둘째, 개발 시간에 당신은 당신의 EJB를가 원격 호출 인터페이스를 노출해야하는지 여부를 결정해야 않습니다. 무엇보다 먼저 디자인 결정입니다. 국지 호출에 적합한 API가 반드시 원격 호출에 적합하지 않을 수도 있습니다. 예를 들어 매우 정교한 API를 사용하면 과도한 메시지 오버 헤드가 발생할 수 있습니다. 이이면 원격 API를 공개하는 경우 API가 굵은 경향이 있습니다.

셋째, EJB 3.0 근본적 원격 배치 패턴이 적절한 지 여부에 관한 결정 아키텍처 및 디자인을 변경하지 않는다. EJB 3.0은 EJB 2.x에 비해 훨씬 단순한 프로그래밍 모델을 제공하므로 코드/XML 작성 횟수가 훨씬 적지 만 결과 배포 패턴 측면에서 처리 또는 네트워크를 통해 흐르는 바이트의 실제 변화는 없습니다 . Spring이나 Seam 개발자가 아니기 때문에 Spring이나 Seam이 똑같을 것이라고 확신 할 수는 없지만 리모트와 같은 근본적인 아키텍처 결정은 기술에 무관심합니다.

그래서 힘이 다른 계층에 웹 및 EJB를 배포하는 당신을 이끌 수있는 어떤

?

동일 위치 : 단순성, 장애 모드 감소, 네트워크 오버 헤드 감소.

분산 EJB/WAR : 별도의 확장 성 (웹 계층 또는 EJB 계층에 별도의 처리 능력을 추가 할 수 있음), 여러 클라이언트 지원, 동일한 비즈니스 논리가 다른 클라이언트에 노출 될 수 있음 (확장 성 요구 사항), 유지 보수가 필요없는 무보수 릴리스 (웹 패치는 EJB를 혼란스럽게하지 않습니다.)