Enterprise Java Beans 2008 5 28 Style System

Enterprise Java. Beans 2008. 5. 28 Style System 1

목차 1. Enterprise Technology 2. 3. 4. 5. 6. 7. 8. 9. J 2 EE EJB Client Session Bean Entity Bean JMS Transaction Security 2

1. Enterprise Technology 1. 2 분산환경과 분산객체 분산환경(Distributed Environment)이라는 것은 System을 이루는 Resource(자원)들이 물리적 혹은 논리적으로 같은 곳에 있지 않음을 뜻한다. 분산환경시스템은 앞으로 종종 언급이 될 것이지만 여러가지 이점들을 가진다. 이러한 분산환경은 오랜 시간에 걸친 System Development Environment(시스템 구축환경) 진보의 결과이다. 　 　　　　 Architecture관점에서의 System Development Environment • • Mainframe Architecture 2 -Tier Architecture 3 -Tier Architecture n-Tier Architecture 4

1. Enterprise Technology 1. 3 Component Programming 1. 3. 2 Component Model [각 Tier별 Component Model] 12

2. J 2 EE 2. 3 J 2 EE Standard Service J 2 EE에서 제공하는 Standard Service는 다음과 같다. J 2 EE Standard Service Servlet JSP (Java Server Page) EJB (Enterprise Java. Bean) JDBC (Java Database Connectivity) JMS (Java Message Service) JNDI (Java Naming and Directory Service) JTA (Java Transaction API) Java Mail JAF (Java Activation Framework) RMI-IIOP(RMI over IIOP) 16

2. J 2 EE 2. 3 J 2 EE Standard Service J 2 EE 에서는 다음과 같은 여러 가지 Service를 제공하며 그 서비스를 이용하여 여러 가지 기술을 이용할 수 있다. Services Technologies WEB Servlet/JSP Database JDBC Messaging JMS E-mail Java Mail Naming and Directory JNDI Transaction JTA Data Formats XML, HTML Protocol TCP/IP, IIOP, S니, HTTP(S) Distributed Object Framework Java. IDL, RMI, RMI-IIOP 17

2. J 2 EE 2. 5 J 2 EE Implementation Architecture J 2 EE의 구현 Architecture는 크게 4부분으로 나뉜다. [J 2 EE의 구현 Architecture] 1. Client Layer 사용자 Interface를 담당하는 Layer이다. 자바 Applet이나 Application을 통해 구현할 수 있다. 직접 EJB Layer를 호출하는것 보다 Web Layer를 통해 호출하는것이 바람직하다. 2. Web Layer Servlet과 JSP로 구성된다. Servlet은 Web Layer의 Business Logic을 담당하고 JSP는 Presentation의 역할을 한다. 3. EJB Layer 대부분의 Business Logic을 담당하는 Layer이다. Web Layer의 Servlet이 이 역할을 할 수 있으나, 안정적이고 용이한 System을 구축하기 위해서는 EJB Layer는 필수적인 부분이다. 4. Database Layer 정보를 저장하고 있는 Layer이다. 자바와 독립적이다. 20

2. J 2 EE 2. 6 J 2 EE Application의 구성 개발자가 J 2 EE환경에서 개발한 System을 흔히 J 2 EE Application이라고 부른다. J 2 EE Aplication의 핵심은 앞장에서 언급한 Web Layer와 EJB Layer이다 [J 2 EE Application의 구성] J 2 EE Application에서 Web Layer를 구성하는 Web Module은. war로 EJb Layer를 구성하는 EJB Module은. jar로 압 축되어 ear파일에 포함된다. 이렇게 하나의 파일로 압축된 J 2 EE Application은 어떤 J 2 EE Application Server에도 Deploy(배치) 될 수 있다. 21

2. J 2 EE 2. 7 J 2 EE Application의 전개 2. 7. 2 개발 단계별 Role 1. EJB Developer 실제로 EJB를 개발하는 사람들이다. 주어진 Business Logic에 맞게 EJB를 개발하며, 배치 설명 파일(Deploy Descriptor File)을 작성하고 다른 EJB와 함께. jar파일을 만든다. 2. Application Assembler 개발된 EJB들과 기타 요소들을 취합하여 완성된 Application을 개발한다. 사용자 Interface쪽을 개발하는 역할 을 한다. 3. Deployer J 2 EE Application Server에 완성된 EJB Application을 설치한다. 사실 J 2 EE Application Server마다 설정이 다르 기 때문에 EJB Application이 잘 수행되도록 J 2 EE Application Server의 Resource를 설정하는 역할은 매우 중 요하다. 4. System Administrator J 2 EE환경을 위한 System을 구축하고 이를 관리하는 역할을 담당한다. 5. EJB Container 제공자 및 J 2 EE Application Server 제공자 J 2 EE Application이 설치될 서버를 제공한다. 24

3. EJB 3. 2 EJB Framework 3. 2. 1 EJB Server는 크게 두 부분으로 나눌 수 있다. • • EJB Server EJB Container EJB Server에는 Enterprise Bean class를 동작시킬 수 있는 Container가 존재한다. [EJB Server의 구성요소] EJB Server는 J 2 EE의 기본 스펙으로 많은 업체에서 여러 제품들을 만들어내고 있다. EJB Server에는 Enterprise Bean class를 동작시킬 수 있는 Container가 존재한다. Web Server에 JSP와 Servlet을 동작시킬 수 있는 Engine이 존 재 하듯이 EJB 스펙에 맞는 Container가 존재한다. 또한 EJB Server에서는 J 2 EE에서 정의하고 있는 다음과 같은 여러가지 Service를 제공하고 있다. • • Transation Database access Naming and Directory Resource access 26

