은서야 서진아 아빠랑 사진 찍자~

JBuilder 4와 EJB (Enterprise JavaBeans)

저 : Todd Spurling, Inprise
편/역 : 백 운기, Inprise Korea

1.EJB 개요

Sun Microsystems가 1998년에 발표한 EJB 1.0 표준 명세에 의하면 EJB는 다음과 같이 정의된다:

Enterprise Java Beans 아키텍처는 객체 지향 분산 엔터프라이즈 레벨 애플리케이션의 개발과 배포를 위한 컴포넌트 아키텍처이다

EJB는 제품이 아니라 표준 명세라는 점을 유의해야 한다. EJB표준 명세를 구현한 많은 상용 제품들의 목록은 http://java.sun.com/products/ejb/tools1.html에 가면 볼 수 있다 그리고 EJB는 분산 엔터프라이즈 컴포넌트들의 개발과 런 타임 환경을 위한 일련의 디자인 패턴이다. 즉 현재의 EJB(Enterprise JavaBeans) 1.1 명세는 자바 서버측 컴포넌트 모델과 어플리케이션 서버를 개발하기 위한 프로그래밍 인터페이스에 대해 정의하고 있다.

여기서 컴포넌트들은 Enterprise JavaBeans로 알려져 있으며 이 안에는 기업에서 사용하는 비즈니스 로직이 포함된다. 엔터프라이즈 자바빈은 트랜잭션 관리(transaction management) 및 보안(security) 등과 같은 서비스를 빈에게 제공해 주는 EJB 서버와 EJB 컨테이너 내부에서 실행된다. 대부분 EJB 서버와 컨테이너는 밴더가 제공하는 상용 제품이며 로우 레벨의 기술을 요구하는 코드를 구현하고 있어서 개발자가 저수준의 복잡한 서비스 제공을 위한 프로그래밍에 대해 신경 쓰지 않고 단순히 조직(기업)이나 시스템의 비즈니스 로직을 빈으로 캡슐화 하는 것에만 집중할 수 있게 해준다. 이렇게 EJB는 개발자들이 빠르게 엔터프라이즈 애플리케이션을 만들 수 있도록 해주는 컴포넌트 아키텍처이다.

또한 EJB는 클라이언트들이 접근하게 될 객체와 메소드들을 기술하는 배포 디스크립터를 갖는다. EJB에서는 이런 디스크립터들이 XML로 작성된다. 그리고 EJB는 자바 클라이언트 애플리케이션 혹은 서블릿, JSP, JavaBean 등과 같은 웹 기반의 클라이언트 메커니즘을 통해 접근할 수 있다.

그림1

EJB와 관련하여 오해의 소지가 있는 것은 EJB를 엔터프라이즈 급 JavaBeans 쯤으로 생각할 수 있다는 것이다. 하지만 EJB는 완전히 JavaBeans와 다르게 생각해야 한다. JavaBeans는 자바 클래스들을 위한 자바 컴포넌트 모델이자 코딩 표준이다. EJB는 엔터프라이즈 컴포넌트를 위한 자바 컴포넌트 모델이며 JavaBeans를 이용해 구현될 수도 있다.

Enterprise JavaBeans에 대해 보다 더 잘 이해하기 위해서는 약간의 배경 지식이 필요하다. 90년대 초, 전통적인 엔터프라이즈 정보 시스템 공급자들은 2 티어(클라이언트/서버 애플리케이션 모델)로부터 보다 유연한 2 티어와 멀티 티어 애플리케이션 모델로 이동하면서 고객의 요구 사항들에 대해 부응하기 시작했다.

클라이언트/서버 모델은 어플리케이션을 개발할 때 즐겨 사용되어 온 것으로 클라이언트 어플리케이션은 로컬 컴퓨터에 위치하고 다른 컴퓨터 상의 RDBMS(관계형 데이터베이스 관리시스템, relational database management system)와 같은 데이터베이스에 저장되어 있는 데이터에 접근한다. 클라이언트/서버 모델은 시스템이 단지 몇 명의 사용자만 가지고 있을 경우 잘 동작한다. 데이터에 접근하는 사용자가 많아질수록 그 요구를 만족시킬 수 없다. 클라이언트가 비즈니스 로직을 포함하고 있기 때문에, 클라이언트 어플리케이션이 반드시 각 컴퓨터에 설치되어야만 하고 이에 따라 사용자가 많아질수록 관리 역시 상당히 복잡해지게 된다. 그리고 엔터프라이즈 애플리케이션의 인터넷과 인트라넷 상에서의 사용이 증가하면서 가볍고 배포가 용이한 클라이언트의 중요성이 가중되었다.

새로운 멀티 티어 모델은 비즈니스 로직을 시스템 서비스와 사용자 인터페이스로부터 분리해서 미들 티어에 위치시킨다. 즉 사용자 인터페이스만 로컬 클라이언트 컴퓨터에 있고, 비즈니스 로직은 서버 컴퓨터의 미들티어에서 실행된다. 물론, 마지막 티어에는 역시 데이터가 위치한다. 예를 들어서 비즈니스 로직이 갱신되어야 할 때, 서버 상의 미들 티어에 있는 소프트웨어만 변경하면 된다.

멀티 티어 모델은 엔터프라이즈 애플리케이션의 개발, 배포, 유지 보수를 극적으로 단순화해준다. 이것은 개발자들로 하여금 비즈니스 로직과 사용자 인터페이스를 위한 클라이언트 쪽 애플리케이션(독립 실행형 및 웹 브라우저 용)의 프로그래밍에 집중할 수 있도록 해준다.

Sun의 JavaTM Software 사업부는 EJB 기술로 나타날 여러 방향의 개발 노력을 기울여 왔다. 먼저, 자바를 기반으로 하는 CGI라 할 수 있는 자바 서블릿 기술이 선보였다. 두 번째로 JDBC 기술이 자바 언어로 데이터베이스 시스템 구축을 가능하게 해주었고 마지막으로 JavaBean 컴포넌트 아키텍처가 전체 기능들을 쉽게 환경 설정 가능하고 재활용 가능한 컴포넌트로 포장하는 것이 얼마나 유용한지 보여주었다. 이런 세가지 개념(자바 언어로 작성되는 서버 쪽 기능 구현, 기존의 엔터프라이즈 시스템에 접근할 수 있도록 해주는 컨넥터, 쉽게 배포할 수 있는 컴포넌트) 의 조합이 EJB 표준을 이끌어 냈다.

2.EJB의 구조와 작동 방식

