WirelessBR

5.0 – WSP (Wireless Section Protocol)

5.1 – Descrição Geral

  O WSP (Wireless Session Protocol - Protocolo de Sessão Sem Fio) provê meios para a troca organizada de conteúdo entre aplicações cooperativas cliente/servidor. Especificamente, ele fornece às aplicações meios para estabelecer uma sessão confiável do cliente ao servidor e liberar esta sessão de maneira ordenada e concordarem com um nível comum da funcionalidade do protocolo usando capacidade de negociação, bem como trocarem conteúdo entre cliente e servidor usando codificação compacta, além de fornecer meios para suspender e continuar a sessão.

  Os serviços definidos atualmente são, na maioria, utilizáveis para aplicações de navegação. O WSP define dois protocolos: um provê um serviço de sessão de modo conexão sobre um serviço de transação e outro provê serviços sem conexão sobre um serviço de datagrama de transporte. O serviço sem conexão é mais usado quando as aplicações não necessitam de entrega confiável de dados e não requerem confirmação, podendo assim ser usado sem realmente ter que estabelecer uma sessão.

Além disso, o WSP provê funcionalidade HTTP/1.1 (métodos de requisição e resposta extensíveis, composição de objetos e negociação de tipo de conteúdo), troca de cabeçalhos de sessão entre o cliente e o servidor, interrupção de transações em processo, conteúdo push do servidor para o cliente de maneira não sincronizada e negociação de suporte para múltiplas e transações simultâneas assíncronas.

  O projeto do núcleo do WSP é um formato binário do HTTP, conseqüentemente as requisições enviadas ao servidor e as respostas a um cliente podem incluir cabeçalhos (metadados) e informação. Todos os métodos definidos pelo HTTP/1.1 são suportados e a capacidade de negociação pode ser usada para a concordância em um conjunto de métodos de requisição estendidos. Dessa maneira, a compatibilidade total com o as aplicações HTTP/1.1 pode ser garantida.

  O WSP provê também transferência de dados tipados para a camada de aplicação, ou seja, a informação dos cabeçalhos HTTP/1.1 é usada para definir tipos de conteúdo, codificação do conjunto de caracteres, linguagens etc, de uma maneira extensível. Entretanto, as codificações binárias compactas são definidas pelos cabeçalhos bem conhecidos para reduzir a sobrecarga do protocolo. O WSP também especifica um formato de dados de composição binária que provê cabeçalhos de conteúdo para cada componente dentro do objeto de dados composto, o que se assemelha à semântica da forma binária do formato “fragmentado/misturado” do MIME (Multi-purpose Internet Mail Extension - Extensão de Correio para Internet de Múltiplo Propósito) usado pelo HTTP/1.1.

  O WSP sozinho não interpreta a informação do cabeçalho em requisições e respostas. Como parte do processo de criação da sessão, os cabeçalhos de requisição e resposta, que permanecem constantes sobre toda a vida da sessão, podem ser trocados entre usuários de serviço no cliente e no servidor. Isto pode incluir tipos de conteúdo aceitáveis, conjunto de caracteres, linguagens, capacidades de dispositivo e outros parâmetros estáticos. O WSP passará através dos cabeçalhos de sessão do cliente e do servidor, assim como pelos cabeçalhos de requisição e resposta, sem adições e remoções.

  O ciclo de vida de uma sessão WSP não é ligado ao transporte. Uma sessão pode ser suspensa enquanto está ociosa para liberar os recursos da rede ou para economizar bateria. Um protocolo de restabelecimento de uma  sessão leve permite à sessão continuar sem sobrecarga do estabelecimento de uma sessão completa. Uma sessão pode recomeçar sobre um transportador de rede diferente.

  O WSP permite estender suas capacidades para negociação entre pontos, o que permite a ambos alto desempenho e uma implementação cheia de recursos, assim como implementações simples, básicas e pequenas. O WSP provê também um mecanismo para anexação de informação de cabeçalho (metadados) para o reconhecimento de uma transação, o que permite à aplicação cliente comunicar informações específicas sobre a transação completada de volta ao servidor. 

