directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Directory Wiki] Update of "MinaTutorialInKorean" by dongchul lee
Date Mon, 16 Jan 2006 11:12:45 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Directory Wiki" for change notification.

The following page has been changed by dongchul lee:
http://wiki.apache.org/directory/MinaTutorialInKorean

------------------------------------------------------------------------------
  {
      /** Choose your favorite port number. */
      private static final int PORT = 8080;
-     
+ 
  
      public static void main( String[] args ) throws Exception
      {
          ServiceRegistry registry = new SimpleServiceRegistry();
-         
+ 
  // Bind
          Service service = new Service( "echo",
  TransportType.SOCKET, PORT );
@@ -166, +166 @@

  
  == Protocol Layer: Reversing the Echo ==
  
- 우리는 단순한 echo 서버 예제를 통해 I/O 레이어를 어떻게 사용하는지를
배웠다. 그러나 여러분은 LDAP(Lightweight Directory Access Protocol)과 같은 복잡한
프로토콜을 어떻게 구현할지에 대해 생각해 봤는가? 그것은 악몽과도
같을 것이다. 왜냐하면 I/O 레이어가 메시지 코덱과 실제 비즈니스 로직(ex.디렉토리
데이터베이스를 액세스)을 분리시키는데 도움을 못 주기 때문이다.
MINA는 이러한 이슈를 해결하는 프로토콜 레이어를 제공한다. 이 프로토콜
레이어는 ByteBuffer 이벤트를 더 high-level 이벤트인 POJO 이벤트로 변환한다:

+ 우리는 단순한 echo 서버 예제를 통해 I/O 레이어를 어떻게 사용하는지를
배웠다. 그러나 여러분은 LDAP(Lightweight Directory Access Protocol)과 같은 복잡한
프로토콜을 어떻게 구현할지에 대해 생각해 봤는가? 그것은 악몽과도
같을 것이다. 왜냐하면 I/O 레이어가 메시지 코덱과 실제 비즈니스 로직(ex.디렉토리
데이터베이스를 액세스)을 분리시키는데 도움을 못 주기 때문이다.
MINA는 이러한 이슈를 해결하는 프로토콜 레이어를 제공한다. 이 프로토콜
레이어는 ByteBuffer 이벤트를 더 high-level 이벤트인 POJO 이벤트로 변환한다:
  
  attachment:Arch3.gif
  
- 여러분은 5개의 인터페이스를 구현해야 한다: ProtocolHandler, ProtocolProvider,
ProtocolCodecFactory, ProtocolEncoder, 그리고 ProtocolDecoder: 
+ 여러분은 5개의 인터페이스를 구현해야 한다: ProtocolHandler, ProtocolProvider,
ProtocolCodecFactory, ProtocolEncoder, 그리고 ProtocolDecoder:
  
  attachment:ProtocolClasses.gif
  
- 어쩌면 이것은 너무 과하다고 생각될 수 있다. 그러나 ProtocolCodecFactory,
ProtocolEncoder, 그리고 ProtocolDecoder 는 완전하게 재사용 가능하다는 점을
주목하기 바란다. Apache ASN1 프로젝트는 MINA를 위한 ASN.1 코덱을 제공하고
있는 상태이고 MINA의 다음 배포버전에는 XML, Java Object Serialization, 그리고
단순한 텍스트와 같은 더 common한 코덱이 제공될 것이다. 일단 유연한
코덱을 구현하고 나면, 여러분은 그것을 미래에 새로운 애플리케이션에서
재사용할 수가 있다. 물론, 여러분의 코덱을 재사용할 계획이 없다고
하더라도, MINA는 복잡한 프로토콜을 구현할 수 있는 꽤 쉬운 방법을
제공한다. (이 문서의 Advanced Topics 부분을 참고하라) 
+ 어쩌면 이것은 너무 과하다고 생각될 수 있다. 그러나 ProtocolCodecFactory,
ProtocolEncoder, 그리고 ProtocolDecoder 는 완전하게 재사용 가능하다는 점을
주목하기 바란다. Apache ASN1 프로젝트는 MINA를 위한 ASN.1 코덱을 제공하고
있는 상태이고 MINA의 다음 배포버전에는 XML, Java Object Serialization, 그리고
단순한 텍스트와 같은 더 common한 코덱이 제공될 것이다. 일단 유연한
코덱을 구현하고 나면, 여러분은 그것을 미래에 새로운 애플리케이션에서
재사용할 수가 있다. 물론, 여러분의 코덱을 재사용할 계획이 없다고
하더라도, MINA는 복잡한 프로토콜을 구현할 수 있는 꽤 쉬운 방법을
제공한다. (이 문서의 Advanced Topics 부분을 참고하라)
  
- 이 챕터에서 우리는 프로토콜 레이어 부분을 어떻게 프로그래밍해야
할 지를 보여주기 위해 "역방향(reverse)" 서버를 만들 것인데, 이 역방향
서버는 서버가 받는 텍스트 라인을 반대로(역방향으로) 출력한다. 
+ 이 챕터에서 우리는 프로토콜 레이어 부분을 어떻게 프로그래밍해야
할 지를 보여주기 위해 "역방향(reverse)" 서버를 만들 것인데, 이 역방향
서버는 서버가 받는 텍스트 라인을 반대로(역방향으로) 출력한다.
  
  === ProtocolSession ===
  
  attachment:ProtocolSession.gif
  
- ProtocolSession은 I/O 레이어의 IoSession에 상응하는 부분이다. 그림 X에서
짐작했겠지만, ByteBuffer 대신에 POJO로 메시지를 작성한다. ProtocolEncoder는
I/O 레이어가 메시지 객체를 밑에 있는 소켓에게 작성(write)할 수 있게
해당 메시지 객체를 ByteBuffers로 인코딩한다. 
+ ProtocolSession은 I/O 레이어의 IoSession에 상응하는 부분이다. 그림 X에서
짐작했겠지만, ByteBuffer 대신에 POJO로 메시지를 작성한다. ProtocolEncoder는
I/O 레이어가 메시지 객체를 밑에 있는 소켓에게 작성(write)할 수 있게
해당 메시지 객체를 ByteBuffers로 인코딩한다.
  
  === ProtocolHandler ===
  
  attachment:ProtocolHandler.gif
  
- ProtocolHandler은 I/O 레이어의 IoHandler에 상응하는 부분이다. dataRead 메소드와
dataWritten 메소드는 각각 messageReceived 메소드와 messageSent 메소드를 대신한다.
이것은 ProtocolDecoder가 I/O 레이어에서 받은 ByteBuffers를 메시지 객체로
디코딩하기 때문이다. 
+ ProtocolHandler은 I/O 레이어의 IoHandler에 상응하는 부분이다. dataRead 메소드와
dataWritten 메소드는 각각 messageReceived 메소드와 messageSent 메소드를 대신한다.
이것은 ProtocolDecoder가 I/O 레이어에서 받은 ByteBuffers를 메시지 객체로
디코딩하기 때문이다.
  
  === ProtocolEncoder and ProtocolDecoder ===
  
  attachment:ProtocolCodec.gif
  
- ProtocolEncoder와 ProtocolDecoder는 각각 하나의 메소드를 갖고 있다. ProtocolEncoder는
메시지 객체를 ByteBuffer로 인코딩하고, ProtocolDecoder는 ByteBuffers를 메시지
객체로 디코딩한다. 밑에서 우리는 이 인터페이스들을 어떻게 구현하는지에
대해 배울 것이다. 
+ ProtocolEncoder와 ProtocolDecoder는 각각 하나의 메소드를 갖고 있다. ProtocolEncoder는
메시지 객체를 ByteBuffer로 인코딩하고, ProtocolDecoder는 ByteBuffers를 메시지
객체로 디코딩한다. 밑에서 우리는 이 인터페이스들을 어떻게 구현하는지에
대해 배울 것이다.
  
  === Implementing ProtocolHandler ===
  
- 먼저 ProtocolHandler를 구현하자. IoHandler를 구현할 때와 마찬가지로 여기에서도
우리는 ProtocolHandlerAdapter를 extend한다. 
+ 먼저 ProtocolHandler를 구현하자. IoHandler를 구현할 때와 마찬가지로 여기에서도
우리는 ProtocolHandlerAdapter를 extend한다.
  
  {{{
  package org.apache.mina.examples.reverser;
@@ -233, +233 @@

  
  === Implementing ProtocolProvider and Setup Code ===
  
- 이제 역방향 프로토콜을 구현하기 위해 유일하게 남은 인터페이스는
ProtocolProvider이다. 이것은 매우 간단하다. 
+ 이제 역방향 프로토콜을 구현하기 위해 유일하게 남은 인터페이스는
ProtocolProvider이다. 이것은 매우 간단하다.
  
  {{{
  package org.apache.mina.examples.reverser;
@@ -278, +278 @@

  }
  }}}
  
- 이게 전부다. 이로써 Reverser 프로토콜은 완전하게 구현이 되었다. startup
코드는 에코 서버의 startup 코드와 매우 유사하다. 
+ 이게 전부다. 이로써 Reverser 프로토콜은 완전하게 구현이 되었다. startup
코드는 에코 서버의 startup 코드와 매우 유사하다.
  
  {{{
  package org.apache.mina.examples.reverser;
@@ -290, +290 @@

  /**
   * (<b>Entry point</b>) Reverser server which reverses all text lines from
   * clients.
-  * 
+  *
   * @author Trustin Lee (trustin@apache.org)
   * @version $Rev: 165594 $, $Date: 2005-05-02 16:21:22 +0900 $,
   */
@@ -313, +313 @@

  
  === Adding ProtocolFilters ===
  
- ProtocolFilter는 I/O 레이어의 IoFilter에 상응하는 부분이다. 
+ ProtocolFilter는 I/O 레이어의 IoFilter에 상응하는 부분이다.
  
  attachment:Arch4.gif
  
@@ -330, +330 @@

  
  == Advanced Topics ==
  
- 여기에서는 보다 MINA를 깊게 알고자 하는 사용자들을 위한 상급 토픽(advanced
topics)을 다룬다. 
+ 여기에서는 보다 MINA를 깊게 알고자 하는 사용자들을 위한 상급 토픽(advanced
topics)을 다룬다.
  
  === ByteBuffers ===
  
  MINA는 자바 NIO ByteBuffer를 직접적으로 사용하지 않는다. 자바 NIO ByteBuffer의
기능을 확장하는 커스텀 ByteBuffer 클래스를 사용한다. Java NIO ByteBuffer와
커스텀 ByteBuffer의 몇가지 차이점은 다음과 같다.
  
-   * MINA ByteBuffer는 사용자들이 자유롭게 확장할 수 있는 추상 클래스이다.

+   * MINA ByteBuffer는 사용자들이 자유롭게 확장할 수 있는 추상 클래스이다.
-   * MINA는 MINA ByteBuffers를 관리하고 풀링한다. acquire()와 release() 메소드를
제공함으로써 사용자들은 버퍼가 릴리즈되는 시점을 조절할 수 있다.

+   * MINA는 MINA ByteBuffers를 관리하고 풀링한다. acquire()와 release() 메소드를
제공함으로써 사용자들은 버퍼가 릴리즈되는 시점을 조절할 수 있다.
-   * MINA ByteBuffer는 unsigned 값의 getter와 스트링 getter & putter와 같은
편리한 메소드들을 제공한다. 
+   * MINA ByteBuffer는 unsigned 값의 getter와 스트링 getter & putter와 같은
편리한 메소드들을 제공한다.
  
- 여러분이 만약 MINA를 쓴다면, NIO 버퍼를 직접적으로 쓸 필요가 절대
없을 것이다. 왜냐하면 거의 모든 버퍼 관련 작업을 MINA 버퍼만으로
할 수 있기 때문이다. 
+ 여러분이 만약 MINA를 쓴다면, NIO 버퍼를 직접적으로 쓸 필요가 절대
없을 것이다. 왜냐하면 거의 모든 버퍼 관련 작업을 MINA 버퍼만으로
할 수 있기 때문이다.
  
  ==== ByteBuffer pooling ====
  
- MINA는 하나의 가상머신에서 실행중인 모든 MINA 애플리케이션들이 공유하는
Global ByteBuffer Pool을 갖고 있다. 할당된 모든 버퍼는 I/O 작업 혹은 이벤트
핸들러 메소드가 수행되거나 invoke된 후에 릴리즈된다. 그러므로 Pool에서
빈(clean) 퍼버를 얻기 위해서는 단순히 ByteBuffer.allocate()를 호출하면 되고
버퍼를 풀에 반환하는 것에 대해서는 신경 안 써도 된다. 더욱 세부적인
내용은 ByteBuffer JavaDocs을 참고하기 바란다. 
+ MINA는 하나의 가상머신에서 실행중인 모든 MINA 애플리케이션들이 공유하는
Global ByteBuffer Pool을 갖고 있다. 할당된 모든 버퍼는 I/O 작업 혹은 이벤트
핸들러 메소드가 수행되거나 invoke된 후에 릴리즈된다. 그러므로 Pool에서
빈(clean) 퍼버를 얻기 위해서는 단순히 ByteBuffer.allocate()를 호출하면 되고
버퍼를 풀에 반환하는 것에 대해서는 신경 안 써도 된다. 더욱 세부적인
내용은 ByteBuffer JavaDocs을 참고하기 바란다.
  
  === Thread Model ===
  
- MINA는 MINA의 다양한 필터 메카니즘을 사용함으로써 다양한 쓰레딩
모델을 지원한다. 쓰레드 풀 필터가 하나도 추가되지 않았을 때에는
싱글 쓰레도 모드 상태에서 작동한다. IoThreadPoolFilter 하나를 IoAcceptor에
추가하면 하나의 리더-추종자(leader-follower) 방식의 쓰레드 풀이 생긴다.
ProtocolThreadPoolFilter를 하나 더 추가하면, 여러분의 서버는 두 개의 쓰레드
풀을 가질 것이다; 메시지 객체를 디코딩하는 풀(IoThreadPoolFilter)과 비즈니스
로직을 수행하는 풀(ProtocolThreadPoolFilter). 
+ MINA는 MINA의 다양한 필터 메카니즘을 사용함으로써 다양한 쓰레딩
모델을 지원한다. 쓰레드 풀 필터가 하나도 추가되지 않았을 때에는
싱글 쓰레도 모드 상태에서 작동한다. IoThreadPoolFilter 하나를 IoAcceptor에
추가하면 하나의 리더-추종자(leader-follower) 방식의 쓰레드 풀이 생긴다.
ProtocolThreadPoolFilter를 하나 더 추가하면, 여러분의 서버는 두 개의 쓰레드
풀을 가질 것이다; 메시지 객체를 디코딩하는 풀(IoThreadPoolFilter)과 비즈니스
로직을 수행하는 풀(ProtocolThreadPoolFilter).
  
- SimpleServiceRegistry는 IoThreadPoolFilter와 ProtocolThreadPoolFilter를 추가하는데
이는 애초에 높은 확장성을 요구하는 애플리케이션에 적합하다. 만약
여러분의 (여러분이 직접 구현한) 쓰레딩 모델을 사용하고 싶다면, SimpleServiceRegistry의
소스 코드를 참고하고 Acceptors를 직접 초기화시켜라. 물론 이것은 매우
간단한 작업이다. 
+ SimpleServiceRegistry는 IoThreadPoolFilter와 ProtocolThreadPoolFilter를 추가하는데
이는 애초에 높은 확장성을 요구하는 애플리케이션에 적합하다. 만약
여러분의 (여러분이 직접 구현한) 쓰레딩 모델을 사용하고 싶다면, SimpleServiceRegistry의
소스 코드를 참고하고 Acceptors를 직접 초기화시켜라. 물론 이것은 매우
간단한 작업이다.
  
  {{{
  IoThreadPoolFilter threadPool = new IoThreadPoolFilter();
@@ -374, +374 @@

  
  === More Complex Protocols ===
  
- 역방향 (Reverser) 예제는 다른 복잡한 프로토콜들에 비해 너무 간단하다.
수십가지의 메시지 타입이 존재할 것이고 그에 따라 서버를 작동시키는
수십가지의 코덱이 존재할 것이다. MINA는 다음과 같은 유틸리티 클래스를
제공한다. 
+ 역방향 (Reverser) 예제는 다른 복잡한 프로토콜들에 비해 너무 간단하다.
수십가지의 메시지 타입이 존재할 것이고 그에 따라 서버를 작동시키는
수십가지의 코덱이 존재할 것이다. MINA는 다음과 같은 유틸리티 클래스를
제공한다.
  
    * DemuxingProtocolHandler
    * DemuxingProtocolCodecFactory
  
- 세부적인 내용은 JavaDocs을 참고하기 바란다. 
+ 세부적인 내용은 JavaDocs을 참고하기 바란다.
  
  === In-VM Pipe Communication ===
  
- 여러분은 프로토콜 레이어가 I/O 레이어 위에 구축된다는 것을 배웠다.
하지만 이는 전적으로 옳은 말은 아니다. 우리가 보통 I/O 레이어를 감싸는
(wraps) 프로토콜 레이어를 사용하긴 하지만, 여기에는 "in-VM pipe communication"이라
불리는 프로토콜 레이어의 특별한 구현체가 존재한다. 
+ 여러분은 프로토콜 레이어가 I/O 레이어 위에 구축된다는 것을 배웠다.
하지만 이는 전적으로 옳은 말은 아니다. 우리가 보통 I/O 레이어를 감싸는
(wraps) 프로토콜 레이어를 사용하긴 하지만, 여기에는 "in-VM pipe communication"이라
불리는 프로토콜 레이어의 특별한 구현체가 존재한다.
  
- 여러분이 SMTP 서버와 스팸 필터 서버를 MINA로 구현했다고 가정하자.
SMTP 서버는 스팸 메시지를 탐지하거나 RBL(Realtime Blackhole List)에 속하는
클라이언트(메일 송신자)를 탐지하기 위해 아마도 스팸 필터 서버와
커뮤니케이션을 할 것이다. 만약 이 두 서버가 동일한 자바 가상머신에
있다면, I/O 레이어는 필요가 없다; 여러분은 메시지 객체를 인코딩 &
디코딩을 할 필요없이 단순히 우회시키기만(bypass) 하면 된다. In-VM pipe
communication은 스팸 필터 서버가 동일한 VM에 있는지 없는지에 관계없이
동일한 코드를 사용할 수 있게 한다. 
+ 여러분이 SMTP 서버와 스팸 필터 서버를 MINA로 구현했다고 가정하자.
SMTP 서버는 스팸 메시지를 탐지하거나 RBL(Realtime Blackhole List)에 속하는
클라이언트(메일 송신자)를 탐지하기 위해 아마도 스팸 필터 서버와
커뮤니케이션을 할 것이다. 만약 이 두 서버가 동일한 자바 가상머신에
있다면, I/O 레이어는 필요가 없다; 여러분은 메시지 객체를 인코딩 &
디코딩을 할 필요없이 단순히 우회시키기만(bypass) 하면 된다. In-VM pipe
communication은 스팸 필터 서버가 동일한 VM에 있는지 없는지에 관계없이
동일한 코드를 사용할 수 있게 한다.
  
- 소스 배포판에 있는 "테니스" 예제를 참고하기 바란다. 
+ 소스 배포판에 있는 "테니스" 예제를 참고하기 바란다.
  
  == How to Contribute ==
  

Mime
View raw message