A história do ASP

Vou postar aqui, um artigo sobre a história do ASP que eu achei por acaso, achei interessante pois nunca antes tinha procurado saber a respeito, segue abaixo.

A história do ASP 3.0

A tecnologia ASP nos permite gerar conteúdo neutro para o browser cliente usando scripts no lado-servidor (server-side) dinamicamente.

O código que acompanham estes scripts podem ser escritos em quaisquer idiomas e embutidos em Tags especiais dentro do HTML tradicional, em arquivos de inclusão para simular um (Code-behind) ou cima de todo o conteúdo HTML.

Este script é heterogêneo , sendo que a página quem o cotem é apenas interpretada pelo servidor de rede no momento que é executada a requisição no lado cliente.

O ASP clássico não é compilado é interpretado! (por isso ame-o ou deixe-o!)

Para entender a evolução e surgimento do ASP e suas capacidades, é preciso saber um pouco da história de aplicações voltadas para web…

A internet estática

Nos primórdios da web toda a informação era provida diretamente ao Browser do cliente e por sua vez era completamente estática.

Sendo que todo conteúdo requistado pelo cliente “A” no web-server seria exatamente igual ao requistado pelo cliente “B”.

O web-server não gerava absolutamente nenhuma parte do conteúdo de forma dinâmica, executando apenas a requisição do http do documento nele armazenado, hospedado , hosteado, guardado…

Ele ( o web-server) recebia a requisição e entregava integralmente o documento ao Browser cliente.

Não existindo assim nenhum laço de interatividade entre o cliente e o servidor.

Embora a evolução atual da web seja fantástica, mesmo naquela época sua evolução era na velocidade da luz, rapidamente as páginas estáticas evoluíram, tendo imagens e sons (mesmo que mids nojentos) mas eram sons!.Mesmo que caveirinhas piscando (mas eram imagens!)

Apesar disso ela continuava estática e com pouca interatividade, e fracamente funcional podendo apenas prover links e mais links...

A internet Dinâmica…engatinhando! Aplicações CGI

Uma das primeiras extensões da internet estática foi o CGI (common Gateway Interface), o CGI então provia o mecanismo no qual o Browser cliente poderia enviar uma requisição de excussão de aplicação ao web-server . Então o resultado dessa aplicação seria convertido e formatado em HTML legível pelo Browser cliente, a CGI foi rapidamente incorporada para efetiva utilização na world wide web(www), sendo ela um caminho fácil para compartilhar informações viabilizando uma plataforma de processamento de dados (server-side).

A resposta para essa considerável evolução na web, foi o rápido e crescente interesse em si desenvolver aplicações comerciais na web pelo paralelo mundo empresarial.

Diante desse interesse $$ começou a era da criação de scripts client-side, que permitiam ao cliente (browser) assumir parte das tarefas de processamento. Então começou a explodir soluções client-side mundo à fora, nascendo assim o javascript da finada Netscape e o VBScript da onipresente Microsoft.

E nesse período como não podia deixar de ser… Tio Bill sagaz e perneta! Liberou a sua primeira versão do IIS (internet information server), o que seria de fácil utilização, escalonável, portátil, seguro(?) e totalmente integrado ao também finado Windows NT. Tornando-se um (“webserver”) popular com rapidez astronômica.

A internet Dinâmica…querendo falar ! Aplicações ISAPI

Além de apoiar, bajular e aplaudir as especificações da CGI, a Microsoft apresentou uma alternativa à CGI, denominada Internet Server Application Programming Interface (ISAPI). Resumidamente o ISAPI iria suprir uma limitação do CGI que toda vez que o cliente requisitava a execução de uma aplicação CGI, o web-server executava uma instância da aplicação CGI, em seguida enviava ao Browser cliente a informação requisitada, proveniente do resultado da aplicação CGI que era finalmente processada no Cliente.

Mas esse processo de trabalhar instâncias da CGI teria um preço um pouco alto, cada requisição a CGI era instanciada.Uma nova CGI criada era instânciada e assim sucessivamente e novamente, e novamente e novamente, Com isso o pomposo Server ia miando, ia miando….miando…e miando….Até mijar no dedão e travar.

A CGI tinha o poder de sugar o web-server ( na época com recursos muito pequenos diga-se de passagem) , vampirizando os recursos do servidor de modo silencioso.

O ISAPI aliviava esse problema porque relacionava os processos em (DLLs) (dynamic link libraries) Cada aplicação ISAPI em forma de uma simples dll era carregada em um espaço de memória no web-server, imediatamente na primeira requisição de processo de execução do aplicativo.

Uma vez lá !(na memória), a DLL continuaria lá e lá ficaria enquanto o usuário (browser -cliente) permanecesse executando pedidos e só seria descarregada de lá (da memória) com um pedido explícito (..Tipo: Vamos sai daí já!).

