A história do ASP

[retrolink 0]

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/

[Mário Monteiro 179]

Boa aula de historia :lol:

[hinom 5]

Na web, comecei com ASP em 1999. Em 2001 deixei-o de lado e investi no php.

Gostava bastante do ASP, já estava acostumado, mas o que me fez migrar para o PHP foi o fato do ASP na época, ser completamente fechado. Não possuía librarys gratuitas.. Para coisas simples como um upload tinha que comprar uma library terceira ou fazer umas gambiarras inconsistentes..

O componente para enviar e-mails também.. e por fim, o que matou de vez foi quando precisamos mudar os sistemas para servidores linux.. Na época, o PHP já conseguia rodar até mesmo no Windows 98 usando PWS e, o ASP não dava suporte algum para outros ambientes fora do windows.

Eu acho que esse foi um dos vacilos da microsoft.. se o asp fosse aberto, talvez nem o PHP estaria de pé hoje.

[retrolink 0]

Particularmente Hinon, eu não passei por isso, trabalho com ASP desde 2003/2004 e nunca tive problemas, sempre achei bastante material, hoje em dia é muito difícil eu não conseguir fazer no asp o que outra linguagem faz (nunca consegui deixar de fazer algo por conta da linguagem), depende de caso a caso, para esse momento eu não penso em mudar do ASP e se um dia ele acabar, certamente não vou pular para o PHP, isso porque não quero ter o trabalho de estudar um bom tempo uma linguagem que faça a mesma coisa que o ASP faz, se o ASP acabar eu simplesmente vou deixar de lado programação web e focar em programação para Smartfones que para mim é o futuro.

 

Mais com fé em Deus eu acredito que o ASP ainda vai ficar por um bom tempooooo!

[hinom 5]

Não disse que o ASP não era capaz, mas sim de que era dificultoso.

Nem todos tem condições de comprar licensas de plugins, componentes, etc.. isso foi um grande empecilho na época, pois encarecia o custo de desenvolvimento e o valor final de um projeto.

Quanto a coisas simples, estávamos até relevando porque os custos eram ate irrisórios, mas o problema mesmo foi a falta de portabilidade. Com o tempo surgiram soluções para emular ASP em ambiente *nix mas é horrível.. isso é fato.

 

Continuamos com ASP 3.0 até 2005 e passamos a usar o .NET em 2006 se não me engano, mas o carro chefe é no PHP mesmo.

O .NET só aplicamos em projetos específicos mesmo, mas sempre que podemos, evitamos usar ou oferecer a clientes.

[retrolink 0]

hummmm entendi Hinon, mais para o seu caso, foi vantajoso, talvez hoje se eu fosse começar eu talvez não escolheria o ASP justamente por alguns questões que com o PHP os desenvolvedores não passam, hoje o PHP á uma das linguagens de programação mais utilizada e isso é uma baita vantagem.

 

Até o momento o ASP ainda não me deixou na mão, o problema é até quando os servidores vão dar suporte a ele, meu medo é somente esse, mais de resto eu estou satisfeito.

[xanburzum 169]

adoro ASP, trabalho varios anos com ASP, mas o UPGRADE para ASP.Net é inevitável....

tenho vários clientes e empresa com muitos sistemas, funcionam perfeito, mas como disse,

a evolução do ASP Classic é o .Net,tem um livro muito bom de ASP da editora Wrox que fala muito dá história também,

muito interessante...

[Ted k' 126]

Gostei da historia ai... Eu era bom em ASP, tenho saudades! Deixarei para a galera que quer mesmo permanecer na linguagem falar mas, Xanildo, hargoniado!!!

[xanburzum 169]

fala ted....tranquilaun irmão

tempos bons....tempos de glória....

[Ronaldo Faria Storck Eler 2]

Assim como alguns colegas trabalho somente com ASP desde 1999, e até hoje consegui fazer tudo o que eu necessitei, infelizmente algumas coisas quando não consigo recorro a fóruns e já usei muito deste, especialmente vários exemplos do Ted'k, e de outros também... penso em passar para PHP? não. Penso em "evoluir" para o ASP.net, talvez... como não dedico todo o meu dia para websites, ainda não consegui tempo para aprender melhor o aspx, mas em 2012 quero dar uma estudada...

 

Sou apaixonado pelo ASP, acho que, principalmente, porque consigo personalizar tudo do jeito que o cliente quer, sei que seria muito mais fácil fazer algumas coisas que faço com PHP, por exemplo, mas gosto do desafio... ;-)

 

sds

[xanburzum 169]

trabalho com ASP e SP.Net, mas gosto, prefiro e faço a maioria em ASP, no .Net você tem mais opções e recursos, mas você consegue fazer em ASP Classic também, em php sei das boas condições, mas não penso em mudar para php, isso vai de questões de preferência de linguagem também.

[Mário Monteiro 179]

ASP poderia ser mais aproveitado se tivessem feito o que o hinom disse de abrir mais os recursos e também se tivessem continuado a sua evolução

 

Infelizmente foi abandonado

 

Mas também sou apaixonado

[hargon 64]

A história foi boa... O ASP me ajudou muito. Conheci em 2000 em um trabalho para uma feira no Colégio e nunca mais larguei.

 

Como disseram também não penso em largar tão cedo. "Infelizmente" desenvolvi um sistema gerente de sites baseado em ASP e para reescrever ele em outra linguagem demoraria cerca de 6 meses ou mais. Isso para a empresa que trabalho não daria certo.

 

Mas nem por isso deixo de estudar outras linguagens como PHP e ASP.NET. Sempre busco fazer alguma coisa para conhecer as linguagens, ninguém sabe o dia de amanhã e não posso ficar preso a apenas uma.

 

Devido ao servidor de hospedagem que utilizo, por falta de alguns recursos, atualmente o ASP me deixa na mão em algumas coisas. Mas tudo que preciso e não consigo fazer no ASP, utilizo uma outra linguagem para complementar, como PHP e ASP.NET.

[xanburzum 169]

A combinação do ASP + ASP.Net + XML + JQuery, conseguimos um trabalho fantástico, para complementar uma necessidade, talvez não disponivel no Glorioso ASP.

 

Agradeço a todos os ASPmanos, pela loucura e devoção ao ASP Classic...