A maior parte das aplicações centradas em dados acessam o banco de dados diretamente usando um modelo cliente-servidor (2-tier) (veja figura 1). Conectando diretamente ao banco de dados provê performance suficiente quando o número de clientes é limitado e aqueles clientes podem acessar o banco de dados numa rede local. Entretanto, quando o número de clientes dentro de uma aplicação aumenta ou os clientes requerem acesso aos dados fora da rede local, o problema surge em achar o melhor método de conexão aos dados sem reescrever a aplicação.

Figura 1: Arquitetura básica de cliente-servidor.


O Enterprise Server do StrataFrame provê para que o método de conexão aos dados possa ser facilmente implementado numa aplicação StrataFrame existente sem mudança de código de programação, provê acesso remoto ao banco de dados através de HTTP, e aumenta a escalabilidade da aplicação reduzindo a carga sobre o servidor de dados.

O Enterprise Server é um site de web armazenado dentro o IIS da Microsoft® que pode ser consumido como uma fonte de dados pela aplicação StrataFrame (veja figura 2). Clientes conectam ao Enterprise Server usando HTTP e o Enterprise Server intermedia seus pedidos ao servidor do banco de dados. O Enterprise Server permite aos clientes acesso aos dados dentro do banco de dados através de uma rede remota usando protocolo HTTP, e usa encriptação e compressão para melhorar a segurança e desempenho aos clientes remotos.


Figura 2: Arquitetura 3-tier com o Enterprise Server.

Aglomerador de Conexões

O Enterprise Server (ou Enterprise Servers numa fazenda de servidores) provê uma localização centralizada para aglomerar conexões ao servidor de banco de dados. Uma das grandes perdas em recursos de servidores é a manutenção de conexões. Mesmo com .NET aglomerando conexões, se clientes têm permissões para conectar diretamente ao banco de dados, cada cliente irá abrir várias conexões e cada conexão requer recusos significantes do servidor do banco de dados para serem mantidos (veja figura 3).

Figura 3: Conexões quando grupamento de conexões é somente disponível dentro de cada cliente.


Quando o Enterprise Server é incorporado, ele se torna o "único" cliente do servidor do banco de dados (o único computador que abre conexões no banco de dados) (veja figura 4). Isto permite que o ES agrupe as conexões de todos os computadores de clientes e altamente reduz a necessidade de recursos do servidor do banco de dados. O banco de dados pode usar mais de seus recursos para rodar "queries" e servir dados em vez de manter conexões de clientes.

Figura 4: Conexões quando os clientes conectam ao Enterprise Server e o agrupamento de conexões é centralizado.


Esta funcionalidade é a maior contribuidora para incrementar a escalabilidade da aplicação, que é conseguida através do uso do Enterprise Server. Enterprise Servers adicionais podem ser adicionados para lidar com conexões de clientes sem aumentar demais o número de conexões ao banco de dados.

Encriptação

O Enterprise Server usa o algorítimo 3DES simétrico para encriptar todos os dados que são transferidos entre os computadores clientes e o Enterprise Server. 3DES é um método universalmente aceito para encriptar dados de missões críticas e é usado comumente por conexões VPN seguras.

Compressão

O Entrerprise Server pode opcionalmente comprimir todos os dados que transitam entre o Enterprise Server e os computadores clientes. Compressão pode reduzir o tamanho do tráfego entre os computadores clientes e o Enterprise Server por volta de 80%. O custo de recursos de CPU para compressão são mínimos, e quando o cliente conecta ao Enterprise Server usando uma conexão de baixa banda a performance é grandemente melhorada por comprimir as comunicações.

Intercambialidade

Uma aplicação StrataFrame usa uma classe de fonte de dados transparente para acessar os dados. A mesma metodologia é usada pelo Enterprise Server; uma fonte de dados específica do Enterprise Server substitui a fonte de dados específica do SQL Server(ou outro banco de dados) dentro da aplicação do cliente (veja figura 5). Estas fontes de dados são transparentes para o nível superior da aplicação, e pode ser trocada em tempo de execução.

Figura 5: A fonte de dados do SQL é substituida por uma fonte de dados do Enterprise Server para permitir ao cliente se conectar ao Enterprise Server.


Esta funcionalidade permite à aplicação a ser escrita para uso com ambos o Enterprise Server ou conexão direta ao banco de dados. Quando uma aplicação é executada na rede local, conectar diretamente ao banco de dados pode ser mais eficiente; entretanto, quando a aplicação é executada de uma rede remota ou na internet, pode então usar o Enterprise Server para acessar o mesmo banco de dados.

