소개

DB2®에서 정적으로 SQL을 실행하는 기능을 제공하는 주요 이유는 성능을 개선할 수 있도록 하기 위함이다. 불행히도, pureQuery 클라이언트 최적화가 도입되기 전까지는 대부분의 Java™ 애플리케이션에서 SQLJ를 사용해야 했다. 따라서, 데이터베이스를 액세스하는 거의 모든 Java 애플리케이션에서는 동적 실행으로 인해 런타임 시에 SQL 명령문을 준비(액세스 계획을 작성하는 것)하는 것과 같은 오버헤드가 발생한다. 캐싱을 사용하면 이러한 오버헤드를 최소화할 수 있다. 캐싱은 데이터베이스 서버와 클라이언트에서 사용할 수 있다. 그러나, 기타 다른 경우에는 메모리 사용에 제한이 따른다. 이 기사에서는 캐싱을 다루지 않는다.

정적 SQL을 사용하면 런타임 시보다 빠른 바인드 시에 액세스 계획을 작성할 수 있어서 성능을 개선할 수 있다. 따라서, 정적 명령문을 실행하기 전에 PREPARE와 DESCRIBE 조작을 수행할 필요가 없다.

Optim pureQuery Runtime의 클라이언트 최적화 기능을 이용하면 기존의 Java 애플리케이션은 물론이고 Java 프레임워크를 사용하여 개발된 애플리케이션에서도 DB2 데이터베이스를 대상으로 정적 SQL 실행을 사용할 수 있어서 정적 실행으로 인한 관리 및 성능 혜택을 얻을 수 있다. 그리고 애플리케이션 코드를 변경하지 않아도 이러한 기능을 수행할 수 있다.

DB2를 실행하고 있지 않은 경우에도 클라이언트 최적화에 따른 기타 장점을 일부 이용할 수 있다. 예를 들어, Optim™ Development Studio의 개발 환경을 사용하면 SQL 명령문을 Java 소스 코드의 원본 행으로 트랙백할 수 있어서 SQL을 더 쉽게 찾아서 조정할 수 있으며 따라서 특정 SQL 명령문을 변경했을 때 미치는 영향을 쉽게 파악할 수 있다. 애플리케이션의 Java 소스 코드를 변경하지 않아도 SQL 명령문을 조정하여 성능이 좋지 못한 명령문을 대체할 수 있다. 그리고 사전 정의된 SQL 명령문과 승인된 SQL 명령문 세트만을 애플리케이션에서 실행하도록 제한하여 SQL 주입을 피할 수 있다.

정적 SQL을 사용함으로써 얻을 수 있는 혜택에 대한 자세한 사항은 "'No excuses' database programming for Java"기사를 참고하기 바란다(참고자료 확인). 트랙백과 SQL 대체를 수행하는 Optim Development Studio의 기능에 관한 자세한 정보는 "What's New in Optim Development Studio 2.2" 기사를 참고하기 바란다(참고자료 확인).

클라이언트 최적화 프로세스 검토

처음에 튜토리얼 "Optimize your existing JDBC applications using pureQuery"(참고자료 확인)에서 설명한 바와 같이 pureQuery 클라이언트 최적화를 사용하여 동적 SQL을 정적 SQL로 변환하는 프로세스에는 그림 1에 표시된 것과 같은 단계가 필요하다. (정적 SQL을 사용하지 않는 경우에는 구성 단계와 바인드 단계가 필요하지 않다.)

pureQuery를 사용하려면 IBM Data Server Driver for JDBC and SQLJ와 Optim pureQuery Runtime이 필요하다. 이러한 두 가지 도구는 Optim Development Studio를 실행 중인 컴퓨터에서 개발용으로 사용할 수 있다. 그림 1에서는 DB2 JCC Driver and pureQuery Runtime으로 레이블이 지정된 상자가 이러한 도구에 해당한다. 그림 1에서 화살표로 강조된 네 가지 주요 프로세스 단계는 다음과 같다.

캡처(Capture)

이 프로세스에서는 애플리케이션을 동적으로 실행하며 pureQuery에서 SQL 명령문과 pureQueryXml 파일(캡처 파일)에 있는 필수 정보를 함께 캡처할 수 있도록 한다. 이 프로세스는 그림 1에서 Captures SQL and related metadata로 레이블이 지정된 파일에 해당한다.

