OAuth의 세부사항

네트워크로그 2011. 1. 1. 03:05




지난 포스팅에 이어 OAuth의 세부사항에 대해 알아보자

① Request Token 요청 / ③ Access Token 요청 / ④ Protected Resources 요청 단계에서 적절한 oauth 파라미터를 함께 전달해주어야 
하는데 이 파라미터들에 대해서 알아보자. Consumer는 ServiceProvider 에게 3가지 방법 중 하나를  통해 파라미터를 전달할 수 있다. 
1) HTTP 헤더에 Authorization 헤더를 통해 전달한다. 
2) HTTP 헤더의 POST request body를 통해 전달한다. (이때 Content-Type 헤더는 application/x-www-form-urlencoded로 설정함)
3) URL의 쿼리 파트를 통해 전달한다. 

어느 방법을 선택해도 되지만, 이 포스팅에서는 첫번째 방법을 설명하겠다.  전체적인 흐름을 나타낸 그림은 다음과 같다. 



oauth 파라미터
oauth  파라미터는 OAuth 스펙에서 요구하는 "oauth_ " 접두어를 갖는 파라미터를 의미한다. oauth 파라미터의 종류와 그 의미는 
다음과 같다. 

  oauth_version  OAuth 프로토콜의 버전으로 1.0으로 설정하며, 선택적인
 파라미터 값이다
 oauth_consumer_key   ServiceProvider 에서 제공하는 Consumer 를 고유하게 식별하기 위한 값
 oauth_token   request token 값으로 Request token 요청시에는 사용되지 않으며,
  Access token 요청과 자원조회시에는 사용된다. 
 oauth_timestamp   GMT 1970년 1월 1일 00:00:00 이후 현재까지의 흐른 초로,  밀리초가 아닌 초 단위 임에 주의하자 
 oauth_nonce  reply attack 을 예방하기 위해,  동일한 timestamp 를 갖는 요청마다 유일한  랜덤값이다. 
 oauth_signature_method  oauth 파라미터 값들이 도중에 변경되지 않았음을 보장하기 위해 사용하는 해시 알고리즘의 종류로, HAC-SHA1,  RSA-SHA1
등이 있다. 이 포스팅에서는  HAC-SHA1 를 사용한다.  
 oauth_signature  HMAC-SHA1 를 사용하여 생성한 알고리즘의 결과값이다.
 이 알고리즘 적용에 필요한 키와 데이터에 대해서는 아래에서 자세히 다루겠다. 
 oauth_callback  Authorize URL 에 접속하여 사용자의 허용을 받고 리다이렉트
시킬 URL 이다. Consumer가 웹서비스가 아닌 애플리케이션이면
 "oob"  로 설정해야 한다. (oob는 out of band의 약자이다.)
 oauth_verifier  사용자 허용을 통해 응답받은 값으로, Access token 요청시에만 설정한다.  

각 단계별로 필요한 파라미터들을 요약한 결과는 다음과 같다. 
Request token URL  요청: oauth_consumer_key,  oauth_callback, oauth_timestamp, oauth_nonce, oauth_signature_method, oauth_signature
                                            oauth_version
Access token  URL  요청: oauth_consumer_key,  oauth_callback, oauth_timestamp, oauth_nonce, oauth_signature_method, oauth_signature,                                                oauth_version, oauth_token, oauth_verifier
Protected Resources 요청: oauth_consumer_key,  oauth_callback, oauth_timestamp, oauth_nonce, oauth_signature_method, oauth_signature,                                                oauth_version, oauth_token


oauth_signature 생성하기
HAC-SHA1 해시알고리즘을 사용하여 시그너처를 생성하는 방법을 알아보자.  각 파라미터들은 percent 인코딩 또는 Base64 인코딩을 하기전에 반드시 UTF-8 로 인코딩해야함을 주의하자.

이 알고리즘은 키를 바탕으로 데이터에 대한 해시 값을 생성하게 되는데,  data는 Signature Base String 이 되며,  key 는 
Consumer Secret 와 Token Secret 를 & 문자로 연결한 값이 된다. 

