Giuliano Bortolassi

Conversando sobre JEE parte 2

2008-08-11T10:41:00.000-07:00

Como falei no artigo anterior (Conversando sobre JEE) a plataforma JEE da Sun já tem 11 anos de desenvolvimento e evolução. Hoje ela é uma plataforma robusta com uma especificação bem elaborada e com várias empresas que usam e investem na sua manutenção e criam produtos baseados na tecnologia JEE, como por exemplo a ORACLE, IBM, BEA que tem seus servidores de aplicação JEE.

O porque dessas empresas adotarem e apoiarem a plataforma JEE, provavelmente, deve-se ao fato de estarmos falando de uma plataforma aberta e robusta, com preocupação principal na compatibilidade entre os servidores e aplicações e as aplicações desenvolvidas para eles. Essa postura de “manter a compatibilidade” entre os softwares desenvolvidos para JEE torna a plataforma uma escolha agradável e acessível para os gerentes de TI, já que, optando pela plataforma JEE eles não ficam amarrados com nenhum vendedor em específico.

No entanto, para que essa compatibilidade, e essa robustez da plataforma fosse alcançada, a Sun e o JCP tiveram, e ainda tem, diversos desafios a vencer. Um deles foi criar a especificação para implementação da plataforma, o que aconteceu na época do lançamento do JPE. De lá para cá a especificação da plataforma tem crescido juntamente com as tecnologias que ela vem agregando ao seu kit de ferramentas. Outro desafio era testar se todas as empresas que usavam a especificação JEE estavam realmente seguindo à risca o que foi especificado. Para isso a Sun lançou sua “implementação de referencia” e o “Kit de testes de compatibilidade” que podem ser usados para assegurar a compatibilidade de um produto com a plataforma JEE de maneira relativamente rápida e fácil. Outro trabalho desenvolvido não só pela Sun, mas por toda comunidade, foi a criação do J2EE Blueprints, que é um catálogo de “boas maneiras” (padrões de projeto) para o desenvolvimento de aplicações JEE.

Especificação JEE
A especificação JEE é um conjunto de documentos que explica como os servidores de aplicação e as implementações de algumas tecnologias (como JSF por exemplo) devem ser desenvolvidas por empresas que o queiram fazer. Essas especificações chegam a nível de “métodos”, ou seja, existem documentos e “interfaces” Java publica que os “implementadores de JEE” devem seguir para que seus produtos sejam considerados compatíveis com JEE.
Esses documentos podem ser encontrados no site da Sun, mais especificamente no seguinte link: http://java.sun.com/javaee/reference/

Implementação de referencia
A Sun, juntamente com as especificações libera as “implementações de referencia”, que são bibliotecas que “concretas” que implementam as interfaces documentadas. Podemos encontrar as implementações de referencia no site da Sun, no seguinte link: http://java.sun.com/javaee/technologies/. Cada tecnologia listada tem sua implementação e os manuais de como utilizá-las. O Glassfish, que é o servidor de aplicação de “referencia” da Sun já traz, no seu download, a maioria das implementações de referencia das demais tecnologias.

Kit de testes de compatibilidade (CTS e AVK)
O CTS (Compatibility Test Suit) é um conjunto de aplicações que servem para testar se um Servidor de Aplicação é compatível com a especificação JEE atual. Se o conjunto de testes for bem sucedido quando executado em um determinado servidor de aplicação, esse servidor pode receber o selo de “J2EE Compatível”, sendo assim, as aplicações que usam as bibliotecas JEE funcionarão perfeitamente nesses servidores.

O AVK (Application Verification Kit) é um kit de testes, semelhantes ao CTS, mas para ser executados nas aplicações. Esse kit garante que a aplicação não tem nenhum código específico, ou seja, nenhum código que fuja da especificação JEE, garantindo assim que a aplicação desenvolvida seja portável entre todos os servidores que passem no teste CTS.
Até a versão 1.4 (J2EE) do AVK, as aplicações que passavam nessa bateria de testes poderiam fazer parte do programa “Java Powered for the Enterprise brand”, mas a partir da versão 1.5 ou 5.0 (JEE) esse programa será descontinuado. Para mais informações acesse: http://java.sun.com/j2ee/verified/program.html

