UMA ARQUITETURA BASEADA EM AMBIENTES PARA SISTEMAS DE COMÉRCIO ELETRÔNICO - PDF
Download "UMA ARQUITETURA BASEADA EM AMBIENTES PARA SISTEMAS DE COMÉRCIO ELETRÔNICO"
Valentina Assunção Fortunato
1 UNIVERSIDADE FEDERAL DE SANTA CATARINA PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO Karin Maria Söhnlein UMA ARQUITETURA BASEADA EM AMBIENTES PARA SISTEMAS DE COMÉRCIO ELETRÔNICO Dissertação submetida à Universidade Federal de Santa Catarina como parte dos requisitos para a obtenção do grau de Mestre em Ciência da Computação Prof. Dr. Rosvelter João Coelho da Costa Orientador Florianópolis, 27 de novembro de 2002
2 UMA ARQUITETURA BASEADA EM AMBIENTES PARA SISTEMAS DE COMÉRCIO ELETRÔNICO Karin Maria Söhnlein Esta Dissertação foi julgada adequada para a obtenção do título de Mestre em Ciência da Computação Área de Concentração Sistemas de Computação, e aprovada em sua forma final pelo Programa de Pós-Graduação em Ciência da Computação da Universidade Federal de Santa Catarina. Prof. Fernando A. O. Gauthier, Dr. Coordenador do Curso de Pós-Graduação em Ciência da Computação Banca Examinadora Prof. Rosvelter João Coelho da Costa, Dr. Presidente da Banca (Orientador) Prof. João Bosco Mangueira Sobral, Dr. Membro da Banca Prof. Roberto Willrich, Dr. Membro da Banca
3 Agradecimentos Agradeço ao Curso de Pós-Graduação em Ciência da Computação e à Universidade Federal de Santa Catarina pela infra-estrutura e organização que viabilizaram o desenvolvimento deste trabalho. Agradeço aos professores João Bosco Mangueira Sobral e Roberto Willrich por participarem no julgamento deste trabalho. Agradeço especialmente ao meu orientador Prof. Rosvelter João Coelho da Costa, pelos valiosos ensinamentos e pela dedicação, paciência e compreensão que demonstrou ao decorrer deste tempo de pesquisa. Agradeço à minha família, por todo o apoio oferecido ao decorrer deste trabalho.
4 Este trabalho é dedicado à minha mãe, com certeza a grande incentivadora deste trabalho, que sempre acreditou no meu sucesso.
5 Resumo Este trabalho explora uma abordagem de ambientes para o desenvolvimento de sistemas de vendas online utilizando a tecnologia Servlets/JSP. A primeira parte deste trabalho é dedicada a um estudo de caso compreendendo a análise de um sistema de vendas online para produtos relacionados à construção civil denominado Sistema de Vendas Online Casarão. A segunda, dedicou-se ao desenvolvimento de um projeto de software contemplando as necessidades do sistema proposto na primeira etapa. Esse estudo tem como objetivo principal a identificação de conceitos arquiteturais para o projeto de sistemas de vendas online. Especificamente, buscou-se, de um lado, esclarecer melhor a problemática envolvida e, de outro, evidenciar uma noção de ambientes como um possível candidato a conceito arquitetural para sistemas de vendas online onde os ambientes são caracterizados conforme ambientes de uma loja real. Palavras-chave: comércio eletrônico, arquitetura de software, Servlets/JSP.
6 Abstract This work explores a treatment of ambients for the development of online sale systems using the Servlets/JSP technology. The first part of this work is dedicated to a case study that encompasses the analysis of an online sale system related to building supplies called Casarão Online Sale System. The second part is dedicated to the development of a software project that attends the funcionalities described in the first part. The goal of this study is to identify an architectural concept for online sale systems. On the one hand this work tries to shed light upon the related problems. On the other hand it tries to highlight a notion of ambients as a possible candidate to an architectural concept for online sale systems, where the ambients are characterized as the ambients of a real life store. Keywords: e-commerce, software architecture, Servlets/JSP.
7 Sumário Lista de Figuras...vii Lista de Tabelas...ix Acrônimos...x Capítulo 1: Introdução...1 Capítulo 2: Servlets Introdução A plataforma Java O servidor Tomcat v Arquitetura dos Servlets Contexto de uma aplicação Sessão e Gerenciamento de Sessão Solicitações Concorrência e sincronização de objetos Estrutura de um servlet Classes utilizadas para solicitações e respostas Servlets x CGI Exemplo Conclusão Capítulo 3: JSP - JavaServer Pages Introdução Arquiteturas baseadas na tecnologia JSP Objetos e sincronização de objetos em JSP Gerenciamento de sessão Sintaxe e semântica de páginas JSP Exemplo Conclusão...27 Capítulo 4: O Sistema de Vendas Online Casarão Introdução Aspectos gerais Requisitos do sistema Casos de uso e cenários Atores do sistema Casarão Casos de uso do sistema Casarão Análise do comportamento do sistema Casarão Diagrama de classes Diagramas de interação... 84
8 4.5.3 Diagramas de estados Aspectos da modulariade do sistema Casarão Conclusão...91 Capítulo 5: Uma Arquitetura Baseada em Ambientes para o Projeto do Sistema Casarão Introdução Arquitetura de software O conceito de ambientes Visão geral do sistema Ambientes Identificação dos ambientes do sistema Circulação entre ambientes Recursos oferecidos pelos ambientes do sistema O tipo Ambiente Servlets e páginas JSP Identificando clientes Servlets como representantes de clientes Páginas JSP como visões de um ambiente Análise do comportamento do sistema Conclusão Capítulo 7: Conclusão e Perspectivas de Continuação ANEXO 1: A Web Introdução A Arquitetura de Redes e o Modelo de Referência TCP/IP O Modelo de Referência TCP/IP World Wide Web Arquitetura cliente/servidor de três camadas O protocolo HTTP (Hypertext Transfer Protocol) URL (Uniform Resource Locator) HTML (Hypertext Markup Language) ANEXO 2: Códigos Fonte Código fonte da classe RecebeDados.java Código fonte da classe CartaoCliente.java Código fonte da classe DepCredito.java Código fonte da página RecebeDados.jsp Código fonte da página Responde.jsp Referências Bibliográficas...147
9 Lista de Figuras Fig Comunicação entre cliente e servidor baseada na arquitetura de servlets Fig Estrutura de solicitação/resposta utilizando a tecnologia Servlets...14 Fig Modelo I...18 Fig Modelo II...19 Fig Estrutura de solicitação/resposta utilizando tecnologia JSP...25 Fig Diagrama 1: casos de uso relacionados ao ator Cliente...34 Fig Diagrama 2: casos de uso não relacionados ao ator Cliente Fig Página principal do sistema Fig Lista de categorias Fig Lista de materiais disponíveis na categoria PISOS Fig Seleção de um item para compra Fig Consulta da lista de compras...45 Fig Alteração de quantidade de item da lista de compras...48 Fig Solicitação de identificação do cliente para realização de uma compra...51 Fig Formulário de informações para compras Fig Formulário de solicitação de confirmação de compra Fig Mensagem de compra efetuada com sucesso Fig Página de cadastramento de clientes Fig Página de cadastramento de novos clientes Fig Página de mensagem de sucesso da transação...61 Fig Página de solicitação de identificação para atualização de cadastro Fig Página de atualização de cadastro de clientes...64 Fig Página de consulta de pedidos do cliente...68 Fig Página de consulta de detalhe de um pedido Fig Página de acesso ao sistema Casarão...71 Fig Lista de pedidos a serem processados pelo Estoque...74 Fig Lista dos itens a serem processados para um pedido...76
10 Fig Lista dos pedidos a serem processados pela Expedição Fig Página de emissão de nota fiscal Fig Diagrama de classes do sistema Casarão...84 Fig Diagrama de seqüência - escolha de itens na loja virtual...85 Fig Diagrama de seqüência - confirmação de pedido de compra Fig Diagrama de seqüência - separação de material de estoque...87 Fig Diagrama de seqüência - expedição de material Fig Diagrama de estados de objetos Pedido...89 Fig Decomposição do sistema Casarão Fig Arquitetura de software como uma ponte...95 Fig Visão geral da arquitetura do sistema Casarão Fig Exemplo de criação e utilização dos beans Fig Planta arquitetônica virtual do estabelecimento Casarão Fig Circulação entre os ambientes do sistema Casarão Fig Diagrama de classes dos ambientes do sistema Casarão Fig Diagrama de classes dos ambientes do sistema Casarão (continuação) Fig Visão apresentada ao usuário pela página VisaoDep.jsp da figura Fig Diagrama de seqüência do comportamento do sistema a cada solicitação Fig. 1 ANEXO 1 - Camadas e protocolos no Modelo de Referência TCP/IP Fig. 2 ANEXO 1 - Arquitetura cliente/servidor de três camadas Fig. 3 ANEXO 1 - Código HTML de uma página Web chamada exemplo.html Fig. 4 ANEXO 1 - Apresentação da página exemplo.html pelo browser
11 Lista de Tabelas Tabela Objetos implícitos do JSP Tabela Atores do sistema Casarão Tabela Ambientes e sub-ambientes do sistema Casarão Tabela Recursos funcionais disponíveis em cada ambiente Tabela 1 ANEXO 1 - Instruções HTML de formatação de conteúdo Tabela 2 ANEXO 1 - Instruções HTML que permitem interação com o usuário...139
12 Lista de Acrônimos ADL Architecture Definition Language API ASP CGI CORBA DNS FTP HTML HTTP IP ISO JDBC JSP JVM LAN MAN MVC OSI PHP RMI SGML SNMP TCP UDP UML URL WAN WML WWW XML Application Program Interface Active Server Pages Common Gateway Interface Common Object Request Broker Architecture Domain Name Service File Transfer Protocol HyperText Markup Language HyperText Transfer Protocol Internet Protocol International Standard Organization Java Database Connectivity JavaServer Pages Java Virtual Machine Local Area Network Metropolitan Area Network Model/View/Controller Open Systems Interconnection Hypertext Preprocessor Remote Method Invocation Standard Generalized Markup Language Simple Network Management Protocol Transmission Control Protocol User Datagram Protocol Unified Modeling Language Uniform Resource Locator Wide Area Network Wireless Markup Language World Wide Web Extensible Markup Language
13 Capítulo 1 Introdução O avanço tecnológico na área de redes de computadores nos últimos anos, vem permitindo que a Internet ocupe cada vez mais espaço como meio de comunicação entre pessoas nas mais diversas finalidades. Mais do que um simples meio de comunicação, a introdução desta tecnologia na área comercial tem exercido influências decisivas na forma pela qual um negócio é conduzido. A Internet possibilitou, por exemplo, que as empresas pudessem anunciar seus produtos globalmente e que as tarefas a serem executadas dentro de uma mesma organização pudessem ser atendidas de forma colaborativa por funcionários fisicamente dispersos. Esta nova realidade possibilitou o surgimento de empresas virtuais e incentivou o desenvolvimento de tecnologias para viabilizar o comércio eletrônico, ou seja, a realização de um negócio utilizando a Internet como meio de comunicação. Como exemplo, pode-se citar a empresa norte-americana de revenda de livros Amazon [ As tecnologias de comércio eletrônico têm como objetivo atender a três categorias diferentes de negócio: comércio orientado ao consumidor (bussiness-to-consumer ou B2C), comércio entre empresas (bussiness-to-bussiness ou B2B) e comércio intraorganizacional [ZWA98]. Dentro da primeira categoria, o setor de vendas de produtos tem explorado com bastante sucesso a utilização desta tecnologia. A própria natureza do negócio de vendas, que consiste basicamente na interação entre dois atores - vendedor e cliente, somado ao fato da Internet ser uma tecnologia multimídia, atraiu atenção especial para o desenvolvimento de sistemas de vendas de produtos pela Internet.
14 2 Os sistemas de vendas online, como vêm freqüentemente sendo chamados, envolvem sempre algum tipo de transação financeira e têm como principal objetivo informatizar o processo de vendas, desde a apresentação do produto até a conclusão de sua aquisição, utilizando a Internet como meio de comunicação para troca de informações entre vendedor e cliente. Uma característica típica de sistemas de vendas online é oferecer funcionalidades ao usuário que se aproximem o mais fielmente possível ao comportamento de um cliente dentro de uma loja no mundo real. Dentro deste contexto, o estudo apresentado neste trabalho teve como objetivo principal a identificação de conceitos arquiteturais para o projeto de sistemas de vendas online. O projeto apresentado neste trabalho tem na noção de ambientes o seu suporte intuitivo principal, onde um ambiente é definido o mais próximo possível de um ambiente real de uma loja. Especificamente, buscou-se evidenciar a noção destes ambientes como um possível candidato a conceito arquitetural para este tipo de sistema. Para disponibilizar e manipular as várias informações necessárias a um processo de vendas online, a abrangência de um sistema deste tipo não se restringe apenas ao ambiente de interação entre cliente e setor de vendas, mas envolve também a troca de informações com outros usuários do sistema como setor de estoque, empresa de cartão de crédito, setor de expedição, etc. Sendo assim, o grau de complexidade de um sistema deste tipo pode ser bastante alto, dependendo da abrangência do sistema e/ou dos tipos de informações trocadas com os usuários. Projetos consagrados de software fundamentam-se em conceitos arquiteturais que, por sua vez, determinam toda uma tecnologia. Por exemplo, monitores [HOA74] nos sistemas operacionais e a álgebra relacional nos bancos de dados [OZS99]. Para o caso dos sistemas de comércio eletrônico, ainda não há conceitos arquiteturais bem definidos. O projeto de tais sistemas busca atender apenas às necessidades funcionais impostas pelo modelo usuário e são fortemente influenciados pela tecnologia de software disponível no servidor Web para o desenvolvimento de aplicações Web de uma forma geral. As aplicações existentes hoje utilizam as mais diferentes tecnologias, como por exemplo, a
15 3 tecnologia de agentes muito utilizada para simular mercados virtuais [DAS02, PET02] ou ainda a tecnologia de realidade virtual [WES98] utilizada por algumas lojas na construção de seu sítio. O estudo apresentado nesse manuscrito de dissertação de mestrado foi desenvolvido em duas etapas. A primeira, consagrou-se à análise das principais funcionalidades de sistemas de vendas online apresentando um estudo de caso que incorpora as principais características deste tipo de sistema. A segunda, dedicou-se ao desenvolvimento de um projeto de software contemplando as funcionalidades que foram apresentadas na primeira etapa. O projeto proposto para o estudo de caso propõe para o servidor uma arquitetura baseada em ambientes definidos o mais próximo possível de um ambiente real de uma loja. A arquitetura proposta neste trabalho segue o modelo cliente/servidor em três camadas. Para a camada de apresentação é utilizada a tecnologia Servlets/JSP [SUN02]. A camada de lógica da aplicação é composta por um conjunto de ambientes onde cada ambiente disponibiliza um conjunto de recursos a serem utilizados pelos servlets e páginas JSP. Neste contexto, os servlets assumem o papel de representantes do usuário, que visitam estes ambientes e executam ações utilizando os recursos neles disponíveis. As páginas JSP são encarregadas de apresentar a visão que o usuário teria ao término da execução de cada ação. Os recursos disponíveis nos ambientes muitas vezes necessitam manipular informações persistentes. A camada de acesso à base de dados é composta por um conjunto de classes que oferece os serviços relacionados à persistência de informações para estes recursos. Esta camada utiliza a tecnologia JDBC. Este trabalho está organizado da seguinte forma: No Capítulo 2, apresenta-se a tecnologia Servlets. No Capítulo 3, apresenta-se a tecnologia JSP.
16 4 No Capítulo 4, apresenta-se a análise de um sistema de vendas pela Internet para uma loja de produtos relacionados à construção civil. Este sistema foi concebido para este trabalho visando fornecer um modelo que incorpore as principais características dos sistemas de vendas online. No Capítulo 5, apresenta-se um projeto de software para o sistema do capítulo 4 que propõe a utilização de uma arquitetura baseada em ambientes. O Capítulo 6, apresenta a conclusão deste trabalho e algumas propostas de continuação. Este trabalho possui dois anexos. O ANEXO 1 apresenta os principais aspectos da rede Internet e da Web e o ANEXO 2 apresenta os códigos fonte na linguagem Java de algumas classes utilizadas neste trabalho. Embora a aplicação estudada por esta dissertação foi desenvolvida utilizando a plataforma Java, apenas duas vertentes dessa tecnologia, Servlets, no Cap. 2, e JavaServer Pages, no Cap. 3, será detalhado neste manuscrito. Grande parte do detalhamento omitido, em particular, a sintaxe e a semântica da linguagem Java, poderá ser obtido, por exemplo, no tutorial sobre Java disponibilizado no sítio da Sun Microsystems [JAV02].
17 Capítulo 2 Servelets 2.1 Introdução Este capítulo é dedicado à apresentação da tecnologia Servlets. Esta tecnologia fornece um conjunto de facilidades para o desenvolvimento de servidores Web, em particular, a parte relacionada à geração de conteúdo dinâmico em resposta a uma solicitação HTTP do cliente. Este capítulo apresenta inicialmente uma introdução à plataforma Java. A seguir são apresentas as principais características da tecnologia Servlets e é feita uma comparação desta tecnologia com a tecnologia CGI (AXEXO 1 Seção 3.4). Por último, é apresentada a conclusão do capítulo. 2.2 A plataforma Java Java é uma linguagem criada pela Sun Microsystems originada de um projeto para programar dispositivos eletrônicos inteligentes em Atualmente é utilizada, entre outras, para criar páginas Web com conteúdo dinâmico e interativo, desenvolver sistemas empresariais de larga escala, desenvolver aplicações para dispositivos eletrônicos como telefones celulares e ainda para estender as funcionalidades de um servidor Web [DEI01]. A linguagem Java é orientada a objetos e é independente de plataforma. Ao compilar um programa Java, o compilador Java gera um arquivo com extensão.class que contém instruções chamadas bytecodes. Estas instruções são compostas por um byte de operação e bytes opcionais de operandos. Em tempo de execução, uma entidade de
18 6 software chamada Máquina Virtual Java (JVM) interpreta as instruções contidas neste arquivo e cria o código executável compatível com a máquina real. Desta forma, um arquivo.class pode ser executado em qualquer plataforma Java [JES00]. As aplicações desenvolvidas para a Internet utilizam recursos que estão fisicamente distribuídos pela rede e que podem eventualmente ser compartilhados com outras aplicações. Estes recursos incluem, entre outros, dados, processos, dispositivos de I/O, objetos e arquivos. Uma aplicação distribuída desenvolvida sob o paradigma de orientação a objetos pode ser vista como um conjunto de objetos distribuídos pela rede que cooperam para a realização de uma determinada tarefa. Estas aplicações utilizam os serviços de software de rede e os elementos Web descritos na seção anterior. Visando facilitar o desenvolvimento de tais aplicações, a plataforma Java fornece uma arcabouço de técnicas e mecanismos para que muitos detalhes da tecnologia associada ao funcionamento da Internet fiquem transparentes ao programador. Estes recursos incluem, outre outros, as tecnologias Servlets, JavaServer Pages (JSP), Remote Method Invocation (RMI), Sockets e Common Object Request Broker Architecture (CORBA) [JAV02] O servidor Tomcat v.4 Tomcat v.4 é uma aplicação servidor desenvolvido sob a licença do grupo Apache Software Foundation [ Este software é um container que implementa as especificações da empresa Sun Microsystems [ referentes às tecnologias Java Servlet v. 2.3 [SER01] e JavaServer Pages v [JSP01]. Esta aplicação pode ser utilizada como um servidor Web independente ou pode funcionar como um container que estende as funcionalidades de outro servidor Web. O servidor Tomcat v.4 está disponível para as plataformas WINDOWS e UNIX no endereço:
19 7 2.3 Arquitetura dos Servlets O conjunto de servlets que compõe uma aplicação é gerenciado por um componente denominado Servlet Container, que estende a funcionalidade de um servidor Web. Ele pode ser instalado como parte do servidor ou pode ser um componente externo acoplado a um servidor. O serviço de troca de mensagens entre cliente e servlet é feito através da interface do Servlet Container. Esta interface aceita o protocolo HTTP e permite também que sejam impostas restrições de segurança. A Fig. 2.1 ilustra um processo de solicitação/resposta entre um cliente e uma aplicação servidor que utiliza a arquitetura de servlets. Os seguintes eventos estão enumerados na figura [SER01]: (1) O cliente faz uma solicitação HTTP ao servidor Web que é redirecionada ao Servlet Container. (2) O Servlet Container escolhe o servlet a ser acionado consultando um arquivo de configuração. (3) O Servlet 2 é selecionado e recebe a solicitação. Para respondê-la ele pode eventualmente consultar um banco de dados e fazer os processamentos necessários. (4) O Servlet 2 responde à solicitação. (5) O Servlet Container envia a resposta ao cliente.
20 8 (1) (2) SERVLET CONTAINER Sevlet 1 (3) BANCO DE DADOS CLIENTE (Browser) (5) (4) Servlet 2 Aplicação Servlet 3 Fig Comunicação entre cliente e servidor baseada na arquitetura de servlets. 2.4 Contexto de uma aplicação Uma aplicação é composta por um conjunto de servlets que precisam eventualmente compartilhar informações sobre o contexto da aplicação ao qual pertencem. Estas informações são disponibilizadas no objeto ServletContext, disponibilizado pelo Servlet Container, onde qualquer servlet deste conjunto pode consultar, adicionar ou remover informações relevantes a outros servlets que participam da mesma aplicação. 2.5 Sessão e Gerenciamento de Sessão Ao utilizar uma aplicação via Web, um cliente segue um protocolo: primeiro acessa a aplicação, depois troca informações com ela e depois sai da aplicação. Do ponto de vista da aplicação, o conjunto de interações entre cliente e aplicação seguindo este protocolo define uma sessão. Para cada sessão, o Servlet Container disponibiliza um objeto do tipo
21 9 HttpSession, que é unicamente identificado através de um SessionID. O objeto HttpSession permite que qualquer servlet que seja executado durante uma sessão possa nele consultar, adicionar ou remover informações relevantes a outros servlets que sejam executados na mesma sessão. Para atingir este objetivo, o SessionId é armazenado como um cookie no cliente [DEI01]. A cada solicitação, este cookie é recuperado e as informações sobre a sessão são disponibilizadas. Caso o browser cliente não aceite cookies, o sistema oferece uma opção chamada URL Rewriting, onde uma sessão é identificada através da composição da URL com uma SessionID. Neste caso, a SessionID é passada como parâmetro da URL em todas as solicitações. Este parâmetro tem o nome jssesionid. A vida de um objeto HttpSession no sistema é definida através de um tempo máximo de persistência (default 30 minutos) ou pode ser interrompida através do método invalidate(). É importante observar aqui que as solicitações feitas à aplicação utilizam o protocolo HTTP que é stateless, ou seja, não tem como identificar o estado do cliente a cada interação. Sendo assim, o gerenciamento de sessão deve ficar a cargo da aplicação. Uma maneira de fazer este gerenciamento é guardar o estado do cliente no próprio objeto HttpSession. Outra forma seria armazenar o estado do cliente em um banco de dados associado à sua SessionId [DAV00]. 2.6 Solicitações Ao fazer uma solicitação, um cliente envia dados a um servlet que, por sua vez, são armazenados em um objeto do tipo HttpServletRequest, criado a cada solicitação. O processamento de uma solicitação pode envolver um conjunto de servlets que eventualmente tenham que compartilhar dados. Todos os servlets envolvidos no processamento de uma única solicitação podem consultar, adicionar ou modificar dados do objeto HttpServletRequest que sejam relevantes a outros servlets executando a mesma solicitação. Através de um objeto do tipo RequestDispatcher, um servlet
22 10 pode redirecionar uma solicitação recebida para outro servlet. O fluxo de execução do servlet é interrompido assim que a solicitação é redirecionada. 2.7 Concorrência e sincronização de objetos O Servlet Container cria uma única instância de cada servlet, exceto no caso do servlet pertencer a um ambiente distribuído. Para cada instância, pode-se ter threads concorrentes acessando o mesmo serviço. Para garantir que um único thread por vez acesse o serviço de um servlet, este servlet deve realizar a interface SingleThreadModel. Neste caso, o Servlet Container pode escolher entre sincronizar os acessos a esta única instância ou então criar um pool de instâncias e despachar cada solicitação para uma instância diferente [SER01]. Entretanto o acesso às classes disponíveis para vários servlets, pertencentes a um escopo externo ao servlet, devem ser sincronizadas, se necessário, utilizando os recursos disponibilizados na API java.net. 2.8 Estrutura de um servlet Toda classe que tem a funcionalidade de um servlet realiza a interface Servlet. Os métodos definidos nesta interface são invocados pelo Servlet Container e compreendem os seguintes métodos [DEI01]: a) ServletConfig getservletconfig() Retorna um objeto que tem as informações básicas sobre as configurações do servlet, parâmetros de inicialização e informações sobre o ambiente onde o servlet atua, por exemplo, se o servlet pertence a um ambiente distribuído ou não. Este objeto é fornecido pelo servidor Web.
23 11 b) void init(servletconfig configuração) É invocado no momento da instanciação de uma classe servlet. Para isso, ele utiliza as informações contidas no objeto configuração. Neste método devem ser declaradas todas a tarefas a serem realizadas uma vez só durante a vida do servlet. Muitas aplicações abrem as conexões com um banco de dados neste método. Neste caso, o servlet vai se comunicar com o banco de dados sempre através da mesma conexão. c) void service(servletrequest request, ServletResponse response) É invocado ao receber uma solicitação do cliente. Este método é implementada toda a computação que descreve a funcionalidade do servlet. O Servlet Container permite acessos concorrentes a este método caso a interface SingleThreadModel não seja realizada pelo servlet. d) void destroy() É invocado antes de terminar um servlet. Este método geralmente libera os recursos alocados no método init(), por exemplo, o encerramento da conexão com um banco de dados. O Servlet Container só destrói as instâncias dos servlets que não estão sendo utilizadas por nenhum thread. Para que uma classe tenha a funcionalidade de um servlet ela deve estender a classe HttpServlet do pacote javax.servlet.http ou a classe GenericServlet do pacote javax.servlet. Ambas realizam a interface Servlet. 2.9 Classes utilizadas para solicitações e respostas Ao ser submetido, um formulário HTML envia uma solicitação a um recurso definido no parâmetro ACTION. Os tipos de solicitações mais comuns são GET e POST. Para solicitar o serviço de um servlet, o parâmetro ACTION deve ter o endereço URL deste
24 12 servlet. Ao receber uma solicitação um servlet executa as computações necessárias e gera como resposta uma página HTML. A classe HttpServlet é muito utilizada pelas aplicações Web. Ela disponibiliza dois métodos principais para responder uma solicitação HTTP, que são invocados automaticamente pelos seguintes métodos: a) doget(httpservletrequest request, HttpServletResponse response) Responde à solicitações GET. b) dopost(httpservletrequest request, HttpServletResponse response) Responde à solicitações POST. O primeiro parâmetro destes dois métodos contém as informações sobre o serviço solicitado e o segundo contém a resposta ao serviço Servlets x CGI Em termos de funcionalidade a tecnologia Servlets pode ser vista como uma tecnologia intermediária entre o modelo CGI (ANEXO 1 Seção 3.4) e extensões proprietárias para servidores Web tais como o Nestscape Server API (NSAPI) ou Apache Modules. Entretanto, a tecnologia Servlets apresenta as seguintes vantagens [SER01, LUB98]: a) Os servlets são extensões diretas de um servidor Web na forma de objetos que são carregados pelo servidor à medida que são solicitados. Cada servlet presente no sistema trata um determinado tipo de solicitação. Quando ocorre uma solicitação, é criado um thread associado ao servlet responsável pelo seu tratamento. No caso do modelo CGI, um processo inteiro é criado a cada solicitação. Uma vez que os
25 13 threads criados são computacionalmente mais leves que processos, esta diferença faz com que o desempenho dos servlets seja maior que a dos scripts CGI em termos de tempo de resposta e utilização de recursos. b) Os servlets são objetos que continuam ativos mesmo após o envio da resposta ao cliente. Desta forma, ele pode armazenar informações persistentes entre solicitações tal como a conexão a uma base de dados. c) A tecnologia Servlets herda vantagens da plataforma Java tais como independência de plataforma e acesso aos recursos disponibilizados pelas várias APIs de Java Exemplo Para entender melhor a mecânica associada aos servlets, apresenta-se um exemplo onde um usuário preenche o formulário apresentado na Fig. 4 do ANEXO 1. Quando o formulário é submetido, os dados são enviados a um servlet chamado RecebeDados. Este servlet cria um objeto com estes dados chamado cartao (classe CartaoCliente) e envia este objeto para ser aprovado pelo objeto credito (classe DepCredito). O objeto credito preenche o atributo estado do objeto cartao com true ou false, indicando a sua aprovação ou não. Conforme o caso, o servlet RecebeDados constrói dinamicamente uma página personalizada e envia ao cliente. A Fig. 2.2 ilustra este processo. Os códigos das classes RecebeDados.java, CartaoCliente.java e DepCredito.java encontram-se no ANEXO 2. A única alteração a ser feita no código da página HTML apresentado no exemplo do ANEXO 1 Seção 3.4 é a invocação do recurso no parâmetro da instrução de formulário. O recurso solicitado não será mais um programa CGI, mas sim o servlet RecebeDados, ou seja: <FORM METHOD="POST" ACTION="../servlet/RecebeDados">
26 14 exemplo.html credito valida envia dados cartao instancia invoca html RecebeDados (servlet) (ou) reprovado aprovado html Fig Estrutura de solicitação/resposta utilizando a tecnologia Servlets
27 Conclusão A tecnologia Servlets permite gerar conteúdo dinâmico como resposta a uma solicitação de um cliente. O conjunto de servlets de uma aplicação é administrado por um container que provê algumas funcionalidades aos servlets. Entre elas podemos destacar o gerenciamento de sessão e o gerenciamento de solicitações que simplificam o desenvolvimento de aplicações Web. A tecnologia Servlets pode ser enquadrada, em termos de funcionalidade, como uma tecnologia intermediária entre as tecnologias CGI e as extensões proprietárias de servidores Web [SER01]. Entretanto, como o conteúdo dinâmico da página de resposta é gerado através de um servlet, qualquer atualização, ainda que seja na parte estática da página, requer um especialista em programação para executar a modificação, recompilar a classe e disponibilizá-la na aplicação [HUN00]. A tecnologia JSP, apresentada no próximo capítulo, fornece uma solução a este problema.
28 Capítulo 3 JSP JavaServer Pages 3.1 Introdução A tecnologia JavaServer Pages (JSP) permite, a exemplo dos servlets, a geração de conteúdo dinâmico da resposta, mas através de uma especificação textual, permitindo assim que projetistas de Web tenham maior autonomia na criação e modificação de páginas Web. Diferentemente da tecnologia Servlets, entretanto, JSP separa o conteúdo estático da página do conteúdo dinâmico. O conteúdo estático é um molde que pode estar em qualquer formato, por exemplo, HTML (HyperText Markup Language), XML (Extensible Markup Language) ou WML (Wireless Markup Language). A lógica de geração do conteúdo dinâmico fica a cargo de comandos especiais da página JSP. Estes comandos podem conter pedaços de código de programação e/ou acessos a um recurso externo, por exemplo, um componente JavaBean [DEI01]. Este pode ser criado e utilizado por uma página JSP através de uma sintaxe especial. Quando alguma modificação no molde de uma página JSP é feita, esta é automaticamente recompilada e disponibilizada no servidor. A tecnologia JSP é uma extensão da API de Servlets. Sendo assim, existem muitas características comuns entre JSP e Servlets. Assim como os Servlets, as páginas JSP são componentes associados a um container. Cada página JSP passa por duas etapas: tradução e solicitação [JSP01]. O JSP Container é responsável pela execução da etapa de tradução da página JSP e pelo gerenciamento das solicitações das páginas pelos clientes. O modelo de componentes do JSP é baseado na arquitetura de componentes JavaBeans [BEA02]. Um componente bean é uma classe Java que segue determinados padrões. Por exemplo, todos os atributos, também chamados de propriedades, devem ser declarados como private e só podem ser manipulados externamente através de métodos modificadores e seletores.
29 17 A etapa de tradução de uma página JSP ocorre somente quando é feita a primeira requisição desta página. Neste momento é criada e compilada uma classe que realiza a interface Servlet. A classe criada tem três métodos principais que são invocados pelo JSP Container: jspinit(), _jspservice() e jspdestroy(). O método jspinit() é invocado quando a instância associada à página é criada e o método jspdestroy() quando a instância é destruída. A etapa de solicitação ocorre sempre que há uma requisição da página por um cliente. Para cada solicitação, o JSP Container invoca o método _jspservice() sobre a instância associada à página em questão. Este método é responsável por executar as ações necessárias para responder à solicitação [JSP01]. 3.2 Arquiteturas baseadas na tecnologia JSP A tecnologia JSP permite que a geração do conteúdo dinâmico seja toda feita dentro da própria página através da execução de pedaços de código de programação. Entretanto, esta visão vai de encontro aos objetivos de simplificar a criação de páginas Web e de ter uma divisão clara entre conteúdo estático e dinâmico [HUN00]. Para usufruir dos benefícios desta tecnologia dois modelos de arquitetura são muito utilizados: o Modelo I e o Modelo II [SES99, LAV02]. No Modelo I, todas as requisições de serviços da aplicação são recebidas e respondidas por uma página JSP. Ao receber uma solicitação, a página JSP faz o processamento necessário à solicitação e invoca um componente JavaBean. Este é responsável por recuperar/inserir os dados necessários em uma base de dados. De posse dos dados necessários, a página compõe a resposta e a envia ao cliente. O problema deste modelo é que, dependendo da complexidade do processamento, teremos ainda uma página cheia de código de programação. A Fig. 3.1 ilustra o Modelo I.
30 18 JSP CONTAINER solicitação Página JSP CLIENTE (Browser) resposta Página JSP requisita dados JavaBean recupera dados Aplicação BANCO DE DADOS Fig Modelo I Para aplicações mais complexas, o Modelo II propõe uma arquitetura baseada no padrão MVC (Model/View/Controller) [GAM94]. As requisições são recebidas por um Servlet ou página JSP. Este Servlet ou página JSP assume o papel de Controller e é responsável por criar os JavaBeans a serem utilizados na resposta, fazer o processamento necessário das informações e invocar a página JSP responsável pela composição e envio da resposta ao cliente. Os JavaBeans atualizados pelo Controller representam o Model do padrão MVC e a página JSP invocada pelo Controller assume o papel de View. Ela é responsável unicamente pela composição e apresentação da resposta ao cliente. Para isso, ela utiliza os beans previamente manipulados pelo Controller para associar as informações necessárias ao seu conteúdo estático. Este modelo deixa bastante clara a separação entre conteúdo estático e dinâmico. Enquanto a lógica de geração do conteúdo dinâmico fica a cargo do Controller, tipicamente desenvolvido por um especialista em programação, as páginas de apresentação ficam a cargo do View, podendo ser facilmente desenvolvidas por page designers. A Fig. 3.2 ilustra a arquitetura do Modelo II.
31 19 CLIENTE (Browser) solicitação resposta JSP CONTAINER repassa solicitação Página JSP ou Servlet Página JSP (Controller) instancia JavaBean acessa (Model) BANCO DE DADOS recupera dados Aplicação (View) Fig Modelo II 3.3 Objetos e sincronização de objetos em JSP A tecnologia JSP permite que objetos sejam instanciados e manipulados por uma página. A visibilidade destes objetos pode ser explicitamente definida no momento de instanciação, através do atributo scope. Este atributo pode assumir os seguintes valores [SES01]: a) page O objeto é acessível apenas pela página em que foi criado. A referência a este objeto é armazenada no objeto pagecontext e é eliminada quando a página responde à solicitação do cliente ou quando a solicitação é redirecionada.
32 20 b) request O objeto é acessível a todas as páginas que respondem à mesma solicitação. A referência a este objeto é armazenada no objeto request e é eliminada quando a solicitação é respondida. c) session O objeto é acessível a todas as páginas que respondem alguma solicitação associada à mesma seção. A referência a este objeto é armazenada no objeto session e é eliminada quando o sessão é terminada (timeout) ou invalidada. d) application O objeto é acessível a todas as páginas da aplicação. A referência a este objeto é armazenada no objeto application e é eliminada quando o ambiente elimina o objeto ServletContext. Alguns objetos, chamados implícitos, são automaticamente criados pelo container e ficam disponíveis para serem acessados por qualquer página JSP. A Tabela 3.1 ilustra quais são estes objetos, sua visibilidade e sua funcionalidade [JSP01]. Objeto Visibilidade Descrição pagecontext página contém informações de implantação que dizem respeito ao contexto da página (Ex: includes, imports, etc..) out objeto JSPWriter que escreve no stream de saída config equivalente ao ServletConfig (servlets) exception objeto Throwable gerado por um erro e não capturado page representa a própria página, equivalente ao operador this response solicitação equivalente ao HttpServletResponse (servlets) request solicitação equivalente ao HttpServletRequest (servlets) session sessão equivalente ao HttpSession (servlets) application aplicação equivalente ao ServletContext (servlets) Tabela 3.1 Objetos implícitos do JSP.
33 21 Como vimos, para cada solicitação o container JSP invoca o método _jspservice() da página requisitada. Se várias solicitações são enviadas simultaneamente para a mesma página, o container despacha cada solicitação em um thread diferente. Fica então a cargo da aplicação administrar a sincronização dos acessos aos objetos compartilhados. A tecnologia JSP oferece um mecanismo de sincronização de páginas equivalente ao mecanismo de sincronização de servlets, acessível através da declaração do diretivo: page isthreadsafe= true %> no início da página JSP. Neste caso, a classe associada à página JSP na etapa de tradução vai realizar a interface SingleThreadModel. O container cria várias instâncias desta classe e associa a cada instância uma solicitação. No caso em que muitas solicitações são recebidas ao mesmo tempo, como o número de instâncias é limitado, uma solicitação pode eventualmente ter que aguardar muito tempo para ser atendida. Neste caso, é recomendável que ao invés de sincronizar o acesso à página como um todo através do diretivo acima, seja feita apenas a sincronização dos objetos eventualmente compartilhados por várias páginas através do modificador syncronized da API java.net [SES00]. 3.4 Gerenciamento de sessão Para cada sessão aberta por um cliente é criado um objeto do tipo session. Este objeto tem uma identificação única que é armazenada no browser do cliente como um cookie. Neste objeto, é possível armazenar informações que podem ser acessadas por qualquer outra página que esteja associada à mesma sessão enquanto a sessão estiver ativa. O objeto session é destruído quando a sessão é invalidada ou fechada. 3.5 Sintaxe e semântica de páginas JSP Uma página JSP é composta de elementos e de um molde. Um elemento é um comando definido entre marcas especiais que é entendido e processado pelo container,
34 22 enquanto o molde é composto pelo resto da página. Por exemplo, o conjunto de comandos HTML de uma página representa um molde. Os elementos de uma página JSP são classificados em três tipos: diretivos, scripts e ações [SES01]. a) Diretivos Os diretivos são elementos usados para que a página comunique alguma informação ao JSP Container que será utilizada na fase de tradução. Os tipos de diretivos mais usados são o page, include e taglib. Através dos atributos do diretivo page pode-se importar classes que serão utilizadas pela página JSP, definir o tamanho de buffer da página, definir se os acessos à página devem ser sincronizados, definir a linguagem utilizada pelo script e definir se a página pode ter acesso aos objetos da sessão. Utilizando o diretivo include é possível incluir um outro arquivo ou página no lugar da página onde se encontra a marca. O diretivo taglib permite que sejam criadas marcas personalizadas pelo usuário para serem utilizadas em uma aplicação. Por exemplo, o elemento page import= java.util.* isthreadsafe= true %> informa ao container que a página vai utilizar recursos do pacote java.util e que a classe servlet correspondente à página em questão deve realizar a interface SingleThreadModel. b) Scripts Os elementos script são utilizados para criar objetos e fazer as computações que alteram o conteúdo dinâmico da página. Eles são classificados em: Declarações Permitem declarar variáveis ou métodos que serão utilizados por outro script da página. Por exemplo:
35 23 <%! String tipo_cartao = VISA ; %> Expressões São valoradas e seu resultado é inserido na página como um string. Por exemplo: <%= cartao.getnome() %> Comentários São utilizados para documentar uma página e não são incluídos na página de resposta ao cliente. Por exemplo: <%-- isto é um comentário --> Scriplets São pedaços de código que em geral contêm a lógica de geração do conteúdo dinâmico em resposta a uma solicitação. Os scriplets também são utilizados para fazer ações sobre objetos ou para executar ações condicionais. Por exemplo, o seguinte script constrói uma lista em HTML contendo os elementos do objeto NOMES: <% out.println( <UL> ); for (int i=0; i < NOMES.length(); i++) out.println ( <LI> + NOMES[i]); out.println( </UL> ); %>
36 24 c) Ações As ações são elementos através dos quais podemos fazer a comunicação entre uma página JSP e recursos externos. As ações podem ser pré-definidas no sistema ou podem ser definidas pelo usuário através do diretivo taglib. Entre as ações prédefinidas, as mais utilizadas são as que permitem instanciar e/ou manipular um objeto não implícito, geralmente um componente JavaBean, e redirecionar uma solicitação para um servlet ou outra página JSP. Para acessar um objeto que não é implícito, o JSP oferece a marca <jsp:usebean>. Através dos atributos desta marca são informados a classe do objeto, o escopo do objeto e a referência a este objeto. Por exemplo, o elemento: <jsp:usebean id= cartao class= CartaoCliente scope= request /> informa ao container que o objeto da classe CartaoCliente cuja referência é cartao vai ser utilizado pela página em questão. O container então procura um objeto com esta referência no escopo da solicitação. Caso o objeto não exista, um novo objeto da classe CartaoCliente é instanciado e associado à referência cartao no escopo request. Os valores dos atributos de um objeto são manipulados através dos elementos <jsp:getproperty> e <jsp:setproperty>. Uma página JSP pode redirecionar uma solicitação para outra página JSP ou para um Servlet através da marca <jsp: forward>. Por exemplo, o elemento: <jsp:forward page= Responde.jsp > redireciona a solicitação que está sendo processada pela página em questão para a página responde.jsp. Ao redirecionar uma solicitação, a execução da página em questão é interrompida. Neste caso, os beans eventualmente necessários podem ser passados como parâmetro através de marcas especiais ou acoplados ao objeto request referente à solicitação.
37 Exemplo Para ilustrar alguns elementos descritos, é apresentado a seguir uma versão JSP do exemplo apresentado no final do capítulo anterior. A Fig. 3.3 apresenta a estrutura equivalente à Fig. 2.2 do Cap. 2, agora utilizando páginas JSP segundo a arquitetura do Modelo II. CLIENTE SERVIDOR exemplo.html dados do formulário RecebeDados.jsp invoca credito valida redireciona solicitação Responde.jsp instancia consulta cartao (bean) html aprovado (ou) reprovado html Fig Estrutura de solicitação/resposta utilizando tecnologia JSP.
38 26 As páginas HTML apresentadas ao cliente são idênticas às da Fig A página RecebeDados.jsp recebe os dados do formulário exemplo.html. Com estes dados ela cria o bean cartao no escopo da solicitação. Este bean é alterado pelo objeto credito como no exemplo anterior. A página RecebeDados.jsp redireciona a solicitação para a página Responde.jsp. Esta página envia uma resposta ao cliente consultando o bean cartao que foi anexado ao objeto request. A única alteração a ser feita no código da página exemplo.html (cf. ANEXO 1 Fig. 3) é novamente a invocação do recurso no parâmetro ACTION da instrução de formulário, que agora deve conter a URL da página JSP que recebe os dados do formulário:... <FORM METHOD="POST" ACTION="../jsp/RecebeDados.jsp">... O código fonte das páginas RecebeDados.jsp e Responde.jsp encontramse no ANEXO 2. Não há alteração dos códigos das classes DepCredito.java e CartaoCliente.java.
39 Conclusão A tecnologia JSP estende a tecnologia Servlet visando simplificar a construção de páginas Web permitindo uma separação clara entre o conteúdo estático e dinâmico da página. Devido ao mecanismo utilizado pelo JSP Container, o conteúdo estático de uma página pode ser modificado e disponibilizado no servidor sem necessidade de précompilação. Desta forma, projetistas de páginas Web adquirem maior independência no trabalho de construção e manutenção destas páginas.
40 Capítulo 4 O Sistema de Vendas Online Casarão 4.1 Introdução Muitas empresas hoje adotam os sistemas de vendas Online como um canal de vendas alternativo para seus produtos. Estas empresas pertencem a diferentes ramos de negócio, como por exemplo, vendas de livros, CDs, materias de construção, aparelhos eletrônicos, produtos alimentícios, etc. Apesar da grande variedade de produtos comercializados, estes sistemas possuem, entre outras, as seguintes características comuns: a) Os produtos a serem vendidos são apresentados geralmente através de um catálogo. Este catálogo é muitas vezes sub-dividido em categorias de produtos para facilitar a navegação do cliente. b) Os produtos selecionados pelo cliente durante uma sessão são armazenados em uma estrutura de dados que pode ser consultada e modificada pelo cliente durante a compra. c) O pagamento pode ser efetuado de várias formas, sendo que o pagamento feito através de cartão de crédito é bastante utilizado devido à facilidade e segurança oferecida pelas tecnologias disponíbilizadas pelas empresas operadoras de cartões de crédito. d) Um cliente pode optar por fazer parte do cadastro de clientes da empresa para receber informações sobre novos produtos, liquidações, eventuais descontos, etc. Visando fazer um levantamento mais detalhado das principais características dos sistemas de vendas Online este trabalho adotou, a título de estudo de caso, um sistema de
41 29 vendas pela Internet para produtos relacionados à construção civil de uma loja fictícea chamada Casarão. Este capítulo apresenta a análise deste sistema, denominado Sistema de Vendas Online Casarão, que compreende um conjunto de funcionalidades ligadas à divulgação de produtos e procedimentos de compra conforme as características observadas acima. O objetivo da análise apresentada neste capítulo é o de fornecer um modelo de concepção para o projeto que será apresentado no próximo capítulo. É importante observar aqui que, dentro desse, as necessidades de segurança de troca de informações inerentes a este tipo de sistema não são consideradas. Além disso, as funcionalidades escolhidas tem como objetivo abranger apenas um conjunto básico de funcionalidades suficientemente expressivas para uma avaliação do projeto que será apresentado. Assume-se também alguns elementos implícitos ao sistema tais como um navegador HTML (por exemplo, o Netscape Communicator) e um servidor Web (por exemplo, o servidor Tomcat versão 4.03). 4.2 Aspectos gerais O sistema Casarão cumpre basicamente dois objetivos: 1) Disponibilizar via Internet um sistema de vendas de produtos da loja, onde qualquer cliente esteja habilitado a: Conhecer os produtos e preços da loja através de um catálogo. Preencher um pedido de compras e efetuar o pagamento via Internet. Acompanhar o estado do seu pedido a qualquer momento do processo. Cadastrar-se como cliente da loja. Poder entrar em contato com a empresa via correio eletrônico ou telefone. 2) Armazenar e processar todas as informações necessárias para atingir o objetivo anterior de forma integrada e consistente entre os seguintes departamentos: