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. 1 Enterprise Environment Internet Site에는 여러 종류가 있다. 개인 신상이나 가족 정보를 보여주는 간단한 Home Page에서부터 은행, 쇼핑몰, 기업의 Intranet과 같은 거대한 Enterprise급 website에 이르기까지 다양하다. 후자의 경우처럼 하루에 수천명이 드나드는 website는 몇십명 정도 드나드는 소규모의 개인 홈페이지와는 그 구조 자 체가 다를 수 밖에 없다. 다시 말해 Enterprise급 website는 하루에 수천번의 client요청도 효과적으로 처리할 수 있는 구조를 가져야 한다. Sun에서는 이 같은 거대한 Enterprise Environment를 고려한 개발방법론을 총체적으로 집약하여 J 2 EE라는 것을 개 발 하였고, 그 중 핵심적인 기술이 바로 EJB이다. 　　　　EJB를 한마디로 요약하면 　　　　　"Enterprise급 개발을 위한 Server Side 분산 객체(Distributed Object) Component"이다. 3

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. 2 분산환경과 분산객체 1. 2. 1 Mainframe Architecture 　　　Client/Server 시스템이 등장하기 전에는 기업들은 주로 IBM의 대형 컴퓨터(Main Frame Computer) 를 사용하였다. 대형 컴퓨터는 중앙에 놓여져 있고 실제 사용자들은 Dummy Terminal이라는 단말기를 이용하여 컴퓨터를 사용하였 다. Dummy Terminal은 실제 프로세싱 능력이나 data저장능력이 없이 단순한 통신 기능만을 수행하는 단말기를 말한 다. 사용자들은 이 단말기의 자판을 통하여 입력하고 단말기에 입력된 내용을 중앙 컴퓨터에 전달한다. 전달된 내용은 중 앙컴퓨터에서 처리하여 다시 단말기로 보내면 단말기 화면에 결과가 텍스트 형식으로 나타난다. 모든 프로그램은 중 앙컴퓨터에서 처리되므로 Presentation, Application, Data 에 관련된 Logic들이 모두 하나의 컴퓨터에서 처리되므 로 이러한 아키텍쳐를 Mainframe Architecture 라 한다. 5

1. Enterprise Technology 1. 2 분산환경과 분산객체 1. 2. 2 2 -Tier Architecture 2 -Tier 모델인 Client/Server 아키텍쳐는 실제 개인용 컴퓨터(Personal Computer)가 비약적으로 발전하여 강력한 프 로세싱 능력과 저장 능력을 갖게됨으로써 가능하였다. 개발자가 개발한 프로그램은 사용자들의 각각의 개인용 컴퓨터에 배포되었고 사용자들은 필요에 따라 이 프로그램들 을 자신의 PC에서 실행하여 사용하였다. 이러한 PC에서 실행되는 프로그램들은 화면을 처리하는 Logic(Presentation Logic)과 업무 처리 Logic (Application), 그리고 파일을 읽어들이고 저장하는 Logic(data)이 모두 하나의 프로그램 또는 컴퓨터에서 처리되도 록 되어 있다. 이러한 PC프로그램들은 개인이 사용하기엔 편리했지만 업무용 또는 여러 사람이 공유해서 사용하려면 많은 문제점 이 있었다. 특히 공유를 하지 못하기 때문에 기업이 사용하기에 적절하지 못했다. Data 공유문제를 실제로 해결했던 존재는 바로 Database관리 시스템(Database Management System) Server의 등장 이다. PC용 프로그램들은 자신의 컴퓨터에서 파일 처리를 포기하고 이러한 DBMS Server의 서비스를 받아 작업을 실 행하므로서 data의 공유문제를 해결하고 여러 사람들이 동시에 작업할 수 있는 업무용 시스템으로 자리를 잡았다. . 6

1. Enterprise Technology 1. 2 분산환경과 분산객체 1. 2. 2 3 -Tier Architecture 3 -Tier 방식의 Client/Server시스템은 Application Server라는 업무 Logic을 서비스하는 전용 Server를 설치하고 Business Logic이 담긴 프로그램을 Application Server를 대상으로 만들어 설치하게 된다. Client는 API를 이용하여 Application Server에 설치된 업무 Logic을 원격지에서 호출하여 원하는 작업을 수행한다. Client는 이렇게 원격지에서 Logic을 호출하는것 이외에 화면을 컨트롤하고 화면관련 작업을 수행하는 Presentation Layer를 담당한다. DBMS는 Data처리 역할을 한다. 3 -Tier방식의 Client/Server 모델은 "Presentation", "Application Logic", "Data"의 3개 계층을 독립적으로 구성하여 아키텍쳐를 구성하므로써 더욱 명확한 계층간의 구분을 제시하였다. Server의 성능과 기능의 발달과 Client소프트웨어 개발 툴등이 발전함에 따라 Database가 단순한 Data서비스 뿐만 아 니라 Stored Procedure라는 형태로 업무 Logic의 일부를 구현하고 Client 개발툴이 발전함에 따라 Client는 Presentation Logic 뿐 아니라 일부 업무 Logic을 담당하기 시작한다. 이러한 발전추세를 반영한 모델이 Multi-Tier Client/Server 아키텍쳐라고 할 수 있다. 이것은 Application Server에 주요 업무 Logic을 두어 서비스 하되, 일부 Logic은 Database에 Stored Procedure형태로 두고 또 일부 Logic은 Client측에 둠으로써 기술적 다양성 및 융통성을 수용하는 모델이다. 7

