O LCCS contém uma infra-estrutura única de servidores que mantém as contas dos desenvolvedores, e estas contas mantém as aplicações através de canais de streaming. Esta arquitetura tem por objetivo proporcionar novas oportunidades para o desenvolvimento de aplicações ricas e colaborativas através de funcionalidades como o real time collaboration (RTC).

Para conhecer mais sobre esta plataforma na prática, resolvi escrever uma versão do 4Conference para funcionar junto ao Adobe Live Cycle Collaboration Service com o objetivo de avaliar o serviço e verificar se realmente vale a pena criar aplicações colaborativas com ele. Nesta aplicação eu usei o protocolo RTMFP para criar um ambiente de conferência p2p com suporte a áudio, vídeo e chat entre duas ou mais pessoas.  O resultado desta avaliação você confere abaixo.

Pontos positivos:

Primeiramente vou falar dos pontos positivos, pois a idéia do serviço me pareceu bastante interessante e válida, apesar de achar que a Adobe está dando um tiro no pé junto ao licenciamento do Flash Media Interactive Server.

SDK

O ponto alto a se destacar do serviço é o SDK, que é um conjunto de componentes visuais e não visuais que permitem criar aplicações Flex/Flash para ambientes de áudio, vídeo, conferências e colaboração síncrona usando protocolos como RTMP e RTMFP.

Componentes

Este conjunto de componentes e classes permitem criar pods visuais de chat, listagem de usuários, área para a publicação de uma ou mais webcans e a publicação do áudio e o seu play, compartilhamento de arquivos e um incrível writeboard, que por sinal é bastante completo e lindão.

Documentação

A documentação é bem completa e trás vários exemplos em vídeo de como compartilhar objetos remotos que são chamados de Shared Models e como trabalhar com eventos concorrentes através de um recurso chamado de Baton que prevê o fluxo de trabalho de forma síncrona entre os usuários. Essencialmente, este recurso fica escutando o usuário que está usando um determinado recurso e fornece uma API para monitorar, adicionar ou remover propriedades de uma determinada funcionalidade da aplicação. Ex: Enquanto o usuário estiver digitando em uma caixa de texto, a caixa é desabilitada para o restante dos usuários.

Código final

A sintax do código final é bastante simples e limpa, até os mais leigos em programação podem usufruir dos recursos somente clicando e arrastando os componentes visuais para criar pequenas aplicações multimídias sobre o flash player e Adobe Air. A idéia primeiramente é ter uma chamada ao rtc:authenticator que vai realizar a autenticação na conta do desenvolvedor para a url da aplicação fornecida no rtc:ConnectSessionContainer.

No exemplo abaixo você pode conferir a quantidade de linhas escritas que criam uma sala com chat e áudio conferência que promove automáticamente todos os  usuários a terem o acesso ao botão para publicar seu áudio.

<rtc:authenticator>

<rtc:AdobeHSAuthenticator id=”auth” username=”username” password=”senha” protocol=”rtmp”/>

</rtc:authenticator>

<rtc:RoomSettings id=”settings” autoPromote=”true” />

<rtc:ConnectSessionContainer  id=”sess”  roomURL=”https://connectnow.acrobat.com/userdeveloper/myappname”
authenticator=”{auth}”  initialRoomSettings=”{settings}” autoLogin=”false” width=”100%” height=”100%”>

<rtc:AudioPublisher id=”audioPub” />

<rtc:AudioSubscriber id=”audioSub” />

<rtc:SimpleChat width=”100%” height=”100%”/>

</rtc:ConnectSessionContainer>

Pontos negativos:

Poucas coisas me perturbaram durante os testes, uma delas é a dificuldade para trabalhar com permissões, o que só pode ser feito somente (pelo menos até onde encontrei) via console ou através de uma api web que permite criar os usuários diretamente no LCCS, mas aí as permissões são setadas antes do usuário autenticar no serviço e não em real time, caso eu precise remover ou adicionar um determinada permissão de um usuário específico.

O Acesso

Se eu precisar definir níveis de acesso através de papéis como administrador, monitor e participante para determinadas funcionalidades, estes usuários devem ser também cadastrados no portal do LCCS, forçando assim qualquer empresa ou desenvolvedor a compartilhar email e senha dos usuários junto ao seu serviço. Achei um pouco de invasão, pois não são todas as empresas e pessoas que gostam de ter seu cadastro em um lugar que eles não conhecem. Afinal, se eu desenvolver uma aplicação usando os recursos do LCCS e vender para um determinado cliente, porque ele gostaria de ter seus dados em outro local?

Custo benefício

O ponto negativo mais alto, é o preço cobrado, que é sob-demanda, você paga por aquilo que usar de banda, mensagens enviadas e por tempo de cada usuário conectado, veja:

Se você estiver usando uma comunicação p2p via RTMFP, irá pagar somente pela quantidade de mensagens enviadas e pelo tempo em que o usuário permanecerá conectado. Caso haja alguma falha na comunicação p2p entre dois ou mais usuários, o usuário que tiver com problemas automáticamente passará a usar o RTMP através de um recurso chamado de FMS failover.

