JMS for 2 way communication
Hi All,
Any insight on this is greatly appreciated,
I have a swing client which need to communicate ( both send and
receive message ) from a distributed system.
Here are my queries.
a)both send and receive is asynchronous - is it a good design to
have two set of queues on acting as a requestQueue and other
as responseQueue
b) we need persisting messages meaning crash recovery, our design is more complicated that each swing client will need to listen to more
than 100 requestQueue & responseQueues - because the client n eeds to communicate with 100's of broker offices located remotely to place orders as well as receive trade updates
c) Finally might sound a silly question,
If we have a requestQueue and responseQueue (point a) , can
the same responseQueue be used for Synchronous and Asynhronous communication ? I mean the swing client need to query
some user specific data (just a request response) will be wise to make use of existing channel instead of creating one ? any thoughts ?
d) Any inputs on scalability of this system, will it scale very well ?
Highly appreciate any thoughts or even if you find some flaw in the approach kindly let me know.
I appreciate if someone could throw some light, as we are a very small team (2) with limited expertise on JMS.
Many thanks,
Abdul
[1414 byte] By [
JAleema] at [2007-10-3 3:19:35]
A) That depends on the requirement, defenitely it is not a bad design, the major advantage of using a asynchronous messaging is "Parallel Processing" of jobs.
B)Persistent Messages : What is the JMS provider you are using if it is MQ then you can acheive this. very easily you only need to configure..also almost all the vendors are now giving persistent message delivery..hence this is not at all a problem,
Why do you require 100 request queues? : It is not required....:) with 5 queues we are processing daily some 100000 records...each queue can hold 50000 records at a time and probabaly each message can have a size of 3KB...
So increase in the no of queues is not a good idea...i hope you got the point.
C)I think it is not possible....
Hello there,
Many thanks for the reply,
Well just clarify i may be wrong, i said i need 100 queues is because
we have hunderds of brokers office where we can place orders
our requirement is as below.
a) One client can place multiple orders with MULTIPLE brokers simultaneously. i.e choose different brokers and do a long and short
at the same time
b) Now based on the brokers chosen by the client orders must be
routed to multiple broker's office
c)same way trade updates / trade confirmation's need to be sent
to the client , please note that MULTIPLE brokers will be sending
the orders to the SINGLE client
d) Now i need a reliable channel to do this, both of the actions (point
b and c ) is async . Unless i create a seperate queue for each of
the brokers how is it possible to reliably (i mean specific broker / client) to communicate with each other
e) It is a complex scenario , please do let me know if you can get the point , if not please do mention i will try to simplify my questions
Would greatly appreciate if someone can help to scrutinize on the architecture , more importantly if JMS is appropriate here.
Many thanks,
forgot to mentionthis project is in the design phase, we are thinking of IBM MQ , alternatively we are also looking on using spring stack JMS /ActiveMQprobably any expert advice on this is welcome as wellregards,Abdul
sorry it is me again :)
well we are planning to build the MQ Server , and also MQ client
MQ clients will be installed on the brokers office
( i mean either pub / sub or P2P not decided yet )
point is we have control on both the sides of the system but just want to make sure how reliably to talk to specific trader / broker
As you mentioned it is not a good idea to create lot of queues,
then will probably need to implement some RECEPTION_LIST pattern
on both the sides such that only specific brokers and clients are targetted .
any thoughts?
just to pipe in here - if you are using activemq do your research. It seems like a great project but a lot of the replication and failover functionality are a little bit buggy in the latest releases. You have to look at development snapshots for some of the functionality (at least last time I checked).
a) Yes
b) As previous stated JMS supports persistant messaging but you'll also need to use a raid array. Think about how quickly you need to recover. If your server goes tits up any persisted messages will be "orphaned" on the raid array until you can rebuild it, therefore a failover system is often required.
c) You can't do synchronous communication with JMS, but you can write code on top of JMS to make it appear synchronous. If your customer is not opposed to using open source software you may find Lingo useful - http://lingo.codehaus.org
d) MQ Server / Client is a good choice for performance. Scalabilty is more difficult to assess as while you can cluster MQ, you can only do so for writing messages. You cant read messages from a cluster - the client needs to know the specific MQ Server that is hosting the queue.
I strongly recommend you either get in some MQ expertise or train your developers as there are lots of do's and don't regarding performance - for example your logs should be on separate disks to your persisted messages.
BTW MQ doesn't include a JNDI server, so if you're planning on using JNDI (not essential), you'll also need WAS.
Hello There,
Thanks Steve for your inputs.
However no one gave a clue here, it is SOA era so gotta think
in terms of services.
we have now decided to use ESB (Mule) , Itz got all we want,
both synchronous, asynchronous, and request response as well.
Itz also got the recipient list implementation aswell. Very useful framework , we are using along with ActiveMQ now, ofcourse we are still in the design phase but have made clear on our technical architecture.
Thanks all, for all the information.
regards,
Aleem
