JBoss EAP 6과 친해지기 3탄 - Java 기반 웹 시스템의 이해

1. Java EE에 대한 이해

"Write Once, Run Anywhere" 이것은 이미 아는 것처럼, Java의 이념을 나타낸 슬로건입니다. "한 번 작성하면 어디에서도 실행된다." 이것은 소스 레벨에서의 이동성은 물론, 바이너리 수준에서의 이동성 실현을 의미합니다.

Java Applet은 웹 브라우저에 내장된 Java VM에 의해 다른 플랫폼에서도 하나의 바이너리를 다운로드하여 동작시킬 수 있으며, 서버 사이드의 동작 환경을 구현한 Java Servlet에서도 서버 쪽 플랫폼 이식성을 유지할 수 있습니다. Linux, Solaris 또는 Windows NT 환경이라도 개발자는 소스 파일을 class 파일이라는 바이너리로 컴파일하여 여러 플랫폼에서 동작 시킬 수 있습니다.

엔터프라이즈 수준의 Java 기술에서는 플랫폼 독립성 이외에 또 하나 해결해야 할 중요한 부분은 인프라 서비스에 대한 지원입니다. 웹 애플리케이션은 순수한 애플리케이션 로직 외에도 웹 시스템에서 요구되는 다양한 인프라 서비스를 제공해야 합니다.

예를 들어, 사용자의 요청이 있을 때마다 매번 데이터베이스에 연결하고 끊는 것은 데이터베이스 서버에 부하가 걸리고 무엇보다 응답 시간이 느려지기 때문에, 서비스 이용자의 불만도 커질 수 있습니다. 그래서 이러한 문제를 해결하기 위하여 데이터베이스 커넥션 풀이라는 방식이 등장합니다. 이 경우 먼저 데이터베이스에 대한 커넥션을 풀링해 두었다가 필요할 때 애플리케이션에 할당하고 사용 후 다시 커넥션 풀에 회수하여 재사용하는 구조입니다. 이 커넥션 풀링은 웹 애플리케이션에는 필수 기술입니다. 이런 기능을 표준화된 방법으로 웹 애플리케이션 서버에서 제공하는 것입니다.

이 외에도, 세션 관리, 트랜잭션 관리, 메일 전송, CORBA 및 메시징을 통한 기존 시스템과의 연계, 로드 밸런싱, 가용성 확보와 같은 서비스가 필요하지만 이러한 기술들을 애플리케이션 개발자가 모두 작성하는 것은 매우 많은 노력이 드는 아주 어려운 작업입니다. 애플리케이션 실행에 필요한 시스템 레벨의 서비스를 미리 준비하여 제공하는 애플리케이션 서버 제품이 등장한 것입니다.

애플리케이션 개발자는 애플리케이션 서버 제품을 사용하여 보다 쉽고 빠르게 서버 사이드 애플리케이션을 구축할 수 있습니다. 위에서 예를 든 것과 같은 시스템 레벨의 서비스들을 애플리케이션 서버에서 제공하여 간단한 메서드 호출만으로 사용할 수 있기 때문입니다. 그러나 Java이기 때문에 언어 자체의 시스템 의존성은 없지만, 애플리케이션 서버 공급 벤더에서 제공하는 기능을 사용하다 보니, 개발된 애플리케이션이 애플리케이션 서버에 대한 의존성이 생기는 결과를 낳게 되었습니다. 즉, 벤더 Lock-in 현상이 발생한 것입니다.

최근에는 이러한 문제를 해결하기 위해 등장한 것이 오픈 소스 애플리케이션 프레임워크입니다. 다양한 오픈 소스 프레임워크의 등장으로 Java EE 기술들도 벤더 중심의 표준에서 오픈 소스 중심의 개방형 표준으로 발전하게 되어 엔터프라이즈 시스템에서도 "Write Once, Run Anywhere"를 실현하는 것이 가능하게 되었습니다.

(1) Java EE는 무엇인가?

Java EE 표준이 매우 활성화된 이유는 오늘날의 기업 정보 시스템에서 요구하는 것이 단일한 업무 처리가 아니라 여러 시스템이 결합된 분산 처리 네트워크이기 때문입니다.

IT 버블 붕괴로 정보 시스템 투자 비용 대비 효과가 주목받고 있습니다. 더 적은 투자로 큰 성과를 올리기 위해서 축적되어 온 기존의 데이터와 시스템을 활용해야 합니다. 그래서 지금까지 사일로 형태로 뿔뿔이 흩어져 만들어진 기존 데이터베이스와 시스템을 조합하여 활용함으로써 기업 전체의 생산성을 높여가는 것이 필요하게 되었습니다.

또한, 기업 시스템에서 요구되는 필수 항목은 유연성, 확장성, 안정성 등이 있습니다.

유연성은 표준 변경이나 하드웨어 등 운영 환경이 변경될 때 쉽게 적응할 수 있는 IT 시스템을 의미합니다. 생산성을 높이기 위해서는 업무의 끊임없는 개선이 필요합니다. 또한, 그러한 개선에 고객의 요구사항을 쉽게 반영할 수 있다면, 비즈니스 성과의 향상도 기대할 수 있을 것입니다. 그러나 유연성이 부족한 시스템에서는 이런 개선 요구에 대응할 수 없기 때문에 시간이 지나면 쓰지 않는 시스템이 됩니다.

웹 애플리케이션 서버의 아키텍처 기반을 구성하는 것은 Java EE입니다. Java EE는 Servlet, JSP, EJB 같은 애플리케이션 컴포넌트의 표준 및 RMI, JNDI, JDBC, JTA(트랜잭션 제어), JMS(비동기 메시징), JAXP(XML 파서)와 같은 애플리케이션들이 사용하는 각종 서비스의 표준을 정한 것입니다. "Java EE"는 Java EE 스펙을 구현한 미들웨어 레이어를 의미합니다.

Java EE에서는 애플리케이션이 기존의 시스템과 서비스에 연결하기 위한 표준으로 "Connector"가 정의되어 있습니다. Java EE에서는 레거시 시스템과 서비스를 EIS(Enterprise Information System)라고 부르고 있습니다. 이 아키텍처에서는 Java EE 범위 외의 각종 서비스를 EIS로 분류하고, EJB는 그런 서비스와 Connector로 연결하는 것으로 정의합니다.

확장성은 시스템의 규모가 커니즌 것에 대한 대비책입니다. 대기업이라면 내부 사용자 만도 상당수가 될 것이고, 웹에서 개설한 쇼핑몰 사이트가 인기를 얻으면 사용자는 무제한으로 증가하게 될 것입니다. 이러한 경우 시스템의 확장을 예상하지 않고 시스템이 개발된다면 모처럼의 기회를 놓쳐 버릴 뿐 아니라, 뜻밖의 문제로 기업의 신뢰를 잃을 수 있습니다.

신뢰성은 안정적인 서비스 제공에 있어 빠뜨릴 수 없는 요소입니다. 만일 시스템의 일부가 정지하는 상황이더라도 나머지 서버가 작업을 위임받아 계속 운영할 수 있도록 이중화 구성도 필요합니다.

이러한 상황에서 Java는 특정 운영 환경에 의존하지 않는 점이 매우 중요한 요소입니다. 비지니스의 성장에 따라 자유롭게 하드웨어와 OS를 교체하면서 규모를 확장하고, 시스템 자체도 부품들을 추가하거나 교체하고 확장하는 것이 가능하기 때문입니다.

(2) Java EE와 Java SE와의 차이점은?

Java SE는 우리가 JDK라고 하면, 떠오르는 이미지에 가장 가까운 것입니다. 말하자면 JVM(java Virtyal machine) 버전이라고 할 수 있습니다. 즉, 일반 PC등의 데스크탑이나 서버 환경에서 사용하는 Java입니다.

JDK를 이미 알고 있다면 Java EE는 서버 사이드 API를 가지고 개발하고 운영하기 위한 환경입니다. Java EE는 Java SE와 완전히 다른 API와 VM을 탑재하고 있다는 것이 아니라 Java SE를 기반으로 서버에서 사용되는 API를 제공하는 것입니다.

Java SE에 엔터프라이즈에 필요한 각종 API와 표준 등을 추가한 것이 Java EE인 것입니다.

예를 들면, Java EE에 포함된 API에는

Java Servlet
Java Server Pages
JDBC

와 같은 Java EE 이전부터 이미 개발자들에게 익숙한 API도 포함되어 있으며

EJB(Enterprise JavaBeans)
JNDI(Java Naming and Directory Interface)
JMS(Java Message Service)
JTA(Java Transaction API)
JavaMail

등 엔터프라이즈를 위한 API도 포함되어 있습니다. java SE, java EE는 Java의 실행 속도를 빠르게 하는 HotSpot VM도 포함되어 있습니다.

이들은 각각 독립적인 API로 업데이트가 이루어지고 있으며, 각각 개별적으로 버전이 관리되고 있습니다. 즉, Java EE는 개별적인 API들을 묶어 놓은 표준 스펙입니다.

이렇게 Java EE라는 틀을 만들어 엔터프라이즈에 필요한 API를 서버사이드 애플리케이션의 이식성을 보장하고 애플리케이션 서버 제품을 공급업체에 대한 의존성을 제거해 더 많은 개발자를 확보할 수 있게 되었습니다. Java EE 표준을 준수하는 제품을 이용하는 것만으로 애플리케이션 서버 제품이 바뀌더라도 애플리케이션을 변경하지 않고 운영 환경을 제공하여 EJB와 같은 서버 사이드 컴포넌트의 재사용이 많아지게 됩니다.