HMAC-SHA1의 데이터 생성 ( Signature Base String 생성)
생성 절차는 좀 까다로운데 절차는 다음과 같다. 
① oauth_signature 파라미터를 제외한 oauth 파라미터들의 키와 값을 각각 percent 인코딩을 하고 =문자로 연결한다. 
     (HTTP request의  post body값이 존재하면 이 값도 동일한 연산을 수행한다)
② oauth 파라미터( 키=값) 쌍을 키의 알파벳순으로 정렬한 후  &문자로 연결하여 정규화된 문자열을 생성한다 
    (키가 동일하면, 값의 알파벳순으로 정렬함)
③  Request URL을 percent 인코딩한다. 
④ HTTP request method(대문자) 와 인코딩된  Request URL, 그리고 정규화된 문자열을 & 문자로 연결하고, percent  인코딩하여
    Signature Base String을 생성한다.   
 

HMAC-SHA1의 키 생성 
① consumer secret를 percent 인코딩한다 
② token_secret를 percent 인코딩한다.  (token_secret 은 Request Token 요청시에는 공백값이며, Access Token 요청시에는 
     Request token의 secret이며,  자원 요청시에는 Access Token의 secret 이 된다. )
③ 인코딩된 consumer secret 값과 token secret 값을  & 문자로 연결하여 최종 데이터를 생성한다. 

Base64 인코딩으로 바이너리 값을 아스키 값으로 변경 
위에서 생성한 키와 데이터를 바탕으로 HMAC-SHA1 알고리즘을 적용하면, signature 의 바이너리 값을 얻을 수 있다.
이 데이터에 Base64 인코딩을 적용하여, 아스키코드값으로 변경하고, 다시 percent 인코딩을 적용하여 최종 signature 값을 
생성한다. 

지금까지 생성한 oauth 파라미터드를 HTTP  request의 헤더에 설정하고, 요청만 하면된다. 하지만 아직 한단계가 더 남아있다. 
HTTP  request 의 Authorization 헤더값를 생성하는 것이다. 

Authorization  헤더값 생성
 "OAuth  " (공백이 있다는 것에 주의) 문자열과 모든 oauth 파라미터의 키와 쌍따옴표로 감싼 값쌍을 =문자료 연결하고 다시 각각을  ,(쉼표)문자로 연결한다 
최종헤더 값은 다음과 같은 형태일 것이다. 
OAuth oauth_callback="oob", oauth_timestamp="13882494", ......


이제는 거의 마지막 과정까지 왔다. 각각 생성한 oauth 파라미터의 키와 값, Authorization 헤더의 키와 값을 HTTP 헤더에 설정하고, 
http 요청을 하면 된다.   HTTP 헤더와 HMAC-SHA1의 키와 데이터를 표현한 그림은 다음과 같다. 

HMAC-SHA1 알고리즘 키와 데이터에 인코딩 적용여부는 그림에 표현하지 않았다.  









OAuth의 개념과 대략적인 흐름

네트워크로그 2010. 12. 31. 19:41




트위터 관련 앱을 개발하면서 정보수집을 하는중에 트위터 서비스에 있는 특정 데이터를 사용하기 위해서는 
OAuth 란 인증과정을 거쳐야 된다는 것을 알게되었다. 트위터 뿐만이 아니라,  스프링 노트와 페이스북 등 대부분의
웹서비스에서 OAuth를 사용하여 써드파티들이 데이터에 접근할 수 있도록 되어 있었다.  각 웹서비스에서는 OAuth 인증과정을
나름대로 설명해주고 있지만,  그 정보만을 가지고 구현하기는 생각보다 쉽지 않아보였다.  공개된 많은 소스와 OAuth 스펙을 참고
하여 나름대로 정리해 보았다. SNS 써드파티에 관심있는 사람들에게 조금이라도 도움이 되었으면 한다. 

