jetty 설치 및 실행

Web/WAS 2012. 11. 10. 00:12


Jetty 서버의 설치 및 기본 사용법을 살펴본다.

Jetty 설치 및 실행

Jetty는 서블릿과 JSP를 지원하는 자바 기반의 WAS 서버이다. Netcraft Web Server 조사에서 따르면 Jetty는 현재 톰캣의 점유율에 대비해서 80% 정도의 점유율을 차지하고 있다고 한다. (Jetty shows strong growh - http://www.theserverside.com/news/thread.tss?thread_id=49010 참고) 실제로 Jetty는 다른 WAS에 비해 가볍고 빠르며, 설정도 더 쉽다. 게다가 Ant나 Maven, 그리고 이클립스와의 연동이 쉬울 뿐더러, WAS를 코드에 임베딩시켜서 동작시킬 수도 있기 때문에 개발 과정에서는 상당한 편리함을 제공한다. (필자 역시 Maven과 Jetty를 연동하여 웹 어플리케이션을 개발하곤 하는데, 늘 느끼는 거지만 정말 편리하다고 생각한다.)

Jetty 설치하기

Jetty의 설치 방법은 톰캣이나 Resin 처럼 필요한 파일을 다운로드 받은 뒤 압축을 풀면 완료된다. 현재 Jetty 버전은 6 으로서 아래 사이트에서 6버전의 Jetty를 다운로드 받을 수 있다.

  • http://docs.codehaus.org/display/JETTY/Downloading+Jetty
이 글을 쓰는 시점에서 최신 버전은 6.1.11 버전이며, 본 글에서는 jetty-6.1.11.zip 파일을 기준으로 설치 과정을 설명할 것이다. 다운로드 받은 파일의 압축을 풀면 기본적인 설치가 완료된다.

Jetty 시작 및 정지

Jetty를 처음 실행한 다음에 Jetty가 올바르게 동작하는 지 확인하려면, Jetty를 설치한 디렉토리에서 다음과 같은 명령어를 실행하면 된다.

C:\devtool\jetty-6.1.11>java -jar start.jar etc/jetty.xml

* jetty-9 에서는 java -jar start.jar 만 입력


Jetty 설치 디렉토리에 위치한 etc/jetty.xml 파일은 기본적으로 제공되는 Jetty 설정 파일로서, 위 명령어를 실행하면 실행하면 다음과 비긋한 메시지가 출력되면서 Jetty 웹 서버가 실행되는 것을 확인할 수 있다.

C:\devtool\jetty-6.1.11>java -jar start.jar etc/jetty.xml
2008-09-29 14:43:37.518::INFO:  Logging to STDERR via org.mortbay.log.StdErrLog
2008-09-29 14:43:37.688::INFO:  jetty-6.1.11
2008-09-29 14:43:37.749::INFO:  Deploy C:\devtool\jetty-6.1.11\contexts\javadoc.xml 
-> org.mortbay.jetty.handler.ContextHandler@1bd0dd4{/javadoc,file:/C:/devtool/jetty-
6.1.11/javadoc/}
2008-09-29 14:43:37.798::INFO:  Deploy C:\devtool\jetty-6.1.11\contexts\test.xml 
-> org.mortbay.jetty.webapp.WebAppContext@1feca64{/,C:\devtool\jetty-
6.1.11/webapps/test}
2008-09-29 14:43:37.847::INFO:  Deploy C:\devtool\jetty-6.1.11\contexts\test-
jndi.xml -> org.mortbay.jetty.webapp.WebAppContext@1193779{/test-jndi,C:\devtool\jetty-
6.1.11/contexts/test-jndi.d}
2008-09-29 14:43:38.185::INFO:  No Transaction manager found - if your webapp requires 
one, please configure one.
2008-09-29 14:43:38.250::INFO:  Extract jar:file:/C:/devtool/jetty-6.1.11/webapps/
cometd.war!/ to C:\Users\madvirus\AppData\Local\Temp\Jetty_0_0_0_0_8080_cometd.war__cometd__-
t2qfkl\webapp
2008-09-29 14:43:39.019::WARN:  Unknown realm: Test JAAS Realm
2008-09-29 14:43:39.142::INFO:  Opened C:\devtool\jetty-6.1.11\logs\2008_09_29.request.log
2008-09-29 14:43:39.181::INFO:  Started SelectChannelConnector@0.0.0.0:8080

Jetty를 시작한 뒤 웹 브라우저를 띄워서 http://localhost:8080 을 이용해서 Jetty 서버에 접속하면 다음과 같은 기본 화면을 볼 수 있다.


Jetty를 종료하고 싶을 때에는 Jetty를 구동한 콘솔(도스창)에서 Ctrl+C를 누르면 된다.

Jetty를 실행하는 콘솔과 Jetty를 종료하는 콘솔이 다를 수도 있는데, 이런 경우에는 다음과 같이 STOP.PORT 시스템 프로퍼티와 STOP.KEY 시스템 프로퍼티를 이용해서 Jetty를 시작하면 된다.

java -DSTOP.PORT=8079 -DSTOP.KEY=secret -jar start.jar etc/jetty.xml

STOP.PORT 시스템 프로퍼티는 Jetty 종료 메시지를 기다릴 때 사용할 포트 번호이며, STOP.KEY 시스템 프로퍼티는 올바른 종료 메시지인지의 여부를 구분할 때 사용할 키 값이다. Jetty를 구동한 콘솔이 아닌 다른 콘솔에서 Jetty를 종료할 때에는 Jetty를 시작할 때 명시한 명시한 포트 번호와 키 값, 그리고 --stop 명령행 인자를 사용하여 종료 메시지를 전달할 수 있다.

java -DSTOP.PORT=8079 -DSTOP.KEY=secret -jar start.jar --stop

만약 STOP.PORT 시스템 프로퍼티만 명시하고 STOP.KEY 프로퍼티는 생략한 경우, STOP.KEY 프로퍼티의 값을 임의로 생성해서 표준 출력(콘솔)에 표시한다. 또한, STOP.PORT 프로퍼티의 값을 0으로 지정한 경우, 임의의 포트를 할당한 뒤 표준 출력에서 할당한 포트 값을 표시한다.

컨텍스트 배포(추가)

Jetty 배포판에 포함된 etc/jetty.xml 파일을 사용할 경우, 다음의 두 가지 방법을 이용해서 새로운 컨텍스트를 추가할 수 있다.

  • [JETTY홈]\webapps\ 디렉토리에 war 파일이나 웹 어플리케이션 디렉토리 생성하기
  • [JETTY홈]\contexts\ 디렉토리에 새로운 컨텍스트 설정 파일 추가히기/li>
webapps에 배포하기

webapps 디렉토리에 배포할 경우 war 파일이나 zip 파일을 webapps 디렉토리에 복사해주면 된다. 또는, webapps 디렉토리에 웹 어플리케이션 디렉토리를 복사해주어도 된다. war 파일이나 웹 어플리케이션 디렉토리를 추가한 뒤에는 Jetty를 새로 시작해 주어야 한다. 즉, webapps 디렉토리에는 Hot Deploy가 적용되지 않는다.

Jetty 배포판에 기본적으로 포함된 etc/jetty.xml 파일을 보면 다음과 같은 설정 부분을 확인할 수 있다.

    <Call name="addLifeCycle">
      <Arg>
        <New class="org.mortbay.jetty.deployer.WebAppDeployer">
          <Set name="contexts"><Ref id="Contexts"/></Set>
          <Set name="webAppDir"><SystemProperty name="jetty.home" default="."/>/webapps</Set>
          <Set name="parentLoaderPriority">false</Set>
          <Set name="extract">true</Set>
          <Set name="allowDuplicates">false</Set>
          <Set name="defaultsDescriptor"><SystemProperty name="jetty.home" default="."/>/etc/webdefault.xml</Set>
        </New>
      </Arg>
    </Call>

위 코드는 웹 어플리케이션 디렉토리를 설정하는 부분으로서, 위 코드의 경우 Jetty의 홈디렉토리에 위치한 webapps 디렉토리를 웹 어플리케이션 디렉토리(webAppDir)로 설정하고 있다. WebAppDeployer는 지정한 디렉토리에 위치한 war/zip 파일이나 하위 디렉토리를 웹 어플리케이션으로 배포해주는 기능을 제공하며, 주요 프로퍼티는 다음과 같다.

  • webAppDir - 웹 어플리케이션을 검색할 디렉토리. 파일 경로나 URL로 명시한다. 이 디렉토리에 위치한 .war 파일이나 .zip 파일이 웹 어플리케이션 컨텍스트로 배치된다. 또한, 이름이 CVS가 아닌 디렉토리도 웹 어플리케이션 컨텍스트로 배치된다. 이때, 파일명이나 디렉토리 이름이 컨텍스트의 경로명으로 사용되며, 이름이 "root"인 경우에는 루트 컨텍스트(/)로 사용된다.
  • parentLoaderPriority - 클래스를 로딩할 때 부모 클래스로더에게 먼저 요청할지 아니면 웹 어플리케이션 클래스로더에서 먼저 로딩할지의 여부를 결정한다.
  • extract - 이 값이 true일 경우 war나 zip 파일을 배치하기 전에 먼저 임시 디렉토리에 압축을 푼다.
  • allowDuplicates - 이 값이 false일 경우 동일한 컨텍스트 경로나 war 파일이 이미 배치된 경우, 다시 배치하지 않는다.
  • defaultsDescriptor - 웹 어플리케이션을 설정할 때 사용할 (기본 값을 갖는) 설정 파일을 지정한다.
webapps 디렉토리에 루트 컨텍스트를 배포하고 싶다면 root.war 파일이나 root 디렉토리를 생성한 뒤 웹 어플리케이션을 복사해주면 된다.

contexts에 배포하기

웹 어플리케이션을 배포하는 두번째 방법은 context 디렉토리에 웹 어플리케이션 배치 설정 파일을 추가하는 것이다. etc/jetty.xml 파일을 보면 다음과 같은 설정 부분을 찾을 수 있다.

    <Call name="addLifeCycle">
      <Arg>
        <New class="org.mortbay.jetty.deployer.ContextDeployer">
          <Set name="contexts"><Ref id="Contexts"/></Set>
          <Set name="configurationDir"><SystemProperty name="jetty.home" default="."/>/contexts</Set>
          <Set name="scanInterval">1</Set>
        </New>
      </Arg>
    </Call>

위 코드에서 configurationDir 프로퍼티는 컨텍스트 설정 파일을 검색할 디렉토리를 입력한다. 위 설정의 경우 [JETTY홈]/contexts 디렉토리에 위치하는 컨텍스트 설정 파일을 이용해서 컨텍스트를 추가하게 된다. scanInterval 프로퍼티는 디렉토리 검색 주기를 초 단위로 입력한다. 지정한 시간 단위로 컨텍스트 설정 파일의 추가, 변경, 삭제 여부를 검사하여 이에 맞춰 컨텍스트를 추가하거나 변경하거나 제거한다.

configurationDir 프로퍼티에서 지정한 디렉토리에 위치하는 xml 파일들은 각각 개별 컨텍스트 정보를 설정한다. 웹 어플리케이션을 추가할 때에는 다음과 같은 형식의 설정 파일을 추가해주면 된다.

    <?xml version="1.0"  encoding="ISO-8859-1"?>
    <!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd">
    
    
    <Configure class="org.mortbay.jetty.webapp.WebAppContext">
    
      <Set name="contextPath">/</Set>
      <Set name="war"><SystemProperty name="jetty.home" default="."/>/webapps/hello.war</Set>
    
    </Configure>

contestPath 프로퍼티는 배포될 컨텍스트의 경로를 입력한다. 루트 컨텍스트인 경우 경로 값으로 '/'를 주면 된다. 다른 컨텍스트는 '/contextpath' 형식으로 컨텍스트 경로를 입력해주면 된다. war 프로퍼티에는 war 파일이나 웹 어플리케이션을 포함하고 있는 디렉토리 경로를 지정해주면 된다. 예를 들어, [JETTY홈]/webapps/hello 디렉토리에 웹 어플리케이션을 배포했다면 다음과 같이 war 프로퍼티의 값을 지정하면 된다.

    <Set name="war"><SystemProperty name="jetty.home" default="."/>/webapps/hello</Set>

맺음말

Jetty의 주요 특징으로는 다음과 같은 것들이 있다.

  • Ant, Maven, 이클립스 툴과의 연동을 지원하기 때문에, 개발 효율성을 증가시켜준다.
  • 간단한 Embedding. 코드에서 직접 Jetty 서버를 실행할 수 있다.
  • Comet 지원
  • 그외 가상 호스트, 응답 데이터 압축, SSL, 아파치 연동, JMX 연동 등 지원
Jetty는 매우 가벼운 웹 컨테이너이고 사용 방법도 매우 간단하다. 또한, Ant/Maven/이클립스 툴과 연동되기 때문에 개발을 효율성을 증가시켜준다. 필자 또한 개발 과정에서 Maven과 Jetty를 연동할 때 테스트 과정의 편리함을 느낄 수 있었다. 만약 톰캣의 대안을 찾고 있다면 Jetty를 고려해보기 바란다.

관련링크:

출처 - http://javacan.tistory.com/tag/Jetty%20%EC%82%AC%EC%9A%A9%EB%B2%95








Posted by linuxism
,


Bean Life Cycle 콜백 중에서 InitializingBean과 DisposableBean 인터페이스를 사용하거나 XML 설정에서 bean 태그 속성 중에 init-method와 destroy-method 을 사용하여 특정 메소드를 생성자가 호출 된 후(초기화 이후)나 객체가 소멸되기 전에 실행할 메소드를 지정할 수 있었습니다. 

이것에 대한 또 다른 대안이자 JSR-250 라이프사이클 애노테이션 표준을 따르는 @PostConstruct와 @PreDestroy 애노테이션이 Spring 2.1에 추가되었습니다.

public class CachingMovieLister {

    @PostConstruct
    public void populateMovieCache() {
        // populates the movie cache upon initialization...
    }
    
    @PreDestroy
    public void clearMovieCache() {
        // clears the movie cache upon destruction...
    }
    
}

사용법은 위 처럼 더욱 간편해 졌습니다.

정리하다 보니 궁금한 것이 생겼는데 애노테이션에서도 설정하고 XML에서도 설정을 하면 어떻게 될지 입니다.
그래서 예제를 만들어 돌려보았습니다.

public class SimpleMovieLister {

    public void initMethod(){
        System.out.println("initMetod");
    }

    @PostConstruct
    public void postConstuct(){
        System.out.println("postConstruct");
    }

}

    <bean name="lister" class="whiteship.SimpleMovieLister"
        init-method="initMethod" />

init-method 속성도 사용하고 @PostConstruct 애노테이션도 사용하면 다음과 같이 @PostConstruct가 먼저 적용되는 것을 확인할 수 있었습니다.

사용자 삽입 이미지


출처  - http://whiteship.tistory.com/tag/@PostConstruct%20%EC%95%A0%EB%85%B8%ED%85%8C%EC%9D%B4%EC%85%98




Posted by linuxism
,


웹 애플리케이션 서버(Web Application Server, 약자 WAS)는 인터넷 상에서 HTTP를 통해 사용자 컴퓨터나 장치에 애플리케이션을 수행해 주는 미들웨어(소프트웨어 엔진)이다.

웹 애플리케이션 서버는 동적 서버 콘텐츠를 수행하는 것으로 일반적인 웹 서버와 구별이 되며, 주로 데이터베이스 서버와 같이 수행이 된다. 한국에서는 일반적으로 "WAS" 또는 "WAS S/W"로 통칭하고 있으며 공공기관에서는 "웹 응용서버"로 사용되고, 영어권에서는 "Application Server" (약자 AS)로 불린다.

웹 애플리케이션 서버는 대부분이 자바 기반으로 주로 Java EE 표준을 수용하고 있으나, 자바 기반이지만 Java EE 표준을 따르지 않는 제품과 .NET이나 Citrix 기반인 비Java 계열도 존재한다.

목차

  [숨기기

[편집]개요

웹 애플리케이션 서버의 기본 기능은 3가지이다.

  • 프로그램 실행 환경과 데이터베이스 접속 기능을 제공한다.
  • 여러 개의 트랜잭션을 관리한다.
  • 업무를 처리하는 비즈니스 로직을 수행한다.

다만, 웹 애플리케이션의 정확한 정의는 존재하지 않아서 일부 기능을 제공하지 않는 웹 애플리케이션 서버도 존재한다. 업체들은 이러한 3가지 기능 말고도 여러 기능을 추가하고 강화하고 있다.

[편집]역사

1990년대 상반기 클라이언트/서버(C/S) 시스템에서는 클라이언트에 화면을 구성하는 각종 기능을 제공하는 리치 클라이언트 구조가 대세였다. 하지만, RDBMS를 포함하는 서버 가격은 매우 고가이고 변경이 편리하지 않은 단점이 있었다. 따라서, 업무 프로세스를 변경할 경우 화면 프로그램을 교체하는 경우가 있었으나, 그 당시는 사용자가 주로 인트라넷이었기 때문에 큰 어려움이 없었다.

1990년 후반 인터넷이 보급되면서 웹 브라우저를 사용한 전자상거래의 요구가 생기기 시작했다. 웹 브라우저를 주로 사용하는 시스템은 사용자가 불특정 다수이기 때문에 시스템의 변경에 따라 사용자의 화면을 수정하는 것은 거의 불가능하다. 이러한 요구와 함께 서버의 고성능화(UNIX서버 등의 저가의 고성능 서버 등장)와 초고속 네트워크 등장, 자바 등의 프로그램 언어의 처리능력 향상으로 애플리케이션의 위치가 클라이언트에서 서버로 전환되었다. 1990년대 후반에는 웹 브라우저를 화면으로 사용하면서 서버에서 애플리케이션을 수행하는 시스템이 일반화되었다.

[편집]분류

 이 문단은 위키백과의 편집 지침에 맞춰 다듬어야 합니다. 더 좋은 문단이 되도록 문단 수정을 도와주세요. 내용에 대한 의견이 있으시다면 토론 문서에서 나누어 주세요.

[편집]Java EE 표준준수 웹 애플리케이션 서버

[편집]정의

Java EE는, 자바의 기본적인 기능을 정의한 Java SE에 웹 서버 역할을 추가한 것으로 자바 애플리케이션을 동작시킬 수 있는 컨테이너 등을 표준화한 스펙이다. Java EE 표준준수 웹 애플리케이션 서버는 Java EE 스펙을 수용하는 웹 애플리케이션 서버이다.

[편집]구성요소

Java EE 표준기반 웹 애플리케이션에서 동작하는 프로그램 언어는 자바이다. 일반적으로 웹 모듈은 자바 서블릿 또는 JSP(Java Server Page)로 구성하고, 비즈니스 모듈은 EJB(Enterprise Java Beans)로 구성한다.

[편집]Java 기반이나 비표준준수 웹 애플리케이션 서버

[편집]기타 웹 애플리케이션 서버

[편집]제품

[편집]Java EE 표준준수 웹 애플리케이션 서버

제품명제작사최신버전출시일JavaEE 준수라이선스
제우스한국 티맥스소프트7.02012년 7월6.0상용
웹로직미국 오라클102007년 6월5.0상용
웹스피어미국 IBM7.05.0상용
레진미국 Caucho4.0.72010년 6월5.0상용
글래스피시미국 오라클3.1.12011년 7월6.0오픈소스(CDDL,GPL)
제이보스미국 레드햇7.1.0.CR1b2011년 12월6.0오픈소스(LGPL)
인터스테이지일본 후지쯔9.0.02007년1.4상용
기타 등등

[편집]Java 기반이나 Java EE 비준수 웹 애플리케이션 서버

[편집]기타 등등

[편집]같이 보기






응용 프로그램 서버 ( 영어 : application server )는 비즈니스 로직 등을 구현 한 응용 소프트웨어 를 실행하는 것을 전문으로하는 컴퓨터 네트워크 상의 서버 컴퓨터 또는 그런 컴퓨터에서 응용 프로그램의 실행을 관리 보조하는 미들웨어 의 수.

애플리케이션 서버라고 부르는 경우 일반적으로 Java EE 를 채용 한 웹 응용 프로그램 서버를 가리키고 Citrix 에 따르면 Citrix Presentation Server 나 . NET (닷넷)에 준한 서버는 애플리케이션 서버라는 것은 적다.

웹 애플리케이션 서버는 웹 클라이언트에서 HTTP 응답 요청을 처리하는 웹 서버 와 백 엔드 관계형 데이터베이스 관리 시스템 (RDBMS)을 중심으로 한 데이터베이스 핵심 계층의 중개를 담당, 데이터 가공 등의 작업을 수행 .

목차

  [ 숨기기 ] 

개요 편집 ]

응용 프로그램 서버의 기본적인 기능과되는 것은 다음 세 가지이다.

그러나 응용 프로그램 서버의 기능에 대한 정확한 정의는 존재하지 않기 때문에 이러한 기능이 없다 애플리케이션 서버도 존재한다. 또한이 3 가지 기능 이외에 각 공급 업체의 기능이 향상되고있는 것도 많다.

이후 본고에서는 웹 애플리케이션 서버의 기재를 중심으로한다.

웹 3 층 구성 편집 ]

