달력

32024  이전 다음

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
crit.clear();
crit.add(MiddlePeer.BIG_ID,MformData.getBigId());
System.out.println(MiddlePeer.createQueryString(crit));<--SQL문 출력하기
MiddlePeer.doDelete(crit);
Posted by tornado
|
 

■Torque사용을 위한 기초작업들

http://jakarta.apache.org/builds/jakarta-turbine/torque/release/3.1/에서

torque-3.1.zip  <==실행

Torque.properties의 편집

클래스 패스는 lib안의 필요한 것(어떤 것? )에 통한다

클라이언트의 코딩과 실행

torque-gen-3.1.zip  <==생성

build.properties의 편집

JDBC 드라이버는 lib에 카피

Ant 태스크를 실행


torque-3.1.zip에 있는 lib폴더 내부의 jar파일들을 사용하는 웹폴더(즉,C:\Tomcat 5.0\webapps-test)의 C:\Tomcat 5.0\webapps-test\ROOT\WEB-INF\lib 에 저장한다. lib폴더엔 스트럿의 jar파일과 중복되는 부분이 있어 torque의 lib폴더의 jar파일의 일부만 가져와서 덮어쓴다. 그 내용은 다음과같다

avalon-framework-4.1.4.jar

commons-configuration-1.0-dev-3.20030607.194155.jar

commons-dbcp-20030825.184428.jar

commons-pool-20030825.183949.jar

jcs-20030822.182132.jar

jdbc-2.0.jar

jndi-1.2.1.jar

junit-3.8.1.jar

log4j-1.2.8.jar

logkit-1.0.1.jar

stratum-1.0-b3.jar

torque-3.1.jar

village-2.0-dev-20030825.jar

xercesImpl-2.0.2.jar

xmlParserAPIs-2.0.2.jar


C:\javatool\torque-3.1에 있는 설정파일들을 사용하는 웹폴더(C:\Tomcat 5.0\webapps-test\ROOT\WEB-INF)의 WEB-INF에 복사한다.


web.xml 에 Torque를 설정해준다.

<servlet>

      <servlet-name>initTorque</servlet-name>

<!--torque를 사용할 때 매번 초기화 하는부분을 이 설정파일(web.xml)에서 설정해준다.-->

      <servlet-class>initialize.TorqueInit</servlet-class>

      <init-param>

      <param-name>config</param-name>

<!--torque를 사용할 때 참조할 properties파일 위치 설정-->

      <param-value>/WEB-INF/classes/properties/Torque.properties</param-value>

      </init-param>

      <init-param>

         <param-name>debug</param-name>

         <param-value>0</param-value>

      </init-param>

      <load-on-startup>1</load-on-startup>

    </servlet>


 ========================================================

<!--torque를 사용할 때 매번 초기화 하는부분을 이 설정파일(web.xml)에서 설정해준다.-->

      <servlet-class>initialize.TorqueInit</servlet-class>  파일이름 : TorqueInit.java(임의로 작성)

package initialize;


/**

* @author  : Kwoen BongJe(2002-12-21)

*/


import javax.servlet.ServletException;

import javax.servlet.http.HttpServlet;


import org.apache.torque.Torque;


public class TorqueInit extends HttpServlet{

    private static boolean hasInitialized = false;


        public void init() throws ServletException{

                

                synchronized(TorqueInit.class){

                        

                        if(!hasInitialized){

                                try{

                                        String propFileName = getServletConfig().getInitParameter("config");

                                if(propFileName==null) {

                                   propFileName="/WEB-INF/classes/properties/Torque.properties";

                                }

                                String propFile = getServletContext().getRealPath(propFileName);

                                        Torque.init(propFile);

                                        hasInitialized = true;

                                }catch(Exception e){

                                        throw new ServletException("\nComstar.framework : Can't initialize Torque!\n"+e);

                                }

                        }

                }

                

        }

}

 

===================================================

<!--torque를 사용할 때 참조할 properties파일 위치 설정-->

      <param-value>/WEB-INF/classes/properties/Torque.properties</param-value> 프로퍼티 파일을 사용환경에 맞게 변경해주어야 한다. 아래는 예제파일


 