3. EJB 3. 2. 2 EJB Container는 Enterprise Bean class를 동작시키는 역할을 한다. Enterprise Bean class가 Container에 전개되어질 때에는 자동으로 Home Interface와 Remote Interface를 Home Object와 EJB Object로 Code를 Generation시켜준다. Enterprise Bean Class가 동작할 때는 EJB Server 에서 제공하 는 여러 가지 Service들을 접근할 수 있고 제어할 수 있는 Interface를 제공한다. EJB Container도 EJB Server와 마찬가지로 J 2 EE에서 정의하고 있는 여러가지 Service를 제공한다. • • • Transaction Control Persistence Security Life Cycle Management EJB Instance Identification EJB를 개발할때, 개발자는 Business Logic 구현 이외의 System과 관련된 복잡한 일들은 J 2 EE Application Server에 내장되어 있는 EJB Container가 제공하는 Service를 받아 사용하면 된다. EJB Container가 제공하는 Service들에는 다음과 같은것들이 있다. • • Resource Management 분산 객체 Protocol Thread Management and Synchronize Transaction Persistence Security JNDI(Java Naming and Directory Interface) 27

3. EJB 3. 3 EJB Application의 구성 3. 3. 1 EJB Application의 구성 EJB 방법론을 이용하여 Enterprise Bean class를 만들고 이를 EJB Server에 전개 시키기 위해서는 다음과 같은 요소 가 필요하다. • • Home Interface Remote Interface Enterprise Bean class Deployment Descriptor [EJB의 구성 요소] 28

3. EJB 3. 3 EJB Application의 구성 3. 3. 2 Home Interface는 Client를 위해서 Enterprise Bean을 생성, 관리하고 삭제하는 역할을 한다. Enterprise Bean Class는 Client가 직접 접근하는것이 아니라, Home Interface를 통해 생성되거나 찾아진다. Home Interface는 EJBHome Interface를 상속 받으며, EJB Container는 이러한 Home Interface를 구현하는 class를 자동으로 만들어 준다. (이러한 class를 artifact라고 한다. ) [EJBHome 인터페이스 Source code] Home Interface를 개발할 때 주의할 사항은 다음과 같다. 1. create()메소드는 Enterprise Bean Class의 ejb. Create()메소드와 Argument, Type이 일치해야 한다. 2. create()의 return type과 argument는 다음 중 하나의 type이어야 한다. -Primitive Type -java. io. Serializable -java. rmi. Remote 3. create()의 return type은 Enterprise Bean의 Remote Interface type이어야 한다. 4. create()는 Remote. Exception, Create. Exception을 throw 해야 한다. 30

3. EJB 3. 3 EJB Application의 구성 3. 3. 3 Remote Interface는 Client에서 호출할 Business Method를 선언해 놓은 Interface이다. Remote Interface는 EJBObject를 상속 받는다. EJB Container는 이 interface를 구현하는 class를 자동으로 만들어 준다. 이렇게 EJB Container가 자동으로 만들어 주는 Class들을 artifacts라고 한다. Remote Interface를 개발할 때 주의할 사항은 다음과 같다. 1. Remote Interface에 정의된 method들은 반드시 Enterprise Bean Class에서 구현해야 한다. 2. Remote Interface에서 정의된 method의 argument와 return type은 다음 중 하나의 type이어야 한다. -Primitive Type -java. io. Serializable -java. rmi. Remote 3. Remote Interface에서 정의된 method는 Remote. Exception을 throw해야 한다. 31

3. EJB 3. 3 EJB Application의 구성 3. 3. 4 Enterprise Bean Class는 Interface에서 정의한 method들의 실제 Body를 구현한다. Enterprise Bean Class는 크게 세가지의 EJB Type에 따라 다르게 만들어 질 수 있다. • • • Session Bean Entity Bean Message Driven Bean [Enterprise Bean] 32

3. EJB 3. 4 Enterprise Bean의 구분 Enterprise Bean은 크게 3가지로 나눈다. • • • Session Bean Entity Bean Message-Driven Bean 34

3. EJB 3. 4 Enterprise Bean의 구분 3. 4. 2 Entity Bean [Entity. Bean Interface Source. Code] 오랫동안 보존해야 하는 Data는 주로 Database에 저장되고, 흔이 이 Data를 Entity라고 부른다. Entity Bean이란 이와 같은 Database에 저장되어 있는 Data가 EJB로 표현된 것을 말한다. 36

3. EJB 3. 5 J 2 EE Application 실행과정 [J 2 EE Application이 실행되는 과정] ①② : Client가 JNDI의 기능을 이용하여 J 2 EE Application Server에서 Home interface를 찾아낸다. 또한 EJB Container는 이 interface를 구현한 class를 생성하고 객체화 한다. ( 이와 같이 EJB Container가 자동으로 생성해 주는 class들을 가리켜 artifact라고 부른다. ) ③ : Client는 Home interface를 implement한 class를 통해 create()메소드를 호출하는데, 이로 인해 Enterprise Bean객 체가 생성되며 ejb. Create()가 호출된다. ④ : Home interface를 implement한 class의 객체는 또한 Remote interface를 implements한 class를 만들고 이를 객체 화 시킨다. 그리고 이 객체의 Reference를 Client로 전달한다. 38

