Sanggu's blog




최상단 광고 코드

 추천 사이트

 애자일 이야기 : http://agile.egloos.com
 서명덕 기자의 인터넷 : http://itviewpoint.com
 비지니스 뉴스 : http://www.ciobiz.co.kr
 MOCOMSYS : http://www.mocomsys.com
 Apache Software : http://www.apache.org
 소프트웨어 기술경력관리: http://career.sw.or.kr
 한이음 (지식경제부): http://www.hanium.or.kr
 IT 기술 뉴스: http://www.bloter.net/
 IBM 티볼리 까페: http://cafe.naver.com/tivolitool.cafe
 JAVA jar 검색 : http://www.findjar.com
 VM Ware 가상화: http://www.vmware.com

2009년 10월 29일 목요일

Derby 사용

1. Derby Client 접속 형태
Derby Database 접속방법은 embedded, client 형태인 2가지 나뉜다.
  • Embedded 접속 : 데이타베이스가 자바의 한 부분으로써 실행되고 , 같은 JVM을 공유한다. 그 결과 임베디드 방식은 port open이 필요없고 user, password만 가지고 자신의 lo서버의  Derby DB Server에 바로 접속한다.  외부에서는 Derby DB Server에 접속 할 수 없다.(즉, 자신이 만든 application에 DB가 필요한 경우 내장해서 application과 함께 배포하여 사용할때 유용하다.)
  • Client 접속 : TCP/IP 방식인 JDBC thin client 방식처럼 ip, port, user, password 의 접속 정보를 가지고 외부의 여러 client에서 Derby DB Server에 접속하여 사용할 수 있다.

Derby Server에 접속(connection) 방법인 embedded로 접속하는 경우 외에, client 환경으로 접속하는 경우가 많다.
그 이유는 embedded 경우로 접속할 경우,  embedded만 DB server에 접속 할수 있고 다른 client에서 접속 할 수 없기 때문이다.

2. 임베디드 방식 접속
>ij

ij version 10.4
ij> connect 'jdbc:derby:firstDB;user=sgtae;password=password';  
ij>
3. client 접속 방식 접속
ij> connect 'jdbc:derby://remote ip or domain:port/db명;user=sgtae;password=password';

client는 임베디드 방식과 달리 IP, Port를 갖는다.
4.feed back
ERROR XJ040: Failed to start database DB
see the next exception for details.
ERROR XSDB6: Another instance of Derby may have already booted
the database DB

이와 같은 경우는 임베디드 형태로 이미 DB Server에  접속되어 있으므로 ,더 이상 Derby client로 접속할 수 없다는 Error 메시지이다.
이 경우,  이미 임베디드 형태로 접속되어 있던 방식을  Client 접속 방법으로 새로 띄운다면, 다른 Client에서도 여러 connection으로 붙을 수 있을 것이다.

2009년 10월 22일 목요일

Linux port 열기

1. 리눅스 port 열기.
리눅스 port를 열기 위해서는  iptables를 통해서, 포트를 열고 막고를  할 수 있습니다.

아래의 예제 부분만 따라 하시면 해당 port에 대해 모두 열 수 있습니다.
Inbound (외부에서 서버로 들어오는) , Outbound( 서버에서 외부로 나가는 )  모두 port를 열기 위해서는 아래의 iptables로 INPUT, OUPUT 을 해주면 모두 열립니다.
권한은 root에서 해주시기 바랍니다.

iptables -I INPUT 1 -p tcp --dport port -j ACCEPT
iptables -I OUTPUT 1 -p tcp --dport port -j ACCEPT


예를 들면 ) FTP port 21번을 열고 싶다.
iptables -I INPUT 1 -p tcp --dport 21 -j ACCEPT
iptables -I OUTPUT 1 -p tcp --dport 21 -j ACCEPT

port 만 맞게 넣어주면 됩니다.

2009년 10월 21일 수요일

linux 비트 버전 확인

root>  uname -m


비트 확인 내용
- 32-bit x86-compatible (i386/i686)
- 64-bit AMD64 and Intel EM64T (x86_64)
- 64-bit Intel Itanium2 (ia64)
- 64-bit IBM eServer iSeries and pSeries and POWER (ppc64)
- 31-bit IBM S/390 (s390)
- 64-bit IBM eServer zSeries (s390x)

2009년 10월 7일 수요일

JBI - componenet framework