일반적인 웹 시스템의 대부분은 " 웹 3 층 구성 "라는 구성으로 설계되어있는 것이 많다. 이 웹 3 층 설계는 다음의 3 개의 층으로 구성되어있다.

웹 시스템을 각각 3 개의 층에 구현을 나누어 수직 분산함으로써 각 층 단위로 확장 (서버 증설로 성능을 향상시킬 수)이 가능하며, 확장 성 및 비용도 크게 향상되고있다 .

일반적으로 3 계층 시스템은 인터넷이 등장하기 전에 고전적인 비 웹 응용 프로그램 등에서 자주 사용 된 클라이언트와 백엔드 단에 비즈니스 로직 을 구현하는 방식 (2 계층 시스템)에 비해 시스템의 변경 및 업데이트, 강화 등이 쉽고 유연성이 높은 시스템 구성 것으로 알려져있다. 특히 웹 어플리케이션 화하여 클라이언트 (웹 브라우저)와 응용 프로그램 계층을 분리함으로써 고전적인 2 계층 시스템 등이었다 시스템 갱신시 "비싼 핵심 데이터베이스 자체와 그 서버의 필요 제원 변경 에 따라 교체해야한다 "라는 고민이 해소되고 비용이 저렴했다. 그러나 대신 웹 브라우저의 제한 사항에 틀어 가기 어려운되게되었다.

