Sistema Web para Múltiplos Clientes

Front-end
#41

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.

#42

Lembrei do Microsiga, kkkkkkkkkkkkkk.

#43

[quote=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.[/quote]

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.

#44

[quote=kicolobo][quote=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.[/quote]

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.[/quote]

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

#45

[quote=romarcio]Interessante essa ideia do OSGi. Ainda não tinha lido sobre isso.[/quote]Não sei se você já trabalhou com o Jira, mas ele é totalmente modular. É possível criar módulos e adicionar sem precisar parar o projeto principal. [=

#46

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

#47

Sabe o que te permite fazer isto também e todo mundo vira o nariz pra ele? PHP[/quote]Uhum. 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. [=

#48

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!!

#49

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.

#50

[quote=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.
[/quote]

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é? :slight_smile:

#51

[quote=kicolobo][quote=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.
[/quote]

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é? :)[/quote]
Sabem se esse OSGi é similar ao MEF do .NET? (http://www.macoratti.net/12/02/net_mef1.htm).

#52

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

#53

[quote=jonas.cant]Hehehe… pois é, as vezes sou bastante otimista. :smiley:
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.[/quote]

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.

#54

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

#55

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.

#56