Best approach for rpc style jms

[Rooftop]

Hello all,

I have to program against some existing jms services, i don't know the details of the services yet but i know they should be called in an rpc style. First i wanted to try to call them as is from flex without writing any server side code, but i don't think this is possible because you then get more like a publish/subscribe model, correct? To me the best option i see now, is calling a remoted spring service which calls the actual jms service with jmsTemplate? Since a i'm new to blazeDS Integration i wanted to check if this is a correct aproach? Do i have any other/better options?

Thanks in advance for answering these questions.

Kind Regards,

Ronald Vermeire

[Rooftop]

Hello all,

I am investigating a little more. I took the testdrive and changed the topic to a queue. I understood that this means point-to-point messaging, only one client receives the message, but in the altered jms-chat application both clients receive the message. Is this an error?

Another thing that wonders me. What is difference between

<flex:jms-message-destination id="jms-chat" topic-name="chatTopic" />

and

<flex:jms-message-destination id="jms-chat" jms-destination="chatTopic" />

Or are these two possibilities identical?

Could someOne answer on my first post?

Kind Regards,

Ronald

[jeremyg484]

I am investigating a little more. I took the testdrive and changed the topic to a queue. I understood that this means point-to-point messaging, only one client receives the message, but in the altered jms-chat application both clients receive the message. Is this an error?

No, this is not an error. Using a queue gives you point-to-point on the *server*, but the Flex producer/consumer model between the server and client is inherently publish/subscribe.

Another thing that wonders me. What is difference between

<flex:jms-message-destination id="jms-chat" topic-name="chatTopic" />

and

<flex:jms-message-destination id="jms-chat" jms-destination="chatTopic" />

The first version essentially uses Spring's DestinationResolver to get ahold of the actual JMS Destination instance, while the second version just directly references a Destination bean that Spring is already managing.

Could someOne answer on my first post?

Your described scenario is a little vague, so it's hard to say if the path you're taking is correct or not. It would help if you could describe your requirements in a bit more detail and how you are trying to interact with the JMS destinations.

[Rooftop]

I am investigating a little more. I took the testdrive and changed the topic to a queue. I understood that this means point-to-point messaging, only one client receives the message, but in the altered jms-chat application both clients receive the message. Is this an error?

No, this is not an error. Using a queue gives you point-to-point on the *server*, but the Flex producer/consumer model between the server and client is inherently publish/subscribe.

Still i find it strange, because when i used then non Spring version of blazeDS it did behave as i expected -only one client receives the message once - even with publish/subscribe. Can you then explain what is the difference between the "normal" BlazeDS implementation and the Spring one? How can i create a model that is not publish/subscribe?

Your described scenario is a little vague, so it's hard to say if the path you're taking is correct or not. It would help if you could describe your requirements in a bit more detail and how you are trying to interact with the JMS destinations.

Well i still don't know exactly, but i have to interact with synchrone short-persistent queues created in websphere.


Kind Regards,

Ronald Vermeire


Kind Regards,

Ronald Vermeire

[jeremyg484]

Still i find it strange, because when i used then non Spring version of blazeDS it did behave as i expected -only one client receives the message once - even with publish/subscribe.

That is strange, because even the simple pure AMF BlazeDS destinations are pub/sub, and if you have multiple clients subscribed to the destination, they're all going to receive the message. Perhaps you were doing some sort of client-side filtering, or you were using the sub-topics?

Can you then explain what is the difference between the "normal" BlazeDS implementation and the Spring one? How can i create a model that is not publish/subscribe?

Well, if you're talking specifically about the JMS integration, the major difference is that you manage the JMS details the same way you would in any other Spring app, using Spring config to handle connections, configuration of topics/queues etc., instead of the comparatively verbose config required in messaging-config when using the standard BlazeDS JMSAdapter.

Doing point-to-point is possible, and there are several approaches. I think the most efficient (that avoids the need for pushing the message to all clients and then filtering) is to use a remote call to dynamically create a messaging destination that is unique to the client that issued the remote call, return its ID and then have the client subscribe to that destination. This would not be a JMS destination, but rather just a basic AMF one. You then need some sort of intermediary on the server to do the routing to/from JMS. Spring Integration works nicely for this. I've given some directions on this approach previously if you look back through the forums.