구성(Configure)

입력 과정을 통해, 캡처된 SQL을 하나 이상의 데이터베이스 패키지 이름에 맵핑한다. 이렇게 하기 위한 가장 쉬운 방법은 Optim Development Studio를 사용하는 것이다.

바인드(Bind)

원격 바인드를 사용하여 구성된 캡처 파일을 패키지로 바인드하거나 DBRM을 대상 서버로 바인드한다. 이 단계는 정적 실행을 사용하는 경우에만 필요하다. Optim Development Studio를 사용하거나 명령행에서 Static Binder 유틸리티를 사용하여 이러한 과정을 수행할 수 있다.

실행(Execute)

캡처된 SQL을 정적이나 동적으로 실행하거나 또는 두 가지 모두로 실행하도록 pureQuery를 구성하여 필요한 동작하게 한다. Optim Development Studio를 사용하거나 명령행에서 실행할 수 있다.

위로

애플리케이션 서버에서 pureQuery Runtime 사용

그림 2에는 클라이언트, 애플리케이션 및 데이터베이스 티어로 구성된 3 티어 애플리케이션 환경에서 전형적으로 사용되는 pureQuery 전개 토폴로지가 표시되어 있다. pureQuery 런타임은 애플리케이션 티어에서 전개하며 애플리케이션 서버를 사용하는 경우에는 이 서버가 있는 곳에 그렇지 않은 경우에는 독립형 애플리케이션용 클라이언트 드라이버가 있는 곳에 전개한다. 데이터베이스 티어에서는 소프트웨어를 추가로 설치할 필요가 없다.

그림 2에는 DB2가 데이터 서버로 표시되어 있지만, Informix Dynamic Server와 Oracle 데이터베이스를 pureQuery와 함께 사용할 수도 있다. 이 기사에서는 WebSphere Application Server를 사용하는 상황에서 pureQuery를 구성하는 방법을 설명한다. 다른 애플리케이션 서버를 사용하는 경우에도 이 기사에서 설명한 기본적인 작업은 동일하지만 애플리케이션 서버 환경에 따라 특정 단계가 다를 수 있다.

기본적인 단계는 다음과 같다.

1. pureQuery Runtime 및 IBM Data Server Driver for JDBC and SQLJ 설치
2. pureQuery 사용 JDBC 제공자 작성
3. pureQuery 사용 데이터 소스 작성

pureQuery Runtime 및 IBM Data Server Driver for JDBC and SQLJ 설치

표 1에는 다양한 pureQuery Runtime(Linux®, UNIX®, Windows® 및 z/OS®용) 릴리스에서 지원되는 JRE(Java Runtime Environment), WebSphere Application Server, IBM Data Server Driver for JDBC and SQLJ 및 JDBC 버전이 표시되어 있다.

전제조건에 관한 자세한 세부사항은 참고자료에 있는 전제조건 링크를 확인하기 바란다.

pureQuery 사용 JDBC 제공자 작성

이 섹션에서는 WebSphere Application Server를 애플리케이션 서버로 사용하여 JDBC 제공자를 사용 가능하게 하는 방법을 설명한다. 또한, 이 섹션에서는 IBM Data Server Driver for JDBC and SQLJ를 사용하여 애플리케이션을 데이터베이스에 연결한다고 가정한다. WebSphere Application Server에서는 이 드라이버가 JDBC 제공자가 된다. pureQuery를 사용하려면 pureQuery jar 파일(pdq.jar와 pdqmgmt.jar)을 JDBC 드라이버(JDBC 제공자) 클래스 경로에 추가해야 한다. 그림 3에는 WebSphere 관리 콘솔에 클래스 경로 설정값이 표시되어 있다.

pureQuery 사용 데이터 소스 작성

이제, 작성된 JDBC 제공자를 사용하여 데이터 소스를 작성할 수 있다. 다음 단계를 따라 WebSphere Application Server에서 데이터 소스를 작성한다.