역사 편집 ]

1990 년대 전반의 클라이언트 서버 기반의 시스템에서는 클라이언트 측을 전용 단말기로 다양한 기능을 제공하는 리치 클라이언트 형 시스템 구축이 주류였다. 이것은 관계형 데이터베이스 관리 시스템 (RDBMS) 등 서버 가 매우 고가이며 변경 (교체)가 쉽지 않았다 때문이다. 따라서 업무 프로세스가 바뀌면 단말기 측의 프로그램 을 업데이트하거나 교체 할 필요가 있었지만, 많은 경우, 이용자는 사내의 인간 등에 한정되어 있었기 때문에 큰 문제가되지 않았다.

1990 년대 후반, 인터넷 이 보급을 시작하면 웹 브라우저 를 이용한 전자 상거래 등의 요구가 확산된다. 웹 브라우저를 클라이언트로 사용 시스템은 서비스 대상자가 불특정 다수가 될 수 많은 시스템의 변경에 따라 이용자 모든 환경을 업데이트하는 것은 사실상 불가능하다. 따라서 서버 측에 업무 프로세스 등 각종 응용 프로그램을 준비하는 것이 요구되게되었다. 이 요청에 대해 응용 프로그램 클라이언트에서 서버로의 이행은 서버 측 컴퓨터의 고성능화 ( UNIX 서버 등으로 대표되는 비교적 저렴하고 고성능 서버의 등장)과 네트워크의 고속화, Java 등 의 프로그램 언어 의 처리 고속화 기술 등의 진전 등에 의해 가능 해졌다. 1990 년대 후반은 웹 브라우저를 클라이언트로 사용하여 다양한 작업을 서버 측에서하는 시스템이 일반화하고있다.

