지난 12개월간 열대 섬으로 휴가를 다녀왔거나 리얼리티 게임 쇼에 참가하여 인터넷과 떨어져 지낸 경우가 아니라면 AJAX에 대한 내용을 들어 본 경험이 있을 것입니다. 그래도 만약을 위해서 간단한 요약을 준비했습니다.
먼저 AJAX는 Asynchronous JavaScript and XML을 의미하는 머리글자어이며 진정한 혁신을 통해 지금까지는 불가능했거나 실질적으로 구현할 수 없었던 솔루션을 가능하게 하는 것을 목표로 하고 있습니다. AJAX가 무엇으로 구성되어 있는지도 알아야 합니다. AJAX는 그 자체가 하나의 기술은 아니며 JavaScript, CSS(Cascading Style Sheet), DHTML 및 XMLHttpRequest와 같이 몇 년 전부터 있었던 클라이언트 쪽 웹 기술의 강력한 조합을 사용하여 구축한 풍부한 기능을 갖춘 브라우저 응용 프로그램을 나타내는 포괄적인 용어입니다.
현재 사용할 수 있는 브라우저의 상당수는 공통적인 기능을 지원하고 있으며 웹 개발자는 이러한 기능을 활용하여 신속하게 새로 고칠 수 있고 클라이언트에서 많은 양의 작업을 처리하는 대화형 응용 프로그램을 구축할 수 있습니다. AJAX 응용 프로그램은 이러한 기능을 활용하여 데스크톱 응용 프로그램을 사용하는 것과 흡사한 풍부한 기능의 사용자 환경을 제공합니다. 또한 AJAX는 어느 때보다 "혼합" 응용 프로그램을 더 쉽게 개발할 수 있도록 지원합니다. 혼합은 다양한 원본의 정보를 결합한 웹 응용 프로그램을 의미합니다. 예를 들어 Microsoft®Virtual Earth™와 부동산 판매 정보를 결합하여 유용한 부동산 업무 도구를 만들 수 있습니다.
사실 필자는 AJAX가 너무 거대하고 중요하기 때문에 몇 년 안에 사람들에게서 잊혀질 것으로 예상하고 있습니다. 그 이유는 AJAX가 이 업계에서 일하는 모든 사람들에게 흡수되어 일상적으로 수행하는 일의 표준적인 부분이 될 것이기 때문입니다. 지금은 XML나 HTTP 사용을 강조할 필요가 없는 것과 마찬가지 원리입니다.
2005년 9월 Microsoft Professional Developers Conference에서 처음으로 소개된 Microsoft ASP.NET AJAX(이전에는 "Atlas"라고 불림)는 ASP.NET 2.0(ajax.asp.net(영문) 참조)에 많은 새 기능을 추가했습니다. 이러한 기능은 모두 웹 사이트에 AJAX 기반 기능을 손쉽게 추가할 수 있도록 설계되었습니다. 이번 달 칼럼에서는 ASP.NET AJAX의 몇 가지 핵심 기능을 자세하게 살펴보고자 합니다. 이 칼럼에서는 독자가 기본 개념 및 도구에 어느 정도 익숙하다고 가정합니다. 처음 시작하는 독자는 Matt Gibbs가MSDN®Magazine2006년 7월호에 소개한 "Atlas at Last: ASP.NET Atlas를 활용한 AJAX 방식의 사이트 개발"을 참조하십시오. 또한 보충 기사인 "현재로서는 동기만 지원" 부분에서도 약간의 추가 정보를 볼 수 있습니다.
ASP.NET에서 AJAX로AJAX를 사용하여 어떤 새로운 응용 프로그램 기능을 만들 수 있을까요? 좀 더 구체적으로 말해, 비동기 JavaScript 호출 및 브라우저의 개체 모델을 사용하여 어떤 기능을 만들 수 있을까요? AJAX의 기능을 가능하게 하는 기술로는 원격 메서드 호출, 클라이언트 쪽 데이터 바인딩 및 시각 효과의 세 가지가 있습니다. 원격 메서드 호출은 다소 막연하게 들리므로 부분 페이지 다시 게시 및 대역 외 요청으로 범위를 좁히겠습니다.
어떻게 하면 새로운 또는 기존 ASP.NET 응용 프로그램을 AJAX 응용 프로그램으로 바꿀 수 있을까요? 현재 AJAX 개발을 위한 100종 이상의 프레임워크가 있는 것으로 보고되고 있습니다. 이러한 프레임워크에서는 다양한 플랫폼을 지원하며 여러 가지 프로그래밍 방식을 활용합니다. 필자는 일반적으로 AJAX 프레임워크를 기능에 따라 콜백 프레임워크, UI 프레임워크 및 종합 프레임워크의 세 가지 큰 범주로 구분합니다.
콜백 프레임워크는 간단한 클라이언트 및 서버 라이브러리 집합으로 구성됩니다. 클라이언트에서 서버 쪽 코드 조각을 호출하고 serialize된 형식으로 입력 및 출력 매개 변수를 전달하는 것이 이 프레임워크의 기능입니다. 일반적인 UI 프레임워크는 고급 표, 차트 및 트리 컨트롤을 제공하던 기존의 전문 컨트롤 라이브러리를 발전시킨 것이며 비동기 다시 게시 및 페이지의 자동 새로 고침을 위해 클라이언트에 JavaScript 코드를 삽입하는 작업을 지원합니다. 마지막으로 종합 프레임워크는 컨트롤 및 응용 프로그램 서비스를 포함하는 풍부한 기능의 프로그래밍 모델을 제공하며 클라이언트 및 서버 양쪽에 대해 지원되는 경우가 많습니다. Microsoft ASP.NET AJAX는 이 세 번째 범주에 속합니다.
이미 시판된 컨트롤 제품군을 사용하고 있다면 매끄럽게 다음 AJAX 지원 버전으로 업그레이드할 수 있을 것입니다. 응용 프로그램 전체를 내부에서 개발하고 프레젠테이션 계층을 비롯하여 백 엔드 계층까지 처리한다면 종합 프레임워크가 가장 적합한 옵션입니다. 마지막으로 간단한 프레임워크는 기존 ASP.NET 버전 1.1 및 2.0 응용 프로그램에 신속하게 콜백 기능을 추가하려는 경우에만 유용합니다.
ASP.NET 2.0에서는 이미 스크립트 콜백 API를 기본 제공하며 이에 대해서는 "Cutting Edge: Script Callbacks in ASP.NET(영문)" 및 "Cutting Edge: Custom Script Callbacks in ASP.NET(영문)" 칼럼에서 몇 차례 살펴본 적이 있습니다. 그리고 이 칼럼과 함께 제공되는 코드에도 원격 메서드 호출을 위한 매우 간단한 AJAX 프레임워크 데모가 포함되어 있습니다. 이 데모는 단지 50줄의 JavaScript 및 관리 코드로 이루어져 있습니다. 물론 이 데모로 ASP.NET AJAX와 경쟁할 수는 없겠지만 ASP.NET 1.1 응용 프로그램에 기본적인 AJAX 기능을 추가하기 위한 핵심 코드로 사용할 수는 있습니다.
ASP.NET AJAX로의 지름길ASP.NET AJAX는 서로 배타적이지는 않지만 별개인 클라이언트와 서버의 두 API로 구성되어 있습니다. 개발자는 직접적인 클라이언트 쪽 프로그래밍, 일반적인 서버 쪽 프로그래밍 또는 이 두 가지의 모든 조합을 사용하여 AJAX 기능을 작성할 수 있습니다. 모든 AJAX 기반 페이지에는 브라우저 DOM(문서 개체 모델) 및 응용 프로그램별 확장 기능을 처리하기 위한 약간의 클라이언트 쪽 JavaScript 코드가 필요합니다. 그러나 이러한 스크립트 코드를 작성하는 역할을 ASP.NET 프로그래머에게 넘길 필요는 없습니다. 프레임워크를 사용하면 서버 쪽 컨트롤의 출력을 통해 맞춤형 스크립트 코드를 생성할 수 있기 때문입니다. 이러한 형식의 간접 페이지 업데이트는 새로운 또는 기존 ASP.NET 2.0 페이지에 AJAX 기능을 추가하는 가장 간단한 방법입니다. ASP.NET AJAX에서 페이지 업데이트는 서버 컨트롤인 UpdatePanel 컨트롤이 자동으로 주입한 클라이언트 코드 조각에 의해 제어될 수 있습니다.
UpdatePanel 컨트롤은 ASP.NET AJAX의 서버 중심 프로그래밍 모델에서 중추 신경이라 할 수 있으며 이를 통해 서버 쪽 코드를 실행하고 업데이트된 태그를 클라이언트 브라우저로 반환할 수 있습니다. 이것이 기존의 다시 게시와 어떻게 다른지 궁금할 것입니다. 차이점은 다시 게시가 구현되는 방법에 있습니다. UpdatePanel 컨트롤은 전체 페이지를 새로 고치지 않고 우선 새로운 태그를 위한 대역 외 요청을 전송한 다음 응답이 준비되면 DOM 트리를 업데이트할 수 있습니다.
ASP.NET의 클라이언트 중심 프로그래밍 모델은 원격 끝점(대부분 ASP.NET 웹 서비스 및 Windows®Communication Foundation 서비스)에 대한 호출을 수행할 수 있는 기능을 중심으로 구성되어 있습니다. 클라이언트 브라우저에서 직접 시작된 원격 끝점에 대한 호출에는 JavaScript 프록시 및 약간의 JavaScript 코드가 필요합니다. 마지막으로 클라이언트 쪽 데이터 바인딩은 기존의 JavaScript 런타임 및 DOM을 확장한 것으로 볼 수 있습니다. 순수한 클라이언트 쪽 프로그래밍 스타일의 경우 원격 끝점에 연결하고 데이터를 다운로드한 다음 이를 DOM 하위 트리에 바인딩합니다. 템플릿의 구조는 약간의 상태 정보와 함께 클라이언트에 유지되며 원시 데이터만 서버에서 클라이언트로 전송됩니다.
ASP.NET AJAX에는 세 가지 주요 프로그래밍 방식이 있습니다.그림 1에서는 이러한 도구를 요약하고 최적의 용도를 보여 줍니다.
UpdatePanel 및 인터셉터 패턴UpdatePanel 컨트롤의 등장으로 인해 페이지 전체를 새로 고치지 않고, 클라이언트 쪽 프로그래밍을 사용하지도 않으면서 페이지 내용을 업데이트하는 프로그래밍 스타일이 가능해졌습니다. ASP.NET AJAX 용어로는 이를 부분 렌더링이라고 합니다. 이러한 기능을 가능하게 하는 구성 요소 중 가장 눈에 띄는 것은 UpdatePanel 컨트롤이지만 부분 렌더링 내부 구현의 실제 처리 주체는 ScriptManager 컨트롤입니다. 물론 UpdatePanel 컨트롤을 무시할 수는 없습니다. 이는 개발자가 부분 업데이트 가능한 페이지를 작성할 때 사용하는 주요 도구입니다.
웹 페이지를 새로 고치는 작업은 제출 단추를 직접 클릭하거나 프로그래밍 방식으로 DOM 폼 개체의 제출 메서드를 호출하는 두 가지 방법 중 하나로 수행할 수 있습니다. 두 경우 모두에서 브라우저는 현재 페이지에 대한 작업을 멈추고 새 요청을 백 엔드 웹 서버로 전송합니다. 그러면 들어오는 응답이 기존 내용을 다시 정의하게 됩니다.
UpdatePanel 컨트롤의 목적은 간단히 말해 이 프로세스에 관여하는 것입니다. 즉, 폼 제출을 가로채어 전송되는 정보를 캡처하고 동일한 정보를 XMLHttpRequest 기반의 대역 외 호출을 통해 전송합니다. 이때 UpdatePanel 컨트롤은 서버에서 처리하여 렌더링될 컨트롤이 무엇인지 나타내는 약간의 정보를 추가합니다. 즉, 부분 페이지 렌더링을 수행하는 것입니다.
UpdatePanel 컨트롤의 결과 동작은 인터셉터 패턴으로 완전하게 설명할 수 있습니다. 여기서 패턴은 개체 호출을 감시하고 자체 코드를 호출자와 수신자 사이에 끼워 넣는 모든 외부 구성 요소를 말합니다. 외부 구성 요소는 이 방법으로 작업을 완벽하게 제어하고 작업이 수행되는 방법을 결정하며 호출자에 유효한 응답을 반환할 수 있게 됩니다.그림 2에서는 ASP.NET AJAX에서 이 패턴이 어떻게 구현되는지 보여 줍니다.
그림 2 UpdatePanel 컨트롤 및 인터셉터 패턴 (더 작게 보려면 이미지를 클릭하십시오.) 그림 2 UpdatePanel 컨트롤 및 인터셉터 패턴 (더 크게 보려면 이미지를 클릭하십시오.) 클라이언트 페이지로 주입된 스크립트 코드는 폼의 onsubmit DOM 이벤트에 대한 처리기를 등록합니다. 이 새 처리기는 XMLHttpRequest를 통과하고 추가 정보를 전달하는 요청으로 기존의 요청을 대체합니다. 특히 이 처리기는 기존 입력 필드의 목록을 다시 게시하는 역할을 하는 UpdatePanel 컨트롤의 이름을 추가합니다. 페이지로 나눌 수 있는 표 형태가 있는 페이지의 경우 내용이 다음과 같이 수정됩니다.
ScriptManager1=UpdatePanel1|GridView1&
__EVENTTARGET=GridView1&
__EVENTARGUMENT=Page%241&
__VIEWSTATE=...&
__VIEWSTATEENCRYPTED=&
__EVENTVALIDATION=...
의사 매개 변수인 ScriptManager는 다시 게시를 수행하는 UpdatePanel 컨트롤의 ID를 참조합니다. 지정된 UpdatePanel 컨트롤과 연결된 컨트롤만 새로 고쳐지며 수정된 태그는 업데이트된 viewstate 정보와 함께 브라우저로 다시 전송됩니다.
내부 구현 방식에는 차이가 있지만 부분 렌더링은 다양한 AJAX 프레임워크의 공통적인 기능입니다. 각 프레임워크의 차이점은 대부분 업데이트 가능 컨트롤을 요청에 연결하는 방식에 있습니다. ASP.NET AJAX에서는 업데이트 가능 컨트롤이 가장 바깥쪽 컨테이너 컨트롤(UpdatePanel)로 그룹화됩니다. 컨테이너에 포함된 모든 내용은 현재 표시된 페이지의 변경된 내용을 나타내는 태그로 렌더링됩니다. AJAX 스타일의 다시 게시로 렌더링을 수행하는 프레임워크에 프로그래밍 방식으로 개별적인 컨트롤을 등록하도록 요구하는 다른 방법도 있습니다. 이것은 ASP.NET 2.0에서 컨트롤 상태를 지원하는 컨트롤을 사용할 때 진행되는 방식과 다소 유사합니다.
컨테이너에 컨트롤을 그룹화하는 것보다 세분성과 유연성이 개선된 방식으로, 각 컨트롤이 AJAX 스타일의 다시 게시를 렌더링하는 방법을 결정하도록 하는 것이 있습니다. 그러나 이 방법을 사용하면 추가 코드 숨김 명령이나 특수 컨트롤을 사용해야 합니다. 이 방식은 컨트롤 라이브러리 및 기타 제품으로는 좋지만 ASP.NET과 같은 웹 프레임워크로는 지나치게 복잡합니다.
UpdatePanel 컨트롤은 System.Web.UI.Panel에서 파생된 클래스입니다. 하위 ASP.NET 컨트롤의 UI 없는 컨테이너인 UpdatePanel은 어떤 ASP.NET 서버 컨트롤도 포함할 수 있으며 이를 사용하기 위해 특수한 AJAX 지원 컨트롤이 필요하지도 않습니다. UpdatePanel을 사용하면 기존의 ASP.NET과 동일한 응용 프로그래밍 모델 및 프로그램 스타일을 사용하여 완전히 서버에서 AJAX 프로그래밍을 수행할 수 있습니다. 개발자는 JavaScript 또는 클라이언트 쪽 Microsoft AJAX 라이브러리에 대해 배울 필요가 없으며, XML 스크립트 또는 브라우저의 DOM을 사용할 필요도 없습니다.
기존 ASP.NET 페이지를 AJAX 페이지로 변환하려면 두 가지 단계를 거치게 됩니다. 우선 ScriptManager 컨트롤을 페이지에 추가합니다. 그런 다음 부분적 및 비동기적으로 새로 고칠 컨트롤 그룹을 UpdatePanel 컨트롤로 래핑합니다. UpdatePanel 컨트롤은 중첩 시나리오를 지원하며 동적으로 만들 수 있습니다. ASP.NET 페이지에는 원하는 만큼 UpdatePanel 컨트롤을 추가할 수 있습니다.
실제 업데이트는 자식 컨트롤이 다시 게시할 때와 특정 외부 이벤트가 발생할 때의 두 가지 방법으로 트리거됩니다. 트리거와 기타 속성을 사용하면 각 UpdatePanel 컨트롤이 해당 내용을 조건에 따라 새로 고치도록 할 수 있습니다.
UpdatePanel 컨트롤을 사용하면 신속하게 ASP.NET 페이지를 조금씩 AJAX로 마이그레이션할 수 있습니다. 동일한 ASP.NET 페이지에서 AJAX 스타일의 다시 게시 및 기존 방식의 다시 게시를 모두 수행할 수 있으므로 UpdatePanel에서는 각각의 모든 요청에 대해 페이지의 보기 상태를 전달해야 합니다. 보기 상태는 서버로 전송되고 선택된 컨트롤의 변경 내용을 반영하도록 업데이트된 다음 클라이언트에서 다운로드됩니다. 이벤트 유효성 검사 데이터의 경우에도 동일한 과정이 진행됩니다. 보기 상태 및 이벤트 유효성 검사 데이터는 클라이언트에서 업데이트할 수 없으므로 서버로 다시 전송하여 변조 및 올바른 업데이트 여부를 확인해야 합니다. 클라이언트에서 보기 상태 및 이벤트 유효성 검사 데이터의 최신 복사본을 사용할 수 있도록 하는 것은 AJAX 및 기존 스타일 모두에서 성공적인 다시 게시를 허용하면서도 페이지를 일관적인 상태로 유지하는 데 매우 중요합니다.
기본적으로 UpdatePanel은 ASP.NET AJAX를 배우기 위한 가장 쉬운 방법이며 이를 사용하면 최소한의 업그레이드와 마이그레이션 작업만으로 기존 페이지 및 AJAX 페이지에서 완벽하게 상호 운용이 가능합니다. 업데이트 가능한 패널을 사용하면 패널이 매우 빠르게 새로 고쳐집니다. 사실 이러한 업데이트는 너무 빠르게 수행되어 사용자가 변화를 알아차리지 못하는 경우도 있습니다. 이 때문에 변화하는 상황에 대해 알려 주는 자주 변경되는 패널에는 적당하지 않을 수 있습니다. UpdateProgress 컨트롤과 같이 내용이 자주 변경되는 패널은 표시된 변경 내용을 사용자에게 알려 주는 용도가 아니라 장기 작업에 맞게 최적화되어 있습니다. 이러한 변경 내용에 대해 사용자에게 피드백을 제공하는 데는 AJAX Control Toolkit의 최신 CTP에 정의되어 있는 UpdatePanelAnimation Extenter를 사용하는 것이 좋습니다.여기(영문)에서 작동하는 샘플을 볼 수 있습니다. 이 Extender는 다시 게시하는 동안 UpdatePanel의 영역에 애니메이션을 적용합니다. Extender에서는 특히 updating 및 updated 이벤트에 대한 애니메이션을 지정할 수 있습니다. AJAX Control Toolkit은 ASP.NET AJAX Extensions 다운로드에는 통합되어 있지 않으므로 별도로 설치해야 합니다.
대역 외 호출 제어JavaScript를 사용하는 데 익숙하며 클라이언트에서 직접 서버 호출을 수행하려는 개발자의 경우에는 기본적으로 웹 서비스를 사용하거나 정적 페이지 메서드로 호출할 수 있습니다.
개발자는 스크립트 관리자에 ASMX 웹 서비스를 등록함으로써 JavaScript 프록시 클래스를 생성하고 이를 클라이언트 페이지에 주입하도록 ASP.NET AJAX 인프라에 지시하게 됩니다. 웹 서비스 URL에 /js 접미사를 붙여 주소 표시줄(로컬 시스템)에 입력하면 프록시 클래스를 살펴볼 수 있습니다. 다음은 공용 메서드 두 개가 있는 웹 서비스를 위한 JavaScript 프록시의 예입니다. 코드는 읽기 쉽게 간소화하였습니다.
Type.registerNamespace('Samples.MyWebService');
Samples.MyWebService = new function() {
this.appPath =http://YourServer/AjaxDemo/;
var cm = Sys.Net.ServiceMethod.createProxyMethod;
cm(this, "LookupCustomer", "id");
cm(this, "LookupAllCustomers");
}이 코드를 사용하면 스크립트 태그에서 웹 서비스를 호출할 수 있습니다. 여기에서는 기존 프록시 패턴이 사용되며 전반적인 메커니즘은 기존 ASP.NET 또는 Windows 응용 프로그램의 서버에서 웹 서비스를 사용할 때와 정확하게 동일합니다.
그러나 몇 가지 주의 사항이 있습니다. 클라이언트에서 어떤 종류의 서버 쪽 코드를 호출하는 것인지, 다른 말로 하면 클라이언트에서 웹 서비스의 어떤 작업을 호출하려는 것인지 생각해 보아야 합니다. AJAX 페이지에서 호출되는 웹 서비스는 클라이언트 페이지에 약간의 비즈니스 논리를 노출하게 됩니다. 공개 끝점은 인터넷에서 호출할 수 있는 웹 서비스이며 응용 프로그램의 논리를 보호하기 위한 기본 제공 보안 계층은 없습니다. 이러한 취약성은 이전부터 있었던 것입니다.
ASP.NET AJAX는 개발자에게 웹 서비스를 통해 약간의 응용 프로그램 논리를 공개할 수 있는 기회를 제공합니다. 일단 인터넷에 게시되면 모든 호출자가 이 논리(어떤 보안 계층으로도 보호되지 않음)를 사용할 수 있습니다. 일반적으로 인터넷에서 사용하기에 안전한 것으로 생각되는 데이터 및 논리만 공개해야 합니다. 제품 목록을 반환하는 웹 서비스를 작성하고 호출하더라도 심각한 문제는 일어나지 않을 것입니다. 그러나 예를 들어 신용 카드 유효성 검사 처리를 포함하는 BLL(비즈니스 논리 계층)을 공개하는 것은 피해야 합니다.
ASP.NET AJAX는 웹 서비스를 사용하여 클라이언트 페이지에서 직접 사용할 BLL을 공개하도록 하고 있습니다. 즉, AJAX 웹 서비스는 중요하지 않은 사용자 인터페이스 계층 BLL의 한 종류로 보면 됩니다. 중요한 BLL은 기존의 다시 게시 또는 UpdatePanel 컨트롤을 사용하여 호출해야 합니다.
웹 서비스를 직접 ASP.NET AJAX 페이지에 연결하려면 이러한 웹 서비스가 호출자 페이지와 동일한 웹 응용 프로그램에서 호스팅되는 로컬 웹 서비스여야 합니다. 이러한 요구 사항이 있는 이유는 두 가지입니다. 첫째, 웹 서비스는 각 요청에 추가된 /js 접미사를 처리하는 방법을 아는 ASP.NET AJAX 응용 프로그램의 지원을 받아야 합니다. 다른 ASP.NET AJAX 응용 프로그램을 사용하여 웹 서비스를 호스팅하는 것도 가능하지만 이 경우에는 클라이언트 호출이 사이트 간 호출을 방지하는 최신 브라우저의 엄격한 보안 설정과 충돌할 수 있습니다.
페이지 메서드 대 웹 서비스 메서드서버 코드를 ASP.NET AJAX 페이지에 바인딩하는 또 다른 방법으로 페이지 메서드를 호출하는 방식이 있습니다. 호출 가능한 페이지 메서드는 코드 숨김 클래스에 정의되며 웹 서비스 메서드에 사용된 것과 동일한 WebMethod 특성이 지정된 공용 정적(Visual Basic®.NET에서는 공유) 메서드입니다. 현재로서는 인라인 및 코드 숨김의 경우 모두 ASPX 페이지에서만 사용할 수 있지만 향후에는 사용자 컨트롤 및 사용자 지정 컨트롤로 확장될 것입니다.
ASMX 웹 서비스와 페이지 메서드에는 다른 설정이 필요하다는 것도 알아야 합니다. 특히 페이지 메서드를 실행하려면 스크립트 관리자에 웹 서비스를 등록하고 스크립트 HTTP 모듈을 설치해야 합니다.그림 3에서는 web.config 파일에 무엇이 필요한지 보여 줍니다.
웹 서비스를 등록하고 프록시 생성을 지정하려면 다음과 같은 항목이 필요합니다.
<asp:ScriptManager ID="scriptManager1" runat="server">
<Services>
<asp:ServiceReference Path="~/WebServices/MyDataService.asmx" />
</Services>
</asp:ScriptManager>
웹 서비스 클래스에 지정할 추가 특성도 필요합니다. 특히 JavaScript 프록시 클래스 생성을 위해 ScriptService 특성이 필요하며 일반 형식을 제외한 사용하려는 각 사용자 지정 형식에 대해 GenerateScriptType이 필요합니다.그림 4에서 예를 볼 수 있습니다.
Customer 형식에는 GenerateScriptType을 적용해야 하지만 CustomerCollection의 경우 이 형식은 ASP.NET AJAX 기본 제공 지원이 있는 제네릭 컬렉션<T> 클래스에서 파생되기 위해 정의된 것이므로 적용하지 않습니다.
public class CustomerCollection : Collection<Customer> {}페이지 메서드에 필요한 HTTP 모듈은 ASPX 요청을 위한 기본 HTTP 처리기에 연결한 다음, 지정된 메서드를 실행하고 반환 값을 serialize하는 사용자 지정 코드 조각으로 렌더링 단계를 재지정합니다.
페이지 메서드 방식과 웹 서비스 메서드 방식은 모두 백 엔드 BLL에 액세스할 수 있도록 도와줍니다. 공개적으로 제공되는 웹 서비스 메서드와 마찬가지로 페이지 메서드 역시 기초적인 JSON(JavaScript Object Notation) 기술만 있으면 브라우저의 주소 표시줄에서 손쉽게 자동화할 수 있습니다. 따라서 공개하는 BLL 논리와 관련하여 WebMethod와 마찬가지로 이러한 페이지 메서드에 대해서도 주의를 기울여야 합니다.
결국 페이지 메서드 또는 웹 서비스 메서드 중에 어떤 것을 사용할지는 순전히 개발자의 선호에 달려 있습니다. 두 가지 경우에 모두그림 5와 같이 적절한 BLL 함수로 라우팅되는 Façade 계층으로 호출해야 합니다. 웹 서비스 메서드는 각 페이지에 서비스로의 끝점을 등록했다는 가정하에 어떤 페이지에서도 호출할 수 있으나 페이지 메서드는 이를 정의한 페이지에서만 호출할 수 있습니다. 현재 필자는 페이지 메서드를 사용하는 방법을 선호하고 있습니다.
그림 5 페이지 메서드 및 웹 서비스 메서드 비교 (더 작게 보려면 이미지를 클릭하십시오.) ASP.NET AJAX 웹 서비스 메서드와 페이지 메서드는 모두 개체 데이터를 전달하기 위해 JSON을 광범위하게 사용합니다. 간단한 데이터 교환 형식인 JSON은 개체를 serialize하여 문자열로 만드는 데 사용됩니다. JSON은 근본적으로 단순하므로 사용자와 시스템 모두에 적절합니다. SOAP 패킷을 읽고 쓰는 것보다는 JSON 문자열을 읽고 쓰는 것이 쉽습니다. 또한 JSON은 시스템에서 구문 분석하고 처리하기도 쉽습니다.
페이지 메서드가 웹 메서드에 비해 좋은 성능을 제공할 것으로 기대하는 개발자도 있을 것입니다. 결국 웹 서비스 호출을 확인하기 위해 ASP.NET 런타임은 SOAP 패킷을 구문 분석해야 하기 때문입니다. 그러나 실제로는 그렇지 않습니다. ASP.NET AJAX는 모든 ASMX 요청을 가로채는 맞춤형 HTTP 처리기를 설치합니다(그림 3참조). /js 접미사가 있는 요청은 JSON 페이로드 및 웹 서비스 메서드와 직접 작업하여 다르게 처리됩니다. 결과적으로 SOAP는 전혀 관련되지 않으며 요청의 본문에는 입력 인수의 JSON 스트림만 포함하게 됩니다. AJAX가 아닌 요청의 경우 새 HTTP 처리기는 SOAP를 이해할 수 있는 원래 ASP.NET 처리기로 호출을 위임합니다.
ASP.NET AJAX 적용 방법모든 사항을 고려할 때 필자는 UpdatePanel이 대부분의 개발 팀에 최적의 방식이라고 생각합니다. 이 방법을 사용하면 기존 ASP.NET이 방해를 받지 않으며 필요에 따라 기존 페이지를 수정할 수 있습니다. 또한 복잡하지 않고 시작하기 전에 많은 내용을 새로 배울 필요도 없습니다. 뿐만 아니라 UpdatePanel은 BLL에 대해서도 기존 웹 페이지와 같이 어느 정도 수준의 보호를 제공하며 긴 작업을 실행하는 비동기 ASP.NET 페이지를 완벽하게 지원합니다.
마지막으로 강조하고 싶은 것은 다양한 AJAX 플랫폼을 혼합하지 않도록 해야 한다는 것입니다. JavaScript 기본 제공 개체 확장이라는 측면에서 ASP.NET AJAX 및 다른 프레임워크 간에 충돌이 발생할 수 있습니다. 더 중요한 것은 현재 동작하는 제품 조합이 나중에도 동작하리라는 보장은 없다는 사실입니다. 특정 프레임워크의 새 버전에서는 이전에는 없던 충돌이 발생할 수 있습니다.
AJAX 기능은 비동기 기능과 연결되는 경우가 많으므로 ASP.NET AJAX가 기본적으로 비동기적으로 프로그래밍된다고 가정하기 쉽습니다. 클라이언트 관점에서 이것은 분명 사실입니다. 작업은 서버에서 시작되며 현재 페이지는 추가 상호 작용에 사용할 수 있도록 유지됩니다.
그러나 ASP.NET AJAX는 ASP.NET 2.0 비동기 페이지를 지원하지 않으며 비동기적으로(비동기 HTTP 처리기를 통하는 것을 의미) 원격 호출을 구현하지도 않습니다. AJAX 웹 서비스 요청을 처리하는 HTTP 처리기는 동기적으로 작동합니다. 페이지 메서드를 처리하는 HTTP 모듈도 역시 동기적으로 작동합니다. 이는 ASP.NET 페이지가 비동기 처리를 위해 표시되었는지 여부에 관계없이 동일합니다. 이러한 구조적인 문제는 현재 코드 이름 "Orcas"라고 부르는 ASP.NET 이후 버전에서 해결될 것으로 보입니다. 현재로서 최선의 방법은 UpdatePanel 컨트롤을 사용하여 AJAX를 구현하는 것입니다.