'분류 전체보기'에 해당되는 글 1250건

지금까지 2003 IIS만 주로 쓰고 있다가, 2008로 넘어오면서 나름 적응을 했다고 생각했다.

그런데, 2008 R2에서는 시스템 성능 및 보안 등등 여러가지를 손 본듯 싶었다.

이번에 지원 프로젝트건이 있어 잠시 나왔다.

ClearQuest 7.1.1 과 IIS간의 연동 부분이 있는데, ClearQuest에서 제공하는 COM 과 연결하는 작업이 반드시 필요한 내용이였다.

로컬 및 자체 Staging 서버(애석하게도 여기는 2008이였지, 2008 R2가 아니였다.)에서는

잘 돌다가, 갑자기 운영서버에 올라가니 다음과 같은 오류를 뿜었다.

'/' 응용 프로그램에 서버 오류가 있습니다.
--------------------------------------------------------------------------------

80040154 오류로 인해 CLSID가 {94773112-72E8-11D0-A42E-00A024DED613}인 구성 요소의 COM 클래스 팩터리를 검색하지 못했습니다.
설명: 현재 웹 요청을 실행하는 동안 처리되지 않은 예외가 발생했습니다. 스택 추적을 검토하여 발생한 오류 및 코드에서 오류가 발생한 위치에 대한 자세한 정보를 확인하십시오.

예외 정보: System.Runtime.InteropServices.COMException: 80040154 오류로 인해 CLSID가 {94773112-72E8-11D0-A42E-00A024DED613}인 구성 요소의 COM 클래스 팩터리를 검색하지 못했습니다.

소스 오류:

줄 19: ....

처음에는 COM이기 때문에, 해당 서버에 저 COM이 제대로 등록되어 있지 않았나 싶었다.

그래서 구성 요소 서비스에 들어가, 해당 Component가 이상한가 봤는데,

애석하게도 내가 다루고 있던 COM은 서버형이 아니므로 전혀 무관계.

이번에는 RegEdit 를 띄운 뒤, 저 CLSID를 검색하는데,

잘 걸린다. 위치도 제대로 되어 있고, 모든 설정은 OK! 였다.

.NET Framework 문제인가? 3.5가 아닌 2.0 기반의 Classic .NET 설정의 문제인가.

아니면 내가 코드를 짤 때 레퍼런스 설정이 잘못된 것인가?

여러가지 의문점들을 하나씩 수정하면서 체크해봤다.

대략 1시간 정도 시간을 보내고 났다.

그러나 방법은 모르겠고.....

그러다가, 현재 동작 중인 응용 프로그램 설정에서 다음을 보았다.

저게 x64 형태의 서버에서만 설정하는 부분인 것 같다.

성능상의 Issue를 최소화 시키기 위해 x86기반의 응용 프로그램 제외 모드가 있는 것 같다.

그런데, 애석하게도 저 옵션이 Default 값이 False인듯.

True로 바꾸자 모든게 매끄럽게 진행이되었다.

근래 시간이 되면 Football Manager 2010을 하고 있다.

천안시청이라는 팀을 하고 있는데, 예전 K-League에서 뛰었던 선수들과,

기존에 있었던 듯한 선수들로 포진되어 있다.

위닝11 2010을 하다 보면, 선수들이 30세를 넘어서면서 파라미터가 마구 내려가기 때문에,

나이 많은 선수의 유지는 어렵다라는 미묘한 선입관이 강하게 박혔다.

그래서 FM 2010에서도 남기일 선수가 벌써 나이기 35세에 육박해서,

제일 먼저 방출을 -_-;;;;;

( 나중에 천안시청 관련글 보고 ㄷㄷㄷ 하긴 했다. 이렇게 훌륭한 선수였어?!! )

그래서 FM 2010을 하면서 나이 많은 선수들의 재배치와 다시 보기를 하고 있었다.

게다가, 팁 처럼 뜬말 중에 이런 말도 있다. MF 진은 28~31이 전성기라고.

아항! 그렇구나.

그리고 어제 경기를 쭉 봤다.

젋은 피가 물씬 느껴지는 전반!

특히 구자철의 플레이는 환상 그 자체 였다. 볼의 움직임에서 창조성이 화려하게 느껴지고

섬뜻섬뜻했다. 더욱이 2번째 골을 넣을때 골키퍼 면전 근처에서 묘기 부리듯 공을

살짝 올리는 모습은 정말이지 천재라는 느낌!

이거 완전히 남미 팀과 아시아 팀이 맞붙은 기분.

그에 반해 이동국 같은 경우 젋은 선수들의 활발한 움직임과는 많이 반하는 모습을 보여주었다

어딘가 짱박혔다가, 수비수의 빈틈을 비집고 들어간듯한.

사실 그래야 골과 연결되는 경우가 많겠지만, 그래도 영 존재감이 없었다.

특히나 수비수를 줄줄줄 달고 댕길 수만 있어도, 그의 존재는 확실할텐데,

무언가 한 템포가 부족한 기분.

애석하게도 카메라 뷰 자체가 이동국만 비출 수 없는 것이기 때문에,

그의 플레이를 전부 보지는 못했다.

하지만, 확실한 건 타켓형 스트라이커는 아닌 것 같다.

- FM 2010의 천안시청에서는 그런 이동국이라도 있으면 전승 할 수 있을 것 같다. 된장.

  윤원철도 좋고 구현서도 좋지만 골 결정력이 너무 낮아 -_-;;;

예전에도 한 친구와 미묘한 서로간의 갈등으로 내 멋대로 절교를 선언했었다.

(그러고 보니 20세기 소년에서처럼 "친구"의 "절교" 같은데 절대 그런 느낌은 아니다.)