1. WebSphere 관리 콘솔에서 Resource 탭 아래에 있는 Data source 탭을 클릭하고 New를 선택한다.
2. 애플리케이션에서 사용한 데이터 소스 이름과 JNDI 이름을 입력한다.
3. 데이터 소스를 작성해야 하는 JDBC 제공자를 선택하고 데이터베이스 이름과 서버 이름, 포트, 사용자 ID, 암호와 같은 데이터베이스 세부사항을 입력한다.
4. 애플리케이션 연결 풀에서 pureQuery를 인식하도록 pdqProperties 데이터 소스 특성의 값을 설정한다. pdqProperties 특성을 기본값(executionMode dynamic)으로 설정할 수도 있다.

pureQuery는 애플리케이션 서버용으로 사용될 수 있다. 애플리케이션 코드에서 이러한 데이터 소스를 사용하여 데이터베이스와 통신하는 데 필요한 연결을 작성한다.

웹 애플리케이션에서는 다수의 데이터 소스를 사용하여 다수의 데이터베이스에서 작업할 수 있다. 마찬가지로, 다수의 웹 애플리케이션에서 하나의 데이터 소스를 사용할 수 있다.

위로

클라이언트 최적화를 위한 pureQuery Runtime 환경 구성 옵션 탐색

클라이언트 최적화 프로세스에서는 특성을 동적 실행에서 정적 실행으로 전환하여 SQL을 캡처할 수 있게 해야 한다. 이 섹션에서는 웹 기반 애플리케이션에 맞게 pureQuery 클라이언트 최적화 특성을 설정하기 위한 세 가지 옵션을 설명한다.

1. 옵션 1: pureQuery Runtime 옵션을 글로벌하게 구성
2. 옵션 2: 데이터 소스의 pureQuery Runtime 옵션 구성
3. 옵션 3: 애플리케이션 레벨에서 pureQuery Runtime 옵션 구성(버전 2.2의 새 기능)

각 옵션에는 장점과 제한사항이 있다. 이 섹션에서는 사용할 방식을 결정하는 데 필요한 다양한 방식과 고려사항을 설명한다.

옵션 1: pureQuery Runtime 옵션을 글로벌하게 구성

이 방식을 선택해야 하는 경우

이 방식에서는 설정값이 특정 드라이버를 사용하는 모든 데이터 소스에 적용되도록 할 수 있다. 설정값이 모든 데이터 소스와 모든 애플리케이션에 반영되어야 하는 경우에 이 방식을 사용한다.

사용 방법

pdq.properties 파일을 사용하여 글로벌 특성을 설정하는 경우에는 JDBC 드라이버의 CLASSPATH에 pdq.properties와 pureQuery jar 파일을 추가한다. JDBC 드라이버의 CLASSPATH에 설정된 특성은 이 드라이버를 사용하는 모든 애플리케이션에 적용된다. 다시 말해서, 애플리케이션과 데이터 소스 레벨에 따라 세분화하여 적용할 수는 없다.

고려사항

동적 모드에서 정적 모드로 이동하는 과정에서 pdq.properties 파일을 수정한 후에는 애플리케이션 서버를 다시 시작하여 변경사항을 반영해야 한다. 특성은 특정 JDBC 제공자를 사용하는 모든 데이터 소스에 적용되므로 모든 SQL은 동일한 pureQueryXml 파일로 이동하여 동일한 모드로 실행된다.

옵션 2: 데이터 소스를 위한 pureQuery Runtime 옵션 구성

이 방식을 선택해야 하는 경우

이 방식을 이용하면 각 데이터 소스의 특성을 설정할 수 있다. 이 방식은 각 데이터 소스를 서로 독립적으로 설정해야 하는 경우에 적합하다. 예를 들어, 애플리케이션에서 다수의 데이터 소스를 사용하는 경우에는 하나의 데이터 소스에 대해서는 동적으로 애플리케이션을 실행하고 다른 데이터 소스에 대해서는 정적으로 실행해야 한다.

사용 방법

데이터 소스 레벨에서 pureQuery 특성을 설정하려면 데이터 소스 사용자 정의 특성 pdqProperties를 사용해야 한다. 그림 4와 같이 WebSphere Application Server 관리 콘솔에서 DataSources > your datasource name > Custom properties > New로 이동하여 이러한 사용자 정의 특성을 설정할 수 있다.