torque.applicationRoot = /usr/local/tomcat

log4j.category.org.apache.torque = ALL, org.apache.torque

log4j.appender.org.apache.torque = org.apache.log4j.FileAppender

log4j.appender.org.apache.torque.file = ${torque.applicationRoot}/logs/testdb/torque.log

log4j.appender.org.apache.torque.layout = org.apache.log4j.PatternLayout

log4j.appender.org.apache.torque.layout.conversionPattern = %d [%t] %-5p %c - %m%n

log4j.appender.org.apache.torque.append = false


torque.defaults.pool.logInterval = 0

torque.defaults.pool.connectionWaitTimeout = 10

torque.defaults.pool.defaultMaxConnections = 80

torque.defaults.pool.maxExpiryTime = 3600


torque.defaults.connection.driver = org.gjt.mm.mysql.Driver

torque.defaults.connection.url = jdbc:mysql://localhost:3306/testdb?useUnicode=true&characterEncoding=euc-kr

torque.defaults.connection.user = test

torque.defaults.connection.password = test


torque.database.default=testdb

torque.database.testdb.adapter=mysql


torque.dsfactory.testdb.factory=org.apache.torque.dsfactory.SharedPoolDataSourceFactory

torque.dsfactory.testdb.pool.defaultMaxActive=10

torque.dsfactory.testdb.pool.testOnBorrow=true

torque.dsfactory.testdb.pool.validationQuery=SELECT 1

torque.dsfactory.testdb.connection.driver = org.gjt.mm.mysql.Driver

torque.dsfactory.testdb.connection.url = jdbc:mysql://localhost:3306/testdb?useUnicode=true&characterEncoding=euc-kr

torque.dsfactory.testdb.connection.user = test

torque.dsfactory.testdb.connection.password = test


torque.idbroker.cleverquantity=true

torque.manager.useCache = true


======

 

설치한 torque-gen폴더 아래에 C:\javatool\torque-gen-3.1 torque가 사용될 폴더를 만들어준다 폴더이름은 임으로 만들지만 프로젝트 명으로 하는 것이 좋겠다.


C:\javatool\torque-gen-3.1\webapps-address 아래에 schema 폴더를 만든다.


schema 폴더에 사용할 DB에서의 사용할 태이블 구조를 xml형식으로 만든다

이때 파일 이름의 형식은 “*-schema.xml”의 형식을 따라야 한다. 이는 C:\javatool\torque-gen-3.1에 있는build-torque.xml파일을 torque가 참조한다. build-torque.xml파일에는 DB를 생성과 참조 등등이 정의 되어있다.

참고자료 : http://db.apache.org/torque-31/generator/schema-reference.html

<예>

<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?>

<!DOCTYPE database SYSTEM "http://db.apache.org/torque/dtd/database_3_1.dtd">


<!-- ==================================================================== -->

<!--                                                                      -->

<!-- I D  B R O K E R  S C H E M A                                        -->

<!--                                                                      -->

<!-- ==================================================================== -->

<!-- This is the XML schema use by Torque to generate the SQL for         -->

<!-- ID_TABLE table used by the id broker mechanism in Torque.            -->

<!-- ==================================================================== -->

<!-- @author: <a href="mailto:jvanzyl@apache.org">Jason van Zyl</a>       -->

<!-- @version $Id: id-table-schema.xml,v 1.2 2003/07/24 12:40:41 mpoeschl Exp $ -->

<!-- ==================================================================== -->


<database name="struts-address">

Posted by tornado
|

6.x --> weblogic.ant.taskdefs.ejb.DDInit
7.x, 8.x
EJB --> weblogic.marathon.ddInit.EJBInit
WEB --> weblogic.marathon.ddInit.WEBInit

 

아직 안해봤음.. ㅋㅋ

 

나도 ejb 결부해서 플젝 하고퍼~

Posted by tornado
|

 J2EE의 개론과 EJB개념, 구현시의 디자인패턴적용등에 대해 실사례를 들어

