EJB (Enterprise Java Bean)
Java bean이란 자바 객체를 재사용 가능하게 컴포넌트화 시킬 수 있는 코딩 방침을 정의한 것을 의미합니다.
( bean은 쉽게 component 또는 객체라고 이해하면 좋습니다. )
그리고 Java bean 스펙에 맞게 구현된 코드를 웹에서 쉽게 사용하기 위해서 JSP 표준 액션 태그를 지원 합니다.
( <jsp:useBean> , <jsp:getProperty> , <jsp:setProperty> )
EJB란 Enterprise 개발을 단순화하기 위해 발표한 스펙입니다.
애플리케이션에는 비즈니스와 관련된 객체가 많기 때문에, "비즈니스 객체들을 관리하는 컨테이너를 만들어서 필요할 때 마다 컨테이너로부터 객체를 받는 식으로 관리하면 좋겠다"고 생각을 했고, 그래서 EJB가 탄생했습니다.
스프링 탄생 배경
당시 EJB의 개념이 획기적이었기 때문에 J2EE 서버 개발 벤더들은 EJB 스펙을 구현하여 여러 WAS 제품을 출시했습니다. ( WebLogic , Jeus 등 … )
그런데 보안, 트랜잭션, 분산 컴퓨팅 등 컨테이너의 다양한 서비스를 제공 받기 위해서는 EJB 스펙을 지켜야 했으며, EJB 컨테이너가 없을 경우 WAS의 다양한 서비스를 사용할 수 없다는 단점이 있었습니다.
그 결과 서비스가 구현해야 하는 실제 비즈니스 로직보다 EJB 컨테이너를 사용하기 위한 상투적인 코드들이 많다는 문제가 발생하기 시작했죠.
예를들어 DAO에서 사용하는 메서드는 고작 3개인데, EJB 스펙을 지키기 위해 여러 클래스를 상속 받아야 하고, 구현해야 하는 클래스가 많다보니 DAO 자체의 메서드보다 EJB를 사용하기 위한 코드가 많아졌습니다.
또한 벤더 사마다 EJB 컨테이너를 구현한 내용이 다르기 때문에 다른 벤더 사의 컨테이너로의 변경에 어려움이 있었고, 설정이 너무 복잡하다는 문제점이 부각되기 시작했습니다.
이런 문제들이 발생한 이유는 비즈니스 로직에 특정 기술이 종속되어 있다는 것입니다.
이를 기술 침투라고 하는데, 이것이 EJB의 가장 큰 문제점입니다.
애초에 컨테이너는 필요할 때 마다 다른 객체를 컨테이너에서 받아내는 방식을 통해 객체들간의 의존성 해결이 목적이였습니다.
스프링 창시자인 로드 존슨은 EJB를 사용하지 않고도 객체간 의존성 해결이 가능한 컨테이너를 개발했는데, 이것이 스프링의 시작이 되었습니다.
즉 특정 기술에 종속되지 않고( 기술 비침투적 ) 객체를 관리할 수 있는 컨테이너를 제공하는 것이 스프링의 기본 철학입니다.
스프링은 WAS의 기능적인 부분을 유지하되 기술 침투적인 부분을 모두 해결해주며, 따라서 개발자는 비즈니스 로직에 집중할 수 있도록 해줍니다.
이것이 스프링의 철학이고, 개발자는 이 철학을 이해하면서 개발을 해야 스프링을 잘 사용하고 있다고 할 수 있습니다.
스프링 컨테이너
스프링 컨테이너는 특정 클래스를 상속하거나 인터페이스를 구현하지 않는 평범한 자바 클래스(POJO, Plain Old Java Object)를 이용하여 EJB의 기능을 유지하면서 복잡성을 제거하고, 객체들의 라이프 사이클을 관리해줍니다.
각 라이브러리들의 객체들은 스프링 컨테이너에서 관리하기 때문에 사용법이 일관적이라는 특징이 있습니다.
Spring Container는 위의 그림과 같이 여러 객체들이 모여있는 공장( Bean Factory )과 같은 개념입니다.
Spring Container를 Bean Factory 또는 IoC Container 라고도 합니다.
의존성 주입( DI )과 제어 역전 ( IoC )
컨테이너의 주 목적은 의존성 해결이라고 했었습니다.
그렇다면 의존성은 무엇일까요?
위의 코드를 보면 클래스 A에서 B객체를 사용하고 있습니다.
클래스 A에서는 객체 B가 있어야 B의 메서드를 사용할 수 있기 때문에, A는 B에 의존적이라 할 수 있습니다.
스프링 컨테이너에서는 의존성 주입 ( DI, Dependency Injection )을 통해 의존성을 해결합니다.
의존성 주입이란 사용자가 직접 new 키워드를 사용하여 객체를 생성하지 않고, 외부( 컨테이너 )에서 생성된 객체를 주입 받는 방식을 말합니다.
설정 파일에서 아래와 같이 bean을 등록하면 의존성이 해결 됩니다.
<bean id=’a’ class=”A” ref=’b’>
<bean id=’b’ class=”B” >
또는 어노테이션 @Autowired를 통해 의존성 주입을 해결 합니다.
스프링에서는 이와 같이 의존성 주입을 통해 객체 간의 의존성 문제를 해결하며,
객체의 생성과 소멸을 개발자가 관리하지 않고 스프링에서 관리하는데, 이러한 현상을 제어 역전 ( IoC, Inversion of Control )이라 합니다.
이상으로 스프링에 대한 전반적인 내용을 마치도록 하겠습니다.
스프링은 기술 비침투가 핵심입니다.
이 말을 하고 싶어서 EJB를 시작으로 스프링이 탄생하게 된 배경을 언급했던 것입니다.
이 밖에 DI , IoC 등 키워드를 언급했는데 이 개념 또한 스프링의 핵심입니다.
스프링을 하면서 자연스럽게 익히게 될 개념이므로, 이런 개념들이 있다 정도만 이해하셔도 될 것 같습니다.