Struts 2.1 + ajax 플러그인 : dojo툴킷 이용 방법 변경

2009/08/26 10:57
Leave a Comment

서비 JAVA , , , ,

실로 오랜만에 struts 2 (정확히는 2.1.6 )를 잡았습니다.
개발팀원이 참조 할 몇몇 코드조각들을 작성하고 있는데 어제는 ajax tag 쪽 코드를 작성했습니다.
코드를 작성해 실행을 시켰는데 아래와 같은 몇몇 오류와 맞닥뜨립니다.


Template /template/ajax/head.ftl not found. - Class: freemarker.template.Configuration 
File: Configuration.java 
Method: getTemplate 
Line: 489 - freemarker/template/Configuration.java:489:-1



org.apache.jasper.JasperException: Expression parameters.parseContent is undefined on line 45, column 28 in template/ajax/head.ftl. - Class: freemarker.core.TemplateObject
File: TemplateObject.java
Method: assertNonNull



Expression parameters.pushId is undefined on line 24, column 6 in template/ajax/a-close.ftl. 
The problematic instruction: 
---------- 
==> if parameters.pushId [on line 24, column 1 in template/ajax/a-close.ftl]


원인은 스트럿츠 2.1 릴리즈!! Committer 인터뷰에서도 언급되었던 내용에서 기인합니다.
기존 strtus2 에서 Dojo 툴킷을 이용한 ajax를 이용하기 위해서 <s:head theme="ajax" /> 같이
기술하던 부분이 deprecated 되었습니다. strtus2.1에서 ajax 태그를 이용하기 위해서는
문서 상단에 <%@ taglib prefix="sx" uri="/struts-dojo-tags" %> 와 같이 새로운 태그 라이브러리를
지정하고 <s:head theme="ajax" /> 를 <sx:head parseContent="true"/> 로 수정,
<s:div ... /> 부분도 <sx:div ... /> 로 바뀔 뿐만 아니라 각 태그의 속성들도 변화가 있습니다.

스트럿츠 2.0 과 2.1의 차이점을 확인하고 싶으시거나 2.0을 2.1로 마이그레이션을
고려하고 계신다면 Apache Strtuts 2 Wiki 의
Troubleshooting guide migrating from Struts 2.0.x to 2.1.x
를 참고하시면 좋을 듯합니다.
이 글의 관련글
  • Vector에 대한 소고
  • ZIP/JAR 엔트리의 생성 제어하기
  • String 타입의 날짜를 Date 타입으로 변환하기
  • 넷빈즈를 이용한 Open Office 플러그인 개발
  • JVM에서 얻어오는 시간이 시스템시간과 차이가 날 때.
  • Creating a Simple SOA Project with NetBeans Enterprise Pack
  • 넷빈즈(NetBeans)를 구하고 설치 해 보자. v1.0
  • 자바는 call by value? call by reference? (1)
  • 객체 지향론자를 위한 함수 프로그래밍(Functional programming)
    • 2009/08/26 10:57 2009/08/26 10:57
    Trackback Address:http://www.yunsobi.com/blog/trackback/505
    [로그인][오픈아이디란?]

    Javascript Framework Prototype

    2007/11/22 03:03
    Leave a Comment

    서비 Tip&Tech , ,

    참고해야할 사이트들...

    Developer Notes for prototype.js -  Prototype의 개발자 노트

    Site design using Prototype - AJAX 이용 가이드~ JSON-PHP라는 것과 이클립스용 AJAX extension을 주목

    AJAX Design Patterns - AJAX 디자인 패턴

    Learning the JavaScript debugger Venkman     - 자바스크립트 디버거 환경 갖추기


    라이브러리

    Rico - LiveGrid같은 기능을 하는 Ajax를 찾고 있었는데!

    script.aculo.us - Sortable List가 일품!

    Moo.fx - 가벼우면서도 센스있는 디자인을 위한 라이브러리. Prototype에는 링크가 안되어있는데 꼭 놓치지 말고 보아야할 곳!

    ZK - 디자인이 좀 투박하긴 하지만, 에러 메세지 보여주는 거랑 아쿠아 런처 스타일의 링크가 일품

    dhtmlgoodies - 쓸만한 예제가 많다. 특히 Tab view는 감동 감동. Folder tree가 쓸만할 듯 그리고 Color Schemer와 Reg. tool, CSS lookup 등 쓸만한 툴도 일품!

    LightBox - 이미지를 이쁘게 보여줄 수 있다.

    이 글의 관련글
  • Ajax와 XML: 다섯 가지 Ajax 안티 패턴(anti-pattern)
  • Ajax와 Java EE의 통합
  • Struts 2.1 + ajax 플러그인 : dojo툴킷 이용 방법 변경
  • AJAX와 XML: 다섯 개의 일반적인 Ajax 패턴
    • 2007/11/22 03:03 2007/11/22 03:03
    Trackback Address:http://www.yunsobi.com/blog/trackback/272
    [로그인][오픈아이디란?]

    Ajax와 XML: 다섯 가지 Ajax 안티 패턴(anti-pattern)

    2007/05/17 23:11
    Leave a Comment

    서비 Tip&Tech , ,

    원문출처 : http://www.ibm.com/developerworks/kr/library/x-ajaxxml3/(새 창으로 열기)

    Ajax 코드의 일반적인 함정 피하기

    난이도 : 중급

    Jack D Herrington, Senior Software Engineer, Leverage Software Inc.

    2007 년 5 월 15 일

    어플리케이션들이 어떻게 잘못 되었는지를 이해함으로써 어플리케이션들을 올바르게 수행하는 방법을 배울 수 있습니다. Asynchronous JavaScript™ + XML (Ajax) 애플리케이션들을 작성하는 것에도 올바른 방식과 그릇된 방식이 있습니다.


    사람들이 처음부터 모든 것을 잘 했다면 이 세상은 완전히 달라졌을 것이다. Ajax도 마찬가지다. 필자는 Ajax 개발자를 위해서 코딩, 기고, 강연, 지원 등 많은 일들을 해왔다. 이러한 일련의 활동들을 통해서 Ajax를 올바르게 다루는 방법과 잘못 다루는 방법에 대해 배웠다. 지난 기술자료인, 다섯 개의 일반적인 Ajax 패턴: 유용한 Ajax 디자인 패턴들에서, Ajax 애플리케이션을 올바르게 작성하는 다섯 가지 패턴들을 제시했다. 이 글에서는 Ajax 코드에서 자주 볼 수 있는 다섯 가지 안티 패턴(anti-pattern)에 대해 설명하겠다.

    안티 패턴이란 무엇인가? 안티 패턴은 문제가 될 가능성이 짙은, 모든 사람들이 주의해야 할 애플리케이션 디자인의 결함이다. 이 글에서는 고급 주제에 대해 이야기 하겠다. 신택스 에러와 링커(linker) 문제는 언급하지 않겠다.

    대부분의 개발자들은 안티 패턴의 대표적인 예라 할 수 있는, 웹 사이트에서 "SQL Injection attack" 이라는 결과를 만들어 내는 Structured Query Language (SQL) 라이브러리의 오용에 대해 알고 있을 것이다. 이러한 안티 패턴은 기업의 매출에 타격을 가하고, 고객의 기록을 노출 하기도 하며, 모든 프로그래밍 언어에서 발생할 수 있다. 따라서, 왜 이러한 일이 발생하는지, 어떻게 발생하는지, 이러한 문제를 어떻게 피하는지를 이해하는 것이 중요하다.

    이 글에서는 Ajax 안티 패턴에 대해 살펴볼 것이다. 필자는 지금 기업에 수십억 달러 정도의 매출의 손실이 있다는 것을 이야기하려는 것은 아니다. 이러한 안티 패턴들이 서버를 충돌시키거나 형편없는 사용자 경험을 제공하고, 이 두 가지 모두 실망스럽고 비용이 많이 들 수 있다는 것을 이야기 하려는 것이다.

    무엇인가 잘못 될 수 있다는 것을 이해한다면 많은 것을 배울 수 있다. 가끔 사람들은 Ajax을 페이지가 로딩된 후에 서버에서 XML을 보내는 유일한 방법으로 생각하고 있다. 이것은 매우 제한된 시각이며, 이것이 잘못 적용된다면 애플리케이션에 성능 문제를 일으킬 수 있다. 이 글에서, 왜 이것이 잘못 되었으며 이를 수정하는 방법을 설명하겠다.

    굳이 그럴 필요가 없는데도 타이머에 폴링(poll)하기

    필자가 생각하기에 많은 Ajax 문제들은 JavaScript 언어에 있는 타이머 기능의 오용과 관련이 있다. 핵심 메소드는 window.setInterval()이다. 이 메소드를 볼 때마다 여러분의 마음속에 작은 경각심이 생긴다. 왜 이 사람은 타이머를 사용하고 있을까? 틀림없이, 타이머에는 예를 들어 애니메이션과 같은 타이머의 본래 목적이 있을 것이다.

    window.setInterval() 메소드는 특정 간격(매 초(second))마다 특정 함수를 콜백(call back)하도록 페이지에 명령한다. JavaScript 언어가 단일 쓰레드이기 때문에, 대부분의 브라우저들은 이러한 타이머를 거의 실행하지 않는다. 여러분이 1초를 요청하면 1초 또는 1.2초 또는 9초 또는 다른 시간으로 콜백을 얻게 된다.

    타이머가 확실히 필요하지 않는 한 부분은 완료 할 Ajax 요청을 찾는 부분이다. Listing 1의 예를 보자.


    Listing 1. Antipat1a_polling.html
                    
<html><script>
var req = null;

function loadUrl( url ) {
  if(window.XMLHttpRequest) {
    try { req = new XMLHttpRequest();
    } catch(e) { req = false; }
  } else if(window.ActiveXObject) {
    try { req = new ActiveXObject('Msxml2.XMLHTTP');
    } catch(e) {
    try { req = new ActiveXObject('Microsoft.XMLHTTP');
    } catch(e) { req = false; }
  } }
  if(req) {
    req.open('GET', url, true);
    req.send('');
  }
}

window.setInterval( function watchReq() {
    if ( req != null && req.readyState == 4 && req.status == 200 ) {
      var dobj = document.getElementById( 'htmlDiv' );
      dobj.innerHTML = req.responseText;
      req = null;
   }
 }, 1000 );

var url = window.location.toString();
url = url.replace( /antipat1a_polling.html/, 'antipat1_content.html' );
loadUrl( url );
</script><body>
Dynamic content is shown between here:<br/>
<div id="htmlDiv" style="border:1px solid black;padding:10px;">
</div>And here.</body></html>

    실제 환경에서는 어떻게 보이는지 알고 싶다면 새 창에서 antipat1a_polling.html 보기 링크 antipat1a_polling.html의 온라인 버전을 참조하라.

    setInterval 호출에 도달할 때까지 모든 것이 좋아 보인다. 이 호출은 요청의 상태를 관찰 할 타이머를 설정하고 다운로드 된 자료에서 페이지의 내용을 설정한다.

    요청이 짧게 완료될 때를 규명할 수 있는 문제에 대한 솔루션을 설명하겠다. Listing 2는 이 페이지가 요청하는 파일을 보여주고 있다.


    Listing 2. Antipat1_content.html
                    
