EJB 개념

정의

  EJB 아키텍쳐는 객체지향 분산 엔터프라이즈 어플리케이션의 개발 및 분산 배치를 위한 컴포넌트 아키텍쳐입니다. 엔터프라이즈 자바 빈즈 아키텍쳐를 이용해 만들어진 어플리케이션은 확장성이 있고, 트랜잭션을 보장하며 다수 사용자 환경에서도 안전합니다. 어플리케이션은 한 번 작성되면 엔터프라이즈 자바 빈즈 스펙을 지원하는 어떤 서버 플랫폼에서도 배치되고 운영될 수 있습니다.

구성  

EJB Server, EJB Container

EJB Component를 설치할 수 있는 환경 제공

여러가지 시스템 레벨의 기능 처리해준다.

Deployment Descripter검사로 EJB Component의 작동환경 설정

Client의 Access요청 접수

데이터베이스, 트랜잭션등의 Container에서 필요한 여러 서비스 제공

운영체제개념

EJB Component

Business Logic을 담고 있는 객체

Session Bean

Entity Bean

 EJB Container 역할

Session Bean과 Entity Bean의 작동환경 제공

트랜잭션 처리

엔터프라이즈 빈에 대한 보안 관리

엔터프라이즈 빈의 Pooling기능

컨테이너간의 호환성

엔터프라이즈 빈에 대한 Customizing가능 제공

 엔터프라이즈 빈 구성요소  

리모트 인터페이스

  엔터프라이즈 빈의 리모트 인테페이스는 빈이 어떤 일을 수행하기 위해서 외부 세계에 제공하는 빈의 비즈니스 메소드를 정의합니다. 리모트 인터페이스는java.rmi.Remote를 계승한 javax.ejb.EJBObject 를 상속받고. 실제로 이 인터페이스는 EJB Container 에 의해서 자동으로 구현되게 됩니다. 이때 구현된 실체를 EJB 객체라 부르고. EJB 개발자는 Remote Interface 의 인터페이스를 제작하여 설치하면 Container는 뒤에 볼 Bean Class 를 Composite로 연결하여 이 인터페이스를 Implement 하게 됩니다.

홈 인터페이스

  홈 인터페이스는 새로운 빈을 생성하고, 제거하고, 찾아내는 등의 빈의 사이클 메소드를 정의합니다. 이는 java.rmi.Remote 를 계승한 javax.ejb.EJBHome 을 상속 받고. 리모트인터페이스와 마찬가지로 EJB Container에 의해서 자동으로 구현되게 됩니다. 이때 구현된 실체를 EJB 홈이라 부릅니다.

빈 클래스

  빈 클래스는 실제로 빈의 비즈니스 메소드를 구현합니다. 그런데 놀랍게도 빈 클래스는 일반적으로 빈의 홈이나 리모트 인터페이스를 Implement 하지 않고, 다만 빈 클래스는 반드시 리모트 인터페이스에 정의된 메소드들과 대응하는 메소드들을 가져야 합니다. 리모트 인터페이스와 홈 인터페이스의 구현은 Java Beans 메커니즘에 의해서 이루어지게 되는데 이에 대해서는 이후에 언급하겠습니다. 엔터프라이즈 빈이 Entity Bean 일 경우 javax.ejb.EntityBean을 구현하여야 하며 세션빈은 javax.ejb.SessionBean 을 구현하여야 합니다.

프라이머리 키

  프라이머리 키는 데이터 베이스로의 포인터를 제공하는 매우 단순한 클래스입니다. 프라이머리 키는 엔티티 빈에만 필요하며, 이 클래스가 반드시 갖추어야 할 요건 한가지는 Serializable 인터페이스를 구현하여야 합니다.

 엔터프라이즈 빈의 작동원리

  서버에 의해 자동으로 생성된 EJB Object 는 Remote Interface 를 implement 하고 있고, 또한 Bean Class에 대해서 참조점을 유지하고 있습니다. 즉 Composite 패턴으로 BeanClass 를 확장한다는 것입니다.(Entity Bean의 경우)

          

[그림1]. EJB 동작 원리

 Client 와 EJB간 상호작용  

[그림2]. EJB 상호작용

 

  먼저 Client는 JNDI로 객체의 위치를 파악합니다 . JNDI는 맨 처음의 기반기술에서 언급한 기술로써 네트웍상의 리소스에 대한 위치파악과 검색 서비스를 제공하는 API입니다. JNDI는 또한네트웍상의 객체의 참조에서도 쓰이고. Client는 JNDI로 HomeInterface를 구현한 객체를 가져 오게 됩니다. HomeInterface를 구현한 객체는 서버에 의하여 자동으로 만들어 진 것이고 Client에서는 이의 Interface만을 인지하고 있으면 되므로 다음과 같이 가져올 수 있습니다. 이렇게 HomeInterface를 가져온 후 이 홈인터페이스를 이용하여 EJBObject를 Create하거나 remove 또는 검색합니다. 이후 Client 에서 이 Remote Interface의 메소드를 호출하면 Server에서 Bean Class를 호출하여 Business Logic을 수행하게 됩니다.

 Bean Class  

