대학원부터 시작한 첫번째 블로그

디버깅 작업 또는 프로그램의 안전성을 검사할 때 디버거를 잘 쓰면 꽤 많은 시간을 절약할 수 있습니다. 대부분 개발자들이 GDB를 써서 디버깅을 하고 있지만, GDB가 가지고 있는 강력한 기능들을 거의 쓰지 못하고 있기 때문에, 이 글에서는 자주 쓰이지는 않을 지언정, 알면 매우 도움이 되는 기능들을 위주로 살펴보겠습니다.

먼저, 이 글을 읽는 분들이 GDB의 기본적인 사용 방법 (특히 break, run, continue, file, backtrace, print 등)을 알고 있다고 가정하겠습니다. 기본적인 사용 방법을 모르신다면 Emacs/GDB/etags/cscope나 기타 GDB manual을 참고하기 바랍니다.

Breakpoints

break 명령은 대개 다음과 같이 쓸 수 있다는 것은 이미 알고 계실 것입니다:

(gdb) break                # 현재 줄에 breakpoint 설정

(gdb) break 31             # 현재 파일 31번째 줄에 breakpoint 설정

(gdb) break foo            # 함수 foo에 breakpoint 설정

(gdb) break list::next     # list 클래스 next 멤버 함수에 설정

(gdb) break hello.c:main   # hello.c 파일의 main 함수에 설정

(gdb) break util.c:300     # util.c 파일의 300번째 줄에 설정

특히 C++의 경우, 한 클래스의 모든 멤버 함수에 breakpoint를 설정하고 검사할 필요가 있는데, 이 경우, 정규 표현식(regular expression)으로 breakpoint를 설정하는 rbreak 명령을 쓰면 편리합니다. 예를 들어 보면:

(gdb) rbreak f*o           # "f*o"를 만족하는 심볼 전체에 대해 설정

(gdb) rbreak list::        # "list::.*"를 만족하는 심볼 전체에 대해 설정

특히 위 두번째 예제를 보시면 ".*"이 항상 default로 따라 온다는 것을 알 수 있습니다. 사실 rbreak 명령에 "foo"를 준 경우 사용되는 정규 표현식은, 정확히 말하면 ".*foo.*"가 됩니다. 따라서 "foo"로 시작하는 함수 전체에 대해 breakpoint를 설정하고 싶다면, 다음처럼 쓰면 됩니다:

(gdb) rbreak ^foo

breakpoint를 설정하면, 해당 breakpoint마다 번호(BNUM)가 주어지고, 이 번호를 써서 다양한 작업을 수행할 수 있습니다. 예를 들어, 전체 breakpoint 목록을 보고 싶다면:

(gdb) info b

Num Type           Disp Enb Address    What

1   breakpoint     keep y   0x08066b44 in eventShow() at menubar.cpp:1017

        breakpoint already hit 3 time

2   breakpoint     keep y   0x080b06f4 in Play() at thumbview.cpp:416

3   breakpoint     keep y   0x08066e7e in ActPlay() at menubar.cpp:1085

4   breakpoint     keep y   0x08059cd3 in Play_SS(int, int) at widgets.cpp:2183

(gdb)

첫번째 컬럼(Num)은 각 breakpoint에 대한 고유번호(BNUM)를 나타냅니다. 그리고 두번째 컬럼(Type)은 breakpoint인지 watchpoint인지 catchpoint인지를 나타냅니다. (watchpoint와 catchpoint는 다음에 설명..) 그리고 세번째 컬럼(Disp)은 이 breakpoint의 특징을 나타냅니다. (다음에 설명). 네번째 컬럼(Enb)는 현재 이 breakpoint가 활성화되어 있는지를 나타냅니다. 비활성화(n)로 표시된 breakpoint는 동작하지 않습니다. 활성화/비활성화는 'enable br [BNUM]' 또는 'disable br [BNUM]'으로 변경할 수 있습니다. 예를 들어 1번 breakpoint를 비활성화하고 싶다면:

(gdb) disable br 1

전체 breakpoint를 활성화하고 싶다면:

(gdb) enable br

2번, 4번 breakpoint를 비활성화하고 싶다면:

(gdb) disable br 2 4

2번부터 5번까지 breakpoint를 활성화 하고 싶다면:

(gdb) enable br 2-5

등으로 할 수 있습니다.

때때로, 딱 한 번만 쓸 breakpoint가 필요한 경우가 있습니다. 이 경우 쓸 수 있는 명령은 enable br once [BNUM] 또는 enable br delete [BNUM]을 쓸 수 있습니다. 예를 들어 아래 명령은 1번, 3번 breakpoint를 활성화하고, 사용된 경우 바로 비활성화시킵니다:

(gdb) enable br once 1 3

아래 명령은 4번 breakpoint를 활성화하고, 사용된 경우, 이 breakpoint를 삭제합니다:

(gdb) enable br delete 4

쓸모있는 기능 중 하나가 바로 breakpoint에 조건을 지정하고, 해당 조건을 만족할 경우에 멈추도록 하는 것입니다. 예를 들어 다음과 같은 코드가 있다고 가정해 봅시다:

int i = 0;


/* do something #1 */


for (i = 0; i < 1000; i++) {

  /* do something #2 */

  /* do something #3 */

}

이상하게도 i가 456일때 반복문 안에서 프로그램이 이상하게 동작한다고 가정해 봅시다. 이 때 "do something #2" 부분에 breakpoint를 걸었다면 (이 breakpoint의 번호는 8번이라고 가정합시다), 반복할 때마다 계속 프로그램 실행이 멈출 겁니다. 정확히 1000번 멈추겠죠. 456번까지 진행한다는 것은 매우 귀찮은 일입니다. 이 경우, 다음과 같이 조건을 지정할 수 있습니다:

(gdb) cond 8 i == 456

즉, 8번 breakpoint는 i == 456을 만족할 때에만 멈추도록 지정합니다. 조건식에는 단순한 상수 비교 이외에, 복잡한 함수 호출도 가능합니다. 예를 들면 다음과 같습니다:

(gdb) cond 8 foo(i) > bar(rand())

앞에서 예로 든 코드는 단순 반복문이기 때문에, 처음 456 - 1번에 발생하는 breakpoint는 무시하라고 지정할 수도 있습니다. 처음 N번 발생하는 breakpoint를 무시하라는 명령은 다음과 같습니다:

(gdb) ignore 8 455

즉, 8번 breakpoint는 455번 동안 무시됩니다.

또, 다음과 같은 코드를 가정해 봅시다:

int i = 0;

int j, k;

long l;


while (1) {

  j = rand();

  k = some_funtion(j, time());


  /* do something #1 */

  l = j & 0xFF00 + (int)(log(k) * 3.2108) - ...;


  if (some_condition)

    break;

}

위 코드는 j와 k가 실행할 때마다 값이 변합니다. 그리고 이상하게도 j < k 일때 변수 l이 이상한 결과를 가지는 것 같지만, 확실하지는 않습니다. 우리가 확신할 수 있는 것은 j < k일 경우, l은 항상 양수이어야 한다는 것입니다. 그래서 l의 값이 전체 반복을 끝낼 동안 어떤 값을 가지고 있는지 검사해보고 싶습니다. 이 경우 해당 breakpoint에서 멈출 때, 특정 명령을 수행하도록 하는 GDB 명령인 commands를 쓰면 됩니다.