쉽게 풀어낸 자료입니다.

 

 

 J2EE 플랫폼이 제공하는 여러 제품, 표준 등을 살펴보고 그 곳에서 제시되는 아키텍처를 활용하는 것은 선택이 아닌 필수적 상황으로 점차 변하고 있습니다. EJB를 설명하기 전에 EJB를 포괄하는 전체적인 틀로서의 J2EE를 소개하고 있고,디자인 패턴의 중요성을 설명하고 있습니다.

 

 사실, 디자인 패턴이 또 다른 앤티패턴(Anti-pattern)이 될 수도 있습니다.

즉, XP(eXtreme Programming) 진영에서 지적하는 것처럼, 디자인 패턴이 최적화된 시스템을 만들기 보다는 막연한 확장 가능성을 위해 많은 시간을 투입하고, 소프트웨어의 복잡도만을 증가시키는 최악의 상황을 연출해 내는 걸림돌이 될 수도 있습니다.

그럼에도 불구하고 디자인 패턴의 중요성을 강조하는 것은, 단점이 있다 해도 나름대로 많은 장점을 갖고 있기 때문입니다. 이미 많은 숙련된 개발자들은, 다른 사람들과의 커뮤니케이션에 있어 패턴의 사용은 우월감의 표현이라기 보다는, 빠른 시간 내에 정확한 의사 전달을 하기 위한 수단으로 활용하고 있습니다. 즉, 방법론 내부의 객체/컴포넌트 모델링 단계에서 디자인 패턴의 표현은 소프트웨어 아키텍처의 보다 구체적인 이해와 명확한 커뮤니케이션을 위해 필수적인 요소가 되어가고 있습니다.

 

 신규개발자 또는 기존개발자라도 개념을 정리하기 위한 문서로 적당한 수준으로 생각됩니다.

 

<글의 목차>

 

       1. J2EE

1.1 시스템 아키텍트와 아키텍처..

1.2 J2EE 기반 아키텍처 정립..

1.3 J2EE Best Practices and Guidelines.

2. EJB(Enterprise JavaBeans)

2.1 EJB Framework.

2.2 Session Beans.

2.3 Entity Beans.

2.4 Transactions in EJB.

2.5 EJB Security.

3. Design Patterns in Application.

3.1 Factory Pattern.

3.2 Facade Pattern.

3.3 Singleton Pattern.

3.4 Reflection Pattern.

3.5 MVC Pattern.

3.6 Observer Pattern.

3.7 Mediator Pattern.

       4. 웹/컴포넌트 기반 소프트웨어 개발 방법론 정립에 관한 사족

Posted by tornado
|

[펌] MVC모델

JAVA/JEE 2004. 3. 19. 12:00

모델: 애플리케이션 객체

뷰 : 디스플레이하는 방법

컨트롤러 : 사용자 인터페이스가 사용자 입력에 반응하는 방법

 

* 데이터가 변경될때마다 모델은 자신과 관련된 뷰에 알려주고 이에 따라 뷰는 스스로 자신의 외형을 변경하여야 한다.

* MVC는 워크 플로우와 표현부로부터 비즈니스로직을 분리시키는 것이며 애플리케이션의 구조와 사용자에게 표현되어지는 정보로부터 모델을 분리시키는 것이 핵심임

 

- 모델 컴포넌트

  EJB를 사용하는 경우 빈에서 받은 value object지칭

- 뷰 컴포넌트 

  HTML, JSP등으로 구성된 표현부

- 컨트롤러 컴포넌트

  서블릿 또는 자바클래스 또는 빈으로 되어 있으며 비즈니스 오퍼레이션을 실행( 어플리케이션의 행위를 정의)

 


'JAVA > JEE' 카테고리의 다른 글

웹로직 컴파일 명령  (0) 2004.03.24
[펌] [퍼옴]J2EE와 애플리케이션개발속의 디자인 패턴  (0) 2004.03.19
[펌] FactoryMethodPattern  (0) 2004.03.19
[펌] 배치디스크립터  (0) 2004.03.19
[펌] UML산출물간의 연관성  (0) 2004.03.19
Posted by tornado
|