Em fato, quando se foi testar o Enterprise Server, nenhuma unidade de testes nova foi desenvolvida, o mesmo teste usado para testar conectividade ao SQL Server foi também usado para testar a conectividade ao Enterprise Server simplesmente mudando a fonte de dados.

Suporte à fazenda de Servidores

O Enterprise Server pode ser instalado em ambientes de único-servidor e também de múltiplos-servidores. Um ambiente de múltiplos-servidores aumenta a escalabilidade de uma aplicação por distribuir a carga sobre o Enterprise Server através de múltiplos computadores. Qualquer método de balanceamento de carga entre os Enterprise Servers pode ser usado, tais como Microsoft® Network Load Balancing (NLB) ou um sistema de requisição de hardware.

Suporte completa a Transações

Transações são completamente funcionais quando se usa um Enterprise Server para prover acesso ao banco de dados, mesmo quando usando vários Enterprise Servers em um ambiente multi-usuário. Cada um dos Enterprise Servers numa fazenda tem conhecimento dos outros servidores. Uma transação é mantida por um único Enterprise Server, e se um Enterprise Server recebe uma requisição de transação para uma transação em outro Enterprise Server, ele transparentemente encaminhará a requisição para o servidor apropriado para que seja processada. (veja figura 6-8).

Figura 6: O cliente envia uma requisição de Início de Transação para o Enterprise Server o qual é enviado ao ES #2 pelo balanceador de carga.


Figura 7: O cliente envia um pedido de Salvar o Registro na Transação para os Enterprise Servers, o qual é enviado ao ES #1 pelo balanceador de carga. O ES #1 não é o proprietário da transação, então a requisição é encaminhada para o ES #2 para que o registro seja salvo na transção.


Figura 8: O cliente envia uma requisição de "Commit" para a Transação para os Enterprise Servers, o qual é enviado ao ES #3 pelo balanceador de carga. O ES #3 não é o proprietário da transação, então a requisição é encaminhada para o ES #2 para que o Commit seja feito na transção.

Pequena mudança de código no lado do cliente (1-6 linhas)

Qualquer aplicação StrataFrame existente pode desfrutar do uso do Enterprise Server por simplismente mudar a fonte de dados (1-6 linhas de código) dentro da aplicação cliente.

Instalação fornecida para o web site do Enterprise Server

Uma instalação separada pode ser baixada para instalar o web site do Enterprise Server dentro do IIS. A instalação permite que o Enterprise Server seja rapidamente e eficientemente instalado e configurado de maneira otimizada no computador servidor.

Aplicações existentes podem ser facilmente adaptadas ao uso do ES

Já que a fonte de dados no lado do cliente do Enterprise Server é intercambiável com todas as outras fontes de dados do StrataFrame, uma aplicação existente escrita para conectar diretamente ao servidor do banco de dados pode ser adaptada para usar o Enterprise Server em minutos usando de 1-6 linhas de código requerido para mudar a fonte de dados.

O Enterprise Server não usa serialização .NET, .NET "remoting", ou "web services". Estas 3 tecnológicas são desenhadas para ser altamente configuráveis, flexíveis, e interoperabilidade; entretanto, a flexibilidade alcançada em usar uma ou mais das tecnologias vem com uma significante perda em performance quando usada no lugar de uma solução customizada. Desenvolver o Enterprise Server teria sido mais fácil se tivéssemos usado uma ou mais destas tecnologias, mas o gasto maior em tempo de desenvolvimento valeu a pena pela performance adquirida.

ES versus Serialização .NET

Por desenvolver o Enterprise Server para trabalhar unicamente com aplicações StrataFrame, nós fomos capazes de ajustar as comunicações de rede. Enquanto um objeto serializado do .NET irá conter uma significante quantidade de meta-dados usados pelo deserializador para reconstruir um gráfico do objeto, o descritor do Enterprise Server contém um identificador de 1 byte que é usado para instuir o ponto final remoto de como reconstruir o objeto pela sequência da rede. Por não usar serialização .NET, o tráfego de rede requerido pode ser reduzido em até 40%.

ES versus .NET "Remoting"

O Enterprise Server usa um modelo completamente desconectado para acesso a dados. Depois que há uma requisição de dados de um cliente ao servidor e os dados são juntados e retornados, a conexão entre o cliente e o servidor pode ser desconectada com nenhum efeito colateral. Quando se usa .NET Remoting, o objeto remoto existe na aplicação do servidor e um manipulador HTTP é usado pelo cliente para acessar o objeto remoto. Isto requer uma conexão persistente entre a aplicação do servdor e a aplicação do cliente desde que qualquer e todo acesso a um método ou propriedade do objeto remoto requer uma chamada separada de HTTP do cliente para o servidor.

Ao usar .NET Remoting em banda de conexão limitada ou instável, pode-se causar uma aplicação a se tornar instável; se a conexão cai, todos os objetos remotos se perdem. Em não usar .NET Remoting, o Enterprise Server ganha um grande estabilidade quando ao se trabalhar com clientes que tem banda de conexão limitada ou instável desde que a persistência da conexão não é necessária.

ES versus Web Services

Web Services são desenhados para ser altamente iteroperativo para que eles possam consumir numerosos sistemas diferentes. Como com serialização .NET, todo requisição objeto de requisição e resposta do web service contém um grande número de meta-dados, geralmente no forma de formatação de tags XML do SOAP. Estas tags podem ser mais que o dobro do tamanho de ambos objetos de requisição e resposta. Com o Enterprise Server, este XML adicional não é necessário já que ambas extremidades sabem como codificar e decodificar as requisições e respostas.

HTTP versus HTTPS (SSL)

O Enterprise Server é desenhado para trabalhar com o protocolo HTTP. Enquanto a conexão entre o Enterprise Server e a fonte de dados no lado do cliente podem ser configurada para usar HTTPS, ele roda mais eficientemente e tão seguro quanto em HTTP.

O Enterprise Server usa algoritmo de encriptação 3DES simétrico para encriptar todo o tráfego entre ele mesmo e as fontes de dados dos clientes. Algoritmos de encriptação simétrica tem melhor performance de encriptação do que algoritmos assimétricos tais como SSL, o que faz com que algoritmos simétricos tais como 3DES e AES sejam usados por VPNs. O Enterprise Server ganha mais poder de processamento usando 3DES/HTTP do que SSL/HTTPS.

Algoritmos simétricos requerem uma chave pré-compartilhada que deve ser configurada manualmente em ambos os lados da conexão. Isto aumenta a segurança já que cria uma "senha" de sistema que é necessária para acessar o Enterprise Server. Cada fonte de dados manuzeada pelo Enterprise Server pode ter sua própria chave de encriptação.

Clientes Inteligentes requerendo acesso remoto

Nesta era de computação móvel, muito frequentemente, sistemas são desenhados para serem usados em ambas redes locais e remotas. Usando o Enterprise Server, uma aplicação StrataFrame instalada num laptop pode acessar dados quando está conectada numa rede locar e acessar ao mesmo tempo dados de uma rede remota através da Internet sem requerer recompilação, somente uma mudança de configuração.

O Enterprise Server permite acesso remoto aos dados usando protocolo HTTP. Também provê execelente segurança para os dados enquanto aumenta a performance pra clientes conectados remotamente. O Enterprise Server pode ser instalado num servidor de web acessível remotamente e exposto à Internet ao invés de requerer que seu banco de dados seja exposto à Internet. (veja figura 9).

Figura 9: Clientes dentro do escritório conectam diretamente ao banco de dados enqunto clientes fora do escritório conectam ao banco de dados pela Internet através do Enterprise Server.

Servidores de Web requirendo um "middle tier"

O Enterprise Server pode ser usado para prover um portão seguro ao servidor de banco de dados para servidores de web de frente. Todos os acessos ao banco de dados pelos servidore de web seriam roteados através do Enterprise Server ao invés de diretamente ao servidor de banco de dados. Acesso ao servidor do banco de dados poderia então ser restrito somente ao Enterprise Server para aumentar segurança. (veja figura 10).

Figura 10: Ambos servidores de web conectam ao banco de dados através do Enterprise Server. Somente o Enterprise Server é permitido comunicar como o banco de dados através do "firewall".

Aumentando escalabilidade da aplicação

O Enterprise Server pode ser instalado em um ambiente de multi-servidores para aumentar a escalabilidade de uma aplicação com um número significante de clientes. Os recursos de hardware necessários pelo servidor de banco de dados seria então altamente reduzido já que o número de conexões ao banco de dados seria reduzido ao número necessário pelos Enterprise Servers. (veja figura 11).

Figura 11: Um largo número de clientes podem usar o mesmo servidor de banco de dados por disponibilizando a fazenda de Enterprise Server reduzir a carga no servidor de banco de dados.