[펌] J2EE 패턴 정리

---

 * 출처

 : http://nya.springnote.com/pages/3991923

---

다루는 내용

• J2EE 플랫폼을 위해 패턴 사용하기
• Best Practice 를 이용하여 애플리케이션 설계
  (특히 J2EE 요소 중 Servlet,JSP,EJB,JMS 4가지 기술에 초점)
• J2EE 플랫폼을 위한 설계/아키텍처 문제 재사용 촉진
• 기존 설계에서 Bad Practice 를 식별하고 리팩토링

 

다루지 않는 내용

• 자바 또는 J2EE 기술로 프로그램을 작성하는 법
• 프로세스나 방법론 제시
• UML 표기법

 

1장. 입문

• J2EE 기술을 배운다는 것과, J2EE 기술로 시스템을 디자인 하는 것은 다름.
• 패턴의 분류 : 디자인 패턴, 아키텍처 패턴, 분석 패턴, 생성 패턴, 구조 패턴, 행위 패턴
• J2EE 패턴은 디자인 패턴과 아키텍처 패턴에 걸쳐있다.

• J2EE 패턴 분류와 목록

  • 프레젠테이션 티어: Intercepting Filter, Front Controller, Context Object, Application Controller, View Helper, Composite View, Service to Worker, Dispatcher View
  • 비즈니스 티어: Business Delegate, Service Locator, Session Facade, Application Service, Business Object, Composite Entity, Transfer Object, Transfer Object Assembler, Value List Handler
  • 통합 티어: Data Access Object, Service Activator, Domain Store, Web Service Brocker

• 패턴 사용의 이점

  • 검증된 해법 활용
  • 공통 어휘 사용 가능
  • 해결 범위를 제한함

 

2장. 프레젠테이션 티어에서 디자인 고려사항과 위험 사례

 

2.1. 프레젠테이션 티어에서 디자인 고려사항

• 세션 관리
• 클라이언트 접근 제어
  - 실습: 뷰에 감시자 Custom Tag 넣기, web.xml에 <security-constraint> 설정과 roles.properties, users.properties 파일
  
• 유효성 검사
• Helper 프로퍼티
  
• 그 외: 보안, 데이터 무결성, 관리 용이성, 확장성

 

2.2. 프레젠테이션 티어에서 BAD PRACTICES

• 제어 코드가 여러 뷰에 존재
• 프레젠테이션 티어 데이터 구조가 비즈니스 티어에 노출
• 프레젠테이션 티어 데이터 구조가 도메인 객체에 노출
• 같은 폼을 중복해서 전송
• 민감한 리소스가 클라이언트에 직접 노출
• <jsp:setProperty>가 자바빈 프로퍼티를 재설정할 것으로 잘못 추정 - 실습: 공백으로 넘어간 session scope 자바빈 프로퍼티는 이전 값이 남아있으므로 reset 필요.
• 팻 컨트롤러를 구현
• 헬퍼를 스클립틀릿처럼 작성 - 실습: 스크립틀릿을 JSTL, Custom Tag, Tag Directory 로 변경

 

3장. 비즈니스 티어에서 디자인 고려사항과 위험사례

 

3.1. 비즈니스 티어에서 디자인 고려사항

• 세션 빈 사용하기 (stateful 빈과 stateless 빈이 있는데 주로 stateless 를 많이 사용) - 실습: @Remote 인터페이스와 @Stateless 클래스 작성하여 만든 jar를 JNDI등록. 클라이언트에서 lookup 하여 빈의 메소드를 실행함.
• 엔티티 빈 사용하기 (EJB3.0에서는 엔티티빈 대신 JPA 사용함) - 실습: @Remote 인터페이스와 Entity Manager 를 가지는 @Stateless 클래스 작성. 그리고 @Table이용해서 Database와 연결한 @Entity 빈 작성. 마찬가지로 jar 를 JNDI 등록. 클라이언트에서 lookup 하여 빈의 메소드를 실행함.
• 엔터프라이즈 빈 원격 참조와 핸들을 임시 저장하기

 