Java EE는 Reference Implementation이라는 표본이 되는 동작 환경을 제공하고, Blueprint라는 애플리케이션 모델 샘플을 제공하고 있어 표준화를 진행하기 위한 더 좋은 환경이 갖춰져 잇는 것도 큰 특징 중의 하나라고 할 수 있습니다.

(3) Java EE 6의 새로운 기능들

Java EE(Enterprise Edition)는 기업 정보 시스템 개발의 공통 기반으로 널리 사용되고 있습니다. 1999년에 등장한 "Java EE 1.2"를 시작으로, 2006년의 "Java EE 5"에서 개발 편의성을 대폭 확대하는 여러 가지 표준이 포함되었고, 2009년에는 Java EE 5를 대폭 개선한 "Java EE 6"를 출시하였습니다.

특히 JBoss의 주요 기술들인 "JBoss Seam", "JBoss Hibernate", "CDI(Web Beans)" 등 각종 오픈 소스 프레임워크의 장점을 표준화한 것이 새로운 Java EE 6 표준이라 할 수 있습니다.

Java EE 5의 부정적 요인을 모두 보완한 Java EE 6는 CDI(Contexts and Dependency Injection : 이전 WebBeans)의 등장으로 모든 클래스에 DI(Dependency Injection) 및 AOP(Aspect Oriented Programming)가 가능하며, 템플릿 엔젠(Facelets)의 표준화 및 AJAX를 사용할 수 있게 되어 기업 시스템이 요구하는 기능을 충족할 수 있게 되었고, "Pessimistic Locking"이나, 보안을 위한 "공통 평가 기준(Common Criteria; ISO / IEC 15408)"을 지원함으로써 미션 크리티컬한 시스템에도 적용할 수 있게 되었습니다.

최근 클라우드 환경으로 변화해가고 있는 추세인데, 이런 환경에는 Java EE 6 및 Java SE 7을 도입하는 것을 권장합니다.

① Java EE 표준 발전 방향

Java EE는 지금까지 다양하고 새로운 기술들을 가져와 표준화하면서 발전해 왔습니다. Java EE의 첫 번째 표준이 나온 이후 오랜 시간이 지난 지금은 그 발전과정 속에서 이젠 사라져 버린 기술도 있습니다.

이전의 Java EE 표준 버전들은 과거의 표준들과 호환성을 유지하였지만, Java EE 6에서는 과감히 과거의 표준들을 제거하는 것으로 방침을 정했습니다. 따라서 JAX-WS로 대체된 JAX-RPC(Java API for MXL-Remote Procedure Call)와 JPA로 대체된 "EJB2.x CMP EntityBean"이 표준에서 제거되었습니다.

또, Java EE 6에서 '프로파일"이라는 방식을 도입하여 Java EE의 서브셋을 만들 수 있는 구조를 정의하여 Java EE 보다 더 가벼운 구조에서 애플리케이션을 운영할 수 있게 되었습니다.

그 시작으로 Java EE 6에서 "Web Profile"이라는 프로파일을 제공하고 있습니다. Web Profile은 Servlet과 JSP 등 웹 애플리케이션에 필요한 표준을 묶어서 제공합니다. 현재는 EJB의 경량 버전과 JSF, CDI 등이 포함되어 있습니다.

② JPA 2.0

기존의 Java EE에서 빈(Bean)과 데이터베이스 테이블의 데이터 맵핑을 맡고 있었던 "Entity Bean"은 너무 사용하기 불편했었습니다. 그래서 EJB 3.0에서는 Entity Bean 대신 개발자들이 많이 사용하는 JBoss Hibernate를 표준화한 새로운 O/R 맵핑 프레임워크로 "Java Persistence API(JPA)"가 채택되었습니다. Java EE 6에서는 JPA를 EJB와 다른 새로운 표준으로 독립하여 "JPA 2.0"이 되었습니다.

JPA 2.0에서는 기존 쿼리언어인 JPA-QL이 구현 방식에 따라 달라서 기존 JPA에서 사용이 힘들었던 것을 표준화하여 편리하게 확장할 수 있도록 하였습니다. 또한, JSR-303에서 표준화된 "Bean Validation"을 이용한 빈의 입력 값 검증 기능도 포함되었습니다. 쿼리 방법에 대해서도 기존 JPA-QL 쿼리문을 통한 검색뿐만 아니라 API를 사용하여 조건을 작성하는 "Criteria Query" 기능이 추가되었습니다.

패키징 방법도 "persistence.xml"을 기존에는 EJB jar에만 패키징할 수 있었지만 이제 클래스 패스에 배치할 수 있게 변경되었습니다. 따라서, EJB를 별도로 패키징하지 않고 WAR내에 포함할 할 수도 있게 되었습니다.

③ Servlet 3.0

지금까지 Java EE에서는 큰 개선이 되지 않은 부분이 Servlet 표준이었지만, Java EE 6에서느 크게 개선된 "Servlet 3.0"이 포함되었습니다.

Servlet 3.0에서는 어노테이션을 사용하여 Servlet에 대한 메타 데이터를 기술할 수 있습니다. 이 항목들은 지금까지 필수였던 "web.xml"에 포함되는 내용으로, "web.xml" 파일 없이 어노테이션만으로 웹 애플리케이션을 작성할 수도 있습니다. 또한, 기존에는 HttpServlet 클래스와 같은 Java EE 표준 API를 상속하여 Servlet을 만들었지만, Servlet 3.0 어노테이션은 Servlet 클래스가 아니어도 원하는 메소드에 @GET, @POST와 같은 어노테이션만 지정하면 Servlet이 되었습니다.

Servlet 3.0에서는 Servlet도 POJO(Plain Old Java Object)화 되었습니다.

④ JSF 2.0

JavaServer Faces(JSF)는 Java EE에 포함된 표준 웹 애플리케이션 프레임워크로 Java EE 5에서 Java EE에 포함되었습니다. Java EE 6에는 "JSF 2.0"이 포함되었습니다.

현재의 웹 애플리케이션은 HTML만으로 만들어진 사용자 인터페이스가 아니라 JavaScript 등을 이용한 대화형 사용자 인터페이스가 대부분입니다. 이러한 기능을 구현하기 위해 JavaScript로 만들어진 AJAX 라이브러리를 제공하고 있습니다. Java EE는 주로 서버 측 Java 기술이기 때문에 클라이언트 측 JavaScript는 표준의 범위를 넘어서는 것일지도 모르지만, JSF 2.0에서는 AJAX 라이브러리를 사용하여 사용자 인터페이스를 컴포넌트화하기 위한 구조를 제공하고 있습니다.

또, 사용자 컴포넌트 제작 방법이 간편해졌고, Facelet 통합, RESTful한 URL 표기 방법 등의 기능이 포함되었습니다.

⑤ CDI(WebBeans)

Java EE 5에서는 EJB 3.0에 Dependency Injection(DI) 개념이 도입되었고, EJB 컨테이너는 DI 컨테이너 기능을 갖게 되었습니다. 한편, 웹 인터페이스 계층에도 표준 프레임워크로 "javaServer Faces(JSF)"가 도입되었습니다. Bean도 컨테이너가 참조 객체를 주입할 수 있는 DI 컨테이너로서의 기능을 갖게 되었습니다. Java EE 세계에는 이미 두 개의 DI 컨테이너가 있고, 거기에 맞춘 프로그램 모델을 제공하고 있습니다.

CDI는 이 두 개의 컨테이너를 통합하고, 통합된 프로그래밍 모델을 제공하기 위한 표준입니다. CDI를 사용하면 jSF 페이지에서 EjB Bean의 메소드를 호출할 수 있습니다. 이렇게 되면 웹 애플리케이션을 작성할 때 만들어야 할 코드를 훨씬 더 줄일 수 있습니다.

또한, CDI 애플리케이션, 세션, 요청 등 기존의 범위에 "대화 범위(Conversation Scope)"가 추가되었습니다. 사용자의 입력 값들을 다음 페이지에서 받으려면, 요청 파라미터로 계속 넘겨 처리하거나, 세션에 보관하여 처리해야 했습니다. CDI의 새로운 "대화 범위"를 사용하면 일련의 페이지에 걸쳐 사용자가 입력한 값들을 쉽게 관리할 수 있습니다.

⑥ JAX-RS

외부에 서비스를 제공할 때 HTTP 방식을 이용한 RESTful 웹 서비스를 API로 공개하는 방법이 최근 많이 사용되고 있습니다. Java EE에도 이와 같은 RESTful 서비스를 만드는 API로 "Java API for RESTful Web Services(JAX-RS)"를 제공합니다.

JAX-RS에서도 Java 코드에 @Path, @GET, @POST와 같은 어노테이션을 사용하여 RESTful 서비스를 만드는 코딩 방법을 제공합니다.

(4) MVC 모델

Java EE의 개발에 있어 핵심 중에서도 핵심인 키워드가 있는데, 그것이 MVC입니다.

MVC는 Model, View, Controller의 약자로, 객체 지향을 적용하는데 있어 검증된 기본 모델입니다.

객체 지향에서는 다양한 클래스를 정의하고, 객체를 결합하여 시스템을 구축하고 있습니다. 클래스들은 복잡하게 흩어져 있는 것이 아니라 일반적으로 명확한 역할에 따라 그룹화됩니다. MVC는 그 역할을 구분하는 방법입니다.

