1 Linux More Popular as Deployment Platform

2 The Open Source Developer Report 2009

2.1 핵심 내용

• 리눅스는 데스크탑과 서버 환경모드를 공유하고 있다. 개발자들이 개발을 위한 데스크탑운영체제로 Microsoft 윈도우즈에서 리눅스와 Mac OX로의 이동하는 모습이 분명히 감지되고 있다. 특히 depolyment 운영체제환경으로 리눅스는 가장 일반적인 플렛폼이 되었다.
  
• Mysql 과 Oracle 데이터베이스는 55%이상의 지배적인 점유율을 보여주고 있다.
  
• 형상관리도구로는 SVN(Subversion)이 57% 점유율을 보여주고 있다.
  
• 기업은 성숙한 OSS 모델을 받아들이고 있다.
  
  1. 더 많은 기업들이 오픈소스 소프트웨어의 사용과 기여에 참여하고 있다. 보고서에 따르면 2008년 48.2%였다. 2007년에는 37%였다.
     
• 15.6 %의 회사가 OSS에 연계한 비지니스 모델을 만들고 있다.
  
  

3 보고서 참여자 통계 자료

4 개발자 데스크탑 개발 환경

1. Windows Server or Client : 64.3%
   
2. Linux : 26.9%
   
   1. Ubuntu 14.5%
      
   2. Fedora 3.4%
      
   3. SUSE 3.2%
      
   4. Debian 2.6%
      
   5. RHEL 1.3%
      
   6. 기타 배포판 1.8%
      
3. Mac OSX : 6.9%
   
4. Sun Solaris or OpenSolaris : 0.9%
   
5. Other : 0.8%
   

4.1 IDE : 통합개발 환경

1. Eclipse JDT : 60%
   
2. Eclipse PHP 개발 툴 : 12.6%
   
3. Eclipse C/C++ 개발 툴 - CDT - : 6.3%
   

4.2 형상관리 툴

5 언어 및 응용프로그램

5.1 Server-Centric 애플리케이션

5.2 Web, Rich 인터넷 애플리케이션

5.3 Rich Desktop Applications

6 Deployment 환경

6.1 주요 데이터 베이스

• Java를 주요 개발언어로 사용하는 경우
  
• server-centric 애플리케이션을 개발하는 경우
  
• Application 서버를 이용하는 경우
  
  

• PHP 언어를 주요언어로 사용하는 개발자
  
• RIA/Web 애플리케이션
  
  

6.2 주요 Application 서버

7 평가

저작권의 출현

문서는 완성된게 아니며, 틀린 내용이 있을 수 있습니다. 수정해야 할 부분이 있음 알려주세요. 확인 후 반영하도록 하겠습니다.

1 Thread에 대해서

// ... 
pid = fork(); 
if (pid > 0) 
{ 
    // 실제는 이 부분의 코드만 병렬로 실행되면 된다. 
    // fork()는 다른 모든영역의 코드가 복사되어 버린다. 
} 
 

1.1 Thread vs Process

• 프로세스는 독립적이다. 쓰레드는 프로세스의 서브셋이다.
  
• 프로세스는 각각 독립적인 자원을 가진다. 쓰레드는 stat, memory 기타 다른 자원들을 공유한다.
  
• 프로세스는 자신만의 주소영역을 가진다. 쓰레드는 주소영역을 공유한다.
  
• 프로세스는 IPC를 이용해서만 통신이 가능하다.
  
• 일반적으로 쓰레드의 문맥교환(context switching)는 프로세스의 문맥교환보다 빠르다.
  
  

1.2 Multi Thread 프로그램의 단점

• 하나의 쓰레드에서 발생된 문제가 전체 프로세스에 영향을 미친다.
  
  멀티 프로세스의 경우에는 프로세스하나가 문제가 생기더라도 단일 프로세스로 문제가 제한된다. 그러나 멀티쓰레드 프로그램의 경우 하나의 쓰레드에 생긴 문제가 다른 쓰레드에까지 영향을 줄 수 있다. 예를 들어 쓰레드 하나가 다른 프로세스의 메모리 영역을 침범할 경우 프로세스 자체가 죽어버림으로써, 프로세스에 생성된 다른 모든 쓰레드도 프로세스와 함께 죽어버리게 된다. - 이 문제는 해결 가능하지만 여기에서는 다루지 않도록 하겠다. 시그널을 잘 활용하면 된다. 관심있으면 한번 고민해 보기 바란다. -
  
• 디버깅이 어렵다. 문맥이 서로 교환되므로 추적하기가 까다롭다.
  
  

1.3 PThread

• 쓰레드 생성과 종료 관련 함수들
  
• 쓰레드 동기화 관련 함수들
  
  쓰레드는 많은 데이터를 공유한다. 그러므로 데이터에 대한 동기화 문제를 해결해야할 필요가 있다.
  
• 쓰레드 시그널 제어 함수들
  
  signal은 프로세스단위로 작동한다. 그러나 쓰레드 프로그램의 경우, 각 쓰레드 마다 다른 시그널 정책이 필요하므로, 쓰레드 전용의 시그널 제어 함수가 필요하다.
  
  

1.4 Multi Thread 프로그램

1.5 Process, Kernel Thread, User Thread

• 비선점형 : 특정 프로세스가 CPU를 독점하는 것이 가능하다.
  