인터넷을 이용한 클라이언트 서버 시스템 은 서버 측에 다양한 기능이 요구된다. 예를 들어 e 커머스 사이트는 상품 정보를 표시하고 여러 상품의 주문 확인란 을 확인하고 최종적으로 상품의 결제를 할 필요가있다. 이 서비스를 구현하려면 대화식 처리 보장과 인증 / 개인 정보 보호 등 보안 면 확보, 안정성 · 가용성 확보 등 다양한 요구 사항과 기능을 보장 할 필요가있다.

서버가 고성능화했다고하지만 대규모 시스템에서는 이러한 요구에 모두 대처 해 나가는 것은 곤란하다. 따라서 기존 웹 서버에서만 처리해온 내용을 웹 서버 와 애플리케이션 서버 의 2 개로 분리하는 것으로,보다 많은 트랜잭션 처리 에도 대응할 수있는 방식 (3 층 구조 시스템)가 실용화되었다. 1998 년경부터 본격적인 제품이 등장하기 시작했다.

웹 응용 프로그램 서버에 요구되는 기능 편집 ]

웹 응용 프로그램 서버는 다음과 같은 요구 사항을 캡처하기 위해 작성이 진행 구현되어있다.

기능 요구 사항요구 사항 설명비고
시스템의 확장 성 및 가용성소비자를 대상으로 한 전자 거래 상용 시스템 등의 경우, 처리 요청이 매우 많은 (수 만건 / 분이라는 것도 많다)되고, 수평 (서버를 증가) / 수직 (서버를 기능 단위로 분리) 방향 부하 분산을 고려할 필요가있다. 웹 애플리케이션 서버에서는 수직으로 인증 기능과 그에 따른 인증 데이터베이스를 LDAP 서버 (디렉토리 서비스 )으로 분리하는 것이 일반화하고있다. 수평에서는 서버의 대수를 동적으로 늘려 대처하고 로드 밸런서 및 웹 서버의 배분 기능 대당 처리 요구 액세스 수를 조정한다. 또한 처리 서버 대수를 늘리고, 분배함으로써 시스템으로 가용성을 보장한다.
세션 관리 기능시스템에 연결 및 처리 요청이 증가하면 단일 웹 응용 프로그램 서버 만에서 서비스를 제공하는 것이 불가능하다. 따라서 웹 애플리케이션 서버 프로세스를 늘리거나 서버 자체를 늘리는 수평 분산이 필요하다.