JBI - component framework.

1. overview.

JBI의 component요소(Sevice Engine, Binding component)를 JBI 환경과 인터페이스에  install/uninstall, life cycle 그리고 error 지시를 제공하는 것입니다.
JBI framework은 아래의 항목 반드시 제공하여야 합니다.

- Component installation context. - component를 install/unistall시에 access ,자원 및 정보 제공을 해야 함.
- Component context. - component를 초기(init())화 할시에 access, 자원 및 정보제공.
- Class Loading. - Class Loader시에 (즉, compoenet instance 생성시) component에 대해, bootstrap과 실행시간을 제공해야 함.
component에게 JBI library로는 표준 class loader계층, component access, 공유를 제공해야 함.
- Error indication. - JBI spec의 구성에 맞추어 개발시 에러에 관해서는 Exception class를 제공하게 되는데, 여러가지 error type을 제공해야 한다.
JBI는 특정 인터페이스를 구현하기 위해 다음과 같은 기능을 제공 :

- Bootstrap - JBI의 관리 기능으로서, install/uninstall에 대해 제공.
- Component - JBI의 구성요소 서비스 단위(SE, BC)
- Component life cycle - component life cycle.
- Service unit manager. - service 단위의 구성요소에 depoly에 관한 제어. (선택적 사항)

2. Component의 관리 기능

 [1]  Bootstrapper.

- componentdml install/uninstall은 JBI의 관리시스템에 의해 실행.
- component는 bootstrap interface스를 구현하는 class의 이름으로 제공되야 한다.
(방식 - Bootstrap.init() )
 [2]. Component Interface

 - 각 componenet는 반드시 component interface에 대해서 구현이 되어야 함.
 - implementation class 이름은 관리 시스템의 install description을 제공해야 함.
 - 그리고 componenet interface는 아래와 같은 access에 대한 제공을 해줘야 함.

 1) component의 life cycle.
 2) component의 service unit manager

3. Component Life cycle
- 각 component들은 componentLifeCycle interface에 의해 구현되어야 한다.
그로인해 component interface를 통해 액세스를 하게된다.
- life cycle은 ComponentLifeCycleMBean으로 구현되며 필요한 component 상태를 변경할 수 있도록
ComponentLifeCycle interface를 사용한다.

4. Service Unit Manager
- 각 component들은 선택적으로 service manager unit을 제공할 수 있다.
serviceUnintManager interface를 통해 구현 가능.


JBI 공급 환경 특징 (요소)

1. Component Context
- component를 초기화 할시에 자원 또는 정보 제공은 아래와 같습니다.
- Component Name
- installation Root
- Workspace Root
- MBean Name service (JMX MBean object name)
- MBean Server
- Naming context
- Delivery channel.
- Endpoint Activation/deactivation

2. Installation (Bootstrap)
- Component name.
- Component class name.
- Class path elements
- Component context. (init() 을 위해 access 제공)

* getComponentName (), getInstallRoot (), getMBeanNames (), getMBeanServer (),
   getNamingContext (), getTransactionManager (), getWorkspaceRoot ()

- Installation root directory
- Component installation descriptor.

3. Logger.
Java.util.logging.Logger 사용.
Class Loading
component instance를 생성하는데 사용되는 클래스 로더 제공. ( Installation time, Execution time)

(예를 들면, jvm class loading 될때, Bootstrap loading --> extension loading --> System class loading)
[1]. Class and Resource Loading Styles and Loader Ordering

1) Initialing loader 생성
2) shared library class loader search
3) component's shared library loader as a single parent.
4) Each shared library loader
5) JBI 상위 클래스 loader로서, shared class 사용.
6) 그 외의 library loader.
[2]. Shared Libraries
일반적으로 둘 이상의 JBI 구성 요소에서 공유되는 Java 클래스를

[3]. Execution Class Loader

  1) Class Loading Ordering Rules
  2) Delegation Style
  3) Installation and Uninstallation of Shared Libraries
  4) Component Viewpoint
 [4]. Bootstrap Class Loader

  1) Class Loading Ordering Rules
   2) Delegation Style

Error Indication

기본적으로 Java exception을 사용.
1) DeploymentException
- administrative tool을 사용하여deployment 실패시. 상세정보를 나타낸다.

2) MessagingException.
- NMR에 의하여 생성, 조작, 전송 및 교환 및 메시지를 수신할때 throw 됩니다.