고려사항

글로벌 pdq.properties 파일을 사용할 때와 마찬가지로 특성값을 변경할 때마다 애플리케이션 서버를 다시 시작하여 애플리케이션 서버가 새로운 값을 반영할 수 있도록 해야 한다. 데이터 소스에 특성이 설정되면 이러한 특성은 이러한 데이터 소스를 사용하는 모든 애플리케이션에 적용된다. 따라서, 애플리케이션에서 데이터 소스를 공유하는 경우에는 모든 애플리케이션에서 사용할 수 있도록 캡처된 SQL 명령문이 공통 파일로 이동한다.

옵션 3: 애플리케이션 레벨에서 pureQuery Runtime 옵션 구성

다른 옵션에서 설명한 바와 같이 글로벌 pdq.properties 파일에 설정된 특성은 JDBC 드라이버의 CLASSPATH에 있기 때문에 이 드라이버를 사용하는 모든 애플리케이션과 이러한 애플리케이션에서 사용하는 모든 데이터 소스에 적용된다. 그러나 데이터 소스에 설정된 특성은 이 데이터 소스를 사용하는 모든 애플리케이션에만 적용된다. 글로벌 설정 및 데이터 소스 레벨 설정의 한계를 극복하기 위해 Optim pureQuery Runtime Version 2.2에서는 웹 애플리케이션을 위해 애플리케이션 레벨 특성 파일이라고 하는 두 가지 새로운 특성 파일이 도입되었다.

이 방식을 선택해야 하는 경우

다수의 애플리케이션에서 n:n 관계로 구성된 다수의 데이터 소스를 사용하는 환경에서 사용한다.

사용 방법

다음 특성 파일 중 하나 또는 모두를 수정한다.

pdq.appwide.properties

이 특성 파일은 특정 애플리케이션에 적합한 pureQuery 특성을 지정한다. 이 파일에서 지정한 모든 특성값은 애플리케이션에서 사용하는 모든 데이터 소스에 적용된다.

pdq.dataSourceName.properties

이 특성 파일은 애플리케이션에서 사용하는 특정 데이터 소스에 적합한 특성을 지정한다. 이 파일에서 지정한 특성은 애플리케이션에서 사용하는 특정 데이터 소스에만 적용된다. dataSourceName은 데이터 소스의 dataSourceName 사용자 정의 특성의 문자열 값이다. 그림 4와 같이 pdqProperties를 설정하는 데 사용한 단계를 사용하여 이 사용자 정의 특성을 설정할 수 있다.

Listing 1에 표시된 바와 같이 특성값을 설정하는 구문은 pdq.properties 파일과 동일하다.

pdq.captureMode = ON pdq.executionMode = DYNAMIC
pdq.pureQueryXml = C:/PDQ_2.2/captureFiles/abc_pdq.xml

하나의 특정 데이터 소스만을 사용하는 특정 애플리케이션에 적합한 특성을 일부 설정하려면 dataSourceName.properties 파일을 사용해야 한다.

이러한 특성 파일을 사용하면 pureQuery 클라이언트 최적화 특성을 애플리케이션과 데이터 소스 레벨에 따라 세분화할 수 있다.

고려사항

애플리케이션에서 pdq.appwide.properties나 pdq.dataSourceName.properties 파일과 같이 특정 애플리케이션에 적합한 특성 파일을 사용하는 경우에는 변경된 사항을 특성 파일에 반영하기 위해 애플리케이션 서버를 다시 시작하는 대신 연결을 제거한다.

위로

애플리케이션 레벨 pureQuery 특성 구성

이 섹션에서는 클라이언트 최적화를 위한 애플리케이션 레벨의 pureQuery 특성과 이러한 특성을 이용하여 애플리케이션과 데이터 소스 레벨에 유연성을 제공하는 방법을 자세히 살펴본다.

애플리케이션 레벨 특성을 추가할 위치

pdq.appwide.properties나 pdq.dataSourceName.properties 특성 파일에 설정된 특성값을 반영하려면 적어도 다음과 같은 위치 중 하나에 이러한 파일을 저장해야 한다.