멀티-티어 분산 애플리케이션은 로컬 머신에서 실행되는 클라이언트, 비즈니스 로직을 포함하고 있는 서버상에서 실행되는 미들-티어, 그리고 엔터프라이즈 정보 시스템(EIS)으로 구성된 백엔드-티어 등으로 구성되어 있다. EIS는 관계형 데이터베이스 시스템, ERP 시스템, 회사에서 사용 중인 기존 시스템, 또는 참조할 필요가 있는 데이터가 저장되어 있는 데이터 저장 장치 등이 될 수 있다. 다음 그림은 3-티어 구조를 갖는 전형적인 EJB 멀티-티어 분산 시스템을 보여주고 있다.

그림 2

EJB 서버와 EJB 컨테이너 모두 빈이 실행될 수 있는 환경을 제공해 준다. EJB가 개발되면 EJB는 EJB 컨테이너에 배포된다.

EJB 컨테이너는 쉽게 말해서 EJB 컴포넌트를 실행하기 위한 런 타임 환경으로서 빈의 적절한 생성과 초기화 그리고 소멸을 책임지고 메소드들이 적절한 트랜잭션 컨텍스트 안에서 실행되도록 보장한다. 그리고 EJB와 그 클라이언트들에게 네이밍 서비스, 디렉토리 서비스, 트랜잭션 서비스, 보안 서비스 및 데이터베이스 연결 등의 서비스를 제공하게 된다.

그림 3

EJB 서버는 엔터프라이즈 빈에게 서비스를 제공하고 엔터프라이즈 자바빈이 실행되고 있는 컨테이너를 관리한다. 즉 EJB 컨테이너를 호스팅하는 애플리케이션 서버이다. 따라서 EJB 서버는 반드시 JNDI 참조 가능한 네이밍 서비스와 트랜잭션 서비스를 사용할 수 있게 구현되어야 한다. 이 밖에 EJB 서버는 추가적인 기능을 제공할 수 있다. 볼랜드의 Inprise Application Server는 EJB 서버의 한 예이다.

그림 4

EJB 컴포넌트를 EJB 컨테이너에 배포할 때 배포 디스크립터(Deployment Descriptor)가 EJB 컴포넌트를 설정하기 위해 사용된다. 배포 디스크립터는 XML 파일로서 EJB 컴포넌트에 대한 설명을 포함하게 되고 배포할 때 파라미터들이 설정될 수 있다. 엔터프라이즈 자바 빈의 이름, 클래스들, 데이터 소스, 트랜잭션 속성들, 환경 변수들에 관한 정보가 여기에 포함된다.

EJB는 두 가지 종류의 인터페이스를 가지고 있다. 하나는 HOME 인터페이스이고 또 하나는 ROMOTE 인터페이스이다. 그리고 EJB는 두 가지 종류의 클래스를 가지고 있다. 하나는 빈 클래스이고 또 하나는 프라이머리 키 클래스이다. EJB를 구현하기 위해서는 이런 인터페이스들과 클래스들을 정의해야만 한다.

엔터프라이즈 자바빈이 EJB 컨테이너 내에 한번 배치되기만 하면, 클라이언트는 빈을 생성하기 위해 홈 인터페이스 내에 정의되어 있는 create() 메소드를 호출한다. 홈 인터페이스는 빈 자체 내에서 구현되지 않고 컨테이너에 의해서 구현된다. 홈 인터페이스 내에 선언되어 있는 다른 메소드는 클라이언트가 빈의 인스턴스를 위치 시키고 더 이상 필요가 없을 때 인스턴스를 제거할 수 있도록 해 준다.

엔터프라이즈 자바빈이 인스턴스로 생성되면, 클라이언트는 엔터프라이즈 자바빈 내의 비즈니스 메소드를 호출할 수 있다. 그러나 클라이언트는 빈 인스턴스 내의 메소드를 절대로 직접 호출하지는 못한다. 클라이언트가 사용할 수 있는 메소드는 엔터프라이즈 자바빈의 리모트 인터페이스 내에 정의되어 있고, 리모트 인터페이스는 컨테이너에 의해 구현된다. 클라이언트가 메소드를 호출할 때, 컨테이너는 요청을 받고 그 요청을 빈 인스턴스에게 전달한다.

이 밖에도 JTA/JTS, JDBC, JNDI 및 기타 다른 Java 2 Enterprise Edition의 API들이 EJB 안에서 사용될 수 있다.

• JTA/JTS는 Java Transaction API / Java Transaction Service의 약자이다. 이들은 EJB 안에서 컴포넌트들 사이의 트랜잭션 그리고 컴포넌트들과 데이터 소스들 사이의 트랜잭션을 위해서 사용된다.
• JNDI는 Java Naming and Directory Interface의 약자로 EJB Home객체를 찾고 트랜잭션을 찾거나 생성하며 환경 정보를 위해 EJB 안에서 사용된다.
• JDBC는 Java Database Connectivity API의 약자이다. 이것은 EJB에서 Entity Bean과 데이터 소스 사이의 데이터베이스 연결 및 처리를 위해 사용된다.

3. EJB 분산 애플리케이션 개발에 있어서의 역할 분담

EJB 분산 애플리케이션을 개발하는 작업은 크게 여섯 가지 역할로 구분할 수 있다. 이렇게 작업을 구분함으로써, 분산 시스템을 보다 쉽게 개발하고 관리할 수 있다.

3.1 애플리케이션 개발

- 빈 개발 : EJB를 생성하고 이 안에 비즈니스 로직을 작성하며 EJB를 위한 리모트 인터페이스와 홈 인터페이스를 정의하고 배포 디스크립터를 만든다.

- 애플리케이션 조합 : EJB를 사용하는 애플리케이션을 작성한다. 이러한 애플리케이션은 일반적으로 GUI 클라이언트, 애플릿, JSP, 서블릿 등과 같은 다른 컴포넌트들을 포함한다. 이런 컴포넌트들이 조합되어 분산 애플리케이션을 이룬다. 이때 EJB 배포 디스크립터에 컴포넌트들의 조합을 위한 명령어들을 추가한다. 이 임무를 담당하는 개발자는 필요한 소드를 호출하기 위해서 반드시 EJB 내에 포함되어 있는 메소드를 잘 알고 있어야 하겠지만 해당 메소드가 구체적으로 어떻게 구현되어 있는지 까지는 알 필요가 없다.

3.2 하부구조

하부구조의 지원이 없다면, 엔터프라이즈 빈과 엔터프라이즈 빈을 사용하는 애플리케이션은 실행될 수 없다. 이런 하부 구조는 대부분 EJB 제품을 개발 판매하는 밴더들에 의해 제공된다. 다음의 두 가지 하부구조가 필요하다.

• EJB 서버
• EJB 컨테이너

3.3 배포 및 모니터링

EJB 분산 애플리케이션 개발의 마지막 단계는 어플리케이션을 배포하고 모니터링 하는 것이다.

