Devo usar JBoss?

Olá

Retire todo e qualquer código de acesso à base de dados da sua aplicação cliente Swing. Crie um pequeno servlet que receba as solicitações do cliente swing para acesso à base de dados e que responda com o resultado do comando SQL. Para troca de mensagens entre o swing e o servlet use URLConnection (ou HttpClient). O servlezinho que acessa à base de dados no servidor por ser instalado no tomcat ou no jetty. Não precisa do JBoss só para isto.

[]s
Luca

Algumas dicas para complementar o post anterior:

. Para a comunicação entre o cliente SWING e o servlet, use um protocolo padrão. Existem vários: SOAP, XML-RPC, JSON, etc. Só não invente mais um !

. No processo de migração, o mais provável é que vc. acabe construindo façades com os métodos de negócio utilizados pelo cliente. Dependendo de como eles existem hoje, pode ser interessante utilizar Statefull Session Beans para a implementação destas façades.

. De modo geral, eu prefiro usar o JBoss como plataforma de produção em vez do Tomcat stand-alone, mesmo quando não existem EJBs nem nada do gênero. Considero que ele agrega facilidades de integração e monitoração que evitam a proliferação de “puxadinhos” na forma de scripts de crontab, servlets “autoexec” e assemelhados, sem, no entanto, exigir demais em termos de treinamento e manutenção como um WebSphere ou BEA.

Olá

Desculpe-me por discordar.

Minha sugestão era para comunicar Java no cliente com Java no servlet. A regra básica para construir as mensagens POST com HttpClient em sistemas com desempenho aceitável é KISS. Portanto jamais use SOAP ou outro protocolo qualquer desenvolvido para interoperabilidade para comunicar 2 lados iguais. Principalmente para fazer uma camada de apresentação de um sisteminha CRUD.

E sobre SFSB eu não sou contra seu uso desde que realmente seja necessário manter o estado (session) em ambientes distribuídos pois pior do que SFSB é SLSB + singletons. Mas não consigo imaginar como refatorar um sistema que usava JDBC na camada de apresentação para ir direto para um ambiente distribuído que só tem serventia em pouquíssimos casos.

[]s
Luca

Não tem do que se desculpar. Eu tb vou discordar e não vou pedir desculpas por isso ;^)

Sem dúvida SOAP é overkill, mas atende ao KISS no quesito “fácil de implementar com as ferramentas existentes”. Montar os dados do POST é tb. é simples, mas vc. tem que implementar classes para serializar/desserializar os dados de um lado e de outro. Pesando estes fatores, ainda mantenho minha posição de usar um protocolo padrão. Minha preferência, neste caso, seria pelo XML-RPC, muito menos “verbose” que o SOAP e com mapeamento automático no lado servidor para métodos de uma classe java convencional - e vc. ainda ganha visibilidade dos dados que passam “no fio” usando qualquer Ethereal da vida.

Um dos pouquissimos casos em que faz algum sentido usar SFSB é justamente quando o front-end é um cliente SWING. Por exemplo, se a interface usa tabelas (típico de CRUDs), a implementação do TableModel correspondente fica mais simples se for utilizado este recurso, com a vantagem de se poder utilizar cursores no lado do servidor para avançar/retroceder no resultset. Como benefício grátis, esta abordagem permite uma implementação da comunicação usando RMI sobre HTTP(S) (ao menos no JBoss), tornando irrelevante a discussão sobre o protocolo.

Olá

Faltou você acrescentar “caso os requisitos do SLA permitam”

Minha experiência com isto é que o throughput fica sofrível. Como já trabalhei com sistemas obrigados por contrato a responder mais transações do que a realidade permitia, continuo achando que as mensagens devem ser as mais simples possíveis. Nem sempre vale economizar tempo de desenvolvimeento achando que colocando mais hardware o sistema acabará sendo usável. Já vi coisas feitas com boa intenção indo para o lixo por falta de desempenho aceitável. E uma das vezes foi justamente quando se enviava classes serializadas nas mensagens ao invés de apenas os campos.

[]s
Luca

Mandar or campos e tratar a resposta correspondem à serialização/desserialização a que me refiro, e que é inevitável. Usei o termo no sentido amplo e não querendo significar “serialização de objetos usando a api do java”.

Quanto a ficar sofrível, cada caso é um caso, e é por isto que existem vários padrões de mensageria. Um dos mais compactos que conheço é o ISO-8583, que, inclusive, possui uma versão XML, mas eu não o utilizaria antes de passar por uma rodada de otimizações em outros pontos do código - mas acho que já estou divagando do tópico.

