Sun ONE 로고      이전      목차      색인      다음     

Sun ONE Application Server 관리자 설명서

10장
이름 지정 및 자원 구성

이 장에서는 Sun ONE Application Server에서 사용하는 J2EE 자원에 대해 설명하고 이러한 자원을 만들고 관리하기 위해 사용하는 방법에 대해서도 설명합니다.

이 장은 다음 내용으로 구성되어 있습니다.

J2EE 이름 지정 서비스 및 자원 정보

EJB를 포함한 J2EE 응용 프로그램, 웹 응용 프로그램 구성 요소 및 응용 프로그램 클라이언트는 자원 관리자, 데이터 소스(예: SQL 데이터 소스), 연결 팩토리, Mail 세션, Java Message Service 대상 객체, URL 연결 팩토리 같은 다양한 자원에 액세스합니다. J2EE 플랫폼은 JNDI (Java Naming and Directory) 이름 지정 서비스를 통해 이러한 자원을 응용 프로그램에 제공합니다.

Sun ONE Application Server를 사용하면 다음 J2EE 자원을 만들고 관리할 수 있습니다.

JDBC 데이터 소스

JDBC 데이터 소스는 Sun ONE Application Server를 사용하여 만들고 관리할 수 있는 J2EE 자원입니다.

JDBC API는 관계형 데이터베이스 시스템과의 연결을 위한 API입니다. JDBC API는 두 부분으로 구성되어 있습니다.

JDBC DataSource 객체는 Java 프로그래밍 언어로 데이터 소스를 표현하는 것입니다. 기본적으로 데이터 소스는 데이터를 저장하기 위한 기능을 의미합니다. 데이터 소스는 대기업의 복잡한 데이터베이스처럼 복잡할 수도 있고 행과 열로 구성된 파일처럼 간단할 수도 있습니다. JDBC 데이터 소스는 Sun ONE Application Server를 통해 만들고 관리할 수 있는 J2EE 자원입니다.

JDBC 데이터 소스에 대한 자세한 내용은 "JDBC 자원 정보"를 참조하십시오.

JavaMail 세션

JMS 대상은 Sun ONE Application Server를 통해 만들고 관리할 수 있는 J2EE 자원입니다.

많은 인터넷 응용 프로그램에서 전자 메일 알림을 보낼 수 있는 기능을 필요로 하므로 J2EE 플랫폼은 JavaMail API와 함께 JavaMail 서비스 공급자를 포함하여 응용 프로그램 구성 요소가 인터넷 메일을 보낼 수 있도록 합니다. JavaMail API는 두 부분으로 구성되어 있습니다.

JavaMail 세션은 Sun ONE Application Server를 통해 만들고 관리할 수 있는 J2EE 자원입니다. JavaMail 세션에 대한 자세한 내용은 "JavaMail 자원 정보"를 참조하십시오.

JMS 대상

JMS (Java Messaging Service)는 게시-가입 모델과 신뢰할 수 있는 지점간 메시징을 지원하는 메시징용 표준 API입니다. 이 사양에는 지점간 메시징과 게시-가입 메시징을 모두 구현하는 JMS 공급자가 필요합니다.

JMS는 두 가지 유형의 일반적인 관리된 객체인 연결 팩토리와 대상을 제공합니다. 두 가지 모두 공급자 관련 정보를 캡슐화하지만 JMS 클라이언트 내에서 아주 다르게 사용됩니다. 연결 팩토리는 메시지 서버를 연결하는 데 사용되며 대상 객체는 JMS 메시징 서비스에서 사용하는 물리적 대상을 식별하는 데 사용됩니다.

JNDI (Java Naming and Directory Interface) 정보

이 절에서는 JNDI (Java Naming and Directory Interface)에 대해 설명합니다. JNDI는 다양한 종류의 이름 지정 및 디렉토리 서비스를 액세스하기 위한 응용 프로그램 프로그래밍 인터페이스(API)입니다. J2EE 구성 요소는 JNDI 조회 메소드를 호출하여 객체를 찾습니다.

이 절에서는 다음 항목에 대해 설명합니다.

JNDI 구조

