desenvolvimentoWeb

Prévia do material em texto

UNIVERSIDADE FEDERAL DE PERNAMBUCO
Centro de Informática
Desenvolvimento de
 aplicações para web
- Sistemas de Informação -
Curso de Especialização em Tecnologia da Informação – Turma 8
Orientação: Professor Hermano Perrelli 
Autores
 Cristiana Neves Moreno (cris@unicap.br)
Juliana Medeiros (juliana.medeiros@serpro.gov.br) 
 Regina Maria Gomes Ferreira (regina@chesf.gov.br)
Rivaldo Cassimiro Júnior (Rivaldo@unicap.br)
�
Í N D I C E
INTRODUÇÃO
HISTÓRICO
O QUE SÃO APLICAÇÕES PARA WEB
COMO FUNCIONA UMA APLICAÇÃO NA WEB?
DESENVOLVENDO APLICAÇÕES PARA WEB
TECNOLOGIAS / FERRAMENTAS UTILIZADAS
TENDÊNCIAS ATUAIS
COMPUTAÇÃO COM OBJETOS DISTRIBUÍDOS: A TERCEIRA ONDA
PRINCIPAIS PADRÕES
DCE (DISTRIBUTED COMPUTING ENVIRONMENT)
COM
RMI (REMOTE METHOD INVOCATION)
SOCKETS
EJB (ENTERPRISE JAVA BEANS)
CORBA
JAVA: UMA EXTENSÃO NATURAL ÀS ESPECIFICAÇÕES CORBA
SISTEMA DE CUSTOS NA WEB: UM CASO PRÁTICO
BENEFÍCIOS OBTIDOS COM O USO DE APLICAÇÕES NA WEB
REDUÇÃO DRÁSTICA DO TCO	
ARQUITETURA ABERTA
USO EFICAZ DE RECURSOS
ONIPRESENÇA
NOVA INTERFACE
CONCLUSÃO
REFERÊNCIAS
ANEXOS
INTRODUÇÃO
Ao longo dos anos temos acompanhado, em muitas ocasiões deslumbrados ou estarrecidos, a evolução consideravelmente rápida da tecnologia nas mais diversas áreas.
Não desejando ir a um passado muito distante, nos reportamos ao tempo onde surgiam as primeiras operações computacionais. Naquela ocasião os computadores, utilizando-se de válvulas, eram instalados em ambientes físicos de dezenas de metros quadrados. Faziam o processamento Batch através de programas, que muito embora utilizando algumas técnicas científicas e matemáticas, eram elaborados praticamente de forma artesanal, servindo apenas àquela máquina e àquela empresa. Isto datava da década de 1940 aproximadamente.
Com o avançar dos anos, o mundo pode observar, de início timidamente e atualmente em uma velocidade quase inacreditável, a evolução dos computadores e de softwares. Vimos nascer novas gerações de mainframes, com toda a sua majestade e grandiosidade, aparentando serem eternos. Novas gerações de softwares (1ª, 2ª, 3ª e 4ª geração) também surgiam, já com a idéia de torná-los ao máximo independentes do hardware. Neste período se deu o início da era do Silício, onde surgiram os minúsculos transistores em substituições às gigantescas e quentes válvulas. Com isto houve condições de redução do tamanho de computadores, que levou na década de 1970 ao surgimento dos micros computadores, que pelo seu baixo custo, tornou-se acessível a um público pessoal, surgindo assim o que denominamos de Computador pessoal (PC).
A partir deste momento a evolução começa a ser acelerada. A cada dia novas aplicações surgem para os computadores pessoais. O foco principal agora seria interligar estes computadores, criando-se redes de transmissão de dados, inicialmente locais, com distâncias modestas, ou de longas distâncias considerando-se alguns quilômetros de distâncias.
Paralelo a este processo evolutivo, outras novas tecnologias foram também se desenvolvendo e se consolidando como alternativas de TI’s para as organizações. Dentre estas novas tecnologias destacamos banco de dados distribuídos, as redes locais e de longas distâncias, Internet, WEB, etc. Estamos acompanhando atualmente o desenvolvimento de tecnologias tipicamente orientadas a objetos, que adiciona uma melhor abstração do mundo real. Provavelmente, com o surgimento de novos negócios, todo este processo evolutivo persistirá, tendo como objetivo principal alcançar soluções viáveis financeira e tecnologica para os processos organizacionais.
Apresentaremos neste documento um pouco sobre o tema “Aplicações para a WEB” que se tornou nestes últimos anos foco de interesse de muitas empresas, dos mais diversos ramos de atividades.
�
HISTÓRICO
Para compreendemos melhor o tema de “Aplicações para a WEB”, devemos conhecer um pouco do que eram os sistemas antes do advento da Internet.
Antes de 1970, as aplicações ou sistemas tinham como característica processamentos locais efetuados em lote (batch) e em uma única máquina. Estas aplicações, inicialmente desenvolvidas para serem executadas em uma única máquina específica, ao final dos anos 60 / início dos anos 70, começam a ganhar portabilidade, podendo ser executadas em outras máquinas. Mesmo assim, os processos eram feitos de forma isolada.
Nesta época já se faziam algumas experiências com redes e a tecnologia de banco de dados começava a obter bons resultados e a ganhar apoio dos profissionais.
As aplicações eram desenvolvidas para serem usadas em um ambiente totalmente controlado, onde a compatibilidade dos elementos envolvidos (hardware e software) era fundamental ao sucesso do projeto.
A utilização de novas tecnologias começava a permitir o compartilhamento de dados entre os diversos usuários (banco de dados) e o processamento descentralizado (redes). Começávamos a observar o surgimento de uma nova arquitetura tecnológica, denominada cliente–servidor, entretanto, ainda necessitando de uma total compatibilidade entre os elementos componentes do sistema para que pudesse ser mantida a operabilidade do sistema, mesmo que estes elementos estivessem geograficamente a dezenas ou centenas de quilômetros de distância. Os custos de manutenção da estrutura de comunicação, feitos através da utilização de linhas dedicadas contratadas junto às concessionárias, eram bastante altos e críticos. 
Na segunda metade dos anos 80 surge (na verdade é disponibilizada abertamente) a Internet, uma rede mundial de computadores caracterizada pelo baixo custo de conexão. Pelo tipo de organização desta rede (bastante desorganizada para muitos), as empresas investiram inicialmente em serviços de marketing, utilizando-se especialmente a editoração eletrônica com o uso do HTML. 
Hoje, melhorados os níveis de segurança na internet e dos meios de comunicação, muitas organizações investem pesado em processos migratórios, com vistas a disponibilizar serviços na rede, que possibilitem vantagens estratégicas aos seus negócios. [1]
�
3. O QUE SÃO APLICAÇÕES PARA WEB
 	