<b>Hello there</b>

    실제 환경에서는 어떻게 보이는지 알고 싶다면 새 창에서 antipat1_content.html 보기 링크 antipat1_content.html의 온라인 버전을 참조하라.

    그림 1은 필자의 브라우저에 나타나는 페이지 모습이다.


    그림 1. HTML 문서
    HTML 문서

    "그런데 이것은 잘 작동하지 않습니까? 깨짐 현상도 없는데 픽스가 왜 필요한가요?"라고 물을 수도 있겠다. 실제로 이것은 깨졌다. 매우 느리기 때문이다. 타이머 설정을 1초 간격으로 하면 요청은 잘 진행된다. 따라서 먼저, 비어있는 박스와 함께 페이지가 나타나고, 1초를 기다리면 내용이 나타난다.

    솔루션은 무엇인가? Ajax는 본질적으로 비동기식(asynchronous)이다. 요청이 언제 끝났는지를 보기 위해 폴링 루프가 필요하지 않을까?

    그렇게 필요한 것은 아니다. Listing 3에서 보듯, 모든 XMLHTTPRequest 객체가 제공하는 것은 onreadystatechange라고 하는 콜백 메커니즘이다. (얼마나 아름다운 이름인가, VAX PDP/11s를 연상시키는 이름이다.)


    Listing 3. Antipat1a_fixed.html
                    
<html><script>
var req = null;
function processReqChange() {
  if (req.readyState == 4 && req.status == 200 ) {
    var dobj = document.getElementById( 'htmlDiv' );
    dobj.innerHTML = req.responseText;
  }
}

function loadUrl( url ) {
  ...
  if(req) {
    req.onreadystatechange = processReqChange;
    req.open('GET', url, true);
    req.send('');
  }
}

var url = window.location.toString();
url = url.replace( /antipat1a_fixed.html/, 'antipat1_content.html' );
loadUrl( url );
</script>
...

    실제 환경에서는 어떻게 보이는지 알고 싶다면 새 창에서 antipat1a_fixed.html 보기 링크 antipat1a_fixed.html의 온라인 버전을 참조하라.

    이 새로운 코드는 onreadystatechange 콜백에 대한 응답으로 요청 객체가 변했는지의 여부를 본다. 그런 다음, 이것이 완료되면 페이지를 업데이트 한다.

    결과는 매우 빨라진 페이지 로드이다. 페이지가 나타나면, 거의 동시에 새로운 콘텐트로 박스가 채워진다. 왜? 요청이 완료되자마자, 이 코드가 호출되고 필자는 페이지를 채우기 때문이다. 바보 같은 타이머 때문에 혼란스러워 할 필요가 없다.

    또 다른 폴링 안티 패턴은 한 페이지가 요청을 서버로 반복해서 바운스(bounce) 할 때이다. 심지어 요청이 변경되지 않았음에도 그렇게 하는 경우이다. Listing 4의 검색 페이지 예제를 보자.


    Listing 4. Antipat1b_polling.html
                    
<html><script>
var req = null;
function processReqChange() {
  if (req.readyState == 4 && req.status == 200 ) {
    var dobj = document.getElementById( 'htmlDiv' );
    dobj.innerHTML = req.responseText;
  }
}

function loadUrl( url ) {
  ...
}

window.setInterval( function watchSearch() {
  var url = window.location.toString();
  var searchUrl = 'antipat1_content.html?s='+searchText.value;
  url = url.replace( /antipat1b_polling.html/, searchUrl );
  loadUrl( url );
 }, 1000 );

</script><body><form>
Search <input id="searchText" type="text">:<br/>
<div id="htmlDiv" style="border:1px solid black;padding:10px;">
</div></form></body></html>

    실제 환경에서는 어떻게 보이는지 알고 싶다면 새 창에서 antipat1b_polling.html 열기 링크 antipat1b_polling.html의 온라인 버전을 참조하라.

    그림 2에서는 필자의 브라우저에서 이 페이지가 실행되는 모습이다.


    그림 2. 동적인 응답 영역을 가진 검색 영역
    동적인 응답 영역을 가진 검색 영역

    얼마나 아름다운가? 이 페이지는 이치에 맞는다. 필자가 검색 텍스트를 바꾸면, 결과 영역은 새로운 기준에 근거하여 바뀐다. (실제로는 그렇지 않지만 막후에 실제 검색 엔진이 있었다면 그렇게 했을 것이다.)

    문제는 JavaScript 코드가 window.setInterval을 사용하여 계속해서 요청을 만든다는 것이다. 심지어 검색 필드의 콘텐트가 바뀌지 않았음에도 말이다. 이는 네트워크 대역폭을 잠식하고 서버 시간을 잠식한다. 대중적인 사이트의 경우 이것은 치명적이다.

    솔루션은 검색 박스에 이벤트 콜백을 사용하는 것이다. (Listing 5)


    Listing 5. Antipat1b_fixed.html
                    
<html><script>
var req = null;
function processReqChange() { ... }
function loadUrl( url ) { ...  }

var seachTimer = null;
function runSearch()
{
  if ( seachTimer != null )
    window.clearTimeout( seachTimer );
  seachTimer = window.setTimeout( function watchSearch() {
    var url = window.location.toString();
    var searchUrl = 'antipat1_content.html?s='+searchText.value;
    url = url.replace( /antipat1b_fixed.html/, searchUrl );
    loadUrl( url );
    seachTimer = null;
   }, 1000 );
}
</script><body><form>
Search <input id="searchText" type="text" onkeyup="runSearch()">:<br/>
<div id="htmlDiv" style="border:1px solid black;padding:10px;">
</div></form></body></html>

    실제 환경에서는 어떻게 보이는지 알고 싶다면 새 창에서 antipat1b_fixed.html 열기 링크 antipat1b_fixed.html의 온라인 버전을 참조하라.

    여기에서 필자는 runSearch() 함수를 검색 박스의 onkeyup() 메소드로 연결했다. 이러한 박식으로 사용자가 검색 박스에 무엇인가 입력하면 콜백을 받도록 한다.

    runSearch()가 수행하는 것은 매우 똑똑하다. 1초 간의 단일 타임아웃을 설정하고 이 시간안에 서버를 호출하고 검색을 실행하도록 한다. 그리고 이것을 설정하기 전에 시간이 경과되지 않았다면 그 타임아웃을 삭제한다. 왜? 이것은 사용자가 많은 텍스트를 입력하도록 허용하기 때문이다. 그런 다음, 사용자가 마지막 키를 누른 후 1초 만에 검색이 실행된다. 이러한 방식으로 사용자는 계속적으로 깜박거리는 디스플레이 때문에 신경 쓰지 않아도 된다.






    콜백에서 리턴 결과 검사하지 않기

    많은 Ajax 안티 패턴은 XMLHTTPRequest 객체의 메커니즘에 대한 오해에서 기인한다. 필자가 종종 목격하게 되는 것 중 하나는 사용자가 콜백에서 객체의 readyState 또는 status 필드를 검사하지 않을 때이다. Listing 6을 보자.


    Listing 6. Antipat2_nocheck.html
                    
<html><script>
var req = null;
function processReqChange() {
  var dobj = document.getElementById( 'htmlDiv' );
  dobj.innerHTML = req.responseText;
}
...

    실제 환경에서는 어떻게 보이는지 알고 싶다면 새 창에서 antipat2_nocheck.html 열기 링크 antipat2_nocheck.html의 온라인 버전을 참조하라.

    모든 것이 멀쩡한 것처럼 보인다. 작은 요청이지만, 일부 브라우저에서는 이것으로 족하다. 하지만, 대부분의 요청들은 onreadystatechange 핸들러로 여러 호출을 요청해야 할 정도로 크다. 따라서 여러분의 콜백은 불완전한 데이터로 작동하게 된다.

    이를 수행하는 올바른 방법은 Listing 7에 나타나 있다.


    Listing 7. Antipat2_fixed.html
                    
<html><script>
var req = null;
function processReqChange() {
  if (req.readyState == 4 && req.status == 200 ) {
    var dobj = document.getElementById( 'htmlDiv' );
    dobj.innerHTML = req.responseText;
  }
}
...

    실제 환경에서는 어떻게 보이는지 알고 싶다면 새 창에서 antipat2_fixed.html 열기 링크 antipat2_fixed.html의 온라인 버전을 참조하라.

    더 많은 코드가 생긴 것은 아니지만 모든 브라우저에서 작동한다.

    Windows® Internet Explorer® 7에서 이러한 문제가 다른 브라우저에서 보다 중요하다는 것을 깨달았다. Internet Explorer 7은 onreadystatechange로 많은 콜백을 한다. 심지어는 작은 요청에도 정말 많다. 따라서, 핸들러를 올바르게 작성하는 것이 중요하다.






    HTML이 더 나은 선택임에도 불구하고 복잡한 XML 실행하기

    필자가 일했던 한 회사에서, "intelligence at the edge of the network"라는 말을 자주 사용했다. 서버에서 모든 일을 수행하는 대신 데스크탑에서 브라우저 기능을 사용하라는 의미이다.

    하지만, 페이지에 많은 정보를 넣으면 그곳에는 많은 JavaScript 코드가 놓이게 된다. 이것은 큰 단점이 된다. 바로 브라우저 호환성이다. 실제로 모든 대중적인 브라우저에서 JavaScript 코드의 모든 중요한 라인을 테스트 해야 한다. 적어도 고객이 사용할 것 같은 브라우저에서도 그렇게 해야 한다. 그래야 의미가 통한다. 복잡한 Ajax 예를 보자. (Listing 8)


    Listing 8. Antipat3_complex.html
                    
<html><head><script>
var req = null;
function processReqChange() {
  if (req.readyState == 4 && req.status == 200 && req.responseXML ) {
    var dtable = document.getElementById( 'dataBody' );
    var nl = req.responseXML.getElementsByTagName( 'movie' );
    for( var i = 0; i < nl.length; i++ ) {
      var nli = nl.item( i );
      var elYear = nli.getElementsByTagName( 'year' );
      var year = elYear.item(0).firstChild.nodeValue;
      var elTitle = nli.getElementsByTagName( 'title' );
      var title = elTitle.item(0).firstChild.nodeValue;

      var elTr = dtable.insertRow( -1 );

      var elYearTd = elTr.insertCell( -1 );
      elYearTd.innerHTML = year;

      var elTitleTd = elTr.insertCell( -1 );
      elTitleTd.innerHTML = title;
} } }

