엔터프라이즈 자바빈즈
1. 개요
1. 개요
엔터프라이즈 자바빈즈는 자바 플랫폼을 위한 서버 측 컴포넌트 모델이다. 썬 마이크로시스템즈에 의해 개발되어 1998년에 최초로 등장했으며, 자바 EE 플랫폼의 핵심 부분을 구성한다. 이 기술은 주로 분산 트랜잭션 처리, 높은 확장성, 그리고 엄격한 보안이 요구되는 기업용 애플리케이션의 비즈니스 로직을 구현하는 데 사용된다.
EJB는 미들웨어의 한 형태로, 복잡한 분산 컴퓨팅 환경에서 애플리케이션 개발의 복잡성을 감소시키는 것을 목표로 한다. 개발자는 EJB 표준에 따라 비즈니스 로직을 작성하면 되며, 트랜잭션 관리, 보안, 동시성 제어, 연결 풀링과 같은 하부 시스템 서비스는 EJB가 동작하는 컨테이너가 제공한다. 이를 통해 개발자는 핵심 업무 로직에 더 집중할 수 있고, 애플리케이션의 이식성과 유지보수성을 높일 수 있다.
2. 역사
2. 역사
엔터프라이즈 자바빈즈의 역사는 1990년대 후반으로 거슬러 올라간다. 당시 기업 환경에서는 복잡한 분산 컴퓨팅 애플리케이션을 구축하는 데 어려움을 겪고 있었다. 이러한 문제를 해결하기 위해 썬 마이크로시스템즈는 1998년 자바 플랫폼을 위한 서버 측 컴포넌트 모델인 EJB 1.0 사양을 발표했다. 이는 자바 EE 플랫폼의 핵심 구성 요소로 자리 잡으며, 개발자가 확장성, 트랜잭션 관리, 보안과 같은 복잡한 인프라 문제보다는 비즈니스 로직 구현에 집중할 수 있도록 설계되었다.
초기 버전인 EJB 1.x와 2.x는 강력한 기능을 제공했지만, 복잡한 배포 서술자와 컨테이너에 대한 과도한 의존성으로 인해 개발이 번거롭다는 비판을 받았다. 특히 엔티티 빈의 성능과 객체-관계 매핑 기능은 한계를 보였다. 이러한 문제점은 경량화된 대안 프레임워크들의 등장을 촉발시켰다.
EJB의 역사에서 중요한 전환점은 2006년 EJB 3.0 사양의 등장이었다. 이 버전은 기존의 복잡성을 대폭 줄이기 위해 어노테이션을 도입하고, POJO 기반의 프로그래밍 모델을 채택했다. 또한 자바 퍼시스턴스 API를 통합하여 엔티티 빈을 대체하는 현대적인 ORM 솔루션을 제공했다. 이후 EJB는 세션 빈과 메시지 기반 빈을 중심으로 계속 발전하여, 현재는 자바 EE 및 그 후속인 자카르타 EE 생태계 내에서 특정 유형의 미들웨어 서비스를 구현하는 선택적 기술 중 하나로 자리매김하고 있다.
3. 아키텍처
3. 아키텍처
3.1. EJB 컨테이너
3.1. EJB 컨테이너
EJB 컨테이너는 엔터프라이즈 자바빈즈 애플리케이션의 실행 환경을 제공하는 서버 측 소프트웨어 구성 요소이다. 이 컨테이너는 자바 EE 애플리케이션 서버의 핵심 부분으로, EJB 구성 요소의 생명주기를 관리하고, 트랜잭션, 보안, 동시성, 연결 풀링과 같은 시스템 수준의 서비스를 투명하게 제공한다. 개발자는 비즈니스 로직 구현에 집중할 수 있도록 이러한 복잡한 인프라 문제를 컨테이너에 위임한다.
EJB 컨테이너는 세션 빈, 메시지 기반 빈, 엔티티 빈과 같은 EJB 구성 요소를 배포하고 실행한다. 컨테이너는 각 빈의 생성, 활성화, 비활성화, 제거를 관리하며, 클라이언트의 요청을 적절한 빈 인스턴스에 전달한다. 또한 분산 트랜잭션의 원자성, 일관성, 고립성, 지속성을 보장하는 트랜잭션 관리자와 협력하여 트랜잭션 경계를 설정하고 롤백을 처리한다.
보안 측면에서 EJB 컨테이너는 선언적 또는 프로그래밍 방식의 접근 제어를 구현한다. 개발자는 배포 서술자를 통해 역할 기반의 권한을 설정할 수 있으며, 컨테이너는 메서드 호출 전에 사용자 인증과 권한 부여를 자동으로 수행한다. 이는 애플리케이션 코드와 보안 정책의 분리를 가능하게 한다.
컨테이너는 확장성과 고가용성을 지원하기 위해 인스턴스 풀링, 캐싱, 클러스터링과 같은 기법을 사용한다. 예를 들어, 스테이트풀 세션 빈의 비활성 인스턴스를 패시베이션하여 메모리를 확보하거나, 여러 서버 인스턴스에 걸쳐 작업 부하를 분산시킬 수 있다. 이러한 기능들은 기업용 애플리케이션이 대규모 사용자와 데이터를 처리하는 데 필수적이다.
3.2. EJB 구성 요소
3.2. EJB 구성 요소
엔터프라이즈 자바빈즈의 핵심 구성 요소는 주로 비즈니스 로직을 구현하고 데이터베이스와 상호작용하는 서버 측 컴포넌트이다. 이러한 구성 요소들은 EJB 컨테이너 내에서 실행되며, 컨테이너가 제공하는 트랜잭션 관리, 보안, 동시성 제어, 생명주기 관리 등의 서비스를 자동으로 활용한다. 주요 구성 요소로는 세션 빈, 메시지 기반 빈, 그리고 엔티티 빈이 있다.
각 구성 요소는 특정한 역할을 수행한다. 세션 빈은 클라이언트의 요청을 처리하는 비즈니스 프로세스를 캡슐화하며, 상태를 유지하는 스테이트풀 세션 빈과 상태를 유지하지 않는 스테이트리스 세션 빈으로 구분된다. 메시지 기반 빈은 JMS 메시지를 비동기적으로 처리하는 데 특화되어 있다. 엔티티 빈은 영속성 데이터를 객체 형태로 표현하는 모델이었으나, 이후 JPA 표준의 등장으로 그 역할이 대체되었다.
이러한 구성 요소들은 인터페이스와 구현 클래스로 정의된다. 원격 클라이언트가 접근할 수 있는 비즈니스 인터페이스와 EJB 컨테이너가 컴포넌트의 생명주기를 관리하기 위해 사용하는 콜백 메서드가 포함된 클래스가 그것이다. 배포 서술자나 어노테이션을 통해 컴포넌트의 동작과 컨테이너 서비스에 대한 요구사항을 선언적으로 지정할 수 있다.
4. EJB의 종류
4. EJB의 종류
4.1. 세션 빈
4.1. 세션 빈
세션 빈은 엔터프라이즈 자바빈즈의 핵심 구성 요소 중 하나로, 클라이언트와의 단일 세션 동안 비즈니스 로직을 캡슐화하고 실행하는 역할을 담당한다. 주로 애플리케이션의 업무 흐름을 제어하거나 복잡한 계산을 수행하는 데 사용되며, 데이터베이스나 다른 시스템과의 상호작용을 조정한다. 세션 빈은 그 상태 유지 방식에 따라 상태 저장 세션 빈과 상태 비저장 세션 빈으로 구분된다.
상태 저장 세션 빈은 특정 클라이언트와의 대화 상태를 유지한다. 클라이언트가 서버와의 연결을 유지하는 동안, 빈의 인스턴스 변수 값이 세션 동안 계속해서 유지되어 여러 번의 메서드 호출에 걸쳐 정보를 기억할 수 있다. 이는 예를 들어, 온라인 쇼핑 카트의 내용을 임시로 저장하는 데 적합한 모델이다. 반면, 상태 비저장 세션 빈은 클라이언트별 상태를 유지하지 않는다. 각 메서드 호출은 독립적으로 처리되며, 이로 인해 컨테이너는 제한된 수의 빈 인스턴스로 많은 클라이언트 요청을 효율적으로 처리할 수 있어 확장성과 성능에 유리하다.
세션 빈은 원격 메서드 호출 또는 로컬 인터페이스를 통해 접근할 수 있으며, 선언적 트랜잭션 관리와 보안 설정을 지원한다. 자바 EE 애플리케이션 서버 내의 EJB 컨테이너는 세션 빈의 생명주기, 트랜잭션, 보안, 동시성 제어 등의 서비스를 관리하여 개발자가 순수한 비즈니스 로직에 집중할 수 있도록 돕는다.
4.2. 메시지 기반 빈
4.2. 메시지 기반 빈
메시지 기반 빈은 자바 메시지 서비스를 통해 비동기적으로 메시지를 수신하고 처리하는 엔터프라이즈 자바빈즈의 한 유형이다. 이는 세션 빈이나 엔티티 빈과 달리 클라이언트가 직접 메서드를 호출하는 방식이 아닌, 메시지 큐나 토픽과 같은 JMS 목적지로 전송된 메시지에 의해 트리거된다는 점이 특징이다. 따라서 클라이언트와 컴포넌트 간의 느슨한 결합을 가능하게 하며, 시간이나 시스템 부하에 구애받지 않는 신뢰할 수 있는 비동기 통신을 구현하는 데 적합하다.
메시지 기반 빈은 javax.ejb.MessageDrivenBean 인터페이스를 구현하며, 주로 onMessage() 메서드를 오버라이드하여 비즈니스 로직을 작성한다. EJB 컨테이너는 배포 서술자나 어노테이션을 통해 빈이 구독할 JMS 목적지를 설정하고, 해당 목적지에 메시지가 도착하면 컨테이너가 빈의 인스턴스를 생성하여 onMessage() 메서드를 호출한다. 이를 통해 주문 처리, 재고 관리, 금융 거래 알림 등 배치성 작업이나 이벤트 기반의 시스템 통합에 널리 활용된다.
메시지 기반 빈은 트랜잭션 관리와 보안 서비스를 EJB 컨테이너로부터 자동으로 제공받을 수 있으며, 풀링 기법을 통해 인스턴스를 효율적으로 관리하여 대량의 메시지를 동시에 처리할 수 있는 확장성을 제공한다. 이는 기업 애플리케이션 통합이나 복잡한 워크플로우 시스템을 구축할 때 중요한 장점이 된다.
4.3. 엔티티 빈
4.3. 엔티티 빈
엔티티 빈은 엔터프라이즈 자바빈즈의 한 종류로, 데이터베이스에 저장된 영속적인 비즈니스 데이터를 객체 지향적인 방식으로 표현하고 관리하기 위한 컴포넌트이다. 자바 EE 애플리케이션에서 비즈니스 로직과 데이터 접근 계층 사이의 중요한 추상화 계층을 제공한다. 엔티티 빈은 관계형 데이터베이스의 테이블 레코드나 객체 지향 데이터베이스의 객체에 대응되며, 각 엔티티 빈 인스턴스는 데이터베이스의 특정 레코드를 나타낸다.
엔티티 빈의 주요 역할은 데이터의 영속성을 관리하는 것이다. 이를 위해 EJB 컨테이너는 엔티티 빈의 상태와 데이터베이스 레코드를 동기화하는 작업을 담당한다. 개발자는 자바 퍼시스턴스 API나 엔티티 빈 자체의 컨테이너 관리 영속성 기능을 통해 복잡한 SQL 쿼리 작성 없이도 객체를 통해 데이터를 생성, 조회, 수정, 삭제할 수 있다. 이는 객체-관계 매핑의 초기 형태로 볼 수 있다.
엔티티 빈은 세션 빈과 함께 사용되는 경우가 많다. 세션 빈이 애플리케이션의 비즈니스 프로세스와 작업 흐름을 처리하는 반면, 엔티티 빈은 그 프로세스에서 사용되는 핵심 데이터 객체를 모델링한다. 예를 들어, 은행 애플리케이션에서 '계좌 이체'라는 작업은 세션 빈이 처리하고, '계좌'와 '고객' 정보는 엔티티 빈으로 표현된다.
초기 EJB 2.x 스펙의 엔티티 빈은 복잡한 배포 서술자 작성과 성능 문제로 인해 비판을 받았다. 이후 EJB 3.0 스펙에서는 훨씬 간소화된 JPA 기반의 새로운 엔티티 모델이 도입되면서, 기존의 엔티티 빈은 사실상 구식 기술이 되었다. 현대의 자바 기업 애플리케이션에서는 JPA와 그 구현체인 하이버네이트를 사용하여 영속성을 관리하는 것이 표준이 되었다.
5. 생명주기
5. 생명주기
엔터프라이즈 자바빈즈의 생명주기는 EJB 컨테이너에 의해 철저히 관리된다. 컨테이너는 빈의 생성, 활성화, 비활성화, 소멸과 같은 모든 단계를 제어하며, 이는 개발자가 복잡한 스레드 관리나 메모리 관리와 같은 저수준 작업에 신경 쓰지 않고 비즈니스 로직에 집중할 수 있게 해주는 핵심 메커니즘이다. 생명주기 관리는 세션 빈과 엔티티 빈마다 그 특성에 따라 다르게 정의된다.
상태 비저장 세션 빈의 생명주기는 비교적 단순하다. 클라이언트 요청이 들어오면 컨테이너가 필요에 따라 빈 인스턴스를 생성하거나 풀에서 가져와 메서드를 실행한다. 작업이 완료되면 인스턴스는 다시 풀로 반환되어 다음 요청을 대기한다. 이 과정에서 빈은 특정 클라이언트의 상태를 유지하지 않는다. 반면, 상태 저장 세션 빈은 클라이언트와의 대화 상태를 유지해야 하므로, 생성된 후 활성 상태로 유지되다가 일정 시간 동안 사용되지 않으면 컨테이너에 의해 비활성화되어 직렬화되어 이차 저장소로 옮겨질 수 있다. 이후 클라이언트가 다시 호출하면 컨테이너가 인스턴스를 재활성화시킨다.
엔티티 빈의 생명주기는 영속성과 밀접하게 연관되어 있다. 엔티티 빈은 데이터베이스의 레코드에 매핑되며, 그 생명주기는 '존재하지 않음', '풀링됨', '준비됨' 등의 상태를 포함한다. 컨테이너는 엔티티를 조회하거나 생성하여 메모리에 로드(준비 상태)하고, 트랜잭션이 커밋되면 변경 사항을 데이터베이스에 동기화한다. 사용이 끝나면 인스턴스는 풀로 돌아가고, 최종적으로 제거되면 데이터베이스에서도 해당 레코드가 삭제된다. 이러한 생명주기 관리 덕분에 개발자는 분산 트랜잭션과 영속성 같은 복잡한 미들웨어 서비스를 직접 구현하지 않고도 안정적인 기업용 애플리케이션을 구축할 수 있었다.
6. 장단점
6. 장단점
엔터프라이즈 자바빈즈(EJB)는 기업 환경에서 요구되는 복잡한 요구사항을 해결하기 위해 설계되었으며, 이로 인해 뚜렷한 장점과 단점을 지닌다.
EJB의 주요 장점은 기업 애플리케이션 개발의 복잡성을 대폭 감소시킨다는 점이다. 개발자는 트랜잭션 관리, 보안, 동시성 제어, 분산 컴퓨팅과 같은 복잡한 인프라스트럭처 수준의 문제를 직접 구현할 필요 없이, 비즈니스 로직 자체에 집중할 수 있다. 이러한 서비스들은 EJB 컨테이너에 의해 선언적 또는 자동으로 제공되며, 이는 생산성 향상과 더욱 견고한 애플리케이션 구축으로 이어진다. 또한, EJB는 자바 EE 플랫폼의 핵심 표준으로서, 다양한 애플리케이션 서버 간의 이식성을 보장하여 벤더 종속성을 줄여준다.
반면, EJB는 특히 초기 버전에서 심각한 단점을 노출했다. 가장 큰 문제는 과도하게 복잡하고 무거운 아키텍처였다. 이는 학습 곡선을 매우 가파르게 만들었고, 개발 및 배포 과정을 느리게 하며, 시스템 자원을 많이 소모하는 결과를 초래했다. 또한, 엔티티 빈과 같은 특정 구성 요소는 객체-관계 매핑(ORM) 기능이 제한적이고 성능이 떨어져 비판을 받았다. 이러한 복잡성과 무거움은 소규모 프로젝트에는 적합하지 않게 만들었고, 결국 더 가볍고 유연한 대안 프레임워크들의 등장을 촉발하는 계기가 되었다.
7. 다른 기술과의 비교
7. 다른 기술과의 비교
7.1. 스프링 프레임워크
7.1. 스프링 프레임워크
엔터프라이즈 자바빈즈는 복잡한 기업용 소프트웨어 개발을 위한 초기 표준이었으나, 스프링 프레임워크의 등장으로 자바 엔터프라이즈 애플리케이션 개발 패러다임에 큰 변화가 일어났다. 스프링은 2000년대 초반 로드 존슨이 제시한 설계 철학과 POJO 기반의 경량 프레임워크로 시작하여, EJB의 복잡성과 컨테이너 의존성을 크게 줄이는 대안으로 자리 잡았다. 스프링의 핵심 개념인 의존성 주입과 관점 지향 프로그래밍은 애플리케이션의 구성 관리와 횡단 관심사를 분리하는 데 중점을 두어, 보다 유연하고 테스트하기 쉬운 코드 작성을 가능하게 했다.
두 기술의 주요 차이점은 아키텍처 접근 방식에 있다. EJB는 자바 EE 애플리케이션 서버에 강하게 결합된 공식 표준 스펙으로, EJB 컨테이너가 트랜잭션 관리와 보안 같은 서비스를 제공한다. 반면 스프링은 경량 컨테이너를 지향하며, 필요에 따라 톰캣 같은 간단한 서블릿 컨테이너에서도 실행될 수 있다. 스프링은 EJB의 기능 대부분을 스프링 트랜잭션, 스프링 시큐리티 같은 자체 모듈로 대체하면서도, EJB 세션 빈과의 통합을 지원하여 점진적인 전환을 도왔다.
시간이 지나며 스프링의 영향력은 커졌고, 이는 EJB 스펙 자체의 진화에도 영향을 미쳤다. EJB 3.0 스펙은 어노테이션 기반의 단순화된 프로그래밍 모델과 JPA를 도입하여 스프링의 장점을 많이 수용했다. 결과적으로 현대의 자바 엔터프라이즈 개발에서는 순수 EJB보다는 스프링 프레임워크, 또는 스프링을 기반으로 한 스프링 부트가 사실상의 표준으로 널리 사용되고 있다. 이는 개발 생산성, 유연성, 다양한 기술 스택과의 통합 용이성 측면에서 스프링이 더 큰 장점을 보여주기 때문이다.
