| Autor |
Mensagem |
|
|
Alessandro Lazarotti wrote:O seu maior furo, é "acesso por RMI".
Dependendo da quantidade de chamadas remotas será um gargalo. É "tão complicado" assim importar os jars e as configurações que "já" estão funcionando? Não estou conseguindo achar o problema em fazer isso.
Quero evitar importar para não começar a bagunçar o classpath. Algum tempo atrás, por exemplo, tentei atualizar a versão do hibernate do legado, passando da versão 3.x para a versão 3.x+1, deu maior problema e algumas coisas deixaram de funcionar, se a memória não me falha foi algo relacionado ao cache. Não foi tão complicado ajeitar para um componente, mas como todos compartilhavam do mesmo classpath em tempo de execução, seria um esforço muito grande e acabei tendo que voltar atrás, principalmente pq o legado não possui qualquer tipo de teste automatizado. Daí pensei isolar todos esses componentes em serviços, ao invés de importar para dentro da minha aplicação.
Também não sei as consequências de se ter dois containners (spring e ejb) rodando na mesma aplicação.
Mas de qualquer forma vou fazer protótipos com sua sugestão e averiguar as escolhas depois de ter implementado algo.
Em tempo, JEE6 acabou sendo nossa principal aposta (ainda temos que fazer alguns spikes). Tivemos muitas dores de cabeça pra colocar o Seam rodando no Glassfish e depois vimos que não valia a pena. Conseguimos uma janela de tempo maior e resolvemos investigar o JEE 6.
|
 |
|
|
Mas para isso eu teria que importar toda a tralha antiga para dentro dos projetos novos (opção 2) e estava querendo evitar fazer isso.
Como não encontrei nenhum furo, pelo menos não conceitualmente, meu primeiro teste vai ser o acesso por RMI.
|
|
|
|
então vc não precisa migrar. Vc precisa fazer o sistema do zero usando tecnologias diferentes. Mas amarrar-se ao JBoss Seams é pura asneira.
Vc vai sair da frigideira para cair no fogo.
Eu não vou migrar nada. O que está feito no framework caseiro vai continuar nele. Somente as coisas novas é que vão ser feitas em uma nova plataforma. E como o framework está muito ruim, amarrado e muito difícil de evoluir é melhor, para as coisas novas, abandaná-lo de vez. Não vejo motivo para continuar fazendo sistemas novos em um framework legado.
|
|
|
|
garcia-jj wrote:Esse seu framework caseiro faz o que? Envolve regras de negócio ou é apenas um controller web?
Ele envolve tudo, desde a persistência até a camada de apresentação.
|
|
|
|
Tentar usar EJB é péssima ideia. Vc já tem uma estrutura em spring, vc não precisa de ejb. Spring roda tranquilo em JEE, sem EJB.
A nossa estrutura com Spring está bem precária e totalmente legada. Fizemos uma avaliação e decidimos usar EJB e JBoss Seam nas aplicações novas. Esta decisão até pode ser revista, mas não quero transformar a thread em uma discussão EJB vs Spring e sim como integrar meu legado com a nova plataforma.
A forma mais limpa é tirar a dependencia do spring dos seus POJO e usá-los puros no EJB.
O legado não depende somente do Spring. Tem o framework caseiro e legado e importar esse componente para dentro do projeto significaria trazer muito lixo. Muitos JARs que estão no classpath não sei nem pq estão sendo usados e mudar a versão de qualquer coisa (do hibernate, por exemplo) sempre é um suplício. Por isso não acho muito legal a alternativa 2
|
|
|
|
garcia-jj wrote:
Porém creio que isso só funcione se você tem o contexto do spring como local. Nunca usei, apenas lí sobre isso nos docs do Spring. Uma solução caso você tenha os EJBs e contexto do Spring em local separado é você usar via webservice como você citou, porém haverá um overhead de fazer o malshal e unmarshal.
Abraços
É, os exemplos que vi foran com contexto local mesmo, o que não é meu caso. De qualquer forma vou investigar mais um pouco. Sobre o overhead do marshal e unmarshal, além do possível gargalo que isso pode ocasionar, eu ainda teria que fazer o mapeamento entidade-xml, que mesmo com JAXB, ou solução parecida, pode dar muito trabalho para se chegar a um schema legal. Minhas entidades são bem complexas.
|
|
|
|
Oi pessoal,
Estamos mudando nossa plataforma de desenvolvimento de Spring + framework caseiro para JEE (ainda não sabemos se será o 5 ou 6). As aplicações existentes não serão migradas, mas vários componentes (implementados com Spring), que são utilizados por várias aplicações, terão que ser acessados nesta nova plataforma. Estamos pensando em como seria este acesso e algumas alternativas seriam:
1. Duplicar o código dos componentes, deixando quieto o que está em Spring e implementando tudo novamente em EJB. No curtíssimo prazo isso seria o mais rápido, mas é fácil descartar esta alternativa já que código duplicado somente em ultimo caso.
2. Importar todo o código (através de JARs) dos componentes para dentro da aplicação e acessar localmente. Isso até que seria simples, mas junto com os JARs dos componentes eu teria que trazer toda a tralha de dependências junto, incluindo Spring e o framework caseiro.
3. Expor os componentes como web-services SOAP. Essa abordagem teria a grande vantagem de deixar o serviço independente de plataforma, mas, por mais que seja fácil expor um pojo como web-service, daria muito trabalho mapear as entidades trocadas em um xml schema, mesmo usando JAXB ou algo similar. As entidades são bem complexas e se contentar com o mapeamento default do JAXB não ficaria legal.
4. Expor os componentes como web-services rest. Teria a vantagem de economizar muito em mapeamento, mas transformar a api dos componentes para seguir uma linha restful exigiria uma reimplementação muito grande.
5. Implementar um componente EJB de fachada, que importaria cada componentes (pelo JAR) localmente e exporia o serviço de maneira transparente. Esse EJB de fachada seria então acessado remotamente pelas aplicações da nova plataforma. Seria um saco implementar um componente só para esse intercâmbio mas como seria só uma fachada, não teria muito código. O Spring tem inclusive uma forma, pelo SpringBeanAutowiringInterceptor, de injetar beans Spring em EJBs
6. Expor os beans Spring por RMI, usando o RmiProxyFactoryBean, e importá-lo nos EJBs com @Resource. Esta acho que seria a melhor alternativa, mas nunca fiz e nem vi nada parecido.
Alguém já precisou fazer algo parecido e teria alguma dica?
valeu!
Fabrício Lemos
|
|
|
|
|
|