1. Enterprise Technology 1. 2 분산환경과 분산객체 1. 2. 2 n-Tier Architecture Web Browser는 Client임은 틀림이 없지만 기존의 Client 프로그램하고는 무척 다른 모습을 하고 있다. 기존의 Client 모듈은 나름대로의 Presentation Logic을 가지고 있지만 Web Browser는 단순히 HTML을 Parsing하여 화면에 보여주 는 역할 만을 담당한다. 오히려 화면을 Markup(치장)해주는 Logic은 서버에 있다. 즉 의도한 화면이 나오도록 서버측 의 CGI프로그램이 실행된다. 이러한 Web 아키텍쳐의 등장은 또 다른 n-Tier 아키텍쳐를 요구하게 되었다. 결국 이러한 맥락아래 n-Tier 아키텍쳐를 근간으로 하고 Web 아키텍쳐를 수용한 가운데 소프트웨어 Component 기 술의 표준을 제시한 아키텍쳐가 Enterprise Java. Beans 아키텍쳐이다. 업무 로직을 EJB라는 형태로 만들고 이를 서버상에 설치하여 사용한다. Presentation에 있어서도 JSP/Servlet을 이용 하여 HTML을 구성하는 화면 로직을 만드는데 있어서 역시 3 -Tier의 모습을 가지고 있지만 JSP/Servlet이 서버 상에 서 수행된다는 점과 JSP/Servlet 자체 만으로도 업무로직을 구성할 수 있다는 점에 있어서는 n-Tier 아키텍쳐라 할 수 있다. 또한 Web을 기반으로 한 아키텍쳐이기 때문에 기존의 Client/Server Multi-Tier 아키텍쳐보다 더욱 발전한 형태의 Web 기반 Multi-Tier 아키텍쳐이다. . 8

1. Enterprise Technology 1. 2 분산환경과 분산객체 1. 2. 5 분산환경 일반적으로 Web site를 구축할 때, 대표적인 Resource인 Web Server와 Database Server를 분리하여 물리적으로 다 른 Server에 구축한다. 이렇게 함으로써 사용자의 접속을 관리하는 Web Server와 Data를 관리하는 Database Server 가 서로에게 큰 방해를 입지 않고 높은 효율로 자신의 일을 수행할 수 있게 된다. 이러한 환경에서 만약 Database Server에 문제가 발생해서 Down된다 하더라도 Web Server는 DB관련 서비스를 제외한 Web. Service를 문제없이 수 행할 수 있는 것이다. [Web Server와 Database Server의 3 tier] 그런데 우리가 살펴 볼 EJB는 물리적인 분산 환경이라 하기 보다는 개념적 혹은 논리적인 Programming 관점에서의 분산환경이다. 이 말은 물리적으로 다른 Server들 간의 Programming 보다 같은 Server안에서 분산객체(Distributed Object)들 간의 통신을 통해 System이 수행되는 환경이라는 것이다. . 9

1. Enterprise Technology 1. 2 분산환경과 분산객체 1. 2. 6 분산객체 분산객체(Distributed Object) 기술은 자신의 영역에 속해있지 않는 객체를 마치 자신의 영역에 속해있는 객체인것 처럼 호출해 사용할 수 있는 기술을 말한다. 자바에서는 이처럼 분산객체를 사용할 수 있도록 지원하는 Protocol이 RMI(Remote Method Invocation) 이다. OMG(Object Management Group)의 CORBA(Common Object Request Broker Architecture)나 MS의 DCOM등이 이 와 유사한 protocol이다. EJB는 분산객체 Protocol인 RMI를 근간으로 운영되는 기술이기 때문에 RMI에 대해서 기본 적인 개념은 알고 있어야 한다. [RMI 의 분산 객체 통신 개념] 이러한 분산객체의 장점은 단일 환경보다는 성능이나 유지보수 차원에서 매우 효과적이다. 다시 말해 각각의 객체들이 자신의 역할을 수행하기 위해서 물리적 혹은 논리적으로 별도의 위치에 존재함으로써 각 각의 성능과 유지보수의 용이성이 한층 더 증가되는 것이다. 10

1. Enterprise Technology 1. 3 Component Programming 1. 3. 1 Component란? Componet란 특정한 일을 수행하는 독립적인 객체 혹은 객체들의 묶음이다. 좀 더 쉽게 설명하자면, 어떤 한 프로그 램 내에서 쓰이는 한 기능이 다른 프로그램에서 재사용이 가능하다면 이것은 어느 정도 Component의 성질을 가지고 있는 것이다. 물론 그 같은 Program의 조각이 Component가 되려면 Component가 갖추어야 할 요건을 어느정도 갖추 고 있어야 한다. 다시 말해 한 프로그램에서 Component를 사용하려면 Component를 사용하는데 있어서 필요한 Interface가 정의되어 있어야 하며, 어떤 표준적인 방법도 일정한 규칙을 가지고 있어야 한다. 이처럼 Component가 갖추어야 할 규약(specification)은 엄연히 존재하며, EJB역시 Component이므로 규약을 가지고 있다. Component를 사용하는 대표적인 응용프로그램은 GUI Tool이다. JBuilder같은 GUI Tool은 Button이나 Combo. Box와 같은 각각의 Component를 조립하여 새로운 프로그램을 개발한다. [ 여러가지 GUI Component] Java Applet, Java Beans, Servlet & JSP 도 바로 Component Programming의 기본 단계였다고 할 수 있다. Applet은 Applet을 동작시키는 Container안에서 동작하는 Component인 것이고 Servlet & JSP 또한 Tomcat이나 Resin과 같은 Servlet, JSP엔진과 같은 Container에서 동작하는 Component인 것이다. Applet이 Client쪽의 Web Component를 만드는 기술이고, JSP & Servlet이 Web Server쪽의 Component를 만드는 기 술이라면 J 2 EE는 Enterprise환경의 기본 정의를 내리고 그 환경 안에서 분산객체환경에 맞는 Component를 만드는 기술을 정의한 것이다. 다시 말해 J 2 EE가 바로 그 환경과 API에 대해 정의를 내린 것이고 그 환경에서 만들어지는 Component를 EJB라고 정의 내린 것이다. 11

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

