J2EE Development without EJB에는 정말 갈수록 방대한 양의 정보가 있다. 정리해 놓기도 만만치 않다. 그러나 그 수고는 충분히 가치있다고 생각된다. 전세계 수많은 뛰어난 J2EE개발자들의 경험과 생각이 녹아있는 책이기 때문이다. 이 책을 읽는 것 만으로도 배울 수 있는 관련지식과 경험의 규모는 엄청나다. 아직도 안 본 J2EE개발자가 있다면 얼른 구해서 읽으시길.

문제많은 EJB. 그러나 EJB에서 배울 것은 많다. EJB에는 우리가 취해야 할 좋은 점들이 충분히 있다. 또 교훈으로 삼아 피해야 할 나쁜 점도 많다. EJB의 특징과 그 역사, 평가와 대안등을 살펴보는 것은 매우 의미 있는 작업이다.

1. EJB와 컴포넌트 기술의 발전

EJB의 처음 목적은 엔터프라이즈급의 개발을 간편하게 하도록 하는 것이었다. 그것은 EJB1.0의 스펙을 살펴보면 잘 알 수 있다. EJB의 설계자들은 개발자들이 트랜잭션, 상태관리, 멀티쓰레딩, 리소스풀링이나 복잡한 로우레벨의 API와 같은 시스템적인 부분에 대해서 많은 신경을 쓰지 않고 개발 대상 도메인과 비즈니스로직에 집중할 수 있도록 하려는 것이었다. 또 한가지 강조한 부분은 EJB는 Java의 캐치프레이즈 그대로 한번 만들어지면 어떠한 다른 플랫폼과 서버환경에서도 재컴파일이나 소스코드 변경없이 사용하도록 하려는 것이었다.

EJB가 처음 등장했던 1998년에 당시 엔터프라이즈 컴포넌트 기술은 MS의 MTS와 CORBA정도가 주류로 존재했었다. COM/DCOM기술에 기반을 둔 MTS의 MS에 대한 의존성의 한계와 너무 방대한 스펙과 그에 따른 제약(CORBA는 진정한 애플리케이션 서버 기술로는 볼 수 없다)으로 역시 크게 쓰이지 못하고 있던 CORBA가 일반 개발자의 별다른 주목을 받지 못하고 있던 상황에서 EJB는 Java기반의 매우 열린기술과 이상적이고 간결해 보이는 스펙등으로 사람들의 관심을 끌기 시작했다. 하지만 그때는 아직 Java기술자체가 계속 발전하던 시기였고 EJB의 등장 이후에 Java는 언어적인 면에서 지속적으로 큰 변화들을 가져왔다. 하지만 EJB는 그 초기 등장이후 로컬인터페이스를 가진 EJB2.x에서 일부 최적화가 있었을 뿐 초기의 설계에서 근본적인 변화가 없이 현재에 이르고 있다. EJB가 초기의 기술에서 크게 변화하지 못하고 정체되어 있는 사이에 새로운 개념과 열린구조를 가진 .NET이나 Web Service같은 새로운 기술들이 등장했고 언어자체로 자바도 많은 발전이 있었다.

EJB는 그 스펙의 발전과정에서 여러가지 논쟁들을 가져왔는데 제일 문제가 되었던 부분은 EJB가 컴포넌트 기술과 리모팅 기술을 구분없이 혼재해서 가지고 있다는 점이다. 덕분에 EJB는 리모팅 부분의 다양한 기술을 적용할 수 없는 유연하지 못한 구조일 수 밖에 없었다. 또한 EJB를 오브젝트관점에서 봐야 하는지 컴포넌트로 이해해야 하는지에 대한 부분도 스펙의 발전에서 계속 고민되어진 부분이다. 특정 컴포넌트 기술에 종속적이지 않은 lightwegith container와 같은 오브젝트 기반의 기술도 컴포넌트들이 갖는 많은 특징들과 장점을 가지고 있음은 분명한 사실이다. 또 엄밀히 컴포넌트 기반의 소프트웨어 기술과 오브젝트 기반의 기술을 구분하는 것은 간단한 문제는 아니라고 생각된다.