JBI 특징

JBI 간략한 특징



JBI는 plug-in component를 이용해서 nomalize한 메시지로 변환을 통해 시스템을 통합할 수 있는 자바 기반의 표준.

* 특징
JBI는 각기 다른 컴포넌트들과 직접적으로 통신하지 않고,,JBI 환경 인터페이스만 제공한다.
컴포넌트 사이의 메시징 라우팅을 담당한다. Service 제공자와 소비자간의 decoupling이 중요 point.
추가적으로 message processing, monitoring을 위한 key제공.
MI architecture 에는 크게 아래의 방향으로 이루어진다.

BC(Binding component) --> Adapter의 한 형식으로 외부 프로토콜을 접속을 해야 한다.
(HTTP, JMS, File 형식 지원)
DC(Delivery channel) --> BC 에서 DC로 message를 전달하고 받기 위해서는 DC로 request, response 한다.

NMR (Normal messaging router) --> DC에서 받은 message가 MI component를 올바르게 돌아다니게 하는것이 NMR이 하는 임무.
BC나 SE에서 직접 NMR로 붙지 않고, DC가 붙는다.
즉. request (External Component --> BC --> DC --> NMR --> DC --> SE)
      response (SE --> DC --> NMR --> DC --> BC --> External Component)
SE 에서 SE 전송 또한 마찬가지이다. (SE1 --> DC --> NMR --> DC --> SE2)

SE(Service Engine) --> Service Engine으로 (XSLT, BPEL, Rule service)를 제공하는 SE가 존재 한다.

* Service life cycle.

Deployment는 자원관리로서 각 unit은 아래와 같은 프로세스를 진행하게 된다.
empty --> depoly --> (shutdown) --> init --> (stopped) --> start --> (started)
              <-- undeploy <--        <-- shutdown <--         <-- stop

Endpoint  란?

End point는 메시지를 주고 받는 개념을 나타낸다.
하나의 서비스는 여러개의 endpoint를 노출시킬 수 있다.
endpoint는 Address, Binding, Contract 3가지로 구분할 수 있다.
Address 예를 들면. http://localhost:8080/services/

Binding은 메시지를 주고받는 방법에 대한 정의
Transport, Encorder, Security, Reliability, Protocol


contract 는 2가지로 나뉘며.
Service Contract
- interface와 interface를 상속받는 class로 구성
- interface에 Service Contract를 계약함
- 멤버는 Operation Contract를 계약해야 함.

Data Contract는 프로그램간의 상호작용이 어떻게 일어나는지에 대해 공식적인 선언.

Message Exchange Pattern.

JBI 모델 서비스는 WSDL 2.0 이용해 component들에 의해 작성되거나 사용되어 지는데, WDSL 서비스는 description은 항상 아래의 정의를 갖는다.

Message Type : XML 스키마
Operations:
- operation name
- Message Exchange - 소비자와 제공간의 순서나 방향같은 것을 나타낸다.
- Message Types

2009년 10월 6일 화요일

Agile CI build process

이전에 문서로 정리한것을 blog에.


개발 프로세스 통합 build 환경.
1. Intro.

Project 관리를 효율적으로 하기 위하여 통합 build 환경을 구성하려고 한다. Build 환경은 web 환경에서 클릭 한번으로 build flow(SVN sync ? source build(source , test code) ? junit test ? 배포)를 가능하게 한다. Build 환경 구성의 목적은 “가장 적은 비용으로 최소한의 버그와 최적화된 application 생성 및 유지보수” 를 위해서는 build 환경 구성은 필수적이다. 또한 개발 IDE(eclipse, visual studio)에 independency 하다.


* 통합 build tool이 없는 경우 진행 사항.
1. Source code를 svn으로 submit.
2. Svn sync 받은 후 compile, error 경우 어느부분인지 console 또는 개발 IDE 또는 console에서 확인.
3. Compile한 후 필요한 파일 package.
4. 추출한 파일들 해당 server에 수작업으로 deploy.
위와 같은 방법을 build 할 때마다 매번 반복해야 함.

* 통합 build tool이 있는 경우 진행 사항.

1. 개발자들이 svn으로 submit.
2. 통합환경 CI에서 button 클릭.
3. 자동으로 (sync -> compile -> unit test -> package ->?deploy)후 결과 email로 통보







2. Development tools environments