OAuth
OAuth 는 Open Authorization 의 약자로 API를 사용하여 자원에 접근하기 위한 오픈 표준이다. 즉
SNS 와 같은 웹서비스에 있는 자원(데이터)을 사용자의 인증정보 없이도 써드파티에서 사용할 있도록 하기위한 오픈 표준이다.  사용자의 아이디와 비밀번호를 통한 명시적인 인증정보 대신 사용자가 개인자원에 접근을 허용했다는 표시인 토큰을 발행하여,  써드파티에서 접근할 수 있게하는 것이다. 

OAuth 프로토콜은 2007년 초반경에 처음 초안이 작성되어 2010 년 4월에 RFC 5849 : The OAuth 1.0 Protocol 로 등록이 되었다. 

OAuth를 통해 써드파티에서 궁극적으로 획득하는 것은 사용자의 자원에 대한 접근허용을 표시하는 액세스 토큰이다. 
이점을 염두하고 자주 언급되는 용어에 대해 알아보자.  트위터를 예로 들어 설명하겠다. 


OAuth 용어
Service  Provider : 서비스 프로바이더는 자원을 제공하는 웹서비스를 의미한다.  트위터 또는 페이스북 서비스를 의미한다. 
Consumer : 서비스 프로바이터의 자원에 접근하는 써드파티 웹사이트/애플리케이션을 의미한다. 
Protected Resource :  트윗글과 팔로워 목록과 같은 서비스 프로바이더가 보유한 데이터를 의미한다. 
Consumer Key/Secret :  서비스 프로바이더는 자신들의 서비스에 써드파티들이 접근할 수 있도록 하는데, 이때 각 써드파티들을 고유하게 식별하기 위한 값이 Consumer Key 이며,  그에 대한 확인을 위한 값이 Consumer Secret  이다. (아이디/비밀번호와 유사)
Request Token : 액세스 토콘과 교환하기 위한 사용자의 승인이 떨어지지 않은 토큰이다. 토큰은 key와 secret으로 구성된다. 
Access Token : 사용자에 의해 승인된 토큰으로,  이 토큰을 소유하면 해당사용자의 자원을 사용할 수 있게 된다. 
OAuth Parameter : OAuth 인증을 위해 필요한 파라미터 값으로, oauth_ 라는 접두어로 시작한다.  


OAuth 의 간략한 흐름 
크게 3가지 단계로 나눌 수 있다. 
① ServiceProvider 가 제공하는 Request token URL에 접속하여, Request Token을 요청하여 얻는다. 
    이 값은 Access Token과 교환하기 위한 값이며, 아직은 사용자의 승인이 되지 않은 토큰 값이다. 
② ServiceProvider 가 제공하는 Authorize URL에 접속하면서  Request Token 값을 전달하면, 사용자의 인증페이지를
    볼수 있게된다. 사용자가 (로그인을 하고)  접근허용을 하면, Verifier 값을 얻을 수 있게된다. 
   (이 때,  Consumer 가 웹서비스 또는 애플리케이션인지에 따라 Verifier 값을 다르게 수신하게 된다. 
    웹서비스라면, ServiceProvider 에게  제공한 callback 주소로 리다이렉트 되면서 Verifier가 전달되며, 
    애플리케이션이면,  리다이렉션 없이 pincode를 발급해준다. 이 pincode를 추출하여 Verifier 로 사용한다. )
③ ServiceProvider 가 제공하는 Access token URL로 접속하여, Request Token 과 Verifier를 함께 전달하면 
    Access Token을 얻을 수 있게된다. 
④ 획득한 Access Token을 사용자의 계정에 따라 저장하여, 이후에 자원에 접근하기 위한 값으로 사용할 수 있다. 

OAuth 인증과정은 4가지 과정으로 단순하다. 하지만 인증과정을 어렵게 보이게 하는 것은 ②번 과정을 제외한 나머지 
과정에서 URL 요청시 적절한 oauth 파라미터 값들을 생성하여, 보내주어야 하기 때문이다.  이 하나하나 파라미터 값들을
올바로 생성하기 위해서는 ServiceProvider 와 스펙에서 요구하는 사항을 준수하여야 한다. 지금은 세부 사항들은 무시하고, 
크게 4가지 단계를 거치게 된다는 것만 이해하자. 위 흐름을 간략히 그림으로 나타내 보았다. 



