[Directory Wiki] Update of "MinaTutorialInKorean" by everlong77

[Apache Wiki <wi...@apache.org>]

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 everlong77:
http://wiki.apache.org/directory/MinaTutorialInKorean

------------------------------------------------------------------------------
  
  == Protocol Layer: Reversing the Echo ==
  
- We learned how to use I/O layer via simplistic echo server example.  But have you ever imagined how you would implement complex protocols like LDAP?  It must be a nightmare because the I/O layer doesn’t help you separate message codec and actual business logic such as accessing a directory database.  MINA provides a Protocol layer to resolve this issue.  The Protocol layer transforms ByteBuffer events to POJO events which are at a higher-level:
+ 우리는 단순한 echo 서버 예제를 통해 I/O 레이어를 어떻게 사용하는지를 배웠다. 그러나 여러분은 LDAP(Lightweight Directory Access Protocol)과 같은 복잡한 프로토콜을 어떻게 구현할지에 대해 생각해 봤는가? 그것은 악몽과도 같을 것이다. 왜냐하면 I/O 레이어가 메시지 코덱과 실제 비즈니스 로직(ex.디렉토리 데이터베이스를 액세스)을 분리시키는데 도움을 못 주기 때문이다. MINA는 이러한 이슈를 해결하는 프로토콜 레이어를 제공한다. 이 프로토콜 레이어는 ByteBuffer 이벤트를 더 high-level 이벤트인 POJO 이벤트로 변환한다: 
  
  attachment:Arch3.gif
  
- You have to implement 5 interfaces: ProtocolHandler, ProtocolProvider, ProtocolCodecFactory, ProtocolEncoder, and ProtocolDecoder:
+ 여러분은 5개의 인터페이스를 구현해야 한다: ProtocolHandler, ProtocolProvider, ProtocolCodecFactory, ProtocolEncoder, 그리고 ProtocolDecoder: 
  
  attachment:ProtocolClasses.gif
  
- Maybe it looks like overkill, but please note that ProtocolCodecFactory, ProtocolEncoder, and ProtocolDecoder are fully reusable; Apache ASN1 project provides ASN.1 codec for MINA, and more common codecs like XML, Java object serialization, and simple text will be provided in the next release of MINA.  Once you implemente a flexible codec, you can reuse it in future applications.  Even if you don’t plan to reuse your codec, of course, MINA provides a quite easy way to implement complex protocols. (Please refer to Advanced Topics)
+ 어쩌면 이것은 너무 과하다고 생각될 수 있다. 그러나 ProtocolCodecFactory, ProtocolEncoder, 그리고 ProtocolDecoder 는 완전하게 재사용 가능하다는 점을 주목하기 바란다. Apache ASN1 프로젝트는 MINA를 위한 ASN.1 코덱을 제공하고 있는 상태이고 MINA의 다음 배포버전에는 XML, Java Object Serialization, 그리고 단순한 텍스트와 같은 더 common한 코덱이 제공될 것이다. 일단 유연한 코덱을 구현하고 나면, 여러분은 그것을 미래에 새로운 애플리케이션에서 재사용할 수가 있다. 물론, 여러분의 코덱을 재사용할 계획이 없다고 하더라도, MINA는 복잡한 프로토콜을 구현할 수 있는 꽤 쉬운 방법을 제공한다. (이 문서의 Advanced Topics 부분을 참고하라) 
  
- In this chapter, we create a ‘reverse’ server that reverses all text lines it receives to demonstrate how to program in protocol layer.
+ 이 챕터에서 우리는 프로토콜 레이어 부분을 어떻게 프로그래밍해야 할 지를 보여주기 위해 "역방향(reverse)" 서버를 만들 것인데, 이 역방향 서버는 서버가 받는 텍스트 라인을 반대로(역방향으로) 출력한다. 
  
  === ProtocolSession ===
  
  attachment:ProtocolSession.gif
  
