Introdução
Os três padrões mais comuns são:
Cliente Leve da Web - Usado, na maior parte das vezes, em aplicativos baseados na Internet, nos quais há pouco controle da configuração do cliente. O cliente requer apenas um navegador padrão da Web (com capacidade para formulários). Toda a lógica do negócio é executada no servidor.
Cliente Pesado da Web - Uma parte significativa, em termos de arquitetura, da lógica do negócio é executada no equipamento cliente. Em geral, o cliente utiliza HTML Dinâmico, Applets Java ou controles ActiveX para executar a lógica do negócio. A comunicação com o servidor ainda é feita via HTTP.
Liberação pela Web - Além de usar o protocolo HTTP para a comunicação cliente/servidor, é possível usar outros protocolos, como IIOP e DCOM, para suportar um sistema de objetos distribuídos. O navegador da Web age principalmente como um dispositivo de liberação e recebimento de um sistema de objetos distribuídos.
Essa lista não pode ser considerada completa, especialmente nos setores da indústria em que as revoluções tecnológicas parecem ocorrer a cada ano. Ela representa, em alto nível, os padrões mais comuns de arquitetura de aplicativos da Web. Assim como ocorre com qualquer padrão, é aceitável a aplicação de vários deles a uma única arquitetura.
Os três padrões mais comuns são:
Cliente Leve da Web - Usado, na maior parte das vezes, em aplicativos baseados na Internet, nos quais há pouco controle da configuração do cliente. O cliente requer apenas um navegador padrão da Web (com capacidade para formulários). Toda a lógica do negócio é executada no servidor.
Cliente Pesado da Web - Uma parte significativa, em termos de arquitetura, da lógica do negócio é executada no equipamento cliente. Em geral, o cliente utiliza HTML Dinâmico, Applets Java ou controles ActiveX para executar a lógica do negócio. A comunicação com o servidor ainda é feita via HTTP.
Liberação pela Web - Além de usar o protocolo HTTP para a comunicação cliente/servidor, é possível usar outros protocolos, como IIOP e DCOM, para suportar um sistema de objetos distribuídos. O navegador da Web age principalmente como um dispositivo de liberação e recebimento de um sistema de objetos distribuídos.
Essa lista não pode ser considerada completa, especialmente nos setores da indústria em que as revoluções tecnológicas parecem ocorrer a cada ano. Ela representa, em alto nível, os padrões mais comuns de arquitetura de aplicativos da Web. Assim como ocorre com qualquer padrão, é aceitável a aplicação de vários deles a uma única arquitetura.
Cliente Leve da Web
O padrão de arquitetura Cliente Leve da Web é muito útil para aplicativos baseados na Internet, para os quais pode-se garantir apenas a configuração mínima no cliente. Toda a lógica do negócio é executada no servidor durante o processamento das solicitações de página do navegador cliente.
O padrão de arquitetura Cliente Leve da Web é muito útil para aplicativos baseados na Internet, para os quais pode-se garantir apenas a configuração mínima no cliente. Toda a lógica do negócio é executada no servidor durante o processamento das solicitações de página do navegador cliente.
Aplicabilidade
Esse padrão é mais adequado a aplicativos da Web baseados na Internet ou a ambientes em que o cliente tenha uma capacidade mínima de computação ou não tenha nenhum controle sobre a configuração.
Esse padrão é mais adequado a aplicativos da Web baseados na Internet ou a ambientes em que o cliente tenha uma capacidade mínima de computação ou não tenha nenhum controle sobre a configuração.
Usos Conhecidos
A maioria dos aplicativos de comércio eletrônico para a Internet usa esse padrão, pois não há muito sentido, comercialmente falando, em eliminar qualquer nicho de consumidores simplesmente porque não têm recursos suficientes no cliente. Um aplicativo típico de comércio eletrônico tenta abranger o maior conjunto possível de consumidores, afinal, o dinheiro de um usuário do Commodore Amiga é tão bom quanto o de um usuário do Windows NT.
A maioria dos aplicativos de comércio eletrônico para a Internet usa esse padrão, pois não há muito sentido, comercialmente falando, em eliminar qualquer nicho de consumidores simplesmente porque não têm recursos suficientes no cliente. Um aplicativo típico de comércio eletrônico tenta abranger o maior conjunto possível de consumidores, afinal, o dinheiro de um usuário do Commodore Amiga é tão bom quanto o de um usuário do Windows NT.
Estrutura
Os principais componentes do padrão de arquitetura Cliente Leve da Web estão no servidor. Em muitos aspectos, essa arquitetura representa a arquitetura mínima do aplicativo da Web. Estes são os principais componentes:
Navegador cliente - Qualquer navegador HTML padrão, com capacidade para formulários. O navegador age como um dispositivo genérico da interface de usuário. Quando usado em uma arquitetura Cliente Leve da Web, o único outro serviço que ele fornece é a capacidade de aceitar e retornar cookies. O usuário do aplicativo utiliza o navegador para solicitar páginas da Web: HTML ou servidor. A página retornada contém uma interface de usuário totalmente formatada, com controles de entrada e texto, que é convertida pelo navegador no modo de exibição do cliente. Todas as interações do usuário com o sistema são feitas por meio do navegador.
Servidor da Web - O principal ponto de acesso para todos os navegadores cliente. Os navegadores cliente, na arquitetura Cliente Leve da Web, acessam o sistema somente por meio do servidor da Web, que aceita solicitações de páginas da Web - páginas em HTML estático ou páginas do servidor. Dependendo da solicitação, o servidor da Web pode iniciar algum processamento no próprio servidor. Se a solicitação de página é para um módulo CGI, ISAPI ou NSAPI da página com scripts do servidor, o servidor de Web delegará o processamento ao interpretador de script ou módulo executável apropriado. De qualquer forma, o resultado será uma página em formato HTML, apropriada para ser processada por um navegador HTML.
Conexão HTTP - O protocolo de uso mais comum entre navegadores cliente e servidores da Web. Esse elemento de arquitetura representa um tipo de comunicação sem conexão entre cliente e servidor. Sempre que o cliente ou o servidor enviar informações um para o outro, uma nova conexão separada é estabelecida entre os dois. Uma variação da conexão HTTP é a conexão segura HTTP via Camada de Soquetes de Segurança (SSL). Esse tipo de conexão criptografa as informações que estão sendo transmitidas entre cliente e servidor, usando a tecnologia de criptografia de chave pública/privada.
Página HTML - Página da Web com interface de usuário e informações de conteúdo, que não passa por qualquer processamento no servidor. Essas páginas geralmente contêm texto explicativo como, por exemplo, direções e informações de ajuda, ou formulários HTML de entrada. Quando o servidor da Web recebe uma solicitação de uma página HTML, ele simplesmente recupera o arquivo e o envia para o cliente solicitante, sem filtrá-lo.
Página de servidor - Páginas da Web que passam por alguma forma de processamento no servidor. Em geral, essas páginas são implementadas no servidor como páginas com scripts (Páginas Active Server, Páginas Java Server, páginas Cold Fusion), que são processadas por meio de um filtro no servidor do aplicativo ou de módulos executáveis (ISAPI ou NSAPI). Elas têm possibilidade de acesso a todos os recursos do servidor, incluindo componentes da lógica do negócio, bancos de dados, sistemas legados e sistemas de contabilidade comercial.
Servidor de aplicativo - O principal mecanismo de execução da lógica do negócio, no lado do servidor. O servidor de aplicativo é responsável pela execução do código nas páginas de servidor. Ele pode estar localizado no mesmo equipamento do servidor da Web e também pode ser executado no mesmo espaço de processamento. O servidor de aplicativo é, em termos de lógica, um elemento de arquitetura separado, pois está envolvido somente na execução da lógica do negócio e pode usar uma tecnologia completamente diferente da usada no servidor da Web.
A figura abaixo mostra um diagrama da visão lógica da arquitetura Cliente Leve da Web.
Navegador cliente - Qualquer navegador HTML padrão, com capacidade para formulários. O navegador age como um dispositivo genérico da interface de usuário. Quando usado em uma arquitetura Cliente Leve da Web, o único outro serviço que ele fornece é a capacidade de aceitar e retornar cookies. O usuário do aplicativo utiliza o navegador para solicitar páginas da Web: HTML ou servidor. A página retornada contém uma interface de usuário totalmente formatada, com controles de entrada e texto, que é convertida pelo navegador no modo de exibição do cliente. Todas as interações do usuário com o sistema são feitas por meio do navegador.
Servidor da Web - O principal ponto de acesso para todos os navegadores cliente. Os navegadores cliente, na arquitetura Cliente Leve da Web, acessam o sistema somente por meio do servidor da Web, que aceita solicitações de páginas da Web - páginas em HTML estático ou páginas do servidor. Dependendo da solicitação, o servidor da Web pode iniciar algum processamento no próprio servidor. Se a solicitação de página é para um módulo CGI, ISAPI ou NSAPI da página com scripts do servidor, o servidor de Web delegará o processamento ao interpretador de script ou módulo executável apropriado. De qualquer forma, o resultado será uma página em formato HTML, apropriada para ser processada por um navegador HTML.
Conexão HTTP - O protocolo de uso mais comum entre navegadores cliente e servidores da Web. Esse elemento de arquitetura representa um tipo de comunicação sem conexão entre cliente e servidor. Sempre que o cliente ou o servidor enviar informações um para o outro, uma nova conexão separada é estabelecida entre os dois. Uma variação da conexão HTTP é a conexão segura HTTP via Camada de Soquetes de Segurança (SSL). Esse tipo de conexão criptografa as informações que estão sendo transmitidas entre cliente e servidor, usando a tecnologia de criptografia de chave pública/privada.
Página HTML - Página da Web com interface de usuário e informações de conteúdo, que não passa por qualquer processamento no servidor. Essas páginas geralmente contêm texto explicativo como, por exemplo, direções e informações de ajuda, ou formulários HTML de entrada. Quando o servidor da Web recebe uma solicitação de uma página HTML, ele simplesmente recupera o arquivo e o envia para o cliente solicitante, sem filtrá-lo.
Página de servidor - Páginas da Web que passam por alguma forma de processamento no servidor. Em geral, essas páginas são implementadas no servidor como páginas com scripts (Páginas Active Server, Páginas Java Server, páginas Cold Fusion), que são processadas por meio de um filtro no servidor do aplicativo ou de módulos executáveis (ISAPI ou NSAPI). Elas têm possibilidade de acesso a todos os recursos do servidor, incluindo componentes da lógica do negócio, bancos de dados, sistemas legados e sistemas de contabilidade comercial.
Servidor de aplicativo - O principal mecanismo de execução da lógica do negócio, no lado do servidor. O servidor de aplicativo é responsável pela execução do código nas páginas de servidor. Ele pode estar localizado no mesmo equipamento do servidor da Web e também pode ser executado no mesmo espaço de processamento. O servidor de aplicativo é, em termos de lógica, um elemento de arquitetura separado, pois está envolvido somente na execução da lógica do negócio e pode usar uma tecnologia completamente diferente da usada no servidor da Web.
A figura abaixo mostra um diagrama da visão lógica da arquitetura Cliente Leve da Web.
 |