사용자의 계정별로 ①,②,③ 번 과정은 한번만 수행하면 되며,  이후 ④ 을 조회하기 위해 사전에 획득한 Access Token을 
사용하게 된다.  (물론 ServiceProvider에 따라 Access Token을 특정기간 동안에만 유효하게 할 수 있는데, 그럴 경우 일정주기마다 
①,②,③ 번 과정을 다시 거쳐야 한다. )



지금까지 OAuth 의 개념과 대략적인 흐름을 알아보았다. 다음 포스팅에서는 각 단계별로 필요한 oauth 파라미터들과 파라미터를
생성하는 방법, 그리고 실제 구현까지 해보겠다. 


[iPhone] 로깅 프레임웍 cocoalumberjack

아이폰 2010. 12. 21. 00:36


아이폰에서 사용할 수 있는 Log4j 같은 로깅 프레임웍을 찾아 구글링을 하다,

cocoalumberjack 이라는 프레임웍을 찾게 되었다. 사용법도 log4j 와 유사하면서,

설정하기 쉽고, NSLog 보다 빠른속도와 커스텀 로거를 작성할 수 있는 유연성도 제공한다.

실제로 사용해보고, 유용성에 대해서는 추후 포스팅 해야겠다.

아래 주소에서 프레임웍 소스를 다운받자. (svn 으로 체크아웃하자)

http://code.google.com/p/cocoalumberjack/


Lumberjack( 이름이 머 이래 -_-;;) 의 사용법은 다음과 같다

1 소스를 아이폰 프로젝트에 복사한다 (logging이라는 폴더를 만들고, lumberjack 폴더를 통째로 복사했다)

2 프레임웍 사용을 위한 설정을 한다. 사용할 로거의 종류를 결정하는 부분으로 초기화하는 부분에 들어간다

( 예를 들면 applicationDidFinishingLaunching...)

DDLog : 프레임웍의 기초가 되는 부분

DDASLogger : 로그메시지를 Apple System 로거인 Console.app 으로 출력한다

DDTTYLogger : 로그메시지를 Xcode 터미널로 출력한다.

DDFileLogger : 로그메시지를 파일로 출력한다.

다음과 같이 사용할 로거의 인스턴스를 생성하여 DDLog에 추가한다

#import "DDLog.h"
#import "DDTTYLogger.h"
#import "DDASLLogger.h"
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    [DDLog addLogger:[DDASLLogger sharedInstance]];
    [DDLog addLogger:[DDTTYLogger sharedInstance]];
    // ...
}

3 기존 NSLog 문을 프레임웍에서 제공하는 로깅 메서드로 대체한다.

로깅 레벨은 error < warn < info < verbose 가 지원된다. 해당 로깅레벨은 설정하면, 자신과 하위레벨의

로깅메시지만을 출력한다. 레벨별 로깅 메서드는 다음과 같다.

DDLogError(@"");
DDLogWarn(@"");
DDLogInfo(@"");
DDLogVerbose(@"");

로깅 레벨은 전역으로 설정 할 수도 있으며, 파일별로 설정할 수도 있다. 로깅 레벨은 상수로 정의되어 진다.

LOG_LEVEL_ERROR : 에러레벨의 로깅메시지 출력
LOG_LEVEL_WARN : 에러, 경고레벨의 로깅메시지 출력
LOG_LEVEL_INFO : 에러, 경고, 인포 레벨의 로깅메시지 출력
LOG_LEVEL_VERBOSE : 모든 로깅메시지 출력
LOG_LEVEL_OFF : 모든 로깅메시지를 출력하지 않음

이제 파일의 상단에 헤더파일과 로깅 레벨을 선언하고, 로깅메서드를 사용한다