- 배포 : 개발한 EJB 분산 애플리케이션을 실전에 배치한다. 배포를 담당하는 개발자는 분산 애플리케이션의 운영 환경을 이해하고 있어야 하며 배포 디스크립터에 적당한 속성을 설정함으로써 트랜잭션 및 보안 정책을 설정할 수 있다.

- 시스템 관리 : 분산 어플리케이션이 배포되면 이것이 제대로 동작하는지 모니터링할 필요가 있다. 애플리케이션이 비정상적으로 동작한다면 적절한 처리를 해야 한다. 이런 일을 시스템 관리자가 담당한다.

4. EJB의 종류

엔터프라이즈 자바 빈의 유형은 다음과 같이 나눌 수 있다:

• Session Bean
  • Stateless Session Bean
  • Stateful Session Bean
• Entity Bean
  • Container-managed Entity Bean
    
  • Bean-managed Entity Bean

4.1 세션 빈

사전적인 의미에서 세션 빈은 그 빈을 생성한 클라이언트의 확장으로 클라이언트를 대신하여 실행된다. 즉 세션 빈은 EJB 서버 내에 있는 클라이언트를 대표한다. 그리고 세션 빈은 상태가 있거나(stateful) 또는 상태가 없는(stateless) 두 종류 중 하나이다. 그리고 세션 빈은 트랜잭션이 가능하고 순간적이다. 순간적이란 말의 의미는 세션 빈이 지속적인 데이터(persistent data)를 나타낼(represent) 수 없다는 것이다. 일반적으로 클라이언트가 세션을 종료할 때 세션 빈은 클라이언트에 의해 제거된다.

상태가 있는 세션 빈은 클라이언트의 상태 정보를 유지할 수 있고 이는 클라이언트를 위한 정보를 계속 유지할 수 있다는 것을 의미한다. 상태가 있는 세션 빈이 사용되어야 하는 것을 보여주는 아주 좋은 예제는 웹 상의 온라인 상점에서의 각 쇼핑을 위한 장바구니(shopping cart)이다. 쇼핑을 하는 사람은 장바구니에 담을 물품을 선택하고 세션 빈은 선택된 물품들의 리스트를 유지한다.

상태가 없는 세션 빈은 특정 클라이언트의 상태 정보를 유지하지 않는다. 상태 정보를 유지하지 않기 때문에 여러(multiple) 클라이언트를 지원하기 위해 사용될 수 있다.

4.2 엔티티 빈

엔티티 빈은 데이터베이스 내에 있는 데이터에 대한 객체 뷰를 제공해 준다. 일반적으로 빈은 관계형 데이터베이스 테이블 셋 내에 있는 열을 표현한다. 즉 세션 빈과는 달리 엔티티 빈은 지속적이라 할 수 있고 지속적인 데이터를 담을 수 있다. 그리고 여러 클라이언트들 사이에서 공유될 수 있다. 모든 엔티티 빈은 빈을 찾고 로드하며 제거하기 위해 사용되는 프라이머리 키 객체(Primary Key Object)를 갖는다. 엔티티 빈에도 두 종류가 있다: Container-managed persistence (CMP), Bean-managed persistence (BMP)

Bean-managed persistence (BMP)는 Bean Provider가 다음과 같은 지속적 메소드들을 구현할 책임이 있는 것을 말한다:

? ejbCreate == insert
? ejbLoad == select
? ejbRemove == delete
? ejbStore == update

Container managed persistence는 EJB 컨테이너에게 지속적인 메소드들을 구현할 책임이 있는 것을 말한다.

5. JBuilder 4 와 Borland Application Server 4.1을 이용한 EJB 개발 단계별 학습 예제

이 학습 예제는 새롭게 JBuilder 4와 Borland Application Server 4.1을 이용해서 EJB를 개발하려는 개발자들이 단계적으로 세션 빈과 엔티티 빈을 만들어 실행시키고 트랜잭션과 클러스터링을 이용할 수 있도록 준비한 것이다. JBuilder 4는 EJB 컴포넌트와 애플리케이션을 개발하기 위한 가장 빠른 툴이다. 여기서는 단계적으로 JBuilder 4의 마법사들과 기능들을 이용해서, 컨테이너가 관리하는 트랜잭션에 참여하는 세션 빈과 엔티티 빈을 만들고 배포하는 방법을 보여줄 것이다. 그리고 Borland Application Server 4.1의 클러스터링 기능 중 하나를 간단히 보여주게 될 것이다.

여기서 설명되는 예제는 Borland Application Server 제품의 기본 예제로 제공되는 'transfer' 샘플을 축소한 것이다. 보다 완전한 코드를 보려면 실제 ‘transfer’ 예제를 참고하도록 한다.

5.1 설치해야 할 것들

이 학습 예제에서 소개하는 단계들을 따라 하기 위해서는 JBuilder 4, Inprise Application Server 4.1, Interbase 5.6 혹은 5.5, InterClient 1.6 혹은 1.51이 필요하다. Interbase와 InterClient 대신 여러분이 사용 중인 데이터베이스와 JDBC 드라이버를 이용할 수도 있다. 그리고 이 문서의 예제는 NT를 기준으로 하고 있다. 다른 운영 체제들을 위해서는 적절하게 디렉토리를 위한 드라이브 문자를 변경하도록 한다.

평가판 제품들을 볼랜드 웹 사이트(http://www.borland.com/)로부터 다운로드 받을 수 있다.

• JBuilder 4 Enterprise : www.borland.com/jbuilder
• JDK 1.2.2 (for IAS 4.1) : java.sun.com
• Inprise Application Server 4.1 : www.borland.com/appserver/download/index.html
• Interbase 5.6 & Interclient 1.6 : www.interbase.com/open/downloads/ib_download.html

5.1.1 JBuilder 4의 설치

이 문서는 기본 설치 디렉토리인 c:\JBuilder4 에 JBuilder 4를 설치한다고 가정한다.

• 먼저 JBuilder Foundations을 설치하고
• JBuilder 4 Enterprise를 설치한다.

5.1.2 JDK 1.2.2와 Borland Application Server 4.1 설치

IAS 4.1을 설치하기 전에 JDK1.2.2부터 다운로드해서 설치한다 - java.sun.com

• JDK1.2.2를 c:\jdk1.2.2에 설치한다.

다음으로 Inprise Application Server 4.1을 설치한다.

• 이 예제는 IAS의 설치 디렉토리가 c:\ias41 (기본 설치 디렉토리가 아님)이고 디폴트 osagent 포트인 14000번이 사용된다고 가정한다.

5.1.3 Interbase와 Interclient 설치

엔티티 빈을 위해서는 데이터베이스에 접근할 필요가 있다. 이 문서는 Interbase 5.5와 Type 3 JDBC 드라이버:InterClient 1.51을 이용한다.

• Interbase를 c:\Program Files\Interbase Corp\InterBase (기본 설치 디렉토리)에 설치한다.
• Interclient를 c:\Program Files\Interbase Corp\InterClient (기본 설치 디렉토리)에 설치한다.

5.2 환경 설정

이제 JBuilder에게 IAS 4.1과 IAS 4.1이 포함하는 VisiBroker 4.1 ORB의 존재에 대해 말해줄 필요가 있다. 다음 단계에 따라 환경 설정을 해주자.

1) JBuilder 4를 시작한다.