| Arquitetura Cliente Leve da Web Mínima |
Na arquitetura mínima Cliente Leve da Web estão ausentes alguns componentes opcionais comuns, que são geralmente encontrados em aplicativos da Web; em especial, o banco de dados. A maioria dos aplicativos da Web usa um banco de dados para que os dados do negócio sejam persistentes. Às vezes, o banco de dados também é usado para armazenar as próprias páginas (essa utilização de um banco de dados, porém, representa um outro padrão de arquitetura). Como os aplicativos da Web podem usar várias tecnologias para que os dados do negócio sejam persistentes, o componente de arquitetura é identificado com o termo mais genérico: Persistência. O componente de Persistência também inclui o possível uso de um Monitor de Processamento de Transações (TPM).
O modo mais simples de conectar um banco de dados ao sistema é permitir que os scripts nas páginas do servidor tenham acesso direto ao componente de Persistência. Mesmo esse acesso direto utiliza bibliotecas padrão de acesso de dados - como RDO, ADO, ODBC, JDBC, DBLib etc. - para fazer o trabalho pesado. Nesse caso, as páginas de servidor reconhecem o esquema do banco de dados. Nos sistemas de banco de dados relacional, elas criam e executam as instruções SQL necessárias para obter acesso aos dados. Em aplicativos da Web de menor porte e menos complexos, isso pode ser suficiente. Em sistemas de maior porte e mais robustos, porém, é preferível a utilização de uma camada completa de objetos de negócios.
O componente objeto de negócios encapsula a lógica do negócio. Esse componente é geralmente compilado, sendo executado no servidor de aplicativo. Uma das vantagens de se ter um componente arquitetural objeto de negócios é que outros sistemas cliente/servidor ou da Web podem usar os mesmos componentes para invocar a mesma lógica de negócio. Por exemplo, uma vitrine virtual na Internet pode usar páginas de servidor e o padrão de arquitetura Cliente Leve da Web para todas as atividades relacionadas aos consumidores, porém, a divisão de faturamento pode requerer um acesso aos dados e à lógica do negócio mais sofisticado, preferindo usar um sistema cliente/servidor em vez de um sistema baseado na Web. O sistema da divisão de faturamento pode utilizar os mesmos componentes de negócio no mesmo servidor de aplicativo da vitrine virtual, mas usar seu próprio software cliente mais sofisticado.
Como os bancos de dados relacionais são o tipo mais usado de banco de dados nos principais setores de negócios, um componente adicional de arquitetura geralmente está presente entre o servidor de aplicativo e o banco de dados. Esse componente fornece um serviço de mapeamento entre os objetos e os bancos de dados relacionais. A camada de mapeamento propriamente dita pode ser implementada de várias formas. A abordagem detalhada desse componente está fora do escopo deste documento.
Outras opções normalmente adicionadas a esse padrão de arquitetura são a integração com sistemas legados e, para aplicativos de comércio eletrônico, um sistema de contabilidade comercial. Ambos são acessados por meio de objetos de negócios (ou por meio do servidor de aplicativo, nos sistemas que não possuam um componente formal de objetos de negócios). Os sistemas legados podem representar sistemas de contabilidade ou de programação de produção. O sistema de contabilidade comercial capacita um aplicativo da Web a aceitar e processar pagamentos com cartão de crédito. Há vários sistemas de contabilidade comercial disponíveis para empresas de pequeno porte que queiram participar do mercado on-line. Para empresas de maior porte, esse componente muito provavelmente será uma interface com sistemas já existentes e capacitados para processamento de pedidos com cartão de crédito.
Com esses componentes adicionais implementados, a visão lógica do padrão de arquitetura Cliente Leve da Web fica mais completa. A visão lógica é mostrada na figura abaixo.
O modo mais simples de conectar um banco de dados ao sistema é permitir que os scripts nas páginas do servidor tenham acesso direto ao componente de Persistência. Mesmo esse acesso direto utiliza bibliotecas padrão de acesso de dados - como RDO, ADO, ODBC, JDBC, DBLib etc. - para fazer o trabalho pesado. Nesse caso, as páginas de servidor reconhecem o esquema do banco de dados. Nos sistemas de banco de dados relacional, elas criam e executam as instruções SQL necessárias para obter acesso aos dados. Em aplicativos da Web de menor porte e menos complexos, isso pode ser suficiente. Em sistemas de maior porte e mais robustos, porém, é preferível a utilização de uma camada completa de objetos de negócios.
O componente objeto de negócios encapsula a lógica do negócio. Esse componente é geralmente compilado, sendo executado no servidor de aplicativo. Uma das vantagens de se ter um componente arquitetural objeto de negócios é que outros sistemas cliente/servidor ou da Web podem usar os mesmos componentes para invocar a mesma lógica de negócio. Por exemplo, uma vitrine virtual na Internet pode usar páginas de servidor e o padrão de arquitetura Cliente Leve da Web para todas as atividades relacionadas aos consumidores, porém, a divisão de faturamento pode requerer um acesso aos dados e à lógica do negócio mais sofisticado, preferindo usar um sistema cliente/servidor em vez de um sistema baseado na Web. O sistema da divisão de faturamento pode utilizar os mesmos componentes de negócio no mesmo servidor de aplicativo da vitrine virtual, mas usar seu próprio software cliente mais sofisticado.
Como os bancos de dados relacionais são o tipo mais usado de banco de dados nos principais setores de negócios, um componente adicional de arquitetura geralmente está presente entre o servidor de aplicativo e o banco de dados. Esse componente fornece um serviço de mapeamento entre os objetos e os bancos de dados relacionais. A camada de mapeamento propriamente dita pode ser implementada de várias formas. A abordagem detalhada desse componente está fora do escopo deste documento.
Outras opções normalmente adicionadas a esse padrão de arquitetura são a integração com sistemas legados e, para aplicativos de comércio eletrônico, um sistema de contabilidade comercial. Ambos são acessados por meio de objetos de negócios (ou por meio do servidor de aplicativo, nos sistemas que não possuam um componente formal de objetos de negócios). Os sistemas legados podem representar sistemas de contabilidade ou de programação de produção. O sistema de contabilidade comercial capacita um aplicativo da Web a aceitar e processar pagamentos com cartão de crédito. Há vários sistemas de contabilidade comercial disponíveis para empresas de pequeno porte que queiram participar do mercado on-line. Para empresas de maior porte, esse componente muito provavelmente será uma interface com sistemas já existentes e capacitados para processamento de pedidos com cartão de crédito.
Com esses componentes adicionais implementados, a visão lógica do padrão de arquitetura Cliente Leve da Web fica mais completa. A visão lógica é mostrada na figura abaixo.
 |