1) CI 도구
CCNET : CI 로 build web application을 제공한다. 중요한 점은 svn sync 및 email alert, build (force , scheduler)를 할 수 있다. ( IIS- .net framework 2.0~ )

2) Build System
maven : Ant와 비슷한 build tool이지만 Maven은 프로젝트의 종속(dependency)관계, 개발자/소유자, 버전 별로 관리할 수 있다는 측면에서 Project Management 측면이 강화되었다고 할 수 있다. 또한 Document, Reporting 제공하고 중요한 ant의 build script를 통합할 수 있다.

3) Test Framework
JUnit : java source 코드를 위한 test code. 해당 class의 method는 TDD로 작성이 필요하며, source code와 test code는 one by one 이면 좋다. Bug가 있을 source code를 집중적으로 TDD 할 필요가 있다.

4) Source code 관리
TortoiseSVN-1.6.2 : svn client

3. CCNET 구성도

Button 한번 click으로 다음 단계를 진행시킴.

1. source sync (CVS, SVN)
2. build (ant, msbuild, maven)
3. unit test (Junit, Nunit)
4. source upload (target server)
5. Email alert
6. Build schedule trigger

4. Maven build tool과 continuum

Maven을 기반으로한 라이브러리 관리 방식은 Maven Repository에서 라이브러리를 관리하고 이를 Local Repository에 download하는 방식이다.

CCNET 과 비슷한 CI tools 로서, Maven build tool의 Repository 관리 , Maven project를 관리 할 수 있는 tool이다. 그러나 중요한 점은 해당 project의 source compile, test, mail alert, 등 통합 빌드 환경을 구성하는 것은 CCNET과는 비슷하다.

5. build process tools을 정리.

* Java language 아닐 경우.

tools
dependency
소스코드 관리
SVN
tools

Build 스크립트 or Tools
MSbuild , etc.
dependency
CI tool
CCNET
IIS, .net framework
Test framework
NUnit, NUintTest++

프로젝트 관리
Gforge


* Java language이고 Build script Ant 사용시.

tools
dependency
소스코드 관리
SVN
tools

Build 스크립트 or Tools
ANT
dependency
CI tool
CCNET
IIS, .net framework
Test framework
NUnit

프로젝트 관리
Gforge


* Java language이고 Build script Maven 사용시.

tools
dependency
소스코드 관리
SVN
tools
Build 스크립트 or Tools
MAVEN
JRE
CI tool
CONTINUUM
JRE
Test framework
JUnit

프로젝트 관리
Gforge

2009년 10월 5일 월요일

Maven 실행

Maven 실행 및 설치에 관련된 내용입니다. repository(dependency library) 관리체계로 ant보다 훨씬 강력합니다.

Maven 환경.


1. 설치

1) http://maven.apache.org 에서 Maven 최신 설치.
2) 압축푼 후 시스템 환경변수 PATH에 Maven_home/bin 추가.

Prompt에서 "mvn -version"을 실행하여 Maven이 정상적으로 설치되었는지 확인할 수 있다



2. Maven에서 Java Project 생성

1) Maven은 각 프로젝트의 성격에 맞도록 Template 프로젝트를 제공하고 있다

2) Maven의 이 같은 기능을 Archetype이라고 한다.

3) Application project 일 경우

mvn archetype:create -DgroupId=net.javajigi -DartifactId=mysample

Web application 일 경우

mvn archetype:create -DgroupId=net.javajigi -DartifactId=mywebapp -DarchetypeArtifactId=maven-archetype-webapp



3. Maven 실행 방법

1) Source Compile

 디폴트로 생성된 하위 디렉토리로 이동한다음. 명령어 실행
  mvn compile

2) Test source compile
    mvn test-compile

3) 구현한 테스트 코드 실행.
     mvn test

4) Compile한 구현 코드를 jar, war로 압축하는 명령어 실행
    mvn package

5) Local repository에 등록
    mvn install

6) Remote repository에 등록
    mvn deploy


4. Maven의 dependency

1) Maven 이 위와 같이 Dependency 라이브러리를 관리할 수 있는 이유는 Maven이 모든 오픈 소스 라이브러리에 대하여 중앙 Repository를 가지고 있기 때문이다.
C:\Documents and Settings\Administrator\.m2\repository

Maven dependency 문제.

