2 reasons

Reason 1: Remoting = Faster performance

Flex enables applications to communicate with the server over AMF, a faster binary alternative to String encoding. If your business logic is available in Java, Blaze DS offers Remoting that enables Flex applications to direct communicate with your business logic over AMF.

Note: The fundamental difference between flex applications and web application is that you don’t generate your presentation logic on the server. The communication between the Flex client and your server (Blaze DS) is primarily data. Hence your application performs much faster than a typical web application.

Reason 2: Messaging = Live Flex Applications

The request response nature of HTTP makes it very challenging to create web applications that are not static with out any user interaction. Remember when you watching NFL (any sport scores) on the Internet, your screen updates every 2 minutes to get the latest scores. It is annoying and inefficient. Blaze DS offers a messaging infrastructure that enable you to build server applications that can push messages to Flex Application. Flex applications using Blaze DS don’t have to blink anymore.

To top it, Blaze DS is Open source and Free to use in production

Em 1995 a Netscape^[1] teve a idéia de utilizar respostas HTTP multipart como implementação de server push, onde o servidor envia múltiplas respostas a uma mesma requisição. Treze anos depois eu me dei conta que esse streaming de dados realmente torna aplicações web muito mais dinâmicas, caracterizando o que alguns chamam de Comet^[2].

Outras opções para aplicações dinâmicas incluem deixar um iframe carregando tags Javascript eternamente; abrir uma conexão XMLHttpRequest a cada intervalo de tempo; ou implementar Long Polling, onde o servidor segura a conexão enquanto não houver conteúdo novo e, quando a resposta for enviada, um novo XMLHttpRequest é criado pelo navegador.

O grande conceito de server push é o servidor poder se comunicar com o cliente em tempo real sem que o navegador tenha que ficar pedindo atualizações. Nenhuma das soluções acima consegue atingir o estado da arte neste ponto.

Multipart

O conceito de multipart é o mesmo que utilizamos em e-mails MIME^[3], como quando enviamos e-mails com anexo. Um cabeçalho deve ser enviado definindo que o tipo da resposta é com várias partes separadas por um delimitador (boundary):

Content-type: multipart/mixed; boundary="delimitador"

E então cada uma das partes fica entre este delimitador, acompanhada do seu próprio content-type:

--delimitador
Content-type: text/plain
 
Primeira mensagem
--delimitador
Content-type: text/plain
 
Segunda mensagem
--delimitador
Content-type: text/plain
 
Mensagem final
--delimitador--

O delimitador é iniciado por dois hífens e o último deles também termina com dois hífens, indicando o final do conteúdo. Sem este último delimitador, o cliente vai ficar esperando por outras partes até que os dois hífens depois do delimitador indiquem o final do conteúdo.

Javascript

A diferença no Javascript para receber respostas multipart é apenas um parâmetro extra no objeto XMLHttpRequest:

var xhr = new XMLHttpRequest();
xhr.multipart = true;
xhr.open('GET', 'script-multipart.php', true);
xhr.onreadystatechange = function(){
    if( this.readyState == 4 && this.status == 200 ){
        document.body.innerHTML = this.responseText;
    }
};
window.onload = function(){ xhr.send(null); }

Quando configurado para respostas multipart, a requisição é dada como concluída pra cada uma das partes recebidas. A propriedade readyState recebe o valor 4 (Loaded) e o evento onReadyStateChange é disparado. A parte carregada vai estar disponível em responseText, da mesma forma que em requisições normais.

Se o XMLHttpRequest estiver configurado para multipart, é importante que o servidor responda como multipart e vice-versa.

Servidor

No servidor é necessário enviar o cabeçalho HTTP para definir o tipo de resposta como multipart. Mas diferente das mensagens MIME, o tipo de conteúdo multipart no HTTP é multipart/x-mixed-replace. A partir daí basta respeitarmos a saída com os delimitadores.

<?php
set_time_limit(0);
    
header('Content-type: multipart/x-mixed-replace;boundary="delimitador"');
echo "--delimitador\n";
    
while( true ){
    echo "Content-type: text/plain\n\n";
    
    echo date("d/m/Y H:i:s"), "\n";
    
    echo "--delimitador\n";
    flush();
    
    sleep(1);
}

Ao acessar o script acima pelo navegador já é possível ver as partes sendo trocadas na tela (daí o tipo replace).

O time limit foi desabilitado para que o script fique em execução enquanto o cliente estiver conectado. Sem ele, pela configuração normal do PHP, o script daria timeout em 30 segundos.

O content-type principal (multipart/x-mixed-replace) foi enviado com a função header por fazer parte dos response headers da requisição HTTP. Já os content-type’s de cada mensagem são enviados como saída normal, pois fazem parte do conteúdo como um todo, e não dos cabeçalhos HTTP. Para diferenciar o cabeçalho do conteúdo em si, ele deve ser terminado com uma linha em branco (\n\n). Caso não seja necessário o envio de nenhum cabeçalho, é importante ter uma linha vazia entre o delimitador e o conteúdo.

Assim que cada parte é montada, é preciso ter certeza que ela será enviada ao cliente ao invés de ficar no buffer do PHP. Dependendo do seu ambiente, pode ser necessário o uso da função ob_flush() em conjunto com flush()^[4].

Problemas

Somente Gecko

Até o momento, a interpretação de multipart pelo XMLHttpRequest está disponível apenas em navegadores que utilizam a engine Gecko, como o Firefox, por exemplo. Para manter o código compatível com outros browsers é possível checar o suporte com if( xhr.multipart != null ) e implementar outra solução como contingência. Uma boa saída é utilizar multipart nos navegadores que o suportarem e long polling nos demais.

if( window.XMLHttpRequest ){
    var xhr = new XMLHttpRequest();
}else if( window.ActiveXObject ){
    var xhr = new ActiveXObject('Microsoft.XMLHTTP');
}
function iniciar(){
    xhr.abort();
    if( xhr.multipart != null ){
        xhr.multipart = true;
        xhr.open('GET', 'script-multipart.php?multipart', true);
    }else{
        xhr.open('GET', 'script-multipart.php', true);
    }
    xhr.onreadystatechange = ler;
    xhr.send(null);
}
function ler(){
    if( xhr.readyState == 4 ){
        if( xhr.status == 200 ){
            document.body.innerHTML = xhr.responseText;
        }
        if( ! xhr.multipart ){
            iniciar();
        }
    }
}
window.onload = iniciar;

<?php
set_time_limit(0);
if( isset($_GET['multipart']) ){
    header('Content-type: multipart/x-mixed-replace;boundary="delimitador"');
    echo "--delimitador\n";
}
while( true ){
    if( isset($_GET['multipart']) ){
        echo "Content-type: text/plain\n\n";
    }
 
    echo date("d/m/Y H:i:s"), "\n";
 
    if( isset($_GET['multipart']) ){
        echo "--delimitador\n";
        flush();
        sleep(1);
    }else{
        sleep(1);
        exit();
    }
}

Controle de falha

Nestes exemplos, o script nunca terminará a requisição e o navegador vai ficar esperando novas partes enquanto a página estiver aberta. Essa é realmente a idéia. Contudo, é possível que a execução do script ou a conexão com o servidor seja interrompida inesperadamente.

Como o navegador não recebeu a indicação do fim da resposta multipart (delimitador seguido de dois hífens), o XMLHttpRequest vai ficar esperando novas partes sem que haja qualquer aviso de erro ou timeout. Uma solução razoável é implementar o controle de timeout manualmente:

var xhr = new XMLHttpRequest();
var t;
function iniciar(){
    xhr.abort();
    xhr.multipart = true;
    xhr.open('GET', 'script-multipart.php', true);
    xhr.onreadystatechange = ler;
    xhr.send(null);
    contarTimeout();
}
function ler(){
    if( xhr.readyState == 4 && xhr.status == 200 ){
        contarTimeout();
        document.body.innerHTML = xhr.responseText;
    }
}
function contarTimeout(){
    clearTimeout(t);
    t = setTimeout(iniciar, 5000);
}
window.onload = iniciar();

FastCGI buffer

Um problema que não consegui resolver foi o buffer do FastCGI. Por mais que o script faça flush e ob_flush, parece que o FastCGI mantém um buffer intocável. Neste caso essa solução não funcionaria.

No meu host, eu tenho a alternativa de executar scripts diretamente como CGI. Ao invés de ter um arquivo com extensão .php, criei o script com extensão .cgi e coloquei #!/usr/bin/php na primeira linha. Esta solução funcionou para testes, mas em produção é melhor procurar outra saída, como utilizar mod_php ou até mesmo uma forma de desabilitar o buffer do FastCGI.

Chat em PHP

Eu já tinha publicado um Chat em PHP utilizando Long Polling^[5] e acabei reescrevendo parte dele para utilizar XMLHttpRequest com requisição multipart.

Assim como no último o exemplo, o Javascript faz o controle manual de timeout. Para evitar reconexões quando ninguém mandar mensagem por muito tempo, o servidor envia um ping de tempos em tempos para manter a conexão ativa. Em navegadores que não utilizam a engine Gecko, a solução de Long Polling é utilizada.

Código fonte:
http://code.google.com/p/chatildis/source/browse/trunk/chat-multipart.php?r=10

Script para download:
http://chatildis.googlecode.com/files/chat-multipart.php

Da mesma forma que o chat anterior, esta implementação ainda utiliza o MySQL com tabela na memória para repassar as mensagens para todos os clientes. Este método está longe do ideal. Talvez em uma próxima ocasião eu tente alguma coisa com threads e Observer Pattern.