3.2. 비즈니스 티어와 통합 티어에서 BAD PRACTICES

• 객체 모델을 직접 엔티티 빈 모델로 매핑
• 관계 모델을 직접 엔티티 빈 모델로 매핑
• 각 유스케이스마다 세션 빈 하나를 매핑
• 모든 엔터프라이즈 빈 속성을 getter/setter 메소드를 사용해서 노출
• 클라이언트에 서비스 검색 코드를 둠.
• 읽기 전용 객체로 엔티티 빈을 사용
• 작은 단위 객체로 엔티티 빈을 사용
• 종속 객체를 포함한 엔티티 빈 전체를 저장
• EJB 관련 예외가 EJB가 아닌 클라이언트에 노출
• 큰 결과 집합을 반환하기 위해 엔티티 빈 파인더 메소드 사용
• 클라이언트가 비즈니스 컴포넌트로부터 데이터를 모음
• 엔터프라이즈 빈에서 오랜 시간이 걸리는 트랜잭션을 처리
• 상태비유지 세션 빈이 매 호출마다 대화 상태를 재구성

 

4장. J2EE 리팩토링

 

4.1. 프레젠테이션 티어 리팩토링

• 컨트롤러 도입
• 동기화 토큰 도입 - 실습: md5 해쉬코드로 토큰 생성, 토큰유효성을 검사하여 '뒤로가기'로 들어왔거나 잘못된 접근을 하지 않았는지 확인.
• 각기 다른 로직을 지역화 하기 (응집도와 결합도)
• 프레젠테이션 티어에 한정된 세부 구현을 비즈니스 티어로부터 숨기기
• 뷰 안에 있는 포맷 변환 코드 제거하기
• 클라이언트로부터 리소스 숨기기 - 실습: /WEB-INF/ 아래로 웹 리소스를 이동하면 직접 접근 불가능.

 

4.2. 비즈니스 티어와 통합 티어 리팩토링

• 세션 빈으로 엔티티 빈 감싸기
• Business Delegate 도입
• 세션 빈 병합하기
• 엔티티 빈 상호 통신 줄이기
• 비즈니스 로직을 세션 빈으로 옮기기

 

4.3. 일반 리팩토링

• 데이터 접근 코드 분리(dao)
• 티어에 따른 아키텍처 리팩토링
• 커넥션 풀 이용하기

 

2부. J2EE 패턴 목록

 

5장. J2EE 패턴 개요

 

5.1. 패턴이란 무엇인가

• 패턴이란 특정 정황(Context)에서 반복적으로 일어나는 문제(Problem)에 대한 해법(Solution)이다.
• 패턴은 반복하여 적용될 수 있어야 유용한 것이다.

 

J2EE 패턴 상호 관계 - 목록, 문제점과 해결법 정리

• 16개 J2EE 패턴: http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html
• 16개+5개 J2EE 패턴: http://www.corej2eepatterns.com/Patterns2ndEd/index.htm

 

 

6장. 프레젠테이션 티어 패턴

 

6.1. Intercepting Filter 패턴

• 설명: request를 직접 처리 하기 전에 가로채서, 선언적 방식으로 중복되는 전후처리를 한다.

• 전략

  • Standard Filter 전략 - 실습: javax.servlet.Filter 를 implements 하여 필터 클래스 작성, doFilter() 메소드 작성. web.xml에 설정.
  • Custom Filter 전략
  • Base Filter 전략
  • Template Filter 전략 - 실습: javax.servlet.Filter 를 implements 하여 TemplateFilter 클래스 작성, doFilter는 구현하고, 하위에서 구현할 abstract 메소드 작성. 그리고 TemplateFilter 를 상속받아 Filter들을 작성함.
  • Web Service Message 처리 관련 전략 (Custom SOAP Filter, JAX-RPC Filter)

 

