finerss's world!

Spring IOC

공부/Spring2011. 12. 12. 22:19

-Spring 에서의 IOC

Spring 프레임워크를 보면 Lightweight Container 라는 단어나 IoC라는 단어가 자주 나온다.

Spring 프레임워크를 이해하기 위해서 가장 먼저 이해해야 하는 것은 IOC 개념이다. 또한  이 IOC 개념이 Container 기능이 된다.

Spring 프레임워크에는 여러가지 모듈이 있는데 IoC모듈은 모든 Spring 모듈의 가장 기본적인 Core 기능을 제공함으로 그만큼 중요하다고 할수 있다.

-Container, Lightweight Container 란

컨테이너의 기본 틍징을보면
Lifecycle Management
Lookup
Configuration
Depenency Resolution
Thread Management
Object Pooling
Clustering Management
Remotion
Exposing remote services
Customization and extensibility

등의 기능을 포함 한다는 것이다.

컨테이너는 여러가지 면에서 반드시 필요한데 첫쨰로 컴포넌트/오브젝트의 자유로운 삽입(Pluggability)이 가능하도록 하기위한
calling code 의 독립성 떄문이다. 둘쨰는 서비스의 lookup이나 configuration이 일관성을 갖도록 하기 위한 것이다.
셋쨰는 단일화된 서비스의 접근방법을 제공하기 위한것이다. 예로 개발자 각자 자기만의 스타일로 싱글톤이나 팩토리를 만들어 쓸 필요가 없어야 한다는 것이다. 넷쨰는 비지니스 오브젝트에 부가적으로 필요로하는 각족 enterprise service를 제공하기 위해서이다.

그렇다면 lightweight Container 의 특징은 무엇일까? 일반 컨테이너처럼 애플리케이션 코드를 관리해 주지만 그 코드 내에 컨테이너에 대한 의존적인 부분들이 필요 없도록 해준다. 코드 내에 컨테이너에서 동작하기 위해서 특별히 필요로하는 부분이 없기떄문에 가볍다고 할수있는것이다.
컨테이너를 알지못하는 오브젝트 또는 알 필요도 없는 오브젝트를 가능하게 해준다는 것이다. 이는 컨테이너 내에 오브젝트를 배치(deploy) 하기 위한
복잡한 과정이 없다는 것을 의미한다. 컨테이너  그 자체로 가볍다는것을 의미한다.

'공부 > Spring' 카테고리의 다른 글

About Spring  (0) 2011.12.12
엔티티 빈  (0) 2011.07.26
RMI(원격 메소드 호출, Remote Method Invocation)  (3) 2011.07.04

About Spring

공부/Spring2011. 12. 12. 21:25

-Framework


1) Framework 란 무엇인가?

프레임워크란  프래그래머가 프로그램을 만드는데 있어 아주 기본이 되는 골격 코드를 말한다.

중요한 것은 이 골격이라는 것이 어떤 특별한 목적을 가지고 있다는 점이다. 건물을 만들기 위한 골격, 배를 만들기 위한 골격처럼말이다.

골격을 보면 앞으로 완성품이 무엇이 될지 예상할 수가 있따. 그래서 이 프레임워크를 반제품이라고 부르는 사람도 많다.

반제품, 즉 반쯤 완성된 제품이라는 의미이다. 반쯤 완성되었기 떄문에 프레임워크를 이용하는 사람은 나머지 반 부분만 채워 넣어주면 된다.

프레임워크 자체는 완전한 애플리케이션 소프트웨어가 아닌 어떤 문제영역을 해결하기 위한 잘 설계된 일반적인,

재사용 가능한 모듈(이미만들어진 '반') 이기 떄문에 완결된 애플리케이션으로 제공되지 못한다.

따라서 사용자가 프레임워크를 확장하여 비즈니스 요구사항을 만족시키는 완전한 애플리케이션 소프트웨어를  완성시키는 작업( 나머지 ' 반') 이 요구되

는 것이다.

<변경이되지않는 Core부분인 Cold Spot 위에 훅 포인트(Hook Point)를 통해 확장한다(Hot Spot).>
 


즉 프레임워크는 Open-Closed 원칙 (이하 OCP)을 그대로 따르고있다. 재사용되는 공통된 부분은 프레임워크로 구현되어

다른사람이 그 내부를 가공 없이 이용하도록 제공하고 있다(Closed). 확장이 필요한 부분은 사용자 요구사항에 맞게 정의하여 확장시키므로

문제영역에 최적화된 애플리케이션 설계가 완성된다(Open) *이를 확장에는 열려있고, 병경에는 닫혀있다라고 말한다.

프레임워크를 애플리케이션에 적용할 떄 변경되지 않고 반복적으로 재사용되는 부분을 프레임워크의 코어로 정의한다. 변경이 잘 일어나지 않는

프레임워크의 코어부분을 콜드 스팟(Cold spot)이라고 부르기도 한다.(OCP) 에서 Closed 모듈에 해당한다).

프레임워크 코어는 각 애플리케이션마다 확장 모듈을 연결하는 확장 점을 제공하는데, 이를 훅 포인트(Hook Point)라고 한다.

대개 훅 포인트는 추상 클래스나 인터페이스의 형태로 나타낸다. 애플리케이션마다 이 훅 포인트를 통해 확장 모듈을 바인딩한다.

이확장 모듈을 핫스팟(Hot Spot)이라고 부른다(OCP에서 Open 모듈에 해당한다).

일반적으로 훅 포인트는 사용자가 소스코드 상에서 함수 호출을 통해 확장 모듈을 등록(혹은 바인딩)하게 된다.

하지만 바인딩 코드들이 사용자 코드 곳곳에 분포되어 산만하고 반복 작업을 하게 되는데 이런 불편 떄문에 현재 프레임워크는 메타 데이터를

이용하여 훅 포인트로의 연결, 정책 설정들을 정의하고 있는 추세이다.

이렇게 프레임워크에 기반해 애플리케이션을 개발하게 되면 생산성이 향상될 뿐 아니라 여러 애플리케이션이 비슷한 구조를 가지게 되므로
 
관리하기도 쉬워진다.

2) 자바 프레임워크에는 어떤 것이 있는가?

대표적인 자바 프레임 워크로는 (이것이 전부는아니다)

웹 어플리케이션 프레임워크: Spring MVC, Struts, WebWork 등
데이터베이스 관련 프레임워크: iBatis, Hibernate, Spring DAO
비지니스 관련 프레임워크 : Spring
*Spring의 경우 객체를 생성하고 객체간의 의존관계를 정의하고 라이프 사이클을 제어하는 틀을 제공해주며,
거기에다 다른 프레임워크들을 서로 연결해 주는 역활도 한다.

-Spring 소개

1)EJB

Spring을 이야기 하기 전에 앞어 EJB를 살펴보면, EJB는 Enterprise JavaBeans 의 약자로 엔터프라이즈 급의 서비스를 제공하는 것을

목적으로 한다. EJB에 대한 문서를 읽어보면 'EJB는 엔터프라이즈 애플리케이션 개발을 단순화 한다'  라고 소개하고 있다.

하지만 이는 그 이전의 엔터프라이즈 애플리케이션과 비교하였을 때 맞는 이야기이고 실상은 그 개발이 단순화하지 못하고 있는것이

사실이다.

EJB의 선언적 프로그래밍 모델이 트랜잭션이나 보안과 같은 개발의 기반구조에 해당하는 여러 측면들을 단순화 시킨것은 사실이지만,

배치 설명자(deployment descriptor), 홈/리모트 인터페이스 등과 같은 과도한 코드를 강제함으로써 다른 방식으로 복잡해졌다고

말할 수 있다. EJB는 분산 객체나 원격 트랜잭션 등의 복잡한 문제를 해결하기 위하여 만들어 졌기 떄문에 복잡하지만,

아이러니하게도 현실적으로 봤을 때 상당수의 엔터프라이즈 애플리케이션은 그정도로 복잡하지 않다는 것이다.

이러한 고민 안에서 스프링은 탄산하게 되었다.

2)Spring

Spring은 로드 존슨이 만든 오픈소스 프레임워크 이며, 복잡한 엔터프라이즈 애플리케이션을 겨냥해 만들어졌다.

스프링은 평범한 자바빈즈(이하 POJO - Plain Old Java Object)를 사용하는데도 EJB에서만 가능했던 일들이 모두 이뤄지게 한다.

그러나 스프링의 유용성은 서버 축 개발에만 국한 한 것이아니라, 모든 자바 애플리케이션에서 단순성, 테스트 용이성, 느슨한 결함성의 측면에서

스프링의 이점을 얻을 수 있다.

Spring 의 특징을 보면

경량 - 스프링은 그 크기와 부하의 측면에서 경량(liteweight)이다. 전체 스프링 프레임워크는 기껏해야 몇 메가 안되는 하나의 JAR 파일로 배포된다.
또한 스프링 자체의 부하는 무시해도 되는 수준이다.

제어 역행- 스프링은 제어 역행(IoC - Inversion of Control) 이라는 기술을 통해 애플리케이션의 느슨한 결합을 도모한다.
IoC가 적용되면 객체는 의존하는 다른 객체를 생성하거나 찾는 대신, 수동적으로 의존성을 받는다. 이런의미로 IoC를 의존성 주입이라고 말하기도한다.

관점지향 - 스프링은 관점지향 프로그래밍(AOP : Aspect Oriented Programming)을 위한 풍부한 지원을 한다.
관점지향 프로그래밍은 애플리케이션 비지니스 로직을 시스템 서비스로부터 분리함으로써 응집된 개발을 가능하게 한다. 애플리케이션 객체는 원래 해야할 일인 비지니스 로직을 수행하는 것 이외에는 아무것도 하지않는다. 애플리케이션 객체는 로깅이나 트랜잭션 지원과 같은 시스템적인 관심사에는 책임이 없으며 신경조차 쓰지 않는다.

컨테이너 - 애플리케이션 객체의 생명주기와 설정을 포함하고 관리한다는 점에서 스프링은 일종의 컨테이너라고 말할 수 있따. 빈의 인스턴스를 하나만
생성시키거나 또한 필요할 떄마다 설정 가능한 프로토 타입을 기반으로 새로운 인스턴스를 생성시키는 등 빈이 어떻게 생성되야 하는지를 직접
설정할 수 있다. 또한 빈이 서로 어떻게 연관돼야 하는지도 설정할 수 있다. 이 부분이야 말로 스프링의 가장 핵심적인 기능이라고 말할 수 있다.

프레임워크 - 스프링을 사용하면 간단한 컴포넌트로 복잡한 애플리케이션을 구성하고 설정할 수 있다. 스프링에서 애플리케이션 객체는 대게 XML파일
내에 선언적으로 구성한다. 또한 스프링은 애플리케이션 로직 개발은 개발자에게 맡기고, 다양한 기반구조 기능을 제공한다.







'공부 > Spring' 카테고리의 다른 글

Spring IOC  (0) 2011.12.12
엔티티 빈  (0) 2011.07.26
RMI(원격 메소드 호출, Remote Method Invocation)  (3) 2011.07.04

엔티티 빈

공부/Spring2011. 7. 26. 10:09

 

1. 엔티티 빈의 개요

1.1. 엔티티 빈이란?

데이터를 객체화하여 재사용이 가능한 컴포넌트를 말한다.

데이터를 객체화한다는 것은 개발자들이 데이터에 접근하고 변경하는 방법이 보다 단순하고 쉬워진다는 것을 의미한다. 객체화 된 데이터를 비즈니스 객체 또는 현실 세계의 객체 라고 하며 이 객체는 영속성을 가진 관계형 데이터베이스에 저장이 되며 데이터베이스에서 테이블의 한 레코드와 대응된다. 여기서 중요한것은 빈 인스턴스와 데이터베이스의 데이터가 동기화되어야 한다는 것이다. 즉 빈 인스턴스에서 새로운 변화가 일어날 때마다 데이터베이스도 같이 갱신이 되어야하는 것이다.

1.2. 엔티티 빈의 종류

- 컨테이너 관리 퍼시스턴스 (CMP)

- 빈 관리 퍼시스턴스 (BMP)

1.3. 엔티티 빈의 구성

- 홈 인터페이스

- 리모트 인터페이스

- 빈 클래스

- 프라이머리 키 클래스 (세션 빈 구성과 차이점)

2. CMP 와 BMP

2.1. CMP

CMP 는 퍼시스턴스를 EJB 컨테이너가 자동으로 관리하는 엔티티 빈을 말한다. 이것은 퍼시스턴스에 대한 책임은 EJB 컨테이너가 맡고 비즈니스 로직에 대한 책임은 개발자가 전담하는것이다.

CMP 에서는 EJB 컨테이너의 능력이 아주 중요하다. 빈 인스턴스가 어떻게 데이터베이스와 대응되는지 알아야 하고 그로부터 데이터베이스에 데이터를 추가, 변경, 삭제 하는 것을 자동 관리하는 역할도 해야 하기 때문이다.

2.2. BMP

CMP 와 달리 개발자가 직접 퍼시스턴스와 관련된 로직을 명시적으로 코딩해야 한다.

3. 엔티티 빈의 라이프 사이클

- 클라이언트 측면에서 본 엔티티 객체의 라이프 사이클

- 컨테이너 측면에서 본 엔티티 빈의 라이프 사이클

아래는 가이드 라인입니다

1.정의
* 서버 컴퓨터에서 실행되는 자바 컴포넌트 모델
즉, 자바로 만들어진 서버쪽 컴포넌트들로 기업용 애플리케이션을 만들 때 사용되는 표준 규칙

가. EJB는 스펙
나. EJB로 개발할 수 있는 app
클라이언트 部分, 서버콤포넌트部分

다. java bean

* 자바빈은 EJB가 나오기 훨씬 전에 만들어진, 주로 클라이언트에서 비주얼하게 다룰 수 있는 컴포넌트를
개발할 때 사용되는 모델

* 단지 자바빈즈의 컴포넌트 개념을 서버로 대폭 확장시켜 기업용 애플리케이션에 알맞게 만든 모델이므로
자바 빈즈라는 이름 앞에 엔터프라이즈를 덧붙여서 엔터프라이즈 자바빈즈가 된 것이다.

* 자바빈즈 모델은 트랜잭션, 보안등의 기업용 어플리케이션에 꼭 필요한 기능 스펙을 포함하고 있지 않다

라. EJB장점

* EJB 스펙대로 app를 구현하게 되면 시스템 레벨의 각종 기능들(보안, 트랜잭션, 안전성 등)이 자동으로 처리
되므로 개발자가 직접 해결할 필요가 없기 때문.
=> 트랜잭션, 보안, 패일오버등의 기능들이 app개발자가 아닌 app 서버(EJB 컨테이너) 차원에서 지원된다.
=> 개발자는 비즈니스 로직만 프로그래밍하면 되고,
그 결과 개발자가 모든것을 코딩했을 때보다 안정된 시스템이 개발된다

* 컴포넌트 방식으로 app를 개발할 수 있게 함으로서 코드의 쉬운 유지보수, 높은 확장성, 코드의 재사용성 등의 장점

2. EJB와 자바빈즈의 비교
* EJB와 자바빈즈는 둘다 자바의 컴포넌트 프로그래밍 모델.

* 자바빈즈:
(1) 비주얼하게 컴포넌트를 다룰 수 있게 하는데 초점이 맞추어 있다. 이벤트(event), 속성(property)등을 규정
(2) 개발자 도구에서 비주얼하게 수행되어질 수 있는 재사용 가능한 소프트웨어 컴포넌트

* EJB: 컴포넌트들이 서버의 EJB 컨테이너 안에 플러그인(plugin)되어 설치된 후
트랜잭션, 보안, 패일오버 등의 서비스를 하게 되는 프레임워크에 초점이 맞춰져 있다.


3. EJB Architecture

* Home Interface => Home객체 (Home Object)

import javax.ejb.*;
import java.rmi.RemoteException;

public interface Name_of_HomeInterface extends EJBHome
{
public Name_of_RemoteInterface create() throws RemoteException, CreateException;
}

클라이언트가 엔터프라이즈 빈을 사용할 수 있도록 생성(create)하거나
또는 사용하고자 하는 엔터프라이즈 빈이 존재한다면 그것을 찾는(find)메소드들,
즉 create, find관련 메소드들이 선언된다.

* Remote Interface => Ejb객체 (EJB Object)

import javax.ejb.*;
import java.rmi.Remote;
import java.rmi.RemoteException;

public interface Name_of_RemoteInterface extends EJBObject
{
public Return_Type Method() throws java.rmi.RemoteException;
}

클라이언트가 호출할 수 있는 엔터프라이즈 빈의 메소드들이 선언된다.
클라이언트가 호출할 수 있는 이런 메소드들을 비즈니스 메소드라고 한다.

* 빈 클래스(bean class) => Bean Instance

(1) 리모트 인터페이스안에 선언된 메소드들고 똑같은 이름의 메소드들의 내부코드를 구현해야 한다.
(2) EJB 컨테이너 규약 메소드들을 추가로 작성해야한다.
이것은 클라이언트가 아닌 EJB 컨테이너가 특정한 순간에 호출하는 메소드들이라서
EJB 컨테이너 규약(contract) 메소드

* deploy descriptor
트랜잭션, 보안, 자원관리등을 설정한 xml파일

----------------------------------------------------------------------
<홈 인터페이스, 홈 인터페이스를 구현(implement)한 클래스, 홈 객체의 관계>

홈 인터페이스는 개발자가 작성하며,
이 인터페이스를 구현(implement)한 클래스는 EJB 컨테이너에 의해 자동으로 생성된다
이 클래스에서 실행시에 생성된 객체를 "홈 객체"라고 한다.

<리모트 인터페이스, 리모트 인터페이스를 구현(implement)한 클래스, EJB객체의 관계>

리모트 인터페이스는 개발자가 작성하며,
이 인터페이스를 구현(implement)한 클래스는 EJB컨테이너에 의해 자동으로 생성된다.
이 클래스에서 실행시에 생성된 객체를 "EJB 객체"라고 한다.

<빈 클래스, 빈 인스턴스의 관계>