function loadXMLDoc( url ) {
  if(window.XMLHttpRequest) {
    try { req = new XMLHttpRequest();
    } catch(e) { req = false; }
  } else if(window.ActiveXObject) {
    try { req = new ActiveXObject('Msxml2.XMLHTTP');
    } catch(e) {
    try { req = new ActiveXObject('Microsoft.XMLHTTP');
    } catch(e) { req = false; }
  } }
  if(req) {
    req.onreadystatechange = processReqChange;
    req.open('GET', url, true);
    req.send('');
  }
}

var url = window.location.toString();
url = url.replace( /antipat3_complex.html/, 'antipat3_data.xml' );
loadXMLDoc( url );
</script></head><body>
<table cellspacing="0" cellpadding="3" width="100%"><tbody id="dataBody">
<tr>
  <th width="20%">Year</th>
  <th width="80%">Title</th>
</tr>
</tbody></table></body></html>

    실제 환경에서는 어떻게 보이는지 알고 싶다면 새 창에서 antipat3_complex.html 열기 링크 antipat3_complex.html의 온라인 버전을 참조하라.

    이 코드는 Listing 9에 나타난 XML에서 데이터를 읽고 이를 테이블로 포맷팅 한다.


    Listing 9. Antipat3_data.xml
                    
<movies>
  <movie>
    <year>1993</year>
    <title>Jurassic Park</title>
  </movie>
  <movie>
    <year>1997</year>
    <title>The Lost World: Jurassic Park</title>
  </movie>
  <movie>
    <year>2001</year>
    <title>Jurassic Park III</title>
  </movie>
</movies>

    그림 3과 같은 결과를 보게 된다.


    그림 3. 복잡한 영화 리스팅 페이지
    복잡한 영화 리스팅 페이지

    이것은 절대로 나쁜 코드가 아니다. 실제로는 비교적 단순한 태스크를 수행하는 많은 코드일 뿐이다. 결과 페이지는 전혀 복잡하지 않다. 클라이언트 측에서는 정렬되거나 검색될 수 없다. 사실, XML과 HTML간 이러한 복잡한 변환을 할 이유가 전혀 없다.

    서버가 XML 대신 HTML을 리턴 하도록 하는 것이 더 간단하지 않을까? (Listing 10)


    Listing 10. Antipat3_fixed.html
                    
<html><script>
var req = null;
function processReqChange() {
  if (req.readyState == 4 && req.status == 200 ) {
    var dobj = document.getElementById( 'tableDiv' );
    dobj.innerHTML = req.responseText;
  }
}

function loadUrl( url ) { ... }

var url = window.location.toString();
url = url.replace( /antipat3_fixed.html/, 'antipat3_content.html' );
loadUrl( url );
</script><body><div id="tableDiv"></div></body></html>

    실제 환경에서는 어떻게 보이는지 알고 싶다면 새 창에서 antipat3_fixed.html 열기 링크 antipat3_fixed.html의 온라인 버전을 참조하라.

    정말로 더 간단해졌다. 모든 복잡한 테이블 행과 셀 생성 코드는 <div> 태그의 innerHTML로 대체된다. à!

    서버에서 리턴된 HTML은 Listing 11을 참조하라.


    Listing 11. Antipat3_content.html
                    
<table cellspacing="0" cellpadding="3" width="100%">
<tbody id="dataBody">
<tr>
  <th width="20%">Year</th>
  <th width="80%">Title</th>
</tr>
<tr>
  <td>1993</td>
  <td>Jurassic Park</td>
</tr>
<tr>
  <td>1997</td>
  <td>The Lost World: Jurassic Park</td>
</tr>
<tr>
  <td>2001</td>
  <td>Jurassic Park III</td>
</tr>
</tbody>
</table>

    실제 환경에서는 어떻게 보이는지 알고 싶다면 새 창에서 antipat3_content.html 열기 링크 antipat3_content.html의 온라인 버전을 참조하라.

    모든 것이 그렇듯, 서버와 클라이언트 중 어디에서 처리할 것인지를 선택하는 것은 작업의 특성에 달려있다. 이 경우, 작업은 비교적 단순했다. 영화 테이블을 채우는 것이다. 작업이 더 복잡했다면, 다시 말해서, 정렬, 검색, 추가 또는 삭제, 영화를 클릭하면 더 많은 정보로 가게 되는 동적 인터랙션 같은 기능이 있다면 클라이언트에 보다 복잡한 코드가 실행되는 것을 볼 수 있다. 사실, 이 글 후반에 가서는 클라이언트에서의 정렬(sorting)을 설명할 것이다. 여기에서 서버에 너무 많은 부하를 주는 요소에 대해서 이야기 할 것이다.

    이것에 대한 가장 완벽한 예제는 아마도 Google Maps일 것이다. Google Maps는 서버 측에서 리치 클라이언트 측 코드와 지능형 매핑 엔진을 혼합하는 고급스러운 작업을 수행한다. 필자는 이 서비스를 거기에서 어떤 프로세싱을 수행할 것인지를 결정하는 방법 예제로서 사용해 보겠다.






    JavaScript 코드를 전달해야 할 때 XML 전달하기

    웹 브라우저가 XML 데이터 소스를 읽고 이를 동적으로 실행한다는 모든 가설을 기반으로, 여러분은 이것이 사용할 수 있는 유일한 메소드라고 생각할 것이다. 하지만, 여러분의 생각은 틀리다. 매우 똑똑한 엔지니어들은 Ajax 전송 기술을 사용하여 XML 대신 JavaScript 코드를 보내기 때문이다. Listing 12에서 영화 테이블 예제를 보도록 하자.


    Listing 12. Antipat4_fixed.html
                    
<html><head><script>
var req = null;
function processReqChange() {
  if (req.readyState == 4 && req.status == 200 ) {
    var dtable = document.getElementById( 'dataBody' );
    var movies = eval( req.responseText );
    for( var i = 0; i < movies.length; i++ ) {
      var elTr = dtable.insertRow( -1 );
      var elYearTd = elTr.insertCell( -1 );
      elYearTd.innerHTML = movies[i].year;
      var elTitleTd = elTr.insertCell( -1 );
      elTitleTd.innerHTML = movies[i].name;
} } }

function loadXMLDoc( url ) { ... }

var url = window.location.toString();
url = url.replace( /antipat4_fixed.html/, 'antipat4_data.js' );
loadXMLDoc( url );
</script></head><body>
<table cellspacing="0" cellpadding="3" width="100%">
<tbody id="dataBody"><tr>
  <th width="20%">Year</th>
  <th width="80%">Title</th>
</tr></tbody></table></body></html>

    실제 환경에서는 어떻게 보이는지 알고 싶다면 새 창에서 antipat4_fixed.html 열기 링크 antipat4_fixed.html의 온라인 버전을 참조하라.

    서버에서 XML을 읽는 대신, JavaScript 코드를 읽는다. 이 코드는 JavaScript 코드에 있는 eval() 함수를 사용하여 데이터를 얻는데, 이는 테이블 구현에 사용할 수 있다.

    JavaScript 데이터는 Listing 13에 나타나 있다.


    Listing 13. Antipat4_data.js
                    
[ { year: 1993, name: 'Jurassic Park' },
  { year: 1997, name: 'The Lost World: Jurassic Park' },
  { year: 2001, name: 'Jurassic Park III' } ]

    이러한 기능은 JavaScript 언어로 서버와 통신하도록 해야 한다. 하지만, 그렇게 큰 일은 아니다. 대부분의 대중적인 웹 언어들은 이미 JavaScript Object Notation (JSON) 아웃풋을 지원한다.

    효과는 명확하다. 이 예제에서 JavaScript 언어를 사용함으로써 클라이언트로 다운로드 된 데이터의 크기가 52%나 줄었다. 성능 역시 증가했다. JavaScript 버전을 읽는 것도 9%나 빨라졌다. 9%는 그렇게 큰 비율은 아니지만, 이 예제는 매우 기본적인 예제라는 것을 기억하라. 더 큰 데이터 블록이나 더 복잡한 구조는 더 많은 XML 파싱 코드를 요구할 것이지만, JavaScript 코드는 바뀌지 않는다.






    서버에서 너무 많은 일을 수행하기

    서버에서 적은 일을 수행해야 할 카운터 인자가 서버에서 너무 많은 일을 수행한다. 앞서 언급했지만, 이것은 균형을 맞추기 위한 작동이다. 하지만, 서버에서 작업을 분산하는 방법에 대한 설명으로서 클라이언트에서 영화 테이블을 정렬하는 방법을 설명하겠다.

    Listing 14에는 정렬 가능한 영화 테이블이 나타나 있다.


    Listing 14. Antipat5_sort.html
                    
<html><head><script>
var req = null;
var movies = null;
function processReqChange() {
  if (req.readyState == 4 && req.status == 200 ) {
    movies = eval( req.responseText );
    runSort( 'year' );
} }

function runSort( key )
{
  if ( key == 'name' )
    movies.sort( function( a, b ) {
      if ( a.name < b.name ) return -1;
      if ( a.name > b.name ) return 1;
      return 0;
    } );
  else
    movies.sort( function( a, b ) {
      if ( a.year < b.year ) return -1;
      if ( a.year > b.year ) return 1;
      return 0;
    } );
  var dtable = document.getElementById( 'dataBody' );
  while( dtable.rows.length > 1 ) dtable.deleteRow( 1 );
  for( var i = 0; i < movies.length; i++ ) {
    var elTr = dtable.insertRow( -1 );
    var elYearTd = elTr.insertCell( -1 );
    elYearTd.innerHTML = movies[i].year;
    var elTitleTd = elTr.insertCell( -1 );
    elTitleTd.innerHTML = movies[i].name;
  }
}

function loadXMLDoc( url ) { ... }

var url = window.location.toString();
url = url.replace( /antipat5_sort.html/, 'antipat4_data.js' );
loadXMLDoc( url );
</script></head><body>
<table cellspacing="0" cellpadding="3" width="100%">
<tbody id="dataBody"><tr>
  <th width="20%"><a href="javascript: void runSort('year')">Year</a></th>
  <th width="80%"><a href="javascript: void runSort('name')">Title</a></th>
