Qual a arquitetura mais adequada?

27 respostas
Luiz_Gustavo

Galera, gostaria de ter a opinião de vocês para a seguinte situação:

Um cliente quer um sistema que possa ser acessado tanto localmente quanto remotamente. Ele gostaria de uma interface gráfica (Swing) para uso local, e a interface para consulta remota seria Web mesmo (Html, JSP, XML, …).
Porém, não é uma exigência que a interface do sistema local seja Swing, pode ser totalmente Web.

Diante disso pergunto a vocês:

Qual a melhor maneira de distribuir minha aplicação?

Faço tudo Web mesmo?
Caso queira fazer a parte Swing, o que seria mais adequado?

Em ambos os casos é adequado deixar o banco de dados em um servidor remoto (host de hospedagem), ou em uma máquina dedicada, no ambiente do cliente?

Até hoje só fiz aplicações cliente/servidor em Java, com Swing, mas sei programar em Servlets/JSP (e me viro com Struts).
O que me sugerem?

Obrigado aquem puder dar uma opinião.

[]'s

27 Respostas

A

Depende. Se os requisitos funcionais te levam a concluir que vc precisa de uma interface rica, pq fazer Web? Não conheço seus requisitos para sugerir a melhor.

Tb depende. Se seus requisitos funcionais te levam a concluir que vc pode trabalhar com um servidor no cliente, pq não!? Se, pelo contrário, vc precisa que os dados estejam centralizados e sempre atualizados, a centralização é a melhor opção.

rodrigoy

A melhor arquitetura é aquela que resolve os requisitos da maneira mais simples possível.

Na sua situação, se os requisitos permitirem, acho que Web seria melhor. Acho que seria bom ser ou tudo web ou tudo swing.

G

Concordo com o rodrigo, a não ser em pequenas execessões (por exemplo base swing e relatorio via web).
Mas quanto ao caso de usar um o outro, veja estas diretivas:

Se sua interface com o cliente precisa ser rica (navegações, filtros, buscas avançadas, etc) use desktop (swing), a parte visual web (Java Server Faces, Struts, etc) está muito forte, mas ainda não tem o poder do desktop.

Se sua aplicação usa muitas atualizações com o banco e de layout, use swing, pois a carga visual será no cliente, e portanto mais rápida (é lógico cada caso é um caso, se sua maquina cliente for ruim e seu servidor uma maravilha, está afirmação precisa ser repensada).

Tem muitas outras caracteriscas do sistema que pode interfir na sua decisão, mas acho que estas duas são as principais. Mas lembre-se tudo tem excessão.

Luiz_Gustavo

Obrigado pelas opiniões galera!!

Estarei atento às novas que surgirem!

valeus

A

rodrigoy:
A melhor arquitetura é aquela que resolve os requisitos da maneira mais simples possível.

Na sua situação, se os requisitos permitirem, acho que Web seria melhor. Acho que seria bom ser ou tudo web ou tudo swing.

Concordo, e voto que tudo seje Web. Você pode deixar uma parte da aplicação funcionando totalmente offline (ou seja, mesmo que o cara tá sem conexão, ele consegue trabalhar) e outra, totalmente online (isso dá o poder de acesso a qualquer computador em qualquer lugar), aí, elas se integram conforme a sua utilização. :roll:

Hoje existem muitas tecnologias e conceitos que nos permite construir aplicações web muito melhores e mais produtivas do que em swing, como exemplo, a utilização de AJAX através de frameworks poderosos (cabe a você escolher: dojo, gwt, dwr, etc.).

[]s.

sapulha

Tb concordo com ser totalmente web.
Se o problema for interface rica, temos o Open Lazlo para aplicações RIA, o que possibilita maior interação.

A

agsilva:

Concordo, e voto que tudo seje Web. Você pode deixar uma parte da aplicação funcionando totalmente offline (ou seja, mesmo que o cara tá sem conexão, ele consegue trabalhar) e outra, totalmente online (isso dá o poder de acesso a qualquer computador em qualquer lugar), aí, elas se integram conforme a sua utilização.

