머리말

애플리케이션 서버(app server)는 정보와 서비스를 제공하는 방식으로서 인기를 얻어가고 있다. 사람들이 사용하고 있는 컴퓨터 유형에 상관없이 다른 위치에 있는 사람들에게 정보와 서비스를 제공할 수 있다. 전형적으로 애플리케이션 서버는 데이터베이스나 기타 정보 스토어(백 엔드)와 "3 티어 아키텍처(three-tier architecture)"라는 것을 생성하는 엔드-유저/고객(클라이언트) 사이에 놓여있다. 이 글에서는 Sun의 Java Enterprise Edition (J2EE) 스팩에 순응하는 애플리케이션 서버를 사용하는 시스템을 위한 백 엔드로서 Derby를 설정하는 방법을 설명하겠다. 여기에서 설명했던 설정은 데이터베이스 관리 시스템(DBMS)은 리소스 매니저(Resource Manager)라는 용어를 쓰기로 했다. Derby 데이터베이스용 WebSphere Application Server Community Edition 데이터베이스 풀의 예제가 제공된다.

오늘날 대부분의 애플리케이션 서버들은 다른 유형들도 물론 존재하지만 J2EE 스팩에 기반하고 있다. J2EE 기반 시스템의 인기는 비 상용이라는 점에 기인한다. 이것은 오픈 소스와 오픈 아키텍처 커뮤니티가 발 빠르게 채택해 왔다. 이러한 만능의 서버들은 자바 기능을 물려받아서 "어디에서나 실행된다." 아파치 Derby 엔진 역시 자바로 구현되기 때문에 깨끗하게 통합되고 J2EE 서버가 실행되는 어느 곳에서나 변함없이 실행될 것이다.

애플리케이션 서버를 다뤄봤다면 이 부분은 무시해도 좋다. 이 부분은 애플리케이션 서버 시스템에 대해 간단히 설명하겠다. J2EE 애플리케이션 서버를 한 개 이상의 유용한 자바 기반의 애플리케이션을 실행하는 중간 소프트웨어로서 생각할 수 있다. 이것은 애플리케이션을 지원하고 사람들을 네트워크에 연결시켜 애플리케이션을 안전하게 사용할 수 있도록 하는데 필요한 기술들을 한데 묶는다. 이 애플리케이션 서버는 대부분의 헤비 리프팅(heavy lifting)을 수행하는 미들 티어 컴포넌트를 관리한다. 클라이언트 티어는 일반적으로 웹 브라우저를 사용하여 미들 티어와 통신하는 사람이다. 미들 티어 뒤에서 보호를 받는 것은 비즈니스 시스템이고 주로 데이터베이스를 포함하고 있으며 백 엔드 또는 최근에는 Enterprise Information System (EIS) 티어로 불리고 있다. 애플리케이션 서버 내에서 클라이언트가 실행하는 애플리케이션들은 많은 Application Programming Interfaces (API), Java (J2SE) 루틴, Java Server Pages (JSP), 서블릿 등을 사용하여 작성될 수 있다. 애플리케이션 서버 환경에 정의된 데이터베이스는 API와 관계 없이 애플리케이션에 의해 액세스 될 수 있다. 그림 1은 세 개의 티어와 컴포넌트들을 간단히 묘사하고 있다. 이 글에서는 미들 티어와 EIS 티어를 중점 설명하겠다.

위로

Derby 차이

대부분의 J2EE 애플리케이션들은 데이터를 저장해야 하고, 데이터를 관리하는데 사용되는 가장 일반적인 방식은 JDBC 순응의 데이터베이스를 사용하는 것이다. JDBC 드라이버 인터페이스를 가진 데이터베이스는 서버와 통합되어 J2EE에서 "리소스 매니저(RM) "라고 불리는 것을 구현한다. 이것은 더 큰 시스템의 관계형 데이터베이스 컴포넌트가 될 것이고, 이는 Derby를 칭하는데 일반적으로 사용되는 "임베디드 데이터베이스 "를 의미한다. J2EE 서버에서 구현(삽입)될 때 서버에 구현(전개)된 애플리케이션에 사용할 수 있는 특별한 컴포넌트의 시스템에 또 하나의 툴이 된다.