1. Enterprise Technology 1. 4 Enterprise Development 은행 시스템이나 Internet 쇼핑몰과 같은 조금이라도 문제가 발생하면 치명적인 대규모의 System을 개발하는 작업 을 일컬어 Enterprise Development라고 한다. 이같은 Enterprise Development를 수행할 때, 몇 가지 선행되어야 할 요구 조건들이 있다. 1. Client-Server 환경 Web Based Client 환경이든 Application Based Client환경이든지 사방에 흩어져 있는 사용자를 위한 Client가 필요하다. Client가 존재한다면 당연히 Server도 존재해야 한다. 2. 분산 객체 환경 Enterprise Development수행 시에는 System의 성능과 유지보수의 용이함을 극대화 시키기 위해 분산객체환경 을 적용하는 것은 반드시 필요한 일이다. 3. Resource 관리 Resource의 재활용은 매우 중요한 개발 기법중의 하나이다. 예를 들어 Database의 Connection객체를 관리하는 Connection Pool은 Enterprise Web Site의 핵심적인 부분중 하나이다. Resource관리는 Enterprise Web Site의 성능과 직결된 문제이다. 4. Transaction A은행에서 B은행으로 100만원의 자금을 이체한다고 가정하자. A은행에서 100만원 감소와 B은행에서 100만원 증가는 필수적으로 동시에 일어나야 한다. 5. 보안 모든 System에는 공개되어서는 안될 Data들이 존재한다. 6. 확장성 및 이식성 새로이 개발되는 시스템은 기존의 시스템을 수용할 수 있어야 하고, 개발된 시스템은 시스템의 추가및 보완이 용이해야 한다. 13

2. J 2 EE 2. 1 Java 2 Platform Java 2 Platform이란 Sun에서 제시한 기본 Application부터 Enterprise solution, Mobile Solution에 대한 개발 방법론과 다양한 API와 Specification을 정의한 것이다. Java 2 Platform은 다음과 같이 3가지로 나누어서 생각할 수 있다. • • • J 2 SE(Java 2 Platform Standard Edition) J 2 EE(Java 2 Platform Enterprise Edition) J 2 ME(Java 2 Platform Micro Edition) J 2 SE는 Java Program을 하는데 있어서 가장 기본적인 핵심 부분을 의미한다. 우리가 가장 많이 사용하는 JVM의 영 역부터 Compiler, Debug와 같은 부분에 대한 Spec을 제시하고 있다. 또한 기본 Application을 만드는데 있어 가장 중 요한 API를 정의하고 있다. J 2 EE는 Enterprise Solution을 개발하는데 있어 필요한 여러 가지 서비스 부분과 API, 개발 방법론을 제시하는 것이다. J 2 EE에 대해서는 뒷장에 보다 자세히 알아 보도록 하겠다. J 2 ME는 다양한 Mobile Solution을 개발하는데 있어 기본적인 환경, 서비스에 대한 부분을 정의 내리고 있고 이러한 환경을 개발하는데 필요한 다양한 API를 제공하고 있다. *참조: http: //java. sun. com/products/에서 보다 자세한 내용을 볼 수 있다. 14

2. J 2 EE 2. 2 J 2 EE 란 매우 포괄적인 의미를 가지고 있는데, 가장 일반적인 의미는 "Enterprise Development에 필요한 다양한 환경을 정의해 놓은 규약(specification)" 이라고 말할 수 있다. J 2 EE란 무엇인가에 대하여 다음과 같이 분류할 수 있다. • Enterprise 개발 환경의 Platform Specification • Enterprise 개발 환경의 Implementation Specification 규약만 가지고 System이 움직이는 것은 아니다. 예를 들어 자바 Program이 수행되려면 당연히 JVM이 있어야 하는 것처럼, J 2 EE 역시도 J 2 EE의 규약에 맞게 만들어 놓은 API들과 부가적인 Tool들이 있어야 한다. J 2 EE라고 하면 다 른 의미로 이 API들과 Tool들을 일컫는다. 그리고 이와 같은 API와 Tool들을 포함하고 기타 Service들을 탑재한 Server들을 일컬어 J 2 EE Server, Web Application Container, J 2 EE Application Server라고 한다. 실제로 많은 Vendor들이 다양한 J 2 EE Application Server를 제공하고 있지만 이들은 모두 J 2 EE 규약을 따르고 있기 때문에 J 2 EE 규약을 맞춘 Component는 어떤 서버에서도 잘 수행될 수 있다. * 참조: “Java. EETutorial. pdf” http: //www. theserverside. com/tt/articles/article. tss? l=Server. Matrix 15

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. 4 J 2 EE의 구성요소 2. 4. 1 J 2 EE의 3가지 Category [J 2 EE의 3대 Category] 1. Component : Servlet, JSP, EJB Business Logic을 구현하고 Presentation Logic을 담당하는 것들로써 개발자가 주로 개발하는 부분이다. 2. Service : JDBC, JNDI, JTA 이미 존재하는 Service들, 예를 들어 Database나 Naming Service나 Transaction Service와 같은 것들로써, 개 발자가 이용하는 구성 요소들이다. 개발자는 이 구성 요소들을 그냥 사용하기만 하면 된다. 3. Communication : JMS, Java Mail, JAF, RMI-IIOP 객체들 간의 통신에 사용되는 것들이다. 메일이나 메시지를 다루는 System을 개발할 때 주로 사용된다. 18