그 때,로드 밸런서 세션 지속성 기능 공급 소요의 처리가 특정 응용 프로그램 서버에 할당되지만, 응용 프로그램 서버에 이상이 발생했을 때 다른 응용 프로그램 서버에 처리가 전달된다. 이 세션 관리 기능을 통해 다시 로그인 처리와 처음부터 상호 작용의 시도를 할 것이 아니라 특정 위치까지의 롤백 처리에서 정보를 점거하고 사용자에게 스트레스없이 처리를 계속할 필요가있다.

트랜잭션 관리 기능웹 브라우저 를 사용하는 경우, 통신 프로토콜 은 HTTP 를 이용한 것이며, 트랜잭션 은 요청 - 응답 단발이되지 않을 수 없다. 따라서 일련의 액세스를 일관성을 갖게 한 트랜잭션으로 관리 할 필요가 발생한다. 이러한 트랜잭션의 일관성을 유지하는 트랜잭션 모니터 기능도 필요하다.
트랜잭션의 고속 처리 기능기존의 CGI 와 비교하여 서버 측 Java ( Java EE ) 및 스크립트 언어 환경에서 프로세스 의 처리는 스레드 단위로 시분할 처리된다. 프로세스의 생성은 부하가 높은 하나의 Java 프로세스에서 여러 스레드를 동시에 실행할 수 있기 때문에 효율적으로 처리 할 수 필요한 스펙을 작게 할 수있다.
데이터베이스 연결 / 응답 기능사용자의 요청을 처리마다 데이터베이스와의 연결과 개방을 반복하면 큰 병목 된다. 이를 방지하기 위해, JDBC 풀링 등 DB 연결을 유지하고 그것을 사용 돌리는 기능을 제공한다.
보안 기능응용 프로그램 서버로 처리를 실시하는데있어서의 각종 보안 요구 사항이 발생한다. 이것을 간단하게 HTTP 기반의 보안 측면 ( TLS 의 채용 / 전자 인증)뿐만 아니라, 트랜잭션 기반도 확보 할 필요가있다.
시스템 개발 기간을 단축 할 수있는 공통적 인 프레임 워크 기반의 채용웹 응용 프로그램 사용의 장점, Java 등의 프로그램 언어 및 응용 프로그램 프레임 워크 의 채용에 의한 개발 공정의 단순화 및 단축이있다. 웹 애플리케이션 서버는 개발 환경이나 프로그램 군의 이용 환경을 정비함으로써 그 장점을 살릴 수 있도록하고있다.

