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

LUCAS SIMES MAISTRO

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

LUCAS SIMES MAISTRO

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
Uma aplicao de catlogo centrada em servlets..............................................54
FIGURA 12
Um EJB lidando com a lgica da aplicao......................................................64
FIGURA 13
Estrutura .Net com a linguagem ASP.NET.......................................................67
FIGURA 14
Demonstra a arquitetura de uma aplicao ASP.NET......................................70
FIGURA 15
Aplicaes Web ASP.NET...............................................................................71
FIGURA 16
As diversas camadas funcionais no modelo de programao .NET.................76
FIGURA 17
Esquema de Integrao do ADO.NET..............................................................78
FIGURA 18
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:
TWebConnection
TCORBAConnection
CORBA,
HTTP, TSocketConnection
TDCOMConnection
DCOM,
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
Se r vid o r d e Ap lica o
B a se D a d o s
problema ele aciona outro.
Cursor Bidirecional
Cache Local
Clie n t e
Cursor
Unidirecional
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.
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
informaes para o banco de dados.
as
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
JSP
EJB
Banco de
Dados
Figura -12 Um EJB lidando com a lgica da aplicao
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
Aplicao Web ASP.Net (Fonte: Revista ClubeDelphi Ed. 51, Ano IV,
Pag 26)
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
usado para criar a conexo entre o programa e o engine do banco de
Command
usado para armazenar comandos SQL que so executados na base de
dados
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>.
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>.
Pool de Conexo e Trs Camadas. Disponvel em:

< http://www.imasters.com.br/web/conteudo/coluna_delphi.php?codcoluna=1756>.
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>.
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

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Multi Camadas

Enviado por

Direitos autorais:

Formatos disponíveis

1

FUNDAO DE ENSINO EURPIDES SOARES DA ROCHA

ARTHUR ANDREAZI NETO

SISTEMAS MULTI-CAMADAS: UMA TENDNCIA PARA O

ARTHUR ANDREAZI NETO

SISTEMAS MULTI-CAMADAS: UMA TENDNCIA PARA O

Monografia apresentada a Faculdade de

ARTHUR ANDREAZI NETO

SISTEMAS MULTI-CAMADAS: UMA TENDNCIA PARA O

Banca examinadora da Monografia apresentada a faculdade de

ORIENTADOR: Prof. Mestre Elvis Fusco

Marlia, 18 de Outubro de 2004.

Primeiramente, dedicamos este trabalho

Inicialmente agradecemos a Deus por nos proporcionar a vida e nos

Ter obstculos na vida inevitvel...

ANDREAZI NETO, Arthur; MAISTRO, Lucas S.; RODRIGUES, William M. Sistemas

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

ANDREAZI NETO, Arthur; MAISTRO, Lucas S.; RODRIGUES, William M. Sistemas

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

ANDREAZI NETO, Arthur; MAISTRO, Lucas S.; RODRIGUES, William M. Sistemas

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

FIGURA 1 Modelo Cliente/Servidor.....................................................................................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

ASP: Active Server Pages

MTS: Microsoft Transsaction Server

3.7. COMPONENTES DO DELPHI PARA DESENVOLVIMENTO EM CAMADAS ..............................42

Com a competitividade fazendo parte do conjunto global de uma empresa, e os

Planejamento de Recursos Empresariais), CRM (Customer Relationship

Com auxlio de livros, revistas, dissertaes de mestrado e artigos, tambm

1.1. Aplicaes em uma camada

As aplicaes baseadas em nica camada, tambm conhecidas como aplicaes

A abordagem baseada em nica camada prov um nmero significante de

Terminais Burros: mquinas onde no h processamentos.

1.2. Aplicaes em duas camadas

Estas aplicaes so conhecidas como Cliente / Servidor, onde dividem a aplicao

Figura 1 Modelo Cliente / Servidor

Trabalhando com essa arquitetura, h trs opes ao se desenvolver, como: Regras

1.2.1. Regras na interface

1.2.2. Regras junto dos dados

Com essa metodologia de desenvolvimento liga-se diretamente a aplicao com o

1.2.3. Regras junto interface e junto aos dados.

a opo mais adequada para esse tipo de arquitetura, balanceando as regras de

1.2.4. Problemas do cliente / servidor

Requisies ao servidor, mesmo os clientes tendo acessos distintos, podem

1.3. Aplicaes em trs camadas:

As aplicaes trs camadas, tambm conhecidas como multi-camadas ou multi-tier,

Figura 2 Modelo Trs Camadas.

1.3.1.1. Camada de apresentao

1.3.1.2. Camada de Negcio

onde esto s regras do negcio, tambm conhecidas como Servidor de Aplicao,

1.3.1.3. Camada de dados

Onde ficam armazenados os dados (Banco de Dados). No modelo em camadas,

1.3.2. Vantagens da tecnologia Multi-Camadas

Mesmo o modelo multi-camadas tendo obstculos como, dificuldades de

2. COMPARATIVO - APLICAES TRS CAMADAS X DUAS

Este captulo tem como objetivo fazer um comparativo (Figura 3) entre o