Voce estah falando de constantes ou enums? Em qualquer um dos casos, nao hah restricoes por parte do genesis. Agora, se estiver trabalhando com variaveis estaticas quando deveria usar enums, seria melhor usar enums mesmo, que sao fortemente tipadas.
[quote=RaulCarlin]Só complementando, são todas variáveis final, NUNCA irei alterar…
Acho que isso que vocês deviam estar pensando né… NUNCA ocorrerá de meu servidor e meu objeto serializado no cliente tratarem valores diferentes, serão sempre os mesmo…[/quote]
Hmm, sao constantes entao. A pergunta eh: deveriam ser enums?
Poderiam…
[quote=Luca]Olá
Não entendi bem onde você discordou de mim e por isto tentarei me explicar melhor.
[/quote]
Releia os posts e entenderá. Vc criticou alguma coisa usando alguma argumentação. Eu invalidei sua argumentação.
Propaganda?!? Pensei que vc estava falando de uma solução com HTTP/servlets.
Sim, isso eu sei. O que tem a ver com a discussão!?
O que te faz acreditar que uma solução com HTTP\servlets é menos acoplada!? A que tipos de acoplamento vc se refere!? Pense bem para responder.
[]s
Olá
Taz, continuo sem entender sua contestação e seus posts não a explicam. Por exemplo: como uma aplicação .NET acessa um EJB engine?
Soluções usando servlets são MUITO mais desacopladas do que soluções usando EJBs, principalmente porque se pode trocar com facilidade o servidor de aplicação. Exemplo: o Banco Postal foi desenvolvido sobre o Tomcat e na produção foi para o WAS com facilidade sem alterar uma única linha no jar. Em demos fizemos ele rodar igualmente fácil no JBoss e no jetty também sem alterar uma linha. As chances de isso acontecer quando se usa EJBs no cliente são mínimas.
A lembrança de SOA x Web Services foi por questões de completitude do meu post e para evitar que outro alguém o fizesse.
E sobre propaganda, é mais uma observação que não entendi. Apenas citei um framework Open Source que pode ser adequado neste caso.
<editado>
[color=darkred] Sobre este seu pense bem para responder, solicito que me trate com o mesmo respeito que eu lhe trato.
Obrigado[/color]
</editado>
[]s
Luca
Olá…
Reiniciando a discussão inicial: vi vários (vários mesmo) posts ordenando repetidamente e expressamente: “mantenham o banco fora da rede”, “faça um servlet”, “faça um webservice”. Mas nunca o porquê.
É realmente tão perigoso assim manter um banco de dados online?
Mesmo configurando senhas e permissões corretamente, lidando com um número limitado e baixo de clientes e estabelecendo uma conexão remota sobre SSL com o BD, enviar a camada de acesso a dados (eg: hibernate/DAOs) via java web start junto com a camada de visualização/controle continua sendo uma solução tão porca assim?
Olá
O banco pode estar em qualquer lugar. No desenvolvimento ou nas demos ele pode ficar na mesma máquina. Em produção pode ficar na rede local ou em um data center externo.
É bem fácil mudar o banco de lugar caso a aplicação seja escrita com esta separação. Com servlets se consegue isto.
Já quem escreve código no lado da camada de apresentação que acessa ao banco de dados fica eternamnte confinado na rede local. Se amanhã aparecer um outro cliente para a aplicação que tenha filiais, ele presisará ser reescrita. Melhor fazer da primeira vez já separando as responsabilidades.
[]s
Luca
Certo, mas por que precisará ser reescrita para funcionar via internet? É isso que não entendo… ao meu ver, seja via internet ou via rede local, fazendo uma conexão remota sobre SSL ao DB… qual o problema?
(sim, eu sei da limitação no número de acessos simultâneos… mas tem algo além disso?)
Olá
Experimente. Verifique a performance. Compare os protocolos de rede. Para sentir melhor o drama, adquira um Oracle com 5 licenças.
E procure ler sobre as vantagens de se ter o acoplamento mais fraco possível.
[]s
Luca
Olá…
Bom, primeiramente, obrigado pela paciência em responder. 
Eu entendo as vantagens de um baixo acoplamento… mas veja, se a aplicação usa hibernate, já esta independente de BD. Só não estou conseguindo é ver um motivo forte o bastante para justificar a adição de mais uma camada na aplicação (os servlets no servidor, URLConnection no cliente), se o driver do banco de dados resolveria isto [buscar os dados através da internet ou rede local].
Desculpe, mas estou meio sem tempo pra poder testar… é possível me dar alguma idéia de como seria a diferença de performance ao usar conexão remota ao BD, sobres SSL, ou usar servlets conectados localmente? De fato, não faço a menor idéia… nem conheço o protocolo que o driver usaria.
Denovo, obrigado pela paciência hehe.
(obs: não entendi o comentário sobre as licenças Oracle)
Olá
bzanchet, repare que eu não falei em independência de BD.
Leia o livro de patterns para integração de sistemas do Gregor Hohpe. No próprio site dele há bastante material. E ele já escreve sobre isto há bastante tempo.
[]s
Luca
[quote=Luca]
Em princípio não gosto de EJBs no cliente por 2 motivos:
- Complica o desenvolvimento e necessita de codificador mais experiente
- Necessita de servidor que entenda um protocolo de EJBs que são estranhos para outras aplicações não baseadas em EJBs
[]s
Luca[/quote]
Se não me engano, o JBoss tem um invoker para SOAP ou Corba… mas… alguém ja utilizou?
Olá
E para que serviria um invoker do JBoss para SOAP ou CORBA?
Não sei bem o que eu poderia fazer com um invoker do JBoss, mas acho que SOAP e CORBA são muito diferentes para que o JBoss tenha algo SOAP ou CORBA.
[]s
Luca
Eu tou pra ver uma aplicação feita em Hibernate que não precise em algum momento de algum comando SQL nativo do banco, mandando a independência do BD pro lixo.
Hoje em dia, eu não uso nem mais esse argumento pra falar sobre Hibernate (independência de BD), falo somente das vantagens de trabalhar com objetos etc. Independência de banco de dados seria lindo, mas não se consegue - principalmente quando o banco já ti fornece modos bem mais fáceis de fazer algumas coisas.
Preste atenção, sua pergunta já foi respondida. Eu disse “O uso de uma Arquitetura Orientada a Serviços (SOA) pressupõe a coexistência entre quaisquer protocolos/plataformas/linguagens no parque de software de uma organização.” Além disso, sua pergunta foge do assunto. Não foi esse o problema apresentado. Não invente requisitos.
Se vc usa servlets, continua acoplado a um servidor Web. Qual a diferença!?
Onde há desrespeito!? Não fique bravo. Apenas propus uma reflexão.
Olá
Pois foi foi exatamente o que eu escrevi. Está la: " Mas sei de gente que usa EJBs no cliente com muito sucesso. Só não sei se eles continuarão felizes se um dia sua arquitetura mudar para SOA e outros clientes precisarem acessar seus serviços. "
E se você respondeu que vão deve saber como um cliente .NET pode acessar um EJB engine.
De novo foi grosseiro. Não me considero capaz de responder no mesmo nível.
[]s
Luca
E essa!? Não responde também!?
Olá
[quote=Taz]
E essa!? Não responde também!?[/quote]
Já foi respondida com o exemplo que dei do Banco Postal que rodava em vários servidores diferentes sem alterar uma linha sequer no código. Na producão usa WAS, mas foi desenvolvido com Tomcat ou JBoss e eu executei várias vezes com o Jetty.
[]s
Luca
[quote=Luca]
E para que serviria um invoker do JBoss para SOAP ou CORBA?
Não sei bem o que eu poderia fazer com um invoker do JBoss, mas acho que SOAP e CORBA são muito diferentes para que o JBoss tenha algo SOAP ou CORBA[/quote]
O JBoss vem com invokers CORBA (baseado no mapeamento padronizado Java-IDL), JRMP e Http. Este último simplesmente serizaliza o objeto Invocation (que carrega as informações do método a ser chamado) dentro de um POST.
Também tem o projeto JBoss remoting, que eu não conheço.
Olá
Obrigado Rafael, eu não tinha idéia sobre o que era isto. Já tinha ouvido falar nos invokers do Spring (acho que em uma palestra do Urubatan) mas também nunca usei.
Como estou envolvido com web services e integração de aplicações, acho que teria obrigação de saber um pouco sobre isto. Vai para a lista. :oops:
[]s
Luca