개요

object생성을 위한 interface를 정의,해당 interface의 상속class의 FactoryMethodPattern(object를 생성후 반환하는 메소드)가 구체적인 object생성을 맡음.

생성할 object의 종류마다 상속class를 따로 만듦.

사용 

application-specific한 object정보를 분리하여 볼 수 있다. 생성처리 부분이 간단해 지고 새로운 종류의 object 생성기를 추가할 시 기존 생성처리클래스는 고치지 않고 상속하여 처리할 수 있다. 반드시 interface를 상속하여 구현해야 한다는 점이 있으므로, 상속해서 처리하는 게 좋다고 생각할 때 사용함

 

--------------------------------------------------------------------------------------

퍼옴...http://network.hanbitbook.co.kr/view_news.htm?serial=719

 

저자: 김대곤

 

Abstraction

 

필자는 패턴을 단순화(또는 추상화 Abstraction)시켜서 이해한다고 말했다. Gang of Four의 Design Patterns에는 "Consequences", "Implementation"라는 소제목들이 등장한다. 하지만 필자는 거의 읽어본 적이 없고, 관심도 없다. 그러므로 필자에게 패턴이라는 단어와 "Consequences"나 "Implementation"이라는 단어와 연관되지 않는다. 이렇듯이 관심사항이 아닌 것을 제거해버리는 것을 추상화(Abstraction)이라고 할 수 있다.

 

Factory Method 패턴이 Object가 생성되어야 하는 시점은 알고 있으나 어떤 Object가 생성되어야 하는지 알 수 없을 때, 객체의 생성을 Subclass에 위임하는 방식으로 문제를 해결할 수 있다고 말하고 있다. 첫 번째 질문은 왜 이런 상황에 직면하게 되었는가이다. 어떻게 이런 일이 발생할 수 있는가? 그것은 여러 종류의 객체를 추상화(Abstraction)시켜서 사용했기 때문이다.

 

게임의 예를 들어보자. 이 게임은 병사와 탱크를 가지고 전투를 하는 게임이고, 병사와 탱크를 만들기 위해서 병사를 만들어 내는 막사와 탱크를 만들어 내는 공장이 있어야 된다. 게임의 기능은 "생성", "공격", "이동"이 있다. 생성의 기능을 자세히 살펴보자. 게임상에 존재하는 어떤 물체를 선택하고 "생성" 버튼을 눌렀다고 가정하자. 먼저 선택한 물체가 생성이라는 기능을 가지고 있는 객체인지를 확인하고, 막사이면 병사를 공장이면 탱크를 만들어야 한다. 만약, 실제 객체(막사와 공장)을 사용하였다고 가정하자. 그런데 비행기를 만드는 새로운 공장이 생기면 생성 기능은 수정되어야 한다. 선택한 객체가 새로운 공장인지를 체크해야 하고, 새로운 공장이면 비행기를 만들어야 하기 때문이다. "생성"이라는 기능의 입장에서는 그게 막사인지, 공장인지, 아니면 새로운 공장인지는 관심의 대상이 아니다. "생성" 기능의 입장에선 오직 선택한 객체가 "생성"이라는 기능을 가지고 있는가만 알면 된다. 실제로는 존재하진 않지만 생성이라는 기능을 가진 것들을 Factory라는 개념으로 추상화하여 사용하면, 빈번한 수정과 High Coupling을 피할 수 있다. 객체의 종류에 따라 행동양식이 바뀌는 경우, 조건문을 사용하지 말고 다형성(Polymorphism)를 사용하라는 GRASP 패턴의 "Polymorphism" 원칙을 적용하여 Interface를 만들어서 생성 기능안에서는 Factory Interface만 사용하고 실제 객체들은 Factory Interface 타입의 변수 안에서 모두 숨겨진다. 새로운 공장이 만들 때 Factory Interface만 구현하면 "생성"버튼의 코드는 전혀 수정될 필요가 없다.