EJB의 등장과 함께 기대했던 것은 EJB컴포넌트마켓의 발전이다. EJB기반의 다양한 3rd-party 컴포넌트들이 개발되고 또 이런 컴포넌트들을assemble해서 사용할 수 있다는 것이 EJB기술 마케팅의 주요한 포인트 중의 하나였음이 분명하다. 하지만 그 결과는 매우 실망스럽다. EJB컴포넌트 시장은 거의 존재한 적이 없다고 할 수 있을 정도로 미미한 수준이었다. 이는 부분적으로 EJB기술자체의 한계에도 기인하지만 한편으로는 엔터프라이즈 레벨의 기능들이 컴포넌트라는 것으로 만들어져 사용되어질 수 있기에는 너무 복잡하고 너무 특정 설계에 의존적인 것이 주요한 원인이라고 볼 수 있다. 그나마 활발한 컴포넌트 시장이 존재한다고 하는 ActiveX/.NET컴포넌트 시장에도 거의 대부분은 UI기능을 지원하는 컴포넌트만이 명맥을 유지하고 있을 뿐이지 본격적인 엔터프라이즈급의 컴포넌트는 찾아보기 힘들다는 점을 생각해보면 EJB의 컴포넌트 시장에 대한 나이브한 기대 자체에 문제가 있었다고 볼 수 있다.

최근 몇년 사이에 일어난 AOP에 대한 관심과 기술의 발전은 EJB가 가지는 많은 특징들을 좀 더 일반적인 방법으로 대치할 수 있는 가능성을 열어주었다. Interception이라는 관점에서 EJB서비스의 핵심적인 요소들은 AOP를 통해서 쉽게 구현가능해졌다. AOP는 OOP가 가지는 장점을 극대화하면서 이를 더욱 보완할 수 있는 기술임에 틀림이 없다. AOP를 통해서 제시되는 많은 기능들은 사실 EJB를 통해서 그동안 지속적으로 적용되어져 왔던 것이다. 다만 EJB에서는 매우 복잡한 방법과 구조를 통해서 이루어 졌다면 AOP는 그부분을 매우 심플한 방법과 새로운 자바자체의 기술들을 통해서 쉽게 적용할 수 있는 길을 열어준 것이다.

2. 우리가 EJB에서 원하는 것

EJB를 사용한다는 많은 프로젝트에서 사실 SLSB만을 사용하는 경우가 많다. SFSB은 사용빈도가 매우 적다. State를 Business Service Layer에서 관리한 다는 것 자체가 문제이다. 상태정보를 관리하기엔 SFSB보다 HTTP session이 훨씬 더 편하기 때문이다. Entity Bean은 가장 많이 외면된 EJB의 기능중의 하나이다. J2EE진영에서 조차 Entity Bean에 대한 비판은 끊임없이 이어져왔다. Entity Bean을 실전에서 적용해본 개발자 중에서 만족한 사람은 거의 없다고 보인다. 근본적인 EJB의 모든 문제점을 모두 가지고 있는데다 CMP/BMP은 지속적인 스펙발전에도 불구하고 현실적인 문제를 제대로 반영해 줄 수 없는 심각한 한계를 가진 persistence 기술이기 때문이다. JDO나 Hibernate, TopLink등의 제대로 현실 문제를 반영할 수 있는 O/R매핑기술이 널리 적용되기까지 O/R 매핑기술에 대한 부정적인 인식을 만들어온 주범이라고 볼 수 있다.

결국 개발자들에 의해서 선택되어진 것은 SLSB와 MDB정도이다. 최근에 EJB프로젝트에서 주로 사용되어지는 것은 Local Interface기반의 SLSB일 것이다. 결국 EJB는 결국 실제 필요보다 너무 많은 기술을 가지고 있고 필요없이 복잡하다고 할 수 있겠다.

SLSB가 가지고 있는 기능들을 뽑아보자면 선언적 트랜잭션 관리, 리모팅, 클러스터링, 쓰레드관리, 인스턴스 풀링, 리소스 관리, 보안, 비즈니스 오브젝트 관리 정도로 정리될 수 있다.

1) CMT
CMT(container-managed transaction)은 EJB의 가장 중요한 기능중의 하나라고 볼 수 있다. 자바코드에서 트랜잭션에 관한 부분을 선언적으로 쓸 수 있게 분리해냈다는 것은 매우 의미있는 것이다. 물론 복잡한 비즈니스로직을 가지는 경우 CMT만으로는 불가능 한 경우가 있기는 하지만 CMT는 그 자체로 매우 가치있는 기능이며 EJB를 사용하게 하는 주요한 이유중의 하나로 볼 수 있다. 하지만 대부분의 시스템구성이 단일DB(그 안에서 다시 clustering을 사용하는 경우를 포함하여)라고 볼 때 애플리케이션 서버 전체적으로 적용되는 JTA기반의 트랜잭션 관리는 대부분의 경우 구지 필요없는 부담이다.