3. EJB 3. 5 J 2 EE Application 실행과정 [J 2 EE Application이 실행되는 과정] ⑤⑥ : Client는 이렇게 전달된 Remote interface를 implements한 class의 객체 Reference를 통해 Business 를 호출한 다. ⑦ : Remote interface를 implements한 class의 객체는 이 요구를 Enterprise Bean에 전달하여 구현된 Business Method가 실행되도록 한다. 이 작업은 Web Module인 Servlet이나 JSP를 호출해도 같은 방식으로 일어난다. 39

4. EJB Client & EJB Sample Program 4. 2 EJB에서 JNDI의 사용 EJB Container는 JNDI를 이용해 Component를 찾을 수 있는 Service를 제공한다. JNDI에는 Naming Context라는 것이 존재해서 Component의 환경 정보를 가지고 있다가, Client의 요청에 따라 적절 한 Service를 해준다. 위의 예는 local환경에 Client가 EJB Server의 Naming Service에 접근하는 예이다. 위의 예는 Client System과 EJB Server가 Remote한 상태에 있을 경우의 예이다. props. put("java. naming. factory. initial", "com. sun. jndi. cosnaming. CNCtxt. Factory"); 특정 EJB Server에서 제공하는 Naming Service에 접근할 수 있는 JNDI Driver에 대한 정보이다. props. put("java. naming. provider. url", "iiop: //"+args[0]+": 1050"); Protocol과 IP, Naming Service Port정보이다. 41

5. Session Bean 5. 2 Stateless Session Bean 5. 2. 2 Stateless Session Bean작성 대부분의 Enterprise Bean의 작성이 그렇듯이 Stateless Session Bean의 작성에는 Home interface, Remote interface, Bean Class와 같은 3가지 Server Code가 필요하다. 각각의 code를 작성함에 있어서 유의사항은 다음과 같다. Home Interface • • java. ejb. EJBHome을 반드시 상속 받아야 한다. Argument를 갖지 않는 create() Method를 반드시 선언해야 한다. Method는 javax. ejb. Create. Exception과 java. rmi. Remote. Exception을 반드시 throws해야 한다. create() Method는 Remote Interface타입을 Return해야 한다. Remote Interface 45

5. Session Bean 5. 2 Stateless Session Bean 5. 2. 2 Stateless Session Bean작성 Stateless Session Bean Class • • • javax. ejb. Session. Bean을 반드시 Implements한다. Class는 반드시 public으로 선언한다. Class는 abstract나 final로 선언될 수 없다. 한 개 이상의 ejb. Create() Method를 구현한다. Remote Interface에서 선언한 Business Method를 구현한다. Parameter를 갖지 않고 public으로 선언된 Constructor를 구현한다. finalize Method를 구현해서는 안된다. javax. ejb. Session. Bean으로 상속 받은 3개의 ejb. XXX()Method들과 set. Session. Context()을 구현한다. ejb. Create() Method는 반드시 public void로 선언되어야 하며, static이나 final로 선언할 수 없다. Business Method는 EJB에서 정의된 이름을 사용할 수 없고, public void로 선언되어야 하며, static이나 final로 선언될 수 없다. 46

5. Session Bean 5. 3 Stateful Session Bean 5. 3. 2 Stateful Session Bean의 작성 Stateless Session Bean과 마찬가지로 Stateful Session Bean의 작성에는 Home Interface, Remote Interface Bean class와 같은 3가지 Server Code가 기본적으로 필요하다. 각 Code의 설명은 다음과 같다. Home Interface 대부분의 규칙은 Stateless Session Bean과 동일하며, create() Method에 RMI타입의 Parameter를 가질 수 있고, 사용자 정의 Exception을 throws할 수 있다. Remote Interface Stateless Session Bean의 내용과 동일하다. 50

5. Session Bean 5. 3 Stateful Session Bean 5. 3. 2 Stateful Session Bean의 작성 Enterprise Bean Class • • • 일반적인 내용은 Stateless Session Bean과 유사하며, ejb. Create() Method에서 RMI타입의 Parameter를 가질 수 있고, 대화 상태를 나타내는 속성 값은 Parameter값으로 초기화한다. ejb. Activate() Method는 활성화 될 때 필요한 Code를 구현한다. (예 : 자원의 재할당 ~DB connection open) ejb. Passivate() Method는 비활성화 될 때 필요한 Code를 구현한다. (예 : 자원의 반납 - DB connection close) 51

5. Session Bean 5. 3 Stateful Session Bean 5. 3. 3 Stateful Session Bean의 동작원리 [Stateful Session Bean Life Cycle] Stateful Session Bean이 활성화/비활성화 상태로의 전이를 갖기 때문에 필요한 경우 ejb. Activate()와 ejb. Passivate() method에서 상태전이에 필요한 Code를 구현해야 한다. Stateful Session Bean이 Passive상태로 가기 직전에 ejb. Passivate()가 호출되고 다시 사용자가 호출할 때 자동적으 로 ejb. Activate()가 호출된다. 53

6. Entity Bean 6. 1 Entity Bean이란? 6. 2 Entity Bean API (Entity Bean Interface) Entity Bean을 만들기 위해서는 Entity Bean Interface를 implements하여 만들게 된다. Entity Bean은 생성되어짐에 따라 Container는 Entity. Context Interface를 자동으로 구현하여 Entity Bean객체에 넘겨 준다. 이 두가지 Interface에 대해서 알아보자. Entity Bean Interface는 Session Bean Interace와 같은 Method를 제공하고 추가적으로 Data를 지속적으로 관 리하도록 하는 몇개의 Method를 제공한다. Entity Bean Inteface 선언 메소드 • • • ejb. Activate() ejb. Passivate() set. Entity. Context(Entity. Context) unset. Entity. Context() ejb. Load() ejb. Store() 56