Para saber detalhes de como os testes funcionam, e para baixar os kits de testes, acessem o seguinte link: http://java.sun.com/j2ee/verified/avk_enterprise.html

J2EE Blueprints
O J2EE Blueprints é um catalogo de “padrões de projeto” para o uso com a plataforma J2EE. Os padrões de projeto (design patterns) são soluções para problemas comuns que foram testadas, e, verificando-se sua eficiência e possibilidade de reuso, catalogadas e tomadas como “boas maneiras” para se desenvolver softwares.

Existem diversos “padrões do projetos”, muitos desenvolvidos pelo GoF (Gang of Four), mas o J2EE Blueprints trata de um conjunto de padrões específicos para aplicações J2EE. Esse catálogo pode ser encontrado em (http://java.sun.com/reference/blueprints/) . Existe também a versão impressa, o livro chama: Core J2EE Patterns: Best Practices and Design Strategies, existindo também uma versão em portugês. Na minha opinião, qualquer um que queira trabalhar profissionalmente com JEE deveria conhecer os padrões do livro, e estar atento para utiliza-los no projeto que irá/está desenvolvendo.

Podemos notar que os desenvolvedores da plataforma JEE preocupam-se em fazer algo que siga o principal objetivo do Java: Escreva uma vez, use sempre! Ou seja, Portabilidade! Não a portabilidade entre sistemas operacionais ou entre dispositivos diferentes, mas acima disso, a portabilidade entre servidores e aplicações!!
Quais os benefícios disso?
Pensando como gerente de TI: Utilizando a plataforma JEE podemos criar aplicações que sejam portáveis entre diversos servidores, e que possam se comunicar com outras aplicações de forma padronizada, diminuindo drasticamente o “custo” no que se diz respeito a testes numa possível troca de ambiente (servidores, etc) ou em testes de integração entre aplicações. Temos uma plataforma aberta, sem medo de que derrepente um fabricante suba o preço ou pare de dar suporte a algum produto do qual dependemos. Na pior das hipóteses, temos toda a “receita” de como criar nosso próprio servidor de aplicação.
Pensando como Programador: Temos uma plataforma completamente documentada, sem perigo de encontrar “armadilhas”. Podemos escolher qual servidor usar para desenvolver sem deixar nosso ambiente pesado (optar por desenvolver em servidores lightweight no ambiente de desenvolvimento), podemos compartilhar componentes com pessoas da comunidade JEE sem se preocupar com compatibilidade nem ter que ficar explicando nos mínimos detalhes como nosso componente funciona já que todos estarão falando a mesma linguagem!

Na sequencia da conversa vamos ver como é a estrutura de uma aplicação JEE e vamos entrar em detalhes mais técnicos!

Abraços!

JEE, o que é Java EE

2008-08-01T12:27:00.000-07:00

Acho que uma das coisas mais chatas quando estamos desenvolvendo um sistema comercial de grande porte é termos que nos preocupar em escrever lógica de serviço de infra estrutura (Leia-se LOG, Conexão com Banco de dados, Cache, etc) e de nos preocupar com aspectos do desenvolvimento que são repetitivos e genéricos.

Esse tipo de preocupação, além de provavelmente não fazer parte do negócio para o qual estamos desenvolvendo o sistema, na maioria das vezes não agrega valor ao nosso sistema e é uma tarefa repetitiva ao longo do desenvolvimento, o que pode ser um esforço mal direcionado.
Pensando em resolver esses problemas, diversas empresas desenvolveram o que chamamos de Frameworks, que seriam “plataformas” de desenvolvimento que já implementam toda essa lógica repetitiva que não gostamos de implementar! Cada fabricante e cada Framework é focada em um determinado conjunto de regras de infra estrutura que resolve uma quantidade de detalhes de implementação.

Meu objetivo aqui é falar sobre a Plataforma Java Enterprise da Sun, que é um conjunto de especificação de frameworks que podem ser utilizadas juntas (ou não) para facilitar o desenvolvimento de nossos softwares coorporativos.

Especificação? Sim!

A Sun, em conjunto com o JCP (Java Community Process) desenvolve as especificações para a plataforma JEE (Java Enterprise Edition), e essa especificação é “aberta”, portanto qualquer empresa que se interesse pode desenvovler seus produtos (OpenSource ou não) seguindo essa especificação criada pelo JCP. Isso garante a portabilidade das aplicações desenvolvidas para a plataforma Java Enterprise. Então, você pode criar seu software de “locadora de videos” baseado em uma plataforma JEE e escolher de quem você vai comprar o servidor de aplicação, tendo a “certeza” de que sua aplicação vai ser portável entre os servidores.

Poxa, quer dizer então que a Sun não desenvolve a plataforma JEE?

Na verdade a Sun inventa a plataforma (em conjunto com o JCP) e atualmente ela tem liberado uma “implementação de referência” para cada especificação criada. Antigamente, quando a Sun lançou a JPE (Java Plataform for Enterprise, a predecessora da J2EE que é predecessora da JEE) em Abril de 1997, ela apenas produzia a especificação. No entanto, não existia uma maneira sólida de testar se os produtos criados por outros vendedores (ex. Oracle, BEA, etc) seguiam a especificação “à risca”.

Atualmente, quando sai uma especificação nova de alguma tecnologia que faz parte da JEE (discutirei essas tecnologias mais a fundo nos próximos posts) a Sun lança uma “implementação de referência”, que é um software implementando todas as funcionalidades que a especificação tras. Resumindo, se você desenvolver um software usando uma das tecnologias JEE e ele funcionar na implementação de referência, ele deve funcionar em um servidor comercial, se não funcionar é porque o vendedor daquele produto não está seguindo a especificação.
Outro problema que a JPE enfrentou foi a não sincronia das tecnologias especificadas.
Como assim?

Bom, a JPE inicialmente trazia a especificação para as seguintes tecnologias:
- EJB – Enterprise Java beans
- Servlet – Geradores de páginas HTML
- JNDI – Java Namming Directory
- (outras mais)

Imagine que, a equipe que desenvolveu a especificação do JNDI comece aprimorar essa especificação e criam um serviço de nomes muito mais estável e robusto, enquanto o pessoal que é responsável pelo EJB vai tirar ferias e esquece de pensar em melhorar a especificação. Qual seria o resultado? Teriamos uma especificação JNDI que poderia se tornar imcompatível com EJB. Uma outra plataforma que sofreu com problemas semelhantes foi a plataforma Eclipse. Antes do lançamento do projeto Europa, os plugins do eclipse evoluiam separadamente, e como existe muita dependência entre os plugins, eles acabavam se tornando imcompatíveis.

Atualmente, para cada distribuição do eclipse, é feito um controle dos plugins disponíveis para garantir essa compatibilidade e evitar muita dor de cabeça ao usuário. A Sun tomou essa mesma postura, e a partir da especificação J2EE já implementou um controle de versão e sincronia das tecnologias que fazem parte da plataforma Java Enterprise.

A plataforma JEE é uma plataforma que já tem 11 anos de história, e 11 anos de evolução contínua. Cabe lembrar que ela também não é proprietária, ou seja, não é a Sun que inventa as especificações ao seu “bel prazer”, existe um “consórcio” de empresas (o JCP) que decidem juntos as especificações, e disponibilizam essas especificações para quem quizer desenvolver.

Isso traz uma garantia para o desenvolvedor de que ele não vai ficar na “mão” de um único fabricante, nem amarrado a um software específico (ou seja, se o servidor de aplicação da oracle for muito caro, voce pode comprar o da RedHat, ou usar a “implementação de referência” da Sun, que é gratis e open source), o que pode ser uma grande vantagem para os “executivos” das empresas que escolhem adotar o Java como tecnologia de desenvolvimento. Para o Desenvolvedor a vantagem é enorme, já que ele tem uma plataforma padronizada e não precisa ficar se preocupando de quem a empresa vai comprar os servidores, além de ja poder usar um kit de ferramentas que implementam a maior parte da lógica de infra estrutura, ou seja, podem se focar apenas nos pontos importantes do software que estão desenvolvendo!

Nos próximos posts iniciarei uma discussão sobre a plataforma JEE atual, falando de uma maneira mais técnica sobre cada uma de suas tecnologias.

Abraços e até lá!
Giuliano Bortolassi

Configurando projeto Flex num Tomcat para acessar EJBs do JBoss

2008-07-24T16:16:00.000-07:00

Pretendo explicar nesse post como configurar a biblioteca do Ryannorris (http://www.ryannorris.com/) para acessar um servidor de aplicação em uma máquina virtual diferente daquela onde roda seu aplicativo Flex.

O cenário onde apliquei os passos descritos nesse post foi o seguinte:

Sistema Operacional: Mac Os X 10.4
Versão do Java: 1.5
Servidor de aplicação: Jboss 2.0GA (http://www.jboss.org/)
Servidor Web: Esse servidor roda o projeto em Flex + Lcds: Tomcat 6.0 (http://tomcat.apache.org/)

Considere que o projeto em Flex já está funcionando juntamente com o LCDs, e os objetos remotos já estão sendo consumidos pelas aplicações em MXML.

A partir do momento em que o meu projeto já estava configurado e integrado com o LCDs, o que precisei fazer foi o seguinte:

(Ah! Tambem estou supondo que já exista um Application Server com os EJBs configurados e rodando perfeitamente)

Passo 1 - Adicionei as bibliotecas de cliente do JBoss na pasta lib do WEB-INF do meu projeto flex. ( No Flex Builder 3 o path seria algo mais ou menos assim
<projetoflex_home>/WebContent/WEB-INF/lib )

Passo 2 - Adicionei a biblioteca do Ryannorris na mesma pasta lib (<projetoflex_home>/WebContent/WEB-INF/lib). No entanto, precisei modificar a biblioteca do Ryannorris para acessar meu sevidor. Veja mais a frente como fiz.

Passo 3 - Registrar o Factory no services-config.xml do Lcds. O diretorio desse arquivo é o seguinte: /WebContent/WEB-INF/flex/.
Para registrar o Factory precisamos colocar o seguinte trecho de codigo no final do documento:


<factories>
<factory id="ejbFactory" class="com.adobe.ac.ejb.EJB3Factory">
</factories>

Essa classe EJB3Factory faz parte do jar da biblioteca do Ryannorris(flex-ejb-factory.jar).

Passo 4 - Registrar seu EJB no remoting-config.xml ( o arquivo fica no mesmo diretório do services-config.xml)



<destination id="carrinhoCompraBean">
<properties>
     <factory>ejbFactory</factory>
     <source>nomeRemotoDoSeuEJB</source>
     <scope>application</scope>
</properties>
</destination>

O "nomeRemotoDoSeuEJB" é o nome usado para dar Lookup no objeto. Esse nome varia de servidor para servidor. No meu caso, usando o JBoss é algo mais ou menos assim: nomeProjeto/nomeClasseImplementacao/remote.
Ex:

myFlexEjbSample/CarrinhoBean/remote

Pronto. Isso é tudo que precisei configurar do lado do servidor. Iniciei o tomcat, e vi que ele startou corretamente, inclusive carregando o Factory especificado.

Agora vamos ao lado da aplicação MXML.

Na aplicação MXML precisamos apenas mapear mais um objeto remoto, como qualquer outro que já estejamos usando.

O código que usei foi o seguinte:


<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">
<mx:Script>
<![CDATA[
     import mx.controls.Alert;
     import mx.rpc.events.FaultEvent;
     import mx.rpc.events.ResultEvent;

     /* Listener para o sucesso do metodo */
     private function meuMetodoRemotoHandler(result:ResultEvent):void{
              Alert.show("Result: "+result," Executou Metodo remoto ");
     }
     /* Listener para o erro do metodo */
     private function meuMetodoRemotoErrorHandler(fault:FaultEvent):void{
              Alert.show("Fault: "+fault," Erro ao executar metodo remoto ");
     }
]]>
</mx:Script>

<mx:RemoteObject id="meuEjb" destination="carrinhoCompraBean">
    <mx:method name="meuMetodoRemoto"     result="meuMetodoRemotoHandler(event)" fault="meuMetodoRemotoErrorHandler(event)"/>
</mx:RemoteObject>
 <mx:Button click="meuEjb.meuMetodoremoto()" label="Executar"  x="250" y="218"/>

</mx:Application>

Na teoria é somente isso que precisamos. Se o seu serivor de aplicação e o servidor onde roda o LCDS forem o mesmo, provavelmente isso funciona. Como expliquei no inicio do post, o ambiente em que desenvolvo é diferente. O servidor de aplicação é em uma maquina, o meu servidor onde roda o LCDs é em outra... simplesmente o Factory não vai encontrar o meu EJB.

Por padrão, quando vamos desenvolver um cliente para um EJB, em outra máquina virtual, e em uma máquina com outro IP, precisamos adicionar um arquivo jndi.properties na pasta "src" do nosso projeto com as informacões para que nosso "initial context" encontre nosso servidor de aplicação. Eu tentei fazer isso. Adicionei esse arquivo na pasta source (que quando exportado vai para a pasta "/WEB-INF/classes" do projeto. Não funcionou. A Factory ainda não encontrava o servidor de aplicação.
Testei colocar o arquivo jndi.properties em outros diretórios, mas também não tive sucesso. Parti para o plano B, alterar os fontes do nosso amigo Ryannorris. ( a biblioteca ja vem com os fonts configurados para trabalhar no eclipse!! Uma mão na roda!)

Joguei a pasta dos fontes em um projeto novo no eclipse e dei uma bisbilhotada! Poxa.. como é simples fazer essa tal de Factory! Achei fantástico o trabalho do Ryannorris!

A idéia da Factory é a seguinte: Extender uma interface do LCDS (flex.messaging.FlexFactory) e implementar os métodos para criar seus objetos. No nosso caso, fazer o lookup dos EJBs. Como não poderia deixar de ser, em algum lugar vamos ter que criar nosso InitialContext e fazer o "lookup" do ejb. Fui na veia procurando já essa instanciação do Initial context. Isso acontece na classe "com.adobe.ac.ejb.LocalJNDIResourceLocator" da biblioteca do Ryannorris. Bom, como não consegui externalizar os parametros, criei um HashMap com eles e passei no construtor do InitialContext. Sei que isso é "feio" de se fazer, porque torna a implementação totalmente acoplada, não fica nada genérico. Toda vez que eu mudar meu servidor de aplicação de IP terei que alterar essa biblioteca. Uma alternativa imbutir o codigo do Ryannorris no meu projeto, mas não pretendo fazer isso. Por enquanto deixarei o código fixo, simplemente para fazer funcionar o lookup. Futuramente me preocuparei em externalizar essas configurações.

Vamos ao código. O que adicionei foram as seguintes linhas no método "locate" da classe do Ryannorris:

Hashtable hashParametros = new Hashtable();
hashParametros.put("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");
hashParametros.put("java.naming.provider.url", "jnp://10.0.0.22:1099");
final Context ctx = new InitialContext(hashParametros);

O código completo do método ficou da seguinte maneira:

public Object locate(final String name ) throws ResourceException {
try {
Hashtable hashParametros = new Hashtable();
hashParametros.put("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");
hashParametros.put("java.naming.provider.url", "jnp://localhost:1099");
final Context ctx = new InitialContext(hashParametros);
final Object res = ctx.lookup( name );
return res;
} catch ( NamingException e ) {
// tratamento da exception
}
}

Percebam que a única coisa que mudei foram realmente os parametros. Esses são os parametros que ficariam dentro do jndi.properties

E.. Voila! Funcionou!

Executei a aplicação flex e meu método remoto funcionou perfeitamente, invocando oEJB no outro servidor corretamente!

Se alguém tem uma solução simples e mais inteligente que a minha (heheh coisa que não é dificil) ou sabe onde colocar o arquivo jndi.porpeties para trabalhar com a biblioteca do Ryannorris, por favor me diga!

Bom, é isso ai, acho que fazer funcionar o EJB não foi tão dificil. Agora quero ver é usar o EJB de uma forma eficiente no projeto! é meu próximo desafio!

Flex3 + Lcds + EJB3

2008-07-24T15:42:00.000-07:00

Recentemente terminei um curso de EJB3 (FJ-31) na Caelum. Curso muito bom, diga-se de passagem e tirei um peso de minhas costas: Aprender a usar efetivamente o tal do EJB.

A um tempo atraz eu tinha iniciado um blog somente para falar sobre tecnologia JEE e para me motivar a estudar o ejb (http://jeenoob.blogspot.com) mas acabei desistindo quando não consegui fazer o lookup e regigir corretamente os arquivos de deploy para o servidor Glassfish. No entanto agora, que aprendi como fazer o tal do EJB funcionar comecei a correr atraz de como usar ele nos meus projetos.

Hoje trabalho como arquiteto/gerente de produção em um projeto que usa as tecnologias Flex, Java e Microsoft SqlServer. Tirando o SQLServer a plataforma é bem produtiva e o Flex3 vem superando minhas expectativas no que diz respeito a produtividade.

Devido a alguns objetivos do lider do projeto, estou prevendo que vamos precisar se esforçar mais em relação a "robustes" da aplicação. Procurei então como mesclar o Flex, o Java e o EJB que poderia ser uma solução para um problema futuro.

Encontrei referências para o blog do Raynnorris ( http://www.ryannorris.com/ ) que desenvolveu uma Factory para o Lcds que consegue instanciar e fornecer EJBs de forma transparente para os aplicativos Flex. Achei a idéia fabulosa e fui testar.

O post do Raynnorris que explica como usar a biblioteca que ele criou é o seguinte: http://www.ryannorris.com/2007/05/18/using-flex-data-services-with-ejb3/

O post é bastante claro em relação a como configurar o LCDs para usar a Factory que ele criou, e explica muito bem como editar os XMLs do flex.

Simples, pratico e rápido.

No meu caso especifico tive que fazer algumas alterações nos fontes do Ray para que a Factory encontrasse meu servidor de aplicação.

Explico o que fiz para usar a biblioteca dele no post:
Configurando projeto Flex num Tomcat para acessar EJB3 no JBoss

Agora resta a dúvida... como será que o LCDs se comporta com uma grande quantidade de requisições??

O próximo passo vai ser fazer um "stress test" no meu aplicativo... simular as requisições e ver se o LCDs não vai gerar gargalo.

De nada adianta ter uma servidor robusto e uma arquitetura extremamente boa no servidor de aplicação se o servidor web não der conta do recado.

Um outro teste que estou agendando é fazer o LCDs rodar no próprio JBoss (hoje ele roda em um Tomcat 6.0).

Vamos ver no que dá!

Perfil

2008-06-05T06:29:00.001-07:00

Perfil de Giuliano

Projetos Ativos

2008-06-05T06:28:00.002-07:00

Como todos desenvolvedores, acabamos nos metendo em encrencas por ai (leia-se projetos), e eu também me envolvi em algumas. Algumas eu mesmo criei, como as duas abaixo:

- Tentativa de um servidor genérico para jogos

Link Direto: https://sourceforge.net/projects/mmooog/

- Aplicativo Java para edição de stored procedures no SQL Server 2005

Link Direto: https://sourceforge.net/projects/jprocbuildersql

Também acabei fazendo parte de outros projetos durante meu tempo de trabalho:

Sistema de BI de uma empresa da área editorial
Sistema de PDV-Mobile
Sistemas B2B
Sistemas de Ensino a Distância
Sistema de Gestão Acadêmica

Cada uma das encrencas me trouxe lições. Espero que sejam úteis para vocês!

2008-06-05T06:28:00.001-07:00

Posts Recentes

Conversando sobre JEE parte 2: Continuação da discussão sobre JEE. Como a Sun venceu os desafios de manter a portabilidade e assegurar que os produtores de aplicativos JEE seguissem o padrão?

Conversando sobre JEE: Inicio de uma discussão sobre a plataforma JEE. Por que usá-la, quais as vantagens.

Configurando Projeto Flex para consumir EJBs: Veja como foi simples configurar a biblioteca do Raynorris para fazer sua aplicação flex consumir EJBs do JBoss!!

Sessões

Java Enterprise: Discussão sobre tecnologia Java para projetos coorporativos. Arquitetura de software, soluções conhecidas, frameworks e problemas comuns desenvolver aplicações no mundo coorporativo

Projetos: Compartilhamento de experiências dos projetos passados e dos atuais. Lições que aprendemos no dia a dia, quebrando a cara ou acertando na mosca! Veja os abacaxis descascados e as pisadas na bola.

Perfil: Dados sobre mim. Portifólio, curriculum e informações pessoais.

Java Enterprise Edition

2008-06-05T06:19:00.000-07:00

Posts sobre JEE

Flex + LCDS + EJB3 - Integrando seu projeto Flex com a tecnologia EJB!

Configurando um Projeto FLEX no Tomcat para acessar EJB3 do JBoss - Acho que o título do post já diz tudo.