• 선점형 : 특정 프로세스가 CPU를 독점하는게 불가능하다.
  

1.6 쓰레드의 생성과 종료

1.6.1 pthread_create : 쓰레드 생성

#include <pthread.h> 
 
int  pthread_create(pthread_t  *  thread, pthread_attr_t *attr,  
     void * (*start_routine)(void *), void * arg); 
 

1. thread : 쓰레드가 성공적으로 생성되었을 때, 넘겨주는 쓰레드 식별 번호.
   
2. attr : 쓰레드의 특성을 설정하기 위해서 사용한다. NULL일 경우 기본 특성
   
3. start_routine : 쓰레드가 수행할 함수로 함수포인터를 넘겨준다.
   
4. arg : 쓰레드 함수 start_routine를 실행시킬 때, 넘겨줄 인자
   

1.6.2 pthread_join : 쓰레드 정리

#include <pthread.h> 
 
int pthread_join(pthread_t th, void **thread_return); 
 

1. th : pthread_create에 의해서 생성된, 식별번호 th를 가진 쓰레드를 기다리겠다는 얘기다.
   
2. thread_return : 식별번호 th인 쓰레드의 종료시 리턴값이다.
   
   

1.6.3 쓰레드 생성 예제

#include <pthread.h> 
#include <stdio.h> 
#include <unistd.h> 
#include <stdlib.h> 
 
// 쓰레드 함수 
void *t_function(void *data) 
{ 
    int id; 
    int i = 0; 
    id = *((int *)data); 
 
    while(1) 
    { 
        printf("%d : %d\n", id, i); 
        i++; 
        sleep(1); 
    } 
} 
 
int main() 
{ 
    pthread_t p_thread[2]; 
    int thr_id; 
    int status; 
    int a = 1; 
    int b = 2; 
 
    // 쓰레드 생성 아규먼트로 1 을 넘긴다.   
    thr_id = pthread_create(&p_thread[0], NULL, t_function, (void *)&a); 
    if (thr_id < 0) 
    { 
        perror("thread create error : "); 
        exit(0); 
    } 
 
    // 쓰레드 생성 아규먼트로 2 를 넘긴다.  
    thr_id = pthread_create(&p_thread[1], NULL, t_function, (void *)&b); 
    if (thr_id < 0) 
    { 
        perror("thread create error : "); 
        exit(0); 
    } 
 
    // 쓰레드 종료를 기다린다.  
    pthread_join(p_thread[0], (void **)&status); 
    pthread_join(p_thread[1], (void **)&status); 
 
    return 0; 
} 
 

1.6.4 자식쓰레드를 부모쓰레드로 부터 분리하기

#include <pthread.h> 
#include <stdio.h> 
#include <unistd.h> 
#include <stdlib.h> 
 
// 쓰레드 함수 
// 1초를 기다린후 아규먼트^2 을 리턴한다. 
void *t_function(void *data) 
{ 
    char a[100000]; 
    int num = *((int *)data); 
    printf("Thread Start\n"); 
    sleep(5); 
    printf("Thread end\n"); 
} 
 
int main() 
{ 
    pthread_t p_thread; 
    int thr_id; 
    int status; 
    int a = 100; 
 
    printf("Before Thread\n");  
    thr_id = pthread_create(&p_thread, NULL, t_function, (void *)&a); 
    if (thr_id < 0) 
    { 
        perror("thread create error : "); 
        exit(0); 
    } 
 
    // 식별번호 p_thread 를 가지는 쓰레드를 detach  
    // 시켜준다. 
    pthread_detach(p_thread); 
    pause(); 
    return 0; 
} 
 

1.7 쓰레드 동기화

1. A와 B 두개의 프로세스가 있다. 이 프로세스는 int count=1 이라는 자원을 공유한다.
   
2. A가 count를 읽어들이고 1을 더한다.
   
3. B가 count를 읽어들인다. 아직 A가 count에 쓰지 않았기 때문에, B도 1을 읽어들인다.
   
4. A가 count에 2를 쓴다.
   
5. B도 count에 2를 쓴다.
   
6. count에는 2가 저장되었다.
   

1.8 접근제어

1.8.1 mutex 잠금

1.8.2 mutex의 사용

• mutex 잠금객체을 만드는 함수
  
• mutex 잠금을 얻는 함수
  
• mutex 잠금을 되돌려주는 함수
  
• mutex 잠금객체를 제거하는 함수
  
  

1.8.3 pthread_mutex_init

pthread_mutex_init(pthread_mutex_t *mutex, const pthread_mutex_attr *attr); 
 

1. mutex : mutex 잠금객체
   
2. mutex_attr : mutex는 fast, 'recursive, error checking의 3종류가 있다. 이 값을 이용해서 mutex 타입을 결정할 수 있다. NULL 일경우 기본값이 fast가 설정된다.
   
   • fast : 하나의 쓰레드가 하나의 잠금만을 얻을 수 있는 일반적인 형태
     
   • recursive : 잠금을 얻은 쓰레드가 다시 잠금을 얻을 수 있다. 이 경우 잠금에 대한 카운드가 증가하게 된다.
     

• fast : PTHREAD_MUTEX_INITIALIZER
  
• recursive : PTHREAD_RECURSIVE_MUTEX_INITIALIZER
  