6. Entity Bean 6. 1 Entity Bean이란? 6. 2 Entity Bean API (Entity Bean Interface) 각각의 메소드역활 • ejb. Load(), ejb. Store() Container가 DB의 Data와 동기화가 요구되는 시점에 자동으로 Container에 의해 실행한다. 이 Method의 목적은 Bean의 Persistence를 유지하는데에 있다. • set. Entity. Context(Entity. Context)/unset. Entity. Context() Bean Instance가 최초에 생성될 때 set. Entity. Context()가 호출되고 삭제될 때 unset. Entity. Context()가 호출된다. • ejb. Activate() ejb. Passivate() ejb. Activate()는 Bean이 Pool영역에 초기에 생성된 후 Client에 의해 Ready상태로 전환될 때 Container에 의해 자동으로 호출된다. Bean의 초기화 역할을 한다. ejb. Passivate()는 Ready상태의 Bean이 다시 Pool로 이동할 때 Container에 의해 호출된다. Bean이 동작된 이후 모든 자원을 반납하는 역할을 한다 57

6. Entity Bean 6. 1 Entity Bean이란? 6. 2 Entity Bean API (Entity. Context Interface) Entity. Context Interface는 Bean Instance가 생성된 후 각각의 Bean의 set. Entity. Context()에 의하여 Setting 되어진다. (set. Entity. Context()는 Bean Instance생성 후 Container에 의해 자동으로 호출되어진다. ) Entity. Context 객체는 set. Entity. Context()를 통해 Setting되어지고 이것은 해당 Bean Instance가 존재하는 동안 반 드시 유지되어야 한다. Entity. Context Interface는 Session. Context Interface경우와 같이 EJBContext를 상속받는다. 그러나 Entity. Bean의 경 우, EJBObject에서 Primary Key를 요구하기 때문에 get. Primary. Key()라는 추가적인 메소드를 가진다. get. Primary. Key()라는 method는 Bean Instance가 현재 연결되어 있는 Data의 Primary Key 값을 Return한다. Bean 내 부에서 Primary Key값을 필요로 할 경우 이 method를 호출한다. Entity Interface의 다른 메소드인 get. EJBObject()는 해당 Bean Instance의 EJB Object 참조를 Return한다. 58

6. Entity Bean 6. 1 Entity Bean이란? 6. 3 Entity Bean의 Life Cycle [Entity Bean의 Life Cycle] EJB Container는 Entity Bean을 만든 후, Entity. Context를 set. Entity. Context()메소드를 통해 Entity Bean에 할당한다. 그리고 Entity Bean은 Pool에 저장된다. 이때 모든 Entity Bean은 Identify(식별성)을 가지고 있지 않다. Client는 Entity Bean의 finder Method나 create Method를 호출하여 Entity Bean을 Ready 상태로 만들수 있고, 이 때 ejb. Create(), ejb. Post. Create() 또는 ejb. Finder. XXX() Method가 호출된다. 이렇게 Ready 상태의 Bean들은 Identity(Primary Key객체)를 갖게 된다. Client는 Entity Bean의 데이터 관련 Business Method를 호출하게 되고, EJB Container는 이 Entity Bean의 상태를 Database에 저장하기 위해 ejb. Load()와 ejb. Store()를 주기적으로 호출한다. EJB Container는 Entity Bean을 Pool로 Passivate(비활성화)시킬때 ejb. Passivate()를 호출하고 반대로 Activate(활성 화)되면 ejb. Activate()가 호출된다. Pool에 존재하는 Entity Bean이 삭제(Remove)될 경우 Database의 해당 Row는 삭제되며 Entity. Bean의 unset. Entity. Context()가 호출된다. 59

6. Entity Bean 6. 4 Entity. Bean의 구성 6. 4. 1 Remote. Interface [Remote Interface의 예] Entity. Bean의 Remote. Interface도 Session Bean과 마찬가지로 Client가 호출할 수 있는 Business Method들을 선언 한다. 이 Business Method는 대부분 Entity Bean의 상태를 변경시키는 Method일 경우가 많으며 이러한 Entity. Bean의 상태변화는 해당 Database의 Data를 변경시키는 작업을 하게된다. 위의 예제는 Entity Bean의 각 Member들의 값을 읽어 들이는 Method를 정의하였다. 60

6. Entity Bean 6. 4 Entity. Bean의 구성 6. 4. 2 Home. Interface [Home Interface의 예] 61

6. Entity Bean 6. 4 Entity. Bean의 구성 6. 4. 2 Home. Interface (Method규칙) Entity Bean의 Home. Interface는 Session. Bean의 Home. Interface와 달리 복잡하다. Home. Interface에 선언되는 메소드들은 다음과 같은 규칙을 지켜야 한다. 1. create. XXX Method Entity. Bean의 초기화에 사용되는 create. XXX Method는 Method 이름에 접두사 create를 반드시 가져야 한다. -create. XXX Method의 Argument List는 Entity Bean Class의 ejb. Create. XXX Method의 Argument List와 일치해야 한다. -Return Type은 Remote. Interface Type이어야 한다. -Entity Bean Class의 ejb. Create. XXX method에서 throws한것과 같은 Exception들을 throws해야 한다. -throws절에는 Remote. Exception과 Create. Exception을 표기할 수 있다. 다음은 위의 예제에서 create. XXX Method 부분이다. 62