2. J 2 EE 2. 4 J 2 EE의 구성요소 2. 4. 2 J 2 EE의 구성요소 • Servlet과 JSP (Java Server Page) Presentation Layer에 해당하는 것으로 Client Interface를 담당한다. Sevlet/JSP는 Server쪽 Component이다. • EJB (Enterprise Java. Beans) Enterprise Development를 위한 Server쪽 분산객체 Component이다. J 2 EE내에서 Business Logic을 담당한다. • JDBC (Java Database Connectivity) Database와 연동을 위해 주로 사용된다. Enterprise Develpment에서 반드시 필요한 존재이다. • JNDI(Java Naming and Directory Service) JNDI는 자원을 이름으로써 관리하는 Service이다. • JTA(Java Transation API) 개발자는 JTA를 이용하여 Transaction처리를 쉽게 처리할 수 있다. • JMS(Java Message Service) 상대방이 현재 대화에 응할 수 없는 상황이라 할지라도, 메세지를 보낼 수 있어야 한다. JMS는 이러한 메세지를 받았다가 상대방이 대화에 응할 수 있는 상태가 되면 메세지를 전달해 주는 Service를 제공한다. • Java Mail과 JAF(Java. Beans Activation Framework) Mail Client를 만드는데 이용된다. 또한 JAF는 MIME을 지원하는 기술로 JAVA MAIL에서는 이것을 이용하여 다 양한 형태의 DATA를 보낼 수 있다. • Java IDL과 RMI-ll. OP Java IDL과 RMI-IIOP를 이용하여 Client가 자바로 구현되어 있지 않다고 하더라도 EJB를 호출해 사용할 수 있 다. 19

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. 1 전개 방법 J 2 EE Application을 전개하는 방법은 그림과 같이 크게 3부분으로 나눌 수 있다. [J 2 EE Application의 구성] • Creat 개발자들이 EJB 스펙에 맞추어 각각의 Component를 개발한다. • Assembly 개발자에 의해 만들어진 Component를 업무 Flow에 맞게 조합한다. • Deployment 조합된 Component들을 EJB Server에 전개시킨다. 전개시에 Component의 성격을 Deployer가 수정할 수도 있다. 이러한 특성 때문에 보다 Flexible한 Enterprise Component를 만들 수 있는 것이다. 22

2. J 2 EE 2. 7 J 2 EE Application의 전개 2. 7. 2 개발 단계별 Role EJB를 이용한 J 2 EE Application개발은 Enterprise급 System에 적용되는 개발 방식이므로 일반 System개발 보 다는 좀 더 복잡하다. 따라서 개발 단계별로 Role이 정해져 있다. [EJB Roles] 23

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. 1 EJB의 정의 Enterprise Java. Beans란 다음과 같은 특성을 지닌 하나의 방법론이다. • • • Enterprise환경에서의 Component 개발 방법론 다양한 EJB Server에서 동작되어지는 Component 개발 방법론 전개시에 EJB Component의 특성을 수정할 수 있게 개발하는 방법론 Enterprise Java. Beans는 Enterprise환경에서 요구되어지는 다양한 Service에 맞게 개발되어지는 Component 개 발 방법론이다. 즉 Enterprise환경에 대한 Service나 API는 J 2 EE에서 정의 내리고 있고 이러한 환경에서 Component 를 개발하는 방법론이 바로 EJB인 것이다. Enterprise Java. Beans 개발방법론으로 만든 Component를 우리는 Enterprise Beans(EB)라고 한다. 현재 다양한 Application Server도 Sun에서 제시한 J 2 EE 스펙을 따르고 있기 때문에 그 안에는 EJB를 동작시키기 위 한 Container가 존재한다. 따라서 EJB Component는 System이나 OS에 관계없이 다양한 Application Server에서 동작 이 가능하다. EJB는 EJB Server에 전개할 때 Component의 특성을 부여하기 때문에 Component를 다양하게 활용할 수 있다. 25

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. 1 EJB Application의 구성 하나의 EJB class를 만드는 것이 아니라, 앞장과 같이 EJB Component를 만드는데 있어서의 기본적인 규칙을 이용 하여 만들어지게 된다. 이러한 규칙들은 하나의 Component가 다양한 EJB Server에서 동작될 수 있는 기본적인 요소가 되는 것이다. EJB의 구성과 전개는 다음 그림과 같다. [EJB의 전개] 29

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. 3 EJB Application의 구성 3. 3. 5 Deployment Descriptor Deployment Descriptor는 우리가 흔히 DD라고 부르기도 한다. 이것은 EJB보다 Portable하게 사용하게 하기위해 XML 로 만들어진 문서이다. EJB를 EJB Server에 전개 시키기 직전에 이 DD에 의해 EJB의 성격이 만들어지고 또한 전개 전에는 여러 형태로 수 정이 가능하다. DD를 만드는 방법은 개발자가 직접 XML문서로 만들 수도 있고 EJB Server에서 제공하는 Deploytool을 이용하여 DD 를 만들어 사용한다. 하나의 DD안에는 하나 이상의 EJB 정보가 들어갈 수 없다. DD안에는 다음과 같은 정보가 들어간다. • EJB의 구조적인 정보 Home Interface Information Remote Interface Information Enterprise Bean Class Information • Runtime시에 참조되어지는 정보 Transaction Control 다른 Bean에 대한 참조 정보 Database에 접근에 대한 정보 Security 정보 • 이렇게 Deployment Descriptor를 이용함으로써 EJB가 Component로서 Bean을 개발할 때 Bean의 특별한 성격을 부 여하는 것이 아니라 EJB를 전개하는 시점에서 다양한 형태의 특징을 EJB에 부여할 수 있는 것이다. 33

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. 1 Session Bean [Session. Bean Interface Souce. Code] Session Bean은 Business Logic에서 회원을 등록한다거나, 상품을 쇼핑카트에 담는다거나 하는 Process를 수행하는 역할을 한다. Session Bean에는 두가지 종류가 있다. • Stateful Session Bean 사용자마다 하나씩 존재해야 하는 경우 Stateful Session Bean으로 구현한다. 대표적인 예로 쇼핑카트를 들 수 있다. • Stateless Session Bean 모든 사람이 공유하는 것으로 state를 유지할 필요가 없을 경우 Stateless Session Bean 으로 구현이 가능하다. 35

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. 4 Enterprise Bean의 구분 3. 4. 3 Message Driven Bean(MDB) [Message. Driven. Bean Interface Source. Code] Message Driven Bean은 JMS의 Message. Listener객체로 EJB spec 2. 0 에서 추가된 EJB중에 하나이다. JMS 메시 지가 도착하면 컨테이너에 의해 호출되어진다. Java Messaging Service(JMS)는 많은 다른 메시징 미들웨어 서버에 접근하기 위해 사용되어질 수 있는 Java API로 1998에 처음 발표되었고 현재 JMS Spec Version 1. 1를 제공하고 있다. JMS 프로그래밍을 하기위해서는 메시징 미들웨어 서버가 있어야 한다. J 2 EE 1. 4 Software Development Kit 은 메시 징 서비스를 지원한다. 그리고 JMS 어플리케이션에서 사용되어지는 Administered Object인 Destination 과 Connection Factory는 j 2 eeadmin. bat 파일을 이용해 관리할 수 있다. 37

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. 1 JNDI 분산시스템을 개발한다는 것은 물리적 혹은 논리적으로 분산되어 있는 Component들을 이용해 시스템을 구현한다는 의미이다. 이 말은 분산되어 있는 Component들을 찾는데 실패한다면 시스템 역시 수행에 실패한다는 의미가 된다. 따라서 분산되어 있는 Component들을 찾기 위해서 제공되는 Service가 Naming Service와 Directory Service이다. • Naming Service Component를 이름으로 찾아주는 Service를 의미한다. 대표적인 예로 DNS(Domain Naming Service)가 있다. DNS는 http: //java. sun. com와 같은 URL을 실제 IP Address로 바꾸어 주는 역할을 한다. RMI의 rmiregistry와 CORBA의 cosnaming등이 Naming Service의 일종이다. • Directory Service Naming Service의 확장판으로 Tree형태의 계층적인 정보를 Service한다. 대표적인 예로 LDAP(Lightweight Directory Access Protocol)이 있다. Naming/Directory Service에는 위에 언급한것 이외에도 여러 종류의 것들이 있다. 이러한 것들은 자신들만의 API와 사용법을 가지고 있으므로 개발자에게 어려움이 아닐 수 없다. 따라서 이러한 문제를 해결하기 위해 JNDI(Java Naming and Directory Interface)가 생겼다. JNDI는 JDBC와 마찬가지로 interface만 정의할 뿐이며, Vendor들의 JNDI SPI(Service Provider Interface)라는 것이 존재한다. 따라서 개발자들은 JNDI API만 익히면 된다. 40

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