Spring의 AOP기반의 선언적 트랜잭션관리 기능은 복잡하게는 멀티DB기반의 환경을 위한 JTA이용으로부터 단순하게는 JDBC API레벨까지 상황에 맞게 scale up/down이 가능하도록 설계되어 있다. 또한 checked exception에서의 rollback rule을 쉽게 설정하도록 할 수 있고 복잡한 트랜잭션의 경우 JTA보다 심플한 방법으로 프로그램에서 트랙잭션을 관리할 수 있는 방법을 제공한다.

2) Remoting
리모팅과 컴포넌트 이 두가지를 구분하지 않고 혼재해놓은 것이 EJB의 대표적인 문제점의 하나로 볼 수 있다. 대부분의 경우는 리모팅을 필요로하지 않는데다 리모팅을 해야 하는 경우 이부분이 독립적으로 삽입되어져 사용되어질 수 없는 고정적인 구조(EJB2.1에 들어서 비로서 RMI/IIOP에 더불어 web service remoting이 지원되어졌다)를 가지고 있기 때문이다. 이미 언급했던 것처럼 대부분의 경우 co-located되어진 구조가 remote 기반의 구조보다 낫다. 그리고 웹서비스를 제공하기에는 EJB보다 더 나은 방법이 얼마든지 있다.

3) Clustering
EJB의 확장성은 매우 편리하고 뛰어난 것으로 제시되어져 왔지만 사실 그렇지 않다. 뛰어난 클러스터링을 지원하는 EJB지원 WAS는 매우 고가인데다 Entity bean과 SFSB는 사실 클러스터링하기에는 너무 제한적이 많은 문제점을 가지고 있다. 결국 SLSB의 클러스터링이 남게 된다. SLSB의 클러스터링의 장점은 사실 제한적이며 성능이나 확장성 면에서 볼때 co-located된 구조가 더 많은 장점이 있다.

4) Thread Management
EJB처럼 동시성의 문제 때문에 특정 메소드가 실행되고 있는 중에 전체 bean을 locking하는 방식은 적절하다고 볼 수 없다. 대신에 서블릿이나 Struts Action처럼 instance variable을 가지고 있지 않은 싱글 오브젝트를 이용한다면 복잡한 쓰레드관리를 해야 할 필요가 없다. 또는 각각의 request에 대해서 새로운 인스턴스를 만들어서 쓰는 것도 간편하게 동시성 문제를 해결 할 수 있다. 최신 JVM은 사실 간단한 오브젝트 생성과 삭제에 별 부담을 가지지 않는다. WebWork/XWork이나 Hibernate에서 왜 의도적으로 오브젝트 풀링을 사용하지 않고 있는지 살펴 볼 필요가 있다. 아니면 자바언어의 synchronization 기능이나 concurrency api등을 이용해서 오브젝트를 작성할 수도 있다.

5) Instance Pooling
EJB인스턴스 풀링은 EJB가 처음 만들어지던 Java 1.1시절에는 garbage collection상의 문제를 피하기 위한 것과 메모리 절약이라는 측면에서 가치가 있었다. 하지만 GC기술이 충분히 발달했고 메모리가격이 매우 저렴한 지금은 그만한 가치가 없다. 오히려 적절한 instance pool 사이즈와 쓰레드 사이즈를 어떻게 결정해야 하는가하는 난감한만 남아 있을 뿐이다.

6) Resource Pooling
DB커넥션과 같은 리소스 풀링은 EJB의 인스턴스 풀링보다 어쩌면 더 중요하다. 하지만 리소스 풀링은 EJB의 기술이 아니라 J2EE애플리케이션 서버 또는 서블릿 컨테이너 레벨에서 준비되어진 기술이다. 따라서 EJB와 상관없이 얼마든지 사용되어 질 수 있다.