6. Entity Bean 6. 4 Entity. Bean의 구성 6. 4. 2 Home. Interface (Method규칙) 2. finder Method Finder Method는 특정 조건으로 Entity Bean 객체를 찾아내는 메소드로 Entity Bean Class에 반드시 하나 이상 존재해야 한다. 또한 "finder"라는 접두어로 시작해야 한다. 이 method의 Return Type은 Entity. Bean의 Remote. Interface Type이거나 java. util. Collection또는 java. util. Enumeration Type이다. 전자는 조건에 검색된 Entity Bean객체가 하나일 경우이고 후자는 여러개가 검 색된 경우이다. 특히, Home Interface는 Primary Key 객체를 이용하여 Entity Bean 객체를 찾는 find. By. Primary. Key()라는 Method를 가지고 있어야 한다. 다음은 위의 예제에서 finder Method의 부분이다. 63

6. Entity Bean 6. 4 Entity. Bean의 구성 6. 4. 2 Home. Interface (Method규칙) 3. Home Method는 특정 Entity Bean과 관계없는 Business Logic을 담고 있는 Method이다. 다시말해 Session Bean에 주로 존재하는 Method 같은 것들이다. 이 같은 Home Method는 create, find, remove 같은 접두어로 시작하면 안되고, Return Type과 Arguement Type 은 모두 RMI / IIOP Type이어야 한다. 또한 Remote. Exception과 같은 Exception을 throws 절에 기술할 수 있다. 다음은 위의 예제에서 Home Method의 부분이다. 64

6. Entity Bean 6. 4 Entity. Bean의 구성 6. 4. 3 Entity Bean Class를 개발할 때는 다음과 같은 규칙을 지켜야 한다. • Enterprise. Bean Interface를 implements 해야한다. • public으로 선언되어야 하며 abstract나 final로 선언되면 안된다. • Argument가 없는 Constructor가 존재해야 한다. • ejb. Create()가 존재하며 이에 해당하는 ejb. Post. Create()가 존재해야 한다. • final Method를 가질 수 없다. • Business Method를 가질 수 있다. Entity Bean class에서 구현되는 Method • ejb. Create. XXX() / ejb. Post. Create. XXX() ejb. Create. XXX()로 받아들이는 Argument들은 Entity Bean을 초기화 하는데 사용되며, Return Type은 Entity Bean의 Primary Key Class이다. 그리고 이 메소드에 해당하는 ejb. Post. Create()메소드가 존재한다. ejb. Create. XXX()나 ejb. Post. Create. XXX()가 존재하지 않을 경우는 Client가 직접 Entity Bean 객체를 만들지 못하 게 하는 것이다. 앞에서 언급한 BMP의 경우 ejb. Create. XXX()에 Data를 Database에 저장하는 SQL Code가 기술되나 CMP의 경 우엔 모든 일을 EJB Container가 해줌으로 null 값을 Return하기만 하면 된다. ejb. Create. XXX() 구현시 주의사항 - public으로 선언한다. - Return Type은 Primary Key Type이다. - Argument는 RMI/IIOP에 적합한 Type이다. - final이나 static을 사용할 수 없다. ejb. Post. Create. XXX()구현시 주의사항 - ejb. Create. XXX()과 항상 같은 Argument를 받는다. - Return Type은 void이어야 한다. 65

6. Entity Bean 6. 5 BMP를 이용한 Entity. Bean 6. 6 CMP 1. 1/2. 0을 이용한 Entity. Bean 67

7. Message Driven Bean 7. 1 JMS란? 7. 1. 1 PTP(Peer-To-Peer). [PTP Message System Architecture] PTP방식은 Sender와 Receiver가 Queue를 이용해서 Message를 주고 받는 형태이다. 또한 이 방식은 Sender가 보 내는 Message는 오로지 한 Receiver만 받게 되어 있다. 그림처럼 MOM은 Queue를 가지고 있어 Sender가 보낸 Message를 보관하고 있고, Receiver는 원하는 시간에 Message를 가져갈 수 있다. 이 때, Receiver는 MOM에게 Message를 잘 받았다는 ACK신호를 보낸다 69

7. Message Driven Bean 7. 2 JMS의 구성요소 7. 2. 2 Connection. Factory Message Receiver는 MOM과 연결하기 위해서 Connection 객체를 필요로 한다. Connection. Factory객체는 Connection에 관한 정보를 가지고 있으면서 Connection객체를 생성할 수 있는 Interface이다. [Connection. Factory의 종류] Connection. Factory 객체에는 2가지 종류가 있는데 첫번째는 PTP에서 사용하는 Queue. Connection. Factory이고 다 른 하나는 PUb/Sub방식에서 사용하는 Topic. Connection. Factory이다. 각각의 객체는 JNDI Name으로 등록되며, Program Code에서는 다음과 같이 JNDI Name을 이용하여 찾을 수 있다. Queue. Connection. Factoryq. Conn. Factory =(Queue. Connection. Factory)context. lookup("Queue. Connection. Factory "); 72

7. Message Driven Bean 7. 2 JMS의 구성요소 7. 2. 2 Connection. Factory에는 create. XXXConnection()이라는 method가 존재하는데, 이를 이용하여 Connection객체를 생 성할 수 있다. Queue. Connection q. Conn=q. Conn. Factory. create. Queue. Connection(); Connection. Factory는 이미 언급했지만 Administrated Object이므로 다음과 같이 도스창에서 j 2 eeadmin명령어로 생 성해야 한다. j 2 eeadmin -add. Jms. Factory Queue. Connection. Factory Queue 또한 이미 등록되어 있는 Connection. Factory들은 다음과 같은 명령어로 찾아 볼 수 있다. j 2 eeadmin -list. Jms. Factory 73