응용 프로그램 서버의 분류 편집 ]

광의의 의미에서의 애플리케이션 서버 라는 용어는 프로그래밍 언어 로 구현 된 응용 프로그램 소프트웨어를 작동시키는 서버 서비스를 의미한다.

특히 웹 액세스에 특화 한 애플리케이션 서버, 마이크로 소프트 제품 및 Java 기반의 제품으로 대별 할 수있다. 특히 Java Platform, Enterprise Edition (Java EE)의 성공은 애플리케이션 서버 라는 용어는 J2EE 애플리케이션 서버 를 보여줄 수 많아졌다. 현재는 J2EE의 것을 Java EE라고 부르듯 호칭이 변경되어있다.

Java EE 애플리케이션 서버 편집 ]

정의

Java EE 표준 기능 세트 인 Java Platform, Standard Edition (Java SE)에 웹 서버 에 필요한 각종 기능을 추가 한 것으로, Java 모듈의 컨테이너 기능 등을 제공하는 것을 J2EE 애플리케이션 서버와 호칭하고있다.

보충

Java EE 애플리케이션 서버에서 응용 프로그램 동작을 설명하는 프로그래밍 언어 로 채용되고있는 것은 Java 이다. 일반적으로 웹 모듈은 Java Servlet 과 JavaServer Pages (JSP)로 구축되고 백엔드 프로그램은 Enterprise JavaBeans (EJB)로 개발된다. Servlet은 웹 컨테이너에서 실행되는 Java 프로그램에서 CGI 스크립트 에 해당한다. JSP는 서버 로직에 대한 참조를 포함시키는 것이로 HTML 페이지를 생성하는 기술이다. Java Beans 는 썬 마이크로 시스템즈 의 Java 아키텍처에서 클래스 의 부품 화 및 그 조합 방법을 규정하는 기술 사양이다.