</tr></tbody></table></body></html>

    실제 환경에서는 어떻게 보이는지 알고 싶다면 새 창에서 antipat5_sort.html 열기 링크 antipat5_sort.html의 온라인 버전을 참조하라.

    이것은 매우 간단한 예제이다. 이 페이지에 나타날 것 같은 특별히 긴 영화 리스트에는 작동하지 않는다. 하지만, 페이지 리프레시 없이도, 서버가 많은 일을 수행하지 않아도 빠르게 정렬하는 테이블을 만들 수 있다.






    결론

    필자는 Ajax에 대한 많은 글을 써왔고 많은 Ajax를 수행했다. 필자는 Ajax forum on IBM developerWorks의 Ajax 포럼을 운영한다. 따라서 Ajax에 대한 한 두 가지의 일쯤은 알고 있고 이것이 어떻게 사용되고 어떻게 오용되는지도 알고 있다. 필자가 자주 목격하게 되는 것 중 하나는 개발자들이 Ajax의 복잡성을 오해하고 있다는 것이다. 개발자들은 Ajax가 XML, JavaScript, HTML 코드를 브라우저로 보내는 것 정도로 생각하고 있다. 필자는 Ajax 플랫폼을 완전한 브라우저로 보고 있다. 사실, 대중적인 브라우저들의 전체라고 볼 수 있다.

    결론은 다음과 같이 내릴 수 있겠다. Ajax에 대해 배워야 할 것은 많이 있고 이와 관련한 실수들도 많이 한다. 바라건데, 이 글이 빠지기 쉬운 함정을 피하는데 지침이 되었기 바란다. 성공을 통해 많은 것을 배울 수도 있지만 실수를 통해서도 많은 것을 배우기 마련이다.

    기사의 원문보기


    필자소개

    Jack D. Herrington은 20년 경력을 지닌 소프트웨어 엔지니어이다. Code Generation in Action, Podcasting Hacks, PHP Hacks 의 저자이다. 30개 이상의 기술자료를 기고했다. (jherr@pobox.com)

    이 글의 관련글
  • Ajax와 Java EE의 통합
  • AJAX와 XML: 다섯 개의 일반적인 Ajax 패턴
  • 옵저버 패턴 :: Observer Pattern
  • Javascript Framework Prototype
  • Struts 2.1 + ajax 플러그인 : dojo툴킷 이용 방법 변경
  • 싱글턴 패턴 :: Singleton Pattern
  • RIA (Rich Internet Application ) 패턴
    • 2007/05/17 23:11 2007/05/17 23:11
    Trackback Address:http://www.yunsobi.com/blog/trackback/77
    [로그인][오픈아이디란?]

    AJAX와 XML: 다섯 개의 일반적인 Ajax 패턴

    2007/05/17 23:10
    Leave a Comment

    서비 Tip&Tech , ,

    원문출처 : http://www.ibm.com/developerworks/kr/library/x-ajaxxml2/(새 창으로 열기)

    유용한 Ajax 디자인 패턴들

    난이도 : 중급

    Jack D Herrington, Senior Software Engineer, Leverage Software Inc.

    2007 년 4 월 10 일

    Asynchronous JavaScript + XML (Ajax)은 단연 2006년의 화두였고, 2007년에도 이러한 기조를 이어갈 전망입니다. 하지만 이것이 여러분의 애플리케이션에는 어떤 영향을 미칠까요? Ajax 애플리케이션에 사용되는 일반적인 아키텍처 패턴에는 무엇이 있을까요? 이 글에서는 다섯 가지 Ajax 디자인 패턴을 소개합니다.

    확실히, Ajax는 모든 사람들이 자신들의 사이트에 채택하고 싶어하는 Web 2.0 용어이다. 하지만, 이것이 진정으로 의미하는 것은 무엇일까? 엔지니어들은 아키텍처 레벨에서 이것을 자신들의 사이트에 어떻게 통합할까? 이 글에서, Ajax의 기초를 설명하고, Ajax 개발에서 베스트 프랙티스로 입증된 몇 가지 Ajax 디자인 패턴을 소개하겠다.

    Ajax는 Dynamic HTML (DHTML)과 XMLHTTPRequest 객체를 포함한 일련의 기술들을 포괄하는 기술이다. DHTML은 세 가지 엘리먼트들, Hypertext Markup Language (HTML), JavaScript 코드, Cascading Style Sheets (CSS)의 결합이다. 웹 페이지에서 JavaScript 코드를 사용하면서, 콘텐트를 추가, 제거, 수정하기 위해 페이지를 동적으로 수정할 수 있다. 바로 이것이 DHTML의 동적인 요소이다. JavaScript 코드는 XMLHTTPRequest 객체를 사용하여 페이지가 로딩된 후에 서버에서 데이터를 요청한다.

    서버에서 데이터를 요청하는 것과, 그 데이터를 사용하기 위해 페이지를 수정하는 것, 이 두 가지 요소들의 결합이 Ajax의 정수이자 Web 2.0 사이트의 동적인 본성이다.

    하지만, 이러한 기능들이 실제 세계에서 어떻게 사용되고, 사이트에서 이들을 어떻게 사용하는지에 대해서는 정확히 알 수 있다. 따라서 간단한 디자인 패턴(design patterns.)이 필요하다. 이 용어가 생소하다면, 같은 이름의 책을 참조하기 바란다. (참고자료) 이 책에서는 엔지니어들이 접하는 공통의 태스크에 대한 구현 패턴을 설명하고 있다. 이 책에서는 시스템을 디자인하는 방법에 대한 베스트 프랙티스 뿐만 아니라, 엔지니어들이 사용할 수 있는 용어도 설명한다.

    이 글에서는 다섯 가지 일반적인 Ajax 디자인 패턴을 소개한다. HTML, XML, JavaScript 코드를 사용하여 서버에서 데이터를 얻는 방법이 다양하다. 서버에서 새로운 HTML로 페이지를 업데이트 하는 가장 단순한 패턴부터 시작하겠다.

    Pattern 1. HTML 세그먼트 대체하기

    아마도 가장 일반적인 Ajax 태스크는 서버에서 업데이트 된 HTML을 요청하여, 이것을 사용하여 페이지의 한 부분을 업데이트 하는 것이다. 예를 들어, 주식 시세를 업데이트 하기 위해 이를 주기적으로 수행할 수 있다. 또는, 검색 요청에 대한 응답으로, 온 디맨드(on demand) 방식으로 업데이트 할 수 있다.

    Listing 1의 코드는 서버에서 페이지를 요청한 다음 콘텐트를 페이지의 바디에 있는 <div> 태그에 배치하는 부분이다.


    Listing 1. Pat1_replace_div.html
    				
<html>
<script>
var req = null;
function processReqChange() {
  if (req.readyState == 4 && req.status == 200 ) {
    var dobj = document.getElementById( 'htmlDiv' );
    dobj.innerHTML = req.responseText;
  }
}

function loadUrl( url ) {
  if(window.XMLHttpRequest) {
    try { req = new XMLHttpRequest();
    } catch(e) { req = false; }
  } else if(window.ActiveXObject) {
    try { req = new ActiveXObject('Msxml2.XMLHTTP');
    } catch(e) {
    try { req = new ActiveXObject('Microsoft.XMLHTTP');
    } catch(e) { req = false; }
  } }
  if(req) {
    req.onreadystatechange = processReqChange;
    req.open('GET', url, true);
    req.send('');
  }
}

var url = window.location.toString();
url = url.replace( /pat1_replace_div.html/, 'pat1_content.html' );
loadUrl( url );
</script>
<body>
Dynamic content is shown between here:<br/>
<div id="htmlDiv" style="border:1px solid black;padding:10px;">
</div>
And here.<br/>
</body>
</html>

    Listing 2는 코드가 요청하고 있는 콘텐트이다.


    Listing 2. Pat1_content.html
    				
HTML encoded content goes here.

    실제 환경에서는 어떻게 보이는지 알고 싶다면 pat1_replace_div.html의 온라인 버전을 참조하라.pat1_replace_div.html 새 창으로 보기 링크

    이 페이지를 Firefox에 로딩할 때, 그림 1과 같은 결과를 볼 수 있다.


    그림 1. <div> 태그가 있는 페이지
    태그 페이지

    Listing 1의 코드로 가서 몇 가지를 살펴보자. 첫 번째로 알아야 할 것은 loadUrl() 함수인데, 이것은 서버에서 URL을 요청한다. 이 함수는 XMLHTTPRequest 객체를 사용하여 서버에 새로운 콘텐트를 요청한다. 또한, 브라우저가 콘텐트를 받을 때 호출되는 콜백 함수(이 경우, processReqChange)도 지정한다.

    processReqChange 함수는 객체를 검사하여 요청이 완료되었는지 여부를 확인한다. 완료되었다면, 이 함수는 페이지의 <div> 태그의 innerHTML을 응답 텍스트에 설치한다.

    동적 콘텐트용 플레이스홀더로서 <div> 태그를 사용하는 것은 Ajax 코드의 주요한 특징이다. 이 태그는 (여러분이 보더 같은 것을 추가하지 않는 한) 눈에 띠는 특징은 없지만 콘텐트가 어디로 가야 할 지를 알려주는 좋은 마커로서 작동한다. 엔지니어들은 대체 가능한 세그먼트에 <span> 태그를 사용한다. 나중에 설명하겠다. <div>와 <span> 태그의 차이점은 전자가 라인 브레이크(패러그래프)를 사용하는 반면, 후자는 인라인 텍스트의 섹션을 정확하게 구분한다는 점이다.

    잠시, processReqChange 함수로 가서, 함수가 status와 readyState 값을 체크하는 것이 중요하다. 일부 브라우저는 요청이 완료될 때에만 함수를 호출하지만, 다른 브라우저는 요청이 실행 중이라는 것을 나타내면서 지속적으로 콜백한다.

    Tab 디스플레이 변수

    이 패턴의 또 다른 변종은 Tab 스타일의 디스플레이를 생성하는 것이다. Listing 3은 Tab Ajax 인터페이스이다.


    Listing 3. Pat1_tabs.html
    				
<html>
<script>
var req = null;
function processReqChange() {
  if (req.readyState == 4 && req.status == 200 ) {
    var dobj = document.getElementById( 'tabDiv' );
    dobj.innerHTML = req.responseText;
  }
}

function loadUrl( tab ) {
  var url = window.location.toString();
  url = url.replace( /pat1_tabs.html/, tab );
  ...
}

function tab1() { loadUrl( 'pat1_tab1_content.html' ); }
function tab2() { loadUrl( 'pat1_tab2_content.html' ); }
tab1();
</script>
<body>
<a href="javascript: void tab1();">Tab 1<a> 
<a href="javascript: void tab2();">Tab 2<a>
<div id="tabDiv" style="border:1px solid black;padding:10px;">
</div>
</body>
</html>

    Listing 4는 첫 번째 탭의 콘텐트이다.


    Listing 4. Pat1_tab1_content.html
    				
Tab 1 content

    Listing 5는 두 번째 탭의 콘텐트이다.


    Listing 5. Pat1_tab2_content.html
    				
