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

2




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

3




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.

4

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.

5

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.

6

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

7

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.

8



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.

9



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

Planejamento de Recursos Empresariais), CRM (Customer Relationship

Management

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 adequada de sua

arquitetura.

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)

1 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.

2 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.

4 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:

6 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).

7 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. Pode-

se 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.

8 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

CORBA,

TDCOMConnection

DCOM, TWebConnection

HTTP, TSocketConnection

Sockets

TCP/IP, TSOAPConnection - SOAP).

TClientDataSet: utiliza os dados providos do DataSetProvider e negocia no

momento de atualizar as informaes. Faz a abstrao no acesso a dados, quem mostra os

dados que vem do Servidor de Aplicao.

TSimpleObjectBroker: componente guarda uma lista de servidores disponveis,

e encaminha para os componentes de comunicao.

3.8. Funcionamento de uma aplicao DataSnap

O modelo de uma aplicao DataSnap composto de vrios componentes do Delphi.

A Figura 7 retrata uma aplicao em camadas (de forma geral), para o possvel entendimento

bsico de cada camada utilizando o Delphi. Importante dizer que qualquer componente de

conexo como: TCORBAConnection

CORBA, TDCOMConnection

DCOM,

TWebConnection

HTTP, TSocketConnection

Sockets TCP/IP, TSOAPConnection

SOAP, tem que estar presente na parte cliente para fazer comunicao com o servidor de

aplicao, portanto cabe ao desenvolvedor escolher o melhor para o seu projeto, tambm

44

podendo usar na parte cliente um componente SimpleObjectBroker para guardar uma lista de

servidores que estaro disponveis no servidor de aplicao, caso algum encontre algum

problema ele aciona outro.

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.

Ba

se

Da

dos

Clie

nte

Serv

ido

r

de

Aplic

a

o

ApplyUpdatesDataPacket

CursorUnidirecional

Cache LocalCursor Bidirecional

45

O ClientDataSet, que possui cursor bidirecional (consulta, inclui, altera, exclui), coloca as

informaes passadas pelo DataSetProvider na memria e trabalha normalmente com elas,

aps as devidas manipulaes, o ClientDataSet utiliza o mtodo ApplyUpdates, que aplica as

alteraes voltando para o servidor de aplicao, e ele consecutivamente envia as

informaes para o banco de dados.

46

4. A TECNOLOGIA JAVASERVER PAGES (JSP)

A tecnologia JavaServer Pages foi desenvolvida com o intuito de facilitar o

processo de desenvolvimento de sites Web dinmicos, permitindo desse modo incorporar

elementos dinmicos nas mesmas de forma rpida pelos designers e programadores Web.

4.1. O JavaServer Pages

Em aplicaes Web, independentemente de sua complexidade, seu desenvolvimento

se d em funo de 3 reas lgicas, da mesma forma como vnhamos descrevendo no decorrer

do trabalho, ou seja, a camada de apresentao ou cliente, a camada de controle que controla o

fluxo de apresentao, a camada lgica de apresentao, que gerencia os dados de aplicao,

gerencia clculos e se comunica com os recursos de back-end, tambm conhecida como o

modelo (banco de dados) (FIELDS, KOLB, 2000), compreendendo assim 3 reas lgicas,

que junto com o banco de dados se torna uma aplicao em 4 camadas.

Freqentemente, vantajoso tratar cada camada como uma parte independente de sua aplicao. Isolar as partes lgicas da aplicao ajuda a garantir que voc tenha coberto todas as bases do design, se concentre na criao de uma arquitetura robusta e crie os fundamentos para a implementao. (FIELDS, KOLB, 2000).

47

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.

Banco de Dados

Camada de Apresentao

Camada de Controle

Lgica de Aplicao

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).

9 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

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.

Menu.jsp catalog.jsp checkout.jsp

Banco de Dados

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).

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.

Cliente Servlet

JSP

Banco de Dados

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.

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)

Menu.jsp

catalog.jsp

checkout.jsp

Banco de Dados

servlet

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

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.

Cliente Servlet EJB

JSP Banco de Dados

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 nme

Documents

Multi Camadas