공룡호가 사는 세상 이야기

지난 달 Part 3 에서는 grep, sed, awk 와 같은 명령행 도구의 필터들을 소개했었다. Part 4 에서는 셸 스크립트 기교에 대해서 소개한다. 셸 명령 실행, 산술연산/진법변환, 대화형 셸 스크립트의 기본이 되는 인라인 입력이나 키보드 입력, 루프 등에 대해서 다룬다. 본 셸이 기본 조건이긴 하나 배시 셸도 관계없다.

거두절미하고 아주 짧은 셸 코드 하나를 보자.
for i in ??; { mv $i $i.ppm; }

위 코드는 현재 디렉토리의 파일 이름이 정확히 2글자인 모든 파일의 확장자를 .ppm 으로 변경한다.
i는 파일이며 ??는 파일의 글자 수이다. 루프 내는 for문의 조건이 만족되는 경우 $i를 $i.ppm으로 변경하는 간단한 코드이다. 하나 더 보자.

#!/bin/sh
# baseconv: 진법을 변환하는 간단한 스크립트
#
NUMBER=1
while [ $NUMBER ]; do
    read -p "Input base: " IN
    read -p "Output base: " OUT
    read -p "Number: " NUMBER
    bc -ql <<- EOF
  obase=$OUT
  ibase=$IN
  $NUMBER
  EOF
done

위 코드는 숫자를 입력 진법에서 출력 진법으로 변환한다. 간단하다. 튜토리얼에 모두 설명된 부분.
이번 튜토리얼은 일전에 몇 번 소개되었던 셸 스크립트 관련 아티클에 비해 자세하다. 일전의 아티클을 먼저 읽어 보는 것도 좋을 것 같다. 셸 스크립트의 강력함은 말로 다 할 수 없다. 배워봅시다.~
유용한 인라인 셸 코드들도 존재하니 많은 참고가 되겠다.

원문 : http://www.ibm.com/developerworks/kr/library/tutorial/au-unixtips4/index.html


앞으로 가젯(=위젯?)이 웹에서 상당한 비중을 차지할 수 있다. 아직은 그 미래가 불확실 한 것은 사실이나, 가젯이 가지고 있는 많은 매력들이 그렇게 될 가능성이 충분하다는 것을 시사하고 있다.
아직은 시장이 크지 않지만, 국내 포털에서도 위젯을 개발할 수 있는 환경을 제공하고 있다. 사실 DAUM의 위젯뱅크는 구글의 그것을 그대로 가져와서 사용했다. 아직, 많은 숙제들을 안고 있긴 하지만, 많은 이들이 여기에 관심을 내보이고 있는 데에는 나름의 이유가 있다. 가젯? 위젯? 그게 뭐냐고? 그것의 정의를 일러주면 아! 하고 이해할 수 있을 것 같은가. 그것이 무엇인지, 어떤 이유로 누구를 이롭게 하는지에 대한 막연한 궁금증 들은 일단 만들어 보면 대부분 이해할 수 있지 않을까.

 MLB Batting Stats

구글 차트 API, 구글 스프레드시트 API, 구글 가젯 API, 이 3가지 API를 통하여, 메이저리그 야구 팀의 최신 타율을 표시하는 재미있는 야구 핵을 구현한다. 예제는 파이썬으로 진행된다.
특히나 스프레드시트 API는 정말로 유용하다. 길어질 수 있는 코드를 작성해야 하는 수고를 덜어준다.
구글 가젯 만들기에 관련된 article을 몇몇개 리뷰했었는데, 이것이 조금 어렵다고 느끼는 분들은 그 중 가장 쉬웠던 것을 찾아 먼저 하는 것도 좋겠다. 우측 위에서 '가젯'이라 검색하면 될거다. 아마도.

가젯이 할 수 있는 일은 상당히 많다. 내가 필요한 것은 다른 누군가에게도 필요하지 않을까.
이번 주말에는 간단한 가젯을 구상하고, 개발하는 것도 좋은 일이다.
부쩍 차가워진 날씨에, 따뜻한 블랙커피도 함께.

링크 : http://www.ibm.com/developerworks/kr/library/wa-googlecode1/

