Software Engineer's ToolBox

1. 설치 전 준비사항

시스템에 JDK가 설치되어 있어야 하고, JDK의 디렉토리 위치를 기억해 두어야 합니다.


2. 설치하기

GUI가 지원되는 설치 프로그램을 실행시키고 진행하다보면 다음과 같이 JDK의 경로를 입력하라는 창이 뜹니다. JDK가 설치된 올바른 경로를 입력합니다. 

관리자 패스워드를 넣는 창이 나옵니다. 이 패스워드는 나중에 JEUS를 설정하고 관리할 때 꼭 필요하니 기억해 두어야 합니다. 

3. JEUS 시작하기

3.1. JEUS Manager(노드) 실행하기
JEUS는 콘솔 창에서 <JEUS_HOME>/bin 디렉토리의 실행 파일인 jeus를 실행함으로써 시작합니다. 이 명령은 JEUS 서버를 작동시키고 JEUS Manager를 준비시킵니다.
콘솔의 로깅 메시지가 JEUS Manager is READY로 끝나 있다면 성공한 것입니다.

3.2. JEUS Web Admin 열어보기
JEUS Manager가 실행되고 있다면, JEUS Web Admin을 열어볼 수 있게 됩니다. 웹 브라우저를 통해 다음 주소로 들어갑니다:
http://localhost:9744/webadmin
그러면 로그인 화면이 뜨는데, 아이디는 administrator 이며, 패스워드는 JEUS 설치시 입력했던 패스워드입니다.
로그인에 성공하면 다음과 같은 화면이 나타납니다.

3.3. 노드 살펴보기
일반적인 방법으로 JEUS를 설치했다면, 한 시스템에 노드 하나가 있게 됩니다. 위에서 실행시킨 JEUS Manager 하나가 하나의 노드를 관리하도록 되어 있습니다. 노드라는 개념이 있는 이유는 클러스터링 환경을 고려한 것입니다. 따라서 일반적인 환경에서는 노드를 하나만 사용하도록 합니다. 위 그림에서는 'thendol1' 이라는 이름의 노드가 있습니다. 디폴트 노드 이름은 JEUS가 설치된 머신의 이름을 따릅니다.

3.4. 엔진 컨테이너 살펴보기
노드는 복수 개의 엔진 컨테이너를 가질 수 있습니다. 그러나 엔진 컨테이너 하나에는 수많은 애플리케이션을 배치할 수 있고, 배치된 애플리케이션을 재사용할 수도 있다는 점을 감안하면 특별한 이유가 없는 한 하나의 엔진 컨테이너만 사용해도 충분합니다.
JEUS의 엔진 컨테이너는 Java EE 5 개념잡기에서 설명한 컨테이너와는 설계가 약간 다릅니다. 애플리케이션 및 모듈을 배치하는 대상이 된다는 점에서는 같지만, 엔진이라는 개념이 있어서 어떤 엔진을 탑재시키는가에 따라 어떤 컨테이너의 역할을 하는지 결정되며, 하나의 엔진 컨테이너에 서로 다른 엔진을 중복해서 탑재시킬 수 있다는 점이 다릅니다. 다시 말해, 용도에 따라 다른 컨테이너들이 물리적으로 분리되어 있는 것이 아니라, 엔진 컨테이너 하나로 통합되어 사용된다는 의미입니다. 아래에서 좀 더 자세히 설명합니다.