6.2. Front Controller 패턴

• 설명: 모든 request를 한 곳으로 보낸다.

• 전략

  • Servlet Front 전략 - 실습: 모든 Form 처리 요청을 특정 FrontController 서블릿 한군데로 넘긴다. 어떤 행동을 할 지 커맨드 파라미터를 함께 넘겨준다.
  • JSP Front 전략
  • Command and Controller 전략 - 실습: 커맨드패턴, 팩토리패턴 적용
  • Physical Resource Mapping 전략, Logical Resource Mapping 전략, Dispatcher in Controller 전략, Base Front 전략, Filter Controller 전략

 

6.3. Context Object 패턴

• 설명: 특정 프로토콜에 한정되는 내용이나 불필요한 데이터를 포함하는 원래 객체 대신, 필요한 데이터만 Context Object로 만들어서 넘김.

• 전략

  • Request Context 전략 (Map, POJO, Validation) - 실습: Map 전략 사용. HttpServletRequest 객체를 넘기는 대신 파라미터 데이터만 Map으로 만들어 넘김.
  • Configration Context 전략 (JSTL configuration, Security Context)
  • General Context Object 전략 (Context Object Factory, Auto-Population)

 

6.4. Application Controller 패턴

• 설명: request를 처리하는 액션 관리와 뷰 관리 컴포넌트를 중앙 집중화 한다.

• 비교: Application Controller 패턴 vs. Front Controller 패턴

  • Front Controller 가 사용자의 request를 한 곳으로 모으는 것이라면, Application Controller 는 받은 request를 처리하는 작업(액션 수행, 뷰 선택)을 한다.

• 전략

  • Command Handler 전략 - 실습: Front Contoller로부터 받은 파라미터에 따라 Command Factory로부터 Command 를 얻어 액션 수행, 뷰 선택을 한다.
  • View Handler 전략
  • Transform handler 전략, Navigation and Flow Control 전략, Message Handling 전략 (Custom SOAP, JAX RPC)

 

6.5. View Helper 패턴

• 설명: View를 만드는 과정에서 제어 로직, 데이터 접근 로직, 포맷 로직을 분리한다. (예를들면 JSP 에서 스크립틀릿 대신 JSTL, Custom Tag 등을 헬퍼로 사용)

• 전략

  • Template-Based View 전략, Controller-Based View 전략
  • JavaBean Helper 전략
  • Customer Tag Helper 전략, Tag File Helper 전략
  • Business Delegate as Helper 전략

 

6.6. Composite View 패턴

• 설명: View를 만들 때 레이아웃을 조합한다. (예를들면 Header/Footer를 일관적으로 붙이는 것)

• 전략

  • JavaBean View Management 전략
  • Standard Tag View Management 전략, Custom Tag view Management 전략
  • Transformer View Management 전략
  • Early-Binding Resource 전략, Late-Binding Resource 전략

 

6.7. Service to Worker 패턴

• 설명: 제어권이 뷰로 넘어가기 전에 프레젠테이션 모델을 가져오도록 제어 로직과 요청 핸들링을 중앙 집중화한다. 뷰는 프레젠테이션 모델에 근거해서 동적 응답을 생성한다. (비즈니스 로직 결과에 따라 View가 선택됨)

• 전략

  • Servlet Front 전략, JSP Front 전략, Template-Based 전략, JavaBean Helper 전략, Customer Tag Helper 전략, Dispatch in Controller 전략

 

6.8. Dispatcher View 패턴

• 설명: 정적 뷰이거나 동적 내용이 거의 없는 뷰, 간단한 애플리케이션을 만들 때만 제한적인 용도로 사용. (정적인 Business Helper 이용)

• 비교: Service to Worker 패턴 vs. Dispatcher View

  • Service to Worker 패턴과는 달리, 뷰에 제어권이 넘어가고 나서 비즈니스 서비스에 대한 호출이 실행된다.

