Grupo B5

     Subject: Resumo trabalho grupo B5 - Programação na Web
        Date: Wed, 15 Apr 1998 16:15:56 -0300
        From: Jose Estevão Picarelli 
Organization: Faculdade de Engenharia Eletrica e da Computacao - UNICAMP
  Newsgroups: feec.posgrad.IA368F


Estudo sobre a programação na Web da aplicação "Curso sob Medida" +
"Prova Virtual"

Grupo - B5

Ivan Granja, João Carlos Orosz (relator),
José Estevão Picarelli (relator), Ricardo Concilio

Sumário:

Introdução
Definições
Cenário
Funcionalidade x Mecanismo de implementação x Justificativa
Conclusão

1- Introdução

        As aplicações na Web  exigem hoje mais do que apresentar páginas
estáticas para consulta. Assim, mecanismos de programação são
necessários para possibilitar a implementação de aplicações completas.
Este trabalho mostra os recursos hoje disponíveis, tais como CGI[4],
Applet[5], Servlet[6], Castanet[7] e faz uma proposta de uso dessas
tecnologias para implementação da aplicação "Curso sob medida" e "Prova
Virtual"[9].

2 - Definições

HTTP - Hypertext Transfer Protocol - Protocolo de comunicação entre
cliente/servidor utilizado no serviço WWW.

HTML - Hypertext Markup Language - Linguagem para hipertexto, multimídia
e exibição de documento na Web. 

CGI- Common Gateway Interface.Interface que permite a interação entre o
HTTP e aplicativos que estão no servidor. O termo "comum" é devido ao
padrão utilizado em vários servidores. O gerenciamento de comunicação
com o script é feito exclusivamente no servidor. 

Applet - Application Net - Pequenos programas escritos em Java que são
enviados via Network pelo servidor e são processados no cliente.

Servlet - Aplicações escritas em Java que são processadas no servidor.

Castanet - Mecanismo na metáfora "pull" (do servidor para o cliente) que
transfere, lê e grava arquivos no cliente.


3 - Cenário

        O cenário desse trabalho foi desenvolvido durante aulas do curso IA368,
cuja conclusão consensual pode ser visto no documento "Formato de
documentos na Web" [9]. Destacamos abaixo as funcionalidades da
aplicação:

        1- Compor disciplinas através de material, exercícios, provas, aulas, 
de forma distribuída, aplicando ou não técnicas de grupo, etc

        2- Estabelecer perfis para cada curso definindo diferentes visões.

        3- Cadastrar atores com diferentes perfis e níveis de acesso 
(instrutor, monitor, alunos, grupos de estudo).

        4- Disponibilizar as disciplinas/aulas (Relacionamento curso/aulas/ 
disciplinas/tempo máximo)

        5- Acompanhar o andamento da disciplina.

        6- Fornecer feed-back para alunos e professores.

        7- Aplicar provas, testes, dissertativas, etc

        8- Corrigir e pontuar a prova pelo próprio sistema, através de testes, 
Instrutor "ad-hoc", auto correção (disponibilizar gabaritos para auto 
avaliação).

        9- Disponibilizar resultados para eventuais consultas.

        A arquitetura proposta para implementação é a  cliente/servidor no
ambiente da WWW.

4 - Funcionalidade x Mecanismo de implementação x Justificativa

        Para efeito de implementação (e exigência de síntese) podemos
classificar essas nove funcionalidades em três categorias :


        A - Infra-estrutura. Funções predominantemente de natureza de 
cadastramento (contrução e manutenção de bases de dados).

        B - Interface. Funções predominantemente de natureza  consulta e 
apresentação.

        C - Mista A e B

        As funcionalidades 1,2,3 se enquadram na categoria A. As  4,5,6 e 9 na
categoria B e a 7 e 8 na categoria C. A tabela a seguir apresenta a
matriz de alternativas para programação das funcionalidades.

Tabela Categoria/Funcionalidade x Programação
 
                        CGI     Applet  Servlet Castanet HTML
Categ. Func.            (V)     (W)     (X)     (Y)     (Z)
        
A       1               x               x               x
A       2               x               x               x
A       3               x               x               x
B       4               x       x       x       x       x
B       5               x       x       x       x       x
B       6               x       x       x       x       x       
C       7               x       x       x               x
C       8               x       x       x               x
B       9               x       x       x                               x

Justificativas:

        A,B,C -Z - O recurso HTML[1] está presente em todas as funcionalidades
para prover a interface inicial com o usuário (páginas iniciais,
apresentação de planilhas e outras relacionadas).

        A-V - Utilizado para preparar FORMS como planilha de entrada de dados,
que poderão ser de inclusão, exclusão e alteração atualizando uma base
de dados. Embora o CGI venha sendo utilizado como padrão tudo indica que
o Servlet, por apresentar mais vantagens, será a melhor alternativa
neste caso.

        A-X - Pode ser usado como uma alternativa ao CGI.