Referências

1. An exploration of dynamic documents
2. Comet (programming)
3. Multipurpose Internet Mail Extensions (MIME), Multipart messages
4. PHP: flush – manual
5. Chat PHP com XHR Long Polling

کامیت یک تکنولوژی تحت وب است که در آن وب سرور ، اطلاعات را به صورت نا متقارن به سمت کلاینت ( معمولاّ مرورگر وب ) می فرستد بدون آنکه کلاینت صریحاً درخواستی کرده باشد.کامیت به شما این امکان را می دهد که بر اساس رخداد ها عمل کنید ، به صورت زنده با مرورگر تراکنش داشته باشید که در حالت های دیگر ( سایر معماری ها ) امکان پذیر نیست.
واژه کامیت از سال 2006 مطرح شد ولی از سال ها قبل تحت نام های Server push, HTTP push, HTTP Streaming, Pushlets, Reverse Ajax و…. به کار می رفته است.اپلیکیشن های کامیت ارتباط های طولانی مدت HTTP بین وب سرور و کلاینت دارند (Long-Lived) که به سرور اجازه میدهد با وقفه به درخواست ها پاسخ دهد ، و هر موقع اطلاعات جدیدی بوجود آمد آن ها را به سمت کلاینت Push کنند.این متغایر با تعریفی که از ابتدا در مورد وب شده است می باشد که در آن مرورگر صفحه ی کامل وبی را در قبال فرستادن درخواست می گیرد.همچنین با مدلی که از آژاکس نیز ارائه شده است هم متغایر است که در آن مرور گر با درخواست خود قطعه ای از اطلاعات را برای بروز رسانی صفحه ی کنونی به کار می برد.اثری که کامیت می گذارد بسیار شبیه اپلیکیشن هایی است که به طور سنتی از آژاکس به همراه Polling برای چک کردن وجود اطاعات جدید و بروز رسانی صفحه استفاده میکنند.
ولی عملکرد بسیار بهینه شده و تاخیر و Server load بسیار کم شده است.اپلیکیشن های وب همیشه به خاطر وجود محدودیت های دسترسی به منابع محلی و شبکه ای و همچنین محدودیت هایی که برنامه های درون مرورگری نسبت به اپلیکیشن های دسکتاپ کم توانا تر و کم انعطاف پذیر تر بودند،با پیشرفت مرورگر ها بسیاری از این محدودیت ها برداشته شد و همین باعث بوجود آمدن اپلیکیش های توانای اینترنت شد.(Rich Internet Applications ) و اپلیکیشن های وب به اپلیکیشن های دسکتاپ شبیه تر و شبیه تر شدند.
یکی از این مشکلات آن بود که هر قطعه ای از اطلاعات که از سمت سرور به سمت کاربر می رفت باید از طرف کاربر صراحتاّ درخواست می شد. که این مشکل با بوجود آمدن کامیت برداشته شد.کامیت به سرور اجازه می داد به صورت زنده به رخ داد ها پاسخ دهد مانند به روز شدن منابع اطلاعات یا تغییر در آن ( شما شاهد تغییر آنی آن خواهید بود ) یا فرستادن پیغامی از طرف کاربر.کامیت بهترین راه حل برای حل این محدودیت می باشد.
فرض کنید شما نشستید و آخرین تغییرات قیمت طلا را مشاهده می کنید برای اینکه قیمت جدید را ببینید احتیاجی نیست از جاوا ، فلش یا … استفاده کنید. شما با کامیت فقط احتیاج به یک مرورگر دارید.به محض تغییر در سرور در مرورگر شما اطلاعات بروز می شوند بدون اینکه از شما درخواستی برای بروز شدن فرستاده شده باشد.
مثال هایی از کامیت

این مثال ها مربوط به Light Streamer نام فریم ورکی تجاری برای Comet و Ajax می باشد.
توجه داشته باشید که در آن واحد فقط یک اپلیکیشن را باز کنید و چند تا با هم باز نکنید.
برای سرعت بیشتر از مرورگر فایر فاکس استفاده کنید.1- نمودار زنده :
http://app.lightstreamer.com/ChartDemo/

2- لیست زنده قیمت های بازار بورس :
http://app.lightstreamer.com/StockLi…x.html?fade=ON

Rss خوان زنده :
http://app.lightstreamer.com/RSSDemo

مونیتوریگ زنده سرور ( برای پهنای باند ، رم ، CPU …)
http://app.lightstreamer.com/MonitorConsole/

اندازه گیری از راه دور مسابقات فرمول 1 :
http://app.lightstreamer.com/WebTelemetryDemo/

*نکته : طرز تلفظ درست Comet ،کامیت می باشد و نه کامت ، در تالار های گفتگوی فارسی دیدم که به اشتباه از کامت استفاده می کنند.