| Autor |
Mensagem |
|
|
Seja mais específico.
Qual erro está lançando?
O que exatamente você está tentando fazer?
|
 |
|
|
Tchello wrote:
Finalmente, se usa EJB 3.0 o webservice deveria ser Stateless Bean e não haveria necessidade de ir do "EJB para o Webservice" . Basta expor o Bean como um webservice. Isso pouparia uma conversão.
Sim, o WebService é Stateless.
No meu projeto teste criei um modulo EJB onde tenho as Stateless SessionBeans, Entity Beans e o meu Stateless WebService, "deployei" tudo junto.
Mas o que você quis dizer exatamente com expor o Bean como um WebService? Estou sentindo que deixei escapar alguma coisa.
Opa, acho que já peguei o que você quis dizer!
Fiz um exemplo aqui onde o WebService É o SessionBean (ou vice e versa), diminuindo um nível provavelmente desnecessário.
Só pra complementar, eu posso implementar minha lógica de persistência com SessionBeans?
Levando em consideração que objetos puros assim já são Anti-OO Isso não entraria naquele conceito anti-pattern de objetos fantoches? FONTE: http://fragmental.com.br/wiki/index.php/Fantoches
Desculpem-me pelo monte de perguntas, preciso esclarecer esse conceitos pra que eu aprenda um dia o conceito verdadeiro de OO, EJB, WebServices, etc... ^^
Abraços!
Edit: erro de concordância.
|
|
|
|
Poxa, sendo assim vejo que peguei bem o conceito.
Achei realmente muito estranho nomearem as entidades com sufixo VO (PessoaVO, por exemplo), embora sejam entidades do WebService pra frente eles tem o comportamento semelhante ao de TOs.
Muita gente tem a mania de nomear as classes de entidades com a terminação VO ( "ClienteVO" , "PedidoVO"). Isto é uma imbecilidade.
Simples use o nome da entidade puro ("Cliente" , "Pedido"). muito mais simples de ler e entender.
Foi mais ou menos o que se passou na minha cabeça, sem usar o sufixo (erradamente).
Finalmente, se usa EJB 3.0 o webservice deveria ser Stateless Bean e não haveria necessidade de ir do "EJB para o Webservice" . Basta expor o Bean como um webservice. Isso pouparia uma conversão.
Sim, o WebService é Stateless.
No meu projeto teste criei um modulo EJB onde tenho as Stateless SessionBeans, Entity Beans e o meu Stateless WebService, "deployei" tudo junto.
Mas o que você quis dizer exatamente com expor o Bean como um WebService? Estou sentindo que deixei escapar alguma coisa.
Grato pela resposta, foi extremamente esclarecedora.
|
|
|
|
RobsonFagundes wrote:testarosa vc esta procurando um sistema com estas caracteristicas pra baixar ????????
cara do céu, isso ta parecendo ser trab de faculdade hehehehehhehe.....
eu faço pra vc hehehehehhe rapidinho .... se tiver interesse fala comigo por MP
T+
Foi exatamente por isso que dei aquela sugestão...
|
|
|
|
Tenho a solução definitiva pra você: quital implementar?
Qualquer algoritmo que faça uma busca em grandes arquivos, ou mesmo processamento de imagens como você mesmo já sugeriu.
Não é tão complicado. Você consegue.
|
|
|
|
ignacio83 wrote:Pelo que eu conheço, normalmente é um Entity por Tabela, existem casos específicos em que isso pode não ocorrer:
1) Herança: Mais de uma entidade pode representar uma única tabela. Pesquise por @Inheritance
2) Relacionamentos ManyToMany: Nesses relacionamentos a tabela do "meio" pode não ser uma Entity. Pesquise por @ManyToMany
Porém o contrário disso, um Entity representar mais de uma tabela, eu desconheço.
A sim, quanto a isso estou ciente.
Ontem mesmo fiz um mega estudo/review sobre os 7 tipos de relacionamentos.
Comprei o livro Enterprise JavaBeans 3.0 do O'Reilly (recomendo!) e tem me ajudado DEMAIS nesses conceitos, mas ainda pairou essa dúvida devido as discuções encontradas por aqui.
O que me deixou intrigado mesmo foi a aparente possibilidade de haver menos entidades do que tabelas (desconsiderando as relações @ManyToMany, onde a tabela intermediária é apenas "citada" como uma @JoinTable) não o inverso.
Com isso em mente pairou a pergunta: como persistir/trabalhar sobre os dados de determinadas tabelas que não tem entidades pra mapea-las?
Pra "ajudar" encontrei essas citações que coloquei no post inicial hehehe
Vlw!
|
|
|
|
Bom dia novamente caros colegas!
Tenho mais uma pergunta sobre EJB3.
Aos exemplos que tenho feito notei que sempre é criada uma entidade por tabela que tenhos na base relacional.
Porém fiquei curioso: é realmente necessário? caso falso, como eu trabalharia nas outras tabelas sem que houvesse entidades para mapea-las e SEM EJB QL e qualquer outra gambiarra? (ou seja, com recursos "oficiais" do EJB).
Pesquisei mais um pouco e encontrei esse material que diz:
3.6.3. Uma tabela por classe entidade concreta
Esta estratégia não é requerida em EJB 3.0, por isso não será abordada neste artigo.
Fonte: http://disciplinas.dcc.ufba.br/pub/MATA60/WebHome/persejb.pdf
Parou por ai,não deu mais explicações. Mas o que vi em outra fonte foi que isso era necessário antes do EJB3:
A tecnologia de mapeamento entre objetos e tabelas (Mapeamento Objeto-Relacional) do framework EJB até a versão 2.1 era precária e basicamente você teria um Entity Bean por tabela no banco de dados
Fonte: http://fragmental.com.br/wiki/index.php?title=Evitando_VOs_e_BOs
Caso eu faça uma entidade por tabela do base relacional, seria trabalho a toa, anti-pattern, estupidez ou pode ser realmente necessário?
Essa informação tem sido realmente mais dificil de ser obtida, por isso peço a opinião de vocês, colegas, que sempre mantém um alto nível nas discuções daqui. Sinto-me muito feliz de participar desse grupo.
Obrigado pela atenção galera, abraços!
|
|
|
|
Bom dia colegas.
Há algumas semanas me deparei com alguns desafios.
Tive que aprender EJB3 aqui onde trabalho (ainda aprendendo... diga-se de passagem) e mais algumas tecnologias como webServices, etc.
Ainda em fase de treinamento tive contato com um protótipo onde temos a seguinte estrutura:
Base de dados relacional;
Entidades mapeando essa base de dados;
SessionBeans acessando essas entidades;
WebServices disponibilizando essas funções pro sistema (acessado por Conteiners Web em máquinas remotas ou outra aplicação Desktop)
Acontece que na documentação as entidades estão especificadas como... VOs!
Como sou curioso resolvi pesquisar o que seria exatamente esse padrão VO.
Encontrei várias discuções pelo google, incluindo muitas aqui no GUJ de alto nível e o que notei foi uma grande divergência de opiniões, embora tenha sido bastante esclarecedor.
O que me deixou com a pulga atrás da orelha foi a classificação dessas entidades como VOs, pelo que li VOs seriam apenas objeto de armazenamento de valores (como o nome já diz...) e nem costumam ter setters, já entidades seriam uma classificação diferenciada, embora nenhum possuisse comportamento (o que fere OO, mas isso já é outra discução).
Enfim, essa classificação das EntityBeans como VOs está correta? Por que pra mim me parece mais um TO (transfer object) já que eles além de armazenarem valores servem também para o transporte disto através das camadas seja do EJB pro webService ou do webservice pra nuvem.
Um tópico que me auxiliou:
http://www.guj.com.br/posts/list/53305.java
Gostaria de saber se essa minha observação está correta e o que vocês tem a acrescentar, uma vez que embora eu acredite que tenha entendido o conceito ainda me ficou aquela dúvida de "será que entendi corretamente? será que eu aprendi errado?".
Desculpem-me por criar mais uma thread sobre isso, mas meu espírito não me permite ficar com essa dúvida.
Tenho mais perguntas depois... hehehe
Abraços e muito obrigado pela atenção!
|
|
|
|
Ta 99.90 na submarino com frete grátis, comprei semana passada.
Abraços.
|
|
|
|
|
Você pode definir como pagina inicial um index que chama a servlet que então chama essa sua página.
|
|
|
|
Cara, esse grafo ta muito bonitinho!!!
Assim que eu puder posto meu simulador aqui, que fiz pruma iniciação científica.
É bem simples, são alguns algoritmos de contenção de falhas em cascata sobre redes complexas (tema do meu TCC e futuro mestrado pré encaminhado =P).
Tive que fazer de última hora e ficou faltando muita coisa na interface, as configurações tem que ser mudadas direto no código (sério, tive uma madrugada pra implementar tudo, foi f* e o prazo curto não foi culpa minha, não dessa vez uhahuahuahuauhauha).
É bem simples, em apenas 2 dimensões representada em uma matriz dinâmica. O próximo será com grafos bem mais complexos com algoritmos mais elaborados de contenção e espalhamento de falhas.
Pra ter uma noção, a visualização do espalhamento das falhas lembra aquelas imagens de colônias de bactérias se proliferando (inclusive várias pessoas que o viram rodando perguntaram: que legal!! é um câncer? >_> .
|
|
|
|
Cara, parece muito interessante.
Valew pela dica, ta anotado.
|
|
|
|
Marlon Meneses wrote:tenho o mesmo problema com validadores de campos...
o cliente quer pq quer q salte uma janelinha e tals dizendo oq tah errado e blablabla
entao pra resolver isso eu fiz o tal do script d validacao e tambem fiz um codigo d validacao
assim fica mais segura pq se furar o script, o servidor barra!
entao recomendo q vc faça o mesmo!
O problema é ficar remendando cada requisito absurdo que surge, afim de que a bomba não exploda na sua mão.
Novamente a documentação fica sua amiguinha nesses momentos, culpa de quem colocou ali e não quis saber se você avisou quatrocentas vezes.
|
|
|
|
Se não der documente o máximo possível. Escreva tudo.
Se der merda você mostra tudo pra eles com um belo "eu avisei, vocês não quiseram saber e eu tenho que seguir os requisitos, certo? ema ema ema cada um com seus 'pobrema' ".
Simples assim, sério, tem situações que não vale a pena discutir muito com "gerente de requisitos" ignorante com mania de grandeza.
|
|
|
|
Lição do dia: g00gle é seu amiguinho, ele não morde e te ajuda sempre que você precisar ^^
Em suma: STFW.
|
|
|
|