Model은 시스템이 처리할 데이터와 동작을 표현하기 위한 그룹입니다. 모델에는 데이터를 보관하고, 데이터 간의 관계를 관리하는 메커니즘을 구현합니다. 말 그대로 시스템의 핵심이 되는 부분입니다.

View는 데이터를 시스템 외부에 표현하는 역할을 담당합니다. 동일한 데이터도 출력하는 대상에 따라 모양을 바꿔야 하는 경우가 많이 있기 때문에 Model과 분리하여 생각하는 것이 좋습니다.

Controller는 시스템 외부에서 데이터 및 작업 입력을 담당합니다. Controller도 모든 입력에 대해 준비해야 하기 때문에, 가능하면 Model과 View의 상세한 부분에 의존하지 않도록 합니다.

이들은 대개 여러 클래스가 결합된 형태로 구성됩니다. 그리고 구성요소 간에 서로 클래스나 메소드의 접근을 제한하여 종속성을 제한할 수 있습니다.

Java EE는 MVC 아키텍처를 채택하여 매우 높은 유연성과 확장성을 제공합니다. 화면 변경 등이 자주 발생하더라도 View 부분만 다시 만들어 추가하기만 하면 되기 때문에 Model에 미치는 영향은 아주 적습니다.

또한, 데이터의 저장 방법 및 값 계산 방법 등 시스템의 주요 로직이 변경되는 경우에도 화면이나 사용자의 조작 방법 등 View와 controller 부분은 변하지 않기 때문에 업무 절차가 변경되거나 운영자를 재교육해야 하는 등 비용이 증가하거나 또 다른 문제가 생길 가능성을 줄일 수 있습니다.

이러한 장점 때문에 MVC는 Java EE의 멀티티어 아키텍처를 지원하는 본질적인 개념이 되고 있습니다.

① MVC 학습 순서

MVC에 대한 이해도 매우 중요하지만 처음부터 이 세가지를 동시에 배운다는 것은 효율적이지 않습니다. 하나 하나 차례로 배워가는 것이 더 나은 방법일 것입니다. MVC는 각각 독립적이면서 연계하였을 때 더 큰 효과가 발휘됩니다. 그래서 처음에는 개별적으로 배우고, 마지막에 연계하는 방식이 더 이해하기 빠른 방법일 것입니다.

View, Controller, Model의 순서로 배우는 것이 좋습니다. 어떤 프로그램 언어라도 맨 처음 배우는 것이 화면에 "Hellow, World!"라고 출력하는 것이었을 것입니다. 그 이유는 화면에 무언가 보여주는 것이 결과를 확인하기 가장 쉬운 방법이기 때문일 것입니다. View를 처음에 공부하라는 것도 이 때문입니다.

그 다음에 입력을 담당하는 Controller를 배우고, 마지막에 Model을 배우게 됩니다. 그 이유는 Model의 동작으 확인하기 위해서는 입출력을 담당하는 View와 Controller가 필요하기 때문입니다.

② MVC와 V와 C

Java EE의 경우 MVC 중 View와 Controller는 주로 웹 인터페이스로 만들어집니다. 웹 인터페이스를 지원하는 Java EE 표준은 JSP(Java Server Pages)와 서블릿(Servlet)입니다. 이들은 모두 미들웨어 서버에서 실행되는 Java 모듈입니다.

기술이 개발된 순서를 보면, 먼저 서블릿이 만들어졌고 그것을 개선하여 JSP가 만들어졌습니다. 이 두가지 기술은 매우 가까운 관계입니다. 그래서인지 이들 두 표준의 역할을 혼동하여 한 번 사용하고 버리는 경우가 많습니다. 역할을 혼동하여 사용하면 매번 새로운 코드를 만들게 되어 하지 않아도 될 고생을 더 하게 됩니다. 그래서 View와 Controller라는 본질을 확인할 필요가 있습니다.

③ View로 JSP

JSP는 Java EE 시스템에서 만든 데이터들을 HTML 코드 속에 작성하여 웹 브라우저에 출력하는 것입니다. 즉, 겉모양은 HTML이고 그 안에 Java 코드를 삽입하는 형태로 작성하는 코드입니다. 이 점에서는 Controller를 담당하게 될 서블릿 Java 코드에 print 메소드의 형태로 HTML을 삽입한 것과는 반대로 HTML로 작성되는 JSP 코드에 Java 코드를 삽입하는 형태로 작성합니다. JSP 파일은 일단 서블릿 소스 파일로 변환된 후 컴파일 됩니다. 즉, JSP는 서블릿 코딩을 개발자, 코더에게 친숙한 HTML 형태로 작성하기 쉽게 개선한 것입니다.

JSP는 일반적인 Java 코드와 달리 컴파일할 필요가 없습니다. 웹 애플리케이션 서버에서 접근할 수 있는 위치에 JSP 파일을 넣으면 처음 호출할 때 웹 애플리케이션 서버가 자동으로 컴파일합니다. 이러한 편리함 때문에 JSP가 Java EE를 처음 배울 때 좋은 시작점이 됩니다.

JSP에는 Java가 가지는 객체 지향적인 특징이 잘 드러나지 않습니다. 이런 특징 때문에 화면을 개발하는 HTML 작업을 HTML 코더나 웹 디자이너가 전담할 수 있게 되었습니다. JSP에 많은 코드를 작성하게 되면 객체 지향을 떠나서 아주 읽기 어려운 코드가 될 가능성이 높습니다. 디자인 및 HTML 코딩 작업의 효율도 떨어지게 됩니다. 따라서 JSP는 View에만 사용하고, 화면 이외의 처리는 가능한 Controller와 Model에서 처리하는 것이 좋은 방법입니다.

④ Controller 서블릿

서블릿은 JSP와 마찬가지로 웹 애플리케이션 서버에서 동작하는 Java 클래스입니다. 서블릿은 웹 애플리케이션 서버에서 웹 인터페이스를 제공하는 것 이외에는 일반 클래스와 다를 바 없습니다. 그래서 JSP에 비해 복잡한 처리를 쉽게 할 수 있습니다.

서블릿은 사용자 입력에 응답 처리를 작성하는데 유용합니다. 즉, Controller의 역할인 셈입니다. 물론, 서블릿에서도 웹 페이지를 생성할 수 있지만 복잡한 화면을 만들게되면, print 메소드가 너무 많아지게 되어 HTML의 코드를 작성하고 유지 보수하기가 매우 어렵습니다.

일반적으로 웹 페이지나 입력 양식 등의 화면 출력은 View와 JSP에서 처리하고, 일력 데이터 확인 및 입력에 따른 처리 등을 서블릿에서 처리하면 효율적으로 개발할 수 있습니다.

⑤ Model로서의 EJB

View와 Controller가 작성되어 합쳐지면 시스템의 형태는 준비됩니다. 사실 간단한 웹 애플리케이션이며, JSP 내에서 JDBC를 통해 데이터베이스에 접근하는 것도 쉽게 만들 수 있습니다.

그러나 처리의 복잡성과 데이터의 양이 늘어나게 되면 곧 한계에 도달합니다. JSP와 서블릿 모두 웹 애플리케이션 서버에서 동작하기 때문에, 한 곳에서 모든 것을 처리하는 형태입니다.

이러한 문제를 해결하기 위하여 데이터 처리의 중심이 되는 Model이 필요합니다. EJB(Enterprise Java Bean)는 데이터베이스 작업을 중심으로 데이터 자체를 관리하는 Model 부분을 담당하는 표준입니다. EJB의 주요 특징 두 가지는 컴포넌트 지향, 분산객체입니다. 컴포넌트 지향은 여러 컴포넌트들을 쉽게 조합하여 사용할 수 있도록 하는 프로그램 단위입니다. 자유로운 조합을 위해서는 어느 정도 결정된 기능과 데이터를 제공해야 하기 때문에 일반적으로 여러 개의 클래스로 구성합니다.

분산객체는 다른 프로세스나 다른 컴퓨터에서 실행 중인 객체에 접근하는 기술을 말합니다. 일반적으로 객체는 동일한 프로세스에 있는 오브젝트들에만 접근할 수 있지만, 분산 객체는 네트워크 통신을 통해 서로 다른 서버의 객체에 접근할 수 있습니다.

부하가 많은 시스템에서는 원격의 EJB만을 처리하는 서버를 구성하여 사용할 수도 있지만, 최근에는 원격 EJB를 호출하는 데 필요한 네트워크의 부하보다는 View, Controller가 있는 미들웨어 로컬의 EJB를 호출하는 것이 훨씬 빠르기 때문에 Model, View, Controller를 한곳에 두는 것이 더 일반적입니다.

⑥ 웹 환경에서 세션관리

웹 환경에서는 웹 브라우저와 웹 애플리케이션 서버 간에 세션을 관리해야 하는 문제가 있습니다. HTTP 프로토콜 자체가 상태가 유지되지 않는 프로토콜이기 때문에 웹 서버에 접근하는 사용자를 식별하는 정보를 유지할 수 없습니다. 여러 페이지로 화면 전환이 필요한 웹 애플리케이션은 사용자를 구분할 수 있어야 합니다. 그렇지 않으면 쇼핑몰 사이트에서 화면이 바뀔 때마다 그 상품을 선택한 사용자가 누구인지 알 수 없게 되고, 온라인 뱅킹에서 타인의 계좌를 볼 수 있는 문제가 발생될 수 있습니다.