4. EJB Client & EJB Sample Program 4. 3 EJB Sample Program EJB Program의 작성순서는 다음과 같다. 1. Beans를 구성하는 코드를 작성 및 컴파일한다. 2. Deploytool을 이용하여 Application을 생성하고 Enterprise Bean을 생성한다. 3. Deploytool을 이용하여 여러가지 설정을 마친후 Deploy한다. 4. Client코드를 작성한다. 5. Deploy시에 얻어진 XXXClient. jar파일을 classpath로 포함하고 Client코드를 컴파일 한다. 6. XXXClient. jar파일을 classpath로 하여 Client클래스파일을 실행한다. 위의 작성순서에 따라 간단한 EJB Program을 작성하고 EJB Application Server에 Deploy시킨 후 Client 프로그램을 통해 Deploy된 EJB를 이용해보자. *참조: 実習順序. txt 42

5. Session Bean 5. 1 Session Bean이란? Enterprise Bean은 Session Bean, Entity Bean, Message-Driven Bean등으로 이루어져 있다. 이번 장에서는 Session Bean에 대해서 알아본다. Entity Bean이 영속적으로 저장된 Business Entity를 표현한다면, Session Bean은 Business Process를 수행하는 역할 을 담당하며, Client의 역할을 확장하는 개념을 갖는다. Session Bean은 Client에서 요청한 작업을 수행함으로써, 복잡한 Business Logic을 Client로부터 분리할 수 있게 하며, Client가 종료되면 Client가 사용하던 Session Bean은 더이상 Client와의 관계가 유지되지 않기 때문에 영속 적일 수 없다. 예컨데 Session Bean은 일반적인 Java Class의 Method의 역할을 하는 것으로 이해하는 것이 가장 쉬울 것이다. Session Bean은 다음과 같은 경우에 사용되어 질 것이다. • • 항상, 오직 하나의 Client만 Bean Instance에 접근하는 경우 아주 짧은 시간동안만 존재하며, Bean의 상태가 영속적일 필요가 없는 경우 Session Bean은 Client가 전달한 상태를 고유하게 유지하는지 여부에 따라 Stateless Session Bean과 Stateful Session Bean으로 나뉘어 진다. 43

5. Session Bean 5. 2 Stateless Session Bean 5. 2. 1 Stateless Session Bean이란? Stateless Session Bean은 Client가 요청하는 Business Logic을 단순히 수행하는 것으로, 수행이 끝난 후에는 Client 가 전달한 어떠한 상태값도 유지하지 않는다. 이것은 EJB Container가 모든 Stateless Session Bean을 요청한 Client에게 독점하게 할당하지 않기 때문이고, 여러 Client가 Stateless Session Bean을 공유하여 사용하기 때문에 Client는 자신의 상태유지를 보증 받을 수 없다. 따라서 Stateless Session Bean은 여러 Client들에게 공유될 수 있기 때문에 요구되는 Instance의 수가 비교적 적어 대 규모의 Client 접속을 요구하는 Application에 대해서 상대적으로 높은 성능을 갖는다. Stateless Session Bean은 다음과 같은 경우에 사용되어 질것이다. • • • Bean이 특정 Client만을 위해 사용되지 않을 경우 Method를 호출하는 사이에 Client의 정보를 유지할 필요가 없는 경우 모든 Client에게 공통적(고유하지 않게)으로 사용되는 Code의 수행이 필요한 경우 44

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. 2 Stateless Session Bean 5. 2. 3 Stateless Session Bean의 동작원리 Stateless Session Bean은 Client의 정보를 유지할 필요가 없기 때문에 각각의 Client별로 Instance를 생성할 필요가 없다. Stateless Session Bean의 동작을 순서는 다음과 같다. 1. Client에 의한 Bean 요청 Client가 Home Interface를 통해 Bean을 요청하면, Bean이 존재하지 않을 시에는 새로운 Instance를 생성하고, set. Session. Context()와 ejb. Create() method를 호출한 후에 client가 요청한 Business Method를 호출하여 응답하게 된 다. 2. Client의 method 호출 종료 Bean은 Pool로 이동하게 되고 다른 Client의 요청을 기다린다. 3. Client에 의한 Bean 요청 Pool에 대기하고 있던 Instance가 새로운 Client의 method 호출 요청에 응답한다. Stateless Session Bean은 상태를 유지하지 않고, 여러 Client에게 공유되어 사용되기 때문에 후에 설명될 비활성화 메커니즘이 필요치 않고 따라서 Life Cycle이 상대적으로 간단하다. 아래 그림은 Stateless Session Bean의 Life Cycle을 표현하고 있다. 47