요즘 괜찮은 아티클이 많이 올라온다.
셸 스크립트. 유닉스의 꽃이라 해도 과언이 아닐 정도로 필요하고, 유용하고, 멋지다.
예전에 도스(DOS)를 이용해 본 사람이라면, 확장자가 'bat'로 되어 있는 batch 파일을 알고 있을 것이다. 스크립트라는 말에서 느낄 수 있듯, 프로그램 언어와 배치파일 사이에 있는 정도라고 이해하면 되겠다.
도스를 몰라도 상관없다. 순차적으로 어떠한 일을 해야 하는데, 그 일이 단순한 반복 작업을 계속해야 한다면, 이를 미리 정의 해 두고, 자동적으로 실행하고 싶다는 생각은 누구나 할 것이다. 비슷하다고 생각하면 이해가 쉽다.

프로그램을 조금 해 보신 분들이라면 syntax만 파악하셔도 될 것 같다. 프로그램 언어를 배우면 가장 먼저 배우게 되는 변수, 표준 입/출력/오류, 함수, if-else, case문 등의 분기분 차례로 튜토리얼이 진행되는데, 평소 셸 스크립트를 한번 공부해보고 싶었거나, 유닉스에 대해 이제 조금 뭔가 알아갈 것 같다. 하시는 분들에게 권한다.

유닉스를 만지면 언젠가는 부딪혀야 하는 셸 스크립트. 잘하든 못하든 일단 다룰 줄은 알아야 될 것이다.
그 기본이 되는 아주 기초적인 문법부터 시작하고 있으며, 생각보다 자세하다.
유의해서 보아야 할 것이 있다면 오류처리 부분. 내가 생각하는 대로 늘 스크립트가 작동할 것이라는 생각은 하지말도록 하자.
1~2시간만 시간을 투자한다면 아래 코드를 이해하고 작성할 수 있게 될 것이다.'

$vi my_second_script.ksh
#!/bin/ksh
###################################################
# 작성자: Jason Thomas
# 목적: 이 스크립트는 첫 스크립트를 개발하는 방법을 보여주기 위해 작성했다.
# 2008년 5월 1일
###################################################

# 변수 정의
HOME="/home/jthomas" # 간단한 홈 디렉터리
DATE=$(date +%H%M) # 콘 셸 명령인 date를 수행한 결과를 DATE에 저장한다.
HOSTNAME=$(hostname) # HOSTNAME은 hostname 명령을 수행한 결과를 저장한다.

##################
function if_error
##################
{
if [[ $? -ne 0 ]]; then # 함수에 전달하는 오류 코드를 점검한다.
    print "$1" # if rc > 0이면 오류 메시지를 출력하고 끝낸다.
exit $?
fi
}
if [[ -e /tmp/file ]]; then  # 먼저 파일이 존재하는지 살펴본다.
   rm -f /tmp/file # 파일 삭제
   if_error "Error: Failed removing file /tmp/file"
else
   print "/tmp/file doesn't exist"
fi

if [[ -e /tmp/test ]]; then
     mkdir /tmp/test # 디렉터리 test 생성
     if_error "Error: Failed trying to create directory /tmp/test"
else
     print "Directory exists, no need to create directory"
fi

case $TIME in
                 "2200")
                  rm -f /tmp/file1
                        ;;
                  "2300")
                  rm -f /tmp/file1
                        ;;
# 스크립트 끝
esac

결론에서도 말하고 있듯, 스크립트 헤더를 작성하고, 변수를 정의한 다음, 오류를 점검하는 순서로 배우도록 하자.
진짜, 익숙해지면 모든 작업을 스크립트로 하려고 들게 된다-_-

링크: http://www.ibm.com/developerworks/kr/library/au-kornshellscripting/

유닉스는 어렵다. 쉽지 않은 게 사실이다.
혹자는 말한다. 알고 보면 유닉스도 쉽다고? 그런데 모르는걸 어쩌나.
일단 텍스트 기반에, 명령어를 모르면 어디서 시작해야 할 지 조차 알 수가 없다.
언젠가 부터, 정말 쉬운 유닉스 강좌를 한번 해보고 싶다는 생각을 했다.
dW 연재는 튜토리얼 4편으로 나뉘며, 사용자 관점에서 기본적인 유닉스 사용법을 소개한다.
유닉스 계정만 하나 있으면 되니, 접속 할 서버가 없다면, VMWARE나 Virtual Box에 유닉스 하나 얹어놓고, 조금씩 따라 해 보자.

