| Autor |
Mensagem |
|
|
Fala Kenobi,
Obrigado pela resposta. Mas eu nem penso em criar os wsdls manualmente. Vamos usar o que o JAX-WS gera mesmo. Na verdade, esse é um motivos da mudança.
Sobre o Aqualogic, ele é responsabilidade de outra equipe. Como é uma grande empresa, é interessante mudar as coisas devagar, para não causar muito impacto. Mas concordo, seria bom se tudo fosse feito da forma certa... he he
vlw
|
 |
|
|
Fala jeangos,
Obrigado pela resposta. Na verdade concordo contigo, mas é que aqui usamos um ESB Weblogic antigo, e para pendurar os serviços eu preciso subir o WSDL nele. Agora que estamos usando JAX-WS, a equipe de produção reclama que precisam subir o WSDL e vários xsds... Entendeu a pressão? rs rs
Nós estamos tentando mudar o menos possível do processo, mas é claro, isso é uma melhoria no processo.
Se encontrar algo, posto aqui.
valeu
|
|
|
|
Fala jeangos,
Acabei de abrir um tópico justamente sobre isso:
http://www.guj.com.br/java/233245-jax-ws-xsdimport#1200298
Existe alguma forma forçar com que o xsd fique dentro do wsdl?
valeu
|
|
|
|
Fala galera,
Estou criando um serviço com JAX-WS no Weblogic11. Ele funciona perfeitamente, entretanto gostaria de colocar todos os xsds das entradas/saídas junto ao wsdl. Hoje isso não acontece, ele usa o xsd:import para isso, separando o xsd em um arquivo diferente. Alguém sabe se é possível fazer essa junção usando anotação?
Esse é o trecho do xsd:import:
Este é o webservice:
valeu
|
|
|
|
maior_abandonado wrote:bom... o que eu pensei quando citei EJB seria facilitar o controle de threads, você ter um pool de objetos para usar ao invés de ficar instanciando a medida que vai usar, eu não conheço essa parte, mas parece que EJB facilita um pouco a clusterização também.
Quanto a usar IO em EJBs, eu pensava que isso fosse desaconselhado, e não que fosse não permitido, acreditava que fosse desaconselhado pelo fato do servidor criar threads de acordo com a necessidade, então se essas threads acessarem arquivos, você não terá muito controle sobre quantas threads estarão ou não acessando algum arquivo em si, isso seria uma coisa a se levar em consideração e tomar certo cuidado com sincronização por exemplo...
Perfeito, as considerações sobre EJB estão corretas.
Quanto as restrições, você não deve fazer. Mas você consegue... O container pode ter mal funcionamento, é um risco que você vai correr.
http://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html
|
|
|
|
maior_abandonado wrote:eu não sou nenhum expert no assunto, posso estar falando bestera mais... vc chegou a analisar colocar esses processos em arquivos em ... EJBs?
não sei se intendi direito...
O EJB seria uma opção, se fosse permitido ler arquivos com ele. A especificação diz que não se deve fazer isso, pois é o container deve gerênciar todos os recursos, acessos a dados, threads, etc.
|
|
|
|
Bom, incialmente você poderia tentar usar um pool de conexões, para gerênciar melhor suas conexões com o banco de dados.
Também poderia verificar se as api de leitura de arquivos está sendo usada corretamente. Trocar algumas classes para nio, caso não esteja usando.
Outro ponto é que as vezes o teu hardware pode estar no limite. Talvez pensar em melhorar ele. Fazer um cluster, etc.
Eu siceramente não acredito que sejam as "Threads", mas sim I/O dentro delas.
Sobre RPC, ou RMI (implementação Java), é para fazer computação distribuída. Talvez pensar em alguma implementação para distribuir esse processamento em várias máquinas, que é o caso do cluster que foi sugerido.
|
|
|
|
A pergunta se refere a web ou desktop?
Bom, no caso da web, normalmente o browser se ocupa de fazer cache de imagens, javascript, etc.
Acredito ser possível também desenvolver algo, provavelmente em javascript.
Em desktop, é possível fazer, claro. Pode-se usar um banco de dados local (hsqldb, derby, etc), armazenar as informações e transmitir em algum momento quando houver conexão.
Mas eu particularmente acho cache no lado do cliente um pouco complicado de gerênciar na web, caso você desenvolva algo. Já no caso de ser uma aplicação desktop, é o caminho comum, armazenar informações localmente. Nem chamaria de "cache".
De qualquer forma, a vantagem do cache é o ganho de velocidade para o cliente, cosumo de menor quantidade de recursos do servidor, escalabilidade, etc. Já a desvantagem é a de ter dados velhos, caso seja mal gerênciado, complexidade maior, etc.
|
|
|
|
|
Que eu saiba, você deve definir um layout para que os componentes redimensionem corretamente. O layout null só é interessante quando teu frame não for redimensionavel.
|
|
|
|
Na minha opinião, para saber aonde melhorar, você deve saber aonde é preciso melhorar. Por isso, use um profiler, encontre aonde estão os gargalos.
Sobre o Quartz, não acho que ajude no teu caso. Thread me parece ser mais adequado.
|
|
|
|
javando wrote:Oi gente, faz tempo que eu nao pergunto nada hein rs
Eu tava dando uma olhada em AOP, fazia um tempo que eu não mexia e comecei a me questionar sobre em que momento usar aspectos.
Sei que não é a mesma coisa, mas interceptadores em EJBs fazem a trabalho adicionar tarefas antes, depois e ao redor ed um método ou de uma transação por exemplo.
Se não tiver usando um servidor de aplicação, pode-se usar os recursos do Spring do Seam que trazem opções de execução antes ou depois de um bean e tals
No caso de banco de dados, tem os listeners do hibernate (caso esteja usando) que também faz esse tipo de coisa, adicionar funções de foma modular em metodos existentes.
Agora, visto essas "opções acima", como identificar se devemos usar AOP ou outro tipo de interceptação de outro framework?
espero q eu tenh oconseguido explicar minha dúvida :S
brigadão gente
Na minha opinião existem dois casos:
1- Quando você não tem opções, por exemplo, você está usando hibernate, mas não está EJB. Você vai usar Interceptor ou Listener do hibernate? Ou seja, você não vai colocar EJB em um projeto que já está funcionando apenas para usar Interceptor. Você resolve de outra forma.
2- Quando você tem opções, por exemplo, você tem hibernate e EJB no projeto. Nestes casos eu prefiro colocar o mais próximo das regras de negócio. Acho que é a melhor camada para colocar esses "serviços".
|
|
|
|
Respondo: Usando @XmlElements:
By: Valter Neto.
|
|
|
|
Fala Galera, blza?
Alguém já precisou "customizar" um wsdl usando JAXWS/JAXB? Eu uso as annotations, para coisas simples funciona que uma blza. Mas agora preciso fazer um "xs:choice" no WSDL, e não encontrei uma forma de fazer isso?
vlw
|
|
|
|
Zaperjava wrote:Pessoal , estou com duvida em relação aos DAO's em um projeto EJB .
Devo eu fazer a camada DAO dentro de um projeto EJB ?
Se eu fazer o DAO como ela não é bean eu perderia o controle do container ( Perdendo IOC , CMT , Injenção de depedencia , etc ... ) . Por outro lado ganharia separando a regra de negócio com DAO .
Uma solução que eu pensei e gostaria de saber se está certo é denotar todos os DAO's como @Stateless e @Local e injetar eles como @EJB dentro do meus beans verdadeiros .
Isso está certo ?
Bom, existem várias formas. Depende de cada caso. As principais são:
* Injetar o Entity Manager no EJB e usar diretamente, sem fazer a DAO;
* Fazer a DAO como se fosse um EJB (que é sua dúvida se está certo fazer isso. Na minha opinião, está sim)
* Pode injetar o Entity Manager no EJB e passar ele no construtor de uma DAO;
Mas qual é o propósito do sistema, os requisitos? Realmente é necessário fazer DAO? Usar o EM diretamente não satisfaz o teu caso?
|
|
|
|
tnaires wrote:
pozzo wrote:Então, no teu caso eu acho melhor implementar o padrão 'Observer' (que inclusive é utilizado em EJB MDB Topic). Mas na minha opinião, EJB não é a melhor forma, pois você precisa que seja tempo real e o MDB não garante isso. E também porque não é legal fazer comunicação socket com um desktop dentro do MDB.
Sobre ficar fazendo refresh em uma tabela, não parece ser a melhor forma também, pois vai consumir muitos recursos.
Por isso, na minha opinião, eu faria uma implementação 'comum' de Observer ( http://en.wikipedia.org/wiki/Observer_pattern).
Náo precisa ser um MDB. Bastaria apenas o session bean que faz a persistência enviar uma mensagem para os clientes de forma assíncrona. E seria em tempo real sim. Tão logo os clientes recebessem a mensagem, eles fariam o refresh nos dados.
Se ele utilizar Observer como você sugere, ele acabará reinventando um serviço de mensageria...
Entendi que você havia dado a sugestão de EJB, quando você disse: "Se sua arquitetura utilizasse Swing + EJB". Mas concordo contigo, usando JMS apenas, acho que ficaria legal. Sendo que cada cliente swing seria um 'cliente/servidor jms'.
Mas, apesar de 'reinventar a roda' na implementação do Observer, acho que ficaria bem simples no caso dele. Na minha opinião, em alguns casos uma solução mais simples pode ser melhor.
|
|
|
|
|
|