3.5. 엔진 컨테이너 생성하기
그러면 노드에 엔진 컨테이너를 하나 생성해 보도록 하겠습니다.
노드를 클릭하면 아래 그림과 같이 다섯 개의 하위 항목이 나타납니다. 여기서는 엔진 컨테이너를 추가하고자 하니, 엔진 컨테이너 항목을 클릭해봅니다. 그러면 오른쪽 뷰에 다음과 같이 나타납니다:
위 그림에서는 thendol1_container1이라는 컨테이너가 이미 하나 있는 모양입니다. 컨테이너를 하나도 만들지 않은 상태라면 테이블이 비어 있을 것입니다. 테이블의 오른쪽 아래에 위치한 새 엔진 컨테이너 생성 링크를 클릭합니다:
컨테이너의 이름은 필수 항목이며, 엔진은 적어도 하나는 선택을 해야 합니다. 엔진 없이는 컨테이너가 의미가 없기 때문입니다. 다음은 엔진에 대하여 살펴봅니다.

3.6. 엔진 살펴보기
엔진을 탑재하면, 엔진 컨테이너는 해당 엔진이 제공하는 기능에 따라 Java EE 5에서 지정한 컨테이너의 역할을 할 수 있게 됩니다. 하나의 엔진 컨테이너는 복수 개의 엔진을 탑재할 수 있지만, 동일한 종류의 엔진이 두 개 이상 탑재될 수는 없습니다.
   a) JEUS에서 제공하는 엔진에는 4가지가 있습니다:
      - EJB 엔진
      - 서블릿 엔진
      - JMS 엔진
      - 웹 서버 엔진
엔진 컨테이너로 하여금 아파치 톰캣과 같은 웹 서버 역할만을 하도록 하려면, 이중에서 웹 서버 엔진과 서블릿 엔진을 탑재시키면 됩니다.
주의할 점은, 웹 서버 엔진은 하나의 노드에서 하나의 엔진 컨테이너만이 가질 수 있는데, 위 그림에서는 기존의 엔진 컨테이너에 웹 서버 엔진이 탑재되어 있으므로, 새로 생성하는 엔진 컨테이너의 엔진 추가 테이블에서는 제외된 것입니다.

3.7. 엔진 컨테이너 시작하기
어떤 웹 서버에서는 브라우저로 admin 화면을 볼 수 있으면 곧 애플리케이션을 탑재하여 사용할 수 있다는 의미가 되지만 JEUS에서는 그렇지 않습니다.
JEUS에서는 웹 admin 화면을 볼 수 있다는 것은 단지 JEUS Manager가 실행되고 있다는 의미에 불과하며, 애플리케이션을 배치하여 사용하려면 엔진 컨테이너를 시작해 주어야 합니다.
다시 3.5 섹션에서의 그림을 보면, 오른쪽에 "시작" 버튼과 "다운" 버튼이 있습니다. 여기서 시작 버튼을 눌러 주면 엔진 컨테이너가 시작됩니다.

3.8. One-step Booting 실행하기
JEUS를 사용할 때마다 jeus 명령을 실행한 후에 다시 엔진 컨테이너를 구동하는 방식은 개발 환경이라면 번거로운 일이 아닐 수 없습니다. 다음과 같이 jeus 명령에 사용자 이름과 패스워드를 옵션으로 지정하면 노드가 가지고 있는 모든 엔진 컨테이너를 시작하는 단계까지 한 번에 완료해 줍니다:
jeus -Uadministrator -P<password>
이 명령은 흔히 jboot 라는 배치 파일 혹은 스크립트 파일로 저장하여 사용합니다.

3.9. One-step Down 실행하기
JEUS는 복수 개의 JVM을 사용하므로 애플리케이션 강제 종료 방법(ctrl + C와 같은)을 사용하면 JEUS 재시작시 에러가 발생할 수가 있습니다. 따라서 다음 명령을 사용하여 올바르게 종료해 주어야 합니다:
jeusadmin <node-name> -Uadministrator -P<password> jeusexit
이 명령은 jdown 이라는 배치 파일 혹은 스크립트 파일로 저장하여 사용합니다.

3.10. 엔진 컨테이너 시작 성공 메시지
엔진 컨테이너의 시작에 성공했다면 다음과 같은 메시지를 보게 됩니다:
engine container[thendol1_container1] is READY
engine container[thendol1_container1] initializatioin successfuly done [pid : 3596]
원스텝 부팅을 사용했으면 추가로 다음 메시지를 볼 수 있습니다:
JeusServer one-step booting successful : [thendol1_container1]