• 전략

  • Servlet Front 전략, JSP Front 전략, Template-Based 전략, Controller-Based 전략, JavaBean Helper 전략, Customer Tag Helper 전략, Dispatch in Controller 전략

 

7장. 비즈니스 티어 패턴

 

7.1. Business Delegate 패턴

• 문제: 클라이언트가 원격 비즈니스 서비스 컴포넌트에 직접 접근하는 경우, 둘 사이의 종속이 심해지고, 작은 단위로 상호작용을 하기때문에 네트워크 성능도 저하되며, 인프라 코드도 사용해야 한다는 문제가 있다.
• 해법: 클라이언트가 직접 비즈니스 서비스를 호출하는 것이 아니라, 사이에 원격이 아닌 것 처럼 사용할 수 있는 Delegator를 둔다. 클라이언트와 비즈니스 서비스 사이의 결합도를 최소화하고, 불필요한 원격호출을 피한다.

• 비교: Business Delegate vs. Session Facade

  • Business Delegate 는 클라이언트 쪽에서, 레이어를 추가하여 서버에서 제공하는 서비스를 그대로 수행함.
  • Session Facade 는 서버 쪽에서, 여러 작은 컴포넌트를 큰 단위로 묶어서 클라이언트에게 서비스함.

• 전략

  • Delegate Proxy 전략 - 실습: 클라이언트에서 ServiceLocator와 EJB Home을 직접 사용하는 대신, Delegate 클래스에게 위임하도록 수정.
  • Delegate Adapter 전략

 

7.2. Service Locator 패턴

• 문제: 비즈니스 서비스와 컴포넌트(EJB, JNDI DataSource 등)를 검색하는 lookup 코드가 반복되어 여러 곳에서 사용되는 경우
• 해법: 싱글톤으로 Service Locator를 만들고 lookup 하는 과정을 캡슐화 한다. lookup 결과를 캐싱 하여 성능도 향상 할 수 있다.

• 전략

  • EJB Service Locator 전략 - 실습: 문자열을 넘기면 EJB Home을 lookup하여 리턴하는 Service locator를 Singleton패턴으로 작성 (Map cache도 사용)
  • JNDI DataSource Service Locator 전략
  • JMS Service Locator, JMS Queue Service Locator, JMS Topic Service Locator 전략, Web Service Locator 전략

 

7.3. Session Facade 패턴

• 문제: 원격 클라이언트가 비즈니스 컴포넌트에 서비스를 직접 요청하면, 작은 단위로 호출하게 되어 네트워크 성능이 저하되고 결합도가 높아지낟.
• 해법: 원격 클라이언트에게 하나 이상의 비즈니스 컴포넌트와 서비스를 EJB 세션빈 같은 데에 모아서 큰 단위로 서비스한다.

• 전략

  • Stateless Session Facade 전략 - 실습: EJB에 userlist 데이터를 가져오는 로직을 담고, 수행함.
  • Stateful Session Facade 전략

 

7.4. Application Service 패턴

• 문제: 여러 컴포넌트에 분산된 서비스를 조합하는 작업을 Business Object에 넣으면 결합도가 증가하고 응집도가 낮아짐. 클라이언트에 비즈니스 컴포넌트를 직접 노출하면 결합도가 증가함.
• 해법: 여러 컴포넌트에 분산되어 있는 관련된 비즈니스 로직 오퍼레이션을 조합하여 하나의 인터페이스로 서비스한다.

• 비교: Session Facade vs. Application Service

  • 중앙 집중으로 관리하는 의미해서 비슷하지만, Session Facade는 비즈니스 로직을 포함하지 않는 단순 래핑이고, Application Service 는 비즈니스 로직을 포함할 수 있다.

