Qual a arquitetura mais adequada?

cv wrote:
Pq esse surto de 'e se o usuario estiver offline?'

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

).
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...

cv wrote: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

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.

Taz wrote:

sapulha wrote:Tb concordo com ser totalmente web.

agsilva wrote: Concordo, e voto que tudo seje Web.

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

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?

rodrigoy wrote:
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.

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.

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.

GUJ Ranger Membro desde: 02/06/2005 16:28:38 Mensagens: 879 Offline

sapulha wrote: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 wrote:
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!?

sapulha wrote:
Tb concordo com ser totalmente web.

Desculpe qq coisa.

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

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.

sapulha wrote: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

Thread.start() Membro desde: 18/08/2006 16:13:29 Mensagens: 39 Offline

Luiz_Gustavo wrote:

sapulha wrote: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

Olá

guerios wrote: Utilização de um link bem mais confiável no caso poderia ser um DDR ou Interlan que ficam em cima de redes ATM de operadoras de telecomunicações.

Francisco, bem vindo ao GUJ.

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

[]s
Luca

Thread.start() Membro desde: 18/08/2006 16:13:29 Mensagens: 39 Offline

Luca wrote:Olá

guerios wrote: Utilização de um link bem mais confiável no caso poderia ser um DDR ou Interlan que ficam em cima de redes ATM de operadoras de telecomunicações.

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

cv wrote: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.

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

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!

Notícias, artigos e o maior fórum brasileiro sobre Java