Sistema Web para Múltiplos Clientes

Cada WAR teria seu próprio hibernate.cfg.xml de configuração.

Eu vejo sempre que a melhor prática e cada um ter seu próprio banco. [=

Seguinte de uma pesquisada sobre “Multitenancy”, o hibernate suporta.

Existe basicamente 3 formas de fazer

1ª Cada cliente tem seu banco de dados;

2ª Cada cliente fica em um schema;

3ª Todas as tabelas tem um campo onde nele tem o código do cliente.

Como disse antes de uma pesquisada sobre o tema

Oi Jonas,

este é um dos problemas mais difíceis da computação atualmente: trata-se do problema da multi tenância (multi-tenant).
Há diversas soluções possíveis para o problema, que vão desde particionamento de tabelas (uma partição por cliente) até modelagens de dados mais complexas, chegando ao ponto de você ter uma instância do banco de dados por cliente.

Você vai ter de pensar em alguns pontos importantes na sua modelagem, como por exemplo a possibilidade de ter campos customizados por cliente na emissão de relatórios customizados.
Há outro ponto também importante a ser abordado: como cobrar. Você precisa montar o seu negócio de tal maneira que aqueles usuários que tenham maior demanda computacional paguem mais. Outro problema difícil.

Minha sugestão pra você neste momento é estudar tudo o que encontrar sobre multi-tenância.
Outro ponto importantíssimo: estude como calcular o seu custo operacional. É vital para o seu problema.

Hebert Coelho:

Cada WAR teria seu próprio hibernate.cfg.xml de configuração.

Eu vejo sempre que a melhor prática e cada um ter seu próprio banco. [=

Oi Herbert, isto eleva o seu custo operacional às alturas. Vai funcionar com dois, três clientes, mas a partir do quarto, quinto, fica tão caro manter as instâncias em execução que o custo por cliente se torna impraticável.

O ideal é ter o mínimo de JVMs em execução, porque a parte da memória compartilhada vai ser sempre gigantesca, mas a customizada mínima.

kicolobo:

Hebert Coelho:

Cada WAR teria seu próprio hibernate.cfg.xml de configuração.

Eu vejo sempre que a melhor prática e cada um ter seu próprio banco. [=

Oi Herbert, isto eleva o seu custo operacional às alturas. Vai funcionar com dois, três clientes, mas a partir do quarto, quinto, fica tão caro manter as instâncias em execução que o custo por cliente se torna impraticável.

O ideal é ter o mínimo de JVMs em execução, porque a parte da memória compartilhada vai ser sempre gigantesca, mas a customizada mínima.

Ou então fechar como em uma empresa que já trabalhei, cada empresa teria seu próprio servidor. [=

Outra opção seria utilizar nuvem, como o Jelastic que entra no tema de multi tenância.

Eu não afirmo que a minha seja a única opção, e apenas a que eu gosto mais. [=

Hebert Coelho:

Cada WAR teria seu próprio hibernate.cfg.xml de configuração.

Eu vejo sempre que a melhor prática e cada um ter seu próprio banco. [=

também vejo assim como você, porém hoje temos suporte a Multi-tenancy.
http://docs.jboss.org/hibernate/orm/4.1/devguide/en-US/html/ch16.html

Sendo uma aplicação Web, se você está colocando as configurações de acesso ao banco no hibernate.cfg.xml isso está errado. O correto é configurar um data source no seu servidor e passar o nome do datasource na configuração do Hibernate.

Eu vejo duas maneiras de resolver o problema:

1 - Fazer um único banco de dados, com uma tabela HOTEL, sendo que cada linha de cada tabela vai precisar referenciar o hotel ao qual pertence (com exceção de tabelas como endereço, estado, etc.)

2 - Considerar que cada hotel terá seu próprio banco de dados. Nesse caso, eu também criaria uma instância do servidor de aplicação para cada hotel também. Pra falar a verdade, eu até acho essa maneira mais justa, pois eu não ia querer que o desempenho da minha aplicação se degradasse por conta de um concorrente.

O que eu definitivamente não faria seria fazer minha aplicação acessar vários banco de dados diferentes e ficar controlando isso pela aplicação. É bem provável que você teria que espalhar essa lógica pela aplicação inteira.

Hebert Coelho:

kicolobo:

Hebert Coelho:

Cada WAR teria seu próprio hibernate.cfg.xml de configuração.

Eu vejo sempre que a melhor prática e cada um ter seu próprio banco. [=

Oi Herbert, isto eleva o seu custo operacional às alturas. Vai funcionar com dois, três clientes, mas a partir do quarto, quinto, fica tão caro manter as instâncias em execução que o custo por cliente se torna impraticável.

O ideal é ter o mínimo de JVMs em execução, porque a parte da memória compartilhada vai ser sempre gigantesca, mas a customizada mínima.

Opa, blz?

Ou então fechar como em uma empresa que já trabalhei, cada empresa teria seu próprio servidor. [=

Outra opção seria utilizar nuvem, como o Jelastic que entra no tema de multi tenância.

Eu não afirmo que a minha seja a única opção, e apenas a que eu gosto mais. [=

Opa Herbert, com certeza. A sua solução é a mais simples de implementar, o problema é isto que mencionei acima: o custo vai ficar bastante elevado. A grande questão é: pra que 10 JVMs se eu posso solucionar o problema com 1 ou 2 (chutando números)?

Nestes casos, uma alternativa que levo em consideração sabe qual é? Não usar Hibernate. Really: usar JDBC direto pra poder otimizar as consultas por cliente e pensar sériamente em uma solução que envolva bancos de dados NoSQL.

Uma base documental por exemplo resolve na hora grande parte do problema dos campos complementares por cliente. Estou desenvolvendo um produto agora que lida justamente com este problema de multitenancia. O grande problema está sendo o custo: nestes casos, cada bit conta, cada ciclo conta. Por isto, quanto mais “próximo ao metal” você estiver, mais fácil fica evitar problemas.

kicolobo:

Opa Herbert, com certeza. A sua solução é a mais simples de implementar, o problema é isto que mencionei acima: o custo vai ficar bastante elevado. A grande questão é: pra que 10 JVMs se eu posso solucionar o problema com 1 ou 2 (chutando números)?

Nestes casos, uma alternativa que levo em consideração sabe qual é? Não usar Hibernate. Really: usar JDBC direto pra poder otimizar as consultas por cliente e pensar sériamente em uma solução que envolva bancos de dados NoSQL.

Uma base documental por exemplo resolve na hora grande parte do problema dos campos complementares por cliente. Estou desenvolvendo um produto agora que lida justamente com este problema de multitenancia. O grande problema está sendo o custo: nestes casos, cada bit conta, cada ciclo conta. Por isto, quanto mais “próximo ao metal” você estiver, mais fácil fica evitar problemas.

Apenas sou pé atras até o quanto o JPA seria pior que JDBC puro (O Batoo, por exemplo, é uma implementação que afirma ser até 15x mais performático que o Hibernate :shock: Nisso me pergunto quão longe estaria da performance com JDBC puro).

Hebert Coelho:

kicolobo:

Opa Herbert, com certeza. A sua solução é a mais simples de implementar, o problema é isto que mencionei acima: o custo vai ficar bastante elevado. A grande questão é: pra que 10 JVMs se eu posso solucionar o problema com 1 ou 2 (chutando números)?

Nestes casos, uma alternativa que levo em consideração sabe qual é? Não usar Hibernate. Really: usar JDBC direto pra poder otimizar as consultas por cliente e pensar sériamente em uma solução que envolva bancos de dados NoSQL.

Uma base documental por exemplo resolve na hora grande parte do problema dos campos complementares por cliente. Estou desenvolvendo um produto agora que lida justamente com este problema de multitenancia. O grande problema está sendo o custo: nestes casos, cada bit conta, cada ciclo conta. Por isto, quanto mais “próximo ao metal” você estiver, mais fácil fica evitar problemas.

Claro! Concordo com você. É tudo uma questão de calcular custos e análise do contrato estabelecido.

Apenas sou pé atras até o quanto o JPA seria pior que JDBC puro (O Batoo, por exemplo, é uma implementação que afirma ser até 15x mais performático que o Hibernate :shock: Nisso me pergunto quão longe estaria da performance com JDBC puro).

Oi Herbert,

é, com relação à performance, vai ser caso a caso. Na maior parte das vezes o JPA/Hibernate vai ser mais rápido por duas razões:

• As consultas muitas vezes são geradas otimizadas e de forma melhor que as geradas manualmente (normalmente aí a culpa fica mais por conta do programador do que vantagem pro JPA)
• As estratégias de cacheamento feitas de maneira automatizada.

Nos dois casos, você ganha muito em produtividade. Mas quando precisa estar mais próximo do SGBD, JDBC ainda impera. Outro ponto importante neste caso é que normalmente o custo de memória vai ser menor, porque é menos coisa pra carregar também. Claro: entra aí o fardo da sua perda de produtividade, mas como disse, cada caso é único.

O que observo é que quando estou no JDBC nativo eu consigo atuar mais diretamente em cima das minhas estratégias de multi tenancia e, nestes casos, eu ganho em produtividade com relação ao JPA (não preciso ficar pensando em como o mapeamento vai ser traduzido pra JDBC por exemplo). Além disto, posso também (ao custo da portabilidade) ganhar alguma coisa usando recursos nativos do SGBD que tiver adotado na solução.

Agora, falando a respeito da minha experiência profissional: JDBC sempre foi nos projetos que atuei ordens de magnitude mais performático que qualquer solução ORM.
E se você conseguir separar BEM dados de algoritmos, ao invés de fazer aquelas maluquices com zilhões de entidades sendo instanciadas - o erro mais comum ao adotarmos um ORM - man… Você consegue tirar muito mais ciclo por real investido.

kicolobo:

Hebert Coelho:

kicolobo:

Opa Herbert, com certeza. A sua solução é a mais simples de implementar, o problema é isto que mencionei acima: o custo vai ficar bastante elevado. A grande questão é: pra que 10 JVMs se eu posso solucionar o problema com 1 ou 2 (chutando números)?

Nestes casos, uma alternativa que levo em consideração sabe qual é? Não usar Hibernate. Really: usar JDBC direto pra poder otimizar as consultas por cliente e pensar sériamente em uma solução que envolva bancos de dados NoSQL.

Uma base documental por exemplo resolve na hora grande parte do problema dos campos complementares por cliente. Estou desenvolvendo um produto agora que lida justamente com este problema de multitenancia. O grande problema está sendo o custo: nestes casos, cada bit conta, cada ciclo conta. Por isto, quanto mais “próximo ao metal” você estiver, mais fácil fica evitar problemas.

Claro! Concordo com você. É tudo uma questão de calcular custos e análise do contrato estabelecido.

Apenas sou pé atras até o quanto o JPA seria pior que JDBC puro (O Batoo, por exemplo, é uma implementação que afirma ser até 15x mais performático que o Hibernate :shock: Nisso me pergunto quão longe estaria da performance com JDBC puro).

Oi Herbert,

é, com relação à performance, vai ser caso a caso. Na maior parte das vezes o JPA/Hibernate vai ser mais rápido por duas razões:

• As consultas muitas vezes são geradas otimizadas e de forma melhor que as geradas manualmente (normalmente aí a culpa fica mais por conta do programador do que vantagem pro JPA)
• As estratégias de cacheamento feitas de maneira automatizada.

Nos dois casos, você ganha muito em produtividade. Mas quando precisa estar mais próximo do SGBD, JDBC ainda impera. Outro ponto importante neste caso é que normalmente o custo de memória vai ser menor, porque é menos coisa pra carregar também. Claro: entra aí o fardo da sua perda de produtividade, mas como disse, cada caso é único.

O que observo é que quando estou no JDBC nativo eu consigo atuar mais diretamente em cima das minhas estratégias de multi tenancia e, nestes casos, eu ganho em produtividade com relação ao JPA (não preciso ficar pensando em como o mapeamento vai ser traduzido pra JDBC por exemplo). Além disto, posso também (ao custo da portabilidade) ganhar alguma coisa usando recursos nativos do SGBD que tiver adotado na solução.

Agora, falando a respeito da minha experiência profissional: JDBC sempre foi nos projetos que atuei ordens de magnitude mais performático que qualquer solução ORM.
E se você conseguir separar BEM dados de algoritmos, ao invés de fazer aquelas maluquices com zilhões de entidades sendo instanciadas - o erro mais comum ao adotarmos um ORM - man… Você consegue tirar muito mais ciclo por real investido.

Mas… só uma pergunta em cima que você falou:

O que observo é que quando estou no JDBC nativo eu consigo atuar mais diretamente em cima das minhas estratégias de multi tenancia e, nestes casos, eu ganho em produtividade com relação ao JPA (não preciso ficar pensando em como o mapeamento vai ser traduzido pra JDBC por exemplo). Além disto, posso também (ao custo da portabilidade) ganhar alguma coisa usando recursos nativos do SGBD que tiver adotado na solução.

Valeu, obrigado por compartilhar. [=

Native Query do Hibernate nem sempre funciona como a gente quer.
Você tem de ficar esperto pra usar uma sessão sem estado quando for fazer isto, porque se usar com estado, é comum que o estado dos objetos em sessão seja atualizado ao executar SQL nativo (rola muito isto com Grails por exemplo). Consequentemente, todo o ganho de performance vai pro saco.

Além disto, um outro ponto importante pra lembrar é o seguinte: quando você vai usar native query via JPA/Hibernate, tá ainda passando por uma camada desnecessária, ao menos no meu ponto de vista. Pra que eu preciso dela se eu quero estar atuando direto no BD? Este é um questionamento interessante. Lembre-se que uma das vantagens do ORM é que ele mantém o estado de algumas entidades, tem de levar isto em consideração.

No geral, uma prática que costumo adotar com bastante sucesso é sempre pensar nas minhas entidades como objetos de curtíssima duração (normalmente apenas dentro da execução de um método). Isto me ajuda a evitar estes problemas que disse acima. Por outro lado, objetos com curta duração podem acabar com sua memória quando alto processamento ocorre, então… nestes casos, em que vou precisar de alta performance, sempre acabo voltando pro JDBC

kicolobo:

Native Query do Hibernate nem sempre funciona como a gente quer.
Você tem de ficar esperto pra usar uma sessão sem estado quando for fazer isto, porque se usar com estado, é comum que o estado dos objetos em sessão seja atualizado ao executar SQL nativo (rola muito isto com Grails por exemplo). Consequentemente, todo o ganho de performance vai pro saco.

Além disto, um outro ponto importante pra lembrar é o seguinte: quando você vai usar native query via JPA/Hibernate, tá ainda passando por uma camada desnecessária, ao menos no meu ponto de vista. Pra que eu preciso dela se eu quero estar atuando direto no BD? Este é um questionamento interessante. Lembre-se que uma das vantagens do ORM é que ele mantém o estado de algumas entidades, tem de levar isto em consideração.

No geral, uma prática que costumo adotar com bastante sucesso é sempre pensar nas minhas entidades como objetos de curtíssima duração (normalmente apenas dentro da execução de um método). Isto me ajuda a evitar estes problemas que disse acima. Por outro lado, objetos com curta duração podem acabar com sua memória quando alto processamento ocorre, então… nestes casos, em que vou precisar de alta performance, sempre acabo voltando pro JDBC :)

Mas tem que se lembrar de que, utilizar native query teria a vantagem de usar um mapeamento ORM o que aumenta a produção de código (imagine jogar o resultado de uma query para um objeto com 40 campos e 3 listas, como seria a produção que código). O cache do JPA pode ser desligado com uma configuração. E existem técnicas para melhorar uma pesquisa, por exemplo, não abrir transação ou anotar um método com @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) que não haverá objetos “attached” e outras.

Existem técnicas que realmente podem melhorar e deixar que o JPA seja otimizado de acordo com a necessidade, mas infelizmente não tenho a experiência de multi tenancy que você. Vou ficar atento a isso quando eu cair nesse cenário. [=

Hebert Coelho:

kicolobo:

Native Query do Hibernate nem sempre funciona como a gente quer.
Você tem de ficar esperto pra usar uma sessão sem estado quando for fazer isto, porque se usar com estado, é comum que o estado dos objetos em sessão seja atualizado ao executar SQL nativo (rola muito isto com Grails por exemplo). Consequentemente, todo o ganho de performance vai pro saco.

Além disto, um outro ponto importante pra lembrar é o seguinte: quando você vai usar native query via JPA/Hibernate, tá ainda passando por uma camada desnecessária, ao menos no meu ponto de vista. Pra que eu preciso dela se eu quero estar atuando direto no BD? Este é um questionamento interessante. Lembre-se que uma das vantagens do ORM é que ele mantém o estado de algumas entidades, tem de levar isto em consideração.

No geral, uma prática que costumo adotar com bastante sucesso é sempre pensar nas minhas entidades como objetos de curtíssima duração (normalmente apenas dentro da execução de um método). Isto me ajuda a evitar estes problemas que disse acima. Por outro lado, objetos com curta duração podem acabar com sua memória quando alto processamento ocorre, então… nestes casos, em que vou precisar de alta performance, sempre acabo voltando pro JDBC :)

Claro, concordo.

Mas tem que se lembrar de que, utilizar native query teria a vantagem de usar um mapeamento ORM o que aumenta a produção de código (imagine jogar o resultado de uma query para um objeto com 40 campos e 3 listas, como seria a produção que código). O cache do JPA pode ser desligado com uma configuração. E existem técnicas para melhorar uma pesquisa, por exemplo, não abrir transação ou anotar um método com @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) que não haverá objetos “attached” e outras.

Existem técnicas que realmente podem melhorar e deixar que o JPA seja otimizado de acordo com a necessidade, mas infelizmente não tenho a experiência de multi tenancy que você. Vou ficar atento a isso quando eu cair nesse cenário. [=

Oi Herbert, é: quando a gente tá falando de JPA, tem de levar em consideração sempre que não usar um ORM quer dizer um impacto MONSTRO na sua produtividade.
É aquela balança, saca? Você acaba tendo de fazer algumas perguntas do tipo: “tenho tempo pra entregar esta funcionalidade usando JDBC nativo?”, “JPA vai permitir a este sistema escalar de verdade e ainda me possibilitar implementar uma estratégia multi tenant eficiente?”

É questão de por as coisas na balança sempre.

Eu acredito que o melhor é cada cliente com o seu WAR/banco próprios.

Imaginando que existem clientes que demandam mais recursos que os outros, você pode facilmente migrar um cliente “parrudo” para um server melhor e não vai atrapalhar os outros.

Se for tudo em um mesmo banco, isso fica quase impossível de fazer.

Este é apenas um dos problemas que existem quando juntamos todos os clientes em um unico banco.

kicolobo:

Oi Jonas,

este é um dos problemas mais difíceis da computação atualmente: trata-se do problema da multi tenância (multi-tenant).

Mutil-Tenant = Multi-Inquilino (tenant = inquilino)

não existe “tenância”

sergiotaborda:

kicolobo:

Oi Jonas,

este é um dos problemas mais difíceis da computação atualmente: trata-se do problema da multi tenância (multi-tenant).

Mutil-Tenant = Multi-Inquilino (tenant = inquilino)

não existe “tenância”

Esse Henrique, vou te falar viu… Vive aprontando das suas!
Valeu pelo toque!

jonas.cant:

Numa situação hipotética, quero criar um sistema web de gestão hoteleira que será vendido para vários hotéis diferentes. Estou com dúvida em relação ao acesso ao banco de dados. Como ficaria essa situação? Cada hotel com seu banco de dados? O mesmo banco de dados para todos hotéis? Se cada hotel deverá ter seu próprio banco de dados, como fazer isso utilizando o hibernate sendo que o arquivo de configuração ‘hibernate.cfg.xml’ é estático e atualmente estou passando um nome de banco de dados específico?
Quem puder me ajudar, fico agradecido.

O pessoal já lhe deu a resposta de multi-inquilino e o suporte do Hibernate, mas vc não especificou quantos servidores estamos falando.
Quando vc diz “Sistema web para Multiplos Clientes” vc quer dizer que faz um software e vende para vários clientes, ou vc quer dizer que faz um software , instala uma só vez num servidor seu e os clientes pagam para ter acesso ?

O cenário de multi-inquilino só aparece na segunda opção. Na primeira opção, vc edita o arquivo de configuração do war em cada deploy. Ou, o que seria melhor, vc configura o arquivo para usar JNDI e configura o servidor de cada cliente com o banco de dados certo via JNDI. Assim, não tem que editar o seu war e o cliente pode mudar de banco quanto quiser sem ter que mexer com o war.

O pessoal comentou bastante, e tem muita coisa que eu não entendi e talvez por hora eu não conseguiria implementar no sistema. Ainda sou um mero principiante em Java.
Só para esclarecimento, a minha situação hipotética é um TCC que estou desenvolvendo, não pretendo vender o sistema. Só quero desenvolver o TCC de uma forma que possa servir numa situação real.

Vamos ver se eu entendi:

Na primeira opção, para cada cliente que fosse comprar meu sistema eu teria que mudar as configurações de acesso ao banco e gerar um novo arquivo WAR que seria colocado no servidor que será mantido pelo próprio cliente.
Na segunda opção, o servidor seria mantido por minha “empresa” e todos clientes acessariam o sistema naquele servidor.

É isso?

jonas.cant:

O pessoal comentou bastante, e tem muita coisa que eu não entendi e talvez por hora eu não conseguiria implementar no sistema. Ainda sou um mero principiante em Java.
Só para esclarecimento, a minha situação hipotética é um TCC que estou desenvolvendo, não pretendo vender o sistema. Só quero desenvolver o TCC de uma forma que possa servir numa situação real.

Vamos ver se eu entendi:

Na primeira opção, para cada cliente que fosse comprar meu sistema eu teria que mudar as configurações de acesso ao banco e gerar um novo arquivo WAR que seria colocado no servidor que será mantido pelo próprio cliente.
Na segunda opção, o servidor seria mantido por minha “empresa” e todos clientes acessariam o sistema naquele servidor.

É isso?

Na mosca.

Bom, tendo em vista a complexidade de implementação do tal “multi-inquilino” em relação ao meu conhecimento atual, farei o sistema como se fosse vendê-lo e o cliente seria o mantenedor do servidor.
Só uma dúvida: meu cliente comprou o sistema e já está com o servidor pronto. Vou configurar o arquivo de conexão ao banco, gerar o WAR e implantar no servidor dele. Esse arquivo WAR não possibilita o cliente de alterar/visualizar o código fonte do sistema, correto? É seguro distribuir este arquivo?

Só precisa gerar o arquivo WAR uma vez na realidade.
Para isto, basta que você obtenha sua conexão com o banco de dados usando JNDI.
Aí basta que em cada servidor você configure o DataSource com o nome que você definir em suas configurações de acesso.

Ok. Vou ver como funciona utilizando JNDI, pois a princípio não fiz desta forma. Estou utilizando um arquivo xml de configuração e ali estou setando as configurações do banco de forma fixa.

jonas.cant:

Bom, tendo em vista a complexidade de implementação do tal “multi-inquilino” em relação ao meu conhecimento atual, farei o sistema como se fosse vendê-lo e o cliente seria o mantenedor do servidor.
Só uma dúvida: meu cliente comprou o sistema e já está com o servidor pronto. Vou configurar o arquivo de conexão ao banco, gerar o WAR e implantar no servidor dele. Esse arquivo WAR não possibilita o cliente de alterar/visualizar o código fonte do sistema, correto? É seguro distribuir este arquivo?

O war é apenas um zip. Ele pode ser descompactado, alterado, e recompactado. É seguro, mas não no sentido de “esconder o código”. Esqueça isso de “esconder o código”.

No cenário de um cliente por servidor (single-tenant), é o servidor que mantém a informação de onde está e qual é o banco de dados. Para isto vc precisa entender como funciona o JNDI e o JEE. O war não deve conter informações fixas sobre nenhuma configuração. Ele deve ler todas as configurações do JNDI do servidor. Desta forma, o mesmo war serve para diferentes servidores porque o que muda é o servidor, não o war. Por exemplo , se o war usasse um serviço de email, a configuração do serviço ficaria no servidor, nunca no war. O servidor JEE provê diversos serviços que o war pode usar , mas a configuração fica do lado do servidor.

Você precisa estudar mais sobre web em java, porque estão lhe faltando conceitos de base. Sem eles não tem como desenvolver uma arquitetura decente.

Eu, pessoalmente, gostaria muito mais de ver um TCC de multi-tenant do que de single-tenant, pelo simples facto que este ultimo cenário é o arroz com feijão e já está muito batido.

Concordo contigo, Sergio.
Pra muita coisa me falta a base, por isso estou aqui e até agora tem me ajudado.

Infelizmente nas faculdades (pelo menos na minha) o que é ensinado é menos que o básico pra desenvolver uma aplicação completa e decente. Eu escolhi Java Web por dois motivos:
1º Estou gostando bastante de Java;
2º Aprendizado.

Não pretendo fazer um “monstro” de TCC, meu objetivo principal é aprender. Mas enfim…

Então não é seguro eu distribuir o WAR já que o cliente pode alterar o código e compilar novamente? Tem alguma outra forma?

jonas.cant:

Concordo contigo, Sergio.
Pra muita coisa me falta a base, por isso estou aqui e até agora tem me ajudado.

Infelizmente nas faculdades (pelo menos na minha) o que é ensinado é menos que o básico pra desenvolver uma aplicação completa e decente. Eu escolhi Java Web por dois motivos:
1º Estou gostando bastante de Java;
2º Aprendizado.

Não pretendo fazer um “monstro” de TCC, meu objetivo principal é aprender. Mas enfim…

Então não é seguro eu distribuir o WAR já que o cliente pode alterar o código e compilar novamente? Tem alguma outra forma?

pro seu TCC é seguro.
pro mundo real não.

O que rola: seu custo de atualização das máquinas clientes no mundo real fica caro.
Imagine ter de atualizar servidor por servidor.

Entendi. A questão da atualização realmente fica praticamente inviável se por exemplo a empresa tem 500 clientes. Sem dúvidas o uso de multi-inquilino seria a melhor opção. Quem sabe até lá eu aprenda a implementar isto.
Se alguém tiver algum material bom sobre como implementar o modelo multi-inquilino, fique à vontade.

jonas.cant:

Entendi. A questão da atualização realmente fica praticamente inviável se por exemplo a empresa tem 500 clientes. Sem dúvidas o uso de multi-inquilino seria a melhor opção. Quem sabe até lá eu aprenda a implementar isto.
Se alguém tiver algum material bom sobre como implementar o modelo multi-inquilino, fique à vontade.

O conceito é simples, depois vc tem que o encaixar nas ferramentas ou implementar do zero.
O conceito é que o sistema tem uma variável chamada TenantID. Esta variável identifica o cliente ( o inquilino). Ela pode esta associada ao login do usuário, ou url de acesso, a coockies, ou a um combinação de todos dependendo como o acesso ao sistema se dá. Normalmente se dá por uma URL dedicada para cada cliente, ( e neste caso cada cliente pode ter um look e layout diferente) ou uma mesma página com a cada da sua empresa que depois do login manda para o sistema customizado do cliente.
Seja como for, vc detecta o tenantID e o usa em todas as invocações (é preciso uma arquitetura e um design amigável para isto). Portanto, em todos os pontos do sistema vc sabe quem está acessando (quem é o user) e em que ambiente ele está ( quem é o inquilino). Para persistencia existem diferentes tecnicas ( que o hibernate implementa). A primeira mais obvia é ter o tenantID como chave em todas as tabelas. A segunda é ter um schema por tennatId num mesmo banco de dados ( para os bancos de dados que suportam isto) e a ultima é ter um banco por tennatID. A primeira é melhor se existem dados ou serviços que ganham sendo partilhados (estatisticas por exemplo), a ultima garante segregação máxima e que nunca nenhum tenant tem o risco de acessar coisas do outro.

Não tem muito mais que isto. O resto é detalhes de implementação, considerações de design e tentar fazer de uma forma que o sistema sabe o tenanat, mas o programador quase não tenha que saber que isso existe. De forma que a programação seja o mais próximo possivel do single-tennat.

Interessante… não parece ser o bicho de sete cabeças.
Se eu fosse implementar esse modelo, com certeza eu faria com que cada inquilino tivesse um banco de dados próprio.

jonas.cant:

Interessante… não parece ser o bicho de sete cabeças.
Se eu fosse implementar esse modelo, com certeza eu faria com que cada inquilino tivesse um banco de dados próprio.

É… só que como já foi dito aqui, isso torna as coisas mais caras para si. O que é meio obvio pois mais segurança normalmente sempre significa mais caro.
Também tem relação com a elasticidade, pois nesse modelo o servidor de nuvem ( este cenário é para ser usado em nuvem) deve criar uma banco de dados novo , mas ele pode não ter a informação de qual criar. As coisas ficam um pouco mais complexas na prática neste cenários. O cenários mais simples é ter o id por tabela. O ideal é realmente usar um schema por tenant, não tem as dores de cabeça de criar várias bancos de dados, nem os problemas de dados misturados, contudo todo o mundo está no mesmo banco. Em tese é o trade-off mais simples, mas na realidade nenhum dos três é o melhor em todos os requisitos, por isso mesmo, existem três , :lol:

A analise em si do trade-off já dá pano para mangas dependendo dos vários cenários de deploy , constrangimentos de tempo e dinheiro e diretivas que a “sua emprea ficiticia” gostaria de seguir. Por exemplo, se seus clientes têm como pagar um banco para cada um, então esta opção é a melhor pois o custo está coberto. Caso aponte clientes mais modestos, uma das outras opções terá que servir, ou o seu modelo de negocio deve gerar fundos suficientes para cobrir os custos.

jonas.cant:

Interessante… não parece ser o bicho de sete cabeças.
Se eu fosse implementar esse modelo, com certeza eu faria com que cada inquilino tivesse um banco de dados próprio.

Vai por mim, são no mínimo umas 9 cabeças aí.

Hehehe… pois é, as vezes sou bastante otimista.
Só acho muito “esquisito” vários clientes no mesmo banco de dados, separando os dados apenas por ID… até digo que se isso já significa modelo multi-inquilino não é nada difícil.
Eu não vejo isso como uma boa prática, apesar de que pode ser bem mais simples de manter. Pensando na questão da segurança da informação e na performance do sistema (pensa ter 500 clientes tudo no mesmo bando de dados) eu creio que deixaria a desejar.

jonas.cant:

Hehehe… pois é, as vezes sou bastante otimista.
Só acho muito “esquisito” vários clientes no mesmo banco de dados, separando os dados apenas por ID… até digo que se isso já significa modelo multi-inquilino não é nada difícil.
Eu não vejo isso como uma boa prática, apesar de que pode ser bem mais simples de manter. Pensando na questão da segurança da informação e na performance do sistema (pensa ter 500 clientes tudo no mesmo bando de dados) eu creio que deixaria a desejar.

Quer ler algo muito bacana sobre este problema? Da uma pesquisada no Google nos artigos publicados pela equipe da SalesForce.com
Eles inovaram bastante nesta área, e passaram por situações como esta.

No caso de tabelas compartilhadas por múltiplos clientes, uma alternativa massa é o particionamento da tabela: cada usuário teria a sua própria partição, o que garantiria a segurança e também a performance (parte da perforamcne pelo menos) nas consultas.

Particionamento de tabela? :shock:
Confesso que é a primeira vez que leio isso. Vou pesquisar mais…

Oi Jonas, sim.

Tem bancos de dados que te permitem particionar a tabela. Este é um procedimento que consiste em armazenar a tabela em “pedaços”, que não necessáriamente estão no mesmo servidor.
Você define isto usando uma coluna específica para identificar a partição. NO caso, o “tenant_id” pode ser aplicado.

Aí, neste caso, toda consulta que tenant_id for 1, por exemplo, busca na partição 1, 2, partição 2, e por aí vai.
A grossíssimo modo é isto.

Muito interessante.
Bastante coisa pra eu pesquisar. Mas vamos lá…

desenvolvi um sistema de fidelização que é utilizado para vários clientes,
cada cliente possui sua base, mas o WAR é apenas um.
Criei um base para armazenar as informações de servidor de cada cliente, ai quando é realizado o login na aplicação o sistema consulta essa base e altera as configurações do hibernate dinamicamente…

AnnotationConfiguration cfg = new AnnotationConfiguration();
		cfg.configure()
		.setProperty("hibernate.connection.url", "jdbc:mysql://127.0.0.1:3306/cliente1")
		.setProperty("hibernate.connection.username","user")
		.setProperty("hibernate.connection.password","pass");

		sessionfactory = cfg.buildSessionFactory();

build_successful:

desenvolvi um sistema de fidelização que é utilizado para vários clientes, cada cliente possui sua base, mas o WAR é apenas um. Criei um base para armazenar as informações de servidor de cada cliente, ai quando é realizado o login na aplicação o sistema consulta essa base e altera as configurações do hibernate dinamicamente...

AnnotationConfiguration cfg = new AnnotationConfiguration();
		cfg.configure()
		.setProperty("hibernate.connection.url", "jdbc:mysql://127.0.0.1:3306/cliente1")
		.setProperty("hibernate.connection.username","user")
		.setProperty("hibernate.connection.password","pass");

		sessionfactory = cfg.buildSessionFactory();

Opa, da pra resolver este problema de forma até mais simples.
Basta que a sua conexão com o banco de dados seja obtida via JNDI.
Aí nem sua string de conexão precisa mudar. Basta você cadastrar um datasource no servidor com o nome que você programou no seu sistema.

kicolobo:

build_successful:

desenvolvi um sistema de fidelização que é utilizado para vários clientes, cada cliente possui sua base, mas o WAR é apenas um. Criei um base para armazenar as informações de servidor de cada cliente, ai quando é realizado o login na aplicação o sistema consulta essa base e altera as configurações do hibernate dinamicamente...

AnnotationConfiguration cfg = new AnnotationConfiguration();
		cfg.configure()
		.setProperty("hibernate.connection.url", "jdbc:mysql://127.0.0.1:3306/cliente1")
		.setProperty("hibernate.connection.username","user")
		.setProperty("hibernate.connection.password","pass");

		sessionfactory = cfg.buildSessionFactory();

Opa, da pra resolver este problema de forma até mais simples.
Basta que a sua conexão com o banco de dados seja obtida via JNDI.
Aí nem sua string de conexão precisa mudar. Basta você cadastrar um datasource no servidor com o nome que você programou no seu sistema.

Veja pesquise como funciona datasource do seu servidor, aí basta referir ao datasource.

Trabalhei em uma empresa que criou 3 sistemas, uma para cada área. Vendeu os 3, e os próprios clientes mantinham o banco de dados e o servidor web. A empresa tinha implantadores para ir até lá e ensinar as coisas e tal.

Mas conforme os clientes vão usando o sistema, eles começam a chegar a conclusão que precisam de um relatório diferente do que tem, de um relatória a mais para a situação X e outro para a Y. Dai a empresa atende as requisições do cliente e aos poucos o sistema que era uniforme para todos clientes, passa a ter mudanças especificas. No final, o mesmo sistema para vários clientes já não é mais exatamente o mesmo.
E sempre tentavamos colocar essas atualizações como parte das novas versões, mas começa um novo ciclo quando um novo cliente aparecia.

Então, acredito que manter base de dados separadas é mais viável, como também se possível, deixar isso por conta do cliente. Mas você também poderia oferecer a ele, como Hebert citou, a Jelastic ou outra, que forneçam o banco e o servidor para a aplicação, e você mesmo poderia gerenciar para o seu cliente. Mas misturar as coisas entre vários clientes não acho uma boa.

Lembrei do Microsiga, kkkkkkkkkkkkkk.

romarcio:

Trabalhei em uma empresa que criou 3 sistemas, uma para cada área. Vendeu os 3, e os próprios clientes mantinham o banco de dados e o servidor web. A empresa tinha implantadores para ir até lá e ensinar as coisas e tal.

Mas conforme os clientes vão usando o sistema, eles começam a chegar a conclusão que precisam de um relatório diferente do que tem, de um relatória a mais para a situação X e outro para a Y. Dai a empresa atende as requisições do cliente e aos poucos o sistema que era uniforme para todos clientes, passa a ter mudanças especificas. No final, o mesmo sistema para vários clientes já não é mais exatamente o mesmo.
E sempre tentavamos colocar essas atualizações como parte das novas versões, mas começa um novo ciclo quando um novo cliente aparecia.

Então, acredito que manter base de dados separadas é mais viável, como também se possível, deixar isso por conta do cliente. Mas você também poderia oferecer a ele, como Hebert citou, a Jelastic ou outra, que forneçam o banco e o servidor para a aplicação, e você mesmo poderia gerenciar para o seu cliente. Mas misturar as coisas entre vários clientes não acho uma boa.

Sabe qual é uma solução interessante para este problema? OSGi
Você implementa uma base como plataforma e possibilita a customização dos clientes a partir de bundles, que podem ser implementados pelo próprio cliente inclusive.
Isto resolve a parte do código fonte e lógica de negócio de uma forma inclusive bastante interessante.

Agora, com relação a dados… a coisa aperta. Tenho tendido pra uma abordagem schemaless neste caso por facilitar a solução do problema.

kicolobo:

romarcio:

Trabalhei em uma empresa que criou 3 sistemas, uma para cada área. Vendeu os 3, e os próprios clientes mantinham o banco de dados e o servidor web. A empresa tinha implantadores para ir até lá e ensinar as coisas e tal.

Mas conforme os clientes vão usando o sistema, eles começam a chegar a conclusão que precisam de um relatório diferente do que tem, de um relatória a mais para a situação X e outro para a Y. Dai a empresa atende as requisições do cliente e aos poucos o sistema que era uniforme para todos clientes, passa a ter mudanças especificas. No final, o mesmo sistema para vários clientes já não é mais exatamente o mesmo.
E sempre tentavamos colocar essas atualizações como parte das novas versões, mas começa um novo ciclo quando um novo cliente aparecia.

Então, acredito que manter base de dados separadas é mais viável, como também se possível, deixar isso por conta do cliente. Mas você também poderia oferecer a ele, como Hebert citou, a Jelastic ou outra, que forneçam o banco e o servidor para a aplicação, e você mesmo poderia gerenciar para o seu cliente. Mas misturar as coisas entre vários clientes não acho uma boa.

Sabe qual é uma solução interessante para este problema? OSGi
Você implementa uma base como plataforma e possibilita a customização dos clientes a partir de bundles, que podem ser implementados pelo próprio cliente inclusive.
Isto resolve a parte do código fonte e lógica de negócio de uma forma inclusive bastante interessante.

Agora, com relação a dados… a coisa aperta. Tenho tendido pra uma abordagem schemaless neste caso por facilitar a solução do problema.

Interessante essa ideia do OSGi. Ainda não tinha lido sobre isso.

romarcio:

Interessante essa ideia do OSGi. Ainda não tinha lido sobre isso.

Sabe o que te permite fazer isto também e todo mundo vira o nariz pra ele? PHP

Sabe o que te permite fazer isto também e todo mundo vira o nariz pra ele? PHPUhum. Com um tal de Joola? Ou coisa assim? Já ouvi falar.

Eu não viro o nariz não, apenas acho que Java paga mais dinheiros.
$.$

Mercenário não, afinal tenho que colocar arroz nas latas. [=

Ola a Todos, estou numa situação parecida com o “jonas.cant”,tentando aprender por fora oque nao aprende na faculdade,mostrando somente o basico"OO no java"!
Estou tentando obter informaçãos sobre OSGI para implementar meu TCC e trabalhar com varios bancos!
Queria saber se vc “kicolobo” tem algum material bom sobre Osgi q vc ja leu?

Obrigado Paulo!!

Achei muito interessante a conversa até aqui. Chegamos na página 4 sem ninguém ofender ninguém!!

Por muito tempo também fui muito a favor de uma base por cliente, mas não partiria para essa abordagem hoje em dia.
Com tanta forma de disponibilizar na nuvem um sistema, acho que o sistema se adaptaria automaticamente a carga, fazendo um melhor aproveitamento do hardware.
(Se estão em servidores separados, um cliente usa muito e outro pouco, para um fica lento e para o outro tem cpu não utilizada).

Imagine se para cada novo cliente no gmail, o google criasse um schema novo no banco (ou um outro banco) pra garantir segurança?

Sobre o OSGI, li pouco a respeito, mas vi muita gente dizendo que seria ótimo se não fosse tão complexo.
kikolobo. você que tem experiência com ele…é realmente tão complicado quanto dizem?
Para mim o fato de conseguir rodar duas versões de uma mesma classe e fazer hot-swap de módulos seria um enorme ganho.

AbelBueno:

Achei muito interessante a conversa até aqui. Chegamos na página 4 sem ninguém ofender ninguém!!

Por muito tempo também fui muito a favor de uma base por cliente, mas não partiria para essa abordagem hoje em dia.
Com tanta forma de disponibilizar na nuvem um sistema, acho que o sistema se adaptaria automaticamente a carga, fazendo um melhor aproveitamento do hardware.
(Se estão em servidores separados, um cliente usa muito e outro pouco, para um fica lento e para o outro tem cpu não utilizada).

Imagine se para cada novo cliente no gmail, o google criasse um schema novo no banco (ou um outro banco) pra garantir segurança?

Sobre o OSGI, li pouco a respeito, mas vi muita gente dizendo que seria ótimo se não fosse tão complexo.
kikolobo. você que tem experiência com ele…é realmente tão complicado quanto dizem?
Para mim o fato de conseguir rodar duas versões de uma mesma classe e fazer hot-swap de módulos seria um enorme ganho.

Opa, este papo do OSGi ser complicado é história pra boi dormir.
O que rola é o seguinte: no OSGi, você componentiza seu sistema em bundles.
Um bundle tem definidos quais os pacotes que serão públicos e visíveis para as demais partes do sistema.
Então, tudo o que não é público, o seu classpath não vai ver.

E cada bundle define quais as dependências que ele precisa pra funcionar.
Então, por exemplo: bundle A precisa do bundle Hibernate e Spring.

Como consequência, você tem de usar bibliotecas como Hibernate, Spring, etc.
Estas dependências já vêm com as principais classes que você tem de usar definidas como públicas, então não rola problema.

O grande problema é que o pessoal não lê pra saber como o trem funciona e, ignorando estas coisas simples, começa a reclamar de coisas do tipo: “tá dando ClassNotFound das classes básicas do Spring”. Aí… num tem mesmo como né?

Mas tirando isto, é uma arquitetura simples de entender quando você a estuda. O trem escala e ainda por cima é leve, muito leve.
E o mais legal é que você pode trocar o sistema com ele em execução de uma forma como nunca vi em nenhuma plataforma Java.

Infelizmente parece que o trem não pegou, porque não vejo sendo muito usado por aí.
Fazer o que né?

kicolobo:

AbelBueno:

Achei muito interessante a conversa até aqui. Chegamos na página 4 sem ninguém ofender ninguém!!

Por muito tempo também fui muito a favor de uma base por cliente, mas não partiria para essa abordagem hoje em dia.
Com tanta forma de disponibilizar na nuvem um sistema, acho que o sistema se adaptaria automaticamente a carga, fazendo um melhor aproveitamento do hardware.
(Se estão em servidores separados, um cliente usa muito e outro pouco, para um fica lento e para o outro tem cpu não utilizada).

Imagine se para cada novo cliente no gmail, o google criasse um schema novo no banco (ou um outro banco) pra garantir segurança?

Sobre o OSGI, li pouco a respeito, mas vi muita gente dizendo que seria ótimo se não fosse tão complexo.
kikolobo. você que tem experiência com ele…é realmente tão complicado quanto dizem?
Para mim o fato de conseguir rodar duas versões de uma mesma classe e fazer hot-swap de módulos seria um enorme ganho.

Opa, este papo do OSGi ser complicado é história pra boi dormir.
O que rola é o seguinte: no OSGi, você componentiza seu sistema em bundles.
Um bundle tem definidos quais os pacotes que serão públicos e visíveis para as demais partes do sistema.
Então, tudo o que não é público, o seu classpath não vai ver.

E cada bundle define quais as dependências que ele precisa pra funcionar.
Então, por exemplo: bundle A precisa do bundle Hibernate e Spring.

Como consequência, você tem de usar bibliotecas como Hibernate, Spring, etc.
Estas dependências já vêm com as principais classes que você tem de usar definidas como públicas, então não rola problema.

O grande problema é que o pessoal não lê pra saber como o trem funciona e, ignorando estas coisas simples, começa a reclamar de coisas do tipo: “tá dando ClassNotFound das classes básicas do Spring”. Aí… num tem mesmo como né?

Mas tirando isto, é uma arquitetura simples de entender quando você a estuda. O trem escala e ainda por cima é leve, muito leve.
E o mais legal é que você pode trocar o sistema com ele em execução de uma forma como nunca vi em nenhuma plataforma Java.

Infelizmente parece que o trem não pegou, porque não vejo sendo muito usado por aí.
Fazer o que né? :)

Bom dia pessoal !!!

Legal o post e principalmente a discussão até o momento.
Cheguei a colocar há algum tempo atrás um post como este, mas a discussão não foi tão boa infelizmente.

Estou terminando o treinamento de Java web na Caelum e vou começar a desenvolver um sistema com as características desse post, ou seja, um sistema único disponibilizado na nuvem e um banco de dados para cada cliente.

Lendo a discussão lançada até o momento não consegui visualizar qual a melhor opção… se um banco para cada cliente, se um banco único… de forma objetiva, qual seria a melhor opção?
Pergunto isso porque alguns momentos deste post deu a entender que a melhor opção seria um banco único… depois entendi que a melhor opção seria um banco para cada cliente e agora não entendi mais nada :lol: (brincadeirinha !!!)

jonas.cant:

Hehehe… pois é, as vezes sou bastante otimista.
Só acho muito “esquisito” vários clientes no mesmo banco de dados, separando os dados apenas por ID… até digo que se isso já significa modelo multi-inquilino não é nada difícil.
Eu não vejo isso como uma boa prática, apesar de que pode ser bem mais simples de manter. Pensando na questão da segurança da informação e na performance do sistema (pensa ter 500 clientes tudo no mesmo bando de dados) eu creio que deixaria a desejar.

eu vejo que tem bastante gente que está pensando em fazer isso, sistema multi - inquilino (não sou conhecedor desse assunto, aprendi esse termo lendo esse esse tópico)… sendo que cada um ficaria em um banco, mas ao invés de de pensar como nesse comentário ai que eu citei, vamos para o outro lado, o que está sendo sugerido, pensa em 500 clientes, cada um em um banco de dados, 500 bancos de dados… alguém acha que isso sairia barato? aliás, alguém acha que 500 bancos de dados com as tabelas do sistema precisariam de menos hardware do que um banco (ou 5, enfim, poucos) com 500 clientes? só para lembrar, a instancia do banco também pesa bastante… ao meu ver, essa não é só a solução mais seguro, é a mais simples, mais numa boa, sai muuuito mais caro.

Alguem sabe algum local ou otro site,que tenha grupo de discussão somente de OSGI em protugues?

Muito boa a discussão aqui! Vou dar minha opinião também.

Tenho um sistema multi-tenancy a mais de 1 ano em produção, e tenho uns 30 tenants funcionando perfeitamente, rodando postgre, tomcat e hibernate. Cada tenant é um schema diferente no postgre.

Eu utilizo interceptor para fazer a troca do tenant no hibernate, eu armazeno o tenant do cliente na sessão do jsf e pelo interceptor eu troco o tenant,

Ou seja, quando chega no interceptor a query gerada pelo hibernate select * from tenantpadrao.tabela ele troca para select * from tenantdocliente.tabela, FUNCIONOU PERFEITAMENTE ATÉ AGORA, nunca tive problemas de performance, nem queda do server, nem pico de processamento, nem de memória, nada…

Estou migrando para hibernate 4 que já tem o suporte nativo a multi-tenancy e não precisa da gambiarra do interceptor.

E eu ganho dinheiro com o uso mensal feito pelo cliente na versão padrão, evito ao máximo fazer implementações personalizadas(acho que não vale a pena pelo tempo se gasta implementando algo personalizado), quando o cliente realmente precisa da implementação, que eu não consiga escapar, eu faço a implementação, contrato um novo servidor, subo a aplicação com as implementações e disponibilizo para o cliente, e o custo dele aumenta já que o servidor está dedicado a ele.

Bom, este é meu cenário, eu sobrevivo com esta arquitetura ai.