EJB컨테이너 실행시에 "빈 클래스"에서 생성된 객체를 "빈 인스턴스"라고 한다.
----------------------------------------------------------------------

4. 엔터프라이즈 빈
* 클라이언트가 호출하여 사용할 수 있는 EJB 컴포넌트를 의미.

* 엔터프라이즈 빈은 단지 한 개의 클래스를 의미하는 것이 아니라 EJB 아키텍쳐 안에
포함되는 컴포넌트를 지칭하는 단어이며 여러개의 클래스와 인터페이스로 구성된다.

* 최소 구성요소
home interface
remote interface
bean class
deploy descriptor

(1) Entity Bean : 영구적으로 저장되어야 할 데이터를 의미(구체적으로 DB의 테이블을 상징)
Entity Bean의 Bean instance는 테이블의 한 레코드를 상징
반면 빈클래스는 테이블 자체를 상징

* 영속성(persistence)을 관리하는 방식에 따라 : CMP(Container Managed Persistence), BMP(Bean Managed Persistence)

① CMP(Container Managed Persistence) : EJB 컨테이너가 자동으로 DB를 관리

* DB관리를 위한 코드를 작성할 필요없음
* Deploy time에 DB종류(관계형, 객체지향등) 상관없이 유연하게 Entity Bean과 연결 가능
* Entity Bean과 DB연결 방식은 EJB컨테이너가 제공하는 툴에 제한됨
* EJB 컨테이너에 의해 SQL문장이 생성되기 때문에 데이터 베이스의 세밀한 관리가 불가능
* 성능이 BMP방식보다 떨어질 수 있다.

② BMP(Bean Managed Persistence) : 빈 자체가 DB를 관리

* DB관리를 위한 코드 작성해야함
* DB관리방식이 Deploy Time에 바뀌지 않음
* 객체와 DB를 연결하는 방식을 빈 개발자가 자유롭게 만듬
* SQL 문장을 자유롭게 사용하여 세밀한 DB관리가 가능
* 개발자의 능력에 따라 CMP방식보다 좋을 수 있다.

(2) Session Bean : 비즈니스 프로세스, 즉 어떤 업무나 일 자체를 상징하는 컴포넌트

* 상태를 관리하는 방식에 따라 : stateful session bean(상태유지 세션빈), stateless session bean(무상태 세션빈)

① stateful session bean(상태유지 세션빈)
* HDD에 상태정보를 save, load하는 (activate/passivate)활성화/비활성화 과정이 수행된다

② stateless session bean(무상태 세션빈)
* activate/passivate과정이 없다

(3) 엔터프라이즈 빈 개발자가 할 일

가. 엔터프라이즈 빈의 종류 선택
나. 3 종류의 소스 코드 작성 및 컴파일
다. deployment
라. 테스트용 클라이언트 프로그램 개발
----------------------------------

가. 엔터프라이즈 빈의 종류 선택

① 개발할 엔터프라이즈 빈이 프로세스나 일의 과정이면 세션 빈,
② 데이터베이스의 데이터를 상징하면 엔티티빈
③ 세션빈으로 선택했다면 무상태 세션빈인지, 상태유지 세션빈인지 결정
④ 엔티티빈이면 BMP인지, CMP 엔티티 빈인지 선택
나. 3종류의 소스 코드 작성 및 컴파일

(A) 세션빈을 선택할 경우
(B) 엔티티빈을 선택할 경우
-------------------------

(A) 세션빈을 선택할 경우

[Home Interface]

① stateful session bean(상태유지 세션빈)

* 코드 템플릿 :
import javax.ejb.*;
import java.rmi.*;
public interface <BeanName>Home extends EJBHome
{
public <BeanName> create(<rmiParams>)
throws [businessException,...] CreateException, RemoteException;
}

* 상속 : javax.ejb.EJBHome을 상속받음

* create() 메소드 규칙 :
1) 한 개 이상의 create() 메소드들을 선언해야만 한다. 이때 파라미터가 존재 할 수 있다.
상태정보가 유지되어야 하기 때문에 초기화 데이터가 필요하며 따라서 파라미터가 존재할 수 있다.
무상태 세션빈과 다른 점은 create()메소드에 파라미터가 있어서(파라미터가 있을수도, 없을수도 있다)
EJB객체를 초기화 할 수 있으며 또한 개발자가 정의한 예외를 처리할 수 있다는 것이다.
2) create() 메소드의 반환 타입은 본 세션빈의 리모트 인터페이스 타입이다.
3) 반드시 "throw"를 사용하여 예외를 포함해야 한다.
이때 개발자가 정의한 비즈니스 예외처리를 할 수 있다.

* 빈 클래스와의 관계 :
홈 인터페이스의 모든 create() 메소드들은 빈 클래스에 똑같은 이름의 ejbCreate()들로
내부코드가 구현된다.(단, 반환값의 타입이 다르다)

* Example>
----------------------------------------------------
<Server Part>
import javax.ejb.*;
import java.rmi.*;
public interface CartHome extends EJBHome
{
Cart create(String customerName, String account)
throws RemoteException, CreateException, BadAccountException;
}

<Client Part>
// JNDI 컨텍스트 생성
Context initialContext = new InitialContext();

// JNDI로 홈객체의 레퍼런스를 얻음
CartHome cartHome = (CartHome)javax.rmi.PortableRemoteObject.
narrow(initialContext.lookup("java:comp/env/ejb/cart"), CartHome.class);

// EJB객체 생성
Cart cart = cartHome.create("John", "7506");
----------------------------------------------------

② stateless session bean(무상태 세션빈)

* 코드 템플릿 :
import javax.ejb.*;
import java.rmi.*;
public interface <BeanName>Home extends EJBHome
{
public <BeanName> create() throws CreateException, RemoteException;
}

* 상속 : javax.ejb.EJBHome을 상속받음

* create() 메소드 규칙 :
1) 단지 파라미터가 없는 한 개의 create()메소드를 선언해야만 한다
상태정보가 없으므로 초기화 데이터가 필요없기 때문에 create() 메소드의 파라미터가 없다
2) create() 메소드의 반환 타입은 본 세션 빈의 리모트 인터페이스 타입이다.
3) 반드시 'throws'를 사용하여 'CreateException' 예외를 포함해야 한다.
RemoteException이 포함된 것은 클라이언트가 RMI프로토콜로 엔터프라이즈 빈을 사용하기 때문이다.

* 빈 클래스와의 관계 :
홈 인터페이스의 모든 create() 메소드들은 빈 클래스에 똑같은 이름의 ejbCreate()들로
내부 코드가 구현된다.(단, 반환 값의 타입이 다르다)

* Example>
-----------------------------------------------------
<서버 부분>
import javax.ejb.*;
import java.rmi.*;
public interface CartHome extends EJBHome
{
Cart create() throws RemoteException, CreateException;
}

<클라이언트 部分>
Context initialContext = new InitialContext();

// JDNI로 홈객체의 레퍼런스를 얻음
CartHome cartHome = (CartHome)javax.rmi.PortableRemoteObject.
narrow(initialContext.lookup("java:comp/env/ejb/cart"), CartHome.class);

// EJB 객체 생성
Cart cart = CartHome.create();
-----------------------------------------------------


* 클라이언트 개발자는 홈 객체의 레퍼런스를 얻은 후에 다음과 같은 작업을 할 수 있다.

① 새로운 EJB객체 생성
② EJB 객체의 삭제
③ 세션 빈의 메타데이터를 얻는다. 이것은 주로 툴을 개발할 때 사용
④ 홈 객체를 가리키는 핸들을 얻는다.
핸들이란 네트워크로 떨어진 객체를 가리키는 레퍼런스를 추상화한 것이다.
이 핸들은 하드에 저장될 수 있으며 다른 컴퓨터로 네트워크를 통해 이동이 가능하다.

javax.ejb.EJBHome
{
EJBMetaData getEJBMetaData() 엔터프라이즈 빈의 메타데이터를 반환한다.
HomeHandle getHomeHandle() 홈 객체의 핸들을 반환한다.
void remove(Handle handle) 핸들이 가리키는 EJB객체를 삭제한다.
void remove(java.lang.Object primarykey) 엔티티 빈의 경우 프라이머리 키에 해당되는 EJB객체를 삭제
}
[Remote Interface]

* 세션 빈이 클라이언트에게 제공해야 하는 비즈니스 메소드를 선언한다.
* 클라이언트는 홈 객체를 통해 EJB객체를 생성하고
그 레퍼런스를 얻은 후 리모트 인터페이스에 선언된 메소드들을 호출할 수 있게 된다.
* 리모트 인터페이스를 구현(implement)한 클래스는 EJB컨테이너에 의해 자동으로 생성된다.
또한 적절한 실행시간에 그 클래스로부터 객체가 생성되는데 그 객체를 "EJB객체"라고 한다.
* 클라이언트가 비즈니스 메소드를 호출할 때 바로 이 객체의 비즈니스 메소드가 호출되며 이 안에서
빈 클래스의 객체인 빈 인스턴스의 해당 비즈니스 메소드를 호출한다.
* 실제로 비즈니스 메소드의 내부를 구현한 클래스는 빈 클래스이며 EJB 객체는 이 빈 클래스의 객체인
빈 인스턴스의 얼굴마담 역할을 한다.
이 EJB 객체는 RMI의 리모트 객체로서 스텁과 스켈레턴이 생성되어 클라이언트가 RMI 프로토콜로 접근하게 된다.

* 코드 템플릿 :
import javax.ejb.*;
import java.rmi.*;
public interface <BeanName> extends javax.ejb.EJBObject
{
public <rmiReturnType> <businessMethod> (<rmiParams>)
throws [<businessException>,...] RemoteException;
}

* 상속 : javax.ejb.EJBObject인터페이스를 상속받는다.

* 비즈니스 메소드 규칙 :
1) 모든 비즈니스 메소드들은 "throw"를 사용하여 RemoteException을 포함해야 한다.
클라이언트가 RMI 프로토콜로 엔터프라이즈 빈을 사용하기 때문
2) 어떤 비즈니스 메소드들은 개발자가 정의한 예외를 "throw"문에 포함할 수 있다.
3) 모든 비즈니스 메소드들의 파라미터와 반환 값의 타입은 반드시 RMI를 통해 이동될 수 있는 타입이어야한다.
즉, Serializable 인터페이스를 구현한 객체 또는 기본 데이터 타입 또는 리모트객체 중의 하나이어야 한다.

* 빈 클래스와의 관계 :
선언된 모든 비즈니스 메소드들은 빈 클래스에 똑같은 이름의 비즈니스 메소드들이 존재하며
그 안에 비즈니스 메소드의 내부 코드가 구현된다.

* Example>
------------------------------------------------
<Server Part>
import javax.ejb.*;
import java.rmi.*;
public interface Cart extends EJBObject
{
void addItem(int item) throws RemoteException
void purchase() throws RemoteException;
}

<Client Part>
Context initialContext = new InitialContext();

// JNDI로 홈객체의 레퍼런스를 얻음
CartHome cartHome = (CartHome) javax.rmi.PortableRemoteObject.
narrow(initialContext.lookup("java:comp/env/ejb/cart"), CartHome.class);

// EJB객체를 생성
Cart cart = cartHome.create("John", "7506");
cart.addItem(96);
cart.purchase();
------------------------------------------------


* 클라이언트 개발자는 EJB객체의 레퍼런스를 얻은 후에 다음과 같은 작업을 할 수 있다.

① 빈 인스턴스 비즈니스 메소드들의 간접적인 호출
② EJB 객체의 삭제
③ 세션 빈의 홈 객체를 얻는다
④ EJB 객체의 핸들을 얻는다
⑤ 현재의 EJB 객체와 다른 EJB 객체가 같은 객체인지 비교할 수 있다.

* javax.ejb.EJBObject는 여러 메소드들이 선언되어 있다.
따라서 클라이언트는 EJB 객체의 레퍼런스를 통해 비즈니스 메소드들을 호출하는 것 외에
다음과 같은 메소드들을 사용할 수 있다.

javax.ejb.EJBObject
{
public EJBHome getEJBHome() // 홈 객체를 반환한다.
public java.lang.Object getPrimaryKey() // 엔티티 빈일 경우 해당 프라이머리 키를 반환한다.
void remove() // EJB 객체를 제거한다.
public Handle getHandle() // EJB 객체의 핸들을 반환한다.
나중에 이 핸들을 사용하여 EJB 객체의 레퍼런스를 얻을 수 있다.
public boolean isIdentical(EJBObject obj)
// 현재 EJB 객체와 파라미터의 EJB 객체가 같은 객체인지 비교한다.
}

[빈 클래스]

* 빈 개발자는 두 가지 종류의 메소드를 구현해야 한다

① 리모트 인터페이스 비즈니스 메소드들과 똑같은 이름의 비즈니스 메소드
② EJB 컨테이너가 적정한 시점에 호출하는 EJB 컨테이너 규약 메소드
setSessionContext(), ejbCreate(), ejbRemove(), ejbActivate(), ejbPassivate()

* 빈 클래스 개발자는 홈 인터페이스에 선언된 모든 create() 메소드들을 ejbCreate()로 정의하며
또한 리모트 인터페이스 안에 선언된 모든 비즈니스 메소드들을 정의한다.
그리고 SessionBean 인터페이스 안에 선언된 4개의 메소드들의 내부를 구현해야 한다.

① stateless session bean

* 비즈니스 메소드 템플릿 :
import javax.ejb.*;
import java.rmi.*;
public class <BeanName>Bean implements SessionBean
{
public <rmiRV> <businessMethod> (<rmiParams>)
[ throws [<businessException>,...] RemoteException ]
{
/* 구현 */
}

// .. 다른 비즈니스 메소드들
}

* EJB 컨테이너 규약 메소드 템플릿 :

1) create 관련 메소드
import javax.ejb.*;
import java.rmi.*;
public class <BeanName>Bean implements SessionBean
{
public void ejbCreate() [ throws [CreateException][RemoteException] }
{
/* 구현 */
}

// 다른 ejbXXX 메소드와 비즈니스 메소드 구현
}

2) SessionBean 인터페이스에 선언된 컨테이너 규약 메소드의 구현
import javax.ejb.*;
import java.rmi.*;
public class <BeanName>Bean implements SessionBean
{
private SessionContext _context;
public void setSessionContext(SessionContext cxt)
{
_context = cxt;
}

public void ejbRemove(){ /* 구현 */ }
public void ejbActivate(){}
public void ejbPassivate(){}

//...
}

* 구현 여부 : 반드시 javax.ejb.SessionBean 인터페이스를 구현한다.

* 주의할 내용 :
1) 추상 클래스가 아닌, 객체를 생성할 수 있는 클래스를 정의해야 한다.
2) javax.ejb.SessionBean 인터페이스를 구현해야 한다.
즉, SessionBean 인터페이스 안에 선언된 메소드들을 모두 반드시 구현해야 한다.
이 안에 있는 메소드들이 EJB 컨테이너가 호출하는, EJB 컨테이너 규약 메소드들이다.
3) 리모트 인터페이스에 선언된 모든 비즈니스 메소드들과 똑같은 이름의 메소드들을 정의한다.
4) 홈 인터페이스의 create() 메소드와 대응되는 ejbCreate() 메소드를 정의한다.
보통 ejbCreate() 메소드의 내부는 비워둔다.
상태 정보가 유지될 필요가 없기 때문에 초기화할 필요가 없기 때문이다.
5) 무상태 세션 빈에서 ejbActivate(), ejbPassivate() 메소드의 내부는 일반적으로 비워두며
ejbCreate(), ejbRemove()에 초점을 맞춘다.

* 다른 인터페이스들과의 관계 :
1) 정의된 모든 비즈니스 메소드들은 리모트 인터페이스에 똑같은 이름의 메소드들로 선언되어 있어야 한다.
2) ejbCreate()에 해당하는 create() 메소드들이 홈 인터페이스에 선언되어 있어야 한다.

* Example>
import javax.ejb.*;
import java.rmi.*;
public class CartBean implements SessionObject
{
private SessionContext _context;

public void setSessionContext(SessionContext ctx)
{
_context = ctx;
}

public void ejbCreate() {}
public void ejbRemove() {}
public void ejbActivate() {}
public void ejbPassivate() {}

void addItem(int item) { // 구현 }
throws RemoteException;

void purchase() { // 구현 }
throws RemoteException;
}

② stateful session bean

* 무상태 세션 빈과의 차이점은 "활성화/비활성화"시에 호출하는 ejbActivate(), ejbPassivate()
메소드에 현재 상태를 유지하기 위한 적절한 코드를 작성해야 한다는 것이다.

* EJB 컨테이너는 자원이 절약되어야 한다고, 즉 "비활성화"해야 한다고 판단하면 자주
사용되지 않는 빈 인스턴스를 선택한 후 하드디스크에 해당 정보를 저장한다.
이때 빈 인스턴스의 ejbPassivate() 메소드를 먼저 호출한다. 클라이언트가 절약된 빈 인스턴스를
사용하려고 한다면 빈 인스턴스를 활성화해서 메모리로 올려야 한다. 이때는 먼저
하드디스크에서 빈 인스턴스 정보를 메모리에 올리고 빈 인스턴스의 ejbActivate()메소드를 호출한다.
(엔티티 빈에서도 이런 "활성화/비활성화" 작업이 일어난다)

비활성화 : ejbPassivate() => 저장
활성화 : 디스크에서 로드 => ejbActivate()

* 비즈니스 메소드 템플릿 :
무상태 세션 빈의 경우와 동일함

* EJB 컨테이너 규약 메소드 템플릿 :

1) create 관련 메소드
import javax.ejb.*;
import java.rmi.*;
public class <BeanName>Bean implements SessionBean
{
public void ejbCreate(<rmiParams>)
[ throws [CreateException] [RemoteException] ]
{/* 구현 */}

// ...
}

2) SessionBean 인터페이스에 선언된 컨테이너 규약 메소드
무상태 세션 빈의 경우와 동일함

* 구현 여부 : 반드시 javax.ejb.SessionBean 인터페이스를 구현한다.