"생성" 기능 버튼을 사용자가 클릭하면, 객체를 생성해야 한다. 시점은 알지만 어떤 객체가 생성될 것인지는 선택되는 객체에 따라서 다르다. 그러면 당연히 Factory 객체는 객체의 생성을 담당하는 메소드(병사, 탱크, 비행기 등을 만들어야 함으로)를 가지고 있어야 한다. 이것이 Factory Method 패턴이 직면하는 상황인 것이다. 사실 이 문제는 객체의 생성 뿐 아니라 일반적인 행동(메소드)도 마찬가지이다. "이동" 기능에 대해서 생각해보라.

 

객체 생성을 (생성자가 아닌) 메소드를 통해서 하고자 하는 이유

 

실제 코드 예제를 보기 전에 객체를 생성자가 아닌 메소드를 통해서 생성하려고 하는 이유에 대해서 살펴보자. 메소드를 통해서 생성한다는 것은 Singleton 패턴에 나오는 Singleton 클래스 또는 Static 메소드를 통한 자기 자신 타입의 객체 생성이 아닌 경우에는 객체를 자기 자신의 메소드가 아닌 다른 객체의 메소드 안에서 생성한다는 의미이다. GRASP 패턴에 나오는 Creator 패턴에서 설명했듯이 이런 경우 컨텍스에서 제공받아야 하거나 제약사항들을 체크할 수 있다. 어떤 객체가 Interface를 구현한 객체의 경우, Interface를 쓴 이유는 실제 객체를 숨기기 위해서 한 작업인데, 생성자를 통해서 하면 실제 객체가 드러나 목표하는 효과를 볼 수 없게 되기 때문이다.

너무나 유명하고, 흔한 예제

필자가 아는 선배는 글을 쓰거나 프리젠테이션을 할 때는 항상 예제를 제공하는 것이 기본적인 예의이지 원칙이라고 했다. 설명을 하면 어려운 것도 예제를 보면 쉽게 이해가 되기 때문이겠지만 사실 이해하기 쉬운 예제를 제공하는 것은 쉬운 일이 아니다. Factory Method 패턴은 너무 유명하고 흔해서 검색엔진으로 검색하면 금방 찾을 수 있다. 솔직히 말하면, 필자도 이 예제를 그런 방식으로 구했다. 1분 전에.

 

import java.sql.*;                               

public class JDBCExample {
  private static String url    = "";
  private static String user   = "";
  private static String passwd = "";

  public static void main(String args[]) {
    try {
      Class.forName("oracle.jdbc.driver.OracleDriver");
      
      Connection connection = DriverManager.getConnection(url,user,passwd);
      Statement statement = connection.createStatement();
      ResultSet resultSet = statement.executeQuery("Select to_char(sysdate) from dual");

      while (resultSet.next())
      {
        System.out.println("It is " + resultSet.getString(1)); 
      }

      resultSet.close();
      statement.close();
      connection.close();           
    } catch (Exception e) {
    } finally {
    }
  }
}

몇 가지이 수정이 가해지지 않으면, 이 예제는 실행되지는 않을 것이다. 그러나 Factory Method 패턴을 사용한 클래스가 무려 2개나 된다. 그것도 연결해서 사용했다. Connection 객체는 createStatement() 메소드를 통해서 Statement 객체를 생성하고 Statement 객체는 executeQuery() 메소드를 통해서 ResultSet 객체를 생성하고 있다. Connection, Statement는 모두 Interface이다. 만약 실제 객체를 사용했다면 위의 코드는 다음과 비슷한 모습이 될 것이다.

public class OracleJDBC {
 
  private static String   url    = "";
  private static String   user   = "";
  private static String   passwd = "";

  public static void main(String args[]) {
    try {
      Class.forName("oracle.jdbc.driver.OracleDriver");
      
      OracleConnection connection  = new OracleConnection(url,user,passwd);
      OracleStatement  statement   = new OracleStatement();
      OracleResultSet  resultSet   = statement.executeQuery("Select to_char(sysdate) from dual");

      while (resultSet.next())
      {
        System.out.println("It is " + resultSet.getString(1)); 
      }

      resultSet.close();
      statement.close();
      connection.close();           
    } catch (Exception e) {
    } finally {
    }
  }
}


