Um estudo teórico sobre a plataforma .NET

1.0- INTRODUÇÃO
No início dos anos 60, surgiram os primeiros grandes projetos de
software, como os sistemas operacionais: CTSS, desenvolvido pelo MIT, e o OS
360 para a família de computadores IBM 360. Atualmente o software é o
principal componente de um sistema de computação. O software está cada vez
mais integrado à sociedade, sendo usado para controlar sistemas críticos como:
sistemas financeiros, gerenciamento de comércio eletrônico, controle de tráfego
aéreo, controle de sistemas telefônicos, equipamentos médicos etc.
A construção de sistemas de software desenvolveu-se com a produção
de programas voltados para o ambiente empresarial. Inicialmente, para
proporcionar à empresa o controle de todos os seus dados operacionais, surgiram
os sistemas de banco de dados. Hoje em dia, esses sistemas evoluíram ao ponto
de aproveitarem a tecnologia da Internet para se tornarem poderosos servidores
de aplicações e de arquivos que aprenderam a "falar" Java e XML. Portanto, os
bancos de dados além de guardar e gerenciar um enorme volume de
informações, permitem que os dados sejam acessados a partir de um browser e
trazem recursos que ajudam as empresas a criar aplicações para a Web, sejam
simples sites corporativos ou complexas operações de comércio eletrônico.
O ponto inicial para se pensar em aplicações orientadas a Web foi a
possibilidade de atingir acessibilidade praticamente ilimitada. Exemplificando:
um sistema, desenvolvido sob medida para uma empresa, visando disponibilizar
o acesso a todos os seus fornecedores, parceiros e clientes. Para ampliar as
capacidades de desenvolvimento de software foi projetada a plataforma .NET.
Esta plataforma foi lançada em julho de 2001, como a primeira
atualização importante da plataforma de desenvolvimento de software da
Microsoft desde que a API1 Win32 apareceu no Windows NT 3.0 em julho de
1
API é a sigla em inglês para Interface de Programação de Aplicativos.
9
1993. Ao contrário da Win32, que oferecia APIs mais poderosas do que a
Win16, mas não mudava ferramentas ou técnicas, a plataforma .NET faz
alterações
fundamentais
nas
ferramentas
e
técnicas
usadas
pelos
desenvolvedores para criar aplicativos [CHERRY, 2001].
A Microsoft garante que a .NET foi construída sobre três pilares:
Segurança: a plataforma Microsoft .NET atende aos padrões mais
modernos de segurança. Através de um ambiente de execução seguro e
desenhado tendo em mente a hostilidade natural de ambientes de computação
altamente distribuídos. As ferramentas de desenvolvimento da plataforma
Microsoft .NET induzem a adoção de práticas melhores de programação,
resultando em software com menos erros. Finalmente, a plataforma Microsoft
.NET inclui ferramentas e serviços que dão a indivíduos e organizações controle
total sobre como e quando suas informações podem ser acessadas e utilizadas.
Padrões de mercado: a Microsoft tem o firme compromisso de agir em
parceria com o resto da indústria de tecnologia para assegurar que os padrões
usados para a criação e fornecimento de Web Services XML permaneçam
íntegros e abertos a todas as empresas, inclusive suas concorrentes, submetendose a entidades de padronização como o World Wide Web Consortium (W3C) e a
European Manufactures Association (ECMA). Isso assegurará que todos os Web
Services XML serão compatíveis, independentemente de que ferramentas
tenham sido utilizadas para criá-los e que empresas as forneceu.
Tudo conectado: os produtos e serviços da plataforma .NET
transformam as “ilhas de informação” isoladas e fechadas em sistemas
proprietários ou inadequados à colaboração em um mundo em que tudo é
conectado. PCs, PDAs, telefones celulares, consoles de videogame, sites
Internet, aplicativos e serviços podem ser compartilhados através de protocolos
comuns, de maneira transparente e segura.
10
Com a plataforma .NET, o desenvolvedor pode criar aplicativos Web
para executar no servidor Internet Information Server (IIS) com mais facilidade.
Ela também facilita a criação de aplicativos estáveis, confiáveis e seguros para
Windows desktop. A plataforma de desenvolvimento .NET contém:
O .NET Framework, que inclui o Common Language Runtime
(CLR), um componente de software para carregar e executar
aplicativos; e novas bibliotecas de classe, coleções de código
organizadas hierarquicamente e usadas pelos desenvolvedores em
seus aplicativos para criar interfaces gráficas com usuário, acessar
bancos de dados e arquivos e comunicar-se através da Web.
As ferramentas de desenvolvimento .NET, incluindo o ambiente
integrado de desenvolvimento (IDE) do Visual Studio.NET para
desenvolver e testar aplicativos, as linguagens de programação .NET
(como Visual Basic .NET e o novo Visual C#) que executam sob o
CLR e usam as bibliotecas de classe.
ASP.NET, uma biblioteca de classe especializada que substitui o
antigo Active Server Pages (ASP) para criar tanto conteúdo Web
dinâmico quanto aplicativos para servidores Web que usam
protocolos da Internet e formatos de dados como HTML, XML e
Simple Object Access Protocol (SOAP).
A plataforma .NET proporciona o desenvolvimento de software com
base na tecnologia de objetos e componentes. Esta abordagem tem se revelado
com inúmeros benefícios. Dentre estes, pode-se destacar a modularidade, a
flexibilidade e a reusabilidade, características essenciais para a qualidade e a
produtividade do desenvolvimento de software.
11
O principal objetivo deste trabalho é apresentar esta plataforma através
de seus principais componentes, seu novo modelo de programação e execução
de aplicativos e principais vantagens e problemas. Além de mostrar uma visão
geral da estratégia de mercado da Microsoft para a plataforma .NET. Faz-se
também uma comparação com a plataforma concorrente da Sun Microsystems
Java Enterprise Edition: a J2EE.
12
2.0- REVISÃO DE LITERATURA
2.1- Computador digital: a evolução das engrenagens mecânicas
Em 1642, o francês Blase Pascal construiu uma máquina de calcular, o
ábaco, que utilizava engrenagens mecânicas. Esta máquina podia apenas somar
e subtrair, mas pelo seu impacto na computação o nome Pascal foi dado a uma
moderna linguagem de programação. Passados 30 anos, o matemático alemão
Leibniz construiu uma máquina mecânica que podia, além de somar e subtrair,
multiplicar e dividir. Podemos dizer que Leibniz construiu uma máquina
equivalente a uma calculadora de bolso com quatro funções, três séculos atrás.
Passaram-se 150 anos até que, em 1822, o matemático Charles Babbage, na
Universidade de Cambridge, construiu uma máquina de calcular que perfurava
os resultados em uma placa de metal. Essa forma de escrita foi a precursora da
escrita em cartões perfurados e em discos ópticos.
A coroa inglesa investiu no projeto dessa máquina e Babbage construiu a
máquina analítica. Como esta era programável em uma linguagem, ela
precisava de um software. Nesse ponto da história Ada Lovelace construiu a
primeira linguagem de programação, além de ser a primeira pessoa a programar
uma máquina. A moderna linguagem de programação Ada® foi assim chamada
em sua homenagem.
Nos anos de 1930, John Atanasoff e George Stibbitz, no Bell Labs,
construíram uma máquina com relês eletromagnéticos surpreendentemente
avançada para sua época: com aritmética binária e circuitos de memória. E em
1944, na Universidade de Harvard, Aiken apresentou o primeiro computador
eletrônico: o Mark II.
Na Segunda Guerra Mundial, as mensagens enviadas pelos alemães aos
seus submarinos eram captadas pelos ingleses. Como essas mensagens eram
13
criptografadas, o ex-presidente dos Estados Unidos Thomas Jefferson construiu
o Enigma, um computador eletrônico para descriptografar essas mensagens. Os
Estados Unidos então resolveram investir em computadores eletrônicos e em
1946 surgiu o ENIAC (Eletronic Numerical, Integrator Calculator). Ocupava
uma sala inteira e tinha centenas de botões e cabos entrelaçados. John Von
Neumann, um dos projetistas do ENIAC, organizou uma equipe que projetou um
novo computador: composto por memória, processador e unidades de entrada e
saída. Os computadores atuais são baseados na arquitetura de Von Neumann.
O prêmio Nobel de Física de 1956 foi dado aos inventores dos
transitores. Esta invenção do Bell Labs proporcionou um avanço aos
computadores, tanto que no final dos anos 60 surgiam os projetos voltados para
o software. Nesta época foi desenvolvida a linguagem Algol 60, precursora da
linguagem Pascal.
No início dos anos 60 os circuitos integrados possibilitaram a produção
de computadores muito mais rápidos e menores a um custo muito menor. A
tecnologia dos computadores foi incrementada com a multiprogramação e com
o
time-sharing,
que
proporciona
a
execução
de
múltiplas
tarefas
simultaneamente. Nessa época, o MIT desenvolveu sistemas operacionais que
permitiam que terminais remotos fossem conectados a um computador central
por meio de linhas telefônicas.
A partir de 1980 a VLSI (Very Large Scale Integration) possibilitou a
colocação de centenas de milhares de transistores em uma pastilha (circuito
integrado). Os minicomputadores, com capacidade de processamento superior
aos primeiros mainframes se tornaram amplamente utilizados em escritórios,
escolas e até em ambientes domésticos.
Informações detalhadas sobre a evolução dos computadores podem ser
vistas em [TANEMBAU, 1995].
14
2.2 A história do software
Nas décadas de 1940 a 1970 o principal objetivo da computação era
desenvolver um hardware que ampliasse as capacidades de processamento e
memória.
Nos
anos
80,
avanços
na
microeletrônica
proporcionaram
computadores digitais com altíssimo poder computacional a um custo
relativamente baixo. No início dos anos 90 a computação passou o foco para
soluções implementadas em software. Afinal, a capacidade de processamento de
um mainframe lançado no mercado em 1980 estava disponível em nossas casas.
No início da computação os problemas implementados pelos
programadores eram simples: por exemplo: calcular uma equação diferencial.
Não eram problemas surpreendentes como implementar um sistema de tempo
real para controle de vôos ou sistemas de segurança para Internet Bankings. Os
problemas se relacionavam com o usuário e o programador; não haviam pessoas
envolvidas. Mas os computadores eram cada vez mais utilizados e mais pessoas
estavam envolvidas. As linguagens de alto nível começavam a ser inventadas no
início dos anos 50 para facilitar a comunicação com a máquina. Mas os
programas eram desenvolvidos para tarefas bem definidas.
A partir da década de 1970, a multiprogramação e os sistemas
multiusuários foram a base para a implementação de aplicações muito mais
sofisticadas; como sistemas de tempo real controlando grandes quantidades de
dados em milisegundos e sistemas sistemas de gerenciamento de banco de dados
com suporte a transações on-line. No final dos anos 70 surgiram também novas
empresas da área de informática: as software houses, que se concentravam na
produção de software em escala. Nessa época universidades e empresas
alocavam seus recursos para pesquisa e desenvolvimento de pacotes de
software.
Em meados dos anos 80, sistemas distribuídos em que múltiplos
15
computadores executavam tarefas de forma concorrente e comunicavam-se entre
si ampliaram a complexidade dos sistemas de computação. Também nessa época
o microprocessador permitiu o lançamento de produtos inteligentes: do
automóvel aos fornos de microondas, de robôs no chão de fábrica a
equipamentos hospitalares. O software estava sendo integrado ao hardware.
Em 1990 o conceito de redes de computadores se tornou popular e
começava o sucesso do computador pessoal. Em 1994 algumas pessoas falavam
em Internet e em 1999 centenas de milhões de pessoas navegavam na Web
diariamente, esse fenômeno social implicou no crescimento, em escala
exponencial, da demanda mundial por software.
Na perspectiva industrial, [PAULA FILHO, 2001] explica que se
voltássemos em 1969, veríamos que a grande maioria dos profissionais de
informática trabalhava em computadores de grande porte. Equipamentos de
milhões de dólares! Seguindo sua linha de raciocínio, o custo de
desenvolvimento dos aplicativos possíveis com a tecnologia da época era
relativamente
pequeno,
se
comparado
com
o
custo
do
hardware.
Surpreendentemente, o projeto de desenvolvimento de um sistema de telefonia
móvel, sob a coordenação da UFMG, há poucos anos, foi implementado em uma
plataforma de hardware que custou alguns milhares de dólares. A plataforma de
software custou algumas centenas de milhares de dólares. A economia que esse
sistema trouxe para o cliente foi de alguns milhares de dólares. Em três décadas
houve uma inversão radical na economia da informática: o software se tornou o
ponto principal no projeto de sistemas de computação. Tanto que atualmente, o
software é a chave para sistemas de computação e, mais ainda, é um fator de
diferenciação para uma empresa em relação às suas concorrentes.
2.3 Engenharia de Software: projeto e análise de software
No início dos anos 60, surgiram os grandes projetos de software
16
desenvolvidos pelos pioneiros da computação. Por exemplo, o Sistema
Operacional CTSS desenvolvido pelo MIT foi um grande projeto desenvolvido
em equipe. Já em 1965, foram lançados os primeiros softwares comerciais. O
melhor exemplo é o Sistema Operacional OS 360 para a família de
computadores IBM 360.
Nesta época as equipes de desenvolvimento começavam a questionar os
problemas relacionados a construção dos softwares. Já se começava a perceber
que projetos de software exigem previsão de custos e um plano de produção.
Mas na grande maioria das vezes o software era desenvolvido como uma arte.
As estimativas feitas pela equipe de desenvolvimento freqüentemente estavam
incorretas. Os programas tinham muitos erros e a tentativa de correção desses
erros produzia mais erros. Em 1979, uma pesquisa realizada nos Estados Unidos
revelou que 2% dos softwares atingiam a funcionalidade exigida pelo cliente.
Essa estatística se explicava pela inexistência ou a não aplicação de métodos,
técnicas e ferramentas para auxiliar e padronizar o processo de desenvolvimento
de software. Então foi inventado o termo: Crise de Software para sintetizar os
problemas: softwares grandes não funcionavam adequadamente; estimativas de
custo e tempo de desenvolvimento eram imprecisas; os computadores se
tornavam cada vez mais rápidos, fáceis de usar e acessíveis. Isto implicava em
uma demanda crescente por software cada vez maior e mais complexo, enquanto
a capacidade de produção não estava tão acelerada quanto esta demanda.
Informações detalhadas sobre a crise de software podem ser encontradas em
[PRESSMAN, 1995].
No contexto da crise do software e do declínio dos custos de hardware
paralelo a ampliação dos custos de software (ampliação causada pela demanda
crescente) foi inventada a Engenharia de Software.
[PRESSMAN, 1995] usa a definição de [BAUER, 1969] que explica: a
Engenharia de Software é a aplicação de metodologias e técnicas de engenharia
17
visando obter economicamente softwares confiáveis e que funcionem com
eficiência em máquinas reais. Segundo [VASCONCELOS, 1999]: a Engenharia
de Software é a aplicação de ciência e matemática visando tornar as capacidades
do equipamento úteis para o ser humano através de programas, procedimentos e
documentação.
O principal objetivo da Engenharia de Software é construir software de
qualidade com a mínima alocação de recursos possível.
É fácil notar que o software está se integrando à sociedade. Cada vez
mais, o software é usado para controlar sistemas críticos como: sistemas
financeiros, gerenciamento de comércio eletrônico, controle de tráfego aéreo,
controle de sistemas telefônicos, equipamentos médicos etc. Isto garante o
interesse crescente da sociedade em depender de software e, principalmente,
mostra a importância crescente em se aprender a construir um software melhor.
A Engenharia de Software define as fases de desenvolvimento de
software:
1. Concepção: entrevista com o cliente/usário para se criar uma lista
de atividades e/ou tarefas realizadas diariamente, semanalmente,
mensalmente, anualmente e esporadicamente pelo cliente/usuário.
Depois de listadas as atividades é essencial dividi-las em grupos e
escrever um documento que mostre como a empresa funciona, quais as
atividades e serviços realizados por ela. Este documento é chamado
escopo. Nesta fase de concepção também se faz a modelagem. Um
modelo é uma simplificação da realidade. Modelos são construídos
para se entender o problema e as necessidades do cliente e servir como
base para projetar o que ele realmente precisa. Além disso, auxiliam no
planejamento e na determinação do produto final a ser desenvolvido;
das fases, etapas e tarefas; de um planejamento e um cronograma de
18
execução; das ferramentas e matéria prima; das equipes de
desenvolvimento. A modelagem é uma parte central de todas as
atividades que levam à implantação de um bom software e à criação de
uma documentação completa. É importante destacar os problemas
relacionados à modelagem que se refletem na qualidade final do
software: alocar os profissionais ideais para uma determinada tarefa
não é uma tarefa trivial, visto que a limitação financeira se contrapõe
ao fato de esses profissionais serem mais caros; o cliente muda de idéia
ao longo do tempo de desenvolvimento; os desenvolvedores nem
sempre tem conhecimento e iniciativa suficientes para resolver
problemas inesperados; o cronograma não é cumprido porque o
problema se mostra mais complexo do que o esperado; o cliente não
consegue definir exatamente as suas necessidades e expectativas.
2. Análise: nesta fase são construídos os diagramas de Caso de Uso, de
Sequencia e de Classe. Informações detalhadas sobre esses diagramas
podem ser encontradas em [PAULA FILHO, 2001]. Além de
determinar as informações que serão guardadas no computador e como
elas serão agrupadas de forma que o software possa realizar
corretamente suas tarefas com eficiência.
3. Projeto: nesta fase faz-se um dicionário de dados e diagramas
extras que podem ser necessários dependendo dos objetivos e da
complexidade da aplicação.
4. Implementação: com base no projeto, os programadores
implementam as estruturas de dados, as funções e os procedimentos
concretizando o que se tem a nível abstrato e conceitual.
5. Teste: é matematicamente impossível testar um sistema por
completo então nesta fase aplicam-se técnicas para se construir uma
base de dados para testar a maior parte do sistema possível.
19
6. Manutenção: esta fase é iniciada com a implantação do sistema em
ambientes organizados. A manutenção pode ser de correção,
adaptação e atualização.
Do ponto de vista de [VASCONCELOS, 1999], é comun ouvirmos falar
em "crise de software". Mas nem todos os projetos são exemplos de falhas de
gerenciamento ou de engenharia. Existem produtos com sucesso espetacular.
Sem sucessos tão grandes, o software não seria integrado à sociedade. Na
verdade estes sucessos é que tem causado a explosiva demanda por software.
Além disso, o crescimento rápido na demanda por software, combinado com os
esforços requeridos na manutenção do software existente, cria um grande
backlog entre as aplicações de software que precisam ser desenvolvidas e a
capacidade de desenvolvimento. Isto é, graficamente a curva que descreve o
crescimento da demanda é muito mais acentuada que a curva que descreve a
capacidade de produção de software. Este é um problema que está bloqueando o
sucesso de muitas empresas: novos produtos não podem ser lançados no
mercado, e às vezes não saem das pranchetas dos projetistas, e novos serviços
não podem ser oferecidos porque o software que é necessário não pode ser
desenvolvido com a rapidez suficiente.
Nesse contexto, [VASCONCELOS, 1999] destaca que a reutilização é
um fator essencial na produção de software. A reutilização do conhecimento e
de projetos anteriores é uma prática padrão em outras engenharias e está se
tornando cada vez mais utilizada em projetos de software desenvolvidos em
ambientes organizados.
Existe uma demanda crescente por software que exige que se encontre o
melhor caminho para se desenvolver software rápido, confiável e seguro com a
mínima alocação de recursos possível. Essa é exatamente a meta da Engenharia
de Software.
20
2.4 Processos: a produção do software
2.4.1 O ciclo de vida do software
Um processo é um conjunto de passos parcialmente ordenados,
constituídos por atividades, métodos, práticas e transformações, usado para
atingir uma meta. Esta meta geralmente está associada a um ou mais resultados
concretos finais, que são os produtos da execução do processo [PAULA FILHO,
2001].
Do ponto de vista deste mesmo autor, o software é visto como um
produto e como todo produto industrial, o software tem um ciclo de vida. Além
disso, em um processo de desenvolvimento de software, o ponto de partida é a
escolha de um modelo de ciclo de vida. O autor define os modelos:
1. Modelo de ciclo de vida em Cascata: são executados passos
sequenciais que podem ser demarcados como pontos de controle que
podem facilitar a gestão dos projetos. A primeira vista esse modelo
parece totalmente confiável e utilizável em projetos de qualquer
escala. Por outro lado, pode se visto como um modelo rígido e
inflexível, em que as atividades de análise e projeto tem que ser
muito bem dominadas. Isso porque erros nessas fases serão refletidos
no produto final. Um outro ponto negativo é que o modelo em
cascata puro é de baixa visibilidade para o cliente, que vê
exclusivamente o resultado final do projeto.
2. Modelo de ciclo de vida em Sashimi: na prática é essencial
permitir que, em fases posteriores, haja revisão e alteração de
resultados das fases anteriores. Por exemplo, os modelos e
documentos de análise e projeto podem ser alterados durante a fase
21
de implementação, na medida em que os problemas surgem. Este
modelo é uma variação do modelo em cascata que permite a
superposição entre as fases e a realimentação de correções. O ponto
negativo é que esta superposição das fases é difícil de se gerenciar.
3. Modelo de ciclo de vida em Espiral: nesse modelo o produto é
desenvolvido em uma série de iterações. Cada nova iteração
corresponde a uma volta na espiral. Isso permite construir produtos
em prazos curtos, com novas características e recursos que são
acrescentados na medida em que a experiência descobre sua
necessidade. As atividades de manutenção são usadas para identificar
problemas; seus registros fornecem dados para definir os requisitos
das próximas iterações. O principal problema do ciclo de vida em
espiral é que ele exige gerenciamento sofsticado para garantir sua
precisão e confiabilidade.
4. Modelo de ciclo de vida de Prototipagem Evolutiva: variação do
modelo em espiral é usado para desenvolver o produto completo, mas
construindo uma série de versões provisórias chamadas protótipos.
Esses protótipos cobrem cada vez mais requisitos, até que se atinja o
produto desejado. A Prototipagem Evolutiva permite que os
requisitos sejam definidos progressivamente, e apresenta alta
flexibilidade e visibilidade para os clientes. Os pontos negativos:
gerenciamento sofisticado e a análise e o projeto devem ter excelente
precisão para que o produto não se degenere ao longo dos protótipos.
5. Modelo de ciclo de vida por Estágios: uma variação do modelo
em cascata em que o cliente recebe entregas de liberações parciais do
produto. Isso amplia a visibilidade do projeto para o cliente. Mas
continua com os outros pontos negativos do modelo em cascata puro.
6. Modelo de ciclo de vida de Entrega Evolutiva: combinação dos
22
modelos em Cascata e Prototipagem Evolutiva que permite que, em
pontos bem definidos, os usuários possam avaliar partes do produto e
fornecer realimentação quanto às decisões tomadas. Facilita também
o acompanhamento do progresso de cada projeto, tanto por parte de
seus gerentes como dos clientes. O ponto negativo continua fixado na
análise e no projeto: devem produzir uma arquitetura robusta que
mantenha a integridade ao longo dos ciclos de desenvolvimento.
7. Modelo de ciclo de vida Dirigido por Prazo: o produto é aquele
desenvolvido em um prazo pré-determinado. Esse modelo é razoável
quando se consegue definir um conjunto de requisitos em que se tem
certeza que o prazo estabelecido é suficiente e as folgas são usadas
para implementar requisitos opcionais.
8. Modelo de ciclo de vida Dirigido por Ferramenta: as ferramentas
CASE (Engenharia de Software Auxiliada por Computador) impõe
processos rígidos, que podem ser adequados para tipos bem
específicos de produtos. A qualidade destes processos depende de
forma fundamental da qualidade da ferramenta e do fato do uso do
processo ser restrito ao domínio da aplicação.
Uma solução alternativa ao desenvolvimento de software é comprá-lo.
Quando se encontra um pacote de software que atende aos requisitos desejados,
essa pode ser uma solução. [PAULA FILHO, 2001] explica que nesse caso, não
há processo de desenvolvimento, mas processos de compra, de implantação e,
possivelmente, de adaptação e integração com outros sistemas. E alerta que,
dependendo do caso, isso pode ser mais complexo e caro que um processo de
desenvolvimento.
23
2.4.2 A produção industrial de software
Inicialmente um produto é construído por uma pessoa ou por uma
equipe, mas na medida em que atinge sucesso no mercado, passa a evoluir. A
partir daí, um número crescente de pessoas participa de sua manutenção e
evolução. Por isso, quase todas as atividades de produção de software são
empreendidas por organizações. Essa linha de raciocínio é de [PAULA FILHO,
2001].
Continuando nessa mesma linha, a maturidade de uma organização
mede o grau de competência técnica e gerencial na produção de produtos de boa
qualidade, dentro de prazos e custos razoáveis e previsíveis. A existência de
processos definidos proporciona um nível operacional padronizado e
reprodutível. Isso viabiliza a capacitação das pessoas de forma que se dependa
menos de determinados indivíduos. A medida do êxito dos processos de
produção é a medida de quanto eles contribuem para que os produtos sejam
entregues aos clientes e usuários com melhor qualidade, pelo menor custo e no
menor prazo possíveis. Diversas organizações no mundo conseguiram propor
paradigmas do tipo modelos de capacitação. Em síntese, um modelo de
capacitação tem o objetivo de avaliar a maturidade dos processos de produção.
Um modelo de capacitação particularmente importante para a área de
software é o CMM (Capability Maturity Model), do Software Engineering
Institute. O CMM é patrocinado pelo Departamento de Defesa Americano, que o
utiliza para a avaliação da capacidade de seus fornecedores de software. Esse
modelo é amplamente aplicado na indústria americana de software, além de
indústrias em todo o planeta.
Partindo do princípio de que, para atingir os níveis superiores de
maturidade, era necessário melhorar a prática dos processos em nível dos
desenvolvedores individuais, Watts Humphrey propôs, em 1995, uma série de
processos pessoais chamada de PSP, do inglês Personal Software Process
24
(Processo Pessoal de Software).
Como conseqüência natural do PSP, Humphrey lançou uma publicação
em 1999 com o TSP, do inglês Team Software Process (Processo de Software
para times). O TSP usa um modelo em espiral. Os participantes do "time" de
desenvolvedores são organizados de tal forma que cada desenvolvedor
desenpenhe um ou dois papéis gerenciais bem definidos, além de dividir a carga
de desenvolvimento. Os papéis suportados pelo processo são os de gerente de
desenvolvimento, gerente de planejamento, gerente de qualidade, gerente de
processos e gerente de suporte, além do líder do "time".
2.4.3- Copyleft: a nova perspectiva para o software2
No Instituto de Ciências Nucleares da Universidade Nacional Autônoma
do México, o administrador de rede Miguel de Icaza em suas horas vagas
coordena o projeto Gnome. Esse projeto mundial é um esforço mundial para
desenvolver um sistema operacional para desktop que supere as múltiplas
versões do Windows, a base do império Microsoft. Os programadores do Gnome
dizem que este sistema será mais rápido, mais poderoso e terá menos
probabilidades de quedas do que qualquer outro sistema criado em Redmond
(cidade americana onde está instalada a matriz da Microsoft). É importante
destacar que o Gnome é grátis, poderá ser obtido a custo zero da Internet.
O objetivo principal do Gnome é reconquistar o comando dos sistemas
operacionais das mãos da Microsoft. Eric S. Raymond, um defensor do software
livre e editor do New Hacker's Dictionary diz: "o Gnome tem a chance de levar
o mundo do software a um lugar muito diferente e melhor".
Por que o Gnome obteria sucesso onde companhias maiores e mais ricas,
como a Apple, fracassaram? Por dois motivos, de acordo com os defensores do
25
sistema. Primeiro: o Gnome foi criado para operar junto com o sistema
operacional Linux. Famoso por sua velocidade, confiabilidade e eficiência, o
Linux é operado em cerca de 17 milhões de sistemas de computadores em todo o
mundo (estatística vista em www.olinux.com.br), de redes pequenas nos setores
de computação de universidades a provedores de acesso à Internet e laboratórios
de computação, passando por empresas de porte imenso como o Correio dos
Estados Unidos. Com sua base de usuários crescendo à razão estimada de 40%
ao ano (estatística: www.olinux.com.br), o Linux é o único sistema não criado
pela Microsoft a expandir sua fatia de mercado. Os defensores do Linux dizem
ainda que este sistema oferece, às pessoas, a oportunidade de conhecer o que é
um "bom software" e estas, então, jamais voltarão a usar o Windows.
A segunda e mais importante razão para que o Gnome tenha sucesso é
que, como o Linux trata-se de um produto do movimento conhecido como
software livre, ou de código fonte aberto. Não só o Gnome pode ser obtido
grátis, como seu código fonte (as instruções básicas que a maior parte das
empresas de software encara como as jóias de sua coroa) estará disponível para
cópia e modificação. Ao liberar os códigos fonte do controle de uma única
companhia, projetos como o Gnome podem contar com a contribuição de
milhares de programadores. Porque nem mesmo a gigante Microsoft tem a
capacidade de sobrepujar o talento unido de todo o mundo, alegam os defensores
do software livre, o software de código fonte aberto sempre supera a
competição.
O Gnome, o Linux e o movimento do software livre têm uma origem
única em 1979, quando a Xerox doou uma das primeiras impressoras a laser ao
Laboratório de Inteligência Artificial do MIT. A máquina parava todo hora, o
que induziu o programador Richard Stallman, do laboratório, a pedir à Xerox o
código que controlava a máquina. Stallman planejava modificar o programa para
2
Da MIT'S MAGAZINE OF INNOVATION TECHNOLOGY REVIEW.
26
que ele respondesse a defeitos com a emissão de um alerta que chegaria às telas
de todas as pessoas que estivessem esperando por impressão. Ou seja, todos
teriam um incentivo para consertar a impressora imediatamente. Para fazer essa
modificação, Stallman precisava do código fonte para o programa da impressora.
Para ele tratava-se de um pedido corriqueiro. Na atmosfera de liberdade
acadêmica do laboratório, os programadores trabalhavam em conjunto uns com
os outros. Além do mais, a Xerox havia dado a Stallman o código fonte de uma
impressora anterior, também problemática. Dessa vez, porém, a Xerox se
recusou, pois adquiria copyright sobre o código fonte. Stallman achava que o
copyright o impedia de melhorar o programa.
A Xerox não estava sozinha. À medida que o software se transforma em
um negócio de grande porte, o Vale do Silício começou a atrair muitos dos
melhores programadores do laboratório de Inteligência Artificial. Quando esses
programadores começaram a trabalhar para essas empresas de software,
descobriu Stallman, os códigos que escreviam tornavam-se exclusivos e não
mais podiam ser melhorados ou compartilhados. Copyright, conclui o idealista
Stallman, estava destruindo a comunidade do software. Em 1984, Stallman
fundou a Free Software Foundation. Sua meta principal era desenvolver um
sistema operacional melhorado que fosse parecido com o Unix, mas que não
usasse seu código fonte. Inventado em 1969 por dois pesquisadores do Bell
Labs, o Unix agora está disponível em muitas versões diferentes, criadas por
companhias com IBM, Compaq e Sun. Stallman batizou sua versão de GNU, um
acrônimo para "GNU não é Unix". Numa espécie de homenagem a Stallman, o
Gnome, quer dizer GNU Network Object Model Environment.
O desafio GNU era enorme. Um sistema operacional define que tarefas
os programadores podem solicitar de um computador (adicionar dois números,
transferir dados a um disco rígido etc) e dirige os pedidos ao hardware (teclado,
monitor, processador, e assim por diante). Mas o sistema é inútil sem centenas
27
de programas subsidiários para executar tarefas específicas, como administração
de janelas e comunicação com impressora e outros periféricos. Para produzir um
sistema funcional, o projeto GNU tinha de criar todos esses programas. Miguel
de Icaza brincava: "É como construir um avião a jato a partir do zero em sua
garagem".
Em 1990, dezenas de programas haviam sido criados e estavam em uso
em todo o mundo, mas o coração do sistema operacional GNU ainda não havia
sido produzido. Parte da razão era que Stallman optara por não duplicar o kernel
do Unix, mas basear o sistema GNU num kernel avançado e experimental
desenvolvido pela Universidade Carnegie Mellon. Único programador a receber
um fellowship MacArthur, láurea reservada a gênios, Stallman era uma das
poucas pessoas no mundo com a capacidade de enfrentar a tarefa de desenvolver
um kernel radicalmente novo, e possivelmente a única com a capacidade de
fazê-lo por conta própria. Mas então suas mãos, esgotadas com a digitação de
tantos códigos, começaram a lhe dar problemas e a dor o impedia de trabalhar
com o teclado.
Depois de Stallman, foi a vez de Linus Torvalds, que tinha 21 anos e
estudava na Universidade de Helsink em 1991. Torvalds estava longe de ser um
especialista em programação. Mas detestava o MS-DOS e ao comprar um 386
com 4 MB de memória percebeu que era uma máquina muito pequena para
operar em Unix. Ignorando o DOS e classificando-o como software de "máqualidade", Torvalds mudou o kernel do projeto GNU para poder usá-lo. Eis que
ele havia criado um sistema operacional completo. Pela primeira vez a potência
do Unix estava disponível para pequenos computadores em um sistema
operacional batizado pelos seus amigos de Linux. Torvalds registrou o Linux
com o copyleft de Stallman e permitiu que quem o quisesse o obtivesse on-line;
quando as pessoas melhoravam o código, ele colocava as versões aperfeiçoadas
à disposição na Internet. Isso foi viabilizado porque como os preços dos
28
computadores pessoais, nessa época, caiu e usa potência aumentou, as pessoas
dos paízes pobres podiam comprar um 486 ou pelo menos um 386. Essa nova
leva de "micreiros" queria testar seus poderes na vanguarda da Ciência da
Computação. Com pouca demanda por seus talentos nos países em
desenvolvimento, eles aproveitaram a chance de poder participar do
desenvolvimento do Linux via Internet.
Iniciado em 1991 como um sistema operacional para chips Intel e um
único usuário, em 1995 o Linux havia sido modificado para operar em máquinas
da Digital e da HP e tinha meio milhão de usuários, muitos deles em países
desenvolvidos. Para Raymond, o defensor do software livre, o desenvolvimento
do Linux pressagia uma mudança total no mundo do software. O Linux nunca
pára. Os usuários comuns trabalhavam com instantâneos bem sucedidos do
sistema operacional, mas os programadores sempre estão consertando ou
acrescentando alguma coisa. Escrever software numa atmosfera de mercado
persa é mais fácil, eficiente e tem maior probabilidade de sucesso, acredita
Raymond. Porque o código fonte está aberto a todos, diz, "raramente temos de
resolver problemas duas vezes". Os criadores de software comercial, em
contraste, são muitas vezes forçados a reinventar a roda, um desperdício quase
criminoso de recursos. Quando uma empresa inventa uma maneira de enviar email diretamente de um programa, por exemplo, os concorrentes não podem
aproveitar e melhorar esse trabalho; devem, em lugar disso, começar do zero e
descobrir uma maneira completamente diferente de fazê-lo. O resultado, alegam
os defensores do código fonte aberto, não precisam se preocupar com a
possibilidade de que consertar um bug possa quebrar centenas de programas que
dependam dele. Os bugs de programas livre podem ser consertados rapidamente,
porque o código fonte está disponível para todos. Os defensores do código fonte
aberto para todos dizem que o GNU e o Linux têm vantagens para os usuários.
No lugar de serem forçados a aceitar os recursos que grandes fornecedores como
29
a Microsoft optam por tornar disponíveis, as companhias podem criar softwares
que atendam às suas necessidades. Em parte devido a sua facilidade de
personalização, o software livre está se espalhando pelo mundo dos negócios
(ainda que em algumas empresas os gerentes de informática escondam o uso
desses sistemas dos seus chefões). A Sega usa Linux para desenvolver
videogames; a Digital Domain, de James Cameron, usou para produzir os efeitos
especiais de Titanic. Netscape e Intel estão investindo na Red Hat, a maior
distribuidora de Linux.
2.5 Algoritmos, linguagens de programação e software
Programar é compreender.
- Kristen Nygaard
"Na década de 40 quando surgiram os primeiros computadores, a
programação era feita por hardware. Os engenheiros que desenvolveram os
primeiros computadores criavam os programas mudando fisicamente suas
conexões. Eram utilizados grandes painéis com centenas de conectores,
semelhantes às antigas mesas telefônicas. A programação era alterada
plugando-se os fios em diferentes conectores. O processo era complicado e com
muitas chances de erro. Além disso, o programa era armazenado em diagramas
impressos em papel, assim, para cada vez que fosse utilizado, o software
precisava ser (re)criado".
Jornal O Estado de S. Paulo, 17 de Julho de 1996
A Ciência da Computação surgiu na antiga Grécia, no século III a.C.
com o desenho de algoritmos por Euclides e com os estudos sobre complexidade
e redutibilidade de problemas na Babilônia. No início do século XX, diversas
pesquisas foram desenvolvidas com o objetivo de definir um modelo
30
computacional suficientemente genérico para implementar qualquer "função
computável".
Em 1936, Alan Turing apresentou a Máquina de Turing. Um modelo
para a formalização de um procedimento efetivo (algoritmo), ou seja, uma
sequencia finita de instruções, realizadas mecanicamente em um tempo finito.
No entanto, menos de 20 anos depois surgiu uma nova forma de
expressar algoritmos: as linguagens de programação. [DEITEL, 2001] explica
as linguagens de alto nível clássicas:
FORTRAN (FORmula TRANslator) desenvolvida pela IBM
Corporation, entre 1954 e 1957, para ser usada no desenvolvimento
de aplicativos científicos e de engenharia que exigem computações
matemáticas complexas. FORTRAN é ainda amplamente usada,
especialmente em aplicativos de engenharia.
COBOL
(COmmon
Business
Oriented
Language),
desenvolvida em 1959 por fabricantes de computadores, usuários do
governo e usuários industriais de computadores. COBOL é
principalmente utilizada para aplicativos comerciais que exigem
manipulação precisa e eficiente de grandes quantidades de dados.
Hoje em dia, mais da metade de todo o software para aplicações
comerciais ainda é programado em COBOL [DEITEL, 2001].
A linguagem de programação Pascal foi criada por Niklaus
Wirth em 1971. Pascal foi planejada para uso acadêmico e projetada
para ensinar programação estruturada em ambientes acadêmicos, e
se tornou rapidamente a linguagem de programação preferida no
ambiente universitário.
A linguagem C foi criada por Dennis Ritchie no Bell
Laboratories e foi originalmente implementada em um computador
31
DEC PDP-11 em 1972. C se tornou inicialmente conhecida como a
linguagem de desenvolvimento do sistema operacional Unix. Hoje
em dia, a maioria dos sistemas operacionais são escritos em C e /ou
C++. C está atualmente disponível para a maioria dos computadores,
além de ser independente do hardware.
C++ é uma extensão de C e foi desenvolvida por Bjarne
Stroustrup no início dos anos 80 no Bell Laboratories. C++
apresenta várias características que melhoram a linguagem C, mas o
mais importante é que fornece recursos para a programação
orientada a objetos.
A Sun Microsystems em 1995 desenvolveu o projeto a
linguagem Java. Baseada em C/C++, Java é usada para criar páginas
Web com conteúdo dinâmico. A tecnologia Java, portanto, está
presente em páginas Web com conteúdo dinâmico e interativo, em
aplicativos empresariais de grande porte, em servidores Web, em
produtos eletrônicos (celulares, pagers, assistentes pessoais) e muito
mais.
A programação de sistema desenvolveu-se com a produção de
programas voltados para o ambiente empresarial. À medida que a computação se
tornava imprescindível no dia a dia das empresas, ficou evidente que o sistema
de banco de dados proporcionava à empresa o controle de todos os seus dados
operacionais.
A linguagem SQL (Structured Query Language) foi criada pela IBM
para definir, modificar e consultar dados contidos em um banco de dados
relacional.
A primeira linguagem para páginas Web foi a HTML (Hipertext Markup
Language), mas a nova linguagem para a Web é muito mais flexível e fácil de se
32
aprender: o XML (eXtensivel Markup Language), que se integra totalmente ao
HTML. Além disso, as duas linguagens tem uma origem em comun, o SGML
(Standard Generalized Markup Language), um padrão internacional genérico
para a descrição da estrutura de diversos tipos de documentos eletrônicos. Ao
contrário do HTML, no entanto, o XML não estabelece como um determinado
elemento deve ser visualizado. Seu objetivo é armazenar as informações de
forma organizada. Um arquivo XML é apresentado em mídias diferentes, dessa
forma um mesmo material pode receber determinado tratamento gráfico para a
Web e outra formatação para ser impresso.
Os bancos de dados corporativos como o Oracle 8i, por exemplo,
aproveitam a tecnologia da Internet para se transformarem em poderosos
servidores de aplicações e de arquivos que aprenderam a "falar" Java, afinal o
mercado volta-se cada vez mais para linguagens de padrões abertos que
facilitam a vida dos desenvolvedores de aplicações e dos usuários. Com isso,
além de guardar e gerenciar um enorme volume de informações, permitem que
os dados sejam acessados a partir de um browser e trazem recursos que ajudam
as empresas a criar aplicações para a Web, sejam simples sites coorporativos ou
complexas operações de comércio eletrônico.
2.6- Software na Internet
2.6.1- Visão Geral
O ponto inicial para se pensar em aplicações orientadas a Web foi a
possibilidade de atingir acessibilidade praticamente ilimitada. Um sistema
desenvolvido sob medida para uma empresa pode agora ser desenvolvido
visando disponibilizar o acesso a todos os distribuidores dessa empresa.
Estendendo a solução, é possível disponibilizar acesso a todos os consumidores.
No passado, atingir essa acessibilidade era o principal obstáculo. Com as
33
tecnologias orientadas à Web, prover acesso externo a sistemas internos é tão
fácil quanto publicar uma URL.
Sem dúvida, a Web foi significativamente influenciada pelos usuários de
sistemas de computadores, mas qual a influência ela tem sobre os designers de
aplicações empresariais? Esta é exatamente a nova questão explorada pela
Engenharia de Software. Que coisas continuam as mesmas? Que coisas são
novas? E que coisas tem mudado sutilmente, mas que são interessantes do ponto
de vista dos modelos e processos de desenvolvimento de software? As
atividades que as pessoas precisam realizar para construir um software para a
Web não são diferentes daquelas realizadas para desenvolver um software
qualquer. É essencial fazer análise de requerimentos, design, implementação,
teste e implantação. Mas para se construir software para uma aplicação Web
adiciona algumas novas variações a esta sequencia de atividades tradicionais.
Essas modificações são compactas, mas suficientes para apontarem novas
direções.
2.6.2- Qualidade, escalabilidade, usabilidade e manutenibilidade
Na programação para aplicações Internet, o ponto de partida é explorar
os atributos de qualidade para sistemas orientados à Web. A Internet não
introduziu, necessariamente, novas regras de qualidade, mas as aplicações Web
lançaram mais desafios que as primeiras gerações de aplicações. Além disso, as
capacidades da Web introduzem novos conceitos às idéias tradicionais de
qualidade.
A Web também destaca a questão sobre a escalabilidade. Enquanto um
sistema provavelmente tinha alguns poucos milhares de usuários uma década
atrás, os projetistas de sistemas Web, hoje em dia, precisam considerar a
possibilidade de centenas de milhares de usuários estarem acessando a aplicação
ao mesmo tempo.
34
Adicionalmente, muitos usuários da Web são potenciais consumidores,
isso faz com que as aplicações empresariais apresentem uma demanda por altos
índices de usabilidade. Portanto, esse problema deve ser tratado com técnicas
para projetar a interface com o usuário, através de modelos de interface, modelos
de tarefas e modelos de conteúdo.
As aplicações Web precisam ser modificadas no mesmo ritmo em que os
negócios se modificam, e sempre o site com melhor usabilidade pode ter
problemas se o projeto da interface é difícil de ser modificado e ampliado.
Portanto, a manutenibilidade é um outro fator essencial em ambientes orientados
à Web.
2.6.3- Agilidade, alcance mundial e lições de aprendizado
Aplicações Web precisam ter altos índices de qualidade, usabilidade,
velocidade de acesso e, ao mesmo tempo, serem rapidamente criadas. Mas
existe um dilema: alta qualidade não é compatível com rapidez de
desenvolvimento. Especialistas apontam que começar os testes antes da fase de
implementação não produz apenas um produto mais sólido, mas também com
muito mais rapidez.
Métodos de agilidade na produção de software são abordados pela nova
área da engenharia de software: a Extreme Programming. Aplicações Web em
particular exigem ênfase em agilidade de processos, ênfase na qualidade e na
velocidade. Uma característica de métodos que visam agilidade, é a ênfase na
modelagem. No entanto, especialistas afirmam que em projetos de aplicações
para Internet, a ênfase dada à documentação e às ferramentas deve ser muito
menor que a ênfase dada à comunicação e à qualidade.
O alcance mundial da Internet é impedido porque pensa-se que em todo
o mundo as pessoas conseguem ler e compreender o inglês. As pessoas que
falam inglês com naturalidade, navegam pela Web com muito mais facilidade e
35
tem acesso a muito mais informações úteis se comparadas com as pessoas que
não dominam o inglês. Esta situação lança um novo desafio: as aplicações Web
tem que direcionar o foco para métodos e regras que visam a
"internacionalização". Essa mudança de foco é um passo em direção a
implementação de aplicações Web que atinjam alcance global.
O principal desafio para a comunidade de software, tanto em
desenvolvimento Web quanto no desenvolvimento tradicional de software, é
entender melhor e aplicar com eficiência, as novas lições aprendidas sobre os
processos de criação do software.
36
3.0- MATERIAL E MÉTODOS
Este trabalho, voltado para a área de Tecnologia da Informação, tem
como foco a tecnologia .NET e foi desenvolvido, no período de Maio de 2002 a
Novembro de 2002, com base em pesquisa bibliográfica e documental. Foram
consultadas publicações dos mais diversos tipos: livros, revistas especializadas e
artigos disponibilizados na Internet.
Espera-se que o trabalho apresente os principais pontos desta tecnologia
e da estratégia da Microsoft .NET.
37
4.0- A PLATAFORMA .NET
4.1- Estratégia .NET
A computação caminha para um cenário que sobrepõe o modelo
desktop. Este novo cenário implica em notebooks, celulares e palmtops
conectados à Internet. Neste novo modelo de computação a informação e os
recursos de software não estarão exclusivamente em discos, mas distribuídos em
intranets, extranets e até mesmo na Internet. O ponto máximo é que o usuário
acessa todos os recursos (informações e aplicativos) em computadores móveis.
Do ponto de vista do software empresarial, os aplicativos serão implementados
visando acessibilidade praticamente ilimitada, isto é, todos os departamentos da
empresa, parceiros e clientes acessam o sistema pelo browser.
A plataforma .NET foi projetada para atender à visão corporativa da
Microsoft, que consiste em dar autonomia às pessoas “através do uso de
software a qualquer hora, em qualquer lugar e em qualquer dispositivo”.
Portanto, as tecnologias .NET abrangem clientes PC e móveis.
Quando a Microsoft formulou a estratégia .NET, no final dos anos 90, a
empresa não passava exatamente bom período:
O Java ganhava terreno rapidamente do lado servidor e se tornava
uma alternativa viável para a arquitetura de servidor Microsoft.
Os analistas da indústria de computação previam a substituição do
modelo tradicional de desktop PC da Microsoft (com Office
executando em Windows) pelo modelo de computação orientado a
Internet (em que predominam os clientes de rede).
As vendas de PC caíram, enquanto as vendas de dispositivos pós-PC
cresceram em ritmo acelerado.
38
O mercado de software passava pelo crescimento exponencial de
produtos de arquitetura aberta e gratuitos para sistemas operacionais,
servidores Web, sistemas de gerenciamento de banco de dados e
aplicativos de produtividade em desktop. Atualmente esses modelos
alternativos incluem Linux, Samba, Apache, PostgreeSQL, Star
Office e Open Office. À época, todos esses sistemas, a plataforma
Java e o Open Source ameaçavam transformar áreas chave do
desenvolvimento de software em serviços gratuitos, compensando o
valor da criação do software com os serviços de suporte e
manutenção.
A Microsoft traçou a estratégia .NET para responder a esses desafios,
presumindo que as arquiteturas de todos os aplicativos futuros serão baseadas
em Extensible Markup Language (XML) e Web Services3. A plataforma .NET
está diretamente ligada a XML e a Web Services que levam, necessariamente, ao
uso de um modelo computacional baseado em padrões Internet, comunicação
entre aplicativos e independência de tecnologia. Pontos principais da plataforma
.NET:
O padrão XML tem a capacidade de troca de mensagens entre
sistemas, com base nesta linguagem muitas empresas conseguem a
3
Web Services: componentes de software que se comunicam com outros aplicativos
codificando mensagens em XML e as enviando através de protocolos padrão da Internet
(como HTTP, SMTP, FTP etc). Intuitivamente, um Web Service é como um site Web
sem interface com o usuário, servindo aplicativos ao invés de pessoas. Em vez de
receber pedidos de navegadores e devolver páginas Web como resposta, um Web
Service recebe um pedido através de uma mensagem formatada em XML de um
aplicativo, realiza uma tarefa e devolve uma mensagem de resposta também formatada
em XML para o aplicativo.
39
integração entre sistemas implementados em diferentes plataformas
de hardware e software.
Todas as ferramentas Microsoft .NET foram construídas com base
em XML, possibilitando a implementação e o suporte a sistemas
orientados a Web. Nesses sistemas, sites e serviços permitem a
interação altamente transparente com quaisquer outros serviços.
Tem-se facilidade para transformar os dados XML em diferentes
formatos para exibição, como HTML para os mais diversos
browsers, WML para celulares WAP, além de outros padrões
específicos disponíveis no mercado. Dessa forma, um dado XML,
produzido por uma empresa ou por um serviço, disponível na Web
poderá ser visualizado e editado pelos mais diferentes dispositivos
como celulares, palms, agendas eletrônicas e, é claro, pelo browser.
A Microsoft promove a plataforma de desenvolvimento .NET para uma
nova classe de aplicativos: os Web Services, ou aplicativos para servidores que
trocam dados formatados em XML com outros aplicativos através da Web. Isso
porque a empresa considera os Web Services uma forma de baixo custo para a
integração de aplicativos entre empresas. Além disso, ela espera que os Web
Services sejam o novo tipo de aplicativo “obrigatório” que leve os profissionais
a desenvolverem soluções baseadas na plataforma .NET; da mesma forma que
os aplicativos para desktop com interface gráfica de usuário os levaram a
desenvolver produtos com base nas primeiras versões do Windows.
Com a plataforma .NET, a Microsoft espera manter sua enorme base de
desenvolvedores em Windows, que poderiam, de outra forma, migrar para outras
plataformas, atraídos pela promessa de independência de hardwares e de
sistemas operacionais, feita pela plataforma Java. [CHERRY, 2001] explica que
os desenvolvedores não produzem lucros para a Microsoft ou para qualquer
40
outra empresa, entretanto, os desenvolvedores Windows são importantes
defensores dos produtos Microsoft (como o próprio Windows) dentro das
empresas e os desenvolvedores de software comerciais constituem uma
importante interface para a oferta de produtos Microsoft aos consumidores.
A plataforma .NET exige que programadores e gerentes de projeto
dominem APIs e linguagens de programação essencialmente novas e com
curvas de aprendizado acentuadas. Além disso, a migração para a
plataforma .NET tem o risco de estar usando tecnologias recém-lançadas
em sistemas de produção críticos. Portanto é essencial pensar nas formas
de usar as capacidades da .NET para traçar um caminho de migração
gradativo. Mas o principal risco para as empresas é que a plataforma
.NET pode atá-las ao sistema operacional Windows e aos produtos para
servidores Microsoft .NET.
4.2- A programação na Plataforma .NET
4.2.1- Um novo modelo de programação
Todos os aplicativos criados na Plataforma .NET precisam de dois
componentes principais para serem executados.
O CLR (Common Language Runtime): um conjunto de rotinas que
carrega aplicativos, confirma que eles podem ser executados sem erros, verifica
as condições de segurança apropriadas, executa aplicativos e faz a “coleta de
lixo” depois de terminado o processo.
As bibliotecas de classe do .NET Framework que oferecem aos
programadores os componentes de software de que necessitam para escrever
programas que rodem sob o controle do CLR (o chamado “código gerenciado”).
41
Esses dois componentes oferecem uma enorme gama de funções (de
sistemas de arquivos e acesso a redes até funcionalidades XML) em uma única
hierarquia organizada logicamente.
Os aplicativos Web para servidores podem usar o ASP.NET, uma
biblioteca de classe especializada para criar esses aplicativos, além de conteúdo
Web dinâmico. O ASP.NET não é necessário para aplicativos desktop.
O CLR tem dois objetivos principais:
Melhorar a confiabilidade e a segurança dos aplicativos;
Reduzir o volume de códigos de baixo nível, tediosos e sujeitos
a erros, que os desenvolvedores de aplicativos precisam escrever.
Esses objetivos são semelhantes aos problemas que empresas como Sun
e IBM estão tentando atacar com a plataforma Java em Unix e mainframes
[CHERRY, 2001]. Para resolver esses problemas no Windows, o CLR faz
modificações fundamentais no modelo de programação e na forma de
carregamento e execução de aplicativos.
Um aplicativo chega ao CLR como um arquivo ou conjunto de arquivos
chamado assembly. A parte principal do assembly é o código escrito em MSIL
(Microsoft Intermediate Language), que o CLR traduz em código nativo
executável. O controle na tradução de aplicativos de MSIL para o código nativo
permite ao CLR gerenciar a execução do aplicativo e impedir muitos tipos de
problemas, daí o nome código gerenciado.
Além do código MSIL, um assembly contém metadados que descrevem
em detalhes os tipos e componentes relevantes que o código MSIL exige para
ser corretamente executado. Finalmente, um assembly contém um manifesto,
documento que lista todos os arquivos e componentes de software contidos no
42
assembly, e indica onde o CLR deverá procurar outros assemblies com
componentes que o aplicativo necessita para execução.
Para carregar um aplicativo, o CLR usa o manifesto do assembly para
localizar a versão correta dos assemblies que o aplicativo necessita. O CLR
examina, então, todo o assembly do aplicativo (isto é, o próprio código MSIL e
os metadados que o descrevem) para confirmar que o código é “type-safe”, o
que significa que ele executa apenas as operações apropriadas em certos tipos de
dados (não permite que o programador use um número inteiro para um ponteiro
de função, por exemplo) e que vai acessar apenas as posições da memória que
está autorizado a acessar.
O CLR então carrega o MSIL do assembly do aplicativo e, ao faze-lo,
coleta “evidências” sobre o assembly, como:
De onde foi baixado e instalado;
Que funções ele precisa executar (se ele precisa gravar arquivos
em disco ou enviar e-mail, por exemplo);
Que usuário está tentando executa-lo;
Se o assembly possui uma assinatura digital válida de um
desenvolvedor autorizado, e se o assembly foi alterado desde que
assinado digitalmente.
Essas evidências são a base para a segurança no .NET Framework, o que
permite ao CLR determinar se deve executar o aplicativo e que permissões ele
deve ter enquanto roda.
Em seguida, o CLR traduz o código MSIL em código nativo que pode
ser executado pelo processador. (A Microsoft se refere a isso como “código
nativo gerenciado”, diferentemente de “código nativo não-gerenciado”, escrito
em uma linguagem mais antiga como C++ e sobre o qual o CLR não tem
43
controle.) Um recurso chamado compilação JIT (Just-in-Time) permite que o
CLR adie o processo de tradução até que ele seja realmente necessário, o que lhe
permite
evitar
traduzir
códigos
usados
esporadicamente.
(Para
uma
representação gráfica desse processo, veja a ilustração em anexo “Executando
código gerenciado”.)
Finalmente, o CLR monitora o código traduzido durante a execução e
limpa periodicamente a memória quando o aplicativo a libera (um processo
conhecido como “coleta de lixo”).
Uma outra função muito importante realizada pelo CLR é fazer a
mediação entre o código gerenciado e o código não-gerenciado (isto é, o código
condicional do Windows que roda fora do CLR). Portanto, o CLR permite aos
programadores combinar novos programas .NET com bibliotecas do Windows e
componentes já existentes, movendo um aplicativo gradualmente da antiga para
a nova plataforma. (Veja, em anexo, a ilustração “Misturando código gerenciado
e não-gerenciado”. )
Mas é importante notar que o código não-gerenciado é executado fora do
controle do CLR e, portanto, pode causar falhas no aplicativo, escape de
memória ou abrir brechas de segurança através de estouros de buffer. Um
aplicativo .NET é, no máximo, tão forte quanto seu elo mais fraco (seu código
não-gerenciado) [CHERRY, 2001].
Mudando o foco para as bibliotecas de classe do .NET Framework, elas
fornecem o código básico exigido por quase todos os aplicativos. Como as
bibliotecas de código fornecidas no Windows e em seus SDKs, as bibliotecas de
classe permitem que os desenvolvedores se concentrem em escrever os códigos
exclusivos de seus aplicativos, ao invés de escrever código repetidamente para
funções freqüentes como ler arquivos [CHERRY, 2001].
As bibliotecas de classe também solucionam um problema sério com as
bibliotecas de código atuais do Windows: o excesso de interfaces de
44
programação de aplicativos (APIs) e SDKs que foram surgindo à medida que a
Microsoft foi adicionando funcionalidades ao Windows [CHERRY, 2001]. As
bibliotecas de Java, em suas várias “edições”, tentam atacar um problema
semelhante e talvez mais grave nos sistemas operacionais não Windows, ou seja,
a incrível variedade de APIs de vários fornecedores para funções básicas como
entrada e saída de arquivos e mensagens [CHERRY, 2001].
Todo código gerenciado é organizado em grupos lógicos denominados
classes (daí o nome bibliotecas de classe), arranjadas em hierarquias chamadas
namespaces.
As bibliotecas de classe do .NET Framework caem no namespace
System. Para simplificar a tarefa de encontrar a classe de que um desenvolvedor
precisa, esse namespace é arranjado em uma hierarquia conforme sua função.
Por exemplo, dentro de System fica System.Data, que contém classes para API
de acesso a dados ADO.NET. O próprio System.Data inclui um conjunto de
classes chamado System.Data.Oledb, que suporta o acesso a banco de dados e
outras fontes de dados que têm um provedor de dados .NET OLE DB do
Windows, e System.Data.SQLClient, que suporta acesso ao SQL Server.
Algumas classes System fornecem funcionalidades anteriormente
disponíveis através da API do Windows ou funções específicas de linguagens,
mas outras classes são totalmente novas, como System.Reflection, que permite
ao código gerenciado obter informações do assembly, como seus metadados.
Os desenvolvedores podem definir classes personalizadas, estendendo as
das bibliotecas base. Também podem definir namespaces proprietários que
sejam globalmente exclusivos, fazendo com que suas classes não entrem em
conflito com as da Microsoft ou de outras organizações.
Finalmente, as bibliotecas de classe tem a vantagem de incluir as funções
mais freqüentemente usadas da principal API do Win32 e de inúmeros SDKs
adicionais em um pacote unificado.
45
A meta principal da CLR é simplificar o processo de implementação de
componentes e aplicações a partir de qualquer linguagem de programação, tendo
como alvo qualquer plataforma de hardware [GUTIERREZ, 2001]. Para atingir
essa meta, no Framework .NET, os compiladores não geram código nativo,
dependente de plataforma. Eles simplesmente fazem a conversão do códigofonte da linguagem de programação em um conjunto de instruções da linguagem
MSIL. Os arquivos resultantes não são os velhos executáveis (.exe) do
Windows. A Microsoft os chama arquivos PE (Portable Executable), já que são
independentes da plataforma de hardware. Então, o primeiro serviço prestado
pelo CLR é a tradução do código intermediário MSIL gerado pelos
compiladores das linguagens de programação em código nativo executável. A
tradução não é feita instrução a instrução, como nos interpretadores, mas de uma
única vez, em tempo de start-up.
Código-fonte em
uma dada
linguagem de
programação
Compilador
Código Intermediário MSIL
CLR
Figura 1: Compilação e execução de um aplicativo .NET
Esse processo garante que os programas desenvolvidos na plataforma
.NET executem sobre qualquer plataforma de hardware e possam interagir entre
46
si, mesmo quando desenvolvidas em linguagens de programação diferentes.
Além disso, este processo possibilita a otimização para cada plataforma de
hardware.
Naturalmente, o processo de tradução em tempo de execução, exige alta
disponibilidade de recursos (memória e capacidade de processamento) para ser
realizado com eficiência. Visando reduzir esse consumo de recursos, a Microsoft
projetou o OptIL (Optimized Intermediate Language), um subconjunto de
instruções MSIL, convertido em código nativo com muito mais velocidade.
É importante lembrar que a estratégia da Microsoft é atingir também a
computação móvel (PDAs, handhelds, telefones etc). Nestes ambientes, as
capacidades de memória e processamento são muito limitados. Além disso,
[GUTIERREZ, 2001] lembra que as limitações naturais dos dispositivos
implicam na redução de funcionalidades. (Para que serve uma interface de
janelas e botões em um telefone celular, se não há um display suficientemente
visível?) Essa redução natural de funcionalidades implica que um conjunto
razoável de instruções pode ser simplesmente removido da MSIL, para se formar
o OptIL.
A MSIL tem suporte a um conjunto de instruções completo e foi
projetada para atender tanto aos requisitos da CLR quanto os requisitos das
linguagens e ambientes de programação existentes. É claro que especial atenção
foi dada aos produtos da Microsoft, a começar pelo Visual Basic; no entanto, as
abstrações MSIL possibilitam que a grande maioria das linguagens existentes
possa ser estendida e seus compiladores adaptados a gerar código MSIL.
Existem projetos, já em estágio avançado, para implementar compiladores
COBOL, Pascal, Eiffel, Haskell e Pearl.
As empresas normalmente precisam dividir projetos em partes, fazendo
com que algumas delas sejam desenvolvidas por programadores em C++ e
outras por programadores em VB, por exemplo [CHERRY, 2001]. A falta de
47
programadores para uma dessas linguagens é um impacto negativo para os
planos da empresa. O .NET Framework combate o problema das linguagens de
duas formas:
Tipos de dados padrão: Em primeiro lugar, o .NET Framework
oferece operações e representações internas padrão para os tipos de
dados mais usados (como números inteiros, números reais e strings).
Esse conjunto de tipos de dados padrão (chamado de Common Type
System – CTS) elimina a necessidade de cada linguagem
implementar tipos de dados em sua própria forma exclusiva e
incompatível.
Formato de aplicativos padrão: O .NET Framework implementa
um formato de aplicativos padrão (o assembly contendo o MSIL,
metadados e o manifesto). Os compiladores de todas as linguagens
de programação .NET geram este formato. Extraindo informações
sobre o MSIL nos metadados, ferramentas como compiladores,
depuradores e geradores de perfil podem analisar e trabalhar com os
dados independentemente da linguagem de programação original.
Os formatos de aplicativos e tipos de dados padrão permitem aos
desenvolvedores criarem bibliotecas de classe que funcionam com qualquer
linguagem de programação que entenda formatos e tipos de dados; isso inclui
todas as linguagens de programação .NET da Microsoft, assim como várias
outras linguagens. Em particular, as bibliotecas de classe do .NET Framework
usam apenas tipos de dados CTS e são distribuídos no formato padrão de
aplicativo. Como resultado, essas bibliotecas de classe podem ser usadas por
aplicativos em qualquer linguagem de programação .NET. (Veja a ilustração
“Desenvolvendo código gerenciado” em anexo.)
48
Concluindo, o CLR e as bibliotecas de classe dão à Microsoft uma
plataforma de execução única, que suporta múltiplas linguagens de
programação. Além disso, as bibliotecas de classe oferecem a todas as
linguagens de programação .NET aproximadamente o mesmo conjunto de
funções básicas, o que permite aos programadores trabalharem com a linguagem
com a qual se sentem mais confortáveis.
4.2.2- As linguagens de programação na plataforma .NET
Ao contrário da mudança da API de Win16 para Win32 em 1993, a
mudança de Win32 para a plataforma .NET inclui alterações em linguagens e
ferramentas existentes, e linguagens inteiramente novas. Como conseqüência, as
organizações que decidirem usar a plataforma .NET terão não só de mudar a
estratégia de plataforma, mas também repensar a estratégia de linguagens e
ferramentas.
Três novas versões das linguagens de programação da Microsoft darão
suporte ao CLR e às bibliotecas de classe: Visual Basic .NET, Visual C++ e
JScript .NET. Eles contarão com duas novas linguagens: Visual C# (C-Sharp) e
Visual J#, que permite aos desenvolvedores em Visual J++ criar código
gerenciado usando a sintaxe já conhecida: Java.
Para suportar diferentes linguagens, diferentes programadores com
conjuntos de conhecimentos diferentes criam componentes usando a linguagem
que conhecem melhor. Na plataforma .NET todos esses componentes funcionam
perfeitamente uns com os outros. Mas isso dá margem à pergunta: Como os
gerentes de desenvolvimento e projeto escolhem a linguagem a ser usada em
seus aplicativos? (Para um guia rápido para escolher uma linguagem para
desenvolvimento em .NET, leia “Regras práticas para a seleção de uma
linguagem .NET”, em anexo).
49
O MSIL é o denominador comum de todas as linguagens de
programação da .NET e, na teoria, construções equivalentes em duas linguagens
diferentes deveriam produzir um IL idêntico. Como resultado, todas as
linguagens de programação são idênticas no desempenho e na alocação de
recursos.
Visual Basic .NET: Linguagem com sintaxe muito próxima à
linguagem do VB, foi projetada para promover a migração dos
desenvolvedores em VB para a plataforma .NET. Mas o VB .NET
significa uma grande alteração em relação a versões anteriores de VB, e
não é compatível com aquelas. A Microsoft disponibiliza uma
ferramenta para a migração de programas fonte de VB para VB .NET
incluída no Visual Studio .NET, mas esse processo não pode ser
totalmente automatizado. Os desenvolvedores terão de inspecionar
manualmente o código migrado, reescrever algumas seções e testar
cuidadosamente os resultados. A Microsoft afirma que desenvolvedores
em VB com experiência principalmente em componentes VB devem
usar o VB .NET para novos aplicativos ao invés de migrar para C#. Ao
passo que programadores em VB avançados que provavelmente criarão
componentes que serão usados por outros programadores da equipe (que
talvez continuem usando VB .NET), devem considerar os benefícios de
migrar para C#.
Visual C++: Linguagem de programação existente para a
criação de código de baixo nível e programadores para Windows
(código não-gerenciado), continuará a existir e será atualizado para
suportar a plataforma de desenvolvimento .NET (código gerenciado). O
C++ tem uma posição única no mundo .NET. Todas as outras
linguagens da Microsoft requerem uma migração completa para a
50
plataforma .NET. Por exemplo, não é possível usar o VB .NET para
criar um componente ao estilo VB que execute no velho ambiente do
VB, nem é possível compilar diretamente um aplicativo em C# para
instruções nativas da Intel. O Visual C++, no entanto, continua tendo
um compilador nativo. Esse fato, somado com a capacidade do CLR de
conectar novos códigos gerenciados a códigos não-gerenciados
existentes, implica que os programadores em C++ continuam a usar
exatamente a mesma linguagem e o mesmo ambiente que usavam no
passado. Mesmo com as extensões gerenciadas, a criação de código nãogerenciado no Visual C++ será difícil e com erros em potencial, devido
às diferenças entre os tipos de dados da plataforma .NET e os do C++.
Isso significa que os desenvolvedores deverão usar o Visual C++ como
usam o C++ hoje, para escrever código não-gerenciado, como drivers de
dispositivo, além de usar as extensões gerenciadas para permitir que
esse código opere em conjunto ou incorpore código gerenciado de outras
fontes.
JScript .NET: Mais atraente para os desenvolvedores Web para a
criação de scripts de clientes em navegadores Web.
Visual C#: Devido a dificuldade para se criar código gerenciado
em Visual C++, a Microsoft criou uma linguagem similar: Visual C#,
especificamente para criar código gerenciado. C# é uma linguagem da
Microsoft que foi criada a partir do zero para ser usada especificamente
com o CLR; a própria empresa está usando C# para criar código
gerenciado em subsistemas como as bibliotecas de classe e o ambiente
ASP.NET de desenvolvimento para Web. De fato, enquanto dar suporte
a múltiplas linguagens era a principal meta de design do CLR, é
razoável dizer que o C# e o CLR foram efetivamente projetados juntos,
e que o projeto de cada um teve impacto no outro [CHERRY, 2001]. O
51
C# é bem mais simples que o C++, mas ele ainda está firmemente
enraizado na família “C” de linguagens de programação. Isso significa
que ele herda certas características que as linguagens como VB não
possuem. Por exemplo, o C# é case sensitive, exige que os
programadores façam conversão explícita entre os tipos de dados,
enquanto o VB faz conversões automaticamente. O C# inclui suporte
para criar código gerenciado que tem acesso mais direto à infra-estrutura
da plataforma .NET, por exemplo, os desenvolvedores podem acessar a
memória de um buffer usando ponteiros. A Microsoft preferiu não
incluir esses recursos no VB.NET, pois faze-lo complicaria a linguagem
VB para o benefício de um grupo muito pequeno de programadores
avançados em VB. Portanto, o C# será mais atraente para os
programadores que já trabalham em Visual C++ ou Java, ou para
programadores avançados em VB que desenvolvem componentes e
precisam de uma linguagem de fácil assimilação que explora o CLR e as
bibliotecas de classe. O C# combina a potência do C++ com a facilidade
do VB6, oferecendo um código tipo C++ legível e compatível com o
CLR. Além disso o C# é uma linguagem puramente orientada a objetos
e permite que o programador escreva um código compreensível e
reutilizável.
Visual J# .NET: Uma nova linguagem que dá aos programadores
um caminho de migração do ambiente Java existente no Visual J++ para
a nova plataforma .NET. Permite aos programadores criarem aplicativos
usando a sintaxe Java, mas os aplicativos resultantes usam as bibliotecas
de classe do .NET Framework e o CLR ao invés das APIs Java 2 da Sun
e da JVM. É importante destacar que o Visual J# .NET não usa a
tecnologia Java da Sun, e os aplicativos poderão não ser facilmente
portáveis para esta.
52
4.2.3- Visual Studio .NET: ambiente de programação na plataforma
.NET
Em fevereiro de 2002, a Microsoft lançou a versão final do Visual
Studio .NET, seu conjunto oficial de ferramentas de desenvolvimento de
software para a criação de aplicativos .NET. O VS.NET oferece aos
desenvolvedores a primeira visão detalhada das mudanças revolucionárias que a
Microsoft está fazendo em suas linguagens e resolve simultaneamente muitos
problemas que impediram os desenvolvedores envolvidos na criação de
aplicativos de usar as ferramentas da Microsoft no passado [LOWY, 2002]. Com
as melhorias incluídas na depuração e a forte integração das ferramentas de que
os desenvolvedores precisam em um único ambiente, o VS.NET terá um
impacto significativo no desenvolvimento de aplicativos Web [DREWANZ,
2002].
O VS.NET oferece ferramentas gráficas que facilitam localizar
componentes de código, acompanhar tarefas, editar e compilar códigos, conduzir
depurações e organizar o trabalho de desenvolvimento. Empacotando novas
ferramentas, assistentes, recursos e enfoques de desenvolvimento em um
ambiente de arrastar-e-soltar já conhecido, o VS.NET exigirá um aprendizado
substancial para dominar todas as suas vantagens, mas deve servir ao propósito
de atrair a base de desenvolvedores da Microsoft existente para a plataforma
.NET.
O conceito principal do VS.NET é a integração. O mesmo ambiente de
desenvolvimento é usado por todas as linguagens .NET, e o IDE pode exibir
praticamente qualquer informação relacionada a desenvolvimento, como
processos de sistema, threads, filas de mensagens, contadores de desempenho,
serviços de sistema, Web Services, applets de painel de controle, tabelas de
53
banco de dados e resultados de pesquisas. Um recurso interessante do VS.NET é
que ele verifica constantemente o que foi digitado, se encontrar um problema de
compilação, ele sublinhará o código da mesma forma que o verificador
automático de um editor de textos faz quando digita-se uma palavra incorreta.
Uma outra funcionalidade, também importante, é uma janela de ajuda especial
que mantém um registro das atividades desenvolvidas e sugere links de ajuda
relevantes.
4.2.4- Programação Web: ASP.NET
Facilita a criação de conteúdo Web dinâmico e de aplicativos Web mais
elaborados e confiáveis, como os Web Services. O ASP.NET é uma parte
essencial da plataforma de desenvolvimento .NET da Microsoft e para que a
estratégia da empresa seja atingida com sucesso ela precisa convencer os
desenvolvedores a adotarem a plataforma .NET, incluindo o ASP.NET
[CHERRY, 2001]. Ainda que os programadores que adotaram o ASP.NET
estejam relatando benefícios substanciais, os desenvolvedores terão de levar em
conta as diferenças no modelo de programação e o suporte a linguagens para
migrar do Active Server Pages (ASP) para o ASP.NET [CHERRY, 2001].
O ASP.NET implementa um modelo de programação “orientada a
eventos” no qual os desenvolvedores adicionam controles a um formulário e
escrevem código para manipular os eventos (como a entrada de dados em uma
caixa de textos ou o clique em um botão) associados a esses controles. Também
torna mais fácil para os desenvolvedores criarem serviços que trocam dados em
XML, permitindo a eles basearem-se no suporte a XML exposto pelas
bibliotecas de classe do .NET Framework.
O ASP.NET é a parte da plataforma .NET voltada à criação de
aplicativos Web hospedados no Microsoft IIS, e usa protocolos da Internet como
54
HTTP e SOAP. O ASP.NET facilita o desenvolvimento e a implantação de dois
tipos de aplicativos Web:
Aplicativos Web Form, incluindo páginas Web geradas a partir
de scripts para conteúdo dinâmico e páginas Web que expõem o
formulário a um cliente como o navegador.
Web Services que expõem funcionalidades a outros aplicativos e
a clientes “inteligentes” e permitem aos aplicativos trocar informações.
Ambos os tipos de aplicativos Web têm em comum uma vantagem
principal em relação aos aplicativos tradicionais: usam protocolos baseados na
Internet para permitir que as informações se movimentem tão facilmente através
das fronteiras organizacionais (e firewalls) quanto se movimentam dentro da
organização [GUTIERREZ, 2001].
Com o ASP, lançado pela Microsoft em 1996, um programador com
experiência em HTML e em criação de scripts podia desenvolver conteúdo Web
dinâmico com facilidade.
Mas o desenvolvimento de um serviço de formulário Web poderoso e
estável continuava muito difícil devido ao modelo de objeto limitado, aos
recursos limitados das linguagens de script, às ferramentas limitadas para
depuração de aplicativos e ao requisito para fazer chamadas no nível da API
para analisadores (parsers) e kits XML externos.
Incorporando o ASP.NET à plataforma .NET, a Microsoft oferece aos
desenvolvedores as vantagens da CLR e das bibliotecas de classe [GATES,
2001]. O ASP.NET usa o CLR para compilar o código e gerenciar a execução,
criando aplicativos Web que rodam com melhor performance e são mais
confiáveis [LOWY, 2002]. Além disso, o ASP.NET usa as bibliotecas de classe
para facilitar aos desenvolvedores incorporar dados formatados em XML em
55
aplicativos Web e adicionar código para manipular exceções, criar elementos da
interface com o usuário e oferecer funcionalidades de programação [CHERRY,
2001].
O ASP.NET usa a tecnologia de acesso a dados do ADO.NET (Access
Data Object), uma biblioteca de classes com funcionalidades para acesso a
fontes de dados como arquivos e bancos de dados. O ADO.NET é baseado em
um modelo de objetos orientado e otimizado para acesso remoto desconectado a
fontes de dados na Internet. Isso é possível porque o ADO.NET armazena em
cache partes inteiras de um banco de dados e executa a sincronização depois que
as alterações forem efetuadas.
É importante destacar que as páginas Web desenvolvidas em ASP.NET
tem muito mais desempenho se comparadas às páginas em ASP, afinal o
ASP.NET é compilado.
4.2.5- Visão geral dos Servidores .NET
A plataforma .NET é orientada por uma visão estendida e de longo
prazo do software como serviço. Essa visão descreve como o software deve ser
projetado, desenvolvido e distribuído. É uma combinação de tecnologias e
padrões Web, tecnologias inteligentes de cliente e de cliente/servidor
tradicionais, todas interligadas ao XML. A visão da .NET apresenta um mundo
onde as informações pessoais e corporativas encontram-se disponíveis a
qualquer momento, de qualquer lugar, num formato aberto e seguro [GATES,
2001].
Os Servidores Corporativos .NET são totalmente integrados ao
Windows, ao mesmo tempo, compatíveis com XML. Portanto fornecem um
conjunto abrangente de serviços que serão utilizados na criação de aplicativos no
.NET Framework.
56
O Commerce Server inclui tabelas SQL para criar aplicativos com
serviços de autenticação, autorização, personalização, busca, gerenciamento de
carrinhos de compras, perfil de usuário, gerenciamento de produtos, marketing e
processamento de transações. Contém também um conjunto de modelos de
páginas Web que o desenvolvedor pode personalizar a medida que cria seu
aplicativo.
O Host Integration Server possibilita a integração dos aplicativos .NET
com os dados e aplicativos de computadores e mainframes.
O Internet Security and Acceleration Server fornece uma combinação de
servidor proxy Internet e cache da Web.
O Móbile Information Server (MI) é um servidor de aplicativos que
proporciona aos usuários acesso a dados corporativos e a e-mails a partir de seus
dispositivos sem fio.
O SharePoint Portal Server proporciona mais controle sobre o
compartilhamento de documentos e outras informações em toda a organização.
O BizTalk Server é usado principalmente para aceitar documentos de
dados de outros aplicativos ou empresas e traduzi-los para o XML.
Em
contrapartida é possível fornecer dados a outros aplicativos ou empresas em
vários formatos.
O SQL 2000 Server é um servidor de banco de dados relacional que
possui muitos de alguns dos melhores índices de desempenho. Tem recursos de
data warehouse, análise de dados e processamento analítico on-line (OLAP) para
utilizar de forma eficiente os dados armazenados no banco de dados.
Passando o foco para os sistemas operacionais, tanto o Solaris como o
HP/UX são sistemas operacionais “abertos” executados em hardware
proprietário. Historicamente, esse status lhes deu vantagem no quesito
estabilidade, pois os fornecedores de sistemas operacionais não precisam se
preocupar com memória RAM, com placas de vídeo, de fax, de rede e outros
57
componentes de hardware. O Windows, por outro lado, é um sistema
operacional proprietário executado em hardware “aberto”; isso significa que a
Microsoft precisa garantir suporte a máquinas com combinações completamente
aleatórias de placas-mãe, memória e periféricos.
Muitos dos servidores .NET tem licença para executar exclusivamente
em configurações de hardware conhecidas e testadas. Isso nivela o campo,
quando esse sistema é comparado com sistemas Solaris e HP/UX, pois todos
eles são executados em configurações de hardware conhecidas.
4.2.6- Web Services e SOAP: a interoperabilidade entre plataformas
Muitas empresas tentam conciliar tempo e esforço na tentativa de
adquirir independência de plataformas ou compatibilidade entre plataformas.
Para conseguir isso, é preciso escolher entre lidar com os problemas
relacionados ao desempenho e a dificuldade de tentar escrever um código
totalmente independente de plataforma ou escrever um código para uma
plataforma de cada vez e aplicar outra tecnologia para conseguir a
interoperabilidade entre sistemas.
Para escrever um código independente de plataforma, é preciso usar uma
combinação de linguagens como Java ou C++ (portáveis em qualquer
plataforma) e CORBA4 (ou tecnologias similares para uma solução de objetos
distribuídos5). Mas [GUTIERREZ, 2001], ressalta que essa combinação
proporciona
menos
suporte
integrado
na
área
de
ferramentas
de
desenvolvimento e apresenta muitos problemas de interoperabilidade.
4
Common Object Request Broker Architecture (CORBA). Uma arquitetura definida
pelo Object Management Group (OMG) para dar suporte ao desenvolvimento de
aplicações distribuídas implementadas em diferentes plataformas e linguagens.
5
Objetos distribuídos: compreendem tecnologias que possibilitam a comunicação
remota entre objetos instalados em diferentes sistemas.
58
O protocolo SOAP e dos Web Services abrem um novo campo para a
interoperabilidade entre plataformas, enquanto tira proveito das melhores
tecnologias e ferramentas de cada plataforma. Na plataforma .NET podem ser
criados aplicativos clientes para sistemas residentes em plataformas Windows
que se comunicam com software escrito em outros sistemas ou que utilizam
arquiteturas e linguagens diferentes. O SOAP é o elo de ligação entre esses
sistemas.
Empresa
Fornecedores
Interoperabilidade
entre sistemas e
plataformas
Parceiros
Clientes
Figura 2: Integração entre vários sistemas e plataformas diferentes através de
objetos distribuídos que, atualmente, pode ser conseguida com a tecnologia de
Web Services.
A solução de integração entre sistemas tradicional é implementá-los em
uma linguagem portável com C++ ou Java e aplicar serviços CORBA. Seguir
por esse caminho, no entanto, exige muito tempo de desenvolvimento e uma
equipe de desenvolvedores que compreendam a complexidade de aplicações
distribuídas. Portanto é uma solução de alto custo. Os Web Services e o
protocolo SOAP apresentam uma solução muito mais simples e econômica para
a interoperabilidade entre plataformas. É suficiente ligar um Web Service .NET
a um cliente Java ou de qualquer outra plataforma ou, ao contrário, consumir um
Web Service em um aplicativo .NET independente das plataformas de hardware
e software e da linguagem de programação em que foi implementado esse Web
Service.
59
Client SOAP
HTTP request
ASP.NET
Mensagem SOAP
HTTP
response
Objeto .NET
Figura 3: Esquema geral da chamada remota de um Web Service.
4.2.7- XML e SOAP
Um sistema bancário é totalmente online para a troca de informações
entre agências e o Banco Central. Do ponto de vista de [GUTIERREZ, 2001],
esse é um problema complexo, visto que são milhares de agências com sistemas
e plataformas de hardware e software totalmente diferentes.
Com o modelo tradicional de construção de aplicações essa é uma tarefa
impossível, porque implica na construção de um único sistema gigante,
totalmente online, que contém a interface entre agências e todos os sistemas
internos [GUTIERREZ, 2001].
Para uma solução simples é preciso especificar um protocolo de
comunicação. Para tanto é necessário um formato específico de mensagem para
que todos os sistemas distribuídos envolvidos possam interpretá-lo corretamente.
Com XML é possível definir um documento que descreve a troca de mensagens
entre as agências. Como documentos XML são produzidos no formato texto,
60
qualquer aplicação executando em qualquer sistema operacional consegue
processá-lo, desde que conheça sua sintaxe. Além disso, como o documento
XML pode ser transportado por qualquer protocolo de comunicação de alto
nível, os meios de transmiti-lo são praticamente universais.
Data
base
Rela
tion
Table
Field
Name
Target
Table
Name
Source
Table
Name
Data
Type
Figura 4: Representação de um documento XML como uma árvore de
elementos (e atributos). A ilustração representa os elementos como nós contra
um fundo cinza e os atributos como nós contra um fundo branco. Nesta árvore,
um programa que precisasse obter o valor do elemento SourceTable deveria
percorrer o caminho Database\Relation\SourceTable para acessá-lo.
Um exemplo da aplicabilidade do XML no mundo real é o Sistema de
Pagamentos Brasileiro (SPB). Com base na troca de documentos XML, esse
sistema está em desenvolvimento acelerado. Além disso, analistas afirmam que
o XML se tornará, em pouco tempo, o padrão universal para a troca de dados
entre aplicações distribuídas.
61
Cardi
nality
Uma possível aplicação usando XML, como exemplo, é um serviço de
busca de notícias. Se todas as notícias estivessem em formato XML e se tais
documentos transportassem a informação e alguns metadados (contendo o
assunto da notícia, data da publicação, fonte etc.): seria possível implementar
uma aplicação para buscar, selecionar e exibir exclusivamente notícias de
interesse exclusivo do internauta. Isso com base em uma lista de sites
previamente definida, é claro. (As plataformas .NET e J2EE tem como meta
produzir infra-estrutura para a implementação de aplicações desse tipo).
Com o protocolo SOAP, é possível a uma aplicação chamar um método
de um objeto remoto utilizando um documento XML enviado através de um dos
protocolos de comunicação da Internet (HTTP, SMTP, FTP etc). Além disso, é
importante destacar, que uma aplicação com a capacidade de criar e interpretar
documentos SOAP tem a capacidade de chamar ou exportar métodos remotos,
independente da plataforma de hardware, sistema operacional ou linguagem de
programação utilizada.
62
HTTP
SOAP document
SOAP header
Delivery Info
SOAP body
Payload
Figura 5: Representação esquemática de uma mensagem SOAP. As mensagens
SOAP são enviadas em um pacote HTTP a partir do comando POST e consiste
simplesmente de um envelope (documento XML) e dois elementos
fundamentais: um Header, elemento opcional, e um Body, onde são passadas as
informações necessárias à chamada do método (seu nome e argumentos
eventualmente necessários).
No mundo orientado à Internet, a informação está distribuída em
milhares de computadores por todo o mundo, que utilizam plataformas de
hardware e software completamente diferentes. Uma parte substancial dessa
informação está publicamente disponível. No entanto, praticamente toda essa
informação aparece sob a forma de documentos HTML, linguagem ideal para
formatar e exibir textos, mas insuficiente para a comunicação entre aplicações.
A crescente demanda por soluções B2B e B2C assinala a exigência de
aplicações que localizem informações na Web. Se estas informações estiverem
disponíveis também sob a forma de serviços para outros computadores (e não
apenas aos leitores) então um novo patamar de aplicações e soluções Internet
estará disponível [GUTIERREZ, 2001].
Portanto tem-se, para as aplicações Internet, o problema de viabilizar a
comunicação entre as aplicações, para solicitar serviços e trocar informações. As
tecnologias mais importantes para essa finalidade são Distributed Component
Object Model (DCOM), Common Object Request Broker Architecture
63
(CORBA) e Remote Method Invocation (RMI). [GUTIERREZ, 2001], destaca
que o problema dessas tecnologias é que dependem fortemente da plataforma (é
o caso de DCOM), da linguagem de programação (é o caso de RMI que depende
da linguagem Java) ou de uma infra-estrutura complexa de software de suporte e
da implementação de protocolos próprios para transporte (é o caso de CORBA).
Considerando a densidade de plataformas computacionais e de
linguagens de programação disponíveis atualmente, a concepção de uma
aplicação deve levar em conta a possibilidade de utilização de componentes (ou
objetos) concebidos nas diferentes linguagens e com a capacidade de executar
em diferentes ambientes [SOUZA, 1999]. Visando a integração das aplicações
atuais, as plataformas .NET e J2EE proporcionam a implementação de Web
Services. Estes totalmente ligados a XML e SOAP.
4.3- Comparação entre a plataforma .NET e o J2EE
Como plataformas de aplicativos concorrentes, a plataforma de
desenvolvimento .NET da Microsoft e o Java 2 Enterprise Edition (J2EE) da
Sun são muito similares nas metas e na arquitetura, mas completamente
diferentes em suas implementações. Tanto a plataforma .NET, quanto a J2EE
não tem domínio fácil, o que significa que os desenvolvedores de software terão
que escolher entre as duas alternativas.
A plataforma .NET e o J2EE foram criadas com objetivos similares:
Melhorar a produtividade dos programadores oferecendo a eles
componentes pré-existentes que eliminam a necessidade de escrever
rotinas de baixo nível junto com um modelo de programação que
facilita a reutilização de componentes de código criados por outros
programadores.
64
Aumentar a confiabilidade eliminando ou reduzindo o uso de
algumas das construções mais sujeitas a erros de linguagens de
programação como C (como ponteiros para acesso direto à
memória), e usando modelos de programação que forçam todos os
pontos de interação entre componentes de código a serem
claramente definidos, o que isola o impacto dos erros e facilita sua
identificação.
Melhorar a segurança através do controle do que os aplicativos
podem e não podem fazer (como permissão para ler ou gravar em
disco) e o uso de assinaturas digitais durante a execução para
confirmar que o código foi criado por uma entidade confiável e que
permanece inalterado.
Simplificar a instalação e a implantação incorporando as
descrições de componentes (incluindo informações sobre versão) no
próprio código. Isso descarta a noção de obrigar os desenvolvedores
a "registrar" seus códigos no momento da instalação (a principal
causa da complexidade e da instabilidade das instalações) e
possibilita a instalação automática do software aplicativo, sob
demanda, com pouca ou nenhuma intervenção do usuário ou
administrador. No caso da plataforma .NET, isso também permite
que diferentes versões do mesmo componente coexistam em um
sistema sem interferir um com o outro ou com outros aplicativos.
Devido a essas metas análogas, as plataformas .NET e J2EE têm uma
arquitetura também similar. Os recursos de arquitetura correspondentes incluem:
Uma máquina virtual: projetada para inspencionar, carregar e executar
programas em um ambiente restrito (sandbox) estritamente controlado.
Colocando fortes limites sobre as ações que o código do programa pode e não
65
pode executar, esse ambiente restrito reduz as ameaças constituídas por
programas maliciosos (como vírus) e pelas ações inadvertidas de programas
confiáveis. Para permitir essa arquitetura de ambiente restrito, todos os
programas são compilados a partir de seu código original para uma linguagem
intermediária independente de processador (MSIL) ou bytecode Java. Esses
módulos de código intermediário são, então, traduzidos para código nativo por
um componente da máquina virtual denominado compilador JIT (Just-in-Time),
direcionado a um tipo específico de CPU e sistema operacional. A máquina
virtual também fornece aos programas serviços básicos como gerenciamento de
memória. A máquina virtual do .NET é a CLR. O J2EE usa a Java Virtual
Machine (JVM).
Bibliotecas de classe: oferecem aos desenvolvedores de aplicativos
funções pré-escritas, incluindo serviços de codificação (como manipulação de
strings e processamento de transações); serviços de conexão de rede (tradução
de protocolos); serviços de gerenciamento de sistema (permissões de segurança
e pool de componentes); serviços de servidor (serviços de páginas web e
conexão a email); e serviços para a conexão com fontes externas (sistemas de
bancos de dados ou streams de dados).
Linguagens de programação especialmente projetadas: baseadas em
C/C++, incluem avanços como tipos de dados fortes e coleta de lixo, que
aumentam a produtividade do programador e reduzem a probabilidade de bugs.
Para escrever programas nessas linguagens (C# para .NET e Java para J2EE), é
preciso que um compilador esteja disponível para traduzir o código fonte
original para o código intermediário entendido pela máquina virtual. O CLR
suporta C#, C++, Visual Basic, JScript, COBOL, Fortran, Haskell, Pascal, Eiffel
e Pearl.
Ambiente de desenvolvimento para páginas web dinâmicas rodando em
um servidor web: o que permite aos desenvolvedores usarem a mesma
66
plataforma para criar aplicativos para desktop e para a Web. O .NET usa
ASP.NET e o J2EE usa Java Server Pages (JSP).
Como o .NET Framework e o J2EE oferecem arquiteturas e recursos
muito similares, a decisão de adotar qualquer das plataformas (ou migrar de uma
para a outra) exige que os gerentes considerem problemas que extrapolam o
contexto técnico. As organizações devem considerar as três áreas principais a
seguir:
Maturidade versus tecnologias mais atuais. Embora os principais
aplicativos baseados em J2EE estejam começando a aparecer, o núcleo da
plataforma Java (a JVM e as bibliotecas de classe da "edição padrão") foi usado
em tantos cenários reais que a maioria dos bugs realmente negativos foram
descobertos e corrigidos e as principais brechas foram preenchidas, pela Sun ou
por terceiros. Além disso, os desenvolvedores tiveram tempo suficiente para
aprender sobre ela e contam com uma ampla base de ferramentas e aplicativos
para suportá-la. Esses fatores podem levar a um processo de desenvolvimento
mais suave e previsível.
Ao mesmo tempo, por ser mais recente, o .NET tem aprimoramentos que
faltam ao Java. Por exemplo, o ASP.NET permite aos desenvolvedores
implementar Web Services com menos código do que os desenvolvedores em
Java poderiam fazer usando a plataforma J2EE.
Disponibilidade de desenvolvedores. Muitas organizações hoje contam
com programadores em VB em seu pessoal. Mesmo que o VB.NET envolva
algumas mudanças significativas, o retreinamento dos desenvolvedores em VB
deve ser bem menos complexo e caro do que o treinamento total dos novos
programadores em Java.
Disponibilidade de conjuntos de ferramentas. Como parte de seus
esforços gerais no .NET, a Microsoft também promoveu alterações significativas
em sua linha de produtos Visual Studio. O VS tem tradicionalmente forte
67
aceitação entre a comunidade de desenvolvedores, e a Microsoft espera usar
esses seguidores para tornar o .NET ainda mais atraente. A Sun não tem
histórico de criação de ferramentas para desenvolvedores. A principal
ferramenta para Java da Sun é o Forte for Java, e outras empresas lançam
ferramentas adicionais, como Visual Age for Java, da IBM.
Portabilidade e interoperabilidade. O Java recebeu boas notas por
portabilidade entre plataformas, trazendo-lhe sucesso em ambientes de grande
porte e múltiplos servidores (embora o código escrito em J2EE seja menos
portável do que o código escrito apenas para a JVM).
O código gerenciado do .NET, por outro lado, é portável apenas entre as
várias plataformas Windows. Porém, o CLR do .NET oferece melhor
interoperabilidade entre o código .NET e o código escrito para a plataforma
Windows existente do que o Java pode oferecer quando roda em Windows.
Além disso, o foco do .NET no Windows não é tão limitante quanto pode
parecer. O Windows 2000 e seus sucessores irão suportar o .NET no servidor e
no desktop, enquanto o Windows CE dará suporte ao .NET em uma variedade
de dispositivos portáteis, como handhelds, telefones inteligentes e consoles de
TV.
4.4- O .NET Framework em múltiplos Sistemas Operacionais
Em uma tentativa de tornar o .NET Framework o padrão para o
desenvolvimento de aplicativos, a Microsoft submeteu especificações da
linguagem C# e da Common Language Infrastructure, a CLI, baseadas no .NET
Framework, à European Computer Manufactures Association (ECMA), uma
associação internacional de padronização. Em princípio, essas especificações
poderiam permitir aos desenvolvedores escrever aplicativos na plataforma .NET
que roda em qualquer sistema operacional e hardware. Uma análise mais
68
profunda das especificações, no entanto, revela problemas que irão limitar a
maior parte do desenvolvimento em .NET ao Windows para o futuro previsível.
Em dezembro de 2001, a ECMA aprovou o padrão ECMA-334 que
especifica a forma e estabelece a interpretação de programas escritos na
linguagem de programação C#. Especifica, entre outros:
A sintaxe e as restrições da linguagem C#
A semântica dos programas em C#
As restrições e os limites impostos por uma implementação que
atende aos requisitos da C#.
Também em dezembro de 2001, a ECMA liberou o padrão ECMA-335,
que define o CLI. O CLI é um ambiente de execução que permite que
aplicativos escritos em uma linguagem de alto nível, como C#, sejam executados
em diferentes sistemas operacionais e hardwares sem exigir que os
desenvolvedores reescrevam o aplicativo visando as características específicas
de cada ambiente. O CLI define:
Um formato de arquivos para aplicativos
Um conjunto de tipos de dados para uso nos aplicativos
Um formato extensível para metadados de aplicativos
Uma linguagem intermediária baseada em MSIL para
código de aplicativos
Uma biblioteca de classes básica como às classes
básicas do .NET Framework.
Em 2001, a ECMA, a Microsoft e a Corel anunciaram que iriam
trabalhar juntas e usar esses padrões para criar uma implementação de C# e do
69
CLI para FreeBSD, e oferecer essa implementação sob licença do Shared Source
Code (código fonte compartilhado) da Microsoft. A Ximian, um desenvolvedor
de código aberto do ambiente GNOME para Linux, também anunciou que irá
usar as mesmas especificações da ECMA para implementar o .NET Framework
no Linux.
As informações submetidas à ECMA para padronização incluem
elementos que parecem mapear para partes do .NET Framework, incluindo o
Common Type System (CTS), que define os tipos de dados comuns (como
números inteiros e strings) para o CLI e um ambiente de execução virtual
semelhante ao Common Language Runtime (CLR). Em princípio, os
desenvolvedores podem criar aplicativos portáveis capazes de rodar em qualquer
sistema operacional e hardware que tenha uma plataforma de desenvolvimento
que atenda a ECMA. Por exemplo, um desenvolvedor pode criar um aplicativo
na plataforma .NET que roda sem alterações no FreeBSD usando a
implementação da CLI da Corel.
Mas a portabilidade dos aplicativos será realmente determinada pela
capacidade de perfeito mapeamento das bibliotecas de classe da ECMA através
dos ambientes: se um programador escreve um programa em Windows usando o
.NET Framework será que todas as funcionalidades expostas nas bibliotecas de
classe da Microsoft estarão disponíveis na implementação FreeBSD da
especificação da ECMA?
A especificação da ECMA descreve um conjunto de bibliotecas de classe
básicas, incluindo classes que mapeiam para as classes System, System.NET,
System.Reflection (que permite aos programas obter a descrição ou os
metadados do código gerenciado) e System.XML do .NET Framework. Porém,
a especificação não parece ter nenhuma classe que mapeie para as bibliotecas de
interface de usuário (UI) do Windows ou da Web; portanto a portabilidade pode
ficar limitada a aplicativos de console não-gráficos ou a Web Services sem
70
interface do usuário. Da mesma forma, a especificação da ECMA não inclui
nenhuma biblioteca análoga às bibliotecas de acesso a dados do ADO.NET;
portanto, os aplicativos escritos com base nessa especificação também não
teriam capacidade portável de trabalhar com bancos de dados.
Finalmente, há a questão do licenciamento. A ECMA não considera
direitos de propriedade intelectual, como patentes, pertencentes a uma empresa
como a Microsoft, que propõe um padrão. Apenas exige que um proprietário dos
direitos de propriedade intelectual ofereça alguma forma de licenciamento a
qualquer entidade que deseje implementar um padrão ECMA. Assim, embora o
padrão ECMA assegure que qualquer um que deseje implementar uma versão
não-Windows do .NET não tenha sua licença negada sem motivos "razoáveis",
os termos de licença podem ser tão caros que a distribuição ficará, na prática
impedida.
71
5.0- CONSIDERAÇÕES FINAIS
Hoje em dia a construção simples e rápida de sites de comércio
eletrônico é a força propulsora para elevar a economia digital a novos patamares.
Com a crescente capacidade de processamento e ampliação acelerada da largura
de banda, essa elevação se torna perfeitamente possível. Nesse contexto, as
tecnologias .NET e J2EE tem como objetivos dar suporte a novos cenários do
Business to Business (B2B) e do Business to Consumer (B2C) que estão sendo
exigidos das aplicações Internet.
Os profissionais de TI encontram-se diante de um desafio: promover a
interoperabilidade entre sistemas e entre sites de diferentes organizações. Para
vencer esse desafio, a Microsoft está investindo alto na implementação de
ferramentas com padrões abertos: XML e SOAP. [GUTIERREZ, 2001], explica
que ao fornecer uma infra-estrutura completa para dar suporte a esses padrões e
ao fornecer serviços implementados com base nesses padrões, a Microsoft está
impulsionando a comunicação entre sites.
A plataforma .NET é avaliada por [CHERRY, 2001] de acordo com os
fatores: confiabilidade e segurança; custo de desenvolvimento e desempenho.
A confiabilidade e a segurança são itens garantidos pelo CLR, que
previne erros de código básicos (como estouros de buffer) e impõe restrições de
segurança definidas pelo administrador. No entanto, um aplicativo é tão forte
quanto seu elo mais fraco: um aplicativo .NET que contém código Windows
não-gerenciado é tão confiável e seguro quanto esse código.
Os sofisticados assistentes e editores gráficos do Visual Studio.NET
ampliam a produtividade dos programadores. Ampliação esta que reduz o custo
final. As bibliotecas de classe simplificam o treinamento de programadores, a
criação e a manutenção de código. Organizações que investiram pesadamente
72
em Windows podem reutilizar esses códigos, o que lhes permite migrar
gradualmente para a nova plataforma.
Mas a plataforma .NET é suficientemente diferente da plataforma
Windows atual para que as empresas precisem treinar desenvolvedores nas
bibliotecas e linguagens de programação. Além disso, as empresas terão de
revisar e rescrever o código fonte existente do Windows, para rodá-lo com pleno
gerenciamento no CLR.
Um dos pontos mais importantes em um sistema de computação é o
desempenho. A plataforma .NET é comparável ou superior a plataforma J2EE
da Sun [CHERRY, 2001]. Comparativos entre ASP.NET e ASP indicaram
fortemente que o ASP.NET é superior ao ASP na plataforma Windows. Por
outro lado, os custos de conversões entre códigos gerenciados e códigos não
gerenciados, da tradução entre o código intermediário em código nativo tornam
a plataforma .NET menos atraente para aplicativos que dependem do
desempenho, como jogos e serviços de rede de baixo nível.
A nova plataforma de desenvolvimento da Microsoft fará mais sentido
para empresas que estão criando novos aplicativos Web baseados em Web
Services e aplicativos que usam códigos Windows já existentes. Faz menos
sentido para organizações que já estão usando produtos de outros fornecedores
de software, principalmente aplicativos Windows para desktops e aplicativos
empacotados para servidores (como os produtos da SAP na área de ERP), que
precisam rodar em sistemas operacionais de mainframe e Unix. As organizações
terão de enfrentar uma espera considerável por uma versão .NET desses
aplicativos [CHERRY, 2001].
Finalmente, o modelo .NET é aplicável a todos os integrantes da cadeia
de produção, independente do tamanho e pode se tornar também uma fonte de
bons negócios.
73
6.0- TRABALHOS FUTUROS
Já existem muitos Web Services implementados na Web. Como
exemplos, tem-se:
Um serviço de tradução do site de busca Google: o cliente envia
uma frase e recebe como resposta a tradução para a língua escolhida.
A Adobe: que está criando serviços para usar Web Services como
uma ferramenta para geração de PDFs pela rede.
O site Google disponibiliza também uma API que permite o acesso a
diversos métodos de busca por meio de chamadas usando-se o
protocolo SOAP, isso torna possível que uma funcionalidade de
busca por páginas sobre um assunto seja embutida dentro de uma
aplicação desktop ou Web.
E uma pesquisa realizada em junho de 2002 pelo IDC identificou
demanda para o mercado de Web Services de US$ 1,6 bilhão, em 2004, e para
2007 de US$ 34 bilhões.
Com isso, este trabalho pode ser estendido, para cobrir os tópicos:
Pesquisar o projeto e a implementação de sistemas distribuídos com
foco em Web Services. Esta pesquisa inclui mapear as principais
ferramentas para a construção de Web Services, além de mostrar o
histórico das aplicações Web até os Web Services.
Realizar uma comparação entre as plataformas .NET e J2EE:
principais ambientes para a implementação de Web Services.
Projetar um sistema integrado para uma cadeia de produção
específica. Afinal os Web Services foram especialmente projetados
74
para facilitar a integração entre sistemas de diferentes empresas, via
Internet, através de padrões abertos como XML e SOAP.
75
7.0- BIBLIOGRAFIA
CHERRY, Michael e Greg Demichillie A Plataforma de Desenvolvimento
.NET: Uma visão independente da tecnologia e da estratégia Microsoft, 2001
www.DirectionsOnMicrosoft.com
DEITEL, H. M. C++ Como Programar Porto Alegre Editora Bookman, 2001
DREWANZ, Marcello VS .NET: Um Novo Começo! DotNet Magazine
Fevereiro 2002 – www.dotnetmagazine.com.br
PAULA FILHO, Wilson de Pádua Paula. Engenharia de Software.
Fundamentos, Métodos e Padrões; Rio de Janeiro - LTC Editora, 2001
GATES, Bill Riscos e Oportunidades das tecnologias .NET às empresas – 2001
Disponível em www.microsoft.com/brasil/net
GUTIERREZ, Marco Antônio Estratégia .NET Rio de Janeiro
Editora Axcel Books, 2001
LOWY, Juval Defina um Novo Rumo com a plataforma .NET DotNet Magazine
Fevereiro 2002 – www.dotnetmagazine.com.br
O’KELLY, Peter Conheça a Estratégia .NET DotNet Magazine
Fevereiro 2002 – www.dotnetmagazine.com.br
PRESSMAN, ROGER S. Software Engineering: a practitioner's approach
Editora Mc Graw Hill, 1992
SOUZA, Anamélia Contente e Vitório Breno Mazzola Implementando
Aplicações Distribuídas Utilizando CORBA: Um Estudo de Caso Voltado à
Área de Banco de Dados InfoComp, Novembro de 1999 –
www.comp.ufla.br/~infocomp
TANEMBAU, Andrew S. Structured Computer Organization
Editora Prentice Hall, 1995
VASCONCELOS, Luiz Fernando Apostila de Engenharia de Software:
UFPE, 1999
76
IEEE Software: Engineering Internet Software - March/April 2002
DotNet Magazine – Fevereiro 2002 – www.dotnetmagazine.com.br
Developers’ Magazine – Setembro de 2002 – www.developers.com.br
[COREL] www.corel.com
[DEVELOPNET] www.developnet.co.uk
[DEVX] www.devx.com/dotnet
[ECMA] www.ecma.org
[FREEBSD] www.freebsd.org
[GOMONO] www.gomono.com
[GOTDOTNET] www.gotdotnet.com
[MSDN] www.msdn.microsoft.com/net
[ORACLE] www.oracle.com
[SDMAGAZINE] www.sdmagazine.com/articles/2001
[SDMAGAZINE] www.sdmagazine.com/articles/2002
[TIMASTER] www.timaster.com.br
[XIMIAN] www.ximian.org
[XML] www.xml.org
77
ANEXOS
78
A plataforma de desenvolvimento .NET
Web Server
application
Windows
desktop
application
WinForms
(Windows
UI)
ASP.NET
Web
Cervicai
s
XML
Web
UI
VB.NET
C++
C#
Networking
ADO.NET
(data access)
Jscript
.NET
Base classes
VS.NET
Common Language Runtime (CLR)
A plataforma .NET é um conjunto de componentes de software para a criação
tanto de aplicativos para servidores Web como aplicativos Windows para desktop.
Os aplicativos criados com a .NET rodam sob o controle da CLR (Common
Language Runtime), rotinas que carregam aplicativos e garantem que eles podem ser
executados sem erros, verifica as permissões de segurança apropriadas, executa os
aplicativos e faz a limpeza depois que eles terminam. Um conjunto de bibliotecas de
classe fornece rotinas que permitem aos aplicativos ler e escrever dados no formato
XML, comunicar-se via Internet, acessar banco de dados e muito mais. Todas as
bibliotecas de classe baseiam-se em uma biblioteca básica que fornece funções de
gerenciamento dos tipos de dados usados com maior freqüência, como strings e
números, e funções de baixo nível, como acesso a arquivos.
Os aplicativos executados sob servidores web normalmente baseiam-se em
ASP.NET, uma biblioteca presente no servidor para processar pedidos da web. O
79
ASP.NET, por sua vez, baseia-se em uma biblioteca de Web Services para enviar e
receber mensagens SOAP e em uma biblioteca de interface com o usuário (IU) web (às
vezes denominada Web Forms) para receber comandos de usuário via navegadores e
gerar dinamicamente páginas web em resposta a eles. Os aplicativos Windows para
desktops podem apresentar uma interface de usuário gráfica através da biblioteca
WinForms, também conhecida com Windows Forms.
Finalmente, o Visual Studio.NET oferece um ambiente de desenvolvimento
integrado (IDE, Integrated Development Environment) para a criação de aplicativos na
plataforma .NET. Os programadores desenvolvem seus programas em uma ou mais
linguagens de programação .NET, como Visual Basic .NET, Visual C++, Visual C# ou
JScript.NET, todas da própria Microsoft. Existem diversas outras linguagens de
programação .NET criadas por outras organizações.
80
Executando código gerenciado
Assembly
Versioning
Policy
1
Class Loader
2
Verifer
3
MSIL to Native
Compilers
Garbage
Collection
Managed
Native Code
Security
System
81
Os componentes da Common Language Runtime (CLR) carregam e executam
aplicativos.
1- O Class Loader (carregador de classes) carrega o assembly do aplicativo na memória.
O assembly consiste no código MSIL (Microsoft Intermediate Language) e metadados
que descrevem os componentes de software no assembly do aplicativo e dos outros
componentes que este requer. Usando os metadados do assembly do aplicativo, o Class
Loader tenta, então, carregar os assemblies que suportam os componentes que o
aplicativo requer. Por exemplo, ele poderia carregar um assembly contendo os controles
da interface gráfica de usuários (GUI) exigidos por um aplicativo para desktop. O Class
Loader usa o Versioning Policy (definição sobre o controle de versões, especificado pelo
desenvolvedor do aplicativo ou pelo administrador do sistema) para determinar que
versões dos assemblies de suporte devem ser carregados. Por exemplo, um Versioning
Policy pode ditar que apenas versões específicas dos componentes da GUI devem ser
usadas, mesmo que haja versões mais recentes disponíveis. Isso elimina o problema da
versão dos componentes que era tão comum nos aplicativos Windows do passado.
2- Uma vez carregados os assemblies do aplicativo e de suporte, o Verifier (verificador)
examina seu conteúdo para assegurar que é “type-safe” e para determinar as permissões
de segurança apropriadas para o aplicativo. Este é o primeiro passo no processo de
reforço da segurança.
3- Os compiladores nativos convertem o MSIL em código nativo gerenciado, que é
código específico para o processador que sabe como interagir com serviços fornecidos
pelo CLR, como coleta de lixo (que libera a memória que não está mais sendo usada
pelo aplicativo) ou o sistema de segurança do CLR (que impõe as permissões de
segurança do aplicativo).
82
Misturando código gerenciado e não-gerenciado
Managed Code Calling COM Code
CLR data
COM data
Managed
Code
Component
COM
Component
RCW
CLR data exception
COM data and
return codes
COM Code Calling Managed Code
CLR data
Managed
Code
Component
COM data
COM
Component
RCW
CLR data exception
COM data and
return codes
Os recursos de interoperabilidade do Common Language Runtime (CLR) permite
aos desenvolvedores misturar código gerenciado e código não-gerenciado existente em
componentes COM, assim como código em bibliotecas de vinculação dinâmica (DLLs,
Dynamic Link Libraries) de Win32. Quando um componente de código gerenciado
chama um código em um componente COM (quando superior), o CLR gera um runtime
callabe wrapper (RCW, ou código executável responsável pela interface entre
componentes). Esse RCW age como um procurador, ou intermediário, para o
componente COM não-gerenciado. O RCW manipula toda a interação entre o
componente gerenciado e o componente COM, incluindo (mas não se limitando a) os
seguintes:
Traduzir e mover dados entre os ambientes CLR e COM
Liberar a memória e outros recursos do componente COM “wrapped”, isto é,
com código executável responsável pela interface entre os componentes COM,
quando o componente de código gerenciado é liberado pelo processo de coleta
de lixo do CLR
Traduzir os códigos de erro retornados pelo COM em erros do CLR
83
Quando um componente COM chama um componente .NET escrito em código
gerenciado (quadro inferior), o CLR novamente gera um COM callable wrapper (CCW,
código executável responsável pela interface entre os componentes COM). Similar ao
RCW, o CCW atua como procurador ou intermediário entre o código COM nãogerenciado. O CCW também implementa o conjunto de funções padrão exigido dos
componentes COM para que o componente de código gerenciado pareça ser um
componente COM normal.
O CCW manipula toda a interação entre o objeto COM não-gerenciado e o componente
.NET gerenciado, incluindo (mas não se limitando) os seguintes:
Mover e traduzir dados entre os ambientes
Liberar o componente de código gerenciado para eventual coleta de lixo pelo
CLR quando o componente COM é liberado
Traduzir erros do CLR em erros do COM.
84
Desenvolvendo código gerenciado
Application
Source Code
Class Libraries
Compilers
VB.NET
C#
C++
Metadata
...
MSIL
Assembly
Generation
Tools
Assembly
Desenvolvedores criam um assembly de código gerenciado combinando seus
programas fonte de aplicativos com o código das bibliotecas de classe da plataforma
.NET. As bibliotecas de classes podem incluir uma combinação de bibliotecas
fornecidas com a plataforma .NET, além de bibliotecas fornecidas por outros
fornecedores. Os compiladores .NET então traduzem esse código fonte para MSIL
(Microsoft Intermediate Language). Além do MSIL, os compiladores .NET produzem
metadados, que descrevem os componentes que compõem o código. Esses metadados
são usados pelo CLR (Common Language Runtime) para implementar a segurança e
garantir que o CLR receba a versão correta dos componentes de que necessita.
85
Regras práticas para a seleção de uma linguagem .NET
Diversas questões precisam ser respondidas antes de selecionar uma linguagem de
programação para um determinado projeto:
1.
2.
3.
4.
Quais os conhecimentos da equipe de programadores atual e com que
facilidade se pode contratar novos programadores?
Os componentes estão sendo desenvolvidos para um único aplicativo para
usuário final ou são componentes fundamentais que serão reutilizados por
outros programadores em diversas situações?
O aplicativo exige um novo código totalmente reescrito do zero ou é possível
apenas modificar e adaptar o código existente?
O uso de linguagens é ferramentas de terceiros (não-Microsoft) é aceitável?
86