7) Security
CMT와 더불어 EJB의 선언적 프로그래밍 기능으로 주목받은 것이 바로 보안에 관한 부분이다. 그러나 대부분의 복잡한 보안요구사항들은 EJB가 지원하는 선언적 보안방식으로는 구현하기가 불가능하다. 또한 선언적인 보안설정등은 서블릿컨테이너 레벨에서도 사용가능하다. Spring에서는 AOP와 interceptor chain등을 이용해서 쉽게 복잡한 보안프레임웍을 구성할 수 있게 해준다.

8) Business Object Management
EJB의 장점중의 하나는 개발자로 하여금 인터페이스기반의 프로그래밍을 강제하고 있다는 점이다. 인터페이스와 구현의 분리는 좋은 프로그래밍 방식이다. 하지만 EJB만 그런 분리를 지원하는 것이 아니다. 자바언어 자체에서 이미 훌륭하게 인터페이스를 지원하고 있으며 lightweight container도 자체적으로 관리하는 오브젝트에 대해서 인터페이스를 통한 접근을 유용하게 해주는 Factory역할을 해준다. 또 IoC기능의 지원을 통해서 fine-grained된 오브젝트의 의존구조를 컨테이너 레벨에서 관리함으로 매우 심플한 프로그래밍 모델을 제공하고 있다.

우리는 EJB의 여러 장점들에 대해서 부인할 필요는 없다. 동시에 그것들이 EJB를 통해서만 지원되는 것이 아님을 알아야 하며 좀더 심플하고 바람직한 방법을 추구해야 할 것이다.

3. 우리가 EJB로부터 원하지 않는 것

참으로 많다. 다 적기도 귀찮다. 한마디로 요약해서 말하자면 “심플하게 할 수 있는 것을 복잡하게 하게 하는 것”이라고 할 수 있다.

4. EJB는 나아질 수 있는가?

EJB 3.0이 최근 자바진영의 주된 화제중의 하나이다. 그간의 복잡성을 최대한 배제하고 대폭적으로 심플한 구조와 방법을 채택하겠다는 것이 EJB 3.0 전문가 그룹의 의지이다. 상당히 고무적이다. 하지만 EJB 3.0을 기대하는 것에는 한계가 있다. 시기적으로 제대로 EJB 3.0을 사용하게 될 수 있는 시점은 2006이나 되야 가능 할 것으로 보인다. 또 WAS업체의 마케팅관점에서 간섭을 무시할 수 없다. 복잡해야 비싸게 팔아먹을 수 있다고!

아무래도 계속 지적되었던 EJB문제들에 대한 모든 면에서의 변화를 기대하기는 힘들 것 같다.

5. 미신과 오해들

몇가지 흔한 잘못된 오해들을 꼽아보자.
1) J2EE == EJB?
J2EE는 EJB 이상이고 EJB는 자바의 일부일 뿐이다. EJB를 포기하는 것이 J2EE를 버리라는 것은 절대 아니다.

2) 모든 개발자들은 EJB를 이해하고 있다.
640페이지에 달하는 EJB2.1 스펙을 한번이나 다 읽어보기라도 한 사람이 얼마나 될까? 나도 관심있는 주제를 중심으로 훑어만 봤을 뿐이다. EJB와 그 관련기술에 대한 깊은 이해와 지식을 가진 개발자와 아키텍트는 극히 소수이다. 사실 다 이해하기에 너무 복잡하다. 샘플 코드 배끼기 수준의 EJB개발자가 얼마나 많은가?

3) MDB없이는 asynchronous application개발을 할 수 없다.
MDB의 상당부분은 EJB가 아니라 J2EE에 기반하고 있다.

4) EJB없는 심플한 시스템을 만들 수는 있으나 그것은 확장성이 없다.
구지 설명할 필요조차 없는 생각이다.

6. 그럼 대안은?

이 책이 이야기 하고 있는 핵심은 EJB를 사용하지 않고 엔터프라이즈 레벨의 서비스를 더 심플하고 생산적인 방법으로 사용할 수 있는 방법에 관한 것이다. 그 평가와 상관없이 EJB는 여전히 그 세력이 막강하다. 엄청난 규모의 WAS제작업체의 파워와 마케팅 능력, 언론플레이는 아직도 대부분의 기업의 의사결정을 담당하는 사람들에게 막대한 영향력을 미치고 있다. 또 많은 개발자들이 아직 EJB외의 대안에 대해서 잘 모르고 안다하더라고 막연한 거부감이나 부담감을 가지고 있는 것이 현실이다. 시간이 점점 지나고 Spring과 같은 좋은 대안들이 현실에서 검증되고 지속적으로 인정받기 시작하면서 EJB는 점점 그 주권을 내주지 않을까 기대해본다.