7. Message Driven Bean 7. 2 JMS의 구성요소 7. 2. 3 Destination 통신Program에서 일반적으로 접속, 즉 Connection이 일어나려면 IP Address와 Port Number가 필요하다. 하지 만 Message System에서는 MOM을 제공하는 Vendor들마다 사용하는 주소방식이 상이하기 때문에 표준을 지정하기 가 곤란한다. 따라서 MOM에서는 Destination이라는 객체를 사용하는데, 이것은 Sender나 Receiver가 Message를 주고 받을 곳 을 지칭하는 가상 채널정도라고 말할 수 있다. (일반적으로 Destination 객체는 MOM자체를 지칭한다. ) PTP에서는 Destination은 보통 Queue라고 불리며, Sub/Pub에서는 Topic이라고 불린다. Destination역시 Administrated Object이므로 다음과 같은 명령어로 등록된다. j 2 eeadmin -add. Jms. Destination my. Queue or j 2 eeadmin -add. Jms. Destination my. Topic 그리고 Program Code에서는 다음과 같이 Destination객체를 찾을 수 있다. Queue queue=(Queue)ctx. lookup("my. Queue"); or Topic topic=(Topic)ctx. lookup("my. Topic"); 74

7. Message Driven Bean 7. 2 JMS의 구성요소 7. 2. 4 Connection Connection객체는 Sender와 Receiver를 MOM과 연결해 주는 객체이다. 이 연결은 TCP/IP 형태로 이루어진다. 사실 Sender가 MOM에게 Message를 보내려면 Session이라는 객체가 필요한데, 이 객체는 바로 Connection객체를 통해 서 얻어진다. Connection객체 역시 PTP의 Queue. Connection과 Topic. Connection 두가지 종류가 있다. 사용된 Connection객체는 Program 종료 시 close()를 호출해서 닫아주어야 한다. 다음은 Program Code에서 Connection객체를 생성하는 예이다. Queue. Connection q. Conn = q. Conn. Factory. create. Queue. Connection(); or Topic. Connection t. Conn = t. Conn. Factory. create. Topic. Connection(); 다음은 Program Code에서 Connection 객체를 Close하는 예이다. q. Conn. close(); or t. Conn. close(); 75

7. Message Driven Bean 7. 2 JMS의 구성요소 7. 2. 5 Session은 Message를 생성(Produce)하고 소비(Consume)하기 위한 환경을 제공한다. 특히 Session은 Message. Producer와 Message. Consumer를 생성하며 Temporary Destination객체를 생성한다. Session에는 Queue. Session과 Topic. Session 두가지 종류가 있다. Queue. Session을 생성하기 위해서는 Queue. Connection을 이용해야 하고, Topic. Session을 생성하기 위해서는 Topic. Session을 생성해야 한다. 다음은 Program Code에서 Connection객체를 생성하는 예이다. Queue. Session q. Session =q. Conn. create. Queue. Session(false, Session. AUTO_ACKNOWLEDGE); or Topic. Session t. Session = t. Conn. create. Topic. Session(false. Session. AUTO_ACKNOWLEDGE); 사용된 첫번째 Argument는 Session이 Transaction에 포함되는지 아닌지를 설정한다. 참고로 'true'로 Setting될 경우, 두번째 Argument는 무시된다. 두번째 Argument는 전달된 Message의 ACK를 제어하는 내용인데, 뒷부분에서 자세히 설명할 것이다. 여기서는 Receiver가 Message를 받으면, 잘 받았다는 내용을 Sender에게 자동으로 보낸다. 76

7. Message Driven Bean 7. 2 JMS의 구성요소 7. 2. 6 Message Producer Message를 Destination객체에 전달하기 위해서는 Message Producer가 필요하다. PTP에서는 Message Producer 를 Queue. Sender라고 부르며, Pub/Sub에서는 Topic. Publisher라고 부른다. Queue. Session의 create. Sender()를 이용하면 Queue. Sender객체를 생성할 수 있고, Topic. Session의 create. Publisher() 를 이용하면 Topic. Publisher객체를 만들 수 있다. 다음은 Program Code에서 각각의 Message Producer를 생성하는 예이다. Queue. Sender q. Sender = q. Session. create. Sender(Queue); or Topic. Publisher t. Publisher = t. Session. create. Publisher(Topic); 이렇게 생성된 Message Producer를 통해 Message를 전송하기 위해서는 다음처럼 send()나 publish()를 이용한다. q. Sender. send(Message); or t. Publisher. publish(Message); 77

7. Message Driven Bean 7. 2. 7 Message Consumer Message Producer로 부터 생성되어 전해진 Message를 받기 위해서는 Message Consumer가 필요하다. PTP에서는 Message Consumer를 Queue. Receiver라고 부르며, Pub/Sub에서는 Topic. Subscriber라고 부른다. Queue. Session의 create. Receiver()를 이용하면 Queue. Receiver 객체를 생성할 수 있고, Topic. Session의 create. Subscriber()를 이용하면 Topic. Subscriber객체를 만들 수 있다. Message를 받는 방식에는 다음과 같은 동기식 방식과 비동기식 방식이 있다. 동기식 방식 이 방식을 사용하는 Client가 Message를 소비하기 위해서 receiver()를 호출한다. receiver()가 호출되면 Client는 Message가 모두 도착하거나 Time-Out될 때까지 Block상태에 놓인다. 비동기식 방식 이 방식을 사용하는 Client는 Event Delegation Model을 사용하여 Event Handler를 등록할 수 있다. Event Handler 는 Message. Listener Interface를 implements해야 한다. Message가 목적지에 도착할 때 마다 on. Message()가 자동 호출된다. 다음은 Program Code에서 각각의 Message Consumer를 생성하는 예이다. Queue. Receiver q. Receiver=q. Session. create. Receiver(Queue); or Topic. Subscriber t. Subscriber = t. Session. create. Subscriber(Topic); 이렇게 생성된 Message Consumer를 통해 Message를 전송 받기 위해서는 다음처럼 먼저 Connection객체가 가지 고 있는 start()를 호출해야 한다. 그 후, Queue. Receiver나 Topic. Subscriber에 있는 receive()를 이용하면 Message 를 받을 수 있다. q. Conn. start(); Text. Message = (Text. Message) q. Receiver. receive(1); receive()의 첫번째 Argument는 Time-Out을 의미한다. (1/1000 초) 다음 Code는 비동기식 방식을 이용하여 Message를 소비한다. 다음의 Code처럼 Topic. Subscriber 객체의 set. Message. Listener() 를 이용해 Event handler에게 Message소비를 위임한다. t. Subscriber. set. Message. Listener(listener); 다음은 Event handler의 Code이다. 78