위 코드는 실행되거나 컴파일이 되거나 하지는 않는다. 실제 오라클을 사용할 경우 쓰이는 객체들이지만 이렇게 코딩하는 사람은 없다. 만약 오라클 안쓰면 다 고쳐야 되는데 누가 이렇게 쓰겠는가? 위의 작업을 하는 사람들에겐 실제 무슨 객체가 쓰이는가는 관심사항이 아니다. 단지 어느 곳에 저장되어 있는 데이터를 읽어서 가져오는 것이 주요 목표인 것이다. JDBC는 각 데이터베이스들을 추상화했지만 더 높은 추상화를 적용한 JDO(Java Data Object)도 있다. JDO는 Persistence에 대한 추상화를 시도하고 있다.

 

결어

 

그럼 추상화(Abstraction)를 어떻게 할 것인가? 이런 문제는 아무도 설명해 주지 않는다. 필자도 누구에게서 추상화의 원리나 관련된 강의를 받은 적이 없다. 필자가 항상 염두에 두는 생각이 있다면 "내가 필요로 하는 최소한의 것만 받아들이겠다"는 자세이다. 누가 나에게 무언가를 요청한다면 "네가 좀 알아서 해 주면 안돼?"라고 말하는 자세 말이다.(실제로 이렇게 살면 맞아 죽겠지만 말이다.) 그렇게 해서 남은 최소한 것을 Interface로 정의해서 사용하자.

필자가 쓰고 있는 패턴에 관한 기사도 Design Pattern를 설명한다기 보다는 Design Pattern이라는 주제에 대해 버리고 버려서 남은, 비슷해 보이지만 전혀 다른 내용이 아닐까 생각한다. 필자는 상속을 좋아하지 않는다. 그래서 SubClass, SuperClass와 같은 용어보다는 Interface라는 용어를 많이 사용한다. 그러나 상속에 대해서도 적용될 수 있음을 밝혀두는 바이다.

 

'JAVA > JEE' 카테고리의 다른 글

웹로직 컴파일 명령  (0) 2004.03.24
[펌] [퍼옴]J2EE와 애플리케이션개발속의 디자인 패턴  (0) 2004.03.19
[펌] MVC모델  (0) 2004.03.19
[펌] 배치디스크립터  (0) 2004.03.19
[펌] UML산출물간의 연관성  (0) 2004.03.19
Posted by tornado
|

* EJB를 첨 사용했을 때 배치 스크립에 대하여 그리 크게 신경쓰지 않았다...간단한 stateless 세션빈으로만 작성했으니까..  그때 궁금했던 것중 하나가 다른 빈은 어떻게 참조할까였따...분명 될것 같은데....잘 안되고 그렇다고 차근차근 공부할 시간은 없었고....  생각나서 정리했따..

 첨부 파일은 배치스크립터에 대한 좀더 자세한 자료임

 

-----------------------------------------------------------------------------------------

 

배치디스크립터

 

배치디스크립터에 포함된 설정정보는

 

1. 구조정보

l 엔터프라이즈 빈 유형(Session, Entity, Message Driven Bean)

l 홈 인터페이스

l 리모트 인터페이스

l 엔터프라이즈 빈 클래스

 

구조 정보는 엔터프라이즈 빈 개발자가 설정합니다. 어플리케이션 어셈블러, 디플로이어는 구조 정보에 대한 사항 중에서 <display-name>,<ejb-name>을 변경할 수 있지만 다른 부분은 변경할 수 없습니다.

 

2. 실행정보

l 리소스 팩토리(Resource Factory)의 참조 정보

l 다른 빈의 참조 정보

l 트랜잭션 제어(Transaction Control)

 