Como vc faz isso com HTML? Vc consegue trazer uma lista de produtos (por exemplo) para seu cliente e trabalhar com ela sem acesso remoto?

Luca

Olá

Para que fazer duas vezes a camada de apresentação?

Faça uma vez só e logo em Swing. Deixe na máquina local só a camada de apresentação. Faça o sistema tudo separadinho enviando mensagens para o servidor via HTTP/HTTPs através de URLConnection (use HttpClient). No servidor separe também a persistência.

Estando tudo bem separadinho, nada impede de você instalar TUDO em servidor na rede local ou até tudo na mesma máquina. Já fica com tudo pronto para no futuro colocar na Internet.

Swing não é tão difícil assim. Na minha opinião, Swing é tão difícil quanto (JSP+JSTL+EL+boas práticas+um framework MVC) e menos difícil do que JSF+(todo o conteúdo dos parêntesis anteriores)

[]s
Luca

A

Há um grande problema entre os profissionais de TI: conceber a solução antes de conhecer o problema. :roll:

cv1

Há um grande problema entre os profissionais de TI: conceber a solução antes de conhecer o problema. :roll:

Tem outro, mais irritante ainda: escrever mal… (‘seje’!?) :roll:

Luiz_Gustavo

agsilva:

Concordo, e voto que tudo seje Web. Você pode deixar uma parte da aplicação funcionando totalmente offline (ou seja, mesmo que o cara tá sem conexão, ele consegue trabalhar) e outra, totalmente online (isso dá o poder de acesso a qualquer computador em qualquer lugar), aí, elas se integram conforme a sua utilização

E como seria isso? Por exemplo, se eu fizer assim, deixar uma parte funcionando offline e outra online, e deixar o banco remoto, num host de hospedagem, quando o cara não tiver conexão como fica o acesso ao banco a partir da aplicação offline?
E se eu deixar o banco numa máquina dedicada no cliente, com a aplicação web acessando o banco… se o cliente perder a conexão por um tempo, como ficaria o acesso ao banco a partir da aplicação remota (que está no host).
Seria o caso de ter as bases replicadas (uma local e uma remota) e fazer a sincronização de tempos em tempos?

Desculpem se estou falando besteira… :smiley:

… mas eu ainda chego lá hehehhee

Luiz_Gustavo

Aí está… eu não sabia como fazer a aplicação Swing “conversar” com o servidor… vou dar uma pesquisada sobre HttpClient (vou recorrer ao amigo google, mas aceito sugestões)

O que não me impediria de já colocar somente a camada de apresentação nas máquinas locais logo de cara, e o restante em um host remoto, certo?

Eu também não acho Swing difícil não, na verdde trabalho mais com ele…

Galera… muito obrigado a quem está postando sugestões… todas estão sendo proveitosas, podem ter certeza.

Continuo na “escuta” do lado de cá
:smiley:

[]'s

Luiz_Gustavo

olha q doido:

http://www.webstreamsystem.com/wss/demosFrame.htm

pena que não seja Free :roll:

cv1

Pq esse surto de ‘e se o usuario estiver offline?’

A internet so funciona quando se esta online, e nao vejo ninguem reclamando - pelo contrario, ficar online esta cada vez mais facil, e azar pros que ainda nao se tocaram disso :wink:

A menos que a sua base de usuarios alvo seja extremamente leiga, afastada dos grandes centros ou pobre (que talvez seja a pior base de usuarios pra arrumar), nao faz sentido.

Luiz_Gustavo

hhehehehehe… acho que essa neura é devido ao fato de eu só ter feito aplicações (locais) cliente servidor, onde tudo funciona independentemente de conexão com internet.
Na verdade o que acontece é o seguinte: há uma empresa que já tem um sistema feito em Delphi/Paradox, e eles querem migrar o sistema para Java. Eu particularmente não conheço a infra-estrutura do cliente, mas sei que o mesmo quer acessar a aplicação pela web também (digamos que num final de semana ocioso, a partir de casa :P).
Como disse, não vejo problema em fazer tudo baseado em uma arquitetura web, mesmo que com uma camada de apresentação em Swing, ou até mesmo baseada em outras tecnologias… mas diante da sugestão do colega, de fazer uma aplicação que também operasse offline me deparei com essa dúvida…

