Daniel Berti Fonseca RA º semestre INTEGRAÇÃO DE SISTEMAS CORPORATIVOS COMPLEXOS COM JAVA EE

Transcrição

1 Daniel Berti Fonseca RA º semestre INTEGRAÇÃO DE SISTEMAS CORPORATIVOS COMPLEXOS COM JAVA EE Jaguariúna 2006

2 Daniel Berti Fonseca RA º 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 para conclusão do curso de graduação. Jaguariúna

3 FONSECA, Daniel Berti. Integração de Sistemas Corporativos Complexos com Java EE 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

4 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

5 LISTA DE FIGURAS Figura 1 - Modelo de Divisão em Camadas Figura 2 - Java EE Containeres Figura 3 - Interações da camada web Figura 4 - Acesso a componentes EJB Figura 5 - Arquitetura de Conectores Figura 6 - Comparativo Java EE e.net

6 SUMÁRIO RESUMO LISTA DE SIGLAS LISTA DE FIGURAS INTRODUÇÃO ARQUITETURA JAVA EE Containeres Java EE A Camada web Tecnologias envolvidas Java servlets Java server pages A Camada de negócio Lógica de negócio Componentes de negócio Tipos de componentes EJB INTEGRAÇÃO COM DEMAIS SISTEMAS EXISTENTES Tipos existentes de integração de sistemas Tecnologias de integração em um sistema Java EE JCA JMS JDBC ARQUITETURA TECNOLÓGICA DOS SISTEMAS DE INFORMAÇÃO EMPRESARIAIS Modelos atuais A Integração de sistemas através de Web Services SUN JAVA EE X MICROSOFT.NET Segurança Independência de fornecedor Interoperabilidade Web services Maturidade Migração para futuras plataformas

7 5.7 Escalabilidade Performance CONCLUSÃO REFERENCIAS BIBLIOGRÁFICAS

8 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

9 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

10 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

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

12 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

13 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 ( 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

14 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

15 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 ( 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) Tecnologias envolvidas 14

16 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 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 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

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

18 - 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 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

19 Figura 4 Acesso a componentes EJB 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

20 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

21 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

22 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

23 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: 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 ) 22

24 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

25 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 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 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

26 4. ARQUITETURA TECNOLÓGICA DOS SISTEMAS DE INFORMAÇÃO EMPRESARIAIS 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

27 - 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

28 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

29 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 ( 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

30 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 ( 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

31 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

32 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 Runtime), a 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

33 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 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

34 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