Sugestão de Substituição de Tecnologia em uma Arquitetura
11 respostas
M
marceloplis
Pessoal, tem-se um sistema financeiro grande e modularizado, com muito acesso concorrente, desenvolvido com a seguinte arquitetura:
WebLogic Portal (PageFlow e Beehive) - Portlets Federados
|
Barramento de Serviços JBoss
|
Servidor de Serviços
|
Servidor de Banco de Dados
Desejando migrar a parte de Portal, pelo alto custo de valor de manutenção e desempenho e com impacto na produtividade, qual seria a melhor opção na opnião de cada um interessado no assunto aqui no GUJ? e o por quê?
P.S. Lembrando que as regras de negócios estão no Barramento de Serviços
[list]
| Alfresco - GED
| Workflow - jBPM -
JBoss Portal (PageFlow e Beehive) - Portlets Federados
|
JBoss ESB
|
Servidor de Banco de Dados
[/list]
Desejando migrar a parte de Portal, pelo alto custo de valor de manutenção e desempenho e com impacto na produtividade, qual seria a melhor opção na opnião de cada um interessado no assunto aqui no GUJ? e o por quê?
Acho que falta especificar muita coisa, pois fica dificil discutir mais a fundo para que e por quem é usada essa arquitetura.Soluções e “Arquitetos” é que não falta.
Isso é similar ao Call Center com 600 posições mais cada site tem somente 40 - posições de atendimento p/cliente sendo gerenciada de forma independente. Então não existe gargalo e sim administração de recursos do Back-Office.
Acho que seu foco é usar jBoss .
.
sds[].
M
marceloplis
WilliamSilva:
Acho que falta especificar muita coisa, pois fica dificil discutir mais a fundo para que e por quem é usada essa arquitetura.Soluções e “Arquitetos” é que não falta.
Isso é similar ao Call Center com 600 posições mais cada site tem somente 40 - posições de atendimento p/cliente sendo gerenciada de forma independente. Então não existe gargalo e sim administração de recursos do Back-Office.
Acho que seu foco é usar jBoss.
sds[].
O foco do sistema é consultar investimentos em fundos. Então ele será acessado por pessoas e empresas que têm investido em fundos, que não são poucos!!
A gerência decidiu em substituir o Portal por Struts 1.3!!! não sei se foi uma decisão acertada … alguém teria algum argumento contra ?
Ah, o JBoss no que diz respeito a ferramenta de desenvolvimento e framework, se encontra estável pra uso efetivo no mercado ?
Então pessoal, nessa arquitetura, o que seria melhor usar… Struts 1.3 ou Struts 2 ? ou alguma outra tecnologia ainda ? tipo o beehive sem portal ?
Valew.
T
Tecnoage
Teoricamente struts 2, porém algumas platafoprmas (Como as 3 plataformas de PORTAL da oracle) são integradas com o que era padrão de mercado muito tempo atrás. Nesse caso geralmente os fabricantes provêm integração “SIMPLES” ( pero no mucho ) somente com struts 1.x ou JSF…
M
marceloplis
Então, nem citei o JSF, pois temos forte dependência e atualização constante de CSS nessa camada que será substituida e me falaram que o JSF dificulta neste aspecto !!! O portal também é muito chato nesse aspecto !!!
Pelo que pesquisei, realmente o Struts 2 teoricamente seria melhor !!! … mas por favor, você que tem experiência em arquitetura de camadas separadas fisicamente, postem sua opniões !!
Valew.
T
Tecnoage
Cara seu problema pelo que entendi não são essas tiers. São os provedores dos seus produtos. Como eu disse, optaram por struts1.3, porque provavelmente ele é, digamos, “homologado” para o conjunto de aplicações que vc possui, em especial o PORTAL.
M
marceloplis
Mas mesmo que o servidor de portal seja substituido por tomcat rodando integrado com jboss ??
T
Tecnoage
Agora tu falou coisas diferentes…rsrsrs Se houver essa substituição soca strus2 ae rs
Luiz_Aguiar
Alguém (eles) tem algum argumento a favor?
W
WilliamSilva
Agora tu falou coisas diferentes…rsrsrs Se houver essa substituição soca strus2 ae rs
Só devemos tomar cuidado com as versões do S2 (Struts 2.0.14/Struts 2.1.6) pois ele está passando por uma fase de “realinhamento” e alguns plugins ainda precisam de mais testes.Sem contar da incompatibilidade de uma versão para outra mais isso pode ser superada com um bom conhecimento do framework.
M
marceloplis
Alguém (eles) tem algum argumento a favor?
O argumento é que o Struts 1.3 já é uma tecnologia que eles têm vários outros projetos desenvolvidos com ele e que se usar o Struts 2 seria algo a mais a aprender e acarretaria perder tempo no projeto. Eles também julgam que terão maior escalabilidade, pois como o sistema é financeiro, ele passa por diversas modificações em suas regras de negócios, modo de apresentação, etc… , ou seja, não há um ciclo de vida completo, com fim do projeto!!!
Mas se o Struts 2 proporcionar uma qualidade e escalabilidade maior, não seria melhor perder tempo no projeto ?