• 웹 애플리케이션의 WEB-INF/classes 아래
• WEB-INF/lib 디렉토리 아래에 .jar 파일로
• 설치된 애플리케이션 디렉토리 바로 아래

첫 번째 두 가지 옵션은 애플리케이션에 Web 모듈이 있는 경우에는 언제나 가능하다. EJB 애플리케이션에서는 세 가지 위치를 모두 사용할 수 있다.

예를 들어, 애플리케이션 TestClintOptEAR.ear이 WebSphere Application Server에서 전개되었다고 가정하자. 이 애플리케이션은 다음 위치(<WAS_INSTALL_ROOT>/profiles/AppSrv01/installedApps/myNode01Cell/TestClintOptEAR.ear)에 설치된다. AppSrv01은 프로파일 이름이고 myNode01Cell은 노드 이름이다. 이 애플리케이션에는 Web 모듈인 TestClintOpt.war이 포함되어 있다. pureQuery 특성 파일을 설정하기 위한 옵션은 다음과 같다.

옵션 1: pdq.appwide.properties 및/또는 pdq.dataSourceName.properties 파일을 TestClintOptEAR.ear/TestClintOpt.war/WEB-INF/classes 디렉토리에 저장한다.

Web 모듈에만 WEB-INF/classes 폴더가 있으므로 이 옵션은 Web 모듈을 사용하는 애플리케이션에만 적합하다.

옵션 2: pdq.appwide.properties나 pdq.dataSourceName.properties 특성 파일 또는 이 두 가지 특성 파일을 모두 포함하고 있는 prop.jar과 같은 .jar 파일을 작성하여 TestClintOptEAR.ear/TestClintOpt.war/WEB-INF/lib 디렉토리에 저장한다.

WAR 모듈은 이러한 .jar 파일을 WEB-INF/lib 폴더에서 직접 읽을 수 있으므로 클래스 경로에 이러한 .jar 파일의 정보를 추가할 필요가 없다. 애플리케이션을 전개하고 나면 Web 모듈에 WEB-INF/lib 폴더가 생기므로 이 옵션은 Web 모듈을 사용하는 애플리케이션에만 적합하다.

옵션 3: 옵션 2에서 설명한 바와 같이 prop.jar 파일을 <WAS_INSTALL_ROOT>/profiles/AppSrv01/installedApps/myNode01Cell/TestClintOptEAR.ear의 EAR 폴더에 저장한다.

이 .jar 파일을 사용하여 pureQuery 특성을 설정하는 애플리케이션의 모든 모듈에 있는 MANIFEST.MF에 prop.jar의 항목을 추가한다. 예를 들어, <WAS_INSTALL_ROOT>/profiles/AppSrv01/installedApps/myNode01Cell/TestClintOptEAR.ear/TestClintOpt.war/META-INF/MANIFEST.MF에서 TestClintOpt.war 모듈의 MANIFEST.MF를 편집한다. 기본적으로 MANIFEST.MF 파일에는 세부적인 버전 정보만 포함되어 있다. 또한, 이 항목을 prop.jar의 Class-Path에 추가한다. Listing 2에서와 같이 이 항목의 앞, 뒤에 공백을 추가하고 끝에는 리턴을 삽입한다.

Manifest-Version: 1.0
Class-Path: <path>/prop.jar

이러한 형태로 모든 유형의 애플리케이션에 특성 파일을 삽입할 수 있다.

특정 애플리케이션에 적합한 특성을 지정해야 하는 경우에는 사용자가 특성 파일 사본을 하나만 유지해야 하기 때문에 Web과 EJB 모듈이 포함된 애플리케이션에서는 새로운 방식으로 prop.jar 파일을 삽입해야 한다. 애플리케이션의 모든 MANIFEST.MF 모듈에 prop.jar 항목을 추가한다. 특성값을 변경하려면 애플리케이션의 특성 파일 사본 하나만을 편집해야 한다. 애플리케이션에 Web 모듈만 있는 경우에는 편집이 쉽도록 첫 번째 옵션을 사용한다.

위로

예제 시나리오에서의 특성 파일 사용

이 섹션에서는 특성 파일을 사용하여 원하는 동작을 하게 하는 방법을 설명한다.