7. Message Driven Bean 7. 3. 1 Message 객체는 JMS에서 Application Program사이에 주고 받는 Data를 의미한다. 이같 은 Message객체는 3부분으로 나눌 수 있다. Header JMS Client와 MOM Server에서 사용되는 통신정보를 가지고 있다. Property Option항목으로 JMS Client나 MOM Server의 고유한 정보가 포함되어 있다. Body Message의 내용이 포함되어 있다. JMS에는 다음과 같이 크게 5가지 형태의 Message Type이 있다. Text. Message : 문자열 Data로서 String Type이다. Map. Message : 이름과 값의 쌍으로써, 이름은 String Type이고 값은 Primitive Type이다. Byte. Message : Byte Stream Data Type Object. Message : 79

7. Message Driven Bean 7. 3 Message 7. 3. 2 Message ACK제어 MOM은 Client가 Message를 잘 받았다는 확인을 받은 후에야 Message소비가 성공적으 로 끝났다고 판단한다. 성공적인 Message 소비는 다음과 같은 3단계를 거친다. Client가 Message를 받는다 Client가 Message를 처리한다 MOM에게 Message를 잘 받았다는 확인 Message를 전송한다. Transaction이 포함된 Session인 경우 Transaction이 Commit되면 확인 Message는 자동 적으로 전달된다. 만약 Transaction이 Rollback되면 소비된 모든 Message는 다시 Client에게 전달된다. Transaction이 포함된 Session이 아닌 경우는 create. Queue. Session()이나 create. Topic. Connection()의 Argument로 어떤 값을 사용하느냐에 따라 확인 Message 를 전달하는 방식이 달라진다. 다음은 그러한 Argument List이다. AUTO_ACKNOWLEDGE : Client가 receive()를 성공적으로 수행하거나 Message. Listener의 Message가 잘 처리 된 경우 자동적으로 확인 Message가 전달된다. CLIENT_ACKNOWLEDGE : Client가 인위적으로 acknowledge()를 호출해야 확인 Message가 전달된다. 80

7. Message Driven Bean ７. 3. 3 Message 지속성 기술 Message가 전달되는 도중 JMS가 중단될 수 있다. 이 경우, Message는 사라질 수도 있고 유지될 수도 있다. JMS API에는 이것을 기술하기 위한 2가지 mode를 제공한다. PERSISTENT Delivery Mode : MOM은 MOM Service가 중단되는 경우, Message가 실종되지 않도록 한다. 이 모드는 Default속성이다. NON_PERSISTENT Delivery Mode : PERSISTENT Delivery Mode와 반대되는 속성이다. 이같은 mode를 설정할 수 있는 방법에는 2가지가 있다. Message. Producer Interface의 set. Delivery. Mode()를 이용한다. send()와 publish()의 Argument를 이용한다. 81

7. 2 JMS의 구성요소 7. 4 Java Message System의 활용 83

7. 5 JMS의 구성요소 7. 5. 2 Message Service Message Driven Bean을 통해서 Queue를 지원하는 Message Service를 살펴보자. [Message Driven Bean을 이용한 JMS] 앞에서 봤던 Pn. P와 Pub/Sub처럼 Client Program과 J 2 ee. Server만을 이용하는 것이 아니라 Session Bean과 Entity Bean처럼 j 2 ee. Server에 Deploy를 시켜서 사용하는 Bean을 제작하고 Deploy하여 사용하는 과정까지 를 살펴보자. 84

8. 2 EJB에서의 Transaction Enterprise 환경에서의 Transaction처리에 있어서는 다음과 같은 처리가 주요하다. 분산 Transation 2 -Phase Commit Flat Transaction 각각에 대하여 자세히 살펴보자 8. 2. 1 분산 Transaction EJB Container가 제공하는 Service중에 하나로 분산(Distributed) Transaction은 Network로 연결된 여러 자원들을 하 나의 Transaction으로 관리하는 것을 말한다. [분산(Distributed) Transaction] 87

8. 2 EJB에서의 Transaction 8. 2. 2 2 -Phase Commit 일반적으로 J 2 EE Application 개발시 Transaction은 EJB Container에 포함된 Transaction Manager라는 것을 이용하여 처리한다. Transaction Manager는 각각의 DBMS(Resource Manager)와 주기적인 message교환을 통해 Transaction을 관리한 다. [Transaction Manager의 역할] Transaction Manager는 일반적으로 2 -Phase Commit이라는 것을 통해 Transaction을 관리한다. 2 -Phase Commit은 다음과 같은 절차로 일어난다. 1. Transaction 관리 프로그램은 관련된 모든 DBMS들을 대신하여 Transaction을 조정한다. Transaction관리 프로그램은 관련된 다른 컴퓨터들에게 Transaction요청을 보낸다. 88

