Multi Camadas

1
FUNDAO DE ENSINO EURPIDES SOARES DA ROCHA CENTRO UNIVERSITRIO EURPIDES DE MARLIA - UNIVEM FACULDADE DE ADMINISTRAO
ARTHUR ANDREAZI NETO LUCAS SIMES MAISTRO WILLIAM MARTO RODRIGUES
SISTEMAS MULTI-CAMADAS: UMA TENDNCIA PARA O DESENVOLVIMENTO DE APLICAES
MARLIA 2004
Monografia apresentada a Faculdade de Administrao do Centro Universitrio Eurpides de Marlia, mantido pela Fundao de Ensino Eurpides Soares da Rocha, para obteno do Ttulo de Bacharel em Administrao com Habilitao em Anlise de Sistemas.
Orientador: Prof. Mestre Elvis Fusco
MARLIA 2004
Banca examinadora da Monografia apresentada a faculdade de Administrao da UNIVEM/F.E.E.S.R., para obteno do Ttulo de Bacharel em Administrao com Habilitao em Anlise de Sistemas.
Resultado: _______________________________________
ORIENTADOR: Prof. Mestre Elvis Fusco
1 EXAMINADOR:___________________________________________________________
2 EXAMINADOR:___________________________________________________________
Marlia, 18 de Outubro de 2004.
Primeiramente, dedicamos este trabalho a todos aqueles que nos ajudaram direta ou indiretamente para elaborao do mesmo. Eu Arthur, dedico totalmente esse trabalho aos meus pais (Jos e Cleuza) que tanto batalharam para eu poder cursar essa faculdade, que esta sendo uma oportunidade muito importante na minha vida.
AGRADECIMENTOS
Inicialmente agradecemos a Deus por nos proporcionar a vida e nos permitir estar presente para elaborao dessa pesquisa. Agradecemos nossa famlia, por sempre nos dar foras nos momentos difceis, e como foram difceis, durante esse perodo de elaborao. A nossas namoradas e amigos que sempre estiveram presentes nos dando apoio, e nos agentando falar sempre sobre isso. Agradecemos ao Elvis (Professor e Orientador), que nos conduziu no caminho certo, para podermos estar aqui a um passo do nosso objetivo. Valeu Rodrigo pelo resumo em Ingls, muito obrigado Jader (Jadinho) pelo resumo em Espanhol, e por nos ajudar a qualquer momento, principalmente com os padres da ABNT.
Muito Obrigado a Todos.
Ter obstculos na vida inevitvel... ...ser derrotado por eles opcional.
ANDREAZI NETO, Arthur; MAISTRO, Lucas S.; RODRIGUES, William M. Sistemas Multi-Camadas: Uma Tendncia para o Desenvolvimento de Aplicaes. 2004. 85f. Trabalho de Concluso de Curso Centro Universitrio Eurpides de Marlia, Fundao de Ensino Eurpides Soares da Rocha, Marlia, 2004.
RESUMO
Com o avano tecnolgico cada vez mais rpido e o uso da informtica cada vez mais presente nos diversos setores de uma sociedade, as dificuldades de encontrar solues para os problemas comuns presentes na maioria das aplicaes se destacam mais e tambm com o nmero de usurios de sistemas crescendo gradativamente surge uma necessidade de melhoria no conceito de desenvolvimento. Essa pesquisa inicia com uma parte conceitual das arquiteturas, comeando pelo processamento centralizado (MainFrame), em seguida chegando ao Cliente/Servidor mostrando o desenvolvimento com regras de negcios na camada Cliente, regras na camada Servidora e regras mesclando as duas camadas, apontando vantagens e desvantagens de seu uso. Logo aps, entra no conceito de Multi-Camadas focando a sua estrutura e vantagens, comparando-a com o modelo Cliente/Servidor. Tambm mostrada uma introduo tcnica sobre alguns conceitos e informaes fundamentais para o desenvolvimento Multi-Camadas. E para demonstrar a utilizao dessa arquitetura, foram utilizados trs ambientes de desenvolvimento: Delphi, Java, ASP.NET.
Palavras-chave: Middleware. Cliente/Servidor. Multi-Camadas.
ABSTRACT
With the new technological advance growing each time and the use of the informatics each time more inside our lives and on the various sectors of a society, the difficulty on finding solutions for the common problems presents on the most of the applications that most are noticed and also with the system s users number growing gradually comes a necessity of increasing the development concept. This search beginning with a conceptual part of architectures, starting by the centralized process (MainFrame), and on the sequence getting to the Client/Server showing the development with business rules on the Client layer, rules on the layer Server and rules mingled the two layers, pointing advantages and disadvantages of its use. Right after get into the Multi-Layers concept focusing its structure and advantages, comparing it with the Client/Server model. It s also showed a technical introduction about some concepts and informations fundamental for the Multi-Layers development. And to demonstrate the utilization of this structure there were used three environments for development: Delphi, Java, ASP.NET
Keywords: Middleware. Client/Server. Multi-Layers.
RESUMEN
Con el avance tecnolgico cada vez ms rpido y el uso de la informtica cada vez ms hallado en los diversos sectores de una sociedad, las dificuldades de encontrar soluciones para los problemas comunes encontrados en la mayora de las aplicaciones se destacn ms y tambin con el nmero de usurios de sistemas aumentando gradativamente surge una necessidad de mejora en el concepto de desarollo. Este trabajo se empeza con una parte conceptual de las arquitecturas, empezando por el procesamiento centralizado (mainframe), despus llegando al Cliente/Servidor mostrando el desarollo con reglas de negcios en la camada cliente, reglas en la camada servidora y reglas mezclando las duas camadas, apuntando ventajas e desventajas de su uso. Despus, entrase en el concepto de multi-camadas enfocando su estructura y ventajas, la comparando con el modelo Cliente/Servidor. Tambin es mostrado una introduccion tcnica sobre algunos conceptos y informaciones fundamentales para el desarollo multi-camadas. Y para demostrar la utilizacin de esa arquitectura, fueran utilizados tres ambiente de desarollo: Delphi, Java, ASP.NET.
Palabras-Clave: Middleware. Cliente/Servidor. Multi-camadas
10
LISTA DE ILUSTRAES
FIGURA 1 Modelo Cliente/Servidor.....................................................................................18 FIGURA 2 Modelo Trs Camadas........................................................................................21 FIGURA 3 Arquitetura Cliente/Servidor e Trs Camadas....................................................24 FIGURA 4 Arquitetura N-Camadas......................................................................................28 FIGURA 5 Middleware de Comunicao..............................................................................31 FIGURA 6 Arquitetura DataSnap para aplicaes distribuidas.............................................32 FIGURA 7 Modelo de Aplicao DataSnap..........................................................................44 FIGURA 8 Camadas de Aplicaes da Web.........................................................................47 FIGURA 9 Fluxo de Programa centrado em pginas............................................................51 FIGURA 10 Fluxo de Programa em uma aplicao centrada em servlets.............................53 FIGURA 11 FIGURA 12 FIGURA 13 FIGURA 14 FIGURA 15 FIGURA 16 FIGURA 17 FIGURA 18 Uma aplicao de catlogo centrada em servlets..............................................54 Um EJB lidando com a lgica da aplicao......................................................64 Estrutura .Net com a linguagem ASP.NET.......................................................67 Demonstra a arquitetura de uma aplicao ASP.NET......................................70 Aplicaes Web ASP.NET...............................................................................71 As diversas camadas funcionais no modelo de programao .NET.................76 Esquema de Integrao do ADO.NET..............................................................78 Viso sobre o desenvolvimento para internet...................................................80
11
LISTA DE ABREVIATURAS
ASP: Active Server Pages AO: Object Adapter BI: Business Intelligence BOA: Basic Object Adapter CGI: Commom Gateway Interface CLR: Commom Language Runtime CLS: Commom Language Specification COM: Componente Object Model CORBA: Common Object Request Broker Architecture COM+: Componente Object Model Plus CRM: Customer Relationship Management DCOM: Distributed Componente Object Model DLL: Dynamic Link Library ERP: Enterprise Resource Planning EJBS: Enterprise JavaBeans GUI: Graphic User Interface HTTP: Hyper Text Transfer Protocol IDL: Linguagem de Definio de Interfaces IIOP: Internet Inter Orb Protocol JSP: Java Server Pages JDBC: Java Database Connectivity MIDL: Microsoft Interface Definition Language
12
MTS: Microsoft Transsaction Server NGWS: Next Generation Windows Services OMG: Object Management Group ORB: Object Request Broker ORPC: Object Remote Procedure Call POA: Portable Object Adapter RMI: Remote Method Invocation SCM: Service Control Manager SGDB: Sistemas Gerenciador de Banco de Dados SOAP: Simple Object Access Protocol
13
SUMRIO
INTRODUO ........................................................................................................................15 METODOLOGIA ......................................................................................................................16 1. CONCEITOS ........................................................................................................................17 1.1. APLICAES EM UMA CAMADA .......................................................................................17 1.2. APLICAES EM DUAS CAMADAS ....................................................................................18 1.2.1. Regras na interface..................................................................................................19 1.2.2. Regras junto dos dados ...........................................................................................19 1.2.3. Regras junto interface e junto aos dados..............................................................20 1.2.4. Problemas do cliente / servidor...............................................................................20 1.3. APLICAES EM TRS CAMADAS:....................................................................................21 1.3.1. As camadas .............................................................................................................22 1.3.1.1. Camada de apresentao ..................................................................................22 1.3.1.2. Camada de Negcio .........................................................................................22 1.3.1.3. Camada de dados .............................................................................................23 1.3.2. Vantagens da tecnologia Multi-Camadas ...............................................................23 2. COMPARATIVO - APLICAES TRS CAMADAS X DUAS CAMADAS.................24 2.1. O MODELO CLIENTE SERVIDOR ........................................................................................25 2.1.1. Manuteno do aplicativo .......................................................................................25 2.1.2. Distribuio do aplicativo .......................................................................................25 2.1.3. Performance ............................................................................................................26 2.2. O MODELO TRS CAMADAS ............................................................................................26 2.2.1. Manuteno do aplicativo .......................................................................................26 2.2.2. Distribuio do aplicativo .......................................................................................27 2.2.3. Performance ............................................................................................................27 3. APLICAES MULTI-CAMADAS COM DELPHI .........................................................29 3.1. OBJETOS..........................................................................................................................29 3.1.1. Objetos distribudos ................................................................................................30 3.2. SISTEMAS DISTRIBUDOS .................................................................................................30 3.3. MIDDLEWARE .................................................................................................................31 3.4. DATASNAP ......................................................................................................................32 3.5. MULTITIER (MULTICAMADAS).........................................................................................33 3.6. OS PROTOCOLOS..............................................................................................................33 3.6.1. CORBA (Common Object Request Broker Architecture)......................................34 3.6.2. COM (Component Object Model) ..........................................................................35 3.6.3. DCOM (Distributed Componente Object Model) ..................................................36 3.6.4. MTS (Microsoft Transaction Server) .....................................................................37 3.6.5. COM+ (Componente Object Model Plus) ..............................................................37 3.6.5.1. Eventos COM+ ................................................................................................38 3.6.6. Sockets ....................................................................................................................39 3.6.7. HTTP (Hyper Text Transfer Protocol) ...................................................................40 3.6.8. SOAP (Simple Object Access Protocol).................................................................41
14
3.7. COMPONENTES DO DELPHI PARA DESENVOLVIMENTO EM CAMADAS ..............................42 3.8. FUNCIONAMENTO DE UMA APLICAO DATASNAP .........................................................43 4. A TECNOLOGIA JAVASERVER PAGES (JSP) ...............................................................46 4.1. O JAVASERVER PAGES ....................................................................................................46 4.2. AS CAMADAS ..................................................................................................................47 4.2.1. A camada de apresentao ......................................................................................47 4.2.2. A camada de lgica de aplicao ............................................................................48 4.2.3. A camada de controle .............................................................................................48 4.2.4. A camada de banco de dados ..................................................................................49 4.3. CONEXO COM A BASE DE DADOS ..................................................................................49 4.4. ARQUITETURAS JSP ........................................................................................................50 4.4.1. Design Centrado em Pginas ..................................................................................50 4.4.2. Design centrado em Servlets...................................................................................52 4.4.3. Servlets para controle da aplicao.........................................................................53 4.5. ENTERPRISE JAVABEANS ................................................................................................55 4.5.1. O que so JavaBeans?.............................................................................................55 4.5.2. Diferena entre JavaBeans e Enterprise JavaBeans................................................56 4.5.3. Containers EJB .......................................................................................................57 4.5.4. A arquitetura Enterprise JavaBeans ........................................................................58 4.5.4.1. Java RMI (Java Remote Method Invocation) ..................................................59 4.5.5. Os elementos dos componentes Enterprise JavaBeans...........................................60 4.5.6. Tipo de componentes ..............................................................................................62 4.5.7. Servidores de aplicao ..........................................................................................63 5. PLATAFORMA .NET..........................................................................................................65 5.1. XML..........................................................................................................................65 5.2. ESTRUTURA .NET ...........................................................................................................66 5.2.1. CLR COMMON LANGUAGE RUNTIME........................................................................67 5.2.2. .NET FRAMEWORK CLASS LIBRARY ......................................................................68 5.3. SYSTEM NAMESPACE .......................................................................................................68 5.4. ASP.NET........................................................................................................................69 5.5. PRINCIPAIS VANTAGENS DESTA TECNOLOGIA ..................................................................70 5.5. WEB FORMS ....................................................................................................................72 5.6. WEB SERVICES ................................................................................................................72 5.7. MULTI-CAMADAS NA PLATAFORMA .NET......................................................................73 5.7.1. Servios de Apresentao .......................................................................................74 5.7.2. Servios de negcios...............................................................................................74 5.7.3. Camada de Gerenciamento .....................................................................................75 5.7.4. Camada de regras de negcio .................................................................................75 5.7.5. Camada de Dados ...................................................................................................76 5.7.6. Servios de dados....................................................................................................79 6. AMBIENTE WEB: UMA PLATAFORMA MULTI-CAMADAS .....................................80 CONCLUSO ..........................................................................................................................82 REFERNCIAS........................................................................................................................84
15
INTRODUO
Com a competitividade fazendo parte do conjunto global de uma empresa, e os Sistemas de Informao estando cada vez mais presentes no apoio as tomadas de deciso, surge sempre a necessidade de aumentar esse diferencial tecnolgico competitivo de cada organizao. Vrias possibilidades esto disponveis no mercado como ERP (Enterprise Resource Planning Management Planejamento de Recursos Empresariais), CRM (Customer Relationship Gerenciamento de Relacionamento com Cliente), BI (Business Intelligence
Inteligncia Empresarial), entre outras, mas a questo : qual dessas ferramentas se adapta melhor na organizao? E agora tambm qual a arquitetura a ser utilizada? O desenvolvedor de hoje tem esse requisito a mais para levantar na sua anlise de projeto, ou seja, vivel continuar na arquitetura mais utilizada atualmente, usando o Cliente / Servidor? Ou deve-se j migrar para uma nova tendncia que o modelo Multi-Camadas? Essa pesquisa tem esse propsito, mostrar os conceitos, a estrutura e como funciona as arquiteturas, vindo desde a era do Mainframe, passando pelo Cliente/Servidor e finalmente chegando nas aplicaes Multi-Camadas, sempre destacando suas vantagens e desvantagens. Tambm foi feito um comparativo entre Cliente/Servidor e Multi-Camadas com a finalidade de mostrar que problemas encontrados na estrutura atual podem ser resolvidos com a implementao de aplicaes em vrias camadas. E uma parte introdutria em algumas plataformas (tecnologias) que do suporte ao desenvolvimento de sistemas em camadas. Com isso, o trabalho visa ajudar o desenvolvedor na escolha de uma metodologia, j que um dos segredos para o sucesso de um sistema est na escolha arquitetura. adequada de sua
16
Metodologia
Com auxlio de livros, revistas, dissertaes de mestrado e artigos, tambm conflitando as idias dos autores, foram colhidas informaes sobre a parte conceitual das camadas, explicando a evoluo das arquiteturas at chegar no modelo Multi-Camadas alm de informaes sobre ferramentas para o seu desenvolvimento. Dando base para o andamento do trabalho e chegando a um consenso final sobre o assunto.
17
1. CONCEITOS
1.1. Aplicaes em uma camada
As aplicaes baseadas em nica camada, tambm conhecidas como aplicaes Mainframe possuem uma arquitetura na quais seus componentes esto integrados em um nico programa, sendo executado em apenas uma mquina. Sendo assim possuem terminais burros1 , pois os processos so centralizados na mquina Mainframe (Sistema Computadorizado de Grande porte), restando ao terminal apenas a funo de apresentar as informaes processadas. Devido a esse fator o trafego de informaes causa uma sobrecarga na rede deixando-a lenta.
A abordagem baseada em nica camada prov um nmero significante de vantagens. Desde que uma aplicao seja centralizada em um ambiente singular, essa aplicao mais fcil de executarmos o gerenciamento, controle, e implementar segurana.(GRANDO, BOMFIM, LDA, 2000, PG.3) No entanto, estas aplicaes tm um problema com questes de escalabilidade, pois para estas aplicaes crescerem na sua proporo de nmero de usurios, preciso migrar para uma mquina com mais recursos. Ainda temos o problema de que estas aplicaes tm dependncia no ambiente operacional baseado no hardware, e como resultado, estas empresas no podem tirar proveito de novas tecnologias enquanto estas no ficarem disponveis pelo fornecedor. (POOL DE CONEXO E TRS CAMADAS, 2004)
Terminais Burros: mquinas onde no h processamentos.
18
1.2. Aplicaes em duas camadas
Estas aplicaes so conhecidas como Cliente / Servidor, onde dividem a aplicao nas estaes e no servidor de dados, comumente divididas na primeira camada (cliente) onde se encontra a apresentao, as regra de negcios e o acesso aos dados, e fazem a requisio de informaes que consta no servidor, assim, se conectam a uma segunda camada (servidor), onde h ligao com o SGBD (Sistema Gerenciador de Banco de Dados) que serve aos clientes o que foi solicitado, como mostra a Figura 1. Toda ligao entra a maquina cliente e a servidora feita por protocolos de comunicao (ex. TCP/IP). uma arquitetura que trouxe vantagens em relao a sua antecessora (mainframe) que aumentou a velocidade na rede, o processamento deixou de ser totalmente centralizado, entre outras.
Figura 1 Modelo Cliente / Servidor
Trabalhando com essa arquitetura, h trs opes ao se desenvolver, como: Regras na Interface, Regras junto dos Dados e Regras Junto a Interface e junto aos dados.
19
1.2.1. Regras na interface
Para sistemas de pequeno porte uma boa opo, mas para outros tipos de sistemas torna-se um problema pelas seguintes questes: Dificuldades de Manutenes: complicado na hora de modificar regras em componentes da aplicao, que podem estar dispersas dificultando a sua localizao, por exemplo. Aumentando o grau de dificuldade, se quem for fazer a manuteno, no for o criador do sistema. Reaplicao das Regras: necessrio modificar todas as ligaes como uma tabela, no caso, quando a regras que atualizam essa determinada tabela forem alteradas. Dificuldades de Distribuio: quaisquer modificaes nas regras tero que redistribuir a aplicao, tornado-se trabalhoso, ainda mais se for um sistema de vrios usurios.
1.2.2. Regras junto dos dados
Com essa metodologia de desenvolvimento liga-se diretamente a aplicao com o banco de dados escolhido, por estar utilizando seus recursos como Stored Procedure, Triggers, Views, etc. Tornando muito trabalhosa a possvel troca para um outro banco de dados.
20
E tem a questo da limitao de cada banco de dados, que variam de um banco para outro, tendo funes em uns que no existem em outros e vice-versa. A questo positiva nesse caso o ganho de desempenho, pois as informaes j esto centralizadas no banco de dados, onde aumenta a velocidade do seu processamento. Outra questo a questo se segurana que limita o acesso ao banco de dados.
1.2.3. Regras junto interface e junto aos dados.
a opo mais adequada para esse tipo de arquitetura, balanceando as regras de negcios para no entrar nos problemas descritos acima. Mas importante ressaltar que essa metodologia no elimina todos os problemas encontrados no modelo Cliente / Servidor.
1.2.4. Problemas do cliente / servidor
Apesar de essa arquitetura ser superior a sua antecessora (Mainframe), por apresentar aplicaes com interface para o usurio, com dezenas de clientes suportados e diminuio do trafego da rede, o cliente / servidor apresenta desvantagens como na: Gerncia de segurana, usurios, aplicaes; Integrao de sistemas;
21
Requisies ao servidor, mesmo os clientes tendo acessos distintos, podem sobrecarregar a rede;
1.3. Aplicaes em trs camadas:
As aplicaes trs camadas, tambm conhecidas como multi-camadas ou multi-tier, a evoluo do modelo cliente / servidor, onde surge uma (ou mais) camada intermediria entre a parte cliente e o servidor de dados. O ponto fundamental desse modelo a diviso distinta entre as camadas onde no h a intromisso de uma na outra. A diviso feita entre a Camadas de Apresentao, Camada de Negcios, Camada de Dados, como mostra a figura 2.
Figura 2 Modelo Trs Camadas.
22
1.3.1. As camadas
1.3.1.1. Camada de apresentao
a interface com o usurio, a qual ele ir ver. sempre indicado criar essa camada, simples e estveis, para que seja leve e no de problemas para manutenes. Essa camada no consegue acessar os dados diretamente, s acessa a camada intermediria (Camada de Negcios), portanto, aumentando a segurana da aplicao.
1.3.1.2. Camada de Negcio
onde esto s regras do negcio, tambm conhecidas como Servidor de Aplicao, que faz o intermdio entre o cliente e o servidor, ou seja, executa processos para servir as requisies solicitadas pelos clientes. Uma colocao muito importante a se fazer, que essa camada a nica responsvel pelo acesso aos dados. onde a aplicao pode se tornar 3, 4 ou n camadas, bastando acrescentar o nmero de camadas necessrias. As manutenes nas regras do sistema apenas feita nesse local, facilitando na manuteno.
23
1.3.1.3. Camada de dados
Onde ficam armazenados os dados (Banco de Dados). No modelo em camadas, indica-se utilizar a metodologia de se usar o banco s como repositrio de dados, ou seja, no utilizar as funes tradicionais do banco (Stored Procedure, Triggers, etc.), para centralizar as regras de negcios, assim no havendo a disperso das regras, mas isso fica a critrio do desenvolvedor.
1.3.2. Vantagens da tecnologia Multi-Camadas
Mesmo o modelo multi-camadas tendo obstculos como, dificuldades de implementao, e at mesmo poucos profissionais especializados no mercado, prov muitas vantagens para os sistemas desenvolvidos no seu contexto, dando eficincia e agilidade nas aplicaes, como: - A facilidade na gerncia de segurana e usurios, na integrao de sistemas, aplicaes clientes menores e independncia de banco de dados. A questo da vantagem continuar sendo abordada no prximo capitulo, onde poder ser visto realmente na comparao entre arquiteturas, a superioridade do desenvolvimento em camadas.
24
2. COMPARATIVO - APLICAES TRS CAMADAS X DUAS CAMADAS
Este captulo tem como objetivo fazer um comparativo (Figura 3) entre o modelo multi-camadas e o modelo Cliente/Servidor, mostrando a necessidade de se desenvolver aplicaes em trs camadas, para evitar possveis problemas futuros como identificados no prxima captulo.
Figura 3 Arquitetura Cliente/Servidor e Trs Camadas
25
2.1. O modelo cliente servidor
2.1.1. Manuteno do aplicativo
As regras ficam divididas entre a aplicao (cliente) e banco de dados, dificultando a manuteno, para as atualizaes e entender as rotinas muito trabalhoso, ainda mais se for uma equipe que no tenha seguido um padro, ou at mesmo uma que no seja as responsveis pelo desenvolvimento do sistema.
2.1.2. Distribuio do aplicativo
Logo aps uma atualizao necessria a redistribuio do aplicativo, para que os clientes tenham acesso s novas rotinas, tornado muito trabalhoso se o sistema tiver muitos usurios. E quando a necessidade de mudar alguma regra necessrio que todos os usurios estejam desconectados do banco de dados.
26
2.1.3. Performance
O cliente / servidor comea a perder performance quando a rede amplia-se muito e a aplicao recebe muitas requisies dos clientes ao mesmo tempo, e acaba formando o gargalo de rede (Figura 3), e mesmo alterando a aplicao (deixando a mais leve) e com um servidor mais robusto, os problemas persistem, quando chegou no ponto, onde a aplicao cliente / servidor no supri mais a necessidade dos usurios, causando uma grande lentido no processamento das informaes e consecutivamente na rede.
2.2. O modelo Trs Camadas
2.2.1. Manuteno do aplicativo
Como as regras de negcios devem estar todas no servidor de aplicao, facilita qualquer possvel alterao, j que as regras esto no mesmo lugar, portanto as regras no ficam junto aos dados.
27
2.2.2. Distribuio do aplicativo
Aps uma alterao nas regras de negcios no h a necessidade de redistribuir as aplicaes nos clientes, pois elas j enxergam as atualizaes, ou seja, as novas regras que foram alteradas na lgica de aplicao, como demonstra a figura 4.
2.2.3. Performance
onde est a maior vantagem do modelo multi-camadas, que tem a parte de processamento totalmente separada no servidor de aplicao. Ainda podendo acrescentar novos servidores (que chamado de escalabilidade, que quando no aumento de usurios e sistemas a aplicao continua suportando, que ele pode ser escalonvel), que podero oferecer servios diferentes, como no exemplo exposto na figura 4, assim balanceando as requisies feitas pelos clientes, e consecutivamente mantendo a velocidade da rede.
28
Figura 4
Arquitetura N-Camadas
Tambm se pode utilizar dois servidores para a mesma lgica, tambm ganhando em desempenho e ainda na questo se por algum motivo um dos servidores no estar disponvel no momento, aciona-se automaticamente o outro, assim no perdendo a conexo.
29
3. APLICAES MULTI-CAMADAS COM DELPHI
Nesse capitulo sero abordados algumas das possveis maneiras de como desenvolver aplicaes Multi-Camadas no ambiente Delphi, onde vai ser visto os protocolos disponveis para se trabalhar com DataSnap, e o entendimento sobre essa tecnologia. Antes de iniciar os assuntos, necessrio entender alguns conceitos.
3.1. Objetos
De acordo com Rodrigues (2002, p.06), so entidades que manipulam e encapsulam informaes, possuem um estado e dados, sendo que posso modificar e obter informaes sobre os mesmos. Existem nos objetos: Atributos: que correspondem a um valor guardado no objeto. Classificao: o agrupamento de caractersticas semelhantes. Abstrao: abstrair caractersticas de um objeto. Encapsulamento: muito parecido com a abstrao, pois permite ocultar detalhes de implementao ao mundo exterior. Identificao: cada objeto tem uma identidade que o identifica e o distingue dos demais objetos.
30
3.1.1. Objetos distribudos
So como os objetos tradicionais, mas com a possibilidade de serem executados independente de sua localizao, onde disponibilizam os seus mtodos e propriedades, podendo ser acessados por outros objetos por um cdigo gerado pelo compilador, independente de onde foi gerado sendo uma mquina local ou mquinas espalhadas por uma rede.
3.2. Sistemas distribudos
Com esses dois conceitos citados anteriormente, pode-se chegar questo de Sistemas Distribudos, que so aplicaes que rodam espalhadas por uma rede, no entanto so integradas (conjunto), hoje em dia tem se falado muito, e implantado tambm, devido grande disponibilidade de meios de comunicao e hardware, e o barateamento dos mesmos. Espalhados entre mquinas clientes e servidoras, assim ajudando no processamento de informaes, consecutivamente ganhando desempenho. Obtendo vantagens como, de crescimento, podendo agregar mais recursos (computadores e meio de comunicao) ao sistema; a replicao de processos, obtendo uma tolerncia a falhas, entre outras.
31
3.3. Middleware
Conforme Kon (2003) o software que reside entre o sistema operacional e a aplicao a fim de facilitar (simplificar) o desenvolvimento de aplicaes, onde surge o Middleware de comunicao, cujo objetivo facilitar o desenvolvimento de aplicaes e sistemas distribudos. Como mostra a Figura 5.
Figura 5 Middleware de Comunicao
E tem como benefcios esconder do programador plataformas de hardware, sistemas operacionais, bibliotecas de comunicao, protocolos de comunicao, formatao de dados, linguagem de programao, modelos de programao. E tambm gerenciamento de nomes e referncia ativao automtica de servios, migrao de servios, gerenciamento de concorrncia, entre outros.
32
3.4. DataSnap
DataSnap um conjunto de ferramentas para o desenvolvimento de aplicaes distribudas (multicamadas) que trabalham integradas e, o nome dado ao antigo Midas2, que foi alterado pela Borland3. Como mostra a Figura 6 uma aplicao dividida em trs partes, mas, percebe-se com esse novo modelo de aplicao algo diferente, que existe uma camada no meio, onde ser feito o meio-de-campo da aplicao, chamado de servidor de aplicao.
Figura 6 Arquitetura DataSnap para aplicaes distribudas.
IAppServer uma interface de comunicao existente entre a aplicao cliente e o servidor de aplicao, em um arquitetura DataSnap (utilizando COM ou Sockets). Importante saber que essa interface est incorporada dentro dos componentes
(ClientDataSet/DataSetProvider), que no necessrio us-la diretamente. Nota-se que o cliente no tem acesso diretamente aos dados, que uma das funes do servidor de aplicao, assim, consecutivamente aumentando a segurana.
Multi-tier Distributed apllication Services, tem o seu foco no desenvolvimento de aplicaes em camadas, permitindo maior independncia entre as camadas. (WILDT, 2002) 3 Empresa desenvolvedora da Plataforma Delphi, entre outros.
33
3.5. Multitier (multicamadas)
Com toda evoluo em sistemas e tecnologia e solues para sistemas distribudos como Socktes, HTTP, CORBA, COM+, SOAP, e todas essas opes que os desenvolvedores tm sua disposio, se fez necessrio ferramentas que ajudassem e facilitassem o desenvolvimento e a implementao de aplicaes e o acesso a dados distribudos. Conforme a evoluo normal de aplicaes Mainframe para aplicaes Cliente/Servidor, agora aparece em alta o conceito de Multi-Camadas. Portanto, nota-se [...] como o Delphi e DataSnap podem facilitar o desenvolvimento de aplicaes distribudas, proporcionando maior produtividade na implementao. (WILDT, Daniel. Aplicaes Multi-Camadas: entenda o MIDAS e MultiCamadas. ClubeDelphi, Rio de Janeiro, ano 2, n.16, p.21-25, 2002) Esta tecnologia j est disponvel h algum tempo, e que vem sendo bastante comentada e destacada pelas suas vantagens em relao ao cliente/servidor, mas atualmente so poucos que a implementam, por motivos (mais encontrados) de custos ou problemas na distribuio da aplicao, o Delphi d suporte a essa plataforma desde a sua verso 3.
3.6. Os protocolos
So esses os protocolos que fazem a comunicao entre a camada de interface e o servidor de aplicao. So vrias possibilidades de protocolos para se trabalhar com
34
DataSnap, e cabe ao desenvolvedor escolher a melhor opo, pois uma boa escolha do protocolo pode ser a chave do sucesso de uma aplicao.
3.6.1. CORBA (Common Object Request Broker Architecture)
Conforme Wildt (2002, p.24), CORBA, o resultado de um projeto de algumas empresas, que fazem parte da OMG (Object Management Group). Que foi estabelecido um padro no desenvolvimento de aplicaes distribudas. Chegando-se a um padro rpido e fcil de fazer a integrao entre mdulos de aplicaes, integrando objetos de forma clara local ou remotamente, independente da linguagem que foi desenvolvido. As suas interfaces de programao so definidas para o Object Request Broker (ORB4), que quem recebe as requisies e responde aos clientes, a comunicao remota feita atravs do IIOP5 (Internet Inter-ORB Protocol). Utiliza-se CORBA enquanto possuir suporte da plataforma para o ORB, que no caso da Borland existe para Windows e UNIX. Para os objetos CORBA, so manipulados atravs de uma IDL (Linguagem de Definio de Interfaces). A tecnologia CORBA espelha-se em um modelo de orientao a objetos, que compe um ambiente aberto e distribudo, que integram componentes aumentando a reutilizao dos mesmos, medida que todos se comunicam atravs de uma linguagem (IDL), que ser gerada pelo Delphi.
o responsvel pela localizao do objeto ao qual se destina a requisio e, tambm, pelo envio de parmetros reconhecidos por este objeto. (RODRIGUES, 2002) 5 Protocolo de comunicao baseado no TCP/IP, que descarta o uso do HTTP. (RODRIGUES, 2002)
35
Algumas caractersticas: Os parmetros que passam entre o Cliente e o Servidor de Aplicao so feitos por referncia no por valor; Quem tem de encontrar um objeto o ORB; A funo de ativar este objeto do AO (Object Adapter, um dos responsveis pelas interaes do objeto ORB), tanto do BOA (Basic Object Adapter) como do POA (Portable Object Adapter). necessrio conhecer a interface do objeto para acess-lo, pela IDL o cliente conhece os mtodos e atributos de um objeto, isso para linguagens estticas, assim conseguindo acessa-los. Os objetos CORBA tm uma caracterstica nica (identificador), que por ele que se faz a localizao de um objeto, utilizado tambm para guardar o estado do objeto, podendo us-lo depois. J clientes utilizam fazerem a comunicao de um determinado objeto.
3.6.2. COM (Component Object Model)
Desenvolvido em 1993, com a funo de dar suporte para as diferentes partes de um sistema poderem se comunicar. Para o COM independente a linguagem em que se foi desenvolvido a aplicao, para ele o importante o acesso dos objetos atravs das Interfaces, pois a responsvel por chamar objeto independente da linguagem. (RODRIGUES, 2002, p.17-18)
36
3.6.3. DCOM (Distributed Componente Object Model)
De acordo com Wildt (2002, p.24-25), um modelo criado pela Microsoft, que uma extenso da tecnologia COM (tambm da Microsoft), dando suporte a chamada de objetos remotos utilizando ORPC (Object Remote Procedure Call), como CORBA o DCOM declara interfaces atravs da IDL. DCOM no segue a definio de orientao a objetos, so apenas funes relacionadas, que independem da linguagem de implementao. Seus clientes utilizam a MIDL (Microsoft Interface Definition Language) para se comunicarem entre si, essa linguagem gerada pelo Delphi. Algumas caractersticas: Utiliza-se DCOM enquanto a plataforma a suportar, que implemente seus servios. Que so: Windows, UNIX e Linux; A identificao feita pelo Class ID (mapeamento que se encontra no registro Windows) Para manipular um objeto do cliente, se usa um ponteiro para interface; Pode-se escolher se os parmetros (entre Cliente e Servidor de aplicao) sero passados por referncia ou valor; Quem deve encontrar um objeto do SCM (Service Control Manager); Quem ativa este objeto tambm do SCM; Como no CORBA, DCOM oferece a possibilidade de inovaes de mtodos de maneira dinmica e esttica. E j ao contrrio de CORBA, ele no mantm o estado do objeto, no deixando os clientes se conectarem novamente a um objeto por sua conexo anterior.
37
No DCOM no h um ID (identificador), existe um ponteiro para interface, e no para o objeto, assim desvalorizando o seu papel de objetos instanciados.
3.6.4. MTS (Microsoft Transaction Server)
Segundo Rodrigues (2002), o servidor de transaes da Microsoft. como se fosse objetos COM, que do suporte a transaes para banco de dados. O MTS compe o Windows 98 (com PWS6 instalado) e Windows NT. O MTS uma expanso do COM, necessrio para o desenvolvimento de sistemas multicamadas que tenham acesso a dados, ele compe vrios recursos existente no DCOM e tambm um gerenciador baseado no MMC (Microsoft Management Console).
3.6.5. COM+ (Componente Object Model Plus)
Conforme Rodrigues (2002), MTS a evoluo do DCOM, COM+ a evoluo do MTS, portanto, COM+ o protocolo que contem todas as caractersticas do DCOM e do MTS juntos e ainda traz outros recursos como:
Personal Web Server: um simulador, para suprir a ausncia de um servidor Web, podendo criar um ambiente Internet real na prpria mquina. (DELPHI & E-COMERCE, www.clubedelphi.net, acessado 26/06/2004).
38
Pooling: quanto um objeto pode manter instncias, atendendo vrios clientes. Assim que COM+ se torna escalonvel. No momento que o cliente fiz uma requisio, o COM+ procura por um objeto no Pool, e se for preciso instancia-o novamente. Escalabilidade: quando se pode aumentar as conexes concorrentes ao objeto, e o COM+ no perder a sua performance. Isso ocorre atravs o Pooling. Gerenciamento: onde se administra o COM+. Pode-se instalar, exporta e gerenciar objetos COM+. Transaes: Podem-se fazer transaes em objetos e em Banco de Dados. Com isso permite h objetos diferentes estejam em uma nica transao, mesmo que o objeto no acesse o Banco de Dados. Pode ser criada na instncia do objeto, e finalizada por usurios ou pelos mtodos SetComplete (como o Commit) e SetAbort (como o RollBack).
3.6.5.1. Eventos COM+
Relacionam-se com as Interfaces de objeto, este mesmo evento pode atender a vrias requisies de clientes e distribuir este evento para todas uma s vez. Uma opo em relao a eventos no COM+ a possibilidade de dar um refresh7 nos clientes (que utilizam a mesma Interface).
Atualizao das informaes.
39
3.6.6. Sockets
Comenta Wildt (2002, p.23), os Sockets faz a comunicao entre aplicaes atravs de TCP ou UDP, por exemplo. Na utilizao de Sockets o desenvolvedor deve implementar o protocolo de comunicao entre o Cliente e o Servidor de Aplicao. A utilizao de Sockets com DataSnap deixa a aplicao cliente leve , garantindo mais acesso a aplicao
conectando-se ao servidor, assim ajudando na comunicao com o Servidor de Aplicao. O funcionamento ocorre atravs de um instncia de uma classe TSocketConnection (responsvel pela comunicao entre Cliente e Servidor de Aplicao) para a conexo necessrio que o servidor de aplicao esteja executando o AcktService.exe (quem aceita as conexes, ativa o modulo de dados remoto usando COM). Como segurana o Servidor de Aplicao deve liberar o uso de conexo com Sockets.
Por definio, os mdulos de dados remotos (TRemoteDataModules) criados possuem estas funcionalidades liberadas. Aps a criao de um modulo de dados remoto, estes registram o uso de conexes com sockets dentro do mtodo UpdateRegistry (automaticamente criada), realizando a chamada do mtodo EnableSocketTransport. Um modulo de dados remoto pode aceitar conexes Sockets, HTTP, e DCOM.
O obstculo em relao ao Sockets quando o cliente termina o programa de uma forma no normal (ex: falta de energia eltrica), assim o servidor no consegue perceber isso, e com essa falha fica na memria do servidor o espao instanciado pelo Cliente, que poderia estar sendo usado por outro processo. No como no DCOM que o servidor sempre envia mensagens para os Clientes para saber se esta ativo. Isso ganha desempenho na questo de
40
enviar e receber mensagens mas ao mesmo tempo, uma falha no armazenamento de dados do servidor.
3.6.7. HTTP (Hyper Text Transfer Protocol)
Conforme Wildt (2002, p.23-24), o HTTP trabalha semelhante ao uso de RPC (Remote Procedure Call), utilizando TCP/IP. Dessa forma a aplicao no mantm o estado. Funciona da seguinte maneira: (1) estabelecida uma conexo do cliente com o servidor, (2) feita uma requisio, (3) processada essa requisio (pelo servidor), assim retornado para o cliente e logo aps finalizando a comunicao. Em questo de segurana possvel se comunicar com um servidor, mesmo protegido por um firewall, assim as aplicaes clientes so distribudas com segurana. Podese incluir um Servidor Web para ser responsvel para validao de usurios. Como Sockets o servidor deve liberar a criao de conexes com HTTP, e tambm deixa a parte cliente mais leve. Requisitos para utilizao de HTTP com DataSnap: Deve-se ter instalado no cliente uma DLL chamada Wininet.dll, que encontrada no diretrio System do Windows, caso possua, instalado, o Internet Explorer 3 ou superior; A DLL HTTPsrvr.dll deve estar instalada no servidor Web com o qual o aplicativo cliente faz a conexo. Esta DLL a responsvel por disparar o servidor de aplicao e conduzir as requisies ao servidor de aplicao.
41
Com o uso de HTTP tem a possibilidade que o sistema operacional Windows NT Enterprise, que o mesmo fornece a criao de cluster de servidores8.
3.6.8. SOAP (Simple Object Access Protocol)
De acordo com Rodrigues (2002), SOAP um modo de usar a infra-estrutura da Internet existente para permitir que as aplicaes se comuniquem diretamente entre si sem serem bloqueadas por Firewalls . baseado em XML. Quando chama-se os mtodos atravs de RPC, esses tambm so codificados em XML. Atravs de HTTP feita a troca de mensagens assim deixando esse tipo de protocolo leve tambm., tambm descarta problemas com firewall no servidor. SOAP tende a facilitar o desenvolvimento das aplicaes distribudas, e tambm as suas comunicaes j que o mesmo feito em XML e, assim eliminado a necessidade da atualizao do Windows 95.
Recurso que possibilita um balanceamento de carga real e tolerncia a falhas do servidor de aplicao implementado pelo uso da tecnologia DataSnap. (WILDT, 2002)
42
3.7. Componentes do Delphi para desenvolvimento em camadas
Mas como est se falando de Delphi, importante se familiarizar com os componentes do mesmo. Wildt (2002, p.22), sobre os componentes do servidor de aplicao refere-se:
Servidor de aplicao: camada responsvel por receber as requisies de clientes, realizarem o acesso a dados e retornar ao cliente o resultado da requisio. .
Componentes existentes no servidor: Mdulos de dados remotos criam Interfaces para serem exportadas para as aplicaes clientes. Que devem ser de 3 tipos:
1.
TRemoteDataModule: implementa o mdulo de dados para aplicaes que
utilizam os componentes de conexo DCOM, HTTP e Sockets; 2. TCorbaDataModule: implementa o mdulo de dados para aplicaes
CORBA utilizando componente de conexo CORBA; 3. TMTSDataModule: usado no projeto de bibliotecas ActiveX;
DataSetProvider: faz a ponte de entrada pois prov os dados a um DataSet (tabela, consulta ou StoredProcedure) onde esta conectado. Codifica dados em pacotes, que sero encaminhados para as aplicaes clientes e tambm aplica atualizaes nas bases de dados, conforme retorno das aplicaes clientes;
43
Wildt (2002, p.22), sobre os componentes da camada de interface (cliente) refere-se: Cliente: a camada de apresentao com o usurio.
Componentes existentes no cliente: Componentes de conexo: quem faz a comunicao com o servidor de aplicao, que depende da tecnologia utilizada, como: (TCORBAConnection TDCOMConnection DCOM, TWebConnection HTTP, TSocketConnection CORBA, Sockets
TCP/IP, TSOAPConnection - SOAP). TClientDataSet: utiliza os dados providos do DataSetProvider e negocia no momento de atualizar as informaes. Faz a abstrao no acesso a dados, quem mostra os dados que vem do Servidor de Aplicao. TSimpleObjectBroker: componente guarda uma lista de servidores disponveis, e encaminha para os componentes de comunicao.
3.8. Funcionamento de uma aplicao DataSnap
O modelo de uma aplicao DataSnap composto de vrios componentes do Delphi. A Figura 7 retrata uma aplicao em camadas (de forma geral), para o possvel entendimento bsico de cada camada utilizando o Delphi. Importante dizer que qualquer componente de conexo como: TCORBAConnection CORBA, TDCOMConnection DCOM,
TWebConnection
HTTP, TSocketConnection
Sockets TCP/IP, TSOAPConnection
SOAP, tem que estar presente na parte cliente para fazer comunicao com o servidor de aplicao, portanto cabe ao desenvolvedor escolher o melhor para o seu projeto, tambm
44
podendo usar na parte cliente um componente SimpleObjectBroker para guardar uma lista de servidores que estaro disponveis no servidor de aplicao, caso algum encontre algum problema ele aciona outro.
B a se D a d o s
Cursor Bidirecional Cache Local Cursor Unidirecional