A dimensão mundial e livre de fronteiras da WEB, combinada com sua portabilidade e facilidade de uso, faz dela um importante elemento de impulso da sociedade de informações do futuro. A WEB cresceu exponencialmente, e o número e a diversidade de usuários (indivíduos, empresas, governos etc.) e aplicações (educação, publicação on-line, comércio eletrônico etc.) estão se expandindo de modo contínuo. 
Diversas aplicações têm sido desenvolvidas para serem executadas na Internet. Sem dúvida, a World Wide Web ou simplesmente WEB, é a mais conhecida e utilizada.
Originalmente, a WEB foi idealizada através de conceitos consideravelmente básicos, fundamentando-se, por exemplo, em uma linguagem de representação de documentos muito simples e fácil de ser entendida e utilizada. Recursos mais complexos da tecnologia hipermídia, que já haviam sido amplamente explorados em projetos e produtos anteriores a WEB, não foram a ela incorporados.
Esta opção foi consciente e impulsionada pelo objetivo de tornar a WEB uma aplicação simples, para que fosse amplamente divulgada e utilizada – condição essencial para sua existência. Muito embora este objetivo tenha sido alcançado, observa-se que a WEB mostra-se, hoje, em sua versão original, incapaz de atender à demanda por novas aplicações.
Da simples facilidade de navegação, acesso e apresentação de informações para usuários humanos, a WEB tem sido exigida para suportar aplicações mais complexas, em que o destino final de um documento não é necessariamente um ser humano que irá visualizá-lo, mas sim outra aplicação que deverá interpretar e processar os dados contidos nos documentos veiculados pela WEB. Também se observa o surgimento a cada dia de novas aplicações que requisitamcada vez mais mecanismos da tecnologia hipermídia, que não estão incorporados a WEB.
Independente do porte da organização, nos dias atuais, nenhuma corporação pode se dar ao luxo de não considerar a Internet, como um novo paradigma para o desenvolvimento de sistemas de informações (SI). Qualquer browser hoje, por mais anônimo que seja, constitui-se num cliente em potencial. Também, funcionários podem ter acesso direto a recursos corporativos, bem como outras organizações podem acessar serviços de seus parceiros através da Internet. 
Tradicionalmente, a implementação dos Web Sites ocorre em três fases:
Provê informações de marketing e sobre produtos, mas de uma forma estática, pela utilização pura e simples de páginas HTML. 
Provê informações dinâmicas sobre serviços, por exemplo, possibilitando acesso a um catálogo ou uma procura sobre conexões de vôos.
Provê serviços transacionais. Tais serviços, tipicamente estão associados a sistemas corporativos, muitas vezes isolados nos chamados “Sistemas Legados”. Considerando-se que o acesso à Internet requer uma forma unificada e integrada de se acessar aplicações diversas, prover acesso a estes sistemas nos conduz ao segundo grande desafio, voltado à integração de sistemas [2].
3.1 COMO FUNCIONA UMA APLICAÇÃO NA WEB?
Para uma melhor compreensão, apresentamos de forma descritiva um exemplo típico do funcionamento de uma aplicação padrão orientada para a WEB:
Inicialmente, no WEB browser, o usuário entra com um endereço (URL), que aponta para uma página no servidor da empresa, servidor este mantido fora do Firewall corporativo. O servidor WEB recebe a solicitação do usuário e retorna uma página para o browser do cliente via protocolo http. Esta página contém um applet Java, tal que o usuário entra com uma solicitação de serviço, disponibilizada por este applet e ‘clica’ em um botão para obter a informação desejada. O applet utiliza um ORB(Object Request Broker) para se comunicar com um objeto de software, rodando por detrás do firewall da empresa, através de um protocolo IIOP (Internet InterORB Protocol). Este objeto faz uma consulta no banco de dados da empresa e retorna o resultado, através do ORB (Object Request Broker), à applet Java, que por sua vez mostra a informação ao usuário final. 
�
4. DESENVOLVENDO APLICAÇÕES PARA WEB
A dificuldade em se escalar a arquitetura cliente/servidor para a computação corporativa e, principalmente, para a Internet, levou a mudanças no foco da arquitetura cliente/servidor, quais sejam de desenvolvimento rápido de aplicações (RAD), para distribuição, manutenção e integração dos sistemas corporativos, e também, de aplicações departamentais, para integração enterprise e transações WEB.
A distribuição de objetos propicia uma melhora na qualidade das aplicações baseadas em WEB, agregando valores à Internet e intranets corporativas. Este relacionamento simbólico está criando uma mudança de paradigmas, da forma idealizada por nós: o design, desenvolvimento, integração, distribuição e manutenção de aplicações. Isto significa que o ciclo de desenvolvimento de SI, como tradicionalmente o conhecíamos, corresponderá às novas fases [2].
Nos últimos anos, além dos investimentos em infraestrutura, empresas têm investido expressivos recursos (financeiros, humanos e tempo) em ferramentas e metodologias que minimizem os esforços e aumente a eficácia das atividades de desenvolvimento de soluções para a plataforma WEB.
- Tecnologias / Ferramentas Utilizadas
Novas metodologias de análise orientada a objetos, baseadas na UML (Unified Modeling Language), constituem-se no passo inicial para se modelar sistemas. A UML tem se consolidado nos últimos anos como uma ferramenta eficaz para integrar metodologias de modelagem de sistemas definindo padrões de apresentação e de interfaces entre os diversos tipos de modelos (uma espécie de organizador da bagunça). Esta reorganização tem possibilitado o surgimento de ferramentas consideravelmente produtivas para a modelagem de sistemas (dados e funções). A UML define o gerenciamento de aplicações com objetos distribuídos que passa a ser uma das fases mais importante deste novo ciclo. 
A arquitetura da Web é do tipo cliente/servidor, com seu protocolo simples de comunicação padrão, o HTTP (HiperText Transfer Protocol) implementado sobre o TCP/IP, o onipresente protocolo da Internet. Com o HTTP, qualquer navegador cliente pode solicitar um documento em um servidor da Web usando seu localizador de recursos uniformes (URL – uniform resource locator). O ponto de entrada para um site da Web é sua home page, identificada por um URL. O HTTP permite o acesso a páginas da Web estáticas, isto é, páginas já armazenadas em arquivos no servidor da Web. Porém, os aplicativos da Web que acessam um SGBD ou algum outro servidor de arquivos devem criar páginas da Web dinâmicas. O protocolo CGI (Common Gateway Interface) torna isso possível, permitindo a um servidor da Web chamar um programa executável especificado no URL. Um exemplo típico desse tipo de programa é aquele que executa o acesso de SQL. A saída produzida pelo programa é devolvida ao servidor da Web e é utilizada para construir a página da Web dinâmica.
Com a Web, o cliente é altamente portável e às vezes é chamado “cliente universal”. Isso dá origem a uma nova forma de arquitetura cliente/servidor, chamada cliente/servidor de três camadas. Com a arquitetura cliente/servidor de três camadas, um servidor de aplicativos é introduzido para executar programas aplicativos. O cliente é um navegador da Web dedicado às interfaces gráficas. A lógica de aplicativo que pode ser necessária no cliente, por exemplo, para verificar a entrada de dados, pode ser admitida através de miniaplicativos, que são pequenos programas aplicativos baixados do servidor de aplicativos.
A arquitetura de três camadas pode se generalizar naturalmente para n camadas com vários servidores de aplicativos. A figura 1 ilustra essa generalização na qual podemos observar os passos que permitem o acesso a banco de dados a partir de um servidor da WEB, como na maioria dos SGBDs. O navegador da WEB se comunica com o servidor da WEB usando o protocolo de comunicação HTTP. O gateway do banco de dados é um programa da CGI que executa o mapeamento entre entradas de HTML e strings de consulta, e entre tuplas de resultados e formulários de relatórios de HTML. O gateway de banco de dados é chamado pelo servidor da WEB com o uso do URL e de entradas associadas (para a consulta) e envia uma requisição de consulta correspondente ao servidor de bancos de dados. Depois que a consulta é executada, ele transforma as tuplas de resultados em páginas de HTML dinâmicas. Desse modo, o desenvolvedor de aplicações pode usar tanto a HTML para criar formulários de consultas e relatórios, quanto à linguagem de banco de dados (SQL) para executar a consulta. [3]
Figura 1. – Acesso a banco de dados a partir de um navegador da Web [3]
 
A evolução das tecnologias utilizadas nas aplicações e os novos modelos de negócios implementados com o uso da internet influenciaram e foram influenciadas por mudanças no uso de banco de dados. Inicialmente as aplicações WEB tinham seus modelos de dados centralizados. Especialmente as grandes organizações, em decorrência das tecnologias acima citadas, começam adotar modelos distribuídos, especialmente as fortalecidas através de fusões. Lógico que mesmo sendo aplicação WEB uma tecnologia nova, os sistemas de banco de dados distribuídos mantém todos os conceitos e princípios próprios a este tipo de arquitetura. Alguns avanços forma alcançados em relação a banco de dados orientados a objetos, porém podemos observar que na grande maioria das aplicações(este número chega perto dos 100%), pela complexidade e risco relativos a investimentos em aplicações WEB, ainda são mais utilizados o consolidado BD relacional.
As tecnologias mais populares para criação de páginasdinâmicas existentes no mercado não são exceções. Tanto o ASP quanto o PHP têm suas origens no mesmo princípio: tornar páginas WEB mais flexíveis, e customizáveis. E o sucesso é inquestionável. 
De mesma forma é indiscutível o aumento da complexidade e volume de código exigido nas aplicações para atender às necessidades do mercado atualmente. Já não é mais suficiente criar páginas dinâmicas capazes de interagir com bancos de dados. O mercado precisa migrar aplicações complexas para o ambiente WEB, abandonar o modelo visual que exige estações parrudas (com grande capacidade de processamento), distribuir o processamento e acesso à aplicação através da Internet.
Nesse novo cenário, a página dinâmica não é mais o centro das atenções. Ela passa a ser apenas um elemento que faz parte de um contexto mais amplo: a aplicação WEB.
Do ponto de vista de funcionalidade, podemos dizer que praticamente todas as linguagens de scripting (ASP/PHP/MSP/JSP) oferecem elementos suficientes para se fazer o que se pretende. Cada qual com suas particularidades. Mas o que o desenvolvedor precisa se preocupar na hora de escolher a tecnologia mais adequada para seus projetos é com a arquitetura por trás de cada uma dessas alternativas.
Uma olhada nas origens de cada alternativa pode ser bastante útil. Tanto o ASP quanto o PHP foram originados a partir do artifício comumente utilizado pelas empresas de software, para estender a funcionalidade das páginas WEB. Nenhuma dessas tecnologias é baseada numa linguagem de programação, planejada e formalmente definida. A linguagem foi sendo construída de forma gradativa e, em muitas situações, até desordenada. Os recursos normalmente foram sendo acrescentados conforme as necessidades, sem muito planejamento.
As conseqüências dessa ausência de planejamento e estruturação da linguagem vão aparecer para o desenvolvedor na pior hora possível: quando a aplicação já está adquirindo proporções consideráveis. A manutenção pode se tornar cada vez mais complexa, a ponto de se tornar impraticável. Isso porque essas pseudolinguagens normalmente não podem ser compiladas. Não permitem que sejam criadas bibliotecas de componentes com código que possa ser colocado fora das páginas dinâmicas, para compartilhamento e reutilização por outras páginas.
A WEB é, por natureza, um ambiente heterogêneo onde diversas tecnologias convivem e cooperam entre si. Para o desenvolvedor, é importante escolher e empregar a tecnologia mais adequada ao projeto que está sendo executado. Na maioria das vezes, a preferência pessoal por esta ou aquela tecnologia precisa ser colocada em segundo plano, dando lugar a uma análise mais abrangente da necessidade do cliente. Por isso, é fundamental estar bem informado sobre todas as alternativas interessantes disponíveis no mercado.
- Tendências Atuais 
A integração de sistemas / aplicações heterogêneas é forçada por aquisições e uniões de corporações e, também, por imposições de mercado, especificamente aquelas causadas pela necessidade de se prover acesso à Internet. A heterogeneidade dos sistemas é multifacetada, já que existem diferentes sistemas operacionais, diferentes linguagens de programação, protocolos de rede, representações de dados, etc… A integração de sistemas deve resolver todas essas diferenças de uma forma segura e com alta performance. 
Ainda dentro das funcionalidades das aplicações WEB, observamos a tendência a processos de parcerias nos processos de negócios. Poderíamos resumir isto pelo fato de experiências já com um bom grau de sucesso de empresas que efetuam venda pela internet, já utilizarem serviços de análise de crédito e até mesmo financiamento oferecidos por financeiras ou administradoras de cartões de créditos. A requisição do serviço de análise de crédito ou de aprovação de financiamento é feita a partir da aplicação WEB da empresa que esta vendendo ao gestor de aplicações WEB da financeira/administradora de cartões. Neste caso, as aplicações de vendas e de análise de crédito e financiamento pertencem a organizações e servidores diferentes, e são feitas requisições aos serviços prestados pela financeira/administradora a partir da aplicação de vendas através de interfaces bem definidas para requisição de serviços e de resposta à requisição.
A onipresença da Internet e a possibilidade de, num clicar de um mouse, poder se comparar diferentes ofertas, implica uma enorme pressão competitiva nas organizações e conseqüentemente em suas estruturas de TI. Isto significa que produtividade em projetos de TI é um grande desafio. 
Os problemas supracitados e a forma como resolvê-los são fatores determinantes no futuro do desenvolvimento de software. 
Nesta era do cliente/servidor (ainda a realidade no Brasil), os times de desenvolvimento necessitavam criar a mesma funcionalidade diversas vezes. A reutilização de código é difícil. Usualmente, reutilizar código significa copiar um de seus segmentos, modificá-lo, e então, distribuir a cópia modificada. Com isto, módulos similares têm que ser atualizados e mantidos separadamente. Isto fatalmente conduz a inconsistências funcionais no SI corporativo. A internet expandiu as necessidades e horizontes das organizações. A partir deste fato as organizações adquiriram uma ampliação dos seus mercados, porém aos usuários podem ter sido adicionados um número infinitamente superior de informação e opções de serviços concorrentes de maneira fácil, geralmente através de um simples click do mouse. Com isto, mesmo estabelecidas na Internet, as empresas devem estar atentas que os seus diferencias devem estar muito mais em seus negócios que simplesmente na tecnologia aplicada. O uso da tecnologia se torna relevante quando proporcionar o provimento de informações com qualidade substancial que possam servir de suporte a atividade administrativa e a tomada de decisões, ou forneçam capacidade significativa de integrar rapidamente os diferencias de seu negócio e as aplicações consideradas críticas ao bem estar do negócio. 
Estamos agora no limiar da ‘terceira onda’, a onda ObjectWeb (objetos distribuídos + Web = ObjectWeb). [2]
Em relação aos sistemas operacionais, o Linux se apresenta como uma tendência cada vez mais forte, ao nível de sistema operacional, tanto de “back end”, quanto de estações clientes. Em julho de 1999, a Inprise/Borland realizou uma pesquisa sobre o Linux, em sites da Web em todo o  mundo, gerando mais de 24.000 retornos. O resultado foi uma expressiva ansiedade dos atendentes por soluções Linux, tanto ao nível de ferramentas de desenvolvimento, como de aplicativos. 
– Computação com Objetos Distribuídos: A Terceira Onda
As revoluções que estão acontecendo, devido à Internet e à computação com objetos distribuídos representam trajetórias convergentes. A Internet provê uma plataforma ideal para aplicações com objetos distribuídos, e desta forma, impulsiona o seu crescimento. 
O gerenciamento de aplicações com objetos distribuídos passa a ser uma das fases mais importantes deste novo ciclo. Imaginem um sistema complexo, com milhares de objetos de software, rodando seus processos em diferentes máquinas, servindo outros tantos milhares de objetos clientes, utilizando a Internet como meio de comunicação. O que fazer se um objeto ‘cair’? Que regras estabelecer para se instanciar objetos, já que determinados objetos dependem de outros para serem instanciados? Como ‘levantar’ objetos que funcionem como backup de outros? Evidentemente que, as respostas a estas colocações devem ter uma solução simples e fácil de ser implementada. Novos tipos de ferramentas surgem no mercado para solucionar o problema de gerenciamento, como é o caso do Application Center da Inprise. 
Sem dúvida, a próxima década será a década das aplicações multi-tier (multicamada). Na realidade, as aplicações com objetos distribuídos representam um caso particular, e provavelmente o que irá dominar, das aplicações multicamadas. Poderíamos classificar as aplicações multicamadas em dois grandes grupos:
-   Aplicaçõescliente/servidor multicamadas; e
-   Aplicações com objetos distribuídos
As aplicações cliente/servidor multicamadas representam uma evolução natural das aplicações cliente/servidor tradicional de duas camadas. Aqui, basicamente cria-se uma camada adicional com toda a lógica necessária para se acessar os dados, retirando-se do cliente esta tarefa. Desta forma, tem-se o que se chama de “thin client” (cliente magro), responsável principalmente pela lógica de apresentação ao usuário final, não havendo a necessidade de se ter no cliente nenhum driver, ou outra facilidade, para acessar bancos de dados. O cliente passa a se comunicar com o SGDB através do servidor de acesso, resultando daí algumas vantagens imediatas, como por exemplo, facilidade de manutenção, já que se passou a ter um único local para se atualizar e manter as funções de acesso a dados. Muito embora este tipo de aplicação multicamada represente novas facilidades, não existentes nas tecnologias da ‘segunda onda’, o tipo de aplicação multicamadas, responsável pela nova revolução que já estamos vivendo é o de aplicações com objetos distribuídos.
O ORB permite, entre outras coisas, que um objeto cliente, no caso o applet, utilize os serviços de um outro objeto, sem a necessidade de conhecer a sua localização e detalhes de sua implementação. Isto é obtido através do conceito de interfaces (estruturas puramente declarativas, sem nenhum detalhe de implementação), que funcionam como um ‘contrato’ entre os objetos cliente e servidor, permitindo a intercomunicação entre eles, de uma forma totalmente transparente para os desenvolvedores das classes/objetos cliente e servidor, é o que se chama de “location transparency”. Tudo que o desenvolvedor do objeto cliente precisa saber, é que existe em algum lugar, um outro objeto que implementa, por exemplo, uma função getStatusInformation, para a qual deve ser passado um parâmetro do tipo numérico e será retornado um valor string, correspondente ao status do pedido. Além disso o objeto cliente poderia estar rodando num PC Windows, num Macintosh, numa workstation Unix, network computer, palmtop, ou mesmo numa WebTV. O objeto servidor poderia estar implementado em Java, C++, COBOL, SmallTalk, Pascal, etc…, inclusive com a utilização de códigos legados. Estamos, portanto falando da independência de fornecedores de hardware e também da independência da linguagem utilizada para implementação, tanto do objeto cliente quanto do objeto servidor. [2]
– Principais Padrões
A internet como inicialmente elaborada (uso de páginas estáticas escritas em HTML) necessitou de uma definição de padrões que deveriam ser observados de forma a minimizar problemas de comunicação. Com o uso de aplicações WEB implementadas com acesso a banco de dados em ambientes distribuído e oferta de serviços onde a segurança tem caráter crítico, os padrões se tornam ainda mais necessários e a observação destes pelos implementadores de sistemas tem fundamental importância, mesmo que as aplicações sejam feitas para relacionamento dentre servidores. 
Hoje, na indústria, os principais padrões para computação distribuída encontram-se listados abaixo:
- DCE (Distributed Computing Environment); 
- CORBA (Common Object Request Broker Architecture); 
- COM (Component Object Model) / DCOM;
- RMI (Remote Method Invocation);
- TCP/IP Sockets programming;
- EJB (Enterprise Java Beans).
4.2.2.1 - DCE (Distributed Computing Environment) 
DCE é um padrão para objetos distribuídos utilizado em ambientes de grande porte. A mais recente implementação ‘roda’ em cima de TCP/IP.
4.2.2.2 - COM
COM / DCOM e sua nova versão COM+, presente na arquitetura DNA (Distributed Internet Application Architecture) do Windows 2000 da Microsoft é uma especificação dependente do ambiente Intel / Microsoft (WINTEL), pecando desta forma num ponto fundamental, que é o da portabilidade de plataformas de hardware. Atende bem os aspectos de computação distribuída na plataforma WINTEL, mas não pode ser considerado como referência para sistemas abertos (incluindo Java “boxes”, UNIX ”boxes”, AS/400, sistemas legados, etc…), onde CORBA representa realmente uma solução, a despeito dos produtos EntireX, inicialmente desenvolvidos pela Software AG, também conhecidos como DCOM para UNIX.
4.2.2.3 - RMI (Remote Method Invocation) 
RMI é uma especificação da Sun para chamadas do tipo RPC (Remote Procedure Call), em ambiente Java.
4.2.2.4 - Sockets 
Programação com sockets permite uma forma fácil, mas com limitações, de aplicações comunicarem-se entre si em uma rede, utilizando endereços TCP/IP do cliente e do servidor.
4.2.2.5 - EJB (Enterprise Java Beans) 
EJB é a mais nova especificação da SUN para objetos (“server side”) distribuídos, também em ambiente “pure” Java. EJB, em praticamente um ano, já conquistou o mercado, a ponto de, praticamente todos os principais fornecedores estarem disponibilizando soluções EJB container e EJB server. O EJB container da Inprise estará sendo comercializado no início do ano 2000. EJB utiliza a filosofia do “divide to conqueur”, através da definição dos papéis que cada tipo de desenvolvedor realiza. Por exemplo, o “bean provider” é um especialista no domínio da aplicação, no sentido de implementar a lógica do negócio, sem se preocupar com tarefas de mais baixo nível, como distribuição, transações, segurança, etc… EJB também faz uso de “design patterns e naming conventions” que permitem, por exemplo, ao “server e container providers” presumirem detalhes sobre o design da aplicação, de modo a suportá-la eficientemente. A figura abaixo apresenta um overview do que é a especificação EJB. Note-se toda uma gama de serviços que o “server provider” deve disponibilizar, desde serviços de distribuição a serviços de segurança. Observe-se também que os beans precisam de um EJB container para poder ‘rodar’.
4.2.2.6 - CORBA
CORBA é o mais importante e ambicioso projeto de middleware já desenvolvido pela indústria de software. É o produto de um consórcio, denominado Object Management Group (OMG) – http://www.omg.org/), que inclui mais de 800 companhias, representando o completo espectro da indústria de computação. Para o resto da indústria, exceção feita à Microsoft, a próxima geração de middleware é CORBA. O canal de comunicação CORBA define a forma pela qual os componentes interoperam e convivem com o ORB (Object Request Broker). Desta forma, escolhendo um canal de comunicação (object bus) aberto, é a escolha para se criar uma infra-estrutura também aberta para os componentes da aplicação interagirem. 
O que torna CORBA tão importante é o fato de que ele define um middleware que tem o potencial de incorporar todas as outras formas de middleware (inclusive client/server) existentes. Em outras palavras, CORBA utiliza objetos como uma metáfora de unificação, de modo a trazer aplicações já existentes para o “bus”. Ao mesmo tempo, provê uma fundação sólida para o futuro de aplicações baseadas em componentes. A mágica da arquitetura CORBA é que o sistema inteiro é autodescritivo. Adicionalmente, a especificação dos serviços é sempre separada de sua implementação. Isto permite se incorporar sistemas já existentes no “bus”. 
CORBA é um conjunto de padrões, incluindo:
Uma linguagem para definição de interfaces, a IDL (Interface Definition Language); 
Mapeamentos IDL para diferentes linguagens de programação (Java, C++, COBOL, SmallTalk, ADA, Pascal); 
Um protocolo para comunicação entre objetos em diferentes ORBs, o IIOP; 
Referências a objetos, IOR (Interoperable Object Reference). Uma referência a um objeto é o equivalente, em computação distribuída, a um ponteiro;
Métodos para se descobrir objetos ao nível da rede;
A palavra chave para CORBA é interoperabilidade / portabilidade / independência, entre plataformas, linguagens e fornecedores;
Um modelo para desenvolvimento de aplicações com objetos distribuídos;
Que objetos podem atuar como clientes, servidoresou ambos;
Suporte para desenvolvimento e administração de serviços de rede, abrangendo uma série de serviços, tais como, naming, events, trading, security, transactions, entre outros;
Alta performance em rede;
Altamente escalável. O que significa que um aumento na demanda de serviços pode ser facilmente suprida pela réplica do objeto servidor em uma nova máquina. O resto o ORB gerencia; e
Tolerância à falhas e balanceamento de cargas;
– JAVA: Uma Extensão Natural às Especificações CORBA
   