J2EE 서버는 시스템의 필요에 따라 설정될 수 있는 네트워크 통신과 보안을 제공한다. Derby 엔진은 이러한 기능들을 중복시키지는 않지만 서버 환경에서 이러한 서비스들을 적극 활용한다. 많은 데이터베이스 시스템 바이너리의 코드 대부분이 시스템 보안과 네트워킹을 제공하는데 이는 J2EE 시스템에서는 과잉이다. Derby 풋프린트는 작게 남는다. 라이브러리에는 이 코드가 포함되지 않기 때문이다. J2EE 서버에 삽입될 때 완전한 기능을 하는 JDBC 순응의 리소스 매니저는 하나의 2MB jarfile을 시스템에 추가함으로서 설치된다.

위로

Derby와 J2EE

다음은 Derby를 사용할 때의 이점들을 요약한 것이다. 자세한 내용은 참고자료 섹션의 "Tech Overview"를 참조하기 바란다.

• Derby는 완벽한 기능을 갖춘 관계형 데이터베이스로서 큰 엔터프라이즈 데이터베이스와 견줄만한 기능을 갖고 있다. 작은 사이즈(2 MB)와 비용($0)이 다가 아니다.
• Derby는 완전한 트랜잭션 방식이고 J2EE 서버의 JTA 트랜잭션 매니저와 함께 사용되면 글로벌(분산) 트랜잭션에 참여할 수 있다.
• Derby 데이터베이스 시스템(바이너리와 데이터베이스)은 J2SE JVM을 가진 어떤 플랫폼에도 복사될 수 있고 재구현 또는 다른 대안 없이도 실행될 수 있다.
• 디폴트 설정의 Derby 데이터베이스 시스템을 특별한 관리가 필요 없다. 이 엔진은 J2EE Server JVM 프로세스 내에서 실행되면서 시스템의 일부가 된다.

데이터베이스를 사용하는 애플리케이션을 설계할 때 첫 번째로 해야 할 결정은 데이터에 액세스 하는 방법이다. J2SE는 JDBC 순응의 드라이버를 가진 관계형 데이터베이스에 액세스 하는 두 가지 방식을 제공한다.

1. JDBC 서비스 프로바이더 인터페이스 (SPI) 사용하기 애플리케이션은 JDBC DataSource 인터페이스를 사용하여 데이터베이스로의 연결을 구축한다. 이것이 J2EE 애플리케이션의 액세스 방식으로 선호되는 이유는 여러 가지가 있다.
   • 프로그램 코드가 완전히 데이터베이스에서 독립된다. 드라이버 정보, 데이터베이스 위치, 설정 매개변수들은 J2EE 서버에 의해 저장된다.
   • 커넥션 공유(풀)를 사용할 수 있다. J2EE 서버 커넥션 매니저는 커넥션을 효과적으로 관리하여 퍼포먼스와 확장성을 매우 높인다.
   • 데이터베이스가 Enterprise JavaBeans (EJB)에 의해 사용되어 J2EE 서버의 일부로서 비즈니스 로직을 구현할 수 있다. EJB 티어를 구현하는 것은 (필수는 아니지만) 확장성이 높은 분산 애플리케이션 아키텍처를 구현하는 토대를 놓는 것이다.
2. 애플리케이션 코드에서 직접 사용하기 애플리케이션은 JDBC DriverManager 클래스를 사용하여 데이터베이스 연결을 구축한다. 이것은 독립형(비 서버 기반) 데이터베이스 애플리케이션이 코딩 되는 방식이다. 애플리케이션은 독립적이고 애플리케이션 서버의 정보나 서버에 의존하지 않는다. 애플리케이션도 애플리케이션 서버 JDBC 서버 프로바이더에서 제공하는 확장성과 이식성의 효과를 볼 수 없다.

J2EE 애플리케이션 서버를 사용할 때의 주요 이점은 데이터베이스 액세스에 JDBC SPI를 사용할 때 그 방법을 단순화 한다는 것이다. 대부분의 비즈니스 프로그래머들은 데이터소스와 커넥션 풀 코드를 작성하고 네이밍 서버를 구현하여 JDBC SPI가 사용될 수 있도록 하는데 드는 시간을 증명할 수 없다. 대신 애플리케이션 서버 환경을 설정하는 것이 훨씬 더 효과적이다.