| Visão Lógica de Cliente Leve da Web |
Muitos componentes de um servidor de aplicativo da Web também podem ser encontrados em aplicativos não baseados na Web. O design e a arquitetura do componente de back-end de um aplicativo da Web não é diferente do design de qualquer sistema cliente/servidor ou mainframe. Os aplicativos da Web usam os bancos de dados e os monitores de processamento de transações (TPM) pelos mesmos motivos dos outros sistemas. As novas ferramentas e tecnologias Enterprise Java Beans (EJB) e Microsoft Transaction Server (MTS), embora tenham sido lançadas visando os aplicativos da Web, são igualmente adequadas para uso em outras arquiteturas de aplicativos.
A arquitetura e o design dos componentes do servidor de um aplicativo da Web são tratados exatamente como em qualquer sistema cliente/servidor. Como esse padrão de arquitetura está concentrado na Web e os componentes são específicos de aplicativos da Web, uma análise detalhada das possíveis arquiteturas de servidores back-end está fora do escopo desse padrão.
A arquitetura e o design dos componentes do servidor de um aplicativo da Web são tratados exatamente como em qualquer sistema cliente/servidor. Como esse padrão de arquitetura está concentrado na Web e os componentes são específicos de aplicativos da Web, uma análise detalhada das possíveis arquiteturas de servidores back-end está fora do escopo desse padrão.
Dinâmica
O princípio básico da dinâmica desse padrão de arquitetura é que a lógica do negócio é executada apenas em resposta a uma solicitação de página da Web feita pelo cliente. Os clientes usam o sistema quando solicitam páginas do servidor de Web com o protocolo HTTP. Se a página solicitada for um arquivo HTML no sistema de arquivos do servidor de Web, o servidor basicamente localizará e enviará o arquivo de volta ao cliente solicitante.
Se for uma página com scripts, isto é, a página contém código interpretável que precisa ser processado antes que a página possa ser enviada ao cliente, o servidor de Web delegará essa ação ao servidor de aplicativos. O servidor de aplicativos interpreta os scripts na página e, se direcionado, interage com os recursos no servidor - como bancos de dados, serviços de e-mail, sistemas legados, etc. O código do script tem acesso, por meio do aplicativo e do servidor de Web, às informações especiais que acompanham a solicitação da página. Essas informações incluem valores de campo inseridos pelo usuário e parâmetros anexados à solicitação da página. O resultado final é uma página HTML devidamente formatada, em condições adequadas para ser enviada ao cliente.
A página também pode ser um módulo executável, como ISAPI ou DLL NSAPI. Uma DLL ou biblioteca de vínculo dinâmico é uma biblioteca compilada, que pode ser carregada e executada, em tempo de execução, pelo servidor de aplicativo. Assim como nas páginas com scripts, o módulo tem acesso ao mesmo detalhamento sobre a solicitação de página (valores de campo de formulário e parâmetros).
O aspecto-chave do comportamento dinâmico desse padrão é que a lógica do negócio é acionada somente durante o processamento de uma solicitação de página. Depois de completada a solicitação, o resultado é enviado ao cliente solicitante e a conexão entre o cliente e o servidor é terminada. É possível que um processo de negócio subsista depois de realizar a solicitação, mas não é o que normalmente acontece.
O princípio básico da dinâmica desse padrão de arquitetura é que a lógica do negócio é executada apenas em resposta a uma solicitação de página da Web feita pelo cliente. Os clientes usam o sistema quando solicitam páginas do servidor de Web com o protocolo HTTP. Se a página solicitada for um arquivo HTML no sistema de arquivos do servidor de Web, o servidor basicamente localizará e enviará o arquivo de volta ao cliente solicitante.
Se for uma página com scripts, isto é, a página contém código interpretável que precisa ser processado antes que a página possa ser enviada ao cliente, o servidor de Web delegará essa ação ao servidor de aplicativos. O servidor de aplicativos interpreta os scripts na página e, se direcionado, interage com os recursos no servidor - como bancos de dados, serviços de e-mail, sistemas legados, etc. O código do script tem acesso, por meio do aplicativo e do servidor de Web, às informações especiais que acompanham a solicitação da página. Essas informações incluem valores de campo inseridos pelo usuário e parâmetros anexados à solicitação da página. O resultado final é uma página HTML devidamente formatada, em condições adequadas para ser enviada ao cliente.
A página também pode ser um módulo executável, como ISAPI ou DLL NSAPI. Uma DLL ou biblioteca de vínculo dinâmico é uma biblioteca compilada, que pode ser carregada e executada, em tempo de execução, pelo servidor de aplicativo. Assim como nas páginas com scripts, o módulo tem acesso ao mesmo detalhamento sobre a solicitação de página (valores de campo de formulário e parâmetros).
O aspecto-chave do comportamento dinâmico desse padrão é que a lógica do negócio é acionada somente durante o processamento de uma solicitação de página. Depois de completada a solicitação, o resultado é enviado ao cliente solicitante e a conexão entre o cliente e o servidor é terminada. É possível que um processo de negócio subsista depois de realizar a solicitação, mas não é o que normalmente acontece.
Resultados
Esse tipo de arquitetura é mais adequado aos aplicativos, cuja resposta do servidor pode ser concluída em um tempo de resposta aceitável esperado pelo usuário (e no tempo limite permitido pelo navegador cliente). Isso normalmente ocorre em poucos segundos, não mais. Esse padrão de arquitetura poderá não ser o mais apropriado, se for necessário que o aplicativo permita ao usuário iniciar e monitorar um processo de negócio mais demorado. A utilização de tecnologias push pode ser adotada para permitir ao cliente monitorar processos de longa duração. Na maior parte das vezes, as tecnologias push basicamente fazem uso de varredura periódica do servidor.
Outro resultado importante desse padrão de arquitetura é a capacidade limitada para interfaces do usuário sofisticadas. Na medida em que o navegador atua como o mecanismo de liberação de toda a interface do usuário, todos os elementos e controles dessa interface precisam ser disponibilizados pelo navegador. Nos navegadores mais conhecidos e nas especificações HTML, esses elementos estão limitados a uns poucos botões e campos de entrada de texto. Por outro lado, pode-se argumentar que uma interface do usuário extremamente limitada é um fator positivo. As poucas opções da interface do usuário evitam que a equipe de desenvolvimento concentre esforços para produzir interfaces "criativas" e "perfeitas" quando opções mais simples seriam suficientes.
Outro resultado importante desse padrão de arquitetura é a capacidade limitada para interfaces do usuário sofisticadas. Na medida em que o navegador atua como o mecanismo de liberação de toda a interface do usuário, todos os elementos e controles dessa interface precisam ser disponibilizados pelo navegador. Nos navegadores mais conhecidos e nas especificações HTML, esses elementos estão limitados a uns poucos botões e campos de entrada de texto. Por outro lado, pode-se argumentar que uma interface do usuário extremamente limitada é um fator positivo. As poucas opções da interface do usuário evitam que a equipe de desenvolvimento concentre esforços para produzir interfaces "criativas" e "perfeitas" quando opções mais simples seriam suficientes.
Cliente Pesado da Web
O padrão de arquitetura Cliente Pesado da Web amplia o padrão Cliente Leve da Web ao usar scripts e objetos personalizados no cliente como, por exemplo, controles ActiveX e Applets Java. O padrão Cliente Pesado da Web tem esse nome porque o cliente pode realmente executar uma parte da lógica do negócio do sistema e, portanto, torna-se mais que um simples contêiner genérico da interface do usuário.
Aplicabilidade
O padrão de arquitetura Cliente Pesado da Web é mais adequado a aplicativos da Web que possam determinar uma versão de navegador e configuração do cliente, que requeiram uma interface do usuário sofisticada e/ou que possam executar uma parte da lógica do negócio no cliente. Muitas diferenças entre os padrões Cliente Leve da Web e Cliente Pesado da Web estão no papel que o navegador desempenha na execução da lógica de negócio do sistema.
As duas motivações mais fortes para a utilização do Cliente Pesado da Web são: capacidade aprimorada da interface do usuário e execução pelo cliente da lógica do negócio. Uma interface do usuário sofisticada deve ser usada para visualizar e modificar modelos tridimensionais, ou para incluir animações em um gráfico financeiro. Em alguns casos, pode-se usar o controle ActiveX para fazer a comunicação com o equipamento de monitoração do cliente. Por exemplo, um equipamento médico que possa medir a pressão sangüínea, fazer a contagem de açúcar no sangue e medir outros sinais vitais pode ser usado por uma instituição que precise monitorar diariamente pacientes situados em diferentes locais, reduzindo dessa forma a freqüência de visitas pessoais a duas vezes por semana.
Às vezes, a lógica do negócio pode ser executada somente no cliente. Nesse caso, todos os dados necessários para executar o processo devem estar disponíveis no cliente. A lógica pode ser tão simples quanto validar dados inseridos. Pode-se verificar a exatidão das datas ou compará-las com outras datas (por exemplo, a data de nascimento deve ser anterior à data da primeira internação no hospital). Com base nas regras de negócios do sistema, alguns campos do sistema podem ou não estar ativados, dependendo dos valores inseridos.
O padrão de arquitetura Cliente Pesado da Web é mais adequado a aplicativos da Web que possam determinar uma versão de navegador e configuração do cliente, que requeiram uma interface do usuário sofisticada e/ou que possam executar uma parte da lógica do negócio no cliente. Muitas diferenças entre os padrões Cliente Leve da Web e Cliente Pesado da Web estão no papel que o navegador desempenha na execução da lógica de negócio do sistema.
As duas motivações mais fortes para a utilização do Cliente Pesado da Web são: capacidade aprimorada da interface do usuário e execução pelo cliente da lógica do negócio. Uma interface do usuário sofisticada deve ser usada para visualizar e modificar modelos tridimensionais, ou para incluir animações em um gráfico financeiro. Em alguns casos, pode-se usar o controle ActiveX para fazer a comunicação com o equipamento de monitoração do cliente. Por exemplo, um equipamento médico que possa medir a pressão sangüínea, fazer a contagem de açúcar no sangue e medir outros sinais vitais pode ser usado por uma instituição que precise monitorar diariamente pacientes situados em diferentes locais, reduzindo dessa forma a freqüência de visitas pessoais a duas vezes por semana.
Às vezes, a lógica do negócio pode ser executada somente no cliente. Nesse caso, todos os dados necessários para executar o processo devem estar disponíveis no cliente. A lógica pode ser tão simples quanto validar dados inseridos. Pode-se verificar a exatidão das datas ou compará-las com outras datas (por exemplo, a data de nascimento deve ser anterior à data da primeira internação no hospital). Com base nas regras de negócios do sistema, alguns campos do sistema podem ou não estar ativados, dependendo dos valores inseridos.
Usos Conhecidos
Os usos mais óbvios de scripts, applets, controles e plug-ins pelo cliente estão relacionados à Internet, na forma de interfaces aprimoradas do usuário. Os Scripts Java são normalmente usados para alterar a cor ou a imagem de um botão ou item de menu em páginas HTML. Os Applets Java e os controles ActiveX são normalmente usados para criar controles de visualização de árvores hierárquicas sofisticadas.
O controle e o plug-in Shockwave ActiveX compõem um dos componentes mais conhecidos de interface do usuário atualmente em uso na Internet. Ele ativa animações interativas e é usado principalmente para tornar mais interessantes os sites na Internet, adicionando gráficos atrativos. Entretanto, também vem sendo usado para exibir simulações e monitorar eventos esportivos.
O controle de agente da Microsoft é usado por vários sites na Internet para aceitar comandos de voz e executar, no navegador, ações que ajudam o usuário a navegar no site da Web.
Fora da Internet, uma empresa de software médico desenvolveu um aplicativo de Intranet baseado na Web para gerenciar registros de pacientes e faturamento. A interface do usuário baseada na Web usa intensamente scripts cliente para executar validações de dados e ajudar o usuário a navegar no site. Além dos scripts, o aplicativo utiliza vários controles ActiveX para gerenciar conteúdos XML usados como o esquema principal de codificação de informações.
O controle e o plug-in Shockwave ActiveX compõem um dos componentes mais conhecidos de interface do usuário atualmente em uso na Internet. Ele ativa animações interativas e é usado principalmente para tornar mais interessantes os sites na Internet, adicionando gráficos atrativos. Entretanto, também vem sendo usado para exibir simulações e monitorar eventos esportivos.
O controle de agente da Microsoft é usado por vários sites na Internet para aceitar comandos de voz e executar, no navegador, ações que ajudam o usuário a navegar no site da Web.
Fora da Internet, uma empresa de software médico desenvolveu um aplicativo de Intranet baseado na Web para gerenciar registros de pacientes e faturamento. A interface do usuário baseada na Web usa intensamente scripts cliente para executar validações de dados e ajudar o usuário a navegar no site. Além dos scripts, o aplicativo utiliza vários controles ActiveX para gerenciar conteúdos XML usados como o esquema principal de codificação de informações.
Estrutura
Toda a comunicação entre cliente e servidor, assim como ocorre no padrão Cliente Leve da Web, é feita com HTTP. Como o HTTP é um tipo de protocolo "sem conexão", na maior parte do tempo não há uma conexão aberta entre cliente e servidor. O cliente só envia informações durante as solicitações de páginas. Isso significa que os scripts, os controles ActiveX e os Applets Java do cliente estão limitados à interação com objetos somente no cliente.
O padrão Cliente Pesado da Web utiliza determinados recursos do navegador como controles ActiveX e Applets Java para executar a lógica do negócio no cliente. Os controles ActiveX são executáveis binários compilados, cujo download no cliente pode ser feito via HTTP e que podem ser chamados pelo navegador. Como os controles ActiveX são essencialmente objetos COM, eles têm total domínio sobre os recursos do cliente. Podem interagir tanto com o navegador como com o próprio sistema cliente. Por esse motivo, os controles ActiveX, especialmente os da Internet, são normalmente "autenticados" por terceiros confiáveis.
As versões mais recentes dos navegadores HTML mais conhecidos também permitem que o cliente produza scripts. As páginas HTML podem ser incorporadas com scripts escritos em Java Script ou VB Script. Essa capacidade de criação de scripts permite que o próprio navegador execute (ou interprete) o código que pode ser parte da lógica do negócio do sistema. O termo "pode ser" é usado porque é muito comum que os scripts cliente contribuam somente com os aspectos externos da interface do usuário, não fazendo realmente parte da lógica do negócio. Nos dois casos, há elementos potencialmente importantes do ponto de vista da arquitetura (isto é, scripts), incorporados às páginas HTML, que precisam ser expressos como tal.
Na medida em que o padrão Cliente Pesado da Web é realmente uma simples extensão do padrão Cliente Leve da Web, a maioria dos elementos significativos do ponto de vista da arquitetura são os mesmos. Os elementos adicionais apresentados pelo Cliente Pesado da Web são:
Script Cliente - JavaScript ou VB Script incorporado às páginas HTML formatadas. O navegador interpreta o script. O W3C (uma organização de padrões para a Internet) definiu a interface Modelo de Objeto de Documento e HTML que o navegador oferece aos scripts cliente.
Documento XML - Um documento formatado por meio de Linguagem de Marcação Extensível (XML). Os documentos XML representam o conteúdo (os dados) sem formatação da interface do usuário.
Controle ActiveX - Um objeto COM que pode ser referenciado em um script cliente e cujo "download" pode ser feito para o cliente, se necessário. Assim como qualquer objeto COM, ele tem total acesso aos recursos do cliente. Os princípios fundamentais do mecanismo de segurança para proteção dos equipamentos cliente são obtidos por meio de autenticação e assinatura. Pode-se configurar os navegadores de Internet para não aceitar o download de controles ActiveX no cliente ou para avisar ao usuário que isso será feito. Os mecanismos de autenticação e assinatura basicamente determinam a identidade do autor do controle por meio de terceiros confiáveis.
Applet Java - Componente independente e compilado, que é executado no contexto de um navegador. Por motivos de segurança, ele tem acesso limitado aos recursos no lado do cliente. Os Applets Java são usados como elementos sofisticados da interface do usuário e também para finalidades não referentes à interface do usuário como, por exemplo, análise de documentos XML ou encapsulamento de lógica de negócio complexa.
Java Bean - Componente Java que implementa um determinado conjunto de interfaces, permitindo que seja facilmente incorporado a sistemas mais complexos e de maior porte. O termo bean (grão) reflete a natureza simples e a finalidade única que o componente deve ter. Uma xícara cheia de café geralmente requer mais de um grão. O ActiveX, nas arquiteturas centralizadas da Microsoft, é análogo ao Java Bean.
A figura abaixo mostra um diagrama da Visão Lógica da Arquitetura Cliente Pesado da Web.
Toda a comunicação entre cliente e servidor, assim como ocorre no padrão Cliente Leve da Web, é feita com HTTP. Como o HTTP é um tipo de protocolo "sem conexão", na maior parte do tempo não há uma conexão aberta entre cliente e servidor. O cliente só envia informações durante as solicitações de páginas. Isso significa que os scripts, os controles ActiveX e os Applets Java do cliente estão limitados à interação com objetos somente no cliente.
O padrão Cliente Pesado da Web utiliza determinados recursos do navegador como controles ActiveX e Applets Java para executar a lógica do negócio no cliente. Os controles ActiveX são executáveis binários compilados, cujo download no cliente pode ser feito via HTTP e que podem ser chamados pelo navegador. Como os controles ActiveX são essencialmente objetos COM, eles têm total domínio sobre os recursos do cliente. Podem interagir tanto com o navegador como com o próprio sistema cliente. Por esse motivo, os controles ActiveX, especialmente os da Internet, são normalmente "autenticados" por terceiros confiáveis.
As versões mais recentes dos navegadores HTML mais conhecidos também permitem que o cliente produza scripts. As páginas HTML podem ser incorporadas com scripts escritos em Java Script ou VB Script. Essa capacidade de criação de scripts permite que o próprio navegador execute (ou interprete) o código que pode ser parte da lógica do negócio do sistema. O termo "pode ser" é usado porque é muito comum que os scripts cliente contribuam somente com os aspectos externos da interface do usuário, não fazendo realmente parte da lógica do negócio. Nos dois casos, há elementos potencialmente importantes do ponto de vista da arquitetura (isto é, scripts), incorporados às páginas HTML, que precisam ser expressos como tal.
Na medida em que o padrão Cliente Pesado da Web é realmente uma simples extensão do padrão Cliente Leve da Web, a maioria dos elementos significativos do ponto de vista da arquitetura são os mesmos. Os elementos adicionais apresentados pelo Cliente Pesado da Web são:
Script Cliente - JavaScript ou VB Script incorporado às páginas HTML formatadas. O navegador interpreta o script. O W3C (uma organização de padrões para a Internet) definiu a interface Modelo de Objeto de Documento e HTML que o navegador oferece aos scripts cliente.
Documento XML - Um documento formatado por meio de Linguagem de Marcação Extensível (XML). Os documentos XML representam o conteúdo (os dados) sem formatação da interface do usuário.
Controle ActiveX - Um objeto COM que pode ser referenciado em um script cliente e cujo "download" pode ser feito para o cliente, se necessário. Assim como qualquer objeto COM, ele tem total acesso aos recursos do cliente. Os princípios fundamentais do mecanismo de segurança para proteção dos equipamentos cliente são obtidos por meio de autenticação e assinatura. Pode-se configurar os navegadores de Internet para não aceitar o download de controles ActiveX no cliente ou para avisar ao usuário que isso será feito. Os mecanismos de autenticação e assinatura basicamente determinam a identidade do autor do controle por meio de terceiros confiáveis.
Applet Java - Componente independente e compilado, que é executado no contexto de um navegador. Por motivos de segurança, ele tem acesso limitado aos recursos no lado do cliente. Os Applets Java são usados como elementos sofisticados da interface do usuário e também para finalidades não referentes à interface do usuário como, por exemplo, análise de documentos XML ou encapsulamento de lógica de negócio complexa.
Java Bean - Componente Java que implementa um determinado conjunto de interfaces, permitindo que seja facilmente incorporado a sistemas mais complexos e de maior porte. O termo bean (grão) reflete a natureza simples e a finalidade única que o componente deve ter. Uma xícara cheia de café geralmente requer mais de um grão. O ActiveX, nas arquiteturas centralizadas da Microsoft, é análogo ao Java Bean.
A figura abaixo mostra um diagrama da Visão Lógica da Arquitetura Cliente Pesado da Web.
 |
