책을 정리해 나가면서 보는게 쉬운 일은 아니다. 일단 전체를 이해하고 읽기 위해서 한번 그리고 정리하며 핵심을 뽑아내고 다시 생각해 보기 위해서 한번. 즉 두번씩 읽어야 하기 때문이다. 이제 1/3겨우 봤는데 아직 갈길이 멀다.

Lightweight Container? IoC? 이게 도대체 뭔 말이지?
SpringFramework을 처음 접했을 때 이 두가지 용어가 정확히 무엇을 말하는지 이해하기가 힘들었다. IoC을 소개하는 Martyn Folwer의 아티클을 읽으면 Dependency Injection이라는 새로운 용어가 또 등장한다. 거기다 IoC는 이미 오래전부터 컨테이너의 기본 작동방식인데 뭐 새로운 것도 아니자나 하는 류의 글들을 읽으니 이거 나는 뭔가 세상돌아가는 것도 모르고 살아온 것 같은 절망에 잠시 빠진 기억이 난다. 요즘엔 종종 친구들이나 후배들이 IoC가 도대체 뭐냐고 물어온다. 한참을 개념을 설명해줘도 잘 이해가 안간다는 사람도 있고 또 그걸 뭐하러 쓰냐고 반문하는 사람도 있다.

Lightweight Container

왜 IoC와 Lightweight Container가 필요한가?
앞 장들에서 쭉 얘기 해 온 것은 EJB는 수많은 문제를 가진 배제되야 할 기술이라는 것이다. 그럼 EJB를 쓰지 않고 EJB이전의 방식으로 J2EE애플리케이션을 개발하면 될 것인가? 그것은 아니다. EJB의 비즈니스 서비스 컨테이너로서의 특징과 장점들은 포기하기에 아까운 것들이다. 그렇다고 그런 것들을 독자적으로 직접 구성해서 만들어 쓰는 것은 배보다 배꼽이 더 큰 상황이 될 것이다. 결국 우리에게 필요한 대안은 잘 구성된 – 완성도 높은 – EJB기반이 아닌 비즈니스 서비스 컨테이너이다. 이 컨테이너는 EJB의 단점들을 가지지 않아야 한다. 동시에 EJB의 장점들을 가지고 있어야 한다. 욕심도 많다. 그 욕심을 채워줄 멋진 컨테이너를 이제 알아보자.

컨테이너니 프레임웍이니 하면 알레르기 부터 일으키는 개발자들이 있다. EJB를 쓰면서 많이 고생한 나도 컨테이너 하면 짜증부터 났다. 내가 뭔가 컨트롤 할 수는 없으면서 많은 제약을 가해오는 그 것. 그것이 컨테이너인데…

하지만 컨테이너 없는 J2EE는 기대할 수도 없다. 당장 서블릿과 서블릿이 사용하는 오브젝트들 구동해주는 웹 컨테이너가 없으면 웹기반의 서버프로그래밍은 기대할 수도 없다.

컨테이너의 기본 특징은 Lifecycle Management, Lookup, Configuration, Dependency Resolution으로 볼 수 있다. 그밖에도 Thread Management, Object Pooling, Clustering, Management, Remoting, Exposing remote services, Customization and extensibility등의 부가적인 기능들을 포함하기도 한다.

그럼 lightweight container의 특징은 무엇인가?

1. lightweight container는 일반 컨테이너처럼 애플리케이션 코드를 관리해 주지만 그 코드내에 컨테이너에 대한 의존적인 부분들이 필요없도록 해준다. 왜 가벼운가? 그것은 코드내에 컨테이너에서 동작하기 위해서 특별히 필요로 하는 부분이 없기 때문이다. 컨테이너를 알지 못하는 오브젝트 또는 알 필요도 없는 오브젝트를 가능하게 해준다는 것이다.
2. 컨테이너 구동이 빠르다. 가벼우니까 당연히 빠르다.
3. 컨테이너 내에 오브젝트를 배치(deploy)하기 위한 복잡한 과정이 없다.
4. 컨테이너 그 자체로 작고 가볍다. 컨테이너는 Pure Java이지 J2EE의존적이 아니다. J2EE를 벗어나 standalone Java나 applet에서도 구동이 가능하다.
5. 컨테이너에서 동작할 오브젝트가 fine-grained 또는 coarse-grained의 어떤 것도 가능하도록 오브젝트의 배치가 쉽고 단순하며 성능의 오버헤드가 없어야 한다.