먼저 가장 많이 쓰는 명령어들 부터. ls, cd, pwd, mkdir, rmdir, 디렉토리 구조.
파일에 관계된 touch, cp, mv, rm,  소유권/권한에 관계된  chown, chgrp, chmod,
여러 파일을 한꺼번에 다루는 와일드 카드와 재귀(사실 별건 없다 -R 옵션으로 반복 작업을 자동화 하는 것 뿐)
압축에 관계된 tar, gzip,  파일시스템과 파일 크기에 관련된 df, du, /dev, mount, umount
입력과 출력에 관계된 stdin, stdout, redirection, cat, more, head, tail, grep, 파이프 연산자 까지.

사실 위에 것들만 다 알아도, 기본적인 유닉스 운영에는 큰 무리가 없을 정도로 중요하고 많은 비중을 차지하는 것들이다. 하지만, 조금 아쉬운 부분은, 파일시스템에 대한 설명이 조금 약하다 싶다.
윈도우 파일 시스템에 익숙해져 있는 이들이 df 명령어에 대한 간략한 설명과 다음 결과값으로, 어떻게 이해를 할 것인가.

$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             7.9G  3.7G  3.9G  50% /
none                  3.9G     0  3.9G   0% /dev/shm
/dev/sda3              24G   20G  1.9G  92% /export


/dev/sda1이 총 7.9G 이고 그 중, 3.7G를 사용하고 있고 3.9G가 남아있다는 것은 알겠다.
그런데, 대체 /dev/sda1 은 무엇인지, / 과 Mounted on은 무엇인지에 대한 설명이 없다.
파일시스템에 대한 사전지식이 없는 이들이 이해하기에는 다소 무리가 있다 싶지만, 의욕있는 분들은 알아서 검색을 통해서 난관(?)을 헤쳐가시리라 믿는다. 그래도 이해가 어렵거나, 궁금한 것이 많아서 미치겠다 하시는 분들은 메일 또는 댓글을 통해 질문을 주시면 성실히 답변을!

총 4편이 연재될 것이고 다음 편 부터는 vi나 shell을 사용하는 기교와 팁을 다룬다고 하는데,
어려워 질 수록 더 자세한 설명이 필요한 것은 당연하다. Part 1에서 아쉬웠던 부분이 좀 더 보완되었으면 하는 바램이다.

링크 : http://www.ibm.com/developerworks/kr/library/tutorial/au-dw-au-unixtips1-i.html
원문 : http://www.ibm.com/developerworks/edu/au-dw-au-unixtips1-i.html

프로젝트 문서화는 소프트웨어 제품을 내 놓을 때, 종종 필요악이 됩니다.
참 맞는 말이다. 개발 할 시간도 없는데 언제 문서까지 만들고 있을까... 실제로, 학부생 때, 프로젝트를 진행 하면서, 중간 보고 때 마다 진척 상황를 문서화 해야 하는 사실이 너무나 귀찮고 어려웠다. 왜 하는 지도 몰랐었던 때가 있었는데, 얼마 후, 코드가 모두 담겨 있는 USB 메모리 스틱을 분실했다. 물론, 백업을 해 두지 않은 잘못이 크긴 하지만, 절망적이었다. 6개월 간의 코드를 분실했다고 생각해 보라.
형식도, 정형화도 되어 있지 않은 내 나름대로의 문서였지만, 나는 그 간의 문서들을 기초로 다시금 코드를 작성했고, 기간은 한 달도 채 걸리지 않았다. 그러나 여전히 필요악인 건 사실인..가(?)

문서화는 중요하다. 진행 중인 프로젝트의 팀원이 변경 되거나, 통채로 중지했다 다시 시작하거나, 실수로 데이터를 유실했을 여러가지 경우에 대해서 문서는 정말 중요한 수단이 된다. 그러나, 개발 할 시간도 부족한데, 일일이 문서를 만드는 것을 좋아 할 개발자가 어디있겠는가.. 비슷한 맥락에서 다음 내용을 보자.

내 경험에 비춰봤을 때, 두 개의 핵심 문제 때문에 소프트웨어 개발 문서화가 병들고 있다. 첫 번째는 아무도 그것을 읽지 않을 것이라는 가능성 때문이다. 두 번째로 흔한 문제는 문서 작성 시기가 거의 대부분 지연된다는 것이다.

