728x90

Java에서 보면 DateTime 대신, Calendar를 주로 사용한다.
아마도 지역마다 다른 이유나, 음력 등을 이유로 Date 개체로 처리하기에는 한계가 있어,
Date를 더욱 막강하게 만든 것 같다.

현재 이런 저런 구성 중에, 특정 일자의 이전, 이후에 대한 판단이 필요한 경우가 발생하는데,
Date 클래스에 있는 befere, after 처럼 Calendar에도 존재한다.

문제는 매번 짤 때 마다, 이 before, after 함수의 의미를 헷갈릴 때가 너무 많아서,
여기에 기억 되새김질 겸해서 적는다.

 

{Calendar 개체}.before({비교대상})

이 기본 문법인데, 이것을 이해하는 방법은 애석하게도 미국인 식으로 생각해주어야 한다.

{Calendar 개체} before then {비교대상}

즉 저 before 라는 의미는 “{비교대상}보다 {Calendar 개체}가 이전 인가?”라는 의미와 같다.

 

역으로 after는 다음과 같이 이해하면 된다.

{Calendar 개체}.after({비교대상})

이 기본 문법인데, 이것을 이해하는 방법은 아래와 같다.

{Calendar 개체} after then {비교대상}

즉, “{비교대상}보다 {Calendar 개체}가 이후 인가?”라는 의미와 같다.

 

아래와 같은 예제 코드를 실행 해보면 대충 짐작이 갈 것이다.

public void testCalendarAfterBefore()
{
	Calendar cal = Calendar.getInstance();
	Calendar calTester = (Calendar) cal.clone();
	calTester.roll(Calendar.DATE, 1);
	System.out.println(calTester.before(cal));
	System.out.println(cal.before(calTester));
}

위의 예제를 실행하면 이와 같은 결과를 얻을 수 있다.

false
true

 

cal 에는 현재 시간이, calTester에는 +1일 날짜가 담긴다.
즉, calTester가 cal보다 1일 더 큰 날짜이다.

이것을 위의 예제를 영어로 해석한다면,

calTester before then cal

cal before then calTester

이것을 한국말로 보자면,

calTester는 cal 보다 이전 날짜인가? 당연 false.

cal은 calTester 보다 이전 날짜인가? 당연 true.

 

단! 주의할 점은 저 비교는 모두 <. > 이지, 같은 것은 false 이다.

public void testCalendarAfterBefore()
{
	Calendar cal = Calendar.getInstance();
	Calendar calTester = (Calendar) cal.clone();
	
	System.out.println(calTester.before(cal));
	System.out.println(cal.before(calTester));
}

처음 예제 와는 다르게 아예 두 개가 같은 날인 경우 비교가 되지 않는다.
그래서 결과 값은 모두 false로 떨어진다.

false
false

만일 이전/이후 뿐만 아니라, 같거나 이전, 같거나 이후 이렇게 하려면,
같은지 여부를 반드시 먼저 체크해준 뒤에 이전/이후를 구분하여 처리해야 할 것 같다.

 

이 정도 적었으니, 잊어 버리진 않을 것 같다 ㅎㅎ.

  1. 개발자 하늘늑대 2017.03.07 05:39

    지금까지 currentTimemills()만 쓰다가 Calendar로 넘어오니 헷갈려서 검색해봤는데 바로 도움이 되는 글을 찾았네요 :)
    좋은 강좌 감사합니다.

728x90