5. Session Bean 5. 2 Stateless Session Bean 5. 2. 3 Stateless Session Bean의 동작원리 다음은 Stateless Session Bean의 특징을 보여주는 예이다. 첫번째 "rainer"를 이름으로 할당한 Instance에 대한 3번째 say. Hello()는 두번째 set. Name("jesica")에 의해 할당된 "jesica"를 반환하고 있다. 이것은 Stateless Session Bean이 Client 각각에게 고유의 Instance를 할당하지 않고 공유하고 있음을 보여준다. 결국, 각 Client는 자신이 전달한 상태의 유지를 보증 받을 수 없는 것이다. 48

5. Session Bean 5. 3 Stateful Session Bean 5. 3. 1 Stateful Session Bean이란? Stateful Session Bean은 Stateless Session Bean과 달리 요청한 Client와의 세션상태가 진행되는 동안 상태의 유지 를 보증한다. 하지만 상태의 유지는 영속적이지 않고 Client가 Bean을 제거하면 세션은 종료되고 상태도 사라지게 된 다. Stateful Session Bean은 하나의 Client에 오직 하나의 Instance가 할당되며, Client의 대리인 역할을 한다. Stateful Session Bean은 "활성화(activation)/비활성화(passivation)"라는 자원관리 기법을 사용한다. 만약 Client 가 Stateful Session Bean을 오랫동안 사용하지 않으면, 이 Session Bean의 Memory및 Resource를 해제하고 2차 저 장소에 저장한다. 이러한 "비활성화"된 Stateful Session Bean은 Client가 다시 사용하려고 할 때 저장소에서 메모리로 로딩되어지며, 이것을 "활성화"라고 한다. Stateful Session Bean은 Client마다 하나씩 할당되며, Client의 각종 상태 정보를 유지해야 하기 때문에 Application 성 능에 있어 Stateless Session Bean보다 오버헤드가 크다. 따라서 경우에 따른 적절한 사용이 필요하다. Stateful Session Bean은 다음과 같은 경우에 사용되어 질것이다. • • • Bean의 상태 초기화가 Bean의 생성시에 필요한 경우 Method의 호출사이에 Client의 정보를 유지할 필요가 있는 경우 Client가 Application과 상호적으로 동작하는 경우 49

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은 Client의 정보를 유지해야 하기 때문에 Client간에 공유되어 지지 않고, 각 Client는 자신만의 고유의 Session Bean을 갖게 된다. Stateful Session Bean의 할당 과정은 다음과 같다. 1. Client가 Home Interface의 create() method를 호출함으로써 Stateful Session Bean이 생성된다 2. Container는 create()메소드가 호출되면, Bean Instance를 생성하고 set. Session. Context()와 ejb. Create() method를 호출한다. 3. EJB Object의 Remote Reference를 Client에게 반환하며, Method 준비상태가 되어 활성화 상태가 된다. Stateful Session Bean은 특정 Client에게 독점적으로 할당되기 때문에 Client가 Business Method를 호출하면, Stateless Session Bean과 같이 Pool로 부터 존재하고 있는 Bean Instance를 가져오거나 반환하지 않는다. 만약 Bean Instance가 비활성화 상태에 있다면 Container에 의해 활성화가 된 후 Method호출에 응답하게 된다. Stateful Session Bean은 각각의 Client별로 새로운 Instance가 생성되기 때문에 Client의 수가 증가함에 따라 시스템 의 성능에 미치는 영향이 크다. 따라서 EJB Container는 LRU(Least Recently Used)알고리즘에 따라 장시간 요청이 없는 Client의 Stateful Session Bean을 2차 저장소에 저장하게 된다. 이와같은 상태를 비활성화(Passivate)상태라 하고, 2차 저장소에 저장된 Instance에게 Client의 요청이 들어오면 EJBContainer는 Bean Instance를 다시 메모리에 Load하여 요청을 수행하게 하고, 이와 같은 상태를 활성화(Activate) 상태라 한다. 52

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이란? [Entity Bean의 이해] 그림에서 보듯이 Entity Bean이라는 것은 Data의 EJB식 표현이다. EJB Container는 이와같이 Database에 저장되어 있는 Data를 Entity Bean형태로 관리하는 것이다. 따라서 Entity Bean은 Session Bean과 달리 데이터를 관리하는 Logic 이외에 Business Logic은 포함하지 않고, 여러 클라이언트가 하나의 Bean를 공유할 수 있으며, 지속성 (Persistence)을 가진다. 54

