Whiteship's Note


[Expert One-on-One J2EE Design and Development] J2EE 아키텍처 1

Spring/J2EE D&D : 2009.09.01 08:47


엔터프라이즈 아키텍처의 목표
- 견고함(be robust): 사용자가 신뢰할 수 있고 버그가 없어야 한다.
- 성능과 확장성이 좋아야 함: 확장을 고려하여 보통 여러 개의 서버 인스턴스를 하나의 클러스터에 배포한다. 클러스터링은 복잡한 애플리케이션 서버 기능을 필요로 한다. 애플리케이션이 클러스터 환경에서 효율적으로 동작하도록 설계되어 있는지 확인해야 한다.
- OO 설계 원리 장점 취하기: we should apply J2EE to realize OO design, not let J2EE technologies dictate object design
- 불필요한 복잡성 기피하기: XP에서는 "동작하게 만드는 가장 간단한 것"을 하도록 권장한다.
- 유지보수와 확장성: 각각의 컴포넌트가 분명한 책임을 가지고 있는지, 컴포넌트 끼리 강하게 결합되어 유지보수를 방해하진 않는지 확인하라.
- 제 때 배포하기
- 쉽게 테스트하기
- 재사용 권장하기

다음은 비즈니스 요구사항에 따른 부가적인 목표
- 다양한 클라이언트 타입 지원하기: 웹 애플리케이션, Swing 애플리케이션, 자바 애플릿 등. 보통은 "얇은" 웹 인터페이스만 널리 사용하고 있다.
- 이식성: 비즈니스 요구사항에 따라 데이터베이스 같은 자원의 이식성이 얼마나 용이한지 고려해야 할 수도 있다.

분산 아키텍처를 사용할 것인지 결정하기
- 분산 애프리케이션은 복잡하고, 런타임 오버헤드를 증가시키며, 만족할만한 성능을 내기 위해 충분한 설계를 필요로하기 때문에 중요한 의사결정이다.

분산 아키텍처가 제공하는 장점
- 다양한 클라이언트를 지원할 수 있는 능력
- 애플리케이션 컴포넌트를 각기 다른 물리적 서버에 배포할 수 있는 능력.

분산 아키텍처의 문제
- 성능 문제: 원격 호출은 로컬 호출보다 느리다.
- 복잡도: 개발, 디버그, 배포, 유지보수가 힘들다.
- OO 설계 적용에 제약이 생긴다

J2EE 설계에서 새로 고려할 것
- 생략

EJB 사용 시점
- EJB는 J2EE가 제공하는 하나의 선택일 뿐이다.
- 요구사항이 분산 아키텍처를 필요로 하고 RMI/IIOP가 원격 프로토콜로 적당할 경우 EJB는 표준 구현체를 제공해줄 수 있다.

EJB를 사용한다는 것의 의미
- 애플리케이션을 테스트하기 힘들다.
- 애플리케이션을 배포하기 힘들다.
- 원격 인터페이스는 OO 디자인 실천을 방행한다.
- 간단한 것도 어렵게 만든다.
- 애플리케이션 서버 선택 범위가 좁아진다.

EJB 사용에 대한 의문
- 생략

EJB 사용을 강하게 주장하는 경우
- 생략

경우에 따라 EJB 사용을 고려해볼 만한 경우
-  개발자가 멀티-쓰레드 코드를 작성하지 않아도 된다.
- CMT(컨테이너가 관리하느 트랜잭션)를 통해 Transparent 트랜잭션 관리를 제공한다.
- 선언적인/프로그래밍적인 롤-기반 시큐리티를 제공한다.
top

  1. 조대협 2009.09.01 15:53 PERM. MOD/DEL REPLY

    EJB는 Transaction 관리, 특히 분산 트렌젝션 관리에 유용하져. 여러개의 컴포넌트들을 통해서 트렌젝션을 전파하거나 여러개의 트렌젝션을 동시 사용하거나.
    그리고 JMS와 함께 쓰는 Message Driven Bean의 장점도 무시할 수 는 없져. ;)
    2.1 스펙부터는 Annotation이 나와서 개발하기도 쉬워졌어요. ;)

    Favicon of http://whiteship.me BlogIcon 기선 2009.09.01 16:45 PERM MOD/DEL

    맞습니다. MDB에 대한 내용도 있었는데 생략한 부분에 포함되어 있었나 봅니다.

Write a comment.