Definir consumidor para mensagem (JMS)

Pessoal,

Seguinte, tenho uma aplicação distribuída, que contém um servidor de mensagens em comum, um dos módulos posta as mensagens que devem ser consumidas pelos mesmo requisitores, qual a maneira em se definir que apenas o cara que requisitou a ação que postou a mensagem vai consumí-la?

exemplo prático… uma tela onde se seleciona algo, uma identificação desse item é postado na fila, na pagina seguinte, a mensagem sera consumida para gerar os dados a partir desse identificador, mas podem se tem várias chamadas simultâneas a essa tela que consumirá a mensagem, como fazer?

Valeu!

Uma solução correta seria Point-to-Point Messaging ?

Eu li, e reli umas 3 vezes e nao entendi muito bem o que quer fazer… esse processo que vc roda é pesado? se nao for, qual seria a necessidade de ser assincrono?

JMS Message selectors podem te ajudar

Eh verdade… uma vez eu fiz isso para um cliente só pq ele (e quem vendeu) achavam JMS bonitinho entre a interface e os componentes de negócios. Qual a vantagem em fazer uma invocação síncrona trabalhar assincronamente!?? Acredito que JMS nessa situação tenha mais overhead que RPC…

PS: Não estou questionando a validade de comunicações síncronas por JMS sistema x sistema

É isso mesmo!

No seu MDB você coloca um MessageSelector:

@ActivationConfigProperty(propertyName=“messageSelector”, propertyValue=“application=64”)

Com um par/valor. Neste meu caso, apenas as mensagens cujo application seja o 64 serão recebidas.

Daí no seu código que você envia a msg vc faz:

message.setStringProperty("Application", "64");

[]'s

É isso mesmo!

No seu MDB você coloca um MessageSelector:

@ActivationConfigProperty(propertyName=“messageSelector”, propertyValue=“application=64”)

Com um par/valor. Neste meu caso, apenas as mensagens cujo application seja o 64 serão recebidas.

Daí no seu código que você envia a msg vc faz:

message.setStringProperty("Application", "64");

[]'s[/quote]

pensando melhor, ele precisa de algo mais dinamico…

não sei se tem como setar dinamicamente as propriedades do seletor… se hj nao fosse sexta eu ate pesquisava um pouco mais hauheua

[]'s

Valeu pelas mensagens amigos…

vou falar de maneira mais clara pra ver se ajuda melhor… rs

o sistema A exibe uma tela de itens… ao clicar em um item, sera enviado usuario e senha de quem esta logado, isso mesmo, e tbm o id do item… tudo para o sistema B (que pode estar em qualquer lugar), esse sistema B vai pegar esses dados, ir até um BPM e buscar os dados para exibir os detalhes do item selecionado, não existe um banco de dados para guardar nada.

O grande enrosco é essa passagem dos dados do usuário… e como disse, vairas pessoas podem estar selecionando itens no sistema A, e elas precisam vizualizar os dados que elas “enviaram”, abre-se uma nova janela chamando o sistema B, e assim ocorre o fluxo.

Complicado pra caramba rsrs… não me perguntem o pq de nada pois eu não defini isso, estou apenas implementando a solução rs

valeu!

Porque optaram por uma solução assincrona de consulta ao sistema B?

É possível encapsular o sistema B com um webservice e fazer acesso sincrono a esse webservice não?

[quote=bandrade]Porque optaram por uma solução assincrona de consulta ao sistema B?

É possível encapsular o sistema B com um webservice e fazer acesso sincrono a esse webservice não?[/quote]
Na verdade é exatamente isso que o sistemaB fará, a diferença é que ele precisa desses dados da seleção feita no sistemaA para chmar o webservice passando os parâmetros, pq ele precisa saber quem está logado no A e passar os dados do login pro webservice, é exigencia da API do BPM, não temos como alterar.