| Visão Lógica do Padrão de Arquitetura Cliente Pesado da Web |
Dinâmica
A principal dinâmica do padrão Cliente Pesado da Web inclui o padrão Cliente Leve da Web, mais a capacidade de executar a lógica do negócio no cliente. Assim como acontece no padrão Cliente Leve da Web, toda a comunicação entre cliente e servidor é feita durante as solicitações de páginas. A lógica do negócio, porém, pode ser parcialmente executada no cliente, por meio de scripts, controles ou applets.
Quando uma página é enviada para um navegador cliente, ela pode conter scripts, controles e applets. Elas podem ser usadas simplesmente para aprimorar a interface do usuário ou para contribuir com a lógica do negócio. A utilização mais simples da lógica do negócio está relacionada às validações de campo. É possível usar os scripts cliente para validar as entradas, não apenas em um único campo, mas também em todos os campos de uma determinada página da Web. Por exemplo, um aplicativo de comércio eletrônico que permita aos usuários configurar seus próprios sistemas de computador pode usar scripts para evitar a especificação de opções incompatíveis.
Para que os Applets Java e os controles ActiveX possam ser usados, é necessário especificá-los no conteúdo da página HTML. Esses controles e applets podem funcionar independentemente de qualquer script na página, ou podem ser controlados por scripts na página. Os scripts em uma página HTML podem responder a eventos especiais enviados pelo navegador. Esses eventos podem indicar que o navegador acabou de concluir o carregamento da página da Web ou que o mouse do usuário acabou de ser movido sobre uma região específica da página.
Eles tem acesso à interface Modelo de Objeto de Documento (DOM). Essa interface é um padrão W3C que dá aos scripts, controles e applets acesso ao navegador e ao conteúdo HTML das páginas. A implementação da Microsoft e do Netscape quanto a esse modelo é o HTML Dinâmico (DHTML). O DHTML é mais que uma simples implementação da interface DOM. Ele inclui eventos que não faziam parte da especificação de Nível 1 do DOM no momento em que este documento estava sendo elaborado.
O núcleo do Modelo de Objeto de Documento é um conjunto de interfaces que manipula especificamente os documentos XML. XML é uma linguagem flexível, que permite que os designers criem suas próprias marcas para fins especiais. A interface DOM permite que os scripts cliente acessem documentos XML.
O uso de componentes especiais no cliente possibilita a utilização de XML como um mecanismo padrão de troca de informações entre cliente e servidor. Os controles ActiveX ou os Applets Java podem ser implementados no cliente para solicitar e enviar, de modo independente, documentos XML. Por exemplo, um Applet Java incorporado a uma página HTML pode fazer uma solicitação HTTP de um documento XML do servidor de Web. O servidor de Web localiza e processa as informações solicitadas e envia um documento formatado em XML, e não um documento HTML. O Applet ainda em execução na página HTML, no lado do cliente, aceita o documento XML, analisa-o e interage com o documento HTML atualmente no navegador, a fim de exibir o seu conteúdo para o usuário. Toda a seqüência ocorre no contexto de uma única página HTML no navegador cliente.
A principal dinâmica do padrão Cliente Pesado da Web inclui o padrão Cliente Leve da Web, mais a capacidade de executar a lógica do negócio no cliente. Assim como acontece no padrão Cliente Leve da Web, toda a comunicação entre cliente e servidor é feita durante as solicitações de páginas. A lógica do negócio, porém, pode ser parcialmente executada no cliente, por meio de scripts, controles ou applets.
Quando uma página é enviada para um navegador cliente, ela pode conter scripts, controles e applets. Elas podem ser usadas simplesmente para aprimorar a interface do usuário ou para contribuir com a lógica do negócio. A utilização mais simples da lógica do negócio está relacionada às validações de campo. É possível usar os scripts cliente para validar as entradas, não apenas em um único campo, mas também em todos os campos de uma determinada página da Web. Por exemplo, um aplicativo de comércio eletrônico que permita aos usuários configurar seus próprios sistemas de computador pode usar scripts para evitar a especificação de opções incompatíveis.
Para que os Applets Java e os controles ActiveX possam ser usados, é necessário especificá-los no conteúdo da página HTML. Esses controles e applets podem funcionar independentemente de qualquer script na página, ou podem ser controlados por scripts na página. Os scripts em uma página HTML podem responder a eventos especiais enviados pelo navegador. Esses eventos podem indicar que o navegador acabou de concluir o carregamento da página da Web ou que o mouse do usuário acabou de ser movido sobre uma região específica da página.
Eles tem acesso à interface Modelo de Objeto de Documento (DOM). Essa interface é um padrão W3C que dá aos scripts, controles e applets acesso ao navegador e ao conteúdo HTML das páginas. A implementação da Microsoft e do Netscape quanto a esse modelo é o HTML Dinâmico (DHTML). O DHTML é mais que uma simples implementação da interface DOM. Ele inclui eventos que não faziam parte da especificação de Nível 1 do DOM no momento em que este documento estava sendo elaborado.
O núcleo do Modelo de Objeto de Documento é um conjunto de interfaces que manipula especificamente os documentos XML. XML é uma linguagem flexível, que permite que os designers criem suas próprias marcas para fins especiais. A interface DOM permite que os scripts cliente acessem documentos XML.
O uso de componentes especiais no cliente possibilita a utilização de XML como um mecanismo padrão de troca de informações entre cliente e servidor. Os controles ActiveX ou os Applets Java podem ser implementados no cliente para solicitar e enviar, de modo independente, documentos XML. Por exemplo, um Applet Java incorporado a uma página HTML pode fazer uma solicitação HTTP de um documento XML do servidor de Web. O servidor de Web localiza e processa as informações solicitadas e envia um documento formatado em XML, e não um documento HTML. O Applet ainda em execução na página HTML, no lado do cliente, aceita o documento XML, analisa-o e interage com o documento HTML atualmente no navegador, a fim de exibir o seu conteúdo para o usuário. Toda a seqüência ocorre no contexto de uma única página HTML no navegador cliente.
Resultados
Sem dúvida, o melhor resultado desse padrão é a portabilidade entre as implementações de navegadores. Nem todos os navegadores HTML suportam Java Script ou VB Script. Além disso, somente o Microsoft Windows baseado em clientes pode usar controles ActiveX. Mesmo quando uma marca específica de navegador cliente é usada com exclusividade, existem diferenças sutis nas implementações do Modelo de Objeto de Documento.
Quando scripts, controles ou applets são usados no lado do cliente, a equipe de teste precisa executar todo o conjunto de cenários de teste para cada configuração cliente suportada. Depois que a lógica crítica do negócio estiver em execução no cliente, é importante que ela se comporte consistente e corretamente em todos os navegadores envolvidos. Jamais suponha que todos os navegadores se comportam da mesma forma. Não só é possível que diferentes navegadores se comportem de modo diferente com o mesmo código-fonte, como também é possível que o mesmo navegador, quando executado em diferentes sistemas operacionais, possa apresentar um comportamento anômalo.
Quando scripts, controles ou applets são usados no lado do cliente, a equipe de teste precisa executar todo o conjunto de cenários de teste para cada configuração cliente suportada. Depois que a lógica crítica do negócio estiver em execução no cliente, é importante que ela se comporte consistente e corretamente em todos os navegadores envolvidos. Jamais suponha que todos os navegadores se comportam da mesma forma. Não só é possível que diferentes navegadores se comportem de modo diferente com o mesmo código-fonte, como também é possível que o mesmo navegador, quando executado em diferentes sistemas operacionais, possa apresentar um comportamento anômalo.
Liberação pela Web
O padrão de arquitetura Liberação pela Web é assim denominado porque a Web é usada principalmente como mecanismo de liberação para um sistema tradicional cliente/servidor de objetos distribuídos. De certa forma, esse tipo de aplicativo é realmente um aplicativo cliente/servidor de objetos distribuídos que inclui um servidor da Web e um navegador cliente como elementos significativos da arquitetura. Seja esse sistema um aplicativo de Web com objetos distribuídos ou um sistema de objetos distribuídos com elementos da Web, o sistema final será o mesmo. O fato de o mesmo sistema poder ter essas duas abordagens e de que sistemas de objetos distribuídos sempre terem sido vistos como sistemas que requerem uma modelagem cuidadosa enfatizam o tema deste documento-de que aplicativos da Web precisam ser modelados e criados como qualquer outro sistema de software.
Aplicabilidade
O padrão de arquitetura Liberação pela Web é mais apropriado para as situações em que exista um controle significativo sobre as configurações do cliente e da rede. Este padrão não é particularmente adequado para aplicativos baseados na Internet, nos quais não há nenhum ou há pouco controle das configurações do cliente, ou quando as comunicações de rede não são confiáveis.
O ponto forte dessa arquitetura é a sua capacidade de aproveitar objetos de negócios existentes no contexto de um aplicativo da Web. Na medida em que há possibilidade de comunicação direta e persistente entre cliente e servidor, as limitações dos dois padrões anteriores de aplicativos da Web podem ser superadas. O cliente pode aproveitar para executar uma parte significativa da lógica de negócio, em um grau ainda mais alto.
É bastante improvável que esse padrão de arquitetura seja usado isoladamente. De uma perspectiva mais realista, esse padrão deve ser combinado com um ou com os dois padrões anteriores. O sistema típico deve utilizar um ou os dois primeiros padrões de arquitetura para aquelas partes do sistema que não requerem uma interface do usuário sofisticada, ou quando as configurações do cliente não forem suficientes para suportar um aplicativo cliente de grande porte.
O padrão de arquitetura Liberação pela Web é mais apropriado para as situações em que exista um controle significativo sobre as configurações do cliente e da rede. Este padrão não é particularmente adequado para aplicativos baseados na Internet, nos quais não há nenhum ou há pouco controle das configurações do cliente, ou quando as comunicações de rede não são confiáveis.
O ponto forte dessa arquitetura é a sua capacidade de aproveitar objetos de negócios existentes no contexto de um aplicativo da Web. Na medida em que há possibilidade de comunicação direta e persistente entre cliente e servidor, as limitações dos dois padrões anteriores de aplicativos da Web podem ser superadas. O cliente pode aproveitar para executar uma parte significativa da lógica de negócio, em um grau ainda mais alto.
É bastante improvável que esse padrão de arquitetura seja usado isoladamente. De uma perspectiva mais realista, esse padrão deve ser combinado com um ou com os dois padrões anteriores. O sistema típico deve utilizar um ou os dois primeiros padrões de arquitetura para aquelas partes do sistema que não requerem uma interface do usuário sofisticada, ou quando as configurações do cliente não forem suficientes para suportar um aplicativo cliente de grande porte.
Usos Conhecidos
O site CNN Interactive na Web é um dos sites de notícias mais ocupados da rede. A maior parte do acesso público é feita por meio de navegadores convencionais e HTML 3.2 normal; entretanto, por trás do site da Web, há uma rede sofisticada baseada em CORBA de navegadores, servidores e objetos distribuídos. Uma análise desse sistema foi publicada com o título Distributed Computing.
Uma empresa de software médico criou um aplicativo de Web para gerenciar pacientes, registros médicos e faturamento. Os aspectos do sistema relacionados ao faturamento são usados apenas por uma parcela significativamente pequena da comunidade global de usuários. Muitos dos sistemas de faturamento de legado foram escritos em FoxPro. O novo sistema baseado na Web aproveitou o antigo código legado do FoxPro e, com o uso de alguns utilitários de conversão, criou documentos ActiveX para a interface do usuário e para a lógica do negócio. O sistema resultante é um Cliente Pesado da Web, que se baseia em aplicativo da Web para registros médicos e de pacientes, integrado ao padrão Liberação pela Web, que se baseia no aplicativo da Web para operações de faturamento.
Uma empresa de software médico criou um aplicativo de Web para gerenciar pacientes, registros médicos e faturamento. Os aspectos do sistema relacionados ao faturamento são usados apenas por uma parcela significativamente pequena da comunidade global de usuários. Muitos dos sistemas de faturamento de legado foram escritos em FoxPro. O novo sistema baseado na Web aproveitou o antigo código legado do FoxPro e, com o uso de alguns utilitários de conversão, criou documentos ActiveX para a interface do usuário e para a lógica do negócio. O sistema resultante é um Cliente Pesado da Web, que se baseia em aplicativo da Web para registros médicos e de pacientes, integrado ao padrão Liberação pela Web, que se baseia no aplicativo da Web para operações de faturamento.
Estrutura
A diferença mais importante entre Liberação pela Web e outros padrões de arquitetura de aplicativos da Web está no método de comunicação entre cliente e servidor. Nos outros padrões, o principal mecanismo era o HTTP, um protocolo sem conexão que limita muito o designer no que se refere às atividades interativas entre usuário e servidor. Os elementos de arquitetura mais importantes no padrão Liberação pela Web incluem todos aqueles especificados no padrão Cliente Leve da Web mais estes:
DCOM - Distributed COM é um protocolo Microsoft de objetos distribuídos. Ele permite que objetos em uma máquina interajam e invoquem métodos em objetos de outra máquina.
IIOP - Internet Inter-Orb Protocol é um protocolo CORBA da OMG para interação com objetos distribuídos pela Internet (ou qualquer rede baseada em TCP/IP).
RMI (JRMP) - A Invocação Remota de Método (RMI) é um modo Java de interação com objetos em outros equipamentos. JRMP (Java Remote Method Protocol, Protocolo de Método Remoto Java) é o protocolo nativo da RMI, mas não é necessariamente o único protocolo que pode ser usado. A RMI pode ser implementada com o IIOP do CORBA.
A figura abaixo mostra um diagrama da Visão Lógica do padrão de Arquitetura Liberação pela Web.
DCOM - Distributed COM é um protocolo Microsoft de objetos distribuídos. Ele permite que objetos em uma máquina interajam e invoquem métodos em objetos de outra máquina.
IIOP - Internet Inter-Orb Protocol é um protocolo CORBA da OMG para interação com objetos distribuídos pela Internet (ou qualquer rede baseada em TCP/IP).
RMI (JRMP) - A Invocação Remota de Método (RMI) é um modo Java de interação com objetos em outros equipamentos. JRMP (Java Remote Method Protocol, Protocolo de Método Remoto Java) é o protocolo nativo da RMI, mas não é necessariamente o único protocolo que pode ser usado. A RMI pode ser implementada com o IIOP do CORBA.
A figura abaixo mostra um diagrama da Visão Lógica do padrão de Arquitetura Liberação pela Web.
 |
