|
Enterprise Java Technologies Tech Tips에 오신 여러분을 환영합니다. 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)를 사용합니다.
이번 호에서는,
 JNDI의 소개
Entity
Resolver 작성하기
저자 Mark Johnson
예제의 샘플 아카이브를 다운로드
받으세요. 컨텍스트 루트는 ttaug2003이고 샘플코드의 사용법은 index.html welcome file
에서 보실 수 있습니다. 이 코드의 사용에 관한 권한이나 정보는 license
terms를 참고하시기 바랍니다.
JNDI의 소개
많은 J2EE개발자들이 환경 변수(environment entries),
DataSource 객체, JMS 메시지 수신지(JMS message
destinations) 그리고 엔터프라이즈 빈 홈 인터페이스(enterprise bean home
interfaces)를 찾고자 Java Naming and Directory Interface (JNDI)를
이용한다. 하지만 많은 사람들은 JNDI에 대한 진정한 이해 없이 이러한 기능을 하는 코드를 단순히 복사해서
붙이고 고칠 뿐이다. 이 팁은 사용자의 엔터프라이즈 시스템에 배포된 리소스를 액세스하기 위해 JNDI를 사용하는
방법을 소개한다.
엔터프라이즈 애플리케이션들은 그것들의 특성상, 비즈니스 오퍼레이션을 지원하기 위해 여러곳에 배포된
리소스들을 한데 모아야 한다. 새로운 시스템이 생성되었다거나, 기존의 시스템이 업그레이드 되었다거나, 오래된
시스템이 더 이상 작동하지 않을 때 서비스들이 오가게 된다. 애플리케이션 서비스를 서로 분리하는 것은 시스템을
쉽게 유지/확장할 수 있게 한다. 하지만 서비스가 분리되었을 때, 각자의 역할을 제대로 수행하기 위해서는 서로를
찾아낼 수 있어야만 한다. 이 때가 바로 명명 서비스(naming services)와 디렉토리가 유용한
시점이다.
명명 서비스는 이름을 이용해서 객체나 객체에 대한 레퍼런스를 검색하는 방법을 제공한다. 그러한 객체로의
예는 메시지 큐(message queues), 데이터베이스 커넥션 팩토리(database connection
factories), 환경 파라미터(environment parameters), 그리고 엔터프라이즈 빈과 같은
분산 컴포넌트(distributed components)등이 있다. 애플리케이션 개발자들은 명명 서비스내의
이름에 객체들을 바인딩해서 객체에 이름을 붙인다. 애플리케이션 코드는 이렇게 바인딩된 이름으로 객체들을 검색하기
위해 명명 서비스를 사용할 수가 있다. 이러한 분리(decoupling)는 네트워크 객체들을 사용하는 시스템
컴포넌트에 대한 어떠한 변경없이 유지 보수를 위해 올리거나 내릴 수 있고, 요청들을
리다이렉트(redirect)시킬 수 있으며, 서비스가 다이나믹하게 재조정될 수 있음을 의미한다.
이미 기존의 명명 서비스에 대해 잘 이해하고 있으리라고 생각된다.
- DNS (Domain Name Service)는
java.sun.com과 같은
호스트네임을 %nslookup java.sun.com%과 같은 IP주로소 매핑한다.
- CORBA (Common Object Request Broker Architecture)를 위해
쓰이는 COS (Common Object Services) 명명 서비스 는 CORBA 인터페이스
이름(interface names)을 객체 인터페이스로 매핑한다.
사용자는 컴퓨터의 파일시스템을 파일의 경로(pathname)에 파일의 컨텐츠를 매핑하는 일종의 명명
서비스로 생각할 수 있다.
밑의 그림은 명명 서비스가 서비스 네임을 데이터나 서비스 인터페이스로 매핑하는 방법을 보여주고 있다.
이름(name)을 객체로 매핑하는 것을 바인딩이라 부른다. 바인딩은 명명 서비스를 형성하는 사람에 의해
생성된다. 대부분의 명명 서비스는 프로그램이 런타임시에 이름을 객체로 바인딩하거나 해제하는 방법도 제공한다.
컨텍스트는 이름을 객체로 바인딩한 집합이다. 예를 들면, 파일시스템에서 경로
/home 는 흔히 시스템의 유저 디렉토리를 포함하는 컨텍스트이다. 컨텍스트는 다른
컨텍스트를 포함할 수도 있다. /home 컨텍스트의 유저 디렉토리는 그 자체가 유저
파일을 포함하는 컨텍스트이다.
컨텍스트는 최소한 명명 규칙(naming convention)과 검색기능(lookup function)을
갖는다. 예를 들면, DNS는 가장 구체적인 스트링은 왼쪽, 도메인은 오른쪽에 나타내면서 스트링을 점으로
분리하는 명명 규칙을 갖는다. DNS의 검색기능은 nslookup 프로그램을 이용해서
커맨드라인으로부터 액세스가 가능하다.(물론, DNS 명명 서비스에 대한 API도 존재한다.) 컨텍스트는 대게
객체들을 바인딩하고 해제하는 방법과 그것들을 열거하는 방법을 제공한다.
때때로 명명 서비스 의 객체들은 다른 프로그램이 필요로 하는 데이터를 포함한다. 가령,
J2EE애플리케이션에서 환경 변수를 나타내는 객체들은 대게 명명 서비스 에 저장된다. 하지만 이외에 명명
서비스의 객체는 객체에 대한 레퍼런스를 나타낸다. 예를 들면, 서버에 레퍼런스를 제공하는 객체는 통상적으로 오픈
서버 커넥션이 아닌 서버에 대한 레퍼런스로서 명명 서비스 에 의해 저장된다.명명 서비스 에 의해 리턴된 레퍼런스
객체는 필요시에 서버 커넥션을 생성하기 위해 사용될 수 있다.
다음 그림은 컨텍스트의 개념도이다. top 컨텍스트는 /top로 불리며 객체,
레퍼런스, 그리고 다른 컨텍스트들을 포함한다. 컨텍스트 /top은 subcontexts
b 와 g를 갖는다. 컨텍스트 /top/g 는 subcontext "b"를 갖는다.
A라고 불리는 객체가 하나 이상 일지라도, 특정 개체 /top/g/b/a는 그 위치가
컨텍스트 /top/g/b 임이 분명하기 때문에 찾을 수가 있다.
바인딩된 객체들에 대한 데이터를 제공하는 명명 서비스를 디렉토리라고 부른다. 가령, 파일시스템 디렉토리는
일반적으로 크기, 타입, 접근 허용 그리고 파일을 생성하고 수정한 날짜에 관한 정보를 제공한다. 몇몇 디렉토리는
이름으로 검색, 애트리뷰트의 조합으로 검색 모두를 허용한다.
각각의 명명 서비스들은 각자의 태스크(task)에 잘 맞도록 되어있지만, 그들이 작동하는 방식은 서로
다르다. 각 명명 서비스는 고유의 명명규칙, 검색기능, 바인딩과 디렉토리 프로토콜(directory
protocols)과 객체 서비스 인터페이스(object service interfaces)를 갖는다. JNDI
는 네트워크 서비스를 이름짓고 찾기 위해 일관된 방법을 제공한다.
Java Naming and Directory Interface
JDBC 데이터베이스 커넥션(database connections), JMS 큐(JMS queues) 혹은
엔터프라이즈 빈 홈 인터페이스(enterprise bean home interfaces)와 같은 네트워크 객체에
액세스하기 위해 JNDI 를 사용하는 방법을 이미 알고 있을 것이다. 사실 JNDI 는 이름들을 객체로
매핑하지만, JNDI 는 명명 서비스가 아니다. 그보다도 JNDI는 명명 서비스를 표준적인 방법으로
액세스가능하게 하면서 기존의 명명 서비스를 감추는(wrap) 인터페이스들의 집합이다.
다음 그림에서 보는 것과 같이, 자바 애플리케이션은 JNDI인터페이스를 이용해서
감춰진(underlying) 명명 서비스에 액세스한다.
애플리케이션내의 코드는 JNDI 인터페이스 메소드를 호출한다. 이러한 메소드를 구현하는 객체들은 JNDI
인터페이스 호출을 감춰진 명명 서비스에 대한 호출로 매핑한다. 또한 JNDI는 통합된 명명 규칙도 정의한다.
JNDI 이름들은 JNDI의 명명 관리자(naming manager)에 의해 감춰진 명명 서비스의 명명 규칙을
따르는 이름으로 매핑된다.
javax.naming 패키지는 다음과 같은 명명과 디렉토리에 관련된 인터페이스들을
포함한다.
javax.naming.Context는 컨텍스트를 나타내는데, 이것은 바인딩과
서브컨텍스트를 찾고 관리하는 데에 쓰인다.
javax.naming.Name는 명명 서비스의 이름을 추상적으로
표현(abstract representation)하게 해준다.
javax.naming.Binding은 명명 서비스 이름과 그 이름에 바인딩된
객체의 표현이다.
javax.naming.Reference는 객체의 복사본을 얻어낼 수 있게
해준다.
컨텍스트 찾기
이 팁에 포함된 샘플코드는 JNDI컨텍스트의 컨텐츠를 열거하는 방법을 보여준다. 샘플 서블릿
Oct2003Servlet는 사용자가 입력한 이름에 해당하는 JNDI namespace내의 컨텐츠를
찾고 디스플레이한다.
컨텍스트를 얻는 가장 쉬운 방법은 javax.naming.InitialContext
클래스의 인스턴스를 생성하는 것이다. 샘플 서블릿 메소드 jndiList 는 최초의
컨텍스트를 생성하고 명명된 객체를 찾을 때 그것을 사용한다. InitialContext ic = new InitialContext();
Object objFound = ic.lookup(name);
여기에서 name은 사용자가 HTML페이지에서 입력한 HTTP GET 혹은
POST 변수명(vriable name)이다. 만약 리턴된 객체가
Context 라면 jndiList 는
listContext 메소드를 호출하고,
ListContext메소드는 주어진 이름에 해당하는 컨텍스트의 컨텐츠를 열거한다. 객체가
DataSource이면, jndiList 는 명명된 데이터 소스에
관한 정보를 출력한다.
listContext 메소드는 주어진 JNDI 컨텍스트의 컨텐츠를 하나의 테이블로
출력한다. 이를 위해서는 Context 메소드 listBindings
를 이용하는데, 이는 NamingEnumeration 를 리턴한다.
NamingEnumeration ne = context.listBindings("");
NamingEnumeration 는
java.util.Enumeration를 구현한 것이다.
NamingEnumeration.next 메소드는
javax.naming.Binding 타입의 객체를 리턴하고, 이는 객체의 이름과 객체의
클래스 이름 그리고 저장된 객체 자체를 포함한다.
while (ne.hasMore()) {
Binding ncp = (Binding)ne.next();
String objName = ncp.getName();
String objClass = ncp.getClassName();
Object objObj = ncp.getObject();
...
}
단순히 Context내의 이름들과 클래스이름을 보고자 한다면
Context.list 메소드를 이용할 수 있다.
Context.list도 NamingEnumeration를
리턴하지만, 그것이 담고있는 컬랙션은 Binding이 아닌
NameClassPair 타입이다. NameClassPair는
이름과 객체 클래스 이름만을 포함한다.
샘플애플리케이션을 배포하고 실행하는 방법은 샘플코드
실행하기 를 참고한다.
애플리케이션을 실행하면, 다음과 같은 시작페이지를 보게 된다.
컨텍스트를 입력하거나, 텍스트 필드를 빈 상태로 놔두고 명명된 컨텍스트의 컨텐츠를 보기 위해 List버튼을
클릭한다. 예를 들면 jdbc 의 엔트리는 다음과 같은 화면을 디스플레이한다.
JNDI 에 관한 더 자세한 정보는 JNDI
튜토리얼를 참고한다.
ENTITY RESOLVER 작성하기
XML을 작성해 본 적이 있다면, ampersand (&)과 less-than (<)같은
캐릭터를 표현하기 위해 XML이 사용하는 심볼을 봤을 것이다. 이 심볼을 엔터티라고 부른다. XML에서,
엔터티는 항상 &로 시작해서 세미콜론(;)으로 끝난다. 엔터티는 XML다큐먼트를 파라미터로 나타내기 위해
사용된다. 이 팁은 다큐먼트의 DTD에 엔터티를 정의함으로써 XML다큐먼트를 파라미터로 나타내는 방법을
설명한다. XML다큐먼트에서 어떤 텍스트가 엔터티 레퍼런스를 대체할 것인지를 조정하는 entity
resolver를 작성하는 방법도 설명한다.
엔터티의 정의
XML다큐먼트의 여러 곳에서 반복사용되는 텍스트는 엔터티로 표현하는 것이 더 낫다. 엔터티는 다큐먼트의
DTD에 쉽게 정의된다. 엔터티를 정의하는 예제는 샘플코드 파일
misc/data.xml에서 볼 수 있다. <!ENTITY helloWorld "Hello, world!">
& 과 <를 사용하는 것처럼, 엔터티는 XML자체에 사용될 수도 있다.
data.xml파일에서 제공하는 예가 있다. <This>
<That>&helloWorld;</That>
<That>&helloWorld;</That>
...
</This>
XML 파서가 이 텍스트를 읽으면, &와 ;사이의 모든 것을 엔터티의 컨텐츠로 대체한다. <This>
<That>Hello, world!</That>
<That>Hello, world!</That>
...
</This>
값이 DTD에 직접적으로 정의된 엔터티는 내부(internal)엔터티라고 불린다. 이것은 C프로그램의
#define과 매우 흡사하다. 내부 엔터티는 프로젝트의 단일 장소에 반복적으로 사용되는 저작권 공고와 같은
텍스트를 삽입하는데 유용하다. 내부 엔터티의 정의를 업데이트하면 대체된 텍스트를 모두 바꾸게 된다.
File Contents 포함하기
또 다른 엔터티는 외부(External)엔터티로서 스트링 대신에 파일으로부터 그것의 대체 문자열을 받는다.
외부엔터티는 C의 #include와 비슷하다. 외부 엔터티를 위한 대체 문자열(replacement text)은
파일의 전체 컨텐츠이다.
외부 엔터티 중 한 종류는 엔터티의 이름을 짓기 위해 PUBLIC 식별자를 사용한다. 그리고 대체 텍스트를
찾을 위치를 XML프로세싱 프로그램에 명령하기 위해 시스템 식별자를 사용한다. 샘플코드에서 이러한 방법으로
4개의 외부 엔터티를 정의하는 XML 파일, data.xml를 볼 수 있다. <!ENTITY firstLine
PUBLIC "-//elucify//ejtt//oct2003//firstLine"
"english.props">
<!ENTITY secondLine
PUBLIC "-//elucify//ejtt//oct2003//secondLine"
"english.props">
<!ENTITY thirdLine
PUBLIC "-//elucify//ejtt//oct2003//thirdLine"
"english.props">
<!ENTITY lastLine
PUBLIC "-//elucify//ejtt//oct2003//lastLine"
"english.props">
각각의 엔터티는 그것의 public id인 고유의 이름을 갖는다. PUBLIC 키워드 뒤에 나오는 첫번째
스트링이 바로 그것이다. 두번째 스트링은 시스템 id로서 대체 텍스트를 찾을 위치를 특정 시스템 식별자에
제공한다.
&firstLine)과 같은 엔터티 레퍼런스가 XML다큐먼트에 사용될 때에는, XML 프로세서가
대체 텍스트를 찾을 방법을 반드시 인지하고 있어야 한다. 이를 엔터티 레퍼런스를 해석(resolve)한다고
한다.
디폴트로, 대부분의 XML 프로세서는 엔터티의 대체 텍스트를 검색하기 위해 URL이나 파일시스템 경로을
시스템 ID로 사용한다. 하지만 간혹 XML프로세서가 레퍼런스를 리졸브하는 방법을 제어해야할 필요가 있다.
가령, 시스템 id가 URL인데 인터넷에 연결되어 있지 않다면 어떻게 할 것인가? SAX 와 DOM 파서s 가
기반하고 있는 SAX 인터페이스는 entity resolver 클래스(entity resolver class)를
정의함으로써 외부 엔터티를 위한 대체 텍스트를 제어할 수 있게 해준다.
엔터티 레퍼런스를 Resolve하기
org.sax.xml.EntityResolver인터페이스를 구현하는 entity
resolver는 signature가 다음과 같은 단일 메소드 resolveEntity를
갖는다.
public InputSource resolveEntity(String publicID,
String systemID)
throws SAXException;
이 메소드는 인수로 엔터티의 public id 나 system id를 받는다. 이것들은
<!ENTITY>선언 상단부의 키워드 PUBLIC 뒤에 오는 첫번째, 두번째
인수들이다. 이는 org.sax.xml.InputSource 인터페이스를 구현하는 객체를
리턴한다. entity resolver는 엔터티를 위한 대체 텍스트의 위치를 정하기 위해 public 과
system id를 사용한다. 그리고 파서가 대체 텍스트를 얻기 위해 액세스하는
InputSource 객체를 리턴한다.
이 글의 샘플 코드는 Properties클래스를 이용해서 Java
속성(property) 파일을 읽는 entity resolver
PropertyEntityResolver 또한 포함하고 있다. 파일을 로드하고 대체
텍스트를 검색하는 코드는 다음과 같다. // Load properties from a URL.
protected void loadProps(String urlString)
throws MalformedURLException, IOException {
URL url = new URL(urlString);
URLConnection con = url.openConnection();
_props = new Properties();
_props.load(con.getInputStream());
}
// Given the name of a property,
// return the property's value
public InputSource resolveEntity(
String publicID, String systemID)
throws SAXException {
// Load properties from URL referenced
// by system id.
// Assume system id is the same for all symbols.
if (_props == null) {
try {
loadProps(systemID);
} catch (Exception e) {
throw new SAXException(e);
}
}
// Extract property name from public ID
int index = publicID.lastIndexOf("//");
String value = "???PropertyNotFound???";
if (index >= 0) {
value = _props.getProperty(
publicID.substring(index + 2));
}
StringReader sr = new StringReader(value);
return new InputSource(sr);
}
샘플 클래스 EntityResolverDemo가 DOM 파서(parser)를
생성하면, 다음과 같이 클래스를 위한 entity resolver를
PropertyEntityResolver의 인스턴스로 설정한다. // Create the parser, and set the error handler
// and entity resolver
DocumentBuilder db = dbf.newDocumentBuilder();
db.setErrorHandler(this);
PropertyEntityResolver propertyEntityResolver =
new PropertyEntityResolver();
db.setEntityResolver(propertyEntityResolver);
파서가 외부 엔터티 레퍼런스를 만나게 되면 파서는
PropertyEntityResolver.resolveEntity를 호출하고, 그것에
대한 응답으로 대체 텍스트를 포함하고 있는 InputSource를 받는다. 그리고 나서
대체 텍스트를 읽고 그것을 엔터티 레퍼런스가 발생한 result XML안의 그 레퍼런스와 치환한다.
샘플 애플리케이션을 배포하고 실행하는 방법은 샘플코드
실행하기를 참고한다. ERDemo 프로그램을 실행하는데 필요한 사항은
인덱스페이지를 참고한다. english.props파일을 지정하고 있는
data.xml을 이용해서 샘플 프로그램을 실행해 보자.
- entity resolver jar 파일로부터 데이터 파일을 추출하자,
ERDemo.jar: jar xvf ERDemo.jar misc
CLASSPATH에 ERDemo.jar를
추가한다.Put ERDemo.jar in your
CLASSPATH.
- 예제를 실행한다.
java ERDemo misc/data.xml
ERDemo 프로그램을 실행하면, 다음과 같은 영문 대체 텍스트를 포함한
XML다큐먼트를 생성하게 된다.
<?xml version="1.0" encoding="UTF-8"?>
<This>
<That>Hello, world!</That>
<That>Hello, world!</That>
<That>Line 1: This line is written in English.
</That>
<That>Line 2: How are you?</That>
<That>Line 3: What would you like to eat?</That>
<TheOther>Last line: I must say goodbye.
</TheOther>
</This>
그 다음엔 data.xml를 편집하고 모든 <!ENTITY정의에 다음과 같이
"english.props"를 "spanish.props" 로
대체해 보자. <!ENTITY firstLine
PUBLIC "-//elucify//ejtt1003//firstLine"
"spanish.props">
<!ENTITY secondLine
PUBLIC "-//elucify//ejtt1003//secondLine"
"spanish.props">
<!ENTITY thirdLine
PUBLIC "-//elucify//ejtt1003//thirdLine"
"spanish.props">
<!ENTITY lastLine
PUBLIC "-//elucify//ejtt1003//lastLine"
"spanish.props">
텍스트는 다음과 같이 바뀔 것이다. <?xml version="1.0" encoding="UTF-8"?>
<This>
<That>Hello, world!</That>
<That>Hello, world!</That>
<That>Line 1: Esta linea esta escrito en Espagnol.
</That>
<That>Line 2: Como estas?</That>
<That>Line 3: Que quieres cenar?</That>
<TheOther>Last line: Hay que decir adios!
</TheOther>
</This>
샘플 코드는 불어와 독어로 된 속성 파일도 포함하고 있으니, 이러한 파일들을 이용해서 샘플 코드를
실행해보는 것도 좋은 생각이다.
JNDI에 대한 자세한 정보는 JNDI
튜토리얼을 참고한다.
샘플코드 실행하기
이 팁의 샘플
아카이브를 다운로드받자. 애플리케이션의 컨텍스트 루트는 ttoct2003 이고, 다운로드된 EAR파일은
완성된 샘플예제코드를 포함한다.
샘플프로그램을 실행하기 위해서는 다음 과정이 필요하다
- j2ee서버와 데이터베이스 서버 모두 실행 중인지 확인하자. J2EE Reference
Implementation을 위해서는 다음 2가지를 모두 실행해야 한다.
j2ee
-verbose
and
cloudscape
-start
- 앞서 설명한 것처럼 ear파일을 다운로드 받자.
- 서버에 ear파일을 배포하자. 사용자는 deploytool 프로그램을 이용해서 J2EE
Reference Implementation에 애플리케이션 아카이브(ttoct2003.ear)를 배포할 수
있다.
$J2EE_HOME/deploytool -deploy ttoct2003.ear localhost
로컬 호스트(localhost)를 서버가 설치되는 호스트의 이름으로 대체하자. 단일 머신에
인스톨할 때, 호스트이름은 일반적으로(글자 뜻대로) localhost가 된다.
- 애플리케이션을
http://localhost:8000/ttoct2003에
액세스하자.
Reference Implementation보다는 J2EE의 specification을 따르는 기능 구현의
측면에서 사용하고자 한다면 사용자의 플랫폼에 애플리케이션을 배포하기 위해 J2EE 프로덕트의 배포
툴(deployment tool)을 사용한다.
애플리케이션의 실행에 대한 지시사항은 index.html welcome file을
참고한다.
| 