세션은 개별 사용자를 식별하고, 상태가 없는 사용자들의 요청을 사용자와 맵핑하여 관리합니다. 즉, 서버에는 세션이 만들어지고, 웹 브라우저에는 세션ID와 같은 값을 갖는 세션 쿠기가 만들어져 사용자 요청마다 세션 쿠키값을 헤더에 담아 보내면 서버에서는 그 요청을 보낸 사용자를 식별할 수 있습니다. Java EE에서는 이러한 세션관리를 위한 API를 제공하고 있습니다. 세션 관리는 웹 애플리케이션과 웹 애플리케이션 서버에서 매우 중요합니다.

⑦ MVC 프레임워크, 개발 방법론

MVC를 염두에 두고 처음부터 시스템 설계를 하는 것은 경험도 많이 필요하지만 매우 어려운 기술들이 필요합니다. 그래서 실제로는 MVC를 지원하는 프레임워크 중 하나를 선택하여 사용합니다. 프레임워크는 건축의 토대와 골격에 비유됩니다. 구축할 시스템의 처리 흐름과 화면 등이 준비되어 있어 필요한 부분을 만들고 통합해 나가는 형태로 사용합니다.

라이브러리 등이 시스템의 부품을 재사용하는 것이라면, 프레임워크는 시스템의 전체적인 틀을 재사용하는 것입니다. 따라서 대부분의 프레임워크는 특정 유형의 시스템에 특화된 것이 많습니다.

Java EE를 지원하는 프레임워크는 오픈 소스들이 많이 있습니다. 각각 용도나 지원하는 범위가 다르기 때문에 적절한 것을 골라 사용해야 합니다. 또한, 실제 개발을 어떻게 진행해 나갈 것인지에 대한 것도 중요한 요소입니다. 최근에는 Agile, XP, RUP 등 다양한 개발 방법론이 있습니다. 개발 프로젝트를 원활하게 추진하기 위해서는 이러한 프레임워크와 개발 방법을 적절하게 선택하여 활용하는 것이 바람직합니다.

(5) 서블릿이란?

서블릿(Servlet)은 "Server" + "Let"의 합성어로 말 그대로 서버에서 실행되는 프로그램을 의미합니다.

Servlet은 주로 웹 애플리케이션 서버와 연계하여 Java 프로그램을 작동시키기 위한 구조로 서버에서 실행됩니다.

일반적으로 웹 페이지는 웹 서버에 파일로 저장되어 클라이언트의 요청에 따라 웹 서버가 지정된 파일의 내용을 클라이언트로 전송하면 페이지가 표시되게 되어 있습니다. 웹 서버만으로 페이지를 제공하는 경우, 그 내용은 변경되지 않는 정적인 것으로 클라이언트에 대해서도 동일한 내용으로 응답할 수 밖에 없습니다.

그러나 웹 시스템이 발전해 오면서 정적인 내용 제공뿐만 아니라 고객마다 다른 내용을 제공해야 하는 요구가 나오게 되었습니다. 예를 들어 검색 페이지에서 클라이언트가 검색하고자 하는 키워드를 입력하면 그 입력 내용에 따라 검색 결과를 다르게 표시해야 합니다. 이를 위해서는 입력된 내용을 서버에서 분석하여 처리하고, 결과를 클라이언트에 보내야 합니다.

이런 처리는 웹 서버만으로는 제공할 수 없기 때문에, 웹 서버 대신 그러한 연산을 수행해 주는 소프트웨어가 필요합니다. 대표적인 기술 중 하나가 Java Servlet입니다.

<JSP와 연계 방법>

① Java Servlet 동작 원리

Java Servlet은 HTTP 서버를 애플리케이션 서버로 변신시키는 기술이라고 설명했는데, 과연 어떤 구조를 하고 있는 것일까요?

앞서 설명한 것과 같이, 서블릿의 "릿"은 영어로 "작은 것"을 가리키는 단어의 접미사로 사용됩니다. Booklet라고 하면 소책자(팜플렛)를 나타내는 것입니다. Java에는 Applet이라는 것이 있는데, 이것은 웹 브라우저에서 동작하는 "작은 애플리케이션"이라는 의미가 됩니다. 서블릿은 "작은 서버 애플리케이션"이라고 할 수 있습니다.

"서블릿"은 간단히 말해 서버에서 동작하는 애플리케이션을 가리킵니다. 서블릿은 서버에서 실행되기 때문에 당연히 "서버"가 필요합니다. 서블릿을 실행하기 위한 서버 프로세스를 "서블릿 엔진"이라고 합니다. 서블릿은 그 출력을 주로 웹 브라우저 화면에 HTML로 표시합니다.

플러그인 모듈은 웹 브라우저에서 웹 서버로 보내온 HTTP 요청을 공유 메모리 및 TCP/IP 등을 사용하여 적합한 서블릿 엔진으로 전달합니다.

일반적으로 모든 웹 애플리케이션 서버는 웹 서버와 서블릿 엔진을 모두 제공합니다.

서블릿 엔진은 요청이 들어오면 해당 서블릿을 로드하고 초기화해 서비스 메소드를 호출합니다. 같은 요청이 반복적으로 오게 되면 로드 및 초기화 처리 과정이 필요없고, 최초 호출 시 이미 생성된 객체의 서비스 메소드 호출만 수행합니다. 서비스 메소드 호출은 서버 프로세스의 스레드에 의해 이루어집니다.

서블릿은 CGI와 달리 서버에 상주하면서 한 번 로드된 애플리케이션을 반복적으로 사용하기 때문에 자원과 성능면에서 유리합니다. 사용자가 HTML에서 입력한 내용이나 작업 내용(라디오 버튼과 체크 박스의 선택 등)은 HTTP 프로토콜의 "파라미터" 데이터로 서버에 전송됩니다. 이 정보는 애플리케이션 서버 프로세스가 읽어 분해하여 변환한 후 리퀘스트 오브젝트로 만듭니다. 서블릿 코드에서 리퀘스트 오브젝트를 참조하려면 "getParameter" 메소드를 사용합니다.

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;

public class HelloWorld extends HttpServlet {

	private String message;
    public void init() throws ServletException
    {
       // Do required initialization
       message = "Hello World";
    }
    public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException
    {
    	response.setContentType("text/html");
        
        PrintWriter out = response.getWriter();
        out.println("<h1>" + message + "</h1>");
    }
    
    public void destory()
    {
    	// do nothing.
    }
}

② 세션 관리는 세션 오브젝트를 사용

HTTP 요청이 Stateless(이전 상태를 기록하지 못하는 접속)이기 때문에 서블릿은 세션 매니저가 있습니다. 서블릿은 기본적으로 하나의 URL에 대해 하나의 인스턴스를 실행하고, 여러 웹 브라우저에서 공유합니다. 웹 브라우저마다 다른 상태나 데이터를 관리하려면 세션 객체를 사용해야 합니다. 세션 객체는 연결될 웹 브라우저 만큼의 인스턴스를 만듧니다. 세션 매니저는 세션ID라는 문자열을 웹브라우저의 쿠키에 저장하는 방법으로 웹 브라우저와 서버의 세션 객체를 1대 1로 맵핑하여 관리합니다. 세션 객체는 요청이 서블릿으로 전송될 때마다 요청 객체의 헤더로 전송하여 스레드가 호출되므로 서블릿에서 언제든지 이용 가능합니다.

세션 객체는 한 번 만들어지면 어떤 서블릿을 호출하든지 항상 브러우저와 1대 1 관계를 유지합니다. 지정된 세션 유지 시간이 지나거나 서버가 다운되어 삭제되기 전까지는 언제든지 동일한 세션 오브젝트를 사용할 수 있습니다. 이러한 방법으로 여러 화면에 걸쳐 웹 브라우저 단위로 관리가 가능합니다. 프로그램에서 명시적으로 세션 객체를 제거하려면 invalidate라는 메소드를 호출하면 됩니다. 대부분의 웹 애플리케이션 서버는 장애를 대비하기 위해 다운된 경우에도 세션 객체를 유지할 수 있는 기능과 여러 서버 인스턴스 간에 세션을 복제하는 기능도 가지고 있습니다.

(6) JDBC를 통한 데이터베이스 접속

윈도우용 애플리케이션에서는 ODBC를 사용하여 데이터베이스에 접근하지만 Java의 표준은 JDBC(Java DataBase Connectivity)를 사용하여 데이터베이스에 접근합니다.

클라이언트/서버 시스템은 클라이언트와 데이터베이스 서버간에 1대 1로 연결하지만, 애플리케이션 서버는 애플리케이션 서버에서 데이터베이스 서버로 여러 개의 커넥션을 연결합니다.

Java EE 애플리케이션에서는 데이터베이스 연결을 커넥션 풀 형태로 애플리케이션 서버에 미리 연결해 두었다가 사용할 수 있습니다. 커넥션 풀은 애플리케이션 서버를 시작할 때 데이터베이스 연결을 먼저 해 두었다가 프로그램에서 필요할 때 커넥션 풀에서 연결을 가져와 데이터베이스르르 사용하는 방법입니다.

커넥션 풀을 사용하지 않는다면 데이터베이스를 사용할 때마다 직접 연결하여 사용해야 합니다. 하지만 데이터베이스 연결은 매우 높은 비용(시간이 많이 걸리는)이 드는 작업이어서 커넥션 풀을 사용하는 것은 성능 면에서도 효율적이고 좋은 방법입니다.

JSP, Servlet, EJB 등 애플리케이션에서 커넥션 풀을 사용하려면 JNDI를 사용해 커넥션을 가져와 사용하면 됩니다.