• 전략

  • Application Service Commad 전략 (Command 패턴을 사용하여 구현)
  • GoF Strategy Application Service 전략 (Strategy 패턴을 사용하여 구현)

 

7.5. Business Object 패턴

• 문제: 비즈니스 로직과 관계 있는 개념적인 도메인 모델이 필요한 경우
• 해법: 객체 모델을 사용하여 비즈니스 데이터, 비즈니스 로직, 퍼시스턴스 로직을 분리한다.

• 전략

  • POJO Business Object 전략
  • Composite Entity Business Object 전략
• 퍼시스턴스 구현 방법 : 엔티티빈, 커스텀DAO, Domain Store 패턴

 

7.6. Composite Entity 패턴

• 설명: 엔티티 빈을 사용하여 개념적 도메인 모델을 구현하고자 할 때 - 로컬 엔티티 빈과 POJO로 Composite Entity를 구성한다.
• EJB 2.0 대 사용하던 패턴이므로 EJB 3.0에는 사용하지 않는다.

 

7.7. Transfer Object 패턴

• 문제: 티어 사이에 다중 데이터를 전송하는 경우
• 해법: 다중 데이터를 클래스로 모델링하고, 티어 간에는 객체를 주고 받는다.(TO 나 VO 라고도 함)

• 전략

  • Updatable Transfer object 전략, Multiple Transfer Object 전략, Entity Inherits Transfer Object 전략

 

7.8. Transfer Object Assembler 패턴

• 문제: 클라이언트가 여러 컴포넌트로부터 데이터를 받을 경우, 데이터의 중복이나 네트워크 호출을 최소화 하려면
• 해법: 여러 개의 Transfer Object를 혼합한 복합 Transfer Object를 만든다.

• 전략

  • POJO Transfer Object Assembler 전략
  • Session Bean Transfer Object Assembler 전략

 

7.9. Value List Handler 패턴

• 문제: 원격 클라이언트에서 다량의 Business Object 검색 결과를 반복하여 처리하고자 할 때
• 해법: 데이터를 검색한 결과를 캐시로 처리하고 검색과 반복 기능을 제공한다.

 

8장. 통합 티어 패턴

 

8.1. Data Access Object 패턴

• 문제: 애플리케이션 내부에 로직과 DB 로직이 섞여 있으면 종속성이 높아진다. 데이터소스가 변경되면 애플리케이션도 변경해야 한다.
• 해법: 퍼시스턴스 로직을 추상화 캡슐화 하여 새로운 레이어를 생성한다. (DAO)

• 전략

  • Custom Data Access Object 전략
  • Data Access Object Factory 전략
  • Transfer Object Collection 전략, Cached RowSet 전략, Read only RowSet 전략, RowSet Wrapper List 전략

 

8.2. Service Activator 패턴

• 문제: 원격에서 비동기적으로 서비스를 실행시키고자 할 때.
• 해법: Listener를 구현한 Service Activator를 사용하여 비동기 요청을 수신하면, Service Activator가 하나 이상의 비즈니스 서비스를 호출한다.

• 전략

  • POJO Service Activator 전략
  • MDB(Message Driven Bean) Service Activator 전략
  • Command Request 전략, Service Activator Aggregator 전략, Response 관련 전략 - 실습: JMS 리스너를 Service Activator로 만들어 메시지를 보내고 받음.

 

8.3. Domain Store 패턴

• 문제: Business Object Model 에서 영속성을 분리하고자 할 때.
• 최근에는 직접 개발하기 보다는 iBatis, Hibernate 이용함.

 

8.4. Web Service Broker 패턴

• 문제: J2EE 애플리케이션의 몇몇 서비스를 웹서비스로 제공하고자 할 때.
• 해법: 하나 이상의 서비스를 XML 및 웹 프로토콜로 노출함. RPC방식이나 메시징 인터페이스.

• 전략

  • Custom XML Messaging 전략, Java Binder 전략, JAX-RPC 전략