EJB를 배제한 J2EE시대를 이끌어 나갈 수 있을 것으로 주목받고 있는 기술들을 꼽아 본다면.
- Spring Framework : 두말할 것 없는 가장 주목받고 있는 EJB이상의 뛰어난 프레임웍. 이 책의 결론이자 검증가능한 증거일 것이다.
- Nanning Aspect : AOP기반의 솔루션.
- JBoss 4 : AOP를 통한 POJO기반의 엔터프라이즈 서비스를 이용할 수 있다.
- PicoContainer : Spring과 유사한 IoC기반의 Lightweight container.
- Hibernate : POJO기반의 최고의 O/R매핑 솔루션
- JDO : EJB를 대신할 수 있는 뛰어난 퍼시스턴스 기술의 하나
- HiveMind : 또하나의 IoC컨테이너.
- iBatis : 심플한 data access와 transaction방법을 제공
- GLUE : 뛰어난 성능의 lightweight 웹 서비스 리모팅 솔루션

이런 기술들은 물론 SUN의 J2EE표준이 아니다. 그러나 표준만 써야 할 것인가? J2EE의 표준화 과정의 문제점은 너무나도 많다. 항상 표준만이 옳고 최선의 것이 아니다. 이미 EJB의 발전과정을 통해서 그 문제점에 대해서는 충분히 경험했다. 많은 필드의 개발자들이 만족하고 사용하고 퍼뜨리고 함께하는 것 그것이 진정한 의미의 표준이 아닐까 생각한다.

Related posts:

  1. J2EE Development without EJB (1) – Why "J2EE Without EJB"?
  2. J2EE Development without EJB (3) – Architecture
  3. J2EE Development without EJB (6) – Lightweight Container & IoC
  4. J2EE Development without EJB (2) – Goal
  5. J2EE Development without EJB (4) – The Simplicity Dividened
  6. J2EE Development without EJB 정리는 이만
  7. SpringFramework vs. J2EE?
  8. 망해가는 EJB 최후의 발악인가? Mastering EJB3 (4th Ed)
  9. Bile Blog – Hani Suleiman 인터뷰
  10. 하이버네이트와 스프링의 갈등
  11. 머리가 복잡하고 마음이 심란할 때는
  12. EJB3의 Dependency Injection
  13. The Spring Experience 셋째날 – TSE사람잡네
  14. 토비의 스프링 3이 나오기까지 (1)
  15. Atlassian은 왜 성공했을까?

Facebook comments:

to “J2EE Development without EJB (5) – EJB, Five Years On”

  1. thanks for share!

  2. Hop Over To THIS Web-Site
    [url=http://www.hyreport.com.cn/member/configispace.php?/cheap-wholesale-oakley-sunglassesoakleyoutlet-cheap.html]cheap wholesale oakley sunglasses,oakley,outlet cheap[/url]
    cheap wholesale oakley sunglasses,oakley,outlet cheap

  3. Visit THIS Site
    [url=http://www.fhce.com/images/index.php?/moncler-boutique-with-a-variety-of-beautifully-created-to-choose-from-2012.html]moncler boutique-With a variety of beautifully created to choose from 2012[/url]
    moncler boutique-With a variety of beautifully created to choose from 2012

  4. Try HERE
    [url=http://www.ahtlsh.com/images/yybgk.php?/moncler-coats-saks-high-quality-and-unique-designs-make-it-popular-all-over-the-world-2013.html]moncler coats saks-High quality and unique designs make it popular all over the world 2013[/url]
    moncler coats saks-High quality and unique designs make it popular all over the world 2013

  5. You Can Check Here
    [url=http://bootsforwomenoutlet.com]womens ugg boots[/url]
    womens ugg boots

  6. Find Out More
    [url=http://baileybuttontriplett.com]ugg triplet bailey button[/url]
    ugg triplet bailey button

  7. mbt sawa J2EE Development without EJB (5) – EJB, Five Years On » Toby’s Epril

Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

© 2017 Toby's Epril Suffusion theme by Sayontan Sinha