또한이 Servlet 컨테이너에서 동작하는 웹 응용 프로그램의 응용 프로그램 프레임 워크 Apache Struts ( 아파치 Jakarta 프로젝트) 등이있다. 이 프레임 워크에 많은 종류가 서로 영향을주고 있고, 발전하고있다.

기타 응용 프로그램 서버 편집 ]

정의

J2EE 이외의 언어 세트 프레임 워크를 사용하여 비즈니스 로직을 구현 할 수있는 응용 프로그램 서버입니다. 대표적인 예로, Windows 2000 이후의 안정성과 Windows 에서 사용자 인증 기능을 바탕으로 많은 기능을 함유 한 . NET 프레임 워크에 준한 것이있다.

보충

. NET 프레임 워크에 따른 것으로, 오픈 소스 및 상용 애플리케이션 서버도있다. Base4 애플리케이션 서버 와 Zope 를 예로들 수있다. 마이크로 소프트의 Windows Communication Foundation 응용 프로그램 서버보다는 통신 프레임 워크 또는 미들웨어 라고 말해야 것이다. 그러나. Net 연계 경우도 Windows 사용자 인증 기능 및 LDAP 를 이용한 것이있다. 그러나. NET 계 어플리케이션 서버의 채용 수는 매우 낮고, 공식 발표도 보도되고 있지 않다.