2. 웹 시스템 아키텍처

몇 가지 관점에서 웹 시스템의 아키텍처를 구성하는 방법을 생각해 봅시다. 서버 구성은 성능과 확장성, 안정성 등 여러 가지 항목과 밀접히 관련되어 있습니다.

웹 애플리케이션 서버 시스템을 구축할 때 여러 가지 문제를 직면하게 될 것입니다. 문제점과 이를 해결하는 솔루션을 설명합니다.

(1) 웹 애플리케이션의 이해

<애플리케이션 서버의 기본적인 기능>

애플리케이션 실행 환경
데이터베이스 커넥션 풀 기능
트랜잭션 관리
업무 처리의 흐름을 제어하는 비즈니스 로직 구현

애플리케이션 서버 기능에 대한 정확한 정의는 존재하지 않기 때문에 이러한 기능이 없는 애플리케이션 서버도 있습니다. 또한, 위의 네 가지 기능 이외에도 각 벤더마다 고유의 기능을 제공하는 경우도 있습니다.

웹 애플리케이션 서버라는 기술 범주의 미들웨어 제품은 현재 웹 애플리케이션을 웹과 Java를 이용하여 구축하는 것이 일반화되었습니다. Java EE(Java Enterprise Edition)의 각종 기능 및 아키텍처는 웹 시스템을 구축하는데 필수적인 커포넌트 및 시스템 구조를 제공하고 있습니다. 실제로 시스템을 통합하여 기업 시스템을 구축하는 경우에는 "Java EE" 기술 범위만으로는 다룰 수 없는 문제들도 있습니다.

(2) 먼저 본질을 이해하고 시작하자

새로운 기술을 다룰 때 중요한 것은 그 본질을 제대로 파악하는 것입니다. 표면적인 노하우만을 습득하는 것만으로는 다양한 환경에서 응용하기 어렵고, 기억할 것들이 너무 많아져 금방 잊어버리게 됩니다. 또한, 이런 단순한 지식들은 새로운 기술이 등장해버리면 금방 사라지고 그 가치를 잃어버리는 경우가 많습니다.

기술에 있어서 본질적인 것. 즉, 근간이 되는 개념은 크게 변하지 않습니다. 어떤 의미에서 컴퓨터의 역사가 시작된 이래 핵심이 되는 기술들은 계속 이어져오고 있다고 볼 수 있습니다.

Java EE도 그러한 역사에서 태어난 기술입니다. 그리고 지금까지 그랬던 것처럼 언젠가 더 진보된 기술로 대체될 것입니다. 그러나 우수한 기술은 완전히 소멸해 버리는 것은 아닙니다. 새로운 기술들을 살펴보면 모양과 이름을 바꾼 것일 뿐 그 기반을 이루고 있는 것들은 기존의 핵심 기술인 경우가 많습니다.

이렇게 변화될 때, 기존의 기술을 제대로 이해하고 있으면, 신기술을 처음부터 습득할 필요가 없습니다. 지금까지 배운 지식을 새로운 이름으로 바꾸고, 우선순위를 바꾸면 새로운 기술의 상당 부분은 쉽게 이해할 수 있을 것입니다. 이런 이유 때문에 Java EE를 충분히 공부하여 완전히 이해하면 반드시 미래에 활용할 수 있게 될 것입니다.

① 웹 애플리케이션 서버 시스템의 정의

"웹 애플리케이션 서버 시스템"은 클라이언트와 서버 사이의 연결 수단으로 웹(World Wide Web)을 사용하는 서버 시스템을 의미합니다. 최근 "웹 애플리케이션 서버"는 웹에서 사용하는 애플리케이션 서버를 구축하기 위한 미들웨어 제품을 지칭하는 단어로 사용해 왔습니다. 일반적으로 서버 시스템의 구성은 논리적으로 웹 서버, 애플리케이션 서버, 데이터베이스 서버의 3-티어로 구성되어 있습니다.

기업의 웹 시스템은 기업 내의 임직원을 위한 인트라넷 시스템과 대외 고객에게 서비스하기 위한 익스트라넷 시스템으로 구성됩니다. 서버 시스템은 외부에서 HTTP 요청을 받고 HTTP 응답을 반환하는 웹 서버, 웹 서버에서 전달된 요청에 대한 업무를 처리하는 애플리케이션 서버, 업무 처리 결과 데이터를 업데이트하는 데이터베이스 서버로 구성됩니다.

<웹 시스템의 기능 요구사항>

기능 요구	설명
시스템의 확장성 및 가용성	소비자를 대상으로 한 전자상거래 시스템의 경우 트래픽이 높기 때문에 수평(서버 증가), 수직(서버 CPU 등을 증설)적 부하 분산을 고려해야 합니다. 웹 애플리케이션 서버에서는 수직적 확장은 서버의 CPU, 메모리를 증설하는 것을 의미합니다. 수평적 확장은 서버의 대수를 동적으로 늘리고 로드 밸런서 또는 웹 서버의 분배 기능을 사용하여 처리량을 늘릴 수 있습니다. 또, 서버 대수를 늘려 분배하여 시스템의 가용성을 보장합니다.
세션 관리 기능	시스템에 트래픽이 증가하면 하나의 웹 애플리케이션 서버만으로 서비스를 제공하는 것이 힘들어집니다. 따라서 웹 애플리케이션 서버 프로세스 수를 늘리거나 서버 자체를 늘리는 수평 분산이 필요합니다. 이때, 로드 밸런서에서 요청을 분산할 때 해시(Hash) 방식을 지정하여 특정 애플리케이션 서버에 할당하여 처리되게 할 수 있지만, 서버 인스턴스에서 장애가 발생하였을 경우에 사용자 상태를 유지할 수 없습니다. 세션 관리의 복제 기능은 장애가 발생하면 다른 서버로 요청을 이동(Fail-Over)시켜도 이미 복제된 세션 정보를 사용하여 사용자의 상태가 유지된 채 작업을 계속할 수 있습니다.
트랜잭션 관리 기능	여러 개의 데이터베이스나 시스템들 간에 데이터 일관성을 유지하려면 트랜잭션으로 관리해야 합니다. 웹 애플리케이션 서버에는 트랜잭션의 일관성을 유지하는 트랜잭션 모니터 기능을 제공합니다.
고성능	Java(Java EE)언어 환경에서 프로세스의 처리는 스레드 단위로 처리됩니다. 하나의 Java 프로세스에서 여러 스레드를 동시에 실행할 수 있기 때문에, 더 효율적이고 빠르게 작은 규모의 하드웨어에서 처리할 수 있습니다.
데이터베이스 연결	사용자 요청 처리마다 데이터베이스와의 연결과 종료를 반복하면 이것이 병목이 됩니다. 이 문제를 해결하기 위해 JDBC 커넥션 풀과 같은 DB 연결을 유지하고 그것을 재사용하는 기능을 제공합니다.
보안 기능	애플리케이션 서버로 요청을 처리하는데 있어 각종 보안이 필요합니다. 이것을 간단히 HTTP 기반의 보안(TLS/전자 인증)에 대한 기능을 제공합니다.
시스템 개발 기간의 단축 가능한 공통적인 프레임워크 지원	웹 애플리케이션 서버를 채택하는 가장 큰 이점은 Java와 같은 쉬운 프로그래밍 언어 및 다양한 애플리케이션 프레임워크를 사용할 수 있기 때문에 개발 공정이 단순화되고 개발 기간이 줄어드는 것입니다. 웹 애플리케이션 서버는 개발 환경이나 다양한 프로그램의 실행 환경을 제공합니다.

② 기존 클라이언트 서버와의 차이점

1990년대 초반의 클라이언트 서버 기반 시스템에서는 클라이언트를 전용 단말기로 다양한 기능을 제공하는 리치 클라이언트 방식으로 시스템을 구축하는 것이 대부분이었습니다. 이런 방식은 관계형 데이터베이스 관리 시스템(RDBMS) 서버가 매우 고가이며 변경이나 교체가 쉽지 않았기 때문입니다. 업무 프로세스가 바뀌면 클라이언트 프로그램을 업데이트하거나 교체해야 했지만, 대부분 이용자는 회사 사람으로 한정되어 있었기 때문에 큰 문제가 되지 않았습니다.

1990년대 후반에 인터넷이 보급되면서 웹 브라우저를 이용하여 비즈니스를 해나가는 전자상거래 사이트들이 많아졌습니다. 웹 브라우저를 클라이언트로 사용하는 시스템은 서비스 대상이 불특정 다수이기 때문에 시스템 변경되면 모든 사용자의 환경을 바꾸는 것이 사실상 불가능하게 되었습니다. 그래서 서버에서 업무 프로세스 등 각종 애플리케이션 로직을 처리해야 했습니다. 애플리케이션의 실행환경이 클라이언트에서 서버로 전환되는 것은 서버의 고성능화(UNIX 서버 등으로 대표되는 상대적으로 저렴한 고성능 서버 등장)와 네트워크 고속화, Java 등의 프로그램 언더 등이 등장하면서 가능해졌습니다. 1990년대 후반에는 웹 브라우저를 클라이언트로 사용하여 다양한 작업을 서버에서 실행하는 시스템이 일반화되었습니다.

인터넷을 이용한 시스템은 서버에서 다양한 기능을 제공해야 합니다. 예를 들어 e-커머스 사이트는 상품 정보를 제공하고 여러 제품을 선택하여 결제할 수 있도록 해야합니다. 이 서비스를 구현하려면 대화식 처리 방식을 제공해야 하고 인증, 개인 정보 보호 등의 보안, 안정성 및 가용성의 확보 등의 기능을 제공해야 합니다.