그리고 거의 5~6년 후에 우연히 다시 만나 오랜만의 재회를 나누었다.

이 때까지만 해도 그럭저럭 넘어간 것 같았다.

오늘(2010-02-06) 저녁.

친구 중 한 명이 게임방을 차린다고 의견을 구하기 위해 나와 또 하나의 친구를 초대했다.

일단 내가 먼저 참가 이야기를 나누었다. 그러다 흡연실로 자리를 옮겼고,

거기서 이런 저런 이야기를 했다.

그리고 좀 늦게 그를 만났다.

그런데 애석하게도 그는 흡연실이 싫었고, 더욱이 신도림까지 다시 나와야 된다는 사실에

다양한 원인이 섞여 결국 화를 내며 집으로 가버렸다.

나에게도, 초대한 친구에게도 화를 내며 갔다.

물론 내 잘못은 분명있다.

다양하게 이렇게 저렇게 화난 친구에게 따돌리듯 (비록 장난이였지만) 한 것은 분명 잘못인 것 같다.

하지만 그의 분노는 의외로 컸다. 전화가 왔고, 그의 분노 섞인 불만이 쏟어졌다.

답변을 했찌만, 나의 미안함은 전해지지 않은 채,

도리어 오해만 잔뜩하고 일방적으로 전화를 끊었다.

다시 연락하고 싶었지만, 연락은 안되었다.

분명 내 잘못은 맞다.

그에게도 그의 사정이 있으니, 복잡하게 꼬였을지도 모른다.

하지만, 그의 액션은 이미 나에게는 어떻게 할 수 없었다.

다시 5년이 될지 10년이 될지는 모르겠지만, 오해 속에서 어설프나마 또 다시 절교 모드 들어갈 것 같다.

돌아오면서 생각해보니,

그 친구와 특별한 Give & Take 요소가 없다는 점이 더욱 그런 것 같다.

그 문제에서 요즘 나에게는 마이너스 적인 우울함 가득한 상태이기에,

그를 달래 다시 만날 생각조차 안든다.

(내 각종 인터넷 계정 정리도 그 일환이지만.)

한참을 복잡하게 생각했지만, 이제 다 포기다.

뭐, 쓸쓸하게 스크루지 처럼 쓸쓸히 죽는 것은 왠지 슬픈 느낌이지만,

(그렇다고 구두쇠에 인색하지는 않다. 단지 좀 성격이 약간 삐뚤어진 것 뿐이다.)

그래도 이런 마이너스 적인 우울함에도 몇몇 친구들은 아직도 나를 반긴다.

뭐 그걸로 만족하면서 살려고 한다.

조용히 아무 고민 없이 살고 싶을 뿐이다.

처음에는 수수료 때문에, 키움닷컴으로 일단 시작은 했는데,

중간에 신한금융투자 쪽에 모바일 기능을 PDA에서 제공되는 것을 보고 그 쪽으로 옮겼다.

그런데 역시 수수료는 증권 살때, 팔때 전부 적용. 게다가 팔때는 세금까지.

0.05% 이니까, 100 만원어치 사면 대략 5만원정도 까인다. 그것도 살 때 팔 때. 게다가 세금까지.

그러니까, 대략 15만원 정도는 까인다고 본다.

(증권거래로 돈 벌려면, 이정도는 가뿐이 넘을 수 있어야 될듯)

뭐 그건 그렇다 치자. 다들 그렇게 거래들을 하고 있으니.

이번엔 정말 목적 처럼 달라 붙었던 모바일 프로그램을 설치했다.

아, 그런데, 이놈의 프로그램은 M480은 지원하지 않았다.

요즘 유행하는 풀 터치 기반의 넓직한 화면만 지원했고, M480같은 짧다목한 화면은 지원 불가.

왜 그런가 했더니 보니까, 해상도가 풀터치폰 기준으로 만들다 보니, M480에서는 보기가 힘들다.

아... 다 포기할까 하다가, 그냥 RealVGA 깔고 128dpi 크기를 96dpi로 만들었다.

일단 뜨긴 뜬다.

어랏? 이번엔 3000원을 더 내란다.

한번이 아닌 매달.

이건 또 무슨 시츄에이션?!

이걸 뭐라고 해야 할까.. 심각하게 고민하기 시작했다.

정말 3000원씩이나 내가면서 봐야 하는거야? 라는...

그러다가, 밖에서도 데이터를 볼 수 있으면 좋지 않을까? 라는 생각이 들었다.

사실 증권의 각종 거래 데이터는 거의 완벽한 유료 서비스.

생각보다 비싼 정보다. ( 물론 쓰레기 더미와 같은 데이터들이긴 하지만...)

이걸 증권사가 나름대로 정순화 해서 보내주는 것.

그정도 즈음이야... 뭐 할 수 없지라는 마음에 3000원 결재 들어갔다.

어라!!!!!!! 이건 또... 뭐..

경고 메시지. 한건 조회할때, 댁은 팍스넷에 가입이 안되있으셔서,

조회 건당 200원씩 내란다. 조회 건당.

이건 또 뭐야!!!!

아쓰벌.

일단, 다 접기로 했다. 빨리 이놈의 서비스도 종료시키고 다 지워버려야지.

내가 바라는게 이런게 아니잖아!!!!!!

정말 쓰레기다. 모바일 제품들.

포기 ~ 포기 ~

앞서 포스팅한 글에서 언급한 문제에 대해서 자세히 설명을 하려고 한다.

아마도 Google Apps Engine은 아마존이나 MS와는 다르게 초기 진행은