* 주의할 내용 :
1) 추상 클래스가 아닌, 객체를 생성할 수 있는 클래스를 정의해야 한다.
2) javax.ejb.SessionBean 인터페이스를 구현해야 한다.
즉, SessionBean 인터페이스 안에 선언된 메소드들을 모두 반드시 구현해야 한다.
이 안에 있는 메소드들이 EJB 컨테이너가 호출하는, EJB 컨테이너 규약 메소드들이다.
3) 리모트 인터페이스에 선언된 모든 비즈니스 메소드들과 똑같은 이름의 메소드들을 정의한다.
4) 홈 인터페이스에 선언된 create 메소드들에 대응되는 ejbCreate() 메소드들을 정의한다.
파라미터가 있는 경우 그 값에 따라 세션 빈의 상태 정보를 초기화한다.
5) "활성화/비활성화"가 일어날 때 상태 정보를 계속 유지하기 위해서
ejbActivate(), ejbPassivate() 메소드를 적절히 구현한다.

* 다른 인터페이스들과의 관계 :
무상태 세션 빈의 경우와 동일함

* Example>

import javax.ejb.*;
import java.rmi.*;
public class CartBean implements SessionBean
{
private SessionContext _context;

// 상태유지 정보
private String customerName, account;

public void setSessionContext(SessionContext ctx)
{
_context = ctx;
}
public void ejbCreate(String customerName, String account)
{
this.customerName = customerName;
this.account = account;
}
public void ejbRemove() {}
public void ejbActivate()
{
// 활성화될 때 해야할 일을 구현
}

public void ejbPassivate()
{
// 비활성화 될 때 해야할 일을 구현
}

void addItem(int item) { // 구현 }
throws RemoteException;

void purchase() { // 구현 }
throws RemoteException;
}

* javax.ejb.SessionBean은 여러메소드들이 선언되어 있다. 그렇지만 이 메소드들을 클라이언트가
직접 호출하여 사용하는 것이 아니라 EJB 컨테이너가 자동으로 호출한다.
따라서 이런 메소드들은 EJB 컨테이너와 빈 개발자와의 일종의 약속이기 때문에 "EJB 컨테이너 규약 메소드"
라고 한다.(이런 메소드들은 이름이 ejbXXX() 등으로 시작한다)

- 클라이언트들은 비즈니스 메소드들을 EJB 객체를 통하여 간접적으로 호출할 수 있다. 클라이언트는
빈 클래스 및 인스턴스의 존재를 전혀 모르며 EJB 객체를 통하여 빈 인스턴스를 호출한다.

- 세션 빈 클래스를 작성할 때 빈 클래스 개발자는 실제 빈 인스턴스가 생성된 후에 EJB 컨테이너가
현재 어떤 정보를 가지고 동작하는지 알지 못한다. 이런 정보를 빈 클래스 안에서 사용하려고 한다면
EJB 컨테이너가 생성한 SessionContext 객체를 setSessionContext() 메소드로 받아서 속성으로
할당받은 다음 원하는 컨테이너 정보를 얻을 수 있다. SessionContext 객체가 제공하는 정보는
현재 빈 인스턴스와 연결되어 있는 EJB 객체의 레퍼런스이다.

javax.ejb.SessionBean
{
public void setSessionContext(SessionContext ctx) // SessionContext 객체를 넘겨받아서
빈 인스턴스의 속성에 할당한다.
컨테이너가 빈 인스턴스를 생성한 직후에 호출한다.
public void ejbRemove() // EJB 객체가 더 이상 사용되지 않을 때 컨테이너에 의해 호출
public void ejbActivate() // 빈 인스턴스가 "활성화"될 때 호출된다.
public void ejbPassivate() // 빈 인스턴스가 "비활성화"될 때 호출된다.
}
(B) 엔티티빈을 선택할 경우
* Home interface, Remote interface, Bean 클래스를 작성해야함(세션빈과 동일)
* Home interface에 findXXX()라는 메소드들을 추가로 선언해야함(세션빈과 차이)
(XXX는 개발자가 그 이름을 자유롭게 지정할 수 있다.)
* 엔티티 빈 클래스는 DB의 테이블을 상징하고, EJB 객체 및 빈 인스턴스는 테이블의 한 레코드를 상징한다.
* create()는 EJB 객체를 생성, 즉 테이블에 한 레코드를 추가하는 역할
* findXXX()들은 이미 존재하는 테이블 내의 특정 조건을 만족하는 레코드들,
즉 EJB객체들을 반환하는 역할을 한다
* findXXX()의 반환 타입은 엔티티 빈의 리모트 인터페이스이거나 Enumeration, Collection
등의 컬렉션 타입이어야 한다.
* 모든 엔티티 빈의 홈 인터페이스는 반드시 findByPrimaryKey() 메소드를 선언해야 한다.
findByPrimaryKey() 메소드의 파라미터는 테이블의 칼럼(column)에 해당되며 테이블의
프라이머리 키 역할을 해야 한다.
이 파라미터의 타입은 "프라이머리 키 클래스" 이며 String 또는 사용자가 정의한 클래스로서
테이블의 프라이머리 키를 상징한다.
* 프라이머리 키 클래스의 개념은 세션 빈에 없는 엔티티 빈만의 독특한 개념이다.
* 따라서 엔티티 빈을 개발할 때는 세션 빈과 달리 홈 인터페이스, 리모트 인터페이스, 빈 클래스외에
프라이머리 키 클래스를 정의해야 한다.
* CMP, BMP에 따라 코드 작성방식이 약간씩 달라진다.

[Home Interface]

* 엔티티 빈 클라이언트가 서버의 엔티티 빈을 사용하기 위해서는 홈 인터페이스의 create()메소드를
호출하여 EJB 객체를 생성해야 한다. 이 홈 인터페이스를 직접 구현(implement)한 클래스는
EJB 컨테이너에 의해서 자동으로 생성되고 적절한 시기에 그 클래스로부터 홈 객체가 생성된다.
생성된 홈 객체는 EJB 컨테이너 안에서 EJB 객체를 생성(create)하거나 찾는(find)공장(factory)역할을 한다

* 홈 인터페이스는 javax.ejb.EJBHome 인터페이스를 상속받은 인터페이스이다.
개발자는 단지 EJB 객체를 생성할 때 초기화해주는 create() 메소드들과
EJB 객체를 찾아서 반환하는 findXXX() 메소드들을 선언하기만 하면 된다.

* 코드 템플릿 : <PrimaryKey>는 프라이머리 클래스를 의미

1) create메소드 :
import javax.ejb.*;
import java.rmi.*;
public interface <BeanName>Home extends EJBHome
{
public <BenaName> create(<rmiParams>)
throws [<businessException>,...] CreateException, RemoteException;

// ...
}

2) findByPrimaryKey() 메소드 선언 :
import javax.ejb.*;
import java.rmi.*;
public interface <BeanName>Home extends EJBHome
{
public <BeanName> findByPrimaryKey(<PrimaryKey>)
throws [<businessException>, ...] FinderException, RemoteException;

// ...
}

3) findXXX() 메소드 선언 (옵션)

가. 한개의 EJB 객체 찾기
import javax.ejb.*;
import java.rmi.*;
public <BeanName> findXXX (<rmiParams>)
throws [<businessException>,]... FinderException, RemoteException;

나. 여러 개의 EJB 객체 찾기
import javax.ejb.*;
import java.rmi.*;
public Enumeration findXXX (<rmiParams>)
throws [<businessException>,]... FinderException, RemoteException;

* 상속 : 반드시 javax.ejb.EJBHome 인터페이스를 상속받는다.

* create() 메소드 규칙 : 상태 유지 세션 빈의 경우와 동일하다.

* find 관련 메소드 규칙 :

1) findByPrimaryKey()을 반드시 선언해야 한다.
반환 타입은 반드시 리모트 인터페이스어야 하며
"throw"는 FinderException과 RemoteException을 포함해야 한다.
단 1개의 파라미터를 정의해야 하며 그 타입은 테이터베이스 테이블의 프라이머리 키의
타입을 상징하는 프라이머리 키 클래스이다.

2) findXXX() 메소드의 반환타입은 리모트 인터페이스이거나 java.util.Enumeration,
java.util.Collection 타입이다. 반환타입이 Enumeration, Collection인 경우 포함된
원소들인 리모트 객체들을 추출하여 사용한다. Enumeration은 JDK1.1, Collection은 java2
에서 사용한다.

* 빈 클래스와의 관계 : 상태유지 세션 빈의 경우와 동일하다.

* Example>

<Server Side>
import javax.ejb.*;
import java.rmi.*;
public interface AccountHome extends EJBHome
{
public Account create(String firstName, String lastName, double initialBalance)
throws RemoteException, CreateException;

public Account create(String accountNumber, double initialBalance)
throws RemoteException, CreateException, LowInitialBalanceException;

public Account findByPrimaryKey(String AccountNumber)
throws RemoteException, FinderException;
}

<Client Side>
// JNDI로 홈 객체의 레퍼런스를 얻음.(세션빈과 동일)
AccountHome = ...;
Account account1 = accountHome.create("John", "Smith", 500.00);
Account account2 = accountHome.findByPrimaryKey("100-3450-3333");

int deposit = account1.deposit(1000);
balance = account1.balance();

* 만약 엔티티 빈이 상징하는 데이터베이스의 테이블의 프라이머리 키(Primary key)가 두개 이상이면
String이 아니라 그 프라이머리 키의 타입을 속성으로 한 프라이머리 키 클래스를 정의한다.
그리고 그 프라이머리 키 클래스를 findByPrimaryKey()의 파라미터의 타입으로 지정한다.
프라이머리 키 클래스는 반드시 디플로이먼트 디스크립터에 명시해야 하며
hashcode(), equals()등의 메소드들을 구현해야만 한다.

[리모트 인터페이스]

* 코드 템플릿 : 세션 빈의 경우와 동일
* 상속 : javax.ejb.EJBObject 인터페이스를 상속받는다.
* 비즈니스 메소드 타입 : 세션 빈의 경우와 동일
* 빈 클래스와의 관계 : 세션 빈의 경우와 동일
* Example>
<Server Side>
import javax.ejb.*;
import java.rmi.*;
public interface Account extends EJBObject
{
public double deposit(double amount)
throws ProcessingErrorException, RemoteException;
public double withdraw(double amount)
throws ProcessingErrorException, RemoteException;
public double balance()
throw RemoteException;
}

<Client Side>
// JNDI로 홈 객체의 레퍼런스를 얻음.(세션 빈과 동일)
AccountHome = ...;
Account account1 = accountHome.create("John", "Smith", 500.00);
Account account2 = accountHome.findByPrimaryKey("100-3450-3333");

int deposit = account1.deposit(1000);
balance = account1.balance();

[빈 클래스]

* 엔터프라이즈 빈의 핵심 클래스로서 EJB 개발자가 가장 신경써서 작성해야 하는 부분이다.
EJB 개발자는 2가지 종류의 메소드를 구현해야 한다.
1) 리모트 인터페이스의 비즈니스 메소드들과 똑같은 이름의 비즈니스 메소드
2) EJB 컨테이너가 때에 따라서 호출하는 EJB 컨테이너 규약 메소드
setEntityContext()
unsetEntityContext()
ejbCreate()
ejbRemove()
ejbActivate()
ejbPassivate()
ejbLoad()
ejbStore()

① CMP 엔티티 빈의 빈 클래스 작성요령

* 비즈니스 메소드 템플릿 :
import javax.ejb.*;
import java.rmi.*;
public class <BeanName>Bean implements EntityBean
{
public <Serializable type> <Attributes>;

// ...

public <rmiRV> <businessMethod>(<rmiParams>)
[throws [<businessException>,...] RemoteException]
{
/* 구현 */
}

// ...
}

* EJB 컨테이터 규약 메소드 템플릿
1) create 관련 메소드
가. create()
public class <BeanName>Bean implememts javax.ejb.EntityBean
{
public <PrimaryKey> ejbCreate (<rmiParams>)
throws [javax.ejb.CreateException,][java.rmi.RemoteException]
{
/* 구현 */
}

// ...
}

나. ejbPostCreate()
public void ejbPostCreate(<rmiParams>)
throws [javax.ejb.CreateException,] [java.rmi.RemoteException]
{
/* 구현 */
}

2) EntityBean 인터페이스에 선언되 컨테이너 규약 메소드
가. 일반 규약 메소드
public class <BeanName>Bean implements javax.ejb.EntityBean
{
private EntityContext _context;

public void setEntityContext(EntityContext ctx)
{
/* 컨텍스트 객체에 대한 레퍼런스를 유지한다 */
}
public void unsetEntityContext(EntityContext ctx)
{
/* 컨텍스트 객체에 대한 레퍼런스를 해제한다. */
}
public void ejbRemove(){ /* 구현 */ }
public void ejbActivate(){ /* 구현 */ }
public void ejbPassivate(){ /* 구현 */ }

// ...
}

3) "Load/Store"관련 메소드
public class <BeanName>Bean implements javax.ejb.EntityBean
{
// ...
public void ejbLoad() { /* 구현 */ }
public void ejbStore() { /* 구현 */ }
}

* 구현 여부 : 반드시 javax.ejb.EntityBean 인터페이스를 구현한다.

* 주의할 내용 :
1) 추상 클래스가 아닌, 객체를 생성할 수 있는 클래스를 정의해야 한다.
빈 클래스의 모든 속성은 엔티티 빈의 상태정보, 즉 데이터베이스 테이블의 칼럼을 상징한다.
따라서 public으로 선언되어야 하며 2차 저장소에 저장될 수 있도록 "Serializable"해야한다.

2) javax.ejb.EntityBean 인터페이스를 구현해야 한다.
즉, EntityBean 인터페이스 안에 선언된 메소드들을 모두 반드시 구현해야 한다.
이 안에 있는 메소드들이 EJB 컨테이너가 호출하는, EJB 컨테이너 규약 메소드들이다.

3) 리모트 인터페이스 선언된 모든 비즈니스 메소드들과 똑같은 이름의 메소드들을 정의한다.

4) 보통 ejbCreate() 메소드는 엔티티 빈의 상태정보를 초기화 하는 역할을 한다.
각 ejbCreate() 마다 ejbPostCreate()라는 메소드를 반드시 구현해야 하며
이 메소드는 ejbCreate() 메소드의 호출이 끝난 직후에 호출된다.

5) 엔티티 빈에서 setEntityContext()와 unsetEntityContext()를 구현한다.
ejbActivate(), ejbPassivate(), ejbRemove()도 구현한다.

* 다른 인터페이스들과의 관계 :
1) 정의된 모든 비즈니스 메소드들은 리모트 인터페이스에 똑같은 이름의 메소드들이 선언되어
있어야 한다.

2) ejbCreate()에 해당하는 create() 메소드들이 홈 인터페이스에 선언되어 있어야 한다.

* Example>
import java.util.*;
import javax.ejb.*;

public class ProductEJB implements EntityBean
{
public String productID;
public String description;
public double price;
private EntityContext context;

public void setPrice(doublc price)
{
this.price = price;
}
public double getPrice()
{
return price;
}
public String getDescription()
{
return description;
}

public String ejbCreate(String productID, String description, double price)
throws CreateException
{
if( productID == null )
{
throw new CreateException("The productID is required.");
}

this.productID = productID;
this.description = description;
this.price = price;

return null;
}

public void ejbPostCreate(String productID, String description, double balance){}

public void setEntityContext(EntityContext context)
{
this.context = context;
}

public void unsetEntityContext() {}

public void ejbActivate()
{
productID = (String)context.getPrimaryKey();
}

public void ejbPassivate()
{
productID = null;
description = null;
}

public void ejbRemove() {}
public void ejbLoad() {}
public void ejbStore() {}

}// ProductEJB

* CMP 엔티니 빈의 경우 ejbCreate() 메소드와 대응되는 ejbPostCreate()메소드와의 관계 :
EJB 컨테이너는 빈 인스턴스의 ejbCreate()를 호출한 후 데이터베이스의 레코드를 해당
파라미터로 초기화하며 그 후에 ejbPostCreate()를 호출한다.
이 모든 것을 EJB 컨테이너가 관리해준다.

* CMP 엔티티 빈 클래스에서는 홈 인터페이스에서 선언된 findXXX()를 개발자가 구현할 필요가 없다.
디플로이먼트할 때 EJB 컨테이너가 자동으로 findXXX() 메소드를 구현해주기 때문이다.

* EJB 컨테이너가 데이터베이스와의 일체화(synchronization)을 자동화하기 때문에
ejbLoad(), ejbStore()의 중요성은 낮아진다. EJB 컨테이너가 빈 인스턴스의 상태정보인
속성 값을 해당 데이터베이스에 저장하고 읽는 과정을 자동으로 관리해준다.

1) EJB 컨테이너가 빈 인스턴스의 상태 정보를 해당 데이터베이스에 반영해야 한다고 판단하면
먼저 빈 인스턴스의 ejbStore() 메소드를 호출한다.
2) 그리고 컨테이너가 자동으로 빈 인스턴스의 속성 값을 해당 데이터베이스에 쓴다.
3) 그리고 다시 데이터베이스의 값을 읽어서 빈 인스턴스의 속성 값으로 할당한다.
4) ejbLoad()메소드를 호출한다.

② BMP 엔티티 빈의 빈 클래스 작성요령

* BMP 엔티티 빈의 빈 클래스 작성 요력은 CMP 엔티티 빈과 비슷하다. CMP 엔티티 빈과의 차이점 :
1) 데이터베이스와의 일체화를 위한 코드를 개발자가 직접
ejbLoad(), ejbStore()에 작성해야 한다는 것이다.
2) 홈 인터페이스의 findXXX()메소드들을 빈 클래스 안에서 개발자가 직접 구현해야 한다는 것이다.
3) 트랜잭션 처리도 직접 코딩해야 한다.

* 비즈니스 메소드 템플릿 : CMP 엔티티 빈의 경우와 동일

* EJB 컨테이너 규약 메소드 템플릿 :
1) CMP 엔티티 빈의 1), 2), 3)과 동일
2) findXXX() 관련 메소드