• error checking : PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP
  
  

1.8.4 pthread_mutex_lock

int pthread_mutex_lock(pthread_mutex_t *mutex); 
 

int pthread_mutex_trylock(pthread_mutex_t *mutex); 
 

1.8.5 pthread_mutex_unlock

int pthread_mutex_unlock(pthread_mutex_t *mutex); 
 

1.8.6 mutex 잠금 예제

int a = 1;  
Thread A 에서 a를 읽어들인다.  
Thread B 에서 a를 읽어들인다.  
Thread A 에서 a = a+1를 한다.  
{  
    a = a+1;  
    결과는 2;  
}  
Thread B 에서 a++를 한다.  
{  
   a = a + 1; // 읽어들인 값이 1이기 때문에  
   역시 결과는 2가 된다.  
}  
 

• Atomicity - mutex 잠금은 최소단위 연적 - atomic operation - 을 보장한다. atomic operation에 대해서 간단히 설명하고 넘어간다. 자세한 내용은 Atomic Operation을 참고하기 바란다.
  
  1. aotomic operation은 일련의 연산 즉 mutex 잠금 연산이 끝날때 까지 다른 프로세스가 그 연산의 변화를 알 수 없는 상태가 되는 연산을 의미한다. (일반적으로 연산은 이전의 연산의 결과를 관찰한 후에서야 이루어질 수 있게다)
     
  2. 전체연산중 하나라도 실패할 경우 모든 연산이 실패하며 시스템은 전체 연산이 시작하기 전의 상태로 복구된다.
     
• Singularity : 한 쓰레드가 뮤택스 잠금을 얻었다면, 이 쓰레드가 뮤택스 잠금을 내어놓기 전까지는 다른 쓰레드가 뮤택스 잠금을 얻을 수 없도록 한다.
  
• None Busy Wait : 이것은 성능과 관련된 것이다. 바쁜대기상태에 놓이지 않는다는 뜻이다. 뮤택스 잠금을 얻을 수 있는지를 확인하기 위한 연산이 필요하지 않는 다는 의미로 받아들이면 될 것이다.
  
  

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

#include <stdio.h>  
#include <unistd.h>  
#include <pthread.h>  
 
int ncount;    // 쓰레드간 공유되는 자원 
pthread_mutex_t  mutex = PTHREAD_MUTEX_INITIALIZER; // 쓰레드 초기화 
 
// 쓰레드 함 수 1 
void* do_loop(void *data) 
{ 
    int i; 
 
    pthread_mutex_lock(&mutex); // 잠금을 생성한다. 
    for (i = 0; i < 10; i++) 
    { 
        printf("loop1 : %d", ncount); 
        ncount ++; 
        sleep(1); 
    } 
    pthread_mutex_unlock(&mutex); // 잠금을 해제한다. 
} 
 
// 쓰레드 함수 2 
void* do_loop2(void *data) 
{ 
    int i; 
 
    // 잠금을 얻으려고 하지만 do_loop 에서 이미 잠금을  
    // 얻었음으로 잠금이 해제될때까지 기다린다.   
    pthread_mutex_lock(&mutex); // 잠금을 생성한다. 
    for (i = 0; i < 10; i++) 
    { 
        printf("loop2 : %d", ncount); 
        ncount ++; 
        sleep(1); 
    } 
    pthread_mutex_unlock(&mutex); // 잠금을 해제한다. 
}     
 
int main() 
{ 
    int thr_id; 
    pthread_t p_thread[2]; 
    int status; 
    int a = 1; 
 
    ncount = 0; 
    thr_id = pthread_create(&p_thread[0], NULL, do_loop, (void *)&a); 
    sleep(1); 
    thr_id = pthread_create(&p_thread[1], NULL, do_loop2, (void *)&a); 
 
    pthread_join(p_thread[0], (void *) &status); 
    pthread_join(p_thread[1], (void *) &status); 
 
    status = pthread_mutex_destroy(&mutex); 
    printf("code  =  %d", status); 
    printf("programing is end"); 
    return 0; 
} 
 

1.9 앞으로 할 것

자유소프트웨어 재단과 오픈소스 진영의 껄끄러운 관계

대량 웹로그 데이터분석의 어려움

많은 통계정보들은 대게 시간축이 기준이 되는 경우가 많다. 특히 웹서비스의 경우가 더욱 그렇다. 웹서버스의 경우 웹로그를 이용해서 통계정보를 내는 경우가 많은데, 이때 문제가 되는 것은 로그의 양이 될 것이다.

로그의 양이 그리 많지 않다면야 RDBMS에 그냥 insert 한다음에 주기적으로 select해서 통계 데이터를 만들면 되겠지만, 하루에 쌓이는 로그의 양이 기가바이트쯤 된다고 하면, 로그를 저장하고 꺼내는 것 자체가 문제가 된다. 분석은 더 말할 필요도 없을 것이다. 로그 분석을 위한 데이터 마이닝 기법들은 그 자체가 하나의 연구분야이기도 하다.

