Iniciando na programação J2EE

“Luckian”:

Olá pessoal !
Os dados, ao meu ver, não deveriam ter acesso assim, direto. Acho que deveria ter um outra camada, que controlaria o acesso do usuario, armazenando dados que dizem respeito do seu logon no sistema, etc. Isso está certo? Se estver, este session deveria ser statefull ( acho q sim )? Uma outra forma poderia ser o envio das informações de logon contínuamente ( pq o sistema poderia ser acessado via Web ou Desktop, atravéz do delphi )…

Não posso te dar esclarecimentos sobre a arquitetura com tão pouca descrição sobre o projeto. Sugiro que você investigue sobre Design Patterns.

“Luckian”:

Olá pessoal !
Outra questão é webservices… como o pessoal trabalha em sistemas assim com webservices… como eh feita a parte da segurança? Como não consigo ver essa parte, para mim, pelo menos, vejo apenas como uma saida de dados, nada que possa gravar no banco, etc… ( existem informações que não deveriam ser compartilhadas ) – A não ser que realize o envio de usuario e senha continuamente…

Não sei que nível de segurança você está esperando para WebServices. Quando implementei, usei os recursos de SSL fornecidos pelo meu servidor web (Tomcat).

“Luckian”:

Olá pessoal !
tah tudo parecendo um tanto precário, principalmente no quisito segurança…

Calma, meu amigo. Java é na verdade muito mais seguro que estas tecnologias que você usou. Não é àtoa que a maioria dos grandes bancos o adotam.

Sugestões para início dos estudos:

:arrow: The JavaTrademarked Web Services Tutorial # Security
:arrow: SSL via Tomcat

Vc pode colocar mais uma camada entre o Remote e o Entity…
ficaria assim…o cliente acessa o SessionRemote que acessa o SessionLocal que manipula o Entity.

Sim, vc pode criar uma camada entre o Remote e o cliente…é mais segura e vc estará implementando o Business Delegate.

Bom, dê uma olhada aqui…
segurança

é interessante tb baixar esse Demo e dar uma conferida…
PetStore

[]'s

na minha humilde opnião… pra q usar entity? heheheh, o treco é uma trabalheira total… aposto sempre as minhas fichas em uma interface DAO… seja com hibernate, ou sql puro como implementação…

o entity pode ser uma trabalheira…e realmente se não for feito um estudo de caso antes ele se torna uma dor de cabeça sem tamanho…
chavão = CMP é o mesmo que matar uma formiga com canhão…

Eu bato o pé…defendo o entity até o fim, desde que antes de adotar a arquitetura o projeto seja muito bem estudo afim de que justifica usar CMP…
e a autonomia do banco de dados…não se preocupar em escrever statements…melhor impossível.

[]'s

adoro discussões de alto nivel … eu diria mais diana, o CMP é dependente de container… bem, o certo é, a cada setter q tu chama em um CMP, ele faz um select no banco, e depois um update, e a cada getter ele faz um select…, isso é pra matar o desempenho… é claro q os containers tem esquemas pra driblar isso, mas ai é dependente do container… td bem, é transparente pra ti tb… mas ainda é uma trabalhera, e só se torna produtivo (q é a única variável q as empresas se preocupam) quando tu ta usando uma ferramenta q os faça… por ex, o JDeveloper, q é uma baita ferramenta… mas ai tu te prende a fornecedor…

:!: com XDoclet ele já se torna produtivo…não se compara…mas já elimina 60% do trabalho.

o mesmo é válido pro hibernate, ninguém merece escrever aquela porrada de xml… pessoalmente, eu ainda prefiro o bom e velho DAOzinho e seu sql por baixo… sei lá hehehe … pior se só tivessemos uma forma de implementação pra tudo né?

Com certeza…

[]'s

“Diana”:

o entity pode ser uma trabalheira…e realmente se não for feito um estudo de caso antes ele se torna uma dor de cabeça sem tamanho…
chavão = CMP é o mesmo que matar uma formiga com canhão…

Eu bato o pé…defendo o entity até o fim, desde que antes de adotar a arquitetura o projeto seja muito bem estudo afim de que justifica usar CMP…
e a autonomia do banco de dados…não se preocupar em escrever statements…melhor impossível.

[]'s

Acho que entaum tenho uma outra pergunta: Quando usar o CMP? Essa devisão depende do tamanho do projeto?

[]´s

Bom dia colega…

Como, vc viu as opiniões são diferentes, cada usa a tecnologia com a qual mais se adapta.

Dá uma olhadinha aqui, para que tu possa ter uma visão melhor dos EJB’s

EJB’s - Sun

Qualquer dúvida…post it!

[]'s

ola amigos, na minha humilde opniao se eh pra se utilizar entity pq nao BMP? pois CMP eu considero muito dependente e muito caixa preta embora seja mais facil de implementar. Se vc precisa de robustez e segurança acho BMP uma opçao senao classes DAO como ja foi dito aqui resolve muito bem o problema
falows

Com EJB 2.0, ninguém mais usa BMP…
Esse “controle maior”, na prática, não oferece benefício algum.