오브젝트가 컨테이너에 의존적이지 않는다면 그래서 컨테이너의 API조차 사용할 필요가 없다면 구지 컨테이너가 필요한 이유는 무엇인가? 컨테이너는 여러가지 면에서 반드시 필요한데 첫째는 컴포넌트/오브젝트의 자유로운 삽입(Pluggability)이 가능하도록 하기 위한 calling code의 독립성 때문이다. 둘째는 서비스의 lookup이나 configuration이 일관성을 갖도록 하기 위한 것이다. 셋째는 단일화된 서비스의 접근방법을 제공하기 위한 것이다. 개발자 각자 자기만의 스타일로 싱글톤이나 팩토리를 만들어 쓸 필요가 없어야 한다. 넷째는 비즈니스 오브젝트에 부가적으로 필요로 하는 각종 enterprise service를 제공하기 위해서 이다.

Inversion of Control

컨테이너에 종속적인 코드를 최소화 하기위한 가장 좋은 방법은 IoC와 Dependency Injection을 적절히 사용하는 것이다. IoC는 기본적으로 framework의 가장 중요한 개념중의 하나이다. DI는 IoC의 일종으로 IoC의 장점을 극대화 한것으로 볼 수 있다.

IoC라하면 간단히 말해서 container/framework이 오브젝트를 관리하는 구조라고 생각하면 된다. 즉 오브젝트의 lifecycle관리 및 구동을 container가 담당하는 구조라고 생각하면 된다.

IoC의 구현방법에는 두가지가 있다.
첫째는 Dependency Lookup이다. 이 것은 컨테이너가 callback을 통해서 제공하는 lookup context를 이용해서 필요한 리소스나 오브젝트를 얻는 방식이다. EJB와 Apache Avalon의 구현방법이다.
둘째는 Dependency Injection이다. 이 책이 홍보하는 방법이다. 비즈니스 오브젝트에 look up 코드를 사용하지 않고 컨테이너가 직접 의존구조를 오브젝트에 설정할 수 있도록 지정 해주는 방법이다. 이 것은 다시 Setter Injection과 Constructor Injection으로 나뉜다.

Dependency Lookup은 JNDI등을 이용하는데 오브젝트간에 decoupling을 해주는 면에서 장점이 있기는 하다. 하지만 이렇게 만들어진 오브젝트는 컨테이너 밖에서 실행 할 수 없고 JNDI외의 방법을 사용할 경우 JNDI관련 코드를 오브젝트내에 일일히 변경해 줘야 하며 테스트하기 매우 어렵고 코드양이 매우 증가하고 Strong typed가 아니므로 Object로 받아서 매번 Casting해야 하고 (그래서 primitive type은 wrapper class를 써야 하고) NamingException같은 checked exception을 처리하기 위해서 exception처리구조가 매우 복잡해지는 단점이 있다.

Avalon의 경우는 EJB보다 좀 더 심플한 lookup방법을 제공하지만 거의 대부분의 나머지 단점에서는 자유롭지 못하다.

Dependency Injection은 각 오브젝트가 자신이 의존적인 resource와 collaborator에 대한 lookup의 책임을 가지지 않고 대신 컨테이너가 그 일을 담당하고 오브젝트 내에 주입해주는 방식이다. 따라서 lookup과 관련된 코드들이 오브젝트 내에서 완전히 사라지고 컨테이너에 의존적이지 않은 코드를 작성할 수 있다. 이는 오브젝트가 컨테이너의 존재여부를 알 필요조차도 없기 때문이다. 또 특별한 인터페이스 구현나 클래스의 상속의 필요가 없다.

DI중 Setter Injecton은 JavaBeans의 property구조를 이용한 방식이다. SpringFramework쪽이 주로 이 Setter Injection을 지지하고 있다. 오브젝트가 컨테이너에 의해서 만들어지고 나서 바로 모든 dependency들이 setter method를 통해서 주입이 된다. Setter Injection이 가지는 장점은 JavaBean property 구조를 사용하기 때문에 IDE등에서 개발하기 편리하고 상속시 그 구조가 그대로 전달이 되며 type conversion을 위해서 JavaBean property-editor기능을 사용할 수가 있고 getter method를 통해서 현재 오브젝트의 상태정보를 얻어올 수 있다는 것들이다. 담점으로는 setting 순서를 지정할 수 없다는 것과 모든 필요한 property가 세팅되는 것에 대해서 보장할 수 없다는 점이 있다.

