EJB와 스프링 개론

EJB(Enterprise Java Bean)

Java bean이란 자바 객체를 재사용 가능하도록 즉, 컴포넌트화시킬 수 있는 코딩 방침을 정의한 것을 의미한다.
(bean은 쉽게 component 또는 객체라고 이해하면 좋다.)

EJB란 엔터프라이즈급 어플리케이션 개발을 단순화하기 위해 발표한 스펙입니다.

개발을 하다 보면 많은 객체들을 만들게 되는데, 이러한 비즈니스 객체들을 관리하는 컨테이너를 만들어서 필요할 때마다 컨테이너로부터 객체를 받는 식으로 관리하면 효율적이겠다. 라는 것에서 탄생합니다.

 

이러한 취지는 좋았으나, 서비스가 구현해야 하는 실제 비즈니스 로직보다 EJB 컨테이너를 사용하기 위한 상투적인 코드(상속 and 구현해야 하는 클래스)들이 많다는 불편함이 있었습니다. 당연히 작성된 코드는 EJB컨테이너가 없다면 사용할 수 없었죠.

 

심각한 것은 벤더 사마다 EJB 컨테이너를 구현한 내용이 다르기 때문에 다른 벤더 사의 컨테이너로의 변경에 어려움이 있었고, 이것은 설정이 너무 복잡하다는 문제로 부각되기 시작합니다. 따라서 프로젝트 자체가 특정 기술(개발 툴 등)에 종속. 즉, 기술 침투(Invasive)되는 문제가 있었습니다.

 

 

 

스프링 컨테이너의 탄생

EJB는 컨테이너로부터 필요한 객체를 꺼내 사용하는 방식으로 객체들 간의 의존성을 해결하려는 것이었지만 비즈니스 로직에 특정 기술이 종속되는 것이 가장 큰 문제점이었습니다. 이에 2002년 '로드 존슨'은 특정 클래스를 상속하거나 인터페이스를 구현하지 않는 평범한 자바 클래스(POJO(Plain Old Java Object), 느슨한 Java Bean, Spring Bean)을 이용하며 단순하지만 EJB에서 제공하는 고급 기술을 제공하는 Spring을 창시합니다.

 

스프링은 「자바 엔터프라이즈 개발을 편하게 해주는 오픈소스 경량급 애플리케이션 프레임워크」라고 정의됩니다. 평범한 자바 클래스를 이용하여 EJB의 기능을 유지하면서 복잡성(기존 EJB컨테이너에서 제공하는 API를 상속받거나 구현하여 코드를 작성하는 부분들)을 제거해 코드가 단순&가벼워졌고(경량급), 스프링에 특화된 인터페이스 구현을 요구하지 않는 등 자바 개발의 폭넓은 간소화를 실현하게 됩니다. 또한 스프링은 위 그림과 같은 여러 객체들을 의존성 해결(DI) 및 제어(IOC)하며 객체들의 라이프 사이클을 관리해 줍니다.

 

스프링은 특정 기술에 종속되지 않고(기술 비침투적) 객체를 관리할 수 있는 컨테이너를 제공하는 것이 스프링의 기본 철학입니다.

 

 

 

DI(Dependency Injection, 의존성 주입)

EJB컨테이너와 스프링 컨테이너는 모두 객체의 의존성 해결 및 관리를 목적으로 한다고 했는데요.

의존성? 객체 간에 의존하다는 것은 무엇을 의미할까요??

public class A(){
	public static void main(String[] args){
		B b = new B(); //A클래스는 B클래스를 사용한다. 즉, A는 B에 의존한다(의존적이다).
		b.hello();
	}
}

class B(){
	public void hello(){
		system.out.print("hello");
	}
}

그리고 위와 같은 객체 간의 의존성을 스프링 컨테이너에서는 의존성 주입(DI, Dependency Injection)을 통해 해결합니다. 의존성 주입이란 사용자가 직접 new 키워드를 사용하여 객체를 생성하지 않고, 외부(컨테이너)에서 생성된 객체를 주입받는 방식을 말합니다. 즉, 의존하는 객체를 직접 생성하는 대신 스프링 컨테이너로부터 의존 객체를 주입(전달)받는 방식 입니다.

 

단어별로 정리하자면,

의존: A라는 클래스가 어떤 일을 하기 위해 B에 있는 기능을 사용하는 것으로 다른 객체에 의존하여 처리한다는 개념.
주입: 생성돼 있는 객체를 주입받는 방식으로 사용하게 됨을 말한다.

빈 설정 정보를 바탕으로 컨테이너가!! 자동으로 주입해 줌. ← 제어하는 주체가 뒤바뀜.

 

 

 

IOC(Inversion of Control, 제어의 역전)

객체(인스턴스)의 생성과 소멸 등 개발자가 직접 제어해야 하는 부분들을 프레임워크(정확하게는 컨테이너)가 대신 처리하는 것을 의미한다. 제어의 주도권이 개발자에서 스프링 프레임워크로 넘어가짐. 그래서 제어의 역전.