완전 무료로 진행되기 때문에, 어중이 떠중이(필자를 포함한) 다양한 사람들이 접근하기 때문에,

CPU에 큰 무리가 될 작업은 아예 배제하고 출발한 것 같다.

(아니면 단순히 설계에서 고려 사항에서 제외하고 출시 한 것일지 모른다.)

지금 현재 관점으로 바라볼때 Google Apps Engine은 다음과 같은 구조를 가지고 있다.

아주 단순한 모양인데, GAE 위에 얹어 놓은 모든 응용 프로그램은 Request/Response 기반으로

동작하게 된다.

자 여기서 함정이다.

즉 Request와 Reponse 사이에 Web Browser에서는 Time-Out을 결정하게 된다.

만일 GAE에 올려놓은 응용 프로그램 내에 처리해야 되는 내용이 많은 경우에는

Web Browser에 Response를 줄 수 없는데, 이러면 응용 프로그램 오류가 발생한다.

물론 응용 프로그램의 설계를 웹 중심으로 다시 생각하여 하나씩 재 설계하면 가능하다.

하지만, 로직을 만들다 보면, 내부적으로 처리되야 하는 경우가 있다.

무언가 작업의 Flow가 있을때, 중간에 끊기면 다음 작업의 완성도에 대한 장담이 어려운 경우가

있는데, 이런 응용 프로그램은 참 곤란하다.

예전에 아마존 클라우드 서비스에 대한 소개 내용 중 이런게 있었다.

한 대중 매체 사이트에 담긴 모든 형태의 파일 형식을 바꿀 일이 있었는데,

이 때 아마존의 클라우드 서비스를 이용하여 임대 식으로 해당 자원을 활용하여 변환했다고 한다.

만일 고도의 계산이나 많은 부하가 필요한 변환 작업이라고 할때, 한번 변환 작업이 5분 걸린다면?

이거 Timeout으로 Exception 뿜고 죽는다.

그렇다면? Back-end에서 처리하는 방법은?

안그래도 Azure를 하면서 그런 기능을 찾아보았다.

Azure에서는 Worker라는 개념이 있어서, 사용자의 특정한 Request가 없이도 실행할 수 있는

로직이 있었다. 게다가, 이 개념에서 시작과 끝에 대해서는 완전 비동기로 동작할 수 있도록 했다.

즉 사용자의 Request는 그 Worker를 동작시켜주세요!!!! 이 정도로 끝내고,

나중에 필요할 때 그 결과값을 얻을 수 있었다.

그러나 이 GAE 안에는 그런 개념은 없었다.

비슷한 기능이라고 생각한 기능을 찾기는 했는데....

바로 Cron이였다. 아 뭐 특이한건 아니고, Linux에 있는 그 Cron이다.

일정 시간이 되면 실행하는 그 데몬. 그런데 웃기는건 이 Cron도 위의 한계를 그대로 안고 있다는

것이다. 즉, 사용자가 직접 액션을 안한다 뿐이지, 실제로는 그 동일한 한계를 들어낸다.

위와 같은 꼴이니, 만일 GAE안의 응용 프로그램이 Timeout에 빠진다고 한다면?

동일한 오류를 뿜고 끝!

그래서 방법은 한가지 밖에 없다고 판단한다.

클라이언트가 복잡해지는 수 밖에 없다는 생각이다.

뭔가 복잡한 그림이 됐지만, 원리는 간단하다.
즉 Client 쪽에 로직을 세우면 된다.

프로그램을 시작한 뒤, 그 다음 단계에 뭐하고 그 다음 단계의 다음 단계에 뭐하고 하는 것을

Client에서 구현한 뒤, 실제 데이터 입출력이나 처리 작업만 일부분만 넘기는 것이다.

GAE에서는 단지 그 일부분을 처리하기 위한 로직 만을 세우면 되는 것이다.

위의 예를 가지고 사용자의 클릭 한번에

     Action1 -> Action 2 -> Action 4

의 작업을 수행한다 가정하자.

그러면 다음과 같은 순서로 실행될 것이다.

1. Action 1 실행
2. Action 1에서 GAE의 Action1에 해당하는 루틴 Requst.
3. GAE의 Response 내용을 받음.
4. Action 2 실행.
5. Action 2에서 GAE에 Action2에 해당하는 루틴 Request.
6. GAE의 Response 내용을 받음
7. Action 4 실행
8. Action 4에서 GAE에 Action2에 해당하는 루틴 Request.

즉 GAE에서는 웹 서비스의 단위 메소드,

이른바 Web 2.0의 한 유행인, 공개 API와 같은 꼴로 구성하면 어떻게든 된다.

아직은 구성에 대해서 다양한 시도와 파악 중이다.

현재까지 이 Google Apps Engine을 통해 무언가를 만든다는 개념은

위의 형태에서 벗어나게 되면 이래 저래 힘들듯 싶다는 생각이다.

지금까지 파악한 방법에서 성공한 방법은

클라이언트 측은 Rich 하게 만들고, GAE에서는 가볍게 만들어

GAE에 데이터를 저장하고 가공하는 정도?

그것도 Time-out 걸리지 않을 정도로, 아주 가볍게 처리해야 한다는 것이다.

UPDATE 2010-01-30   21:40

Auzre의 Worker의 비동기 개념을 탑재 시켜준 거와 비슷한 기능이 있다.

Task Queue Java API다.  그런데, Time Out 레벨의 작업 역시 못하리라 생각은 든다.

Workflow 형태로 뭔가 Back-end에서 실행은 할 수 있을지는 모르겠는데,

역시 동작에 필요한 무언가의 작업은 Google Apps 내 웹을 부르는 작업을 수행한다.