서버가 고성능화 됐다고 하지만 대규모 시스템에서 이러한 요구사항을 모두 개발하여 제공하는 것은 많은 어려움이 있습니다. 그래서 기존 웹 서버에서만 처리했던 내용을 웹 서버와 애플리케이션 서버 두 개로 분리하여 더 많은 트랜잭션을 처리할 수 있는 방식인 3-티어 아키텍처가 일반화되었습니다. 1998년경부터 본격적으로 웹서버와 웹 애플리케이션 서버 제품들이 시장에 등장하기 시작했습니다.

Java EE에서는 특히 웹과 데이터베이스 관리 시스템(DBMS)과의 연계가 중요합니다.

클라이언트 서버의 단순한 2-티어 구조에서는 처리가 복잡해지면 처리 로직이 클라이언트에 집중됩니다.

클라이언트 애플리케이션에서 로직이 많아지면 복잡하고 큰 애플리케이션을 사용자 컴퓨터에 설치해야 합니다. 이런 설치형 애플리케이션은 유지 보수 비용이 많이 듭니다. 또 외부에 제공되는 서비스는 이런 방식의 애플리케이션 배포 자체가 어렵습니다.

한편, DBMS 서버로만 연결을 집중시키는 것도 문제가 발생할 가능성이 높아 집니다. 아무리 고성능 서버라고 해도 모든 작업을 한대로 처리하는 것은 불가능에 가깝습니다. DBMS는 원래 데이터를 통합 관리하기 위한 시스템입니다. 따라서 쉽게 대수를 늘려 처리를 분담시킬 수도 없습니다.

이와 같이 기존의 클라이언트 서버 환경에서 유연성 및 확장성에 문제가 있었습니다. 이를 극복하기 위한 것이 3-티어 이상의 멀티티어 아키텍처입니다. Java EE는 이러한 멀티티어를 적극적으로 지원하고 있습니다.

웹 브라우저에는 HTML 화면만을 출력하고, 모든 처리는 서버에서만 이루어지기 때문에, 애플리케이션 로직은 서버에서만 수정하면 모든 클라이언트에 곧바로 적용됩니다. 수 많은 클라이언트 애플리케이션을 유지 관리하는 비용을 우선 줄일 수 있습니다.

(3) 3-티어 아키텍처

일반적인 웹 시스템의 대부분은 "웹 3-티어 구성"으로 구성하는 경우가 많습니다.

이 웹 3-티어 디자인은 다음의 3개 층으로 구성되어 있습니다.

웹 브라우저에서 HTTTP 액세스 요청을 분산 처리하는 웹 서버 계층
트랜잭션의 일관성을 유지하고, 시스템 관련 작업을 수행하는 백엔드에서 실행되는 데이터베이스 쿼리와 데이터의 가공 등을 담당하는 웹 애플리케이션 서버(WAS) 계층
시스템 데이터 및 관리 정보를 맡는 데이터베이스 서버 계층

아래의 그림은 멀티티어로 구성되는 웹 시스템의 아키텍처를 보여줍니다.

이 그림은 논리적인 소프트웨어 구성을 나타낸 것으로, 하드웨어 구성은 포함하고 있지 않습니다.

멀티티어 아키텍처는 서버 시스템 구성에 따라 웹 서버, 애플리케이션 서버, 데이터베이스 서버의 3-티어로 구성되어 있습니다. 또한, 웹 애플리케이션 서버 시스템과는 다른 기존 시스템으로 "레거시 시스템"이 존재하고 애플리케이션 서버와 연동합니다.

각 계층 별로 확장(서버 증설로 성능을 향상시킬 수 있는 것)이 가능하기 때문에, 확장성 및 가격 대비 성능도 크게 향상됩니다. 웹 서버는 클라이언트와 웹 애플리케이션 서버로 요청, 응답을 중계하는 기능을 가지고 있습니다. 웹 애플리케이션 서버에서는 업무를 처리합니다. 업무 처리는 애플리케이션 컴포넌트에 의해 구현됩니다. 또한, 애플리케이션 서버는 BPM, Rule 엔진 등 다른 미들웨어들과 함께 사용될 수 있습니다.

일반적으로 3-티어 시스템은 인터넷이 등장하기 전에 애플리케이션에서 많이 사용되고 있던 클라이언트/서버 방식(2-티어 시스템)에 비해 시스템 변경 및 업데이트 등이 매우 쉽고 유연성이 높은 시스템 구성 방법입니다. 특히 웹 애플리케이션화되면서 클라이언트(웹 브라우저)와 웹 애플리케이션 서버 계층이 생겻고, 고전적인 2-티어 시스템에 비해 시스템 변경 시 도입 비용도 저렴해졌습니다. 그러나 대신 기능이 제한적인 웹 브라우저만을 사용해야 한다는 제한 사항이 생기게 되었습니다. 주로 이런 제한을 해결하기 위해 ActiveX가 많이 사용되었지만, 최근에는 HTML5 기술이 도입되어 웹 브라우저만으로도 다양한 기능을 제공할 수 있게 되었습니다.

(4) 웹 서버와 웹 애플리케이션 서버의 분리

웹 서버와 웹 애플리케이션 서버(WAS : Web Application Server)는 비슷한 개념이기 때문에 혼용되어 사용하는 단어 중 하나입니다. 인터넷 확산 초기에는 웹 서버라는 개념이 주로 사용되었지만, 시간이 지남에 다라 웹 애플리케이션 서버의 중요성이 높아지고 있습니다. 인터넷 사용자가 증가함에 따라 각 웹사이트는 보다 많은 사용자에게 원활한 서비스를 제공하기 위해 기능적인 레이어를 나누게 되었고 여기서 웹 서버와 웹 애플리케이션 서버의 구분이 생기게 된 것입니다.

<웹 서버와 웹 애플리케이션 서버의 비교>

구분	웹 서버	웹 애플리케이션 서버
설명	웹 브라우저에 정적 콘텐츠를 제공하는 서버 즉, 정적인 HTML이나 jpeg, gif 같은 이미지를 HTTP 프로토콜을 통해 웹 브라우저에 제공	서버에서 애플리케이션이 동작할 수 있도록 지원 일반적으로 컨테이너(노드)라는 용어가 사용됨 초창기에는 CGI, 그 이후에는 Servlet, ASP, JSP, PHP 등의 프로그램으로 사용되고 있음
콘텐츠 생성	페이지의 내용이 이미 서버에 존재하고 있고 사용자 요청 시 해당 파일을 읽어 제공	사용자의 요청이나 입력이 있는 경우 데이터베이스 쿼리 결과를 동적 콘텐츠로 작성하여 응답
주요 작업	로직이 아닌 단순 HTTP 서버	애플리케이션 로직을 서비스
주요 기능	1. 로드 밸런싱 기능 : 사용자 요청이 발생하면 상황에 따라 각각의 요청을 WAS에 넘김 2. Cache 기능 : css, js, image 등의 리소스 파일을 가지고 있다가 WAS를 거치지 않고 사용자에게 직접 제공	1. 프로그램 실행 환경과 데이터베이스 연결 기능 제공 2. 여러 작업을 연결하는 트랜잭션 관리 기능 3. 업무 처리 흐름을 제어하는 비즈니스 로직 구현

(5) 웹 사이트 특징에 따른 아키텍처

웹 사이트 특성에 따라 어떤 부분을 강화하거나 신뢰성을 높이려고 할 때, 사이트 전체 구성 방법을 정합니다. 웹 사이트의 안정성과 성능은 밀접한 관계가 있습니다. 특히 클러스터는 성능 향상과 서비스 신뢰성을 높이는 필수적인 기술 요소입니다. 따라서 설계 단계에서 웹 사이트에서 제공해야 하는 성능이나 안정성이 대한 수준을 명확하게 해두어야 합니다. 동시에 웹 사이트의 성격도 파악해야 합니다. 다음은 웹 시스템을 설계할 때 고려해야 할 항목들입니다.

정적 콘텐츠(이미지나 HTML 등)가 많다.
동적 콘텐츠(JSP와 서블릿에서 생성하는 HTML 등)가 많다.
데이터베이스 액세스가 많다.
다운로드가 많다.

① 소규모 웹 사이트

소규모 웹 사이트 구성에서는 이해하기 쉽도록 두 개의 방화벽을 사용하고 있지만, 실제로는 하나의 방화벽을 사용하여 DMZ(DeMilitarized Zone)을 구성합니다.

이러한 구성에서는 애플리케이션 서버 및 데이터베이스 서버의 장애만으로 서비스가 중지되어 버립니다. 또 이 구성에서 성능을 높이려면 간단하게 CPU 수와 메모리를 늘리는 것으로 애플리케이션 서버와 데이터베이스 서버의 하드웨어 장비를 더 빠르게 하는 것입니다. 즉, 이러한 구성은 24시간 연속 가동을 요구하는 서비스에서는 사용할 수 없는 아키텍처입니다. 반대로, 서비스 중단이 비즈니스에 큰 영향을 주지 않는 경우에는 이런 간단한 구성을 이용해도 좋을 것입니다.

② 정적 콘텐츠가 많은 웹 사이트