2) Tools | Enterprise Setup…메뉴를 선택한다.

3) CORBA 탭에서, VisiBroker를 선택하고 Edit 버튼을 클릭한다

4) Enter the path for ORB tools 란에 IAS 4.1의 bin 디렉토리를 입력한다.

그림 5

5) OK 버튼을 클릭한다.

6) Application Server 탭에서 IAS4.1 installation directory 란에 IAS 4.1 설치 디렉토리를 입력한다.

그림 6

7) OK 버튼을 클릭하고 JBuilder를 다시 시작한다.

이제 IAS 4.1 jar 파일들로 구성되는 라이브러리를 디폴트 프로젝트 옵션에 추가해서 JBuilder가 이 클래스들에 의지하는 프로젝트들을 컴파일할 수 있도록 해야 한다.

1) Project | Default Project Properties… 메뉴를 선택한다.

2) Required Libraries 탭에서 Add… 버튼을 클릭한다.

3) New 버튼을 클릭한다.

4) C:\IAS41\Lib 디렉토리에 있는 모든 jar 파일들을 추가한다.

5) New Library Name을 ias로 설정한다.

6) OK 버튼을 클릭하고 다시 OK 버튼을 클릭한다.

5.3 세션 빈(Session Bean)

여기서는 JBuilder 프로젝트를 만들고 TellerBean이라는 이름의 상태 없는 세션 빈을 만들고 여기에 가상의 은행원 번호를 리턴하는 메소드를 구현할 것이다. 그리고 이 빈에 접근하는 테스트 클라이언트를 만들 것이다. 그리고 나중에 이 메소드를 이용해 각 클라이언트가 연결한 은행원을 알아낼 것이다. 또한 이 빈에 다른 메소드를 추가해서 두 엔티티 빈들 사이의 트랜잭션을 수행하도록 만들 것이다.

5.3.1 세션 빈 개발하기

우선 프로젝트를 만들어야 한다. 다음 단계에 따라 새 프로젝트를 만들도록 하자.

1) File | New Project… 메뉴를 선택한다.

2) 프로젝트 이름과 디렉토리를 quickstart로 설정한다.

3) Root path를 c:/project로 설정한다.

그림 8

4) Finish 버튼을 클릭한다.

이제 EJB Group을 만들 차례다. EJB Group은 Make 때 마다 JBuilder로 하여금 자동적으로 EJB를 포함하는 배포 용 Jar 파일을 만들게 한다.

1) File | New… | Enterprise tab | Empty EJB Group 을 선택한다.

2) 그룹의 Path를 설정한다: 프로젝트의 디렉토리- quickstart라는 jar 파일을 생성할 위치.

그림 9

3) OK 버튼을 클릭한다.

이제 빈을 만들 차례이다. 물론 마법사를 이용한다:

1) File | New… | Enterprise tab | Enterprise JavaBean을 선택한다.

2) Next 버튼을 클릭해서 빈을 앞에서 만든 그룹에 추가한다.

3) Class name을 TellerBean으로 선택하고 Next 버튼을 클릭한다

그림 10

4)인터페이스 이름들은 그대로 두고 Bean home name(JNDI)를 TellerHome을 입력한다.

그림 11

5) Finish 버튼을 클릭한다.

여러분은 이제 프로젝트에 추가된 세 클래스들을 볼 수 있을 것이다. TellerHome과 Teller는 EJB 컨테이너가 구현할 인터페이스이다. TellerBean은 우리가 메소드를 추가할 빈이다. 즉 우리의 비즈니스 로직이다. 여기서는 TellerBean에 다음 메소드를 추가한다:

Public int getTellerNo() {

return 1;

}

Save All버튼을 클릭하고 Make 버튼을 클릭해서 지금까지의 모든 작업을 저장하고 컴파일 하도록 한다.

이제 방금 구현한 간단한 메소드를 리모트 인터페이스에 추가할 필요가 있다. 그렇게 해서 컨테이너가 그 메소드를 노출시켜 클라이언트가 리모트 호출을 할 수 있게 만들어야 한다. Bean 탭의 'Methods' 탭은 JBuilder로 하여금 여러분을 대신해 코드를 작성하게 만들 수 있다:

1) TellerBean.java를 더블클릭한다.

2) Bean 탭을 선택하고 Method 탭을 클릭한다.

3) getTellerNo 메소드 체크 박스를 체크한다

그림 12

Teller.java의 소스코드를 보면 인터페이스에 메소드 선언이 추가된 것을 확인할 수 있을 것이다. 확인할 수 있을 것이다.

이제 EJB의 자바 코드 작성이 끝났다. 배포 디스크립터를 만들고 확인할 차례이다. 배포 디스크립터는 EJB에서 중요한 부분이다. 이것은 배포 설정 사항들을 배포 코드로부터 분리해서 소스 코드 변경 없이도 애플리케이션의 파티셔닝과 튜닝이 가능하도록 해준다.

배포 디스크립터는 이미 프로젝트 안에 마련되어 있다. 이것은 EJB Group 마법사에 의해 만들어 진다. 여러분이 EJB 마법사를 사용했을 때, 마법사는 TellerBean 자바 코드를 자동으로 생성했고 상응하는 엔트리를 배포 디스크립터에 추가했다. 여기에 약간의 변경을 가해 보도록 하자:

1) quickstart.ejbgroup 을 더블 클릭한다.

2) 스트럭처 창에서 TellerBean 을 확장 시키고 Container Transactions을 클릭한다.

그림 13

3) Add 버튼을 클릭하고 transaction attribute의 값으로 ‘Required’를 선택한다.

그림 14

‘Required’ transaction attribute는 이 빈의 모든 메소드들과 인터페이스들에 적용될 것이다.

4) 배포 디스크립터의 설정 사항들에 에러가 없는지 확인하기 위해서 verify 버튼을 클릭한다. 메시지 필드가 에러나 경고를 보여주지 않아야 한다.

Save All버튼을 클릭하고 Make 버튼을 클릭해서 지금까지의 모든 작업을 저장하고 컴파일 하도록 한다.

이렇게 해서 예제 애플리케이션의 서버 쪽 개발이 완료되었다. 이번에는 빈의 getTellerNo를 호출하는 자바 클라이언트를 만들 것이다.