No momento que estiver usando RTMP, você pagará pela quantidade de banda de upload e download que passar por sua aplicação, pela quantidade de mensagens enviadas e pelo tempo de conexão por usuário conectado junto a aplicação.

Confira abaixo os preços divulgados pela Adobe.

Note: Though multiple currencies are supported and your payment card will be charged in the appropriate currency,
the developer portal interface and billing emails will be in English and USD only.

Sinceramente achei um absurdo e caro a forma de cobrança, acredito que um modelo baseado na quantidade de conexões simultâneas seria mais justo, pois pagar 10 centavos de dólares por 1k de mensagens enviadas, ou seja, 1k de uso do chat é fora de série. Comece a somar tudo isso e entenda a onde eu quero chegar. Não importa o tamanho de sua aplicação em recursos, o que importa é a quantidade de uso, se há uma aplicação que fique dois usuários conectados usando recursos de áudio, vídeo, chat e compartilhamentos de arquivos durante 24 horas, e outra aplicação que tenha 10 usuários conectados durante 1 hora, a diferença no valor final pode ser bem pouca.

Qualidade do áudio e vídeo

Ter o controle da qualidade do áudio e vídeo é bem fácil, o que não é fácil é identificar o momento em que a internet do usuário está ruim para assim alterar a qualidade do áudio e vídeo. Por vários momentos o áudio falhou, houve latência, e quando entrava mais de 4 usuários, algum dos usuários ficava sem áudio, isso acontecia de forma randômica e constantemente.

Upgrade

Depois de ter feito todos os testes resolvi fazer o upgrade da conta developer que vem com 15 dólares iniciais para testes, pois pretendia conhecer outros recursos como o controle detalhado de uso por aplicação e a possibilidade de adicionar limite de uso por aplicação, o que permite criar um sistema de bilhetagem. E para minha decepção, até a data deste post a conta não tinha sido atualizada, e olha que já se passaram mais de 5 dias após a Adobe Store ter enviado um email informando a compra e confirmação dos dados da transação.

Conclusão:

A curto prazo o uso do LCCS pode ser bastante interessante, criar aplicações que devem ir para produção o mais rápido possível podem usufruir do serviço com muita facilidade. Já a médio e a longo prazo pode não ser uma boa solução, principalmente se a aplicação exigir muitas conexões simultâneas e pontos de customizações que o SDK não permite criar.

Importante:

Espero que tenha ajudado você de alguma forma com este post. Quero deixar claro que estas foram opiniões pessoais e as mesmas não refletem no desenvolvimento de futuras aplicações usando o Adobe Live Cycle Collaboration Service que eu venha a fazer.

Aplicação demo:

O resultado desta aplicação pode ser visto aqui.

A partir desta aquisição a Adobe criou o Real-Time Media Flow Protocol (RTMFP), um protocolo para comunicações p2p a partir de duas aplicações Flash/Flex rodando sobre o Adobe® Flash® Player 10 ou sobre o Adobe AIR® 1.5. O RTMFP possui recursos muito importantes que inclui baixa latência, segurança e escalabilidade, pois a comunicação parte diretamente entre dois clientes, não passando assim por um servidor Flash Media.

O RTMP funciona somente sobre o TCPIP e sempre irá precisar de um servidor Flash Media no centro, o que pode aumentar a latência dependendo da localização do servidor e seu desempenho. Já com o RTMFP conseguimos garantir mais qualidade porque a comunicação é feita sobre o UDP,  levando assim mais eficiência e a redução drástica da quantidade de pacotes perdidos. Vale destacar que o áudio  tem prioridade sobre o vídeo, o que faz deste procotolo uma excelente opção para o desenvolvimento de aplicações para vídeo conferência de alta qualidade.

Com o RTMFP podemos criar aplicações para vídeo conferências, salas de bate papo, jogos multi-players e ferramentas como o msn, skype, gtalk e afins. Não existe uma API nova para o uso desde protocolo, a comunicação continua sendo feita por NetConnection e NetStream, a única diferença é que é preciso gerar um peer ID para as comunicações p2p, e hoje é possível negociar isso através do Stratus que é um serviço beta da Adobe que permite cada cliente se conectar ao servidores deste serviço somente para gerar e gerenciar o peer ID.

O peer ID nada mais é que uma chave que identifica cada cliente e sua localização, ele é gerado da seguinte forma:

Após conectado ao serviço, basta recuperar o peer ID com:

var myPeerID:String = nc.nearID;

Em seguida basta estabelecer a comunicação do streaming através do NetStream.

sendStream = new NetStream(nc,NetStream.DIRECT_CONNECTIONS);
sendStream.addEventListener(NetStatusEvent.NET_STATUS, netStatusHandler);
sendStream.publish(“media”);

var sendStreamClient:Object = new Object();
sendStreamClient.onPeerConnect = function(callerns:NetStream):Boolean{

farPeerID = callerns.farID;

trace(“O cliente “+farPeerID + “Está te chamando para uma comunicação p2p”);

return true;
}