rodrigoy

cv:
Pq esse surto de ‘e se o usuario estiver offline?’

A internet so funciona quando se esta online, e nao vejo ninguem reclamando - pelo contrario, ficar online esta cada vez mais facil, e azar pros que ainda nao se tocaram disso :wink:

A menos que a sua base de usuarios alvo seja extremamente leiga, afastada dos grandes centros ou pobre (que talvez seja a pior base de usuarios pra arrumar), nao faz sentido.

Ainda existem muitas aplicações locais que necessitam ser locais ou por confiabilidade ou porque a infra-estrutura não pode atender uma conexão internet. Atualmente isso ocorre muito no comércio. Ex. Redes de Lojas distribuídas. Nesse cenário uma aplicação local que sincroniza com um servidor via linha discada a noite é a realidade. Pelo menos aqui no BR, conexão internet é de baixa confiabilidade e uma loja não pode parar de vender porque o link está fora do ar. Isso é uma necessidade comum e muito pouco explorada.

sapulha

Há um grande problema entre os profissionais de TI: conceber a solução antes de conhecer o problema. :roll:

Concordo que é irritante, mais não tanto quanto se achar o bom e postar mensagens só pra criticar os outros.

Isso é só pra incrementar o seu contador de mensagens?

Luiz_Gustavo

Exato. E esta aplicação a que me refiro não poderia deixar o usuário na mão no caso de uma eventual queda de conexão.

Não é contexto da aplicação a que me refiro, mas imagine uma livraria, que tenha uma loja em uma cidade, e ainda um sistema de compra on-line.
Digamos que o gerenciamento todo da loja física (as compras feitas em balcão, controle de estoque etc…) esteja também no host remoto. Apesar da alta disponibilidade oferecida hoje em dia pelos hosts nada me dá a certeza de que a conexão não possa falhar lá na loja, por uma razão qualquer (tá… nada me garante que ninguém vai derrubar o gabinete também… ou que o HD vai paular… tudo isso também prejudicaria da mesma forma). Mas em se tratando dessa questão de disponibilidade da aplicação, o que seria mais viável?
De repente seria viável manter a aplicação e a base de dados localmente, e uma parte da aplicação no host remoto, acessando a base local? (pelo menos nesse caso, se a conexão viesse a passar por um problema, mesmo que momentâneo, o fluxo de trabalho local seria mantido, e somente a aplicação WEB ficaria mometaneamente indisponível).

E olha, eu não estou pedindo a solução definitiva galera… gostaria de saber a opinião de vocês mesmo… o que cada um vê como uma solução para o que foi apresentado (e até onde foi apresentado). Alguns colegas estão criticando o fato de alguns tentarem dar uma solução antes de conhecer o problema… mas repito… eu não quero a solução definitiva, como se o que fosse sugerido aqui fosse ser aplicado de cabo-a-rabo… são só pistas do que seria possível ou absurdo.

sapulha

Luiz_Gustavo, ja vi algo parecido com o que você precisa em sistemas bancários, o problema e a solução foi a seguinte:
Um determinado banco precisa sinvronizar seus dados com a central em outro país, caso a conexão esteja on-line esse sincronismo é na hora, senão, ele é feito quando a conexão é re-estabelecida, pois os usuários não podem ficar sem o sistema.
Para isso, a solução foi uma aplicação local, utilizando JEE com banco e servidor de aplicação local, mais que utilizava mensagens para sincronizar os dados com a central. Se não me engano, eles utilizavam TIBCO para esse sincronismo, mais nada impede de usar o JMS.
Acho que no seu caso talvez seja interessante algo do tipo, com uma aplicação local(seja swing ou web, apesar de ser partidário de web) fazendo um sincronismo com uma central via JMS. Aí se a conexão com a central cair, o JMS se encarrega de enfileirar e enviar quando a conexão voltar.
Não sei se atende ao seu caso, mais é uma idéia.