1. 기업용 소프트웨어 개발하기

보통 어떤 제품을 프로그래밍한다고 했을 때 핵심이 되는 부분은 단순히 자바나 C 같은 프로그래밍 언어로 만들 수 있습니다. 이것은 학교나 책에서 배운 프로그래밍 언어만 가지고도 만들 수 있구요, 실제로 학교에서 가르치는 부분도 이정도 수준까지라고 할 수 있겠습니다.

그런데 기업용 소프트웨어(애플리케이션)를 구축하거나, 개인적으로 만든 애플리케이션을 다른 사람들이 사용할 수 있도록 하려면 추가적인 기술들이 필요합니다.

우선 아무리 좋은 애플리케이션을 만들었다고 할지라도 기껏해야 문자와 숫자를 보여주는 정도에 그쳐서는 사용자들에게 어필이 안되겠죠. 내부적으로 오고 가는 정보는 문자와 숫자에 불과할지라도, 이것을 시각적으로 보기 좋게 나타내 주는 기술이 GUI라는 것이고, 요즘은 웹이 대세입니다.

그리고 애플리케이션에서 처리해야 하는 데이터량이 너무 많거나, 애플리케이션의 실행과는 별도로 데이터들의 상태를 한 곳에 유지하고 저장해야 할 필요성이 있을 때, 우리는 데이터베이스를 씁니다.

이쯤만 되어도 신경 써야 하는 부분들이 생기기 시작하는데, 가장 중요한 것이 트랜잭션입니다.
사용자가 웹에서 어떤 명령을 내렸을 때, 다시 응답을 받기 위해서는 데이터가 위에서 말한 웹, 코어 프로그램, 데이터 베이스 등을 거쳐야 하는데, 사용자의 입력 데이터와 사용자가 받을 출력 데이터 간에는 실제로는 하나의 함수에서와 같은 input, output 파라미터는 없을지라도, 의미상으로 어떤 데이터의 일관성 있는 흐름이라는 게 존재하게 됩니다.
트랜잭션이란 이렇게 도중에 끊기거나 데이터가 훼손되어서는 안되는 데이터 흐름 처리가 한 덩어리로서 안전하게 수행될 수 있도록 해주는 기술입니다.

이외에도 모듈간 통신을 하는 기술, 사용자의 인증 및 권한 관리와 같은 보안 기술 등이 필요할 때가 있으며, 이러한 것들이 필요해질 때마다 개발자들은 직접 개발하든지, 구입을 하든지, 공개된 소프트웨어를 찾아 헤매든지 해야 합니다.

그런데 이런 짜깁기 식의 프로젝트에서는 트랜잭션도 문제지만 특정 모듈에서의 병목 현상, 모듈간 분리가 되지 않는 경직성, 또는 모듈마다 상이한 프로그래밍 언어와 프레임워크 및 플랫폼을 사용하게 되는 데서 오는 모듈간 통신 및 개발자의 부담 증가 등이 문제가 됩니다.


2. Java EE 5란?

자바 세계에는 JSR 이라는 것이 있습니다. Java Specification Requests의 약자로서, 자바로 구현해 두면 좋을 것 같은 기술들을 전문가들이 모여서 표준화한 것인데, http://jcp.org/en/jsr/all에서 살펴볼 수 있습니다. 여기서 Java EE 5는 244번으로 등록이 되어 있군요.