public <PrimaryKey> ejbfindByPrimaryKey(<PrimaryKey>)
throws [javax.ejb.FinderException,][java.rmi.RemoteException]
{
/* 구현 */
}

public Enumeration ejbfindXXX(<rmiParams>)
throws [javax.ejb.FinderException,][java.rmi.RemoteException]
{
/* 구현 */
}

* 구현 여부 : 반드시 javax.ejb.EntityBean 인터페이스를 구현한다.

* 주의할 내용 :
1) 위의 CMP 엔티티 빈의 "주의할 내용" 중 1),2),3),4),5)는 동일함
2) 홈 인터페이스에 선언된 findXXX() 메소드에 대응되는 ejbfindXXX()의 내부코드를 정의한다.
여러개의 엔티티 객체를 반환할 경우 java.util.Enumeration, Collection이
반환타입으로 사용된다.
3) ejbLoad(), ejbStore()에 해당 데이터베이스 테이블과 일체화하는 코드를 작성하여 구현한다.

* 다른 인터페이스들과의 관계 :
1) 위의 CMP 엔티티 빈의 1), 2)는 동일
2) 빈 클래스에 정의된 findXXX() 메소드들은 홈 인터페이스에서 선언되어 있어야 한다.

* Example>
import java.sql.*;
import javax.sql.*;
import java.util.*;
import javax.ejb.*;
import javax.naming.*;

public class AccountEJB implements EntityBean
{
private String id;
private String firstName;
private String lastName;
private double balance;
private EntityContext context;
private Connection con;
private String dbName = "java:comp/env/jdbc/AccountDB";

// 중간 생략

public void credit(double amount)
{
balance += amount;
}

public String ejbCreate(String id, String firstName, String lastName, double balance)
throws CreateException
{
if( balance < 0.00 )
{
throw new CreateException("A negative initial balance is not allowed.");
}

try
{
insertRow(id, firstName, lastName, balance);
}
catch(Exception ex)
{
throw new EJBException("ejbCreate: " + ex.getMessage());
}

this.id = id;
this.firstName = firstName;
this.lastName = lastName;
this.balance = balance;

return id;
}

public String ejbFindByPrimaryKey(String primaryKey) throws FinderException
{
boolean result;

try
{
result = selectByPrimaryKey(primaryKey);
}
catch(Exception ex)
{
throw new EJBException("ejbFindByPrimaryKey: " + ex.getMessage());
}

if( result )
{
return primaryKey;
}
else
{
throw new ObjectNotFoundException("Row for id " + primaryKey + " not found.");
}
}

// 중간 생략

public void ejbLoad()
{
try
{
// 데이터베이스 테이블에서 값을 읽는다.
loadRow();
}
catch(Exception ex)
{
throw new EJBException("ejbLoad: " + ex.getMessage());
}
}

// 클래스 속성정보를 DB에 쓴다.
public void ejbStore()
{
try
{
storeRow();
}
catch(Exception ex)
{
throw new EJBException("ejbLoad: " + ex.getMessage());
}
}

/*********** DB 연결코드 ***************/
private void makeConnection() throws NamingException, SQLException
{
InitialContext ic = new InitialContext();
DataSource ds = (DataSource)ic.lookup(dbName);
con = ds.getConnection();
}

// 이하 생략

}// class AccountEJB

* javax.ejb.EntityBean은 여러 메소드들이 선언되어 있다.
그렇지만 이 메소드들은 클라이언트가 직접 호출하여 사용하는 것이 아니라
EJB 컨테이너가 자동으로 호출한다.
따라서 이런 메소드들은 EJB 컨테이너와 빈 개발자와의 일종의 약속이기 때문에
"EJB 컨테이너 규약 메소드" 라고 한다.

javax.ejb.EntityBean
{
public void setEntityContext(EntityContext ctx)
: EntityContext 객체를 넘겨받아서 빈 인스턴스의 속성에 할당한다.
컨테이너가 빈 인스턴스를 생성한 직후에 호출한다.

public void unsetEntityContext()
: EntityContext 객체의 레퍼런스를 해제한다.
컨테이너가 인스턴스를 제거하기 전에 호출한다.

public void ejbRemove() : 컨테이너가 EJB 객체를 제거하기 전에 호출한다.
public void ejbActivate() : 빈 인스턴스가 "활성화"될 때 호출된다.
public void ejbPassivate() : 빈 인스턴스가 "비활성화"될 때 호출된다.
public void ejbLoad() : 데이터베이스로부터 값을 읽어서 빈 인스턴스의
상태 정보인 속성 값으로 할당해야 할 경우
컨테이너가 호출한다.
public void ejbStore() : 빈 인스턴스의 상태 정보가 DB안으로 저장되어야 할경우
컨테이너가 호출한다.
}

* 세션 빈처럼 엔티티 빈 클래스를 작성할 때 빈 클래스 개발자는 실제 빈 인스턴스가 생성된 후에
EJB 컨테이너가 현재 어떤 정보를 가지고 동작하는지 알지 못한다.
이런 정보를 빈 클래스 안에서 사용하기 위해서는 EJB 컨테이너가 생성한 EntityContext 객체
를 setEntityContext() 메소드로 받아서 속성으로 할당받은 다음 해당 정보를 얻을 수 있다.
EntityContext 객체가 제공하는 정보는 현재 빈 인스턴스와 연결되어 있는 "EJB객체의
레퍼런스"와 현재 빈 인스턴스의 "프라이머리 키 클래스의 객체"이다.

다. deployment
* 개발된 엔터프라이즈 빈을 클라이언트가 사용하려면 먼저 EJB 컨테이너 안에 플러그인 되어야 한다.
이과정을 "디플로이먼트"라고 하며 컨테이너의 종류에 따라 그 방법이 다르다.

* 빈 개발자가 개발한 엔터프라이즈 빈이 다른 사람 및 다른 EJB 컨테이너에서 Deployment되어 사용될 수
있기 때문이다. 그렇게 하기 위해서는 빈 개발자가 만든 엔터프라이즈 빈을 디플로이먼트 하는 사람이
소스 코드를 수정하지 않고도 여러 옵션을 줄 수 있어야 한다.
(DB네트워크주소, DB의 JDBC드라이버, ...)

라. 테스트용 클라이언트 프로그램 개발
* Example>
Context initialContext = new InitialContext();

// JNDI로 홈 객체의 레퍼런스를 얻음
CartHome cartHome = (CartHome) javax.rmi.PortableRemoteObject.
narrow(initialContext.lookup("java:comp/env/ejb/cart"), CartHome.class);

Cart cart = cartHome.create("John", "7506");

// 비즈니스 메소드 호출
cart.addItem(96);
cart.purchase();

* JNDI로 홈 객체를 찾을 때 EJB 컨테이너 업체(웹로직, 웹스피어등)에서 제공하는 라이브러리를 사용한다.
자세한 것은 EJB 컨테이너 업체에서 제공하는 매뉴얼을 봐야 한다.

5. JNDI
* Example>

import javax.naming.*;
public static Context getInitialContext() throws NamingException
{
Properties p = new Properties();
p.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
p.put(Context.PROVIDER_URL, "t3://localhost:7001");
return new InitialContext(p);
}

InitialContext ic = new InitialContext();
Object objref = ic.lookup("java:comp/env/ejb/Cart");
CartHome home = (CartHome)PortableRemoteObject.narrow(objref, CartHome.class);

* JNDI 주요 환경변수
------------------------------------------------------------------------------
환경 변수 상수 선언
------------------------------------------------------------------------------
java.naming.factory.initial Context.INITIAL_CONTEXT_FACTORY
컨텍스트 팩토리(Context Factory)의 클래스명으로 서비스 제공자에 의해 제공되는 이름

java.naming.factory.object Context.OBJECT_FACTORIES
디렉토리 서비스 안에 저장된 객체를 위해 클래스 팩토리처럼 행동하는 클래스명의 리스트

java.naming.provider.url Context.PROVIDER_URL
서비스 제공자의 구성 정보

java.naming.security.principal Context.SECURITY_PRINCIPAL
서비스 제공자를 사용하기 원하는 Principal의 ID

java.naming.security.credentials Context.SECURITY_CREDENTIALS
Principal의 패스워드
6. JDBC
* 데이터 소스와의 커넥션을 생성
* 질의 구분 및 수정 구분을 전송
* 결과 처리

* Example>
Connection con = DriverManager.getConnection("jdbc:myDriver:wombat", "myLogin", "myPassword");
Statement stmt = con.createStatement();
ResultSet rs = stmt.executeQuery("SELECT a, b, c FROM table1");
while( rs.next() )
{
int x = rs.getInt("a");
String s = rs.getString("b");
float f = rs.getFloat("c");
}

(1) JDBC 드라이버의 종류
가. JDBC-ODBC 브리지(bridge)드라이버
나. 데이터베이스 API(A Native-API partly-java) 드라이버
- JDBC API 호출을 특정 데이터베이스의 클라이언트 호출 API로 바꿔주는 드라이버이다.

다. 네트워크 프로토콜(A net-protocol all-java) 드라이버
- 클라이언트는 JDBC API 호출을 특정 데이터베이스의 프로토콜과 전혀 상관없는
독자적인 방식의 프로토콜로 바꾸어 서버로 전송한다.
- 이 드라이버는 보통 자바언어로 만들어진다.
- 서버에서는 미들웨어가 있어서, 그 프로토콜을 특정 데이터베이스의 API로 바꾸어서 처리한다.

라. 데이터베이스 프로토콜(A Native-protocol all-java) 드라이버
- JDBC API 호출을 서버의 특정 데이터베이스에 맞는 프로토콜로 변환시켜 서버로 전송하는 드라이버
- '나'의 드라이버와 비슷하나, 클라이언트의 API로 변환하는 것이 아니라 직접 서버의
데이터베이스로 요청 한다는 것이 다르다.
- 데이터베이스의 생산업체가 직접제공(특정 DB프로토콜로 직접 변환시켜야 하므로 해당 업체만이 만들 수 있기 때문)


(2) JDBC 2.0 API의 새로운 기능

가. 스크롤 가능한 ResultSet

ResultSet rs = stmt.executeQuery("SELECT * FROM committees");
while( rs.next() )
{}
...
rs.absolute(5); // 커서를 5번째 레코드로 이동한다.
...
rs.relative(-2); // 커서를 3번째 레코드로 이동한다.
...
rs.relative(4); // 커서를 7번째 레코드로 이동
...
rs.previous(); // 커서를 6번째 레코드로 이동
...
int rowNumber = rs.getRow(); // rowNumber는 6이 반환된다.

나. 일괄수정(Batch Updates)

con.setAutoCommit(false);
Statement stmt = con.createStatement();
stmt.addBatch("INSERT INTO employees VALUES(1000, '홍길동')");
stmt.addBatch("INSERT INTO employees VALUES(260, '구매부')");
stmt.addBatch("INSERT INTO employees VALUES(1000, '260')");
int [] updateCounts = stmt.executeBatch();

다. API를 통한 수정(Programmatic Updates)
* updateXXX(), getXXX(), setXXX()

* rs.absolute(4); //커서를 네번째 레코드로 옮김
rs.updateString("ADDRESS", "서울 서초구"); // ADDRESS필드를 "서울 서초구"로 변경
rs.updateFloat("AMOUNT", 10101.0f); // AMOUNT 필드를 10101.0f로 변경
rs.updateRow(); // 수정구문을 DB로 보냄

* rs.moveToInsertRow(); // 새로운 레코드를 삽입하기 위해 커서를 insert row라는 특수위치로 옮김
rs.updateObject(1, myArray); // 1번째 필드를 myArray를 값으로 가진다.
rs.updateInt(2, 3857); // 2번째 필드는 3857를 값으로 가진다.
rs.updateString(3, "Mysteries"); // 3번째 필드는 "Mysterious"를 값으로 가진다.
rs.insertRow(); // 데이터베이스로 전송
rs.first(); // 커서를 ResultSet으로 옮긴다.

* rs.first(); // 레코드를 삭제하기 위해서 삭제하고자 한느 레코드로 커서를 옮김
rs.deleteRow(); // 1번째 레코드를 삭제

라. 새로운 데이터 타입에 대한 지원

* JDBC 2.0 API는 새로운 SQL3 데이터 타입을 JDBC 인터페이스에 매핑하여 기본 데이터 타입처럼
쉽게 사용할 수 있는 기능을 제공한다.

* ResultSet rs = stmt.executeQuery("SELECT members FROM committees "
+ "WHERE comm_name = 'finance'");
rs.next();
Array financeMembers = rs.getArray("members");

financeMembers 변수는 회원들의 이름 데이터 자체를 포함하고 있는 것이 아니며,
단지 서버에 존재하는 이름 데이터에 대한 논리적 포인터를 값으로 가지고 있을 뿐이다.
이는 모든 이름들을 배열에 담아 클라이언트로 가져옴으로써 발생될 수 있는 오버해드 없이
financeMembers 변수를 마치 SQL ARRAY 자체를 사용하는 것처럼 조작할 수 있음을 띃나다.
데이터베이스에 이름의 배열을 저장하기 위해서는 PreparedStatement의 setArray 메소드를
통해서 financeMembers 변수를 넘겨주기만 하면 된다.

* BLOB, CLOB도 같은 방식으로 동작한다.

(3) JDBC 2.0 Standard Extension API
가. JNDI를 이용한 DataSource 인터페이스

* DataSource 인터페이스는 DriverManager 클래스를 대신해서 데이터 소스와의 커넥션을 생성하는데 사용될 수 있다.
* DataSource 인터페이스를 구현한 클래스를 사용한 코드는 더 포터블해지며, 유지보수는 더 쉬워진다.
* DataSource 에 대한 정보는 DataSource 객체에 프로퍼티 형식으로 저장된다.
* 특정 드라이버 업체명과 서버의 주소 등을 코드로 작성해야 하는 DriverManager클래스를 이용하는 클래스보다
DataSource 객체를 이용한 코드가 더 포터블하다.
* DataSource 가 다른 서버로 옮겨졌을 경우 관련된 프로퍼티만 수정하면 되므로 유지보수가 편리

* Example>
Context ctx = new InitialContext();
DataSource ds = (DataSource) ctx.lookup("jdbc/InventoryDB");
Connection con = ds.getConnection("myPassword", "myUserName");

나. Connection pooling
* DataSource.getConnection() 메소드에 의해 반환된 커넥션이 커넥션 풀링을 사용하는지의 여부는
전적으로 해당 DataSource의 구현에 달려있다. 해당 DataSource 클래스가 커넥션 풀링을 지원하는
middle tier서버와 함께 사용되도록 구현되었다면 DataSource 객체는 풀링을 지원하며
재사용되는 Connection 객체를 반환할 것이다.
* 풀링된 커넥션을 가져오는 코드가 동일한 것처럼, 풀링된 커넥션을 사용하는 코드도 다를 것이 없다.
단 한가지 차이점이라면 커넥션을 finally 블록에서 반드시 닫아야 한다.
이렇게 해야만 예외가 발생해도 커넥션은 닫혀지고 커넥션 풀로 돌아갈 수 있다.

}
finally
{
if( con != null )
try
{
con.close();
}
catch(SQLException)
{}
}

다. 분산 트랜잭션

라. RowSet

7. RMI
* 소켓 프로그래밍 :
- 데이터를 주고 받기 위해서는 저차원적인 일들(네트워크 연결, 소켓 생성등)까지 코딩 해야함

* RPC(Remote Procedure Call) :
- 네트워크로 연결된 다른 컴퓨터에 있는 함수를 마치 자신의 컴퓨터내에 있는 함수처럼 호출하고 그 결과값을 반환받음.

* RMI(Remote Method Invocation) :
- RPC는 함수를 호출하는 것이기 때문에 객체 지향 언어에서는 구현하기가 부적합.
(왜나하면 객체 지향 언어에서는 함수란 개념이 없고 객체의 메소드란 개념이 그것을 대체하기 때문)
- RPC의 장점을 십분 살려 분산 객체 APP을 쉽게 만들 수 있는 개념
- 분산객체APP : 네트워크로 연결된 컴퓨터들 안에 있는 객체들이 서로의 메소드를 호출하며 한 목표를 향해 동작하는
시스템을 의미

(1) RMI 및 자바 분산 객체 모델
* RMI의 구조는 3계층으로 나누어 구성된다.
stub / skeleton
---------------
Remote Reference Layer
----------------------
Transport

가. stub / skeleton
* stub : 리모트 객체를 나타내는 클라이언트 부분
* skeleton : 리모트 객체를 나타내는 서버쪽 부분

나. Remote Reference Layer
* 리모트 레퍼런스의 메타 정보를 전달
(Client의 stub과 Server의 skeleton과 독립적인 RMI메소드 호출에 관한 메타 정보를 전달하는 역할)

다. Transport
* 리모트 객체외의 네트워크 연결 및 관리와 추적 기능을 담당

(2) RMI의 구조
가. 파라미터와 반환값 처리
* 리모트 객체의 메소드의 반환값, 파라미터로 어떤 타입도 사용될 수 있다.
단, 객체가 사용될 경우, 반드시 java.io.Serializable 인터페이스를 구현한 것이어야 한다.

나. 예외 처리
* 리모트 객체의 메소드를 호출할 때 에러가 발생하면, 그 정보는 java.rmi.RemoteException클래스에 저장된다.

다. RMI를 구현하기 위한 클래스와 인터페이스
* 개발자는 java.rmi, java.rmi.server 패키지의 클래스와 인터페이스를 주로 사용한다.

① java.rmi.Remote interface
* 모든 리모트 인터페이스는 직접, 간접으로 반드시 java.rmi.Remote interface를 상속해야 한다.
* Remote interface는 어떤 메소드도 선언된 것이 없다.

public interface Remote{}

* Example>
public interface BankAccount extends Remote
{
public void deposit(float amount) throws java.rmi.RemoteException;
public void withdraw(float amount) throws OverdrawnException, java.rmi.RemoteException;
public float balance() throws java.rmi.RemoteException;
}

