한국스프링사용자모임 KSUG

Apache Ftp Server + Spring

benelog — Fri, 17 Apr 2009 08:12:21 +0900

Apache FTP 서버(http://mina.apache.org/ftpserver/ )는 Java기반의 오픈소스 FTP서버입니다.

Java기반의 모듈이라고 하면 성능이 안 나오지 않을까 걱정하시는 분도 계실 것 같습니다. 이전에 1.0.M3버전으로 제 PC에서 다른 FTP서버와 비교해서 테스트해본 결과는 아래와 같았습니다.

테스트 환경
- OS : Windows XP
- CPU : Intel® Core™ 2 Duo CPU E6750, 2.66GHz
- RAM : 2GB
업로드 테스트 데이터
- 용량 : 126MB
- 파일수 : 392개
- 폴더 : 16개

테스트 결과로 윈도우에서 돌아가는 다른 FTP서버와 비교했을 때 가장 빠른 속도를 보여주는 예상밖의 성능이 나왔었습니다. Linux등에서는 어떤지 몰라도 크게 성능을 걱정할 수준은 아닐 것으로 예상됩니다.

Apache Ftp서버는 설정만으로도 FTP에 부가적인 기능을 많이 사용할 수 있습니다. 예를 들면 Log4j의 설정을 이용해서 원하는 수준과 방식으로 로그를 기록할 수 있고, 사용자정보를 입력,조회 등의 쿼리만 설정 파일에 넣어주면 DB로 사용자를 관리할 수 있게도 해줍니다.

그리고 Java기반이다 보니, 직접 코딩을 해서 확장을 하는 것도 손쉽습니다. Apache FTP 서버에서 정의한 인터페이스대로 코딩을 하고 이를 설정파일에다 추가할 수도 있죠. 대표적으로 Ftplet과 같은 인터페이스가 있습니다.

활 용사례로, Hadoop의 파일시스템인 HDFS(Hadoop Distributed File System)으로 파일을 올릴 수 있는 서버모듈도 이 Apache Ftp 서버를 이용해서 구현한 사례가 있습니다. FTP client프로그램으로 붙어서 직접 HDFS로 파일을 올리거나, 다른 프로그램에서 ftp프로토콜을 이용해 HDFS에 접근할 수 있는 것이죠.^[각주:1]

흥미로운 점은, 이 FTP서버에서는 스프링 방식의 설정을 지원한다는 것입니다. 예를 들면, 데이터베이스로 사용자를 관리할때, 익숙한 bean태그를 이용해서 datasource의 선언을 할 수 있습니다.

<db-user-manager encrypt-passwords = "clear">
       <data-source>
         <beans:bean class="org.apache.commons.dbcp.BasicDataSource">
                <beans:property name="driverClassName" value="${jdbc.driverClassName}" />
                <beans:property name="url" value="${jdbc.url}" />
                <beans:property name="username" value="${jdbc.username}" />
                <beans:property name="password" value="${jdbc.password}" />
                <beans:property name="initialSize" value="${dbpool.initialSize}" />
            </beans:bean>
        </data-source>

.....

더욱 재미있게도, 배포된 소스 ^[각주:2]중 examples폴더를 보면, Spring DM을 이용해서 OSGI번들로 apache FTP서버를 활용하는 예제가 나옵니다. META-INF/spring/bundle-context.xml의 파일을 보면 아래와 같이 선언되어 있습니다.

<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:osgi="http://www.springframework.org/schema/osgi"
    xmlns:ftp="http://mina.apache.org/ftpserver/spring/v1"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
       http://www.springframework.org/schema/beans/spring-beans.xsd
       http://www.springframework.org/schema/osgi
       http://www.springframework.org/schema/osgi/spring-osgi.xsd
       http://mina.apache.org/ftpserver/spring/v1
       http://mina.apache.org/ftpserver/ftpserver-1.0.xsd ">
    <ftp:server id="server">
        <ftp:listeners>
            <ftp:nio-listener name="default" port="2222" />
        </ftp:listeners>
        <ftp:ftplets>
            <ftp:ftplet name="ftplet1">
                <ref bean="ftplet" />
            </ftp:ftplet>
        </ftp:ftplets>
        <ftp:file-user-manager
            url="org/apache/ftpserver/example/osgiservice/users.properties" />
    </ftp:server>
    <osgi:service interface="org.apache.ftpserver.FtpServer"   ref="server">
    </osgi:service>
    <osgi:reference id="ftplet" interface="org.apache.ftpserver.ftplet.Ftplet" />     <bean class="org.apache.ftpserver.example.osgiservice.impl.FtpServerLifecycle"
       init-method="init" destroy-method="destroy"    >
       <property name="server" ref="server" />
    </bean>

</beans>

FTP 서버 역할을 하면서 확장된 기능이 필요하고, 모듈을 재배포하는 도중에도 멈추지 않아야하는 서비스를 만들어야 할 때가 생긴다면, Apache Ftp Server + Spring DM의 조합을 사용해서 편하게 구현을 할 수 있을 것으로 보입니다.

HDFS로 접근하는 FTP서버에 대한 자료
- HDFS over FTP
- hadoop을 이용한 ftp server
[본문으로]
http://mina.apache.org/ftpserver/apache-ftpserver-100-release.html에 서 다운 받을 수 있습니다. [본문으로]

[Spring batch]차세대 배치시스템 구축 성공전략 - JCO컨퍼런스

benelog — Tue, 14 Apr 2009 08:54:40 +0900

2009.04.30 수정이력 :
해당 프로젝트 사이트에 대해서 잘 못 전달될 수 있는 내용이 글에 포함되어서, 해당 부분은 삭제했습니다. 해당 사이트의 극히 일부 개발자의 단순한 언급, 그것도 농담일 수도 있는 내용이 다수의 반응처럼 오해될 수 있는 부분이 있었고, 공식 발표 내용에는 포함되지 않은 내용도 있어서 본의아니게 발표자나 관련 사업자분들께 누를 끼쳐드린 것 같습니다. 비록 익명으로 된 해당사례가 올라와 있지만, 제가 보다 신중을 기하지 못하여 마음을 상하신 분들이 있다면 사과드립니다. 그리고 글 후반후에 제가 다른 발표에서 받은 질문과 일반적인 내용에 대해서 덧붙여서 언급한 내용이 있는데, 해당 사이트 사례와 전혀 관계가 없지만, 글을 빨리 읽으시는 분들께는 연결해서 생각할 수 있는 오해의 여지가 있을 것 같아서 그 부분도 삭제했습니다. 이 포스트에 포함된 내용으로 사실과 다르게 사례가 전달된다면 전적으로 제 잘못입니다.
이 포스트를 포함하여 글의 내용에 대한 문의와 정정요청은 benelog[at]gmail[dot]com으로 해주시면 업무시간 외의 시간에는 최대한 빨리 답변드리겠습니다.

발표자료 : http://www.jco.or.kr/conference/data/10th/Tiger-3.zip

물개선생님 김승권님이 2009년 JCO 컨퍼런스에서 발표하신, 국내 대형 보험사에 Spring batch 기반으로 배치프레임웍을 적용한 사례입니다. 해당 보험사는 처리 자료 건수가 1억건 단위에 운영인력 50명, 800여건 작업을 돌리는 큰 규모의 배치 시스템을 가지고 있다고 합니다.

그 프로젝트에서는 개발자들이 더 쉽게 프레임웍을 적용하기 위해서 Job의 유형별로 설정을 간편하게 만들 수 있는 FactoryBean을 제공했다고 합니다. 그렇게 Job유형별로 설정이 정리되니, Spring의 설정파일을 읽어서 배치Job에 대한 정리된 정보와 통계까지 볼 수 있는 관리화면도 제공할 수 있게되는, 처음에는 생각하지 않았던 장점도 생겼다고 하네요. 저도 프로젝트에서는 같은 유형의 Job의 설정에는 중복코드가 없게 하기 위해서 유형에 따른 FactoryBean을 만들고 bean 설정에서 parent 속성을 이용했었는데, 그런 시도는 스프링배치를 실무에 적용할 때 프로젝트의 특수성을 반영하면서도 간편한 코드를 만들기 위한 필수적인 절차라고 생각되었었습니다.

그리고, 중간의 Wrapping 계층을 두어서 최종 개발자들의 요구사항을 반영할 수 있는 확장점을 만들고, Spring batch의 API변화에 대처할 수 있도록 했다고 합니다. 재미있게도, 이 구조가 ItemProcessor 등 Spring batch 2.0구조와 상당히 비슷해서 프로젝트 내부의 정보가 스프링 쪽에 세어나간 것이 아닌가 하는 농담도 나왔었다고 합니다. ^[각주:1]

http://static.springsource.org/spring-batch/migration/2.0-highlights.html

http://forum.ksug.org/viewtopic.php?f=6&t=468

Spring Batch 1.0에서 2.0으로 진화하기- 1. ItemReader/ItemWriter(1)

Spring Batch 1.0에서 2.0으로 진화하기- 1. ItemReader/ItemWriter(2)

Spring Batch 1.0에서 2.0으로 진화하기- 3. JobExecutionLisneter & 4. ItemProcessor

Spring Batch 1.0에서 2.0으로 진화하기- 5. Configuration

그 외에도 기술 지원을 위한 프레임웍 운영팀의 역할이 커졌던 점과 프레임웍 적응을 위한 학습기간이 필요했던 점, 개발계보다 훨씬 많은 건 수의 데이터가 Skip이 일어날 수 있는 운영계의 데이터 특성이 개발계에서 모두 반영되지 못해서 나중에 대처를 했었던 사례 등을 들을 수 있었습니다.

- 정상혁 (http://benelog.egloos.com)

' [본문으로]

Blaze DS or LiveCycle Data Services

영회 — Tue, 17 Feb 2009 08:45:45 +0900

명확한 비교표를 제시하는군요. 비용과 기술 지원 조합에 따라 네 가지 선택사항이 있습니다. NIO 은 LiveCycle DS라도 Community Edition에서는 지원하지 않는군요. 더 자세한 내용은 원문(Blaze Data Services or LiveCycle Data Services?)을 보세요.

제10회 한국자바개발자 컨퍼런스

영회 — Mon, 09 Feb 2009 13:47:18 +0900

JCO 홈페이지를 방문하시면 보다 자세한 컨퍼런스 정보를 확인하실 수 있습니다.
* 홈페이지 URL: http://www.jco.or.kr/

[Spring batch]배치 어플리케이션 실행 스크립트와 빌드

benelog — Mon, 02 Feb 2009 08:09:21 +0900

스프링배치를 처음 접할 때는 만들어진 Job을 어떻게 빌드하고, 실행시킬지가 감이 잘 잡히지 않을 수도 있습니다. Qurtz를 이용한 스케쥴링을 하고 Web Application Server안에서 실행시킨다면 다른 Web application과 같이 배포시킬 수도 있을 것입니다. 그래도 스프링배치 연재(10) JobLauncher와 Job, Step에 서 소개한 것처럼 CommandLineJobRunner 를 사용하여 직접 console에서 실행시키는 것이 가장 기본적인 실행법이라고 생각됩니다. 그리고 스케쥴링도 하루에 4~5번 정도 실행되는 정도의 작업이라면, 초기 클래스 로딩시간에 대한 큰 부담이 없으므로 Cron을 배치잡을 실행하는 스크립트를 호출하는 것이 더 간편하기도 합니다. 이처럼 command line에서 바로 배치잡을 실행시킬 때, Job이 참조하는 jar파일들을 같이 묶고, 실행할 때 그 jar들을 classpath에 지정하는 스크립트를 만드는 과정을 정리해 봅니다.

먼저 배치Job을 실행시킬 수 있는 스크립트를 만들어 봅니다. -classpath 지정을 특정 디렉토리 아래에 있는 *.jar파일을 다 포함시키도록 만드는 것이 편리합니다. Tomcat 같은 java application을 실행시키는 쉘스크립트를 보면, 이런 부분이 다 유사하게 들어가 있습니다.

다음은 Windows 계열에서 실행시킬 수 있는 runJob.bat파일의 예제입니다. JAVA_HOME 환경변수에 실행하고자 하는 JAVA버전이 있는 디렉토리가 지정되어 있어야 합니다. 스크립트가 있는 곳 아래 /lib 폴더 아래에 job에서 참조하는 jar파일이 있는 것으로 설정했습니다.

@echo off
set JAVA_CMD=%JAVA_HOME%\bin\java
set MAIN_CLASS=org.springframework.batch.core.launch.support.CommandLineJobRunner
set CLASSPATH=.
FOR %%F IN (*.jar) DO call :addcp %%F

FOR %%F IN (lib\*.jar) DO call :addcp %%F
goto extlibe

:addcp
set CLASSPATH=%CLASSPATH%;%1
goto :eof

:extlibe

"%JAVA_CMD%" -Xmx512M -cp "%CLASSPATH%" %MAIN_CLASS% %*

이 파일을 이용해서 특정 Job을 실행시키는 스크립트를 따로 만들 수 있습니다.

cd /D D:\workspace\imaso-batch\deploy
runJob.bat applicationContext.xml teamDbToXmlJob %*

CommandLineJobRunner의 형식과 마찬가지로 runJob.bat [설정파일명] [Job의 bean id] [파라미터1] [파라미터2]... 의 형식입니다. 설정파일에는 해당하는 Job에 대한 설정과 공통적인 JobLauncher, Database에 대한 설정 등 Job에서 필요한 모든 설정이 다 포함되어야 합니다. 공통적인 부분과 특정 Job에만 필요한 것을 잘 분리해서 include 등을 이용해서 applicationContext 파일을 구성하는 것이 여러 Job을 관리할 때 효율적인 것입니다.

다음은 리룩스나 유닉스에서 실행되는 runJob.sh 쉘스크립트의 예제입니다. run.bat와 마찬가지로 실행위치/lib에 참조하는 라이브러리의 jar파일이 했지만, imaso-batch.jar라는 파일하나는 실행위치 디렉토리에 있는 것을 따로 지정하도록 했습니다.

#!/bin/sh
BASEDIR=`dirname $0`
cd $BASEDIR

CLASSPATH=$BASEDIR
CLASSPATH=$CLASSPATH:$BASEDIR/imaso-batch.jar

for f in `find $BASEDIR/lib -type f -name "*.jar"`
do
CLASSPATH=$CLASSPATH:$f
done

JAVA_BIN=$JAVA_HOME/bin/java
OPT="-cp $CLASSPATH -Xmx512M"

echo $JAVA_BIN
$JAVA_BIN $OPT org.springframework.batch.core.launch.support.CommandLineJobRunner

runJob.sh를 이용해서 특정 Job을 실행시키는 스크립트를 다음과 같이 만듭니다.

#!/bin/sh
BASEDIR=`dirname $0`
cd $BASEDIR
sh runJob.sh applicationContext.xml teamDbToXmlJob "${1+$@}"

이제 이런 스크립트와 jar파일들을 같이 배포할 수 있도록 Maven에 설정을 추가합니다.

pom.xml에 배포시 필요한 jar파일들을 같이 복사할 수 있도록 <build/>절 밑에 다음과 같이 maven-dependency-plugin의 설정을 추가합니다. 예제에서는 ${basedir}/deploy/lib 폴더로 복사되게 했습니다.

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.0</version>
<executions>
<execution>
   <id>copy-dependencies</id>
    <phase>package</phase>
     <goals>
       <goal>copy-dependencies</goal>
      </goals>
      <configuration>
       <outputDirectory>${basedir}/deploy/lib</outputDirectory>
        <overWriteReleases>false</overWriteReleases>
        <overWriteSnapshots>false</overWriteSnapshots>
        <overWriteIfNewer>true</overWriteIfNewer>
      </configuration>
    </execution>
</executions>

</plugin>

그리고 Job의 구성을 위해 작성한 xml파일과 class파일들을 jar로 묶을 수 있도록 jar plugin을 설정합니다. ${basedir}/deploy로 복사하도록 했습니다.

<plugin>
<groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-jar-plugin</artifactId>
   <configuration>
    <outputDirectory>${basedir}/deploy</outputDirectory>
    </configuration>
</plugin>

마지막으로 처음에 작성한 스크립트 파일들이 ${basedir}/deploy로 복사되도록 resources-plugin 설정도 추가했습니다. 원래 Maven Super POM에서 스크립트들의 디렉토리가 src/main/scripts로 지정이 되어 있는데, 어떤 플러그인에서 기본적으로 참조되는 지는 파악이 잘 안 됩니다. (아시는 분은 알려주셨으면 합니다.)

<plugin>
<artifactId>maven-resources-plugin</artifactId>
   <version>2.3</version>
   <executions>
    <execution>
      <id>copy-resources</id>
       <phase>package</phase>
        <goals>
        <goal>copy-resources</goal>
        </goals>
      <configuration>
        <outputDirectory>${basedir}/deploy/</outputDirectory>
        <resources>
        <resource>
        <directory>src/main/scripts</directory>
       </resource>
       </resources>
       </configuration>
       </execution>
     </executions>
</plugin>

이렇게 설정한 후 mvn package를 실행하면 ${basedir}/deploy 아래에 스크립트, 참조라이브러리, 직접 작성한 application의 jar파일들이 같이 생성됩니다. 이 디렉토리를 개발팀에서 쓰고 있는 배포방식을 이용해서 서버로 복사하게 합니다. Hudson에서 제공하는 FTP업로드 기능 등도 이럴 때 활용할 수 있겠습니다.

배포된 서버에서 스케쥴링을 하고 싶다면 runJob.bat, runJob.sh나 이럴 이용한 스크립트를 crontab에 설정하면 됩니다. 실행되는 OS user나 JAVA_HOME 등의 환경변수값이 잘 넘어가는지 유의해야 합니다.

pom.xml파일이나 runJob.sh, runJob.sh의 스크립트는 imaso-batch.zip에 포함되어 있습니다.

- 정상혁, http://benelog.egloos.com

스프링배치 국내 자료 모음

benelog — Mon, 19 Jan 2009 07:12:33 +0900

Winter of Code 행사 공지

영회 — Tue, 13 Jan 2009 15:12:25 +0900

안녕하세요
Winter of Code 운영자 입니다.

Winter of Code란 학생-개발자간의 합작 프로젝트로 일정기간(1/31~3/18) 동안 프로젝트를 진행을 하면서 멘토와, 그리고 다른 참가자와 만나서 교류(네트워킹)하는 행사 입니다.

WoC 프로젝트 리스트 보기

특히 WoC 2008에서는, 참여, 공유, 개방이라는 키워드에 알맞게, 프로젝트를 진행하는 것 못지 않게, WoC 참가자들간의 교류를 지향 합니다.

Code your Network!!

이 캐치프레이즈는 개발을 꿈꾸는 예비개발자들의 실력향상에 못지않게, 같은 분야의 동료를 만나는 것의 중요성을 이야기 합니다.
WoC의 프로젝트기간이 끝난 이후에도, 직접 만들고 싶은 서비스나, 프로그램이 있을 때 WoC에서 함께 했던 동료들과 아이디어와 기술을 나누고, 함께 시도 할 수 있는 Network을 넓혀가는 행사로 만들어 가려고 합니다.

많은 참여 부탁 드립니다.

WoC에 참가를 하게 되면,, (WoC 혜택)

프로젝트 진행을 통한 Spec up!

프로젝트 진행 과정에서 발생하는 어려운 문제를 해결해가면서 얻는 기술은 학생 때에 할 수 있는 최고의 Spec Up 기회입니다.

멘토에게 듣는 개발 실무

개발실무자인 멘토의 조언을 통해 실무에서 다져진 프로젝트 진행 방법, 그리고 현재 기업에서 가장 필요로 하는 입사자의 능력 혹은 성격 등에 대한 진솔한 조언을 들을 수 있습니다.

개발에 관심 있는 친구, 동료를 만날 수 있는 곳 WoC

팀 프로젝트를 통해 인맥을 만들고, 훗날 취업, 서비스 개발의 길을 함께 할 수 있는 친구와 동료를 만날 수 있는 있습니다.

WoC 가이드 보기

참가방법

WoC 프로젝트 리스트
운영안

WoC에서는 이러한 분들의 참여를 기다리고 있습니다.

- 새로운 기술을 습득 하고 실력향상에 열정을 가진 분들
- 주변의 사람들과 함께 교류(네트워킹)하는 것을 즐기는 분들
- 다양한 분야를 다양한 시각으로 바라보는 것을 좋아하는 분들

수행계획서 신청기간 : 08. 12/20~ 09. 1/18 (24시)
프로젝트 신청기간 : 08. 12/20~ 09. 1/28 (13시)

<추가 참가 혜택>

1. 오프라인 강연

학생들에게 도움이 되는 다양한 오프라인 강연을 준비하고 있습니다.

기업 출신 멘토 강연 (예상주제: 기업개발문화, 기업에서 원하는 인재상, 팀 프로젝트 스킬 등)

학생 벤처 성공비결 (난~ 단순히 하고 싶은 프로젝트로 회사를 차렸을 뿐이고! 대박이 났고!)

개발자의 돋보이는 이력서

개발 서적 번역 스토리 (개발자들의 지적인일상)

2. 우수작 시상

우수작 한국 소프트웨어 진흥원장상 수여

최우수상 300만원 (1팀)

우수상 100만원 (2팀)

특별상 20만원씩 (5팀)

참고: WoC 우수작 선정은 멘토와 운영위원회 그리고 참여하는 학생들의 의견을 모아 결정됩니다. 특히 특별상은 WoC 우수작의 백미로 WoC 프로젝트를 진행하는 과정에 열심히 그리고 즐겁게 참여한 팀들에게 드리는 상입니다. Ex: 교류상, 공유상, 인기상

3. 프로젝트 보조금 40만원 지급

보조금은 개발 및 연구비용으로 사용처는 크게 오프라인 모임 식음료대와 프로젝트 진행용 도서구입비로 나누어 집니다. 자세한 보조금 사용 내역은 후에 멘토 및 학생프로젝트 팀리더에게 전달 예정입니다.

4. 사은품

- 취업 포탈 정보 교환권
- W 팩키지: 온?오프라인 행사 참가 시 따뜻한 무릎 담요와 멋진 모자티셔츠를 증정합니다.

5. 한빛 미디어 40% 할인혜택 (WoC 프로젝트 기간동안)

[Spring batch] 스프링배치 연재(16) DB to XML 파일 만들기 예제

benelog — Mon, 12 Jan 2009 08:12:25 +0900

드디어 마지막회입니다. DB테이블에서 부모-자식 구조의 데이터를 읽어와서 하나의 XML파일로 만드는 작업을 구성해 봤습니다. 코드의 단순함을 위해서 전형적인 N+1쿼리 문제점을 가지는 예제를 만들었는데, 공개해 놓고보니 무턱대고 이런 방식을 따라할 사람이 있을까봐 걱정이 되기도 합니다. 예제의 방식보다 더 나은 성능이 필요한 경우에는 DB에서 join할 키값을 기준으로 정렬해서 테이블별로 한번씩만 조회한 다음에 sort merge방식으로 부모-자식 테이블간의 짝을 맞춰주는 방법을 쓸 수도 있습니다. 하이버네이트를 활용할 수 있다면 batch size 속성을 지정하는 것이 도움이 될 수 있는 상황도 있을 것입니다. (http://chanwook.tistory.com/710 참조) 저는 프로젝트에서 활용할 때, 기대 성능을 충족시키는데 지장이 없었던 작은 건수의 처리는 그냥 N+1쿼리방식을 쓰고 많은 건수를 읽는 작업은 sort merge방식을 사용했습니다.
그리고 XStream으로 XML파일을 생성할 때 특별한 설정을 안 하면, 태그 명 중에 들어간 언더바 1개(_)가 언더바 2개(__)로 바뀌어버리는데, 처음 써보는 사람들이 공통적으로 겪을 수 있는 시행착오일 것입니다.

DB에서 2개 테이블을 엮어서 XML파일로 쓰기 예제

DB에서 부모-자식 간의 관계로 된 테이블을 읽어서 하나의 XML로 만드는 작업은 실무에서 흔하게 만날 수 있는 배치처리 사례이다. 다음의 예제에서는 팀 테이블(team)과 선수(player)테이블에 DB에 있다고 가정하고 이를 하나의 XML로 만드는 작업을 진행해보고자 한다. 팀 테이블과 선수테이블은 당연히 1대 다 관계로 이루어져 있다. 테이블을 생성하고 테스트로 몇 개의 데이터를 넣어주는 스크립트가 첨부파일(imaso-batch.zip)에 포함되어 있다. (src/main/resources/data 폴더)

먼저 부모 테이블인 팀 테이블을 읽어오는 ItemReader를 작성해 보자. JdbcCursorItemReader클래스를 이용해서 쿼리와 그 결과를 Team의 도메인 오브젝트로 매핑할 수 있는 mapper를 지정한다. (리스트12)

<bean id="teamMasterReader" class="org.springframework.batch.item.database.JdbcCursorItemReader">
<property name="dataSource" ref="dataSource" />
<property name="mapper">
<bean class="org.springframework.jdbc.core.BeanPropertyRowMapper" >
<property name="mappedClass" value="imaso.batch.domain.Team"/>
</bean>
</property>
<property name="sql">
<value> SELECT team_id, team_name, symbol, rank FROM team</value>
</property>
</bean>

리스트 12 : JDBC커서 방식으로 Team테이블 조회

간단한 코딩을 위해서 mapper에 BeanPropertyRowMapper를 사용하고 mappedClass속성을 team테이블의 내용을 담는 도메인 오브젝트인 Team클래스로 지정했다. Team 클래스는 team 테이블의 컬럼명이 그 멤버변수로 선언되고 있고, getter,setter를 가진 단순한 클래스이다. Java의 일반적인 명명규칙에 맞추어서 언더바(_)가 없이 camel casing으로 표기되어 있다. BeanPropertyRowMapper는 언더바와 camel casing간의 변환을 자동으로 해 주기 때문에 team_id의 컬럼도 setTeamId메소드를 통해서 값이 채워지게 된다. 만약 성능을 조금이라도 향상시키고 싶다면 다소의 추가 코딩을 하더라도 별도의 RowMapper를 구현해서 사용하기 바란다.

이제 team의 자식 테이블인 player를 읽을 차례다. 여러가지 방법이 있겠지만, DrvingQuery방식과 비슷하게 team 1건마다 그 팀에 소속하는 선수를 조회하는 쿼리를 던지는 방식을 사용해 보았다. 이를 위해 상위테이블만 읽어온 item object에서 그 자식 테이블을 읽어서 채워줄 수 있는 경우를 추상화하여 ItemWithChildrenReader라는 클래스를 작성해 보았다.

public abstract class ItemWithChildrenReader extends DelegatingItemReader{

public Object read() throws Exception {
Object item = super.read();
    if(item==null) return null;
      setChildren(item);
      return item;
   }
    protected abstract void setChildren(Object item);
   public ItemWithChildrenReader() {}

}

리스트 13: 부모-자식 테이블 조회기능을 추상화한 클래스

이를 상속한 클래스에서 setChildren메소드를 구현하여 자식 테이블을 읽어서 넣도록 설계된 것이다.
Team테이블에서 읽어온 값에서 Player테이블을 채워줄 수 있는 ItemReader는 리스트 14와 같이 구현하였다.

public class TeamReader extends ItemWithChildrenReader {
private RowMapper mapper;
private JdbcTemplate jdbcTemplate;
private String sql;
protected void setChildren(Object item) {
    Team team = (Team)item;
    Object[] params = new Object[]{team.getTeamId()};
    @SuppressWarnings("unchecked")
    List<Player> playerList = jdbcTemplate.query(sql, params, mapper);
    team.setPlayerList(playerList);
}
// private 멤버 객체에 대한 setter 생략
}

리스트 14ㅣ Player를 읽어서 Team에 넣어주는 클래스

setChild메소드 안에서 JdbcTemplate, RowMapper를 이용하여 player테이블의 건들을 읽어와서 team객체에 넣어준다. 만약 두 테이블을 연결시키는 키 속성명, 결과가 들어갈 속성명까지도 설정파일로 빼고 BeanUtils클래스의 setProperty, getProperty들을 활용한다면 보다 일반화시킨 클래스를 만들 수도 있다.
TeamReader의 설정에는 앞에서 나온 Team테이블을 읽어오는 TeamMasterRead를 itemReader속성으로 지정해 준다.

<bean id="teamReader" class="imaso.batch.item.TeamReader">
<property name="itemReader" ref="teamMasterReader" />
<property name="sql">
<value>
SELECT team_id, player_id ,player_name, main_position
FROM player WHERE team_id = ?
</value>
</property>

</bean>

리스트 15 : TEAM과 PLAYER를 같이 읽어오는 클래스의 설정

만약 위의 구현처럼 쿼리를 건마다 하나씩 던지고 싶지 않다면, 다소 구현이 복잡해 지더라도 team과 player 테이블 모두 team_id를 기준으로 정렬해서 조회한 후에 sorted merge 방식과 유사하게 양쪽 item들의 team_id값을 비교해 가면서 team에다 player를 붙여주는 구현도 가능하다.

그 다음은 읽어온 내용을 XML파일로 쓰는 기능은 StaxEventItemWriter와 XStream 라이브러리를 같이 사용해서 구성했다. XStream 라이브러리를 보다 잘 활용하기 위해서 반드시 프로젝트가 의존하고 있는spring-oxm을 최신버전인 1.5.4로 참조해서 쓰기 바란다. 스프링배치의 샘플 프로젝트에서는 1.0.0버전을 참조하고 있는데, 당연히 최신버전에 비해 기능이 많이 빠져있다. 그리고 앞으로 설명한 아노테이션을 이용한 태그명 설정을 사용하기 위해서는 spring-oxm-tiger 라이브러리도 포함시켜야 한다. 예제에서 사용한 Maven2의 pom.xml파일은 첨부파일 내에 포함되어 있다.
생성시킬 XML파일의 형태는 team태그 밑에 team 컬럼의 속성들이 들어가고 player테이블의 내용은 team 태그 밑에서 player태그로 여러 번 반복된다. (리스트 16)

<content>
<team> <team_id>1</team_id> <team_name>Lotte</team_name>
    <symbol>Giants</symbol><rank>1</rank>
    <player>
      <playerId>0</playerId> <player_name>이대호</player_name>
      <main_position>3루수</main_position>
    </player>
    <player>....</player> <player>....</player>
   <team>...</team>
   <team>...</team>
</content>

리스트 16 : 생성할 XML파일

앞의 teamReader에서 읽어온 내용을 쓰기 위한 StaxEventItemWriter을 리스트17과 같이 설정한다.

<bean id="teamXmlWriter" class="org.springframework.batch.item.xml.StaxEventItemWriter">
    <property name="resource" value="file:target/team.xml" />
    <property name="serializer" ref="teamSerializer" />
    <property name="rootTagName" value="content" />
    <property name="overwriteOutput" value="true" />
</bean>
<bean id="teamSerializer" class="org.springframework.batch.item.xml.oxm.MarshallingEventWriterSerializer">
    <constructor-arg ref="teamMarshaller"/>
</bean>

리스트 17 : StaxEventItemWriter의 설정

루트태그명을 rootTagName에서 content로 지정하고 xml을 생성하는데 필요한 요소들을 serializer속성-> MarshallingEventWriterSerializer 클래스-> teamMarshaller 빈으로 연결시켜 주는 것까지는 기본적인 사용법과 별차이가 없다.
여기서 도메인 오브젝트인 Team과 Player클래스에서 태그를 연결하기 위한 설정을 편하게 하기 위해서 아노테이션을 사용했다. AnnotationXStreamMarshaller를 사용하면 도메인 오브젝트 내에서 리스트18처럼 태그를 지정해 줄 수 있다.

public class Team {
@XStreamAlias("team_id") private int teamId;
@XStreamAlias("team_name") private String teamName;
private String symbol;
private int rank;
@XStreamImplicit private List<Player> playerList;

리스트 18 : 태그명을 어노테이션으로 지정

@XStreamAlias 어노테이션을 이용해서 멤버변수의 이름과 태그명이 다른 경우에는 태그명을 명시해 준다. playerList필드처럼 Collection이면서, 그 필드의 이름 자체는 태그로 옮기어 지지 않을 경우에는 @XStreamImplicit 어노테이션을 이용한다. 즉, 우리가 만들고자 하는 샘픔에서 playerList속성과 대응되는 부분이 <playerList><player/><player/></playerList> 의 형식처럼 player태그를 playList태그가 한번 감싸고 있는 것이 아니고 바로 <player/>가 반복되는 형태이기 때문에 @XStreamImplicit가 붙어야 하는 것이다. Player클래스에서는 team_id 멤버 변수는 아예 태그로 옮기어 지지 않으므로 @XStreamOmitField 어노테이션을 붙여서 이를 명시했다. XStream의 annotation에 대한 자세한 설명은 http://xstream.codehaus.org/annotations-tutorial.html페이지를 참고하기 바란다.
어노테이션을 사용하지 않는다면 AnnotationXStreamMarshaller의 상위클래스인 XStreamMarshaller 를 사용하고, implicitCollection, omittedFields의 속성에 Map의 형태로 생략할 필드들을 지정할 수 있다.
또 하나 주의할 점은 태그명에 언더바(_)가 들어가면 XStream에서는 디폴트로 그것을 언더바2개(__)로 바꾸어 준다는 점이다. 이 것은 XStream의 XmlFriendlyReplacer라는 클래스에서 하는 작업인데, 불행히도 현재의 AnnotationXStreamMarshaller클래스에서는 이 클래스를 바꿔치기 할 수 있는 기능이 없다. 그래서 AnnotationXStreamMarshaller를 상속하는 별도의 클래스를 만들고 XmlFriendlyReplacer를 끼워넣을 수 있도록 구현을 했다.

public class ExtendedXStreamMarshaller extends AnnotationXStreamMarshaller{
private XmlFriendlyReplacer replacer;
protected void marshalSaxHandlers(Object graph,
ContentHandler contentHandler, LexicalHandler lexicalHandler)
throws XmlMappingException {
SaxWriter saxWriter = new SaxWriter(replacer);
saxWriter.setContentHandler(contentHandler);
getXStream().marshal(graph, saxWriter);
}
//replacer에 대한 setter 생략
}

리스트 19 : XmlFriendlyReplacer 를 지정할 수 있는 확장 클래스

XmlFriendlyReplacer상속한 DummyReplacer를 만들고 여기서는 언더바를 더블언더바로 바꾸는 동작을 수행하지 않도록 만든 후 이를 setter로 설정했다.

<bean id="teamMarshaller" class="imaso.batch.item.support.ExtendedXStreamMarshaller">
<property name="annotatedClasses">
<list><value>imaso.batch.domain.Team</value>
         <value>imaso.batch.domain.Player</value>
   </list>
</property>
<property name="replacer">
<bean class="imaso.batch.item.support.DummyReplacer"/>
   </property>
</bean>

리스트 20 : Marshaller설정

annotatedClasses속성으로 Team과 Player클래스를 지정해서 어노테이션을 XStream에서 인식할 수 있도록 해준다.
StaxEventItemReader에는 이 밖에도 다양한 형태의 Xml 생성을 돕는 속성들이 있다. Root태그 밑에 여러 속성들이 있다면 rootElementAttributes 속성에 Map형식으로 이를 지정할 수 있다. 예들 들어 “<content id=”baseball”>”으로 XMl이 시작한다면 id가 key이고 baseball이 value인 Map을 지정해 주면 된다. 그리고 headerItems속성으로는 루트 태그 아래에 추가로 들어갈 다른 태그들을 넣을 수 있다. 이와 함께 XStream에서 제공하는 Converter인터페이스를 구현하고 XStreamMarshaller 의 converters 속성으로 그것을 등록해 주면, 객체가 태그로 바뀌는 형식을 보다 정교하게 구현할 수도 있다. 자세한 내용은 첨부파일에 있는 예제를 참고하기 바란다.

ItemReader와 ItemWriter를 연결시키는 Step과 Job의 설정을 하면 모든 작업은 끝이 난다. 주의할 점은 SimpleStepFactoryBean에서는 ItemReader가 Writer가 바로 동시에 ItemStream이라면 자동으로 stream속성에 등록이 되는데, 다른 ItemStream객체가 있다면 따로 지정을 해 주어야 한다는 것이다. DelegatingItemReader안에 감싸져서 들어가는 itemReader와 같이, Step에 직접 등록되는 ItemReader가 아닌 경우도 여기에 해당한다. 리스트12와 15에서 보이듯이, teamMasterReader도 teamReader에 감싸져 있는 클래스인데, itemStream인 JdbcCursorItemReader클래스이므로, Step설정에서 streams에 지정되어 있어야지 open,update,close와 같은 메소드들이 제대로 호출될 수 있다.

<bean id="teamDbToXmlStep" parent="simpleStep">
  <property name="itemReader" ref="teamReader"/>
  <property name="itemWriter" ref="teamXmlWriter"/>
  <property name="streams" ref="teamMasterReader"/>
</bean>

리스트21: Step의 설정

첨부파일

imaso-batch.zip

-정상혁, http://benelog.egloos.com

[Beta 1.0] Spring Web-Flow 프레임웍 레퍼런스 한글화(편역).

찬욱 — Mon, 05 Jan 2009 13:50:28 +0900

Spring Web-Flow 레퍼런스 편역 본입니다. 2.0.5 버전 기준입니다.

SWF 2.x에서는 EL과 플로우 정의 언어도 더 풍부해졌고, 통합, 특히 MVC와 통합도 훨씬 깔끔하게 통합 할 수 있는 것을 볼 수 있습니다. 이제 MVC와 좀더 유기적으로 맞물려서 사용할 수 있게 됐습니다. 스프링 자바스크립트는 좀더 살펴봐야겠습니다. 그래도 기본 구조는 1.x와 거의 동일하기 때문에 1.x를 학습하셨다면, 쉽게 2.x를 보실 수 있을 것 같습니다.

본 문서는 1, 8, 12, 13, 15을 제외한 전 장을 포함하고 있습니다. 빠진 내용들이 핵심적인 내용은 아니니 중요한 내용은 충분히 학습하실 수 있습니다.

감사합니다.

spring-webflow-reference-kr-beta-1.0.pdf

올해의 스프링 기술 top5, 내년 유망 스프링 기술 top5 (박찬욱 편)

영회 — Fri, 02 Jan 2009 09:00:00 +0900

안녕하세요. KSUG 박찬욱입니다. 저도 올 해와 내년 유망주를 나누기가 어려워 하나의 목록으로 작성했습니다. 올 해 관심사들이 내년에는 실제 적용 가능환 수준으로 심화되는 과정이라고 볼 수 있을 것 같습니다.

1. Spring Web Flow(SWF)
개인적으로 SWF를 살펴 봤던 시점이 작년의 1.x였는데 어느덧 2.x가 공개가 됐습니다. 작년 1.x일 때 로드 존슨이 SWF는 앞으로 SpringSource의 주력이 될 것이라는 말을 했었는데요, 역시나 그 말처럼 지금 SWF의 위상은 상당히 높아졌습니다.

1.x가 위자드 형식의 흐름(flow)를 갖는 conversation 구현에 집중 됐다면, 2.x부터는 Spring MVC, JavaScript, Faces 등 다른 모듈과의 통합을 기반으로 한 Client와의 통합 프레임웍으로 발전하고 있습니다. 특히 spring mvc와 java script와의 통합 강화로 이제 Spring MVC와 유기적으로 협력해서 적용할 수 있게 됐습니다.

특히 Spring-js는 서버 단 프로그래밍 모델 제시가 주를 이웠던 과거에 비해 클라이언트 단의 프로그래밍 모델까지 제시하는 좋은 기회가 될 것으로 보입니다. 사실 Controller+form tag로는 부족했었죠^^. 다양한 Ajax 프레임웍들과의 통합이 지원되고, 사용사례 등이 공유되기 시작하면 Spring-mvc 도입 시 자연스레 Spring-js로 클라이언트 단 로직을 처리(역할이 어느 정도까지 갈지는 모르겠습니다. 현재는 Dojo toolkit 기반 Ajax 요청 처리와 유효성 검증 등이 제공 됩니다.)하고, 여기에 더해서 SWF로 conversation 구현과 flow 제어를 구현하게 될 수 있겠죠. 3.0에서는 Spring-js가 core로 넘어 온다니 역시 다음 한 해에도 기대를 갖고 지켜볼만한 것 같습니다.

2. Spring core 발전
올해 공개된 Spring 2.5에서는 애노테이션 기반 설정이 보다 심하되고, 강화됐습니다. 설정의 단순화만을 강조하는 것이 아니라, @MVC 처럼 프로그래밍 모델 자체를 개선해주는 효과를 얻고 있습니다. '설정'이라는 말이 주는 부담과는 달리, 애노테이션을 사용해서 최소한의 설정으로 최대의 효과를 얻을 수 있는 모델을 제시하고 있습니다. 단지 설정 기법이 XML에서 애노테이션 기반으로 변경된 것이 아니라, 메타 정보를 활용한 새로운 프로그래맹 모델을 제시하는 기회로 활용하고 있는 것이죠.

이번 Spring One America에서도 밝혀 졌듯이 3.0에서는 많은 내용이 개선될 것 같습니다. REST지원, EL 지원 등 3.0에서 도입되거나 개선된 다양한 특징에 대해서는 이미 다녀오신 분들의 글을 참조하시면 될 것 같습니다.

여기서 제가 주목하는 점은 Spring 3.0 도입에 대한 Spring 포트폴리오들의 의지입니다. 아직 3.0 정식버전이 나오지도 않았지만, 포트폴리오의 주요 프로젝트에 해당 하는 프로젝트들(SWF, Spring Security, Spring batch 등)이 이미 3.0에 맞는 기능을 소개하거나 조만간 공개되는 버전에 바로 적용하는 모습을 보여주고 있습니다. 발빠른 행보를 보이고 있으니 3.0은 보다 빠르게 현장 도입 수준에 오르지 않을까 생각됩니다^^.

3. Spring batch
Spring의 다른 프로젝트들도 마찬가지지만, Spring batch는 특히 현장의 경험을 추상화해 이를 기반으로 프레임웍을 구성했다는 점이 가장 인상적입니다. 특히, Job, Step과 배치 실행과 관리에 대한 추상화된 개념을 통해서 처음 배치 업무 구성에 접하는 사람도 개념적인 판단기준을 가지고 학습할수 있는 상황을 제공한다는 점에서 매력적입니다. 아직 첫 번째 돌도 안된 프로젝트지만, 조만간(2009년 3월)이면 벌써 2.0 정식 버전이 나오고, 이미 현장에서도 여러모로 적용했다는 소식을 접할 수 있습니다.

2.0이 나오면 커스텀 네임스페이스나 애노테이션 기반 설정이 가능해져 근본적으로 복잡한 배치 잡 구성을 조금은 쉽게 구성할 수 있을 듯 합니다. 또한 Scalability 측면에서도 Spring Batch 기반의 다양한 구현 패턴(Partitioning, Chunking processing, parallel processing 등)의 공유로 Spring Batch의 활용성이 더 높아질 것으로 기대됩니다. 또한 API도 훨씬 직관적이고, 개발이 편리하도록 개선되었고, 관리 인터페이스 또한 추가 됐습니다.(또는 정식버전 전까지 추가될 예정입니다.) 현재는 2.0M3가 나온 상태고, 정식 버전은 3월에 나올 예정이라니 조금만 기다려 주시죠^^.

4. Spring dm server
올 한해 가장 큰 화두 중 하나로 OSGi를 꼽을 수 있습니다. 임베디드 시장에서 이미 확고한 위치를 점령한 OSGi가 본격적으로 엔터프라이즈 시장에 진출하게 된 시점이 됐습니다. 물론 아직까지는 실험적인 단계라고 생각합니다. 현장 적용을 통해서 쌓여진 노하우(베스트 프랙티스)가 거의 없고, OSGi 환경에서 OSGi의 장점을 누리면서 개발할 수 있는 환경이 아직은 부족하다고 생각합니다. Maven이나 PMD 등이 있지만, 둘 다 엔터프라이즈 환경에서 개발을 지원하기에는 불편하거나, 부족한 상황입니다.

이런 상황에서 Spring dm server의 존재는 엔터프라이즈 환경에서의 OSGi 지원 가능성을 옅볼 수 있게 해줬습니다. 내부적으로 OSGi 환경을 제공하거나 단순히 배포 가능한 컨테이너 제공만 하는 것이 아니라, OSGi 프로그래밍 모델과 Spring의 프로그래밍 모델을 통합할 수 있는 기반을 제공(Spring-DM과 함께) 합니다. dm server는 SSTS와 SpringSource Enterprise Repository 등을 활용해서 OSGi 기반 개발 환경을 지원하고 있습니다. 이에 더불어 별도의 manifest 헤더와 배포 단위를 제공하는 등, 저수준 OSGi 명세를 기준으로 개발할 때 느끼는 불편함을 해결할 방법을 제시하고 있습니다.

물론 이마저도 아직은 많이 불안한게 사실입니다. dm server를 사용해서 개발하고, 배포해보려면 단순히 따라하기도 쉽지 않습니다^^. 올 한 해는 OSGi의 엔터프라이즈 환경 적용을 시험한 무대였다면, 내년에는 본격적으로 적용하는 다양한 방안에 대해서 연구되고, 공유될 수 있는 한 해가 될 것 같습니다. 역시 기대되는 내년 한 해가 될 것 같습니다.

5. tc server
이제 SpringSource는 아파치 톰캣(Tomcat)의 가장 '큰 손'이 됐습니다. 최근 2 년간의 톰캣 개발/버그 수정 중 대부분을 SpringSource가 제공했다고 합니다. 내년에 Spring tc server가 공개되면 어쩌면 Spring 기반으로 개발하면서도 WAS를 사용해야 하는 요구사항이 줄어들 수 있는 기회가 될 지도 모르겠습니다. 아직 내용 공개된 내용이 거의 없지만, 내년 초 가장 큰 관심사임은 분명해 보입니다.

6.Grails와 함께하는 Spring
올 해 말을 가볍게 강타한 내용입니다. Spring One America를 다녀오신 분들의 소감을 들어보면 감동이었다는 표현까지도 들을 수 있습니다. 이 역시 향후 전망을 가능케 할 수 있는 자료가 전무하지만, Grails로 기존 프로그래밍 모델을 개선할 수 있는 방안을 어떻게 도출해낼지 너무나 기대됩니다. 스크립트 언어의 장점을 Spring에 어떻게 접목시킬 지 기대되는 바입니다.