Java EE 5 스펙은, 이렇게 수많은 JSR 스펙들 중에서 특히 기업용 애플리케이션 개발에 빈번하게 사용되고, 또 사용하면 좋을 것 같은 스펙들을 모아 놓은 통합 스펙입니다. 위에서 설명한 것들과 같은 기업용 애플리케이션 개발 및 운용에 필요한 기술들을 집대성한 것이라고 볼 수 있죠. 명시적으로 주장하고 있지는 않지만, 자바 언어를 주특기로 하는 개발자들이 되도록이면 자바만으로 보다 많은 영역을 개발할 수 있도록 하려는 노력이 엿보입니다. 자바의, 자바에 의한, 자바를 위한 환경을 말이죠.


3. 컴포넌트와 컨테이너

Apache Tomcat을 안다면 설명이 쉽습니다. 톰캣은 웹 컨테이너를 가지고 있는 웹 서버이고, 개발자가 작성해서 디플로이하는 war 아카이브가 컴포넌트입니다.

자바 EE 5에서 정의하고 있는 컨테이너들은 다음과 같습니다. 톰캣은 이중에서 웹 컨테이너만을 가지고 있습니다.

Java EE 5의 설계는 이렇습니다. 무책임하게도 막강한 능력을 지닌 컨테이너의 존재를 가상으로 상정한 채 개발자들에게는 '니들은 컴포넌트만 개발해. 그리고 컨테이너에 탑재하기만 하면 되는거야. 그리고 설정 몇 가지만 해주면 되지. 게다가 컴포넌트는 컨테이너를 죽이지 않은 채로 자유로이 올렸다 내렸다 마음대로 할 수가 있어.' 라고 유혹합니다.

그러면 컨테이너는, 이것을 팔아서 돈을 벌어야 하는, 예를 들면 JEUS를 개발한 TmaxSoft의 WAS실 연구원들 같은 사람들이 죄다 떠맡아서 구현을 해야 되는 것입니다.


4. WAS

WAS는 Web Application Server의 약자입니다. 서버라 함은 Client-Server 모델의 그 서버를 말하는 것이고, 수많은 종류의 서버가 있는데 그 중 애플리케이션 서버라 함은 애플리케이션을 사용자가 각자 가지고 사용하는 것이 아니라 클라이언트의 요청에 따라 서버에서 그 실행을 책임져 준다는 의미가 되겠습니다.

웹 애플리케이션 서버는 애플리케이션 서버 중에서도 특히 웹 환경에서의 클라이언트 요청에 기반을 둔 것을 의미합니다.

WAS의 정의에서는 Java EE 5는 고려돼있지 않습니다. 따라서 WAS가 무조건 Java EE 5 스펙을 지원한다고 생각해서는 안된다는 것이죠. 또한 Java EE 5를 지원하는 WAS를 사용한다고 하더라도 애플리케이션을 반드시 Java EE 5 스펙을 따라서 개발해야 하는 것도 아닙니다. 어디까지나 WAS는 웹 환경에서 접근할 수 있는 애플리케이션 서버를 구축하는 것이 주 임무입니다.

하지만 현실적으로 대부분의 WAS는 Java EE 5 스펙을 지원하고 있습니다. 아니, 처음부터 대부분의 WAS들이 Java EE 5 스펙을 기반으로 설계되고 만들어졌습니다. 거기에 추가적으로 경쟁력을 갖추기 위한 여러가지 기능을 포함하고 있습니다.


5. 4-tier 모델과 Distributed Multitiered Application

기존의 Client-Server 모델을 2-tier 모델이라고 합니다. 그리고 우선 Server 모델에서 데이터 관리를 맡는 EIS(Enterprise Information System) tier를 분리해 냈습니다. DB의 발전과 함께 EIS Tier는 보통 독립된 DB 서버가 맡게 되었습니다. 이것을 3-tier 모델이라고도 합니다.

그리고 나서, EIS tier가 분리되고 남은 tier가 또 둘로 나뉘게 되는데, 하나는 비즈니스 로직만을 전담하는 Business Tier, 또 하나는 웹 클라이언트와의 통신만을 전담하는 Web Tier가 그것입니다.

