log4sql을 사용하면 I,U,D,S 쿼리문과 쿼리 수행시간, parameter까지 확인을 할 수 있습니다.
사용방법은 간단합니다.
라이브러리만 추가해준후 driver class만 변경해주면 됩니다.
보다 자세한 사용법 및 jar파일은 아래 URL에서 확인하시면 됩니다.
2009년 9월 16일 수요일
2009년 9월 14일 월요일
out 객체
out 객체는 JSP 페이지의 결과를 웹 브라우저에 전송해 주는 출력 스트림을 나타내며 JSP페이지가 웹 브라우저에게 보내는 모든 정보는 out객체로 통해서 전달이 된다.
out객체는 java.io.Writer 클래스를 상송 받은 javax.servlet.jsp.JspWriter클래스 타입의 객체이며 out객체로 사용한다.
주로 많이 사용되는 메소드는 웹 브라우저에 출력을 하기 위한 println() 메소드이다.
out 내부 객체의 메소드
boolean isAutoFlush() 출력버퍼가 다 채워진 경우에 자동으로 flush했을 경우는 true를 리턴, 그렇지 않은 경우는 false 를 리턴한다.
int getBufferSize() 출력 버퍼의 전체의 크기를 바이트 단위로 리턴한다.
int getRemaining() 출력 버퍼의 남은 양을 바이트 단위로 리턴한다.
void clearBuffer() 현재 출력 버퍼에 저장된 내용을 취소한다.(비운다.)
String println(string) 현재 출력 버퍼에 저장된 내용르 웹 브라우저로 전송하고 버퍼를 비운다.
void close() 출력 버퍼의 내용을 flush하고 스트림을 닫는다.
|
리턴타입 |
메소드명 |
설명 |
| 없음 | clear() |
출력버퍼에 저장된 내용을 버림. 비었을 경우 예외발생 |
| 없음 | clearBuffer() |
clear()메소드와 같은 역할이지만, 버퍼가 빈경우에도 예외발생않고 현재 버퍼를 비움 |
| 없음 | flush() |
현재 버퍼에 저장된 내용을 클라이언트로 전송하고 버퍼를 비움. |
| 없음 | close() |
출력 버퍼를 클라이언트로 전송하고 출력스트림 종료 |
| boolean | isAutoFlush() | page지시어의 autoFlush속성으로 지정된 값을 리턴 |
| int | getBufferSize() | 출력 버퍼의 크기를 바이트 단위 |
| int | getRemaining() | 출력 버퍼의 남은 양 |
| 없음 | print(String str ) | 출력 스트림으로 str 문자열 출력 |
Cannot load JDBC driver class
tomcat/common/lib/ 아래에
ojdbc14라이브러리 추가
아울러 jdk1.5/lib 안에도 꼭 있어야 함..
jdk1.5/jre/lib/ext 안에는 있으나 마나이다..
==========================================
위 작업 끝난 다음에...도 jdbc 드라이버가 인식이 안됫었는데 알보고니 철자가 틀려서 그런거였다;;
ㅠㅠ;;;
'oracle.jdbc.dirver.OracleDriver' 로 써 있었던 것이였다 =>'oracle.jdbc.driver.OracleDriver' 로 바꿔야 햇는데;;
org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot load JDBC driver class 'oracle.jdbc.driver.OracleDriver'
at org.apache.tomcat.dbcp.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:766)
at org.apache.tomcat.dbcp.dbcp.BasicDataSource.getConnection(BasicDataSource.java:540)
at org.apache.jsp.index_jsp._jspService(index_jsp.java:62)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:328)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:315)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:265)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:870)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ClassNotFoundException: oracle.jdbc.driver.OracleDriver
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at org.apache.tomcat.dbcp.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:760)
... 22 more
2009년 7월 27일 월요일
Log4j logging
Logging Messages from Servlets and JSPs
웹 어플리케이션에서 로그를 기록하는 법은 크게 2가지가 있습니다.
하나는 ServletContext.log() 를 이용하는 것이고 다른 하나는 Log4j 를 이용하는 것입니다. 먼저 ServletContext.log()를 사용해서 로그를 남기는 방법을 보겠습니다.
import javax.servlet.*;
import javax.servlet.http.*;
public class MyLog extends HttpServlet {
public void goGet( HttpServletRequest request, HttpServeltResponse response ) throws SevletException, java.io.IOException {
ServletContext context = getServletContext();
context.log("에러가 발생했습니다.");
context.log("에러가 발생했습니다.",new IllegalStateException("잘못된 파라메터입니다."));
}
}
log 메서드는 2개가 있는데 하나는 String 변수만 받고 다른 하나는 String와 Throwable을 받습니다.
Log4j 를 사용하는 방법은 좀더 자세히 보겠습니다. 요것은 아주 유용하기 때문에 자세히 봐야 합니다.^^
먼저 Log4j를 셋업하는 방법부터 보겠습니다. 일단 셋업을 하기전에 다운받아 설치를 해야합니다.
http://jakarta.apache.org/log4j/docs/download.html
여기서 다운받아 톰켓의 WEB-INF/lib 에 가져다 놓습니다. 압축을 풀면 jakarta-log4j-1.2.8 파일이 나옵니다. 파일이름은 버젼마다 틀려집니다. 참고하세요. 압축을 풀고 WEB-INF/lib 에다가 가져다 놓았으면 properties 파일을 만들어야 합니다. 이는 단순히 text파일로 키,값으로 이루어져 로그파일에 대한 각종 정보들을 담아둡니다. 이 프로퍼티 파일로 log4j를 서블릿에서 사용하기 위해선 2개의 패키지를 import 해야 합니다.
import org.apache.log4j.Logger;
import org.apache.log4j.PropertyCofigurator;
하지만 이 프로퍼티 파일을 이용하지 않고 싶을때는 log4j에서 지원하는 default configurator를 이용할 수 있습니다. 이때는 PropertyCofigurator 대신 BasicConfigurator를 임포트 합니다. 사용법은 약간 다르니 주의하세요.
import org.apache.log4j.Logger;
import org.apache.log4j.BasicConfigurator;
import javax.servlet.*;
import javax.servlet.http.*;
public class LoggerDefaultConfig extends HttpServelt {
private Logger log = null;
public void init(){
log = Logger.getRootLogger();
BasicConfigurator.configurator();
}
public void goGet( HttpSevletRequest req, HttpServletResponse res ) throws ServletException, java.io.IOException {
log.debug("디버깅 메시지입니다.");
log.info("정보 메시지입니다.");
}
}
다음은 configuration file 을 이용한 로그 사용법을 보겠습니다.
먼저 log4j.properties 파일을 만들고 web-inf/classes 폴더에다가 넣습니다. 그리고 사용하고자 하는 서블릿에다가 org.apache.log4j.Logger 를 import를 합니다. 그런다음 정적 메소드인 Logger.getRootLogger() 를 사용하여 레퍼런스를 얻어와서 로그를 남김니다.
이 로그파일에는 org.apache.log4j.ConsoleAppender 타입의 이름을 붙입니다. 여기서는 hans로 정하겠습니다.
log4j.rootLogger=DEBUG, hans
log4j.appender.hans=org.apache.log4j.ConsoleAppender
log4j.appender.hans.layout=org.apache.log4j.SimpleLayout
BasicConfigurator.configure( ) 이게 호출되지 않으면 자동으로 web-inf/classes 에서 log4j.properties 파일을 찾아 설정하게 됩니다.
log4j.rootLogger=DEBUG, cons
log4j.logger.com.jspservletcookbook=, myAppender
#the root logger's appender
log4j.appender.cons=org.apache.log4j.ConsoleAppender
#the com.jspservletcookbook logger's appender log4j.appender.myAppender=org.apache.log4j.RollingFileAppender
log4j.appender.myAppender.File=h:/home/example.log
log4j.appender.myAppender.MaxBackupIndex=1
log4j.appender.myAppender.MaxFileSize=1MB
#the root logger's layout
log4j.appender.cons.layout=org.apache.log4j.SimpleLayout
#the com.jspservletcookbook logger's layout
log4j.appender.myAppender.layout=org.apache.log4j.PatternLayout
log4j.appender.myAppender.layout.ConversionPattern=%-5p
Logger:%c{1} Date: %d{ISO8601} - %m%n
위 코드는 myAppender라는 이름으로 rootLogger를 상속하여 다양한 로그를 남기는 법을 보여줍니다.
the log4j Javadoc page: http://jakarta.apache.org/log4j/docs/api/index.html [출처] log 남기기 ( with log4j )|작성자 달콤인생
the log4j project documentation page: http://jakarta.apache.org/log4j/docs/documentation.html
좋은 개발자를 뽑는방법
개발자 생존 가이드 발표하기 전 자바서비스넷의 이원영님이 추천해주셨던 내용이기도 했습니다. http://www.inter-sections.net/2007/11/13/how-to-recognise-a-good-programmer/
6가지 요소를 얘기합니다. 물론 여러 요소들이 많겠지만, 6가지 소양은 다음과 같습니다.
#1 : Passion
#2 : Self-teaching and love of learning
#3 : Intelligence
#4 : Hidden experience
#5 : Variety of technologies
#6 : Formal qualifications
물론 변명의 여지도 Disclaimer에 남겨놓았습니다. 저 조건을 만족하는 것이 모두 좋은 프로그래머는 아니고, 또한 일부 조건에 맞는 형편없는 프로그래머도 있다고. 하지만 비즈니스맨 입장에서 좋은 프로그래머는 알아놓을 필요가 있다고 얘기합니다.
하단에 있는 긍정적인 지표와 부정적인 지표들로 내용을 마무리짓습니다.
Positive indicators:
* Passionate about technology
* Programs as a hobby
* Will talk your ear off on a technical subject if encouraged
* Significant (and often numerous) personal side-projects over the years
* Learns new technologies on his/her own
* Opinionated about which technologies are better for various usages
* Very uncomfortable about the idea of working with a technology he doesn’t believe to be “right”
* Clearly smart, can have great conversations on a variety of topics
* Started programming long before university/work
* Has some hidden “icebergs”, large personal projects under the CV radar
* Knowledge of a large variety of unrelated technologies (may not be on CV)
Negative indicators:
* Programming is a day job
* Don’t really want to “talk shop”, even when encouraged to
* Learns new technologies in company-sponsored courses
* Happy to work with whatever technology you’ve picked, “all technologies are good”
* Doesn’t seem too smart
* Started programming at university
* All programming experience is on the CV
* Focused mainly on one or two technology stacks (e.g. everything to do with developing a java application), with no experience outside of it
사람을 뽑는 입장이라면 자신과 같은 사람을 뽑을까요? 대답이 "Yes"라면 이제 비즈니스맨을 잘 만나는 일만 남았군요. 제리 맥과이어 같은 사람말이죠.
2009년 7월 17일 금요일
Struts VS Struts2
Struts1 VS Struts2
1. 서블릿 의존성
스트럿츠1에서의 Action은 Action이 호출될때 HttpServletRequest와 HttpServletResponse 오브젝트들이 execute 메소드를 통해서 전달되기 때문에 서블릿 API에 대해 의존성을 지니고 있었습니다. 그러나 스트럿츠2의 경우에는 Action클래스들이 단순한 POJO형태로 개발되기 때문에 컨테이너에 의존성이 없습니다. 스트럿츠2에서는 서블릿 컨텍스트가 단순한 Maps로 표현되기 때문에 격리된 환경하에서 Action에 대한 테스트가 가능합니다. 필요하다면 스트럿츠2의 Action은 원 request, response에 접근할 수 있습니다. 그러나 다른 아키텍쳐적인 요소들이 HttpServletRequest나 HttpServletResponse에 대한 직접적인 접근에 대한 필요를 감소시켜주었습니다.
2. Action 클래스들
인터페이스 기반이 아닌 추상클래스 기반으로 개발된 스트럿츠1의 디자인 관련 이슈들은 스트럿츠2에서 해결이 되었습니다. 스트럿츠1의 Action 클래스들은 프레임웍에 의존적인 기반 추상클래스를 상속받도록 되어 있었지만 스트럿츠2의 Action클래스들은 옵셔널하고 커스텀한 서비스를 적용하기 위해 인터페이스를 구현할 수도 있고 아예 하지 않을 수도 있습니다. 스트럿츠2의 경우 Action 클래스들은 단순 POJO들로 개발되기 때문에 컨테이너에 대한 종속관계가 없습니다. 스트럿츠2는 ActionSupport 클래스를 제공하여 공통적으로 사용되는 인터페이스들을 개발할 수 있도록 지원합니다.
그럼에도 불구하고 Action 클래스가 어떤 인터페이스를 구현하도록 요구되지는 않습니다. 어떤 POJO 오브젝트라도 execute 메소드만 존재한다면 스트럿츠2에서 Action 오브젝트로 사용이 가능합니다.
3. 검증(Validation)
스트럿츠1과 스트럿츠2는 둘다 validate 메소드를 통한 메뉴얼한 검증을 지원합니다. 스트럿츠1은 ActionForm내에 validate메소드를 통해 지원하거나 또는 Commons Validator에 대한 확장을 통해서 검증을 지원합니다.
그러나 스트럿츠2에서는 validate 메소드를 통한 메뉴얼한 검증방식과 XWork Validation 프레임웍을 통한 검증을 지원합니다. XWork Validation 프레임웍은 validation 컨텍스트와 프러퍼티의 타입을 위해 정의된 validation설정을 사용하여 validation chaining을 서브 프러퍼티까지 지원합니다.
4. 쓰레딩 모델
스트럿츠1에서 Action들은 반드시 thread-safe이거나 synchronized되어야 했었습니다. 그래서 Action들은 싱글톤이고 thread-safe했으며 해당 Action에 대한 모든 요청을 처리하기 위해 하나의 인스턴스만이 존재했습니다. 싱글톤 전략은 스트럿츠1의 Action에서 처리될 수 있는 일에 대해서 제한을 가져왔으며 추가적이고 조심스러운 개발을 요구했습니다.
그러나 스트럿츠2에서는 Action의 인스턴스들이 각 요청마다 생성됩니다. 따라서 더이상 thread-safe에 대한 이슈가 없습니다.(실제로 서블릿 컨테이너는 하나의 요청에 대해서 한번 사용하고 제거하는 오브젝트들을 많이 생성해냅니다. 그리고 이러한 추가적으로 생성되는 오브젝트들이 퍼포먼스와 가비지 컬렉션에 문제가 되지는 않습니다.)
5. 테스트의 용이함.(Testability)
스트럿츠1 기반의 어플리케이션은 테스트가 복잡했었습니다. 스트럿츠1의 Action을 테스트함에 있어서 가장 큰 장애는 execute 메소드가 서블릿 API에 노출되어 있다는 것입니다. 써드파티 모듈에 의한 확장, Struts TestCase 등이 스트럿츠1을 위한 mock 오브젝트를 제공하고 있습니다. 하지만 스트럿츠2의 Action은 Action을 인스턴스화하고 프러퍼티를 셋팅하고 메소드를 호출함으로써 테스트가 가능합니다. Dependency Injection가 지원되어 테스트 과정을 보다 단순화 할 수 있습니다. 스트럿츠2의 Action은 단순한 POJO들이며 프레임웍에 독립적이므로 스트럿츠2에서의 테스트환경은 아주 쉽습니다.
1. 서블릿 의존성
스트럿츠1에서의 Action은 Action이 호출될때 HttpServletRequest와 HttpServletResponse 오브젝트들이 execute 메소드를 통해서 전달되기 때문에 서블릿 API에 대해 의존성을 지니고 있었습니다. 그러나 스트럿츠2의 경우에는 Action클래스들이 단순한 POJO형태로 개발되기 때문에 컨테이너에 의존성이 없습니다. 스트럿츠2에서는 서블릿 컨텍스트가 단순한 Maps로 표현되기 때문에 격리된 환경하에서 Action에 대한 테스트가 가능합니다. 필요하다면 스트럿츠2의 Action은 원 request, response에 접근할 수 있습니다. 그러나 다른 아키텍쳐적인 요소들이 HttpServletRequest나 HttpServletResponse에 대한 직접적인 접근에 대한 필요를 감소시켜주었습니다.
2. Action 클래스들
인터페이스 기반이 아닌 추상클래스 기반으로 개발된 스트럿츠1의 디자인 관련 이슈들은 스트럿츠2에서 해결이 되었습니다. 스트럿츠1의 Action 클래스들은 프레임웍에 의존적인 기반 추상클래스를 상속받도록 되어 있었지만 스트럿츠2의 Action클래스들은 옵셔널하고 커스텀한 서비스를 적용하기 위해 인터페이스를 구현할 수도 있고 아예 하지 않을 수도 있습니다. 스트럿츠2의 경우 Action 클래스들은 단순 POJO들로 개발되기 때문에 컨테이너에 대한 종속관계가 없습니다. 스트럿츠2는 ActionSupport 클래스를 제공하여 공통적으로 사용되는 인터페이스들을 개발할 수 있도록 지원합니다.
그럼에도 불구하고 Action 클래스가 어떤 인터페이스를 구현하도록 요구되지는 않습니다. 어떤 POJO 오브젝트라도 execute 메소드만 존재한다면 스트럿츠2에서 Action 오브젝트로 사용이 가능합니다.
3. 검증(Validation)
스트럿츠1과 스트럿츠2는 둘다 validate 메소드를 통한 메뉴얼한 검증을 지원합니다. 스트럿츠1은 ActionForm내에 validate메소드를 통해 지원하거나 또는 Commons Validator에 대한 확장을 통해서 검증을 지원합니다.
그러나 스트럿츠2에서는 validate 메소드를 통한 메뉴얼한 검증방식과 XWork Validation 프레임웍을 통한 검증을 지원합니다. XWork Validation 프레임웍은 validation 컨텍스트와 프러퍼티의 타입을 위해 정의된 validation설정을 사용하여 validation chaining을 서브 프러퍼티까지 지원합니다.
4. 쓰레딩 모델
스트럿츠1에서 Action들은 반드시 thread-safe이거나 synchronized되어야 했었습니다. 그래서 Action들은 싱글톤이고 thread-safe했으며 해당 Action에 대한 모든 요청을 처리하기 위해 하나의 인스턴스만이 존재했습니다. 싱글톤 전략은 스트럿츠1의 Action에서 처리될 수 있는 일에 대해서 제한을 가져왔으며 추가적이고 조심스러운 개발을 요구했습니다.
그러나 스트럿츠2에서는 Action의 인스턴스들이 각 요청마다 생성됩니다. 따라서 더이상 thread-safe에 대한 이슈가 없습니다.(실제로 서블릿 컨테이너는 하나의 요청에 대해서 한번 사용하고 제거하는 오브젝트들을 많이 생성해냅니다. 그리고 이러한 추가적으로 생성되는 오브젝트들이 퍼포먼스와 가비지 컬렉션에 문제가 되지는 않습니다.)
5. 테스트의 용이함.(Testability)
스트럿츠1 기반의 어플리케이션은 테스트가 복잡했었습니다. 스트럿츠1의 Action을 테스트함에 있어서 가장 큰 장애는 execute 메소드가 서블릿 API에 노출되어 있다는 것입니다. 써드파티 모듈에 의한 확장, Struts TestCase 등이 스트럿츠1을 위한 mock 오브젝트를 제공하고 있습니다. 하지만 스트럿츠2의 Action은 Action을 인스턴스화하고 프러퍼티를 셋팅하고 메소드를 호출함으로써 테스트가 가능합니다. Dependency Injection가 지원되어 테스트 과정을 보다 단순화 할 수 있습니다. 스트럿츠2의 Action은 단순한 POJO들이며 프레임웍에 독립적이므로 스트럿츠2에서의 테스트환경은 아주 쉽습니다.
6. 입력값 수집 [출처] Struts1 VS Struts2|작성자 슬레이어
스트럿츠1은 사용자의 입력값을 받기 위해 ActionForm 오브젝트를 사용합니다. 그리고 모든 ActionForm들은 프레임웍에 의존적인 기반 클래스를 extend 하도록 되어 있습니다. JavaBean이 ActionForm으로 사용될 수 없기 때문에 개발자들은 입력값을 받기 위해 과다한 클래스들을 생성해야 합니다.
그러나 스트럿츠2는 Action클래스의 프러퍼티들(프레임웍에 독립적인 입력 프러퍼티로서)을 사용함으로써 추가적인 입력값 처리 관련 오브젝트들의 필요성을 제거했고 그리하여 과다하게 클래스가 생성되는것을 방지합니다. 추가적으로 스트럿츠2에서 Action클래스의 프러퍼티들은 웹페이지 상에서 태그라이브러리로 접근이 됩니다. 스트럿츠2는 POJO 폼오브젝트와 POJO Action을 지원할 뿐만 아니라 ActionForm형태의 사용도 지원합니다. 비즈니스 오브젝트나 도메인 오브젝트와 같은 타입들 역시 입력/출력값 관련 오브젝트로 사용이 가능합니다.
7. 표현식(Expression Language)
스트럿츠1은 JSTL과 통합되기 때문이 보통 JSTL을 EL로 사용합니다. 스트럿츠1은 기본적인 수준의 오브젝트내의 값에 대한 처리/순회를 지원하지만 상대적으로 컬렉션과 인덱스가 지정된 프러퍼티에 대한 지원이 약합니다. 스트럿츠2 또한 JSTL을 사용합니다만 보다 강력하고 유연한 Expression Langugae인 OGNL(Object Graph Notation Language)을 지원합니다.
8. 값을 뷰에 연결하기
뷰의 관점에서 보면 스트럿츠1은 오브젝트(Model에서 처리된 결과값을 담은)을 페이지 컨텍스트에 바인딩하기 위해 표준적인 JSP 메커니즘을 사용합니다.
하지만 스트럿츠2는 "Value Stack" 이란 기술을 사용하므로 View와 View가 렌더링할 오브젝트를 연결해놓지 않고도 태그라이브러리를 사용하여 값에 접근할 수 있습니다. Value Stack를 사용하여 값을 프로퍼티명을 사용하지만 그 타입이 다를 수도 있는 항목들을 가진 View들의 경우 해당 View를 재사용할 수 있습니다.
9. 형변환
보통 스트럿츠1에 있어 ActionForm의 프러퍼티값들은 모두 String형입니다. 스트럿츠1은 형변환시에 Commons-Beanutils를 사용합니다. 이런 타입컨버터들은 클래스당 하나씩 할당되고 인스턴트당 하나씩으로 설정할 수 없습니다.
하지만 스트럿츠2는 형변환에 OGNL을 사용합니다. OGNL의 구조는 기본적이고 공통적인 오브젝트의 타입과 프리미티브 타입에 대한 컨버터를 포함하고 있습니다.
10. Action의 실행에 대한 제어
스트럿츠1은 각 모듈당 별개의 RequestProcessors(라이프사이클)을 지원하지만 동일한 모듈내의 모든 Action들은 동일한 라이프사이클을 공유해야하만 합니다. 그러나 스트럿츠2는 Interceptor Stack을 사용하여 Action당 다른 라이프사이클을 가질 수 있도록 지원하고 있습니다. 필요하다면 커스텀 스택도 생성/사용할 수 있습니다.
EJB는 왜 사용하는가?
from : 차의중 prof21@empal.com
아래는 제가 모 회사의 개발자와 주고받은 메일의 내용입니다.
=============================== 1차 질문 =============================
From : 정**(won***@h*******.com)
To : prof21@empal.com
Sent : Friday, Jan 17, 2003 05:34 PM
Subject: JAVASERVICE에서 글을 보고서...
안녕하세요.
좋은 내용을 많이 올려 주셔서 감사합니다.
시스템 개발에서 고견을 구하고자 이렇게 메일을 보냅니다.
시스템 개발을 하려고 합니다.
기본 구성을 말씀드리면....
데이타 건수 : 1>1일 300만건
2>내용별로 60개 테이블에 분리
Transaction : 1>25000 건/1일 * 2개 TABLE
2>이 TABLE의 데이타을 가지고 메인트 작업이 발생합니다.(납품카드 발행,결과 메인트)
3>업무 집중 시간 : 08:00 ~ 10:00 약80~90% 진행
4>나머지 데이타는 주로 조회/엑셀저장 형태로 이루어 집니다.
5>사용자 700 * 1.5 업무 사용자
문제점 : 짧은 시간에 많은 사용자와 많은 업무 수행
기본 환경은 : UNIX, 0RACLE9, WAS(WEBSPHERE/WEBLOGIC)
** EJB 적용을 하였으면 하는데...
속도 및 안정적 서비스에 촛점을 둔다면 사용을 해야 할지요?
바쁘시지만 검토 후 회신을 부탁 드립니다.
============================= 답 ====================================
최근엔 제가 바빠서 글을 거의 못 올렸네요. '고견'이라고까지 표현해주시니 송구합니다. ^^a
EJB를 사용할까 말까의 문제에 관해 많은 분들이 오해를 하고 계신 것 같습니다.
EJB는 왜 필요할까요?
EJB는 "대규모이고 구조가 복잡한 분산 객체 환경"을 쉽게 구현하기 위해서 등장했습니다.
이것이 과거, 현재, 미래를 통틀어 EJB의 제 1 목표이고, 존재의 의미입니다.
따라서, EJB를 사용할 것인지 말 것인지에 앞서, 개발자들은 전체 아키텍쳐를 분산 객체 환경으로 가져갈 것인가 말 것인가를 고려해야 합니다. 만일, 분산 객체 환경이 필요 없다면, EJB를 써야 할 필요성의 70퍼센트는 감소됩니다.
그렇다면, 분산 환경은 왜 필요한걸까요?
분산 환경은 비즈니스 로직과 UI로직을 서로 다른 머신(또는 프로세스)로 분리시킴으로써 비즈니스 로직의 재사용성과 시스템 아키텍쳐의 유연성을 높이기 위해서 등장했습니다.
이 두 조건은 시스템이 커지고 복잡해질 수록 중요합니다. 그래서 대규모 시스템엔 분산 객체 아키텍쳐가 추천되는 것이고, 분산 객체 환경의 구축을 쉽게 하려다 보니 EJB와 같은 전용 플랫폼이
필요한 것입니다.
자, 그렇다면, EJB의 각 요소들과 기능들이 나오게 된 연유에 대해 좀 더 자세히 알아봅시다.
분산 환경을 쉽게 구현하게 하려다보니, RMI 가 필요합니다. 재사용성을 높이려다 보니 컴포넌트 형태가 적합합니다. 데이트 소스가 어떤 형태이든 간에 비즈니스 로직의 소스가 바뀌지 않게 하기 위해서는 비즈니스 로직 컴포넌트와 데이터베이스 접근 컴포넌트를 따로 나눌 필요가 있었습니다. 그래서 세션 빈이라는 것과 엔터티 빈이라는 것을 만들었습니다.
이들이 데이터베이스에 접근하는 컴포넌트이고, 만들기 쉽게, 재사용하기 쉽게 만들어야 하다보니
자연히 트랜잭션을 최대한 자동화할 필요가 생겼습니다. 그래서 트랜잭션 속성이란 걸 지정해서 트랜잭션을 관리하게 만들었습니다. 컴포넌트가 컴포넌트를 호출하다 보니, 컴포넌트 간에 트랜잭션을 전달하게 할 필요도 있습니다. 그래서, 그런 기능도 넣었습니다. 컴포넌트의 다양한 상태에 따라 사용자가 적절한 조치를 취할 수 있도록 콜백 메소드들도 넣었습니다. 자, 수정사항이 발생할 때마다 컴포넌트를 고치게 하는 것은 용이성, 재사용성의 규칙에 위배되므로, 굳이 로직으로 넣을 필요가 없는 것(비즈니스 로직이 아닌 것)은 설정파일에 담아, 소스 수정이 없이 설정만 하면 적용되도록 만들 필요가 있습니다. 그래서 배치 디스크립터란 설정 파일을 만들고, 그런 것들을 끌어
모아 몽땅 집어넣었습니다....etc....어라? UI 와 비즈니스 로직 컴포넌트 간에 네트웍을 통한 RMI 통신이 들어가고, 게다가 여러 개의 객체가 모여 하나의 컴포넌트를 이루며, 자동화를 위해 개발자 모르게 여러 로직을 실행시키게 하다 보니 이거 원 속도가 장난이 아니게 느리고, 자원을 지나치다 싶을 만큼 잡아먹습니다.
이렇게 무겁고 느린 걸 누가 삽니까. 자, 어떻게든 최대한 자원을 관리할 필요가 있습니다.
세션 빈을 상태유지 세션 빈과 무상태 세션 빈으로 나누고, 무상태 세션 빈 인스턴스는 풀링을 시켰습니다. 같은 맥락으로, 데이터 베이스 커넥션 풀링시키는 건 테크닉이라고 하기도 뭐할 만큼 일반적이며 필수적이므로 이 또한 포함시켰습니다.
자, 그럼 결론.
1. "속도를 위해 EJB를 사용한다?"
=> EJB의 여러 기능들은 "속도" 를 위해서 나온 것이 아니라, "분산 객체 환경" 에서 "개발유지보수의 편의성" 과 "시스템의 유연성"을 높이기 위해 고안되었습니다. "속도" 와 "개발유지보수편의성/시스템유연성"은 서로 반비례 그래프를 그리는 인자들입니다. "속도" 와 "편의성/유연성" 이 대치되어 이들 중 하나를 선택할 필요가 있을 때, EJB의 스펙이나 컨테이너 설계자들은 "편의성/유연성"을 택할것입니다.
따라서, 누군가가 "기능 구현을 위해 꼭 필요한 것은 아니지만, 속도를 높이기 위해 EJB를 끼워넣겠다" 라고 한다면 그는 EJB의 개발 의도를 잘못 이해한것이고, 따라서 심각한 오해를 하고 있다는 것을 말해두고 싶습니다.
2. "안정성을 위해 EJB를 사용한다?"
EJB는 이론적으로 안정성이 높습니다. 왜 그럴까요?
첫째 이유는, EJB가 좋은 프레임웍이기 때문입니다.
비즈니스 로직과 UI가 완전히 분리되어있으므로, 개발자들은 비즈니스 로직 담당자와 UI담당자로 나뉘게 됩니다. 각 개발자들의 관심의 범위가 1/2로 좁아지게 되는 만큼 이들은 각각의 영역에 대해 심리적, 지식적으로 2배만큼 전문화됩니다.
전문가들이 만든 코드는 일관성과 안정성을 갖게 되죠. 또한, 잦은 로직 수정 요구가 있더라도 보다 적은 부분을 수정함으로써, 짧은 시간에, 안정적으로 요구를 반영할 수 있습니다.
또한, EJB는 프로그래밍 상의 제한점을 많이 두었기 때문에(예를 들어 하나의 컴포넌트 인스턴스를 동시에 두 명의 사용자가 사용하지 못한다든지 하는...) 개발자의 실수를 미연에 방지하는 역할도 합니다. (안정성을 저해하는 가장 큰 요인은 설계/개발자의 무지와 OS 및 엔진 역할을 하는 소프트웨어의 버그 때문이라는 거 아시죠?)
둘째, EJB는 3계층의 미들티어에 위치하면서, 한정된 공유자원들 (예를 들어, 데이터 베이스 커넥션)을 효과적으로 관리해줍니다. 이것은 사용자가 많을 경우의 안정성에 지대한 영향을 미치는 요인입니다.
그러나, EJB를 끼워넣어야만 이것이 가능한 것은 아닙니다. 웹서버(WAS포함)와 데이터베이스만으로 이루어지는 구조에서, WAS 즉, 서블릿/JSP 엔진은 데이터베이스 커넥션 풀링이라든지 스레드 풀링등을 통해 나름대로 공유자원을 최대한 활용하는 메커니즘을 제공해 줍니다.
세째, 기본적으로 EJB가 들어가면, 머신은 WebServer단 + EJB 단 + DB 단으로 보통 3계층화 됩니다.
WebServer 단 + DB 단으로 이루어지는 2계층에 비해 머신이 1대 더 많죠. 즉, 한 대의 머신이 UI 와 비즈니스 로직을 모두 처리하는 대신, 두 대의 머신이 비즈니스 로직과 UI를 나눠서 처리하므로 2계층 환경에 비해 더 많은 사용자를 수용할 수 있습니다.
어라? 그럼, EJB서버로 쓸 예정이던 머신을 WebServer 머신으로 쓰고, 2개의 WebServer 머신을 클러스터링 시키면 어떨까?
네, 좋습니다. RMI 와 컴포넌트를 사용하지 않으므로, 같은 수의 사용자에 대해서 이 구조는 자원을 보다 덜 소모합니다. 이는 바꿔 말하면, 같은 양의 자원으로 보다 많은 사용자를 수용할 수 있다는 뜻입니다.
또한, WebServer + EJB 서버 각각 한 대로 된 구조는 클러스터링이 되어있지 않습니다.
클러스터링을 시키려면 각 티어마다 머신을 한 대씩 더 두어서 총 4대의 머신을 마련해야 하죠.
그러나, EJB를 안쓰면 웹서버 단이 두 대가 되므로 이들은 자연스레 클러스터링을 구성할 수 있습니다. 즉, 동일한 물리적 환경에서 이 구조는 페일오버가 된다는 얘기죠. 이렇게 보면, EJB를 쓰지 않은 구조는 오히려 훨씬 안정적인 아키텍쳐가 됩니다.
결론적으로, 분산 객체 환경이 필요하지 않다면, EJB를 쓰는 구조가 쓰지 않는 구조에 비해 갖는 이점은 "좋은 프레임웍을 제공" 한다는 것 뿐입니다.
아래는 제가 모 회사의 개발자와 주고받은 메일의 내용입니다.
=============================== 1차 질문 =============================
From : 정**(won***@h*******.com)
To : prof21@empal.com
Sent : Friday, Jan 17, 2003 05:34 PM
Subject: JAVASERVICE에서 글을 보고서...
안녕하세요.
좋은 내용을 많이 올려 주셔서 감사합니다.
시스템 개발에서 고견을 구하고자 이렇게 메일을 보냅니다.
시스템 개발을 하려고 합니다.
기본 구성을 말씀드리면....
데이타 건수 : 1>1일 300만건
2>내용별로 60개 테이블에 분리
Transaction : 1>25000 건/1일 * 2개 TABLE
2>이 TABLE의 데이타을 가지고 메인트 작업이 발생합니다.(납품카드 발행,결과 메인트)
3>업무 집중 시간 : 08:00 ~ 10:00 약80~90% 진행
4>나머지 데이타는 주로 조회/엑셀저장 형태로 이루어 집니다.
5>사용자 700 * 1.5 업무 사용자
문제점 : 짧은 시간에 많은 사용자와 많은 업무 수행
기본 환경은 : UNIX, 0RACLE9, WAS(WEBSPHERE/WEBLOGIC)
** EJB 적용을 하였으면 하는데...
속도 및 안정적 서비스에 촛점을 둔다면 사용을 해야 할지요?
바쁘시지만 검토 후 회신을 부탁 드립니다.
============================= 답 ====================================
최근엔 제가 바빠서 글을 거의 못 올렸네요. '고견'이라고까지 표현해주시니 송구합니다. ^^a
EJB를 사용할까 말까의 문제에 관해 많은 분들이 오해를 하고 계신 것 같습니다.
EJB는 왜 필요할까요?
EJB는 "대규모이고 구조가 복잡한 분산 객체 환경"을 쉽게 구현하기 위해서 등장했습니다.
이것이 과거, 현재, 미래를 통틀어 EJB의 제 1 목표이고, 존재의 의미입니다.
따라서, EJB를 사용할 것인지 말 것인지에 앞서, 개발자들은 전체 아키텍쳐를 분산 객체 환경으로 가져갈 것인가 말 것인가를 고려해야 합니다. 만일, 분산 객체 환경이 필요 없다면, EJB를 써야 할 필요성의 70퍼센트는 감소됩니다.
그렇다면, 분산 환경은 왜 필요한걸까요?
분산 환경은 비즈니스 로직과 UI로직을 서로 다른 머신(또는 프로세스)로 분리시킴으로써 비즈니스 로직의 재사용성과 시스템 아키텍쳐의 유연성을 높이기 위해서 등장했습니다.
이 두 조건은 시스템이 커지고 복잡해질 수록 중요합니다. 그래서 대규모 시스템엔 분산 객체 아키텍쳐가 추천되는 것이고, 분산 객체 환경의 구축을 쉽게 하려다 보니 EJB와 같은 전용 플랫폼이
필요한 것입니다.
자, 그렇다면, EJB의 각 요소들과 기능들이 나오게 된 연유에 대해 좀 더 자세히 알아봅시다.
분산 환경을 쉽게 구현하게 하려다보니, RMI 가 필요합니다. 재사용성을 높이려다 보니 컴포넌트 형태가 적합합니다. 데이트 소스가 어떤 형태이든 간에 비즈니스 로직의 소스가 바뀌지 않게 하기 위해서는 비즈니스 로직 컴포넌트와 데이터베이스 접근 컴포넌트를 따로 나눌 필요가 있었습니다. 그래서 세션 빈이라는 것과 엔터티 빈이라는 것을 만들었습니다.
이들이 데이터베이스에 접근하는 컴포넌트이고, 만들기 쉽게, 재사용하기 쉽게 만들어야 하다보니
자연히 트랜잭션을 최대한 자동화할 필요가 생겼습니다. 그래서 트랜잭션 속성이란 걸 지정해서 트랜잭션을 관리하게 만들었습니다. 컴포넌트가 컴포넌트를 호출하다 보니, 컴포넌트 간에 트랜잭션을 전달하게 할 필요도 있습니다. 그래서, 그런 기능도 넣었습니다. 컴포넌트의 다양한 상태에 따라 사용자가 적절한 조치를 취할 수 있도록 콜백 메소드들도 넣었습니다. 자, 수정사항이 발생할 때마다 컴포넌트를 고치게 하는 것은 용이성, 재사용성의 규칙에 위배되므로, 굳이 로직으로 넣을 필요가 없는 것(비즈니스 로직이 아닌 것)은 설정파일에 담아, 소스 수정이 없이 설정만 하면 적용되도록 만들 필요가 있습니다. 그래서 배치 디스크립터란 설정 파일을 만들고, 그런 것들을 끌어
모아 몽땅 집어넣었습니다....etc....어라? UI 와 비즈니스 로직 컴포넌트 간에 네트웍을 통한 RMI 통신이 들어가고, 게다가 여러 개의 객체가 모여 하나의 컴포넌트를 이루며, 자동화를 위해 개발자 모르게 여러 로직을 실행시키게 하다 보니 이거 원 속도가 장난이 아니게 느리고, 자원을 지나치다 싶을 만큼 잡아먹습니다.
이렇게 무겁고 느린 걸 누가 삽니까. 자, 어떻게든 최대한 자원을 관리할 필요가 있습니다.
세션 빈을 상태유지 세션 빈과 무상태 세션 빈으로 나누고, 무상태 세션 빈 인스턴스는 풀링을 시켰습니다. 같은 맥락으로, 데이터 베이스 커넥션 풀링시키는 건 테크닉이라고 하기도 뭐할 만큼 일반적이며 필수적이므로 이 또한 포함시켰습니다.
자, 그럼 결론.
1. "속도를 위해 EJB를 사용한다?"
=> EJB의 여러 기능들은 "속도" 를 위해서 나온 것이 아니라, "분산 객체 환경" 에서 "개발유지보수의 편의성" 과 "시스템의 유연성"을 높이기 위해 고안되었습니다. "속도" 와 "개발유지보수편의성/시스템유연성"은 서로 반비례 그래프를 그리는 인자들입니다. "속도" 와 "편의성/유연성" 이 대치되어 이들 중 하나를 선택할 필요가 있을 때, EJB의 스펙이나 컨테이너 설계자들은 "편의성/유연성"을 택할것입니다.
따라서, 누군가가 "기능 구현을 위해 꼭 필요한 것은 아니지만, 속도를 높이기 위해 EJB를 끼워넣겠다" 라고 한다면 그는 EJB의 개발 의도를 잘못 이해한것이고, 따라서 심각한 오해를 하고 있다는 것을 말해두고 싶습니다.
2. "안정성을 위해 EJB를 사용한다?"
EJB는 이론적으로 안정성이 높습니다. 왜 그럴까요?
첫째 이유는, EJB가 좋은 프레임웍이기 때문입니다.
비즈니스 로직과 UI가 완전히 분리되어있으므로, 개발자들은 비즈니스 로직 담당자와 UI담당자로 나뉘게 됩니다. 각 개발자들의 관심의 범위가 1/2로 좁아지게 되는 만큼 이들은 각각의 영역에 대해 심리적, 지식적으로 2배만큼 전문화됩니다.
전문가들이 만든 코드는 일관성과 안정성을 갖게 되죠. 또한, 잦은 로직 수정 요구가 있더라도 보다 적은 부분을 수정함으로써, 짧은 시간에, 안정적으로 요구를 반영할 수 있습니다.
또한, EJB는 프로그래밍 상의 제한점을 많이 두었기 때문에(예를 들어 하나의 컴포넌트 인스턴스를 동시에 두 명의 사용자가 사용하지 못한다든지 하는...) 개발자의 실수를 미연에 방지하는 역할도 합니다. (안정성을 저해하는 가장 큰 요인은 설계/개발자의 무지와 OS 및 엔진 역할을 하는 소프트웨어의 버그 때문이라는 거 아시죠?)
둘째, EJB는 3계층의 미들티어에 위치하면서, 한정된 공유자원들 (예를 들어, 데이터 베이스 커넥션)을 효과적으로 관리해줍니다. 이것은 사용자가 많을 경우의 안정성에 지대한 영향을 미치는 요인입니다.
그러나, EJB를 끼워넣어야만 이것이 가능한 것은 아닙니다. 웹서버(WAS포함)와 데이터베이스만으로 이루어지는 구조에서, WAS 즉, 서블릿/JSP 엔진은 데이터베이스 커넥션 풀링이라든지 스레드 풀링등을 통해 나름대로 공유자원을 최대한 활용하는 메커니즘을 제공해 줍니다.
세째, 기본적으로 EJB가 들어가면, 머신은 WebServer단 + EJB 단 + DB 단으로 보통 3계층화 됩니다.
WebServer 단 + DB 단으로 이루어지는 2계층에 비해 머신이 1대 더 많죠. 즉, 한 대의 머신이 UI 와 비즈니스 로직을 모두 처리하는 대신, 두 대의 머신이 비즈니스 로직과 UI를 나눠서 처리하므로 2계층 환경에 비해 더 많은 사용자를 수용할 수 있습니다.
어라? 그럼, EJB서버로 쓸 예정이던 머신을 WebServer 머신으로 쓰고, 2개의 WebServer 머신을 클러스터링 시키면 어떨까?
네, 좋습니다. RMI 와 컴포넌트를 사용하지 않으므로, 같은 수의 사용자에 대해서 이 구조는 자원을 보다 덜 소모합니다. 이는 바꿔 말하면, 같은 양의 자원으로 보다 많은 사용자를 수용할 수 있다는 뜻입니다.
또한, WebServer + EJB 서버 각각 한 대로 된 구조는 클러스터링이 되어있지 않습니다.
클러스터링을 시키려면 각 티어마다 머신을 한 대씩 더 두어서 총 4대의 머신을 마련해야 하죠.
그러나, EJB를 안쓰면 웹서버 단이 두 대가 되므로 이들은 자연스레 클러스터링을 구성할 수 있습니다. 즉, 동일한 물리적 환경에서 이 구조는 페일오버가 된다는 얘기죠. 이렇게 보면, EJB를 쓰지 않은 구조는 오히려 훨씬 안정적인 아키텍쳐가 됩니다.
결론적으로, 분산 객체 환경이 필요하지 않다면, EJB를 쓰는 구조가 쓰지 않는 구조에 비해 갖는 이점은 "좋은 프레임웍을 제공" 한다는 것 뿐입니다.
일, 비즈니스 로직과 UI를 완전히 분리시킬 수 있는 좋은 프레임웍이 있다면 EJB를 사용하지 않고,
WebServer 티어 (아...물론, 이 글에서 WebServer 티어라 하는 것은 , JSP 와 서블릿을 포함하여 말합니다.
정확히 말하면, WebServer + WAS를 말한다는 거죠.) 에 모든 것을 두는 것이 안정성이 더욱 높습니다.
3. 더하여, "EJB는 배우기 쉽고, 사용하기 쉽다" 라는 말씀들을 많이 하시는데...그건, CORBA라든지 하는 다른 분산객체용 엔진에 비해 그렇다는 것입니다.
EJB를 능숙하게 사용하려면 적잖은 시간이 걸립니다. 한 일주일 교육받는 걸로 충분한 문제가 아니라는 거죠. 그렇다고, EJB에 대해 철저히 알지 못하고 사용하시는 것은 오히려 사용하지 않는 것만 못합니다.
이는 오히려 개발자의 무지로 인해 시스템의 안정성과 유지/보수의 용이성을 해치게 되죠. 그리고, 나중에 튜닝한다고 시간을 더 뺏기게 될 수도 있습니다. 필요한 만큼 머신을 구입할 수 있는 상황이 안되는 그런 경우에, 성능이 기대만큼 안 나오면 어쩔 수 없이 튜닝작업 들어가야 하지 않겠습니까? 아다시피, 어플리케이션의 정확한 속도는 테스트를 해봐야 아는 거고 보다 정확한 테스트는 개발이 어느 정도 완료된 후에야 할 수 있는 거죠. 그러다보니, 튜닝할 시간은 짧고, 그래서 꼼수에 꼼수를
더해가는 하는 거죠. 이거...쥐약이죠. 잘 만들어 놓은 어플리케이션을 끝에 가서 완전히 꼬아놓을 수도 있습니다. 흔히 말하는 "스파게티 소스" 가 되는거죠. 스파게티 소스에서 안정성을 기대할 수 있겠습니까? 절대 아니죠.
결론적으로, 님의 환경이 어떻든간에 즉, 트랜잭션이 얼마나 많고, 레코드가 얼마나 많건간에 "분산 객체 아키텍쳐"가 필요치 않고, 좋은 프레임웍을 갖고 계시다면, EJB는 넣지 않으시는 것이 좋습니다. 그렇지 않다면, 즉, "분산 객체 아키텍쳐"가 필요하다거나, 좋은 프레임웍이 없다거나, 능숙한 설계/개발자가 없다거나 하실 경우는 EJB가 적극 추천됩니다.
WebServer 티어 (아...물론, 이 글에서 WebServer 티어라 하는 것은 , JSP 와 서블릿을 포함하여 말합니다.
정확히 말하면, WebServer + WAS를 말한다는 거죠.) 에 모든 것을 두는 것이 안정성이 더욱 높습니다.
3. 더하여, "EJB는 배우기 쉽고, 사용하기 쉽다" 라는 말씀들을 많이 하시는데...그건, CORBA라든지 하는 다른 분산객체용 엔진에 비해 그렇다는 것입니다.
EJB를 능숙하게 사용하려면 적잖은 시간이 걸립니다. 한 일주일 교육받는 걸로 충분한 문제가 아니라는 거죠. 그렇다고, EJB에 대해 철저히 알지 못하고 사용하시는 것은 오히려 사용하지 않는 것만 못합니다.
이는 오히려 개발자의 무지로 인해 시스템의 안정성과 유지/보수의 용이성을 해치게 되죠. 그리고, 나중에 튜닝한다고 시간을 더 뺏기게 될 수도 있습니다. 필요한 만큼 머신을 구입할 수 있는 상황이 안되는 그런 경우에, 성능이 기대만큼 안 나오면 어쩔 수 없이 튜닝작업 들어가야 하지 않겠습니까? 아다시피, 어플리케이션의 정확한 속도는 테스트를 해봐야 아는 거고 보다 정확한 테스트는 개발이 어느 정도 완료된 후에야 할 수 있는 거죠. 그러다보니, 튜닝할 시간은 짧고, 그래서 꼼수에 꼼수를
더해가는 하는 거죠. 이거...쥐약이죠. 잘 만들어 놓은 어플리케이션을 끝에 가서 완전히 꼬아놓을 수도 있습니다. 흔히 말하는 "스파게티 소스" 가 되는거죠. 스파게티 소스에서 안정성을 기대할 수 있겠습니까? 절대 아니죠.
결론적으로, 님의 환경이 어떻든간에 즉, 트랜잭션이 얼마나 많고, 레코드가 얼마나 많건간에 "분산 객체 아키텍쳐"가 필요치 않고, 좋은 프레임웍을 갖고 계시다면, EJB는 넣지 않으시는 것이 좋습니다. 그렇지 않다면, 즉, "분산 객체 아키텍쳐"가 필요하다거나, 좋은 프레임웍이 없다거나, 능숙한 설계/개발자가 없다거나 하실 경우는 EJB가 적극 추천됩니다.
물론, 어플리케이션 개발 후, 성능 테스트의 결과에 따라, 머신은 WebServer 만 사용할 때보다 1.5 내지 2 배정도 증설하실 여력이 있다면 말입니다.
=============================== 2차 질문 =========================
From : 정원식(won***@h*****.com)
To : 차의중(prof21@empal.com)
Sent : Saturday, Jan 18, 2003 10:22 AM
Subject: 감사합니다.추가로..[JAVASERVICE에서 글을 보고서...]
답변에 감사를 드립니다.
죄송하지만 추가 질문을 좀 드리겠습니다.
1> 3tire 로 갈때 꼭 h/w 가 구분이 되어야 한는지요?
webserver tire(weblogic) -- ejb tire(weblogic) -- db
이 경우 결국 weblogic로 tire1 , tire2 를 구현하게 되지 않나요? 아니면, 한 box에서 weblogic으로 (jsp/servlet , ejb) 구현하면 문제점은?
=> H/W를 나누지 않고, 한 서버 내에서 두 JVM으로 이들을 나눌 경우, 두 JVM간에 RMI가 일어납니다. 그런데, 어차피 한 서버 내에 있으면 RMI를 사용해야 할 필요가 없지요. 이것은 부가적인 부담을 서버에게 안겨줍니다. 물론, 머신 수가 충분치 않을 때, 이런 구조로 사용하다가, 나중에 꼭 필요하면 쉽게 머신을 분리시킬 수 있죠.
어쨌건 이것은 "문제"라고 볼 수는 없고, 만일 머신을 분리시킬 계획이 없다면, "쓸 데 없는 일"이 되어버립니다.
물론, EJB 와 WAS를 한 개 JVM에 올리고, 서블릿과 EJB간 통신을 로컬 인터페이스를 이용하여 함으로써 RMI 즉, 네트웍 통신을 하지 않는 아키텍쳐를 택할 수도 있습니다.
그러나, 여전히 EJB 컴포넌트는 무겁습니다. 이건 어쩔 수 없죠. 컴포넌트는 일반 클래스에 비해 당연히 무거운겁니다. 컴포넌트에 대해 사람들이 요구하는 조건은 한 개 클래스만 가지고는 만족시킬 수가 없습니다. 당연히, 보이지 않는 부분에서의일을 수행하기 위해 보이지 않는 클래스들이 중간에 끼어들지요. 그러니, RMI 를 하지 않아도 역시 가벼운 객체로 처리할 수 있는 일을 무거운 컴포넌트로 처리하게 되는 결과가 옵니다.
보통 EJB를 쓰면서 그 장점을 트랜잭션 수행의 편의성과 안정성을 따지시는데, JDBC 커넥션에 begin() 과 commit()을 쓰신다고 해서, EJB에 비해 얼마나 더 복잡하고 어려운 작업을 해야 할 것인가...를 생각해 보면, "일반적인 어플리케이션에서는 그다지 차이가 없다." 라는 것입니다. 데이터 소스가 다양하고, 여러 개이며, 복잡한 구조를 가지고 있으며, 이들을 하나의 트랜잭션으로 묶어야 할 필요가 있다면, EJB 나 JTA의 사용은 꼭 필요합니다.
이 경우 결국 weblogic로 tire1 , tire2 를 구현하게 되지 않나요? 아니면, 한 box에서 weblogic으로 (jsp/servlet , ejb) 구현하면 문제점은?
=> H/W를 나누지 않고, 한 서버 내에서 두 JVM으로 이들을 나눌 경우, 두 JVM간에 RMI가 일어납니다. 그런데, 어차피 한 서버 내에 있으면 RMI를 사용해야 할 필요가 없지요. 이것은 부가적인 부담을 서버에게 안겨줍니다. 물론, 머신 수가 충분치 않을 때, 이런 구조로 사용하다가, 나중에 꼭 필요하면 쉽게 머신을 분리시킬 수 있죠.
어쨌건 이것은 "문제"라고 볼 수는 없고, 만일 머신을 분리시킬 계획이 없다면, "쓸 데 없는 일"이 되어버립니다.
물론, EJB 와 WAS를 한 개 JVM에 올리고, 서블릿과 EJB간 통신을 로컬 인터페이스를 이용하여 함으로써 RMI 즉, 네트웍 통신을 하지 않는 아키텍쳐를 택할 수도 있습니다.
그러나, 여전히 EJB 컴포넌트는 무겁습니다. 이건 어쩔 수 없죠. 컴포넌트는 일반 클래스에 비해 당연히 무거운겁니다. 컴포넌트에 대해 사람들이 요구하는 조건은 한 개 클래스만 가지고는 만족시킬 수가 없습니다. 당연히, 보이지 않는 부분에서의일을 수행하기 위해 보이지 않는 클래스들이 중간에 끼어들지요. 그러니, RMI 를 하지 않아도 역시 가벼운 객체로 처리할 수 있는 일을 무거운 컴포넌트로 처리하게 되는 결과가 옵니다.
보통 EJB를 쓰면서 그 장점을 트랜잭션 수행의 편의성과 안정성을 따지시는데, JDBC 커넥션에 begin() 과 commit()을 쓰신다고 해서, EJB에 비해 얼마나 더 복잡하고 어려운 작업을 해야 할 것인가...를 생각해 보면, "일반적인 어플리케이션에서는 그다지 차이가 없다." 라는 것입니다. 데이터 소스가 다양하고, 여러 개이며, 복잡한 구조를 가지고 있으며, 이들을 하나의 트랜잭션으로 묶어야 할 필요가 있다면, EJB 나 JTA의 사용은 꼭 필요합니다.
그러나, 1개 데이터베이스에 대한 접근은 JDBC만으로 처리가 가능합니다. 물론, CMP를 사용하면, SQL 날코딩의 복잡성을 Encapsulation 해주므로 좀 더 소스를 간단하게 만들 수 있습니다. 그러나 이것은 DAO 객체 등을 도입해서, SQL문을 가진 클래스를 따로 분리시킨다든지 함으로써 상당 부분 극복이 가능한 문제입니다.
ps : 하나의 머신에서 WAS 와 EJB를 한꺼번에 돌림으로써 WAS만 돌릴 때보다 사용자를 더 많이, 안정적으로 수용하는 경우도 있을 수 있는데 이것은 다중 CPU 머신에서 JVM의 분리가 가져다주는 효과입니다. WAS-EJB 구조와 WAS-WAS 구조를 비교하자면, 어차피 JVM을 분리시켰기 때문에 WAS-WAS 구조가 역시 수행성능이 낫습니다.
2> 두가지 관점에서 보면..
속도는 2tire 보다 3tire(ejb)에서 어느 정도가 느려 지나요?
=> 동일한 H/W 사양을 두고 측정을 해보면 어쨌든 2배 이상은 느립니다. 이론적으로도 그럴 수 밖에 없죠. 물론, 이것은 관점의 차이일 수도 있습니다. 하나 요청의 총 처리 시간이 10초인데, 이 중 9초가 데이터베이스에서 잡아먹는 시간이라면, 2-Tier 와 3-Tier 간에 처리시간이 길게 차이 나봤자 1초 이내가 나올 수 있을껀데, 이것이 전체 처리 시간에 비해 워낙이 작으므로 "차이가 거의 나지 않는다"라고 볼 수도 있을껍니다.
따라서, 2배라고 하는 것은 "클라이언트-WAS" 간에서의 처리 속도와 "클라이언트-WAS-EJB"간의
처리 속도만을 비교했을 때라는 것을 주지하시기 바랍니다. 속도차이는 동시사용자가 많으면 점점 더 벌어집니다.
하지만 3tire(ejb) 안정적인 서비스(급격한 속도 저하 극복)를 위한 대안으로 될 수 있는지요?
=> 안정성이라는 것은 많은 사용자가 동시에 어플리케이션에 접근할 때에도 시스템이 급격히 느려지거나 다운되는 것을 막아준다는 것이겠지요. 이를 위한 가장 이상적인 방법은 머신의 수를 늘리는 것입니다.
그러나, 우리가 사용할 수 있는 머신의 수는 한정되어있지요.
한정되어있는 머신으로 더 많은 사용자를 수용하려면,머신의 자원을 최대한 활용하는 방법을 찾는 것이 최선의 목표이겠지요. 더 느려지는 것을 감수하고라도 안정성을 꽤하겠다면, 차라리 sleep() 이나 yield()를 두어 하나의 요청이 CPU를 지나치게 오랫동안 점유하는 것을 막고, 그 사이에 다른 요청이 CPU를 사용할 수 있도록 배려하는 것이 머신의 성능을 최대한 활용하는 것이겠지요.
다른 컴포넌트를 끼워넣어 부가적인 일을 그 사이에 하는 것은 답이 아니겠지요. 왜냐하면, 같은 일을 처리하기 위해 더 많은 CPU점유시간이 필요하고,메모리도더 많이 사용하는 것이 되기 때문이지요. 어떤 하나의 일을 처리할 때 CPU 와 메모리등에 대한 단위 요구량을 최소화 시키는 것이
가장 안정성을 높이는 일이 아니겠습니까?
물론, 아다시피 완벽한 안정성이란 없습니다. 사용자가 끝없이 늘어나는 데 어떤 메커니즘을 도입한다 한들 그 모든 사용자를 수용하면서 안정적인 서비스를 할 수 있겠습니까? 하나의 머신이 처리할 수 있는 최대 동시 사용자 수에는 한계가 있죠.
따라서, 그야말로 한계에 다다르면 어쨌든 머신을 늘려야겠죠. 만일, 어떤 경우에도 한정된 머신만으로 안정적인 서비스를 해야겠다면, 한계치 이상의 동시 사용자가 접속할 경우, 그 이상의 사용자에게는 "죄송합니다. 다른 요청을 처리 중이오니 잠시 후에 다시 접속해 주십시요" 라고 메시지를 내보내서 점잖게 돌려보내는 것이 최선입니다.
-----------------------------------------------------------------
본 문서 및 첨부파일은 자유로이 복사/배포가 가능하나 반드시 저자의
이름과 연락처를 명시해주시기 바랍니다.
차의중
prof21@empal.com
(2004-02-27 09:50:59)
[출처] [EJB] EJB 는 왜 사용하는가 ?|작성자 슬레이어
피드 구독하기:
글 (Atom)