하지만 아직 이 부분에 대해서 실험은 안 해봤다.

(게다가 이 동작 Java 에서는 베타 테스트 중이다. )

아직은 개발 도상 단계인듯. 조금 더 살펴봐야 겠다.

관리자 콘솔(Administration Console)를 사용하여 App Engine 안의 각종 응용 프로그램을 생성하고, 관리할 수 있습니다. 응용 프로그램에 대한 응용 프로그램 ID를 한번 등록하면, 다른 이클립스 플러그인이든, SDK 에서 제공하는 명령줄 도구를 사용하든, App Engine으로 업로드 할 수 있습니다.

NOTES: 응용 프로그램 ID를 한번 등록한 뒤, 그 응용 프로그램을 삭제하면, 나중에 그 ID로 같은 응용 프로그램을 올리지 못합니다. 만일 지금 등록하지 않으려면, 이 단계를 건너 뛰시기 바랍니다.

응용 프로그램 등록하기.

App Engine 관리자 콘솔에서 App Engine 웹 응용 프로그램들을 생성하고 관리할 수 있습니다. 이 App Engine 관리자 콘솔에 접속하려면 다음 URL에 접속하도록 합니다.

https://appengine.google.com/

지금 사용 중인 구글 계정을 통해 이 App Engine에 가입하도록 합니다. 구글 계정이 없으시면, 이메일 주소와 암호를 가지고 https://www.google.com/accounts/ 에서 구글 계정을 생성하실 수 있습니다.

응용 프로그램을 생성하려면, "Create an Application" 버튼을 클릭하시기 바랍니다. 그리고 그 안에서 설명하는 내용을 따라 이 응용 프로그램에 대한 application ID와 고유한 이름을 등록하시기 바랍니다. 만일 무료로 도메인을 제공하는 appspot.com 을 그대로 사용한다면, 전체 URL은 http://application-id.appspot.com 이 됩니다. 아니면 top-level의 별도의 도메인을 구입하여 사용하신다면, 원하는 이름으로 설정하여 구성하실 수 있습니다.

일단 응용 프로그램 ID를 받았으면 그 내용을 지금 만든 응용 프로그램에 그 내용을 넣어주셔야 합니다. 그 방법은, appengine-web.xml 파일을 연 뒤, <application> 엘리멘트 안에 등록한 응용 프로그램 ID를 넣어주시면 됩니다.

응용 프로그램 올리기.

이클립스를 사용하여 응용 프로그램을 올리는 방법은 간단합니다.

모든 동작은 Google Apps SDK의 플러그인에서 대부분 자동으로 처리해 줍니다.

일단 응용 프로그램이 모두 정상적으로 동작한 것을 확인 하셨으면,

