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

다른 원인일 수도 있습니다.

하지만, 저 메시지가 뜬다면 win32k.sys(0X00000050) 한번쯤 메모리 테스트 해보는 수도 있습니다.

테스트 프로그램은
1. windiag(http://oca.microsoft.com/ko/windiag.asp#top) -> 자료실 15번
2. memtest86 3.4a(http://memtest86.com/ -> Free Download)
3. memtest86 2.1(http://memtest.org -> Download(Pre-built & ISOs))
4. memtest 3.7(http://hcidesign.com/memtest/download.html) -> 자료실 57번(신기센터장님)
    (버전 업이 되어서 3.7까지 올라갔네요..)

몇군데는 usb용도 존재하네요..

입맛에 맞게 사용하세요..


오늘 며칠전에 출고한 컴인데, 고객이 자꾸 파란화면이 뜬다고 해서 오늘 입고처리했습니다.
(그땐 이상없이 동작해서 윈도우도 깔고, 가져다 준건데....)

메모리 테스트를 해보았는데, 오류 메시지를 듬뿍~!! 쏟아내더군요..

메모리 교체후 몇시간 테스트해보고 있지만, 현재까진 이상이 없네요..

참고하세요..
[출처] [Tip] win32k.sys 덤프가 뜰 경우..(메모리 테스트 프로그램들)|작성자 제우스신

자아.. 요즘에는 지식에 목이 말라서..
열심히 배울려고 자료를 찾고 있다..
음음..
디버깅 관련 문서를 보고 있는데..
http://msdn2.microsoft.com/en-us/library/ms954590.aspx
요놈을 보다가..
adplus 에 대해서 알게 되었다..
아무튼..
프로세스 상에 떠있는 놈을 덤프를 뜰수 있다..
옵션은 대충 hang, crash 의 옵션이 있는데..
hang 을 통하여 덤프를 뜨게 되면..
메모리의 대용을 그대로( hex ) 화일로 덤프를 뜨게 된다..
음.. 머 저걸로 분석을 한다는건 다른 문제지만..
그래도 일단은 통으로 덤프를 뜰수 있다는 정도..
아.. 그리고 한가지..
덤프를 뜨면서.. 프로그램과 함깨 로드된 모듈의 정보도 같이 나타나게 된다..
음음..
조금더 자세한 사항들은 더 연구를 해봐야.. 흐흐..
자아.. 이건 adplus 에 대한 문서..
http://support.microsoft.com/default.aspx?scid=kb;en-us;q286350
http://support.microsoft.com/default.aspx?scid=kb;en-us;q286350
덤프를 뜨는 예제..
adplus -hang -pn process.exe -o c:\dir\newdir
요래하면 된다..
[출처] 프로그램 덤프 뜨기...|작성자 베타

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

어렸을 때 뮤직 컴포넌트를 처음보고 검은색 레코드 판에서 음악이 흘러나온다는 것보다는 서로 다른 기능을 하는 기기들이 선으로 복잡하게 연결되어 하나의 훌륭한 음악을 만들어 낸다는 것에 감동했습니다. 프로그래밍을 하면서 문득 프로그램도 뮤직 컴포넌트처럼 서로 연결해 새로운 프로그램을 만들 수 있다면 좋겠다고 생각했습니다. 그러던 어느 날 컴포넌트 프로그래밍이라는 것이 있다는 사실을 알았을 때 무척이나 흥분됐습니다. 객체지향 궁합도 잘 맞을 것 같다는 생각이 들었습니다. 과연 그럴까요?

우리나라에서도 컴포넌트에 대한 관심이 많이 높아지고 있습니다. 이것은 객체지향과 더불어 하나의 새로운 패러다임이라고도 합니다. 컴포넌트는 소프트웨어를 이제까지처럼 계획, 설계, 분석, 구현, 테스트하는 순차적인 개발 과정으로 보는 것이 아니라 레고 블럭이나 자동차 부품처럼 조립하는 개념으로 간주하기 때문에 현재 IT 산업을 이루고 있는 기존 틀과 구조를 가내 수공업 형태에서 ‘표준화’하고 ‘산업화’하는 데 그 의미가 있다고 하겠습니다.
이러한 컴포넌트는 인터넷이라는 환경의 부상으로 더욱 강력한 위치를 차지하게 됐습니다. 그것은 개발자에게도 새로운 개발 환경을 이해하도록 요구하고 있습니다. 컴포넌트 프로그래밍에서는 특정한 환경의 국소적인 이해보다는 시스템에 대해 전체적으로 이해할 수 있어야만 좋은 프로그램을 제작할 수 있습니다. 하지만 컴포넌트를 쉽게 이해할 수 있는 방법이 마땅히 있지 않습니다. 이번 연재에서는 객체지향과 컴포넌트를 연계해서 이해하고 간단하게 컴포넌트 환경을 살펴보겠습니다.

컴포넌트의 등장
컴포넌트라 함은 말 그대로 서로의 인터페이스를 연결하면 하나의 시스템으로 동작할 수 있는 환경의 구성 요소를 의미합니다. 몇 가지 컴포넌트의 결합으로 새로운 소프트웨어를 만들 수 있다는 생각은 그리 새로운 것은 아닙니다. 실제 우리 생활에서도 뮤직 컴포넌트처럼 서로 공통의 인터페이스로 연결해 새로운 시스템을 만드는 경우가 많습니다. 어릴 적 즐겨 가지고 놀았던 합체 로봇도 컴포넌트 시스템입니다. 그리고 비디오, 오디오, TV로 만드는 AV 시스템 역시 훌륭한 컴포넌트 시스템의 예입니다. 서로 다른 기능을 하는 두 요소를 결합해 새로운 기능을 만든다면 그것을 컴포넌트 시스템이라고 말할 수 있습니다.
우리가 사용하는 컴퓨터 시스템도 또 다른 컴포넌트 시스템의 예입니다. 컴퓨터 시스템은 컴퓨터 본체, 모니터, 키보드, 마우스, 스피커로 구성되고 사전에 규정된 모니터 케이블, PS/2 마우스, 키보드 포트, 오디오 잭 등을 통해 컴포넌트의 결합을 이룹니다. 하드웨어적인 컴포넌트는 표준화를 통해 산업화하는 하나의 전형적인 메커니즘입니다.
소프트웨어에서도 컴포넌트라고 하면 마찬가지 개념으로 생각해 볼 수 있습니다. 소프트웨어에 있어서 컴포넌트라는 개념은 RAD 툴의 등장과 더불어 탄생했다고 할 수 있습니다. RAD 툴의 등장 자체가 프로그래밍의 산업화 과정이라고 할 수 있습니다. 물론 소프트웨어 컴포넌트라는 개념이 갑자기 만들어진 것은 아닙니다. 이미 컴포넌트 이전에 라이브러리가 그러한 기능을 하고 있었습니다. 사전에 필요한 함수들을 만들어 놓고 프로그래밍에서 활용할 수 있도록 만들어 두는 것이 라이브러리인데, 컴포넌트를 이해하기에 앞서 우선 라이브러리를 이해하는 것이 좋습니다.

소프트웨어 라이브러리
소프트웨어 라이브러리는 매우 중요한 프로그래밍 자원으로 프로그래밍에 자주 쓰이는 함수나 클래스를 함께 묶어놓은 것입니다. 라이브러리 안에 있는 코드를 사용하기 위해서는 필요한 함수나 클래스의 사용법을 미리 숙지하고, 정의된 인터페이스를 통해 프로그래밍 모듈을 작성하고, 컴파일 과정에서 라이브러리와 작성한 모듈을 링크하는 작업이 필요합니다.
라이브러리를 많이 가지고 있는 친구는 빠르게 프로그램을 완성할 수 있는 반면에 라이브러리를 가지고 있지 않거나 기본적으로 언어 개발 툴에서 제공하는 라이브러리를 잘 이해하지 못하는 경우에는 이미 라이브러리에 있는, 그러나 본인은 알지 못하는, 함수를 직접 구현하기 위해 많은 시간을 소비하면서도 프로그램을 완성하지 못하기도 합니다.
기껏 만들고 있으면, 다른 친구가 “야, 이건 이미 기본 라이브러리에 있는 기능이야”라고 말해 당사자를 실망하게 만듭니다. 상황이 이렇다 보니, 한때는 소프트웨어 개발자들이 가지고 있는 소프트웨어 라이브러리의 양이 좋은 개발자와 나쁜 개발자로 나누는 기준이 되기도 했습니다.
일부 개발자 중에서는 편집광적으로 소프트웨어 라이브러리를 모으는 경우도 쉽게 찾아볼 수 있었습니다. 하지만, 개발 툴이 커지고 대규모가 되면서 대부분의 필요한 라이브러리들은 개발 툴에 포함되어 제공됐습니다. 최근에는 개발 툴이 제공하지 않는 추가적인 라이브러리를 이용하는 비중은 틈새시장 정도로 무척이나 작아졌습니다. 그만큼 소프트웨어 라이브러리가 정형화됐다고 할 수 있습니다. 하지만, 여전히 라이브러리에 대한 충분한 사전 지식 없이 소프트웨어 라이브러리를 쉽게 사용한다는 것은 어려운 일입니다.

컴포넌트와 라이브러리
인터넷의 보급과 더불어 누구나 쉽게 라이브러리를 인터넷에서 찾아 사용할 수 있게 됐고 부담 없는 수준에서 라이브러리를 구입할 수 있습니다. 그리고 오픈 소스 정책으로 인해 많은 라이브러리 소스가 공개되면서 라이브러리의 가치는 지속적으로 떨어졌습니다. 하지만 이것은 다른 한편으로 게으른 개발자를 양산했습니다. 그냥 모든 것은 인터넷에 있다고 생각하는 나머지 라이브러리 사용법조차 알지 못하는 개발자가 많아진 것입니다.
이러한 문제점을 새롭게 해결하고자 나온 것이 바로 컴포넌트입니다. 컴포넌트는 컴포넌트 스스로가 어떤 인터페이스를 가지고 있는지 개발자에게 알려줄 수 있습니다. 그리고 속성을 변경해 자신의 초기값을 조정할 수 있기 때문에 커스터마이징이 쉽습니다. 이러한 사용자 환경이 만들어낸 것이 애플리케이션을 빠르게 제작할 수 있는 RAD 툴입니다. RAD 툴 안에서는 미리 작성되어 있는 컴포넌트들을 통해 애플리케이션을 쉽게 작성할 수 있습니다.
컴포넌트의 기본적인 개념은 소프트웨어 라이브러리와 유사합니다. 라이브러리가 사전에 필요한 코드를 작성해놓고 나중에 컴파일 과정에서 연결해 사용하는 것이라면, 컴포넌트는 사전에 정의된 컴포넌트 인터페이스를 만족하도록 작성되고, 이를 통해 프로그래밍 과정에서 연결해 사용할 수 있게 되어 있습니다. 따라서 컴포넌트의 동작 상황을 개발 당시에 확인할 수 있다는 장점이 있습니다. 그리고 대부분 비주얼한 컴포넌트를 제공하기 때문에 GUI까지 한꺼번에 해결해주기도 합니다.
최근에 나온 개발 툴은 대부분 자신들의 컴포넌트를 제공합니다. 하지만 컴포넌트가 단지 최신 라이브러리라는 의미는 아닙니다. 그것은 현재 시스템이 점점 복잡해지면서 시스템을 구축할 때 모든 기능을 새롭게 구축하면 비용이 많이 들기 때문에 필수적이고 복잡한 환경은 사전에 만들어 놓고 적용하려는 시스템에 따라 변화되는 부분만을 새롭게 작성하여 동작할 수 있도록 하는 데 사용하는 것입니다. 아마도 이것은 뮤직 컴포넌트 개념보다는 DVD 플레이어와 DVD의 관계라고 말할 수 있을 것입니다.

컴포넌트의 구성
그렇다면 소프트웨어 컴포넌트는 무엇으로 구성될까요? 컴포넌트는 우선 서로 다른 컴포넌트를 연결하는 입출력 인터페이스가 필요합니다. 그리고 기본적인 상태를 정의할 수 있는 프로퍼티가 있습니다. 컴포넌트는 잘 정의된 인터페이스를 통해 사전에 구현한 소프트웨어 모듈입니다. 예전에는 특정한 툴 환경에서만 의미 있는 컴포넌트들이 있었는데, 지금은 특정한 언어와 상관없이 사용할 수 있는 컴포넌트 구조들도 있습니다.
대표적으로 COM(Common Object Model)은 윈도우 환경에서 빼놓을 수 없는 핵심적인 컴포넌트 구조를 제공합니다. COM은 윈도우의 핵심 커널을 제외하고는 대부분의 환경에서 사용되는 모델입니다.
그리고 EJB(Enterprise Java Beans)는 자바 프로그래밍 언어를 통해 미들웨어를 구현할 수 있도록 제공하는 모델입니다. 트랜잭션, 보안, 데이터베이스 접속 등을 쉽게 이용할 수 있도록 하는 환경을 제공하고, 이를 컴포넌트화해 소프트웨어 모듈을 개발할 수 있게 하는 것입니다.

객체지향과 컴포넌트
객체지향은 소프트웨어를 행동과 상태 기반의 객체로 정의해 재사용성을 높이는 것이 목표입니다. 컴포넌트는 사전에 정의된 인터페이스를 통해 즉각 실행할 수 있는 컴포넌트로 생산하여 재사용성을 높이는 것입니다. 재새용성을 높인다는 것에 대해서는 그 목적이 동일하지만 접근 방법의 차이가 있다고 할 수 있습니다. 객체지향에서는 새로운 데이터 형을 작성하는 것부터 출발하는데, 컴포넌트는 잘 짜여진 인터페이스를 사전에 정의하고, 이를 통해 필요한 동작을 구현하는 것부터 출발합니다.

◆ 클래스 = 데이터 + 메쏘드
◆ 컴포넌트 = 특성 + 인터페이스 + 로직 + 이벤트

이와 같이 컴포넌트는 서로의 기능을 쉽게 연결할 수 있는 인터페이스가 가장 중요한 위치를 차지합니다. 객체지향과 컴포넌트가 만나는 위치는 인터페이스입니다. 컴포넌트의 인터페이스는 객체지향의 메쏘드와 유사합니다. 물론 객체지향 언어에서 메쏘드와 인터페이스는 엄밀한 의미에서 구별되지만 실제로는 그 기능이 비슷하다고 할 수 있습니다.
차이점은 인터페이스가 아니라 접근 방법에 있습니다. 컴포넌트는 컨테이너라는 컴포넌트가 동작할 수 있는 환경을 제공하고, 이 구조에 맞는 다른 컴포넌트들이 서로 연결되어 동작할 수 있게 해주는 개발 환경이라면, 객체지향의 기본 개념은 메쏘드 재정의나 클래스 확장을 통해 기존 클래스를 재사용할 수 있도록 하는 것입니다.

컴포넌트 소프트웨어 환경
컴포넌트는 크게 비주얼 컴포넌트와 미들웨어 컴포넌트로 나눌 수 있습니다. 비주얼 컴포넌트는 대부분의 RAD 툴이 제공하는 각종 UI와 이를 이용한 기능성 컴포넌트입니다. 반면에 미들웨어 컴포넌트는 미들웨어 위에서 동작하는 컴포넌트로 특별한 UI없이 동작할 수 있습니다. 최근 웹 환경 개발이 강화되면서 중요한 컴포넌트로 자리를 잡았습니다. 여기서 중요한 것은 비주얼 컴포넌트와 미들웨어 컴포넌트는 개념상 비슷하지만 그 내용은 크게 다르다는 것입니다.

비주얼 컴포넌트
비주얼 컴포넌트는 말 그대로 시각적인 컴포넌트입니다. 비주얼 컴포넌트 소프트웨어로는 델파이, 비주얼 베이직, 비주얼 에이지 등이 대표적입니다. 이들은 대부분 비슷한 GUI를 가지고 컴포넌트를 마우스를 통해 소프트웨어 폼에 쉽게 부착하고, 프로퍼티를 조절하고, 다른 컴포넌트와 연결해 새로운 소프트웨어를 만들 수 있습니다. 비주얼 컴포넌트는 대부분 사용자 인터페이스와 관련이 있습니다. 여기서는 이에 대해 구체적으로 다루는 것은 생략하겠습니다.

미들웨어 컴포넌트
미들웨어 컴포넌트는 시각적인 인터페이스를 제공하지 않는 컴포넌트입니다. 미들웨어 컴포넌트는 컴포넌트 환경이 제공하는 다양한 기능을 이용해 실제 데이터의 동작에 대한 로직만을 제공해 소프트웨어가 완성될 수 있게 합니다. 미들웨어 컴포넌트는 대부분 웹 인터페이스를 통해 사용자와 인터페이스하기 때문에 사용자는 웹 브라우저로 웹 서버에 접속하면 내부적인 미들웨어 컴포넌트에 의해 동작되는 결과들을 확인할 수 있습니다. 아마도 최근에 비주얼 컴포넌트보다 미들웨어 컴포넌트가 더 강화되는 이유가 이 때문이 아닐까 생각합니다. 미들웨어 컴포넌트의 대표적인 두 가지가 COM+와 EJB입니다.

COM+
COM+는 마이크로소프트의 MTS(Microsoft Transaction Server)의 최신 버전입니다. 1999년에 발표됐으므로 약 3년 정도의 시간이 지났습니다. COM+는 닷넷 기반의 애플리케이션과 COM을 하나로 묶는 것으로 관리 기능, JITA(Just-In-Time Activation), 객체 풀링, 트랜잭션 처리, 동기화, 보안, 컴포넌트 큐 관리, 이벤트 처리 등 다양한 기능을 제공합니다. COM+에는 다음과 같은 구성 요소가 있습니다.

◆ COM+ 대리 실행 모듈(dllhost.exe)
◆ COM+ 클래스 로딩 및 리모트 프레임워크(ole32.dll)
◆ 컨텍스트 오브젝트와 랩퍼 프록시
◆ COM+ 서버 컴포넌트
◆ COM+ 클라이언트
◆ COM+ 런타임, 서비스 컨트롤 관리자(SCM), 분산 트랜잭션 관리자(MS-DTC), 메시지큐(MSMQ), 트랜잭션 통합 관리자(COM-TI)
COM+는 조금 복잡한 동작을 요구합니다. 기본적으로 COM+ 서버 컴포넌트는 OLE32.DLL 및 DLLHOST.EXE로 구성된 컨테이너에 의해 호출되고, 다시 컨텍스트 객체에 의해 처리되도록 고안됐습니다. 이것은 COM+가 기존 MTS 및 다른 환경도 함께 수용할 수 있는 환경을 만들다 보니 더 복잡한 환경을 제공하는 것으로 보이지만 실제로는 기존 COM 환경에서 그리 많은 변화가 있던 것은 아닙니다.
COM+의 특징 중 하나는 스스로 자신을 설명할 수 있는 컴포넌트라는 점입니다. 이것은 프로퍼티와 달리 애트리뷰트를 제공합니다. 애트리뷰트는 컴포넌트에 런타임 특성을 설정할 수 있는 것을 의미합니다. 이것은 특정한 기능이 작동하도록 컴포넌트를 조절할 수 있는 기능입니다. 예를 들어, 데이터베이스 연결에 사용하는 문자열을 런타임 환경에서는 관리자에 의해 변화할 수 있는 값이 되는데 이것은 자바 환경에서 상태 저장·복원과 관련이 있는 것입니다.
COM+는 또한 큐 컴포넌트 기능을 제공합니다. 큐 컴포넌트는 컴포넌트와 애플리케이션의 상호작용이 실시간에 이루어지지 않더라도 큐를 이용해 컴포넌트가 다시 기동했을 때 상호작용이 다시 일어날 수 있게 하는 것입니다. 이벤트 메커니즘은 자바의 이벤트 리스너 모델처럼 다양한 이벤트 채널을 통해 이벤트를 전달할 수 있게 되어 있습니다. 이 밖의 다른 기능은 COM+의 참고자료를 이용하기 바랍니다.

EJB
EJB는 자바 표준 미들웨어 컴포넌트 구조입니다. EJB는 다음과 같은 구성요소로 이루어져 있습니다.

◆ EJB 서버
◆ EJB 컨테이너(EJB 서버 위에서 동작)
◆ EJB(EJB 컨테이너 위에서 동작)
◆ EJB 클라이언트
◆ 기타 구성 요소 : JNDI(Java Naming and Directory Inter face), JTS(Java Transaction Service)

이를 그림으로 표현하면 <그림 4>와 같습니다. EJB 서버는 CORBA의 ORB(Object Request Broker)와 비슷한 기능을 제공합니다. 시스템 실행환경을 제공하고, 멀티프로세싱, 부하분산, 장치제어, 네이밍 및 트랜잭션 처리 등을 제공하며, EJB 컨테이너를 올릴 수 있게 해줍니다. EJB 컨테이너는 EJB와 외부 세계의 인터페이스를 제공합니다. EJB 클라이언트는 결코 직접 EJB와 연결되지 않습니다. EJB를 연결할 수 있는 메쏘드를 EJB 클라이언트에 제공하는 것이 바로 EJB 컨테이너입니다.
EJB는 크게 두 종류가 있습니다. EJB의 상태가 지속적으로 유지되는 경우와 매번 초기화되는 경우가 있습니다. EJB의 상태가 유지되려면 가장 최근의 EJB 속성을 저장하거나 복구하는 기능을 제공해야 합니다. 이러한 기능은 EJB 컨테이너 인터페이스를 통해 EJB 서버가 제공합니다. EJB 클라이언트는 컴포넌트를 이용하는 주체이며, EJB는 컴포넌트 자체입니다. 이러한 구조는 대부분의 컴포넌트 구조의 특징입니다.
EJB는 EJB 클라이언트의 요청에 의해 그때마다 생성되는 세션 빈과 상태를 공유하는 엔티티 빈으로 나눌 수 있습니다. 엔티티 빈은 항상 상태를 가지고 있으며, 시스템이 동작하는 한 계속 살아있는 상태가 됩니다. 세션 빈은 상태를 가지고 있을 수도 있고, 상태가 없을 수도 있습니다. 이러한 상태 저장 및 복구는 그 주체가 누구이냐에 따라 컨테이너 관리형 상태 유지와 빈 관리형 상태 유지로 나눌 수 있습니다. 쉽게 이야기하면 저장 및 복구를 컨테이너가 하면 컨테이너 관리형 상태 유지이고, 저장 및 복구가 빈에 의해 수행되면 빈 관리형 상태 유지입니다. EJB는 *.ser 파일에 의해 동작 가능하도록 배치(deploy)할 수 있습니다. 이 파일은 다음과 같은 엔트리로 지정되어 동작합니다.

Name: ~bean/CompanyAccssRight.ser
Enterprise-Bean: True

컴포넌트의 미래
정보통신부는 컴포넌트 산업을 육성하기 위해 향후 3년간 공용 컴포넌트 개발은 물론 공용 컴포넌트 뱅크 마련, 컴포넌트 유통 시스템 구축, 컴포넌트 품질 평가 및 인증제도 확립, 컴포넌트 가격 산정 및 라이선스 규정 수립, 관련 인력 양성 등에 박차를 가할 계획이라고 합니다.
현재 국내 시장에 나와 있는 컴포넌트는 약 150종에 불과하지만 올해 말이면 1000개 가량의 컴포넌트가 개발될 것이라고 예견하기도 합니다. 현재 국내 신생 업체들을 중심으로 자바 컴포넌트 기술을 이용해 상용 애플리케이션을 개발하는 사례가 늘고 있으며 특히 전사적자원관리 시스템부터 개발 툴, XML 솔루션, 검색엔진, 통신용 소프트웨어, 인터넷 구축 툴, 언어처리 모듈, 지식관리, 고객관리 등의 분야에 이르기까지 다양한 분야에서 개발이 진행되고 있다고 합니다.
하지만 컴포넌트가 일반적인 개발 환경이 되기 위해서는 넘어야 할 과정이 많이 있습니다. 아직 교육 환경이 컴포넌트 개발 환경에 맞게 빠르게 제공되지 못하는 실정입니다. 대부분의 개발자는 전체 컴포넌트 환경을 이해할 수 있는 수준이 되지 못하고 있습니다. 그것은 소프트웨어 시장의 요구를 교육 환경이 미처 뒷받침해줄 수 없을 정도로 빠르게 변화하고 있다는 것을 의미합니다. 필자의 생각으로는 컴포넌트가 일반적인 개발 환경에 되려면 좀더 많은 시간이 필요할 것입니다. 객체지향이 20년이 지나서야 일반적인 개발환경이 되는 것을 보면 새로운 개념이 쉽게 보편화되지는 않기 때문입니다. 하지만 컴포넌트가 일반화되는 데 20년이 걸릴 것이라는 것은 아닙니다. 그보다 훨씬 빠른 시간에 도달할 것입니다. 하지만 이 자리에서 그 시기가 언제라고 언급하는 것은 별 의미가 없다고 생각합니다.

컴포넌트에 대한 깊은 이해와 적용 필요
컴포넌트와 객체지향은 밀접한 관계가 있다고 말할 수 없지만, 그 목적이 비슷하기 때문에 객체지향과 컴포넌트가 연결되는 다양한 시도가 있었습니다. 대부분의 개발 툴이 객체지향 언어를 지원하고 컴포넌트 구조를 제공함으로써 더욱 편리하게 프로그래밍이 가능하도록 하고 있습니다. 비주얼 컴포넌트는 대부분의 개발 툴이 제공하는 요소가 됐습니다. 하지만 이것은 특정한 개발 환경에서만 사용할 수 있는 경우가 많고, 대부분 웹 인터페이스를 사용하기 때문에 미들웨어 컴포넌트의 중요성이 더 커지고 있습니다. 미들웨어 컴포넌트는 윈도우 기반의 COM 계열, 자바 기반의 EJB 계열, OMG의 CORBA 계열이 있습니다.
이들을 간략하게 살펴보았는데, 실제 체계적인 학습 없이 빠른 시간에 컴포넌트 환경을 이해한다는 것은 매우 어려운 일입니다. 개발자들이 컴포넌트 환경을 이해하고 업무에 활용하기 위해서는 앞으로 많은 교육 기회가 주어져야 할 것으로 보입니다. 그런 의미에서 서로 다른 컴포넌트 환경은 경쟁자라기보다는 컴포넌트라는 하나의 거대한 목표를 향해 달리는 협력 주자라고 할 수 있습니다.

정리 : 송우일 wooil@sbmedia.co.kr
출처 : http://www.imaso.co.kr/