EJB를 위한 테스트 클라이언트를 작성하기 위해 새로운 JBuilder 4의 마법사를 이용해 보자.

1) File | New… | Enterprise tab | EJB Test Client를 선택한다.

2) Class 란에 Client를 입력한다.

3) Generate main function 옵션만 체크한다.

그림 15

4) OK 버튼을 클릭한다.

여기서 생성된 클래스의 생성자에서 ‘TellerHome’을 위한 JNDI 룩업, Naming Context를 인스턴스화 하고 리턴 되는 객체 참조를 TellerHome 타입에 narrow 하는 try 블록을 볼 수 있을 것이다.

5) Try 블록 안에서 위 코드 라인들 다음에 다음 코드를 추가해서 bean을 생성하고 리모트 메소드를 호출한 후 그 결과를 출력한다:

Teller teller = tellerHome.create();
int t = teller.getTellerNo();
System.out.println(“Using teller No: “ + t);

최종적으로 이 클라이언트는 리모트 메소드 호출을 위한 RMI/IIOP 스텁을 필요로 한다.

6) TellerHome.java 를 마우스 오른쪽 버튼 클릭하고 Properties 메뉴를 선택한다.

7) Build | VisiBroker 탭에서 Generate IIOP를 체크한다.

그림 16

8) OK 버튼을 클릭한다.

지금까지의 작업을 저장하고 컴파일하기 위해 Save All버튼을 클릭하고 Make 버튼을 클릭한다.

이렇게 해서 상태 없는 세션 빈의 개발과 테스트 클라이언트의 개발을 마쳤다.

5.3.2 세션 빈 배포하기 - Deployment

이 첫 예제에 대해서는 앞서 만든 빈을 JBuilder 4 내에서 실행해 보겠다.

우선 VisiBroker Smart Agent를 실행해야 한다. Tools | VisiBroker Smart Agent 메뉴를 선택하면 된다.

이번에는 컨테이너를 실행하기 위한 환경 설정을 한다.

1) Run | Configurations… 메뉴를 클릭한다.

2) Default configuration을 편집한다.

3) EJB 탭을 클릭한다.

그림 17

4) OK 버튼을 클릭하고 다시 OK 버튼을 클릭한다

5) 버튼을 클릭해서 JBuilder 4 안에서 컨테이너를 실행한다. 그리고 컨테이너가 초기화 될 때까지 잠시 기다린다.

6) Client.java를 마우스 오른쪽 버튼 클릭하고 Run 메뉴를 선택해서 테스트 클라이언트를 실행한다.

클라이언트의 메시지 탭에 다음과 같은 결과가 출력 되면 성공적으로 메소드 호출이 이루어진 것이다:

C:\JBuilder4\jdk1.3\bin\javaw ?class…
Using teller No: 1

컨테이너의 메시지 탭을 보면 EJB의 상태를 보여주는 임시적인 정보를 확인할 수 있을 것이다.

5.4 Entity Beans

이번에는 Container Managed Persistence Entity Bean을 만들겠다. 이 빈은 데이터베이스에 있는 계좌 정보를 담게 될 것이다. 그리고 다음 섹션에서는 앞에서 만든 세션 빈을 수정해서 이 엔티티 빈의 두 인스턴스에 접근하고 자금을 계좌 사이에서 이체하는 일을 수행하도록 만들 것이다.

엔티티 빈은 지속적인 데이터, 우리의 경우에는 관계형 데이터베이스 안에 저장된 데이터에 대한 객체 표현(Object Representation)이다. Interbase에서 예제 테이블을 만들어 이것의 데이터를 기초로 하고 JBuilder 4의 마법사를 이용해서 CMP 엔티티 빈을 만들도록 하겠다. 애플리케이션을 실행할 때 EJB 컨테이너가 데이터베이스와 빈 사이의 데이터 교환을 위해 필요한 모든 SQL을 구현할 것이다.

우선 Interbase 데이터베이스부터 만들자:

1) Interbase Server를 실행한다.

2) [Interclient] InterServer를 실행한다.

3) Interbase Windows ISQL을 실행한다.

4) File | Create Database… 메뉴를 선택한다.

5) Database Name 옵션에서 Database 란에 c:\project\quickstart\accounts.gdb를 입력한다.

6) UserName은 SYSDBA로 password는 masterkey로 지정한다. 이 때 암호는 반드시 소문자여야 한다.

그림 18

7) OK 버튼을 클릭한다.

8) 상단 메모 박스에 다음 SQL을 입력해서 테이블을 새로 생성한다:

create table account

(

  name VARCHAR(20) NOT NULL,

  balance INTEGER NOT NULL,

  PRIMARY KEY (name)

);

9) 실행 버튼(번개 아이콘)을 클릭해서 쿼리를 실행한다.

10) ISQL을 종료하고 Yes 버튼을 클릭해서 지금까지의 작업을 저장한다.

5.4.1 엔티티 빈 개발하기

JBuilder의 새로운 마법사를 이용해서 엔티티 빈의 코드를 생성하고 이것을 기존 프로젝트에 추가하겠다.

먼저 라이브러리를 생성해서 컨테이너가 실행될 때, InterClient 드라이버가 classpath에 추가되도록 만든다:

1) InterClient의 jar 파일(interclient.jar)을 c:\JBuilder4\lib\에 복사한다.

2) Project | Project Properties 메뉴를 선택한다.

3) Required Libraries 탭을 열고 Add… 버튼을 클릭한다.

4) New… 버튼을 클릭한다.

5) New Library Name 란에 Interclient를 입력한다.

6) InterClient의 jar 파일(interclient.jar)의 위치(c:\JBuilder4\lib\interclient.jar)를 추가한다.

7) 계속 OK 버튼을 클릭한다.

다음으로 InterClient JDBC 드라이버를 JBuilder JDBC Explorer의 classpath에 등록해야 한다.

8) Tools | Enterprise Setup… 메뉴를 선택한다.

9) Database Drivers 탭에서 Add 버튼을 클릭하고 Interclient를 선택한다.

10) 계속 OK 버튼을 클릭한다.

데이터베이스가 제대로 생성되었는지 확인하기 위해서 JDBC Explorer를 사용해 보자:

1) Tools | JDBC Explorer 메뉴를 선택한다.

2) File | New… 메뉴를 선택한다.

3) interbase.interclient.Driver 드라이버를 선택한다.

4) Browse 버튼을 클릭해서 ACCOUNTS.GDB 파일을 선택한다.

그림 19

여기서 URL은 “jdbc:interbase://localhost/C:\project\quickstart\ACCOUNTS.GDB”가 된다.

5) OK 버튼을 클릭한다.

6) 방금 만든 URL을 확장 시킨다.