툴 바에서 App Engine deploy 버튼(

그리고 아이디와 암호 입력창이 뜨면, 구글 계정에 대한 아이디(이메일 주소)와 암호를 넣어주시면 됩니다. 그리고 Upload 버튼을 클릭해주시면 됩니다. 그러면 이클립스에서는 앞서 수정한 appengine-web.xml 에서 응용 프로그램 ID와 버전 정보를 가져와서 war/ 디렉터리에 있는 파일을 패키징 해서 업로드 하기 시작합니다.

올린 응용 프로그램 실행해보기.

App Engine 상에 만든 응용 프로그램을 실제로 확인할 차례 입니다. 간단하게 무료로 제공하는 appspot.com 도메인을 통해 바로 접속해 볼 수 있습니다.

http://application-id.appspot.com

축하드립니다!!!

이제 기초적인 내용은 모두 끝났습니다. 최소한 이 단계까지 오셨다면 Java를 이용한 Google Apps Engine 용 응용 프로그램 만들기의 처음부터 끝까지 다 거친 것입니다.

이 외의 더 자세한 내용은 App Engine 문서를 통해 자세하게 확인해보시기 바랍니다.

You create and manage applications in App Engine using the Administration Console. Once you have registered an application ID for your application, you upload it to App Engine using either the Eclipse plugin, or a command-line tool in the SDK.

보통 웹 브라우저로 정적 파일을 그대로 전달하는 방법은 다양하게 있습니다. 이미지, CSS 스타일시트, 자바스크립트 코드, 동영상 및 플래쉬 애니메이션 등은 일반적으로 브라우저에서 내용 그대로 받게 됩니다. 그러므로 보다 효율적인 App Engine 운영을 하려면, 이런 정적 파일들을 각 서블릿과는 별개로 제공하는 방법이 좋습니다.

기본적으로 App Engine은 JSP와 WEB-INF/ 안의 파일들을 제외한 정적 파일들 모두 WAR 안에 만들게 됩니다. URL에 대한 요청들 중 정적 파일들에 해당하는 경로가 있으면, 그에 맞는 정적 파일들을 제공하게 됩니다.

서블릿 또는 필터된 매핑 또한 그런 규칙에 맞게 진행됩니다.

이것을 각 파일 별로 별도 구성하여 App Engine이 정적 파일들에 대해서 처리하지 않도록 구성할 수 있습니다. 그 설정은 appengine-web.xml 파일을 사용하여 구성하게 됩니다.

지금 부터 CSS 스타일 시트로 방명록 표현방법을 구성하도록 하겠습니다.
하지만, 이 예제에서는 정적 파일에 대한 설정을 다루지는 않습니다. 정적 파일과 자원 파일들에 대해 설정하기 위한 자세한 정보는 App Configuration을 보시기 바랍니다.

간단한 스타일시트

war/ 디렉터리 안에 stylesheets/ 라는 이름의 스타일 시트를 만드시기 바랍니다.  그리고 그 안에 main.css 파일을 생성한 뒤에 다음과 같은 내용으로 채우시기 바랍니다.

body {
    font-family: Verdana, Helvetica, sans-serif;
    background-color: #FFFFCC;
}

war/guestbook.jsp 파일을 연 뒤에 파일의 맨 위에 있는 <html> 줄 다음 줄을 다음과 같이 수정해주시기 바랍니다.

<html>
  <head>
    <link type="text/css" rel="stylesheet" href="/stylesheets/main.css" />
  </head>

  <body>
    ...
  </body>
</html>

자 이제 http://localhost:8080 으로 접근해보시기 바랍니다. 그러면 스타일 시트로 바뀐 새로운 화면을 보실 수 있습니다.

다음은...

이제 지금까지 구성한 내용을 실제 Google Apps Engine에 등록해 보도록 하겠습니다.

응용 프로그램 올리기에서 계속 됩니다.

원본글 : http://code.google.com/appengine/docs/java/gettingstarted/usingdatastore.html

NOTES: 지금까지 개인적으로 Google Apps를 이용하여 간단한 Application을 개발하고,

배포해서 적용해 봤습니다. 초라하고 엉성하기 그지 없지만, 나름 Google Apps Engine에

대한 생각이 정리되기 시작했습니다. 사실 이거 2009년 말에 모두 번역에서 등록하려고
했는데, 이 데이터 저장 부분은 번역하면서 막히기도 하고, 개념도 이해가 안가, 상당히

망설인 부분 이였습니다. 그래서 직접 몸으로 체험을 해봤습니다.
하지만 여전히 내용이 무척 어렵습니다. 짧은 Java 실력 때문에,
20세기 말에서 부터 지금까지 만들어진 각종 Java 표준을 거의 모르다 보니,
전혀 생뚱맞게도 번역되는 군요. 어느정도의 원리라도 알면 쉽게 번역 될텐데...

그냥 강행 하렵니다!!!!!!

확장성을 갖춘 웹 응용프로그램에서 데이터를 저장하는 방법은 약간의 편법이 요구 됩니다. 사용자가 요청한 작업을 처리하기 위한 웹 서버가 여러 대 인 경우, 그 사용자의 다음 요청에 대해서도 정상적인 처리 될 수 있도록 이전 요청 내용에 대해서 모든 웹 서버들이 알고 있어야 한다는 점입니다. 이 때문에 물리적으로 완전 분리되어 다른 지역에 있는 웹 서버일지라도 이 사용자 정보를 모두 공유해서 보유 해야 될 것입니다.

Google Apps Engine에서는 이런 분산 환경에 대한 문제에 대해 여러분이 걱정하지 않도록 도와드립니다. App Engine의 인프라 스트럭처에서는 단순한 API 뒤에서 동작되는 분산 환경의 관리, 데이터 복제 및 부하 분산까지 고려되어 제공됩니다. 물론 단순한 API라고 해도 강력한 query 엔진과 트랜젝션 관리를 처리할 수 있도록 도와드립니다.

Apps Engine의 데이터 저장은 두 가지 유형의 API를 통해 각종 저장 관련 서비스를 제공합니다. 그 API의 두 가지 유형에는 표준형 API와 저 수준(low-level) API가 있습니다. 
표준형 API를 사용한다면, 실제 구현한 내용 그대로, 다른 데이터베이스 기술과 호스팅 환경으로도 쉽게 이식 적용이 가능합니다. 표준 API는 App Engine서비스와 여러분의 응용 프로그램 간의 의존성을 최대한 낮추도록 설계되어 있습니다. 
물론 Apps Engine 에서 제공되는 서비스를 직접 활용할 수 있도록 저수준(low-level) API를 제공하고 있습니다. 이 저수준 API를 사용하여 새로운 아답터 인터페이스를 별도로 구현할 수 있으며, 직접 응용 프로그램 내에서 사용할 수도 있습니다.

App Engine은 두 가지의 다른 데이터 저장 표준 - Java Data Object(JDO)와 Java Persistence API(JPA) - 서비스를 포함하고 있습니다. 이들 인터페이스는 DataNucleus Access Platform을 기반으로 구성되어 있습니다. 이 DataNucleus Access Platform은 다양하게 있는  Java persistence 표준들을 구현한 오픈 소스로써 App Engine 저장소에서는 이 플랫폼에 대한 아답터를 사용하고 있습니다.

방명록에서는 JDO 인터페이스를 사용하여 사용자가 남긴 메시지를 다시 불러올 수 있도록 구성할 것입니다.

DataNucleus Access Platform 구성하기.

Access Platform에는 JDO 구현에 대한 배경을 App Engine 저장소로 사용한다고 알려주기 위한 설정 파일이 필요합니다. 이 설정 내용은 최종 WAR 안에, war/WEB-INF/META-INF 디렉터리 안에 jdconfig.xml이라는 이름의 파일이 있어야 합니다. 

이클립스를 사용하신다면, 프로젝트 탐색기에서 src/META-INF 안 에 jdconfig.xml 파일을 생성해주시면 됩니다.

jdconfig.xml 파일에는 다음과 같은 내용이 담기면 됩니다.

<?xml version="1.0" encoding="utf-8"?>
<jdoconfig xmlns="http://java.sun.com/xml/ns/jdo/jdoconfig"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="http://java.sun.com/xml/ns/jdo/jdoconfig">

    <persistence-manager-factory name="transactions-optional">
        <property name="javax.jdo.PersistenceManagerFactoryClass"
            value="org.datanucleus.store.appengine.jdo.DatastoreJDOPersistenceManagerFactory"/>
        <property name="javax.jdo.option.ConnectionURL" value="appengine"/>
        <property name="javax.jdo.option.NontransactionalRead" value="true"/>
        <property name="javax.jdo.option.NontransactionalWrite" value="true"/>
        <property name="javax.jdo.option.RetainValues" value="true"/>
        <property name="datanucleus.appengine.autoCreateDatastoreTxns" value="true"/>
    </persistence-manager-factory>
</jdoconfig>

JDO Class 확장하기.

JDO 클래스를 만들 때, 어떻게 데이터가 저장되어 구현될지, 데이터를 조회할 때 다시 인스턴스를 만들지에 대하여 Java의 문법을 활용하여 구성할 수 있습니다. Access Platform에서 데이터 클래스와 컴파일 후 처리되는 단계의 구현물 간의 연결을 수행할 때 그 DataNucleus 를 "확장된" 클래스라고 부르게 됩니다.

이클립스와 Google Plugin을 사용하게 되면, 플러그인에서 JDO 클래스에 대한 확장 작업을 빌드 단계 때 자동으로 수행하게 됩니다. 이클립스가 없다면...  Ant를 사용하여 하게 되는데, 그 내용은 원본 문서를 활용해 주세요.

JDO 클래스의 확장에 대한 더 자세한 내용은 JDO를 사용하기(Using JDO)를 참고하시기 바랍니다.

POJOs 와 JDO 문법

DataNucleus Access Platform과 같은 JDO호환 아답터로 Java 객체(대부분 Plan Old Java Objects 또는 POJOs 라고 불린다.)를 JDO로 저장할 수 있습니다. App Engine SDK에는 App Engine 저장소를 위한 Access Platform 플러그 인이 포함되어 있습니다. 즉, App Engine 데이터 저장소에 정의하려는 내용을 클래스 형태로 구현하여 저장 할 수 있다는 것입니다.  마찬가지로 JDO API를 사용하여 객체를 통해 데이터를 가져올 수도 있다는 것입니다. Java 문법을 사용하여 만든 클래스의 인스턴스를 저장하거나 재 생성하는 방법만 JDO에 전달 할 수 있으면 되는 것입니다.

방명록에 올린 개별 메시지를 표시 할 때 사용될 Greeting 클래스를 만들어보도록 하죠.

일단 guestbook 패키지 안에 Greeting 이라는 클래스를 생성하시기 바랍니다. 이 클래스 안에 채울 내용은 다음과 같습니다.

package guestbook;

import com.google.appengine.api.datastore.Key;
import com.google.appengine.api.users.User;

import java.util.Date;
import javax.jdo.annotations.IdGeneratorStrategy;
import javax.jdo.annotations.IdentityType;
import javax.jdo.annotations.PersistenceCapable;
import javax.jdo.annotations.Persistent;
import javax.jdo.annotations.PrimaryKey;

@PersistenceCapable(identityType = IdentityType.APPLICATION)
public class Greeting {
    @PrimaryKey
    @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
    private Key key;

    @Persistent
    private User author;

    @Persistent
    private String content;

    @Persistent
    private Date date;

    public Greeting(User author, String content, Date date) {
        this.author = author;
        this.content = content;
        this.date = date;
    }

    public Key getKey() {
        return key;
    }

    public User getAuthor() {
        return author;
    }

    public String getContent() {
        return content;
    }

    public Date getDate() {
        return date;
    }

    public void setAuthor(User author) {
        this.author = author;
    }

    public void setContent(String content) {
        this.content = content;
    }

    public void setDate(Date date) {
        this.date = date;
    }
}

인사말을 저장하기 위한 3가지의 간단한 속성(author:작성자, content:내용, date:작성일)을 클래스 안에 정의했습니다. 이 세가지 private 필드들은 각각 @Persistence 라는 문법을 추가하여 App Engine 저장소에 저장될 항목들임을 알려주게 됩니다.

이 클래스에는 이 속성 값을 가져오고 넣을 수 있는 인터페이스도 만들어서 넣었습니다. 하지만 이것은 응용프로그램 내에서 사용하는 내용일 뿐 JDO에서는 사용하지 않습니다. ( 즉 이름이 조금 틀려도 상관 없다는 의미입니다.)

여기서 주목해서 봐주시면 하는 것이 바로 key 라는 필드 입니다. key에서는 @Persistence 뿐만 아니라 @PrimaryKey라는 Java 문법이 추가되어 있습니다. App Engine 저장소에는 사용되는 각 Entity(레코드)를 고유하게 구분하기 위한 키라는 개념이 있는데, 이 키를 표현하는 방법이 객체에 따라 여러 가지 다른 방법들이 있습니다. App Engine 저장소에서 각종 키들을 표현하는 모든 방법은 Key 라는 클래스에 정의되어 있습니다. 방법 중에서 일반적으로 사용되는 방법은 객체가 저장 될 때 유일한 값을 자동적으로 정의해서 넣는 숫자형 ID를 주로 사용됩니다.

JDO 문법에 대하여 더 자세한 내용은 Data Classes를 정의하는 방법(Defining Data Classes)를 참고하시기 바랍니다. 

PersistenceManagerFactory에 대해

위와 같은 구조에서는 요청이 들어올 때 마다 저장소는 PersistenceManager 클래스의 새 인스턴스를 계속 생성하게 됩니다. 이를 위해서 PersistenceManagerFactory 클래스를 만들어 사용하면 더 간단하게 구성하실 수 있습니다. PersistenceManagerFactory 인스턴스는 초기화 될 때 만들어지게 됩니다. 다행히도, 응용 프로그램 내에서는 단 한 개의 인스턴스만 있으면 되기 때문에, 여러 클래스들과 여러 번의 요청에서도 사용될 수 있는 정적 변수 하나에 저장되어 있으면 됩니다. 이런 정적 인스턴스를 들고 있을 싱글톤 형태의 클래스만 생성하면  간단하게 처리됩니다.

guestbook 패키지 안에 PMF라는 이름의 새로운 클래스를 생성한 뒤(src/guestbook 디렉터리 안에 PMF.java라는 파일을 만들면 됨), 다음과 같은 내용을 넣어주시면 됩니다.

package guestbook;

import javax.jdo.JDOHelper;
import javax.jdo.PersistenceManagerFactory;

public final class PMF {
    private static final PersistenceManagerFactory pmfInstance =
        JDOHelper.getPersistenceManagerFactory("transactions-optional");

    private PMF() {}

    public static PersistenceManagerFactory get() {
        return pmfInstance;
    }
}

개체를 생성하고 저장하기.

Greeting 클래스에 적절한 위치에, DataNucleus를 사용하여 저장소에 새로운 인사말을 저장하기 위한 처리 로직을 구성하면 됩니다.  

일단 src/guestbook/SignGuestbookServlet.java 파일을 열어 다음과 같은 내용처럼 재구성해주시면 됩니다.

package guestbook;

import java.io.IOException;
import java.util.Date;
import java.util.logging.Logger;
import javax.jdo.PersistenceManager;
import javax.servlet.http.*;
import com.google.appengine.api.users.User;
import com.google.appengine.api.users.UserService;
import com.google.appengine.api.users.UserServiceFactory;

import guestbook.Greeting;
import guestbook.PMF;

public class SignGuestbookServlet extends HttpServlet {
    private static final Logger log = Logger.getLogger(SignGuestbookServlet.class.getName());

    public void doPost(HttpServletRequest req, HttpServletResponse resp)
                throws IOException {
        UserService userService = UserServiceFactory.getUserService();
        User user = userService.getCurrentUser();

        String content = req.getParameter("content");
        Date date = new Date();
        Greeting greeting = new Greeting(user, content, date);

        PersistenceManager pm = PMF.get().getPersistenceManager();
        try {
            pm.makePersistent(greeting);
        } finally {
            pm.close();
        }

        resp.sendRedirect("/guestbook.jsp");
    }
}

(굵은 글자의 표시가 불분명하여 밑줄을 추가했습니다.)

이 코드는 생성자를 호출하여 Greeting 클래스의 새로운 인스턴스를 만들 때 데이터를 채우게 됩니다. 그리고 저장소에 이 인스턴스의 내용을 저장하기 위해 PersistenceManagerFactory를 통해 PersistenceManager를 새로 생성 한 뒤, 데이터 인스턴스를 PersistenceManager의 makePersistence() 메소드에 넘기게 됩니다. 이제 클래스에서 정의된 Java 규칙에 맞게 바이너리 확장이 되고 데이터가 저장소로 전달되게 됩니다. makePersistent()를 갔다오게 되면 저장소에 데이터 내용이 저장되게 됩니다.

JDOQL로 데이터 조회하기.

JDO 표준에는  persistent 객체를 조회할 때 사용하는 매커니즘이 정의되어 있습니다. 이 매커니즘을 보통 JDOQL이라고 부릅니다. App Engine 저장소에 있는 entity들을 조회할 때 이 JDOQL을 사용하게 되면, JDO-확장 객체 형태의 결과 값을 돌려주게 됩니다.

여기서는 그 사용 예제를  guestbook.jsp에서 직접 쿼리 코드를 직접 다루어 처리하는 형태로 구성할 예정입니다. 하지만 일반적인 형태로 만들 경우에는 가급적 데이터 처리용 대리자 클래스를 별도로 구성하여 사용하는 것이 좋습니다.

일단 war/guestbook.jsp를 연 뒤에 다음 코드 형태대로 수정하시기 바랍니다.

<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%@ page import="java.util.List" %>
<%@ page import="javax.jdo.PersistenceManager" %>
<%@ page import="com.google.appengine.api.users.User" %>
<%@ page import="com.google.appengine.api.users.UserService" %>
<%@ page import="com.google.appengine.api.users.UserServiceFactory" %>
<%@ page import="guestbook.Greeting" %>
<%@ page import="guestbook.PMF" %>

<html>
  <body>

<%
    UserService userService = UserServiceFactory.getUserService();
    User user = userService.getCurrentUser();
    if (user != null) {
%>
<p>Hello, <%= user.getNickname() %>! (You can
<a href="<%= userService.createLogoutURL(request.getRequestURI()) %>">sign out</a>.)</p>
<%
    } else {
%>
<p>Hello!
<a href="<%= userService.createLoginURL(request.getRequestURI()) %>">Sign in</a>
to include your name with greetings you post.</p>
<%
    }
%>

<%
    PersistenceManager pm = PMF.get().getPersistenceManager();
    String query = "select from " + Greeting.class.getName();
    List<Greeting> greetings = (List<Greeting>) pm.newQuery(query).execute();
    if (greetings.isEmpty()) {
%>
<p>The guestbook has no messages.</p>
<%
    } else {
        for (Greeting g : greetings) {
            if (g.getAuthor() == null) {
%>
<p>An anonymous person wrote:</p>
<%
            } else {
%>
<p><b><%= g.getAuthor().getNickname() %></b> wrote:</p>
<%
            }
%>
<blockquote><%= g.getContent() %></blockquote>
<%
        }
    }
    pm.close();
%>

    <form action="/sign" method="post">
      <div><textarea name="content" rows="3" cols="60"></textarea></div>
      <div><input type="submit" value="Post Greeting" /></div>
    </form>

  </body>
</html>

쿼리를 준비하기 위해 먼저 PersistenceManager 인스턴스의 newQuery() 메소드를 호출합니다. 이 메소드에 실제로 쿼리로 사용할 Text 내용을 건네 주게 됩니다. 이 메소드의 실행 결과 값은 쿼리에 대한 개체 입니다. 쿼리 개체의 execute() 메소드를 호출하게 되면 정의한 쿼리 내용대로 실행하게 되며, 그 결과 값은 각 유형에 맞는 결과 개체를 List<>로 돌려주게 됩니다. 쿼리 문장에는 쿼리를 할 클래스의 전체 이름 - 패키지 이름까지 포함한 - 을 반드시 넣어주어야 합니다.

프로젝트를 다시 빌드한 뒤, 서버를 재시작합니다. http://localhost:8080/ 에 들어갑니다. 인사말을 넣고 submit을 하도록 합니다. 폼 위에는 인사말이 표시될 것입니다. 계속 각각 다른 인사말을 넣고 submit을 하도록 합니다. 그러면 입력했던 인사말들이 계속 표시됩니다. 이제는 로그인 했을 때 다른 인사말을 submit 해보고, 로그아웃 했을 때 다시 인사말을 넣고 submit을 해보도록 하세요.

Tip: 실제 사용되는 응용 프로그램에서는 HTML용 문자들(태그 등등)에 대해 Escape 처리하는 것이 좋습니다. JavaServer Pages Standard Tag Library(JSTL)에는 이런 Escape 처리를 위한 도구들을 제공합니다. App Engine에는 JSTL(및 기타 JSP 관련 런타임 JAR들)을 포함하고 있어, 이런 Escape 처리를 위해 별도로 관련 JAR들을 포함시킬 필요는 없습니다.  escapeXml 함수에 대한 자세한 설명은 태그 라이브러리http://java.sun.com/jsp/jstl/functions 에서 보시기 바랍니다.

더 자세한 내용은 Sun의 J2EE 1.4 튜토리얼을 참고하시기 바랍니다.

JDOQL 기초

방명록 예제에서는 시스템 내에 등록된 모든 메시지들을 보여주고 있습니다.이 메시지들이 표시되는 순서는 알 수 없는 순서로 나열되고 있는데, 이를 메시지가 생성된 순서대로 나열하도록 하겠습니다. 또 너무 많은 메시지가 저장되어 있을 때, 최신의 메시지가 맨 위에 오도록 하는 것이 좋을 것입니다. 이런 조정을 쿼리를 수정함으로써 간단하게 처리가 가능합니다.

SQL과 유사하게 생긴 쿼리 문법인 JDOQL을 이용하여 JDO 인터페이스에 처리를 요청하여 원하는 데이터 개체들을 조회하는 것입니다. 앞서 편집한 JSP 페이지의 코드 내용을 보시면 다음 내용과 같은 부분을 보실 수 있습니다.

String query = "select from " + Greeting.class.getName();

이 내용을 실행하면 query라는 변수 안에 다음과 같이 담기게 됩니다.

select from guestbook.Greeting

즉 이 쿼리 문장을 통해 조회하게 되면 Greeting 클래스를 이용하여 저장한 모든 데이터를 가져오게 됩니다.

결과물로 돌려줄 객체의 속성값을 제한 값으로 쿼리에 포함하게 되면, 결과 값을 제한시켜 받을 수 있게 됩니다. 예를 들면 Greeting 객체에 있는 author라는 속성 값이 alfred@example.com 인 개체만을 가져오려면 다음과 같이 쿼리를 만들면 됩니다.

select from guestbook.Greeting where author == 'alfred@example.com'

또 특정 속성값을 기준으로 순서에 맞게 정렬 할 수도 있습니다. 최신글을 맨위로 해서 정렬을 한다고 할 때는 다음과 같이 쿼리를 만들면 됩니다.

select from guestbook.Greeting order by date desc

또 쿼리 결과물 갯수를 제한할 수 있습니다. 만일 최신 메시지 5개까지만 가져오도록 하고 싶다면, order by 와 range를 동시에 써서 표현 하면 됩니다. 그 쿼리는 다음과 같습니다.

select from guestbook.Greeting order by date desc range 0,5

guestbook.jsp 안의 쿼리를 수정하여 위에서 언급한 대로 최근 메시지 5개만 뿌리도록 설정하도록 하죠.

그러려면 guestbook.jsp 안의 쿼리 부분을 아래와 같이 수정하시면 됩니다.

String query = "select from " + Greeting.class.getName() + " order by date desc range 0,5";

그러면 가장 최근에 등록된 인사말 중 5개까지만 나타나게 될 것입니다.

JDOQL에 대한 더 자세한 내용은 Query와 Index를 참고하시기 바랍니다.

다음은...

모든 웹 응용 프로그램들은 템플릿이나 기타 매커니즘을 통해 동적으로 생성된 HTML을 돌려주게 됩니다.하지만 여전히 많은 웹 응용 프로그램들은 추가적으로 정적 컨텐츠 - 이미지, CSS, JavaScript 파일 등등 - 역시 같이 제공되고 있습니다. 이 때 응용 프로그램 구성을 보다 효과적으로 하기 위해서는 이러한 정적 파일과 응용프로그램은 명확하게 구분하는 것이 좋습니다.

다음 내용에서는 CSS 시트를 생성하여 응용 프로그램과 분리하여 구성하는 방법을 소개해 드리겠습니다.

정적 파일 사용하기에서 계속 됩니다.