Isto aumentou a performance e otimizou a tarefa de gerenciamento da memória. Todo o ISAPI DLLs deve estar em um thread seguro de forma que as múltiplas linhas podem ser instanciadas na DLL sem causar problemas com a função da aplicação atual ou standby.

As aplicações de ISAPI normalmente são mais rápidas que as aplicações de CGI equivalentes porque o web-server não tem que instanciar uma aplicação nova toda vez que um pedido era feito. Uma vez a aplicação de ISAPI DLL está na memória, ela fica na memória. E o web-server não precisa carregá-la novamente.

Além de aplicações de ISAPI, o ISAPI permitiu a criação de filtros ISAPI.

Um filtro ISAPI é nada mais do que uma DLL customizada que está no mesmo espaço de memória web-server e é chamado pelo web-server em resposta a todo http requisitado. Em deste modo, o filtro ISAPI trata as mudanças e a maneira na qual o próprio web-server irá se comporta.

Os filtros ISAPI então instruem o web-server como controlar as requisições. Os filtros ISAPI permitem personalizar a resposta de um web-server para tipos específicos de requisições dos Clientes.

Para diferenciar um filtro ISAPI e aplicações de ISAPI (e aplicações de CGI)de maneira mais clara, um filtro ISAPI oferece três tipos de funcionalidade que os separa de uma aplicação ISAPI (ou CGI):

Um filtro de ISAPI permite a você fornecer uma form no seu site ou uma página segura através de inserção em uma camada entre o cliente e o web-server.

Um filtro de ISAPI permite a você localizar mais informação sobre as requisições ao web-server e o conteúdo provido por quem o requisita um documento sobre o HTTP padrão ao web-server.

Estas informações são armazenadas separadamente em outro formato de arquivos, txt na maioria das vezes, criando um Logging das funções do web-server.

Um filtro de ISAPI fornecia informação aos clientes de uma maneira diferente que o web-server pode por si só não poderia fazer.

Aqui são alguns do filtros de ISAPI:

Uma camada Segura entre o cliente e o web-server (SSL). Esta camada de segurança pode prover para uma blindagem mais completa durante a requisição pelo cliente e possibilitou a utilização de Login e senha, criando ambientes de autenticação.

Um filtro ISAPI customizado, pode interpretar o fluxo de informações do servidor e, baseado naquela interpretação, apresentar o fluxo de texto em um formato diferente daquele que web-server possui originalmente.

O ASP.DLL é um exemplo deste tipo de filtro de ISAPI. Interpreta o código do servidor em um manuscrito requisitado pelo cliente e, dependendo de sua interpretação, provê ao cliente um conteúdo personalizado de acordo com sua requisição.

Um filtro ISAPI customizado pode traçar a requisição de um cliente a um local físico diferente no servidor.

Isto poderia ser usado em locais e volumes de alta capacidade onde você poderia querer movimentar o cliente sobre um servidor diferente.

Um filtro ISAPI desenvolvido de maneira profissional pode originar novas formas ou até linguagens de programação para web.

A internet Dinâmica… Voando baixo

Nos mirrados anos do IIS 2.0, a Microsoft começou a testar o beta de uma tecnologia com o codinome Daneli (a Microsoft adora batizar seus betas com codinomes), hoje chamamos essa tecnologia de ASP – Active Server Pages isso foi um marco na estratégia da Microsoft de alavancar o IIS 2.0. O ASP é encapsulada dentro um único e pequeno arquivo dll de (~300K) chamado ASP.DLL.

Esta DLL é um filtro de ISAPI que reside no mesmo espaço de memória do IIS. Sempre que um usuário pede um arquivo cuja extensão é. ASP, o (ASP filtro ISAPI) criam as instâncias de interpretação.

O ASP carrega qualquer linguagem de criação de scripts que possam ser interpretadas pelas DLLs na memória, executa qualquer código server-side encontrado na página ASP, e passa esse resultado para um HTML, isso ainda no lado servidor, então envia isto ao Browser – Cliente (Client- side).

Só para reafirmar, a produto ASP gerando no servidor é puramente HTML ou um conjundo de códigos cliente-side que são ou já estão inseridos no fluxo de texto que o Browser – Cliente enviou...

Então para finalizar...

O ASP não surgiu para tapar buracos, é apenas mais um filtro, não veio para fazer coisas extraordinárias, veio de uma cronologia evolutiva normal e obrigatória como todo e qualquer sistema ou linguagem, e dele agora temos o ASP.Net que na teoria seria a evolução do ASP, faz o que o ASP faz e ainda lava, passa, cozinha, e assa 500 mil lingüiças em segundos!

Fonte: http://www.chiavegatti.com.br/blog/index.php/2009/10/a-historia-do-asp-classico/