6. Entity Bean 6. 1 Entity Bean이란? Entity Bean은 Database에 있는 Table의 한 Row나 혹은 여러 Table에 걸쳐 있는 Data를 표현한다. 그리고 Entity Bean은 그 Row와 연결되어 있어 Entity Bean의 정보를 변경하면 동시에 Table의 Row도 변경된다. 따라서 Entity Bean은 필수적으로 Transaction문제를 가진다. Entity Bean은 Session Bean과는 달리 Primary Key 객체를 가진다. Client는 이 Primary Key 객체를 이용하여 원하 는 Entity Bean을 찾아낼 수 있다. Entity Bean의 Persistence(지속성)을 어떻게 관리할 것이냐에 따라 다음과 같은 2가지 방식으로 Entity Bean을 나눌 수 있다. 1. Bean Managed Persistence(BMP) Entity Bean의 Persistence를 개발자가 직접 관리한다. 즉, Entity Bean의 상태를 Database에 반영하기 위해 직접 JDBC와 SQL Code를 Entity Bean 안에 작성한다. 2. Container Managed Persistence(CMP) Entity Bean의 상태를 Database에 반영하는 관련 Code들을 Container가 생성한다. 개발자는 별도의 SQL Code를 작성할 필요가 없고, DBMS에 독립적이다. 이러한 Bean의 배치설명자에는 연동할 Member Variable과 SQL을 명시해야 하고, Member Variable은 public 으로 선언되어야 하며, transient로 선언되어서는 안된다. 55

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. 4 Entity. Bean의 구성 6. 4. 3 Entity Bean Class Entity Bean class에서 구현되는 Method • ejb. Remove() client가 Entity Bean의 삭제를 요청하면 EJB Container는 해당 Entity Bean 객체를 제거하기 전에 ejb. Remove() 메소드를 호출한다. 개발자는 Cleanup Task가 필요하다면 이 Method안에 구현해 준다. • ejb. Find. XXX() BMP를 사용한다면 Entity Bean을 찾기 위해 개발자는 SQL Code를 이 Method안에 기술해야 한다. CMP를 사용한다면 EJB Container가 자동으로 만들어 주므로 개발자는 EJB QL(Enterprise Java. Beans Query Language)만 작성하면 된다. ejb. Find. XXX() 구현시 주의사항 - ejb. Find. By. Primary. Key()메소드를 가져야 한다. - ejb. Find접두사로 시작해야 한다. - public으로 선언되어야 한다. - final이나 static으로 선언할 수 없다. - Argument와 Return Type은 RMI/IIOP Type이어야 한다. - Return Type은 Primary Key Type이거나 Collection Type이다. • ejb. Home. XXX() Home Interface에서 선언된 Home Method의 내용을 정의한 Method이다. Client에서 XXX()메소드를 호출하면 자동으로 Entity Bean 객체의 ejb. Home. XXX()가 호출된다. EJB Container는 Pool에 저장되어 있는 Entity Bean 객체를 Ready상태로 변화시켜 사용하며, 사용이 다 끝나면 다시 Pool에 객체를 저장한다. Home Method는 Entity Bean과 연관없는 작업을 수행해야 하기 때문에 ejb. Home. XXX()안에서 Entity Bean 객체 의 상태를 바꾸거나 다른 Entity Bean객체와의 관계를 변형시켜서는 안된다. 66

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란? JMS(Java Message System)는 비동기적 의미를 내포하고 있는 UDP 통신개념의 Mail. System과 유사하지만 Component간 통신이라는 점에서 다르다. JMS는 다른 말로 MOM(Message Oriented Middleware)라고 부르고 많은 Vendor들이 MOM제품을 출시하고 있다. IBM의 MQSeries, Progress의 Sonic. MQ, MS의 MSMQ등이 그것들 중 하나이다. 물론 Sun의 J 2 EE Application Server 에도 MOM은 탑재되어 있다. JMS의 비동기적 메세지 전송은 아래 그림과 같이 MOM이 중간에서 Message를 받아두었다가 Receiver가 접속을 하 면 Message를 전달해 주는 방식으로 이루어진다. Message System에는 크게 2가지 방식이 있다. 첫번째 것은 PTP(Peer-To-Peer)방식이고 또 다른 하나는 Pub/Sub (Publisher-Subscriber)방식이다 [Message System의 architecture] 68

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. 1 JMS란? 7. 1. 2 Pub/Sub (Publisher-Subscriber). [Sub/Pub Message System Architecture ] Pub/Sub 방식은 Message를 받고 싶어하는 Subscriber들은 원하는 Topic에 등록한다. 그림처럼 Publisher는 MOM 이 가지고 있는 해당 Topic에 Message를 보내며, MOM은 Topic에 등록되어 있는 Subscriber들에게 Message를 전달 하는 구조이다. 이와같은 두 방식은 모두 MOM을 필요로 하고 MOM제품은 다양하게 존재한다. 그렇기 때문에 서로 다른 API를 사용 하여 개발된 System의 호환성에 문제가 발생할 수 있다. 이러한 것을 해결하기 위하여 Sun에서는 JDBC처럼 Interface들로 구성된 JMS(Java Message System)을 개발하였다. 따라서 MOM Vendor들은 JMS를 지원하는 JMS Driver를 제공해야 한다. 70