A

sapulha:
Concordo que é irritante, mais não tanto quanto se achar o bom e postar mensagens só pra criticar os outros.

Isso é só pra incrementar o seu contador de mensagens?

Não Sapulha. Encare as críticas de uma maneira construtiva e não pelo lado pessoal. Meu objetivo não é o de incrementar contadores. Meu objetivo é o de ver software de qualidade no mercado.

sapulha:

Acho que no seu caso talvez seja interessante algo do tipo, com uma aplicação local(seja swing ou web, apesar de ser partidário de web) fazendo um sincronismo com uma central via JMS. Aí se a conexão com a central cair, o JMS se encarrega de enfileirar e enviar quando a conexão voltar.
Não sei se atende ao seu caso, mais é uma idéia.

Parece que vc abriu a mente depois do que eu falei. Tah vendo como vc foi precipitado!?

Desculpe qq coisa. :roll:

sapulha

Taz:

Parece que vc abriu a mente depois do que eu falei. Tah vendo como vc foi precipitado!?
Desculpe qq coisa. :roll:

Ok Taz, não esquenta.

Concordo que me precipitei, pois quando disse totalmente web, queria dizer “rodando no browser”, seja local ou remoto, mais concordo que o swing possa ser uma solução plausível nesse caso.

É que tem algumas pessoas no fórum que adoram entrar só pra criticar, e acabei descontando em você.

Mais uma vez, desculpe.

Obrigado.

Luiz_Gustavo

sapulha:
Luiz_Gustavo, ja vi algo parecido com o que você precisa em sistemas bancários, o problema e a solução foi a seguinte:
Um determinado banco precisa sinvronizar seus dados com a central em outro país, caso a conexão esteja on-line esse sincronismo é na hora, senão, ele é feito quando a conexão é re-estabelecida, pois os usuários não podem ficar sem o sistema.
Para isso, a solução foi uma aplicação local, utilizando JEE com banco e servidor de aplicação local, mais que utilizava mensagens para sincronizar os dados com a central. Se não me engano, eles utilizavam TIBCO para esse sincronismo, mais nada impede de usar o JMS.
Acho que no seu caso talvez seja interessante algo do tipo, com uma aplicação local(seja swing ou web, apesar de ser partidário de web) fazendo um sincronismo com uma central via JMS. Aí se a conexão com a central cair, o JMS se encarrega de enfileirar e enviar quando a conexão voltar.
Não sei se atende ao seu caso, mais é uma idéia.

Poxa… parece ser uma solução legal… apesar de eu nunca ter usado JMS, TIBCO… mas dou uma pesquisada.

Muito obrigado pela sugestão…

[]'s

guerios

Luiz_Gustavo:
sapulha:
Luiz_Gustavo, ja vi algo parecido com o que você precisa em sistemas bancários, o problema e a solução foi a seguinte:
Um determinado banco precisa sinvronizar seus dados com a central em outro país, caso a conexão esteja on-line esse sincronismo é na hora, senão, ele é feito quando a conexão é re-estabelecida, pois os usuários não podem ficar sem o sistema.
Para isso, a solução foi uma aplicação local, utilizando JEE com banco e servidor de aplicação local, mais que utilizava mensagens para sincronizar os dados com a central. Se não me engano, eles utilizavam TIBCO para esse sincronismo, mais nada impede de usar o JMS.
Acho que no seu caso talvez seja interessante algo do tipo, com uma aplicação local(seja swing ou web, apesar de ser partidário de web) fazendo um sincronismo com uma central via JMS. Aí se a conexão com a central cair, o JMS se encarrega de enfileirar e enviar quando a conexão voltar.
Não sei se atende ao seu caso, mais é uma idéia.

Poxa… parece ser uma solução legal… apesar de eu nunca ter usado JMS, TIBCO… mas dou uma pesquisada.

Muito obrigado pela sugestão…

[]'s

Dae galera eu tava dando uma olhada neste post e resolvi opinar.