O WSP provê transferência push e pull de dados, onde o pull é feito usando o mecanismo de requisição e resposta do HTTP/1.1. Para a transferência push, o WSP fornece três mecanismos de transferência de dados: push de dados confirmada dentro do contexto de uma sessão existente, push de dados não-confirmada dentro do contexto de uma sessão existente e push de dados não-confirmada sem o contexto de uma sessão existente.

  O mecanismo de push confirmado permite ao servidor enviar dados para o cliente a qualquer momento durante a sessão e o servidor recebe a confirmação de que o push foi entregue. O mecanismo de push não-confirmado dentro de uma sessão existente provê uma função similar ao push de dados confiável, mas sem confirmação; já no de push não-confirmado  sem uma sessão existente, o contexto padrão de uma sessão é assumido. Os dados de push não-confirmado podem ser usados para enviar mensagem em um único sentido sobre um transporte não confiável.

Opcionalmente, o protocolo WSP suporta requisições assíncronas, isto é, um cliente pode enviar múltiplas requisições para o servidor simultaneamente, o que melhora a utilização de transmissão, uma vez que estas múltiplas requisições e respostas podem ser combinadas em algumas poucas mensagens.

5.2   Perfil do Agente-Usuário 

O perfil do agente-usuário é preocupado com captura de informações de referências das 
 classes de dispositivos. Estas classes incluem as características de hardware e software do  
 dispositivo, assim como informações sobre a rede na qual este está conectado. O perfil 
 contém também informações usadas para propósitos de formatação de conteúdo. Um perfil de 
 agente usuário é diferente de um perfil de preferências do usuário, pois este contém  informações sobre o usuário específicas para aplicações com propósitos de seleção de  conteúdo. Por exemplo, um perfil de preferências do usuário pode designar que este tem  interesse em receber resultados de determinados esportes e somente de certos times. O  esquema do perfil do agente-usuário é definido usando um vocabulário e um esquema RDF  (Resource Description Framework - Estrutura de Descrição de Recursos). 
O documento  [UAProf]  define detalhadamente a estrutura deste esquema no que diz respeito 
 à definição de classe e semântica de atributos para dispositivos voltado para o padrão WAP.   

5.3 – Protocolo OTA de Push

O PAP (Push Access Protocol - Protocolo de Acesso Push) foi definido para ser usado na entrega de conteúdo de Inicializadores Push ³ aos gateways de proxy push, que são gateways de proxy com capacidade de prover serviços de proxy push, para subseqüente entrega para dispositivos de banda estreita, incluindo telefones celulares e pagers. Alguns exemplos para mensagens de push podem ser notícias, índices de ações, previsão do tempo, informações sobre o tráfego e notificações de eventos como a chegada de e-mail. Com a funcionalidade push, os usuários são capazes de receber informações sem ter que requisitá-las. Apesar de sua clara funcionalidade, o PAP não foi criado para uso direto por dispositivos sem fio e para suprir esta deficiência o WAPForum especificou o Protocolo OTA (Over-The-Air – Sobre o Ar) de Push para entrega de conteúdo a um cliente WAP a partir de um servidor WAP. 

O Protocolo OTA de Push é um protocolo leve que se situa no topo da arquitetura do WSP e é a parte da estrutura push responsável pelo transporte de conteúdo de um PPG (Push Proxy Gateway - Gateway de Proxy Push) para o cliente e seus agentes-usuários. 

O push orientado à conexão requer que a sessão de push seja estabelecida antes que o conteúdo possa ser entregue e esta sessão pode ser compartilhada entre múltiplas aplicações clientes.

  Um servidor é capaz de iniciar uma sessão de push com o cliente usando uma sessão de push sem conexão através de uma porta WDP registrada neste cliente para requisitar a ele que inicialize uma sessão push. Para conseguir a criar a sessão, a inicialização do servidor para sessões de push deve ter um SAI (Session Initiation Application - Aplicação de Inicialização de Sessão). A Figura 12, ilustra a arquitetura push do WAP.

Figura 12: Arquitetura Push do WAP