혹시라도 빠른 분석정보의 출력을 원한다고 하면, 해야할 일이 보통 많은게 아니다. 임의의 페이지에 대한 1년간의 방문추이정보, 임의의 유저의 1년동안의 활동정보, 검색어의 사용추이 등의 통계정보를 만들어야 한다고 생각해보라. 경험많은 개발자라면, 방법이야 생각해낼 수 있겠지만, 매우 복잡하고, 많은 시스템자원과 시간이 소비되는 일일 거라는 건 미루어 짐작할 수 있을 것이다.

RRD의 사용

RRD(Round Robin Database)는 다양한 범위의 시간을 축으로 가지는 (한정된 크기를 가진)환영큐로 이루어진 형식의 데이터 베이스다.

예를들어서 PV에 대한 통계정보를 만드는 RRD는 다음과 같이 구성될 것이다.

• 5분간의 PV를 가지는 한시간짜리 테이블 : 단지 12개의 저장공간만 가지고 있으면 된다.
  
• 만약 12개의 공간을 다채우게 되면, 12개의 평균을 낸다음.. 1시간짜리의 평균데이터를 가지는 RRD 테이블에 값을 채워 넣는다. 이제 다시, 테이블의 처음으로 가서 5분 데이터를 써넣기 시작한다. 즉 테이블의 크기는 12개로 제한된다. 말그대로 테이블 형 테이터베이스
  
• 한시간이 최소간격이 되는 이 테이블을 24의 크기를 가지게 하면, 하루의 평균데이터를 가지게 될 것이다.
  
  

대략 다음과 같은 형식이다.

최소한의 크기로 1시간 평균, 하루 평균, 한달의 평균의 통계데이터를 유지할 수 있음을 알 수 있다. 시간간격을 다르게 한다면, 하루, 일주, 월, 분기, 년 등 다양한 주기의 통계정보를 생성할 수 있다.

물론 RRD 방식의 테이블이 가지는 단점도 있다. Round Robin방식을 취하게 됨으로써, 원본데이터가 손실되며, 연산이된 통계정보만 쌓인다는 점이다.

하지만 이정도로도 거의 대부분의 경우에 충분한 수준의 정보를 제공해 준다.

BitTable의 사용

BigTable은 고려대상이 아니다. BigTable은 거대한 저장공간영역을 준비해서 모든 로그를 저장하고, 강력한 (분산 컴퓨터의)연산능력을 이용해서 데이터를 분석하겠다. 라는 취지에서 만들어진 데이터 저장 방식이다. 이 문서는 간단하고 필요한 정보를 얻을 수 있는 실용적로그 분석시스템의 제안을 목적으로 하고 있다. 이 목적에서 봤을 때, Bigtable은 오버 테크놀러지다.

RRD 툴의 이용

이제 위에서와 같이 테이블이 꽉차면, 자동으로 필요한 통계연산을 한다음에 다음 테이블에 적도록 하는 애플리케이션을 만들면 된다. 아주 복잡한 애플리케이션이라고 할 수는 없겠지만, 상당히 귀찮은 일임에 틀림 없다. 그렇지만 걱정할 것 없다. 이미 그러한 구현이 있다. 이름도 RRD 이다.

이 RRD툴을 이용하면 간단하게, RRD 테이블을 구성할 수 있다. 뿐만 아니라 그래프까지 그려준다.

RRD를 이용한 페이지별 통계정보

현실적인 웹로그 분석의 예를 들어보자. 만약 페이지뷰의 통계정보를 제품별로 만들어 내고 싶다면 어떻게 해야 할까. ? 가장 간단한 방법은 제품의 갯수만큼 RRD테이블을 만드는 것이다. 100만개면 100만개의 파일을 만들면 된다.

100만개라고 하면, 굉장히 많은 양 같은데, 어느 정도의 크기를 가질지 계산해보자.

1. 하나당 5k의 크기를 가진다고 가정한다.
   
   테이블구성에 따라 다르겠지만, 대략 5k라면, 일,주,월,년,5년 의 평균데이터를 저장할 수 있다. 최소 시간간격을 1시간으로 하는 등의 방법으로, 최적화 시킨다면 3k미만으로도 할 수 있다.
   
2. 5k * 100만 하면 대략 4Gbyte 정도가 된다.
   

고작 5Gbyte로 100만개의 상품의 통계정보를 저장할 수 있다. 거기다가 이미 통계된 정보가 전부 들어가 있기 때문에, 매우 빠른시간 (0.수초내)에 원하는 정보를 얻어올 수 있다.

천만이라고 해도 40G밖에 안된다.

유저 & 페이지 통계 정보

단 유저별로 페이지 통계정보 혹은 검색어통계정보등을 만들려고 한다면, 문제가 약간 달라진다. 100만 유저이고 만들어질 수 있는 페이지가 10만개라고 하고, 모든 정보를 RRD로 남길려고 한다면, 280000 G의 공간이 필요하다.

이 경우에는 TOPN개의 정보만 RRD 테이블로 구성할 필요가 있다. 검색어를 예로 한다면 다음과 같다.

1. 하루동안의 TOPN의 검색어를 남긴다. 이 테이블의 크기는 7이다.
   
2. 테이블의 크기 7을 다채우면, TOPN에 대한 TOPN을 만들어서 일주일치 데이터를 만든다.
   
3. 일주일치의 TOPN을 저장하는 테이블의 크기는 8개다. 즉 두달동안 각 주의 TOPN 검색어의 통계정보를 저장할 수 있다.
   
   