웹 애플리케이션 서버는 대부분 웹 서버 기능을 가지고 있어 HTML 및 이미지를 웹 브라우저에 보내는 것이 가능합니다. 하지만 애플리케이션 서버의 원래 임무는 데이터베이스에 액세스하여 웹 브라우저의 요청에 따라 HTML을 생성하는 것입니다. 이런 처리를 위해서 애플리케이션 서버는 더 많은 하드웨어 리소스를 사용하는 것이 일반적입니다.

정적 HTML 및 이미지를 애플리케이션 서버 앞 단의 웹 서버에서 웹 브라우저로 전송하는 구성을 하게 되면 애플리케이션 서버가 작동되는 시스템에 부하가 덜 발생하여 시스템을 효율적으로 사용할 수 있게 됩니다. 웹 서버는 Java보다는 C 언어로 작성된 Apache HTTPD 서버와 같은 웹 서버를 사용하는 것이 일반적입니다.

DMZ는 웹 서버에만 적용합니다. 웹 서버는 웹 브라우저에서의 요청을 애플리케이션 서버에 전달합니다. 따라서, 웹 브라우저는 웹 서버와 통신만 하면 됩니다. DMZ에서 데이터베이스에 직접 액세스할 수 없기 때문에 강력한 보안 환경을 구성할 수 있습니다.

③ 동적 콘텐츠가 많은 웹 사이트

동적 콘텐츠가 많다는 것은 애플리케이션 서버의 작업량이 많다는 것입니다. 애플리케이션 서버의 CPU 수와 메모리를 늘려서 대응할 수 없을 경우 애플리케이션 서버를 클러스터링하여 구성합니다.

웹 브라우저의 요청을 웹 서버가 받아 설정되어 있는 알고리즘에 따라 웹 애플리케이션 서버로 전달합니다. 두 개의 애플리케이션 서버는 모든 요청을 동등하게 처리합니다. 단순히 생각하면 용량은 2배가 되지만, 요청마다 동일한 데이터를 참조하고 갱신하는 경우엔 데이터베이스 측에서 Lock이 걸리고 생각보다 처리량이 높아지지 않을 수도 있습니다. 이 문제를 해결하려면 여러 애플리케이션 서버에서 데이터베이스를 공유하더라도 데이터베이스 처리가 지연되지 않도록 테이블을 설계해야 합니다.

④ 데이터베이스 액세스가 많은 사이트

데이터베이스 액세스가 많은 경우 애플리케이션 서버에서 데이터를 캐시하는 것이 좋습니다. 이렇게 처리하기 위해서는 설계 시 어떤 기술을 이용하여 캐시를 할지 결정해야 합니다. Java EE에서는 데이터베이스 접근에 EJB를 사용하면 트랜잭션 제어를 간단히 처리할 수 있습니다. EJB를 사용하면 캐시를 쉽게 적용할 수 있기 때문에 프로그램 작성은 간단합니다.

효율적으로 데이터를 캐시하려면 데이터베이스 및 애플리케이션 서버를 1대 1로 구성합니다. 그러나 클러스터 구성을 채택하면 하나의 애플리케이션 서버의 데이터가 업데이트되면 다른 애플리케이션 서버에 알려야 해서, 그 결과 서버 간의 통신이 자주 발생하여 처리량이 줄어들게 됩니다. 클러스터를 구성하면 데이터를 캐시하는 것이 어려워지게 됩니다. 이런 경우엔 설계 시에 데이터에 대한 읽기만 있는지, 업데이트가 많은 데이터인지 명확히 구분하여 두었다가 읽기가 많은 데이터를 캐시하도록 설계하면 간단하고 효율적인 시스템을 구성할 수 있습니다. 업데이트가 많은 데이터와 잘 분리하여 데이터베이스 접근이 작아지도록 설계합니다.

캐시를 효율적으로 이용하기 위해서 애플리케이션 서버 자체의 기능을 사용할 수도 있습니다. 일부 애플리케이션 서버는 클러스터에 공유하여 캐시된 데이터를 쓰기 작업 시 폐기하는 기능도 제공하고 있습니다.

JBoss의 경우 jboss Data Grid(Infinispan)를 애플리케이션 캐시 프레임워크로 사용할 수 있습니다.

⑤ 안정성을 중시하는 웹 사이트

24시간 서비스를 계속해야 하는 웹 사이트들이 많이 있습니다. 이 경우 웹 서버, 애플리케이션 서버, 데이터베이스, 네트워크 모두를 이중화하여 어디에서 장애가 발생해도 계속 작동할 수 있는 구성이 필요합니다. 또한, 이런 사이트는 접속량도 많기 대문에 처리량에 따라 확장할 수 있도록 설계되어야 합니다.

웹 브라우저에서 웹 사이트에 접속하면 먼저 로드 밸런서에 전달됩니다. 로드 밸런서는 사용자의 요청을 웹 서버로 보내는 역할을 하는 것으로 일반적으로 하드웨어입니다.

로드 밸런서도 장애가 발생해도 계속 동작할 수 있도록 구성해야 합니다. 로드 밸런서의 처리 배분은 DNS 라운드 로빈으로 합니다. DNS 라운드 로빈은 하나의 DNS 이름에 여러 개의 IP 주소를 할당하는 기능입니다.

웹 브라우저는 요청한 URL 주소를 DNS서버에 질의하면 여러 IP 주소가 순서대로 돌아옵니다. 즉, 하나의 로드 밸런서가 오류로 작동하하지 않는 경우에 다시 액세스를 시도하면, 실행되고 있는 로드 밸런서에 연결 할 수 있습니다. 다음 웹 서버의 장애를 생각하면, 로드 밸런서는 일정 주기로 HTTP 서버의 동작을 모니터링하는 기능도 가지고 있고, 만약 웹 서버가 작동하지 않으면 로드 밸런서가 동작하고 있는 웹 서버에로 요청을 전달합니다.

애플리케이션 서버의 쟁애는 앞서 언급했듯이, 실패 시 웹 서버의 모듈에서 애플리케이션 서버로 전달하지 않도록 하는 것입니다. 데이터베이스의 이중화 방법은 제품에 따라 이중화 방법이 다릅니다. 단순히 복제본을 만들어 두는 것부터 정지 대기(cold standby), 상시 대기(hot standby) 등의 다양한 구성 방법이 있습니다.

웹 사이트의 규모, 처리량, 보안 등에 따라 서버 구성을 결정하는 것은 쉬운 일이 아닙니다. 경험이 풍부한 엔지니어와 제품을 제공하는 벤더로부터 가이드를 받아 구성을 결정하는 것이 좋습니다. 하드웨어도입도 구매에도 시간이 필요하지만, 한번 결정된 하드웨어를 변경하는 것이 쉽지 않기 때문에 신중히 결정해야 합니다.

(6) 서버 자체의 보안 관점에서 구성