Olá

Agora entendi e você tem razão.

Sobre serialização Java há casos recomendáveis: é quando o sistema é todo baseado em tabelas, isto é, se a maioria do tráfego de mensagens é composto de ArrayLists para preencher tabelas. Mas eu não imaginei um sistema assim.

Sobre os padrões de mensagens que é um dos meus interesses. Um dos grandes problemas destes padrões é que justamente seu uso não é padronizado. Assim há o EDIFACT de fulano, o ISO-8583 de Redecard e assim por diante. Esta confusão é um dos motivos de se buscar soluções com SOA/EDA.

Uma pergunta: você tem experiência com o JPOS?

O que usou para converter o ISO para XML? Desenvolveu na raça? Usou um produto comercial?

[]s
Luca

Os quais, IMHO, so aumentam a confusão, ainda mais pela visão que se tenta passar de que sistemas díspares vão cooperar apenas por usarem SOA, mas este é assunto para outro thread…

Já usei bastante, mas só a parte de empacotamento/desempacotamento. Existem bancos no Brasil em que toda a mensageria da camada web para o host utiliza este pacote.

O JPoss possui o conceito de Packagers, que fazem a etapa final de conversão dos “bits” em uma mensagem pronta para ser transmitida. Existe um packager que suporta XML, mas não cheguei a utilizá-lo.

O cenário em que usei XML + ISO foi um pouco diferente. Utilizei o XML-RPC (não confundir com o SOAP XML-RPC, veja em http://www.xmlrpc.com !) para fazer uma transação com o host já mandando a mensagem ISO formatada a partir do cliente. A mensagem ISO era um dos argumentos da chamada e usei o JPos do lado do servidor para tratamento dos bits. O lado cliente usava C/C++ e usei um dos bindings disponíveis para esta linguagem

Legal…

Não sabia que dava para usar Servlets com Swing. Sempre pensei que Servlets eram apenas para aplicações web…

Ainda estou meio confuso sobre o que usar… Acho que vou tentar usar servlets, porque parece mais fácil. Vocês falaram umas coisas aí que eu nem sei direito o que é hehehe…

Valeu.

Java Player,

outra solução mais simples é vc definir seus usuários no BD. A senha para acesso ao sistema é a mesma utilizada na conexão com o banco, de maneira que ela não fica gravada em qualquer .class. Obviamente, o acesso precisa ser configurado caso-a-caso de maneira que o banco só permita que o usuário realize as funções de sua alçada.

Dei uma pesquisada a respeito de XML-RPC e SOAP, mas fiquei em dúvida se é mesmo a melhor solução para meu caso.

Posso dizer que meu sistema é em parte um CRUD, usando JTable no cliente para popular dados que ele vai requisitar através do servlet.

Para a comunicação entre o cliente Swing e o servlet no servidor, eu pensei em usar XML usando uma API XML como o XStream.

O servlet no servidor faz uma busca no banco de dados, e gera um ArrayList com esses dados. Depois ele pega esse ArrayList, e faz a serialização usando a API XML XStream. Em seguida envia esse arquivo XML para o cliente, como resposta à requisição.

Esse arquivo XML seria algo do tipo:

<List>

   <Cliente>
      <nome>João da Silva</nome>
      <email>[email removido]</email>
      <foneComercial class="Telefone">
         <ddd>55</ddd>
         <numero>5555 5555</numero>
      </foneComercial>
   </Cliente>

   <Cliente>
      <nome>Manuel Fernandes</nome>
      <email>[email removido]</email>
      <foneComercial class="Telefone">
         <ddd>55</ddd>
         <numero>3333 3333</numero>
      </foneComercial>
   </Cliente>

</List>

Daí o cliente Swing vai pegar esse XML e desserializar, gerando um ArrayList de volta.

No meu código no servidor eu tenho vários metodos do tipo:

public List<Cliente> getClientes();

public List<Produto> getProdutos();

public List<Produto> getProdutosCategoria(int categoria);

Daí eu pensei em criar uma servlet para cada um desses métodos.

Tipo, eu iria criar as classes: ServletGetClientes, ServletGetProdutos, ServletGetProdutosCategoria, etc…

Essa é a solução mais simples que eu consegui enxergar para o meu caso.

O que vocês acham? Gostaria da opinião de você que já mexeram com essas coisas.

Obrigado.