#import "DDLog.h"
// 모든 로깅메시지 출력하도록 레벨 설정
static const int ddLogLevel = LOG_LEVEL_VERBOSE;
// 에러 레벨 로깅메시지 출력
DDLogError(@"fail!!");
커스텀 로거를 작성하는 방법 또는 파일로거를 작성하는 방법은 프로젝트 사이트를 참고하자~

[Perl] 스칼라 데이터

카테고리 없음 2010. 12. 16. 00:14

사용자 입력

키보드에서 사용자 입력을 받기 위해 <STDIN>을 사용한다.

<STDIN>은 하나의 개행문자를 만날때까지 입력을 받는다. (개행문자 포함)

$line = <STDIN>;
if ($line eq "\n") {
    print "That was just a blank line!";
} else {
    print "That line of input was: $line";
}

chmop 연산자

chomp연산자는 변수에서 하나의 개행문자를 제거하는 함수이다.

chomp($text = <STDIN>);
이렇게 한문장으로 사용할 수도 있으며,
$text = <STDIN>;
chomp($text);
와 같이 두문장으로 사용할 수도있다. 펄의 특징 중 하나로, 괄호를 사용하지 않았을 때 의미가 변경되는 경우를 제외하고, 괄호없이도 함수를 호출할 수 있다는 것이다. 다음처럼 호출할 수 있다.
$food = <STDIN>;
$betty = chomp $food;
chomp의 반환값은 제거된 문자의 개수로, 이 반환값은 거의 쓰이는 경우가 없다.

[Perl] 펄 맛보기

언어로그 2010. 12. 15. 23:26
#!/usr/bin/perl

@lines = `perldoc -u -f atan2`;
foreach (@lines) {
    s/\w<([^>]+)>/\U$1/g;
    print;
}
유닉스/리눅스 프로그래밍에서는 관용적으로 라인의 첫번째 2개의 문자 #! 뒤부터 
그 라인의 끝까지에 파일의 나머지 부분을 처리할 실행프로그램의 경로가 오게된다. 
위에서는 /usr/bin/perl 경로의 펄인터프리터에 의해 프로그램이 실행되게 된다. 
시스템마다 설치된 위치가 다룰수도 있지만, 대부분 /user/bin/perl에 존재한다. 

 위 프로그램은 perldoc 라는 명령을 실행하고, 그 출력을 가져와서 행단위로 정규표현식에 