7) SYDBA와 masterkey를 이용해서 로그인한다.

8) 트리를 확장 시켜서 만들어진 테이블과 컬럼들을 확인한다.

그림 20

9)JDBC Explorer를 닫는다. 변경 사항들을 저장할지 물으면 Yes를 선택한다.

엔티티 빈을 quickstart 프로젝트에 추가하기 위해서 JBuilder의 EJB Entity Bean Modeller를 이용해 보자:

1) File | New… | Enterprise tab | EJB Entity Bean Modeller 를 선택한다.

2) Next 버튼을 클릭해서 빈을 기존의 그룹에 추가한다.

3) step 2에서 데이터베이스(InterClient 드라이버를 이용한 Accounts.gdb)에 로그인한다.

그림 21

4) Next 버튼을 클릭한다.

5) > 버튼을 이용해서 Account 테이블을 선택하고 Next 버튼을 클릭한다.

6) 모든 컬럼들을 사용하도록 선택하고 Next 버튼을 클릭한다.

7) 표준 타입 매핑을 위해 Next 버튼을 클릭한다.

8) 기본적인 클래스 이름과 PK 클래스를 이용하도록 하고 Next 버튼을 클릭한다.

9) Finish 버튼을 클릭한다.

Save All버튼을 클릭하고 Make 버튼을 클릭해서 지금까지의 모든 작업을 저장하고 컴파일 한다.

엔티티 빈 개발이 끝났다. 마법사가 엔트리를 배포 디스크립터에 추가했고 또한 데이터 소스 엔트리도 추가했다. 물리적으로 보면 엔티티 빈은 마법사가 생성한 코드일 뿐이다.

다음에는 이 엔티티 빈에 접근하는 클라이언트를 만들 것이다. 이 클라이언트는 4 개의 엔티티 빈 인스턴스를 생성하고 따라서 accounts 테이블에 4 개의 레코드를 만들게 될 것이다.

이번에도 EJB Test Client 마법사를 이용한다. 하지만 Account EJB에 대한 테스트 클라이언트를 만드는 것이다.

1) 디폴트 클래스 이름인 AccountTestClient1을 그대로 이용하고 generate a main function 옵션을 선택한다.

2) try 블록에서 casting/narrowing 코드 라인들 다음에 아래 코드를 삽입한다:

Account ac1 = accountHome.create("John", 150);
Account ac2 = accountHome.create("Paul", 150);
Account ac3 = accountHome.create("George", 150);
Account ac4 = accountHome.create("Ringo", 150);

3)AccountHome.java에 대한 RMI/IIOP 스텁을 생성한다. AccountHome.java를 마우스 오른쪽 버튼 클릭하고 Properties 메뉴를 선택한 후 Generate IIOP옵션을 체크한다.

Save All 버튼과 Make 버튼을 클릭해서 작업 내용을 저장하고 컴파일 하도록 하자.

5.4.2 엔티티 빈의 배포

테스트 클라이언트를 이번에도 컨테이너 안에서 실행한다.

1) Smart Agent, Interbase, InterServer 가 실행되고 있는지 확인한다.

2) 버튼을 클릭해서 JBuilder 안에서 컨테이너를 실행하고 초기화될 때까지 잠시 기다린다.

3) AccountTestClient1을 마우스 오른쪽 버튼 클릭하고 Run 메뉴를 선택한다.

JDBC Explorer를 이용하면 4 개의 계좌가 생성된 것을 볼 수 있을 것이다.

그림 22

5.5 트랜잭션

지금까지 JBuilder 4를 이용해서 빈을 만들고 테스트해 보았다. 이번에는 컴포넌트들을 하나의 jar 파일에 묶어서 이것을 IAS 4.1에 배포하고 트랜잭션 속성을 설정해 보겠다.

5.5.1 아키텍처

이 Bank 예제 애플리케이션에 새로운 메소드들을 추가해서 트랜잭션 컨텍스트 안에서 한 계좌로부터 다른 계좌로 자금 이체를 수행할 수 있도록 만들어야 한다.

애플리케이션에서, 클라이언트는 세션 빈 상의 “transfer”라는 새 메소드에 대한 리모트 호출을 통해 계좌들 사이의 자금을 이체 시킬 것이다. 클라이언트는 메소드의 파라미터로 이체 신청 계좌의 이름, 대상 계좌의 이름, 금액 등의 값을 전달해야 한다. 세션 빈은 엔티티 빈을 이용해서 계좌를 찾고 트랜잭션 안에서 자금 이체(withdraw, deposit)를 수행하게 될 것이다.

그림 23

5.5.2 엔티티 빈의 수정

엔티티 빈에 자금 이체를 위한 두 개의 새 메소드를 정의해야 한다.

1) 다음 코드를 AccountBean.java에 추가한다:

public void deposit(int amount) {

  balance += amount;

}

public void withdraw(int amount) {

  if(balance < amount)

     entityContext.setRollbackOnly();

  else

     balance -= amount;

}

withdraw 메소드는 계좌에 충분한 금액이 없으면 트랜잭션이 롤백 되도록 한다는 점을 유의하자.

이제 새 메소드들을 리모트 인터페이스에 추가해서 리모트 호출이 가능해지도록 만든다

2) Bean 탭을 선택하고 Methods 탭을 선택한다.

3) withdraw 그리고 deposit 메소드를 체크한다

그림 24

AccountHome 인터페이스를 Rebuild해야 한다.

4) AccountHome.java 를 마우스 오른쪽 버튼 클릭하고 Rebuild 메뉴를 선택한다.

Save All 버튼을 클릭하고 Make 버튼을 클릭한다. 엔티티 빈 수정이 끝났다.

5.5.3 세션 빈의 수정

Teller Session Bean을 수정해서 한 계좌에서 예금을 인출하고 다른 계좌에 입금하는 일을 수행하는 transfer 메소드를 포함시킬 것이다.

1) 다음 코드를 TellerBean.java의 import 절에 추가한다. 이들은 JNDI 접근을 위한 코드 작성에 필요하다.

import javax.naming.*;
import javax.rmi.PortableRemoteObject;

2) 다음 코드(transfer 메소드)를 추가한다.

public void transfer(String accountFrom, String accountTo, int amount) throws RemoteException {

try {

    //naming context 얻기

    Context ctx = new InitialContext();

    // jndi name 룩업

    String homeName = "java:comp/env/ejb/accountdept"; // a logical name to look up in DD

    Object ref = ctx.lookup(homeName);

    //Home interface 변환

    AccountHome accountHome = (AccountHome)PortableRemoteObject.narrow(ref, AccountHome.class);

    // 계좌 찾기

    Account acc_from = accountHome.findByPrimaryKey(accountFrom);

    Account acc_to = accountHome.findByPrimaryKey(accountTo);

    // 이체

    acc_from.withdraw(amount);

    acc_to.deposit(amount);

    }

    catch(Exception ex) {

    ex.printStackTrace();

    throw new RemoteException(ex.getMessage());

    }

}