이렇게 할때 필요한 디스크 공간을 대략 계산해 봤다. 시간간격을 어떻게 둘것인지와 TOPN의 크기를 어느정도로 할 것인지에 따라 다를 것이다. 여기에서는 TOPN의 크기를 10으로 잡아서 계산을 했다. 검색어의 크기를 20byte로 하고, 하루, 일주일, 한달, 일년, 5년의 정보를 남긴다고 하면..

필드 하나의 크기 : 20 * 10 = 200 
(7*200)+(4*200)+(12*200)+(5*200) = 5600 
 

약 6K로 유저의 5년치의 TOP10 검색어 정보를 남길 수 있다. 100만유저가 남긴다고 하면, 5G, 1000만 유저라고 해도 50G 정도면 된다.

물론 데이터의 손실이 필연적으로 발생한다는 TOPN 통계방식의 문제점이 있기는 하다. 그러나 유저활동의 대부분이 롱테일구조, 즉 상위 10%가 전체활동의 90%를 차지한다고 볼 수 있으니 문제될게 없다고 본다. 데이터를 몽땅남길 수도 있겠지만, 내상각에 이건 '90%의 완성도에서 1%의 완성도를 높일려고, 90%를 만들기 위해서 들였던 비용의 수백배를 소비하는 그닥 가치없어 보이는 행위로 보이기 때문이다.

구글의 웹사용 서비스

구글 서비스 중에 웹사용이란 서비스가 있다. 개인의 검색어와 검새어를 통해서 방문한 페이지의 대한 통계정보를 보여주는 서비인데, RRD 스타일의 데이터베이스 환경을 구축한걸 알 수 있다. 관심있으면 한번 사용해 보기 바란다.

얻을 수 있는 장점

단점은 대략 알고 있을테니 넘어가고.

• 빠르다.
  
  유저별로 100만개의 테이블을 만들었다고 가정해도, 0.1초내에 데이터,를 읽어 올 수 있다는 걸 보장할 수 있을 것이다.
  
• 작은 용량
  
  위에서 계산했던 것처럼, 작은 용량으로 충분한 효과를 얻을 수 있다.
  
• 관리성
  
  사이즈가 작으니 관리하기도 편하다. 간단하게 그룹화, 나누기, 백업 작업을 할 수 있다.
  
  

실제 구현 테스트는 다음번 문서에서

Abstract Factory pattern

구조

예제 1

#include <iostream> 
 
using namespace std; 
 
#define DEFAULT 0 
#define GET 1  
#define PUT 2 
 
/* Interface */ 
class Handler 
{ 
    public: 
        virtual void execute(char *instr)=0; 
        virtual int getID()=0; 
}; 
 
/* Factory Class */ 
class HandlerFactory  
{ 
    public: 
        Handler *instance(){} 
}; 
 
class GetHandler : public Handler 
{ 
    public : 
        void execute(char *str) 
        { 
            cout << "Get Handler : " << str << endl; 
        } 
        int getID(){return GET;} 
}; 
class PutHandler : public Handler 
{ 
    public : 
        void execute(char *str) 
        { 
            cout << "Put Handler : " << str << endl; 
        } 
        int getID(){return PUT;} 
}; 
 
class DefaultHandler : public Handler 
{ 
    public : 
        void execute(char *str) 
        { 
            cout << "DefaultHandler : " << str << endl; 
        } 
        int getID(){return DEFAULT;} 
}; 
 
class GetDataHandler : public HandlerFactory 
{ 
    public :   
        Handler * instance(int type) 
        { 
            if (type == GET) 
                return new GetHandler; 
            if (type == PUT) 
                return new PutHandler; 
            return new DefaultHandler; 
        } 
}; 
 
int main() 
{ 
    GetDataHandler *dh = new GetDataHandler;  
    Handler *mh = dh->instance(PUT); 
 
    mh->execute((char *)"ok"); 
    cout << "ID : " << mh->getID() << endl; 
} 
 

예제 2

#include <iostream> 
using namespace std; 
 
class Lock 
{ 
    public: 
        virtual void lock()=0; 
        virtual void unlock()=0; 
}; 
 
class LockFactory 
{ 
    public: 
        Lock *getInstance(int type); 
}; 
 
class FileLock : public Lock 
{ 
    public: 
        void lock(){cout << "File Record LOCK " << endl;} 
        void unlock(){cout << "File Record UN Lock " << endl;} 
}; 
 
class MutexLock : public Lock 
{ 
    public: 
        void lock(){cout << "Mutex LOCK " << endl;} 
        void unlock(){cout << "Mutex UN Lock " << endl;} 
}; 
 
class DefaultLock : public Lock 
{ 
    public: 
        void lock(){cout << "LOCK " << endl;} 
        void unlock(){cout << "UN Lock " << endl;} 
}; 
 
 
class GetLockHandler : public LockFactory 
{ 
    public: 
        Lock *gethandler(int type)     
        { 
            if (type == 1) 
            { 
                return new MutexLock; 
            } 
            if (type == 2) 
            { 
                return new FileLock; 
            } 
            return new DefaultLock;  
        } 
}; 
 
int main(int argc, char ** argv) 
{ 
    GetLockHandler *LockHandler = new GetLockHandler;  
    Lock *myLock = LockHandler->gethandler(2); 
    myLock->lock(); 
    myLock->unlock(); 
    return 0; 
} 

 