O problema de integração com sistemas antigos com novos não é novo, existem hoje soluções de integração com JMS proprietárias usadas mais na Europa e Estados Unidos e também existem as soluções open Source que é o caso do framework openMQ.

Existem também soluções na internet para usar código delphi acessando aplicativos J2EE (EJB) através de uma tecnologia um pouco complicada, mas funciona que é uma beleza.

Portanto integrar uma aplicação feita em uma linguagem com outra feita em outra linguagem não é problema. O que deve ser verificado é quanto custaria fazer esta integração e quanto custaria fazer o sistema novamente partindo do princípio que o modelo de dados seria praticamente o mesmo com algumas modificações, como por exemplo migrando de Delphi para Java na Web com Struts, Hibernate para persistência.

Bom quanto a disponibilidade numa loja ou comércio em geral eu também concordo que é complicado de você chegar no cliente e falar “Olha eu tenho uma solução web aqui que resolve teu problema de localização(Acessar de Casa) mas pode ser que um dia a conexão caia e você tenha que escrever na mão os pedidos, o caixa e etc” .

Pondero este problema com as seguintes informações:

Deixar um aplicativo web em modo offline(Sem JMS) seria muito difícil de fazer pois teria que escrever um arquivo texto ou um xml e gravar locamente e para isso teria que existir um Applet, na minha visão muito complicado e demorado para fazer além de ser uma fonte eterna de bugs.
Assim como um cliente/servidor teria as mesmas dificuldades se um servidor local caísse por exemplo

A segunda ponderação é sobre a questão da alta disponibilidade. Para mim um cliente de pequeno porte querer alta disponibilidade 24 por 7 e quase nunca dar problema é utópico(Posso estar errado) pois ele não vai ter o dinheiro(Pode ser que tenha e não queira pagar) para garantir este tipo de disponibilidade ainda mais num sistema baseado em web aonde o link dele provavelmente seria um ADSL normal que não é garantido.

Nem sempre o software aplicativo é o responsável por todas as obrigações e necessidades do cliente (Muitos confundem)

O que poderia ser sugerido para o cliente seria:
Utilização de um link bem mais confiável no caso poderia ser um SLDD, Interlan ou Frame Relay que ficam em cima de redes ATM de operadoras de telecomunicações.

Alta disponibilidade da aplicação seria hospedar a aplicação num servidor aonde seja garantido isso que até aonde eu conheço o locaweb e a brasiltelecom tem serviços que garantem isso.

Bem, dito tudo isso posso simplificar que as vezes o que o cliente quer não é o que ele pode pagar.

Alta disponibilidade é coisa cara e hoje somente grandes empresas tem como supermercados, lojas de departamentos, prefeituras, Estados e etc.

Talvez este paradigma esteja mudando mas enquanto as conexões realmente confiáveis estiverem num preço relativamente alto a solução mais barata para o cliente seria um client/server na loja e um e-commerce na web aonde existiria uma integração entre os dois seja via JMS seja via arquivo texto mesmo, ai depende do “braço” do implementador.

Éssa é a minha opinião sobre o assunto

Abraço a todos

Francisco Guerios
Analista Programador J2EE
www.infosist.com.br

Luca

Olá

Francisco, bem vindo ao GUJ.

Muito bom seu post com bons fundamentos. Mas o que são estes tais DDR e Interlan?

[]s
Luca

guerios

Luca:
Olá

Francisco, bem vindo ao GUJ.

Muito bom seu post com bons fundamentos. Mas o que são estes tais DDR e Interlan?

[]s
Luca

Muito Obrigado Luca

Desculpe amigos aonde está escrito DDR entendam SLDD
confundi as siglas.

Existem várias formas de conexão fora o ADSL comum

Seguem elas

Definições

Fame Relay