- ProtocolSession is a counterpart of the I/O layer IoSession.  As you must have noticed from FIGURE X, you write messages as POJO's instead of ByteBuffer's.  ProtocolEncoder encodes message objects to ByteBuffers so that the I/O layer can write them to underlying sockets.
+ ProtocolSession은 I/O 레이어의 IoSession에 상응하는 부분이다. 그림 X에서 짐작했겠지만, ByteBuffer 대신에 POJO로 메시지를 작성한다. ProtocolEncoder는 I/O 레이어가 메시지 객체를 밑에 있는 소켓에게 작성(write)할 수 있게 해당 메시지 객체를 ByteBuffers로 인코딩한다. 
  
  === ProtocolHandler ===
  
  attachment:ProtocolHandler.gif
  
- ProtocolHandler is a counterpart of the I/O layer IoHandler.  dataRead and dataWritten methods are replaced with messageReceived and messageSent.  This is because ProtocolDecoder decodes ByteBuffers received from I/O layer into message objects.
+ ProtocolHandler은 I/O 레이어의 IoHandler에 상응하는 부분이다. dataRead 메소드와 dataWritten 메소드는 각각 messageReceived 메소드와 messageSent 메소드를 대신한다. 이것은 ProtocolDecoder가 I/O 레이어에서 받은 ByteBuffers를 메시지 객체로 디코딩하기 때문이다. 
  
  === ProtocolEncoder and ProtocolDecoder ===
  
  attachment:ProtocolCodec.gif
  
- ProtocolEncoder and ProtocolDecoder have just one method each.  ProtocolEncoder encodes message objects into a ByteBuffer, and ProtocolDecoder decodes ByteBuffers into message objects.  We’ll learn how to implement these interfaces below.
+ ProtocolEncoder와 ProtocolDecoder는 각각 하나의 메소드를 갖고 있다. ProtocolEncoder는 메시지 객체를 ByteBuffer로 인코딩하고, ProtocolDecoder는 ByteBuffers를 메시지 객체로 디코딩한다. 밑에서 우리는 이 인터페이스들을 어떻게 구현하는지에 대해 배울 것이다. 
  
  === Implementing ProtocolHandler ===
  