참고로 위 3번 섹션의 그림에서 Applet 및 Application Client 컨테이너는 Client Tier에 속하고, 웹 컨테이너는 Web Tier에, EJB 컨테이너는 Business Tier에 속합니다.

분산형 다층 애플리케이션(Distributed Multitiered Application)이라고 하는 것은, 하나의 애플리케이션을 이루는 각 모듈들이 이 모델에서 각각 알맞은 tier에 분산되어 들어가 동작하는 형태를 말합니다. 아래 섹션에서 좀 더 자세히 알아보도록 하겠습니다.


6. JAR, WAR, RAR, EAR

자바에서 배포의 단위는 JAR 파일입니다. 물론 .class 파일 하나에 main() 메소드를 두고 실행할 수 있도록 하면 그것도 하나의 애플리케이션이 될 수 있습니다. 그런데 일반적으로 애플리케이션은 여러 개의 클래스파일을 사용하며, JVM에서는 클래스 로더 라는 객체를 사용해서 그 애플리케이션에서 사용할 수 있는 클래스들의 네임스페이스 역할을 하도록 합니다.

JAR 아카이브를 사용하지 않고 자바 애플리케이션을 실행하려면 java 명령어의 옵션으로 CLASSPATH를 일일히 지정해 주어야 합니다. 그러면 클래스 로더는 해당 애플리케이션을 수행하는 데 필요한 클래스들을 CLASSPATH 옵션에 주어진 경로에서 로딩합니다.

그런데, JAR 아카이브는 애플리케이션 수행시 필요한 클래스들을 물리적으로 묶어주는 단위체로서의 역할을 합니다. 즉 JAR 아카이브를 사용하면 지저분하게 CLASSPATH를 지정해줄 필요 없이 어떤 애플리케이션에서 필요한 클래스들의 네임스페이스를 제공할 수 있게 됩니다.

JAR 아카이브는 반드시 main() 메소드를 가지는 클래스가 있어서 단독적으로 수행할 수 있게 할 필요는 없습니다. JAR 아카이브는 단순히 다른 JAR 아카이브의 라이브러리 역할을 하기도 합니다.

WAR, RAR, EAR도 기본적으로는 JAR 아카이브와 같습니다. 여기에 의미와 기능이 추가되는 정도입니다. 우선 WAR 아카이브는 웹 컨테이너에 들어가는 웹 컴포넌트를 의미합니다. 다른 JAR 아카이브들을 내부에 포함할 수 있으며, 반드시 따라야 할 몇 가지 조건들만 지정해주면 됩니다.

톰캣을 사용할 때와 같이 WAR 아카이브를 그 자체로 독립적인 애플리케이션으로 개발한 경우, WAR 파일 단위로 서버에 배치가 됩니다. 이 경우 이 WAR 아카이브를 웹 애플리케이션이라고 합니다.

RAR은 Resource Adapter Archive의 약어로서, Java EE 5 스펙에서는 레거시 시스템에 대한 어댑팅 모듈, 혹은 특정 EIS에 대한 커넥터 아키텍쳐 구현체라고 설명하고 있습니다. 즉, 쉽게 말해 자바에서 곧바로 사용하기 곤란한 리소스들에 대해 어댑터 역할을 하는 모듈이라고 이해하면 되겠습니다.

EAR은 Jave EE 5 스펙의 최상위 애플리케이션 단위입니다. EAR은 하나 이상의 JAR, WAR, RAR 아카이브들을 가질 수 있으며, 사실 이러한 모듈들을 하나로 묶어 준 아카이브에 불과합니다. 실제로 WAS에 배치될 때, 각 모듈들은 흩어져 제각기 자신이 있어야 할 Tier의 컨테이너 안으로 탑재됩니다. 그래서 Java EE 5의 애플리케이션 모델을 분산형 다층 애플리케이션(Distributed Multitiered Application) 이라고 하는 것입니다.


여기까지, Java EE 5의 개념잡기였습니다.