* 리모트 인터페이스의 모든 메소드는 반드시 throws문을 통해
java.rmi.RemoteException을 예외처리 해야함.
* 메소드의 반환값, 파라미터로 리모트 객체가 쓰일때, 그 타입은 리모트 인터페이스를 구현한
클래스 타입이 아니라 리모트 인터페이스 타입이어야 한다.

② java.rmi.RemoteException class
* RMI 실행중에 발생하는 모든 예외를 나타내는 클래스들의 최상위 클래스.
* RMI 기능을 사용하는 모든 메소드는 반드시 이 예외를 throws문으로 예외 처리할 수 있음을 선언해야함.

③ java.rmi.server.RemoteObject class
* 리모트 객체의 기능은 이 클래스와 또는 하위 클래스인 java.rmi.server.RemoteServer,
java.rmi.server.UnicastRemoteObject에 의해서 제공받는다.

* java.rmi.server.RemoteObject :
- 리모트 객체가 갖추어야 할 기본적인 메소드(hashcode().toString()등)를 정의한다.

* java.rmi.server.RemoteServer :
- 리모트 객체를 생성하고 등록할 수 있는 기능을 메소드로 정의한다.
- 추상클래스이므로 상속받은 하위 클래스들이 메소드를 구현한다.

* java.rmi.server.UnicastRemoteObject :
- 서버 프로세스가 동작할 때만 실행할 수 있는 싱글 리모트 객체
- 개발자 대부분은 이 클래스를 사용

④ 리모트 인터페이스를 구현하기 위한 규칙
㉠ java.rmi.server.UnicastRemoteObject를 상속받는다
RemoteServer, UnicastRemoteObject 클래스의 모든 속성과 메소드를 사용할 수 있다.

㉡ 1개 이상의 리모트 인터페이스를 구현 할 수 있다
㉢ 리모트 인터페이스를 구현한 다른 클래스를 상속받을 수 있다는 점
㉢ 리모트 인터페이스에 선언되어 있지 않은 메소드를 정의할 수 있는 점,
하지만 클라이언트는 호출할 수 없고, 로컬에서만 호출가능

* Example>
import java.rmi.*;
import java.rmi.server.*;
public class BankAccountImpl extends UnicastRemoteObject implements BankAccount
{
public void deposit (float amount) throws RemoteException(...}
public void withdraw (float amount) throws OverdrawnException, RemoteException{...}
public float balance() throws RemoteException{...}
}
(3) EJB에서의 RMI
* 엔터프라이즈 자바빈즈는 RMI/IDL CORBA 기술을 분산 객체 모델의 구현을 위해 기반 기술로 채택하고 있다.
* RMI-IIOP는 J2EE플랫폼의 구성요소로써 CORBA IDL(Inferface Definition Language)을 배우지 않고
자바 플랫폼에서 동작하는 CORBA 응용프로그램을 작성할 수 있는 기능을 제공하며
CORBA ORB의 모든 기능을 포함하고 있다.
* RMI는 EJB 아키텍처에서 통신의 근간을 이루고 있다.

8. EJB 아키텍처의 역할 분담
(1) 엔터프라이즈 빈 제공자(Enterprise Bean Provider)
(2) 애플리케이션 조립자(Application Assembler)
(3) 배치자(Deployer)
(4) EJB 서버 제공자(EJB Server Provider)
(5) EJB 컨테이너 제공자(EJB Container Provider)
(6) 시스템 관리자(System Administrator)
9. 세션 빈(Session Bean)
(1) 무상태 빈(stateless bean)의 내부동작 과정

------------------------------------------------------------
존재하지 않는 상태

1. newInstance()
2. setSessionContext(sc) ↓ ↑ ejbRemove()
3. ejbCreate()
메소드 준비 풀
------------------------------------------------------------

* 무상태 세션 빈은 상태관리가 필요없기 때문에 활성화/비활성화 상태를 갖지 않는다.
* 무상태 세션 빈의 생명주기
① EJB 컨테이너가 세션 빈 클래스의 객체인 빈 인스턴스를 생성
② 빈 인스턴스가 생성되면 컨테이너는 setSessionContext() 메소드를 호출한 후 ejbCreate()메소드를 호출한다.
이는 클라이언트의 create() 메소드 호출과는 상관없다.
③ 컨테이너가 더 이상 빈 인스턴스를 필요로 하지 않으면 EJB 컨테이너가 스스로 ejbRemove()메소드를 호출한다.
가. 풀에 빈 인스턴스를 할당하는 과정
* 클라이언트가 EJB 객체의 비즈니스 메소드를 호출할 때 빈 인스턴스가 생성되어 있지 않으면
EJB 컨테이너에 의해 새로운 빈 인스턴스가 생성되고 setSessionContext(), ejbCreate()가 호출된다.
* 이미 풀에 해당 인스턴스가 존재하면 두 메소드는 호출되지 않고, 이미 생성되어 풀에 있는 빈 인스턴스를 사용한다.

나. 클라이언트가 create() 메소드를 호출했을 때
* 클라이언트가 create() 메소드를 호출해도 실제 빈 인스턴스가 생성되거나 ejbCreate()가 호출되는 것이 아니라
EJB 객체를 생성하는 것이다.
* EJB 객체는 EJB 컨테이너에 의해 적당한 빈 인스턴스와 연결된다.
이때 EJB 컨테이너는 빈 인스턴스를 풀에서 꺼내거나 또는 새롭게 생성한다.

다. 클라이언트가 비즈니스 메소드들을 호출했을 때
* 클라이언트가 비즈니스 메소드를 호출하면 EJB 객체를 통하여 해당 빈 인스턴스의 비즈니스 메소드가 호출된다.

* 클라이언트에 의해 실행되는 모든 비즈니스 메소드는 다음의 순서로 동작한다.(웹로직인 경우)
① EJB 컨테이너가 빈 인스턴스를 풀에서 꺼낸다.
② 메소드는 빈 인스턴스에 의해 실행된다.
③ EJB 컨테이너가 빈 인스턴스를 풀로 반환한다.

라. 클라이언트가 remove() 메소드를 호출했을 때
* 클라이언트가 EJB 객체의 remove() 메소드를 호출해도 실제 풀에서 인스턴스가 삭제되지는 않는다.
* 일단 EJB 컨테이너에게 삭제한다는 메시지를 보내고 추후 적당한 시기에 삭제되는 것이다.
* 무상태 세션 빈은 하나의 빈 인스턴스가 여러 클라이언트에 의해 사용될 수 있으므로,
실제 풀에서 제거되지 않고 일단 풀에서 대기 하게 된다.
* 더이상 사용되지 않는 빈 인스턴스는 EJB 컨테이너가 자동으로 제거한다.
* remove()를 호출하면 클라이언트는 세션 빈을 더 이상 사용할 수 없다.

마. 풀에서 빈 인스턴스를 제거하는 과정
* EJB 컨테이너가 더 이상 빈 인스턴스가 필요하지 않거나, 유휴 대기시간을 초과하면
EJB 컨테이너가 스스로 ejbRemove()를 호출하여 풀에서 인스턴스를 제거한다.
(2) 상태유지 빈(stateful bean)

가. 풀에 빈 인스턴스를 할당하는 과정
* 무상태 세션 빈의 내용과 동일하나, 메소드 준비 풀이 상태유지 세션 빈에서는 메소드 준비 상태(활성화 상태)가 된다.
* 무상태 세션 빈과 달리, 상태유지 세션 빈은 클라이언트가 홈 객체의 create()를 호출하는 순간 빈 인스턴스가 생성된다.
왜냐하면 각 클라이언트마다 상태정보를 유지 하기 위해 해당 클라이언트를 전담하는 독립적인 빈 인스턴스가
각각 존재해야 하기 때문

나. 클라이언트가 create() 메소드를 호출했을 때
* 클라이언트가 상태유지 세션 빈의 create() 메소드를 호출하면 상태유지 세션 빈의 생명주기가 시작된다.

다. 클라이언트가 비즈니스 메소드들을 호출했을 때
* 상태 세션 빈의 인스턴스는 클라이언트에 종속되기 때문에 풀에서 빈 인스턴스를 가져오거나 반환할 필요가 없다.

라. 활성화/비활성화될 때
* 컨테이너에 의해 어떤 빈 인스턴스가 비활성화될 것인지 결정된다.
* 비활성화될 빈 인스턴스는 LRU(Least Recently Used)에 의해서 선택되어
컨테이너는 비활성화될 빈 인스턴스의 ejbPassivate() 메소드를 호출하고,
작업이 완료되면 컨테이너는 빈 인스턴스의 상태를 객체직렬화(serialization)를
통해 보조 기억 장치에 저장한다.
* 빈이 비활성화된 상태에서 클라이언트가 EJB 객체의 비즈니스 메소드를 호출하면
컨테이너는 빈 인스턴스를 활성화시킨다.
이때, 컨테이너는 보조 기억 장치에서 빈 인스턴스의 상태를 읽어오고
ejbActivate() 메소드를 호출하여 활성화 상태로 만든다.

마. 클라이언트가 remove() 메소드 호출 및 빈 인스턴스 제거할 때
* 클라이언트가 remove() 메소드를 호출하면 ejbRemove() 메소드가 호출되어 빈 인스턴스를 제거한다.
* 무상태 세션 빈은 클라이언트가 remove() 호출할 때 풀에 남아 다른 클라이언트의 호출에 대기하지만
상태유지 세션 빈은 각각의 클라이언트의 상태를 가지고 있기 때문에
상태유지 세션 빈의 생명주기는 여기서 종료된다.
10. 엔티티 빈(Entity Bean)
* 엔티티 빈은 데이터베이스와 같은 영속적인 저장 메커니즘에 저장되어 있는 비즈니스 객체를 나타낸다.
* 세션 빈이 EJB를 통해 구현하고자 하는 비즈니스 로직을 담고 있다면,
엔티티 빈은 이 비즈니스 로직의 구현에 필요한 각종 데이터들과 대응되는 데이터베이스에서
영속적으로 유지되어야 하는 정보(persistent information)들과의 연동을 담당하고 있다.

(1) CMP(Container Managed Persistence)
* EJB 컨테이너가 자동으로 영속성 관리
* DB내의 엔티티 빈 인스턴스와 관련된 데이터를 자동으로 추가/삭제/변경한다.

가. 장점
* 개발이 용이하고 코드의 크기가 줄어든다.
영속성에 대한 관리 자체를 EJB 컨테이너가 해결해 주기 때문에,
개발자는 비즈니스 로직에만 집중하여 개발할 수 있기 때문이다.
따라서, 개발자는 개발한 빈을 디플로이먼트할 때 엔티티 빈의 어떤 필드가 EJB 컨테이너에 의해 관리되고
데이터베이스에 대응되는지 지정해 주기만 하면 된다.
이와 같은 작업만 마치면, 컨테이너는 빈의 모든 영속성 작업에 필요한 코드를 자동으로 생성한다.

* 빈이 자신의 상태를 저장하는데 사용하는 데이터베이스와 독립된다는 것이다.
즉, CMP 기반 엔티티 빈은 관계형 또는 객체 지향 데이터베이스의 장점을 모두 이용할 수 있다.
또한, 이와 같은 특징 때문에 빈에 대한 응용프로그램간의 재사용성과 유연성이 높아질 수 있게 된다.

나. 단점
* 빈의 필드를 데이터베이스에 대응시킬 때 BMP에 비해 정교함이 떨어진다.
즉, 정교하게 CMP 엔티티 빈과 DB를 대응시키시 위해서는 훨씬 강력한 툴을 요구한다.
예를 들어, 특정 빈의 상태는 복잡한 관계형 DB의 join연산으로 정의될 수 있다.
또한, CICS나 IMS와 같은 기존의 시스템에 대응될 수도 있다.
실제 CMP 기반으로 엔티티 빈을 설계할 때는 여러 가지 제약사항이 뒤따른다.

다. 리모트 인터페이스
① 반드시 javax.ejb.EJBObject 인터페이스를 상속받아야 하며
② 엔티티 빈에 있는 모든 비즈니스 메소드는 반드시 리모트 인터페이스 내에 그 정의가 포함되어야 하고
빈 클래스의 비즈니스 메소드에 있는 대응되는 메소드와 메소드 형태(반환값 및 전달 파라미터)가 동일해야 한다.
③ 모든 비즈니스 메소드는 반드시 java.rmi.RemoteException을 throws절에 포함해야 하며 사용자가 정의하는
비즈니스 예외 클래스를 추가적으로 포함할 수 있다.
④ 리모트 인터페이스 내에 포함되는 모든 비즈니스 메소드의 전달 파라미터들과 반환 값은 반드시 유효한 RMI호환형
이어야 한다.

라. 홈 인터페이스
① 엔티티 빈의 생명주기에 관련된 메소드들을 제공한다.
EJB 시스템에서 EJB 객체를 생성하고, 찾고, 삭제하는데 사용된다.
② 홈 인터페이스는 한개 이상의 create 메소드(아예 정의되지 않을 수도 있음)와 하나 이상의 find 메소드를 정의한다.
③ EJB 홈 인터페이스는 반드시 javax.ejb.CreateException을 포함해야 하는데
CMP의 경우 컨테이너는 생성 과정에서 유발되는 통신 문제에 대해 일반적인 예외 처리가 필요한다.

public interface <홈 인터페이스 이름> extends javax.ejb.EJBHome
{
/**
* 0 또는 한개 이상의 create 메소드가 정의될 수 있다.
*/
public <리모트 인터페이스> create(<다양한 초기화 인자들...>)
throws [<사용자 정의 예외>,]...
java.rmi.RemoteException,
javax.ejb.CreateException;

/**
* 반드시 정의되어야 하는 findByPrimaryKey 메소드
*/
public <리모드 인터페이스> findByPrimaryKey(<프라이머리키 형 또는 프라이머리키 클래스의 인스턴스>)
throws [<사용자 정의 예외>,]...
java.rmi.RemoteException,
javax.ejb.FinderException;

/**
* 비즈니스 로직에 필요에 의해 부가적으로 정의될 수 있는 find 메소드들
*/
public <리모트 인터페이스형 or 집합형> findByRange(...)
throws ...;

...
}

④ 홈 인터페이스의 create 메소드는 다음과 같은 조건을 만족해야 한다.

* 엔티티 빈의 홈 인터페이스는 0 또는 한 개 이상의 create 메소드
(각각은 저마다의 방법으로 엔티티 객체를 생성한다.)를 정의할 수 있다.
일반적으로 create메소드들의 전달 파라미터는 생성된 엔티티 객체들의
상태(state)를 초기화하는데 사용된다.

* create 메소드의 반환 값은 엔티티 빈의 리모트 인터페이스이며 대응되는 빈 클래스에 위치한
ejbCreate메소드와 동일한 수, 형태의 전달 파라미터를 가져야 한다.

* 모든 create 메소드의 throws절은 java.rmi.RemoteException과 javax.ejb.CreateException을
포함하고 있다. 또한, 응용프로그램 차원에서 제공되는 예외들을 추가로 포함할 수 있다.

⑤ 홈 인터페이스의 find 메소드의 형태들은 반드시 다음과 같은 조건을 만족하도록 작성되어야 한다.

* 홈 인터페이스에 있는 모든 find 메소드는 빈 클래스에 있는 find 메소드와 대응된다.
홈 인터페이스에 정의된 find 메소드의 이름은 find로 시작되는 반면에
빈 클래스에 있는 것들이 이름은 ejbFind로 시작한다.
예를 들어, 홈 인터페이스에서 findInRange()라는 메소드를 선언했다면,
빈 클래스는 ejbFindInRange()라는 이름으로 메소드를 구현한다.

* 전달 파라미터의 개수와 형태는 빈 클래스에 있는 대응되는 메소드의 것들과 동일해야 한다.

* 반환 값은 엔티티 빈의 리모트 인터페이스형이거나 그런 형태들의 Enumeration type(나열형)이다.

* throws절의 예외들은 빈 클래스의 대응되는 메소드에 나타나 있는 것을 포함해야 한다.

* throws절은 javax.ejb.FinderException과 java.rmi.RemoteException을 담고 있다.

마. 컨테이너 관리 필드(Container managed field)

* 엔티티 빈이 CMP 기반이거나 BMP 기반이거나에 관계없이 리모트 인터페이스와 홈 인터페이스는 동일하다.
하지만 빈 클래스에 있는 코드는 당연히 CMP와 BMP가 서로 다르다.
CMP의 빈 클래스는 어떤 DB 접근/제어 코드도 가지고 있지 않다.
deploy tool이 deploy할 때 필요한 SQL 구문들을 자동으로 생성해 준다.
deploy tool이 DB에 저장되어야 하는 빈 인스턴스의 속성들을 알아야 한다.
이런 속성들을 컨테이너 관리 필드라고 한다.

* 컨테이너 관리 필드는 반드시 public으로 선언되어야 하며 임시적인 것이어서는 안된다.

* 직렬화(serializable) 클래스, 기본형 자료형(primitive type),
홈 인터페이스에 대한 레퍼런스 또는 리모트 인터페이스에 대한 레퍼런스 중 하나의 형태여야 한다.

* deploy tool을 사용할 때, 하나 이상의 컨테이너 관리 필드를
엔티티 빈의 프라이머리 키 필드로 반드시 선언해야 한다.

바. 빈 클래스 구현

* EntityBean 인터페이스를 구현한다.
* 클래스는 abstract나 final로 선언될 수 없고 반드시 public으로 선언되어야 한다.
* 한 개 이상의 ejbCreate와 ejbPostCreate 메소드를 구현한다.
* BMP 엔티티 빈일 경우에는 find 메소드를 구현해야 한다.
* 애플리케이션이 요구하는 비즈니스 메소드를 구현한다.
* 파라미터가 없는 생성자(empty constructor)를 가지고 있다.
* finalize 메소드를 구현하지 않는다.

사. EntityBean 인터페이스

아. ejbCreate()
* 클라이언트가 create()를 호출할 때, EJB 컨테이너가 호출하는 대응 되는 메소드

① 하는 일
* DB에 엔티티 상태를 삽입
* 빈 인스턴스 속성을 초기화 한다.
* primary key를 반환한다.