Entity Bean

  대량의 데이터를 처리하기 위해서 보통 DB를 사용합니다. 전통적으로 개발자들은 DBMS에서 제공하는 여러 가지 API를 이용하여 직접 DB에 데이터를 저장하고 또 가져오게 됩니다. 예를 들어 1000개의 Record가 있는 데이터가 있는 경우 DB에서 원하는 정보를 가지고 오는 메소드를 작성하고 가져온 데이터를 처리하게 됩니다. Entity Bean은 이것과는 다른 상소한 개념을 가지고 있고 Entity Bean은 DB의 Record를 대표하게 됩니다. 즉 DB에 1000개의 레코드가 있다면 Entity Bean 인스턴스가 1000개가 존재하는 것으로 생각하면 됩니다. 다르게 말하자면 Entity Bean는 DB의 Schema를 대표하고 Entity Bean 인스턴스는 그 Schema의 DB Record 를 대표하는 것입니다..
  개발자는 다량의 Entity Bean 중 원하는 Entity Bean을 검색한다면 DB에서 원하는 Record를 검색하는 것과 같은 의미를 띄게 됩니다. Pooling을 설명할 때 언급했듯이 Entity Bean은 Container-managed Entity Bean과 Bean -Managed Entity Bean 두 가지로 나눌 수 있습니다.
  이 두 방법은 Entity Bean 내의 필드관리는 누가 맡게 되느냐에 따라 차이를 두게 되고 Container-managed Entity Bean는 개발자가 프로그래밍을 하지 않더라도 Container가 직접 Entity Bean 의 필드관리를 맡습니다. Client가 특정 Entity Bean 을 Search하는 작업을 수행한다면 Server 측에서 이를 DB에서 검색하여 Entity Bean의 필드로 값을 전달하고 Client로 이를 리턴하게 되는데 이 DB와의 연동작업을 Container가 알아서 해준다는 것입니다. 이에 반하여 Bean -Managed Entity Bean은 직접 이 코드를 작성해 줘야 합니다.
  만약 주식거래 시스템을 구현한다면 Entity Bean에 해당하는 요소는 주식 , 고객 등 실제로 어떠한 실체를 가진 것이 될 것입니다.

Session Bean

  Session Bean은 비즈니스 로직을 담고 있는 Bean이고 Client는 주로 Session 빈을 이용하여 Entity Bean에 접근하고 또 여러 가지 작업을 수행하게 됩니다.
  일반적으로 Session Bean 내부에는 필드를 만들지 않는 것이 좋습니다. 즉 한 개의 메소드로 수행될 수 있는 작업들만을 Session Bean 내에 생성하는 것을 권장합니다. SessionBean 내에 필드를 두어 Client 측에서 2개 이상의 메소드를 수행하여야 한다면 (즉 상태를 가져 각 상태에 따라 같은 메소드로 다른 것을 수행한다면) Pooling 되었을 때를 대비하여 상태를 저장하는 코딩이 추가되어야 합니다.

 Deployment Descriptor

  Deployment Descriptor는 Text 파일로서 내부에는 XML Schema로 구성되어 있습니다. 이 파일은 Entity Bean일 경우 EntityDescriptor라는 객체 인스턴스에 여러 설정사항을 메소드를 호출하여 설정한 뒤 이를 직렬화하면 생성되게 됩니다. 맨 처음에 언급한 XML 형식의 직렬화를 구현한 객체입니다. 또한 SessionBean 일 경우도 비슷하게 SessionDescriptor 라는 클래스를 직렬화 하면 이 파일을 생성할 수 있습니다. 대부분의 EJB Server 제품은 이 것을 자동화하는 여러 가지 툴을 제공합니다.

 Jar

  자바의 표준 압축파일은 jar는 여러 클래스들을 이 내부에 압축하고 또 모아둘 수 있고 자바버츄얼머신에서도 이를 지원하여 압축을 풀지 않고도 jar 내부의 클래스들을 조사하고 사용할 수 있습니다. 엔터프라이즈 자바빈을 Container에 설치할 때는 바로 jar 파일을 이용하게 됩니다. jar 파일내부에는 manifest라는 파일을 포함하여야 한다. manifest에 jar에 압축된 파일 중 어떤것이 Deployment Descriptor인지 명시 해놓는다. jar 파일을 EJB Container에 설치할 때 Container는 jar 파일내부의 manifest 파일을 찾게 되고 이 파일 parsing하여 Deployment Descriptor를 찾게 됩니다. Container는 이 파일을 파싱하여 홈인터페이스, 리모트 인터페이스, 빈 클래스 파일의 이름을 알아내고 jar 내부의 이 파일들을 적합한 위치에 설치하게 됩니다.