클라이언트가 필요한 파라미터 값들과 함께 이 메소드를 호출하게 될 것이다. 이 메소드는 JNDI를 이용해서, 배포 디스크립터 안에 AccountHome 인터페이스에 대해 매핑된 논리적인 이름을 찾는다. 그리고 이 메소드는 AccountHome 인터페이스의 findByPrimaryKey 메소드를 이용해 ‘from’과 ‘to’ 계좌를 찾는다. 이 시점에서 우리는 컨테이너 안에 엔티티 빈의 논리적 인스턴스 두 개를 갖게 된다. 그 다음으로 ‘form’ 계좌에 대해 withdraw 메소드를 호출하고 ‘to’ 계좌에 대해 deposit 메소드를 호출한다.

이제 새 메소드들을 리모트 인터페이스에 추가하자.

3) Bean 탭을 열고 Methods 탭을 연다.

4) transfer 메소드를 체크한다.

그림 25

다음으로 TellerHome.interface를 위한 스텁을 Rebuild 한다.

5) TellerHome.java를 마우스 오른쪽 버튼 클릭하고 Rebuild 메뉴를 선택한다.

Save All 버튼을 클릭하고 Make 버튼을 클릭한다. 이제 세션 빈 수정이 끝났다.

5.5.4 기타 설정 사항들

이번에는 세션 빈을 엔티티 빈에 연결하고 트랜잭션 속성을 설정한 후 빈들을 묶는 작업을 처리할 것이다. 즉 EJB 개발 역할 분담에 있어 “EJB 애플리케이션의 조합” 역할에 해당하는 작업을 수행하는 것이다.

1) quickstart.ejbgroup을 더블 클릭해서 배포 디스크립터를 연다.

그림 26

trnasfer 메소드에서 AccountHome 인터페이스를 찾기 위해 논리적 이름을 찾도록 코딩한 것을 기억할 수 있을 것이다. 그 논리적 이름과 실제 인터페이스의 매핑은 배포 디스크립터에 안에서 이루어진다. 그래서 소스 코드를 수정하지 않아도 나중에 파티셔닝이 가능하다. 논리적 이름 java:comp/env/ejb/accountdept 을 Account 빈에 매핑할 필요가 있다.

2) 스트럭처 창에서 TellerBean 을 클릭한다.

3) EJB References 탭을 연다.

4) Add 버튼을 클릭한다.

5) Name을 ejb/accountdept 로 설정하고 OK 버튼을 클릭한다.

6) isLink 체크 박스를 체크한다.

7) Link 콤보 박스에서 Account 를 선택한다.

그림 27

트랜잭션 속성(transaction attribute)를 이용해서 컨테이너가 여러 메소드들을 하나의 작업 단위로 실행하도록 만들 수 있다. 즉 트랜잭션이 가능하다. 배포 디스크립터에서 이렇게 함으로써 트랜잭션 처리를 위한 자바 코드 작성을 생략할 수 있다. 이 예제에서는 컨테이너에게 transfer 메소드를 새로운 트랜잭션 안에서 실행하도록 지시할 것이다. 엔티티 빈의 withdraw와 deposit 메소드는 transfer 메소드를 위해 만들어지는 트랜잭션 컨텍스트를 이용하게 된다.

8) 스트럭처 창에서 TellerBean 항목을 확장 시킨다.

9) Container Transactions 을 클릭한다.

10) transaction attribute를 Requires New로 바꾼다

그림 28

11) 스트럭처 창에서 Account 빈 항목을 확장 시킨다.

12) Container Transactions을 클릭한다.

13) transaction attribute가 Required로 되어 있는지 확인한다

그림 29

배포 디스크립터의 설정 사항들이 제대로 이루어져 있는지 확인해 보자.

14) verify 버튼을 클릭한다. 메시지 필드에 에러나 경고 메시지가 나타나지 않아야 한다.

Save All 버튼을 클릭하고 Make 버튼을 클릭한다.

우리는 프로젝트 내의 모든 빈들이 EJB Group quickstart.ejbgroup에 등록되도록 했기 때문에 프로젝트 내의 모든 빈들이 애플리케이션을 구성하도록 결정한 것이다. 컴포넌트들을 모아서 이들을 하나의 jar 파일(배포 파일)로 만드는 일은 마지막 Make 작업 시 JBuilder에 의해 수행되었다. Quickstart.ejbgroup 노드를 확장 시키고 quickstart.jar 파일을 더블 클릭하면 그 내용을 볼 수 있다.

5.5.5 배포

이제 앞에서 만들어진 jar 파일을 IAS 4.1에 배포해 보자. 즉 이번에는 EJB 개발의 역할 분담에 있어 “EJB 애플리케이션의 배포” 역할을 수행하는 것이다.

1) 컨테이너가 JBuilder 안에서 실행되고 있지 않도록 한다.

2) Interbase와 InterServer가 실행되고 있는지 확인한다.

3) IAS 4.1을 실행한다.

4) JBuilder에서 Tools | EJB Deployment 메뉴를 선택한다.

5) Next 버튼을 클릭한다.

6) Browse 버튼을 클릭해서 quickstart.jar 파일을 선택한다

그림 30

  7) Next 버튼을 클릭한다.

그림 31

8) Finish 버튼을 클릭한다.

애플리케이션이 IAS 4.1에 배포되었다.

"배포” 역할을 수행함에 있어 한 가지 더 할 일이 있다. 컨테이너의 classpath에 interclient.jar 파일을 추가해야만 한다. 엔티티 빈이 InterClient 드라이버를 이용하고 있기 때문이다. 이것은 IAS 콘솔에서 수행할 수 있다.

9) IAS 4.1 console을 실행한다.

10) Application Servers 노드를 확장 시킨다.

11) <server> 노드를 연다.

12) EJB Containers 노드를 확장 시킨다.

13) ejbContainer를 마우스 오른쪽 버튼 클릭하고 Edit Properties 메뉴를 선택한다.

그림 32

14) c:\JBuilder4\lib\interclient.jar 를 classpath에 추가한다.

그림 33

15) Ok 버튼을 클릭한다.

16) IAS를 다시 시작한다.

IAS 콘솔에서 우리의 EJB 컨테이너가 quickstart.jar의 Account 빈과 Teller 빈을 실행시키고 있는 것을 볼 수 있을 것이다. 빈들의 홈 인터페이스들은 JNDI / CosNaming 안에 등록 되어 있다.

그림 34

서버 쪽 컴포넌트들이 배포되었고 준비가 끝났다.

