[Spring Framework] EJB의 등장과 쇠퇴

 

EJB(Enterprise Java Beans)는 당시, EJB 컨테이너에 의해 분산된 EJB 컴포넌트를 마치 같은 머신에 있는 것처럼 접근할 수 있게 하거나, 분산된 데이터베이스의 트랜잭션을 마치 하나의 데이터베이스만 있는 것 처럼 제어할 수 있는 분산 처리와 분산 트랜잭션의 융합 컴포넌트로 탄생한 기술이다.

EJB 발전의 근원은 같은 분산 기술인 CORBA에 있다. CORBA가 벤더 각자의 설게로 상호 운용성(interoperability)을 잃었기 때문에 상호 운용성을 확보하기 위해 만든 기술이 EJB라고 할 수 있다. 이처럼 EJB란 원래 분산 환경을 위한 컴포넌트로 등장했을 뿐, JSP, Servlet과 같은 웹 애플리케이션을 위한 기술은 아니었다.

 

 

 

사실 과거의 EJB에는 이러한 점에서 오해가 있었다. 
물론 오해하게끔 홍보한 사람들이 있었지만, 어느새 EJB는 웹 애플리케이션용 재사용할 수 있는 컴포넌트나 SQL 기술이 필요없는 DB 액세스 프렝미워크가 됐다. 그리고 JSP와 Servlet으로 프레젠테이션을 구현하고 비즈니스 로직은 EJB로 구현하는 것이 웹 애플리케이션에서의 권장 설계가 됐다.

하지만 이러한 권장 설계를 믿고 웹 애플리케이션을 개발한 개발자들에게서 불만의 목소리가 높아지기 시작했다. 애초에 EJB는 분산용 컴포넌트이므로 원격 엑세스밖에 지원하지 않는다. 그런데 웹 애플리케이션은 분산 처리를 거의 사용하지 않으며 로컬 엑세스가 필요하다.
 또한 EJB 컨테이너에 의존하는 EJB는 테스트하기 어렵다는 문제가 지적되었고, EJB의 사양도 복잡해서 많은 개발자가 멀리하는 존재가 되었다.

EJB가 트랜잭션을 소스 코드에서 분리하거나 컴포넌트를 풀링해 리소스를 절약하는 등 아주 뛰어난 설계 철학을 바탕으로 했다면, 그래서 EJB를 무리하게 웹 애플리케이션의 비즈니스 컴포넌트라고 강조하지 않고 제대로 웹 애플리케이션용으로 재구축했다면 스프링은 태어나지 않았을지도 모른다. 하지만 얄궃게도 EJB는 Java EE로 새로 단장한 EJB 3 이후로 스프링+하이버네이트와 아주 비슷한 사양으로 다시 등장했다.

때가 너무 늦은 감도 있꼬 기존 EJB와는 사양이 너무 달랐다. 마치 "오랜만에 TV에서 건담을 보았는데, 아무로도 사야도 나오지 않고 애초에 그림이 전혀 다른데도 건담인가?"라고 할 정도로 버전 3 이전의 EJB와 현재의 EJB는 다른 제품이다.

그러다 1.7.6 부품화의 미래에 기술한 마이크로서비스 아키텍처가 등장했다. 왠지 과거 EJB의 재탕이 아니냐는 이야기도 나오고 있고, 웹 서비스의 재탕이라는 이야기도 있지만, 역시 역사는 반복되는 것 같다.