* ejbCreate()는 입력 전달 파라미터로 들어오는 컨테이너 관리 필드들을 초기화한다.
이 메소드는 반환 값으로 널(null)값을 가지는데 그 이유는 CMP기반의 경우
컨테이너가 반환 값을 무시하기 때문

public String/* <= */ ejbCreate(String productId, String description, double price)
{
if( productId = null )
{
throw new CreateExceptin("The productId is required");
}

this.productId = productId;
this.description = description;
this.price = price;

return null;// <= 리턴타입과 실제 리턴값이 다르다
}

② 작성 규칙
* 메소드의 접근 제어 지정자(access control modifier)는 반드시 public이어야 한다.
* 반환형은 반드시 프라이머리 키여야 한다.(BMP일 경우에만)
* 파라미터는 반드시 Java RMI에 적합한 형태여야 한다.
* 메소드 지정자(method modifier)는 final이나 static이 될 수 없다.

자. ejbPostCreate()
① 각각의 ejbCreate()에 대해, 빈 클래스에 ejbPostCreate()를 작성해야 하는데,
일반적으로 ejbPostCreate()는 내부가 비어있는 empty 메소드로 남아있다.

② EJB 컨테이너는 ejbCreate()를 호출한 바로 직후에 ejbPostCreate()를 호출한다.
ejbCreate()와는 다르게, ejbPostCreate()는 EntityContext 인터페이스의
getPrimaryKey()와 getEJBObject()를 호출할 수 있다.

③ 메소드 작성 규칙
* 전달 파라미터의 개수와 형태는 대응되는 ejbCreate()와 동일해야 한다.
* 메소드의 접근 제어 지정자(access control modifier)는 반드시 public이어야 한다.
* 메소드 지정자는 final이나 static이 되어서는 안된다.
* 메소드의 반환형은 반드시 void형이어야 한다.

차. ejbRemove()
* Client가 remove()를 호출하면, 컨테이너는 ejbRemove()를 호출한다.
* ejbRemove()의 실행이 완료되면, 컨테이너는 DB에서 해당 레코드(row)를 삭제한다.
즉, Client는 remove()를 호출하여 엔티티 빈을 삭제하게 되는 것이다.
만일 엔티티 빈이 삭제하기 전에 즉각적인 어떤 처리가 필요하다면 ejbRemove()에서 하면 된다.
* 만일 ejbRemove()가 시스템 문제에 부딪히면, javax.ejb.EJBException을 발생시킨다.
반면 애플리케이션 에러에 부딪히게 되면 javax.ejb.RemoveException을 발생시킨다.
또한 엔티티 빈은 직접적인 DB 삭제에 의해 직접적으로 삭제될 수 있다.
(SQL 스크립트가 직접적인 엔티티 빈의 상태를 저장하고 있는 레코드를 삭제하면,
그 엔티티 빈은 삭제되는 것이다.)

카. ejbLoad() / ejbStore()
* EJB 컨테이너가 엔티티 빈의 인스턴스 속성과 DB에 저장되어 있는 대응 값을 동기화 할 필요가 있다며,
EJB 컨테이너는 ejbLoad()와 ejbStore()를 호출하게 되며,
클라이언트에서 ejbLoad()나 ejbStore()를 직접적으로 호출하는 것은 불가능한다.

① ejbLoad() 호출순서
* DB에서 재설정하고자 하는 엔티티 빈에 해당하는 레코드를 가져온다.
* 가져온 레코드의 각 칼럼 값을 대응하는 각 컨테이너 관리 필드에 할당
* ejbLoad() 호출

② ejbStore() 호출순서
* ejbStore() 호출
* 컨테이너 관리 필드들의 값들을 읽어온다.
* 해당 엔티티 빈에 대응되는 DB 레코드의 각 칼럼값들을 읽어온 컨테이너 관리 필드 값들로 대체한다.

타. find()들
* CMP 기반의 엔티티 빈에서는 컨테이너가 홈 인터페이스에 정의된 find 메소드들을 자동으로 구현해주기
때문에 이 find()들을 개발자가 직접 구현할 필요가 없다.

파. Primary Key
* 프라이머리 키는 빈의 형태, 홈 인터페이스, 그리고 프라이머리 키가 사용되는
컨테이너 컨텍스트(container context)에 따라 엔티티 빈을 유일하게 구분하는 구분자이다.
* Primary Key가 기본형 타입(primitive type)일지라도 프라이머리 키 클래스를 구현해 놓으면
차후 애플리케이션의 확장이나 DB 및 테이블의 변동에서 오는 영향을 최소화시키고,
빈의 find 메소드들을 좀 더 유연하고 융통성 있게 만든다.
* Primary key 클래스 반환 값의 형태는 반드시 RMI-IIOP에 적합한 값의 형태이어야 한다.
* Primary Key 클래스는 클라이언트 프로그램의 프라이머리 키를 간단히 관리하기 위해
hashCode(), equals(Object other)를 제공해야 한다.

* Example>

import java.io.Serializable;
public class ProductPK implements java.io.Serializable
{
public String productId;

public ProductPK(){}

public ProductPK(String _Id)
{
productId = _Id;
}

public boolean equals(Object obj)
{
if( obj == null || !(obj instanceof ProductPK) )
{
return false;
}
else if( ((ProductPK)obj).productId.compareTo(productId) == 0 )
{
return true;
}
else
{
return false;
}
}

public String hashCode()
{
return productId;
}
}

하. 객체의 동일성 체크
① 클라이언트는 isIdentical()을 통해서 두개의 엔티티 빈에 대한 EJB 객체 레퍼런스(Object reference)가
동일한지 비교할 수 있다.

Account accta, acctb;
...
if( accta.isIdentical(acctb) )
{
System.out.println("identical");
}

② 또한, 두 엔티티 빈의 프라이머리 키를 비교하여 구분할 수도 있다.

String key1 = (String)accta.getPrimaryKey();
String key2 = (String)acctb.getPrimaryKey();
if( key1.compareTo(key2) == 0 )
{
System.out.println("equal");
}

③ 어떤 엔티티 빈을 다른 엔티티 빈에서 사용하고자 할 때
* 사용하고자 하는 엔티티 빈에 대한 레퍼런스를 사용할려는 빈에 전달하는 방법
즉, 엔티티 빈에 대한 객체 레퍼런스(Object reference)를 전달하는 방법.

public void setEntityContext(EntityContext ec)
{
this.context = ec;
}

...

public void passItOn(Inventory tally)
{
// EntityContext에 있는 getEJBObject()를 호출하여 EJB객체의 레퍼런스를 얻어오는 과정
tally.copyItems(context.getEJBObject());
}

가.가. 엔티티 빈의 생명주기

존재하지 않는 상태
newInstance() | |
setEntityContext()↓ ↑ unsetEntityContext()
| |
┌--------------- 풀링된 상태 <-------------┐
1. create() | | 1. remove()
2.ejbCreate() | ejbActivate() ↓ ↑ ejbPassivate() | 2. ejbRemove()
3.ejbPostCreate()| ejbLoad() ejbStore() |
| |
└--------------> 준비 상태 --------------┘

* 엔티티 빈의 생명주기는 응용프로그램에 의해 결정되는 것이 아니라 EJB 컨테이너에 의해 결정된다.
* EJB 컨테이너는 엔티티 빈 인스턴스를 생성하고 나서 빈 클래스에 있는 setEntityContext()를 호출한다.
* setEntityContext()는 entity Context를 빈에 전달한다.

[인스턴스化된 이후]
* 엔티티 빈은 가용 인스턴스 풀(a pool of available instances)에 들어가게 된다.
인스턴스 풀 상태에는 어떤 EJB 객체와도 연관되어 있지 않다.
풀에 있는 모든 인스턴스들은 다 동일하다.

[EJB 컨테이너가 인스턴스를 준비 상태로 이동]
* 비로소 인스턴스는 EJB 객체와 연동하게 되는 것이다.

[인스턴스가 준비 상태에서 풀링된 상태로 변하는 경우]
① 클라이언트가 remove()를 호출하는 경우로 이때 EJB 컨테이너는 ejbRemove()를 호출
② EJB 컨테이너가 ejbPassivate()를 호출하는 경우

[unsetEntityContext()]
* 풀링된 상태에서 인스턴스는 어떤 EJB 객체와도 연동하지 않음.

* 참고사항 1
BMP(Bean-Managed Persistence) 기반 엔티티 빈에서는
EJB 컨테이너가 인스턴스를 풀링된 상태에서 준비 상태로 이동시킬 때,
인스턴스는 프라이머리 키를 자동으로 설정하지 않는다.
따라서, ejbCreate()와 ejbActivate()는 반드시 프라이머리 키를 설정해주어야 한다.
만일 프라이머리 키가 틀릴 경우 ejbLoad(), ejbStore()는 인스턴스 변수들을 DB와 동기화시킬수 없다.

* 참고사항 2
풀링된 상태에서 인스턴스 변수들의 값들은 불필요하다.
따라서 이런 인스턴스 변수들을 ejbPassivate 메소드에서 널로 설정함으로써
가비지 컬렉션(garbage collection)당할수 있도록 만들수 있다.

(2) BMP(Bean Managed Persistence)
* CMP 엔티티 빈에서 컨테이너가 해주던 작업들을 개발자가 직접 명시적으로 해주어야 한다.
따라서 개발자는 DB에 접근하는 코드를 반드시 사용해야 하며 EJB 컨테이너는 언제 DB의
데이터를 추가/삭제/변경하는 것이 안전한지를 알려준다.

가. 장점
* 빈 인스턴스와 DB 사이의 상태를 관리할 때 보다 유연하다.
즉, 복잡한 join 연산이나 서로 다른 DB들의 연동 또는 기존 시스템과의 연동에서는
BMP 엔티티 빈이 훨씬 유용하게 적용될 수 있다.

나. 단점
* 빈을 설계하기가 CMP에 비해 훨씬 까다롭다.
즉, BMP 엔티티 빈을 설계하는 사람은 DB의 구조에 대한 이해와 지식이 필요하고
엔티티에 관련된 데이터를 생성하고 변경 및 제거하는 로직을 개발해야 한다.
또한, 개발자는 빈의 홈 인터페이스에 정의된 find 메소드들을 모두 구현해야 한다.
또 빈을 특정한 DB 타입이나 구조에 종속시킨다는 점이다.
이는 DB 또는 데이터 구조 내의 모든 변화가 빈 클래스의 구현에 영향을 미치는 것을 의미한다.
따라서 빈의 유연성이 나빠진다.

* CMP 기반의 빈 클래스에서는 리모트 인터페이스에서 선언된 모든 메소드들과 홈 인터페이스에서 선언되
일부 메소드들(생명주기에 관련된 메소드들)만을 구현했지만,
BMP 기반에서는 리모트 인터페이스와 홈 인터페이스에 선언된
find 메소드들을 포함한 모든 메소드들을 구현해야 한다.

* 홈 인터페이스에 정의된 모든 메소드들을 구현하기 위해서는 개발자가 직접 빈 클래스 내에
DB를 제어하기 위한 작업, 즉 각종 메소드들과 커넥션 및 SQL 구문을 실행하기 위한 작업을 해야 한다.

* ejbCreate()의 반환 값이 CMP에서는 널(null)값이었으나
BMP 엔티티 빈에서는 반드시 프라이머리 키 값이어야 한다.

다. BMP 엔티티 빈의 내부 동작 과정

[클라이언트가 create() 메소드를 호출했을 때]
* ejbCreate() 메소드가 새로운 엔티티를 DB에 생성한 후 null을 반환하지 않고
엔터프라이즈 빈의 프라이머리 키를 반환한다.

* 새롭게 생성된 엔티티를 DB에 생성할 때도 컨테이너가 아닌 빈 인스턴스에 의해 이루어짐.

11. 트랜잭션
(1) 트랜잭션 타입
가. 개발자가 직접 트랜잭션 관리 코드 작성(프로그래밍 트랜잭션 방식)
① 클라이언트에 의한 트랜잭션 관리
* javax.transaction.UserTransaction을 사용.
java.sqlConnection의 commit(), rollback()을 사용하면 안됨

② 엔터프라이즈 빈에 의한 트랜잭션 관리

* 엔티티 빈은 "컨테이너에 의한 트랜잭션 관리"가 기본적으로 수행된다.
세션 빈은 "엔터프라이즈 빈에 의한 트랜잭션 관리" 와 "컨테이너에 의한 트랜잭션 관리"
중 하나가 가능하며, 동시에 둘 다는 불가능하다.

* 트랜잭션 관리 코드는 JDBC와 JTA를 사용하는 2가지 경우로 나눠진다.
두개가 같은 효과를 내지만 JTA를 사용하는 것이 DB에 종속되지 않고
좀 더 유연하게 트랜잭션을 관리할 수 있기 때문에 낫다.

* JDBC를 사용하는 경우 DBMS 시스템의 트랜잭션 기능을 직접 사용하는 것이다.

* "엔터프라이즈 빈에 의한 트랜잭션 관리"에서는
EJBContext의 getRollbackOnly()와 setRollbackOnly()를 사용해서는 안된다.
이 메소드는 "컨테이너에 의한 트랜잭션 관리"인 경우에만 사용될 수 있다.

㉠ 상태유지 세션 빈
* EJB 빈 메소드가 끝날 때 반드시 트랜잭션을 커미트하거나 롤백할 필요가 없다.
따라서 상태유지 세션 빈의 경우 한 트랜잭션이 여러 개의 메소드에 걸칠 수 있다.

㉡ 무상태 세션 빈
* 트랜잭션 아래에서 실행되는 비즈니스 메소드는 반드시 메소드의 실행이 끝나기 전에
commit(), rollback()해야한다.

나. deploy descriptor에 트랜잭션 타입 지정(선언 트랜잭션 방식)
* 빈 개발자가 트랜잭션 관리코드를 소스 코드 내에 포함하지 않는다.
디플로이먼트할 때 트랜잭션 속성을 지정한다.

* 트랜잭션 처리가 필요한 엔터프라이즈 빈의 특정 메소드들마다 각각 6개의 트랜잭션 속성 중 하나를
만족하도록 디플로이먼트 디스크립터에 지정하여 디플로이먼트 한다.
그러먼, EJB 컨테이너가 특정 메소드가 호출될 때, 해당 트랜잭션 속성대로 트랜잭션이 보장되도록
자동으로 처리한다.

* NotSupported, Required, Supports, RequiresNew, Mandatory, Never

* 디플로이먼트할 때 디플로이먼트 디스크립터의 각종 정보(트랜잭션, 보안, 자원관리 등)에 따라
리모트 인터페이스를 구현(implement)한 클래스가 자동으로 생성된다.
그리고 이 클래스로부터 생성된 객체가 EJB 객체이다.
리모트 인터페이스를 구현(implement)한 클래스 안에 디플로이먼트 디스크립터에 지정한
트랜잭션 속성에 대응되는 트랜잭션 코드가 자동으로 생성되는 것이다.

* 다음과 같은 메소드들은 컨테이너가 관리하는 트랜잭션을 방해하기 때문에 빈 클래스 안에서 사용할 수 없다.

- java.sql.Connection의 commit(), setAutoCommit(), rollback()
- javax.ejb.EJBContext의 getUserTransaction()
- javax.transaction.UserTransaction의 모든 메소드

① NotSupported
* EJB 컨테이너는 명시적으로 트랜잭션을 지원하지 않으며 자동으로 트랜잭션을 결코 실행하지 않는다.
또한 클라이언트 안에서 트랜잭션을 시도해도 그것을 "지원하지 않는(NotSupported")다.

클라이언트 컨테이너
------------------------------------------------------------
1. 클라이언트에 트랜잭션 코드가 없는 경우
bean.deposit() -> bean.deposit()

* 만약 클라이언트 코드 내에서 트랜잭션을 시도하면 엔터프라이즈 빈 메소드 호출이
끝날 때까지 클라이언트 트랜잭션은 멈춘 상태(suspend)가 된다.
2. 클라이언트에 트랜잭션 코드가 있는 경우
utx.begin()
...
bean.deposit() -> utx.suspend();
... bean.depsit();
... utx.resume();
utx.commit()

* 만약 클라이언트 코드에 의해 호출된 엔터프라이즈 빈이 다른 엔터프라이즈 빈을 호출했을 때
클라이언트의 트랜잭션 문맥(Transaction Context)은 전달되지 않는다.
② Required
* 엔터프라이즈 빈 메소드는 클라이언트 내에 트랜잭션 코드가 있건 없건 간에 항상 트랜잭션 상태에서 실행.
만약 클라이언트가 트랜잭션 하에서 동작하지 않으면 EJB 컨테이너는 자동으로 트랜잭션을 시작
만약 클라이언트내에서 트랜잭션을 시도하면 비즈니스 메소드도 트랜잭션 하에서 동작한다.

클라이언트 컨테이너
---------------------------------------------------------------
1. 클라이언트에 트랜잭션 코드가 없는 경우
bean.deposit(1); -> tx.begin();
bean.deposit(1);
tx.commit();

2. 클라이언트에 트랜잭션 코드가 있는 경우
utx.begin()
...
bean.deposit(1); -> bean.deposit(1);
...
utx.commit();

* 만약 호출된 엔터프라이즈 빈 메소드가 다른 엔터프라이즈 빈 메소드를 호출해도 같은
트랜잭션 문맥 아래에서 동작한다.

클라이언트 컨테이너 Account 빈 인스턴스
----------------------------------------------------------------------
1. 클라이언트에 트랜잭션 코드가 있는 경우
begin()
...
deposit() -> 컨테이너 -> deposit()
...
commit()


2. 클라이언트에 트랜잭션 코드가 없는 경우
begin()
deposit() -> 컨테이너 -> -> deposit()
commit()


③ Supports
* 컨테이너는 자동으로 트랜잭션을 결코 실행하지 않는다.
그렇지만 클라이언트 내에서 트랜잭션을 시도하면 그것을 "지원(Supports)" 한다.

* 즉, 클라이언트 코드가 트랜잭션 하에서 엔터프라이즈 빈을 호출하면 "Required"의 경우와 같이 동작한다.
클라이언트 코드가 트랜잭션이 아닌 상태에서 엔터프라이즈 빈을 호출하면 "NotSupported"의
경우와 같이 동작한다.