관리자 콘솔(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.

728x90

보통 웹 브라우저로 정적 파일을 그대로 전달하는 방법은 다양하게 있습니다. 이미지, 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에 등록해 보도록 하겠습니다.


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

728x90

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


Google App Engine에서는 Google 인프라 스트럭처를 활용한 몇몇 유용한 서비스를 제공합니다.

이 서비스들은 SDK에 포함된 라이브러리를 이용하여 응용 프로그램에서 접근 가능합니다.

Users Service와 같은 서비스는 Google 사용자 계정과 통합되어 여러분들의 응용 프로그램에서 활용할 수 있습니다. 그래서 응용 프로그램 내에 Google 계정을 이용해 가입된 사용자들의 정보를 활용할 수 있습니다.

이제부터 Users service를 이용하여, 개별 사용자 별로 인사말이 표시되게 끔 하는 방법을 구현하려 합니다.


Users 사용하기.

src/guestbook/GuestBookServlet.java를 편집하여 열어보면 다음과 같습니다.

package guestbook;

import java.io.IOException;
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;
public class GuestbookServlet extends HttpServlet {
    public void doGet(HttpServletRequest req, HttpServletResponse resp)
              throws IOException {
        UserService userService = UserServiceFactory.getUserService();
        User user = userService.getCurrentUser();

        if (user != null) {
            resp.setContentType("text/plain");
            resp.getWriter().println("Hello, " + user.getNickname());
        } else {
            resp.sendRedirect(userService.createLoginURL(req.getRequestURI()));
        }
    }
}


Eclipse를 이용한 디버거 내에 개발 서버가 실행되고 있다면,

이 파일을 변경/저장 후, Eclipse에서 새 코드에 대해 자동적으로 컴파일 되고

이미 동작중인 서버 내에 새로운 코드가 적용될 것입니다.

클래스, JSP, 정적 파일 및 appengine-web.xml 등이 변경되면 서버의 재 시작 없이 바로 서버에 적용됩니다. 하지만, web.xml 및 기타 설정 파일에 대해 설정한 내용은 반드시 서버를 재 시작 해야 합니다.

메시지를 표시하는 대신 서버에서 이메일을 표시하도록 합니다.
아무 이메일 주소(
alfred@example.com 등등)을 받고 “Log in”을 클릭합니다.
응용 프로그램에서는 메시지를 표시하게 되는데, 이 때, 여러분이 입력한 이메일 주소를 담게 됩니다.

GuestbookServlet 클래스에 대한 새로운 코드에서는
사용자가 Google Account에 가입되어 있는지를 확인하기 위해 Users API를 사용하게 됩니다.
만일 없다면, 사용자는 Google Account 가입 화면으로 리다이렉트 하게 됩니다. userService.createLoginURL(…)에서는 가입 화면으로 가는 URL을 돌려줍니다.
현재 페이지의 URL을 createLoginURL()에 넘겨 줌으로써
URL 별로 응용 프로그램이 다르더라도 적절한 URL로 리다이트렉트 하는데 상당히 편리합니다.

개발 서버는 Google Accouns의 가입 처리를 어떻게 적절히 맞추어 나타낼지 알고 있습니다.
여러분의 PC에서는 입력 받은 이메일 계정으로 가입 처리할 수 있도록, 가입 처리용 페이지로 이동하게 됩니다.

실제 App Engine 환경에서는 진짜 가압에 사용되는 곳으로 이동하게 됩니다.
즉  실제 Google Account 관리화면으로 넘어가게 됩니다.

테스트 응용 프로그램 상에서 가입이 되었다면 다시 한번 페이지를 불러 화면을 다시 표시해보도록 하세요.

사용자 로그 아웃 처리를 하려면, 이번에는 로그아웃 화면에 대한 링크를 제공해야 합니다.
이 링크는 createLogoutURL() 메소드로 생성됩니다.
참고로 로그 아웃 링크는 현재 사용자가 로그인 했던 모든 구글 서비스에 대해서 로그아웃 처리됩니다.


다음은…

이제 사용자의 정보를 어떻게 가져오는지 알았기 때문에,
방명록 상에 메시지를 게시할 사용자들을 초대할 수 있습니다.

이번에는 JavaServer Pages(JSP)를 사용하여

이 응용 프로그램에 대한 사용자 인터페이스를 설계하도록 하도록 하겠습니다.

JSP 사용하기 에서 계속됩니다.

728x90

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


App Engine Java 응용 프로그램은 Java 서블릿 표준을 이용하여 웹 서버 환경과 연동합니다.

컴파일 된 클래스, JAR, 정적 파일 및 설정 파일들을 포함한 응용 프로그램 파일들은

WAR 라는 자바 웹 응용 프로그램 표준 Layout을 이용하여 디렉터리 별로 정리되어 저장되게 됩니다.

이 WAR 디렉터리 구성은 다른 어떤 Java 웹 응용 프로그램 구성에서도 동일하게 적용됩니다.

( 애석하게도 SDK 에서는 이 WAR 저장 방식 파일에 대해서 지원되지 않습니다. )


프로젝트 디렉터리

현재 이 튜토리얼에서는 모든 프로젝트 파일들은 Guestbook/이라는 이름으로 된 단 하나의 디렉터리 안에 담겨 있습니다. src/ 라는 하위 디렉터리에는 Java 소스 코드들이 담겨 있으며, war/ 라는 하위 디렉터리에는 WAR 포맷에 맞게 구성된 응용 프로그램들이 담겨 있습니다.

Java 소스 파일들이 컴파일 되면 war/의 위치에 컴파일 된 파일들이 담기게 해야 합니다.


완전한 프로젝트 디렉터리는 다음과 같은 형태가 되어 있어야 합니다.

Guestbook/
  src/
    ...자바소스 파일들...
    META-INF/
      ...기타 설정 파일들...
  war/
    ...JSPs, 이미지, 데이터 파일...
    WEB-INF/
      ...응용 프로그램 설정 내용...
      lib/
        ...라이브러리 JAR들...
      classes/
        ...컴파일된 클래스들...

Eclipse 에서는 툴바에서 New Web Application Project 버튼()을 클릭하여 새로운 프로젝트를 생성하기만 하시면 됩니다. 새 프로젝트에 대한 설정 창에서 “Project Name”에는 Guestbook 을, “Package”에는 guestbook 을 넣어주시고 “Use Google Web Toolkit”의 체크를 풀어주시고, 대신 “Use Google App Engine”에 체크해주시기 바랍니다. 그러면 Eclipse의 Plugin에서 제공하는 마법사를 통해 위에서 언급한 디렉토리 구조를 구성하고 필요한 기본적인 파일들을 배치하게 됩니다.


SDK안에 포함된 새 프로젝트 템플릿을 직접 복사해서 구성하실 수도 있습니다.
이 템플릿은 appengine-java-sdk/demos/new_project_template/ 디렉터리에 위치해 있습니다.


서블릿 클래스

App Engine Java 응용 프로그램에서는 the Java Sevlet API를 이용하여 웹 서버와 직접적인 연결을 합니다. HTTP 서블릿은 응용 프로그램 클래스로 웹에서의 요청에 대한 응답 프로세스를 할 수 있습니다.
이런 요청 응답용 클래스는 javax.servlet.GenericServlet 클래스

또는 javax.servlet.http.HttpServlet 클래스를 상속 받은 클래스로 구성하게 됩니다.

예제로 구성된 방명록 프로젝트는 하나의 서블릿 클래스로 시작되어 있으며

단순한 서블릿을 사용하여 메시지를 출력하게 됩니다.


이 파일은 src/guestbook/ 디렉터리에 GuestbookServlet.java 파일로 다음과 같이 구성되어 있습니다.

package guestbook;

import java.io.IOException;
import javax.servlet.http.*;

public class GuestbookServlet extends HttpServlet {
    public void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws IOException {
        resp.setContentType("text/plain");
        resp.getWriter().println("Hello, world");
    }
}

web.xml 파일에 대해

웹서버에서 요청을 받았을 때, 서블릿 클래스에서는 “웹 응용 프로그램 배치 설명자(web application deployment descriptor)” 라고 불리는 구성 파일을 사용하여 요청된 서블릿 클래스을 선택하게 됩니다.

이 파일은 보통 web.xml 이라고 이름 지어지며, WAR 파일 안에 있는 war/WEB-INF/ 디렉토리에 담기게 됩니다. WEB-INF/ 와 web.xml은 서블릿 규칙에 따라 이름 지어지고 위치된 것입니다.

war/WEB-INF/ 디렉토리에 있는 web.xml 내용을 대략적으로 보면 다음과 같습니다.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE web-app PUBLIC
 "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
 "http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app xmlns="http://java.sun.com/xml/ns/javaee" version="2.5">
    <servlet>
        <servlet-name>guestbook</servlet-name>
        <servlet-class>guestbook.GuestbookServlet</servlet-class>
    </servlet>
    <servlet-mapping>
        <servlet-name>guestbook</servlet-name>
        <url-pattern>/guestbook</url-pattern>
    </servlet-mapping>
    <welcome-file-list>
        <welcome-file>/index.html</welcome-file>
    </welcome-file-list>
</web-app>


Eclipse에서 해당 XML을 열면 아래와 같이 보입니다.

이 web.xml 파일은 서블릿인 guestbook에 대한 선언을 담게 되며,

/guestbook 이라는 URL path와 연결되게 끔 구성하는 것을 보여주고 있습니다.

응용 프로그램의 WAR 안에 디렉토리 경로 상에서 없는 경로를 이용하여 서브릿과 연결하여,

외부에서는 전혀 다른 형태의 URL로 접근할 수 있도록 해줍니다.

하지만, 해당 하는 경로에 index.html 이 있다면, 서블릿 설정보다 index.html을 먼저 보여주게 됩니다.


appengin-web.xml 파일에 대해

App Engine은 추가적은 설정 파일이 하나 더 있습니다.

이 파일은 응용 프로그램을 어떻게 배포하고, 실행할지에 대해서 나타내는 설정 파일입니다.

반드시 이 파일은 web.xml 이 있는 WEB-INF/ 디렉토리 안에 위치해야 하며,

그 이름은 appengine-web.xml 이여야 합니다.

그 안에는 응용 프로그램의 등록 ID( Eclipse에서는 언제든지 채울 수 있도록 빈 ID를 생성하여 제공합니다. ), 정적 파일(이미지나 CSS 등등), 리소스 파일(JSP 파일이나, 기타 응용 프로그램 데이터)과 같이 명시적으로 나타낼 내용들을 담고 있습니다 .


war/WEB-INF/ 디렉터리 안에 있는 appengine-web.xml 이라는 파일은 다음과 같이 되어 있습니다.

<?xml version="1.0" encoding="utf-8"?>
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
    <application></application>
    <version>1</version>
</appengine-web-app>

appengine-web.xml 에는 App Engine에 대해 설명하는 내용을 담고 있지만,

서블릿 표준에 포함되는 내용은 아닙니다.

SDK에 보시면 이 파일의 형식에 대해 명기되어 있는 XML 스키마 파일을

appengine-java-sdk/docs 안에서 찾을 수 있습니다.

이 파일에 대한 자세한 설명은 Configuring an App를 보시기 바랍니다.


프로젝트 실행하기.

App Engine SDK 에는 여러분이 만든 응용 프로그램을 테스트 할 수 있도록

제공되는 웹서버 응용 프로그램을 포함하고 있습니다.

이 서버는 sandbox 제약영역, 저장소, 기타 서비스 등

각종 App Engine 환경에서 제공되는 기본적인 기능들을 모두 제공합니다.


이 웹서버는 Eclipse의 Debugger로 간단하게 시작할 수 있습니다.

Run 메뉴 안에 있는 Debug As > Web Application을 선택하기만 하면 됩니다. 

디버그 관련된 설정 방법은 Google Plugin in Eclipse 사용하기를 참고하시기 바랍니다.



응용 프로그램 테스트 하기.

서버가 시작되면, 여러분의 브라우저를 이용하여 다음 URL을 입력해보시기 바랍니다.

http://localhost:8080/guestbook

(간혹 설정 상으로 http://localhost:9999/guestbook 일 수도 있습니다. 
  포트 번호는 각자 확인해보시기 바랍니다. )
서버에서 서블릿을 호출하면, 브라우저 상에 메시지를 출력할 것입니다.


다음은…

여기 까지 오셨다면 기본적인 App Engine 응용 프로그램을 성공적으로 제작하신 것입니다!.
이제 이 내용을 배포만 하시면 전세계의 모든 사용자들과 권리를 누리며 나누실 수 있습니다.
이 응용 프로그램은 모든 사용자에 대한 일반적인 인사 내용을 보여줍니다.


이제부터는 인사말을 커스터마이징 하여,

Google Account로 접속한 사용자들에 대한 별도의 인사말을 만들어보도록 하겠습니다.


다음은, User Service를 사용하기 에서 계속 됩니다.

728x90

전문적으로 개발하는 것은 아니고, 어디까지나 취미로 시작했던 작업이다.

기존에 Azuare로 구현했던 내용을 이번에는 Google Apps Engine으로 개발한 것이다.

아마도 단순 접근성으로 따지면 단연 Google Apps Engine인 것 같다.

제일 먼저 높은 점수로 줄 수 있는 부분은 대부분의 비용이 Free 라는 사실이다.

이거 때문에, Azure에서 이 Google Apps Engine을 선택한 주요한 원인이니까,

상당한 매리트였다.

그리고 Java 지원. 사실 지금 그나마 다룰 줄 언어는 C/C++, C#, Java 뿐이니, Python이라든가, Peal 이렇게 나왔으면 아마도 GG였을 것 같다. Google Apps Engine 초창기는 Python 이라고 했는데, 그 당시의 생각만 했다면 접근 불가였을 것이다. 그런 시스템이 지금은 Java를 훌륭하게 지원한다.

다음은 시작하기 가뿐한 Start up Tutorial 이다. 이것 따라하기만 하면 금방 개념이라든가

처리하는 방법을 배울 수 있었다. 훌륭한 내용이지 않을까 싶다.


그러나, 이런 훌륭한 접근성에 비해 마음에 안드는 부분이 있기는 했다.

제일 먼저 Back 단에서 처리하는 작업을 하기 위한 일종의 Service 개념이 없었다.

지금까지 찾아서 확인한 것 까지 본다면, JSP 페이지와 같은 I/F를 통해 Request/Response 기반의

작업 뿐인 것 같다. 물론 cron 이나, queue와 같은 것들을 활용하여,

각 Request를 마치 Service 처럼 구성하면 될지는 모르겠지만…


처음에 아무 생각없이 Azure에서 구현한 방식대로 구현한 뒤, 내 PC에서 돌릴 때는 문제가 없었다가,

이번에 처음으로 Google Apps Engine에 올려보니, 역시 Request Time out 이 발생하였다.

아마도 Request가 들어오게 되면 처리하는 내용이 많다보니, Response까지 나오는 시간이

의외로 많이 걸리게 되었는데, 바로 걸려 버리는 문제가 발생했다.


일단, 소정의 목적만 달성하고, 현재는 재설계 계획 중이다.

Response가 빠르게 할 수 있도록 Job을 Page 단위로 분해하여 재조립을 해야 할 필요가 느껴졌다.

여튼 현재로는 Back 단에서 서비스 처럼 동작하는 부분이 없다는 약점만은 어떻게든 보완할 필요가 있다.
( 최소한 Azure에는 Worker 라는 개념이 있고, Amazone 에서는 Enterprise 서비스를 활용하면 그 안에서 처리할 방법이 있는 것 같다. )


Java로 웹 서비스 같은 것을 개발할 계획이라면, 한번 활용해 보는 것도 나쁘지 않을 것 같다!!

  1. Favicon of http://keepburning.tistory.com Keep Burning 2010.03.02 08:55

    구글 홈페이지 내 문서는 영어로 되어 있어서 대충은 알아도 정확히 읽히지 않았는데 해석해 놓은 문서보니 많은 도움이 되네요. 감사합니다.

    • 하인도 2010.03.02 16:54

      도움이 되신다니 다행입니다. 하지만, 제가 영어에 잼병이라, 그다지 정확한 번역 정보는 아닐겁니다(은근 오역 투성이입니다.) 이점 양해 드립니다 ^^

728x90

지금까지 해온 웹 프로그래밍은 ASP.NET 2.0 기반으로 해왔기 때문에, 이 지식을 기반으로 Java에 매핑하기 시작했다. 사실 지금까지 ASP.NET 2.0 형태로 Web Form을 구성하면서, 외부에 노출되지 않은 내부 기능들에 많이 답답해 왔던 것도 사실이다.


그런데, 이번 Java기반 웹 프로그래밍을 하면서 이 ASP.NET이 많은 부분에 있어 프로그래머에게 편의를 주고 있다는 점을 알게되었다. ( 물론 Java 기반의 웹 프로그래밍을 전부 파악하고 하는 말은 아니다. 분명 Java에서도 다양한 기능들이 있기 때문에, 쉽게 처리할 수 있는 방법은 있을 것이다. )


일단 ASP.NET 2.0 으로 넘어가면서 웹 페이지 디자인 코드 부분과 코드 부분이 명확하게 나뉘게 되었다. 그래서 실제적인 .NET 코드들은 코드 부분이 담기는 페이지에 담기고, HTML 부분은 ASP 부분에만 담기게 되었다. 그 사이를 IIS와 .NET 엔진에서 알아서 붙여 진행하였다. ( 이 부분은 대부분의 웹 프로그래밍 환경에서는 최악의 문제점으로 알고 있다. 디자인과 코드가 뒤엉키다 보면 유지보수가 너무 어렵다. )


더 결정적인 부분.

사실 Form에서 데이터를 전달할 때, Ghost 페이지라는 것을 만들어 사용했다. 즉, Form에서 입력된 데이터를 DB에 저장하거나, 그 데이터를 기반으로 특정 값을 찾는 작업을 하려고 할 때, 사용자에게 보여주지는 않는 페이지를 Form의 Action으로 등록하여 처리하는 것이다. 


이 때, Servlet과 JSP에서는 이렇게 처리한다.

JSP에는 실제 사용자에게 값을 입력 받을 때 사용되는 Form(혹은 결과값을 보여주는 Form)으로 제공되고, Servlet은 이 Form에서 만들어진 값을 받아 처리하게 되는 일종의 Ghost 페이지처럼 동작하도록 하는 것이다.


즉, 입력 Form(JSP) –> Servlet –> Form(JSP).


합리적이긴 하지만, ASP.NET 2.0 기반 프로그래머 입장에서는 순간 헤매기 십상일 듯 싶었다.

게다가 Servlet 이라는게 사실 Web Server와 직접 연동하여 동작하는 작업을 구성하는 것이기 때문에 왠지 접근하기가 쉽지 않은(.NET 에서는 이 부분의 로직을 모두 숨겨서 알아서 처리해 줬기 때문이다. )부분이라, 망설임이 지대로다.


지금 Google Apps Engine 코드들을 하나씩 까면서 차근 차근 따라가보고 있다.

뭐랄까 새록새록 한 기분?

728x90

이 글은 하인도님의 2009년 11월 18일에서 2009년 12월 10일까지의 미투데이 내용입니다.

+ Recent posts