Tab 2 content

    실제 환경에서는 어떻게 보이는지 알고 싶다면 pat1_tabs.html의 온라인 버전을 참조하라.pat1_tabs.html 새 창으로 보기 링크

    이 페이지를 브라우저에 로딩하면, 그림 2와 같은 첫 번째 탭을 볼 수 있다.


    그림 2. 첫 번째 탭의 콘텐트
    첫 번째 탭의 콘텐트

    두 번째 탭 링크를 클릭한다. 브라우저는 두 번째 탭의 콘텐트를 가져와서, 이를 탭 영역에 보여준다. (그림 3)


    그림 3. 두 번째 탭의 콘텐트
    두번째 탭의 콘텐트

    사용자에게서 요청을 가져와서 새로운 내용으로 디스플레이의 일부를 업데이트 하는 것, 이 경우에는 Tab 디스플레이를 만드는 것이야 말로 이 디자인 패턴의 전형적인 사용법이다. 애플리케이션 측에서 얻을 수 있는 가치는 사용자에게 훨씬 가벼운 페이지를 제공할 수 있고, 사용자는 자신들이 원하는 자료들에 온 디맨드 방식으로 액세스 할 수 있다.

    Ajax 이전의 일반적인 기술은 페이지에 두 개의 탭을 두고, 온 디맨드 방식으로 이들을 숨기거나 보여주는 것이었다. 다시 말해서, 두 번째 탭용 HTML은 결코 보이지 않더라도 생성되었으며, 서버 시간과 대역폭의 낭비만 초래했다. 이제 새로운 Ajax 방식으로, 두 번째 탭용 HTML은 사용자가 요청할 때에만 생성된다.

    Read more 변형

    실제 환경에서는 어떻게 보이는지 알고 싶다면 의 온라인 버전을 참조하라. pat1_readmore.html pat1_readmore.html 새 창으로 보기 링크

    또 하나의 예로 Read more 링크를 들 수 있다. (그림 4)


    그림 4. 내 지루한 블로그 엔트리의 Read more 링크
    Read more 링크

    강아지 산책에 대해 더 읽고 싶다고 가정해 보자. Read more 링크를 클릭하고 그 링크를 전체 스토리로 대체할 수 있다. (그림 5)


    그림 5. Read more 링크를 클릭한 후의 페이지 모습
    Read more 클릭 후

    사용자들은 페이지 리프레시 없이도 더 많은 자료들을 볼 수 있다.

    Listing 6은 이 페이지에 대한 코드이다.


    Listing 6. Pat1_readmore.html
    				
<html>
<script>
var req = null;
function processReqChange() {
  if (req.readyState == 4 && req.status == 200 ) {
    var dobj = document.getElementById( "moreSpan" );
    dobj.innerHTML = req.responseText;
  }
}

function loadUrl( url ) { ... }

function getMore()
{
  var url = window.location.toString();
  url = url.replace( /pat1_readmore.html/, 'pat1_readmore_content.html' );
  loadUrl( url );
}
</script>
<body>
<h1>Walking the dog</h1>
I took my dog for a walk today. 
<span id="moreSpan">
<a href="javascript: void getMore()">Read more...</a>
</span>
</body>
</html>

    Listing 7은 "read more" 섹션에 대한 콘텐트이다.


    Listing 7. Pat1_readmore_content.html
    				
It was a nice day out. Warm and sunny. My dog liked getting out for a stretch.

    이 코드는 <div> 태그 대신 <span> 태그의 사용법을 보여준다. 사용 방법은 사용자 인터페이스(UI)의 요구 사항에 따라 다르다. 여러분도 보다시피 어떤 방법이든 사용하기 쉽다.

    이 페이지에 새로운 HTML을 만드는 것은 해결되었고, JavaScript가 데이터를 사용하여 보다 지능적인 작업을 수행하도록 하려면? 구조적인(structured) 방법으로 데이터를 브라우저에 어떻게 가져올 것인가? 당연히, XML이 필요하다.






    Pattern 2. XML 데이터 읽기

    몇 가지 이유로, Ajax는 XML의 동의어처럼 되어버렸다. XML은 절대로 그렇지 않은데 말이다. 위 예제에서 보듯, 텍스트 또는 HTML 조각 또는 Extensible HTML (XHTML) 코드를 리턴할 수 있다. 하지만 XML을 보내도 응답을 받을 수 있다.

    Listing 8은 서버에서 책에 대한 기록을 요청하고, 페이지 내의 테이블에 그 데이터를 디스플레이 하는 Ajax 코드이다.


    Listing 8. Pat2_xml.html
    				
<html>
<head>
<script>
var req = null;
function processReqChange() {
  if (req.readyState == 4 && req.status == 200 && req.responseXML ) {
    var dtable = document.getElementById( 'dataBody' );
    var nl = req.responseXML.getElementsByTagName( 'book' );
    for( var i = 0; i < nl.length; i++ ) {
      var nli = nl.item( i );
      var elAuthor = nli.getElementsByTagName( 'author' );
      var author = elAuthor.item(0).firstChild.nodeValue;
      var elTitle = nli.getElementsByTagName( 'title' );
      var title = elTitle.item(0).firstChild.nodeValue;

      var elTr = dtable.insertRow( -1 );

      var elAuthorTd = elTr.insertCell( -1 );
      elAuthorTd.innerHTML = author;

      var elTitleTd = elTr.insertCell( -1 );
      elTitleTd.innerHTML = title;
} } }

function loadXMLDoc( url ) {
  if(window.XMLHttpRequest) {
    try { req = new XMLHttpRequest();
    } catch(e) { req = false; }
  } else if(window.ActiveXObject) {
    try { req = new ActiveXObject('Msxml2.XMLHTTP');
    } catch(e) {
    try { req = new ActiveXObject('Microsoft.XMLHTTP');
    } catch(e) { req = false; }
  } }
  if(req) {
    req.onreadystatechange = processReqChange;
    req.open('GET', url, true);
    req.send('');
  }
}

var url = window.location.toString();
url = url.replace( /pat2_xml.html/, 'pat2_xml_data.xml' );
loadXMLDoc( url );
</script>
</head>
<body>
<table cellspacing="0" cellpadding="3" width="100%">
<tbody id="dataBody">
<tr>
  <th width="20%">Author</th>
  <th width="80%">Title</th>
</tr>
</tbody>
</table>
</body>
</html>

    Listing 9는 이 페이지의 데이터이다.


    Listing 9. Pat2_xml_data.xml
    				
<books>
  <book>
    <author>Jack Herrington</author>
    <title>Code Generation in Action</title>
  </book>
  <book>
    <author>Jack Herrington</author>
    <title>Podcasting Hacks</title>
  </book>
  <book>
    <author>Jack Herrington</author>
    <title>PHP Hacks</title>
  </book>
</books>

    실제 환경에서는 어떻게 보이는지 알고 싶다면 pat2_xml.html의 온라인 버전을 참조하라.pat2_xml.html 새 창으로 보기 링크

    이 페이지를 브라우저에 로딩하면, 그림 6과 같은 결과를 볼 수 있다.


    그림 6. XML 디스플레이 페이지
    XML 디스플레이 페이지

    이 페이지와 이전 패턴의 페이지와의 큰 차이는 processReqChange 함수에 있다. responseText를 보는 대신, 이제는 서버에서 온 응답이 XML로 올바르게 인코딩 될 경우에만 사용할 수 있는 XML Document Object Model (DOM)인 responseXML을 본다.

    responseXML을 사용하여, XML 문서에서 <book> 태그들의 리스트를 요청한다. 이들 각각에 대해 <title>과 <author> 엘리먼트를 받는다. 그런 다음, 각 책의 테이블에 행을 추가하고, 각 행에 셀을 추가하여 저자와 제목 데이터를 포함시킨다.

    이는 전형적인 XML 데이터의 사용법이다. 보다 고급의 JavaScript 코드는 리턴된 데이터에 기반하여 클라이언트 측 소팅(sorting) 또는 검색을 수행한다.

    안타깝게도, XML 데이터를 전송할 때의 단점은 브라우저가 XML 문서를 파싱하는데 시간이 걸린다는 점이다. 또한, XML에서 데이터를 찾는 JavaScript 코드는 복잡해 질 수 있다. (Listing 8) 대안은 서버에서 JavaScript 코드를 요청하는 것이다.


    Pattern 3. JavaScript 데이터 읽기

    서버에서 JavaScript 데이터를 요청하는 것은 JavaScript Object Notation (JSON)으로 통용되는 기술이다. JavaScript 데이터를 리턴하면 브라우저가 효율적으로 JavaScript 데이터 구조를 파싱하고 생성할 수 있고, 사용이 훨씬 쉬워진다.

    서버에서 XML 데이터를 읽는 Listing 8의 코드를 서버에서 JavaScript 데이터를 읽는 것으로 수정했다. 새로운 코드는 Listing 10과 같다.


    Listing 10. Pat3_js.html
    				
<html><head><script>
var req = null;
function processReqChange() {
  if (req.readyState == 4 && req.status == 200 ) {
    var dtable = document.getElementById( 'dataBody' );
    var books = eval( req.responseText );
    for( var b in books ) {
      var elTr = dtable.insertRow( -1 );

      var elAuthorTd = elTr.insertCell( -1 );
      elAuthorTd.innerHTML = books[b].author;

      var elTitleTd = elTr.insertCell( -1 );
      elTitleTd.innerHTML = books[b].title;
} } }

...

    모든 HTML 코드는 같다. processReqChange 함수는 JavaScript 데이터가 서버에서 리턴했던 eval을 읽기 위해 변경된다. 이 함수는 eval에서 나온 JavaScript 객체들을 데이터 소스로서 사용하고, 이것은 테이블에 추가된다.

    Listing 11은 서버에서 온 JavaScript 데이터이다.


    Listing 11. Pat3_js_data.js
    				
[ { author: 'Jack Herrington', title: 'Code Generation in Action' },
{ author: 'Jack Herrington', title: 'Podcasting Hacks' },
{ author: 'Jack Herrington', title: 'PHP Hacks' }
]

    실제 환경에서는 어떻게 보이는지 알고 싶다면 pat3_js.html의 온라인 버전을 참조하라. pat3_js.html 새 창으로 보기 링크

    왜 많은 Ajax 애플리케이션 엔지니어들이 데이터를 인코딩할 때 XML 대신 JavaScript를 선호하는지를 쉽게 알 수 있다. JavaScript 코드는 읽기와 관리하기가 더 쉽고 브라우저가 처리하기에도 더 쉽다.

    데이터 수집과 디스플레이도 중요하지만, Ajax의 핵심은 현재 데이터의 디스플레이이다. 여기에서는 현재(current.)가 중요하다. 여러분은 서버에서 늘 새로운 데이터를 가져오고 있다고 어떻게 확신할 수 있는가?


    Pattern 4. 브라우저 캐시 피하기

    브라우저는 웹 트래픽을 최적화하려고 하므로, 같은 URL을 두 번 요청하면, 페이지를 다시 요청하는 대신, 브라우저 캐시에 저장된 페이지를 사용하게 될 것이다. 따라서, Ajax 애플리케이션의 또 다른 패턴은 URL에서 무작위 엘리먼트를 사용하여 그 브라우저가 캐싱된 결과를 리턴하지 않도록 하는 것이다.

    내가 좋아하는 방법은 현재 시간의 숫자 값을 URL에 추가하는 것이다. Listing 12는 그 방법이다.


    Listing 12. Pat4_cache.html
    				