* 엔터프라이즈 빈 메소드가 반드시 트랜잭션 하에서 동작할 필요가 없을 경우에 선언한다.

④ RequiresNew
* 컨테이너는 엔터프라이즈 빈 메소드를 호출하기 전에 항상 새로운 트랜잭션을 시작하며
매소드 호출이 끝났을 때 트랜잭션의 커미트를 시도한다.

1. 클라이언트에 트랜잭션 코드가 없는 경우

bean.deposit() -> tx.begin();
bean.deposit();
tx.commit();

* 만약 클라이언트 코드가 트랜잭션 하에서 엔터프라이즈 밴의 메소드를 호출하면
메소드 호출이 끝날 때까지 클라이언트 트랜잭션은 멈춘 상태(suspend)가 된다.
따라서 피하는 것이 좋다.

2. 클라이언트에 트랜잭션 코드가 있는 경우

utx.begin()
...
bean.deposit() -> utx.suspend()
... tx.begin();
utx.commit() bean.deposit();
tx.commit();
utx.resume();

⑤ Mandatory
* 클라이언트의 엔터프라이즈 빈의 메소드 호출은 반드시 트랜잭션 하에서 이루어져야 한다.
컨테이너는 자동으로 트랜잭션을 결코 실행하지 않는다.
트랜잭션은 클라이언트에 의해 관리되어야 한다.

* 만약 클라이언트가 트랜잭션 하에서 엔터프라이즈 빈의 메소드를 호출하지 않았을 경우
TransactionRequiredException이 발생한다

* 엔터프라이즈 빈 메소드를 호출하는 클라이언트가 트랜잭션 하에서 호출하지 않으며 아예
애플리케이션이 실행되지 않도록 만들 때 선언한다.

⑥ Never
* 트랜잭션이 어떤 상황에서도 실행되지 않는다.

* 만약 클라이언트 코드가 트랜잭션 하에서 엔터프라이즈 빈 메소드를 호출하면
java.rmi.RemoteException이 발생한다.

* 클라이언트 코드가 트랜잭션 상태가 아니라면 NotSupport경우와 같이 동작한다.


T1 : 클라이언트 코드 내에서 시작된 트랜잭션
T2 : EJB 컨테이너에 의해 시작된 트랜잭션
---------------------------------------------------------------------------------------
트랜잭션속성 클라이언트의트랜잭션 엔터프라이즈빈메소드와연관된트랜잭션 자원관리자와연관된트랜잭션
---------------------------------------------------------------------------------------
NotSupported 없음 없음 없음
T1 없음 없음

Reequired 없음 T2 T2
T1 T1 T1

Supports 없음 없음 없음
T1 T1 T1

RequiresNew 없음 T2 T2
T1 T1 T2

Mandatory 없음 에러 N/A
T1 T1 T1

Never 없음 없음 없음
T1 에러 N/A
---------------------------------------------------------------------------------------

(2) 트랜잭션 속성을 지정하는 구체적인 방법

가. 디플로이먼트 디스크립터 안에 선언
나. 디플로이먼트 툴의 GUI를 사용

* SessionContext 객체를 통해 javax.ejb.EJBContext의 setRollbackOnly()메소드를 호출할 수 있다.
이것은 트랜잭션이 커밋될 수 없도록 해주는 메소드이다.
트랜잭션하에서 실행되는 메소드가 중간에 애플리케이션 관련 예외가 발생할 경우 자동으로 롤백되지 않는다.
따라서 컨테이너에게 롤백시켜달라고 알리는 메소드이다.
이 메소드를 빈 클래스 내에서 호출하면 적당한 시기에 컨테이너에 의해 트랜잭션은 강제로 롤백된다.

(3) 상태유지 세션 빈에서 SessionSynchronization을 사용하는 경우
* 상태유지 세션 빈은 트랜잭션이 시작, 커미트, 롤백될 때 빈 인스턴스의 속성 값과 데이터베이스 정보의
일관성을 유지하기 위해 SessionSynchronization 인터페이스를 구현할 수도 있다.
하지만 반드시 구현해야 하는 것은 아니다.

* EJB 컨테이너에 의해 트랜잭션이 관리되는 겻우, 빈 클래스를 개발하는 개발자는
트랜잭션이 언제 시작되고 커미트되고 롤백되는지 정확히 예측할 수 없다.
하지만 그런 시기를 알고 적절하게 코딩해야 하는 경우도 있는데 SessionSynchronization은 그때를 위해 필요한것.

* EJB 컨테이너는 트랜잭션의 시작, 커밋, 롤백 등이 발생될 때 빈 인스턴스의 SessionSynchronization의 메소드를 호출한다.
따라서 빈 인스턴스는 현재 트랜잭션의 진행상황을 알 수 있게 되어 트랜잭션의 실행에 맞춰 적절한 행동을 할 수 있다.

- implement javax.ejb.SessionSynchronization
을 통해 인터페이스를 구현한다.

- public void afterBegin()
트랜잭션이 시작한 직후에 컨테이너에 의해 호출됨
afterBegin()이 호출되면 이후에 호출되는 비즈니스 메소드는 전부 트랜잭션하에서 동작하는 것이다.
따라서 트랜잭션이 아니거나 다른 속성의 메소드가 호출되면 에러가 발생

- public void beforeCompletion()
트랜잭션이 끝나기 직전에 컨테이너에 의해 호출됨

- public void afterCompletion(boolean committed)
트랜잭션이 끝난 직후에 호출됨.
파라미터가 참이면 커밋, 거짓이면 롤백인 경우에 호출됨

* 트랜잭션이 롤백되었을 때 DB의 값을 돌려 놓는 것 외에 빈 인스턴스의 속성 값도 원래 상태로
돌려야 하는 경우에 SessionSynchronization이 사용된다.

(4) 컨테이너가 관리하는 트랜잭션을 롤백하는 방법

* "컨테이너에 의한 트랜잭션 관리"에서 롤백이 일어나야만 하는 경우는 트랜잭션 수행도중 예외가 발생하는 때이다.
* 엔터프라이즈 빈에서 발생하는 모든 예외는 시스템 레벨의 예외와 애플리케이션 예외의 두종류로 나눠진다.
가. 시스템 레벨 예외
① 시스템 레벨의 예외가 발생하면 컨테이너는 자동으로 트랜잭션을 롤백

- 엔터프라이즈 빈 내에서 시스템 레벨의 예외가 발생하면 개발자는 EJBException을 발생시키기만 하면 된다.

나. 애플리케이션 레벨 예외
① SessionContext객체의 setRollbackOnly()를 호출하면 컨테이너가 트랜잭션을 롤백

- 애플리케이션 레벨의 예외가 발생하면 개발자가 소스 코드 내에 롤백을 지시하는 코드를 직접 작성해야 한다.
왜냐하면 애플리케이션 레벨의 예외가 발생하면 롤백이 자동적으로 수행되지 않기 때문이다.
반드시 수동으로 setRollbackOnly()를 호출하여 롤백해야 한다.

다. Example>
public void transferToSaving(double amount) throws InsufficientBalanceException
{
checkingBalance -= amount;//현재 예금계좌를 이체금액만큼 감소한다.
savingBalance += amount;// 이체할 예금계좌를 이체금액만큼 증가한다.

try
{
updateChecking(checkingBalance);//DB를 현재 예금 금액으로 업데이트

if( checkingBalance < 0.00 )// 만약 잔고가 0보다 작으면
{
context.setRollbackOnly();// 이체할 금액이 부족하므로 롤백을 지시함

throw new InsufficientBalancException();// 애플리케이션 예외 발생
}

updateSaving(savingBalance);// 잔고가 0보다 크면 정상처리
}
catch(SQLException ex)// 만약 SQL예외, 즉 시스템 예외가 발생하면
{
// EJBException을 발생시켜 컨테이너가 자동 롤백하도록 함
throw new EJBException("Transaction failed due to SQL Exception: " + ex.getMessage());
}
}

라. 트랜잰션 롤백을 위한 코드 템플릿

try
{
// 트랜잭션의 내용
if( 애플리케이션 예외 == true )
{
context.setRollbackOnly();// 컨테이너에게 롤백하도록 알림

throw new 애플리케이션예외();
}

// 트랜잭션의 내용
}
catch(시스템예외)
{
throw new EJBException();// 컨테이너에게 롤백하도록 알림
}

(5) Isolation
* 트랜잭션들은 작업을 "All or Nothing"으로 처리해야 할 뿐 아니라 여러 트랜잭션들이 동시에 실행될 경우
한 트랜잭션이 다른 트랜잭션에 의해 방해받지 않고 진행되어야 한다.

* Isolation이란 어떤 트랜잭션이 다른 여러 개의 트랜잭션과 동시에 같은 데이터를 사용해도 서로
독립적으로 해당 데이터를 처리할 수 있는 능력을 의미한다.

* 여러 트랜잭션이 동시에 같은 데이터를 사용하면 다음과 같은 3가지 현상이 발생할 수 있다.

- Dirty Read
: A트랜잭션이 B트랜잭션이 변동한 데이터를 커밋하기 전에 읽는다.
만약 B트랜잭션이 롤백되면 A트랜잭션은 무효가 된다.

update ->
read<-
rollback->

- Non-Repeatable Read
: 한 트랜잭션이 수행중에 읽은 데이터는 트랜잭션중이라면 이후에 읽어도 같은 값을 가질 것을 보장할 수 없다.

read <-
update ->
read <-

- Phantom Read
: DB에 데이터를 삽입하기 전에 시작한 트랜잭션은 DB에 새로 첨가된 레코드들을 알 수 없다.



* JDBC에서는 이런 현상들을 제어하기 위해 java.sql.Connection 클래스와
setTransactionIsolation()로 Isolation 레벨을 지정할 수 있다.

Isolation 레벨 DirtyReads UnRepeatableRead PhantomReads
-----------------------------------------------------------------------------------------------------------------
TRANSACTION_READ_UNCOMMITTED 커밋되지 않은 데이터들을 읽을 수 있다. 예 예 예

TRANSACTION_READ_COMMITTED 커밋되지 않은 데이터들을 읽을 수 없다. 아니오 예 예

TRANSACTION_REPEATABLE_READ 어떤 트랜잭션도 다른 트랜잭션에 의해서 아니오 아니오 예
읽혀지고 있는 데이터를 변경할 수 없다.

TRANSACTION_SERIALIZABLE 어떤 트랜잭션도 다른 트랜잭션이 사용하고 아니오 아니오 아니오
있는 데이터를 읽을 수도 변경할 수도 없다.


* EJB 아키텍처 안에 Isolation을 위한 공식적인 API는 정의되어 있지 않고 따라서
리소스 매니저에 따라 그 방법이 달라진다.

- 리소스 매니저가 데이터베이스 :
DBMS가 지원하는 Isolation과 locking에 따라 실제 정확한 Isolation의 수행 행위가 결정된다.

- 컨테이너에 의해 트랜잭션이 관리 될 경우 컨테이너가 자동으로 Isolation 레벨을 정의한다.

- 엔터프라이즈 빈에 의한 트랜잭션이 관리되는 세션 빈의 경우
개발자가 JDBC의 java.sql.Connection 클래스의 setTransactionIsolation()를 사용하여
빈 클래스내에서 Isolation레벨을 정의할 수 있다.
이런 Isolation 레벨을 엔터프라이즈 빈 내에서 정의하지 않으며 DB 시스템이 디폴트로 제공하는
Isolation레벨대로 동작한다.
만약 트랜잭션의 Isolation을 개발자가 정의한다면 애플리케이션이 사용하는 DBMS가 제공하는
Isolation을 고려해야 하기 때문에 매우 주의해야 한다.
12. 보안
* javax.ejb.EJBContext

javax.security.Principal getCallerPrincipal();
boolean isCallerInRole(String roleName);

// EJB 1.0 메소드는 deprecated 되었다.

java.security.Identity getCallerIdentity();
boolean isCallerInRole(java.security.Identity role);
13. 예외처리
java.lang.Throwable
java.lang.Error
java.awt.AWTError
...
java.lang.Exception
...
java.io.IOException
...
java.lang.RuntimeException
...

(1) 자바의 경우 개발자가 작성한 프로그램이 자바 언어의 구문적인 규약을 위배했을 때 자바 가상 머신은 에러를 발생시키고
이를 예외라는 형태를 통해서 프로그램에게 전달한다.
자바에서 예외는 클래스로 정의되며 모든 예외 클래스는 Throwable 클래스를 상속한다.

가. Error 클래스
자바 가상 머신 내부의 에러, 또는 AWT의 에러와 같이 일반적인 프로그램에서 처리할 수 없는 치명적인 오류이다.
이러한 Error 클래스를 상속한 예외들은 처리할 수도 없고 처리해서도 안된다.
따라서 개발자는 Error 클래스를 상속한 예외들을 고려할 필요가 없으며,
개발과 실행이 안정적으로 이뤄진다면 발생하지 않는다.

나. Exception 클래스
발생할 확률이 높고 프로그램의 책임이 높은 오류이다. 즉, 개발자가 실수로 예외가 발생되는 코드를 작성하는 경우가 많다.
따라서 개발자는 Exception 클래스를 상속하는 예외가 발생하지 않도록 코딩상의 오류를 수정하거나 예외가 발생하는 경우에
대한 처리가 필요하다.

다. RuntimeException 클래스
검사되지 않은 예외나 시스템 정의 예외를 말한다.
예를 들어 숫자를 0으로 나누는 경우나 범위를 벗어난 배열을 참조하는 경우에 발생한다.

(2) 자바에서의 예외는 위와 같이 계층적인 구조와 함께 다음과 같이 분류하는 것도 가능하다.
가. 검사된 예외(checked exception)
메소드의 throws절에 정의된 예외를 말한다. 이러한 예외는 컴파일시에 검사되므로 반드시 처리되어야 한다.
RuntimeExceptin 및 그 서브 클래스를 제외한 나머지 Exception 클래스의 서브 클래스들이 이에 해당한다.
자바에서는 검사된 예외를 발생한 이벤트를 전달하는데 사용하기도 한다.

나. 검사되지 않은 예외(unchecked exception)
컴파일러에 의해 검사되지 않은 예외를 말한다.
따라서 예외 처리를 해주지 않아도 컴파일시에 오류가 발생하지 않는다.
하지만 이 예외가 발생할 경우 프로그램은 비정상적으로 종료된다.
제대로 코딩만 된다면 이 예외는 완벽하게 없앨 수 있으며 따라서 개발자가 세심하게 주의하면 된다.
Error와 RuntimeExceptin 및 그 서브 클래스들이 검사되지 않은 예외에 해당된다.

(3) 자바에서는 예외가 발생하는 3가지 원인
가. 비정상적인 실행 상태가 자바 가상 머신에 의해서 감지되었을 경우
① 표현식의 계산이 자바 언어의 규칙을 위반했을 경우(예: integer를 0으로 나누는 행위)
② 프로그램의 로딩 및 링크 부부에서 에러가 발생했을 때
③ 제한된 자원을 초과하여 사용했을 때(예: 메모리 초과 사용)

나. throw 구문이 실행되었을 경우

다. 다음과 같은 이유로 비동기적인 예외가 발생할 경우
① Thread 클래스의 stop()가 호출될 때
② 자바 가상 머신에서 내부 에러가 발생할 때

(4) EJB에서의 예외 처리

* 예외 처리에 대한 EJB 스펙은 다음과 같은 목적을 위해 디자인되었다.
- 빈 인스턴스가 throw한 애플리케이션 예외는 클라이언트에게 정확히 전달되어야 한다.
- 빈 인스턴스가 throw한 애플리케이션 예외가 자동으로 클라이언트의 트랜잭션을 롤백해서는 안된다.
클라이언트가 애플리케이션 예외로부터 트랜잭션을 복구할 수 있는 기회가 주어져야 한다.
- 인스턴스의 상태 변수나 영속성 있는 데이터를 비안정적인 상태로 만드는 예기치 못한 예외는
안전하게 처리되어야 한다.

* EJB의 예외는 크게 애플리케이션 예외와 시스템 예외로 나눌 수 있다.
<애플리케이션 예외>
스펙에 정의된 표준 애플리케이션 예외나 엔터프라이즈 빈의 홈 인터페이스와 리모트 인터페이스 메소드의
throws절에 정의된 예외들 중 java.rmi.RemoteException를 제외한 나머지 예외들을 말한다.
이러한 애플리케이션 예외는 엔터프라이즈 빈에서 발생한 애플리케이션 수준의 비정상적인 상태를
클라이언트에게 전달하는데 사용된다.

<시스템 예외>
엔터프라이즈 빈의 비즈니스 메소드와 컨테이너 콜백 메소드에서 발생하는 시스템 수준의 예외를 말한다.
이러한 시스템 예외는 주로 EJB 컨테이너가 엔터프라이즈 빈의 메소드에서 발생하는 각종 비정상적인 상태를
제대로 처리해주지 못하기 때문에 발생한다.
이러한 시스템 예외는 EJB 컨테이너에 의해 catch되고, 이를 로그에 기록함으로써 시스템 관리자에게
예외의 발생을 경고한다.

가. 애플리케이션 예외
① 엔터프라이즈 빈의 홈 인터페이스와 리모트 인터페이스 메소드의 throws절에 정의된 예외들 중
java.rmi.RemoteException 예외를 제외한 나머지 예외들

이러한 애플리케이션 예외는 엔터프라이즈 빈의 비즈니스 메소드가 클라이언트에게 애플리케이션 수준의
비정상적인 상태를 알리는데 사용된다. 따라서 빈을 이용해 클라이언트를 개발하는 개발자는 예외에
알맞은 처리를 해줌으로써 이러한 애플리케이션 예외를 복구할 수 있다.

② javax.ejb.CreateException, javax.ejb.RemoveException, javax.ejb.FinderException과 같은
예외와 이들 클래스를 상속한 예외들