다수의 애플리케이션이나 데이터 소스를 사용하는 복잡한 웹 환경에서는 모든 데이터 소스를 대상으로 애플리케이션을 다양한 모드로 실행할 수 있어야 한다. 두 가지 애플리케이션 특성 파일에서 특성을 설정함으로써 이와 같이 작동하게 할 수 있다. 애플리케이션에 pdq.appwide.properties와 pdq.dataSourceName.properties 파일이 모두 있으면 애플리케이션은 이 특성 파일을 모두 고려한다. 그러나 동일한 특성이 두 파일에 모두 지정된 경우에는 pdq.dataSourceName.properties 파일을 고려한다.

다음 예제 시나리오에서는 이러한 특성에 대한 사용법을 설명한다. 그림 5에 표시된 바와 같이 예제 시나리오에는 다수의 데이터 소스를 사용하는 두 개의 애플리케이션이 있다.

Application 1

Application 1은 세 개의 데이터 소스를 사용한다. DS1과 DS2는 서로 다른 DB2 데이터베이스에 맵핑되는 반면, DS3는 비DB2 데이터베이스(IBM Data Server Driver for JDBC and SQL를 사용하는 DBMS나 Informix)에 맵핑된다. 관리자는 처음에 pdq.appwide.propertiec 파일에서 captureMode ON을 설정하여 모든 데이터베이스를 캡처할 수 있게 설정했다. 개별 데이터 소스 레벨 특성 파일에는 각 데이터 소스에 맞는 pureQueryXml 파일이 포함되어 있다. 표 2에는 데이터 소스의 구성사항이 표시되어 있다.

DS2에서 모든 SQL을 캡처하고 나면 관리자는 이 데이터 소스를 대상으로 정적 실행을 사용하려고 한다. 그러나 DS1은 여전히 캡처 단계에서 실행해야 한다. 반면에 DS3에서는 정적 SQL이 불가능한 경우에도 관리자가 옵션을 사용하여 캡처된 SQL만 실행될 수 있게 하려고 한다.

DS2의 경우에는 관리자가 DS2를 대상으로 애플리케이션을 정적으로 실행할 준비가 되어 있으며 관리자가 pdq.ds1.properties 파일에서 해당 특성값을 입력하여 captureMode와 executionMode 특성을 대체할 수 있다. 이러한 특성은 captureMode OFF와 executionMode STATIC으로 설정된다. 관리자가 동적 실행을 전혀 허용하지 않고자 할 경우에는 allowDynamicSQL FALSE로 설정할 수도 있다. Listing 3에는 pdq.ds2.properties 파일에서 이러한 값을 설정한 예가 표시되어 있다.

captureMode=OFF
executionMode=STATIC
pureQueryXml=app1_ds2.pdqxml

DS1은 여전히 캡처 단계에 있기 때문에 아무것도 대체할 필요가 없다. pureQueryXml=app1_ds1.pdqxml과 같은 pureQueryXml 파일의 이름만 pdq.ds1.properties 파일에 입력된다.

DS3의 경우에는 동적 SQL을 사용하여 SQL 주입 공격을 차단할 수 있도록 관리자가 pdq.ds3.properties 파일에서 capturedOnly 특성과 captureMode 특성을 Listing 4와 같이 각각 TRUE와 OFF로 설정해야 한다.

captureMode=OFF
capturedOnly=TRUE
pureQueryXml=app1_ds3.pdqxml

Application 2

이 애플리케이션에서는 DS1 하나만 애플리케이션의 데이터 소스로 사용한다. 이 애플리케이션은 원래 캡처 단계를 실행하도록 설정되었다. 관리자는 캡처가 완료되면 정적 실행을 사용하여 애플리케이션을 실행하려고 하지만 애플리케이션을 변경한 다음 이 애플리케이션을 다시 전개하고 싶지는 않다. 두 가지 애플리케이션을 원하는 대로 작동되게 하려면 관리자는 dataSourceName.properties 파일을 사용하여 기존의 애플리케이션 레벨 특성을 대체해야 한다.