O Frame Relay é o produto que oferece melhor custo-benefício para empresas que precisam ligar mais de três unidades a uma central.
Você não precisa investir em instalações físicas. Uma única porta de acesso é suficiente para que toda a rede se comunique com total segurança.
Isso porque os circuitos que fazem as ligações entre os pontos são virtuais.
Outra vantagem: esses mesmos circuitos também são permanentes,
o que garante uma conexão contínua de rede.
E, para facilitar o trabalho da sua empresa, o serviço é monitorado ponto a ponto. Assim, você pode controlar o sistema e identificar problemas
com mais facilidade.
O atraso no transporte de dados é baixíssimo. Traduzindo: a informação chega muito mais rapidamente à sua empresa.
O Frame Relay é tão veloz e confiável que pode ser usado para transmitir voz com a mesma qualidade de uma linha telefônica.
O serviço oferece diversas opções de velocidade
Sua empresa utiliza a velocidade máxima disponível por um preço mensal fixo.
O melhor de tudo: você tem uma taxa de velocidade garantida para acessar a rede, por mais congestionada que ela esteja.

O FrameRelay não resolve totalmente o problema pois não conecta com a internet de uma forma natural.

InterLan (Recomendo)

Para interligar a matriz de sua empresa a mais de duas filiais,
o InterLAN oferece a melhor relação custo-benefício.
A empresa não precisa mais investir em instalações físicas para expandir
sua capacidade de transmissão de dados.
Com uma única porta de acesso no ponto concentrador,
todas as unidades podem se comunicar com rapidez e segurança (Circuitos Virtuais Permanentes - CVPs).

Outra vantagem do InterLAN é o dimensionamento pela média de uso.
Você pode usar a velocidade excedente que estiver disponível,
pagando um preço fixo, sem sustos no fim do mês.
E não se preocupe com os picos de tráfego: sua empresa tem garantia de banda mínima para manter o desempenho de suas aplicações.

Níveis de serviço
Não importa o tamanho da sua empresa, existem várias velocidades, níveis de serviço.
E, enquanto ela cresce, rede e o transporte de informações pode ser adaptada com a agilidade necessária.

Você pode escolher entre duas modalidades:

Dados - com o mais alto desempenho do mercado, ideal para empresas que necessitam transmitir um grande volume de dados em alta velocidade;

Segurança
Todos os pontos da rede são monitorados. Assim, fica muito mais fácil identificar problemas e controlar o sistema
O serviço Interlan tem acesso a internet.

SLDD

Canal exclusivo para ligar redes próximas ou distantes e ainda transportar qualquer tipo de informação.
O trecho contratado fica 100% alocado para a empresa e mais ninguém.
É como ter uma rodovia exclusiva onde somente o seu carro pode trafegar.
Assim, sua empresa pode ter diferentes tecnologias compartilhando a mesma rede.
E garante tranqüilidade na hora de transmitir grandes volumes de dados, voz e multimídia,
porque o transporte é em tempo real.
Tudo isso graças aos circuitos privativos que ligam o trajeto ponto a ponto.

Informações retiradas da BrasilTelecom

Estes são serviços da BrasilTelecom, outras operadoras podem usar outros nomes.

E éra isso

abraço

Guilherme_Silveira

COnheco projetos para medicos nessas regioes… nenhum deu certo. Nao deu de verdade. So no papel.

Luiz_Gustavo

guerios,

Que se façam minhas as palavras do Luca… bem vindo ao GUJ.
Olha, muito legal sua resposta.

Agradeço as opiniões e sugestões de todos…

O cliente resolveu colocar apenas um módulo na Web, e será praticamente para consulta, com algumas manipulações de dados na base que não surtirão efeito na aplicação Delphi, isso porque os dados usados pela aplicação WEB (que ficará mesmo hospedada num host remoto) estarão em uma base local, e essa base será em mysql, uma vez que o banco usado pela aplicação desktop é o paradox (simmmm).
Nesse caso a aplicação Delphi ficará responsável por atualizar a base Mysql, que será acessada pela aplicação Java.

Bom, essa foi a decisão a que chegamos.
Qualquer sugestão ou crítica é bem vinda…

[]'s e mais uma vez obrigado!

Criado 31 de julho de 2006
Ultima resposta 18 de ago. de 2006
Respostas 27
Participantes 10