위로

리소스 매니저로서의 Derby

본 섹션에서는 JDBC 서비스 프로바이더 인터페이스(SPI)를 사용하여 J2EE 리소스 매니저로서 Derby를 설정하는 방법을 설명할 것이다. 위에 설명한 이점 외에도 JDBC SPI를 사용하여 Derby 임베디드 드라이버를 지원하면 애플리케이션 서버의 오랜 관행인 보안과 고립화 문제를 피할 수 있다.(서버 내의 리소스 매니저 참조) 관리 리소스로서 데이터베이스의 설정과 사용 단계는 다음과 같다.

1. 데이터베이스를 준비한다.
• RDBMS를 설치한다. Derby의 경우 derby.jar를 서버 디렉토리 트리에 추가한다.
• 필요할 경우, RDBMS를 시작한다. Derby의 경우, 서버가 JDBC 드라이버를 로딩하면 엔진은 자동으로 시작한다.
• 애플리케이션 데이터베이스를 만든다. 주로 데이터베이스의 명령행 툴(예를 들어 IJ)에 의해 처리되는 SQL 명령어들이 포함된 파일을 사용한다.
2. 데이터베이스에 액세스 하기 위해 애플리케이션에 의해 사용될 데이터소스를 정의 및 전개한다. 대부분의 J2EE 서버는 이 시점에서 다음과 같은 일들을 자동으로 수행한다.
   • 객체 이름을 네임 서버로 등록한다. 이 이름은 데이터베이스로 연결을 구축하기 위해 데이터베이스 스팩의 정보를 대신하여 애플리케이션에 사용된다.
   • 커넥션 풀을 설정한다. 이 풀은 애플리케이션에는 완전히 투명하지만 향상된 퍼포먼스와 확장성을 제공한다.
3. 데이터소스/커넥터를 시작하거나 서버를 설정하여 이를 자동으로 시작시킨다.
4. 커넥션에 JDBC DataSource 인터페이스를 사용하여 애플리케이션을 코딩한다. (또는 컨테이너에서 관리되는 영속성(EJB)을 사용하지만 이는 또 다른 문제이다.)

"데이터소스의 정의 및 전개" 단계에서 연결을 구축하는데 필요한 RDBMS와 데이터베이스 스팩의 정보가 제공된다. 이 단계를 완성하는데 필요한 기본 정보는 다음과 같다.

• JDBC 드라이버 라이브러리의 위치와 이름 (예: derby.jar)
• JDBC 드라이버 클래스 이름 (예: org.apache.derby.jdbc.EmbeddedDriver)
• 데이터베이스 커넥션 URL (예: jdbc:derby:JPetstoreDB)
• 매개변수 코드 (대부분의 경우 옵션이다.)

데이터소스 정보가 포착되고 데이터베이스가 전개되는 프로세스는 각 J2EE 서버마다 다양하다. 많은 시스템들은 콘솔 애플리케이션이 있어서 데이터소스의 정의와 전개가 간단해진다. 다음 섹션에서는 IBM WebSphere Application Server Community Edition Administrative 콘솔을 사용하여 데이터소스를 설정하는 방법을 설명하겠다. 다른 서버에서 리소스 매니저로서 Derby를 설정하는 방법은 온라인에서 찾아볼 수 있다. 아래 참고자료 섹션에서 IBM WebSphere, Apache Geronimo, Tomcat 관련 링크를 참조하기 바란다.

위로

WebSphere Application Server Community Edition에 Derby Resource Manager 설정하기

IBM WebSphere Application Server Community Edition (WAS CE)은 Apache Geronimo에 구현된 무료의 경량 J2EE 애플리케이션 서버이다. WAS CE에는 관리 콘솔 애플리케이션이 포함되어 있어서 J2EE 환경에서 자바 애플리케이션의 전개와 관리를 단순화 한다.(참고자료) 다음 단계들은 JPetstoreDB라고 하는 Derby 데이터베이스용 데이터소스를 만드는 과정이다. 이 예제의 경우 전체 데이터베이스가 WAS CE 하위 디렉토리인 ...var/derby에 복사된다. 이 구현은 WAS CE (...repository/org.apache.derby/jars)와 함께 번들되는 Derby 배포판을 사용한다. WAS CE에서 제공하는 Derby jarfile은 알기 쉽도록 재명명되었기 때문에(버전 넘버와 배포자 이름이 추가되었다.) derby.jar 파일은 WAS CE version 1.0.1.1에서는 derby-10.1.2.ibm.jar이다.

