출처
: http://myfancy.blog.me/140035609029
웹2.0 이라는 키워드가 널리퍼지면서 새로운 개념의 정립과 시도들이 늘고 있다.
Reverse AJAX, LazyHttp, WEB 3.0등 많은 용어들이 만들어 지고 있다.
이중에서 Reverse AJAX라는 서버쪽에서 클라이언트로 업데이트 정보를 쏘아주는 것을 알아보자.
<출처>
Ajax는 웹의 유저빌리티와 인터랙티비티를 극적으로 향상시켰다.
Reverse Ajax는 그이상의 인터랙티비티를 약속하는 새로운 기술이다.
Ajax의 소개
고전적인 웹에서 유저는 버튼을 클릭하고, 수초를 기다려야 두번째 페이지를 볼수 있었다. 웹은 데스크톱 기반의 소프트웨어보다 느리고 유저빌리티도 나빴다. 이것은 매우 느리고, 끊어지는 동작이고, 클릭하고 빈 화면을 몇초동안 쳐다봐야 했다. Not GOOD
AJAX는 사용자에게 보다 끊김이 없는 환경을 가져다 주었다. 심지어는 데스크톱 프로그램에 견줄수 있을정도로 말이다. 하지만, AJAX는 완전한 솔루셩이 아니다. 우리는 아직도 실시간 정보를 우리의 브라우저에 즉시 전달할수 없다.
AJAX의 첫번째 큰 문제는 사용자가 접속을 실행해야 한다는 것이다. 예를 들어 웹어플리케이션은 유저에게 응답을 줄때만 액션을 할수가 있다. 서버는 사용자에게 자동으로 무엇인가를 업데이트 하도록 할수 없다. 그래서 서버는 브라우저에 접속을 발생시킬수가 없다.
위에서 보듯이 처음의 웹은 유저가 데이터를 서버로 전송하면 서버프로세스가 활성화되고 처리되는 동안 사용자는 로드중이라는 상태로 빈 화면을 보고 있게된다. 결국 끊김 현상을 격을수 밖에 없다.
AJAX는 자바스크립트를 통해 백그라운드프로세스로 이 문제를 회피하낟. 사용자는 끊김을 느끼지 못하고, 보다 부드럽고 나은 User EX를 제공한다.
위에서 처럼 Ajax는 완전히 부드러운 경험을 제공한다. 클라이언트쪽의 브로세스가 사용자의 동작을 캡쳐하여 백그라운드로 서버에 관련정보를 전달한다. 그렇지만 기본의 비동기방식의 웹과 마찬가지로 서버의 프로세스는 사용자의 요청내에서만 실행된다.
Reverse Ajax의 소개
이런 Ajax의 사기에도 불구하고, Ajax는 여전히 서버로부터 리얼타임 정보를 직접 전송받을수 없다.
어떤 추가정보가 서버에 발생되더라도, 사용자는 페이지를 리로드 하기 전에는 그 정보를 볼수 없다.
우리는 전통적인 방법으로 웹페이지의 자바스크립트를 통해 몇초마다 자동으로 갱신하게 하면 이문제를 해결할수도 있다. 하지만 이렇게 하는것은 많은 유저가 있는 사이트에서는 대역폭을 대단히 증가시킨다. 거의 스스로 DOS를 프로그래밍 하는 것이다.
우리가 실제로 원하는 것은 서버에 새로 도착한 작은 정보조각을 브라우저에 실시간으로 업데이트 시켜주는 것이다. 가장 간단한 방법은 서버가 브라우저에게 데이터가 없데이트 되었다는 것을 알려주는 것이다. 하지만, Ajax관련 설명에서 이야기했듯이, 서버는 브라우저에 접근할수가 없다. 그래서 우리는 이 문제를 해결하기 위한 솔루현이 필요하다.
Reverse Ajax
DHTML, AJAX, LAMP, SPA처럼 ReverseASJAX도 그것만으로는 기술이 아니다. 다른것들과 함께 사용되는 기술들중의 하나이다. 이용어는
Prokata가 설명한것처럼,
DWR이라는 Java Open Source Library에 의해서 만들어 졌다. Reverse Ajax는 웹사이트 디자인의 다른 부분에서 이전에 사용되어저 왔던 기존의 Pushing Data 기술의 조합니다. Ajax에서 이것을 구현함으로서 Reverse Ajax를 구현한다.
Reverse Ajax는 서버에서 브라우저에 컨텐츠를 즉시 전송하는 것을 가능하게 한다. 아래 각각의 세가지 기술을 설명한다.
Polling
Polling은 클라이언트에 의해서 서버에 반복적으로 쿼리하는 것이다. Ajax환경에서 전체페이지가 아닌, 작은 부분의 리프레시를 하는 것이다. Polling은 몇초마다 자바스크립트를 호출함으로서 간단하게 구현할 수 있다. 함수가 호출되었을때만, 클라이언트가 서버에 쿼리(풀링)한다.
위의 그림에서처럼 Ajax를 설명한때 언급한 클라이언트-서버 이벤트모델과 동일하다. 하지만 위 그림은 또한 "Continuous Server Application"을 가지고 있다. 이것은 주식시세정보나 실시간축구스코어 정보등의 예처럼, 서버에서 실시간 액티비티의 연속적인 프로세스를 나타낸다. 실시간 정보가 서버에 도착하면 'Server Processiong'에 전달되는 '이벤트'를 발생시킨다. 서버 프로세싱은 서버에서 클라이언트의 요청을 다루고, 처리하는 영역이다.
위 그림에서 보는것처럼 처음 페이지가 로드되고 나면, 클라이언트쪽 자바스크립트는 몇초간격으로 서버의 정보를 가져온다. 반복적인 풀링은 점선으로 표시되어 있다. 서버에 새로운 정보가 없다면, 점선으로 표시된 빈 응답을 준다. 예를들어 서버에 "Continuous Server Application"으로부터 실시간 데이터 도착과 같은, 새로운 데이터가 있다면, 그것은 클라이언트가 다음에 풀링할때까지 보관된다.
다음 풀링이 발생하면 실선으로 표신된것처럼 데이터를 응답으로 준어 클라이언트에 컨텐츠를 표시한다. 관심을 가져야 하는 부분은, 그림의 오른쪽 부분처럼 만약 클라이언트가 어떤 입력을 발생시키면, 이것은 일반적인 Ajax 어플리케이션처럼 서버로 전달하게 된다.
이것의 문제는 클라이언트가 몇초마다 서버를 계속 괴롭힌다는 것이다. 이 문제는 백만명의 유저가 이 사이트를 이용한다면 발생할수밖에 없다. 서버는 서버가 다루어야하는 일반 트래픽의 최고점에서는 매 몇초마다 백만명의 유저로부터의 백만명의 요청을 처리해야만 한다. 이점은
서버에 부하를 주게되고, 가치있는 대역폭을 소모시킨다.
Comet
보기에는
Comet은 웹페이지는 계속 업데이트하기위한 정말 오래된 기술이다. 이 기술은 서버와 클라이언트 사이에 절대 닫히지 않는 커넥션을 필요로한다. 한번 클라이언트가 서버에 페이지를 요청하면 데이터를 가능한한 천천히 반환한다. 그리고, 가능한 오래 열려있는 커넥션을 유지한다. 이것은 전화를 걸고, 끊지 않고 들고있는 것과 같아서, 당신은 실제로 많은 말을 하지는 않지만, 아직 연결을 되어 있는 것이다.
그렇지만, 페이지가 결코 로드되지 않는 다면 이것이 어떻게 가능한가? 정말로 요청된 페이지를 결코리턴하지 않는 서버는 서버로서 실패한것이 아닌가? 맞다. Comet의 트릭은 페이지와 그 페이지에 IFrame을 반환한다. 이 페이지는 일반적으로 반환되는 것이다. 하지만 IFrame의 내용은 가능한한 느리게 반환되는 것이다. 이 IFrame은 사용자로부터는 숨겨져있고, 그래서 사용자는 일반 웹사이트와 어떤 다른점도 모르게 된다.
위의 그림은 영구적으로 열린 커넥션으로 무엇이 가능한지를 보여준다. 모든 지속적인 서버사이드 업데이트 이벤트는 브라우저로 전달될 수 있다. 더 많은 정보는
Alex Ressell's Blog에 있다.
Piggyback
Reverse Ajax의 이면의 세가지 기술에서 마지막것은 piggyback이다. 이 이름은 관련이 없는 클라이언트 요청에 대한 응답위에 새로운데이터를 피기백(부가로 처리)으로 반환한다고 해서 지어졌다. 서버에 새로운 정보가 도착하면 클라이언트가 서버로 다음 요청을 보낼때까지 저장한다. 서버가 요청에 대한 응답을 줄때 갱신된 새로운 정보도 추가하는 것이다.
위의 다이어그램은 Reverse Ajax를 위한것이 아니고, 단순하게 전통적인 웹 어플리케이션 모델의 컨텍스트에 피기백하는것을 보여준다. 피기백은 또 다른 클라이언트 사이드 자바스크립트 레이어를 필요로 한다. 이 기법은 업데이트되려면 그 전에 사용자가 어떤 활동을 해야하기 때문에 풀링이나 Comet보다는 인기있지는 않다. 이 기법은 사용자가 블로그를 읽는등의 집중력이 있는 작업을 할때, 오래동안 어떤 액티비티도 발생하지 않게되고, 그러면 웹페이지는 새로운 컨텐츠가 발생하여도 그 시간동안은 업데이트 할 수 없다.
Ajax and Reverse Ajax - Putting It All Together
Ajax는 유저빌리티와 인터랙티비티를 향상시키고, UI를 매끄럽게 해준다. Reverse Ajax는 사용자에게 실시간 컨텐츠를 전달하여, 사용자를 끌고 그들의 주의를 계속 유지시켜준다. 마지막 그림은 Reverse Ajax를 제공하기 위해 Comet기술을 사용하는 두가지를 함께 보여준다.
왼쪽에서 오른쪽으로 따라가보면, 점선은 최초의 페이지 요청을 나타낸다. 이 요청은 Comet event bus를 열고, 이벤트를 클라이언트까지 전달하고, UI를 업데이트 할수 있게 해준다. 또한 클라이언트는 'event'와 'dispaly'의 두경우와 같은 Ajax 이벤트를 제공한다. 두번째로는 정보를 Continuous server application을 통해서 정보를 보내는 것도 보여준다. - 이것은 스스로 실시간 정보를 다른 브라우저에 업데이트하는 것을 가능하게 한다.
<출처>
<참고>
Wikipedia
Ajaxian
MSDN
- Asynchronous Pages in ASP.NET 2.0
- User Threads and Build Asynchronous Handlers in Your Server-Side Web Code