유래

bus 구조

웹서비스에서의 버스 구조

DMF 프로젝트

현재 DMF 프로젝트가 진행되고 있습니다.

1 웹개발을 위한 프레임워크

2 환경

3 기본컨셉

1. 컴포넌트 Model
   
   Module 단위로 개발된다. Page는 Module들의 집합이 된다.
   
2. Message driven Architecture
   
   Controll, Module는 Message를 이용해서, 데이터를 전달 받는다.
   
3. 전술패턴
   
   알고리즘(모듈)의 풀을 유지하고, 이름을 이용해서 모듈을 실행시킨다.
   
4. 가볍게 : 가능한 개발자에게 많은 권한을 준다.
   
   

4 나름 대충 설계

• 범용성을 강조한 나머지, 너무 무거운 경우가 많다. 대부분의 프레임워크에 대한 평가도 그렇다.
  
• 개발자에게 더 많은 권한을 주는 방향이 나을 것 같다. 대부분의 프레임워크가 개발자의 권한을 지나치게 제한한다는 느낌을 준다. 인터페이스정도만 따르도록 하고, 실제 개발은 각 개발자의 개성이 가능한 많이 반영 될 것이다. 개발자에게 많은 권한을 주는게 무슨 프레임워크냐고 할 수도 있겠다. 그냥 철학의 차이로 봐줬음 한다.
  
  

1. Client의 모든 요청은 Controller를 통해서 이루어진다. 호출될 서비스는 URL String 형태로 Controller 페이지에 전달된다.
   
2. Controller는 요청된 서비스페이지를 읽어들이고 해석한다. 만약 [[module]]를 만나면, module의 인스턴스를 만들고, model메서드와 view메서드를 실행한다.
   
3. Module를 실행할때, DB Connection, Session 정보, 기타 유저정보등을 넘겨주게 된다.
   
   

• 모든 모듈은 서로 완전히 독립된다.
  
• 각 페이지들은 이들 모듈의 집합이다.
  
• Module는 3개의 인자를 가지며, MV의 구현을 가진다.
  

  formatter	기본 설정값
  options	POST,PUT 등 유저입력 데이터, 필요에 따라 설정된 값들
  Value	함수 인자

• 모듈은 하나의 파일에 대응되며, 다음의 MV 작업을 수행할 수 있어야 한다.
  

  Model	데이터 프로세싱
  View	프로세싱된 데이터를 보여준다.

• Controller는 controller page에서 작동하며, page를 해석해서 모듈을 실행시키고, 결과를 client에 전달한다.
  

  Controller

  입력을 받아들여서 Model을 호출하고 결과를 리턴한다.

<table><tr><td> 
[[bbs]] 
</td><td> 
[[navi]] 
</td></tr></table> 
 

1. session 관리 : 이건 기본으로 들어가야 겠지 ?
   
2. DB Interface : 복잡하고 커다랗게 만들고 싶지 않다. 일단 facade 클래스를 만들어서 한단계만 추상화 하는 정도로 만족하려고 한다.
   
3. Editor : page를 수정하거나 추가할 수 있도록 한다. 추가나 수정뒤에 바로 테스트 해볼 수 있다.
   

4.1 model class

class Module 
{ 
  var $arg; 
  var $modelarg; 
  var $formatter; 
  var $options; 
  var $rtv; 
  var $className = 'myTest'; 
  var $isrtv=0; 
  var $values; 
 
  function Module($formatter, $options, $values="") 
  { 
    $this->formatter = $formatter; 
    $this->options = $options; 
    $this->values = $values; 
    echo "Create class !!<br>"; 
  } 
 
  function className() 
  { 
    return $this->className; 
  }  
  
  // model 구현 
  // view로 넘어갈 데이터는 viewData를 이용해서 넘긴다. 
  function model() 
  { 
    echo "This is Model method<br>"; 
  } 
 
  function view() 
  { 
    echo "This is View method<br>"; 
  } 
} 
 

1. formatter과 options을 이용해서 메시지를 교환하게 된다.
   
2. formatter과 options는 성능을 위해서, 복사대신 레퍼런스를 사용할 수 있다.
   
   

4.2 Controller

1. User Query를 분석해서, 각 모듈에 넘겨준다.
   
2. cookie, DB connection을 관리한다.
   
3. 설정값을 모듈에 넘겨준다.
   
4. 모듈의 리턴값을 다른 모듈로 넘겨준다.
   

1. preLoader
   
   페이지를 읽기전에 실행된다. session, db connection, user 환경설정 값등을 처리한다. 처리된 값은 message 형태로 controller로 넘겨진다.
   
2. moduleLoader
   
   페이지를 읽기 시작하고 module의 model과 view를 실행한다.
   
3. postLoader
   
   페이지를 읽고 난후의 작업들이다. logging, 에러처리와 같은 작업을 수행할 것이다.
   
   

5 문제들

5.1 데이터 교환

• XSLT : 쓸데없이 무거워지지 않을까라는 생각 때문에 망설여진다. 디자이너도 이것저것 알아야 하는 것 같고.
  
  

5.2 모듈사이의 데이터 교환

function model() 
{ 
   $rtv = array(); 
   // ..... 
   $rtv['username'] = $username; 
   $rtv['opner'] = $opner; 
   return $rtv; 
} 
 