Falar de CORBA implica necessariamente uma referência à linguagem Java, sem dúvida a linguagem mais significativa no futuro do desenvolvimento de software. Quando Java foi introduzida, o seu foco principal era a programação no lado cliente. Java, hoje pode ser vista com duas colocações distintas e complementares: uma poderosa e fácil de usar linguagem para construir aplicações distribuídas do lado cliente; e uma linguagem e um ambiente para desenvolver aplicações midtier ou aplicações que rodem em Web servers, ambas as visões com o forte apelo da independência de plataforma (“write once and deploy anywhere”). Apelo este que vem proporcionando a grandes corporações a possibilidade de economizar milhões, com o aproveitamento inclusive dos chamados “legacy systems”, sem a necessidade de ter que se reescrever milhares de linhas de código. Por tudo isto, Java tem cativado muito mais do que a imaginação dos técnicos. Companhias, de todos os segmentos de negócios que se possa imaginar, de finanças a transportes, estão examinando alternativas para utilizarem Java. 
A linguagem Java propriamente dita é um estado da arte em termos de linguagem orientada a objetos (OO). O termo Java, como acima comentado, também é utilizado como uma referência à tecnologias de computação distribuída, indo de sistemas operacionais de pequeno porte a “heavyweight application services” . A introdução das tecnologias Enterprise Java Beans (EJB) e Java Servlets no âmbito das aplicações distribuídas possibilitou às companhias aumentar as opções em disponibilizar camadas de lógica de negócios e de acesso a dados, opções estas independentes do sistema operacional / plataforma, tanto no lado cliente como no lado servidor. 
Considerando o progresso que Java vem realizando na computação corporativa, julgo importante colocar duas questões chaves:
1) Por que Java representa hoje a melhor opção para se escrever aplicações corporativas, em especial para a especificação CORBA? 
2) Que ferramentas / tecnologias estão disponíveis para se escrever aplicações corporativas em Java?
Quanto à primeira pergunta, a principal razão para se usar a linguagem Java de modo a mapear uma interface definida em IDL (Interface Definition Language) é explorar a combinação de facilidades, únicas na linguagem Java:
Portabilidade entre plataformas;
Programação Internet;
Linguagem totalmente OO; e
Modelo de componentes
Da mesma forma, CORBA complementa as especificações Java, abrindo as portas para o mundo das aplicações / objetos distribuídos, através de paradigmas, tais como:
Interfaces definidas de forma independente de suas implementações;
Acesso a objetos implementados em outras linguagens de programação;
Acesso a objetos, independentemente de sua localização (location transparency);
Geração automática de código para lidar com chamadas remotas; e
Acesso a todos os serviços e facilidades CORBA (naming, trading, event, transaction service, security service, etc…)
Já para a segunda pergunta, a resposta está nas API´s corporativas, disponíveis hoje para a plataforma Java. Estas API´s podem ser genericamente classificadas em três categorias primárias:
1) APIs para acesso a dados JDBC 
Mapeamento Objeto-Relacional
Extensible Markup Language (XML)
2) APIs para comunicação entre objetos 
Remote Method Invocation (RMI)
Common Object Request Broker Architecture (CORBA / JavaIDL) 
Remote Method Invocation - Internet InterORB Protocol (RMI – IIOP) 
Enterprise JavaBeans (EJB) 
3) APIs Enterprise 
Java Naming and Directory Interface (JNDI) 
Java Message Service (JMS)
JavaMail (Jmail) 
Java Transaction Service (JTS)
Java Cryptography Extensions (JCE)
Servlets / JSP
 