As funcionalidades 1, 2 e 3 (categoria A) têm as mesmas características
de cadastramento. Deve ser ressaltado, entretanto, que a funcionalidade
3 precisa de funções de segurança, que podem ser implementados pelo
"user authorization" do CGI.

        A-W - Idéia dinâmica da página , apresentação de animação, imagens,
gráficos.

        B-V - Acessar perfis para mostrar o que será exibido 

        B-Y - Alternativa ao paradigma de browser para economia de comunicação
em rede, uma vez que ele só envia o que foi alterado desde a última
requisição.


        A Common Gateway Interface (CGI) é um padrão que determina como os
aplicativos externos fazem  interface com os servidores Web. A razão por
trás da invenção da CGI é simples: sem ela a especificação HTTP[2] e
todos os servidores Web iriam tornar-se um conjunto não padronizado de
extensões improvisadas. A CGI fornece um meio de escrever programas que
rodarão no servidor quando forem invocados pelo browser Web cliente por
meio de código HTML.
        
        O CGI permite a interatividade entre o cliente e o host através da WWW
via HTTP. Um documento HTML, que é entregue pelo servidor na Web, é
estático. Um programa CGI, por outro lado, é executado em tempo real
permitindo que a informação seja apresentada de modo dinâmico sob o
ponto de vista de interatividade.
        
        O CGI scripts são flexíveis porque o servidor não está realmente
envolvido no processo. A responsabilidade primária do servidor é iniciar
o script, enviar a informação e passar a saída de volta para o browser,
assim é o script quem executa o maior trabalho.
        
        Para requisições mais complexas como os forms, o servidor chamará
programas específicos. Os scripts colecionam dados dos formulários e
dinamicamente fazem a construção da página Web. Essas páginas não
existem no hard-disk do servidor, elas são construídas dinamicamente em
resposta as requisições do browser.
        O  Servlet(serve-side script) é popular pelas razões:
        - é totalmente independente do browser uma vez que tudo está no 
servidor;
        - requisições complexas podem ser executadas mais rapidamente no 
servidor;
        - pode ser mais seguro, uma vez que os programas serão executados 
diretamente sob o controle do administrador do servidor.

        Servlet tem quatro vantagens distintas em relação ao CGI:

        - familiaridade: tem acesso a todos os pacotes Java;
        - portabilidade: são suportados pelos servidores e, uma vez em Java, 
poderia ser executado em qualquer lugar;
        - segurança: por ser escrito em Java, traz todas as características de 
segurança herdadas;
        - performance: servlets são mais eficientes que CGI.




5 - Conclusão

        A escolha de melhor alternativa de implementação de aplicações mais
sofisticadas para serem processadas na Web dependem, além de aspectos
técnicos, da época e circunstâncias do desenvolvimento. Assim, hoje, a
utilização de CGI e Java (Applet e Servlet) se mostram como os melhores
recursos. Outras metáforas, tais como Castanet Marimba)[7], são
consideradas alternativas prematuras. Como mostrado na tabela de
categoria x funcionalidade x programação, uma mesma funcionalidade pode
ser implementada de mais de uma forma, sendo que o julgamento passa por
uma análise custo x benefício.

Referências bibliográficas

[1]HTML 4.0 Specification
     Dave Raggett, Arnaud Le Hors, Ian Jacobs (Eds.)
     REC-html40-971218, The World Wide Web Consortium, 1997 
[2]HTTP: A protocol for networked information
     Tim Berners-Lee
     Internet Draft, 1992 
[3]Dynamic argument embedding: Preserving state on the World Wide Web
     Arun Iyengar
     IEEE Internet Computing, 1(2):50-56, March/April 1997
     Disponível através da IEEE Digital Library (acesso restrito) 
[4]CGI: The Common Gateway Interface for Server-side Processing
     The Web Developer's Virtual Library, 1997 
[5]Overview of Applets
     in The Java Tutorial: Object-Oriented Programming for the Internet,
2nd Ed.
     Mary Campione, Kathy Walrath
     java.soft.com, March 1998 
[6]Dynamic WebPages in Java: Servlets
     Benoît Marchal
     Digital Cat's Java Resource Center, November 1997. 
[7]Java beyond the browser: The channel metaphor
     Bill Venners
     JavaWorld 1(10), December 1996. 
[8]Prelude to CGI
     em Introduction to CGI/Perl, Capítulo 1
     Steven E. Brenner, Edwin Aoki
     M&T Books, 1996 
[9]Pimenta, Marcia de Fátima e Soares,Márcio Vieira
        Formatos de Documentos na Web, abril 1998.
        Tópicos de Engenharia de Computação (IA368F)

ricarte@dca.fee.unicamp.br

Last modified: Wed Apr 29 16:59:34 BRA 1998