class controller 
{ 
  var $options; 
  // .... 
  $this->options['RTV']=Module->model(); 
} 
 

class ModuleB extents Module 
{ 
  //... 
  function model() 
  { 
    $username = $this->options['RTV']['username']; 
    $opner = $this->options['RTV']['opner']; 
  } 
}; 
 

5.3 동적타이틀

#!title modulename 
 
코드들... 
... 
[[modulename]] 
[[modulename2]] 
[[modulename3]] 
 

5.4 개인화 전략

class preLoader 
{ 
    function model() 
    { 
        $usersession = new session(); 
        // 이런 저런 유저 세션 작업 
        // 유저 theme, css, 홈디렉토리, 문자셋 기타등등의 정보들 
       $rtv['formatter']['user'] = $usersession; 
        // DB Connection을 넘겨야 할 필요가 있다면. 
        $rtv['formatter']['db'] = new DBI(); 
        // 필요할 경우 header 정보를 생성한다. 
       $this->viewData = $header; 
       return $rtv; 
    } 
    function view() 
    { 
        return $this->viewData; 
    } 
} 
controller: 
  $rtv = preLoader->model(); 
  $rtv의 key 이름이 formatter 임을 알 수 있으므로 아래와 같이 formatter를 설정한다. 
  $this->formatter['user'] = $rtv['formatter']; 
 
module: 
  이제 다른 모듈들에서는 다음과 같이 user session 정보를 사용할 수 있다. 
  $user = $this->formatter['user']; 
  $user->isLogin(); // 로그인 체크 
  $user->getUserID(); // 사용자 ID 
  .... // 기타등등등의 활용. 
  // db 관련작업을 해야 한다면.. 
  $dbi = $this->formatter['db']; 
  $dbi->query($sql); 
  $dbi->fetch(); 
  .... // 기타등등등 
 

5.5 서로 다른 view가 필요할 경우

$cp = new $className($formatter, $this->options); 
$viewPage = 'view_userInfo'; 
$cp->$viewPage(); 가 호출이 된다. 
 

6 디렉토리 구성

 --- controll.php --+-- data -+-- text 
                    |         |  
                    |         +-- cache 
                    | 
                    +-- config -+-- config.ini 
                    | 
                    +-- theme -+-- default -+-- _user.css 
                    |          | 
                    |          +-- blog 
                    | 
                    +-- plugin  
 

7 테스트 페이지

• http://wowclub.joinc.co.kr/controll.php 에서 테스트결과와 모듈의 소스코드를 확인할 수 있다.
  
• controller는 POST 액션에 대해서 do method를 실행시킬 수 있어야 한다. 이것은 Module에 do 메서드를 추가함으로써 가능할 것이다. 그렇다면 POST액션이 일어날 경우에는 Module->model 대신에 Module->do를 실행시키게 된다. 만약 do 메서드가 존재하지 않는다면, model을 그대로 실행하도록 하면 된다. 로그인 같은 모듈이라면 do 메서드가 존재할 것이고, 게시판 같은 경우라면 do 메서드가 필요 없을 것이다.
  
  

7.1 Ajax 가 도입될 경우에는 ?

7.2 이 프레임워크?의 장점

• Page단위로 개발됨으로, 개발/테스트/배포가 용이하다.
  
• 재활용이 쉬운 Module을 유지할 수 있다.
  
• Module간의 결합도가 매우 낮다. 즉 유지/보수가 쉬워진다.
  
• 디자인과 모델을 높은 수준에서 분리시킬 수 있다.
  
• 디자인 템플릿 유지가 용이하다.
  
  • 디자이너는 템플릿 pgae를 만들어서 관리한다.
    
  • 개발이 충분히 끝났다면, 개발자는 템플릿 page를 복사해서 (모듈을 포함한)서비스 페이지를 만들면 된다.
    
• 버전관리의 용이성
  
  • wiki처럼 page단위로 버전관리가 용이하다.
    

Adapter pattern

인터페이스가 일치하지 않는 클래스를 함께 운용해야 하는 경우에 사용할 수 있다. 비교적 간단한 패턴으로 각각의 class를 수정하지 않고 함께 운용할 수 있도록 해준다.
이 패턴에는 다음의 객체들이 존재한다.

• Adaptee : 원하는 기능을 가지고 있는 객체
  
• Client : Adaptee의 기능을 사용할려는 사용자 객체
  
• Adapter : Client의 인터페이스를 가지고 Adaptee의 원하는 기능을 구현한 객체
  

Adapter pattern은 Object Pattern과 Class pattern 두가지 방법으로 구현가능하다.

Object Pattern 버전

Client는 Adaptee의 methodB를 사용하고 싶다. 그런데, Client와 Adapter모두 구현이 끝난 상태 - 혹은 라이브러리만 가지고 있거나 -로 클래스를 수정할 수 없다. 대신 중간에 Client와 호환되는 인터페이스를 가진 Adapter를 둔다. 이 호환되는 메서드를 client가 호출하면, Adapter는 Adaptee의 methodB를 호출하게 된다. 이렇게 해서 기존 클래스의 수정없이 Client에서 Adaptee의 기능을 이용할 수 있게 된다.