Clie n t e
DataPacket ApplyUpdates
Figura 7 Modelo de aplicao DataSnap
A aplicao esta dividida em trs partes: cliente, servidor de aplicao, banco de dados, o fluxo de informaes ocorre da seguinte forma: O componente SQLConnection do servidor de aplicao faz a conexo com o banco de dados, onde sero feitas as trocas de informaes. Logo abaixo do componente SQLConnection, vem os que iro compor as regras de negcio (SQLDataSet, SQLQuery, SQLTable, SQLStoredProc), que por ter um cursor unidirecional (s faz consultas, no inclui, no altera, no exclui) que so os quais iro fazer as requisies SQL, assim passando para o DataSetProvider, que ira prover os dados para o ClientDataSet (aplicao cliente), que est ligado a um DataSource, que mostra as informaes do banco de dados na aplicao cliente.
Se r vid o r d e Ap lica o
45
O ClientDataSet, que possui cursor bidirecional (consulta, inclui, altera, exclui), coloca as informaes passadas pelo DataSetProvider na memria e trabalha normalmente com elas, aps as devidas manipulaes, o ClientDataSet utiliza o mtodo ApplyUpdates, que aplica as alteraes voltando para o servidor de aplicao, e ele consecutivamente envia as
informaes para o banco de dados.
46
4. A TECNOLOGIA JAVASERVER PAGES (JSP)
A tecnologia JavaServer Pages foi desenvolvida com o intuito de facilitar o processo de desenvolvimento de sites Web dinmicos, permitindo desse modo incorporar elementos dinmicos nas mesmas de forma rpida pelos designers e programadores Web.
4.1. O JavaServer Pages
Em aplicaes Web, independentemente de sua complexidade, seu desenvolvimento se d em funo de 3 reas lgicas, da mesma forma como vnhamos descrevendo no decorrer do trabalho, ou seja, a camada de apresentao ou cliente, a camada de controle que controla o fluxo de apresentao, a camada lgica de apresentao, que gerencia os dados de aplicao, gerencia clculos e se comunica com os recursos de back-end, tambm conhecida como o modelo (banco de dados) (FIELDS, KOLB, 2000), compreendendo assim 3 reas lgicas, que junto com o banco de dados se torna uma aplicao em 4 camadas.
Freqentemente, vantajoso tratar cada camada como uma parte independente de sua aplicao. Isolar as partes lgicas da aplicao ajuda a garantir que voc tenha coberto todas as bases do design, se concentre na criao de uma arquitetura robusta e crie os fundamentos para a implementao. (FIELDS, KOLB, 2000).
47
Camada de Apresentao
Camada de Controle
Lgica de Aplicao
Banco de Dados
Figura 8 - Camadas de Aplicao da Web
A figura 8 ilustra os relacionamentos entre as camadas, a camada de banco de dados que armazenas os mesmos se comunica com a camada de lgica de aplicao, esta por sua vez realiza as diversas funcionalidades do sistema, enviando os resultados e recebendo solicitaes da camada de controle que por sua vez controla o fluxo de apresentao da camada de apresentao.
4.2. As camadas
4.2.1. A camada de apresentao
Interface com o usurio da aplicao, utilizada para obter input do usurio final alm de exibir os resultados da aplicao. Seu objetivo no est direcionado no sentido de controlar a maneira da qual a informao foi obtida, ou ainda, de onde ela foi obtida, concentrando-se apenas na exibio da prpria informao, delegando as outras camadas a responsabilidade de controlar qualquer outra atividade.
48
4.2.2. A camada de lgica de aplicao
a principal parte de uma aplicao, responsvel direto pela realizao das vrias funcionalidades que qualquer aplicao possa desejar realizar, realizando desde a consulta ao banco de dados at o clculo de impostos sobre vendas. Compreende a esta camada modelar os dados e seu comportamento por detrs do processo de negcios, ou seja: Diferentemente da camada de apresentao, esta camada se preocupa apenas com o armazenamento, manipulao e gerao de dados, no sua exibio (FIELDS, KOLB, 2000).
4.2.3. A camada de controle
Aqui so determinados os fluxos de apresentao das informaes da aplicao, funcionando como uma ponte entre a camada de apresentao e a camada de lgica de aplicao, fornecendo um modelo para visualizao e regulando a comunicao entre as duas.
49
4.2.4. A camada de banco de dados
Consiste numa mquina que contenha um Sistema Gerenciador de Banco de Dados (SGBD) onde so armazenados os dados dos sistemas.
4.3. Conexo com a Base de Dados
A conexo com a base de dados de uma aplicao Java e JSP um item crtico do seu desenvolvimento, isso pelo fato de que tais aplicaes no operam diretamente com os drivers padres da plataforma Windows, ou seja, no fazem uso de drivers comuns para comunicao com bases de dados para Windows como OLE, ADO e ODBC. Sendo assim o cdigo Java independente de banco de dados, e isso se deve ao API Java Database Connectivity, ou simplesmente JDBC, que um driver compatvel com aplicaes Java, sem ele o mximo que se pode obter com os drivers no-JDBC uma ponte de ligao entre JDBC e ODBC.
50
4.4. Arquiteturas JSP
4.4.1. Design Centrado em Pginas
Nesta abordagem iremos apenas realizar uma breve descrio de seu funcionamento, pois ela no compreende o foco principal do trabalho que o particionamento de uma aplicao em vrias camadas lgicas. Sendo assim j podemos ter a idia de que ela composta apenas de uma camada lgica, que so um conjunto de pginas JSP inter-relacionadas que realizam todo o processo de tratamento das vrias partes de uma aplicao, ou seja, elas compreendem as camadas de apresentao, controle e lgica de aplicao em uma s camada. Essas pginas JSP realizam todo tipo de tarefa que forem necessrias, por exemplo, comunicar-se com fontes de dados de back-end (banco de dados), realizar operaes e gerar elementos de contedo dinmico. Dessa forma as decises sobre controle e lgica de aplicao sobre que pgina visitar a seguir sero hard-coded9 na prpria pgina ou expressas atravs de Beans, scriptlets e expresses no tempo de execuo (FIELDS, KOLB, 2000).
Cdigo permanente, fixo ou fisicamente definido; cdigo que no pode ser alterado pela operao normal de um sistema. (HARD, http://www.netpedia.com.br, 16/10/2004)
51
Menu.jsp
catalog.jsp
checkout.jsp
Banco de Dados
Figura 9 - Fluxo de Programa centrado em pginas
Neste modelo cada pgina tem um papel bem especfico dentro da aplicao, como demonstra a figura 9, onde uma pgina exibe o menu, outra fornece um formulrio para selecionar itens do catlogo e outra faria o encerramento do processo de compra. Esta abordagem considerada simples no sentido arquitetnico do problema, isso pelo fato de que ela apresenta poucas partes mveis e pouca abstrao, porm devido a essa facilidade alguns problemas so encontrados nela. Tais problemas se concentram na sua capacidade de manuteno: [...] pelo fato das pginas JSP que compem a aplicao conterem tanto cdigo de controle/lgica, quanto de apresentao, pode ser difcil realizar a manuteno da aplicao. (FIELDS, KOLB, 2000) E tambm questes no sentido do controle de fluxo das aplicaes Web, pois como se sabe este tipo de aplicao est sujeita a receber solicitaes fora de seqncia, dessa forma exceto em aplicaes mais simples tal controle se torna praticamente impossvel, para isso descreveremos a seguir sobre uma abordagem que ajuda a centralizar o controle de tal fluxo reduzindo tal complexidade encontrada em pginas individuais.
52
4.4.2. Design centrado em Servlets
[...] a atual tendncia entre os desenvolvedores buscar uma modularizao no desenvolvimento das aplicaes. Criar uma aplicao segundo essa tendncia implica separar as informaes quanto lgica da aplicao e sua apresentao: a primeira parte ficando por conta dos programadores e a segunda por conta dos designers. (BOMFIM JR., 2002)
Esta abordagem tem como objetivo principal sanar as dificuldades encontradas no gerenciamento do fluxo das aplicaes Web encontradas na abordagem anterior, nas qual esse controle devia estar intrnseco em cada pgina JSP da aplicao. Aqui iremos centralizar tais cdigos de controle em um servlet ou em um grupo destes, sendo assim todas as solicitaes sero indiretamente conduzidas as pginas JSP de front-end atravs dele, que ter ento a incumbncia de realizar as aes que forem necessrias para a aplicao. Segundo Bonfim Jr. (2002), os servlets so componentes, pequenos programas na linguagem Java, que geram as pginas visualizadas pelo navegador. Eles funcionam de modo semelhante aos scripts CGI10. Sua grande vantagem est na velocidade aps a primeira execuo. Os servlets servem a ambos os propsitos. Eles podem conter a lgica e a apresentao do contedo de uma apresentao ou podem funcionar apenas como componentes da aplicao, dando suporte a outros servlets ou a pginas JSP. Com essa definio usada por Bonfim Jr. (2002) em seu livro ficam mais claro quais as tarefas que um servlet pode realizar, sendo assim um servlet pode executar aes em nome de uma pgina JSP, entregar registros do banco de dados para uma JSP exibir, ou ainda
10
CGI (Commom Gateway Interface, ou seja, Interface Comum de Gateway) uma interface definida de maneira a possibilitar a execuo de programas sob um servidor de informaes.Os programas CGI esto na forma de scripts escritos em alguma linguagem como C, Perl, Shell do Unix e VB Script. Os scripts so interpretados pelo servidor que executa as instrues. (CGI, http://www.rafah.hpg.ig.com.br, 01/10/2004)
53
controlar o fluxo entre as pginas JSP da aplicao, da mesma forma como demostrado na figura 10, na qual todos os processos so centralizados no servlet que se incumbe de fazer o controle da aplicao. Sendo assim: [...]esta abordagem elimina a complexidade do cdigo JSP de front-end, os reduzindo para pura exibio de dados e atividades de coleta de input. (FIELDS, KOLB, 2000).
Cliente
Servlet Banco de Dados JSP
Figura 10 - Fluxo de Programa em uma aplicao centrada em servlets
4.4.3. Servlets para controle da aplicao
Nesta arquitetura os servlets tem a incumbncia de ser o Proxy de transaes entre pginas JSP individuais quem compem o front-end da aplicao, ou seja, a partir dela que uma solicitao feita em uma JSP tem continuidade na aplicao. O objetivo desta arquitetura centralizar nele determinadas tarefas, garantindo que a aplicao mantenha o estado adequado e o fluxo esperado entre componentes (FIELDS, KOLB, 2000), ou seja, o servlet gerencia o fluxo atravs da aplicao, no caso de outras abordagens isso seria feito pelos formulrios e links em cada pgina JSP.
54
Dessa forma os cdigo de apresentao de JSP so isolados, reduzindo-os a sua essncia, ou seja, apenas servindo como mecanismo de apresentao, e o servlet por sua vez desempenha as funes lgicas da aplicao, determinando a ao apropriada a ser tomada e em seguida atravs de um RequestDispatcher encaminhar os dados para uma pgina JSP.
Menu.jsp
catalog.jsp
checkout.jsp
servlet
Banco de Dados Figura 11 - Uma aplicao de catlogo centrada em servlets
A figura 11 exemplifica bem esta arquitetura, j que a requisio do catlogo de endereos feita por uma pgina JSP ao servlet que por sua vez disponibiliza a outra JSP tal catlogo, o qual retorna ao servlet outras informaes que sero checadas por uma ltima pgina JSP. Introduzida pela Servlet API 2.1 a interface RequestDispatcher quem permite que o processamento de uma solicitao seja encaminhado para uma JSP ou para um outro Servlet.
Um objeto RequestDispatcher criado ao passar o URL da pgina JSP, ou do servlet de destino para o mtodo getRequestDispatcher do objeto de solicitao de chegada, ou ServletContext do servlet. [...] o RequestDispatcher que nos permite usar servlets no papel controlador da aplicao. Se o cdigo de servlet precisar realizar qualquer tipo de output, ele simplesmente faz seu trabalho, depois encaminha a solicitao para manuseio pela pgina JSP. (FIELDS, KOLB, 2000)
55
4.5. Enterprise JavaBeans
As arquiteturas descritas anteriormente apresentam as camadas que nos permite defini-las como sendo uma arquitetura em mltiplas camadas, porm como afirmam Fields e Kolb (2000) facilmente no suporta diretamente arquiteturas distribudas e gerenciamento de transaes complicadas , sendo assim uma outra faz-se necessria denominando-se Enterprise JavaBeans, que tem por objetivo sanar tais dificuldades encontradas na arquitetura anterior, livrando o desenvolvedor de ter que realizar tarefas que podem ser at mais complexas que as prprias regras de negcio. Portanto os EJBs so componentes reutilizveis e transacionais onde so implementadas as regras de negcio das aplicaes em mltiplas camadas em Java.
4.5.1. O que so JavaBeans?
So componentes de uma aplicao que no foram originalmente desenvolvidos para trabalharem com pginas JSP, e esto mais ligados ao desenvolvimento de aplicaes visuais, como caixas de textos, botes de radio, e um leque de outros componentes que fazem parte do desenvolvimento de uma interface visual. Com isso a funo dos JavaBeans nas pginas JSP encapsular procedimentos, fazendo dessa forma que haja uma separao entre a lgica do negcio da sua apresentao, da mesma maneira como funcionam os servlets, porm recebem um tratamento diferenciado
56
deles, j que atravs de tags predefinidas o programador visual pode acessar seus recursos disponveis sem ter que programar vrias vezes uma nica linha de cdigo Java. No contexto JSP, um JavaBean simplesmente uma classe Java que pode ser acessada por tags especficas de modo a receber dados de uma pgina ou envi-los a uma pgina (BOMFIM JR., 2002).
4.5.2. Diferena entre JavaBeans e Enterprise JavaBeans
Do ponto de vista tcnico ambos no se relacionam, ou seja, no tem muito em comum, porm, em ambos, o conceito de que eles permitem que programadores faam uso de componentes reutilizveis em suas aplicaes comum, alm de serem componentes de software baseados em Java. Apesar dessas semelhanas os EJBs tem outro propsito com relao ao propsito da existncia dos JavaBeans que, como j mencionado anteriormente, visa encapsular lgica de negcios em componentes reutilizveis do servidor. Nos EJBs uma aplicao implementada como um conjunto de componentes que fazem o controle das regras de negcio, sendo que suas configuraes so especficas de sua aplicao, e sua interface preparada para se comunicar com o mesmo e tratarem dos resultados.
57
4.5.3. Containers EJB
Os containers representam um ambiente operacional, fornecendo os recursos e infra-estrutura necessria publicao e execuo de componentes, assim encapsulam a complexidade do ambiente corporativo e fornece independncia de plataforma aos componentes (SANTOS JR., 2002).
Ou seja, a partir dos containers que os componentes de uma aplicao podem ser desenvolvidos j que eles fazem a ligao desses componentes com os servios de baixo nvel disponveis na plataforma Java. Dessa forma tais componentes, para que possam ser utilizados pela aplicao, devem estar publicados em um container, e para que tal publicao possa ser realizada, uma operao de configurao e preparao para a execuo do mesmo se faz necessria, essa operao tem o nome de deploy. No deploy, o componente poder ser configurado de duas maneiras, a primeira compreende configur-lo em arquivos XML e a outra gerando classes de servios, podendo tanto ser configurado em apenas uma das formas ou nas duas se necessrio. Nesses arquivos e classes de servios estaro as informaes de segurana, controle transacional, persistncia de dados, escalabilidade, associao com outros componentes, servios de nomes, entre outros. Com esses conceitos, fica clara a funcionalidade de um container EJB, que nada mais do que gerenciar a execuo dos componentes EJB.
58
4.5.4. A arquitetura Enterprise JavaBeans
Como mencionado no item anterior o container EJB o responsvel pelo gerenciamento dos componentes EJBs, portanto ele quem gera e fornece camada cliente, uma srie de servios responsveis pela utilizao do ambiente distribudo. Com isso os containers faro uso dos componentes EJBs para gerarem tais classes de servios, sendo que elas que iro fornecer a transparncia do ambiente distribudo. Uma camada cliente faz constantes requisies de execuo de mtodos, nesse caso tais mtodos estaro localizados nos componentes EJBs, para que isso possa ocorrer ela dever possuir a referncia para a interface remota do mesmo, para que a interface faa a solicitao da execuo do mtodo e receber o resultado, para isso uma classe de servios chamada STUB gerada automaticamente pelo EJB e far a comunicao entre a camada cliente e o container. Essa solicitao feita pela camada cliente tem seu incio no momento em que ela: obtm um objeto que implementa a interface remota, o qual foi gerado automaticamente e fornecido pelo container (SANTOS JR., 2002) a partir desse objeto que o mtodo solicitado pela aplicao cliente invocado. Esse objeto, por sua vez, via RMI, transmite ao container EJB a chamada feita ao mtodo que far a solicitao ao EJB para que o mtodo seja executado e devolvido ao container o resultado desse mtodo, nesta parte outra classe de servios de gerao automtica ser responsvel pela comunicao no lado servidor e tem o nome de SKELETON, e este far o percurso no sentido contrrio ao que foi percorrido na solicitao do mtodo, at que tal resultado chegue ao ponto onde ele foi requisitado que a aplicao cliente.
59
4.5.4.1. Java RMI (Java Remote Method Invocation)
O Java RMI
um modelo de objetos distribudos para a plataforma Java
(PAULOVICH, 2000), que visa principalmente permitir que um mtodo pertencente a uma interface remota possa ser invocado, lembrando que um objeto remoto um objeto que permite que uma solicitao possa ser feita por uma outra mquina diferente. O RMI muito parecido com o CORBA, j que os clientes interagem com os objetos remotos via interfaces remotas e no diretamente com as classes que as implementam, podendo ser considerado como sendo uma evoluo natural do modelo RPC, j descrito anteriormente, sendo que na sua essncia o RMI uma extenso da linguagem Java. Considerando o fato de que o RMI resolve dinamicamente invocaes de mtodo entre diferentes mquinas, seu ambiente totalmente distribudo e orientado a objetos, outra considerao importante que por ele ser nativo da linguagem Java, seu desenvolvimento se d dentro de um nico modelo de objetos, o prprio modelo Java, no havendo a necessidade de se trabalhar com mltiplos modelos, dessa forma, reduzindo bastante sua complexidade de programao. Conforme descreve Paulovich (2000), o modelo RMI oferece alguns dos elementos crticos de um sistema de objetos distribudos Java pelo fato do RMI ser nativo da linguagem Java. Possui facilidades de comunicao entre objetos, anlogas ao protocolo IIOP de CORBA, e seu sistema de serializao de objetos fornece uma maneira prtica de se transferir ou requisitar uma instncia de um processo remoto para outro.
60
4.5.5. Os elementos dos componentes Enterprise JavaBeans
Componentes EJB possuem trs elementos que servem de base para a gerao de classes de servios nos conceitos de objetos distribudos, da o fato destes serem definidos como interfaces, no permitindo a implementao de mtodos, e classes abstratas que por sua vez no podem ser instanciadas. Eles formam a base para a operao de configurao do container, j denominada anteriormente como deploy, e so eles: Interface Home, Interface Remota e Classe Abstrata. Todos os mtodos que pertencerem a estas interfaces que estiverem disponveis para o ambiente remoto devero indicar a possibilidade do lanamento da exceo java.rmi.RemoteException, que ter a incumbncia de transportar a exceo ocorrida na execuo do mtodo onde ele foi invocado, ou seja, para o ambiente remoto. E para que os componentes EJB sejam configurados atravs da operao de deploy faro uso de arquivos chamados de XML denominados deployment descriptors, que por sua vez possuem as configuraes dos componentes EJB. Abaixo sero melhor explicados os conceitos de Interface Home, Remota, Classe Abstrata e Deployment Descriptors.
Interface home
A interface Home ir fornecer mtodos para manuteno do ciclo de vida dos componentes EJB. Os seus mtodos iro permitir criar, remover e localizar Beans. Essa interface deve estender a interface javax.ejb.ejbHome. atravs da interface Home que a camada cliente ir obter acesso interface remota do Bean. Os mtodos de localizao da interface Home retornam
61
interface Remota do Bean, ou uma coleo (java.util.Collection), justamente para que a camada cliente possa utilizar os mtodos ofertados pelo Bean camada cliente (SANTOS JR., 2002).
Interface remota
A Interface Remota representa a viso do Bean ao ambiente remoto. A interface Remota deve estender a interface javax.ejb.EJBObject e deve possuir a assinatura de todos os mtodos a serem ofertados, camada cliente. Todos os seus mtodos devem indicar na assinatura a possibilidade do lanamento da exceo java.rmi.RemoteException. A interface Remota ir servir como base para gerao da classe STUB, a qual gerada automaticamente atravs da operao de deployment. Esta classe gerada faz a comunicao entre a camada cliente e o container EJB (SANTOS JR., 2002).
Classe abstrata
A Classe Abstrata ir conter a implementao de todos os mtodos a serem fornecidos pelo Bean, alguns dos quais sero mtodos de servios e no sero ofertados camada cliente, ou seja, suas assinaturas no estaro presentes na interface Remota. A Classe Abstrata deve implementar a interface javax.ejb.EntityBean, javax.ejb.SessionBean ou javax.ejb.MessageDrivenBean, a depender do tipo de Bean. O container ir gerar classes automaticamente para estender a Classe Abstrata do bean, adicionando os mtodos necessrios utilizao dos recursos oferecidos pelo container . (SANTOS JR., 2002).
Deployment descriptors
O Deployment Descriptors so arquivos XML que permitem a configurao dos componentes EJB em tempo de publicao. Possibilitando realizar ajustes sem necessitar alterar o cdigo fonte dos componentes, fornecendo flexibilidade na utilizao dos componentes, uma vez que o mesmo
62
componente EJB pode ser configurado de maneira diferente a depender da necessidade. Os deployment descriptors configuram as caractersticas dos componentes EJB, tais como: segurana, controle transacional, persistncia de dados, escalabilidade, associao com outros componentes e servio de nomes (SANTOS JR., 2002).
4.5.6. Tipo de componentes
A tecnologia Enterprise JavaBeans apresenta dois tipos de componentes que do auxlio no seu desenvolvimento.
Entyte bean
O entity bean o componente que representa a fonte de dados na camada cliente ou intermediria, seu objetivo principal trazer a camada onde se encontram as regras de negcio uma forma de acesso aos dados atravs de objetos que os representam, dessa forma possvel aumentar a capacidade de processamento, pois pode-se criar novos pontos de processamento distribuindo assim a carga de processamento que era para ser toda realizada na camada de dados. Sendo assim, como na maioria dos casos de sistemas comerciais utilizam-se de banco de dados relacionais, para cada tabela existente no banco de dados um entity bean dever ser criado para que este gerencie as operaes sobre a tabela.
63
Session bean
Os session beans representam numa aplicao EJB as regras de negcio, ou seja, utilizam-se de vrios entity beans para realizarem as diversas operaes do ambiente corporativo que esto alocadas nas mesmas. Numa aplicao EJB os session beans representam um cliente na camada intermediria atendendo as solicitaes do mesmo, alm de oferecer a esses clientes uma variedade de mtodos. Tais mtodos possuem um controle transacional que desfazem todas as operaes caso uma exceo do tipo javax.ejb.EJBException seja disparada. Os session beans podem ser de dois tipos que so definidos conforme sua relao com o cliente, ou seja, podem ser session beans com estado (Statefull) ou sem estado (Stateless), no caso dos session beans com estado, estes so alocados pelo cliente mantendo uma sesso com ele, enquanto que os sem estado criam esse vnculo somente no momento da execuo de um dos seus mtodos.
4.5.7. Servidores de aplicao
Os servidores de aplicao em particular so excelentes ambientes para atuar como host de containers EJB, porque eles automatizam os recursos mais complexos dos processamento de mltiplas camadas. [...] Eles tambm fornecem servios de infra-estrutura como segurana, servios de diretrio e nomeao. Eles fornecem aplicaes baseadas em Beans com o benefcio de redimencionabilidade a maioria dos ambientes de servidor de aplicao permitir que voc redimensione sua aplicao atravs da adio de novos clusters de mquinas. (FIELDS, KOLB, 2000)
64
Cliente
Servlet
EJB
JSP Figura -12 Um EJB lidando com a lgica da aplicao
Banco de Dados
Na figura 12 possvel compreender melhor com funciona um Enterprise JavaBeans, j que este se comunica com um servlet enviando e recebendo resultados e requisies, alm de fazer a comunicao com o banco de dados. A partir dessa figura o sentido de se ter um servidor de aplicao fica mais claro, pois ele que vai armazenar os containers EJB, portanto e no servidor de aplicao que as diversas funcionalidades da aplicao sero realizadas.
65
5. PLATAFORMA .NET
A Plataforma .Net surgiu do resultado de dois projetos, o primeiro s foi possvel com o lanamento do Internet Information Server11 (verso 4.0), que possibilitou criao de novas tecnologias de desenvolvimento Web, com ASP12 e COM, este projeto teve melhorias e o batizaram de NGWS (Next Generation Windows Services), em seguida surgiu um segundo projeto, que tinha como objetivo o suporte uniforme de todas as ferramentas de desenvolvimento da Microsoft.
Net (Dot-Net) uma plataforma de software que conecta informaes, sistemas, pessoas e dispositivos. A plataforma .Net conecta uma grande variedade de tecnologias de uso pessoal e de negcios, de telefones celulares a servidores corporativos, permitindo o acesso a Informaes importantes, onde e sempre que forem necessrias. Desenvolvido sobre os padres de Web Services XML, .Net possibilita que sistemas e aplicativos, novos ou j existentes, conectem seus dados e transaes independente do sistema operacional, tipo de computador ou de dispositivo mvel que sejam utilizados, ou que linguagem de programao tenha sido utilizada na sua criao.(http://www.comquest.com.br/Net.ASP, 21/08/2004)
5.1. XML
XML uma linguagem universal utilizada no mundo para comunicao pela Internet, sua funo de organizar, descrever e transmitir todas as informaes que transitam na Web. Esta ferramenta utilizada em todas as camadas, tanto lgicas como fsicas de uma aplicao
11
Internet InFormation Server: O principal objetivo desta ferramenta publicar os documentos ou aplicativos na Web, dando suporte aos mesmos.
66
desenvolvida para Internet. Na plataforma .Net existe uma ferramenta que permite manipular e criar informaes no Formato XML: System.XML Dentro desta ferramenta existem classes (conjunto de atributos e mtodos), que auxiliam e facilitam a manipulao de dados em XML.
5.2. Estrutura .NET
A arquitetura .Net construda por duas camadas ou partes: A Common Language Runtime (CLR), que ser responsvel pela execuo de cdigos, assim como o gerenciamento de memria e Threads13 . E a segunda parte denominada de .Net Framework Classes Library, com funo de oferecer suporte, necessrio para o desenvolvimento de aplicaes desde Console14 e GUI15 at aplicaes Web, utilizando tecnologias como ASP.NET e Web
Services, assuntos abordados nos prximos captulos. Com esta estrutura tornou-se possvel a criao de cdigos com uma maior aceitao em plataformas diferentes. A figura 13 demonstra como esta estrutura se consolida.
12
ASP: Active Server Pages - Pginas de Servidor Ativas, so um ambiente para programao por scripts no servidor (ASP, http://www.fundanet.br, acessado em 20/09/2004) 13 Threads: permitem que vrias atividades aconteam simultaneamente em um mesmo programa. (THREADS, http://www.linux.ime.usp.br, acessado em 16/10/2004) 14 Uma unidade de controle, com um terminal, atravs da qual o usurio se comunica com um computador. (CONSOLE, http://www.netpedia.com.br, acessado em 16/10/2004) 15 GUI: Graphic User Interface, uma interface grfica, muito utilizada no desenvolvimento de aplicaes para o clinet.(GUI, http://www.freenetpages.co.uk/, acessado em 16/10/2004)
67
Figura 13 Estrutura .Net com a linguagem ASP.NET (Fonte:APRESENTANDO A ARQUITETURA .NET, http://www.altabooks.com.br/pdf/Aplica%C3%A7oes%20WEB_01.PDF, acessado em 16/10/2004)
5.2.1. CLR
Common Language Runtime
O CLR possui duas funes primarias, a primeira, de gerenciamento do cdigo executado e a segunda, de promover a integrao de linguagens diferentes, sua funo secundria de disponibilizar recursos para facilitar o desenvolvimento destas linguagens. Uma das vantagens de se trabalhar com a tecnologia .NET, est ligada a esta camada, o CLR possui uma definio de um sistema comum de tipos, fazendo com que as linguagens que geram cdigos para o CLR utilizem a mesma definio de tipos de dados, sendo possvel assim a execuo de cdigos entre linguagens.
68
5.2.2. .Net FrameWork Class Library
Nesta camada possvel acessar todas as funcionalidades do sistema onde as aplicaes e componentes so construdos. Muitos cdigos so derivados de alguns tipos de dados que esta camada disponibiliza, tornando possvel diversificar a estrutura dos cdigos de linguagens diferentes sem abalar a compatibilidade entre essas linguagens e a plataforma .Net. Sobre esta camada possvel desenvolver: Sevios Windows 2000 e NT Aplicaes de Console Aplicaes ASP.Net (Web Forms, Web Services)
5.3. System namespace
Toda programao necessita de tipos de dados para se concretizar, o system namespace o principal namespace da arquitetura .Net responsvel pela definio dos tipos de dados. As definies contidas nesta classe devero servir para outras linguagens se basearem na construo de cdigos. Na arquitetura .Net existe outra ferramenta com a finalidade de assegurar a interoperabilidade entre diversas linguagens, chama-se CLS Common Language
Specification. Esta ferramenta um subconjunto do sistema de tipos comuns, para que seja possvel manter a interoperabilidade entre as linguagens, todos os objetos criados nestas
69
linguagens de programao devem expor somente tipos de dados que sejam suportados por estas linguagens. Porm por motivos de design, uma linguagem pode implementar seus prprios tipos de dados. Permitindo uma portabilidade de linguagens de programao para a .Net Framework sem perda de cdigos internos, mas se for exportados para outras linguagens existir perda de cdigos internos.
5.4. ASP.NET
Um dos mais importantes recursos dos ASP.Net so os Web Forms, capaz de tornar o desenvolvimento de sites dinmicos, uma atividade atrativa e simples. ASP.Net um Framework construdo sobre o .Net, voltado a desenvolvimento de aplicaes para Web Services (Web Forms e Web Services sero abordados nos prximos captulos). Assim como o ASP tradicional o ASP.Net roda em um Servidor Web, as duas tecnologias permitem um desenvolvimento de sites personalizados, dinmicos e com contedo rico, porm a tecnologia ASP.Net possui recursos novos e melhores. O principal componente do ASP.Net o Web Form, similar ao desenvolvimento de aplicaes Windows. Os Web Forms desenvolvidos com esta tecnologia no se baseiam em script do lado cliente, por este motivo no depende do tipo do browser ou sistema operacional. A figura14 demonstra como funciona a arquitetura de aplicao ASP.Net.
70
Figura 14
Demonstra a arquitetura de uma aplicao ASP.NET
5.5. Principais vantagens desta tecnologia
possvel desenvolver aplicaes Web em qualquer linguagem baseada em .Net. O ASP.Net faz parte do .Net Framework, e para se desenvolver uma boa aplicao, no necessrio que o desenvolvedor tenha conhecimentos avanados de programao em HTML, DHTML, JAVASCRIPT ou VBSCRIPT, e nenhuma outra linguagem, pois a maioria dos cdigos j esto prontos, so gerados automaticamente.
No ASP.Net as pginas da aplicao so compiladas em um assembly que roda no servidor (nesse caso uma .DLL16 ). Isso diferente do ASP, que apenas interpretava o cdigo, montava o HTML e enviava ao browser que solicitou. Com isso, aplicaes desenvolvidas em ASP.Net so no mnimo 25% mais rpidas que aplicaes desenvolvidas em ASP. Em aplicaes com um grande nmero de acessos, esse ganho de performance torna-se ainda mais elevado, fazendo com que o ASP.Net seja realmente uma ferramenta excepcional para criao de aplicaes distribudas na Web.(ClubeDelphi, edio 51, ano IV)
16
DLL: Um recurso da famlia Microsoft Windows de sistemas operacionais que permite que rotinas executveis sejam armazenadas em separado como arquivos com extenses DLL e s sejam carregadas quando necessrio. (DYNAMIC-LINK-LIBRARY, http://xoops.softwarelivreparana.org.br, 16/10/2004)
71
possvel escolher qualquer linguagem .NET para desenvolver a lgica de aplicao, este recurso conhecido como Codebehind, podendo assim ter um profissional trabalhando na interface da aplicao utilizando a ferramenta que ele tiver um maior desempenho, e outro trabalhando na lgica de aplicao, aproveitando os recursos que os antigos funcionrios possuam, no precisando investir em treinamentos.
Figura 15
Pag 26)
Aplicao Web ASP.Net (Fonte: Revista ClubeDelphi Ed. 51, Ano IV,
Arquitetura de uma aplicao ASP.Net esta ilustrada na Figura15: Os clientes ao se conectarem a Internet, efetuam requisies ao servidor Web, atravs de Web Services, as informaes e dados. Ao desenvolver cdigos utilizando esta tecnologia possvel escrever cdigos de duas Formas: Web Forms e Web Services.
72
5.5. Web Forms
Um Web Form uma pgina dinmica que pode acessar recursos do servidor, gerando contedo a ser visualizado no browser. Como um Web Form ASP.NET no se baseia em scripts do lado do cliente, ele no depende do tipo de browser ou sistema operacional do cliente. Essa independncia permite a voc desenvolver um Web Form que pode ser visualizado em diversos browsers.(ClubeDelphi, edio: 51, ano: IV)
O Web Form, gera automaticamente o cdigo HTML que enviado para o browser, enquanto que o cdigo de tratamento dos controles permanece no servidor Web. Esse misto, entre interface cliente e cdigo no servidor, uma diferena crucial, entre Web Forms e pginas Web tradicionais.
5.6. Web Services
Maneira de se acessar um servidor remotamente usando para isso tecnologia padro como XML e HTTP. Desta maneira uma empresa pode expor informao e lgica de negcio que poder ser utilizada pelo cliente ou outra aplicao servidora dentro de um ambiente Web. A sua forte caracterstica vem da sua implementao com XML e HTTP. Isto possibilita um fcil trfego atravs de firewall17, alm de uma independncia de plataformas e linguagens de programao, j que o XML um fluxo de dados universalmente conhecido(ClubeDelphi, edio: 51, Ano IV) Web Services a melhor estratgia de componentizao para aplicaes que se integram Internet. O motivo disso que os Web Services resolvem questes especficas relacionadas Internet, que so diferentes dos desafios comuns envolvidos em aplicaes de intranet ou LANs18 , tais como latncia, falhas, heterogeneidade e segurana. (ClubeDelphi, edio: 51, Ano IV)
17 18
Firewall: Sistemas de segurana e do suporte ao computador Lans: Conjunto de computadores que comunicam entre si, compartilhando informaes existentes entre eles.
73
Quando se fala de Internet, a melhor estratgia para desenvolvimento de aplicaes sem dvida Web Services. Com esta estratgia possvel resolver problemas especficos relacionados a Internet, problemas estes mencionados anteriormente dentro do conceito de Web Services.
5.7. Multi-Camadas na Plataforma .NET
Em Multi-camadas muitas interpretaes podem surgir, como: As camadas fsicas definidas por mquinas ou camadas definidas por aplicaes. Para um maior entendimento no desenvolvimento em multi-camadas esta pesquisa focar a parte terica, no se aprofundando em partes muito tcnicas de desenvolvimento. Numa abordagem conceitual e lgica uma aplicao se constitui pelas suas funcionalidades que sero identificadas aqui como servios. Estes estaro classificados em trs categorias, esses servios j foram mencionados em captulos anteriores, porm, agora estaro voltados para Arquitetura .Net com a ferramenta ASP.Net: Servios de apresentao; Servios de Negcio; Servios de Dados.
74
5.7.1. Servios de Apresentao
Todo o visual da aplicao da aplicao estar dentro desta camada, as interfaces grficas assim como a lgica de apresentao, no desenvolvimento desta camada sero utilizados tecnologias como: Web Forms, Namespaces, Win Forms, e classes com objetivo de fazer validaes dos dados inseridos pelo usurio.
5.7.2. Servios de negcios
Nesta classe existem trs tecnologias para implementao: classes organizadas em namespaces e compiladas como .DLLs; Web Services disponibilizados como .ASMX para acesso via Web; Classes implementadas em cdigo no gerencivel (Componentes COM). Nesta camada se aplica a lgica necessria para a aplicao das regras de negcio. Dentro desta camada existem mais trs funcionalidades, que ser implementada independente da tecnologia escolhida, que so: Camada de Gerenciamento; Camada de Regras de Negcio; Camada de Acesso a Dados. Uma vantagem obtida com estas divises e utilizando esta plataforma que tornasse possvel o trabalho em equipe, delegando responsabilidades a cada um, de forma mais flexvel.
75
5.7.3. Camada de Gerenciamento
Toda aplicao desenvolvida nesta camada estar relacionada aos servios de usurio.
Eles faro a devida interao com as classes de validao de entrada de dados pelo usurio e eventuais dependncias com regras de negcio, servios de log, servios de auditoria, controle transacional e outros. Na sua implementao, geralmente as classes gerentes delegam seus servios s classes de regras de negcio depois de j terem agregado seu trabalho. (MANUAL .NET DO DESENVOLVEDOR, Pg. 6, www.swise.com.br/uploads/manuais/manualdotNetbase.doc)
5.7.4. Camada de regras de negcio
Esta camada a mais importante dentro dos negcios, esta camada s se faz necessria, pois atravs dela que conseguimos identificar os fluxos de trabalho (Workflows). Tudo o que foi feito nesta camada deve levar em conta previses de extenses aceitao de novos requisitos finalidade do negocio, com isso se tem uma maior reutilizao de seus objetos, que determinaram a dinmica de operao do negcio a ser automatizado e a criao dos principais componentes de cdigo. Na implementao desta camada, importante verificar a natureza do negcio versus as necessidades e os desejos pretendidos para a automao do sistema em questo, assim como a identificao do que ser mais importante.
76
5.7.5. Camada de Dados
A principal funo desta camada isolar tudo que estiver relacionado a manipulao dos bancos de dados, alm de fornecer dados para as regras de negcio, que modificam o contedo do banco, levando em conta as regras, isolando as funes e os detalhes da implementao fsica, como se observa na figura16. importante observar que na arquitetura de aplicao .Net, quando colocada a aplicao dividida em camadas funcionais, existiro alguns ganhos.
A utilizao de uma camada de dados entre a camada de regra de negcios encapsulando o ADO.NET garante a padronizao do mesmo para as funcionalidades mais comuns do dia a dia, promovendo facilidades de manuteno, extenso e produtividade. ( Manual .Net do Desenvolvedor, Pag. 10, www.swise.com.br/uploads/manuais/manualdotNetbase.doc, acessado em 16/10/2004)
Figura 16 - As diversas camadas funcionais no modelo de programao .NET

(Fonte:MANUAL .NET DO DESENVOLVEDOR, Pg. 10, www.swise.com.br/uploads/manuais/manualdotNetbase.doc, acessado em 16/10/2004)
77
As ferramentas dentro de cada camada se integram com ferramentas e classes de outras camadas, como demonstra a figura16. Estas camadas esto dentro da camada de acesso a dados. O ADO.Net a nova gerao do conjunto de classes de acesso a dados feito sob medida para o universo .Net, oferece vantagem na manipulao de dados em um ambiente como a Internet, que possui clientes espalhados e conectados pelo mundo todo. O ADO.Net composto de vrias classes: Connection dados Command usado para armazenar comandos SQL que so executados na base de usado para criar a conexo entre o programa e o engine do banco de
dados (SELECT, INSERT, UPDATE, DELETE, Stored Procedures, etc) DataReader trata-se de um cursor read-only e forward-only com o objetivo de
oferecer a mxima performance na busca de dados (til e eficiente para preencher combos, listas e tabelas) DataAdapter classe usada para buscar dados na base de dados e preencher uma
instncia DataSet ou DataTable. DataSet Esta classe funciona como uma base de dados na memria da aplicao.
Cria uma estrutura que permite armazenar dados de tabelas, colunas, registros e relacionamentos entre as tabelas. Os dados podem ser serializados em XML, alterados, excludos, inseridos e sincronizados com a fonte original. DataTable - Destaca-se, ainda, as classes DataTable, hierarquicamente internas classe DataSet. A classe DataTable armazena o resultado de um comando select ou stored procedure.
78
Existe dois tipos de acesso, a dados, que o ADO.NET oferece: acesso nativo ao SQL Server (SQL Server.Net Data provider) ou acesso a OLEDB Provider (OLEODB.NET Data Provider). Quando for necessrio acessar dados no SQL Server, devesse usar sempre as classes de SQL Server .Net Data Provider para obter o mximo proveito, caso contrrio use classes do OLEDB.NET DATA Provider).
1 Camada Servios de Apresentao
2 Camada Servios de Negcio
3 Camada Servios de Dados
Figura 17
Esquema de Integrao do ADO.Net
79
5.7.6. Servios de dados
Nesta camada encontrasse a aplicao de armazenamento e gerenciamento dos dados, toda estrutura lgica e fsica em que os dados esto armazenados, os protocolos de comunicao a concorrncia no acesso e o uso dos dados, a segurana entre outros Na arquitetura .Net teremos algumas tecnologias para implementao dentro desta camada, como: namespace System.Data (ADO.Net). Uma das grandes facilidades que um ambiente gerenciado proporciona a independncia de plataforma. O .Net funciona em qualquer sistema operacional que possua instalado o .Net Framework. Quando se fala de desenvolvimento em multi-camadas, deve-se observar cinco pontos importantes, para que se obtenha o mximo de desempenho e qualidade, como: Escalabilidade neste ponto deve se ater a problemas de performance, preocupando-se com
tendncias de crescimento de usurios, aumento de carga de dados, em outras palavras o tempo de resposta de um processo ao outro; Disponibilidade aqui a preocupao a medida
da porcentagem do tempo em que a aplicao demora para responder a uma requisio; Facilidade de Manuteno A projeo, implementao e instalao, so pontos
fundamentais para que se consiga maior facilidade na administrao, configurao, reparo e alterao; Segurana uma da maiores preocupaes quando se fala de aplicaes, aqui deve
se levantar a poltica de segurana da organizao e se basear nela para efetuar o desenvolvimento de restries e permisses; Facilidade de Gerenciamento Operacional
importante observar mudanas previsveis e as ferramentas e processos que sero utilizados para o desenvolvimento, garantindo assim mais facilidades no gerenciamento.
80
6. AMBIENTE WEB: UMA PLATAFORMA MULTI-CAMADAS
Um exemplo que se pode citar para exemplificar a utilizao de um sistema multicamadas a Internet, que hoje em dia um meio de comunicao e integrao utilizada mundialmente e cada vez mais acessada por milhes de usurios, o seu modelo desenvolvido na tecnologia em camadas, como mostra a Figura 18.
CAMADA DE INTERFACE INTERFACE
CAMADA DE REGRAS DE NEGCIOS
CAMADA DE DADOS
Figura 18 - Viso sobre o desenvolvimento para Internet.
O esquema acima mostra uma arquitetura dividida em trs partes, que so: Cliente (Browser), Servidor Web e SGBD (Sistema Gerenciador de Banco de Dados).
Cliente: quem faz as requisies de pginas dinmicas (ASP, PHP, etc.) para o Servidor Web.
81
Servidor Web: interpreta as pginas dinmicas, acessando o Banco de Dados e retorna para o Browser suas requisies em formato HTML. SGBD: onde ficam armazenados os dados (informaes) da aplicao.
Sempre que forem feitas transaes com pginas dinmicas, essas transaes so feitas com Banco de Dados, portanto aplicaes desse tipo so no mnimo trs camadas. Pode-se nesse mesmo modelo acrescentar novos servidores, para que sejam divididos os processos em lugares diferentes assim ganhando em performance, j que nas aplicaes para Internet, tambm depende do Cliente, pois no se sabe qual o seu tipo de conexo, e a potncia do seu Browser. Assim a aplicao se torna N-Camadas, pois tem a opo de acrescentar quantos servidores se achar necessrio.
82
CONCLUSO
Hoje vivemos na era da Internet, onde a tecnologia est cada vez mais presente no nosso dia-a-dia, nos conduzindo sempre a utiliz-la, isso tambm acontece no desenvolvimento de sistemas com a grande gama de ferramentas disponveis para o ambiente Web, que nos acaba forando direto ou indiretamente seguir essa tecnologia, conforme comentado no captulo 6, um ambiente Internet, que tenha pginas dinmicas, desenvolvido no modelo Multi-camadas, mostrando que essa metodologia uma tendncia futura, mas no descartando outras arquiteturas existentes. Aps conhecer um pouco das estruturas disponveis para se trabalhar no desenvolvimento de sistemas, nota-se que todas as arquiteturas so aplicveis, ou seja, dependem muito do ambiente a ser desenvolvido, pois a maior diferenciao est nas possveis necessidades futuras, por isso, se desenvolvem aplicaes para o ambiente atual e j pensando na escalabilidade do software conforme o crescimento da utilizao do sistema, isso induz na utilizao de vrias camadas. Com essa pesquisa notou-se que a arquitetura Multi-Camadas superior ao Cliente/Servidor, como mostrado no comparativo do captulo 2, que as desvantagens encontradas no Cliente/Servidor so corrigidas, e se tornam vantagens no ambiente MultiCamadas. Constatou-se que profissionais especializados nessa tecnologia ainda esto escassos no mercado, com isso causando um aumento do custo de desenvolvimento, e consecutivamente diminuindo a demanda sobre esse tipo de aplicao. Observou-se que as trs tecnologias adaptadas adotadas no estudo deste trabalho atendem plenamente o desenvolvimento plataforma Multi-Camadas.
83
Num futuro bem prximo o conceito de Multi-Camadas estar enraizado no desenvolvedor de sistemas, pois com essa abordagem s se tem a ganhar, principalmente em performance e escalabilidade, ela separa a lgica (regra de negcios) da apresentao (Interface), agilizando na manuteno dos sistemas de maneira impossvel em outros conceitos apresentado nesse trabalho. E trar para o profissional uma ferramenta competitiva que cada vez mais as empresas procuram e necessitam para o apoio tomada de deciso, de forma rpida e eficaz no mundo dos negcios.
84
REFERNCIAS
.Net, Disponvel em: <http://www.comquest.com.br/Net.ASP >. Acesso em: 06 out. 2004.
ASP, Disponvel em: <http://www.fundanet.br>. Acesso em: 06 out. 2004. BONFIN, Francisco T. JavaServer Page: A Tecnologia Java na Internet. So Paulo: Editora rica, 2002. CGI, Disponvel em: <http://www.rafah.hpg.ig.com.br/cgi.html>. Acesso em: 16 nov. 2004. Console, Disponvel em: <http://www.netpedia.com.br>. Acesso em: 20 set. 2004. Criando Aplicaes em 3, 4 ou n Camadas, Disponvel em: < http://www.juliobattisti.com.br/artigos/ti/ncamadas.asp>. Acesso em: 28 abr. 2004. Desenvolvimento de Aplicaes Web Sobre a Plataforma J2EE, Disponvel em: < http://www.juliobattisti.com.br/artigos/ti/ncamadas.asp>. Acesso em: 06 mai. 2004. DLL, Disponvel em: <http://xoops.softwarelivreparana.org.br/modules/wordbook/print.php?entryID=6280>. Acesso em: 16 nov. 2004. Estrutura .Net com a linguagem ASP.NET, Disponvel em: <http://www.altabooks.com.br/pdf/Aplica%C3%A7oes%20WEB_01.PDF>. Acesso em: 06 out. 2004. FIELDS, Duane K.; KOLB Mark A. Desenvolvendo na Web com JavaServer Page. Rio de Janeiro: Cincia Moderna, 2000. GRANDO, Andr L. C., BOMFIM, David R. D., LDA Marcel I. Arquitetura Multi-camadas. Disponvel em: <http://www.sit.com.br/textos/Multilayer.doc>. Acesso em: 01 jun. 2004. GUI, Disponvel em: <http://www.freenetpages.co.uk/hp/alan.gauld/port/tutgui_por.htm>. Acesso em: 16 jul. 2004. Hard Coded, Disponvel em: <http://www.netpedia.com.br/MostraTermo.php?TermID=3034>. Acesso em: 16 nov. 2004. Introduo e Motivao: Arquiteturas em n Camadas, Disponvel em: < http://jacques.dsc.ufcg.edu.br/cursos/j2ee/html/intro/intro.htm>. Acesso em: 27 abr. 2004.
85
KON, Fabio. Middleware Reflexivo: Construindo Sistemas Distribudos Flexveis, Adaptveis e Reconfigurveis. Disponvel em:<www.clubedelphi.net>. Acesso em: 12 set. 2004. Manual .Net do Desenvolvedor, Disponvel em: < http:://www.swise.com.br/uploads/manuais/manualdotNetbase.doc>. Acesso em: 29 out. 2004. MATOS, Gladstone; Entenda o conceito de Multi-Camadas. Revista ClubeDelphi, Rio de Janeiro, n. 16, p. 35-37, 2002. MOURA, Sanyo C. S.; ASP.NET: Desenvolvimento para Web com Delphi 8. Revista ClubeDelphi, Rio de Janeiro, n. 51, p. 26-31, 2002. MOURO, Walter I. Falando em Camadas. Disponvel em: <http://www.delphi.eti.br/ver_artigo.php?id=5&PHPSESSID=a1a0b20e30e40fd07432ad1841 70f528>. Acesso em: 03 mai. 2004. PAULI, Guinther B.; Multicamadas Passo a Passo: Migre para uma arquitetura baseada em DataSnap no Delphi e Kylix. Revista ClubeDelphi, Rio de Janeiro, n. 46, p. 22-30, 2004.
PAULOVICH, Fernando V. Middlewares em Sistemas Distribudos Disponvel em: < http://www.dc.ufscar.br/~paulovic/MidSDs.pdf>. Acesso em: 18 set. 2004.
Pool de Conexo e Trs Camadas. Disponvel em: < http://www.imasters.com.br/web/conteudo/coluna_delphi.php?codcoluna=1756>. Acesso em: 29 abr. 2004. RODRIGUES, Anderson H. Sistemas Multicamadas com Delphi DataSnap e DBExpress: Conceitos, Implementao e Macetes. Florianpolis: VisualBooks, 2002. SANTOS JUNIOR, Jos M. R.. Arquitetura de Aplicaes. Disponvel em: < http://www.unit.br/zemaria/arquivos/Arquitetura.pdf>. Acesso em: 06 mai. 2004. Threads, Disponvel em: <http://www.linux.ime.usp.br/~bani/java/ej7.html>. Acesso em: 20 set. 2004. WILDT, Daniel; Aplicaes Multi-Camadas: Entenda o MIDAS e Multicamadas. Revista ClubeDelphi, Rio de Janeiro, n. 16, p. 21-25, 2002
86
Desenvolvido por:
Arthur Andreazi Neto arthurandreazi@terra.com.br
Lucas Simes Maistro lucassimoes@fundanet.br
William Marto Rodrigues willmadri@hotmail.com
This document was created with Win2PDF available at http://www.daneprairie.com. The unregistered version of Win2PDF is for evaluation or non-commercial use only.

Multi Camadas

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Multi Camadas

Caricato da

Copyright:

Formati disponibili

1

ARTHUR ANDREAZI NETO LUCAS SIMES MAISTRO WILLIAM MARTO RODRIGUES

SISTEMAS MULTI-CAMADAS: UMA TENDNCIA PARA O DESENVOLVIMENTO DE APLICAES

ARTHUR ANDREAZI NETO LUCAS SIMES MAISTRO WILLIAM MARTO RODRIGUES

SISTEMAS MULTI-CAMADAS: UMA TENDNCIA PARA O DESENVOLVIMENTO DE APLICAES

Orientador: Prof. Mestre Elvis Fusco

ARTHUR ANDREAZI NETO LUCAS SIMES MAISTRO WILLIAM MARTO RODRIGUES

SISTEMAS MULTI-CAMADAS: UMA TENDNCIA PARA O DESENVOLVIMENTO DE APLICAES

ORIENTADOR: Prof. Mestre Elvis Fusco

Marlia, 18 de Outubro de 2004.

Muito Obrigado a Todos.

Ter obstculos na vida inevitvel... ...ser derrotado por eles opcional.

Palavras-chave: Middleware. Cliente/Servidor. Multi-Camadas.

Keywords: Middleware. Client/Server. Multi-Layers.

Palabras-Clave: Middleware. Cliente/Servidor. Multi-camadas

1.1. Aplicaes em uma camada

Terminais Burros: mquinas onde no h processamentos.

1.2. Aplicaes em duas camadas

Figura 1 Modelo Cliente / Servidor

1.2.1. Regras na interface

1.2.2. Regras junto dos dados

1.2.3. Regras junto interface e junto aos dados.

1.2.4. Problemas do cliente / servidor

1.3. Aplicaes em trs camadas:

Figura 2 Modelo Trs Camadas.

1.3.1.1. Camada de apresentao

1.3.1.2. Camada de Negcio

1.3.1.3. Camada de dados

1.3.2. Vantagens da tecnologia Multi-Camadas

2. COMPARATIVO - APLICAES TRS CAMADAS X DUAS CAMADAS

Figura 3 Arquitetura Cliente/Servidor e Trs Camadas

2.1. O modelo cliente servidor

2.1.1. Manuteno do aplicativo

2.1.2. Distribuio do aplicativo

2.2. O modelo Trs Camadas

2.2.1. Manuteno do aplicativo

2.2.2. Distribuio do aplicativo

3. APLICAES MULTI-CAMADAS COM DELPHI

3.1.1. Objetos distribudos

3.2. Sistemas distribudos

Figura 5 Middleware de Comunicao

Figura 6 Arquitetura DataSnap para aplicaes distribudas.

3.5. Multitier (multicamadas)

3.6.1. CORBA (Common Object Request Broker Architecture)

3.6.2. COM (Component Object Model)

3.6.3. DCOM (Distributed Componente Object Model)

3.6.4. MTS (Microsoft Transaction Server)

3.6.5. COM+ (Componente Object Model Plus)

3.6.5.1. Eventos COM+

Atualizao das informaes.

3.6.7. HTTP (Hyper Text Transfer Protocol)

3.6.8. SOAP (Simple Object Access Protocol)

3.7. Componentes do Delphi para desenvolvimento em camadas

TRemoteDataModule: implementa o mdulo de dados para aplicaes que

3.8. Funcionamento de uma aplicao DataSnap

Sockets TCP/IP, TSOAPConnection

Cursor Bidirecional Cache Local Cursor Unidirecional

Figura 7 Modelo de aplicao DataSnap

informaes para o banco de dados.

4. A TECNOLOGIA JAVASERVER PAGES (JSP)

4.1. O JavaServer Pages

Figura 8 - Camadas de Aplicao da Web

4.2.1. A camada de apresentao

4.2.2. A camada de lgica de aplicao