- Let’s implement a ProtocolHandler first.  We extend ProtocolHandlerAdapter here too, just like we did when we implemented IoHandler:
+ 먼저 ProtocolHandler를 구현하자. IoHandler를 구현할 때와 마찬가지로 여기에서도 우리는 ProtocolHandlerAdapter를 extend한다. 
  
  {{{
  package org.apache.mina.examples.reverser;
@@ -233, +233 @@

  
  === Implementing ProtocolProvider and Setup Code ===
  
- The only one interface left to implement reverse protocol is ProtocolProvider.  It is very simplistic:
+ 이제 역방향 프로토콜을 구현하기 위해 유일하게 남은 인터페이스는 ProtocolProvider이다. 이것은 매우 간단하다. 
  
  {{{
  package org.apache.mina.examples.reverser;
@@ -278, +278 @@

  }
  }}}
  
- That's it, the Reverser protocol is fully implemented now.  Startup code is very similar to that of echo server:
+ 이게 전부다. 이로써 Reverser 프로토콜은 완전하게 구현이 되었다. startup 코드는 에코 서버의 startup 코드와 매우 유사하다. 
  
  {{{
  package org.apache.mina.examples.reverser;
@@ -313, +313 @@

  
  === Adding ProtocolFilters ===
  
- ProtocolFilter is the counterpart of IoFilter from I/O layer:
+ ProtocolFilter는 I/O 레이어의 IoFilter에 상응하는 부분이다. 
  
  attachment:Arch4.gif
  
- Adding IoLoggingFilter logs low-level I/O events which are appropriate for debugging purposes.  We could use ProtocolLoggingFilter instead to log higher-level events:
+ IoLoggingFilter를 add하면 디버깅 목적에 적합한 low-level I/O 이벤트에 대한 로그를 출력한다. 더 높은 high-level 이벤트에 대한 로그를 출력하려면 ProtocolLoggingFilter을 사용한다.
  
  {{{
      private static void addLogger( ServiceRegistry registry )
@@ -330, +330 @@

  
  == Advanced Topics ==
  
- We cover more advanced topics for serious MINA users here.
+ 여기에서는 보다 MINA를 깊게 알고자 하는 사용자들을 위한 상급 토픽(advanced topics)을 다룬다. 
  
  === ByteBuffers ===
  
- MINA doesn’t use the Java NIO ByteBuffer class directly.  It uses custom a ByteBuffer class that extends the functionality of the Java NIO ByteBuffer.  Here are some differences:
+ MINA는 자바 NIO ByteBuffer를 직접적으로 사용하지 않는다. 자바 NIO ByteBuffer의 기능을 확장하는 커스텀 ByteBuffer 클래스를 사용한다. Java NIO ByteBuffer와 커스텀 ByteBuffer의 몇가지 차이점은 다음과 같다.
  
-   * MINA ByteBuffer is an abstract class that users can extend freely.
-   * MINA manages and pools MINA ByteBuffers.  Users can control the point the buffers are released by providing acquire() and release() methods.
-   * MINA ByteBuffer provides convenient methods like unsigned value getter and String getter and putter.
+   * MINA ByteBuffer는 사용자들이 자유롭게 확장할 수 있는 추상 클래스이다. 
+   * MINA는 MINA ByteBuffers를 관리하고 풀링한다. acquire()와 release() 메소드를 제공함으로써 사용자들은 버퍼가 릴리즈되는 시점을 조절할 수 있다. 
+   * MINA ByteBuffer는 unsigned 값의 getter와 스트링 getter & putter와 같은 편리한 메소드들을 제공한다. 
  
- If you use MINA, you’ll never need to use NIO buffers directly because you can do most buffer manipulation tasks using MINA buffers only.
+ 여러분이 만약 MINA를 쓴다면, NIO 버퍼를 직접적으로 쓸 필요가 절대 없을 것이다. 왜냐하면 거의 모든 버퍼 관련 작업을 MINA 버퍼만으로 할 수 있기 때문이다. 
  
  ==== ByteBuffer pooling ====
  
- MINA has a global ByteBuffer pool that is shared by all MINA applications in the same Virtual Machine.  Any allocated buffers are released after the I/O operation or event handler method is performed or invoked.  So you can simply call ByteBuffer.allocate() to get a clean buffer from the pool and forget about returning it to the pool.  Please refer to the ByteBuffer JavaDocs for more details.
+ MINA는 하나의 가상머신에서 실행중인 모든 MINA 애플리케이션들이 공유하는 Global ByteBuffer Pool을 갖고 있다. 할당된 모든 버퍼는 I/O 작업 혹은 이벤트 핸들러 메소드가 수행되거나 invoke된 후에 릴리즈된다. 그러므로 Pool에서 빈(clean) 퍼버를 얻기 위해서는 단순히 ByteBuffer.allocate()를 호출하면 되고 버퍼를 풀에 반환하는 것에 대해서는 신경 안 써도 된다. 더욱 세부적인 내용은 ByteBuffer JavaDocs을 참고하기 바란다. 
  
  === Thread Model ===
  
- MINA provides support for various threading models using its versatile filter mechanism.  It runs in a single thread mode when no thread pool filters are added.  If you add one IoThreadPoolFilter to IoAcceptor, you get one leader-follower thread pool.  If you add one more ProtocolThreadPoolFilter, Your server will have two thread pools; one (IoThreadPoolFilter) for decoding message objects and the other (ProtocolThreadPoolFilter) for processing business logic.
+ MINA는 MINA의 다양한 필터 메카니즘을 사용함으로써 다양한 쓰레딩 모델을 지원한다. 쓰레드 풀 필터가 하나도 추가되지 않았을 때에는 싱글 쓰레도 모드 상태에서 작동한다. IoThreadPoolFilter 하나를 IoAcceptor에 추가하면 하나의 리더-추종자(leader-follower) 방식의 쓰레드 풀이 생긴다. ProtocolThreadPoolFilter를 하나 더 추가하면, 여러분의 서버는 두 개의 쓰레드 풀을 가질 것이다; 메시지 객체를 디코딩하는 풀(IoThreadPoolFilter)과 비즈니스 로직을 수행하는 풀(ProtocolThreadPoolFilter). 
  
- The SimpleServiceRegistry adds IoThreadPoolFilter and ProtocolThreadPoolFilter which is adequate for applications that require high-scalability by default.  If you want to use your own threading model, please refer to the SimpleServiceRegistry source code and initialize Acceptors by yourself.  It is, of course, a trivial task.
+ SimpleServiceRegistry는 IoThreadPoolFilter와 ProtocolThreadPoolFilter를 추가하는데 이는 애초에 높은 확장성을 요구하는 애플리케이션에 적합하다. 만약 여러분의 (여러분이 직접 구현한) 쓰레딩 모델을 사용하고 싶다면, SimpleServiceRegistry의 소스 코드를 참고하고 Acceptors를 직접 초기화시켜라. 물론 이것은 매우 간단한 작업이다. 
  
  {{{
  IoThreadPoolFilter threadPool = new IoThreadPoolFilter();
@@ -374, +374 @@

  
  === More Complex Protocols ===
  
- ‘Reverser’ example is still too simple compared to other complex protocols.  There should be dozens of message types, and their codec is required to make the server work.  MINA provides the following utility classes to help you:
+ 역방향 (Reverser) 예제는 다른 복잡한 프로토콜들에 비해 너무 간단하다. 수십가지의 메시지 타입이 존재할 것이고 그에 따라 서버를 작동시키는 수십가지의 코덱이 존재할 것이다. MINA는 다음과 같은 유틸리티 클래스를 제공한다. 
  
    * DemuxingProtocolHandler
    * DemuxingProtocolCodecFactory
  
- Please refer to the JavaDocs for more details.
+ 세부적인 내용은 JavaDocs을 참고하기 바란다. 
  
  === In-VM Pipe Communication ===
  
- You must have learned that protocol layer is built on top of I/O layer, but it is not really true.  Though we usually use protocol layer that wraps I/O layer, there is a special implementation of protocol layer called as ‘in-VM pipe communication’.
+ 여러분은 프로토콜 레이어가 I/O 레이어 위에 구축된다는 것을 배웠다. 하지만 이는 전적으로 옳은 말은 아니다. 우리가 보통 I/O 레이어를 감싸는 (wraps) 프로토콜 레이어를 사용하긴 하지만, 여기에는 "in-VM pipe communication"이라 불리는 프로토콜 레이어의 특별한 구현체가 존재한다. 
  
- Let’s assume that you implement a SMTP server and a Spam Filter server in MINA.  The SMTP server will possibly communicate with the Spam Filter server to detect spam messages or any clients which are listed in the RBL.  If these two servers are in the same Java VM, an I/O layer is unnecessary; you can simply bypass encoding and decoding of message objects.  In-VM pipe communication enables you to use the same code regardless of whether spam filter server resides in the same VM or not.
+ 여러분이 SMTP 서버와 스팸 필터 서버를 MINA로 구현했다고 가정하자. SMTP 서버는 스팸 메시지를 탐지하거나 RBL(Realtime Blackhole List)에 속하는 클라이언트(메일 송신자)를 탐지하기 위해 아마도 스팸 필터 서버와 커뮤니케이션을 할 것이다. 만약 이 두 서버가 동일한 자바 가상머신에 있다면, I/O 레이어는 필요가 없다; 여러분은 메시지 객체를 인코딩 & 디코딩을 할 필요없이 단순히 우회시키기만(bypass) 하면 된다. In-VM pipe communication은 스팸 필터 서버가 동일한 VM에 있는지 없는지에 관계없이 동일한 코드를 사용할 수 있게 한다. 
  
- Please refer to the ‘Tennis’ example in the source distribution.
+ 소스 배포판에 있는 "테니스" 예제를 참고하기 바란다. 
  
  == How to Contribute ==