집합관계를 이용한 새로운 객체를 두는 방식으로, Object Pattern 이라고 한다.

  Client     Adapter      Adaptee  
 +-----+     +------+     +-----+ 
 |     |---> >      |---) )     | 
 |     |---> >      |---) )     | 
 +-----+     +------+     +-----+ 
 Adapter는 Client와 Adaptee에 호환되는 Interface를 모두 가지고 -집합- 있다. 
 

디자인 패턴을 생성하는 방법중 객체 합성을 이용한 예라고 보면 될것 같다. 다른 한가지 방법은 클래스 합성인데, 아래에 설명한다.

Class Pattern 버전

C++의 다중상속을 이용하는 방법이다. 여기에서 Adapter는 Adaptee를 상속받아서 구현할 수 있다.

예제

와우를 좋아하니, 와우의 직업군으로 예제를 만들어 봤다. 와우에서 가장 중요한 직업이라고 하면 역시 파티의 리더이자 몸빵인 Fighter와 Fighter와 파티의 피를 책임져 주는 healer일 것이다. - 참고로 나는 천민 냥꾼. 그래도 부사령관이라는. 말퓨리온서버 드라고너를 찾아주세요.-

Fighter도 피가 없을때에는 붕대질로 피를 채울 수 있기는 한데, 힐러의 healing 마법에 비해서는 그 효율성이 대단히 떨어질 수 밖에 없다.

그래서 Fighter에게 힐러의 1 level 힐링 능력을 선사하기로 했다. 와우저의 입장에서는 Fighter에게 마법이 생소할 수 있겠지만, D&D룰 같은 경우에만 봐도 Fighter Class가 마법을 배우는 것을 금지하고 있지는 않다. 좀 효율이 떨어져서 그렇지..

이제 Fighter에게 힐러의 cure 능력을 줘야 하는데.. 음 이게 인터페이스가 다른게 좀 문제다. Adapter Pattern을 이용하면, 이 문제를 풀 수 있을 것 같다.

Object pattern 버전

이건 Object pattern 버전의 코드다.

#include <iostream> 
 
using namespace std; 
 
/* 
 응급상자 클래스 
 여기에는 붕대와 붕대감기를 위한 Operation이 포함되어 있을 것이다. 
*/ 
class AidKit 
{ 
 
}; 
 
class Fighter  
{ 
    private: 
    public: 
    // 원래 전사는 붕대를 이용해서 치료할 수 밖에 없었지만.. 
        virtual void cure(AidKit *) = 0; 
        virtual void attack() = 0; 
        virtual void defense() = 0; 
        void myClass(){cout << "I'm fighter" << endl;} 
}; 
 
class Healer 
{ 
    public: 
        void healing(int Level) { 
            cout << "Level : " << Level << "Healing 시전" << endl; 
        } 
        void magic_attack(); 
        void magic_defense(); 
}; 
 
class AdvFighter : public Fighter 
{ 
    private : 
        Healer *heal; 
        int healLevel;  
    public: 
        AdvFighter(Healer *h) { 
            heal = h; 
            healLevel = 1; 
        } 
        void attack(){cout << "Attack !!!" << endl;}; 
        void defense(){cout << "Defense !!!" << endl;}; 
        void setHealLevel(int lev) { 
 
        } 
        // 레벨업 되면서, 힐러의 healing 마법을 쓸 수 있게 되었다. 
        // 1 level 이지만 이것만 해도 감사 감사. 
        // 기존의 붕대질 스킬은 그대로 둔채, 새로운 스킬을 추가해도 된다.  
        void cure(AidKit *) 
        { 
            heal->healing(healLevel); 
        } 
        void healing() 
        { 
            heal->healing(healLevel); 
        } 
        int getHealLevel() 
        { 
            return healLevel; 
        } 
}; 
 
int main(int argc, char **argv) 
{ 
    Healer *myHealer; 
    AidKit *myKit; 
    AdvFighter *healFighter = new AdvFighter(myHealer); 
    healFighter->myClass(); 
    healFighter->cure(myKit); 
    healFighter->healing(); 
    healFighter->attack(); 
} 
 

Class Pattern 버전

C++의 다중상속을 이용해서 구현했다.

// ...전략 
class Fighter  
{ 
    private: 
    public: 
        virtual void cure(AidKit *) = 0; 
        virtual void attack() = 0; 
        virtual void defense() = 0; 
        void myClass(){cout << "I'm Fighter" << endl;} 
}; 
 
class Healer 
{ 
    public: 
        void healing(int Level) { 
            cout << "Level : " << Level << "Healing 시전" << endl; 
        } 
        void magic_attack(); 
        void magic_defense(); 
}; 
 
class AdvFighter : public Fighter, private Healer 
{ 
    private : 
        int healLevel;  
    public: 
        AdvFighter() { 
            healLevel = 1; 
        } 
        void cure(AidKit *) { 
            Healer::healing(healLevel); 
        } 
        void attack(){}; 
        void defense(){}; 
}; 
 
int main() 
{ 
    AdvFighter *myFighter = new AdvFighter; 
    AidKit *myKit; 
    myFighter->myClass(); 
    myFighter->cure(myKit); 
    return 0; 
} 
 

generic Adapter pattern

템플릿을 이용한 generic adapter pattern이건 따로 문서를 만들어서 정리해볼 생각임.