pom.xml 설정에서 종속성 있는 library를 다운로드 받아 빌드를 하게 된다.
무료 오픈소스 인경우는 문제없이 자동 다운로드를 받게 되나, 상용 library 경우 자동으로 repository에 다운로드 받지 못하며, 빌드에 실패 하게 된다.
예를 들어)



이 경우 jms에서 문제가 발생하게 되어 빌드 fail이 발생한다. 이와 같은 경우는 다음과 같이 설정을 하면 된다. 즉) 직접 해당 library를 install 해 주는 방법이다.

mvn install:install-file -DgroupId=javax.jms -DartifactId=jms -Dversion=1.1 -Dpackaging=jar -Dfile=/pathto/

-Dfile에 실제 존재하는 파일명을 넣고 command를 실행하면, repository에 해당 파일이 설치 되는 것을 볼 수 있다.

2009년 10월 3일 토요일

[청소년 월드컵] 한국 대 미국 동영상

아. 정말 멋지게 싸웠네요.ㅋ
3대 0 대승으로 조 2위 진출..
파라과이하고 16강 붙습니다.~ㅋㅋ

[청소년 월드컵] 한국 대 미국 클릭 (출처 - Utube)

2009년 10월 2일 금요일

청소년 월드컵 경기일정

아.. 이번 미국전은 반드시 이겨 16강 진출 했으면..
5년전인가. 본선에서 미국과 2대2로 비겨 16강 동반 진출 했지만.
이번에는 무조건 이기야지 16간다고 합니다. 이제 3시간 뒤면 시작하네요.
한국이 3대 1로 이길것 같다는 예감이.ㅋㅋㅋ 대한민국 화이팅.
참 sbs에서 방송합니다~

경기 일정

2009년 9월 27일 (일), 오전 1시 45분 한국 vs 카메룬 0:2 패

2009년 9월 29일 (화), 오후 11시 한국 vs 독일 1:1 무

2009년 10월 3일 (토), 오전 1시 45분 한국 vs 미국

2009년 10월 1일 목요일

TDD 동영상

LineReader 실습으로 김창준씨와 강규영씨가 직접 작업한 동영상 입니다.

http://xper.org/LineReaderTdd/

환경
Develop tool --> eclipse
Language --> Java
TDD tool --> junit

[천추태후] 금나라 시조

내가 좋아하고 즐겨보던 천추태후가 지난주 막을 내렸다.

사실 역사 왜곡이라는 이야기도 많았지만, 어느정도는 사실에 기반하여 재미를 주기 위해 각색했다고 생각 한다.

가장 흥미로운 것중 하나가 천추태후에서도 금나라의 시조에 대해 언급을 하는 부분이 있다.


그래서 한번 범위를 좁혀가며 찾아보기로 했다..
첫째, 신라 사람이 금나라의 시조인가? 아니라면 고구려 및 백제의 후손은?
둘째, (신라, 고구려 및 백제) 사람이라면 누가? (천추태후에선 마의태자 후손?)

이전 영화를 기억하는가?

<마지막 황제>라는 중국 영화를 보면 다음과 같은 장면이 나온다. 재판장에서 판사가 한 젊은이에게 묻는다.

"너의 이름이 무엇이냐?"
젊은이는 대답한다.
"아이신지료 푸이(愛新覺羅 傅儀)."
판사가 고개를 갸우뚱하며 말한다.
"참 이상한 성이구나."
바로 청나라 마지막 황제 부의가 모택동에게 재판을 받는 장면이다
[출처 : <천추태후>  오마이뉴스]

 여기서 아인신지료를 한자로 읽는 다면 '애신각라'  신라를 사랑하고 기억하라 는 뜻이다.
일설에 따르면, 마의태자는 항복에 반대하였고 그의 후손이 여진으로 금나라를 세웠다고 한다. '금' 이라는 이름 또한 '김'씨에서 연관된것 이고, 금을 계승한 청나라 역시 신라를 조상으로 생각했다고 한다.

또한 임진왜란 때 청나라에선 조선을 돕겠다고 했으나, 친명배금 정책을 폈던 조선은 그 요청을 받아들이지 않았다는 얘기도 있다.
여러 정황이나 기록을 미루어 보았을 때 마의태자에 대한 또 다른 학설은 어느 정도 신빙성을 가지고 있고 <천추태후> 제작진에서도 이를 드라마의 내용으로 활용했다고 생각한다.
재미와 즐거움을 주는 부분도 작가의 몫이라고 생각한다.