Whiteship's Note


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

Spring/J2EE D&D : 2009.09.03 14:00


Web Ties Design

이전에 보았던 각기 다른 네 가지 아키텍처에 모두 적용가능하다.

웹 단을 미들 단의 비즈니스 인터페이스에 의존하는 별도의 계층으로 구분하는 것이 중요하다. 그렇게 해야 비즈니스 객체를 바꾸지 않고도 웹 단을 수정할 수 있으며 웹 단을 참조하지 않고도 비즈니스 객체를 테스트할 수 있다.

MVC 아키텍처 패턴

이 패턴은 스몰토크 유저 인터페이스를 위해 처음으로 문서화 되었으며 가장 성공적인 OO 아키텍처 패턴중 하나이다.

중략~

웹 단에서 MVC 아키텍처 패턴을 사용하라. 스트럿츠같이 작성해야 할 애플리케이션 코드의 양을 줄여주며, 기본적인 MVC 패턴 구현체를 사용하라.

Designing Applications for Portability

특정 플랫폼에 종속적인 것은 추상화 계층을 사용하여 구현해야 한다. 인터페이스 자체는 플랫폼에 독립적이기 때문이다.

구현 이식성과 디자인 이식성의 차이를 알아야 한다. 구현 이식성이랑 어떤 서버에 배포하든 코드를 고칠 필요가 없는 것이고, 디자인 이식성은 분명한 인터페이스 약간을 다시 구현하기만 하면 어떤 서버에든 배포할 수 있는 것이다. 완전한 구현 이식성을 달성하기는 매우 많은 노력이 필요할 수 있지만, 디자인 이식성은 달성할만하며 충분한 비즈니스 가치를 가져다 준다. 이식성이 비즈니스 요구사항이 아니더라도, 디자인 이식성은 좋은 OO 디자인 실천으로 자연스래 달성할 수 있다.

Summary

- 분산 아키텍처의 단점: 보다 복잡하고, 구현, 테스트, 유지보수 하기 힘들다. 주의깊게 설계하지 않으면 성능 문제가 발생한다.
- 분산 아키텍처의 장점" 특정 경우에 따라, 보다 견고하고 확장성이 좋을 수 있다. 특정 비즈니스 요구사항에 따라 분산 아키텍처가 필요할 수도 있다.
=> 진짜 장점을 주지 못한다면 분산 아키텍처를 피하는 것이 최선이다.

- EJB 2.0에 웹 서비스가 포함되었다. 따라서 RMI에 종속적이지 않게 되었다. 로컬 인터페이스를 통해 EJB가 실행되고 있는 동일한 JVM에 접근할 수 있다. 따라서 분산 아키텍처에 종속적이지 않게 되었다.

- 언제 EJB를 사용할 것인가. EJB는 특정 문제를 매우 잘 해결할 수 있는 복잡하고, 강력한 기술이다. 하지만 대부분의 애플리케이션에 적절하지 않다.

- 나머지 dao, tiered architecture, four J2EE architecture, web-tire design issue 생략~
top

Write a comment.


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

Spring/J2EE D&D : 2009.09.02 18:19


Accessing Data

(예전) EJB를 사용하면 엔티티 빈이라는 하나의 선택지 밖에 없다. (EJB 3.0부터는 JPA가 있지요.)

J2EE Data Access Shibboleths

- 데이터베이스 간의 이식성은 항상 중요하다.
- O/R mapping은 관계형 DB를 사용할 때 항상 최선의 솔루션이다.

데이터 접근 전략을 사용할 때, 비즈니스 로직과 데이터 접근 로직을 추상화 계층으로 분리하는 것이 좋다.

Entity Beans

특정 DB에 종속되지는 않지만, EJB 컨테이너와 특정 O/R 맵핑 기술에 묶이게 된다. 성능이 안 좋다. 아키텍처적인 유연성이 떨어지고 테스트하기 어렵다.

EJB 2.0이 되고나서도, 너무 기초적인 O/R 맵핑인데다, 비효율적으로 관계형 DB를 사용하기 때문에 성능이 좋치 않다.

JDO

JDO는 엔티티 빈에 비해 성능이 좋고, 특정 RDBMS에 종속적이지도 않다. EJB에도 종속적이지 않다. 단점은  JDO 구현체가 아직 비교적 성숙하지 못하다는 것이다.

다른 O/R 맵핑 솔루션

탑링크와 코코베이스는 JDO 보다 성숙한 O/R 맵핑 솔루션으로 대부분의 J2EE 애플리케이션에서 사용할 수 있다. 다양한 기능과, 고성능의 O/R 맵핑을 제공한다. (하이버네이트 얘기는 하나도 없지 왜..)

JDBC

암묵적인 J2EE에서 JDBC와 SQL은 악마라는 소문이있다. 하지만 이 책에서 제공하는 고 수준의 라이브러리를 사용하면 (이때부터 JdbcTemplate이 나오나 봅니다. 캬..) O/R 맵핑이 없는 상황에서 최선책이 될 수 있다. 제대로 사용하면 JDBC는 좋은 성능을 발휘할 것이다. 데이터를 자연스럽게 캐시할 수 있는 O/R 맵핑 계층이 있다면 JDBC는 적절하지 않다.

상태 관리

J2EE 아키텍처에서 또 다른 중요한 의사결정은 서버-측 상태를 어떻게 관리할 것이냐이다. 이것으로 인해 서버 클러스터 환경에서 애플리케이션이 어떻게 동작하는지 그리고 어떤 J2EE 컴포넌트를 사용해야 하는지 결정된다.

서버-측 상태가 필요한지 결정하는이 중요하다. 애플리케이션을 단일 서버에서 운영할 떄는 서버-측 상태를 유지하는 것이 별 문제는 아니다. 여러 서버를 클러스터 환경에서 운영한다면 페일오버(failover)나 server affinity 문제 등을 피하기 위해 서버-측 상태를 복사해야 한다.

서버-측 상태가 필요하다면 유지해야 할 양을 최소화 하는 것이 좋다.

서버-측 상태를 유지하지 않는 애플리케이션이 그러는 애플리케이션보다 확장성이 좋고, 간결하며 클러스터 환경에 배포하기 좋다.

서버-측 상태를 어디에 저정해야 할지 결정해야 한다. 저장할 정보의 종류에 따라 달라진다. 사용자 세션 정보냐, 비즈니스 객체 상태냐. 둘 다냐. 분산 EJB는 웹 단의 상태와 상관없이 stateless session bean으로 확장성을 최대화 한다.

J2EE는 웹 애플리케이션에서 상태 관리에 사용할 두 가지 옵션을 제공한다. HTTP session 객체와 stateful session EJB다.  상태 관리가 필요하다고 해서 EJB가 필요한건 아니다.

J2EE 아키텍처

생략~


top

  1. 우가가 2009.10.19 16:48 PERM. MOD/DEL REPLY

    좋은 글 읽고 갑니다.
    직접 번역하신 건가요? ^^

    그리고 하이버네이트 1.0이 릴리즈 되었을 때가 2002년 7월이고 로드 존슨이 저 책을 2002년 10월에 탈고했으니까 아마 당시 듣보버전이었던 녀석을 책에 언급했을 것 같지는 않네요. 판본이 바뀌면서 수정하지 않았다면요.

    Favicon of http://whiteship.me BlogIcon 기선 2009.10.19 16:57 PERM MOD/DEL

    넹. 제가 번역/요약한 글입니다.
    시간까진 안 따져봤는데, 시기를 보니 그럴만도 하군요. :)

Write a comment.