8. 2 EJB에서의 Transaction 8. 2. 3 EJB Transaction EJB 개발시 Transaction의 관리는 전적으로 EJB Container가 하게 할 수 있는데, 이것은 순수하게 EJB Container가 Deploy Descriptor의 정보를 가지고 Transaction을 관리하므로 Declarative(or Container Managed)Transaction Demarcation이라고 한다. Declarative Transaction은 Container-managed Transaction이라고 불리며, 모든 형태의 EJB에서 사용이 가능하 다. EJB 개발시 Transaction을 관리하는 방법 중 또 다른 하나는 개발자가 Program Code에 Transaction의 시작과 끝 을 나타내는 Code를 삽입해서 Transaction을 관리하는 Programmatic Transaction Demarcation이 있다. Programmatic Transaction은 Bean-Managed Transaction이라고 불리며, Session Bean과 Message Driven Bean 심지어 Servlet과 JSP에서도 사용가능하다. 이 Transaction은 JDBC Transaction기능을 사용하는 것과 JTA 의 기능을 사용하는 것으로 나뉜다. 89

8. 3 Bean-Managed Transaction은 프로그래머가 Transaction 처리부분을 Bean내부에 Code상으로 처리하는 방법이다. 즉 Programmatic하게 Transaction을 처리하겠다는 의미이다. 이러한 BMT를 Code상에서 처리하기 위해서는 다음과 같은 순서로 진행 된다. Transaction 생성 Transaction에 대한 상황 파악 Transaction에 대한 Commit Transaction에 대한 Rollback 다음은 Bean-Managed Transaction을 구현할 때 주의사항이다. Stateless Session Bean은 Method를 마치기 전에 Transation을 Commit하거나 Rollback해야 한다. Stateful Session Bean의 경우는 여러 Business Method를 Transaction으로 묶을 수 있다. 만약 Transaction을 끝마치지 않 고 Business Method를 종료했다면, 다음번 호출도 아직 끝나지 않은 Transaction에 포함된다. Message Driven Bean은 on. Message()가 끝나기 전에 Transaction을 Commit하거나 Rollback해야 한다. Container-Managed Transaction에서 사용할 수 있는 get. Rollback. Only()나 set. Rollback. Only()는 사용할 수 없다. Bean-Managed Transaction방법은 JDBC Transaction기능을 사용하는것과 JTA의 기능을 사용하는 것으로 나뉜다. JDBC Transaction을 이용한 방법 : Bean내부의 Transaction처리하는 Code를 Database의 Connection객체를 통해 직접 처리하는 방법이다. 이 방법 을 이용하면 각각의 Database의 Transaction을 프로그래머가 직접적으로 관리할 수 있다는 장점이 있다. Bean-Managed Transaction은 Transaction관리를 Database의 DBMS에 맡기는 것으로 JDBC Transaction을 사 용할 땐 java. sql. Connection class의 commit()과 rollback()을 이용해 Transaction을 관리한다. 이때는 java. sql. Connection 의 set. Auto. Commit(false)메소드를 호출하여 commit과 rollback을 명시적으로 수행할 수 있 게 해야한다. 90

8. 4 Container-Managed Transaction 이미 언급했듯이 이 방법은 모든 EJB에서 사용이 가능한 방법이며, 특히 Entity. Bean은 이 방법만 사용가능하다. 다른 말로 Declarative Transaction demarcation이다. 이 Transaction은 Deploy Descriptor에 제공된 명령어로 Transaction을 구분한다. 이러한 명령어를 일컬어 Transaction Attribute라고 한다. Transaction Attribute에는 6가지 종류가 있으며 Method실행 시 Transaction Scope를 어떻게 관리할 것인가에 의해 정해진다. 6가지 Transaction Attribute는 다음과 같다. Required Requires. New Not. Supported Support Mandatory Never [Transaction Scope] 위의 Transaction Scope그림의 환경을 바탕으로 각각의 Transaction Attribute의 특징을 알아보자 Required 가장 널리 사용되는 속성이다. 모든 Data변경작업이 단일 작업으로 처리되는 것을 보장한다. Caller가 Transaction에 포함된 경우 : worker()는 Transaction에 포함된다. 그렇지 않은 경우 : 91

8. 5 Session. Synchronization EJB Container가 Transaction을 Rollback시키는 경우엔 Session Bean의 변경된 내용은 원래상태로 돌아가지 않는다. Session Bean의 변경된 내용을 Rollback시키기 위해서는 일반적으로 Session Bean의 Session. Synchronization interface를 implements하여 처리한다. Session. Synchronization interface는 3가지 Method를 가지고 있다. public void after. Begin() Transaction이 시작되면서 호출된다. 따라서 Database에서 값을 읽어 instance variable등을 초기화하는 Code가 올 수 있다. public void before. Completion() Transaction이 끝나기 바로 직전에 호출된다. Transaction을 commit하지 말고 rollback해야 하는 경우가 발생했다면 이곳에서 set. Rollback. Only()를 호출하여 Transaction이 commit되는 것을 막을 수 있다. public void after. Completion(boolean committed) Transaction이 끝난 직후에 호출된다. Argument로 전달되는 boolean값은 Transaction이 commit, rollback여부를 알려준다. rollback이 되었을 경우 Session. Bean의 instance variable을 다시 초기화 해주는 코드가 올 수 있을 것이다. 92