sendStream.client = sendStreamClient;

Para aceitar a conexão p2p é só usar o código abaixo. Onde o farPeerID é a chave peer ID do amigo p2p.

recvStream = new NetStream(nc,farPeerID);
recvStream.addEventListener(NetStatusEvent.NET_STATUS,netStatusHandler);
recvStream.play(“media”);

recvStream.client = this;

Para enviar uma mesagem para o amigo p2p basta fazer.

sendStream.send(“receiveSomeData”,txtSendData.text);

Você deve estar se perguntando, mas como irei recuperar o peer ID de cada amigo conectado ao Stratus? A resposta é simples, cada amigo se conecta ao Stratus, e de posse do peer ID, cada amigo guarda este ID em seu servidor web ou em um sharedObject em um outro servidor Flash Media por exemplo. A opção de um outro servidor Flash Media para guardar estas chaves de amigos e grupos de amigos é a mais interessante, pois quando eles conectarem ou se desconectarem da aplicação através de um script server side no Flash Media, será possível adicionar ou remover o peer ID de uma lista. Desta forma conseguimos criar um recurso que indentifica quando o usuário estará on-line ou off-line.

O exemplo acima usa o Adobe Stratus que é um serviço beta e não permite criar aplicações comerciais por enquanto, mas já dá uma idéia de uso do RTMFP, pois você poderá criar aplicações para testes entre amigos ou empresas dentro da internet ou intranet. Agora se você pretende implementar uma aplicação comercial e fazer uso de comunicações p2p com o RTMFP, você poderá usar o Adobe Live Cycle Collaboration Service que recentemente foi liberado para uso comercial e que inclui a geração de peer IDs via RTMFP e um recurso chamado de FMS failover que estabelece uma comunicação RTMP automáticamente caso a RTMFP falhe. Como o Adobe Live Cycle Collaboration é um serviço comercial, consequentemente iremos pagar pelo mesmo, e o mais interessante é que vamos pagar somente pelo uso, uma espécie de SaaS.

Em outubro de 2009 no Adobe Max,  a Adobe levou ao público o lançamento de suas principais tecnologias e tendências,  a mesma fez o anúncio do Flash Player 10.1, do Adobe AIR 2.0, e os novos recursos do RTMFP, que inclui:

1. Groups – Inclui suporte a comunicação por grupos de clientes via p2p, assim como acontece no Skype e MSN. Só que a grande sacada é que será possível enviar dados, áudio e vídeo entre todos os clientes presentes em um ou mais grupos.
2. Multicast – Camada que permite o suporte nativo para multicast IP, que são técnicas para a transmissão e serviço de alta qualidade.
3. Posting – Recurso que permite enviar mensagens ActionScript.
4. Directed Routing - Direcionamento de mensagens ActionScript dentro de um grupo para um ou mais clientes especificos. Resumindo, dentro de um grupo será possível enviar mensagens privadas para os usuários que você definir.
5. Object Replication – Envio de mensagens em ActionScript através de replicação. Resumindo, você envia para um cliente x dentro de um grupo, e este cliente envia para outro cliente, e assim sussesivamente.

Na imagem abaixo você pode conferir uma breve amostra do funcionamento de uma comunicação RTMFP baseada em grupos.

Apesar  do RTMFP estar completando um ano, ainda não é possivel o uso de sharedObject como acontece com uso do Flash Media Interactive Server, mas ele tem se comportado muito bem em meus testes de bancada, possuindo uma alta qualidade de áudio quando usado com Speex e vídeo mesmo usando o padrão Nellymoser.

Com todas estas novidades da Adobe estavámos esperando que o Flash Media Interactive Server pudesse gerar e gerenciar também estes peer ID’s, mas pelo jeito isso não deve acontecer tão cedo, pois em novembro de 2009 a Adobe deve lançar o Flash Media Interactive Server 3.5.3 que contém somente atualizações  e a implementação de pequenos novos recursos.  Veja as palavras de Kevin Tower na lista de Flash Media da Community.lsoft.com.

“FLASH MEDIA SERVER – we have not announced any new version of FMS yet that will support RTMFP.  We did hint yesterday that we’ll be updating FMS3.5 to version 3.5.3 later this year to support the new FP 10.1 features – and in a future version after that release – FMS may be one of your options to host a local service to build your own P2P applications – including introductions, and supporting server side programming.”.

Agora vamos aguardar, pois para nós que temos servidores dedicados com a licença do Flash Media Interactive Server não é uma boa opção ter que pagar para usar o Adobe Live Cycle Collaboration Service somente para estabelecer esta geração de peer ID’s. Lembrando que caso falhe a comunicação RTMFP o FMS failover passará a usar o RTMP e teremos também a cobrança de banda de upload, download e da quantidade de dados enviados.  É um pouco estranho estas cobranças para o uso do RTMFP, mas vale ficar atento porque mais novidades virão por aí.