애플리케이션을 변경하지 않으면서 DS1을 대상으로 애플리케이션을 정적으로 실행하려면 관리자가 pdq.ds1.properties 파일에 새로운 값을 입력하여 captureMode와 executionMode를 대체해야 한다. Listing 5에는 Application 2에 맞게 설정된 pdq.ds1.properties 파일의 특성값이 표시되어 있다.

captureMode=OFF
executionMode=STATIC
pureQueryXml=app2_ds1.pdqxml

DS1에서는 두 애플리케이션의 pdq.appwide.properties 파일을 사용하여 특정 애플리케이션에 적합한 특성을 설정할 수 있다.

완료된 솔루션

완료된 솔루션에는 두 개의 pdq.ds1.properties 파일과 두 개의 pdq.appwide.properties 파일이 있다. 이 파일은 각기 다른 애플리케이션 아래의 디렉토리에 있기 때문에 각 파일은 해당되는 특정 애플리케이션에만 적용된다.

완료된 예제 솔루션의 경우, Application 1의 파일과 특성은 표 3에 표시되어 있다.

Application 2의 파일과 특성은 표 4에 표시되어 있다.

데이터 소스 DS1에서는 app1.ds1.pdqxml(Application 1용)과 app2.ds1.pdqxml(Application 2용) 파일을 이용하여 DB1 데이터베이스를 사용한다. 데이터 소스 DS2에서는 app1.ds2.pdqxml(Application 1용) 파일을 이용하여 DB2 데이터베이스를 사용한다. 데이터 소스 DS3에서는 app1.ds3.pdqxml(Application 1용) 파일을 이용하여 DB3 데이터베이스를 사용한다.

완료된 예제 솔루션은 그림 6에 표시되어 있다.

위로

결론

이 기사에서는 클라이언트 최적화 프로세스의 개요를 살펴보았으며 애플리케이션 코드를 변경하지 않으면서 이러한 프로세스를 사용하는 데 따른 장점, 특히 DB2 데이터베이스를 액세스하는 기존의 Java 애플리케이션에서 정적 SQL 실행을 사용할 수 있다는 점을 확인하였다. 또한, 다수의 애플리케이션이 다수의 데이터 소스를 공유하는 단일 노드 웹 서버 환경에서 클라이언트 최적화 프로세스(캡처 및 실행 모두)를 지원하기 위해 사용할 수 있는 다양한 레벨의 구성 특성(글로벌, 데이터 소스 및 애플리케이션 레벨)에 관해 살펴보았다.

이 시리즈의 두 번째 기사에서는 더욱 복잡한 내용을 살펴보게 되며 이러한 특성 파일을 사용하여 다수의 웹 서버나 클러스터된 웹 서버를 사용하는 데이터 소스나 애플리케이션을 지원하는 방법을 설명한다.

감사의 글

이 기사의 내용을 검토해 준 Christopher M Farrar 및 Kathryn Zeidenstein, Patrick Titzler에 진정으로 감사드린다.

참고자료

교육

