Sun Developer Network 공식 블로그

TS-5343 EJB3.1 Technology  - JCO 기술전략팀장 김홍회(자바스터디네트워크)

 한때 많은 관심을 끌었던 EJB는 EJB 2.1을 기점으로 기타 프레임워크의 등장 이후 어느덧 유저들의 관심에서 멀어져 갔다. 그 주요 이유는 XML 파일 작성 등 개발이 어려운 점을 비롯하여 EJB를 대체할 만한 기술이 많이 나와 굳이 EJB를 사용하지 않고도 트랙젝션 관리 등 소프트웨어 품질을 보장할 대체 기술이 많았다는 점일 것이다.

이에 SUN은 이러한 상황을 풀어나가기 위해 EJB 3.0에서 Hibernate의 아버지 Gabin King을 영입하며 Entity Bean을 Hibernate화 하는 등 ease of use에 초점을 맞췄으나 아직 복잡한 감이 많이 남아 있었으며 유저의 관심을 되돌리기에는 역부족이었다. 이번 EJB 3.1은 이러한 요구 사항을 인식한 듯 ease of use에 또다시 초점을 맞췄다.

EJB 3.1의 가장 큰 변화는 인터페이스의 과감한 삭제이다. 세션빈 비즈니스 인터페이스를 선택적으로 생성할 수 있게 함으로써 개발과정 중 인터페이스를 만들고 그에 맞춰 Bean을 만들며 Business Logic을 구현하는 복잡함을 생각하지 않아도 된다는 점은 개발자의 요구를 수긍한 듯 하다. 그리고 Gavin King이 EJB 3.1에 준 또다른 선물은 WebBeans의 편리한 사용이다. Gavin King은 WebBeans JSF(JSR 299)를 이끌고 있는데 EJB에도 그 영향을 준 듯 하다. Beans를 WebBeans에 적용하기 매우 쉽게 되어 있으며 예제는 다음과 같다.

 @Stateless @WebService
Public class PlaceBean {
 @PersistenceContext
  private EntityManager entityManager;
  @WebMethod public void placeBid(Bid bid) {
  entityManager persist(bid)
  }
}

또한 singleton, Timerservice, Asynchronous등의 다른 기능들도 추가 되었다. 이들의 사용법은 위와 마찬가지로 매우 간단하며 어노테이션 형식으로 @ + 기능명을 명시해 주면 된다.

먼저 singleton은 session bean의 새로운 type으로서 애플리케이션간 state를 공유하는 데 쓰인다. 예전 Stateful Session Beans도 세션 캐쉬를 공유할 수 있었으나 state 공유가 쉽지는 않았다. Signleton을 사용하는 방법은 다양하다. 제일 쉬운 것은 GOF singleton pattern POJO의 static field를 사용하는 것이다. 다음은 Servlet Container 애플리케이션의 클러스터를 사용해서 state 공유를 하는 방법도 있다. 그러나 이들은 thread safe 하지 않거나 transactional 하지 않는 단점이 있었다. 이에 대한 해결책으로서 EJB 3.1에서는 singleton을 지원해준다. 컨테이너가 single EJB 3.1 singleton의 객체를 공유한다는 것은 애플리케이션 티어에서 cache state를 공유할 수 있다는 것을 뜻한다. singleton은 single threaded가 기본이며 선택적으로 Bean과 컨테이너 Managed  형식으로 concurrency 형상유지가 가능하다. 이를 통해 read only와 애플리케이션의 시작 및 종료시 프로그램의 분기를 명시할 수 있다. 예제는 다음과 같다.

@Singletom
Public class DiscountRateBean {
@PersistenceContext
private EntityManager entityManager;
private Rate rate;
@PostConstruct
private void init() {
 rate = entityManager find(Rate.class, 1);
}
@PreDestroy
private void destroy(){
entityManager merge(rate);
}
public void setRate(Rate rate){
  this.rate = rate;
}
public Rate getRate() {
  return rate;
}
}
 

 위 예제에서 setRate와 getRate 메소드를 호출하는 어떠한 Bean들도 singleton의 적용을 받게 된다.

 다음으로 추가된 기능은 Timerservice이다. EJB 3.0에서 Timer Service를 제공했었는데 이는 programmatically하게 선언할 수는 있었으나 선언적으로 사용할 수 없었다. 즉. 일정 시간을 두고 한 달에 한번 Timer를 다시 세팅하는 등 스케쥴링 하는 기능을 사용하는데는 취약했다. 그러나 EJB 3.1에서의 Timerservice는 Calendar Based 형식으로 Automatic timer 생성이 가능하며 Timeout시와 특정시간대의 schedule 형식으로 시간에 따른 프로그램 분기를 명시할 수 있다.  예제는 다음과 같다.

 @Stateless
public class NewsLetterGeneratorBean implements NewsLetterGenerator {
   @Schedule(second="0", minute="0", hour="0",
                dayOfMonth="1", month="*", year="*")
    public void generateMonthlyNewsLetter() {
        ... Code to generate the monthly news letter goes here...
    }
}
 

위와 같이 @Schedule 함수를 사용하여 원하는 날짜별로 프로그램 실행을 지원한다.

 마지막으로 Asynchrony의 지원으로 프로그램의 동기화 기능을 지원했다. 동기화는 대부분 애플리케이션에서도 사용되고 있으므로 사용자들도 그 의미를 충분히 알 것이라 판단되어 설명을 생략하겠다. 예제는 다음과 같다.

@Stateless
public class OrderBillingServiceBean implements OrderBillingService {
    ...
 
    @Asynchronous
    public void billOrder(Order order) {
        try {
            // Attempt to charge the order.
            bill(order);
            // Send email notification of billing success.
            notifyBillingSuccess(order);
            order.setStatus(OrderStatus.COMPLETE);
        } catch (BillingException be) {
            // Send email notification of billing failure.
            notifyBillingFailure(be, order);
            order.setStatus(OrderStatus.BILLING_FAILED);
        } finally {
            update(order);
        }
    }
     ...
}
 

이처럼 EJB 3.1은 기능면에서 다양해지고 좀 더 개발이 편한 방향으로 방향을 잡고 있지만 세션 참석자 수가 같은 시간대의 다른 세션에 비해 상대적으로 적었으며 JavaFX등 다른 기술이 여러 세션을 가진데 비해 EJB 세션은 단 두 개였다는 점은 EJB에 대한 관심이 예전에 비해 저조해 졌음을 느낄 수 있었다. 더욱 강력해 진 기능과 개발 편의성을 가지고 반전에 나선 EJB. 그 행보가 기대된다.