|
Enterprise Java Technologies Tech Tips (2003년 8월 25일)에 오신
여러분을 환영합니다. Java 2 Platform, Enterprise Edition (J2EE)에 기반한
enterprise Java technologies 와 APIs의 사용에 관한 최신 정보를 얻어 가시기
바랍니다. 이 글에서는 Java 2 SDK, Standard Edition, v 1.4와 Java 2 SDK,
Enterprise Edition, v 1.3.1 (Reference Implementation)를 사용합니다.
이번 호에서는,
 리스너를
이용한 애플리케이션 초기화
파인더
메소드와 EJB-QL
저자 Mark Johnson
예제의 샘플 아카이브를 다운로드
받으세요. 컨텍스트 루트는 ttaug2003이고 샘플코드의 사용법은 index.html welcome file
에서 보실 수 있습니다. 이 코드의 사용에 관한 권한이나 정보는 license
terms를 참고하시기 바랍니다.
리스너를 이용한 애플리케이션 초기화
"Servlet
Life Cycle Listeners" 2003/6/26 Tech Tip 에서는 애플리케이션의 특정코드를
실행시키기 위한 서블릿 라이프 사이클 이벤트 리스너 (servlet life cycle event listeners)의
이용방법을 설명하고, 애플리케이션 배포시에, 이를 이용해
애플리케이션 컴포넌트(application components)를 초기화할 수도 있다고 언급하였다.
이번 TechTip은 웹 애플리케이션이 배포될 때, 엔터티 빈의 네트워크를 만들기
위해 ServletContextListener가 사용되는 예를 보여줄 것이다.
서블릿 라이프 사이클 리스너--리뷰
라이프 사이클 리스너는 서블릿 콘테이너 (servlet container)로부터 이벤트들을 받는
이벤트 리스너 클래스(event listener classes)이다. 서블릿 콘테이너는
특정 라이프 사이클 이벤트의 발생을 리스너들에게 알려주는 역할을 하며,
이벤트들은 다음과 같은 일을 한다.
- 서블릿 콘텍스트와 HTTP 세션의 생성 혹은 파기
- 서블릿 콘텍스트 애트리뷰트와 HTTP세션 애트리뷰트의 생성, 변경 혹은 제거
- HTTP세션의 액티베이션과 패시베이션(passivation)
- HTTP 세션 애트리뷰트에 구속되어 있거나 그렇지 않은 객체에게 알림
웹 애플리케이션은 애플리케이션의 모든 서블릿과 JSP페이지 사이에 공유되는
하나의 ServletContext객체를 갖는다.(분산된 웹 애플리케이션은 각각의 웹 애플리케이션과
자바 버츄얼 머신을 위한 하나의 ServletContext를 갖는다.) 웹 애플리케이션이 배포될 때,
웹 콘테이너는 ServletContext객체를 초기화한다. 만약 웹 애플리케이션의
deployment descriptor가 ServletContextListeners를 선언하면,
콘테이너는 선언된 리스너 순으로 각 리스너의 contextInitialized 메소드를 호출한다.
이 이벤트는 서블릿의 라이프 사이클에서 단 한번만 일어나는데, 이벤트의 발생시점은
웹 애플리케이션의 필터나 서블릿이 초기화되기 전이다. 결과적으로,
ServletContextListener.contextInitialized 메소드는 애플리케이션 컴포넌트의 초기화에
사용되는 것이다.
Listeners가 트랜잭션과 트랜잭션 사이를 구별하기(demarcate)위해서
javax.transaction.UserTransaction 인터페이스를 사용할 수는 없다는 것을 기억하자.
샘플 코드
"파인더 메소드와 EJB-QL"은 엔터티 빈의 컬랙션을 식별하기 위해
파인더 메소드 생성 방법을 설명한다. 이 글에서 사용된 예제는
파인더 메소드를 위한 엔터티 빈를 필요로 한다. 따라서 애플리케이션이 배포될 때,
엔터티 빈의 네트워크을 생성할 수 있는 수단이 있어야 한다. 그 수단이라는 것은
ServletContextListener를 통해서 제공된다. 엄밀히 말하자면, 이 팁에서 제공된
샘플 코드는 LoadDataSCL 클래스를 포함하는데, 이 클래스는 ServletContextListener의
contextInitialized 메소드가 엔티티 빈의 넥트워크을 생성하도록
ServletContextListener을 구현하는 역할을 한다. 이 메소드는
웹 애플리케이션 아카이브(WAR file)에서 배포되는 XML파일의 컨텐츠에 기반한 빈을 생성한다.
LoadDataSCL 클래스의 contextInitialized 메소드를 보자.
public void contextInitialized(
ServletContextEvent sce) {
ServletContext sc = sce.getServletContext();
System.out.println(
"contextInitialized: Creating entity beans.");
DataLoader dl = new DataLoader();
InputStream is = sc.getResourceAsStream(
"/persondata.xml");
dl.load(is);
System.out.println(
"contextInitialized: Entity beans created.");
}
이 메소드는 ServletContextEvent 타입의 단일인수(single argument)를 받고,
ServletContextEvent는 초기화되는 서블릿 컨텍스트에 레퍼런스를 리턴하는
getServletContext메소드를 포함한다. DataLoader객체는 포맷된 InputStream인
XML로부터 data read를 이용하여 로컬 Person, Address, PhoneNumber 엔터티 빈를 생성한다.
인풋 스트림(input stream)은 getResourceAsStream의 호출에서 양생되었고 애플리케이션
아카이브에 패키지된 XML파일에 스트림을 연다.
애플리케이션의 배포시에, 서블릿 콘테이너는 ServletContext객체를 초기화한 후,
LoadDataSCL클래스의 인스턴스를 생성하고 ServletContextEvent객체를 ServletContextEvent에
넘겨준다. 그리고 나서 메소드는 XML파일에 정의된 엔터티 빈의 네트워크을 생성한다. 가령,
사용자가 Reference Implementation에 애플리케이션을 배포시키면, 서버 로그 파일에 다음을
출력한다.
contextInitialized: Creating entity beans.
INFO: Document parsed
contextInitialized: Entity beans created.
Created Context:/ttaug2003
Application TTAug2003 deployed.
애플리케이션 배포가 완성되기 전에 초기화 과정이 선행되어야 함을 명심하자.
데이터를 초기화하기 위해서 리스너를 이용하는 것은 웹 리퀘스트가 서비스되기 전에
이미 생성 혹은 초기화 된 객체가 존재한다는 것을 말한다.
이 기법은 엔터티 빈의 네트워크를 생성하는데 유용할 뿐만 아니라,
database connections, JMS sessions, Connector 레퍼런스와 같은 웹 컴포넌트들 간에
공유되는 리소스를 서블릿 콘텍스트 리스너(servlet context listener)에 초기화할 때도
사용할 수 있다.
마지막으로 사용자는 웹 애플리케이션의 리소스를 생성하기 위해 다른 타입의 리스너를
이용할 수 있다. 예를 들면, HTTP 세션 애트리뷰트에 상태를 갖는 세션 빈
(가령, 쇼핑카트를 나타내는 것과 같은) 에 대한 레퍼런스를 저장할 수 있다.
그리고 나서 같은 세션 빈 레퍼런스는 같은 세션안의 여러 웹 리퀘스트를
서비스하도록 사용될 수 있다. HTTP 세션 리스너 클래스를 이용해서 확보된
세션 빈 레퍼런스를 HTTP 세션에 저장할 수 있는데, 특정 애플리케이션 서버가 이러한 연산을
수행할 때, 세션 마이그레이션(session migration)과 패시베이션/활성화(passivation/activation)를
적절하게 다루는 역할도 이 클래스의 몫이다.
파인더 메소드와 EJB-QL
파인더 메소드는 엔터티 빈의 인스턴스나 컬랙션을 찾는
엔터티 빈 홈 인터페이스 메소드이다.
애플리케이션과 콤포넌트 개발자들은 인스턴스를 찾을 때 사용하도록 범주를 정한다.
예를 들어 콤포넌트 개발자가 Account home interface 메소드인
findDelinquentAccounts를 정의하면, 이 메소드는 90일 이상 지난 어카운트를나타내는 모든
Account의 레퍼런스 콜랙션을 리턴한다.
Enterprise JavaBeans (EJB) version 2.0이전에는, 파인더 메소드를 생성하는 것이 어려웠지만,
EJB specification version 2.0의 쿼리 랭귀지 (EJB-QL) 소개 이후, 파인더 메소드의 생성이
훨씬 수월해졌다.
EJB-QL은 standard SQL 92에 기반한(혹은 비슷한) 객체지향적인 쿼리 랭귀지이다.
이 글은 EJB 2.0 이상에서 파인더 메소드 구현을 위한 EBJ-QL 사용 방법을 설명하고,
지난 테크팁인 "리스너를 이용한 애플리케이션 초기화" 에서 설명한 로더의 초기화에
의해 생성된 엔터티 빈을 사용한 파인더의 예를 살펴본다.
파인더와 쿼리
EJB 2.0 이전에는 파인더 메소드를 생성할 때 2가지 옵션이 있었다;
- bean-managed persistence를 사용하고
ejbFind 메소드를 수동으로 구현한다.
- container-managed persistence를 사용하고, vendor-specific 쿼리 랭귀지를
이용하여 파인더 구현을 정의한다.
첫번째 방법은 이식가능하게 만들 수 있다는 장점을 갖지만, 많은 양의 일을 동반하고
CMP의 이점을 이용할 수가 없는 단점이 있다. 반면 두번째 방법은 상대적으로 쉽게
구현할 수 있지만 이식성을 포기해야 한다.
EJB 2.0이상의 파인더 메소드는 이식가능하고 쉽다.(사실, 파인더 메소드를 작성할 필요조차 없다.)
EJB 2.0 에서 파인더 메소드를 생성하는 방법을 보자.
- 샘플코드에서 발췌한 내용과 같이 엔터티 빈의 홈 인터페이스에 파인더 메소드
signature를 정의한다. 파인더 메소드 signature는
PersonLocal 엔터티 빈의
PersonLocalHome 인터페이스에 정의된다.
public interface PersonLocalHome
extends EJBLocalHome {
...
public Collection findAll()
throws FinderException;
...
};
- 두번째로, 엔터프라이즈 빈의 deployment descriptor에
<query>요소를 추가한다.
다음은 PersonLocal 엔터티 빈의 deployment descriptor에서 발췌한 것이다.
<query>
<description>
Return all Person objects
</description>
<query-method>
<method-name>findAll</method-name>
<method-params />
</query-method>
<ejb-ql>
SELECT OBJECT(p) FROM Person AS p
</ejb-ql>
</query>
<query>는 쿼리가 하는 일을 문서화하는 <description>요소를 갖는다.
<query-method>는 홈 인터페이스에서 정의된 파인더 메소드의 이름을 정의한다.
(이 경우에는 findAll이다.) <method-param>요소들의 리스트는 메소드 매개변수(parameter)의
타입을 제공한다. 메소드의 이름과 함께 타입 리스트는 유일무이하게 메소드 signature를
식별한다. 마지막으로, <ejb-ql>은 어떤 엔터티 빈이 파인더에 의해 리턴되어야 하는지를
식별하는 EJB-QL 쿼리를 정의하는데, 위의 경우에는 모든 Person 객체들이 리턴된다.
배포시에, deployment tools은 파인더 메소드를 작성하거나 구현하기 위해
EJB-QL 쿼리를 사용한다. EBJ-QL의 구조(semantics)가 EJB 명세(specification)에
명시되어 있기 때문에 EJB-QL 쿼리가 애플리케이션 서버를 통해 이식가능하다.
파인더 메소드를 좀 더 자세히 살펴보자.
Finder Method Declarations 작성하기
앞에서 언급했다시피, 파인더 메소드를 생성할 때 엔터티 빈의 홈 인터페이스에
메소드 signature를 선언해야 하는데, 그 메소드는 콘테이너에 의해 자체적으로 구현된다.
파인더 메소드는 다음과 같은 룰을 갖는다.
- 파인더 메소드의 이름은 스트링 "find"으로 시작해야 한다.
- 파인더 메소드는 반드시 퍼블릭이어야 한다.
- 모든 파인더 메소드는
FinderException를 보낸다.
- 원격 파인더 메소드는
RemoteException을 발생시키지만, 로컬 파인더 메소드는 그럴 수 없다.
- 파인더 메소드의 리턴값은 컴포넌드 인터페이스 타입이거나,
컴포넌트 인터페이스 타입의
java.util.Collection객체이다.
만약 쿼리가 하나이상의 값을 잠재적으로 리턴한다면,
그것의 리턴값은 반드시 java.util.Collection이어야 한다.
- 홈 인터페이스는 반드시 홈 인터페이스에 존재하는
findByPrimaryKey(primaryKeyType)
메소드를 포함해야하고, 오버로드하면 안된다. PrimaryKeyType은 엔터티의
프라이머리 키타입이고 컴포넌트 인터페이스 타입를 리턴한다.
파인더 signatures를 지정한 후에는 <query>를 엔터티 빈의 deployment descriptor에 추가하고,
대응(corresponding) 엔터티 빈을 정의하는 <entity> 안에 <query> 를 내포시킨다.
EJB-QL 이해하기
EJB-QL 쿼리는 엔터티 빈의
abstract persistence schema로부터 값(values), 객체(objects),
그리고 객체의 컬랙션 (collections of objects)을 선택한다. abstract persistence schema는
엔터티 빈, 그것의 CMP파일, 그 둘을 서로 연결하는 CMR필드의 이식가능한
schema representation이다. 콘테이너와 deployment tools은 abstract schema와 그에
반하는 쿼리를 특정 플랫폼 구현을 위한 실제 스키마(real schema)와 쿼리로 맵핑한다.
EJB-QL 쿼리의 구성요소는,
- 쿼리가 리턴할 것을 정하는
SELECT 구
- 데이터가 온 장소를 지정하는
FROM 구
- 객체 셀렉션의 범주를 정하는
WHERE 구
샘플 코드의 파인더 메소드와 <query>요소를 보여주는 예를 보자. 파인더 메소드는
PersonLocal 엔터티 빈의 PersonLocalHome 인터페이스에 선언되었다.
프라이머리 키를 이용한 객체 찾기
모든 객체는 findByPrimaryKey메소드를 갖는데, PersonLocalHome에 작성된
signature는 다음과 같다.
public PersonLocal findByPrimaryKey(String key)
throws FinderException;
이 메소드는 항상 콘테이너에 의해 구현되기 때문에 대응 EJB-QL가 없다.
모든 객체 찾기
많은 엔터티 빈은 컴포넌트 인터페이스 타입의 컬랙션을 리턴하는 findAll 메소드를 제공한다.
샘플코드의 파인터 메소드 선언은,
public Collection findAll() throws FinderException;
이고,
파인더의 대응 EJB-QL는;
SELECT OBJECT(p) FROM Person AS p
이 쿼리는 Person에서 객체들을 선택한다. FROM 구는 Person 객체와 p객체의 "nicknames"를
선택한다. 닉네임은 OBJECT(p)를 사용하여, 셀렉트 구의 객체 타입으로 변환된다.
파인더 메소드는 컴포넌트 인터페이스나 컬랙션만 리턴한다는 것을 기억하자.
NULL을 이용해서 값이 존재하는지 확인하자
샘플코드의 추상 스키마(abstract schema)에서, Person은 0개 혹은 한 개의 workAddress 객체를
갖는데, 하나도 갖지 않았을 경우 Person.workAddress의 값은 NULL이다. workAddress 없는 user를
찾기 위한 파인더 메소드의 signature는 이하와 같다.
public Collection findWithNoWorkAddress()
throws FinderException;
deployment descriptor의 대응 EJB-QL는;
SELECT OBJECT(p)
FROM Person AS p
WHERE p.workAddress IS NULL
결과가 "workAddress IS NULL"인 사람에게로 한정되었다는 것만 제외하면
이 쿼리는 findAll과 흡사하다. "workAddress IS NULL"는 Person이 workAddress를
갖지 않을 때에 일어난다. 또한 키워드 NULL은 "WHERE p.middlename IS NULL"과 같이
cmp-field가 설정되었는지를 테스트하기 위해 WHERE 구문안에서 사용된다.
컬랙션이 멤버를 갖는지 EMPTY를 사용해서 확인하자
abstract persistence schema에서 Person 과 PhoneNumber는1대 다의 관계를 갖는다.
Phone이 없는 모든 Person객체를 찾는 PersonLocalHome메소드를 보자.
public Collection findWithNoPhone()
throws FinderException;
이 파인더의 EJB-QL는;
SELECT OBJECT(p) FROM Person AS p
WHERE p.phones IS EMPTY
p.phones는 컬랙션이기 때문에 IS NULL대신에 IS EMPTY가 사용되었다. 반대로
EJB-QL 의 NOT 연산자를 사용해서 Phones를 갖는 모든 Persons을 찾을 수도 있는데
이때는 WHERE 구를 WHERE p.phones IS NOT EMPTY로 바꾸면 된다.
쿼리로 인수(arguments) 넘겨주기
쿼리는 특정 장소에 "?1",
"?2"과 같은 폼의 위치매개변수(positional parameters)를 갖는다.
(자세한 내용은 EJB 2.0 specification을 참고.) 여기서 숫자는 파인더 signature의
매개변수 리스트에 매개변수의 위치를 지정하는데, 매개변수의 인덱스 초기값은 1이다.
(다시 말하면, "?0"는 없다는 말이다.)
데이터베이스의 모든 Person은 M이나 F값을 갖고 파인더는 성별로 모든 Persons를 찾아낸다.
public Collection findGender(String gender)
throws FinderException;
또한 그것의 <query> 요소는;
<query>
<description>Return persons by gender</description>
<query-method>
<method-name>findGender</method-name>
<method-params>
<method-param>java.lang.String</method-param>
</method-params>
</query-method>
<ejb-ql>SELECT OBJECT(p) FROM Person AS p
WHERE p.gender = ?1</ejb-ql>
</query>
여기서 주목할 만한 것은 <method-param>가 단일 스트링 인수를 갖는 메소드를 지정한다는 것과,
WHERE p.gender = ?1를 포함하는 WHERE clause의 매개변수 ?1이 쿼리 가 실행될 때 String인수로
대체된다는 것이다.
이 글은 파인더 메소드의 생성을 위한 EJB-QL의 소개에 그치고 있지만,
EJB-QL은 이후의 Enterprise Java Technologies Tech Tips에서 셀렉트 메소드를
생성할 때도 사용될 것이다. EJB-QL에 대한 심화 정보는 Applying Enterprise JavaBeans를
참고한다.
샘프 코드 실행하기
이 팁의 샘플 아카이브를 다운로드받자. 애플리케이션의 컨텍스트 루트는 ttaug2003이고,
다운로드된 EAR파일은 완성된 샘플예제코드를 포함한다.
샘플프로그램을 실행하기 위해서는 다음 과정이 필요하다.
- j2ee서버와 데이터베이스 서버 모두 실행 중인지 확인하자. J2EE Reference Implementation을
위해서는 다음 2가지를 모두 실행해야 한다.
j2ee -verbose
and
cloudscape -start
- 앞서 설명한 것처럼 ear파일을 다운로드받자.
- 서버에 ear파일을 배포하자. 사용자는 deploytool 프로그램을 이용해서
J2EE Reference Implementation에 애플리케이션 아카이브(
ttaug2003.ear)를 배포할 수 있다.
$J2EE_HOME/deploytool -deploy ttaug2003.ear localhost
로컬 호스트(localhost)를 서버가 설치되는 호스트의 이름으로 대체하자.
단일 머신에 인스톨할 때, 호스트이름은 일반적으로(글자 뜻대로) localhost가 된다.
- 애플리케이션을 http://localhost:8000/ttaug2003 에 액세스하자.
Reference Implementation보다는 J2EE의 specification을 따르는 기능 구현의 측면에서 사용하고자 한다면 사용자의 플랫폼에 애플리케이션을 배포하기 위해 J2EE 프로덕트의 배포 툴(deployment tool)을 사용한다.
애플리케이션 실행중에 index.html welcome file for instructions을 보자.
애플리케이션을 실행하면, 다음과 같은 페이지를 보게 된다.
결합된 EJB-QL 를 실행하기 위해 하이라이트된 기능을 하나 혹은 몇 개 선택하자.
가령, 사용자가 다음을 선택하면,
List Persons with no phone
파인더 메소드인 findWithNoPhone()의 EJB-QL이 실행된다.
SELECT OBJECT(p) FROM Person AS p
WHERE p.phones IS EMPTY
결과는 다음과 같다.
|