포털 사이트 제품 편집 ]

많은 포털 사이트 제품은 Java EE 애플리케이션 서버와 사용자 인증 기능을 제공하는 LDAP, 또한 싱글 사인온 을 제공하는 확장 기능을 연계하고, 일반적인 응용 프로그램 서버기구 할 수있다.

WebSphere Application Server 와 OracleApplicationServer, BEA WebLogic Server 와 같은 통합 된 유료 상용 제품은 하나의 진입 점에서, 어떤 디바이스에서도 모든 웹 서비스 에 액세스 할 수 있도록 설계되어 있으며, 유연 있다.

J2EE 애플리케이션 서버 목록 편집 ]

제품명벤더버전출시Java EE 대응라이센스
Apache GeronimoASF2.2.12010 년 12 월 11 일5.0Apache 라이센스
JBoss레드햇7.02011 년 7 월 12 일6.0LGPL
WebSphere Application ServerIBM8.02011 년 6 월 28 일6.0독점
Oracle WebLogic Server오라클10g Release 32008 년 8 월5.0독점
JEUS티맥스 소프트6.02007 년 6 월 13 일5.0독점
Sun JSAS썬 마이크로 시스템즈9.12007 년 9 월 17 일5.0무료
GlassFish오라클3.1.12011 년 7 월 28 일6.0무료 ( CDDL , GPL )
Oracle AS오라클10g (10.1.3)2005 년 3 월 23 일1.4독점
OrionOrion2.0.62005 년 3 월 23 일1.3
SAP WASSAP AG6.40-1.3독점
Cosminexus히타치 제작소9.02012 년 2 월6.0독점
Interstage후지쯔V9.2.02009 년 8 월 10 일1.4/5.0독점
WebOTX선관위8.42011 년 5 월 25 일5.0독점
JOnASObjectWeb4.8.12006 년 8 월 8 일1.4LGPL
AppDev StudioSAS Institute3.1.42005 년 3 월1.3
BlazixDesiderata Software1.22005 년 3 월NO무료
Borland ES볼랜드2005 년 3 월1.3
ColdFusion어도비 시스템즈10.0.02012 년 5 월6.0독점
Dynamo ASATG6.32005 년 3 월1.3
EAServer사이베이스5.1.92005 년 3 월 23 일NO독점
EnhydraLutris5.1.92005 년 3 월 23 일NO무료 (GPL)
VOBSEnhydraNEC 소프트5.12003 년 8 월 7 일1.3/1.4독점
exteNd노벨5.1.92005 년 3 월 23 일NO무료 (GPL)
JRun어도비 시스템즈4.0.72007 년 10 월1.3
ApusicKingdee4.02005 년 3 월 23 일1.4
OnceAS중국 과학원2.02005 년 3 월 23 일1.4
PramatiPramati4.1 SP12005 년 3 월 23 일NO무료 (GPL)
ResinCaucho4.0.272012 년 3 월 22 일6.0Dual GPL
TriforkTriforkT42005 년 3 월 23 일1.4
WebObjects애플5.4.12008 년NO독점


관련 항목 편집 ]

외부 링크 편집 ]
























Posted by linuxism
,