트랜잭션 제어는 컨테이너 관리 트랜잭션(Container Managed Transaction)일 경우 각 메소드에 트랜잭션 속성(Transaction Attribute)을 설정하는 것을 말합니다. 배치 툴에서 실행 정보의 설정은 각각의 화면으로 구분됩니다. 배치 툴을 실행시켜 실행 정보 각각의 설정 화면을 지금 보는 것도 이해에 도움이 됩니다.

 

3. 보안정보

l 보안 식별 정보(Security Identity)

l 메소드 허용 정보(Method Permission)

l 리소스 등에 대한 접근 정보

 

엔터프라이즈 빈의 보안관련 정보를 설정하는 부분으로 배치 툴에서 하나의

화면으로 되어 있습니다.

 

그럼 실행 정보중

 

* 환경정보

 

: 배치 디스크립터 (Deployment Descriptor)의 이름(Name), 값(Value), 데이터 타입(Data Type)의 정보이다.

 

변경 가능한 데이터에 대한 하드 코딩을 피하기 위한 EJB에서의 환경 정보(Environment Entry)는 배치 디스크립터에 설정되어 서버 배치 시 네이밍 서비스에 등록됩니다. 엔터프라이즈 빈 개발자는 빈에서 JNDI를 이용해 네이밍 서비스에 등록된 환경 정보를 얻어 이용합니다.

 

예)

 

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN' 'http://java.sun.com/dtd/ejb-jar_2_0.dtd'>

<ejb-jar> 

<display-name>LoanBean</display-name> 

<enterprise-beans>   

<session>     

<display-name>LoanEJB</display-name>     

<ejb-name>LoanEJB</ejb-name>     

<home>com.sds.ejb.ch5.LoanHome</home>     

<remote>com.sds.ejb.ch5.Loan</remote>     

<ejb-class>com.sds.ejb.ch5.LoanEJB</ejb-class>     

<session-type>Stateless</session-type>     

<transaction-type>Bean</transaction-type>     

<env-entry>       

<env-entry-name>loan/interest</env-entry-name>       

<env-entry-type>java.lang.Double</env-entry-type>       

<env-entry-value>0.067</env-entry-value>    

</env-entry>

<security-identity>       

<description></description>       

<use-caller-identity></use-caller-identity>     

</security-identity>   

</session> 

</enterprise-beans>

</ejb-jar>

 

  서비스호출과는 관계가 없이 배치스크립터에 이자율을 정의하는 부분이다. 배치 스크립터에서 loan/interest 로 기술된 부분을 찾아 정의된 타입과 값을 얻어 사용할수 있다. 

( 배치스크립터에 기술된 0.067을 리턴한다. ) 

 

u소스에서 활용

 

public double interestByYear(double amount) 

{                        

. . .                   

                                   ctx = new InitialContext();                             

                           String codedName = "java:comp/env/loan/interest";

                           Double interest = (Double)ctx.lookup(codedName);

                           if(interest==null)                                           

                                        throw new EJBException("Check the env-entry. - "+codedName);

                                        return amount*interest.doubleValue();                         

                                       

}           

OR

public double interestByMonth(double amount)            

{                         . . .

Context ctx = new InitialContext();                                   

Context envCtx = (Context)ctx.lookup("java:comp/env");                              

Double interest = (Double)envCtx.lookup("loan/interest");

if(interest==null){                                              

                                   throw new EJBException("Check the env-entry. "+

                                             "- java:comp/env/loan/interest");                               

}                                                        

return amount*interest.doubleValue()/12.0;                       

. . .

}

 

*


* EJB 리소스 팩토리

 

엔터프라이즈 빈은 서버에서 제공하는 여러 리소스 즉, JDBC 커넥션, JMS 커넥션 등을 이용하는 경우가 있습니다. 리소스 팩토리는 서버가 시작할 때 서버 네이밍 서비스에 등록되기 때문에 엔터프라이즈 빈 개발자는 JNDI 프로그래밍 방법으로 서버에서 제공하는 리소스 팩토리를 사용합니다. 이런 리소스 팩토리에 대한 참조 정보도 서버 설정에 의해 변경되는 정보들인데 리소스 팩토리 참조 정보를 엔터프라이즈 빈 클래스에 직접적으로 하드 코딩하는 것은 좋지 못한 방법이라 할 수 있습니다.

 