<html>
<script>
...

function loadUrl( url ) {
  url = url + "?t="+((new Date()).valueOf());
  ...
}

...

    실제 환경에서는 어떻게 보이는지 알고 싶다면 pat4_cache.html의 온라인 버전을 참조하라.pat4_cache.html 새 창으로 보기 링크

    이 것은 Listing 1에서 참조한 코드이지만, URL 스트링에서 JavaScript 텍스트가 추가되었다. 시간 값을 갖고 있는 t라고 하는 새로운 매개변수를 URL에 추가했다. 서버가 그 값을 인지하는지 여부는 상관 없다. 이것은 브라우저가 URL 기반 페이지 캐시를 무시하는지를 확인하는 방법일 뿐이다.


    Pattern 5. 여러 HTML 세그먼트 대체하기

    마지막 패턴은 첫 번째 패턴의 고급 버전이라고 볼 수 있다. <div> 태그를 서버에서 가져온 콘텐트로 대체하는 것이다. 웹 애플리케이션의 일반적인 문제는 사용자 인풋에 응답할 때, 여러 디스플레이 영역들이 업데이트되어야 한다는 점이다. 예를 들어, 주식 시세 애플리케이션에서, 디스플레이의 한 부분이 최신 시세를 보여주고, 또 다른 부분은 최신 가격 리스트를 보여준다.

    디스플레이의 여러 부분들을 업데이트 하기 위해, 두 섹션에 대한 데이터를 포함하고 있는 서버에서 XML 응답을 사용한다. 정규식을 사용하여 응답에서 개별 섹션들을 분리한다. Listing 13은 그 방법이다.


    Listing 13. Pat5_multi_segment.html
    				
<html>
<head>
<script>
var req = null;
function processReqChange() {
  if (req.readyState == 4 && req.status == 200 ) {
    var one = req.responseText.match( /\<one\>(.*?)\<\/one\>/ );
    document.getElementById( 'divOne' ).innerHTML = one[1];
    var two = req.responseText.match( /\<two\>(.*?)\<\/two\>/ );
    document.getElementById( 'divTwo' ).innerHTML = two[1];
} }

function loadXMLDoc( url ) { ... }

var url = window.location.toString();
url = url.replace( /pat5_multi_segment.html/, 'pat5_data.xml' );
loadXMLDoc( url );
</script>
</head>
<body>

This is the content for segment one:<br/>
<div id="divOne" style="border:1px solid black;padding:10px;">
</div>
And segment two:<br/>
<div id="divTwo" style="border:1px solid black;padding:10px;">
</div>

</body>
</html>

    Listing 14는 서버에서 가져온 데이터이다.


    Listing 14. Pat5_data.xml
    				
<segments>
  <one>Content for segment one</one>
  <two>Content for segment <b>two</b></two>
</segments>

    실제 환경에서는 어떻게 보이는지 알고 싶다면 pat5_multi_segment.html의 온라인 버전을 참조하라. pat5_multi_segment.html 새 창으로 보기 링크

    이 코드를 브라우저에 로딩하면 그림 7과 같은 결과를 볼 수 있다.


    그림 7. 서버에서 온 데이터로 업데이트 된 두 세그먼트
    두 세그먼트 디스플레이

    페이지 코드에서, 서버에서 리턴된 자료는 유효 XML이기 때문에 XML 응답을 사용할 수도 있었따. 하지만, XML 코드에서 개별 세그먼트를 크래킹 하는 대신 정규식을 사용하는 것이 더 쉬웠다.


    결론

    Ajax는 강력한 만큼, 오용 및 오해의 여지도 많이 있다. 이 글에서 내가 설명한 패턴들은 웹 애플리케이션에서 Ajax를 사용하는데 좋은 지침이 될 것이다. 이 글에서 제공한 코드를 사용하는 것 외에도, Ajax에서 파생된 Ajax와 Web UI 라이브러리도 사용해 보는 것도 좋다. 이중 가장 중요한 것은 Prototype.js 라이브러리로서, 서버에서 데이터를 쉽게 가져올 수 있으며, 크로스 브라우저 호환 방식을 사용하여 웹 페이지 콘텐트를 업데이트 한다. 이 라이브러리를 사용하면 전담 엔지니어들은 다양한 브라우저와 플랫폼에서 이들을 관리 및 테스트 할 수 있다.

    Ajax에는 여러분의 애플리케이션에 동적인 작동을 추가할 수 있는 분명 무엇인가가 있다.

    기사의 원문보기

    필자소개

    Jack D. Herrington은 20년 경력을 지닌 소프트웨어 엔지니어이다. Code Generation in Action, Podcasting Hacks, PHP Hacks 의 저자이다. 30개 이상의 기술자료를 기고했다. (jherr@pobox.com)

    이 글의 관련글
  • Struts 2.1 + ajax 플러그인 : dojo툴킷 이용 방법 변경
  • 싱글턴 패턴 :: Singleton Pattern
  • 옵저버 패턴 :: Observer Pattern
  • Ajax와 Java EE의 통합
  • RIA (Rich Internet Application ) 패턴
  • Javascript Framework Prototype
  • Ajax와 XML: 다섯 가지 Ajax 안티 패턴(anti-pattern)
    • 2007/05/17 23:10 2007/05/17 23:10
    Trackback Address:http://www.yunsobi.com/blog/trackback/76
    [로그인][오픈아이디란?]

    Ajax와 Java EE의 통합

    2007/04/24 17:33
    Leave a Comment

    서비 JAVA , ,

    원문 출처 : http://www.ibm.com/developerworks/kr/library/j-ajaxee/index.html(새 창으로 열기)

    비동기식 통신 모델과 동기식 통신 모델을 효과적으로 혼합하기

    IT 전문가 Patrick Gan이 Ajax 기술을 Java EE 웹 애플리케이션에 적용할 때 전체적인 개발 과정 속에서 발생할 수 있는 문제들을 점검합니다. 패턴에 기반하고 있는 Ajax의 비동기식 통신을 채택할 때의 문제들을 파악하는 것이 효과적인 Ajax 통합의 지름길입니다.

    Asynchronous JavaScript + XML (Ajax)은 매우 새로운 기술이다. Java EE 커뮤니티를 비롯한 많은 웹 개발 커뮤니티에서 이에 대한 많은 소문들이 만들어지고 있다. Ajax 기술은 과도한 웹 페이지 리프레쉬를 줄임으로서 애플리케이션 가용성을 향상시키고 있다. 그리고 Ajax의 best-of-both-worlds 접근 방식은 클라이언트 측 코드와 서버 측 코드를 활용하여 웹 사용자에게 거의 완벽한 UI를 제공하고자 한다. Ajax는 웹의 부활(Web 2.0)에 있어 핵심 인에이블러로서 간주되고 있다.

    부지런한 Java EE 개발자라면 아마도 Ajax에 대한 많은 하우투 문서를 섭렵하고 이것이 여러분의 애플리케이션에 가져올 향상에 대해서도 기대했을지 모른다. 하지만 어떻게 Ajax의 비동기식 통신 기반 패턴이 Java EE 애플리케이션에 맞을까? 이 글에서는 Java EE 애플리케이션의 디자인, 개발, 퍼포먼스, 테스팅에 Ajax를 채택했을 때 미치는 영향을 검토하여 해결책을 모색하고자 한다. 이렇게 하는 이유는 Ajax 사용을 금하려는 것이 아니라, 오히려 Ajax를 효과적으로 사용할 수 있도록 문제들을 해결하려는 것이다.

    디자인 문제점

    자바 커뮤니티는 좋은 디자인 패턴들을 웹 관련 애플리케이션 개발에 적용하려고 부단히도 애썼다. 가장 광범위하게 사용되는 패턴들 중 하나가 Model-View-Controller (MVC)이다. Apache Struts 같은 여러 오픈 소스 프레임웍들은 이러한 디자인 패턴/아키텍처에 기반하고 있다. (참고자료) MVC의 많은 장점들 중에는 관심의 분리(separation of concerns)와 과잉 코드의 감소를 들 수 있다.

    관심의 분리를 통해, 애플리케이션 아키텍처에서 사전에 협상된 인터페이스를 사용하면서 각 개발자는 애플리케이션 개발 프로젝트에서 지정된 역할에만 집중할 수 있다. 예를 들어, 모델-레이어 개발자들은 JDBC, Enterprise JavaBeans (EJB), 데이터 영속성 기술과 관련 있는 자바 클래스 같은 기술에 초점을 맞춘다. 뷰-레이어 개발자들은 JavaServer Pages (JSP), 태그 라이브러리, 기타 표현 관련 기술에 초점을 맞춘다. 컨트롤러 레이어는 모델과 뷰 사이를 구분 및 중재하고 인커밍 요청들을 백엔드 호출로 라우팅 하면서 관심들을 깨끗하게 분리한다. 그림 1은 MVC 아키텍처 모습이다.


    그림 1. MVC 아키텍처
    MVC architecture

    Ajax를 Java EE 웹 애플리케이션에 도입하는 것에는 관심의 분리라는 의미가 내포되어 있다. (따라서 개발자 역할도 분리된다.) 어떤 경우, Ajax는 많은 양의 JavaScript 코드를 뷰-레이어(JSP) 페이지에 도입한다. 표 1은 Ajax가 적용되지 않은 MVC 뷰 레이어와 필요한 코드를 설명한다. 컨트롤러 레이어는 서블릿으로 구현되고 뷰 레이어는 JSP로 구현된 것으로 간주된다. (다음 개발 딜레마 처리하기 섹션에서는 동기식 요청과 비동기식 요청간 차이점을 설명하겠다.)


    표 1. Ajax가 적용되지 않은 MVC: 전형적인 뷰-레이어 시퀀스와 관련된 코드 분량

    시퀀스 설명 필요한 코드?
    동기식 요청을 실행하기 전 폼(form) 제출을 준비할 때 스크립틀릿 코드가 필요하다. 없음.
    동기식 요청 실행 폼 제출은 버튼이나 링크를 통해 실행된다. DOM 엘리먼트 값은 ( GET 또는 POST를 통해) HttpRequest로 자동 설정된다. 없음: 필요한 것은 페이지를 제출하는 방식이다.
    동기식 요청에 대한 응답 처리하기 서버 측 코드가 실행을 완료하면 객체는 (HttpRequest를 통해서나 HttpSession에 저장되어) JSP로 보내진다. 이 시점에서 객체들은 HttpRequest 또는 HttpSession을 통해 JSP에 액세스 되고(스크립틀릿이나 태그 라이브러리 사용), 객체 콘텐츠를 디스플레이 하는데 최소한의 스크립팅이 요구된다. 있음: 최소한의 스크립틀릿

    Ajax를 이용한 MVC 뷰 레이어를 나타내는 표 2와 표 1을 비교해보자. 여기에서도 마찬가지로 컨트롤러 레이어는 서블릿에 의해 구현되고 뷰 레이어는 JSP로 구현된다.


    표 2. Ajax를 이용한 MVC: 전형적인 뷰-레이어 시퀀스와 관련된 코드

    시퀀스 설명 필요한 코드?
    비동기식 요청을 실행하기 전 Ajax 호출에 필요한 DOM 엘리먼트의 값을 가져오는데 JavaScript 코드가 필요하다. 있음
    비동기식 요청 실행 XMLHTTPRequest를 만들고 (이전에 모은) DOM 엘리먼트의 값을 연결시키고 보내는데 (XMLHTTPRequest.send()) JavaScript 코드가 필요하다. 있음
    비동기식 요청에 대한 응답 처리하기 서버 측 코드가 실행을 끝낸 후에 JavaScript 코드는 (XML 응답 스트림에서) 결과를 가져와서 해당 DOM 엘리먼트에 따라서 값을 전파한다. 있음

    Ajax를 사용하면서 뷰 레이어에서의 스크립팅 코드의 양이 증가하는 것을 볼 수 있다. 세 가지 큰 단점이 있다.

    • JSP는 많은 JavaScript 코드를 필요로 한다.
    • 디자인은 역할 영역의 분리를 무시한다.
    • 디자인이 통합된 monolithic JSP (Model 1 접근 방식: 많은 HTML, CSS 코드, 이미지, 스크립팅 코드)를 사용한다. 이는 읽고 관리하기가 매우 까다로운 반패턴이다. (참고자료)

    이러한 디자인 상의 단점을 피하거나 최소한 완화시킬 수 있는 여러 옵션들이 있다:

    • 재사용을 고려한 디자인: Ajax의 스크립팅 코드는 피하기 힘들다. 스크립팅 코드를 기획 및 설계하여 최대한 재사용할 수 있도록 한다.

    • 클라이언트 측에 MVC 방식 채택: 클라이언트 측에 MVC 방식 (Ajax in Action - 참고자료)을 사용할 수 있다. 이 방식은 관심의 분리 측면에서는 효과를 거둘 수 있지만 복잡해 질 수 있기 때문에 충분히 고려해야 한다.

    • Ajax 프레임웍 사용: Direct Web Remoting (DWR)(참고자료) 같은 여러 오픈 소스 Ajax 프레임웍들은 최소한의 코딩으로도 Ajax 패턴을 Java EE 애플리케이션으로 잘 통합한다.

    • 디자인의 유효성에 대한 재평가: Ajax는 웹 애플리케이션에 데스크탑 애플리케이션 애트리뷰트를 제공한다. 주어진 웹 애플리케이션에서 클라이언트 측 인터랙션 대부분이 Ajax를 활용한다. 애플리케이션은 데스크탑 애플리케이션으로서 보다 더 잘 설계될 것이다.




    		위로


    개발 딜레마 처리하기

    자바 웹 개발에 Ajax를 사용할 때 동기식(synchronous) 통신 모델과 비동기식(asynchronous) 통신 모델의 차이를 완전히 이해하는 것이 중요하다. (참고자료) 비동기식 통신 모델의 지원 부족은 클라이언트 측 개발, 웹 프레임웍과의 통합, 태그 라이브러리의 사용, IDE 사용, 쓰레딩 작동에 영향을 미칠 수 있다.

    동기식 요청/응답 통신 모델에서 브라우저(웹 서버, 애플리케이션 서버, 웹 애플리케이션에 반(反)하는 개념)는 언제나 요청을 초기화 한다. 한편, 웹 서버, 애플리케이션 서버, 웹 애플리케이션은 인커밍 요청에 대응한다. 동기식 요청/응답 쌍이 처리되는 동안 사용자는 브라우저를 사용할 수 없다.

    그림 2는 전통적인 웹 애플리케이션의 동기식 통신 모델을 나타내는 시퀀스 다이어그램이다. 서버의 생명 주기에서 클리어언트의 데이터 제출과 서버 측 프로세싱은 강결합 된다.


    그림 2. 동기식 통신 시퀀스
    Synchronous Communication sequence

    비동기식 요청/응답 통신 모델에서, 웹 서버, 애플리케이션 서버, 웹 애플리케이션에 대한 브라우저 간 통신은 결합력이 약하다(decouple). 비동기식 요청/응답이 처리되는 동안 웹 사용자는 브라우저를 계속 사용할 수 있고 동시에 비동기식 요청이 처리된다. 비동기식 요청 프로세싱이 완료되면 비동기식 응답이 (웹 서버, 애플리케이션 서버, 웹 애플리케이션 에서) 클라이언트 페이지로 간다. 일반적으로 이 프로세스 동안에 실행은 웹 사용자들에게는 어떤 영향력도 없다. 응답을 기다릴 필요가 없다.

    그림 3의 시퀀스 다이어그램은 비동기식 통신 모델을 묘사한 것이다. 첫 번째 dataSubmission(서버 측 프로세싱)과 리턴된 dataSubmission 모두 빨간색 원이 그려져 있다. 이 시퀀스들은 분리되어 있다. 이 그림에서는 중요한 요소들을 강조하고 있다. (쓰레딩 문제 참조) 다시 말해서 이 모드에서 다중 제출(쓰레드)가 빈번히 일어날 것 같다.


    그림 3. 비동기식 통신 시퀀스
    Asynchronous communication sequence

    클라이언트 측에 미치는 영향

    Ajax를 웹 애플리케이션에 도입할 때 개발 팀은 여러 가지 함정을 조심해야 한다. 대개는 생성된 HTML 페이지와 이것이 브라우저와 인터랙팅 하는 방식과 관련되어 있다. 이러한 문제들은 Chris Laffra의 Considering Ajax 시리즈에 잘 설명되어 있다. (참고자료)

    • 스크립팅이 실행되지 않을 수 있다: 여러 가지 다양한 이유로 인해, JavaScript는 많은 사용자 브라우저에서는 실행되지 않는다.

    • 크로스 브라우저 지원 때문에 많은 코드가 필요하다: 여러 브라우저들과 브라우저 버전들을 지원하는 애플리케이션은 스크립팅 코드가 많아져야 한다. 브라우저가 DOM 엘리먼트(그리고 그러한 엘리먼트를 연산하는 자바 스크립트 코드)를 인터프리팅 하는 방식에 미묘한 변수들이 존재하기 때문이다.

    • JavaScript는 안전하지 않다: 대부분의 브라우저에서, HTML 페이지와 제휴된 JavaScript 소스 코드는 뷰 소스 옵션을 선택하면 볼 수 있다. Ajax 패턴을 사용할 때 스크립팅 코드의 로직이 민감하지 않은지를 확인해야 한다.

    웹 프레임웍과의 통합

    Ajax 개발을 자신의 Java EE 웹 프레임웍과 통합하려는 시도는 자연스러운 현상이다. 하지만 몇몇 Java EE 웹 프레임웍은 비동기식 통신 모델을 지원하지 않는다. 서블릿이 동기식 통신과 비동기식 통신을 처리하는 방법을 이해해야 한다. 그림 4는 전통적인 서블릿이 동기식 요청을 처리하는 모습이다.


    그림 4. 동기식 요청을 처리하는 서블릿 시퀀스
    Traditional Servlet sequence (synchronous)

    그림 4는 Java EE 웹 개발자에게는 익숙할 것이다. 브라우저에서 온 요청이 처음에는 컨트롤러 서블릿의 service()에 의해 처리된다. 서블릿은 필요한 값을 HttpRequest (매개변수 또는 애트리뷰트로서)를 가져올 수 있다. 컨트롤러 프로세싱이 처리되면 결과는 HttpRequest (또는 HttpSession)로 보내지고 RequestDispatcher는 컨트롤을 페이지로 전달한다.

    그림 5는 비동기식 요청을 처리하는 서블릿 시퀀스이다:


    그림 5. 비동기식 요청을 처리하는 서블릿 시퀀스
    Servlet sequence (asynchronous)

    그림 5의 시퀀스는 동기식 시퀀스와는 약간 다르다. 브라우저에서 온 요청은 처음에는 컨트롤러 서블릿의 service()에 의해 처리된다. 이 서블릿은 필요한 모든 값을 HttpRequest (매개변수 또는 애트리뷰트로서)에서 가져올 수 있다. 일단 컨트롤러 프로세싱이 끝나면 HttpServletResponse의 콘텐트 유형이 XML로 설정되어야 한다. 또한 컨트롤러 로직의 결과는 PrintWriter로 작성된다. 이 시점에서 RequestDispatcher의 사용이 바이패스(bypass)된다.

    이것은 대부분의 Java EE 웹 프레임웍이 지원하지 않는 정확한 (비동기식) 시퀀스이다. 이것 때문에 Ajax와의 통합이 어렵게 된다. 비동기식 통신 모델을 지원하지 않는 포틀릿과 JavaServer Faces (JSF) 프레임웍도 같은 상황에 처해있다.

    이러한 문제를 해결할 수 있는 몇 가지 옵션이 있다:

    • 웹 프레임웍과의 공존: 빌트인 Ajax 지원을 기다리거나 자신의 프레임웍에 Ajax를 강제적으로 지원하는 대신 개별 서블릿으로 모든 비동기식 요청들을 처리할 수 있다. DWR이 이 방법을 사용한다. 이 방식의 단점은 Ajax 요청이 프레임웍의 기능들을 쉽게 활용할 수 없다는 점이다.

    • 웹 프레임웍과 통합하기: 확장을 사용하거나 커스텀 확장을 작성하여 웹 프레임웍과 통합할 수 있다.

    • Ajax를 지원하는 프레임웍으로 마이그레이션: 새로운 프레임웍이 비동기식 통신 모델을 지원하기 시작했다. 이중 하나가 Apache Shale 이다. (참고자료)

    태그 라이브러리

    자바 웹 애플리케이션 개발 시 일반적으로 태그 라이브러리(taglibs)를 많이 사용한다. 많은 Java EE 웹 프레임웍과 마찬가지로 taglibs는 비동기식 통신 모델을 지원하지 않는다. XMLHttpRequest를 통해서 제출된 데이터를 HttpServletRequest로 트랜슬레이트 할 방법이 없다. 본질적으로 비동기식 통신을 지원하지 않는 taglibs는 Ajax XMLHttpRequest 호출이 실행되는 동안 기능을 하지 않는다. 여러분에게 주어진 옵션은 다음과 같다.

    • 비동기식 모델을 지원하지 않는 taglibs를 사용하지 않는다: taglibs로 만든 코드를 HTML/JavaScript 코드로 마이그레이션 한다. (웹 애플리케이션이 taglibs에 많이 의존하는 경우 이 방법을 사용하면 뷰-레이어의 페이지 크기만 늘어난다.)

    • 문제를 해결한다: 이 문제에 대한 해결책을 갖고 있는 Ajax 프레임웍을 사용한다. 그 한 가지 예가 DWR이다. (ExecutionContext.forwardToString() 참조) 이 경우 여러분이 사용했던 taglibs를 계속 사용할 수 있다.

    • Ajax 지원 taglibs를 사용한다: Ajax JSP Tag Library (AjaxTags) 같은 비동기식 모델을 지원하는 taglibs를 사용한다. (참고자료)

    IDE를 이용한 개발과 디버깅

    많은 JavaScript 디버깅 툴은 JavaScript 솔루션을 개발할 때 도움이 된다. 하지만 전통적인 자바 개발 환경에서는 XMLHTTPRequest의 가치와 Ajax와 관련된 특징을 확인할 수 없다.

    한 가지 방법은 AJAX Toolkit Framework (ATF) (참고자료)을 사용하는 것이다. ATF는 강화된 JavaScript 에디팅 기능을 갖춘 Eclipse 플러그인이다. 편집 시 신택스 검사를 할 수 있고, Mozilla 웹 브라우저, DOM 브라우저, JavaScript 디버거 등이 내장되어 있다. ATF에는 Personality Builder가 있는데 이것은 임의의 Ajax 런타임 프레임웍용 IDE 기능의 구현에 도움이 되고 ATF에 있는 런타임 환경에 추가된다.

    쓰레딩 문제

    전형적인 동기식 웹 애플리케이션에서 버튼이나 링크 클릭에 다소 긴 처리 시간이 필요하다. 인내심이 없거나 경험이 없는 웹 사용자들은 버튼과 링크를 한 번 이상 클릭하여 여러 개의 폼 제출을 실행하곤 한다. 이것이 프로세싱 속도를 높일 것이라고 생각하면서 말이다. 사용자들은 (데스크탑 애플리케이션 처럼) 더블 클릭이 필요하다고 생각한다. 웹 애플리케이션에서의 여러 폼 제출은 어떤 경우에는 무해하다. 하지만 어떤 경우에는 심각한 쓰레딩 문제나 경쟁 조건(여러 쓰레드가 코드 블록의 실행을 위해 경쟁하는 것)을 야기할 수 있다. 예를 들어, 뱅킹 애플리케이션에서 Transfer Funds 버튼을 여러 번 클릭하면 원치 않는 다중 이체 결과를 초래할 수 있다.

    동기식 통신 모델과 비동기식 통신 모델 모두를 지원하는 웹 애플리케이션은, 기능이 올바르게 분석 및 기획되지 않으면, 비슷한 문제에 봉착한다. 두 개의 통신 모델을 지원하는 애플리케이션은 해당 페이지에서 서버 측 호출을 혼합한다. (완전한 동기식, 완전한 비동기식, 동기식과 비동기식의 혼합). 여러 번 클릭되는 상황에서 비동기식 호출은 보다 느리게 처리된다. 애플리케이션이 이를 방지하지 않는다면 사용자는 비동기식 쓰레드가 처리되고 있는 동안 동기식 호출을 처리한다. 이 페이지는 리프레시 되지 않아 페이지가 더 이상 작동하지 않기 때문이다. 웹 페이지상의 같은 버튼이나 링크에서 나오지 않았더라도 같은 상황이 서버 측 코드에 쓰레딩 문제를 야기할 수 있다. (다중 클릭 문제와 비슷함)

    뱅킹 애플리케이션의 자금 이체 페이지 예를 들어보자. (그림 6)


    그림 6. 자금 이체 예제
    Transfer funds example

    빨간색 Transfer Funds 버튼은 Ajax 호출을 실행한다. Logout 링크(노란색)는 동기식 호출을 실행한다. 성급하거나 경험이 없는 사용자는 빨간색 버튼과 노란색 링크를 연속적으로 클릭하면 (그리고 두 링크 모두 공통 경로를 갖고 있다고 생각한다면) 경쟁 조건이 발생한다.

    일반적으로 이러한 상황을 방지할 수 있는 두 가지 방법이 있다. 첫 번째는 클라이언트 측 솔루션이다. 링크나 버튼이 실행되면 JavaScript를 사용하여 추가의 페이지 제출이 현재 쓰레드가 실행을 종료할 때까지 금지되었는지를 확인한다. 두 번째 솔루션은 서버 측 코드의 동기화에 의존하여 경쟁 조건을 지키면서 멀티 쓰레드 제출을 허용하는 것이다. 이 문제를 해결할 때 동기화를 적용한다면 Java EE 웹 컴포넌트(서블릿, 포틀릿, JSF)가 멀티 쓰레딩 된다. 코드의 큰 섹션을 동기화 할 때 주의하라. (특히 요청/응답 프로세싱과 관련된 코드) 실제로, 동기화를 잘못 사용하면 애플리케이션이 싱글-쓰레드 애플리케이션으로 변하고 쓰루풋도 줄어든다.




    		위로


    퍼포먼스 함정 피하기

    Ajax를 사용하면 Java EE 웹 기반 애플리케이션의 퍼포먼스에도 영향을 미친다. 요청 당 추가 쓰레드를 허용하게 되면 두 가지 리소스가 영향을 받는다.

    우선, 서블릿 컨테이너에 있는 쓰레드 풀(thread pool))이 영향을 받는다. 쓰레드 풀은 웹 컨테이너에서 동시에 실행할 수 있는 최대 쓰레드의 수를 지정한다. 클라이언트 요청에 쓰레드가 필요하다. 하지만 클라이언트 요청이 사용자 요청과 언제나 같은 것은 아니다. 브라우저는 사용자 요청 당 여러 클라이언트 요청을 필요로 할 수 있다. 예를 들어, 사용자가 제출한 폼에 여러 클라이언트 요청이 필요하다. (폼 값 제출, GIF 파일 가져오기, JavaScript 파일 가져오기, CSS 파일 가져오기) 동기식/비동기식 요청이 동시에 제출될 수 있다면 사용자 요청당 (Ajax 요청에 대해) 적어도 한 개 이상의 쓰레드 소비를 지원할 수 있다는 의미이다. 사용자 요청당 한 개 이상의 쓰레드를 추가하는 것이 가능하지만 애플리케이션이 로딩중이면 결과는 자명하다. (사용자 요청 당 추가 쓰레드가 평균 사용자 카운트 만큼 배가될 것이다.) 분명 서블릿 컨테이너의 퍼포먼스에 영향을 미칠 것이다.

    또 한가지 리소스는 데이터베이스 커넥션 풀(database connection pool)이다. 전형적인 Java EE 웹 애플리케이션은 사용자 요청에 대해 두 가지 유형의 시퀀스를 실행한다. 가벼운(shallow) 요청과 무거운(deep) 요청이다. 가벼운 요청은 서버 측 코드를 실행하는 웹 페이지에서 기원한 요청이지만 요청을 완료하기 위해 (데이터베이스 같은) 영속 스토어에 액세스 하지 않는다. 무거운 요청은 서버 측 코드를 실행하는 웹 페이지에서 기원한 요청이고 요청을 완료할 때 영속 스토어에 액세스 한다.

    무거운 요청 시퀀스(데이터베이스 연결이 필요함)에서, 더 많은 쓰레드를 허용하면 데이터베이스 커넥션 풀링에는 다음과 같은 요소들이 영향을 받는다.

    • 커넥션을 기다리는 쓰레드의 평균 수
    • 커넥션을 기다리는 평균 시간 (밀리초 단위)
    • 커넥션을 사용하는 평균 시간

    결국, 커넥션 풀의 크기나 커넥션 수를 늘려야 한다.




    		위로


    테스팅

    자바 개발자들은 Java SE와 Java EE 코드에 단위 테스트를 수행하는 것을 중요하게 생각하고 있다. Ajax 때문에 브라우저에 내장된 JavaScript의 양이 많아지면서 견고한 단위 테스팅 프레임웍이 절실히 요구된다. JsUnit, Selenium, HttpUnit 등을 사용할 수 있다. (참고자료)

    이러한 프레임웍들은 웹 페이지 상에서 DOM 엘리먼트를 조작하는 JavaScript 함수에 대한 단위 테스트를 개발하는 장치를 제공한다. 또한 단위 테스트를 테스트 슈트로 그룹핑 할 수 있다. Selenium의 브라우저 호환성 테스팅 기능으로 다양한 브라우저와 운영 체계에서 JavaScript 함수를 테스트 할 수 있다. 이것은 JavaScript와 Iframes를 사용하여 테스트 자동화 엔진을 브라우저에 삽입한다. 이 기술은 JavaScript가 작동되는 브라우저에 적용해야 하고 다중 브라우저와 브라우저 버전들을 지원하는 애플리케이션에 특히 유용하다. Selenium과 JsUnit 모두 연속 통합(continuous integration)을 지원한다. JavaScript 단위 테스트와 테스트 슈트를 자동화 구현 프로세스에 통합할 수 있다.




    		위로


    결론

    다른 기술이나 패턴과 마찬가지로 Ajax를 Java EE 애플리케이션에 적용할 때 장단점이 있다. 이 글에서는 Ajax를 Java EE 웹 애플리케이션으로 통합하는 것에 대한 큰 그림을 보여주었다. Ajax의 비동기식 통신 모델은 전통적인 Java EE 웹 애플리케이션의 동기식 모델과는 매우 다르다. 따라서 Ajax를 채택하기 전에 문제가 되는 부분에 대한 충분한 고려가 있어야 한다.

    Java EE 프레임웍과 유틸리티 지원은 계속 발전한다. Ajax가 지원되는 프레임웍을 활용하여 통합 시 생기는 복잡함을 줄여야 할 것이다. JSF 기반 Apache Shale과 서블릿 기반 DWR을 계속 주목하기 바란다.

    기사의 원문보기



    참고자료

    교육


    제품 및 기술 얻기


    토론


    이 글의 관련글
  • JavaMail :: 인증을 요하는 메일 SMTP에 접속하는 방법
  • Yahoo Buzz Game 에서 자바 IDE 부문에서 넷빈즈가 1위네요.. (2)
  • 썬은 G1(Garbage First) Garbage Collector를 상용화할 것인가?
  • 자바 날짜/시간 계산 예제 코드 :: Java Date Code Snippet (2)
  • JAVA.UTIL.SCANNER로 텍스트 스캔하기
  • HTTPURLCONNECTION를 사용하여 웹 페이지 액세스하기 (1)
  • 대칭키를 이용한 암호화와 복호화
  • 객체 지향론자를 위한 함수 프로그래밍(Functional programming)
  • Sun Tech Days 2008 개발자 컨퍼런스 무료 등록자에 선정되다. (4)
    • 2007/04/24 17:33 2007/04/24 17:33
    Trackback Address:http://www.yunsobi.com/blog/trackback/45
    [로그인][오픈아이디란?]