일단 "l = j & 0xFF00..." 부분에 breakpoint를 걸고 (9번 breakpoint라고 가정), 다음 명령을 내립니다:

(gdb) commands 9

Type commands for when breakpoint 9 is hit, one per line.

End with a line saying just "end".

>silent

>if j < k

 >printf "l is %d\n", l

 >end

>cont

>end

대충 눈치가 빠른 분은 아시겠지만 'commands [BNUM] ... end'는, BNUM breakpoint에서 멈췄을 때, "..."에 지정한 GDB 명령들을 수행합니다. 일단 silent 명령으로 명령 자체가 출력되지 않도록 한 다음, GDB printf 명령으로 변수 l 값을 출력합니다. 그리고 continue 명령으로 계속 프로그램을 진행하도록 합니다. 그 결과, 프로그램을 실행할 경우, breakpoint에서 멈추고 l 값을 출력한 다음 프로그램을 자동으로 진행합니다. 이 과정은 반복문이 끝날 때까지 계속되기 때문에, 다음과 같은 비슷한 출력을 얻을 수 있습니다.

(gdb) continue

l is 3

l is -2

l is 2

l is 1

l is -3

앞에서 j < k일 때, l은 항상 양수여야 한다고 말했습니다. 위 결과를 보고 우리는 l 값이 때때로 잘못된다는 것을 쉽게 알 수 있습니다.

commands에 쓸 수 있는 GDB 명령어 형태는 다음 기회에...

가끔 next나 step으로 실행 과정을 따라 가다가 반복문을 만날 경우, 반복문 끝난 부분으로 바로 건너뛰거나, 현재 함수의 실행을 정상적으로 끝내고 상위 함수로 돌아가야할 경우가 있습니다. 예를 들어:

for (i = 0; i < 1000; i++) {

  /* do something #1 */

  /* do something #2 */

}

/* do something #3 */

현재 "/* do something #2 */" 부분까지 실행했고, 이 반복문에 이상이 없다고 판단되면, 반복문 다음까지 빠르게 진행하고 싶을 겁니다. 이 경우, until 명령이나 advance 명령을 쓰면 편리합니다.

until 명령을 쓰면, 반복문이 아닌 경우에는 next 명령과 똑같이 동작합니다.

(gdb) until

반복문일 경우, 현재 스택 프레임 (즉, 현재 함수) 안에서, 현재 줄 다음 줄에 올 때까지 프로그램을 실행합니다. 쉬운 말로, 루프를 진행하고 빠져 나오는 순간까지 실행한 다음 "(gdb)" 프롬프트를 보여줍니다.

advance 명령은 continue 명령과 마찬가지로 프로그램을 주욱 실행시키는 대신, 지정한 곳에 코드 흐름이 오면 바로 멈춥니다. 예를 들어 위 코드의 "/* do something #3 */" 부분의 줄 번호가 34였다면, until 명령 대신 다음과 같이 실행할 수도 있습니다:

(gdb) advance 34

advance 명령은 스택 프레임에 대한 제한이 없기 때문에, 현재 함수가 아닌, 아무 곳이나 설정할 수 있으며, 위치 지정은 줄 번호 뿐만 아니라, break 명령에 쓰는 모든 형식을 다 지원합니다.

네트워크로 서비스 요청 데이터를 전송받아 분석하고, 적절한 기능을 수행하고, 그 결과를 돌려주는 서버 프로그램을 생각해 봅시다. 그리고 다음과 같은 꼴로 되어 있다고 가정해 봅시다:

#define PACKET_MAX      10


int

fetch(void)

{

  int packet_received = 0;

  int received[PACKET_MAX];


  while (1) {

    if (!packet_received) {

      if (recv_data(received, PACKET_MAX) == 0)

        packet_received = 1;

    }


    /* do work here */


    process_packet(received, PACKET_MAX);

  }

  return 0;

}

이 프로그램은 평소에는 정상적으로 잘 동작하지만, 특정 패킷을 받으면 이상하게 동작한다고 가정합시다. 그리고 이 패킷은 아주 가끔 들어온다고 가정해 봅시다. 원하는 대로 패킷을 보내주는 프로그램을 따로 작성해 두지 않았다면, 이 프로그램을 디버깅하기 위해서, 문제를 일으키는 패킷이 올 때까지 하염없이 기다려야할 지도 모릅니다. 실제 코드는 다음과 같습니다:

만약 원하는 패킷이 recv_data()를 통해 들어왔다고 가정합시다. 이 때 packet_received는 1이 되고, 그에 따라 처리 작업이 이상하게 동작할 것입니다. 이 때, received의 내용을 저장하기 위해, 다음 명령을 쓸 수 있습니다:

(gdb) dump binary value buggy.dat received

위 명령을 수행하면 배열 received의 내용을 파일 buggy.dat에 저장합니다. 만약 시작 주소와 끝 주소를 알고 있다면 다음 명령을 쓸 수 있습니다:

dump binary data buggy.dat START-ADDR END-ADDR

이 때, START-ADDR는 시작 주소를, END-ADDR는 끝 주소를 나타냅니다. 즉, 앞 received 배열의 경우, 다음과 같이 쓸 수 있습니다.

(gdb) dump binary memory buggy.dat received received+10

어느 방법을 썼든지, 현재 디렉토리에는 buggy.dat이라는 파일로, 배열 received의 내용이 저장될 것입니다. 이는 메모리 내용을 그대로 dump시킨 것이므로 od(1)와 같은 툴을 써서 그 내용을 직접 볼 수 있습니다. received 배열은 int 배열이므로 다음과 같이 확인 가능합니다:

$ od -td buggy.dat 

0000000         163         151         162          85

0000020          83         190         241         252

0000040         249         121

0000050

$ _

만약, 바로 디버깅을 성공적으로 끝냈다면, 사실 위와 같은 기능은 큰 역할을 발휘하지 못합니다. 하지만, 계속해서 디버거를 실행해서 여러번 디버깅을 해야 한다면 꽤 쓸모있다는 것을 알 수 있습니다.