JNDI 구조는 API (Application Programmer's Interface)와 SPI (Service Provider Interface)로 구성됩니다. Java 응용 프로그램은 JNDI API를 사용하여 다양한 이름 지정 및 디렉토리 서비스를 액세스합니다. SPI는 다양한 이름 지정 및 디렉토리 서비스가 투명하게 플러그 인되게 함으로써 Java 응용 프로그램이 JNDI API를 사용하여 해당 서비스에 액세스할 수 있게 해줍니다. 다음의 "JNDI 구조의 개요" 그림은 JNDI API를 통해 액세스할 수 있는 서비스를 보여줍니다.

그림 10-1 JNDI 구조의 개요

JNDI 구조를 전체적으로 보여주는 그림입니다.

J2EE 이름 지정 서비스

JNDI 이름은 사람들에게 친숙한 객체 이름입니다. 이러한 이름은 J2EE 서버에서 제공하는 이름 지정 및 디렉토리 서비스에 의해 객체에 바인딩됩니다. J2EE 구성 요소는 JNDI API를 통해 이 서비스에 액세스하므로 일반적으로 사람들에게 친숙한 객체 이름을 JNDI 이름이라고 합니다. Pointbase 데이터베이스의 JNDI 이름은 jdbc/Pointbase입니다. Sun ONE Application Server는 시작할 때 구성 파일로부터 정보를 읽어 이름 공간에 JNDI 데이터베이스 이름을 자동으로 추가합니다.

J2EE 응용 프로그램 클라이언트, Enterprise Bean 및 웹 구성 요소에는 JNDI 이름 지정 환경에 대한 액세스 권한이 필요합니다.

응용 프로그램 구성 요소의 이름 지정 환경은 배포나 조립 중에 응용 프로그램 구성 요소 비즈니스 논리의 사용자 정의를 허용하는 메커니즘입니다. 응용 프로그램 구성 요소 환경을 사용하면 응용 프로그램 구성 요소의 소스 코드를 액세스하거나 변경할 필요 없이 응용 프로그램 구성 요소를 사용자 정의할 수 있습니다.

J2EE 컨테이너는 응용 프로그램 구성 요소의 환경을 구현하며 이러한 환경을 응용 프로그램 구성 요소 인스턴스에 JNDI 이름 지정 컨텍스트로 제공합니다. 응용 프로그램 구성 요소의 환경은 다음과 같이 사용됩니다.

각 응용 프로그램 구성 요소는 고유 환경 항목 집합을 정의합니다. 같은 컨테이너 내의 모든 응용 프로그램 구성 요소 인스턴스는 같은 환경 항목을 공유합니다. 응용 프로그램 구성 요소 인스턴스는 런타임에 환경을 수정할 수 없습니다. 웹 컨테이너 및 EJB 컨테이너 같은 J2EE 컨테이너가 JNDI 이름 지정 서비스를 사용하여 객체를 조회하는 방법에 대한 자세한 내용은 "J2EE 컨테이너 구성"을 참조하십시오.

이름 지정 참조 및 바인딩 정보

자원 참조는 자원에 대한 구성 요소의 코드화된 이름을 식별하는 배포 설명자의 요소입니다. 즉, 코드화된 이름은 자원의 연결 팩토리를 참조합니다. 다음 절의 예에서 자원 참조 이름은 jdbc/SavingsAccountDB입니다.

자원의 JNDI 이름과 자원 참조의 이름은 같지 않습니다. 이 방법으로 이름을 지정하려면 배포 전에 두 이름을 매핑해야 하지만 자원으로부터 구성 요소를 분리하기도 합니다. 이러한 분리 기능으로 인해 나중에 구성 요소가 다른 자원에 액세스해야 하는 경우 코드에서 이름을 변경하지 않아도 됩니다. 또한 이러한 융통성으로 인해 기존의 구성 요소로부터 J2EE 응용 프로그램을 조립하기가 쉽습니다.

다음의 "JNDI 조회 및 관련 참조" 표에서는 Sun ONE Application Server가 사용하는 J2EE 자원에 대한 JNDI 조회 및 관련 참조를 나열합니다.

표 10-1 JNDI 조회 및 관련 참조

JNDI 조회 이름

관련 참조

java:comp/env

응용 프로그램 환경 항목

java:comp/env/jdbc

JDBC 데이터 소스 자원 관리자 연결 팩토리

java:comp/env/ejb

EJB 참조

java:comp/UserTransaction

UserTransaction 참조

java:comp/env/mail

JavaMail 세션 연결 팩토리

java:comp/env/url

URL 연결 팩토리

java:comp/env/jms

JMS 연결 팩토리 및 대상

java:comp/ORB

응용 프로그램 구성 요소 간에 공유되는 ORB 인스턴스

J2EE 표준 배포 설명자의 이름 지정 참조

이름 지정 참조는 주어진 이름 지정 컨텍스트에서 객체를 조회하기 위해 응용 프로그램에서 사용하는 문자열입니다. 각 J2EE 응용 프로그램에 대해 이름 지정 컨텍스트가 있고 표준 구성 요소 배포 설명자에 참조가 구성되어 있습니다. 이 절에서는 Sun ONE Application Server에서 사용하는 표준 배포 설명자에 대해 설명합니다. 이 절에서는 다음 항목에 대해 설명합니다.

응용 프로그램 환경 항목

<env-entry>를 사용하여 정의하는 환경 항목은 J2EE 응용 프로그램에 배포 시간 매개 변수를 지정할 수 있는 방법을 제공합니다. 웹 응용 프로그램의 경우 <context-param>을 사용하여 서블릿 컨텍스트 초기화 매개 변수를 정의할 수 있지만 응용 프로그램 배포자는 응용 프로그램 매개 변수의 이름, 유형 및 값을 명시적으로 지정하여 이러한 매개 변수를 구성하므로 <env-entry>가 선호되는 방법입니다.

다음 예에서는 J2EE 표준 배포 설명자에 지정되어 있는 <env-entry>의 구문을 설명합니다.

<env-entry>
<description> Send pincode by mail </description>
<env-entry-name> mailPincode </env-entry-name>
<env-entry-value> false </env-entry-value>
<env-entry-type> java.lang.Boolean </env-entry-type>
</env-entry>

<env-entry-type> 태그는 항목에 대한 전체 클래스 이름을 지정합니다. 다음은 응용 프로그램 구성 요소(서블릿/JSP, Entity Bean 또는 IIOP 응용 프로그램 클라이언트를 가리키는 용어)에서 JNDI를 사용하여 <env-entry>를 조회할 수 있는 코드 조각입니다.

Context initContext = new InitialContext();
Boolean mailPincode = (Boolean)
initContext.lookup("java:comp/env/mailPincode");

// one could use relative names into the sub-context
Context envContext = initContext.lookup("java:comp/env");
Boolean mailPincode = (Boolean)
envContext.lookup("mailPincode");

EJB 참조

다음 예에서 설명하는 것처럼 배포 설명자 지원 기능과는 별도로 JNDI 이름 지정 서비스는 응용 프로그램에서 논리적 이름(EJB 참조)을 사용하여 Enterprise Bean의 홈 인터페이스에 매핑하게 해줍니다.

<ejb-ref>
<ejb-ref-name> ejb/EmplRecord </ejb-ref-name>
<ejb-ref-type> Entity </ejb-ref-type>
<home> com.wombat.empl.EmployeeRecordHome </home>
<remote> com.wombat.empl.EmployeeRecord </remote>
<ejb-link> EmployeeEJB </ejb-link>
</ejb-ref>

JSP와 같은 응용 프로그램 구성 요소는 다음 예에서 설명하는 것처럼 JNDI를 사용하여 EJB 홈 객체에 액세스할 수 있습니다.

Context initContext = new InitialContext();
Context envContext = initContext.lookup("java:comp/env");
Object result = envContext.lookup("ejb/EmplRecord");
EmployeeRecordHome emplRecordHome = (EmployeeRecordHome)
javax.rmi.PortableRemoteObject.narrow(result, EmployeeRecordHome.class);

ejb-ref-name 요소는 위의 예에서와 같이 응용 프로그램 코드에 사용되는 문자열을 정의합니다. ejb-link 요소는 ejb-jar.xml에서 정의된 Entity Bean의 ejb-name 요소를 사용하여 정의되는 대상 Enterprise Bean에 이러한 참조를 연결합니다. 응용 프로그램 배포 설명자나 Enterprise Bean 설명자 중 하나를 수정하지 않고 연결을 설정할 수 있습니다.

자원 관리자 연결 팩토리에 대한 참조

팩토리는 요청 시 다른 객체를 만드는 객체입니다. 자원 팩토리는 데이터베이스 연결이나 메시지 서비스 연결 같은 자원 객체를 만들며 이러한 객체는 표준 배포 설명자의 <resource-ref> 요소를 사용하여 구성됩니다.

다음 예에서는 팩토리 사용을 설명합니다.

예 A:

javax.sql.DataSource 유형의 객체를 반환하는 JDBC 연결 팩토리에 대한 참조 선언

<resource-ref>
<description> Primary database </description>
<res-ref-name> jdbc/primaryDB </res-ref-name>
<res-type> javax.sql.DataSource </res-type>
<res-auth>Container</res-auth>
</resource-ref>

예 B:

다음은 JavaMail 세션 자원 팩토리를 참조하는 예입니다.

<resource-ref>
<description> mail Session </description>
<res-ref-name> mail/Session </res-ref-name>
<res-type> javax.mail.Session </res-type>
<res-auth>Container</res-auth>
</resource-ref>

<res-type>은 자원 팩토리의 전체 클래스 이름입니다. <res-auth> 변수를 Container나 Application에 값으로 할당할 수 있습니다. JavaMail 세션 자원 팩토리 구성에 대한 자세한 내용은 "JavaMail 자원 정보"를 참조하십시오.

Container가 지정되어 있는 경우 웹 컨테이너는 자원 팩토리를 JNDI 조회 레지스트리에 바인드하기 전에 인증을 처리합니다. Application이 지정되어 있으면 서블릿이 프로그래밍 방식으로 인증을 처리해야 합니다. 다음과 같이 자원 유형을 설명하는 별도의 하위 컨텍스트에서 다양한 자원 팩토리를 조회할 수 있습니다.

다음은 응용 프로그램 구성 요소의 JDBC 연결을 인증을 처리하는 컨테이너와 연결하기 위한 코드 조각입니다.

InitialContext initContext = new InitialContext();
DataSource source =
(DataSource) initContext.lookup("java:comp/env/jdbc/primaryDB");
Connection conn = source.getConnection();

이러한 자원 참조가 제대로 작동하려면 res-ref-name이 런타임에 유효한 자원 팩토리에 매핑되어야 합니다.

자원 환경 참조

자원 환경 참조는 JNDI 조회를 통해 자원과 관련된 관리 대상 객체에 액세스하는 방법을 제공합니다. 예를 들어, 응용 프로그램에서 JMS 대상 객체에 액세스해야 할 경우가 있습니다. 표준 배포 설명자에 정의되어 있는 <resource-env-ref> 요소를 사용하면 응용 프로그램이 자원 요구 사항을 선언할 수 있습니다.

<resource-env-ref>와 <resource-ref> 요소의 주요한 차이점은 특정 자원 인증 요구 사항이 없다는 것입니다. 두 가지 요소 모두 자원 팩토리 설명자가 백업해야 합니다.

예:

<resource-env-ref>
<description> My Topic </description>
<res-env-ref-name> jms/MyTopic </res-ref-name>
<res-env-ref-type> javax.jms.Topic </res-type>
</resource-env-ref>

다음 코드를 사용하면 JMS 항목 객체에 액세스할 수 있습니다.

InitialContext initContext = new InitialContext();
javax.jms.Topic myTopic =
(javax.jms.Topic) initContext.lookup("java:comp/env/jms/MyTopic");

이러한 resource-env-ref 변수가 올바로 작동하려면 관리자가 런타임에 대상 자원 팩토리를 사용할 수 있게 만들어야 합니다. JMS 항목 및 대기열 대상 액세스에 대한 자세한 내용은 11장, "JMS 서비스 사용"을 참조하십시오.

UserTransaction 참조

J2EE는 JNDI 이름 java:comp/UserTransaction에서 컨테이너가 UserTransaction 객체 구현을 제공할 것을 요구합니다. 응용 프로그램은 UserTransaction 객체를 사용하여 트랜잭션을 시작, 완결 및 중단할 수 있습니다.

프로그래밍 방식으로 트랜잭션을 시작하고 수행하기 위해 구성 요소는 java:comp/UserTransaction에 대해 JNDI 조회를 하여 컨테이너의 기본 트랜잭션 조정자에 대한 참조를 얻습니다. 반환된 객체는 javax.transaction.UserTransaction 인터페이스를 구현하며 프로그램에서 트랜잭션의 시작, 완결, 롤백 및 상태 쿼리를 위해 사용할 수 있습니다. Sun ONE Application Server의 JNDI 구현은 이러한 트랜잭션 조정자 조회를 지원합니다. javax.transaction.UserTransaction 인터페이스에 대한 자세한 내용은 "트랜잭션 서비스 사용"을 참조하십시오.

초기 이름 지정 컨텍스트

Sun ONE Application Server에서 지원하는 이름 지정 기능은 기본적으로 J2EE 1.3을 기반으로 하며 몇 가지 향상된 기능이 추가되었습니다. 응용 프로그램 구성 요소가 InitialContext()를 통해 초기 컨텍스트를 만들면 Sun ONE Application Server는 응용 프로그램의 이름 지정 환경에 대한 핸들 역할을 하는 객체를 반환합니다. 그러면 이 객체는 java:comp/env 이름 공간에 대한 하위 컨텍스트를 제공합니다. 각 응용 프로그램은 고유한 이름 공간을 갖습니다. 즉, 각 응용 프로그램별로 java:comp/env 이름 공간이 존재하므로 한 응용 프로그램 이름 공간에 바인딩된 객체는 다른 응용 프로그램에 바인딩된 객체와 충돌하지 않습니다.

COSNaming 서비스

EJB 상호 운용성 프로토콜은 JNDI API를 사용하여 EJB 객체를 조회할 때 COSNaming 프로토콜을 사용할 것을 요구합니다.

CORBA CosNaming 서비스에서 EJBHome 객체 참조를 게시하려면 EJB 컨테이너가 필요합니다. CosNaming 서비스는 정의되어 있는 CosNaming 모듈에서 IDL 인터페이스를 구현해야 하며 클라이언트가 IIOP를 통해 확인 및 목록 작업을 호출할 수 있도록 합니다.

CosNaming 서비스는 루트 NamingContext 객체의 호스트, 포트 및 객체 키를 제공하기 위해 CORBA Interoperable Name Service 사양의 요구 사항을 따라야 합니다. CosNaming 서비스는 광고 호스트, 포트 및 객체 키에서 루트 NamingContext의 IIOP 호출을 처리할 수 있어야 합니다.

클라이언트 컨테이너(즉, EJB, 웹 또는 응용 프로그램 클라이언트 컨테이너)는 표준 CosNaming API를 사용하여 서버의 CosNaming 서비스에 연결하고 EJBHome 객체를 확인하기 위해 Interoperable Name Service 사양에 정의되어 있는 메커니즘을 사용하는 JNDI CosNaming 서비스 공급자를 포함해야 합니다. JNDI CosNaming 서비스 공급자는 JNDI SPI 구조를 사용할 수도 있고 사용하지 않을 수도 있습니다. JNDI CosNaming 서비스 공급자는 다음 URL로부터 객체 참조를 만들어 서버 CosNaming 서비스의 루트 NamingContext에 액세스해야 합니다.

corbaloc:iiop:1.2@<host>:<port>/<objectkey> (여기서 <host>, <port>, <objectkey>는 서버의 CosNaming 서비스 또는 이와 동등한 메커니즘을 사용하여 광고한 루트 NamingContext에 해당하는 값임)

배포 시 클라이언트 컨테이너의 개발자는 서버의 CosNaming 서비스의 호스트, 포트 및 객체 키와 클라이언트 구성 요소 배포 설명자의 각 ejb-ref 요소에 대해 서버의 이름 공간을 검색하는 것과 같은 작업을 수행하여 서버 EJBHome 객체의CosNaming 이름을 얻어야 합니다. JNDI 조회 호출 시 클라이언트 코드에서 사용하는 ejb-ref-name은 EJBHome 객체의 CosNaming 이름에 연결되어야 합니다. 런타임에 클라이언트 구성 요소의 JNDI 조회 호출은 CosNaming 서비스 공급자를 사용합니다. 이 서비스 공급자는 서버의 CosNaming 서비스에 연결하여 CosNaming 이름을 결정한 다음 EJBHome 객체 참조를 클라이언트 구성 요소에 반환합니다.

EJBHome 객체의 이름은 제공된 호스트와 포트에서 액세스할 수 있는 CosNaming 서비스의 이름 공간 내에 있으므로 클라이언트와 서버 컨테이너의 이름 공간을 결합할 필요가 없습니다.

CosNaming 사용의 장점은 비 J2EE CORBA 클라이언트 및 서버와의 상호 운용성을 비롯하여 상호 운용성에 필요한 IIOP 인프라와 더 잘 통합된다는 점입니다. CosNaming은 CORBA 객체만 저장하기 때문에 공급업체는 다른 자원을 저장하는 데 다른 엔터프라이즈 디렉토리 서비스를 사용할 가능성이 높습니다.

Sun ONE Application Server는 J2EE 1.3 사양에 따라 JNDI의 모든 이름 지정 자원을 통합합니다.

CosNaming 공급자    

전역 JNDI 이름 공간(IIOP 응용 프로그램 클라이언트 액세스 가능)을 지원하기 위해 Sun ONE Application Server는 CORBA 참조(원격 EJB 참조) 바인딩을 지원하는 J2EE 기반 CosNaming 공급자를 포함합니다. IIOP 클라이언트에 반환되는 InitialContext는 CosNaming 공급자입니다. Sun ONE Application Server 서버의 인스턴스는 IIOP 클라이언트가 조회하고 바인드하는 Entity Bean을 등록합니다.

Sun ONE Application Server에서는 CosNaming 및 로컬 JNDI 이름 지정 환경에 저장된 객체를 임시적인 것으로 취급합니다. 즉, 서버가 시작될 때와 응용 프로그램이 재로드될 때마다 모든 관련 객체가 이름 공간에 다시 바인드됩니다. CORBA/IIOP 클라이언트 구성 지원에 대한 자세한 내용은 "CORBA/IIOP 클라이언트를 위한 서버 구성"을 참조하십시오.

JNDI 연결 팩토리

J2EE 웹 응용 프로그램의 경우 web.xml 파일의 배포 설명자는 응용 프로그램 환경 항목, 자원 관리자(예: SQL 데이터 소스) 연결 팩토리 또는 EJB에 대한 참조를 정의하기 위한 자리 표시자입니다. 응용 프로그램은 J2EE 컨테이너가 제공하는 JNDI InitialNamingContext를 사용하여 이러한 참조를 조회합니다. 따라서 응용 프로그램의 소스 코드를 액세스하거나 수정하지 않고 배포 설명자만 변경하여 응용 프로그램을 다양한 응용 프로그램 서버 환경에 이식할 수 있습니다. 마찬가지로 J2EE는 Entity Bean (ejb-jar.xml)과 IIOP 응용 프로그램 클라이언트(application-client.xml)의 배포 설명자를 이러한 JNDI 이름 지정 참조를 위한 주요 방법으로 사용합니다.

연결 팩토리는 J2EE 구성 요소가 자원에 액세스할 수 있게 해주는 연결 객체를 만드는 객체입니다. 데이터베이스의 연결 팩토리는 javax.sql.DataSource 객체이며 이 객체는 java.sql.Connection 객체를 만듭니다.

Sun ONE Application Server에서 다음 자원 및 자원 팩토리에 액세스하기 위한 방법을 구성할 수 있습니다.

모든 Sun ONE Application Server 자원 팩토리는 server.xml의 <resources> </resources> 태그 안에 지정되어 있으며 jndi-name 속성을 사용하여 지정한 JNDI 이름을 갖습니다. 이 속성은 서버 차원의 이름 공간에서 팩토리를 등록할 때 사용됩니다. 배포자는 resource-ref-mapping 요소를 사용하여 사용자 지정, 응용 프로그램별 자원 참조 이름(resource-ref 또는 resource-env-ref 요소 내에 선언됨)을 서버 차원의 자원 팩토리에 매핑할 수 있습니다. 따라서 주어진 응용 프로그램에 대해 어떤 JDBC 드라이버 및 기타 자원 팩토리를 사용할지와 관련하여 배포 시간을 결정할 수 있습니다.

사용자 정의 자원은 로컬 JNDI 리포지토리에 액세스하고 외부 자원은 외부 JNDI 리포지토리에 액세스합니다. 두 가지 유형의 자원 모두 사용자 지정 팩토리 클래스 요소, JNDI 이름 속성 등을 필요로 합니다. 이 절에서는 J2EE 자원에 대해 JNDI 연결 팩토리 자원을 구성하는 방법과 이러한 자원을 액세스하는 방법을 설명합니다.

이 절에서는 다음 항목에 대해 설명합니다.

사용자 정의 자원 만들기

server.xml에 정의되어 있는 custom-resource 요소는 사용자 정의 서버 차원의 자원 객체 팩토리를 지정할 수 있는 방법을 제공합니다. 이러한 객체 팩토리는 javax.naming.spi.ObjectFactory 인터페이스를 구현합니다. 이 요소는 JNDI 이름(다른 Sun ONE Application Server 자원 같은 jndi-name 하위 요소를 통해 지정)을 연결하여 서버 차원 이름 공간, 유형, 자원 팩토리 클래스의 이름 및 같은 내용을 인스턴스화하는 데 사용되는 표준 등록 정보 집합에서 사용되도록 합니다.

다음 예에서는 javax.naming.spi.ObjectFactory 인터페이스의 구현을 설명합니다.

<resources> <custom-resource jndi-name="test/myBean"
res-type="test.MyBean"factory-class="test.MyBeanFactory"
enabled="true">

<property name="foo" value="test custom bean prop" />
</custom-resource>
</resources>

자원 참조의 환경 참조와 EJB 참조가 server.xml의 custom-resource와 external-jndi-resource 태그를 사용하여 정의한 구성 서버 차원 자원에 연결되도록 해야 합니다. 응용 프로그램 구성 요소를 동적으로 재배포하는 것은 JNDI 이름 지정 환경과 관련된 문제입니다. Sun ONE Application Server는 응용 프로그램 관련 참조를 모두 해제하고 모든 새로운 참조를 새로 설치한 응용 프로그램의 이름 지정 컨텍스트에 다시 바인드합니다.

관리 인터페이스를 사용하여 사용자 정의 자원을 만들려면 다음을 수행합니다.

  1. 관리 인터페이스의 왼쪽 창에서 JNDI 구성을 수정할 Sun ONE Application Server 인스턴스를 엽니다.
  2. "JNDI" 탭을 열고 "사용자 정의 자원"을 누릅니다. 사용자 정의 자원이 이미 만들어져 있으면 오른쪽 창에 나열됩니다. 새 사용자 정의 자원을 만들려면 "새로 만들기"를 누릅니다. 관리 인터페이스의 오른쪽 창에 "JNDI 사용자 정의 자원 페이지"가 표시됩니다.

그림 10-2 JNDI 사용자 정의 자원 페이지

JNDI 사용자 정의 자원 페이지에 대한 구성 가능한 설정을 보여주는 그림입니다.

  1. 자원을 액세스하는 데 사용할 이름을 "JNDI 이름" 필드에 입력합니다. 이 이름은 JNDI 이름 지정 서비스에 등록됩니다.
  2. 위의 예에서와 같이 "자원 유형" 필드에 전체 유형 정의를 입력합니다. 자원 유형 정의는 xxx.xxx 형식을 따라야 합니다.
  3. 만들고 있는 사용자 정의 자원에 대한 팩토리 클래스 이름을 "팩토리 클래스" 필드에 입력합니다. 팩토리 클래스는 팩토리 클래스에 대한 사용자 지정 이름입니다. 이 클래스는 javax.naming.spi.ObjectFactory 인터페이스를 구현합니다.
  4. 만들고 있는 자원에 대한 설명을 "설명" 필드에 입력합니다. 이 설명은 문자열 값이므로 최대 250자까지 입력할 수 있습니다.
  5. 사용자 정의 자원을 활성화하려면 "사용자 정의 자원 사용" 확인란을 선택합니다.
  6. 사용자 정의 자원을 저장하려면 "확인"을 누릅니다.

외부 JNDI 자원 만들기

관리 인터페이스를 사용하여 외부 자원을 만들려면 다음을 수행합니다.

  1. 관리 인터페이스의 왼쪽 창에서 JNDI 구성을 수정할 Sun ONE Application Server 인스턴스를 엽니다.
  2. JNDI를 열고 "외부 자원"을 선택합니다. 외부 자원이 이미 만들어져 있으면 오른쪽 창에 나열됩니다. 새 외부 자원을 만들려면 "새로 만들기"를 누릅니다.

    3. 관리 인터페이스의 오른쪽 창에 "JNDI 외부 자원 페이지"에 표시된 다음 창이 나타납니다.

그림 10-3 JNDI 외부 자원 페이지

구성 가능한 JNDI 외부 자원 옵션을 보여주는 그림입니다.

  1. 자원을 액세스하는 데 사용할 이름을 "JNDI 이름" 필드에 입력합니다. 이 이름은 JNDI 이름 지정 서비스에 등록됩니다.
  2. 위의 예에서와 같이 "자원 유형" 필드에 전체 유형 정의를 입력합니다. 자원 유형 정의는 xxx.xxx 형식을 따라야 합니다.
  3. 외부 리포지토리에서 조회할 JNDI 값을 "JNDI 조회" 필드에 입력합니다. 예를 들어, Bean 클래스를 테스트하기 위해 외부 자원을 만들어 외부 리포지토리에 연결하는 경우 JNDI 조회는 cn=testmybean을 읽을 수 있습니다.
  4. com.sun.jndi.ldap와 같은 JNDI 팩토리 클래스 외부 리포지토리를 "팩토리 클래스" 필드에 입력합니다. 이 클래스는 javax.naming.spi.ObjectFactory 인터페이스를 구현합니다.
  5. 만들고 있는 자원에 대한 설명을 "설명" 필드에 입력합니다. 이 설명은 문자열 값이므로 최대 250자까지 입력할 수 있습니다.
  6. 외부 자원을 활성화하려면 "외부 자원 사용" 확인란을 선택합니다.
  7. 사용자 정의 자원을 저장하려면 "확인"을 누릅니다.

외부 JNDI 리포지토리 액세스

Sun ONE Application Server에서 실행되는 응용 프로그램의 경우 외부 JNDI 리포지토리에 저장된 자원에 액세스해야 하는 경우가 있습니다. 예를 들어, LDAP 서버에 일반 Java 객체를 Java 스키마별로 저장할 수 있습니다. 사용자는 외부 JNDI 자원 요소를 사용하여 이러한 외부 자원 리포지토리를 구성할 수 있습니다. 외부 JNDI 팩토리는 javax.naming.spi.InitialContextFactory 인터페이스를 구현해야 합니다.

예:

<resources>
<!-- external-jndi-resource element specifies how to access J2EE resources
-- stored in an external JNDI repository. The following example
-- illustrates how to access a java object stored in LDAP.
-- factory-class element specifies the JNDI InitialContext factory that
-- needs to be used to access the resource factory. property element
-- corresponds to the environment applicable to the external JNDI context
-- and jndi-lookup-name refers to the JNDI name to lookup to fetch the
-- designated (in this case the java) object.
-->
<external-jndi-resource jndi-name="test/myBean"
jndi-lookup-name="cn=myBean"
res-type="test.myBean"
factory-class="com.sun.jndi.ldap.LdapCtxFactory">

<property name="PROVIDER-URL" value="ldap://ldapserver:389/o=myObjects" />
<property name="SECURITY_AUTHENTICATION" value="simple" />
<property name="SECURITY_PRINCIPAL", value="cn=joeSmith, o=Engineering" />
<property name="SECURITY_CREDENTIALS" value="changeit" />
</external-jndi-resource>
</resources>

응용 프로그램 자원 참조 매핑

응용 프로그램 관련 자원 참조는 미리 정의된 서버 차원 자원 팩토리에 매핑해야 합니다. 이때 Sun ONE Application Server 관련 자원 참조 매핑 요소를 사용할 수 있습니다.

다음 예에서는 자원 참조가 JDBC 데이터 소스에 지정되어 있는 웹 응용 프로그램의 배포 설명자인 web.xml을 살펴볼 것입니다.

<resource-ref>
<res-ref-name> jdbc/EstoreDataSource </res-ref-name>
<res-type> javax.sql.DataSource </res-type>
<res-auth>Container</res-auth>
</resource-ref>

원하는 res-ref-name을 다음과 같이 컨테이너 차원 Orcale JDBC 연결 자원 팩토리에 매핑할 수도 있습니다.

<resource-ref>
<res-ref-name> jdbc/EstoreDataSource </resource-ref-name>
<jndi-name> jdbc/estore/InventoryDB </jndi-name>
</resource-ref>

URL 연결 팩토리 자원 정보

URL 연결 팩토리의 경우 server.xml에 정의되어 있는 자원이 필요하지 않습니다. 해당 Sun ONE Application Server 응용 프로그램(웹 또는 ejb) 배포 설명자의 jndi-name 요소가 대상 URL을 지정합니다.

예를 들어, 웹 응용 프로그램의 배포 설명자 web.xml이 java.net.URL 자원 참조를 지정하고 sun-web.xml에 있는 URL http://www.sun.com/index.html에 매핑된다고 가정합니다.

매핑은 다음과 같을 것입니다.

<resource-ref>
<res-ref-name>myURL</res-ref-name>
<res-type>java.net.URL</res-type>
<res-auth>Container</res-auth>
</resource-ref>

<sun-web-app>
<resource-ref>
<res-ref-name>myURL</res-ref-name>
<jndi-name> http://www.sun.com/index.html </jndi-name>
</resource-ref>
</sun-web-app>

응용 프로그램 자원 환경 참조 매핑

응용 프로그램 관련 자원 환경 참조 선언은 응용 프로그램 서버의 런타임 환경에서 사용 가능한 대상 자원 객체에 매핑되어야 합니다. Sun ONE Application Server 관련 구성 파일에 정의되어 있는 자원 환경 매핑 요소를 사용하여 배포자는 다음과 같이 매핑할 수 있습니다.

예:

<resource-env-ref>
<description> My Topic </description>
<res-env-ref-name> jms/MyTopic </res-ref-name>
<res-env-ref-type> javax.jms.Topic </res-type>
</resource-env-ref>

이 참조는 server.xml에 정의되어 있는 jms/iMQ/Topics/Stocks/SUNW 항목에 매핑됩니다. 자세한 내용은 Sun ONE Application Server Administrator’s Configuration File Reference를 참조하십시오.

<resource-env-ref-mapping>
<res-env-ref-name> jms/MyTopic </res-ref-name>
<jndi-name> jms/iMQ/Topics/Stocks/SUNW </jndi-name>
</resource-env-ref-mapping>

EJB 참조 매핑

대상 Enterprise Bean에 사용된 ejb-name에서 응용 프로그램 코드에 사용된 실제 ejb-name을 분리할 수도 있습니다. 웹 응용 프로그램 배포 설명자, web.xml을 수정하지 않고 Enterprise Bean 배포 설명자의 ejb-name을 사용하려고 할 때 이 방법이 특히 유용합니다. Sun ONE Application Server 관련 구성을 사용하면 Sun ONE Application Server 관련 배포 설명자의 ejb-ref-mapping 요소를 사용하지 않고 ejb-ref-name 요소를 대상 Bean의 ejb-name에 매핑할 수 있습니다.

예:

<ejb-ref>
<ejb-ref-name> ejb/EmplRecord </ejb-ref-name>
<ejb-ref-type> Entity </ejb-ref-type>
<home> com.wombat.empl.EmployeeRecordHome </home>
<remote> com.wombat.empl.EmployeeRecord </remote>
</ejb-ref>

<ejb-ref>
<ejb-ref-name> ejb/EmplRecord </ejb-ref-name>
<jndi-name> AccountEJB </jndi-name>
</ejb-ref-mapping>

지속성 관리자 자원 정보

이 모듈에서는 지속성에 대해 설명하고 Sun ONE Application Server에서 지원하는 플러그형 지속성 관리자 사용을 위한 프레임워크를 설정합니다.

이 모듈에서는 다음 내용을 설명합니다.

지속성이란?

대부분의 비즈니스 응용 프로그램의 주요 측면은 지속성 데이터(응용 프로그램의 외부에 저장되어 있는 오래된 데이터)를 프로그래밍 방식으로 조작하는 것입니다. 지속성 데이터를 사용하거나 수정하려고 할 때는 임시 메모리로 읽어들이지만 오랫 동안 저장하기 위해서는 관계형 데이터베이스나 플랫 파일 시스템에 기록합니다.

객체 지향 프로그래밍 시스템에서 지속성 데이터는 응용 프로그램 코드에 의해 조작되는 하나 이상의 데이터 객체로 메모리에 표현됩니다. 일반적으로 데이터 저장소의 지속성 데이터와 메모리에 표현된 지속성 데이터 객체 간의 대응은 다음의 "기본 지속성 체계" 그림에 표시된 대로 많은 소프트웨어 계층을 통해 이루어집니다.

그림 10-4 기본 지속성 체계

메모리에 표현된 지속성 데이터에 사용되는 기본 지속성 체계를 보여주는 그림입니다.

각 데이터 저장소에는 데이터 저장소와 응용 프로그램 간의 연결을 설정하고 유지하는 데 사용되는 드라이버 소프트웨어를 통해 외부 영역과 연결되는 인터페이스가 있습니다. 이 연결이 설정되면 질의어를 사용하여 데이터 저장소로부터 정보를 검색하여 응용 프로그램으로 읽어들이거나 반대로 응용 프로그램에서 데이터 저장소로 데이터를 기록할 수 있습니다. 다른 계층은 메모리의 데이터 객체와 데이터 저장소의 정보 간의 매핑을 제공합니다.

이러한 일반 체계를 통해 프로그래머는 지속성 데이터를 응용 프로그램에서 사용하고 조작할 수 있는 런타임 객체로 표현할 수 있습니다. 이러한 체계는 CRUD로 축약되기도 하는 모든 기본 지속성 작업을 지원합니다.

지속성 관리자의 역할

지속성 관리자(PM)는 EJB 컨테이너에서 컨테이너 관리 지속성과 함께 Entity Bean의 지속성을 관리합니다. Entity Bean 공급자는 Entity Bean 클래스를 추상 클래스로 제공해야 합니다. 지속성 관리자 공급자의 도구를 통해 이를 구체적으로 구현해야 합니다. 이러한 작업을 수행하려면 추상 Entity Bean과 관련 클래스를 하위 클래스로 나눈 다음 이를 구체적으로 구현하거나 캡슐화와 위임을 사용해야 합니다.

지속성 관리자 도구가 제공하는 클래스는 Entity Bean 사이의 관계를 관리하고 지속성 상태에 대한 액세스를 관리할 책임이 있습니다. PM 도구는 컨테이너 관리 지속성(CMR)을 유지하는 데 사용되는 java.util.Collection 클래스 구현을 제공할 책임도 있습니다.

사전 배포 Bean 구성

Enterprise Java Bean 표준은 Entity Bean에 대한 두 가지 지속성, 컨테이너 관리 지속성(CMP)과 Bean 관리 지속성(BMP)을 제공합니다. EJB 2.0 사양은 EJB 서버와 지속성 관리자 사이의 표준 API를 정의하지 않습니다.

이 절에서는 배포 및 코드 생성 시의 통합 요구 사항을 설명합니다. 배포라는 용어는 여러 의미로 사용될 수 있습니다. 일반적으로 배포 과정은 구성, 코드 작성 및 설치의 세 단계로 이루어집니다.

사용된 지속성 메커니즘, 지속성 공급업체, 사용 중인 버전, 지속성 메커니즘에 필요한 추가 정보 등을 비롯하여 Bean에 대해 많은 등록 정보를 지정해야 합니다. 대부분의 지속성 공급업체는 모든 관련 Bean과 그 종속 클래스를 단일 단위로 배포할 수 있는 프로젝트의 개념을 갖고 있습니다. 프로젝트별로 공급업체 관련 xml 파일이 있을 수 있습니다.

배포 목적으로 지원되는 세 가지 표준 파일에는 ejb-jar.xml, sun-ejb-jar.xml 및 sun-cmp-mappings.xml이 포함됩니다. sun-ejb-jar.xml에 CMP Bean과 함께 있는 각 EJB 모듈에는 다섯 개 이상의 속성을 지정하는 한 개 이상의 <pm-descriptor> 요소와 함께 <pm-descriptors>가 있어야 합니다. 이러한 다섯 가지 속성은 pm-identifier, pm-version, pm-config, pm-class-generator, pm-mapping-factory입니다.

Sun ONE Application Server 관련 설명자(sunEjb_jar_2_0.DTD에서와 마찬가지)는 지속성 관리자 관련 태그를 정의합니다. 샘플 CMP 설명자는 Sun ONE Application Server DTD에 정의된 것처럼 아래와 비슷할 것입니다.

PM descriptors contain one or more pm descriptors, but only of them must be in use at any given time

<!ELEMENT pm-descriptors ( pm-descriptor+, pm-inuse)>

<!--

pm-descriptor describes the properties for the persistence manager

associated with entity bean

-->

<!ELEMENT pm-descriptor ( pm-identifier, pm-version, pm-config?, pm-class-generator?,

pm-mapping-factory?)>

<!--

이 요소는 PM 구현을 제공한 공급업체를 설명합니다. 예를 들면 Sun ONE Application Server Transparent Persistence, TopLink, Versant 또는 CocoBase일 수 있습니다.

-->

<!ELEMENT pm-identifier (#PCDATA)>

<!--

pm-version further specifies which version of PM vendor product to be used

-->

<!ELEMENT pm-version (#PCDATA)>

<!--

pm-config specifies the vendor specific config file to be used

-->

<!ELEMENT pm-config (#PCDATA)>

<!--

pm-class-generator specifies the vendor specific concrete class generator

This is the name of the class specific to a vendor:

-->

<!ELEMENT pm-class-generator (#PCDATA)>

<!--

pm-mapping-factory specifies the vendor specific mapping factory

This is the name of the class specific to a vendor:

-->

<!ELEMENT pm-mapping-factory (#PCDATA)>

새 지속성 관리자 만들기

관리 인터페이스를 사용하여 새 지속성 관리자 인스턴스를 만들 수 있습니다. 새 지속성 관리자 인스턴스를 만들려면 다음을 수행합니다.

  1. 관리 인터페이스의 왼쪽 창에서 새 지속성 관리자를 만들 Sun ONE Application Server 인스턴스를 엽니다. 표시된 서버 구성 요소 목록에서 "지속성 관리자"를 누릅니다.

    2. Sun ONE Application Server의 해당 인스턴스에 대해 지속성 관리자가 만들어져 있으면 관리 인터페이스의 오른쪽 창에 목록이 표시될 것입니다.

  2. 새 지속성 관리자를 만들려면 "새로 만들기"를 누릅니다. "새 지속성 관리자 만들기" 그림에 표시된 다음 창이 표시될 것입니다.

그림 10-5

새 지속성 관리자를 만드는 방법을 보여주는 그림입니다.

새 지속성 관리자 만들기

  1. 응용 프로그램을 대신하여 특정 지속성 관리자를 찾기 위해 응용 프로그램 서버가 런타임에 사용하는 JNDI 이름입니다. 이 이름은 Sun 관련 배포 설명자의 Entity Bean cmp 자원 요소에 정의된 것과 같아야 합니다.
  2. "설명" 필드에 새 지속성 관리자에 대한 설명을 입력합니다. 이 필드의 값은 문자열이므로 250자까지 입력할 수 있습니다.
  3. 지속성 관리자의 팩토리 클래스 연결을 "팩토리 클래스" 필드에 입력합니다. setEntityContext는 JNDI 이름 조회를 통해 이 연결 팩토리를 조회합니다. 팩토리 클래스 이름은 지속성 관리자 인스턴스를 만드는 지속성 관리자 팩토리의 클래스 이름입니다. 기본적으로 이 이름은 Sun ONE Application Server의 내부 지속성 관리자 팩토리 클래스로 설정됩니다. 대체 구현을 사용하는 경우 이 클래스를 서버 클래스 경로에서 사용할 수 있도록 해야 합니다.
  4. "연결 풀" 드롭다운 목록에서 새 지속성 관리자를 풀링할 데이터베이스 연결 풀을 선택합니다. 연결 풀링을 사용하면 Entity Bean은 단일 연결을 요청하고 이를 사용하여 여러 클라이언트 스레드에 대해 명령문을 동시에 실행할 수 있습니다. 다른 데이터베이스 액세스와 마찬가지로 지속성 관리자는 연결 풀링을 사용하여 성능 및 확장성을 향상시킵니다. 기존 연결 풀을 선택하거나, 아직 만들어진 풀이 없는 경우 "선택된 대상이 없습니다."를 선택합니다.

    5. 주: JDBC 자원이 자동으로 만들어져 PM 런타임이 JNDI를 사용하여 연결 풀에 바인드하게 해줍니다. JDBC 자원의 JNDI 이름은 "PM"이란 접두어를 갖는 PM JNDI 이름과 같을 것입니다. 지속성 관리자를 삭제하면 관련 JDBC 자원도 삭제됩니다.

  5. 지속성 관리자를 활성화하려면 "지속성 관리자 사용 가능" 확인란을 선택합니다. 이제 지정된 연결 팩토리에 대해 지속성 관리자가 활성화됩니다.
  6. 변경 사항을 저장하려면 "확인"을 누릅니다.

JDBC 자원 정보

이 모듈에서는 일반적인 JDBC API, JDBC 자원 및 구현과 Sun ONE Application Server에서의 사용에 대해 구체적으로 설명합니다.

이 모듈은 다음 절로 구성되어 있습니다.

JDBC API 정보

JDBC API는 실제로 모든 유형의 테이블 형식 데이터에 액세스하기 위한 Java API입니다. 흥미롭게도 JDBC는 머리 글자어가 아닌 상표 이름입니다. 그럼에도 불구하고 JDBC를 "Java Database Connectivity"의 약어로 생각하는 경우가 종종 있습니다. JDBC API는 도구/데이터베이스 개발자를 위한 표준 API를 제공하고 모든 Java API를 사용하여 데이터베이스 응용 프로그램을 작성할 수 있게 해주는 Java 프로그래밍 언어로 작성된 일련의 클래스와 인터페이스로 구성됩니다.

JDBC API는 관계형 데이터베이스 시스템으로 SQL 문을 쉽게 보낼 수 있게 해주며 SQL의 모든 언어를 지원합니다. 하지만 JDBC 3.0 API는 SQL 이상을 포함하므로 데이터베이스 외부의 파일을 비롯한 다른 종류의 데이터 소스와도 상호 작용할 수 있게 해줍니다.

JDBC API의 이점은 응용 프로그램이 실제로 모든 데이터 소스에 액세스하며 Java 가상 시스템을 사용하는 모든 플랫폼에서 실행될 수 있다는 것입니다. 즉, JDBC API를 사용하면 Sybase 데이터베이스, Oracle 데이터베이스, IBM DB2 데이터베이스 각각을 액세스하기 위해 별도의 프로그램을 작성할 필요가 없다는 것입니다. JDBC API를 사용하여 단일 프로그램을 작성하면 이 프로그램에서 SQL이나 기타 명령문을 적절한 데이터 소스로 보낼 수 있습니다. 또한 Java 프로그래밍 언어로 작성된 응용 프로그램을 사용하면 여러 플랫폼에서 실행하기 위해 여러 응용 프로그램을 작성할 필요가 없습니다. 프로그래머는 Java 플랫폼과 JDBC API를 조합하여 코드를 한 번만 작성해 놓으면 어느 플랫폼에서나 이 코드를 실행할 수 있습니다.

JDBC API를 사용한 작업

JDBC 기술 기반 드라이버(JDBC 드라이버)를 사용하면 다음 세 가지 작업을 할 수 있습니다.

다음 코드 단편은 이러한 세 단계에 대한 간단한 예를 제공합니다.

Context ctx = new InitialContext();

DataSource ds = (DataSource)ctx.lookup("jdbc/AcmeDB");

Connection con = ds.getConnection("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");

 }

데이터베이스 액세스 모델 정보

JDBC API는 데이터베이스 액세스를 위해 2계층과 3계층 모델을 모두 지원합니다. Sun ONE Application Server는 좀 더 일반적인 2계층 데이터베이스 액세스 모델을 통합합니다.

이 절에서는 다음 항목에 대해 설명합니다.

2계층 데이터베이스 액세스 모델

2계층 데이터베이스 액세스 모델에서 Java 애플릿이나 응용 프로그램은 DBMS 소유 프로토콜을 사용하여 데이터 소스와 직접 통신합니다. 이 액세스 모델에는 액세스할 특정 데이터 소스와 통신할 수 있는 JDBC 드라이버가 필요합니다. 사용자의 명령은 데이터베이스나 다른 데이터 소스로 전달되며 이러한 문의 결과는 다시 사용자에게 보내집니다. 데이터 소스는 네트워크를 통해 연결된 다른 시스템에 있을 수도 있습니다. 이러한 구성을 클라이언트/서버 구성이라고 하며 사용자 컴퓨터는 클라이언트로, 데이터 소스를 관리하는 컴퓨터는 서버의 역할을 합니다. 네트워크는 기업 내에서 직원을 연결하는 인트라넷이 되거나 인터넷이 될 수 있습니다.

3계층 데이터베이스 액세스 모델

3계층 데이터베이스 액세스 모델에서 Java 애플릿이나 응용 프로그램은 서비스의 "중간 계층"으로 명령을 보내고 이 중간 계층은 데이터 소스로 명령을 보냅니다. 클라이언트 응용 프로그램은 HTTP, RM, CORBA 또는 기타 호출을 통해 중간 계층과 통신합니다. 중간 계층은 DBMS 소유 프로토콜을 통해 데이터 저장소와 통신합니다. 데이터 소스는 명령을 처리하여 결과를 다시 중간 계층에 보내고 중간 계층은 결과를 사용자에게 다시 보냅니다. MIS 담당자는 중간 계층을 사용하여 기업 데이터에 대한 여러 가지 업데이트 및 액세스를 제어할 수 있으므로 3계층 모델을 선호할 것입니다. 그밖의 장점으로는 응용 프로그램 배포 과정이 단순화된다는 것입니다. 마지막으로 3계층 구조는 성능상의 이점을 제공합니다.

JDBC 데이터 소스 정보

DataSource 객체는 데이터 소스를 Java 프로그래밍 언어로 나타낸 것입니다. 기본적으로 데이터 소스는 데이터를 저장하기 위한 기능을 의미합니다. 데이터 소스는 대기업의 복잡한 데이터베이스처럼 복잡할 수도 있고 행과 열로 구성된 파일처럼 간단할 수도 있습니다. 데이터 소스는 원격 서버에 있을 수도 있고 로컬 데스크탑 컴퓨터에 있을 수도 있습니다. 응용 프로그램은 연결을 사용하여 데이터 소스에 액세스하므로 DataSource 객체는 DataSource 인스턴스가 나타내는 특정 데이터 소스 연결을 위한 팩토리로 생각할 수 있습니다. 데이터 소스 인터페이스는 데이터 소스와 연결을 설정하기 위한 두 가지 방법을 제공합니다.

DataSource 객체에는 자신이 나타내는 데이터 소스를 식별하고 설명하는 등록 정보가 있습니다. 또한 DataSource 객체는 JNDI 이름 지정 서비스와 함께 작동하며 해당 객체를 사용하는 응용 프로그램과는 별도로 만들어지고 배포되며 관리됩니다. 드라이버 공급업체는 DataSource 인터페이스의 기본 구현인 클래스를 JDBC 2.0 또는 3.0 드라이버 제품의 일부로 제공합니다.

이 절에서는 다음 항목에 대해 설명합니다.

데이터 소스 객체의 등록 정보

DataSource 객체에는 자신이 나타내는 실제 데이터 소스를 식별하고 설명하는 등록 정보가 있습니다. 이러한 등록 정보에는 데이터베이스 서버 위치, 데이터베이스 이름, 서버와 통신하는 데 사용되는 네트워크 프로토콜 등의 정보가 포함됩니다. DataSource 등록 정보는 JavaBeans 디자인 패턴을 따르며 대개 DataSource 객체가 배포될 때 설정됩니다.

여러 공급업체의 DataSource 구현 간에 일관성을 유지하기 위해 JDBC 2.0 API는 표준 등록 정보 집합과 각 등록 정보에 대한 표준 이름을 지정합니다.

DataSource 인터페이스를 구현하는 클래스의 인스턴스는 한 개의 특정 데이터 소스를 나타냅니다. 해당 인스턴스에 의해 설정되는 각 연결은 같은 데이터 소스를 참조합니다. 기본 DataSource 구현 시 DataSource.getConnection 메소드를 호출하면 DriverManager 기능에서 반환하는 연결 객체와 같은, 데이터 소스에 대한 물리적 연결 객체를 반환합니다.

JNDI는 응용 프로그램이 네트워크를 통해 원격 서비스를 찾아 액세스할 수 있는 일관된 방법을 제공합니다. 원격 서비스에는 메시징 서비스나 응용 프로그램 서비스를 비롯한 모든 엔터프라이즈 서비스가 포함되지만 JDBC 응용 프로그램은 주로 데이터베이스 서비스만 처리합니다. DataSource 객체를 만들어 JNDI 이름 지정 서비스에 등록하면 응용 프로그램은 JNDI API를 사용하여 해당 DataSource 객체에 액세스할 수 있습니다. 이 데이터 소스 객체는 자신이 나타내는 데이터 소스에 연결하는 데 사용될 수 있습니다.

마찬가지로 연결 풀링을 구현하는 DataSource 객체는 DataSource 클래스가 나타내는 특정 데이터 소스에 대한 연결을 생성합니다. 하지만 DataSource.getConnection 메소드가 반환하는 연결 객체는 물리적 연결이 아닌 PooledConnection 객체에 대한 핸들입니다. 응용 프로그램은 평소대로 연결 객체를 사용하며 일반적으로 이 연결 객체가 어떠한 방식으로건 달라졌다는 점을 인식하지 못합니다. 연결 풀링은 모든 연결과 마찬가지로 풀링된 연결이 항상 명시적으로 닫혀 있어야 한다는 점을 예외로 하면 응용 프로그램 코드에 전혀 영향을 미치지 않습니다. 응용 프로그램이 풀링된 연결을 닫으면 해당 연결은 재사용 가능한 연결 풀로 돌아갑니다. 다음에 DataSource.getConnection을 호출하면 이 풀링된 연결 중 하나가 사용 가능한 경우 이에 대한 핸들이 반환됩니다. 연결 풀링을 사용하면 연결이 요청될 때마다 물리적 연결을 새로 만들지 않아도 되므로 응용 프로그램을 훨씬 더 빠르게 실행할 수 있습니다.

분산 트랜잭션 환경에서 작동하도록 DataSource 클래스를 구현할 수 있습니다. 예를 들어, EJB 서버는 분산 트랜잭션을 지원하고 자신과 상호 작용하도록 구현되는 DataSource 클래스를 필요로 합니다. 이 경우 DataSource.getConnection 메소드는 분산 트랜잭션에서 사용할 수 있는 연결 객체를 반환합니다. 일반적으로 EJB 서버는 분산 트랜잭션과 연결 풀링에 대한 지원 기능을 제공합니다. 연결 풀링과 마찬가지로 트랜잭션 관리도 내부적으로 처리되므로 분산 트랜잭션을 사용하기 쉽습니다. 트랜잭션을 분산하는 경우(두 개 이상의 데이터 소스와 관련되는 경우) 응용 프로그램에서 commit이나 rollback 같은 트랜잭션 메소드를 호출할 수 없다는 점이 유일한 제한 사항입니다. 또한 연결을 auto-commit 모드에 둘 수도 없습니다. 이렇게 제한을 두는 이유는 트랜잭션 관리자가 분산 트랜잭션을 모르게 시작하고 끝내기 때문에 트랜잭션이 시작하거나 끝나는 시간에 영향을 미치는 작업을 응용 프로그램에서 할 수 없게 됩니다. Java 트랜잭션에 대한 자세한 내용은 9장, "트랜잭션 서비스 사용"을 참조하십시오.

JDBC 자원 등록

Sun ONE Application Server 또는 명령줄 인터페이스를 사용하여 JDBC 자원을 관리 인터페이스에 등록할 수 있습니다.

이 절에서는 다음 항목에 대해 설명합니다.

명령줄을 사용하여 자원 등록

명령줄 인터페이스를 사용하여 JDBC 자원을 등록하려면 다음 명령을 실행합니다.

./asadmin create-jdbc-resource

JDBC 자원을 등록하려면 XML 코드 단편에서 아래(sun-server_7_0.dtd에서 발췌)와 같이 몇 가지 속성을 지정해야 합니다.

<!-- JDBC javax.sql.DataSource resource definition -->

<!ELEMENT jdbc-resource (description?, property*)>

<!ATTLIST jdbc-resource jndi-name CDATA #REQUIRED

pool-name CDATA #REQUIRED

enabled %boolean; 'true'>

여기에서 지정하는 모든 내용은 응용 프로그램이 J2EE 응용 프로그램 내부에서 이 데이터 소스를 참조할 때 사용하는 심볼릭 이름입니다. pool-name 속성은 데이터베이스 연결의 모든 측면을 지정하는, 이름이 지정된 풀 정의를 가리킵니다. 관리자는 활성 속성을 사용하여 일부 자원을 해제할 수 있습니다.

관리 인터페이스를 사용하여 자원 등록

관리 인터페이스를 사용하여 데이터 소스를 등록하려면 다음 작업을 수행합니다.

  1. 관리 인터페이스의 왼쪽 창에서 JDBC 자원을 등록할 Sun ONE Application Server 인스턴스를 엽니다.
  2. JDBC를 엽니다.
  3. JDBC에서 "JDBC 자원"을 누릅니다.
  4. 오른쪽 창에서 "새로 만들기"를 누릅니다. "새 JDBC 자원 만들기" 그림에 표시된 것과 같이 새 JDBC 자원을 만들 수 있는 페이지가 오른쪽 창에 표시됩니다.

그림 10-6 새 JDBC 자원 만들기

새 JDBC 자원을 만들 수 있는 관리 인터페이스의 창을 보여주는 그림입니다.

  1. 만들고 있는 자원에 대한 JNDI 이름을 입력합니다.

    2. JDBC 자원은 JNDI 리포지토리에 저장되며 JNDI 이름을 사용하여 액세스합니다. JNDI 이름의 루트는 Java:comp:env/에 명시되어 있기 때문에 이름의 해당 부분을 지정할 필요가 없습니다. JDBC 자원(데이터 소스)은 'jdbc' 하위 컨텍스트에 저장하는 것이 좋으므로 JNDI 이름은 jdbc/EmployeeDB_DS와 비슷할 것입니다.

  2. "풀 이름' 드롭다운 목록의 풀 이름 목록에서 새 데이터 소스에 대한 풀 이름을 선택합니다. 등록된 모든 연결 풀이 이 드롭다운 목록에 표시됩니다. 선택한 풀 이름은 데이터베이스 연결의 모든 측면을 지정하는, 이름이 지정된 풀 정의를 가리킵니다. 두 개 이상의 JDBC 자원이 하나의 풀 정의를 사용할 수 있습니다. JDBC 연결 풀 구성 방법에 대한 자세한 내용은 "관리 인터페이스를 사용하여 새 JDBC 연결 풀 만들기"를 참조하십시오.
  3. 데이터 소스의 용도를 설명하는 간단한 설명을 "설명" 필드에 입력합니다. 설명은 250자를 초과할 수 없습니다.
  4. "사용 가능" 확인란을 선택하여 데이터 소스를 활성화하거나 비활성화합니다. 데이터 소스가 활성화되어 있지 않으면 데이터베이스를 연결할 때 데이터 소스를 사용할 수 없습니다.
  5. "확인"을 눌러 새 데이터 소스를 등록하거나 "취소"를 눌러 새 데이터 소스를 취소합니다. "취소"를 누르면 새 데이터 소스를 다시 만들 수 있는 주 "JDBC 자원" 페이지로 돌아갑니다.

JDBC 연결 정보

연결 객체는 데이터베이스와의 연결을 나타냅니다. 연결 세션에는 실행된 SQL 문과 연결을 통해 반환되는 결과가 포함됩니다. 단일 응용 프로그램은 단일 데이터베이스와 한 개 이상의 연결을 가질 수 있거나 많은 데이터베이스와 연결을 가질 수 있습니다.

사용자는 Connection.getMetaData 메소드를 호출하여 연결 객체의 데이터베이스에 대한 정보를 얻을 수 있습니다. 이 메소드는 데이터베이스 테이블, 지원하는 SQL 문법, 저장 프로시저, 이러한 연결의 기능 등의 정보가 있는 DatabaseMetaData 객체를 반환합니다.

응용 프로그램은 데이터 소스 객체가 만든 연결 객체를 사용합니다. 예외가 발생하더라도 연결을 확실히 닫을 수 있도록 응용 프로그램은 항상 "finally" 블록을 포함해야 합니다. 이는 유효한 연결이 사용 가능한 연결 풀에 항상 다시 반환되도록 하므로 연결 객체가 풀링된 연결인 경우 특히 중요합니다. 다음 코드 단편은 연결이 유효한 경우 연결을 닫는 finally 블록의 예이며 여기서 con은 연결 객체입니다.

finally{

if (con != null) con.close();

}

다음 예에서와 같이 finally 블록은 try/catch 블록 다음에 표시되며 여기서 ds는 데이터 소스 객체입니다.

try {

Connection con = ds.getConnection("user", "secret");

// . . . code to do the application's work

} catch {

// . . . code to handle an SQLException

} finally {

if (con != null) con.close();

}

이 절에서는 다음 항목에 대해 설명합니다.

JDBC URL 정보

URL (Uniform Resource Locator)은 인터넷에서 자원을 찾는 데 필요한 정보를 제공합니다. URL은 인터넷상의 주소라고 할 수 있습니다.

JDBC URL은 적절한 드라이버가 데이터 소스를 인식하여 데이터 소스와의 연결을 설정할 수 있도록 데이터 소스를 식별하는 방법을 제공합니다. 특정 드라이버를 식별하는 JDBC URL을 실제로 결정하는 사람은 드라이버 작성자입니다. 사용자는 JDBC URL 구성 방법을 신경 쓸 필요가 없고 사용하고 있는 드라이버에서 제공하는 URL을 사용하기만 하면 됩니다. JDBC의 역할은 드라이버 작성자가 JDBC URL을 구성할 때 따라야 할 몇 가지 규칙을 권장하는 것입니다.

JDBC URL은 다양한 드라이버와 함께 사용되기 때문에 규칙도 매유 유연해야 합니다. 먼저, JDBC URL은 다양한 드라이버가 데이터베이스 이름을 지정할 때 다양한 체계를 사용하는 것을 허용합니다. 예를 들어, ODBC 하위 프로토콜은 URL이 속성 값을 갖는 것을 허용합니다. 하지만 속성 값을 요구하지는 않습니다.

두 번째로, JDBC URL은 드라이버 작성자가 JDBC URL 안에 필요한 모든 연결 정보를 인코딩할 수 있도록 허용합니다. 따라서 사용자가 시스템 관리 작업을 하지 않더라도 주어진 데이터베이스와 통신하려는 애플릿이 데이터베이스 연결을 열 수 있습니다.

세 번째로, JDBC URL은 주소 간접도를 허용합니다. 이는 JDBC URL이 네트워크 이름 지정 시스템에 의해 실제 이름으로 동적 변환되는 로컬 호스트나 데이터베이스 이름을 참조할 것임을 의미합니다. 따라서 시스템 관리자는 특정 호스트를 JDBC 이름의 일부로 지정하지 않아도 됩니다. 다양한 네트워크 이름 서비스가 많이 있으며 사용할 수 있는 서비스에 대한 제한은 없습니다.

JDBC URL의 표준 구문은 다음과 같습니다. 세 부분으로 되어 있으며 콜론으로 구분합니다.

jdbc:<subprotocol>:<subname>

JDBC URL의 세 부분은 다음과 같이 구성됩니다.

JDBC 연결 풀 구성

Sun ONE Application Server에서 사용자는 이름이 지정된 JDBC 연결 풀을 만들 수 있습니다. JDBC 연결 풀은 연결 풀을 만드는 데 사용되는 등록 정보를 정의합니다. 풀 정의의 이름이 지정되며 여러 JDBC 자원을 구성하기 위해 정의를 다시 사용할 수 있습니다. 이름이 지정된 각 풀 정의는 서버 시작 시 물리적 풀을 인스턴스화합니다. 두 개 이상의 JDBC 자원이 같은 풀 정의를 가리키는 경우 이러한 자원은 런타임에 같은 연결 풀을 사용하게 됩니다.

다음 절에서 설명하는 대로 관리 인터페이스와 명령줄 인터페이스를 사용하여 JDBC 연결 풀을 만들고 구성할 수 있습니다.

관리 인터페이스를 사용하여 새 JDBC 연결 풀 만들기

관리 인터페이스를 사용하여 새 JDBC 연결 풀을 만들려면 다음을 수행합니다.

  1. 관리 인터페이스의 왼쪽 창에서 JDBC 연결 풀을 만들 Sun ONE Application Server 인스턴스를 엽니다.
  2. Sun ONE Application Server에 나열된 J2EE 서비스 목록에서 JDBC를 선택하여 그 아래의 ConnectionPools 탭을 엽니다. "새 JDBC 연결 풀 만들기" 그림과 같은 화면이 관리 인터페이스의 오른쪽 창에 표시됩니다.

그림 10-7 새 JDBC 연결 풀 만들기

새 JDBC 연결 풀을 만들 수 있는 관리 인터페이스의 창을 보여주는 그림입니다.

  1. 만들고 있는 연결 풀의 JNDI 이름을 "이름" 필드에 입력합니다.
  2. 새 연결 풀에 대해 전역 트랜잭션 지원을 활성화하려면 "전역 트랜잭션 지원 사용" 확인란을 선택합니다. 전역 트랜잭션에 참여할 수 있는 연결 풀을 XA 가능 연결 풀이라고 합니다.
  3. "데이터베이스 공급업체" 드롭다운 목록에서 데이터베이스 공급업체를 선택하고 "다음"을 누릅니다. 다음과 같은 화면에서 연결 풀 설정을 구성해야 합니다.
연결 풀 설정 구성

풀 설정을 구성하려면 "관리 인터페이스를 사용하여 새 JDBC 연결 풀 만들기"의 단계 1-단계 5를 수행합니다. 단계 5에 설명한 대로 "다음"을 누르면 관리 인터페이스의 오른쪽 창에 새 페이지가 표시됩니다. 여기에는 다음과 같은 섹션이 포함되어 있습니다.

다음 표의 지침에 따라 제공된 매개 변수의 값을 이 페이지의 "일반" 섹션에서 지정합니다.

표 10-2 일반 설정

매개 변수

설명

이름

연결 풀의 이름입니다.

데이터 소스 클래스 이름

데이터 소스 및/또는 XADataSource API를 구현하는 공급업체별 클래스 이름입니다.

설명

연결 풀에 대한 설명입니다.

이 페이지의 "등록 정보" 섹션에서 표준 및 독점 JDBC 연결 풀 등록 정보를 지정합니다. 이러한 등록 정보 중 많은 부분은 선택 사항입니다. 기본적으로 모든 표준 등록 정보의 이름이 제공됩니다. 어떤 표준 등록 정보 및 공급업체 관련 등록 정보가 필요한지 확인하려면 데이터베이스 공급업체의 설명서를 참조해야 합니다.

다음 표의 지침에 따라 제공된 매개 변수의 값을 이 창의 "풀 설정" 섹션에서 지정합니다.

표 10-3 연결 풀 설정

매개 변수

설명

고정 풀 크기

풀에서 유지해야 하는 최소 연결 수를 지정합니다. 요청된 스레드에 연결이 할당되면 해당 스레드가 풀에서 제거되므로 현재 풀 크기가 줄어듭니다. 고정 풀 크기는 서버 시작 시 풀에 추가될 항목 수도 참조합니다.

최대 풀 크기

지정된 시점에서 풀에서 사용할 수 있는 최대 연결 수를 지정합니다.

풀 크기 조정 개수

풀이 고정 풀 크기로 축소되면 일괄 처리의 크기가 조정됩니다. 이 값은 일괄 처리의 크기를 결정합니다. 이 값을 너무 크게 하면 연결 재순환이 너무 지체되며 너무 적게 하면 효율성이 떨어집니다. 풀 용량은 한 번에 연결을 한 개만 증가시키므로 이 필드는 풀 용량 증가에는 영향을 미치지 않습니다.

유휴 시간 초과(초)

풀에서 연결이 유휴 상태로 있을 수 있는 최대 시간(초)입니다. 이 시간이 지나면 풀 구현에서 해당 연결을 닫을 수 있습니다.

최대 대기 시간

연결 시간이 초과될 때까지 호출자가 대기해야 하는 시간입니다. 기본 대기 시간은 long이므로 호출자는 오랫 동안 대기할 수 있습니다.

이 창의 연결 검증 섹션과 트랜잭션 격리 섹션에서 다음 표의 지침에 따라 연결 풀을 위한 검증 방법과 트랜잭션 격리 방법을 선택합니다.

표 10-4 연결 검증 및 트랜잭션 격리

매개 변수

설명

연결 검증 필요

이 필드를 선택하면 연결이 응용 프로그램으로 전달되기 전에 검증됩니다. 따라서 네트워크 실패나 데이터베이스 서버 크래시로 인해 데이터베이스를 사용할 수 없는 경우 응용 프로그램 서버가 데이터베이스 연결을 자동으로 다시 설정합니다. 연결 검증을 수행하면 추가 오버헤드가 발생하며 성능이 약간 저하됩니다.

검증 방법

데이터베이스 연결을 검증하기 위해 응용 프로그램 서버에서 사용할 수 있는 방법으로는 세 가지가 있습니다. 적절한 방법을 결정하려면 사용 중인 데이터베이스의 기능에 대해 잘 알고 있어야 합니다. 세 가지 검증 방법은 다음과 같습니다.

  • auto-commit, meta-data - con.getAutoCommit() 및 con.getMetaData() 메소드는 일반적으로 연결을 검증하는 데 사용됩니다. 안타깝게도 많은 JDBC 드라이버는 이러한 호출 결과를 캐시하므로 항상 신뢰할만한 검증 결과를 제공하지는 않습니다. 이러한 호출의 캐시 여부를 결정하려면 공급업체에 확인해야 합니다.
  • table: 이 메소드를 사용하려면 응용 프로그램 서버가 사용자 지정 테이블에 대해 쿼리를 수행해야 합니다. 실제 쿼리는 "select (count *) from <table-name>"입니다. 행은 없어도 되지만 테이블은 반드시 있어야 하고 액세스할 수 있어야 합니다. 많은 수의 행이 있는 기존 테이블이나 이미 자주 액세스하는 테이블은 사용하지 마십시오.

테이블 이름

"검증 방법" 드롭다운 목록에서 마지막 검증 옵션, table을 선택하는 경우 여기에서 테이블 이름을 지정합니다.

모든 연결 끊기

풀의 모든 연결을 끊으려면 이 확인란을 선택하고 한 연결만 끊으려면 연결을 다시 설정하십시오. 이 확인란을 선택하지 않으면 연결은 사용될 때만 개별적으로 다시 설정됩니다.

트랜잭션 격리

이 연결의 트랜잭션 격리 수준을 선택할 수 있습니다. 이 확인란을 선택하지 않으면 풀은 JDBC 드라이버에서 제공하는 기본 격리 수준으로 실행됩니다.

격리 수준 보장

격리 수준이 지정된 경우에만 적용할 수 있습니다. 따라서 풀에서 가져온 연결은 항상 동일한 격리 수준을 갖게 됩니다. 예를 들어, 마지막으로 사용했을 때 연결의 격리 수준을 프로그래밍 방식으로 변경한 경우
(예: con.setTransactionIsolation) 이 메커니즘은 연결의 격리 수준을 지정된 격리 수준으로 다시 변경합니다.

명령줄 인터페이스를 사용하여 새 JDBC 연결 풀 만들기

이 절에서는 예를 통해 명령줄 인터페이스를 사용하여 JDBC 연결 풀을 만드는 방법을 설명합니다.

다음 표는 연결 풀을 만드는 데 필요한 모든 옵션(예: 서버 이름, 비밀번호)을 나열합니다. 다음 표에는 샘플 값이 사용되었습니다. 이 절에서 설명한 명령을 실행하기 전에 Sun ONE Application Server 설치와 관련된 매개 변수를 준비하는 것이 좋습니다.

표 10-5 명령줄 인터페이스를 사용하여 JDBC 연결 풀을 만드는 데 필요한 옵션

필요한 옵션 설명

샘플 값

응용 프로그램 서버 관리 사용자 이름

admin

응용 프로그램 서버 관리 비밀번호

adminadmin

응용 프로그램 서버 관리 포트

8888

응용 프로그램 서버 컴퓨터 이름

sas.sun.com

응용 프로그램 서버 인스턴스 이름

server1

연결 풀의 데이터 소스 클래스 이름

oracle.jdbc.xa.client.OracleXADataSource

주: 연결 풀을 만들 데이터베이스의 데이터 소스 클래스 이름을 사용합니다. 이 예에서 사용되는 데이터베이스는 Oracle입니다.

Jdbc 자원 설명 샘플

Jdbc 자원

연결 풀 설명 샘플

Jdbc 연결 풀

Jdbc 자원 이름

jdbc/SampleJdbcResource

연결 풀 이름

SampleJdbcConnectionPool

데이터베이스 사용자 이름

oracle

데이터베이스 이름

oracle

Jdbc 연결 URL

jdbc:oracle:thin:@oracleserver.sun.com:1521:ORA

다음 예에서는 "명령줄 인터페이스를 사용하여 JDBC 연결 풀을 만드는 데 필요한 옵션" 표에 나열된 변수를 사용합니다.

예 1:

이 예에서는 SampleJdbcConnectionPool이라는 JDBC 연결 풀을 만듭니다. 이 예에서는 JDBC 연결 풀을 만들기 위해 다음과 같이 두 단계 과정을 사용합니다.

1단계 - 연결 풀 만들기

다음은 JDBC 연결 풀을 만들기 위한 명령줄 인터페이스 구문입니다.

asadmin create-jdbc-connection-pool --user admin_user [--password admin_password] [--host localhost] [--port 4848] [--secure | -s] [--instance instancename] --datasourceclassname classname [--restype res_type] [--steadypoolsize 8] [--maxpoolsize 32] [--maxwait 60000] [--poolresize 2] [--idletimeout 300] [--isolationlevel isolation_level] [--isisolationguaranteed] [--isconnectvalidatereq=false] [--validationmethod auto-commit] [--validationtable tablename] [--failconnection=false] [--description text] [--property (name=value)[:name=value]*] connectionpool_id

예를 들어, 다음 명령은 SampleJdbcConnectionPool이라는 연결 풀을 만듭니다.

asadmin create-jdbc-connection-pool --user admin --password adminadmin --host sas.sun.com --port 8888 --instance server1 --restype javax.sql.XADataSource --datasourceclassname oracle.jdbc.xa.client.OracleXADataSource --description "Sample Jdbc Connection Pool" --property User="oracle":Password="oracle":URL="jdbc\:oracle\:thin\:@oracleserver.sun.com\:1521\:ORA" SampleJdbcConnectionPool

주

새 연결 풀에 대해 전역 트랜잭션 지원을 활성화하려면 --restype javax.sql.XADataSource를 설정합니다. URL 등록 정보에서 콜론(:)을 (\:)으로 바꾸십시오.

JDBC 연결 풀이 성공적으로 만들어지면 다음 메시지가 표시됩니다.

Created the JDBC connection pool resource with id = SampleJdbcConnectionPool

2단계 - 인스턴스에 변경 사항 적용

이제 JDBC 연결 풀을 성공적으로 만들었으므로 이러한 변경 사항을 Sun ONE Application Server의 현재 인스턴스에 적용해야 합니다.

다음은 Sun ONE Application Server의 인스턴스에 변경 사항을 적용하기 위한 구문입니다.

asadmin reconfig --user admin_user [--password admin_password] [--host localhost] [--port adminport] [--secure | -s] [--discardmanualchanges=false|--keepmanualchanges=false] instancename

예를 들어, 다음 명령은 Sun ONE Application Server의 인스턴스인 server1에 변경 사항을 적용합니다.

asadmin reconfig --user admin --password adminadmin --host sas.sun.com --port 8888 server1

Sun ONE Application Server의 인스턴스에 변경 사항이 적용되면 다음 메시지가 표시됩니다.

Successfully reconfigured

명령줄 인터페이스를 사용하여 JDBC 연결 풀 관리

이 절에서 설명하는 대로 명령줄 인터페이스를 사용하여 JDBC 연결 풀과 해당 등록 정보를 관리할 수 있습니다.

연결 풀 나열. 다음 명령은 2단계 에서 사용한 Sun ONE Application Server의 인스턴스인 server1에 대해 만든 모든 연결 풀을 나열합니다.

asadmin list-jdbc-connection-pools --user admin --password adminadmin --host sas.sun.com --port 8888 server1

JDBC 연결 풀 등록 정보 변경. 다음과 같이 maxPoolSize 등록 정보 같은 JDBC 연결 풀 등록 정보를 변경할 수 있습니다.

  1. JDBC 연결 풀 속성 maxPoolSize에 지정한 값을 얻으려면 다음 명령을 실행합니다.

    2. asadmin get -u admin -w adminadmin -H sas.sun.com -p 8888 server1.jdbc-connection-pool.SampleJdbcConnectionPool.maxPoolSize

    이 명령을 실행하면 다음과 같은 결과가 표시됩니다.

    server1.jdbc-connection-pool.SampleJdbcConnectionPool.maxPoolSize = 32

    다음 명령을 실행하여 MaxPoolSize 값을 80으로 변경합니다.

    asadmin set -u admin -w adminadmin -H sas.sun.com -p 8888 server1.jdbc-connection-pool.SampleJdbcConnectionPool.maxPoolSize="80"

    표시된 대로 값을 지정하면 다음 메시지가 표시됩니다.

    Attribute maxPoolSize set to 80

  2. 다음 명령을 사용하여 Sun ONE Application Server의 인스턴스에 변경 사항을 적용합니다.

    3. asadmin reconfig --user admin --password adminadmin --host sas.sun.com --port 8888 server1

사용자 등록 정보 변경. 다음 샘플 코드에서 "User" 등록 정보를 oracle에서 System으로 변경할 수 있습니다.

asadmin create-jdbc-connection-pool --user admin --password adminadmin --host sas.sun.com --port 8888 --instance server1 --restype javax.sql.XADataSource --datasourceclassname oracle.jdbc.xa.client.OracleXADataSource --description "Sample Jdbc Connection Pool" --property User="oracle":Password="oracle":URL="jdbc\:oracle\:thin\:@oracleserver.sun.com\:1521\:ORA" SampleJdbcConnectionPool

  1. 사용자 등록 정보를 변경하려면 다음 명령을 실행합니다.

    2. asadmin set -u admin -w adminadmin -H sas.sun.com -p 8888 server1.jdbc-connection-pool.SampleJdbcConnectionPool.property.User="System"

    사용자 이름이 Oracle에서 System으로 변경됩니다.

  2. 사용자 이름을 변경하고 다음 명령을 실행하여 변경 사항을 적용합니다.

    3. asadmin reconfig --user admin --password adminadmin --host sas.sun.com --port 8888 server1

SampleJdbcResource라는 JDBC 자원 만들기. 아래에 설명한 대로 JDBC 자원을 만들 수 있습니다. 다음은 JDBC 자원을 만들기 위한 구문입니다.

asadmin create-jdbc-resource --user admin_user [--password admin_password] [--host localhost] [--port 4848] [--secure | -s] [--instance instancename] --connectionpoolid id [--enabled=true] [--description text] [--property (name=value)[:name=value]*] jndiname

  1. SampleJdbcResource라는 JDBC 자원을 만들려면 다음 명령을 실행합니다.

    2. asadmin create-jdbc-resource --user admin --password adminadmin --host sas.sun.com --port 8888 --instance server1 --description "Sample Jdbc Resource" --connectionpoolid SampleJdbcConnectionPool jdbc/SampleJdbcResource

    이 명령을 실행하면 JDBC 자원이 만들어지고 다음 메시지가 표시됩니다.

    Created the external JDBC resource with jndiname = jdbc/SampleJdbcResource

  2. 다음 명령을 실행하여 Sun ONE Application Server의 인스턴스에 변경 사항을 적용합니다.

    3. asadmin reconfig --user admin --password adminadmin --host sas.sun.com --port 8888 server1

  3. 다음 명령을 실행하여 server1 인스턴스의 JDBC 자원을 모두 나열합니다.

    4. asadmin list-jdbc-resources --user admin --password adminadmin --host sas.sun.com --port 8888 server1

연결 풀링 정보

응용 프로그램은 JNDI를 사용하여 데이터 소스를 먼저 조회하여 연결을 얻을 수 있습니다. 이 작업을 위한 샘플 코드 단편이 아래에 나와 있습니다.

InitialContext ctx = new InitialContext();

DataSource ds = (DataSource) ctx.lookup("java:comp/env/jdbc/employee_ds");

DataSource를 얻은 다음 응용 프로그램 구성 요소는 J2EE 배포 설명자의 <res-auth> 요소에 설정된 값에 따라 두 가지 방법으로 연결을 얻을 수 있습니다. 이 요소의 값이 Container인 경우 응용 프로그램은 ds.getConnection() 메소드를 사용하여(즉, 로그온 정보를 지정하지 않음) 연결을 얻을 수 있습니다. 그렇지 않은 경우 응용 프로그램은 로그온 정보를 입력해야만 ds.getConnecion(userName, password) 같은 자원 관리자로부터 연결을 얻을 수 있습니다.

getConnection()에 대한 모든 요청은 풀에서 처리됩니다. server.xml에서 설명된 일련의 매개 변수에 따라 JDBC 연결 풀이 만들어집니다. 풀이 만들어지면 풀에서 처음에 사용할 수 있는 연결 개수가 지정됩니다. 따라서 ds.getConnection() 요청은 풀에서 현재 사용할 수 있는 연결에 따라 처리될 수 있습니다. 다음 요청은 풀이 비어 있음을 발견하고(이전 연결 중에서 풀로 반환된 연결이 없는 경우) 풀에 지정된 최대 연결 개수 제한에 따라 연결 수를 늘리게 됩니다. 풀 구현은 만들어진 연결 개수를 추적합니다. getConnection() 요청이 풀이 비어 있음을 발견하거나 만든 연결 수가 풀의 최대 연결 수와 같은 경우 현재 요청이 차단됩니다. 연결 공유가 가능하지 않은 경우에만 차단되며 연결이 풀에 반환될 때까지 계속됩니다.

데이터베이스가 크래시되어 시작되더라도 연결 풀이 계속 실행되는 한 연결 풀은 계속 제대로 작동합니다. "연결 풀 설정 구성"에 설명한 대로 연결 검증을 활성화한 경우에만 작동합니다.

"검증 유형" 드롭다운 목록에서 선택한 값에 따라 다음 매개 변수가 풀 구현 프로그램에 의해 실행됩니다.

fail-all-connections 등록 정보를 활성화한 경우 풀의 연결 중 어느 하나라도 유효하지 않은 것으로 확인되면 모든 연결이 닫히고 다시 설정됩니다. 그렇지 않은 경우 무효 및 재설정이 지연되었다가 개별 연결을 사용할 때 발생합니다.

또한 풀 구현은 풀에서 사용 가능한 연결을 모두 재순환할 수 있는 기능을 제공합니다. 연결이 지정된 유휴 기간을 초과하여 유휴 상태로 있는 경우 연결이 닫히며 풀 크기는 고정 풀 크기로 바뀝니다. 풀이 과도하게 유휴 상태에 있는 경우 컨테이너가 비활성화된 연결을 다시 설정하려고 시도할 수 있으므로 항상 풀을 사용 가능한 고정 개수로 채워 놓아야 합니다. 최대 풀 크기에 상대적으로 고정 풀 크기를 설정할 것인지 여부를 결정할 때에는 이 내용을 유념해야 합니다.

JDBC 연결 풀링 모니터링

풀 크기 구성이 효율적으로 작동하는지 확인하기 위해 풀 작업을 주기적으로 모니터링할 수 있습니다. 다음 표는 모니터링할 수 있는 모든 JDBC 연결 풀링 매개 변수를 나열합니다.

모니터링을 활성화하는 방법과 모니터링할 수 있는 속성은 다음 릴리스에서 개선될 것입니다.

표 10-6 모니터링을 위한 JDBC 연결 풀 매개 변수

속성 이름

데이터 유형

설명

total-threads-waiting

정수

JDBC 연결을 대기하는 총 스레드 수

total-outbound-connections

정수

총 JDBC 연결 검증 실패 횟수

total-connections-timed-out

정수

시간이 초과된 총 연결 요청 수

연결 공유 정보

J2EE 응용 프로그램에서 얻은 여러 연결이 동일한 자원 관리자를 사용하는 경우 풀 구현 시 같은 트랜잭션 범위 내에서 연결 공유를 제공합니다. 트랜잭션 범위라는 용어를 이해하려면 다음 예를 참조하십시오.

Bean_A는 트랜잭션(Tx1)을 시작하여 연결을 얻습니다. 그런 다음 Bean_A는 같은 트랜잭션(Tx1)의 Bean_B에서 메소드를 호출합니다. Bean_B는 같은 DataSource로부터 같은 로그온 정보를 사용하여 연결을 얻으므로 Bean_A가 트랜잭션을 완료한 경우에만 같은 연결을 공유할 수 있습니다. 또한 자원 공유 범위가 J2ee 배포 설명자에서 Shareable로 설정된 경우에만 연결을 공유할 수 있습니다. 연결 공유를 원하지 않는 경우 배포 설명자에서 자원 공유 범위를 Unshareable로 설정해야 합니다. Sun ONE Application Server는 성능 향상을 위해 연결 공유를 제공합니다.

JDBC 트랜잭션 정보

트랜잭션은 실행되고 완료된 다음 완결되거나 롤백된 하나 이상의 문으로 구성됩니다. commit이나 rollback 메소드가 호출되면 현재 트랜잭션이 끝나고 다른 트랜잭션이 시작됩니다.

일반적으로 새 연결 객체는 기본적으로 auto-commit 모드에 배치되며 이는 문이 완료되면 해당 문에 대해 commit 메소드가 자동으로 호출될 것임을 의미합니다. 이 경우 각 문은 개별적으로 완결되므로 한 트랜잭션은 한 문으로 구성됩니다. auto-commit 모드가 비활성화되어 있는 경우 commit이나 rollback 메소드가 명시적으로 호출될 때까지 트랜잭션은 종료되지 않습니다. 따라서 commit이나 rollback를 마지막으로 호출한 이후에 실행된 모든 문을 포함하게 됩니다. 두 번째의 경우 트랜잭션의 모든 문은 그룹으로 완결되거나 롤백됩니다.

commit 메소드는 SQL 문이 데이터베이스에 변경한 내용을 영구적으로 반영하며 트랜잭션에서 설정한 잠금을 해제합니다. rollback 메소드는 이러한 변경 사항을 무시합니다.

한 트랜잭션에 두 개의 업데이트가 있는 경우 두 번째 업데이트도 함께 변경되지 않는다면 한 업데이트에 대해서만 변경 사항을 적용하고 싶지 않을 수 있습니다. 이렇게 하려면 auto-commit을 비활성화하고 두 업데이트를 한 트랜잭션으로 그룹화하면 됩니다. 두 가지 업데이트가 모두 성공한 경우 commit 메소드가 호출되어 두 가지 업데이트가 모두 영구적으로 반영됩니다. 한 업데이트나 두 가지 업데이트가 모두 실패하면 rollback 메소드가 호출되어 업데이트가 실행되기 이전의 값을 복구합니다. 대부분의 JDBC 드라이버는 트랜잭션을 지원합니다.

javax.sql 패키지의 클래스와 인터페이스는 연결 객체가 분산 트랜잭션(두 개 이상의 DBMS 서버에 대한 연결과 관련된 트랜잭션)의 일부가 될 수 있도록 합니다. 분산 트랜잭션에 참여하려면 중간 계층 서버의 분산 트랜잭션 인프라와 작업할 수 있도록 구현된 DataSource 객체가 연결 객체를 만들어야 합니다. DriverManager가 만든 연결 객체와는 달리 DataSource 객체가 만든 연결 객체는 기본적으로 auto-commit 모드가 비활성화되어 있습니다. 반면 DataSource 객체의 표준 구현은 DriverManager 클래스가 만드는 것과 똑같은 연결 객체를 만듭니다.

연결 객체가 분산 트랜잭션의 일부인 경우 트랜잭션 관리자는 commit 또는 rollback 메소드가 호출된 시점을 확인합니다. 따라서 연결 객체가 분산 트랜잭션에 참여하고 있는 경우 응용 프로그램은 Connection.commit이나 Connection.rollback 메소드를 호출하거나 연결의 auto-commit 모드를 설정하는 등 연결이 시작되거나 끝나는 시기에 영향을 미치는 작업을 하면 안 됩니다. 이러한 작업은 트랜잭션 관리자가 분산 트랜잭션을 처리하는 데 방해가 됩니다.

JavaMail 자원 정보

JavaMail API를 사용하면 메시지 저장소에 포함된 전자 메일 메시지에 액세스할 수 있으며 메시지 전송을 사용하여 전자 메일 메시지를 만들고 전송할 수 있습니다. 인터넷 표준 MIME 메시지에 대한 지원 기능도 포함되어 있습니다. 메시지 저장소와 전송에 대한 액세스는 특정 저장소와 전송 프로토콜을 지원하는 프로토콜 공급자를 통해 이루어집니다. JavaMail API 사양에서는 특정 프로토콜 공급자를 요구하지는 않지만 JavaMail에는 IMAP 메시지 저장소 공급자와 SMTP 메시지 전송 공급자가 포함되어 있습니다.

JavaMail API는 메일 시스템을 구성하는 객체를 정의하는 추상 클래스 집합을 제공합니다. API는 메시지, 저장소, 전송 등과 같은 클래스를 정의합니다. 새 프로토콜을 제공하고 필요한 경우 기능을 추가하기 위해 API를 확장하고 하위 클래스로 나눌 수 있습니다. 또한 API는 추상 클래스의 구체적인 하위 클래스를 제공합니다. MimeMessage와 MimeBodyPart 같은 하위 클래스는 널리 사용되는 인터넷 메일 프로토콜을 구현합니다.

JavaMail API는 IMAP, MAPI, CMC, c-client 및 기타 전자 메일 메시징 시스템 API와 많은 상호 작용을 합니다. JavaMail API는 다양한 메시지 저장소와 다양한 메시지 형식 및 다양한 메시지 전송 같은 여러 메시징 시스템 구현을 지원합니다. JavaMail API는 클라이언트 응용 프로그램의 API를 정의하는 기본 클래스와 인터페이스 집합을 제공합니다. 개발자는 IMAP, POP3, SMTP 같은 특정 메시징 시스템 구현을 위해 JavaMail 클래스를 하위 클래스로 나눌 수 있습니다.

이 절에서는 다음 항목에 대해 설명합니다.

JavaMail 메시지 처리 과정 정보

JavaMail API는 일반 클라이언트 응용 프로그램을 위한 표준 메일 처리 과정을 구성하는 다음 기능을 수행합니다.

다음 그림은 JavaMail API가 메시지를 처리하는 과정을 보여줍니다.

그림 10-8

JavaMail API에서 메시지를 처리하는 과정을 보여주는 그림입니다.

JavaMail API의 메시지 처리 과정

JavaMail API는 javax.mail.Session을 만드는 정적 팩토리 메소드를 사용하여 구성되었습니다. Sun ONE Application Server는 JNDI를 사용하여 세션 객체를 요청하고 resource-ref 요소를 사용하여 배포 설명자에 세션 객체에 대한 요청을 나열합니다. JavaMail API 세션 객체는 자원 팩토리로 간주됩니다.

메시지 전송은 javax.mail.internet.InternetAddress 유형의 주소와 javax.mail.internet.MimeMessage 유형의 메시지를 처리할 수 있어야 합니다. javax.mail.Transport 클래스의 send 메소드를 사용하여 이러한 메시지를 전송할 수 있도록 기본 메시지 전송을 올바르게 구성해야 합니다.

JavaMail API의 추상 계층은 모든 메일 시스템이 지원하는 메일 처리 기능을 지원하기 위해 클래스, 인터페이스 및 추상 메소드를 선언합니다. 추상 계층을 구성하는 API 요소는 표준 데이터 유형을 지원하고 필요한 경우 메시지 액세스와 메시지 전송 프로토콜과 상호 작용하기 위해 하위 클래스로 나뉘고 확장되도록 설계되었습니다.

인터넷 구현 계층은 인터넷 표준 - RFC822와 MIME을 사용하여 추상 계층의 일부를 구현합니다.

JavaMail의 구조적 구성 요소 정보

이 절에서는 다음 항목을 통해 JavaMail 구조를 구성하는 주요 구성 요소에 대해 설명합니다.

메시지 클래스

메시지 클래스는 메일 메시지 내용과 속성 집합을 정의하는 추상 클래스입니다. 메시지 클래스의 속성은 주소 지정 정보를 지정하고 내용 유형을 비롯한 내용 구조를 정의합니다. 내용은 실제 데이터를 둘러싸는 DataHandler 객체로 표현됩니다.

메시지 클래스는 Part 인터페이스를 구현합니다. Part 인터페이스는 메시지 객체가 전달하는 데이터 내용을 정의하고 형식을 지정하며 메일 시스템과 성공적으로 인터페이스하는 데 필요한 속성을 정의합니다. 메시지 클래스는 메시지 전송 시스템을 통해 메시지를 라우팅할 때 필요한 보낸 사람, 받는 사람, 제목, 회신 및 기타 속성을 추가합니다. 메시지 객체가 폴더에 포함되어 있는 경우 해당 객체는 자신과 관련된 일련의 태그를 갖습니다. JavaMail은 특정 메시징 구현을 지원하는 메시지 하위 클래스를 제공합니다.

메시지 내용은 메시지 객체 내에 캡슐화된 바이트 모음이거나 바이트 모음에 대한 참조입니다. JavaMail은 메시지 내용의 데이터 유형이나 형식을 알지 못합니다. 메시지 객체는 중간 계층 - JAF(JavaBeans Activation Framework)를 통해 해당 내용과 상호 작용합니다. 이렇게 분리되어 있기 때문에 메시지 객체는 임의의 내용을 처리한 다음 같은 API 메소드를 호출하고 적절한 전송 프로토콜을 사용하여 내용을 전송할 수 있습니다. 메시지 받는 사람은 일반적으로 해당 내용의 데이터 유형 및 형식과 그 처리 방법을 알고 있습니다.

또한 JavaMail API는 각 Bodypart가 자신의 고유 속성 및 내용 집합을 정의하는 multipart 메시지 객체를 지원합니다.

메시지 저장 및 검색

메시지는 폴더 객체에 저장됩니다. 폴더 객체는 메시지와 하위 폴더를 포함할 수 있으므로 트리형 폴더 계층을 제공합니다. 폴더 클래스는 메시지를 불러오고 추가하며 복사하고 삭제하는 메소드를 선언합니다. 또한 폴더 객체는 Event Listener로 등록된 구성 요소로 이벤트를 보낼 수 있습니다.

저장소 클래스

저장소 클래스는 메시지와 함께 폴더 계층을 보관하는 데이터베이스를 정의합니다. 또한 저장소 클래스는 폴더에 액세스하여 폴더에 저장된 메시지를 검색하는 액세스 프로토콜을 지정합니다. 또한 폴더를 불러오고 연결을 닫기 위해 데이터베이스에 대한 연결을 설정하는 메소드를 제공합니다. 메시지 액세스 프로토콜(IMAP, POP3 등)을 구현하는 서비스 공급자는 저장소 클래스를 하위 클래스로 나누는 작업부터 시작합니다. 사용자는 일반적으로 특정 저장소 구현에 연결하여 메일 시스템과의 세션을 시작합니다.

메시지 작성 및 전송

클라이언트는 적절한 메시지 하위 클래스를 인스턴스화하여 새 메시지를 만듭니다. 받는 사람 주소와 제목 같은 속성을 설정하고 내용을 메시지 객체에 삽입합니다. 마지막으로 Transport.send 메소드를 호출하여 메시지를 보냅니다. 전송 클래스는 메시지를 대상 주소로 라우팅하는 전송 에이전트를 모델화합니다. 이 클래스는 메시지를 받는 사람 목록으로 보내는 메소드를 제공합니다. 메시지 객체와 함께 Transport.send 메소드를 호출하면 대상 주소에 따라 적절한 전송 방법을 식별합니다.

세션 클래스

세션 클래스는 메일 활성 클라이언트와 네트워크 사이의 인터페이스를 정의하는 전역 및 사용자별 메일 관련 등록 정보를 정의합니다.

JavaMail 시스템은 세션 객체를 사용하여 특정 등록 정보를 설정하고 얻습니다. 또한 세션 클래스는 데스크탑 응용 프로그램이 공유할 수 있는 기본 인증 세션 객체를 제공합니다. 세션 클래스는 구체적인 마지막 클래스이며 하위 클래스로 나눌 수 없습니다. 세션 클래스는 또한 특정 액세스 및 전송 프로토콜을 구현하는 저장소 및 전송 객체에 대한 팩토리 역할을 합니다. 세션 객체에 대해 적절한 팩토리 메소드를 호출하면 클라이언트는 특정 프로토콜을 지원하는 저장소 및 전송 객체를 얻을 수 있습니다.

JAF (JavaBeans Activation Framework) 정보

JavaMail은 메시지 데이터를 캡슐화하고 이 데이터와 상호 작용할 명령을 처리하기 위해 JAF (JavaBeans Activation Framework)를 사용합니다. 메시지와의 상호 작용은 JavaMail API가 제공하지 않는 JAF 인식 JavaBeans를 통해 이루어져야 합니다.

JavaBeans Activation Framework 표준 확장을 통해 Java 기술을 사용하는 개발자는 표준 서비스를 이용하여 임의 데이터 부분의 유형을 결정하고 이에 대한 액세스를 캡슐화하여 사용 가능한 작업을 알아내며 이러한 작업을 수행하기 위해 적절한 Bean을 인스턴스화할 수 있습니다. 예를 들어, 브라우저에서 JPEG 이미지를 가져온 경우 이 프레임워크는 브라우저가 해당 데이터 스트림을 해당 유형의 JPEG 이미지로 식별할 수 있게 해주며 브라우저는 그 이미지를 조작하거나 볼 수 있는 객체를 찾아 인스턴스화할 수 있습니다.

JavaBeans Activation Framework API는 다양한 MIME 데이터 유형을 지원합니다. JavaMail API는 다음 표에서 설명하는 Java 프로그래밍 언어 유형에 해당하는 다음 MIME 데이터 유형에 대한 javax.activation.DataContentHandlers를 포함해야 합니다.

표 10-7 JavaMail API MIME 데이터 유형 대 Java 유형 매핑

MIME 유형

Java 유형

Text/Plain

java.lang.String

Multipart/

javax.mail.internet.MIME.Multipart

Message/rfc822

javax.mail.internet.MIME.Message

JavaBeans Activation Framework는 MIME 데이터 유형에 대한 지원을 Java 플랫폼에 통합합니다. MIME 바이트 스트림은 javax.activation.DataContentHandlerobjects를 사용하여 Java 프로그래밍 언어 객체와 상호 변환할 수 있습니다. JavaBeans 구성 요소에 대해 데이터 보기나 편집 같은 MIME 데이터에 대한 작업을 지정할 수 있습니다. 또한 JavaBeans Activation Framework는 파일 이름 확장자를 MIME 유형에 매핑할 수 있는 메커니즘을 제공합니다. JavaMail API는 JavaBeans Activation Framework를 사용하여 전자 메일 메시지에 포함된 데이터를 처리합니다. 전자 메일을 복잡하게 사용하는 응용 프로그램의 경우 JavaBeans Activation Framework를 직접 사용해야 할 수도 있지만 일반 J2EE 응용 프로그램은 JavaBeans Activation Framework를 직접 사용할 필요가 없습니다.

JavaMail 구성 매개 변수 정보

다음 구성 매개 변수는 Sun ONE Application Server의 JavaMail 자원에서 사용됩니다. 이러한 구성 매개 변수는 이름, 값 쌍으로 이루어지며 server.xml 파일의 mail-resource 요소에서 읽을 수 있습니다.

JavaMail 세션 참조용 J2EE 배포 설명자

JavaMail 자원을 서버에 등록하면 JNDI 조회를 사용하여 모든 J2EE 응용 프로그램 구성 요소에서 해당 자원을 참조할 수 있습니다. 자원 관리자 연결 팩토리를 참조하는 응용 프로그램을 배포하려면 구성 요소 공급자가 표준 J2EE 1.3 배포 설명자에서 모든 자원 관리자 연결 팩토리 참조를 선언해야 합니다.

JavaMail 참조에 필요한 모든 J2EE1.3 설명자 요소를 아래에서 설명합니다.

<resource-ref>

<description>

메일을 보내는 데 사용한 JavaMail 자원

</description>

<res-ref-name>mail/MyMailSession</res-ref-name>

<res-type>javax.mail.Session</res-type>

<res-auth>Container</res-auth>

<res-sharing-scope>Shareable</res-sharing-scope>

</resource-ref>

Sun ONE Application Server 배포 설명자의 항목

메일 자원을 참조하는 배포된 각 구성 요소에 대해 배포자는 구성 요소에서 사용되는 자원 이름을 데이터 소스가 이름 지정 서비스에 등록한 실제 jndi 이름에 매핑해야 합니다. 배포 도구는 배포자가 이 매핑을 쉽게 할 수 있도록 도움을 주어야 합니다. 이 매핑은 Sun ONE Application Server 관련 xml에 등록되어 있습니다. 매핑을 포함하는 Sun ONE Application Server의 특정 XML 단편이 아래에 나와 있습니다.

<resource-ref>

<res-ref-name>mail/MyMailSession</res-ref-name>

<jndi-name>mail/Session</jndi-name>

</resource-ref>

새 JavaMail 세션 만들기

관리 인터페이스를 사용하여 JavaMail 세션을 구성할 수 있습니다. 새 JavaMail 세션을 만들고 구성하려면 다음 작업을 수행합니다.

  1. 관리 인터페이스의 왼쪽 창에서 새 JavaMail 세션을 만들 Sun ONE Application Server 인스턴스를 확장합니다.
  2. "JavaMail 세션"을 누릅니다. 관리 인터페이스 오른쪽 창의 "JavaMail 세션 구성" 그림에 표시된 다음 창이 나타납니다.

그림 10-9 JavaMail 세션 구성

JavaMail 세션이 어떻게 구성되어 있는지를 보여주는 그림입니다.

  1. 만들고 있는 JavaMail 세션에 대한 JNDI 이름을 "JNDI 이름" 텍스트 필드에 입력합니다. JavaMail 자원을 서버에 등록하면 JNDI 조회를 사용하여 모든 J2EE 응용 프로그램 구성 요소에서 해당 자원을 참조할 수 있습니다.
  2. 기본 메일 서버의 DNS 이름을 "메일 호스트" 텍스트 필드에 지정합니다. 프로토콜 관련 호스트 등록 정보가 없는 경우 저장소 및 전송 객체의 연결 메소드는 이 등록 정보를 사용하여 대상 호스트를 찾습니다.
  3. 메일 서버에 연결할 때 제공할 사용자 이름을 "기본 사용자" 텍스트 필드에 지정합니다. 프로토콜 관련 사용자 이름 등록 정보가 없는 경우 저장소 및 전송 객체의 연결 메소드는 이 등록 정보를 사용하여 사용자 이름을 가져옵니다.
  4. 현재 사용자의 기본 반송 주소를 "기본 반송 주소"에 지정합니다. 기본 주소의 형식은 username@host이어야 합니다.
  5. "설명" 필드에 이 JavaMail 세션에 대한 설명을 입력합니다.
  6. 만든 JavaMail 세션을 활성화하려면 "JavaMail 세션 사용" 확인란을 선택합니다.
  7. 구성한 새 JavaMail 세션을 저장하려면 "확인"을 누릅니다.

고급 자원 등록 정보 구성

관리 인터페이스를 사용하여 새 JavaMail 세션에 대한 몇 가지 추가 등록 정보를 구성할 수 있습니다. 등록 정보 이름과 값 쌍은 사용 중인 메일 프로토콜에 따라 달라집니다. 이러한 등록 정보를 server.xml 파일에서 직접 지정할 수도 있습니다.

추가 등록 정보를 구성하려면 다음 작업을 수행합니다.

  1. 관리 인터페이스의 왼쪽 창에서 JavaMail 세션을 수정할 Sun ONE Application Server 인스턴스를 확장합니다.
  2. "JavaMail 세션"을 누릅니다. "새 JavaMail 세션 만들기"에서 설명한 주요 구성 절 아래에 있는 관리 인터페이스의 오른쪽 창에 "JavaMail 세션의 추가 자원 구성" 그림에 있는 대로 다음 창이 표시됩니다.

그림 10-10 JavaMail 세션의 추가 자원 구성

JavaMail 세션의 추가 자원을 구성하는 방법을 보여주는 그림입니다.

  1. 이러한 특정 JavaMail 세션에 사용할 저장소 프로토콜(예: POP3, IMAP)을 "저장소 프로토콜" 텍스트 필드에 지정합니다.
  2. 표시한 저장소 프로토콜의 클래스 이름을 예에 표시된 대로 "저장소 프로토콜 클래스" 텍스트 필드에 지정합니다.
  3. 이러한 JavaMail의 특정 세션에 사용할 전송 프로토콜(예: SMTP)을 "전송 프로토콜" 텍스트 필드에 입력합니다.
  4. 이 세션에 대해 표시한 전송 프로토콜의 클래스 이름을 위의 예에서 표시한 대로 "전송 프로토콜 클래스" 텍스트 필드에 지정합니다.
  5. 이러한 JavaMail의 특정 세션 디버깅을 활성화하려면 "디버그 사용" 확인란을 선택합니다. 이 확인란을 활성화하면 디버그 모드가 설정됩니다.
  6. 추가 등록 정보 구성을 저장하려면 "확인"을 누릅니다.

메일 자원 구성에 대한 전체 예가 아래에 나와 있습니다.

<mail-resource

jndi-name = "mail/Session"

enabled = "true"

store-protocol = "imap"

store-protocol-class = "com.sun.mail.imap.IMAPStore"

transport-protocol = "smtp"

transport-protocol-class = "com.sun.mail.smtp.SMTPTransport"

host = "gopostal.acme.com"

user = "kingkong"

from = "kingkong@acme.com"

debug = "false">

<property name = "mail-imap-host" value = "spaceduck.acme.com"/>

<property name = "mail-imap-user" value = "fredbloggs"/>

</mail-resource>



이전      목차      색인      다음     

Copyright 2003 Sun Microsystems, Inc. 모든 권리는 저작권자의 소유입니다.