1. WAS CE를 시작하고 관리 콘솔에 액세스 한다. (기본 URL: https://localhost:8443/console) 사용자 이름과 패스워드가 필요하다. WAS CE에서 만들어진 기본 사인온 계정은 system / manager이다.
2. 첫 Welcome 스크린에서 왼쪽 Console Navigation 페인에서 Database Pools링크를 클릭한다.
   
   그림 2. WAS CE Console Navigation 페인
   
   
   

2. Database Pools 윈도우에서 Using the Geronimo database pool wizard 링크를 클릭하여 풀 생성을 시작한다. (그림 3)
   
   그림 3. WAS CE Database Pools 페인
   
   
   

3. 데이터베이스 풀 네임으로 JPetstoreDB를 입력한다. Database Type 드롭다운 리스트에서 Derby embedded(Step 1)를 선택한다. Next를 클릭한다.
   
   Step 1. Name과 Database를 선택하기
   
   
   

4. JDBC Driver Class 필드의 값이 org.apache.derby.jdbc.EmbeddedDriver인지를 확인하고 필요할 경우 값을 정정한다. Driver JAR 드롭다운 리스트에서 org.apache.derby/derby/10.1.2.ibm/jar를 선택한다. Database 필드에 DB 이름으로 JPetstoreDB를 입력한다. Next를 클릭한다.(Step 2)
   
   Step 2. Select Driver, JAR, Parameters
   
   
   

5. JDBC Connection URL의 값이 jdbc:derby:JPetstoreDB 인지를 확인하고 필요할 경우 값을 정정한다.(Step 3) Test Connection을 클릭한다.
   
   Step 3. 최종 풀 설정
   
   
   

6. Test Result 필드를 체크하여 연결을 성공했는지를 확인한다. Deploy를 클릭하여 풀 정의를 저장한다.
   
   Step 4. 연결 테스트하기
   
   
   

7. Data Pools Main 메뉴가 새롭게 생성된 JPetStoreDB 풀을 나열하며 디스플레이 될 것이다.

이제 서버에 전개된 애플리케이션이 실제 사용되는 DBMS와 관계 없이 Database Pool 이름을 참조하여 데이터베이스에 액세스 할 수 있다. J2EE 애플리케이션에서 데이터베이스 풀 JPetstoreDB를 사용할 때 특정 정보가 필요하면 풀용 Usage 링크를 클릭한다.

위로

서버 내의 리소스 매니저

위에 설명했던 대로 설정하면 Derby 데이터베이스 엔진은 서버 티어와 EIS 티어 사이에 목적지를 흐린다. 대부분의 RDBMS와는 달리 이것은 애플리케이션 서버 JVM(임베디드) 내에서 실행되는 자바 프로그램이고 고유의 조소 공간에서 실행되는 개별 프로세스가 아니다. 이러한 이유로 애플리케이션 서버의 내부 구현 상세에 민감하고 특히 다중 클래스로더의 구현에 민감하다. 애플리케이션 서버는 다중 클래스로더를 사용하여 동시에 많은 애플리케이션들을 실행하는데 필요한 고립화를 제공한다. Derby 시스템은 클래스들이 모든 애플리케이션 인스턴트 보다는 개별 애플리케이션 인스턴스를 지원하기 위해 만들어진 클래스로더에 의해 클래스들이 로딩될 때 Derby 시스템은 문제가 생길 수 있다. 데이터베이스 엔진 클래스가 다중 클래스로더들 사이로 퍼져나갈 수도 있다. 이것 때문에 데이터베이스 엔진이 정지하거나 예견치 못한 방식으로 실패하고 만다. 데이터베이스는 공유 리소스이기 때문에 클래스로더 계층에서 높이 로딩되어야 하고 애플리케이션은 다른 클래스로더에 Derby 클래스를 로딩해서는 안된다.

클래스로더와 클래스로더 계층은 복잡한 주제이고 설명할 것이 더 많이 있다.(참고자료) 클래스로더가 사용되는 방법은 애플리케이션 서버들 마다 다르다. Derby 드라이버를 직접 로딩하는 애플리케이션은 하나의 서버에 잘 전개된다면 잘 작동한다. 다른 애플리케이션 서버에 전개된다면 같은 애플리케이션은 작동을 하지 않을 것이다. 서비스 프로바이더 인터페이스를 통해 데이터베이스 연결을 구축하면 클래스로더 계층이 관리되는 방식과 관계없이, 애플리케이션은 애플리케이션 서버 환경들 간 이식 가능하다.

애플리케이션 아키텍처에서 서비스 프로바이더 인터페이스를 사용할 수 없거나 데이터베이스 프로세싱 로드를 또 다른 머신에 분산해야 한다면 Derby와 Network Server를 사용할 수 있다. Derby Network Server는 J2EE 서버와 개별 된 프로세스로 Derby를 실행한다. 네트워크 서버는 약간의 복잡성을 시스템에 추가한다. 개별적으로 시작되어야 하고 인증과 보안 정책들이 구현되어야 한다. Derby 네트워크 서버는 다른 JAR 파일들을 사용해야 하고 데이터베이스 커넥션 URL 신택스를 사용해야 한다. Derby 네트워크 서버에 삽입된 Derby 엔진은 다른 데이터베이스 시스템과 마찬가지로 표준 클라이언트-서버 아키텍처에서 실행된다.

위로

요약

많은 J2EE 애플리케이션 서버들이 있고 각각 자바 제품과 서비스들을 고유의 방식으로 번들링 함으로서 스스로를 차별화 하고 있다. 어떤 것을 사용하는지 알 수 있으려면 참고자료 섹션의 "Application Server Matrix"를 참조하기 바란다. 각 서버는 단순화된 인터페이스를 제공하여 다양한 기술들을 사용할 수 있도록 한다. 대부분 여기에서 설명한 것과 비슷한 방식으로 데이터소스와 커넥션 풀의 생성을 제공한다.

대부분의 J2EE 애플리케이션 서버의 또 다른 중요한 특징으로는 서블릿과 Java Server Pages (JSP)를 통해 서버측 프로세싱을 지원한다는 점이다. J2EE 서버 번들에 있는 기타 서비스와 기술들로는 EJB, 커넥터, JMS, JTA 등이 있다. 새로운 기술과 표준들이 구현되면 이들 역시 애플리케이션 서버에 통합될 것이다. 이 기술은 너무 방대하고 빠르게 성장하고 있다. 다른 복잡한 시스템과 마찬가지로 차례차례 J2EE를 경험하는 것이 최상이다. 여기에서 설명한 대로 데이터베이스를 통합하는 것은 J2EE 아키텍처에서 근본적인 부분이다.

기사의 원문보기

• Use Derby in a J2EE Server environment

참고자료

교육

• IBM Cloudscape Technical Resource Center
  
  
• Cloudscape Version 10: A technical overview
  
  
• Use IBM Cloudscape with WebSphere Application Server Community Edition
  
  
• IBM WebSphere Developer Technical Journal: WebSphere Application Server Community Edition 시작하기
  
  
• Using Derby and WebSphere
  
  
• Using Derby and Geronimo
  
  
• Integrate Cloudscape Version 10 or Derby with Tomcat
  
  
• Using IBM Cloudscape 10 with WebSphere 6
  
  
• J2EE Class Loading Demystified
  
  
• The Application Server Matrix
  
  
• The J2EE 1.4 tutorial
  
  

제품 및 기술 얻기

• IBM Cloudscape Version 10.1 출시
  
  
• Get IBM WebSphere Application Server Community Edition
  
  

토론

• 포럼에 참여하기.
  
  

필자소개

아티클 순위

의견

위로

목차

• 머리말
• Derby 차이
• Derby와 J2EE
• 리소스 매니저로서의 Derby
• WebSphere Application Server Community Edition에 Derby Resource Manager 설정하기
• 서버 내의 리소스 매니저
• 요약
• 참고자료
• 필자소개
• 의견