7. Message Driven Bean 7. 2 JMS의 구성요소 7. 2. 1 Administrated Object 이미 언급했지만, 많은 Vendor들이 MOM제품을 출시하고 있다. 따라서 MOM제품의 운영을 담당하는 핵심 요소는 제품마다 다를 수 있다. 그러므로 이같은 핵심부분을 운영하는 방법을 여러 가지 형태로 제공할 수 있다. (Sun의 J 2 EE SDK의 J 2 EE Application Server는 Console명령어로 제공한다. ) 이처럼 MOM제품의 운영을 담당하는 핵심요소를 가 리켜 Administrated Object라고 한다. 예를 들어 Sun의 J 2 EE SDK의 MOM에 있는 Connection. Factory와 Destination객체가 대표적인 Administrated Object인데, 이들을 운영하기 위해서는 Sun의 J 2 EE SDK가 제공하는 j 2 eeadmin이라는 명령어를 사용해야 한다. 역시 이같은 객체들도 JNDI Name을 이용하여 등록하고 찾는다. 71

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. Message Driven Bean 7. 3. 4 Message 우선순위 중요한 Message나 급한 Message를 먼저 처리할 수 있도록 우선순위를 지정할 수 있다. 우 선 순위는 0~9까지로 10단계로 되어 있으며, 0이 가장 낮은 우선순위이고, 9가 가장 높 은 우선 순위이다. 4순위가 기본 순위이다. 우선순위를 지정하는 방법에는 2가지가 있다. send()와 publish()에 우선순위를 기술한다. Message. Producer 객체의 set. Priority()를 이용한다. 82

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. 1 Transation의 이해 Transaction이라는 용어의 의미는 일반적으로 Database에 가해지는 일련의 작업을 의미한다. 다시말해, Transaction이란 Database의 Data의 일관성 정확성을 유지하기 위해 여러 Table에 가해지는 작업을 8. 1. 1 Transaction의 특성 앞에서 설명한것처럼 Data가 정확하고 일관성 있게 유지되려면 ACID(Atomicity, Consistency, Isolation, Durability) 라는 특성이 지켜져야 한다. • Atomicity System의 어떤 상황하에서도 한 Transaction의 작업들이 모두 완료되거나 아니면 전혀 실행되지 않아 다. 즉, 한 Transation에 대한 모든 질의들의 결과가 Database에 모두 반영되든가 아니면 전혀 반영되지 않 함을 의미한다. • Consistency 어떤 Transaction이 일어난다고 하더라도 여러 사용자의 동일한 질의에 대하여 모순되지 않는 똑같은 결 를 제공할 수 있는 Database를 유지해야 한다. • Isolation Transaction이 완료되기 전에는 그 실행 결과를 다른 Transaction이 이용할 수 없게 하는 것이다. • Durability Transaction이 일단 완료되면 이후에 System에 어떤 형태의 고장이 발생하더라도 그 Transaction의 결 는 계속 유지되어야 한다. 85

8. 1 Transation의 이해 8. 1. 2 Transaction의 Isolation Level Transaction과 관련해서 또 알아두어야 할 개념이 Transaction Isolation Level이다. Transaction Isolation Level에는 다음과 같은 4가지가 있다. Read Un. Committed Commit이 되지 않은 읽기이다. Update되어지고 아직 Commit되지 않은 데이터를 사용자가 Select하여 읽을 수 있 다. 이같은 접근을 Dirty Read라 한다. Read Committed Commit된 읽기이다. Data가 수정 중이라면 Lock으로 인해 다른 사용자는 Data에 접근할 수 없다. Commit이나 Rollback으로 Transaction이 종료되면 다른 사용자의 접근이 가능하다. Repeatable Read 반복읽기로써 Transaction이 종료할 때까지 Shared Lock을 유지한다. 즉, 다른 사용자는 Data를 검색하거나 추가만 할 수 있고, 수정은 불가능하다. 가장 일반적인 방식이다. Serializable 순차가능이라고 하며 Repeatable Read의 제약에 Data의 추가까지 불가능하게 한다. 86

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

9. 1 EJB Security EJB는 여러 Client들에 의해서 사용되는 객체이다. 그러므로 사용자에 따라서 보안을 설정해야 할 필요가 발생한다. 예를 들어 특정 EJB나 그 EJB가 가지고 있는 Method는 특정 사용자들만이 사용할 수 있도록 하는 것이다. EJB Layer에서 의 보안을 의미하는 것이다. Web Page에서 사용자의 id와 password로 Login을 했다고 하더라도 EJB Layer에서 다시 한번 보안을 적용하는 것이다. 그러나 Web Layer에서만 보안을 적용하는 것이 일반적이다. EJB에 보안을 적용하는 방법은 2가지가 있다. Programmatic Security : 프로그램 내에 보안관련 Code를 두어 보안을 적용하는 방법이다. 유연성이 떨어지기 때문에 선호되지 않는다. Deploy Descriptor : Deploy Descriptor에 보안 관련사항을 기록하는 방법이다. Descriptor에 의해 설정되기 때문에 매우 유연성이 좋고 따라서 바람직한 방법이다. 93

9. 2 Authentication & Realm EJB에 보안을 적용하기 전에 알아두어야 할 사항이 있다. 그것은 인증(Authentication)과 권한부여(Authorization)이다. 인증(Authentication) 특정 System에 자신의 id와 password를 입력해 Login하는 과정과 같은 자신을 밝히는 행위이다. J 2 EE Application Server역시 사용자의 인증을 거쳐 특정 Component에 접근을 제어할 수 있다. 영역(Realm) 동일한 인증 정책에 영향을 받는 사용자들의 그룹이다. J 2 EE Application Server에는 두가지 영역이 존재한다. 증명영역(Certificate Realm) 주로 Web Browser를 이용한 Client에 적용된다. HTTPS protocol을 사용하며 사용자의 id확인을 위해서는 X 509를 사용한다. 3가지 type이 존재한다. basic : Server가 Web Browser에게 사용자 id와 password를 묻는 창을 보여준다. form : 94 HTML의 Form Tag를 이용해서 사용자 id와 password를 입력하게 하는 방법이다.

9. 3 Authentication & Role 권한 부여 인증된 사용자라고 해도 접근할 수 있는 EJB는 사용자마다 다를 수 있다. 즉, 사용자마다 다른 권한을 가질 수 있다는 것이다. 이처럼 사용자마다 다른 권한을 부여하는 행위를 권한부여(Authorization)라고 한다. 　　　　　[사용자, 그룹, role의 관계] 권한부여 절차는 다음과 같다. 1. Role을 만든다. 2. Method에 권한을 부여한다. 3. Role을 사용자 및 그룹과 연관시킨다. 4. Role이라는 것은 그룹과 다르다. Role은 특정 EJB를 접근할 수 있는 사용자들의 범주이다. 95

Скачать презентацию Enterprise Java Beans 2008 5 28 Style System

c976098a39a647eb8f6b77bc0532240b.ppt

Количество слайдов: 95