5.5.6 테스트 클라이언트

JBuilder를 이용해서 간단한 클라이언트를 만들어 보자.

1) File | New… | Enterprise tab | EJB Test Client를 선택한다.

2) TellerBean Enterprise JavaBean에 대한 테스트 클라이언트를 만들도록 선택한다.

3) 클래스의 이름은 TransferClient로 지정한다.

4) Generate main function only 옵션을 체크한다.

그림 35

5) try 블록의 끝에 다음 코드를 추가한다:

Teller teller = tellerHome.create();
teller.transfer("John", "Paul", 100);

6) TransferClient.java를 마우스 오른쪽 버튼 클릭하고 Run 메뉴를 선택한다.

JDBC Explorer를 열어 테이블의 레코드를 확인해 보면, John의 계좌로부터 Paul의 계좌로 100이 이체되었음을 볼 수 있다.

그림 36

7) 그 상태에서 클라이언트를 다시 한 번 실행한다.

이번에 withdraw 메소드가 transfer 메소드의 트랜잭션 안에서 실행될 때, John의 계좌에 자금이 부족하기 때문에 트랜잭션이 Rollback only로 설정된다. 그러므로 트랜잭션의 끝에 즉 transfer 메소드의 끝에서 트랜잭션 서비스는 트랜잭션을 저장(commit)할 수 없고 데이터베이스의 데이터가 변경되지 않는다.

6 클러스터링(Clustering)

이번에는 IAS의 클러스터링 기능 중 한 가지를 소개한다.

Inprise Application Server는 VisiBroker 위에서 만들어졌고 ORB의 로드 밸런싱과 fault tolerant 기능을 그대로 가지고 있다. JNDI를 구현한 VisiBroker 4 Naming Service는 클러스터링과 클라이언트들의 자동적인 로드 밸런싱을 위해 사용 될 수 있다.

간단히 말해서, 빈에 대한 동일한 JNDI 홈 이름이 빈에 대한 여러 컨테이너 배포에 사용될 수 있다. Naming Service는 그 홈 이름으로 등록된 홈 인터페이스를 구현하는 각 컨테이너에 대한 참조를 갖는다. 하지만 단지 클라이언트에게 그 이름만을 노출시킨다. 클라이언트가 JNDI에서 그 이름을 찾을 때, Naming Service가 순차적으로 컨테이너에 대한 참조를 넘겨준다. 이로써 간단한 로드 밸런싱이 구현된다.

이 예제에서는 IAS 4.1 안에 두 컨테이너를 실행하고 Bank 애플리케이션을 각자에게 배포할 것이다. 두 번째 컨테이너에 위치할 TellerBean을 수정해서 숫자 2를 리턴하도록 만들고 다시 컴파일 하겠다. 그렇게 해서 로드 밸런싱이 일어나는지 확인해 볼 것이다.

6.1 IAS 4.1 에 또 다른 컨테이너 추가하기

1) IAS 4.1을 종료한다. 도스 창에서 Ctrl-C 키를 누른다.

2) c:\ias41\properties\server\에 ejbcontainer 디렉토리를 ejbcontainer2라는 이름의 디렉토리로 복사한다.

3) 텍스트 에디터로 ejbcontainer2/ejb.properties 파일을 연다.

4) 다음 라인을 찾는다

ejb.jss.pstore_location=ejbcontainer_jss

ejb.jdb.pstore_location=ejbcontainer

5) 다음과 같이 변경한다:

ejb.jss.pstore_location=ejbcontainer2_jss

ejb.jdb.pstore_location=ejbcontainer2

6) 파일을 저장한다.

새로운 컨테이너가 자신 만의 세션 상태 저장소를 이용하도록 만든 것이다.

7) 텍스트 에디터로 ejbcontainer2/service.properties 파일을 연다.

8) 다음 라인을 찾는다:

Service.name=ejbcontainer

9) 다음과 같이 변경한다:

Service.name=ejbcontainer2

이제 IAS 콘솔에서 ejbcontainer2가 나타나도록 만들자.

10) c:\ias41\properties\server\<your server> 디렉토리의 adminster_services.properties 파일을 연다.

11) 다음과 같은 라인의 끝에 ejbcontainer2 를 추가하고 저장한다:

server.service.administer=webpageservice secureservice osagentservice jdatastoreservice visinaming visitransact_tm visitransact_xarf visimessage ejbcontainer ejbcontainer2

server.servicegroup.ejbservices=ejbcontainer ejbcontainer2

12) c:\ias41\properties\server\ 디렉토리의 server.properties 파일을 연다.

13) 다음과 같은 라인의 끝에 ejbcontainer2를 추가하고 저장한다:

Server.service.autostart= osagentservice jdatastoreservice visinaming sessionservice adminservice servermanager webpageservice ejbcontainer ejbcontainer2

Server.service.startorder= osagentservice jdatastoreservice visinaming sessionservice adminservice servermanager visitransact_tm visitransact_xarf visimessage ejbcontainer ejbcontainer2

Server.service.shutdownorder= osagentservice jdatastoreservice visinaming sessionservice adminservice servermanager visitransact_tm visitransact_xarf visimessage ejbcontainer ejbcontainer2

Naming Service clustering을 활성화 하자.

14) c:\ias41\properties\server\<your server>\java.options 파일을 열고 다음 라인을 추가한 후 저장한다(대소문자 구분):

-Dvbroker.naming.propBindOn=1

15) IAS 4.1을 시작한다.

16) IAS 콘솔을 실행한다.

17) 콘솔에서 ejbContainer2 을 마우스 오른쪽 버튼 클릭하고 Start 메뉴를 선택한다.

그림 37

6.2 TellerBean 수정하고 두 번째 컨테이너에 배포하기

어떤 컨테이너에 클라이언트가 연결되었는지 확인하기 위해서 두 번째 컨테이너에 애플리케이션을 배포하기 전에 약간의 수정을 가하도록 하자.

1) JBuilder에서 TellerBean의 getTellerNo( ) 메소드가 2를 리턴하도록 만든다.

2) Save All 버튼을 클릭하고 Make버튼을 클릭한다.

3) Tools | EJB Deployment 메뉴를 이용해서 jar 파일을 ejbContainer2에 배포한다.

4) Client.java를 마우스 오른쪽 버튼 클릭하고 Run 메뉴를 계속 선택해서 여러 번 실행시킨다.

클라이언트를 실행할 때마다 teller No의 숫자 값이 다르게 나타나는 것을 볼 수 있을 것이다. 즉 로드 밸런싱이 이루어지는 것이다:

C:\JBuilder4\jdk1.3\bin\javaw ?class…
Using teller No: 1

C:\JBuilder4\jdk1.3\bin\javaw ?class…
Using teller No: 2