그러면 문서작성을 자동화 하는 것을 생각해 볼 수 있다. 코드가 작성될 때 마다, 버튼 한 번으로 문서를 작성할 수 있다면, 그것을 항상 최신 상태로 유지함으로써 프로젝트에 참여한 모든 인원들 그리고 사용자 까지도 더 유용하게 만들 수 있다.
과연, 어떻게 그것을 자동화 할 수 있을까? dW에서 그 해답을 찾아보는건?

원문보기
http://www.ibm.com/developerworks/kr/library/j-ap06108/

유닉스에서 셸이란 명령줄이라고도 하는데, 운영체제 상에서 다양한 운영체제 기능과 서비스를 구현하는 인터페이스를 제공하는 프로그램이다. 사용자와 운영체제의 내부(커널) 사이의 인터페이스를 감싸는 층이라는 의미에서 셸 이라는 이름이 붙여졌다. 셸은 그 종류가 다양한데, 그 종류별로 세부적인 기능의 차이들이 조금씩 존재한다. 또한, 셸 스크립트 문법도 조금씩 다른데, 사용자 별로 자신에게 익숙한 셸이 하나씩은 있기 마련이다.

dW에서 소개하고 있는 배시(bash) 셸은 거의 모든 유닉스기반에서 활용 가능한데, 이번 튜토리얼에서는 배시 셸에 대한 간략한 역사, 주요 기능을 다루며, 유닉스 파일시스템, 디렉토리와 파일 조작방법 등을 설명하고 있다.

  • 배시 개괄
  • 배시에서 명령 행 프롬프트로 작업하기
  • 배시에서 파일과 디렉터리 다루기
  • 배시 개인화하기
  • 배시 작업 제어

이 튜토리얼을 읽기 위한 시스템 요구 사항은 없다. 단지 글을 읽고 배시를 익히면 된다. 하지만 이 튜토리얼을 최대로 활용하려면 튜토리얼이 제공하는 기법을 시도할 필요가 있다. 이렇게 하려면 버전 2.05 이상인 동작하는 배시 셸이 필요하다. 컴퓨터에 설치된 배시 셸 버전을 모른다면, 배시 셸 홈 페이지를 방문해 필요한 정보를 얻기 바란다.

원문 보기
http://www.ibm.com/developerworks/kr/library/tutorial/au-dw-au-bash-i.html

NIS(Network Information Service)는 유닉스, 리눅스 사이에서 시스템 파일 등을 NIS map 형태로 도메인에 참가하고 있는 이들끼리 공유하는 서비스이다. 방법은 NFS, automounter 등이 있다. 유닉스와 리눅스는 비슷하나, 두 시스템을 통합하는 과정을 어렵게 하는 몇 가지 중요한 차이점이 있다.
아직도 NIS가 무엇인지, NIS로 둘을 통합하는 것이 과연 어떤 의미를 지니는지 잘 모를 것이라 생각한다.

좀 더 자세히 이야기 해 보자. 최초 SUN에서 처음 개발되어 현재는 거의 모든 UNIX 시스템에서 사용되는 대표적인 통합 서비스이다. 기본 개념은 서버에 저장된 /etc 환경파일 정보를 유닉스 클라이언트들이 공유하는 서비스이다. 보통은 윈도우즈의 도메인 개념과 비슷한데, 서버에 저장된 사용자들은 클라이언트에서도 로그인 및 서비스를 이용할 수 있다는 의미가 된다.
유닉스 서버와 워크 스테이션들이 단일한 공간에 많이(10대 이상) 설치되어 있는 경우, NIS를 이용하면 편리하나, 실제로 많이 쓰이지는 않는다. 그래서 연구기관이나 학교같은 실습 장비가 많은 곳에 주로 사용되기도 한다.
이제, 조금 감이 오는지?

이러한 NIS를 이용하여, 유닉스, 리눅스간 통합에 대해서 dW에서 다루고 있다. 구조는 다음과 같다.

NIS 마스터와 슬레이브 구조