먼저 일반적인 웹 애플리케이션 서버 구성을 생각해 봅니다. 일반적으로 웹 애플리케이션 서버는 웹 서버 기능이 포함되어 있습니다. 웹 서버에 Apache HTTPD (http://httpd.apache.org)를 사용하는 경우도 있습니다. JBoss에서도 JBoss EAP가 웹 서버 역할을 할 수 있지만, 별도의 JBoss EWS(Apache HTTPD) 서버를 이용하는 것이 일반적입니다.

Servlet / JSP는 웹 서버를 통해서 접근할 수 있지만, EJB는 RMi로 접근할 수 있습니다. 또한, 웹 애플리케이션 서버를 관리하기 위한 인터페이스가 각 제품에 따라 다릅니다. 따라서 웹 애플리케이션 서버는 HTTP 이외의 다양한 인터페이스를 사용할 수 있어서 이를 그대로 방화벽 밖에 놓는 것은 매우 위험합니다. 또, HTTP 포트만 개방하고 있다 해도 위험합니다. 그래서 인터넷에서 사용하기 위해서는 몇 가지 구성 방법이 있을 수 있습니다.

먼저 가장 단순한 구성을 생각해 봅니다.

1차 방화벽은 인터넷에서 접근되는 HTTP 프로토콜만 통과시킵니다. 웹 애플리케이션 서버에 네트워크 인터페이스 카드를 두 개 준비하여 하나는 1차 방화벽과의 통신에 사용하고, 다른 카드는 2차 방화벽의 통신에 사용합니다. 웹 사이트에서는 일반적으로 데이터베이스를 이용하기 때문에 데이터베이스는 가장 높은 수준의 보안이 가능한 곳에 배치합니다. 2차 방화벽은 웹 애플리케이션 서버의 주소, 데이터베이스에 대한 접근 포트, 프로토콜만 통과하 수 있도록 설정합니다. 더 간단하게 하려면 2차 방화벽을 생략할 수도 있습니다.

웹 애플리케이션 서버 컴퓨터 자체가 해킹되어 버리면 데이터베이스에 직접 접근할 수 있게 됩니다. 따라서 더 높은 보안을 제공하는 방식이 필 요합니다.

(7) 안정성과 성능을 중시한 클러스터 구성

대규모 웹 사이트나 신뢰성이 중시되는 웹 사이트에서는 클러스터 구성을 하는 것이 일반적입니다. 웹 애플리케이션 서버의 클러스터는 아래와 같은 구성입니다.

인터넷에서 접근하면 웹 서버에서 받아서, 그 뒤에 있는 웹 애플리케이션 서버에 보냅니다(일반적으로 이 웹 서버를 프록시라고 함). 웹 서버는 설정된 알고리즘에 따라 처리할 웹 애플리케이션 서버에 배분합니다. 이 알고리즘은 랜덤 및 가중치 등 여러 가지 방식이 있지만 웹 애플리케이션 서버 제품에 따라 다릅니다. 웹 서버는 웹 애플리케이션 서버가 처리하 수 있는지를 알 수 있기 때문에, 하나의 웹 애플리케이션 서버가 중지된 경우에도 처리가 가능한 웹 애플리케이션 서버에 배분할 수 있습니다. 이런 방식을 통해 장애가 발생하여 한 웹 애플리케이션 서버가 정지해도 웹 사이트의 서비스를 지속적으로 제공할 수 있습니다.

또한, 성능 면에서도 유리합니다. 웹 사이트의 내용에 따라 다르지만 일반적으로 데이터베이스보다 웹 애플리케이션 서버의 처리 부하가 높은 경향이 있습니다. 다라서 여러 웹 애플리케이션 서버에 작업을 분배할 수 있다면 웹 사이트의 전체적인 성능이 향상됩니다. 클러스터 구성은 앞의 DMZ 서버 구성과 함께 사용하기 좋은 구성입니다. 프록시는 보통의 웹 서버내에서 동작을 하기 때문에 웹 서버를 DMZ에 배치하여 보안도 강화하고, 안정성, 성능 모두 좋은 구성을 가질 수 있습니다. 일반적으로 프록시는 Apache HTTPD 같은 웹 서버의 모듈입니다.

(8) Java 기반의 Intergration 방안

웹 애플리케이션 서버를 사용하여 외부 시스템과 연계할 수 있는 방법에는 무엇이 있을까요? 웹 사이트의 서비스는 계속 진화하고 있고, 메인 프레임과 직접 통신하거나 기타 기업의 내부 시스템과 연계하여 동작하는 웹 사이트 시스템이 많아지고 있습니다. Java EE 세계에서는 어떻게 외부 시스템과 연계시키는 것일까요?

① JDBC(Java Database Connectivity)

관계형 데이터베이스를 연결하는세 사용되고, Java EE 표준이 아니라 Java SE의 표준에 포함됩니다.
트랜잭션이 지원되고, 다중 데이터베이스 트랜잭션을 하나로 묶어 처리하는 2단계 커밋 등도 이용할 수 있습니다. 트랜잭션을 관리하는데 가장 좋은 수단이며, 가장 많이 사용되고 있기 때문에 품질도 높습니다.
JDBC 드라이버는 웹 애플리케이션 서버가 포함하고 있는 경우와 데이터베이스 공급 업체에서 제공하는 드라이버를 사용하는 제품이 있습니다.(JBoss)

② JCA(Java EE Connector Architecture)

패키지 애플리케이션 제품과의 연결을 위한 표준입니다. 각 패키지 애플리케이션 공급업체에서 어댑터가 제공됩니다. 이것을 웹 애플리케이션 서버에 통합하여 연결하고, 트랜잭션 처리도 지원합니다.
이용 방법은 JDBC와 유사하기 때문에 상대적으로 쉽게 프로그래밍이 가능하나 제공하는 업체가 아직 많지 않으며 어댑터의 가격도 비싼 편입니다.

③ Java RMI(Java Remote Method Invocation)

Java 원격 객체 호출 구조로 Java SE에 포함됩니다. 애플리케이션이 RMI 인터페이스를 준비하고 있거나 애플리케이션에 맞게 RMI 인터페이스 부분을 만들어 연결합니다.
애플리케이션의 인터페이스를 결정하여 설계, 코딩할 필요가 있습니다. 트랜잭션 관리는 지원되지 않기 때문에, 트랜잭션 처리가 필요한 경우 트랜잭션을 고려한 설계 및 코딩이 필요합니다.
모든 것을 직접 개발해야 하기 때문에, 품질 보장을 위해서 테스트에 상당한 시간이 걸립니다. 특히 오류 처리를 구현하기 위한 시간과 노력이 많이 소요되나 최소한의 구현만 하면 되기 때문에 연결 요구 사항에 따라 쉽게 개발할 수도 있습니다.

④ CORBA

CORBA(Common Object Request Broker Architecture)
Java에서의 CORBA의 호출은 OMG(Object Management Group)에서 상호 운용성이 검증되어 있습니다. 웹 애플리케이션 서버도 표준 CORBA를 지원하는 것이 많습니다.
Java가 CORBA 표준을 지원하기 때문에 CORBA의 IDL정보를 얻어 연결할 수 있습니다.

⑤ JNI(Java Native Interface)

Java에서 OS에 의존하는 네이티브 프로그램을 호출하는 구조입니다. OS에 따라 네이티브 프로그램이 다른 시스템과 통신하는 경우에 JNI를 이용하여 네이티브 프로그램을 호출하면 다른 시스템과 연결할 수 있습니다.
대상 시스템 또는 애플리케이션에 연결하기 위한 수단이 특정 OS나 플랫폼에 의존한 네이티브 프로그램밖에 없을 경우 사용합니다. 연결이 네이티브 코드로 이루어져서 연결 자체의 성능은 좋지만, JNI 호출 비용이 많이 소요되기 때문에 주의가 필요합니다.
Java VM이 NJI에서 다른 프로그램을 시작하는 경우에는 Java VM이 실행중인 프로세스가 확보하고 있는 메모리 영역과 같은 메모리 영역을 확보하는 네이티브 프로그램도 있습니다. 이 경우 JNI 호출을 전용 기능을 다른 Java VM에서 작동시키고 웹 애플리케이션 서버에서 RMI 등을 사용하여 호출하는 방식도 고려할 수 있습니다.

⑥ JMS(Java Messaging Service)

메시지 기반 통신을 위한 구조로 다른 시스템 등과 연계하여 동작하는 것으로 다른 시스템과 연결을 할 때 사용됩니다.
웹 애플리케이션 서버에 있는 JMS 서비스를 이용합니다. 연결하는 시스템 또는 애플리케이션에 비동기적으로 메시지를 보내는 경우나 시스템 또는 애플리케이션에서 웹 애플리케이션 서버에 비동기적으로 메시지를 보내는 경우에 사용됩니다.
모두 대상 시스템에서 Java 인터페이스를 사용하여 JMS에 연결해야연결합니다. 또는 JMS를 지원하는 메시징 패키지 등을 이용하는 경우에도 사용할 수 있습니다.

⑦ 웹 서비스(Webservice)

Java에서 웹 서비스를 이용할 수 있습니다. 웹 애플리케이션 서버는 JAX-WS, JAX-RS 등 웹 서비스 표준으로 지원하고 있습니다.
웹 서비스는 HTTP 통신이므로 방화벽을 통해 연결이 가능합니다. 또 시스템 통합에서 표준 인터페이스로 사용되는 경우가 많아, 수 많은 패키지 애플리케이션 공급 업체가 지원하고 있습니다.

⑧ EAI(Enterprise Application Integration) 제품

EAI 제품은 시스템 간의 연계를 위한 제품으로 예를 들어 기존의 수주 시스템 및 재고 관리 시스템을 연계하고 싶을 때 사용합니다.
제품에 따라 구조는 다르지만, 주로 XML 기반의 제품과 ORB(Object Request Broker) 기반, 자체 프로토콜을 사용하는 제품이 있습니다. 기본적으로 애플리케이션의 메시지를 EAI 제품이 지원하는 메시지 형식으로 변환하여 다른 시스템에 전송합니다.
이들 제품들은 대부분 Java EE에 대한 인터페이스를 가지고 있기 때문에 이 제품을 사용하여 웹 애플리케이션 서버와 다른 시스템을 통합할 수 있습니다.

⑨ 연결 방법의 선택 기준

실제로 시스템 연결이 필요한 경우 어떻게 연결 방법을 선택하는 것이 좋을까요?

선택 기준에는 설계의 용이성, 프로그래밍의 용이성 외에 연결 수단을 제공하는 회사에서 드라이버나 어댑터 등을 구입해야 할 경우 가격, 네트워크 제한사항 등 몇 가지 결정 요인이 있습니다.

선택의 기준이 되는 항목을 정리하면 다음과 같습니다.

요구사항	적당한 선택 방법
트랜잭션 관리는 필요한가?	롤백이 필요한 경우 트랜잭션을 지원하는 연결 방법이 바람직합니다. JDBC나 JCA를 선택합니다. JMS도 트랜잭션을 지원합니다.
인터넷을 통한 연결이 필요한가?	인터넷을 통한 연결은 반드시 그 사이에 방화벽이 존재합니다. 따라서 웹 서비스를 상용하는 방식이 적절한 방법입니다. 최근에는 RESTful 방식의 웹 서비스도 많이 사용하고 있습니다.
비동기 연결이 필요한가?	JMS를 사용하는 것이 가장 적절합니다. JMS를 사용할 수 없다면 독자적으로 개발하여야 합니다.

참고 서적 : 거침없이 배우는 JBoss

저작자표시 비영리 변경금지

'IT 이야기 > JBoss EAP' 카테고리의 다른 글

JBoss EAP 6과 친해지기 5탄 - 시작, 정지, 실행 파라미터, 기본 CLI 사용법 (0)	2020.09.21
JBoss EAP 6과 친해지기 4탄 - 관리자 등록하기 (0)	2020.09.21
JBoss EAP 6과 친해지기 2탄 - JBoss EAP 6의 새로운 기능 및 특징 (0)	2020.09.15
JBoss EAP 6과 친해지기 1탄 - JBoss EAP 6란? (0)	2020.09.11
[JBoss EAP7] 파일 업로드 시 10MB 이상 등록하기 (0)	2020.09.11