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의 개념잡기였습니다.
보통 어떤 제품을 프로그래밍한다고 했을 때 핵심이 되는 부분은 단순히 자바나 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의 개념잡기였습니다.