Estive pensando MUITO sobre a possibilidade de usar o DAO. Mas existe alguns pontos no projeto que dificultam a utilização do mesmo. Vou contar uma história sobre a empresa em q trabalho. ( e que vai explicar o pq o DAO fica dificil de usar aki )

Quando comecei a trampar aki, a uns 4 anos atras, estava sendo migrado para Delphi 5 um sistema implementado em Clipper 5.3. Na época, os “analistas” aproveitaram todo o conceito pré-existente, o que dificultou MUITO nosso trabalho. Os sistemas que não existiam já possuiam certa liberdade, e graças ao sucesso ( de implementação ) de alguns desses novos sistemas, alguns antigos foram reformulados para seguir akele padrão.
Esse sistema DEVERIA, inicialmente, ser independente de banco de dados, mas com o passar do tempo, para otiizar determinadas consultas, foram-se empregando recursos do Interbase/Firebird, tornando nossos sistema dependente apenas desses bancos. ( A própria empresa decidiu ignorar o resto ).
Detalhe: Esses sistemas não são para um cliente específico, mas para vários clientes ( Prefeituras, etc ).

Acontece que isso dificulta, hj, a entrada de cliente muito grandes, que normalmente já possuiam uma solução anterior usando Oracle ou MS-SQL. - que pela lei de responsabilidade fiscal, não podem simplesmente colocar na prateleira e começar a usar outro banco.

Por isso mesmo, hoje não vejo uma solução a não ser utilizar os Entities, por fornecer algumas opções “extras”, como:

• alteração transparente do banco de dados;
• a possibilidade de Clusterizar servers J2EE, caso seja necessário aumentar o desempenho,
• Implementação de determinados recursos serem realizados extra-banco, sem necessidade de tanta programação, já que o conteiner já realizaria parte do trampo.

Claro, usando o DAO, poderia simplesmente programar um DAO para cada banco utilizado, mas não confio que a empresa ira disponibilizar pessoal caso ocorra a necessidade, e nossos recursos - humanos ou não - já estão bastante limitados ( 6 programadores apenas - o resto estah envolvido com o projeto antigo ).

Para vcs terem uma ideia, nem mesmo um profissional mais experiente tivemos acesso, e tudo o que foi feito foi realizado atraves de pesquisas e estudos de parte do pessoal que antes programava em Delphi.

Uma outra questão que tenho duvidas ainda eh QUANDO eh melhor trabalhar com o entity ao invés do DAO? ( Termos de desempenho ) existe algum lugar onde possa ver uma especie de curva com o desempenho de ambos os metodos em função do volume de dados ou coisa parecida? Por naum ter uma parametro como este, os pontos acima citados me fazem achar que a melhor solução continua sendo os entities…

[]'s pra todos e MUITO OBRIGADO!!!

o hibernate sendo utilizado como implementação de um DAO tb te ajudaria no caso de ser independente de banco, mas o melhor motivo de se usar entity q tu (Luckian) disse é o fato de poder clusterizar… isso é ótimo, mas até q ponto isso é possível de se fazer, sem que haja dependencia com o servidor de aplicação? hehehehe, isso chega a deixar a gente louco né, de um lado tem que fugir da dependencia de banco, do outro, da dependencia de servidor de aplicação… hehehe , mas estou adorando este tópico, conteúdo de altíssimo nível

Bom, quanto ao nosso caso, a troca de Servidor de aplicativos parece MUITO mais remota, pois no nosso campo de trabalho, existem poucas soluções J2EE. E hoje, acredito que se uma prefeitura tiver opção, irá optar por um servidor gratuito, mesmo pq os q temos hoje em dia são de altíssima qualidade. Eh mais facil convencer a trocar um servidor gratuito por outro que dizer pra eles trocar e depois explicar o pq pro Tribunal de Contas

Qto ao hibernate, um ex-colega nosso ( agora estah trabalhando em Brasilia no BB, com J2EE ) nos disse que existem alguns problemas com ele, de acordo com o volume de dados… Preciso entrar em contato com ele, pois faz tempo q tivemos essa conversa e agora jah naum lembro mais dos problemas…

Voltando agora ao servidor… no caso de servidores diferentes, a dificuldade naum seria apenas na configuração? Ateh hoje apenas trampei com o JBoss, e estava pensando em realizar alguns testes com o geronimo, mas pela falta de tempo ( o tempo extra-trampo estou estudando pra certificação java-programmer ), estou adiando…

[]´s

tb nunca trabalhei com nada sem ser JBoss, é oq leio por ai, de que é difícil portar EJBs entre servidores… Na minha opnião, isso é até um problema da especificação EJB, que não define exatamente oque um servidor tem q ter pra suportar EJB, do contrário, não seria necessário ter um XML nativo de cada container, e não existiriam implementações tão distintas… por ex, não lembro quem me falou, q no JBoss um EJB stateless era interpretado exatamente como um statefull… não lembro se era isso, mas era algo assim… :roll:

Bem , vou contar o meu empenho e da empresa na transformacao de Delphi para J2EE