이러한 예외들은 엔터프라이즈 빈의 create, remove, find 메소드의 오류를 클라이언트에게 알리기
위한 표준 애플리케이션 예외로 사용된다.

③ 빈 제공자 관점에서의 애플리케이션 예외
* 빈 제공자(개발자)는 리모트 인터페이스와 홈 인터페이스 메소드의 throws절에 애플리케이션 예외를 정의한다.
* 애플리케이션 예외는 시스템 관리자가 아닌 클라이언트에 의해 처리되므로, 시스템 레벨의 문제가 아닌
비즈니스 로직상의 예외를 발싱시키게 된다.
* 빈 제공자는 비즈니스 메소드가 클라이언트에게 비즈니스 로직 예외를 알릴 수 있도록 적절한
애플리케이션 예외를 throw해야 한다.
* 주의사항은 애플리케이션 예외가 발생해도 트랜잭션은 자동으로 롤백되지 않는다는 사실
* 따라서 빈 제공자는 데이터의 무결성을 보장하기 위해서 엔터프라이즈 빈 인스턴스가 애플리케이션 예외를
throw하기 전에 다음 중 하나의 작업을 반드시 수행해야 한다.

- 빈 제공자는 트랜잭션을 커밋 하거나 계속 수행하려는 클라이언트에 의해 엔터프라이즈 빈이
무결성을 잃지 않도록 보장해야 한다.
예를 들어, DB에 대한 갱신을 하기 전에 입력 파라미터의 값이 유효하지 않다는 애플리케이션 예외를
throw함으로써 데이터 무결성을 보장한다.

- 애플리케이션 예외를 throw하기전에 EJBContext.setRollbackOnly()를 이용하여 트랜잭션이 롤백되도록
플래그 세팅. 롤백으로 세팅된 트랜잭션은 절대로 커밋되지 않는다.

* 빈 제공자가 애플리케이션 예외를 작성할 때 특히 주의해야 할 사항

- 애플리케이션 예외는 java.lang.RuntimeException이나 java.rmi.RemoteException 클래스를 상속해서는
안된다. 이들 클래스 및 서브 클래스는 시스템 예외에서 사용된다.

- 빈 제공자는 javax.ejb.CreateExceptio, javax.ejb.RemoveException, javax.ejb.FinderException과
같은 표준 EJB 애플리케이션 예외를 사용해야만 한다.
또한 빈 제공자는 이러한 표준 EJB 애플리케이션 예외의 서브 클래스를 정의하여 엔티티 빈의
메소드에서 그 서브 클래스의 인스턴스를 throw할 수 있다.
이렇게 서브 클래스를 정의함으로써 빈 제공자는 이 예외를 catch하는 클라이언트에게 더 많은
정보를 제공할 수 있다.

④ 클라이언트 관점에서의 애플리케이션 예외

* 엔터프라이즈 빈 호출시 애플리케이션 예외가 발생해도, 클라이언트 프로그램이 엔터프라이즈 빈을 계속해서
호출하는 것은 가능하다. 즉, 애플리케이션 예외로 인해 EJB객체가 제거되지는 않는다.

* 트랜잭션 도중에 클라이언트가 엔터프라이즈 빈을 호출하다가 애플리케이션 예외를 catch하여도
컨테이너가 자동으로 트랜잭션을 롤백으로 세팅하지 않으므로 클라이언트는 트랜잭션을 계속 할 수 있다.

* 하지만 throw된 애플리케이션 예외 때문에 컨테이너가 자동으로 트랜잭션을 롤백시키지 않아도,
엔터프라이즈 빈이 애플리케이션 예외를 throw하기 전에 트랜잭션을 롤백으로 세팅할 수도 있다.

* 특정 애플리케이션 예외가 트랜잭션 롤백을 일으키는지의 여부를 알아내는 방법은 두가지이다.
- 정적인 방법
프로그래머는 엔터프라이즈 빈의 리모트 인터페이스와 홈 인터페이스에 대한 문서를 체크한다.
빈 제공자는 예외를 throw하기 전에 엔터프라이즈 빈이 트랜잭션을 롤백으로 세팅하는
애플리케이션 예외를 지정할 수 있다.

- 동적인 방법
CMP 트랜잭션을 사용하는 엔터프라이즈 빈을 호출하는 클라이언트는 현재 트랜잭션이 롤백으로
세팅되었는지의 여부를 알아내기 위해서 javax.ejb.EJBContext 객체의 getRollbackOnly()를
사용할 수 있다. 다른 방법으로는 javax.transaction.UserTransaction 인터페이스의 getStatus()
를 사용해 트랜잭션 상태를 알아낼 수도 있다.

⑤ 표준 애플리케이션 예외
* EJB 스펙은 다음과 같은 표준 애플리케이션 예외를 정의하고 있다.
- javax.ejb.CreateException
- javax.ejb.DuplicateKeyException
- javax.ejb.FinderException
- javax.ejb.ObjectNotFoundException
- javax.ejb.RemoveException

㉠ CreateException
* CreateException 및 그 서브 클래스는 홈 인터페이스의 create(...)메소드에서 애플리케이션 수준의
예외가 발생했음을 알려주는 역할을 수행한다. 하지만 클라이언트가 이 예외를 받는다고 해도,
해당 엔티티 객체의 초기화가 완료되었는지 아니면 전혀 생성되지 않았는지를 알 수는 없다.

* 또한 CreateException은 엔티티 빈 인스턴스의 ejbCreate(...)와 ejbPostCreate(...)에서 생성이나
초기화 작업중에 애플리케이션 수준의 예외가 발생하였음을 알리기 위해 사용된다.

㉡ DuplicateKeyException
* DuplicateKeyException은 CreateException의 서브 클래스로써, 같은 키를 가진 엔티티 객체가
존재하여 새로운 객체를 생성할 수 없는 경우 ejbCreate(...)가 throw한다.
DuplicateKeyException은 DB의 프라이머리 키나 다른 유일한 키에 의해 발생한다.

㉢ FinderException
* FinderExceptionn 및 그 서브 클래스는 find(...)에서 애플리케이션 수준의 예외가 발생하였음을
알려주는 역할을 수행한다. 즉, find메소드에서 애플리케이션 수준의 예외가 발생하였을 경우
ejbFind<METHOD>(...)메소드는 FinderException 이나 그 서브 클래스를 throw 하게 된다.
㉣ ObjectNotFoundException
* ObjectNotFoundException은 FinderException의 서브 클래스로써, 요청된 엔티티 객체가 존재하지
않는 경우 ejbFind<METHOD>(...)메소드가 throw한다.
주의할 점은, 하나의 객체를 반환하는 find 메소드만이 이 예외를 throw한다는 것이다.
다수의 객체를 반환하는 find 메소드는 이 예외를 throw할 수 없다. 다수의 객체를 반환하는
find 메소드는 적합한 객체를 찾을 수 없음을 알리기 위해서 비어 있는 컬렉션(collection)을 반환해야 한다.

㉤ RemoveException
* RemoveException 및 그 서브 클래스는 remove(...) 메소드에서 애플리케이션 수준의 예외가
발생했음을 알려주는 역할을 수행한다. 하지만 클라이언트가 이 예외를 catch하더라도 엔티티 객체가
제대로 제거되었는지의 여부를 알 수는 없다.
또한 RemoveException은 ejbRemove() 메소드의 엔티티 객체의 제거 과정에서 애플리케이션 수준의
예외가 발생하였음을 알리기 위해 사용된다.

⑥ 시스템 예외
* 엔터프라이즈 빈의 비즈니스 메소드와 컨테이너 콜백 메소드는 다양한 예외와 에러로 인해 정상적인 실행을
방해 받는다. 보통 이러한 예외와 에러들은 전혀 예상치 못했거나 아니면 예상했지만 EJB 컨테이너가 이를
제대로 처리해주지 못하기 때문에 발생한다. 이러한 예외와 에러를 시스템 예외라 통칭

* 엔터프라이즈 빈 메소드가 정상적인 실행을 방해하는 시스템 수준의 예외나 에러에 직면하게 되는 경우
해당 메소드는 throws절에 명시된 예외 클래스와 호환되면서도 상황에 적합한 비 애플리케이션 예외를
throw해야 한다. EJB 스펙이 예외의 사용을 정확하게 정의하고 있지는 않지만, 빈 제공자는
다음의 가이드라인을 따라야 한다.

- 빈 메소드에서 RuntimeException이나 에러가 발생하면, 이 에러는 빈 메소드에서 컨테이너로 전달된다.
따라서 빈 메소드는 절대로 이 예외를 catch하면 안된다.

- 빈 메소드에서 java.lang.RuntimeException의 서브 클래스가 아니면서 복구할 수 없는 예외가 발생하면,
빈 메소드는 원래의 예외를 감싸는 javax.ejb.EJBException을 throw해야 한다.

'공부 > Spring' 카테고리의 다른 글

Spring IOC  (0) 2011.12.12
About Spring  (0) 2011.12.12
RMI(원격 메소드 호출, Remote Method Invocation)  (3) 2011.07.04

메서드 호출은 항상 같은 힙에 들어있는 두 객체 사이에서 이루어진다.

 class Foo{
       void go()  {
             Bar b = new Bar();
             b.doStuff();
       }

        public static void main (String[] args) {
                 Foo f = new Foo();
                 f.go();
       }
}


위 코드의 두 객체는 JVM에서 관리하는 같은 힙안에 들어있으며 힙에 있는 객체에 접근하는 방법을 나타내는
레퍼런스 변수를 비트에 채워 넣는 일은 JVM에서 맡아 처리한다. JVM은 항상 각 객체가 어디에 있는지,
어떻게 그 객체에 접근할 수 있는지를 알고 있다. 하지만 JVM에서는 그 자신의 힙에 있는 인스턴스에 대한 것만 알고 있다.
예를들어, 한 시스템에서 돌아가고 있는 JVM에서 다른 시스템에서 돌아가고 있는 JVM의 힙 공간에 대해서
알수 있게 할수는 없다.
사실 어떤 시스템에서 돌아가고 있는 JVM에서 같은 시스템에서 돌아가고 있는 JVM에 대해서도 전혀
알 수가 없다. JVM이 물리적으로 같은 시스템에 있는 것인지 다른 시스템에있는것인지는 중요하지않다.
중요한것은 JVM 두개가 별도로 호출된 JVM 이라는 것이다.


다른 시스템에서 돌아가고 이쓴ㄴ 객체에 있는 메소드를 호출하려면 어떻게해야하나?

방법은 RMI(원격 메소드 호출, Remote Method Invocation)

원격 메서드 호출 방법 설계
서버, 클라이언트,서버 보조 객체, 클라이언트 보조 객체, 이렇게 네가지를 만든다.



'보조객체(helper)'의 역활

'보조객체(helper)'는 실제 통신 작업을 처리하는 객체다. "클라이언트가 로컬 객체에 있는 메소드를 호출하는 척" 하는 것을
가능하게 해준다. 사실, 클라이언트는 로컬 객체에 있는 메소드를 호출한다. 클라이언트는 그 보조 객체를 실제 서비스로
간주하고 클라이언트 보조 객체에 대한 메소드를 호출한다. 결국, 클라이언트 보조 객체는 진짜 객체를 대신하는 역활을 한다.

즉, 클라이언트 보조 객체는 "클라이언트에서 호출하려고 하는 메소드를 가지고 있는 객체인 척" 하는 객체다.

하지만 클라이언트 보조 객체는 사실 진짜 원격 서비스가 아니다.
(서비스에서 제공하는 것과 같은 메소드가 있 기 때문에) 원격 서비스인 것처럼 행동하긴 하지만 거기에는 클라이언트에서
예상하고 있는 실제 메소드 처리 코드 같은 것은 없다. 대신 클라이언트 보조 객체에서는
서버와 접촉하고, 메소드 호출에 대한정보(메소드명, 인자 등)를 전송하고 서버에서 결과를 리턴할때까지 기다린다.

서버 쪽에서는 서비스 보조 객체에서, (소켓 연결을 통해) 클라이언트 보조 객체에서 보낸 요청을 받아서 호출에 대한
정보를 열어보고 진짜 서비스 객체에 있는 진짜 메소드를 호출한다.

서비스 보조 객체는 서비스로부터 리턴값을 받아 포장한후 다시 (소쳇의 출력 스트림을 통해) 클라이언트 보조 객체로 보낸다.
클라이언트 보조 객체는 그 포장을 풀고 그 정보를 다시 클라이언트 객체로 리턴한다.

메서드 호출과정


1. 클라이언트 객체에서 클라이언트 보조 객체에 있는 메서드를 호출한다.
2. 클라이언트 보조 객체에서 메서드 호출에 대한 정보(인자, 메소드명 등)를 포장해서
    네트워크를 통해 서비스 보조 객체로 보낸다.
3. 서비스 보조 객체에서 클라이언트 보조 객체로부터 받은 정보를 풀어서 어떤 객체의 어떤 메소드를 호출할지 알아낸 다음
    진짜 서비스 객체에있는 진짜 메소드를 호출한다.


자바 RMI가 클라이언트와 서비스 보조 객체를 제공한다.

자바에서는 RMI가 클라이언트와 서비스 보조 객체를 만들어주고 클라이언트 보조 객체가 진짜 서비스인 것처럼 보이게하는
방법도 알고 있다. 즉, RMI에서 클라이언트 보조 객체에 원격 서비스에 대해 호출하고자 하는 것과 같은 메소드를 배정해 주는 방법도
알고있다.

그리고 RMI는 클라이언트에서 클라이언트 보조 객체(진짜 서비스인 것처럼 행동하는 객체)를 찾고 가져올 수 있게 해주는 룩업 시스템을 비롯한 모든 필요한 기반을 제공한다.

RMI를 사용할때 JRMP, IIOP 이렇게 두가지 규약가운데 하나를 사용할수있는데 JRMP는 RMI에서 원래 사용하던 규약으로 자바에서->자바로 원격 호출을 하기 위한 용도로 만들어진 반면, IIOP는 CORBA용 규약이며 자바가 아닌 원격 객체에 있는 것도 호출할수 있는 규약이다.
양쪽에서 모두 자바를 사용하지않으면 엄청나게 많은 해석과 변환이 이루어져야하기 떄문에 CORBA는 RMI에비해 쓰기가 어렵다.


RMI에서 클라이언트 보조 객체는 '스터브(stub)'고
서버 보조 객체는 '스켈레톤(skeleton)' 이다.



코드로 보면 이해하기 쉽다.

서버용코드


-원격 인터페이스(service)
 import java.rmi.*;
//RemoteException과 Remote인터페이스가 java.rmi 패키지에 들어있다.
public interface MyRemote extends Remote {
 //인터페이스에서 반드시 java.rmi.Remote를 확장시켜야한다.
           public String sayHello() throws RemoteException;
           //모든 원격 메소드에 RemoteException을 선언해야한다.
}

-원격 서비스(serviceimpl, 인터페이스를 구현한 클래스)
import jave.rmi.*;
import java.rmi.server.*;
//UnicastRemoteObject가 java.rmi.server패키지에 들어있다.
public class MyRemoteImpl extends UnicastRemoteObject implements MyRemote {
//앞서 만든 원격 인터페이스를 구현해야 한다.
//원격 객체를 만들 때는 UnicastRemoteObject를 확장하는 것이 가장 쉬운 방법이다.
             public String sayHello() {
                       return "Server says, 'Hey'";
             }
             // 당연히 모든 인터페이스 메소드를 구현해야 한다. 하지만 RemoteException을 선언하지 않아도 된다.

            public MyRemoteImpl() throws RemoteExeption {}
           //상위 클래스 생성자(UnicastRemoteObject생성자)에서 예외를 선언하기 떄문에 반드시 생성자를 만들어야한다.
              이렇게 해야 생성자에서 위험한코드(상위클래스 생성자)를 호출한다는 것을 선언할수 있기떄문이다.

            public static void main (String[] args) {

                      try{
                          MyRemote service = new MyRemoteImpl();
                          Naming.rebind("Remote Hello", service);
                          //원격 객체를 만들고 Naming.rebind()라는 정적메소드를 써서 RMI 레지스트리에 결합시킨다.
                             나중에 클라이언트에서 RMI레지스트리에 있는 서비스를 찾을떄 바로 여기에서 지정한이름을 사용한다.

                     }catch ( Exception ex){
                          ex.printStackTrace();
                     }
            }
}


클라이언트코드

import java.rmi.*;
//Naming 클래스(RMI 레지스트리 룩업에 필요함) 가 java.rmi 패키지에 들어있다.

public class MyRemoteClient{
          public static void main (String[] args) {
                    new MyRemoteClient().go();
          }

          public void go(){

                    try{
                         MyRemote service = 1.(MyRemote) Naming.lookup("2.rmi://127.0.0.1/3.Remote Hello");
                         //1. 레지스트리에서 보낸 객체는 Object 유형이므로 반드시 캐스트를 해야함.
                         //2. ip주소 또는 호스트명이필요하다.
                         //3. 서비스를 연결/재연결 할때 사용한 이름도 필요하다.
                         String s = service.sayHello();
                        //  일반 메소드 호출방법하고 똑같다. (RemoteException을 처리하거나 선언해야한다는점을 빼면)
                         System.out.println(s);
                     }catch(Exception ex){
                         ex.printStackTrace();
                     }
           }
}



그림으로 보면


1.클라이언트에서 RMI 레지스트리에 대한 룩업 작업을 한다.
   Namin.lookup("rmi://127.0.0.1/Remote Hello");

2. RMI 레지스트리에서 스터브 객체를 리턴한다.
   (이 객체는 lookup()메소드의 리턴값 형태로 전달된다)
   그리고 RMI에서 스터브를 자동으로 역직렬화 해준다. 클라이언트에 스터브 클래스(rmic가 만들어준것)가 없으면 스터브가 역직렬화되지않음

3. 클라이언트에서 실제 서비스에 있는 메소드를 호출하는 것과 같은 방법으로 스터브에 있는 메소드를 호출한다.

'공부 > Spring' 카테고리의 다른 글

Spring IOC  (0) 2011.12.12
About Spring  (0) 2011.12.12
엔티티 빈  (0) 2011.07.26