일단, 새로 GDB를 띄워 디버깅을 시작했다고 합시다.

    if (!packet_received) {

위 코드를 실행할 때, 강제로 packet_received를 1로 만들어, 패킷을 받는 부분을 건너뜁니다. 변수의 값 변경은 print 명령으로 쉽게 할 수 있습니다:

(gdb) p packet_received = 1

그리고 나서, received 배열을 아까 저장해 두었던 buggy.dat에서 다음과 같이
불러올 수 있습니다:

(gdb) restore buggy.dat binary received

Restoring binary file buggy.dat into memory (0xbfeda890 to 0xbfeda8b8)

이 외에도, GDB는 타 디버거에 비해 강력한 기능들을 많이 제공합니다. 다음 기회에 좀 더 알아보겠습니다.

core dump file이 발생하였을 경우 이것을 가지고 디버깅 하는 방법을 소개하고자 한다.

간단한 소스 코드를 보자.

#include <stdio.h>

int main(int argc, char* argv[]) {
char buffer[16];

buffer[80000] = 3;

return;
}

gcc -g -o main main.c

ps: -g 옵션은 디버그 정보를 넣어서 컴파일을 해 주는데, 이게 없으면 core 파일을 분석 할 수 없다.

frank@tightrope:~/tmp/gdbtest$ ./main
Segmentation fault

core dump file이 생성되지 않을 경우는 막아 놓았기 때문인데, ulimit 를 사용해서
이것을 풀어줄 수 있다.

ulimit -c 1024 (core file 용량을 정해준다.)

frank@tightrope:~/tmp/gdbtest$ ./main
Segmentation fault (core dumped)

frank@tightrope:~/tmp/gdbtest$ ls -als core
72 -rw------- 1 frank frank 147456 2006-01-13 21:19 core

분석을 해 보도록 하겠다.

frank@tightrope:~/tmp/gdbtest$ gdb ./main ./core
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".

Core was generated by `./main'.
Program terminated with signal 11, Segmentation fault.

warning: current_sos: Can't read pathname for load map: Input/output error

Reading symbols from /lib/tls/i686/cmov/libc.so.6...done.
Loaded symbols for /lib/tls/i686/cmov/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0 main (argc=1, argv=0xbfca9944) at main.c:6
6 buffer[80000] = 3;
(gdb)

이걸 보고 우리는 main 함수에서 Segmentation fault로 종료되었다는 것을 알 수 있다.
함수 이름과 매개변수 값, 몇 번째 줄에서 segmentation fault가 났는지 보여준다.

이제는 조금 더 복잡한 소스를 디버깅해 보도록 해 보자.

#include <stdio.h>

int main(int argc, char* argv[]) {

// notice the erroneous "=", the coder meant "=="
if(argv = 0) return;

printString(argv);

return;
}

컴파일 하고 실행해 보자.

frank@tightrope:~/tmp/gdbtest$ gcc -g -o main main.c

frank@tightrope:~/tmp/gdbtest$ ./main
Segmentation fault (core dumped)

frank@tightrope:~/tmp/gdbtest$ ls -als core
68 -rw------- 1 frank frank 147456 2006-01-13 21:53 core

이제 디버깅을 해 보도록 하자.

frank@tightrope:~/tmp/gdbtest$ gdb ./main ./core
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.

...

#0 0x08048396 in printString (string=0x0) at main.c:14
14 sprintf(string, "This is a test.\n");

#0 줄을 보면 string 이 널 포인터라는게 분명하다. 그런데 우리는 이게 어디서 왔는지
모른다. 단서는 파일 main.c에 14번 째 줄이라는 것과 main 에서 에러가 발생하지
않았다는 것이다. 그래서 우리는 backtrace를 할 것이다.

(gdb) backtrace
#0 0x08048396 in printString (string=0x0) at main.c:14
#1 0x0804837c in main (argc=1, argv=0x0) at main.c:8

'backtrace' 명령어는 함수를 연대기순으로 나열해 준다. 맨 위에 줄이 segmentation fault
가 발생한 소스이다. 저걸 보면 main.c:8 에서 main.c:14를 호출한 것을 알 수 있다.
더 많은 정보를 얻기 위해 'frame' 명령을 사용하도록 하자. 'frame' 명령은 'backtrace'
명령 실행으로 나온 항목들에 대해 더 많은 정보를 보여준다.

(gdb) frame 0
#0 0x08048396 in printString (string=0x0) at main.c:14
14 sprintf(string, "This is a test.\n");
(gdb) frame 1
#1 0x0804837c in main (argc=1, argv=0x0) at main.c:8
8 printString(argv);

이것을 보면 이미 main.c:8 에서 argv가 0으로 값이 넘어간 것을 알 수 있다.

*잡다한 tip
스레드를 사용해서 프로그래밍을 할 때 threadsafe 함수를 사용해야 한다. 예를 들어서 localtime
함수는 언젠가 프로그램과 충동할 것이다. 그 대신에 localtime_r 함수를 쓰는게 좋다. localtime_r
함수는 threadsafe 함수이다.

유선과 무선 환경의 차이

• 노드 사이의 명시적인 링크가 존재하지 않음
  • 라디오의 전송 범위 내에 노드들이 위치하면 통신 가능
• 무선상에서는 MAC 기술이 아주 중요
  • NS2 유선 시뮬레이션 환경은 MAX이 존재하지 않음
• 무선상에서 노드는 이동성이 존재
• 라우팅
  • 유선상에서는 특별히 라우팅을 설정하지 않아도 링크 설정관계를 통해서 최단 경로가 선택
  • 무선에는 반드시 라우팅이 존재해야 함
• 주소
  • 유선에서는 flat address
  • 무선만 존재하면 flat address
  • 유무선 연동인 경우는 hierarchical address

NS2에서의 유선과 무선의 차이

• C++ 상에서의
  • 유선 : class Node
  • 무선 : class MobileNode
• 노드 생성은 유무선 모두 $ns node로 하지만 무선에서는 node-config라는 추가 작업이 필요
• Trace
  • $ns/common 에서
    • 유선 : trace.{h, cc}
    • 무선 : cmu-trace.{h, cc}
• 이동성
  • 무선에서는 이동성을 지원
  • 위치 정보가 중요
    • 유선에서는 연결 구조가 중요, 노드의 배치는 중요하지 않음
    • 무선에서는 위치에 따라서 전송 범위 내에 있는지 여부가 결정
• 그 외에는 유무선 모두 같은 네트워크 컴포넌트를 사용

node-config

• -adhocRouting : 라우팅 프로토콜 설정
  • DSDV, AODV, TORA,, FLOODING,...
• -llType : 링크 레이어 설정
  • LL
• -macType : 맥프로토콜 설정
  • Mac/802_11, Mac/SMAC
• -propType : 경로손실타입
  • Propagation/twoRayGround, Propagation/FreeSpace, Propagation/Shadowing,...
• -ifqType : 큐타입
  • Queue/DropTail/PriQueue,...
  • 애드혹라우팅 프로토콜이 DSR인 경우 반드시 CMUPriQueue로 해야 함
• -ifqLen : 큐길이
  • 패킷 개수
• -phyType : 피지컬레이어타입
  • Phy/WirelessPhy,...
• -antType : 안테나 타입
  • Antenna/OmniAntenna
• -channel : 현재는 없어짐
  • Channel/WirelssChannel
• -topoInstance : 전체 영역
  • $topo
• -agentTrace : 트레이스 설정
  • ON or OFF
• -routerTrace : 트레이스 설정
  • ON or OFF
• -macTrace : 트레이스 설정
  • ON or OFF
• -movementTrace : 트레이스 설정
  • ON or OFF

NS2 무선환경 시뮬레이션 스크립터

 Max/802_11 Bandwidth

• basic rate, data rate 두가지 존재
  • basic reate : RTS, CTS, ACK 을 전송하는 속도
  • data rate : 실제 데이터를 전송하는 속도
• 설정하는 방법
  • Mac/802_11 set basicRate_ 1Mb
  • Mac/802_11 set dataRate_ 1Mb
  • 기본값은 둘다 1Mbps

범위 설정

• 전송 범위 : 데이터가 성공적으로 수신되는 범위
• 캐리어 감지 범위 : 데이터를 성공적으로 수신하지는 못하지만 신호만 감지하는 범위 -> CSMA/CA 프로토콜의 CA
• 전송 범위와 캐리어 감지 범위는 수신 노드에서 받는 전파세기와 쓰레쉬홀드에 의해서 결정
• $ns/tcl/lib/ns-default.tcl

• 다른 설정은 변경하지 않고 위 두개의 threshold만 변화시켜 범위 조절 가능
• $ns/indep-utils/propagation/threshold.cc
  • 컴파일 후 threshold -m <경로손실모델> <범위> ->threshold

1. 자바 애플릿.클래스 정보

class파일이란?

확장자가 class인 파일로 파일형식은 "파일이름.class" 입니다.
(예: lake.class, snow.class )
이 파일은 애플릿 효과를 구사하는데 있어서 가장 중요한 파일로 일반인들은 만들기 어렵고 프로그래머들이 개발해 놓은 것을 애플릿을 구사할 때 code로 사용하게 됩니다. 예를 들면 눈오는 효과를 구사하고 싶으면 snow.class를 code로, 물결 효과를 구사하고 싶다면 lake.class를 code로 (참고: anfy사에서 개발한 눈 내리는 효과 클래스 파일은 ansnow.class, 물결 효과는 anlake.class.) 사용하면 됩니다.

애플릿의 실행 방법

애플릿이 실행 되려면 기본적으로 세 개의 파일이 있어야 합니다.
위에서 말씀드린 class 파일과 이미지 파일(보통jpg,gif파일을사용함), 그리고 매개변수를 설정한 html(웹페이지형식)파일 입니다.

위 세 개의 파일이 같은 디렉토리(경로) 즉, 같은 폴더 내에 있어야 실행이 됩니다.

홈페이지를 가지신 분들은 알겠지만 ftp나 기타 홈계정에서 제공하는 홈피 관리프로그램을 실행해보시면 윈도우 탐색기처럼 디렉토리가 형성되어 있을 것입니다.
자신의 컴퓨터에서 애플릿 작업을 하고 자신의 홈피에 업로드할 때 위의 세 파일을 같은 장소(폴더)에 올려야 되지요--->'중요'

그렇다면 class 파일은 어디서 구해오고, html파일을 어떻게 만드느냐...
html 파일을 직접 만들기란 시간적 낭비일 뿐만 아니라 용어까지 모두 알아야 합니다. 그렇기 때문에 이미 만들어진 HTML 파일을 권해보도록 하겠습니다. 우선 아래 사이트에 가셔서 애플릿마법사 Anfy 1.4.5 를 다운받으셔서 사용해 보세요.

http://www.anfyteam.com/

단계별로 자신이 원하는 그림을 넣을 수도 있고 매개변수도 설정할 수 있습니다.
한글도 지원되기 때문에 글을 넣을 수 있는 애플릿에서는 글도 넣을 수 있답니다.
좋은 효과를 보실려면 매개변수를 바꿔가면서 많이 연습해 보시는 것이 좋겠죠?

설정이 다 끝나면 복사탭을 클릭하시고 자신의 컴퓨터 일정한 폴더에 붙여넣기를 하시면
필요한 모든 파일이 생기게 됩니다.
(사용이미지가 들어있는 폴더에 붙여 넣으세요.)

여기에 생긴 파일들(이미지파일포함)을 모두 홈피계정에 올리시면 됩니다.(같은 디렉토리에)

html 파일은 실행 파일이므로 애플릿을 보실려면 그 파일에다 링크를 걸어야겠죠?

그럼 codebase란 무엇일까?

인터넷 여기 저기를 다니다 멋진 애플릿을 보면 어떻게 내 홈에 올려 놓을 수는 없을까? 또는 자신이 애플릿을 아주 멋지게 만들었는데 다른 게시판에 올릴 수는 없을까 하는 생각을 하시게 될 겁니다.
그런데 애플릿은 같은 디렉토리 내에서만 실행이 되기 때문에 html 문서를 다른 곳으로 옮기면 class파일이나 이미지 파일을 읽어올 수 없게 되지요.
(유리꽃 Hous에 있는 애플릿은 모두 절대 경로를 사용했기 때문에 다른 곳에서도 실행이 됨.)
그래서 필요한 것이 codebase(클래스파일과 이미지파일이 들어있는장소) 입니다.
즉 codebase는 class파일이 업로드된 폴더 주소(경로)를 말하는 것이죠.

* codebase="해당애플릿 class파일과 이미지가들어있는 경로"

위와 같은 형식으로 실행 html 소스에서 클래스 파일 경로 를 수정해 주시면 되지요.

이상 웹사이트에서 애플릿 실행 방법을 알려드렸는데 이해가 가시는지 모르겠습니다.
아래 클래스 파일을 다운받을 수 있는 곳에 가셔서 더 많은 것을 살펴보시기 바랍니다.

class파일을 다운 받을 수 있는 곳

<환상여행>
Coowild.class 를 다운받을수 있는곳입니다..

* http://chunma.yu.ac.kr/~fworkers/test_cw.htm

* http://www.coolshare.com/ftp/adware/java/coowild.zip

* http://www.winsite.com/info/pc/win95/netutil/coowild.zip

* http://www.winsite.com/info/pc/winnt/netutil/coowild.zip

* ftp://ftp.simtel.net/pub/simtelnet/win95/java/coowild.zip


<픽쳐메뉴 홈페이지>
각종 픽쳐메뉴를 제공해 주는 외국 싸이트 입니다.

* http://www.javabase.fsnet.co.uk/



Anfy 프로그램을 내 컴퓨터에 다운받아
설치한후에 애플릿 효과를 직접 만들수 있는 싸이트 입니다.
외국싸이트이지만 한국어를 지원해 주고 있답니다..

* http://www.anfyteam.com/

이 외에 자바 애플릿의 자료를 구하시려면 검색엔진에서 각종 클래스의 이름만 넣고 검색을 하셔도 수백개의 사이트를 찾을 수 있을 것입니다. 많은 참고 바랍니다.

각 회사의 영업 부서와 마케팅 부서에서 자사의 기술을 더 강조하기 위해 조장하는 과대 광고나 홍보에 신물이 났는가? 자바 기술은 언론에서 긍정적으로 평가받기도 하고 부정적으로 평가받기도 했다. 언론은 이 기술에 대해 상반되는 정보를 제공하여 사람들을 혼란스럽게 만들었다. 이 글에서는 자바를 현실적으로 평가하고 "자바를 사용할 때 front end와 관련해서 우리에게는 어떤 옵션이 있는가?" 란 질문에 답을 제공해 볼 생각이다.

서버단 개발에서 자바를 사용할 때 기존의 다른 기술에 비해 자바가 훨씬 많은 이점을 제공하기 때문에 이 부분에 있어서는 확실한 입지를 굳히고 있긴 하다. 그러나, 실질적으로 모든 애플리케이션이 유저 인터페이스와 front-end 프리젠테이션을 어떤 형태로든 가진다. 우리 대부분은 클라이언트단에서의 자바 사용을 언론에서 맹공격하고 있는 것에 대해 익숙하다. (remember how many times we've heard about "nails in the coffin of Java"?) 언론에서는 HTML 기반 front end 를 제외한 그 밖의 다른 기술을 사용하는 것이 제 무덤을 파는 것과 같다고 말하고 있다.

그러나 사실은 기존의 HTML 클라이언트를 사용하는 것 외에도 다른 옵션들이 있다. 필자는 Java 기반 애플리케이션에서 유저 인터페이스를 개발하기 위해 사용할 수 있는 세 가지 주요 솔루션에 대해 설명할 것이다. 우선 JavaServer Pages™ 과 서블릿에서 HTML 을 사용하는 것에 대한 장단점을 살펴볼 것이다. 다음으로, 약간 놀랍게 들릴 수도 있겠지만, 초기 약속 중 하나인 "GUI 애플릿을 통한 인터렉티브 Web"이 가능하다는 점을 증명할 것이다. 끝으로, XML과 이 언어와 함께 출시된 그 밖의 고급 기술들에 대해 설명할 것이다. 이제 여러분이 정말로 알고자 하는 문제로 넘어가자 - 기술적 사실들.

HTML Client with JSP/Servlets

또한 HTTP/HTTPS 프로토콜의 단순함을 고려하면 다양한 네트워크 설정이나 방화벽에서 프로그램 했을 때 어떤 일이 일어날 지를 예측할 수 있는 장점이 있다. 그러나 이 지구상의 모든 것이 그러하듯이 이런 장점이 공짜로 얻어지는 것은 아니다. HTML 의 단점은 사용자와의 상호작용이 없으며, 사용자의 리퀘스트에 대한 리스펀스를 보낼 때 마다 서버를 거쳐야 한다는 것이다.

물론 JavaScript도 존재한다. 그러나 여러분이 프로그래머로써 일하면서 강제적인 필드를 enforce 하고 간단한 프롬프트를 생성하며, 또한 이 둘을 모든 브라우저에서 동일한 방식으로 실행되게 하는 것 보다 더 어려운 작업을 해 본 경험이 있는가? 단순함이 늘 좋은 것은 아니다. 간단히 말해서 JavaScript 는 꼬이지 않은 인터렉티브 로직을 static 한HTML 에 추가하기에 적절한 언어이지만 사용자가 놀랄정도로 잘 구성된 고차원의 유저 인터페이스를 만들 능력은 없다.

여러분 스스로가 디지털화되어 사이버공간에서 살고 있지 않는 한, 혹은 집에 T-1 전용선이 설치되어 있지 않는 한, 웹페이지가 로드되기를 기다리거나 서버가 쓸데없는 페이지를 거치게 만드는 답답함을 느껴보았을 것이다. thin 클라이언트가 다수의 인터렉티브 하지 않은 유저 인터페이스의 프리젠테이션을 멋지게 소화할 수 있는 방안을 제시하기 하지만, 기존의 fat 클라이언트가 똑똑함(intelligence)이란 측면에서는 thin 클라이언트를 능가한다. 예를 들어 온라인 브로커는 HTML 클라이언트보다 훨씬 잘 실행되는 애플리케이션 클라이언트를 active trader 에게 제공한다. Netscape™ Communicator 와 MS Outlook 등의 이메일 클라이언트는 웹 기반 이메일 포털에 비해 훨씬 더 사용자 친화적이다.

HTML 프론트 엔드를 개발하기 위해 Java 를 사용하는 것은 현명한 일이다. 왜냐하면 HTML 이 플랫폼에 구애 받지 않으면서 컨텐트를 전달하고 보여줄 수 있듯이 Java 서블릿과 JSP를 사용하면 거의 모든 환경의 운영 체제에서 실행될 수 있는 서버 단 로직을 개발할 수 있다. 풍부한 Java API와 웹 서버 및 애플리케이션 서버 벤더들이 Java 를 지원하고 있다는 점을 고려할 때 Java 는 확장성 있는 (scalable) 웹 싸이트를 구축하기 위한 최상의 선택이다.

요약하자면, 서브릿을 사용하는 HTML 프론트 엔트는 static 컨텐트를 개발하기 위한 아주 좋은 방법이다 (그리고 당부하건데, 페이지 디자인은 제발 전문 디자이너에 맡기도록 하자). 그러나 이 thin 클라이언트는 유저의 액션에 재빨리 리스펀스를 보내야 한다거나 데이터를 빠르게 조작하는 복잡한 로직을 사용할 때는 그리 좋은 성능을 제공하지 못한다.

Swing GUI Client

AT&T 의 자회사인 Telecorp PCS 사는 자사의 점포와 키오스크에서 휴대폰을 구매하고자 하는 고객들이 제공한 정보를 저장하고 이들의 신용 정보를 조회하며, 그 자리에서 휴대폰을 개통해 줄 수 있는 애플리케이션을 개발해야 했다. 이 클라이언트 애플리케이션은 유저 인풋이 정확한지를 검증하는 작업 외에도 분류, 필터링 및 그 밖의 표준 테이블 기능을 가진 인터렉티브 보고서를 만들어 낼 수 있어야 했다. 거기다 고객에게 휴대전화가 개통되었다는 사실을 인스턴트 메시지로 통보하고 이를 디스플레이 해야 했다.

이를 HTML 로 구현할 수 있을까? 가능하긴 하지만, 구현하기가 까다롭고 늘 네트워크를 사용해야 하기 때문에 개발 속도가 느려진다. 그래서 개발 팀은 자바를 사용하여 자바가 원래 의도했던 것 - 인터렉티브 애플릿 - 을 구현해 보기로 했다. 결과는 대성공이었다. 이 애플릿은 Swing 을 사용하여 개발되었고 Java Plugin을 사용해 배포되었다. Swing UI 클래스를 사용하여 유효하지 않은 인풋이 들어오면 그 자리에서 이를 점검하고 사용자가 계속 진행할 수 있거나 진행할 수 없을 때 활성화되고 비활성화 되는 버튼과, 칼럼의 헤더를 클릭하기만 하면 자동으로 분류되는 표(테이블)를 손쉽게 만들 수 있었다. 그리고 인스턴트 메시지는 다이얼로그 창을 생성하는 RMI callback 으로 처리했다. 물론 사용자들은 대단히 만족스러워 했다.

여러분 대부분이 Java 를 처음 배울 당시 애플릿을 사용해 본 경험이 있을 것이다. 우리는 브라우저마다 나타나는 차이와 애플릿 다운로드 시간, 성능 그리고 그 밖의 모든 문제들을 해결하느라 많은 시간과 노력을 허비했었다. 클라이언트 단 자바에 대한 비판은 거의대부분 객관적인 의견들이다. 그렇지만, 확실히 많은 것이 변화했다. 썬 마이크로 시스템즈 사는 자바의 코드와, 더불어 우리의 삶을 향상시키기 위해 많은 노력을 기울였다. 이제부터 Swing UI 를 사용하는 것이 왜 고려해 볼만한 옵션인지 설명하겠다.

Swing and its Deployment Models

대부분의 Swing 모델은 다양한 UI 요소들에 의해 공유된다; 가령, JTable 은 JList 와 JTree 가 사용하는 것과 동일한 selection 모델을 사용한다. 이런 점 때문에 Swing 은 배우고 사용하기가 쉽다. Command, Observable, Listener 등의 패턴은 유연성과 바람직한 객체 지향 디자인을 제공한다. 아마도 Swing의 유일한 구조상의 단점이라면 모든 이벤트가 하나의 EventDispatch 스레드에 전달되기 때문에 전체 GUI 클라이언트가 단일 스레드로 실행되게 만든다는 점일 것이다. 그렇지만 EventDispatchThread 대신에 다른 스레드를 사용해 유저 명령에 리스펀드하게 만들면 이런 단점도 쉽게 극복할 수 있다.

모든 출시된 JDK 는 Java 와 Swing 을 향상시킨다. JDK 1.3에서 Swing 과 관련해서 의 가장 중요한 개선점은 성능과 메모리 점유 및 인풋 유효성 점검 프레임워크 (input validity framework) 이다. 성능과 메모리의 향상은 놀라울 정도이다. 필자의 회사에서 사용하는 클라이언트를 JDK 1.2.2 에서 1.3으로 변경하고 나서 메모리의 사용이 적어도 30% 이상 감소했다; 몇몇 애플리케이션은 훨씬 더 많은 메모리 절감 효과를 볼 수 있었다. Swing 의 내부 초기화가 최적화되기 때문에 우리가 사용하는 클라이언트가 훨씬 더 빠르게 실행되고 반응할 수 있다. 간략하게 말하자면, anonymous 인터페이스 구현에서 생성한 너무 많은 수의 클래스를 자동으로 로딩하는 것이 속도에 지장을 주는 가장 큰 요소였다. 이에 대한 해결책은 reflection 메커니즘에 의존하는 한 클래스가 적절한 구현 프록시를 생성하도록 만드는 것이었다. 또 한가지 주목할 만한 변화는 GUI drawing 과 클라이언트 단 실행에 최적화되어 있는 HotSpot Client VM이 디폴트 VM 으로 사용된다는 것이다. 명령 프롬프트에서 java -version 을 실행하면 디폴트 JVM 에 대한 정보를 얻을 수 있다.

input validity framework 를 사용하면 mandatory 필드 또는 엔트리 validation 을 손쉽게 프로그램할 수 있다. 과거에는 사용자가 다음 필드로 넘어가기 전에 제대로 값을 입력했는지 확인하기 위해 해당 컴퍼넌트에 listener 를 달아야 했고, and every time that component lost focus you would validate and possibly restore the focus. 처리하기가 번거롭고 따분한 일이었다. 새로이 InputVerifier 클래스가 추가된 덕분으로 이제는 InputVerifier 서브클래스의 인스턴스를 생성하고 validate 가 필요한 JComponent 에 이 인스턴스를 설정함으로써 똑같은 효과를 얻을 수 있다. 이 컴퍼넌트는 focus 가 이동하도록 허가하기 전에 verify() 메서드를 자동으로 호출할 것이다.

Swing은 초기부터 배포시의 속도와 호환 불가능성의 문제를 안고 있었다. 그러나 그간의 현격한 발전 덕분에 이런 문제를 충분히 해결했고 Java 클라이언트는 효과적인 방법으로 다시금 부상했다. CPU 속도가 지난 2~3년간 거의 두 배 이상 증가했다. JDK 1.3 에서 Swing 애플리케이션은 훨씬 더 빨리 실행되고 더 작은 양의 메모리를 소모한다. 그래도 아직 남아 있는 문제가 있는데 이는 바로 배포이다. 배포에 관해서는 세 가지 옵션이 있다.

Java Plugin

<HTML>
<HEAD>
<TITLE>My traditional applet page</TITLE>
</HEAD>
<BODY>
<APPLET CODE=HelloWorld.class ARCHIVE=
HelloWorld.jar>
Sorry, looks like I bumped into another browser that 
doesn't support Java applets
</APPLET>
</BODY>

이 방식은 HelloWorld 클래스를 로드하고 실행하기 위해 브라우저 JVM 에 의존해야 한다는 문제점이 있다. 시중에 다양한 브라우저가 출시되어 있고 이들이 각기 다른 방식으로 Java 를 구현하기 때문에 애플릿 배포가 매우 까다롭다. 그렇다면 쉬운 해결책은 뭐가 있을까? 우선, 반드시 여러분이 테스트를 해 본 JVM 에서 실행해야 한다. 브라우저가 Java 를 실행하도록 요구하는 대신, 애플릿을 실행할 JVM 을 설치하고 실행하도록 요구해야 한다. Internet Explorer (IE) 에서는 <OBJECT> 태그를 사용하면 되고 그 밖의 브라우저에서는 각기 다양한 태그를 사용하는데, Netscape Navigator의 경우에는 <EMBED> 태그를 사용하면 된다. 이제 수정된 페이지를 살펴보자 :

<HTML>
<HEAD>
<TITLE>My new applet page</TITLE>
</HEAD>
<BODY>
<OBJECT classid="clsid:8AD9C840-044E-11D1-
B3E9-00805F499D93" 
 width=100% height=100
 codebase=
"./j2re-1_3_0_02-win.exe#Version=1,3,0,2">
   <param name=
"code" value="HelloWorld.class">
   <param name=
"archive" value="HelloWorld.jar">
   <param name=
"cache_archive" value="HelloWorld.jar">
   <param name=
"cache_option" value="Plugin">
</OBJECT>
</BODY>

플러그인은 모든 플랫폼에서 모든 브라우저를 지원해야 하는 부담을 덜어준다는 매력이 있다. 거기다 보장된 실행 환경을 얻을 수도 있다. 플러그인은 한번만 설치하면 되고 모든 애플릿을 cache 하기 때문에 재실행 시에 많은 자원을 소모하지 않는다. 이 방식의 가장 큰 담점은 사용자들이 애플릿을 실행하기 전에 5MB 크기의 플러그인을 다운받아야 한다는 것이다. 회선이 느린 사용자들에게는 부담스러울 수도 있다. 여러분이 만든 애플릿이 5KB 크기의 웹페이지 상에 조그맣게 나타나는 시계인데, 그것을 실행하기 위해 5MB 의 플러그인을 다운받는 것이 비합리적으로 느껴질 수도 있기 때문이다.

Java Web Start

필자의 경험에 의하면 Java Plugin 이 관리자나 사용자를 덜 귀찮게 하기 때문에 Java Web Start 에 비해 설정하기가 더 간단하고 더 사용자 친화적이다. 몇몇 회사에서는 이와 비슷한 일을 하는 (어떤 경우에는 Java Web Start 보다 뛰어난 성능을 제공하는) 배포 툴을 자체적으로 개발하고 있다. 가령, Sitraka의 DeployDirector 는 Java Web Start의 성능을 향상시켜 설치를 보다 간편화했다.

요약하자면 Java Plugin 과 Java Web Start를 사용하면 Swing 애플릿의 배포가 예전보다 훨씬 더 간편하고 안전하게 진행될 수 있지만 JavaScript 가 포함된 HTML 을 클릭하는 것 보다는 더 많이 관여한다. 어떤 사용자들은 컴퓨터에 JVM 을 설피하는데 필요한 과정을 거치는 것이 두려워서 Swing이 제공하는 이점들을 경험하지 못할 수도 있다. 그렇지만 여러분이 사용자에게 유연성을 제공하는 동적 GUI 인터페이스를 만들어야 한다면 Swing 애플릿을사용하는 것 이상의 좋은 방법은 없다.

또한, 전체 배포가 Java 로 되어 있다면 HTML 리퀘스트 데이터와 여러분의 내부 스트럭쳐 관에 mapping이 존재하지 않는다. RMI 는 네이티브 데이터를 옮길 수 있는 빠른 속도의 round-trip 네트워크 call 을 제공한다. 또한 클라이언트에 callback 을 구현하여 서버의 리퀘스트가 있을 때 사용자에게 이를 통보하거나(prompt?) 스크린을 업데이트할 수 있다.

Deploying Swing as Pure HTML

WebCream 은 Java 툴로써 GUI 기반 Java 애플리케이션 및 애플릿에 자동화된 Web-enabling을 제공한다. WebCream 은 AWT와 Swing을 사용하는 GUI front end를 구현하는 동시에 그 애플리케이션으로의 HTML 액세스를 자동으로 얻을 수 있게 해 준다. 어떤 면에서 WebCream 은 Java 플레임과 다이얼로그를 그 즉시 HTML로 변환하는 동적 Java-to-HTML 변환기라고 볼 수도 있다. 다음으로 WebCream 은 애프리케이션의 본래 로직을 유지하기 위해 Webpage 액션을 GUI 이벤트로 emulate 한다. WebCream은 기존의 형식과 비즈니스 로직에 어떠헌 수정도 필요로 하지 않으며 여러분이 새로운 API 를 배워야 할 필요가 전혀 없다. WebCream은 기존의 애플리케이션과 애플릿을 publish할 목적으로 설계되었다; 즉, 여러분이 사용하는 웹 서버와 해당 애플리케이션을 설명하는 프로퍼티 파일을 설정하기만 하면 된다. 나머지는 WebCream이 다 처리한다. 스탠다드 에디션이 모든 기능을 제공하며, 무료로 다운로드 받을 수 있다. WebCream은 클라이언트 장비에 설치할 필요가 없다; 사실 Java 를 지원하기 위한 브라우저 조차도 필요없다. 왜냐하면 브라우저에게는 HTML 밖에 보이지 않기 때문이다.

WebCream 기능은 꽤 독특하다 - 필자가 아는 바에 의하면 아무도 WebCream과 같은 솔루션을 제공하지 않는다. 그렇지만 몇 가지 제품들이 다른 방식을 사용해서 Web 용으로 개발되지 않은 Web-enabling 애플리케이션들에 WebCream 유사한 기능을 제공하기는 한다. Windows 2000 에는 Terminal Server 서비스가 있는데, 이 서비스는 사용자가 마치 로컬에서 로그인 한 것처럼 원격으로 서버에 액세스하도록 해 준다. Citrix Systems' MetaFrame과 마찬가지로 Terminal Server는 원격 터미널에 비디오 스트림을 전송하고 서버에서 실행중인 애플리케이션들에 사용자 액션을 emulate 한다. 상대적으로 빠른 네트워크 상에서 매우 잘 실행되지만 네트워크의 속도가 느리다면 좀 까다로워질 수도 있다. 또한 네이티브 drawing 과 scrolling 루틴을 사용하지 않기 때문에 Java 애플리케이션에서 문제를 야기하기도 한다. 그리고 Terminal Server 는 각 사용자에게 개별 복사본을 제공하는 형태이기 때문에 확장성에서 떨어진다.(Terminal Server is also not very scalable because each user is essentially given an individual copy of the application). WebCream에서 제공하는 애플리케이션은 로컬 장비에서 실행되는 애플리케이션과 형식상 다르지만 사용자가 어떤 페이지를 submit할 때만 서버에 액세스 하기 때문에 훨씬 더 나은 성능을 제공한다. WebCream-enabled 애플리케이션을 사용하는 모든 사용자들은 JVM을 공유할 수 있고 이는 자원의 소비를 크게 줄일 수 있다.

WebCream이 어떻게 실행되는지 보여주기 위해 아래에 나온 도표들은 WebCream이 사용되었을 때 샘픔 GUI 애플리케이션이 HTML 내에서 어떤 모습을 보이는 지를 제시하고 있다. 왼쪽 도표는 실행중인 GUI 애？리케이션 (소스) 를 보여주고, 오른쪽 도표는 WebCream이 똑 같은 애플리케이션을 관리하는 모습을 보여준다. 여기서 각 윈도우는 브라우저 상의 페이지로 나타난다.

도표 1. 샘플 GUI 애플리케이션	도표 2. WebCream과 함께 사용된 샘플 GUI

이 Swing-HTML bridge 가 모든 클라이언트에게 다 적용되지 않을 수도 있지만, WebCream은 HTML을 통한 액세스를 Swing 기반 프론트 엔드에 제공함으로써 그 가치를 높여준다. 일반적으로 애플리케이션 중 95퍼센트 정도가 HTML로 아무 문제없이 변환되고, 나머지 5퍼센트에 대해서는 데이터가 보여지는 방식이나 처리되는 방식을 수정해야 할 수도 있다. WebCream에 대한 더 자세한 정보는 Resources 를 참고하기 바란다.

Emerging Choice : XML/XSLT-Based Client

XML 이 데이터를 publish하고 서로 다른 프리젠테이션 모델을 생성하는 깔끔한 모델을 여러분에게 제공하기는 하지만 그렇다고 해서 XML 이 만병통치약은 아니다. XML은 디자이너와 아티스트가 프리젠테이션을 처리하는 동안 개발자가 데이터에만 신경을 쓸 수 있도록 해 준면에서는 극찬을 받을 만 하다. 애플리케이션은 메모리에 저장되거나 디스크에 저장되는 XML 데이터 파일을 생성한다. 가령 HTML 과 같은 특정 타입의 프리젠테이션을 제공하기 위해서 적절한 XSLT 스타일쉬트를 사용해 컨텐트를 변형(transform)한다. 스타일쉬트는 XML문서에 적용되어 HTML 문서를 만들어 낸다. 스타일쉬트는 문서로부터 어떤 데이터가 나와서 페이지상에서 어디에 디스플레이 되는 지를 결정한는 템플릿과 유사하다. 스타일쉬트와 템플릿 둘 다 데이터를 변형하고 조건 문을 실행하며 데이터를 manipulate하기 위해 루프를 실행하고 결정을 내린다. 처리하기가 매우 복잡해 질 수도 있다.

만약 동일한 애플리케이션에 휴대폰으로부터의 액세스를 제공해야 할 경우에 여러분은 단지 새로운 WML 스타일쉬트만 만들면 되는 장점이 있다. 이론상으로는 애플리케이션의 그 밖의 다른 부분이 수정될 필요가 없기 때문에 서버단 프로그래밍이 매우 효율적으로 진행될 수 있다. XML을 사용하는 프론트 엔드를 구현하는 것은 branding, personalization 및 customization 등의 작업을 매우 간편하게 만든다. 왜냐하면 디스플레이될 데이터와 이를 처리하는 코드가 수정될 필요가 없기 때문이다. 개발팀의 구성원이 독립적으로 각자 맡은 일에 매달리면 되기 때문에 개발의 속도를 향상시킨다.

그러나 필자는 몇 가지 문제점을 경험한 바 있으며, 이 때문에 XML 기반 클라이언트의 새 버전이 출시되었지만 이를 사용하지 않게 되었다. 두 가지 간과할 수 없는 단점으로는 XML 생성과 스타일쉬트 개발을 돕기 위한 툴이 부족하다는 것과 프로세싱 스피드가 느리다는 것이다. 첫번째 단점은 특히 DreamWeaver 와 FrontPage 등의 visual HTML 툴을 사용하여 HTML 페이지를 디자인하는데 익숙한 이들에게는 큰 문제가 된다. 개인적으로 필자는 아직도 때때로 DreamWeaver로 생성된 코드를 browse through하고 수정하길 좋아한다. (FrontPage는 잘 사용하지 않는다). 그렇지만 필자는 HTML을 텍스트 편집기로 처음부터 코딩하는 것에는 별반 재미를 느낄 수 없다; 어쨌든 지금은 21세기가 아닌가. 이제 간단한 XML 문서를 HTML로 변형하기 위해 사용되는 매우 간단한 XSLT 스타일쉬트를 보여주겠다 :

<xml version="1.0">
<xsl:stylesheet version="1.0" xmlns:xsl=
"http://www.w3.org/1999/XSL/Transform">

<xsl:template match="page">
<html>

<head>
<title><xsl:value-of select=
"title"/></title>
</head>

<body>
<xsl:apply-templates/>
</body>
</html>
</xsl:template>

<xsl:template match="title">
<h1><xsl
:apply-templates/></h1>
</xsl:template>

</xsl:stylesheet>

<html>
<head>
<title>My first page</title>
</head>

<body>
  <h1>Hello, world</h1>
</body>
</html>

두번째문제는 모든 단계를 런타임에 수행하는 데 시간이 많이 걸린다는 것이다. XML 외의 다른 저장방식 (storage) 을 사용한다면 여러분은 우선 XML 문서를 생성하는 것에서부터 시작할 것이다. 그러면 적절한 스타일쉬트가 적용되어 여러분이 실제 결과물인 HTML 페이지를 생성하기 전에 필요한 모든 변형을 처리할 것이다. 이를 서블릿이나 JSP 내의 메모리 버퍼에 최적화된 방식으로 저장하는 것과 비교해 보면 필자가 무슨 말을 하고자 하는지를 금방 알 수 있을 것이다. 속도와 단순성은 오늘날의 기술의 관점에서 XML 기반 프론트 엔드가 제공할 수 있는 장점이 되지 못한다.

요약하자면 다양한 레이아웃과 form을 사용하는 프리젠테이션을 동적으로 생성하고자 할 때는 XML을 사용하라. 프리테이션 포맷이 자주 변경되거나 또는 유연성을 제공해야 한다면 프리젠테이션 디자이너가 새로운 스타일쉬트를 만들도록 하는 것이 더 쉬울 수 있다; 디자이너는 오직 XML 와 XSLT에 대해서만 알고 있으면 된다는 사실을 기억하자.

여러분의 데이터가 네이티브 Java 타입과 객체, 또는 관계형 데이터베이스의 형태로 오는 것이 아니라 XML의 형태로 오는 경우에도 XML 기반 UI를 잘 활용할 수 있다. XML은 향후의 Web 에서 확실한 자리매김을 할 수 있는 가능성이 큰 신규 기술이다. 그러나 오늘날 프리젠테이션을 위해서는 JSP를 사용하는 HTML을 개발하는 것이 훨씬 간편하다. 특히 여러분이 사용할 수 있는 프론트 엔드가 HTML 밖에 없을 경우에는 더욱 그러하다. JavaBeans 와 JSP 용 태그 라이브러리 등의 잘 알려진 디자인 패턴을 사용하면 컨텐트와 프리젠테이션을 XML/XSLT가 하는 것과 거의 동일한 수준으로 분리해 낼 수 있다. 그리고 훨씬 더 빨리 실행될 수 있다. XML/XSLT 편집을 자동으로 처리하는 기술이 출시되면서 이 기술도 사용하기에 훨씬 더 간편해 질 것이다.

Conclusion

HTML/JSP 를 사용하라 :

- 그래픽과 예술적인 내용이 많이 들어간 상대적으로 정적인 컨텐트일 때 .

- 인터페이스가 서로 다른 소프트웨어를 실행하는 모든 유저 타입을 지원해야 할 때

- 사용자의 네트워크 속도가 느릴 때

- 그다지 정교하지 않은 애플리케이션을 빠르게 개발해야 할 때

Swing을 사용하라 :

- built-in, 인터페이스 관련 로직을 가진 매우 인터렉티브한 GUI 일 때

- 네트워크 체증을 줄이고 가능할 때 즉각적인 리스펀스를 제공하고자 할 때

- 사용자가 인터페이스의 품질과 기능에 대한 기대치가 높을 때

- UI의 기능이 보여지는 아름다움(aesthetics) 보다 더 중요할 때

- 프리젠테이션에서 여러가지 다양한 형태의 자주 변경되는 form을 지원해야 할 때

- 데이터가 XML 내에서 네이티브하게 저장되고 조회될 때 (obtained)

- branding과 정교한 personalization을 지원해야 할 때

- 무선 액세스 등, 다른 방식의 UI 를 제공하려는 계획이 있다면

About the Author

Resources

- Java Plugin 에 대한 정보는 : http://java.sun.com/products/plugin

- Java Web Start Application Manager에 대한 정보는 : http://java.sun.com/products/javawebsta ··· ure.html

- WebCream과 그 기능에 대한 자세한 정보는 : http://www.creamtec.com/webcream

- Citrix Systems의 MetaFrame에 대한 정보는 : http://www.citrix.com/

- "The Magic of Merlin": Find out how the new JDK 1.4 -- code-named Merlin -- levitates its functionality, Vinay Aggarwal (March 16, 2001)

- "Jato: The New Kid on the Open Source Block, Part 1": Discover a new library for converting between Java and XML, Andy Krumel (March 16, 2001)

- "Jato: The New Kid on the Open Source Block, Part 2": Look in-depth at Java-to-XML translation, Andy Krumel (April 13, 2001)

- "Java Tip 109: Display Images Using JEditorPane": Modify the JEditorPane component to display images without a document base, Rob Kenworthy (March 16, 2001)

- "Dodge the Traps Hiding in the URLConnection Class": Alleviate snags caused by the URLConnection class design, Michael C. Daconta (March 23, 2001)

- JavaWorld를 주제별로 보려면 :

http://www.javaworld.com/javaworld/topi ··· dex.html

- ITworld.com의 자바 포럼에 의견을 개진하려면 :

http://www.itworld.com/jump/jw-0420-swi ··· .ee6b802

- JavaWorld This Week 및 그 밖의 무료 Java 뉴스레터를 구독하려면 :

http://reg.itworld.com/cgi-bin/subcontent12.cgi