BLUE STUDY :: EJB(Enterprise Java Beans)

Programming/Java2007/09/28 09:34

EJB(Enterprise Java Beans)

SUN Microsystems사의 EJB Spec 2.0에 의한 EJB의 정의는 다음과 같습니다.

Enterprise JavaBean is an Architecture for component-based distributed object computing. Enterprise beans are components of distributed transaction-oriented enterprise applications.

한마디로 분산 객체 컴퓨팅 환경에서의 트랜잭션 처리를 위한 Java Bean Component를 EJB라 부르고 있다. EJB의 특성은 다음과 같습니다.

EJB의 특성

EJB는 Enterprise Data를 운용하는 Business Logic을 포함합니다.
EJB의 Instance들은 Runtime시에 Container에 의해 생성되고 관리되어집니다.
EJB의 전개(Deployment)시 해당 EJB의 환경변수(Environment Entries)의 편집으로 EJB는 Customizing될 수 있습니다.
Transaction이나 보안과 같은 Service들은 EJB Class와는 독립되어 있으며, 이는 Application이 조합되고 전개될 때 Tool에 의해 관리되어집니다.
Client로부터의 EJB로의 접근은 해당 EJB가 전개된 Container에 의해 중재 되어집니다.
EJB Spec을 따른다면, 어떤 EJB 도 모든 Container에서 사용 가능합니다.
EJB는 Source Code의 변형이나 재 Compile 없이 조합(Assemble)되어질 수 있습니다.
EJB의 Client View를 제공하는 것은 Bean provider입니다.

위의 특성 중 EJB의 Openness에 대한 부분은 좀 사실과 다를 수 있습니다. 즉, 개념적으로 사용자에 의해 작성된 EJB는 어떤 EJB Engine Vendor제품에도 동일하게 사용할 수 있어야 하지만 이것은 SUN Microsystems사가 EJB의 모든 부분에 대하여 완전한 SET의 EJB Spec을 제공했을 경우입니다. 현실이 그렇지 않기 때문에 현재의 EJB Spec은 EJB Engine Vendor들로 하여금 혼란을 야기할 소지가 있는 조항을 가지고 있습니다. 그것이 의도적이건 그렇지 않건 간에 어쨌든 현재의 EJB 기술은 100% 완전한 표준 형태를 지니고 있지 않은 것이 사실입니다.

EJB 관련 용어

CTM(Component Transaction Monitor)

전통적인 TP(Transaction Processing) Monitor와 ORB(Object Request Broker)의 복합 형태로 꾸준히 개선되어 왔고 이를 통하여 개발자들이 Business System을 쉽게 만들어 내고, 사용하며 배치할 수 있도록 하는 강력한 Server Component Model을 말합니다. CTM은 Transaction, Distributed Object, 동시성 제어, 보안, Persistency등과 자원관리를 자동화해주는 하부 구조를 제공합니다. 이러한 개념에서 EJB는 CTM을 위한 표준 Server Component Model이라 하겠습니다.

분산 객체 아키텍쳐(Distributed Object Architecture)

RMI(Remote Method Invocation) Protocol을 이용하여 STUB - SKELETON - Server Object 의 구조로 구성되어 있습니다.

STUB : Server 호출을 위한 Client의 대리인
SKELETON : 특정 IP Address와 Port와 맞물려 있으며 Stub의 요청을 서버 Object와 연결시키는 역할 수행

< EJB 호출 메커니즘 >

EJB는 그 역할과 형태에 따라 크게 두 가지 종류를 가지고 있습니다. 하나는 Session Bean이고 또 하나는 Entity Bean입니다. 전
형적인 System Modeling 개념에서 Session Bean은 Process를 대표하며 Entity Bean은 Entity를 대표합니다. 즉, 객체 지향 Application에서는 더 이상 설계와 구현이 뚜렷하게 나뉘어지지 않고 있으며 설계가 곧 구현으로 이어지는 자연스러운 형태를 띄게 되었습니다. Java Application을 객체 지향의 시각에서 바라보지 않으면 이것을 이해할 수 없습니다. 그것은 마치 Entity Bean 객체를 통해 Database의 Table을 생성시킬 수 있다는 것을 Procedural 한 시각에서 이해할 수 없는 것과 마찬가지 입니다.

Entity Bean

Entity Bean은 Persistent Data를 표현하는데 사용됩니다. 대부분의 경우에 있어서 각각의 Entity Bean의 Field들은 RDBMS의 Field들로 Mapping 되어집니다. 그러나 좀 더 복잡한 상황에서는 이것들이 Application의 method호출이나 기존의 CICS Transaction의 실행 결과로써 얻어지기도 합니다. Entity Bean은 그 형태에 따라 BMP(Bean-Managed Persistence)와 CMP(Container-Managed Persistence)가 있습니다. 단순하게 BMP는 Container의 역할을 사용자가 Code로 구현해야 하는 것을 말합니다. 이에 반해 CMP는 Source Data 정의 및 그 Access와 같은 Low-Level의 일들을 Container에서 해주기 때문에 개발자는 Business Logic에만 전념할 수 있고 그 만큼 Application의 이식성이 좋아집니다. 실제 많은 상황에서 CMP가 사용됩니다.

Session Bean

Session Bean이 Entity Bean과 다른 점은 Primary Key Class를 갖지 않는다는 점입니다. Entity Bean 이 Data Storage내의 Permanent Data를 대표하는 것에 반해 Session Bean은 특정 Client와 결부되어 생성되고 소멸됩니다. Session Bean은 Data를 저장하거나 Load하지 않으며 Session Bean을 가장 쉽게 이해할 수 있는 것은 Session Bean을 단순히 Client Module의 확장이라고 생각하는 것입니다. 단지 그 확장이 Server에 존재할 뿐입니다.