| Visão Lógica do Padrão de Arquitetura Liberação pela Web |
Dinâmica
A principal dinâmica do padrão de arquitetura Liberação pela Web é a utilização do navegador para fornecer um sistema de objetos distribuídos. Usa-se o navegador para conter uma interface do usuário e alguns objetos de negócios que, independentemente do navegador, se comunicam com objetos na camada do servidor. A comunicação entre objetos do cliente e do servidor ocorre com os protocolos IIOP, RMI e DCOM.
A principal vantagem de usar um navegador da Web em um sistema cliente/servidor de objetos distribuídos é que o navegador tem alguns recursos internos para fazer automaticamente o download dos componentes necessários do servidor. Uma nova marca de computador na rede só precisará de um navegador da Web compatível para passar a usar o aplicativo. Um software especial não precisará ser manualmente instalado no cliente, pois o navegador gerenciará essa tarefa para o usuário. Os componentes são liberados e instalados no cliente de acordo com a necessidade. Os Applets Java e os controles ActiveX podem ser automaticamente enviados e armazenados na memória cache do cliente. Quando esses componentes são ativados (como resultado do carregamento da página apropriada da Web), eles podem se ligar por comunicação assíncrona com os objetos do servidor.
A principal dinâmica do padrão de arquitetura Liberação pela Web é a utilização do navegador para fornecer um sistema de objetos distribuídos. Usa-se o navegador para conter uma interface do usuário e alguns objetos de negócios que, independentemente do navegador, se comunicam com objetos na camada do servidor. A comunicação entre objetos do cliente e do servidor ocorre com os protocolos IIOP, RMI e DCOM.
A principal vantagem de usar um navegador da Web em um sistema cliente/servidor de objetos distribuídos é que o navegador tem alguns recursos internos para fazer automaticamente o download dos componentes necessários do servidor. Uma nova marca de computador na rede só precisará de um navegador da Web compatível para passar a usar o aplicativo. Um software especial não precisará ser manualmente instalado no cliente, pois o navegador gerenciará essa tarefa para o usuário. Os componentes são liberados e instalados no cliente de acordo com a necessidade. Os Applets Java e os controles ActiveX podem ser automaticamente enviados e armazenados na memória cache do cliente. Quando esses componentes são ativados (como resultado do carregamento da página apropriada da Web), eles podem se ligar por comunicação assíncrona com os objetos do servidor.
Resultados
Sem dúvida, o melhor resultado desse padrão é a portabilidade entre as implementações de navegadores. O uso desse padrão requer uma rede segura. As conexões entre objetos do cliente e do servidor duram muito mais que as conexões HTTP e, assim, as perdas esporádicas de servidor, que não são um problema nas outras duas arquiteturas, se transformam em um problema sério nesse padrão.
Sem dúvida, o melhor resultado desse padrão é a portabilidade entre as implementações de navegadores. O uso desse padrão requer uma rede segura. As conexões entre objetos do cliente e do servidor duram muito mais que as conexões HTTP e, assim, as perdas esporádicas de servidor, que não são um problema nas outras duas arquiteturas, se transformam em um problema sério nesse padrão.
0 comentários:
Postar um comentário