Exploring Reverse AJAX
Ajax dramatically improved the usability and interactivity of the web and the hype still goes on. But there is a new technology called Reverse Ajax, which shows a lot of promise in taking that interactivity further.
Ajax allows the user to have an almost seamless user interface, improving usability and interactivity. Reverse Ajax goes further and allows web pages to have real-time content, attracting more users and retaining their attention. Reverse Ajax will possibly open up areas of website development which up to now have not been possible.
Firstly, an introduction to Ajax
There was a time on the Internet when you clicked a button and waited a second or two while the page loaded. It was all a bit slow and stilted, and web applications most certainly did not have the speed or usability of desktop based software. Every time the user clicked they ended up staring at a blank screen for a couple of seconds. Not good.
Then along came AJAX and sped it all up. Asynchronous Javascript And Xml (Ajax) allows users to see a much more seamless web application, almost on a counterpart to desktop speed. But Ajax alone is not the total solution. We still cannot get real-time information arriving instantly into our browser.
The one major problem with Ajax is that the user still has to initiate contact. i.e. the application/website is only doing actions in response to the user. At no point does the server decide to do something and update the user automatically. This is because servers cannot initiate contact with browsers.
The whole process of asking for and getting a web page, or indeed any other web resource, can be seen more easily in the following diagrams (in the style of Jesse James Garret's original Ajax explanation).
As you can see the client transmits data to the server when the user requests it. While the server is processing and trying to return a new fresh web page to the user, the user is left with a blank screen and a 'still loading' icon in the status bar which is shown in our diagram by the horrible breaks in the user activity line. Ajax gets around this by using Javascript to handle all the background processes, and allows us to have no breaks in the user activity line, translating into a smoother and more aesthetic user experience.
As can be seen, Ajax allows for an altogether smoother experience. It allows client side processes (Javascript functions embedded in the web page) to capture all the user activity and then pass back relevant information to be processed in the background by the server. But notice that again, just like the classic synchronous web application model, all the server processing is done at the request of the user.
An introduction to Reverse Ajax
Despite all the hype, Ajax cannot get real time information directly from the server. If some information arrives after the user has loaded a page they will never see it, unless they refresh the page.
We could easily solve this problem in the traditional way, by having a having a little bit of Javascript in the webpage that automatically refreshes the page every few seconds. But refreshing an entire page every few seconds is overkill. If the millions of users of a large site were to refresh every few seconds it would increase the bandwidth dramatically. The effect on the servers would be similar to a DOS attack!
We really just need the small piece of real time data to be updated on the browser as soon as it arrives in the server. The simplest way would be to have the server tell all the browsers that the data has been updated. But as we discussed in the introduction to Ajax, servers cannot initiate contact with browsers. Hence we need a solution which gets around this problem.
Welcome to Reverse Ajax
Like DHTML, AJAX, LAMP and SPA, Reverse AJAX is not a technology in itself, but a term that refers to the use of a group of technologies together. The term, as Prokata explains, was coined by DWR, the Java open source library. Reverse Ajax is composed of existing technologies for pushing data, which have been used before in other areas of website design. By implementing these technologies in Ajax we have created Reverse Ajax. Reverse Ajax allows servers to push content out to browsers immediately it becomes available. The following is a brief introduction to each of the three technologies.
Polling
Polling is the repeated querying of the server by a client. In an Ajax environment on refreshing only as small section will have to be updated, and not the whole page. Polling could easily be implemented by having a javascript function called by a timer every few seconds. When the function is called it queries (polls) the server.
The above diagram shows the same client-server event model as I used for explaining Ajax, but it also has a "Continuous Server Application". This is meant to represent the continuous process of real-time activity on the server, for example stock market prices being updated or the latest football scores arriving etc.. When real time information arrives on the server it raises an 'event', which is passed to the 'Server Processing'. Server Processing is the area where client requests are handled, processed, by the server.
As you can see from the above diagram, once the page is loaded, the client side javascript polls the server every few seconds. This repetitive polling is shown on the diagram as dashed lines. If the server has no new information it returns an empty response, shown by the returning dashed lines. If the server does have some new data, for example the real time data coming from the "Continuous Server Application", it is stored until the next time a client polls it.
When the next poll occurs its response returns data, shown by the solid returning line, and passes the content up to the client. An interesting point to note, if the client does actually makes some input, then this can be passed to the server as an Ajax application normally would. Shown on the right part of the diagram.
The problem with this is it requires the client to constantly hassle the server every few seconds, and the problem would only grow if millions of users were using the site. The server would have to handle millions of requests from millions of users every few seconds, on top of the normal traffic it would handle. This could lead to overloading on the server and waste valuable bandwidth.
Comet
Apparently Comet is a really old technology for constantly updating a webpage. The technology requires that the connection between the client and server is never closed. Once the client has requested the web page the server returns the data as slowly as possible, trying to maintain an open connection for as long as possible. It is kind of like phoning up and being put on hold, you are still connected but not very much actual talking is going on.
But how does it work if the page is never loaded? Surely a server which never returns a requested page is failing as a server? Well, you would be right. The trick to Comet is to return a page with an IFrame in it. The page is returned as normal, but the contents of the IFrame are returned as slow as possible. The IFrame is hidden from the user, so the user does not notice any difference from a regular website.
In this way the user gets a normal page and a continuously open connection. It is down this connection that the server can send data to the browser, this data can be handled by Javascript on the normally loaded page.
The above diagram shows what can be done with the permanently open connection, all continuously update server side events can be passed up to the browser. There is far more information on Comet on Alex Russell's blog.
Piggyback
The final of the three technologies behind Reverse Ajax is piggyback. As the name suggests, it is the piggy backing of new data on top of an unrelated response to a client's request. When new information arrives at the server it is stored until the client next makes a request to the server. When the server replies to the request it also adds all the new information which was updated.
The above diagram shows piggybacking in the context of a classic web application model for simplicity, but for reverse Ajax it should have another client side Javascript layer. This technique is not as popular as Polling or Comet as it requires the user to do some activity before it can be updated. If the user is doing a time intensive task, such as reading a blog, they may not do any activity for a long time and so the web page would not be updated at the exact time the new content became available.
Ajax and Reverse Ajax - Putting It All Together
Ajax allows the user to have an almost seamless user interface, improving usability and interactivity. Reverse Ajax allows users to have real time content, attracting users and retaining their attention. One final diagram shows the two working together, using the Comet technology to provide Reverse Ajax.
Walking through the diagram from left to right, we see the dashed line representing the initial request for the page by the client to the server. This opens up the Comet event bus, allowing server side events to travel up to the client and update the browser UI. The client can also provide Ajax events, two examples of the 'event' and 'display' are shown. The second also shows the sending of information through to the "Continuous server application" - this itself is real time information which could be used to update other browsers.
Further Reading
Beyond Ajax
Changing the Web Paradigm
Comet Wikipedia Article
Reverse Ajax Wikipedia Article (initially created by this author)
Reverse Ajax on Ajaxian
Ajax dramatically improved the usability and interactivity of the web and the hype still goes on. But there is a new technology called Reverse Ajax, which shows a lot of promise in taking that interactivity further.
Ajax allows the user to have an almost seamless user interface, improving usability and interactivity. Reverse Ajax goes further and allows web pages to have real-time content, attracting more users and retaining their attention. Reverse Ajax will possibly open up areas of website development which up to now have not been possible.
Firstly, an introduction to Ajax
There was a time on the Internet when you clicked a button and waited a second or two while the page loaded. It was all a bit slow and stilted, and web applications most certainly did not have the speed or usability of desktop based software. Every time the user clicked they ended up staring at a blank screen for a couple of seconds. Not good.
Then along came AJAX and sped it all up. Asynchronous Javascript And Xml (Ajax) allows users to see a much more seamless web application, almost on a counterpart to desktop speed. But Ajax alone is not the total solution. We still cannot get real-time information arriving instantly into our browser.
The one major problem with Ajax is that the user still has to initiate contact. i.e. the application/website is only doing actions in response to the user. At no point does the server decide to do something and update the user automatically. This is because servers cannot initiate contact with browsers.
The whole process of asking for and getting a web page, or indeed any other web resource, can be seen more easily in the following diagrams (in the style of Jesse James Garret's original Ajax explanation).
As you can see the client transmits data to the server when the user requests it. While the server is processing and trying to return a new fresh web page to the user, the user is left with a blank screen and a 'still loading' icon in the status bar which is shown in our diagram by the horrible breaks in the user activity line. Ajax gets around this by using Javascript to handle all the background processes, and allows us to have no breaks in the user activity line, translating into a smoother and more aesthetic user experience.
As can be seen, Ajax allows for an altogether smoother experience. It allows client side processes (Javascript functions embedded in the web page) to capture all the user activity and then pass back relevant information to be processed in the background by the server. But notice that again, just like the classic synchronous web application model, all the server processing is done at the request of the user.An introduction to Reverse Ajax
Despite all the hype, Ajax cannot get real time information directly from the server. If some information arrives after the user has loaded a page they will never see it, unless they refresh the page.
We could easily solve this problem in the traditional way, by having a having a little bit of Javascript in the webpage that automatically refreshes the page every few seconds. But refreshing an entire page every few seconds is overkill. If the millions of users of a large site were to refresh every few seconds it would increase the bandwidth dramatically. The effect on the servers would be similar to a DOS attack!
We really just need the small piece of real time data to be updated on the browser as soon as it arrives in the server. The simplest way would be to have the server tell all the browsers that the data has been updated. But as we discussed in the introduction to Ajax, servers cannot initiate contact with browsers. Hence we need a solution which gets around this problem.
Welcome to Reverse Ajax
Like DHTML, AJAX, LAMP and SPA, Reverse AJAX is not a technology in itself, but a term that refers to the use of a group of technologies together. The term, as Prokata explains, was coined by DWR, the Java open source library. Reverse Ajax is composed of existing technologies for pushing data, which have been used before in other areas of website design. By implementing these technologies in Ajax we have created Reverse Ajax. Reverse Ajax allows servers to push content out to browsers immediately it becomes available. The following is a brief introduction to each of the three technologies.
Polling
Polling is the repeated querying of the server by a client. In an Ajax environment on refreshing only as small section will have to be updated, and not the whole page. Polling could easily be implemented by having a javascript function called by a timer every few seconds. When the function is called it queries (polls) the server.
The above diagram shows the same client-server event model as I used for explaining Ajax, but it also has a "Continuous Server Application". This is meant to represent the continuous process of real-time activity on the server, for example stock market prices being updated or the latest football scores arriving etc.. When real time information arrives on the server it raises an 'event', which is passed to the 'Server Processing'. Server Processing is the area where client requests are handled, processed, by the server.As you can see from the above diagram, once the page is loaded, the client side javascript polls the server every few seconds. This repetitive polling is shown on the diagram as dashed lines. If the server has no new information it returns an empty response, shown by the returning dashed lines. If the server does have some new data, for example the real time data coming from the "Continuous Server Application", it is stored until the next time a client polls it.
When the next poll occurs its response returns data, shown by the solid returning line, and passes the content up to the client. An interesting point to note, if the client does actually makes some input, then this can be passed to the server as an Ajax application normally would. Shown on the right part of the diagram.
The problem with this is it requires the client to constantly hassle the server every few seconds, and the problem would only grow if millions of users were using the site. The server would have to handle millions of requests from millions of users every few seconds, on top of the normal traffic it would handle. This could lead to overloading on the server and waste valuable bandwidth.
Comet
Apparently Comet is a really old technology for constantly updating a webpage. The technology requires that the connection between the client and server is never closed. Once the client has requested the web page the server returns the data as slowly as possible, trying to maintain an open connection for as long as possible. It is kind of like phoning up and being put on hold, you are still connected but not very much actual talking is going on.
But how does it work if the page is never loaded? Surely a server which never returns a requested page is failing as a server? Well, you would be right. The trick to Comet is to return a page with an IFrame in it. The page is returned as normal, but the contents of the IFrame are returned as slow as possible. The IFrame is hidden from the user, so the user does not notice any difference from a regular website.
In this way the user gets a normal page and a continuously open connection. It is down this connection that the server can send data to the browser, this data can be handled by Javascript on the normally loaded page.
The above diagram shows what can be done with the permanently open connection, all continuously update server side events can be passed up to the browser. There is far more information on Comet on Alex Russell's blog.Piggyback
The final of the three technologies behind Reverse Ajax is piggyback. As the name suggests, it is the piggy backing of new data on top of an unrelated response to a client's request. When new information arrives at the server it is stored until the client next makes a request to the server. When the server replies to the request it also adds all the new information which was updated.
The above diagram shows piggybacking in the context of a classic web application model for simplicity, but for reverse Ajax it should have another client side Javascript layer. This technique is not as popular as Polling or Comet as it requires the user to do some activity before it can be updated. If the user is doing a time intensive task, such as reading a blog, they may not do any activity for a long time and so the web page would not be updated at the exact time the new content became available.Ajax and Reverse Ajax - Putting It All Together
Ajax allows the user to have an almost seamless user interface, improving usability and interactivity. Reverse Ajax allows users to have real time content, attracting users and retaining their attention. One final diagram shows the two working together, using the Comet technology to provide Reverse Ajax.
Walking through the diagram from left to right, we see the dashed line representing the initial request for the page by the client to the server. This opens up the Comet event bus, allowing server side events to travel up to the client and update the browser UI. The client can also provide Ajax events, two examples of the 'event' and 'display' are shown. The second also shows the sending of information through to the "Continuous server application" - this itself is real time information which could be used to update other browsers.Further Reading
Beyond Ajax
Changing the Web Paradigm
Comet Wikipedia Article
Reverse Ajax Wikipedia Article (initially created by this author)
Reverse Ajax on Ajaxian
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을 통해서 정보를 보내는 것도 보여준다. - 이것은 스스로 실시간 정보를 다른 브라우저에 업데이트하는 것을 가능하게 한다.
출처
영문 : http://gmapsdotnetcontrol.blogspot.com/2006/08/exploring-reverse-ajax-ajax.html (새 창으로 열기)
한글 : http://blog.naver.com/myfancy?Redirect=Log&logNo=140035609029 (새 창으로 열기)
Trackback URL : http://apollo89.com/blog/trackback/348
rss