Aqui decidimos usar Entitys CMP , e comecamos a transferencia , tive uma grande surpreza em saber que MUITA COISA que EJB oferece depende MUITO de container pra container , a sintaxe eh diferente , os .XML proprietarios sao um com cada cara mais lazarenta que o outro , porem algo muito interessante eh que em suma mairia de recursos ( cluster , cache , CMP , cache invalidation , etc ) é presente em 90% dos bancos detentores da marca J2EE 1.4 , esse negocio de dizer q vc codifica apenas uma vez e sair correndo gritando “FUNCIONA EM TUDO , FUNCIONA EM TUDO” eh pura BALELA , eh o maior PEGA TROUXAS DA ESTORIA, usar Entitys CMP eh complexo e trabalhoso ( para nos compensou muito prq todo mundo hj fala uma soh lingua ) , o Jboss tem uma forma LAZARENTA de fazer campos CMR , maldito seja o cara q implementou aquela porra de jboss-cmp.xml , levamos uma semana INTEIRA pra fazer um relacionamento 1:n nessa merda prq ele “tem um jeitinho soh dele de fazer isso” , e prq a documentacao eh uma porcaria tambem…

Mas compensa ainda mais se vc for fazer integração de outros sistemas da empresa , exemplo um sistema de CAIXA controlando diversos outros sistemas , isso fica transparente… todo mundo fala a mesma lingua… eh uma COISA LINDA ! , e quem ganha ? o cliente… prq nao vai ter mais aquelas incompatibilidades bisonhas…

A especificação é FALHA em muitos quisitos , porem , eh um padrao e deve ser seguido, antes contratavamos profissionais e levava uns 5 meses pra ele comecar a produzir de verdade , entender nosso codigo , ter seguranca no que faz… hj … procuramos a marca "CERTIFICADO EM J2EE 1.4 " e pode contratar que o cara dah conta… isso nao tem preco…

Uma coisa q me dah arrepios eh apenas o Jboss , nao gosto e soh uso prq o geronimo AINDA nao tah bom…

O pessoal que diz que o Conteiner EJB eh uma caixa preta nao deveria nem tar programando em java , afinal… a JVM nao eh caixa preta ? se esse pessoal soubece o que a JVM faz para driblar bugs de processador e outras coisinhas a mais nao falariam que ter uma “CAIXA PRETA DENTRO DA ESPECIFICACAO E PADRAO MUNDIAL” eh problematico…

Pensamos em usar o HIBERNATE aqui , porem… nao eh da especificação , ae sempre teriamos que ir atraz de um cara que eh CERTIFICADO em J2EE1.4 E QUE SAIBA HIBERNATE… e que goste de usar vetores de um lado pra outro

EJB-QL eh uma porra velha… nao faz nem 1 % que o SQL faz… MAS , se eu quisesse continuar programando com SQL eu nao usaria algo Objeto Relacional certo ? afinal uma QUERY SQL volta um ResultSet , uma query EJB-QL volta um OBJETO.

E a luta continua companheiro HEHE

Espero ter contribuido… abracos

hahaha, o chun quase teve um ataque heaheahea, mas realmente, eu concordo com tudo… em especial que a especificação é falha…

Pessoal, valeu msm pelas opinioes… ha alguns dias atras, jah tava desiludido… mas agora lah vejo uma luz no fim do tunel. Apesar de coisas como “100% na especificação, 100% fora do prazo” ( na verdade isso naum rolou aki, mas vi em outro Forum, inclusive com a participação do amigo Chun ), acho q o CMP, pelo menos neste caso, vai ser nosso caminho mesmo. Não soh pelo volume de infomações, mas a propria complexibilidade do mesmo. Nosso produto Delphi, hoje, tem cerca de 20 sistemas, todo integrado. Como são feitos por equipes distintas, vcs podem imaginar o babaio de gato :). Eh claro, tem um core compartilhado por todos - principalmente a parte de auditoria e controle de acessos, mas tbm ha muita coisa replicada, cada um escrevendo de maneira propria e sem muita padronização. Felizmente, a curva de aprendizado eh mais rápida - cerca de 2 meses no máximo pro ingressante começar a produzir.
J2EE estah sendo trabalhoso, soh sentimos falta de maior apoio - por parte da empresa - que reluta em contratar, mesmo q temporariamente, um profissional com mais experiencia na area para nortear o novo projeto. Tah certo, muitos aki são autodidatas - como a maioria dos programadores - mas como esperar q aprendam todas as especificações do dia pra noite? Assim, cada um procurou pesquisar determinadas areas e repassar o conhecimento adiante, Com a pratica da XP, facilitou MUITO essa dissiminação, mas mesmo a XP aqui eh novidade - na verdade foi implantada juntamente com o java, por nossa propria iniciativa.
bom, a luta continua ( MESMO )
[]'s a todos…

P.S.: Ei, não parem de postar… qto mais opinioes, melhor Garanto q vao estar ajudando outro com os mesmos problemas
Assim q pegar mais experiencia, pretendo postar RESPOSTAS, e nem soh PROBLEMAS

“vinci”:

Com EJB 2.0, ninguém mais usa BMP…
Esse “controle maior”, na prática, não oferece benefício algum.

Vc tá louco? Bebeu?
Vai estudar mininu!!!