이를테면, 사용자가 암호를 변경할 때, 사용자가 NIS 데이터베이스에 직접 변경을 가하면 NIS 마스터로 변경 내역이 전해지며, 데이터베이스를 갱신하고 슬레이브 서버에 변경 내역을 전파하게 된다. NIS 데이터베이스에 변경이 일어나면 변경이 일어난 시점에서 슬레이브 서버로 자동으로 전파되며, yppush 명령을 사용하여 수동전파가 가능하다. 그럼, NIS 구성에 대해서 알아보자. NIS는 무엇보다 OS나 머신에 무관하게 파일시스템을 통해 각자의 파일과 자원을 계속 사용할 수 있다는 점이다.

자세한 내용과 구성방법 등에 대해서는 아래에서 확인하자.
http://www.ibm.com/developerworks/kr/library/au-linuxtogether/index.html

포스팅을 해 놓고 비공개로 설정된 것을 몰랐다니...-_- 어쨌든 이달 마지막 리뷰.
간단한 이야기를 하나 해 보자.

'갑' 기업의 새로운 업무 프로세스를 '을'기업에서 저렴한 비용으로 개발을 하게 되었다.
많은 회의 끝에 시스템이 도입되었고, 해당 시스템 위에서 6개월간 개발되었다.
6개월 후, 프로그램 테스트에서 결함이 발견되었다. 다름아닌 '성능'이었다.
개발의 완료단계에서 '성능'이 이슈가 되어 '을'은 굉장히 당황스러웠다.
결국은 시스템의 하드웨어를 증설하여 성능 문제를 어느정도 개선시킬 수 밖에 없게 되었다.

이러한 사례를 가끔 보게되는데, 요즘같은 고성능 하드웨어 시대에서 조차 프로그램 성능을 고려하지 않을 수는 없다. dW에서 자바코드 벤치마킹을 두 편에 걸쳐 연재하게 되었는데, 그 첫번째가 번역되었다.

Listing 1. 성능 수수께끼

protected static int global;

public static void main(String[] args) {
    long t1 = System.nanoTime();

    int value = 0;
    for (int i = 0; i < 100 * 1000 * 1000; i++) {
        value = calculate(value);
    }

    long t2 = System.nanoTime();
    System.out.println("Execution time: " + ((t2 - t1) * 1e-6) + " milliseconds");
}

protected static int calculate(int arg) {
    //L1: assert (arg >= 0) : "should be positive";
    //L2: if (arg < 0) throw new IllegalArgumentException("arg = " + arg + " < 0");

    global = arg * 6;
    global += 3;
    global /= 2;
    return arg + 2;
}


 다음 중 어느 버전의 실행 속도가 가장 빠를까?

  1. 코드를 그대로 둔다(calculatearg를 테스트하지 않음).
  2. L1만 코멘트를 해제하지만 조건 확인(assertion)은 비활성화하여 실행(JVM 옵션 중 -disableassertions 사용. 이는 JVM의 기본 동작임)
  3. L1만 코멘트를 해제하지만 조건 확인은 활성화하여 실행(JVM 옵션 중 -enableassertions 사용)
  4. L2만 코멘트를 해제한다.

적어도 테스트를 전혀 하지 않는 A가 가장 빠를 것이라고 짐작할 것이다. 그리고 좋은 동적 최적화 컴파일러가 죽은 코드인 L1은 제거할 것이므로, 조건 확인을 끈 B쪽이 A에 근접한 성능을 보일 것이라 짐작하리라. 그렇지 않은가? 불행히도 이러한 짐작은 틀렸다. 위의 코드는 Cliff Click이 2002 자바원(JavaOne)에서 소개한 것을 수정하였다. 그가 발표한 실행 시간은 다음과 같다.

놀라운 결과와 다양한 이슈들은 아래 링크에서 확인하자.
링크 : http://www.ibm.com/developerworks/kr/library/j-benchmark1.html#listing1

마음이 급하여 Part 2의 원문을 확인하고 싶으신 분들은 아래로.
링크 : http://www-128.ibm.com/developerworks/java/library/j-benchmark2/

'IBM dW review' 카테고리의 다른 글

배시 셸로 작업하기  (0) 2008.08.31
유닉스와 리눅스 함께 어울리기.  (0) 2008.08.31
Ajax에서 XML 처리하기, Part 3  (0) 2008.07.30
10가지 더 좋은 유닉스 습관  (0) 2008.07.30
Ajax에서 XML 처리하기, Part 2  (0) 2008.06.30