�
5. SISTEMA DE CUSTOS NA WEB : UM CASO PRÁTICO
Uma aplicação para WEB não é apenas uma barata substituição para o que existe na plataforma cliente/servidor nas organizações. É um modelo de comunicação inteiramente novo e permite que as organizações foquem na melhor forma de se beneficiar com a tecnologia de Internet. Esse processo, prover equipes de desenvolvimento que possuem o potencial de simplificar os processos de negócio, aumentar o acesso a informação corporativa e de revolucionar o compartilhamento do conhecimento da empresa (knowledge sharing), tendo assim o custo de comunicação reduzido. 
O processo considera que grandes desafios são enfrentados pelos desenvolvedores, tais como: as mudanças culturais, o modelo de distribuição do software, segurança da informação, distribuição de dados e os impactos nos processos de negócio. Esses riscos devem ser balanceados com o custo, performance e políticas internas da organização na justificativa das decisões.
O sistema exemplificado abaixo, denominado CustosWEB foi desenvolvido na plataforma WEB, prestando atendimento a todas as unidades do SERPRO – Serviço Federal de Processamento de Dados.
O CustosWEB instrumentalizará a Superintendência de Gestão Financeira – SUPGF do SERPRO para:
Sistematizar o processo de apuração dos custos financeiros na empresa;
Gerar objetos de análise em forma de relatórios e consultas para a identificação dos valores apurados, bem como de possíveis distorções no âmbito de custos;
Disponibilizar às unidades gestoras informações geradas pelo sistema.
Dentro da visão do cliente, o CustosWEB permitirá:
Informações operacionais e gerenciais sobre o processo de apuração dos custos da empresa, no tocante aos custos de pessoal, equipamento, software, hardware, comunicação, Custos gerais administrativos (água, luz, telefone, etc) e outros custos (passagens, diária, ect);
As informações obtidas deverão permitir o contínuo monitoramento dos resultados e a identificação de erros ou distorções do processo para se promover as correções necessárias em tempo oportuno.
Modelo Conceitual
O Sistema foi projetado de forma que as informações estejam organizadas por região. Cada região concentrará dados de outras localidades da seguinte forma:
São Paulo: Sudeste
Brasília: Norte, Centro-oeste.
Curitiba: Nordeste e Sul
�
 Estrutura de Implementação
