원문 출처 : 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 아키텍처
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. 동기식 통신 시퀀스
비동기식 요청/응답 통신 모델에서, 웹 서버, 애플리케이션 서버, 웹 애플리케이션에 대한 브라우저 간 통신은 결합력이 약하다(decouple). 비동기식 요청/응답이 처리되는 동안 웹 사용자는 브라우저를 계속 사용할 수 있고 동시에 비동기식 요청이 처리된다. 비동기식 요청 프로세싱이 완료되면 비동기식 응답이 (웹 서버, 애플리케이션 서버, 웹 애플리케이션 에서) 클라이언트 페이지로 간다. 일반적으로 이 프로세스 동안에 실행은 웹 사용자들에게는 어떤 영향력도 없다. 응답을 기다릴 필요가 없다.
그림 3의 시퀀스 다이어그램은 비동기식 통신 모델을 묘사한 것이다. 첫 번째 dataSubmission(서버 측 프로세싱)과 리턴된 dataSubmission 모두 빨간색 원이 그려져 있다. 이 시퀀스들은 분리되어 있다. 이 그림에서는 중요한 요소들을 강조하고 있다. (쓰레딩 문제 참조) 다시 말해서 이 모드에서 다중 제출(쓰레드)가 빈번히 일어날 것 같다.
그림 3. 비동기식 통신 시퀀스
클라이언트 측에 미치는 영향
Ajax를 웹 애플리케이션에 도입할 때 개발 팀은 여러 가지 함정을 조심해야 한다. 대개는 생성된 HTML 페이지와 이것이 브라우저와 인터랙팅 하는 방식과 관련되어 있다. 이러한 문제들은 Chris Laffra의 Considering Ajax 시리즈에 잘 설명되어 있다. (참고자료)
- 스크립팅이 실행되지 않을 수 있다: 여러 가지 다양한 이유로 인해, JavaScript는 많은 사용자 브라우저에서는 실행되지 않는다.
- 크로스 브라우저 지원 때문에 많은 코드가 필요하다: 여러 브라우저들과 브라우저 버전들을 지원하는 애플리케이션은 스크립팅 코드가 많아져야 한다. 브라우저가 DOM 엘리먼트(그리고 그러한 엘리먼트를 연산하는 자바 스크립트 코드)를 인터프리팅 하는 방식에 미묘한 변수들이 존재하기 때문이다.
- JavaScript는 안전하지 않다: 대부분의 브라우저에서, HTML 페이지와 제휴된 JavaScript 소스 코드는 뷰 소스 옵션을 선택하면 볼 수 있다. Ajax 패턴을 사용할 때 스크립팅 코드의 로직이 민감하지 않은지를 확인해야 한다.
웹 프레임웍과의 통합
Ajax 개발을 자신의 Java EE 웹 프레임웍과 통합하려는 시도는 자연스러운 현상이다. 하지만 몇몇 Java EE 웹 프레임웍은 비동기식 통신 모델을 지원하지 않는다. 서블릿이 동기식 통신과 비동기식 통신을 처리하는 방법을 이해해야 한다. 그림 4는 전통적인 서블릿이 동기식 요청을 처리하는 모습이다.
그림 4. 동기식 요청을 처리하는 서블릿 시퀀스
그림 4는 Java EE 웹 개발자에게는 익숙할 것이다. 브라우저에서 온 요청이 처음에는 컨트롤러 서블릿의 service()에 의해 처리된다. 서블릿은 필요한 값을 HttpRequest (매개변수 또는 애트리뷰트로서)를 가져올 수 있다. 컨트롤러 프로세싱이 처리되면 결과는 HttpRequest (또는 HttpSession)로 보내지고 RequestDispatcher는 컨트롤을 페이지로 전달한다.
그림 5는 비동기식 요청을 처리하는 서블릿 시퀀스이다:
그림 5. 비동기식 요청을 처리하는 서블릿 시퀀스
그림 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 버튼은 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을 계속 주목하기 바란다.
기사의 원문보기
참고자료
교육
제품 및 기술 얻기
토론
oracle-middleware-strategy-briefing-072008.pdf