맞는 부분을 출력하는 프로그램이다.  역따옴표(`)로 감싼 부분은 해당하는 외부명령을 실행하게 한다.

'언어로그' 카테고리의 다른 글

[Perl] 펄 맛보기  (0) 2010.12.15
[WinAPI]Hello WinAPI 예제  (0) 2010.12.13

[VC2008] 라인넘버 표시

개발도구로그 2010. 12. 13. 21:57

프로젝트 메뉴 > 도구 > 텍스트 에서 확장자 별로 줄번호를 표시 설정을 할 수 있다.

[VC2008] 문자 셋 변경

개발도구로그 2010. 12. 13. 21:52

Visual Studio 2008을 설치한 후, 문자 셋의 기본설정은 유니코드이다.
기존 C 문자열을 매크로나 함수를 사용하여 유니코드로 변환하여 API 에 넘겨주어야 한다.
이런 작업들이 번거롭다면 다음과 같이 수정해보자.  

프로젝트 뷰에서 프로젝트를 선택하고 속성을 확인하면 문자 셋을 설정할 수 있는 메뉴가 있다.
기본값은 유니코드인데, 이것을 멀티바이트로 설정하면 된다.


[OOAD] 요구사항 수집부터 분석까지

방법론로그/OOAD 2010. 12. 13. 19:42



OOAD(Object Oriented Analysis Development) 

OOAD 는 인간은 실수한다는 것을 전제하고  문제인식, 정보수집,  분석, 아키텍처, 설계, 구현, 테스트, 배포, 서비스, 

유지보수의 일련의 개발과정을 반복적으로 수행해나가며 점진적으로 개선해나가며 시스템을 구축하는 개발 방법론

이다.  

이 포스트에서는 각 단계에 대표되는 산출물들을 간략히 알아보도록 하겠다.   사실 각 단계가 무엇을 목표로 하는지가 

더 중요하지만 이에 관한 사항들은 추후에 포스팅 하도록 하겠다.  들어가기에 앞서,  "방법론은 산출물이 아니다" 라는

말만 명심해두자. 그 단계가 목표로 하는 것이 무엇이냐에 따라 도움이 되는 활동이라면 사실 어떠한 것도 산출물이 

될 수도 있다. 즉  OOAD는 각 단계에 필요한 산출물을 확정짓지 않는다는 것이다. 

소개될 산출물들은  Refinement(정제) 과정을 통해 끊임없이 수정되고 개선되어야 한다. 




문답서 (인터뷰)

고객이 정말로 무엇을 원하는지 요구사항을 수집하고  업무의 흐름을 파악하는 과정으로

고객과 최대한 자연스러운 대화를 이끌어내야 한다. 여러차례에 걸쳐 대화를 통해 문답서를 정련해 나간다. 

ex) 비디오 가게 회원관리 문답서

 


유스케이스

문답서를 바탕으로 시스템의 주체와 대상(액터), 그리고 업무의 핵심 서비스를 도출해 내는 과정이다.  

이 과정은 문답서에서 명사와 동사를 힌트로 하여 추출해 낼 수 있다.

 

 

절차서 

문답서를 바탕으로, 서비스 항목(기능)에 따라 비지니스 영역에서 업무가 어떠한 순서에 따라 일어나는지 정리한 문서이다.

이 문서는 정보수집과정에서 필요로하며,  시스템화 이전의 비스니스 업무가 어떻게 이루어졌는지 파악하는데 목적이 있다.

(이 단계에서 시스템적인 용어를 사용않고, 실제 업무(domain)에서 사용하는 용어를 사용한다)

ex) 회원관리 절차서

 


분석절차서, 요구사항 기술서(Service Requirement Specification)

기존 업무흐름에서 시스템이 대체할 영역을 반영하여 절차를 다시 기술한 문서로 시스템화의 첫 진입점이 된다. 

기존 업무가 시스템화 되었음을 가정하고, 그 절차를 기술하는 과정이다. 

ex) 분석 절차서

 


단어리스트

분석절차서를  바탕으로,  명사와 동사를 추출해서 나열하고,  그것들의 연관성과 책임을 식별하는 과정이다. 

객체지향 개발을 위한 진입점이라 할 수 있다.  명사는 데이터가 되며,  동사는 데이터에 대한 조작/처리가 된다.




CRC (Class Relation Collaboration) 

단어리스트에서 식별한 데이터와 그에 대한 처리를 관련있는 것들끼지 그룹화 하는 과정이다. 그 그룹들은 클래스의 후보들이

되며 이들 사이에  연관관계 또한 식별한다.  이 과정에서 각 그룹들을 카드화하여 서로 조합해보면서 각 기능을 수행할 최적의

그룹과 그 관계를  찾는 것이 좋은 방법이 된다.  이 방법을 개인적으로 해보지는 않았지만, 좀더 재사용성 좋고  견고한 SW가

되기 위해서 반드시 필요한 과정이라 생각한다. 



Domain Model

클래스들의 전체적인 관계에 초점을 맞추어 특정 플랫폼과 기술에 종속적이지 않게  도식화한 문서이다. 

도메인 모델의 클래스에는 범용타입의 데이터와 처리 메소드들도 표현된다. (메소드의 인자타입과 반환값도 표시됨) 

ex) 회원관리 단어리스트, CRC, Domain Model

 



Class Diagram

 Domain Model 에 아키텍처(Architectur) 에서 결정된 플랫폼과 기술,  언어들이 적용되어  실제 구현언어의 클래스들로 관계를 

도식화한 문서이다. (아키텍처를 적용하면, 3-tier, 웹, 클라이언트 등과 같은 아키텍처에 수반되는 역할을 갖는 클래스들이 

추가(결합)가 된다. )

ex) 회원관리 Class Diagram

 

 


Sequence Diagram

서비스 또는 기능별로 객체들의 상호작용(메소드 호출)을 시간순으로 도식화 한 문서이다. 

ex) Sequence Diagram

 


개인적으로   OOAD와 UML을 공부하면서, 항상 걸림돌이 되었던 부분이 절차와 데이터를 파악하고 나서, 객체지향 기술을

적용하는 부분이었다.   도출한 데이터와 절차를 바탕으로 절차지향적인 시스템으로 바꾸는 것은 어렵지 않은 일이다. 

반면  객체지향적으로 바꾼답시고 데이터를 그룹화하고 클래스에  Model, View, Controller 라는 이름을 붙히는 것이 늘 왠지 어색

하고 찝찝한 과정이었다.   지금 생각해 보면 단어리스트와 CRC 를 바탕으로 최적의 방법으로 그룹핑하여 Domain Model을 

도출하는 과정이 객체지향 프로그래밍 모델로의 첫번째 진입점이 된다고 생각한다.  두 번째는 웹 , 클라이언트/서버 아키텍처 

등이 결정되어  도메인 모델과 결합되는 부분이라 생각한다.  

 기존에는 아키텍처라는 과정을 간과했기 때문에  늘  부자연스움을 느꼈던  것 같다.  


 


[OOAD] 아키텍처, IA , 화면기준안, 스토리보드

방법론로그/OOAD 2010. 12. 13. 19:42


 

이 포스트에서는 아키텍처와 UI 디자인 단계의 산출물에 대해서 간략하게 알아볼 것이다..

아키텍처가 결정됨과 동시에 Programming 설계와 더블어 UI 설계를 시작하게 된다. UI 설계 단계의 산출물에는 

 IA, 화면기준안, 스토리 보드가 존재한다.  이들 하나하나에 대해서만 알아볼 것이며, 이것들을 하나의 흐름으로 

연관지어 설명하지는 않겠다. 이런것들이 무언인지만 파악하고, 추후 포스트에서 전체적인 흐름을 설명하겠다. 

 

1. 아키텍처(Architecture)

성능과 안정성 등과 같은 비기능적인 요구사항을 만족시키 위한 것으로, 시스템의 S/W 및 H/W 의 전반적인 구성을 포함한다.

흔히 stand alone, 2-tier , 3-tier, 혹은 웹 아키텍쳐, 애플리케이션 아키텍처 등과 특정 목적을 달성하기 위해 최적화된  소프트웨어

및 하드웨어의 구성을 의미한다. 

 stand alone : 단일 PC에서 동작하는 구성

 2-Tier : client와 데이터 및 그것을 처리하는 비지니스 로직을 갖는 DB, 2개 층으로 구성되는 시스템

 3-Tier : 비지니로직를 갖는 DB에 대한 부하를 분산하기 위해, 비지니스 로직을 WAS(Web Application Server)에 별도로                                 분리해 3개층으로 구성되는 시스템 형태. 여러 대의 WAS 를 마치 하나처럼  클러스터링하여 부하를 분담한다 

웹 아키텍쳐: 시스템의 접근이 웹으로 이루어지는 구성

애플리케이션 아키텍처: 시스템의 접근이 애플리케이션을 통해 이루어지는 구성

엔터프라이즈 아키텍처 : 시스템의 접근이 웹과 애플리케이션을 통해 이루어지는 구성

 

 

2. IA(Information Architecture)

인간이 소프트웨어를 이용하여 정보, 즉 Contents와의 접점에서 사용자가 편리하게 고민하지 않고  정보를 찾아 지식을 얻어 

갈 수 있도록 정보를 배치하는 과정 


 

3. UI 기준안

화면 구성의 전체적인 레이아웃과 일관적인 컨셉을 결정하는 단계



4. 스토리보드(Story Board)

IA와 UI 기준안을 바탕으로 각 서비스(기능)의 화면요소들을 배치하고 구성해보는 과정 

 


5. 그 외 용어

1) EJB(Enterprise Java Beans)

네트웍 커넥션 자원(Dao)과, 비지니스를 로직을 갖는 컨트롤러(Manager)와 같은 객체자원을 원격에서 대신 관리해주는

엔터프라이즈 서버 프레임웍. 

네트웍 커넥션은 Entity Bean, 비지니스 로직 컨트롤러는 Sesssion Bean으로 관리된다


2) Fail Over

프로세서, 서버, 네트웍 또는 데이베이스 등이 고장, 또는 유지보수시 시스템이 중단되는 것을 막기위하여

두 개의 이상의 시스템을 중복 구축하고, 고장, 유지보수 하는 1차 시스템의 기능을 그대로 2차 시스템이 수행하는 구조

(사용자에겐 아무일도 없었다는 듯이 인식된다)

 

3) RAC (Real Application Cluster)

여러대의 병렬 DB들을 마치 하나의 DB인 것처럼 사용할 수 있는 오라클 DB 클러스터링 기법

데이터베이스의 확장성과 성능향상의 장점이 있다.  


  • 뽀&쏭 2016.02.03 13:40 신고 ADDR 수정/삭제 답글

    핵심만 잘 정리되어 있어서 좋아요. ^^

[WinAPI]Hello WinAPI 예제

언어로그 2010. 12. 13. 19:31



WinAPI를 사용하여 간단한 윈도우 창을 뛰우는 예제
#include <windows.h>

LRESULT FAR PASCAL WndProc(HWND, UINT, UINT, LONG);

int PASCAL WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpszCmdLine, int nCmdShow) 
{
	static char szAppName[] = "Hello Win";
	MSG msg;
	HWND hwnd;
	WNDCLASS wndclass;

        // 실제 생성할 윈도우 스타일 지정 
	if (!hPrevInstance) {
		wndclass.style = CS_HREDRAW | CS_VREDRAW;
		wndclass.lpfnWndProc = WndProc;
		wndclass.cbClsExtra = 0;
		wndclass.cbWndExtra = 0;
		wndclass.hInstance = hInstance;
		wndclass.hIcon = LoadIcon(NULL, IDI_APPLICATION);
		wndclass.hCursor = LoadCursor(NULL,  IDC_ARROW);
		wndclass.hbrBackground = (HBRUSH)GetStockObject(WHITE_BRUSH);
		wndclass.lpszMenuName = szAppName;
		wndclass.lpszClassName = szAppName;

		// 윈도우를 만들겠다고 통보 
		RegisterClass(&wndclass);
	}
	// 실제 윈도우 생성 
	hwnd = CreateWindow(szAppName, "Hello Win Demo",
						WS_OVERLAPPEDWINDOW,
						CW_USEDEFAULT, CW_USEDEFAULT,
						CW_USEDEFAULT, CW_USEDEFAULT,
						NULL, NULL, hInstance, NULL);
	ShowWindow(hwnd, nCmdShow);
	UpdateWindow(hwnd);

	while (GetMessage(&msg, NULL, 0, 0)) {
		TranslateMessage(&msg);
		DispatchMessage(&msg);
	}
	return msg.wParam;
}


LRESULT FAR PASCAL WndProc(HWND hwnd, UINT message, UINT wParam, LONG lParam) 
{
	HDC hdc;
	PAINTSTRUCT ps;
	RECT rect;

	switch (message) 
	{
	case WM_PAINT:
			hdc = BeginPaint(hwnd, &ps);
			GetClientRect(hwnd, &rect);
			DrawText(hdc,  "Hello, Windows!", -1, &rect, DT_SINGLELINE | DT_CENTER | DT_VCENTER);
			EndPaint(hwnd, &ps);
			return 0;

	case WM_DESTROY:
		PostQuitMessage(0);
		return 0;
	}
	return DefWindowProc(hwnd, message, wParam, lParam);
}


'언어로그' 카테고리의 다른 글

[Perl] 펄 맛보기  (0) 2010.12.15
[WinAPI]Hello WinAPI 예제  (0) 2010.12.13