• RSS 피드를 사용하여 곧 공개될 이 시리즈 기사에 대한 소식을 요청하자. (developerWorks 컨텐츠의 RSS 피드에 관해 자세히 확인해보자.)
  
  
• 정적 SQL과 그 혜택을 자세히 확인하려면 "No Excuses" Database Programming for Java"를 읽어본다.
  
  
• Optimize your existing JDBC applications using pureQuery 튜토리얼을 통해 클라이언트 최적화 프로세스에 관해 자세히 배워보자."
  
  
• "Changing connection pool settings with the wsadmin tool"에서 연결을 제거하기 위한 연결 풀 설정 방법을 자세히 확인해 보자.
  
  
• WebSphere Application Server 관리 도구와 이 관리 도구를 호출하는 방법 및 JACL 스크립트를 작성하는 방법에 관해 자세히 배우려면 "Starting the wsadmin scripting client"를 확인한다.
  
  
• System requirements for pureQuery Runtime for Linux, UNIX, and Windows를 참조하자.
  
  
• z/OS에서의 pureQuery 요구사항을 확인하자.
  
  
• 이 기술노트를 참조하여 pureQuery Runtime for Linux, UNIX, and Windows 2.2.0.1의 전제조건을 확인하자.
  
  
• 이 기술노트를 참조하여 pureQuery Runtime for z/OS 2.2의 전제조건을 확인하자.
  
  
• IBM 지원 포털에서 pureQuery와 관련된 설치 및 계획 정보를 확인하자.
  
  
• Integrated Data Management Information Center에서 웹 애플리케이션의 구성과 관련된 제품 문서를 확인할 수 있다.
  
  
• "Integrated Data Management: Managing data across its lifecycle"(developerWorks, 2009년 6월 갱신) 기사를 읽어보자. 이 기사에서는 통합 데이터 관리의 비전과 현실성을 다양한 역할을 통해 설명한다.
  
  
• 하나의 가상 회사에서 Optim 솔루션을 사용하여 어떻게 문제점을 신속하게 판별하고 성능과 개발을 촉진하는지 확인하려면 Demo: Optim solutions for accelerating Java database access를 살펴본다.
  
  
• IDM virtual technical briefings schedule에서 클라이언트 최적화에 관한 자세한 내용을 확인할 수 있으며 등록을 통해 2010년 2월 4일 개최된 클라이언트 최적화 이벤트를 다시 볼 수 있다.
  
  
• developerWorks Optim 제품군 페이지를 참조하여 Optim 솔루션에 관해 자세히 알아 보자. 기술 자료, 사용법 기사, 교육, 다운로드, 제품 정보 등을 찾아볼 수 있다.
  
  
• developerWorks Information Management 영역에서는 Information Management에 대한 정보를 제공한다. 기술 자료, 사용법 기사, 교육, 다운로드, 제품 정보 등을 찾아볼 수 있다.
  
  
• developerWorks 기술 행사 및 웹 캐스트를 통해 최신 정보를 얻을 수 있다.
  
  

제품 및 기술 얻기

• 개발 환경용 30일 시험판을 제공하는 Optim Development Studio와 단일 컴퓨터에서 개발용으로 사용할 수 있는 pureQuery Runtime 링크가 포함된 Data Studio 및 Optim 시험판과 무료 소프트웨어 링크
  
  
• developerWorks에서 직접 다운로드할 수 있는 IBM 시험판 소프트웨어를 사용하여 후속 개발 프로젝트를 구현해 보자.
  
  

토론

• 포럼에 참여하기.
  
  
• Integrated Data Management 전문가 블로그를 확인하고 포괄적인 참고자료와 다운로드 목록이 있는 Integrated Data Management 커뮤니티 공간에 참여하자.
  
  
• developerWorks 포럼 & 블로그를 통해 developerWorks 커뮤니티에 참여하자.
  
  

필자소개

Charul Kapil은 소프트웨어 기술자로 IBM India Software Lab에서 3년간 근무했다. 현재, OPM-Reporting QA 팀에 소속되어 있다. 이전에는 pureQuery Client Optimization QA 팀 구성원이었다.

Jaijeet Chakravorty는 IBM의 소프트웨어 기술자이다. 그는 캘리포니아주 산호세에 있는 IBM Silicon Valley Lab에서 근무한다. Java Common Client JDBC 드라이버, SQLJ 및 pureQuery 클라이언트 측 제품을 담당한다. Jaijeet는 제품 개발에 참여했으며 전세계에 있는 고객에게 L3 지원을 제공한다.

Manoj Sardana는 소프트웨어 기술자로 5년 넘게 IBM India Software Lab에서 근무하고 있다. 그는 DB2 for Linux, UNIX and Windows용 애플리케이션 개발자이자 IBM 공인 고급 관리자이다. 현재, pureQuery 개발 팀에 소속되어 있다. Manoj는 NITK Surathkal에서 전산학 학사 학위를 받았다. 한가한 시간에는 음악을 듣거나 아이들을 돌본다.

아티클 순위

의견

위로

목차

• 소개
• 클라이언트 최적화 프로세스 검토
• 애플리케이션 서버에서 pureQuery Runtime 사용
• 클라이언트 최적화를 위한 pureQuery Runtime 환경 구성 옵션 탐색
• 애플리케이션 레벨 pureQuery 특성 구성
• 예제 시나리오에서의 특성 파일 사용
• 결론
• 참고자료
• 필자소개
• 의견