엔터프라이즈 빈이 리소스 팩토리를 참조한다는 정보를 배치 디스크립터에 <resource- ref> 태그를 이용해 설정함

 

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN' 'http://java.sun.com/dtd/ejb-jar_2_0.dtd'>

 . . . . .

<security-identity>       

<description></description>       

<use-caller-identity></use-caller-identity>     

</security-identity>     

<resource-ref>       

<res-ref-name>jdbc/empDB</res-ref-name>       

<res-type>javax.sql.DataSource</res-type>       

<res-auth>Container</res-auth>       

<res-sharing-scope>Shareable</res-sharing-scope>     

</resource-ref>   

</session> 

</enterprise-beans> 

<assembly-descriptor>   

 . . .

 

u소스에서 활용

                  Context ctx = new InitialContext();

             ds = (DataSource)ctx.lookup("java:comp/env/jdbc/EmpDB");

             con = ds.getConnection();

 

( 배치디스크립터에 기술된 데이터소스 클래스 인스턴스를 리턴하겠지... )

 

다른 EJB 빈 참조

 

² 세션 빈은 비즈니스 로직을 처리하는 컴포넌트이고, 엔티티 빈은 비즈니스 데이터를 표현하는 컴포넌트임

² 하나의 세션 빈에서 여러 개의 엔티티 빈 컴포넌트를 참조하는 경우도 있고, 세션빈에서 다른 데이터베이스에 접근할 수도 있음

² 세션 빈에서 엔티티 빈을 참조하는 경우가 다른 빈을 참조하는 일반적인 예임

 

l 리소스 팩토리를 참조하는 경우와 동일하게 처리함 

l EJB 클라이언트 프로그램과 동일한 방법으로 해당 빈을 사용함 (엔터프라이즈 빈 개발자가 참조 빈의 JNDI 이름을 알 수가 없음)

l 빈 개발자는 임의의 이름("Coded Name")으로 참조 빈의 Home Object를 네이밍 서비스에 룩업(Lookup) 함

l 엔터프라이즈 빈이 다른 빈을 참조하고 있다는 것을 배치 디스크립터에 설정함

l 엔터프라이즈 빈은 디플로이어가 서버에 배치 시에 코딩 된 이름과 실제 JNDI 이름을

l 연결하여 설정함

 

. . .

<ejb-ref>

<ejb-ref-name>ejb/CabinHome</ejb-ref-name>

<ejb-ref-name>Entity</ejb-ref-type>

<home>com.titan.cabin.CabinHome</home>

<remote>com.titan.cabin.Cabin</remote>

</ejb-ref>

. . .

 

 

u소스에서 활용

InitialContext jndiContext = new InitialContext();

Object ref = jndiContext.lookup("java:comp/env/ejb/CabinHome") ;

CabinHome home = (CabinHome)

PortableRemoteObject.narrow(ref, CabinHome.class);

 

 

 

 

 

'JAVA > JEE' 카테고리의 다른 글

웹로직 컴파일 명령  (0) 2004.03.24
[펌] [퍼옴]J2EE와 애플리케이션개발속의 디자인 패턴  (0) 2004.03.19
[펌] FactoryMethodPattern  (0) 2004.03.19
[펌] MVC모델  (0) 2004.03.19
[펌] UML산출물간의 연관성  (0) 2004.03.19
Posted by tornado
|


 
 
 
 
전자상거래를 대상으로 하는 사례입니다...
 
 

'JAVA > JEE' 카테고리의 다른 글

웹로직 컴파일 명령  (0) 2004.03.24
[펌] [퍼옴]J2EE와 애플리케이션개발속의 디자인 패턴  (0) 2004.03.19
[펌] FactoryMethodPattern  (0) 2004.03.19
[펌] MVC모델  (0) 2004.03.19
[펌] 배치디스크립터  (0) 2004.03.19
Posted by tornado
|