- Polis Educacional

Daniel Berti Fonseca
RA 0310096 - 8º semestre
INTEGRAÇÃO DE SISTEMAS CORPORATIVOS
COMPLEXOS COM JAVA EE
Jaguariúna
2006
Daniel Berti Fonseca
RA 0310096 - 8º Semestre
INTEGRAÇÃO DE SISTEMAS CORPORATIVOS
COMPLEXOS COM JAVA EE
Monografia apresentada à disciplina Trabalho
de
Graduação,
do
curso
de
Ciência
da
Computação da Faculdade de Jaguariúna, sob
orientação do Prof. Ms. Peter Jandl Jr., como
exigência
graduação.
Jaguariúna
2006
1
para
conclusão
do
curso
de
FONSECA, Daniel Berti. Integração de Sistemas Corporativos Complexos com
Java EE. 2006. Monografia (Bacharelado em Ciência da Computação) – Curso de
Ciência da Computação da Faculdade de Jaguariúna, Jaguariúna.
RESUMO
Existe hoje um número imenso de sistemas heterogêneos e com diferentes
aplicações sendo utilizados por empresas ou instituições. Com o surgimento de
novas tecnologias e com a necessidade de integração entre sistemas diferentes,
surge a importância da utilização de padrões abertos no desenvolvimento de
aplicações para tentar simplificar uma tarefa que a princípio é extremamente
complexa. Existem plataformas que visam facilitar o desenvolvimento de aplicações
distribuídas e integração entre sistemas, entre estas plataformas destacam-se o Sun
Java Enterprise Edition (todo baseado na tecnologia Java) e o .NET (de propriedade
da Microsoft). Apesar de compartilharem o mesmo propósito, ambas as plataformas
possuem características distintas em diferentes aspectos. Após pesquisa, verificouse que a plataforma da Sun com certeza leva grande vantagem sobre o rival .NET,
principalmente por sua independência de plataforma ou fornecedor, porém cada
caso é um caso, e a escolha de qualquer uma destas plataformas com certeza deve
estar relacionada a uma serie de fatores que devem ser levados em consideração e
cabe a cada empresa ou instituição definir a que melhor se adequa à sua realidade.
Palavra-Chave: INTEROPERABILIDADE, INTEGRAÇÃO DE SISTEMAS.
2
LISTA DE SIGLAS
Java EE - Java Enterprise Edition
JSP - Java Server Pages
EJB - Enterprise Java Beans
EIS - Enterprise Information System
API - Application Programming Interface
JDBC - Java Database Connectivity
JCA - Java Connector Architecture
XML - Extensible Markup Language
HTML - Hyper Text Markup Language
ERP - Enterprise Resource Planning
RMI - Remote Method Invocation
CORBA - Common Object Request Broker Architeture
SOAP - Simple Object Access Protocol
HTTP - HyperText Transfer Protocol
MDB - Message Driven Beans
CCI - Common Client Interface
JMS - Java Message Service
kM - Knowledge Management
CRM - Custom Relationship Management
EAI - Enterprise Application Integration
WSDL - Web Services Description Language
UDDI - Universal Description, Discovery and Integration
CLS - Common Language Specification
CLR - Common Language Runtime
XHTML - Extensible HyperText Markup Language
3
LISTA DE FIGURAS
Figura 1 - Modelo de Divisão em Camadas ------------------------------------------- 10
Figura 2 - Java EE Containeres ---------------------------------------------------------- 12
Figura 3 - Interações da camada web -------------------------------------------------- 13
Figura 4 - Acesso a componentes EJB ------------------------------------------------- 16
Figura 5 - Arquitetura de Conectores --------------------------------------------------- 22
Figura 6 - Comparativo Java EE e .NET ----------------------------------------------- 28
4
SUMÁRIO
RESUMO ----------------------------------------------------------------------------------------- 2
LISTA DE SIGLAS ----------------------------------------------------------------------------- 3
LISTA DE FIGURAS --------------------------------------------------------------------------- 4
1. INTRODUÇÃO ------------------------------------------------------------------------------- 6
2. ARQUITETURA JAVA EE----------------------------------------------------------------- 9
2.1 Containeres Java EE ------------------------------------------------------------11
2.2 A Camada web ------------------------------------------------------------------- 12
2.2.1 Tecnologias envolvidas --------------------------------------------- 13
2.2.2 Java servlets ----------------------------------------------------------- 14
2.2.3 Java server pages ---------------------------------------------------- 14
2.3 A Camada de negócio ---------------------------------------------------------- 14
2.3.1 Lógica de negócio ---------------------------------------------------- 15
2.3.2 Componentes de negócio ------------------------------------------ 16
2.3.3 Tipos de componentes EJB ---------------------------------------- 17
3. INTEGRAÇÃO COM DEMAIS SISTEMAS EXISTENTES ----------------------- 20
3.1 Tipos existentes de integração de sistemas ------------------------------ 20
3.2 Tecnologias de integração em um sistema Java EE ------------------- 21
3.2.1 JCA ----------------------------------------------------------------------- 21
3.2.2 JMS ----------------------------------------------------------------------- 23
3.2.3 JDBC --------------------------------------------------------------------- 23
4.
ARQUITETURA
TECNOLÓGICA
DOS
SISTEMAS
DE
INFORMAÇÃO
EMPRESARIAIS -------------------------------------------------------------------------------- 24
4.1 Modelos atuais -------------------------------------------------------------------- 25
4.2 A Integração de sistemas através de Web Services -------------------- 25
5. SUN JAVA EE X MICROSOFT .NET -------------------------------------------------- 28
5.1 Segurança -------------------------------------------------------------------------- 29
5.2 Independência de fornecedor ------------------------------------------------- 30
5.3 Interoperabilidade ---------------------------------------------------------------- 30
5.4 Web services ---------------------------------------------------------------------- 31
5.5 Maturidade ------------------------------------------------------------------------- 32
5.6 Migração para futuras plataformas ------------------------------------------- 32
5
5.7 Escalabilidade --------------------------------------------------------------------- 33
5.8 Performance ----------------------------------------------------------------------- 33
6. CONCLUSÃO -------------------------------------------------------------------------------- 34
7. REFERENCIAS BIBLIOGRÁFICAS ---------------------------------------------------- 35
6
1. INTRODUÇÃO
Quais as vantagens e desvantagens da utilização da tecnologia Java EE
(Java Enterprise Edition) na Integração de Sistemas Corporativos Complexos e no
desenvolvimento de aplicações distribuídas?
O que as grandes empresas visam quando investem no desenvolvimento de
aplicações em ambiente distribuído ou mesmo na implementação de novos serviços
são principalmente a redução de custo e o aumento no desempenho de seus
negócios e em conseqüência disto, o aumento de capital. Geralmente, estas
aplicações ou serviços devem combinar sistemas ou informações já existentes
(informações acumuladas ao longo de toda a vida de uma empresa) com novas
funcionalidades ou novas funções de negócio. A maioria das informações destas
empresas, geralmente estão concentradas em um ou mais banco de dados ou
mesmo em sistemas legados. BALL; CARSON; HAASE; JENDROCK; EVANS
(2004, p.1)
O grande desafio de se desenvolver este tipo de aplicação está em como
integrar uma nova aplicação ou um novo serviço com os diversos sistemas já
existentes. Para alcançar este objetivo são necessários padrões que permitam o
acesso da aplicação a estes sistemas já existentes e que em muitas vezes,
envolvem tecnologias heterogêneas.
A plataforma Java EE surge com o objetivo de padronizar e simplificar a
criação de aplicações corporativas. Para isso, propõe um modelo onde os
componentes Java EE (páginas JSP (Java Server Pages), Servlets, EJB's
(Enterprise Java Beans), etc) podem fazer uso dos serviços por ela fornecidos, os
quais simplificam em muito sua implementação e possibilitam assim que a maioria
do tempo de projeto seja gasto buscando a solução do problema proposto e não em
implementação.
Ela disponibiliza serviços que se destinam a suprir as necessidades de
aplicações empresariais distribuídas, isto é, aquelas que necessitam da flexibilidade
de disponibilizar acesso à sua lógica de negócio e dados para diferentes tipos de
7
dispositivos clientes (navegadores, dispositivos móveis, aplicações desktop, etc) ou
para outras aplicações residentes na mesma empresa ou fora desta.
As aplicações distribuídas normalmente são compostas de uma camada
cliente, que implementa a interface com o usuário, uma ou mais camadas
intermediárias, que são responsáveis por processar toda a lógica do negócio e
provêem serviços à camada cliente, e outra, chamada de EIS (Enterprise Information
System), formada por sistemas legados e bancos de dados. A infra-estrutura
oferecida por esta plataforma possibilita que estas camadas, possivelmente
localizadas em máquinas diferentes, possam se comunicar remotamente e juntas
comporem uma única aplicação.
Um diferencial significativo na arquitetura foi a iniciativa de enfatizar a
utilização de padrões de projetos. Estes padrões possibilitam o projeto de soluções
mais rapidamente e com qualidade e visa principalmente flexibilidade, organização e
reaproveitamento de código, o que resulta em maior produtividade, qualidade e
facilidade de manutenção das aplicações desenvolvidas. Os desenvolvedores
contam ainda com os chamados Java BluePrints que são boas práticas de
desenvolvimento e modelos de soluções para problemas comuns encontrados no
desenvolvimento de aplicações.
Nos últimos anos, a plataforma Java EE vem transformando o mercado de
computação empresarial distribuída. Este grande sucesso se dá pelo fato de que ela
foi toda desenvolvida como um padrão aberto de desenvolvimento, ou seja, não fica
dependente de uma plataforma e isso assegurou que muitos dos fornecedores de
soluções para computação voltassem seus olhos para gama de possibilidades que a
ela podia oferecer.
A plataforma caracteriza-se por ser altamente escalável, extensível e flexível,
e que preserva os investimentos em tecnologia e ainda, a definição de API’s
(Application Programming Interface) de acesso em Java permite que produtos de
outras empresas que sejam compatíveis com a plataforma Java, entre elas podemse citar a Oracle e IBM, sejam facilmente utilizados em sistemas Java EE, com a
vantagem de ser possível migrar para produtos concorrentes sem reescrever a
aplicação, ou ser possível utilizar dois ou mais produtos concorrentes na mesma
aplicação. SINGH; STEARNS; JOHNSON (2004, p.23)
Estas API’s fornecem suporte a várias funcionalidades entre elas a conexão
com banco de dados relacionais através de JDBC (Java Database Connectivity),
8
integração com outros sistemas já existentes através da tecnologia JCA (Java
Connector Architecture) e ainda fornece suporte ao desenvolvimento de Web
Services fazendo uso das API’s de processmento XML (eXtensible Markup
Language) e de outros protocolos de comunicação padrões para troca de
informações entre aplicações.
Existem várias tecnologias disponíveis no mercado que prometem atender as
necessidades das empresas quanto a soluções para o desenvolvimento de
aplicações distribuídas e por sua vez na integração de sistemas. Entre elas está o
Microsoft .NET, porém a plataforma da Sun vem ganhando a preferência dos
desenvolvedores por suas características e principalmente por sua independência
de plataforma.
O objetivo deste trabalho é caracterizar os problemas e dificuldades da
integração de sistemas coorporativos complexos, avaliar as alternativas existentes
no mercado para a integração de sistemas, estudo detalhado da arquitetura Java EE
e analisar as vantagens e desvantagens frente à plataforma.NET da Microsoft.
Como todo o trabalho está voltado ao estudo das tecnologias utilizadas para a
integração de sistemas coorporativos e focando principalmente na plataforma Java
e relacionando as alternativas existentes no mercado que atendem a estes
propósitos, o cronograma de estudos foi dividido em tópicos de forma que
gradativamente venha-se a obter o conhecimento sobre a arquitetura das
tecnologias estudadas e suas aplicações.
Voltando para a utilização de padrões abertos na integração de sistemas, a
primeira parte das etapas de estudo é adquirir conhecimento sobre a arquitetura,
componentes, API’s e um breve estudo sobre as camadas que podem compor uma
aplicação distribuída.
Na segunda etapa, dedica-se a um estudo aprofundado das camadas que
fazem parte de uma aplicação Java EE, entre elas as camadas web e EJB.
A terceira etapa destina-se ao estudo das formas de integração existentes e
ao estudo das API’s que compõe a plataforma e que se destinam a fornecer suporte
a integração de aplicações Java com demais sistemas existentes.
Na última etapa, serão relacionadas algumas das alternativas existentes no
mercado quanto a integração de sistemas e desenvolvimento de aplicações
distribuídas e fazer um estudo comparativo entre a plataforma da Sun e o Microsoft
9
.Net quanto a aplicações distribuídas, Web Services e na integração com demais
sistemas indicando as vantagens e desvantagens de cada plataforma.
2. ARQUITETURA JAVA EE
A plataforma Java EE foi desenvolvida para suportar aplicações distribuídas
multicamadas tanto do lado do cliente quanto do servidor. As aplicações são
configuradas da seguinte forma: uma camada para fornecer uma interface ao
usuário, uma camada responsável por fornecer serviços para o cliente e a lógica de
negócio para algumas aplicações e uma outra camada responsável pelo
gerenciamento de dados.
No modelo de desenvolvimento em camadas, toda a lógica da aplicação é
distribuída entre os componentes do sistema de acordo com a sua função. Os
componentes que fazem parte da plataforma podem ser instalados em máquinas
diferentes dependendo da camada a qual o componente pertence. Estes
componentes consistem basicamente de classes Java que são capazes de
comunicar-se com outros componentes do sistema. A principal diferença entre um
componente Java EE e um componente Java padrão, é que um componente Java
EE tem que ser desenvolvido seguindo as especificações impostas pela plataforma e
os mesmos são executados e administrados pelo servidor Java EE. BALL;
CARSON; HAASE; JENDROCK; EVANS (2004, p.2)
A plataforma fornece uma clara divisão, tanto lógica quanto física, de uma
aplicação em camadas. O particionamento de uma aplicação em camadas permite
uma maior flexibilidade de escolha da tecnologia apropriada para uma determinada
situação. Múltiplas tecnologias podem ser utilizadas para fornecerem o mesmo tipo
de serviço possibilitando escolher a que melhor se adeqüa baseado nas
características do problema em questão. Na Figura 1 é apresentada uma visão das
camadas que podem fazer parte de uma aplicação distribuída Java EE.
10
Figura 1 - Modelo de Divisão em Camadas
Camada cliente:
É responsável por interagir e apresentar os dados aos usuários e por se comunicar
com outras camadas da aplicação. Em geral é a única parte da aplicação com a qual
o usuário tem contato. A camada cliente comunica-se com outras camadas através
de interfaces bem definidas.
Camada web:
É quem recebe e processa as requisições dos usuários através de um web
container. É responsável por realizar todo processamento web, como hospedar
páginas HTML (Hyper Text Markup Language), executar servlets e formatar páginas
JSP a serem apresentadas pelos navegadores. Também pode ser responsável pelo
controle do fluxo da aplicação e por processar parte da lógica de negócio da
aplicação, incluindo o gerenciamento de conexões com banco de dados e
conectores para acesso a recursos legados.
11
Camada de Negócio:
Camada responsável pelo processamento dos componentes EJBs ou seja, pelo
processamento dos componentes responsáveis pelas funções ou regras de negócio.
Esta camada fornece serviços, implementados por um EJB container, para os EJBs.
Alguns deles são: controle de transação, mecanismos de segurança, persistência,
dentre outros. Estes serviços disponíveis facilitam a vida do programador, que fica
livre da obrigação de ter que tratá-los, podendo se concentrar mais na
implementação das funcionalidades inerentes ao seu negócio. Quando esta camada
está presente, a lógica de negócio (toda ou parte desta) pode passar a ser
implementada nos componentes de negócio distribuídos, ficando a camada web
assim mais voltada à exibição dos dados.
Camada de banco de dados e sistemas de informação legados:
Tipicamente nesta camada estão incluídos sistemas gerenciadores de banco de
dados, ERP’S (Enterprise Resource Planning) e quaisquer sistemas legados. Com o
apoio da API JCA, esta camada provê uma infra-estrutura de software que mapeia
dados e recursos de aplicações existentes dentro de projetos Java EE de forma
padronizada.
2.1 Container Java EE
Os componentes criados numa aplicação Java EE devem ser instalados em
seu container apropriado. Um container é um ambiente de execução padronizado
que fornece serviços específicos a um componente. Assim, um componente pode
esperar que em qualquer plataforma Java EE implementada por qualquer fornecedor
estes serviços estejam disponíveis. Sun Microsystems
(http://java.sun.com/javaee/5/docs/tutorial/doc/, Mar. 2006)
Um container também pode administrar serviços não configuráveis como, por
exemplo, o ciclo de vida de componentes EJB e Servlets, recursos de conexão de
banco de dados, persistência dos dados e acesso as API’s da plataforma.
Um web container, por exemplo, destina-se a processar componentes web
como servlets, JSP's, HTML's e Java Beans.
12
Um EJB container destina-se a fornecer a infra-estrutura necessária para a
execução de componentes de negócio distribuídos. Um EJB é um componente de
software que estende as funcionalidades de um servidor permitindo encapsular
lógica de negócio e dados específicos de uma aplicação. Tal componente pode ser
acessado de maneiras diferentes, por exemplo, através de RMI (Remote Method
Invocation), CORBA (Common Object Request Broker Architeture) ou SOAP (Simple
Object Access Protocol), o que possibilita que este seja utilizado por qualquer
tecnologia que provê suporte a um destes padrões de comunicação.
A plataforma Java EE permite uma arquitetura flexível sendo que tanto o web
container quanto o EJB container são opcionais como demonstra a Figura 2.
Figura 2 - Java EE Containeres
2.2 A Camada web
Em uma aplicação Java EE, a camada web é responsável por tornar a lógica
de negócio acessível por toda a rede. A camada WEB administra todas as
comunicações de uma aplicação com os clientes web, invocando a lógica de
negócio e transmitindo dados requisitados através de chamadas.
Esta camada trabalha com conteúdos HTML ou XML e ela pode gerar e servir
este tipo de conteúdo. Enquanto a lógica de negócio normalmente é implementada
13
em componentes EJB, ela também pode em certos casos ser implementada na
camada web. A Figura 3 exibe a interação entre a camada web e as demais
camadas
que
podem
fazer
parte
de
uma
aplicação.
Sun
Microsystems
(http://java.sun.com/javaee/5/docs/tutorial/doc/, Abr. 2006)
Figura 3 – Interações da camada web
As principais funções da camada web dentro de uma aplicação Java EE são:
-
Administrar a interação entre os clientes web e a lógica de negócio da
aplicação.
-
Gerar conteúdo dinâmico em diversos formatos de dados, entre eles HTML,
XML, imagem, som e vídeo.
-
Traduzir chamadas HTTP e repassá-las de modo que a camada de negócio
entenda e apresente os resultados no conteúdo web.
-
Implementar a lógica de negócio (enquanto muitas aplicações distribuídas
concentram a lógica de negócio em componentes EJB, algumas aplicações
podem conter algum tipo de lógica de negócio dentro da camada web).
2.2.1 Tecnologias envolvidas
14
Uma aplicação web nada mais é do que uma coleção de componentes da
camada web, conteúdo e informações de configuração e que opera como se fosse
uma única unidade funcional.
A especificação da plataforma define dois tipos de tecnologias para
componentes web. Estas tecnologias são os Servlets e páginas JSP. Estes dois
componentes são executados pelo container web.
2.2.2 Java servlets
Um Servlet é um programa que estende a funcionalidade de um web server,
gerando conteúdo dinâmico e interagindo com os clientes, utilizando o modelo
request/response.
Os
servlets
não
são
restritos
ao
modelo
HTTP
de
request/response, onde na realidade são pequenas aplicações de servidores, mas o
modelo HTTP é o modelo mais comumente utilizado.
2.2.3 Java server pages
Uma página JSP é uma página que possui uma estrutura fixa somada com
algum tipo de linguagem de marcação para incluir outro tipo de texto ou lógica
embarcada. Esta estrutura fixa normalmente é toda baseada em HTML. A linguagem
de marcação que tem como função gerar algum tipo de conteúdo dinâmico pode
apresentar-se das seguintes formas: scripts ou tags customizadas.
Páginas JSP podem especificar conteúdo dinâmico por qualquer meio textual,
mas elas são primeiramente utilizadas para criar conteúdo estruturado baseado em
HTML, XML, XHTML (eXtensible HyperText Markup Language). As páginas JSP
diferenciam-se dos servlet’s por seu modelo de programação.
2.3 A Camada de negócio
Em aplicações Java EE multicamadas, a camada de negócio especifica a
lógica de negócio e fornece serviços como a administração de transações, controle
de concorrência e segurança.
15
A tecnologia de componentes EJB fornece um modelo de componentes
distribuídos que habilita aos desenvolvedores concentrar-se na solução dos
problemas envolvendo regras de negócio e deixar que a plataforma administre os
serviços de baixo nível. Os componentes EJB são um link fundamental entre os
componentes da camada web e dados críticos de negócio armazenados na camada
de sistemas de informação e banco de dados. SINGH; STEARNS; JOHNSON (2002
p.129-75).
2.3.1 Lógica de negócio
Quando falamos de lógica de negócio, estamos nos referindo a uma porção
de procedimentos e métodos que são usados para administrar funções de negócio
específicas. O conceito de orientação a objetos nos habilita decompor todas estas
funções e métodos e distribuí-las entre vários componentes conhecidos como
objetos de negócio. Estes objetos devem atender aos seguintes requisitos:
- Manutenção de Estado
Objetos de negócio normalmente devem manter seu estado durante chamadas de
métodos (Persistência).
- Operar com dados compartilhados
Componentes devem fornecer controle de concorrência e níveis apropriados para o
isolamento do acesso aos dados compartilhados.
- Participação em transações
Uma transação poder ser definida como uma série de tarefas que precisam ser
completadas como uma unidade, ou seja, se caso uma das tarefas falhar, todas as
outras devem ser canceladas.
- Fornecer acesso remoto aos dados
Os clientes devem conseguir acessar os serviços fornecidos pelos componentes de
modo remoto - um objeto de negócio deve fornecer serviços genéricos ao cliente
como suporte a transações, segurança, acesso remoto, etc.
16
- Controle de Acesso
Os controles oferecidos por um objeto de negócio devem oferecer algum tipo de
serviço de autenticação, ou seja, um mecanismo que permita que certos usuários
tenham acesso a serviços protegidos.
- Reutilização
Os componentes de negócio devem ser reutilizados por componentes diferentes da
mesma aplicação ou de aplicações diferentes.
2.3.2 Componentes de negócio
Os componentes EJB facilitam o desenvolvimento uma vez que eles tratam
automaticamente a segurança, persistência, transação dentre outros serviços. Dessa
forma o desenvolvedor não precisa se preocupar com a implementação
programática desses serviços, a não ser que realmente deseje. Por ter essas
facilidades, rapidamente o EJB tornou-se um padrão para desenvolvimento de
aplicações corporativas distribuídas e multicamadas.Os componentes EJB não são
acessados diretamente pelo cliente, como ocorre em RMI. A aplicação cliente
requisita o acesso ao Container que por sua vez faz a chamada ao objeto EJB.O
gerenciamento do ciclo de vida do Bean, o controle transacional, pooling, dentre
outros aspectos são gerenciados pelo Container EJB.
A tecnologia EJB é, portanto, um modelo de componentes do lado servidor
(Figura 4) e por ser um modelo de componentes, ele deve seguir algumas regras
durante o seu desenvolvimento. Existem interfaces responsáveis por tarefas
definidas, regras de herança, dentre outros aspectos que devem ser seguidas
durante a implementação de componentes EJB.
17
Figura 4 – Acesso a componentes EJB
2.3.3 Tipos de componentes EJB
A especificação Enterprise Java Beans define três tipos de componentes:
- Session Beans
Os Session Beans são componentes de negócio. A lógica de negócio dos
componentes EJB encontram-se nestes componentes. Existem dois tipos de
Componentes Session Bean, o Stateless Session Bean e o Stateful Session Beans.
O Stateless é um componente de negócio que não mantém conversação com o
usuário, não há garantia que chamadas sucessivas de métodos remotos vão ser
feitas no mesmo objeto. O Stateful é um componente que mantêm estado, com ele
temos a garantia que chamadas sucessivas de métodos remotos feitas por um
mesmo cliente serão processadas por um mesmo objeto.
Os componentes EJB Session Beans usam um protocolo de invocação remota (RMI
ou RMI-IIOP) para receber solicitações de aplicações clientes. Esses protocolos
exigem uma comunicação síncrona e bloqueante, ou seja, o cliente deve ficar em
espera enquanto o servidor realiza o processamento e envia a resposta ao cliente.
- Entity Beans
Entity Beans são componentes que representam entidades de negócio, como
Cliente, Fornecedor, Gerente. Os dados das entidades se encontram em base de
dados, e os componentes são responsáveis por realizar o mapeamento entre
objetos de negócio e o banco de dados. Esses componentes facilitam o
desenvolvimento uma vez que eliminam a necessidade do programador desenvolver
código de persistência. O Container realiza a persistência e faz com que o
desenvolvedor se concentre na lógica de negócio.
- Message-Driven Beans
Message-Driven Beans são componentes ativados assíncronamente através de
mensagens JMS (Java Message Service). Os componentes Message-Driven Beans
18
escutam uma determinada fila de mensagens e realizam algum processamento
quando recebem algum dado da fila de mensagens.
O modelo de troca de mensagens funciona, simplificadamente, da seguinte forma: O
cliente envia mensagens para uma estrutura que as armazena. Os componentes
Message-Driven Beans processam conteúdos oriundos de uma fila de mensagens.
Quando uma mensagem é recebida o Container se encarrega de entregá-la ao
componente, que executa o código de negócio.
Vantagens do uso de Enterprise Java Beans em aplicações distribuídas
Invocação remota de métodos
Com a invocação remota de métodos podemos ter diversos clientes remotos nas
mais diversas localidades.
Load Balancing
Podemos ter diferentes servidores, e a cada chamada do cliente podemos balancear
a carga entre os diversos servidores disponíveis.
Fail-over
Quando um desses servidores der problema, devemos passar a chamar
automaticamente outro servidor transparentemente para o cliente.
Transações
O conceito de transação é muito importante para EJB. Com o conceito de
transações, é possível acessar diversas base de dados e executar uma série de
modificações, caso algum erro ocorra durante o processamento de alguma das
tarefas solicitadas todo o processo é cancelado e o sistema volta ao estado inicial.
Clustering
Para podermos ter tolerância à falhas, devemos replicar a aplicação entre os
diversos servidores.
Threading
19
O desenvolvedor de componentes EJB não precisa se preocupar com aspectos
multitheading da aplicação. Como tratar diversos clientes? Como evitar deadlock
entre as threads? Como sincronizar os objetos? Essas perguntas não devem ser
respondidas pelo desenvolvedor uma vez que o Container é responsável pelo
tratamento dessas questões.
Segurança
Pode-se definir a segurança de um componente EJB simplesmente por configuração
(segurança declarativa).
Caching
O servidor de aplicações faz caching de componentes de Entidade de forma a
otimizar o acesso ao banco de dados.
20
3. INTEGRAÇÃO COM DEMAIS SISTEMAS EXISTENTES
A integração com os demais sistemas existentes é um ponto importante a se
considerar dentro de uma aplicação distribuída. Estes sistemas normalmente podem
ser banco de dados relacionais, ERP’s, algum sistema de processamento de
transações de um mainframe e outros sistemas legados.
3.1 Tipos existentes de integração de sistemas
Dentro do conceito de integração de sistemas, podemos destacar três tipos de
integração:
-
Integração de aplicações
-
Integração de Dados
-
Integração de Sistemas Legados
Integração de Aplicações
Este tipo de integração consiste em integrar uma ou mais aplicações existentes de
modo que compartilhem informações.
Integração de Dados
Uma aplicação distribuída normalmente contém mais de um sistema de banco de
dados. Estes sistemas de banco de dados podem ser relacionais, orientados a
objetos, hierárquicos, baseados em fila, entre outros.
A integração de dados foca na integração dos dados já existentes, com as
aplicações distribuídas.
Integração legada
Integração legada envolve integrar novas aplicações distribuídas com aplicações ou
sistemas que já estão em operação há algum tempo.
21
3.2 Tecnologias de integração em um sistema Java EE
Para tentar solucionar os problemas de integração com sistemas legados, a
plataforma Java EE fornece as seguintes tecnologias para integração:
3.2.1 JCA
A JCA é a arquitetura padrão para a integração de produtos e aplicações Java
EE com sistemas heterogêneos. A JCA permite que fornecedores de sistemas de
informação forneçam um adaptador para cada um de seus sistemas. Devido a este
adaptador seguir a especificação da JCA, ele pode ser inserido em um servidor Java
EE de modo que forneça a infra-estrutura necessária para a integração com
qualquer sistema destes fornecedores. Um servidor Java EE, devido ao seu suporte
a arquitetura de conectores, pode conectar-se a múltiplos sistemas de informações.
O servidor Java EE e os adaptadores EIS contribuem para manter todos os
sistemas de baixo nível como controle de transações, segurança, administração de
conexões transparentes aos componentes da aplicação. Isto permite que o
desenvolvedor foque nos componentes de negócio e na lógica sem se preocupar
com os mecanismos de baixo nível que estão envolvidos em uma integração de
sistemas.
Através de contratos, a arquitetura de conectores estabelece padrões para
acesso a sistemas legados. A JCA define dois tipos de contratos (conforme nos
mostra a Figura 5): contratos de nível de sistema e de aplicação. Os contratos de
nível de sistema existem entre o servidor de aplicações Java EE e um adaptador. Já
os contratos de nível de aplicação existem entre um componente de uma aplicação e
o adaptador. Os contratos de nível de aplicação determinam a API de cliente que o
componente da aplicação utiliza para o acesso aos sistemas de informações.
SINGH; STEARNS; JOHNSON (2004, p.175-200)
22
Figura 5 – Arquitetura de Conectores
A arquitetura de conectores não necessita que um componente de aplicação
utilize uma API de cliente específica. A API do cliente pode ser uma CCI (Common
Client Interface), a qual é uma API para acesso a vários sistemas de informação
heterogêneos, ou pode ser uma API específica para um determinado tipo de
adaptador e ao sistema de informação que ele dá suporte.
Há vantagem em usar a CCI, principalmente porque os desenvolvedores
podem construir suas ferramentas voltadas para esta API.
Embora a CCI seja o alvo principal para os desenvolvedores de ferramentas e
para distribuidores de sistemas de informação, isto não desencoraja os fornecedores
a usarem as API’s JDBC. Um fornecedor de sistemas de informação normalmente
irá combinar JDBC com CCI usando a API JDBC para acessar banco de dados
relacionais e CCI para acessar sistemas legados
Os contratos de nível de sistema definem a interoperabilidade padrão entre
servidores de aplicação JAVA EE e sistemas legados. Desenvolvendo-se
componentes que consigam aderir a estes contratos, um servidor de aplicação e um
sistema legado sabem que se conectar é uma operação imediata de conectar-se a
um adaptador.
23
Os fornecedores de sistemas de informação ou adaptadores implementam
parte dos contratos de nível de sistema nos adaptadores, o qual é uma biblioteca de
sistema específica para cada sistema de informação.
Como exemplo de adaptador, podemos citar um que se conecta a um sistema
ERP, ou a um sistema de processamento de transações de um mainframe. Há
também uma interface entre o adaptador e seu sistema de informação. Esta
interface é específica para o sistema e ela pode ser uma interface nativa ou de
algum outro tipo.
A arquitetura de conectores não define esta interface e sim os
serviços que o servidor de aplicações Java EE deve fornecer. Estes serviços como
gerenciamento de transações, segurança e pool de conexões, são esboçados nos
três contratos de nível de sistema: Connection management contract, Transaction
management contract, Security contract os quais o servidor de aplicações deve
implementar.
3.2.2 JMS
A JMS (Java Message Service) é a API Java padrão definida para o sistema
de troca de mensagens em ambiente distribuído. Ela é uma API comum que pode
ser usada em diversos sistemas de troca de mensagens. Uma aplicação Java usa a
API JMS para se conectar a um sistema de troca de mensagens distribuída. Uma
vez conectado, a aplicação faz uso dos recursos fornecidos pela API para criar
mensagens e se comunicar com mais de uma aplicação.
Uma aplicação cliente, chamada cliente JMS, usa a API para acessar
mensagens assíncronas providas pelo sistema de mensagens.
3.2.3 JDBC
Os sistemas de gerenciamento de banco de dados relacionais são a formas mais
comuns de amazenamento de dados. Muitas aplicações utilizam a API JDBC para
acessar banco de dados relacionais para administrar a persistência de dados de
suas aplicações.
24
4.
ARQUITETURA
TECNOLÓGICA
INFORMAÇÃO EMPRESARIAIS
DOS
SISTEMAS
DE
As empresas hoje em dia estão sujeitas às várias forças internas e externas,
tais como: os clientes, fornecedores, parceiros, revendedores, acionistas, governos,
colaboradores. Estas forças condicionam e potenciam necessariamente o negócio
da empresa, a qual tem de saber responder adequadamente. Para satisfazer a
gestão da cadeia de produção ou de fornecimento, as empresas adotam sistemas
designados de ERP que dão suporte às áreas de produção, armazenamento,
distribuição e logística. Para satisfazer a gestão da cadeia de vendas, as empresas
adotam sistemas designados por CRM’s (custom relationship management) que
suportam as áreas de venda, pré e pós-venda, apoio ao cliente, apoio aos
vendedores, etc. Para satisfação dos requisitos internos da gestão dos
colaboradores, as empresas adotam sistemas clássicos de gestão de recursos
humanos, gestão de projetos, e gestão de competências. Por fim, para satisfação
dos requisitos dos acionistas, auditores financeiros e imposições fiscais, as
empresas adotam sistemas de gestão financeira e de contabilidade, gestão de
aplicações financeiras, etc. SILVA (2001, p.3)
Existem dois componentes fundamentais que permitem unificar e integrar
todo o conhecimento e os vários processos de negócio da empresa. São ele o KM
(knowledge
management),
responsável
por
captar,
manter
e
difundir
o
conhecimento; e o EAI (Enterprise Application Integration), responsável pela
integração dos vários sistemas de informação da empresa.
As organizações de sucesso são aquelas que conseguem de forma
sustentada e continuada manter e otimizar o seu negócio pela conjugação destes
diferentes sistemas de informação. Existem dois aspectos cruciais, que atualmente
começam a dar os primeiros passos. São eles:
- Integração interna:
Integração entre os vários sistemas de informação (entre o ERP e o CRM, entre o
ERP e o sistema financeiro)
25
- Integração externa:
Integração dos processos de negócio entre a organização e as outras entidades
envolvidas, quer sejam clientes, parceiros, fornecedores, ou outras.
4.1 Modelos atuais
Os processos de negócio entre empresas têm sido tradicionalmente
suportados pelos seguintes mecanismos ou tecnologias:
Interações telefônicas ou fax:
Caracterizadas por não apresentarem qualquer integração com os sistemas de
informação empresariais, pelo conseqüente consumo intensivo de recursos
humanos, e erros vários de inconsistência ou duplicação de informação.
Interações baseadas em EDI:
Caracterizadas por permitirem transações ponto-a-ponto entre sistemas de
informação de diferentes organizações, mas apresentando problemas ao nível dos
custos elevados de implementação e de manutenção; utilização de tecnologias
proprietárias e tecnicamente ultrapassadas.
Interações baseadas na Web (Web Services):
Caracterizadas por uma não integração estreita e automática entre os sistemas de
informação empresariais e correspondentemente, estes mecanismos devem ser
vistos como uma ligeira evolução relativamente às interações baseadas em telefone
e fax.
4.2 A Integração de sistemas através de Web Services
A integração entre sistemas desenvolvidos em plataformas heterogêneas de
hardware e software é uma necessidade crescente no mundo de desenvolvimento
de soluções e-business. As grandes empresas possuem inúmeros sistemas
construídos em diferentes combinações de plataforma ou linguagem. Do ponto de
vista financeiro, não é viável que esses sistemas sejam substituídos sempre que
26
novas tecnologias surgem no mercado, e sim que estas novas aplicações possam
interagir eficientemente com as existentes. Esse é um grande desafio que a
tecnologia em Web Services tem a vencer. SILVA (2001, p.4-12)
Web Services é uma nova onda tecnológica que traz consigo novos conceitos
e diversas promessas. Diferentemente das ondas passadas, o contexto tecnológico
nunca foi tão propício a mudanças, principalmente devido ao amadurecimento do
desenvolvimento de software componentizado e ao avanço da padronização de
soluções web. As primeiras iniciativas de utilização são no sentido de integrar
sistemas desenvolvidos em plataformas de hardware e software distintas. Esses
sistemas podem ser internos a uma empresa ou na fronteira de relacionamento entre
empresas parceiras.
Totalmente baseado em padrões abertos de grande aceitação no mercado,
independente de linguagem, de plataforma e de fornecedor, para o desenvolvimento,
existem duas grandes plataformas relacionadas à infra-estrutura: Java EE e .Net.
Fica a cargo de cada empresa escolher a que melhor se adequa a sua infraestrutura. A plataforma .Net é encampada pela Microsoft enquanto que a Java EE,
pelos demais fornecedores de tecnologia do mercado como BEA Systems, IBM,
Oracle, Sun e HP.
Um conjunto de novas tecnologias serve de base para a revolução que se anuncia,
destacando-se: XML, SOAP, WSDL (Web Services Description Language) e UDDI
(Universal Description, Discovery and Integration).
27
5. SUN JAVA EE X MICROSOFT.NET
Abaixo, segue uma comparação entre as duas plataformas: Microsoft .NET e
Sun Java EE. Porém, é necessário cautela quanto a qualquer comparação entre as
duas plataformas, pois, apesar de criadas para propósitos semelhantes, a plataforma
da Microsoft é uma plataforma relativamente nova, enquanto que a da Sun já está
no mercado há mais tempo.
Java EE é uma especificação para o desenvolvimento de aplicações
distribuídas. Existem mais de 50 fornecedores de ferramentas, servidores, etc. para
facilitar o desenvolvimento de milhares de classes, estruturas e tipos de dados. Entre
estes fornecedores incluem-se as grandes do mercado como IBM, BEA, Sun, Oracle
entre outras, que tem facilitado o desenvolvimento de aplicações e fornecendo
meios simplificados de acesso a dados através de JDBC, Java Connector
Architecture e suporte a XML e Web Services. SDS Consulting (http://www.sdsconsulting.com, Nov.2006)
Devido a isso, existe um grande número de pessoas envolvidas a dar suporte
e desenvolverem softwares para a especificação Java EE, cooperação e competição
nunca foram tão proveitosas. A cooperação é derivada da própria especificação e a
competição cresce com as organizações empenhadas em criar os melhores
produtos a preços mais acessíveis.
Já a plataforma. NET consiste em várias tecnologias que permitem o
desenvolvimento de sistemas distribuídos. Para este propósito, a Microsoft
incorporou o XML em quase todos os aspectos de comunicação e armazenamento
de dados. O acesso aos dados tem sido bastante simplificado através de um
mecanismo chamado ADO. NET, e eles criaram e aperfeiçoaram a programação
para web chamada ASP. NET. No .NET, componentes individuais podem ser
construídos utilizando-se diversas linguagens de programação. Fornecendo uma
série de funcionalidades comuns chamadas de CLS (Common Language
Specification) o.NET permite que estes componentes venham a funcionar bem
amanhã. Esta série de funcionalidades compreende mais de 6600 classes, tipos e
estruturas de dados. A CLS opera na Common Language Runtime (CLR), um
ambiente de execução similar à máquina Virtual Java.
28
A plataforma da Sun foi criada para facilitar o desenvolvimento e reduzir erros
em sistemas de software distribuídos. Ela foi criada tirando proveito de métodos de
engenharia de software como incorporar padrões de projeto diretamente nos
componentes pertencentes a plataforma.
Desenvolvedores são encorajados a desenvolver componentes de fácil
manutenção em Java. Estes componentes podem ser reutilizados em outras
aplicações uma vez que a Máquina Virtual Java facilita a portabilidade entre
plataformas. A plataforma Java EE é toda baseada na tecnologia Java e esta já
conhecida por sua escalabilidade, desempenho e baixo custo de manutenção.
.NET também foi criado para facilitar o desenvolvimento de software. Para este fim,
a API do Windows já está consolidada e muito mais fácil de usar.
.NET também incorporou tipos de dados unificados chamados Common Type
System (CTS), os quais ajudam o desenvolvimento onde múltiplas linguagens estão
envolvidas. Na Figura 6 podemos ter uma visão comparativa da estrutura das duas
plataformas. SDS Consulting (http://www.sds-consulting.com, Nov.2006)
Figura 6 – Comparativo Java EE e .NET
5.1 Segurança
É difícil comparar Java EE e.NET do ponto de vista da segurança. Ambas as
plataformas seguem os padrões X.509 e Kerberos. Porém, olhando mais de perto,
29
podemos considerar que o .NET é uma tecnologia relativamente nova se comparada
ao Java , o qual já vem sendo usado em ambiente distribuído a algum tempo.
Quanto à segurança, também devemos considerar as linguagens primárias de
cada plataforma: Java e C#. As duas linguagens foram criadas com a segurança em
mente, e ambas têm meios similares de focar o assunto, porém, não há diferenças
significativas. O C# é sempre compilado para código nativo ou uma linguagem
intermediária que será interpretada para código nativo antes da execução. Java é
interpretado para bytecodes através da Máquina Virtual Java.
A diferença mais significativa é que o .NET força a segurança através de um
sistema baseado em evidências que determina se um código é seguro ou não
baseado de onde ele veio. Java conta com o modelo de segurança sandbox
utilizando verificações de segurança em tempo de execução.
A última diferença a ser notada é de que a Sun encoraja os sistemas open
source e a especificação da Máquina Virtual Java é disponível já a Microsoft,
mantém os componentes da CLR fechados. Desta forma , podemos dizer que a Sun
tem segurança open source enquanto que a Microsoft tem segurança obscura.
5.2 Independência de fornecedor
A portabilidade é o aspecto mais atrativo na plataforma JAVA EE devido ao
grande número de fornecedores disponíveis. Atualmente, há cerca de 37
fornecedores JAVA EE licenciados e no mínimo 17 servidores de aplicação. Este
grande número de fornecedores permite que encontremos dentre eles aquele que
melhor se ajusta às necessidades por um preço competitivo. Devido a isso, ele
também nos dá a opção de negociação, pois mudar para um outro fornecedor é
sempre uma alternativa a ser estudada.
Atualmente, com o. NET, há somente uma opção de sistema operacional, o
Microsoft Windows, e você tem de pagar a quantia estipulada pela Microsoft para
obter as licenças requeridas
5.3 Interoperabilidade
30
Muitos dos sistemas distribuídos são construídos seguindo as tendências da
indústria em determinada época. Dois bons princípios a se considerar quando
sistemas serão usados por cinco ou dez anos são interoperabilidade e portabilidade.
Interoperabilidade consiste na habilidade de um sistema trabalhar com outros
sistemas. Devido a Microsoft ter incorporado o XML por todo o .NET, sistemas que já
usam o XML há 5 ou 10 anos podem agora trabalhar com sistemas .NET
desenvolvidos hoje. O Java EE também fornece interfaces XML similares às que são
usadas no .NET. Ele também fornece a arquitetura de conectores para uma
integração limpa com sistemas legados.
Portabilidade consiste em mover uma aplicação de um sistema operacional
para outro. Como as aplicações Java fazem uso da Java Virtual Machine , torna-se
possível migrar aplicações para sistemas diferentes sem a necessidade alterações
significativas.
O .NET encara a questão da portabilidade de um ponto de vista diferente. Em
vez de mover a aplicação de um sistema operacional para outro, .NET considera a
mudança de uma linguagem para outra. O recurso que habilita esta mudança é a
CLR
(Common
Language
a
Runtime),
qual
fornece
interoperabilidade
e
independência de linguagem. Similar à Máquina Virtual Java, a CLR fornece uma
camada de execução entre a linguagem de programação e o código nativo do
sistema operacional. Dessa forma, uma aplicação.NET pode ser constituída de uma
série de linguagens diferentes e no futuro, os desenvolvedores estarão aptos a
escolher sua linguagem de programação favorita se ela for suportada pelo.NET.
5.4 Web services
O foco de um Web Service é a Interoperabilidade. Um Web Service JAVA EE
deve estar apto a conversar com um Web Service .NET. Grandes empresas como a
Oracle, já estão fazendo testes de interoperabilidade com Web services .NET para
assegurar que os dois sistemas possam trabalhar em conjunto.
Quanto à implementação de um Web Service, ambas as plataformas dão
suporte a padrões de Web Services como: Simple Object Access Protocol (SOAP),
Web Services Description Language (WSDL), e Universal Description, Discovery,
and Integration (UDDI). Um Web Service é descrito utilizando –se a WSDL e enviado
31
como uma mensagem SOAP. Um consumidor pode obter informação sobre um
serviço via um registro UDDI. Uma vez que estes passos foram seguidos, o
consumidor pode usar o serviço da tecnologia que ele preferir - Java, C#, Perl, etc.
Sempre que um padrão para obter algum tipo de informação é seguido, o Web
Service responderá apropriadamente.
Este é um grande passo, porém, é uma tecnologia ainda nova e novos
padrões começarão a surgir.Microsoft e Sun com certeza estarão envolvidas nas
definições destes padrões, e o mais importante, suas plataformas terão que suportálos de alguma forma.
5.5 Maturidade
A maturidade de uma plataforma de desenvolvimento pode ter uma grande
influência no sucesso de um sistema. Maturidade traz estabilidade, um grupo de
desenvolvedores e uma base de conhecimentos sobre problemas comuns
associados à plataforma em questão.
O núcleo Java EE foi liberado em 1997. Quase dez anos se passaram e
vários sistemas distribuídos foram desenvolvidos, e mais de 50 organizações te
licença Java EE. Dessa forma, a arquitetura Java EE teve muito tempo para
amadurecer. Alem disso, muitos desenvolvedores tem documentado suas melhores
práticas na forma de padrões de projeto.
Apesar de tudo, o .NET é surpreendentemente robusto para uma plataforma
tão nova. Isto de deve ao fato de que muito do ambiente coorporativo da Microsoft
em utilização é baseado no .NET, e ele vêm sendo utilizado internamente ao longo
dos últimos anos. A Microsoft também forneceu uma versão beta de sua plataforma
durante 18 meses para ajudar a revelar aos desenvolvedores as exclusividades
associadas ao .NET.
5.6 Migração para futuras plataformas
Quando consideramos a mudança para uma outra plataforma, devemos
considerar o que acontecerá com os sistemas legados. Normalmente a plataforma
Java EE fornece uma boa quantidade de ferramentas definidas pela especificação
32
JCA para tratamento de sistemas legados. Através destas ferramentas, aplicações
Java EE podem comunicar-se com sistemas mais antigos.
.NET possui a CLR e a melhorada estrutura orientada a objetos do VB.NET que
muda drasticamente a maneira de desenvolvimento que havia no passado. Esta
mudança implica que qualquer mínimo trecho de código que tenha sido escrito em
versões mais antigas do Visual Basic terá que ser atualizadas no VB.NET.
Felizmente, existem ferramentas para auxiliar em todo o processo de transição.
5.7 Escalabilidade
Como sistemas se tornam mais aceitáveis e ganham mais usuários com o
passar do tempo, a infra-estrutura original pode não estar apta a suportar
crescimento. Java EE possui a tecnologia de load-balancing embutida. Dessa forma,
um cluster de máquinas pode colaborar administrando facilmente tanto a carga como
o número crescente de usuários do sistema.
Outro ponto interessante é que a arquitetura Java EE não é limitada a
plataforma, podemos ter uma máquina com Solaris, uma com Linux e outra com
Windows 2000 todas elas colaborando em um cluster.
.NET também foi desenvolvido com a escalabilidade em mente, porém nos deixa
amarrados à plataforma Windows.
5.8 Performance
Quando consideramos a arquitetura distribuída, dois lugares óbvios onde a
performance do sistema pode ser melhorada são com certeza o acesso aos dados e
a velocidade do programa. Tanto o Java EE quanto o .NET fornecem a habilidade de
manter processos de negócio alocados em memória e dessa forma reduzir o tráfego
no banco de dados, e dessa forma aumentar a performance de acesso aos dados.
Relacionando a velocidade dos programas, aplicações Java são geralmente
mais rápidas que suas equivalentes nativas. .NET também incorporou um otimizado
sistema de compilação em tempo real para produzir códigos que normalmente
rodam mais fácil do que as linguagens equivalentes
33
6. CONCLUSÃO
É fato a importância da utilização de padrões abertos no desenvolvimento de
aplicações tendo em vista as constantes mudanças e evoluções proporcionadas
pelas áreas de tecnologia e informática. A utilização destes padrões (destaque para
o XML) em conjunto com plataformas que os suportam, proporcionam um caminho
mais simples para o desenvolvimento de aplicações distribuídas complexas e
também na integração entre sistemas distintos. Entre estas plataformas, Java EE e
.NET destacam-se perante as demais alternativas do mercado.
É certo que as duas plataformas possuem propósitos semelhantes, porém, a
plataforma Java EE leva grande vantagem sobre a plataforma da Microsoft
principalmente pela sua maturidade e independência de fornecedor, porém uma
série de fatores devem ser levados em consideração antes de optar por uma ou
outra plataforma. A responsabilidade ficará a cargo de cada organização optar por
aquela plataforma que melhor se adequa à sua estrutura atual.
34
7. REFERÊNCIAS BIBLIOGRÁFICAS
Ball, Jennifer; Carson, Debbie Bode; Evans, Ian; Haase, Kim; Jendrock, Eric. The
Java EE 5 Tutorial, Sun MicroSystems, 2004
Microsoft. “What Is.NET?”.
[Internet http://www.microsoft.com/net/ recuperado em 03/11/2006]
SUN Microsystems. “JAVA EE Tutorial”.
[Internet http://java.sun.com/javaee/5/docs/tutorial/doc/ recuperado em 27/10/2006]
Stearns, Beth ; Johnson, Mark ; Singh, Inderjeet. Designing Enterprise
Applications. Addison Wesley, 2002
Silva, Alberto Rodrigues. Web Services: Próximos passos na globalização da
computação distribuída. 2002
[Internet http: //berlin.inescid.pt/alb/static/papers/2002/ e-portugal-2002-albertosilva.pdf recuperado em 04/11/2006]
SDS Consulting. “NET or J2EE? A Management Perspective”
[Internet http://www.sds-consulting.com/J2EE_NET_Manager.pdf recuperado em
29/11/2006]
35