지난 2달간, Ajax에서 XML을 처리하는 방법(Part 1, Part 2)을 리뷰했었다.
이제 연재의 마지막인 Part 3가 소개되었다.
Part 1 링크 : http://www.ibm.com/developerworks/kr/library/x-xmlajaxpt1
Part 2 링크 : http://www.ibm.com/developerworks/kr/library/x-xmlajaxpt2

1. DOM 트리 탐색 - Part 1
2. 서버쪽 XSLT - Part 2
3. 클라이언트쪽 XSLT - Part 2
4. JSON과 동적 스크립트 태그

Part 3에서는 JSON과 동적 스크립트 태그를 이용하는 방법을 알아본다.
위 1,2,3 방식 모두 Ajax 에서 자바스크립트 XMLHttpRequest 객체를 사용하는 방법이었다. 즉, 모두 일종의 웹 프록시를 사용하여 원격지 서버의 XML 데이터를 가져오는 방법으로 Ajax의 '같은 도메인'문제를 해결했다.
Part 1에서도 언급되었고, Part 3에서도 잠깐 언급하고 있는데 '같은 도메인'문제는 Ajax프로그램이 원래 페이지를 가져온 서버로만 XMLHttp Request를 보내야 한다는 보안 제약을 말한다. 그러나 현실적으로는 Ajax 프로그램에서 가져오는 정보는 한 서버에 국한되지 않는다. 그래서 흔히 웹 서버 구성을 변경하거나 특수한 스크립트를 생성하는 방법으로 '같은 도메인' 문제를 해결한다.
그러나, 또 다른 방법이 있다. 해당 문제를 우회하여 프로그래머가 위와같은 제약사항에 신경쓸 필요가 없다.
Part 3에서는 JSON을 이용하여 이 문제를 해결한다.

JSON은 JavaScript Object Notation 을 줄인 약자로, 자바스크립트 언어가 기본적으로 이해하는 자료 형식이다. XML과는 달리, JSON은 자바스크립트 코드이므로 별도의 구문 분석이 필요 없다.
Part 1, 2에서도 그랬듯 날씨 정보 NWS(XML)을 가져와 야후 파이프를 이용, JSON으로 변환한다.

그림: 야후 파이프
야후 파이프 편집기

JSON으로 변환 후, 해당 변수에 할당하면 코드 내에서 바로 참조가 가능하게 된다.
전체 파이프 라인을 보면 다음과 같다.

접근 방식 4가 따르는 파이프라인

자세한 방법 및 수순은 아래 링크에서 확인하도록 하자. 더불어 각 방법의 장단점에 대해서 고민해 보고,
해당 방법을 변형하여 새로운 접근을 만들어 낼 수도 있을 것이다.

Part 3 링크 : http://www.ibm.com/developerworks/kr/library/x-xmlajaxpt3/

지난 달에 'Ajax에서 XML 처리하기, Part 2' 을 리뷰했었다. 그 때는 DOM 트리 탐색 방법을 이용한 예제를 사용했었는데, 기다렸던 대로 Part 2가 소개되었다.
(Part 1 링크: http://www.ibm.com/developerworks/kr/library/x-xmlajaxpt1/)

1. DOM 트리 탐색
2. 서버쪽 XSLT
3. 클라이언트쪽 XSLT
4. JSON과 동적 스크립트 태그

Part 2 에서는 2,3번 방법을 살펴본다. 모두 XSLT를 사용한다는 공통점이 있다.

Part 1 : DOM 트리 탐색 방법
접근 방법 1을 위한 자료 파이프라인

Part 2 : 서버쪽 XSLT
접근 방식 2가 따르는 자료 파이프라인

Part 2 : 클라이언트쪽 XSLT
접근 방식 3이 따르는 자료 파이프라인

3가지 방식은 비슷하나 조금씩 다른 면이 있다.
간단한 예제라면 브라우저에 아무런 부담이 없겠지만 XML 이 커지면 문제는 달라진다.
또한, 사용자가 사용하는 브라우저와 컴퓨터도 고려해야 한다.
어떤 방법을 사용할 것인가는 각기 다른 모델에 대한 충분한 이해와 적용하는 환경에 따라 선택해야 할 것이다.

좀 더 자세한 설명과 튜토리얼은 아래 링크로.
http://www.ibm.com/developerworks/kr/library/x-xmlajaxpt2/