Constructor Injection은 PicoContainer에서 주로 많이 사용하는 방식이다. Setter Injection의 단점을 일부 극복할 수는 있는 장점이 있지만 반대로 단점도 제법 많다. 하지만 뭐 크게 문제가 될만한 것들은 아니라고 본다.

어떤 방식의 Dependency Injection을 쓰느냐는 취향의 문제에 가깝다. 거의 모든 IoC 컨테이너에서는 두가지 방식을 다 지원한다.

Dependency Injection을 쓰기 어려운 경우가 있다. Dependency 구조가 매우 다이나믹해서 미리 지정하기 어려운 경우이다. 가능한 이런 구조는 설계단계에서 피하는 것이 낫지 않을까 싶다. 정 어쩔 수 없는 경우가 아니라면.

IoC Container

SpringFramework

이 책의 저자의 개념과 철학이 모여 만들어진 결과물이다. 이제 버전 1.1대의 매우 새로운 제품이지만 그 인기와 적용되는 속도는 정말 놀랄 만하다. 베타단계부터 꾸준하게 테스트 되고 계속 기능이 확장, 안정되어왔기 때문일 것이다. 가장 활발하게 업데이트 되고 논의 되는 컨테이너이다.

기본적으로 XML을 이용한 메타데이터로 configuration을 지원한다. 사용법은 매우 간편하다. 사실 IoC/DI 관점에서만 보자면 정말 매우 심플하고 가볍다. 몇가지 특징으로는 autowiring를 지원해서 XML작업을 최소화 할 수 있고 다양한 collection구조를 지원하며 각 오브젝트의 lifecycle 메소드를 지원한다는 것이 있다.

꼭 필요한 경우에는 container의 callback기능을 이용해서 직접 lookup하는 방식을 지원하기도 한다. 가능하면 container관련 코드를 전부 제거하면 좋지만 서버환경에서 특정한 경우에는 container레벨의 정보를 직접 사용해야 할 때가 있다.

EJB의 대안으로 제시하는 Lightweight Container가 EJB와는 달리 심플할 수 있는 가장 중요한 요소는 바로 IoC/DI를 사용하기 때문일 것이다. IoC기반의 프로그래밍을 해보지 않은 경우에는 처음에는 조금 접근하기가 간단치 않을 것이다. 그것은 IoC가 어려워서가 아니라 그 구조가 지금까지 해왔던 방식과 반대방향으로 되어있기 때문이다. 그러나 한번 익숙해 지고 나면 이만큼 편리한 것도 없다. Spring으로 몇달간 개발해온 프로그래머들이 공통적으로 하는 말이 있다.
“IoC를 쓰기 전엔 도대체 어떻게 개발을 했었는지? 이젠 IoC없는 개발은 상상이 안되네…

Related posts:

  1. J2EE Development without EJB (3) – Architecture
  2. J2EE Development without EJB (5) – EJB, Five Years On
  3. J2EE Development without EJB (4) – The Simplicity Dividened
  4. J2EE Development without EJB 정리는 이만
  5. J2EE Development without EJB (2) – Goal
  6. J2EE Development without EJB (1) – Why "J2EE Without EJB"?
  7. SpringFramework vs. J2EE?
  8. JavaBeans에 관한 논쟁

Facebook comments:

to “J2EE Development without EJB (6) – Lightweight Container & IoC”

  1. ^^저도 Martyn Folwer 아티클 보고 느낀건데 정말 대단하다고 밖에는 말을 못하겟더군요..

  2. MGpCpB nlclzpruwbjy, [url=http://oymjurxeuoux.com/]oymjurxeuoux[/url], [link=http://foihhumlzykr.com/]foihhumlzykr[/link], http://yttycrzskogl.com/

  3. Excellent read, I just passed this onto a colleague who was doing a little research on that. And he actually bought me lunch because I found it for him smile So let me rephrase that.

  4. mbt cheap shoes J2EE Development without EJB (6) – Lightweight Container & IoC » 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