O sistema terá como suporte uma base de dados descentralizada em três estados: São Paulo, Brasília e Curitiba de forma que todas a localidades terão acesso ao banco de dados mais próximos. Todos os envolvidos poderão acessá-lo via INTRANET, através de browser. A base de dados ficará residente no SERPRO em cada localidade, que propiciará aos demais órgãos a entrada e o acesso aos dados para atualizações e consultas. 
A plataforma indicada, até o momento, é a descrita a seguir, podendo ser alterada por inovações tecnológicas que se apresentarem ou por análise da equipe de desenvolvimento. Cabendo, portanto, ao SERPRO a definição final sobre a plataforma a ser efetivamente utilizada, naturalmente sem nenhum prejuízo para os usuários do sistema.
Características básicas da plataforma:
Banco de Dados: SQL/Server
Linguagem de Programação: HTML, DHTML, Java Script, VB Script e ASP
Sistema Operacional: Windows 2000 nas estações dos clientes e Windows NT Server nos servidores.
Estrutura de Implementação:
Relacionam-se a seguir as necessidades básicas de Hardware e Software para a produção do sistema, com possibilidade de complementação, conforme necessidade. As versões dos softwares não foram especificadas por motivo de atualizações constantes, sendo utilizadas as versões mais atuais de cadaum.
Servidor WEB:
Máquina com configuração compatível com a demanda.
Windows NT Server
Windows NT Service
Internet Information Service (IIS)
Servidor de Banco de Dados:
Máquina com configuração compatível com a demanda.
Windows NT Server
Windows NT Service
Banco de Dados SQL/Server
Topologia de Rede:
A operação do sistema será viabilizada pela utilização da Intranet do SERPRO. A Intranet permite que as diversas unidades gestoras envolvidas com o sistema de custos atualizem as informações de seu escopo, bem como permite a disponibilização destas informações. A figura abaixo mostra a topologia necessária à operação do sistema.
�
BENEFÍCIOS OBTIDOS COM O USO DE APLICAÇÕES NA WEB
6.1 - Redução Drástica do TCO (Custo Total de Propriedade) 
Em aplicações convencionais utilizando-se arquitetura cliente/servidor, sempre foi muito comum se ter um TCO elevado, devido à necessidade de estações, tanto no cliente quanto no servidor, consideravelmente robustas. O que acontece com aplicações na WEB? Nestes casos as estações não precisam ter uma grande capacidade de processamento e nem tampouco requer softwares especialistas que propiciem o aumento da eficiência das estações em questão. Esta característica reduz o TCO. Diversos estudos comprovam que estações de trabalho baseadas em browsers (thin-client) apresentam redução do TCO de até quatro vezes em relação aos PCs (fat-client). 
6.2 - Arquitetura Aberta
A tecnologia Web está fundada em protocolos e componentes de software totalmente abertos, muitos deles open source. Isso significa mais flexibilidade para os desenvolvedores e total independência de fornecedor, além de favorecer a interoperabilidade e a escalabilidade. 
6.3 - Uso Eficaz de Recursos
Uso eficaz de recursos – Operando sob demanda, as aplicações construídas com a tecnologia Web utilizam com muito mais eficácia recursos normalmente caros, como processos de usuário, base do licenciamento de sistemas operacionais e de bancos de dados. Um único processo de acesso a banco de dados, por exemplo, é capaz de atender a múltiplas requisições vindas de vários usuários. Ou seja, os recursos são alocados ao usuário apenas enquanto durar sua conexão, possibilitando o acesso de maior número de usuários concorrentes. 
6.4 - Onipresença 
Onipresença – Enquanto no modelo tradicional é preciso instalar a camada cliente em cada uma das estações que irá executar determinada aplicação, no modelo Web o único requisito é a presença de um browser na estação de trabalho, que nem precisa ser um PC. AS atualizações de versão são feitas no servidor. O cliente ao acessar o servidor terá disponível automaticamente, uma nova versão da aplicação. Desse modo, resguardado os cuidados com a segurança, uma aplicação pode ser acessada de qualquer lugar, mesmo fora dos muros da corporação. 
6.5 - Nova Interface
A interface gráfica da tecnologia Web, baseada em linguagens de apresentação como TML e JavaScript, representa um novo paradigma onde prevalece a simplicidade e facilidade de uso, aliados a mais produtividade na sua construção. Mesmo suportando conteúdo multimídia, a interface Web não requer superestações de trabalho para ser executada, ao contrário da interface GUI tradicional.
�
CONCLUSÃO
Muito embora consideremos o paradigma relacionado a aplicações WEB como fato irreversível, nem tudo são flores. Não basta apenas migrar aplicações para o ambiente WEB. Isto não se trata de um modismo. Manter-se na Internet pode ter custos elevadíssimos e proibitivos para quem não procurou se preparar para este ambiente. 
Para que uma aplicação dentro deste ambiente possa alcançar o sucesso esperado, ela deve ter acima de tudo um planejamento muito bem executado. Deste planejamento devem constar:
Objetivos claros e bem definidos;
Identificação e Reconhecimento do público alvo;
Estratégia de Marketing apropriada;
Equipe responsável pelo desenvolvimento, manutenção e gestão do sistema devidamente capacitada e motivada;
Programar auditagem do sistema visando validar investimentos e (re)direcionar esforços em busca de melhores resultados.
O desenvolvimento de aplicações WEB, em ambiente corporativo, envolve projetos de grande complexidade, com necessidade de integração entre ambientes heterogêneos, utilização de metodologia e grande capacitação tecnológica. Acrescente-se neste contexto a necessidade de compartilhar dados que estão distribuídos e os requisitos de segurança que vem conferir credibilidade ao serviço disponibilizado pela aplicação WEB.
Os desafios de desenvolver aplicações distribuídas em um ambiente com estas características são imensos. Enquanto várias das características necessárias aos desenvolvedores de aplicações não distribuídas são valiosas, um conjunto totalmente novo de importantes e fundamentais características são necessárias para desenvolver aplicações distribuídas. [3]
Entretanto, os resultados e benefícios obtidos são fatores preponderantes para o sucesso das grandes corporações.
“Os executivos devem observar que a TI com o advento da Internet deixa de ser uma ferramenta de produtividade ou um centro de custos, onde quanto menor o custo do centro, melhor ele é. As aplicações da Internet (WEB) devem ser consideradas como elementos estratégicos dentro da organização. As empresas que criam uma divisão de internet separadas dos negócios regulares estão cometendo um grande erro”.[4]
“Um outro equivoco bastante comum nas organizações ocorrem ao tratarem as iniciativas (projeto e desenvolvimento de aplicações) para internet com implementações de ERP (Enterprise Resource Planning). Elas precisam ser mais velozes para alcançar suas metas de negócio”. [4]
Vemos com bons olhos, a iniciativa de pessoas, grupos de pessoas e organizações que trabalham em prol da elaboração de metodologias e modelos, bem como a criação de ferramentas que possibilitem uma redução de esforço e tempo no desenvolvimento de aplicações para WEB. Esperamos muito em breve já podermos escolher entre algumas destas ferramentas, a que melhor se adeque as nossas particularidades.
“Nos dias iniciais da revolução da Internet, as pessoas responsáveis pelo controle dos negócios em todo o mundo, estavam divididas em dois grupos. Aqueles que reconheciam o extraordinário poder e promessa da Internet e aqueles que não reconheciam. Somente uma dessas facções, os web-revolucionários, sobreviverá”.[5]
�
REFERÊNCIAS
[1] www.microsoft.com
[2] www.borland.com
[3] Princípios de Sistemas de Banco de Dados,
M. Tamer Ozsu e Patrick Valduriez, Editora Campos
[4] Sue Bostrom – Vice-pesidente sênior do grupo de soluções da CISCO, PCWORD Online do dia 02/07/200 [ http://pcworld.terra.com.br/pcw/update/3964.html ]
[5] www.inprise.com
�
9. ANEXOS
Anexo1 - Tela de Entrada de Dados do Sistema CustosWEB
Anexo2 – Relatório do Sistema CustosWEB
�
Anexo1 – Tela de Entrada de Dados do Sistema CustosWEB
Anexo2 - Relatório Gerado pelo Sistema CustosWEB
SQL dinâmica
CGI
HTTP
Formulário
de HTML
Tuplas
Consulta
Servidor 
de banco
de dados
Chamada de Consulta
Formulário de HTML
URL + Entradas
Gateway de banco de dados-		 	
Servidor da Web
Navegador da
Web
BRASÍLIA
CURITIBA
SÃO PAULO
�PAGE �
_1063041238.vsd