| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Which to use, MQ Server or MQ Client? |
« View previous topic :: View next topic » |
| Author |
Message
|
| Shay Ashton |
 Posted: Wed Dec 03, 2003 9:22 am Post subject: Which to use, MQ Server or MQ Client? |
 |
|
Newbie
Joined: 03 Dec 2003
Posts: 3
|
Hi
I am in the process of architecting a solution now and need some advice on MQSeries.
I will have a number of locations approx 100. In each location there will be approximately 5-10 user using MS IE browser connecting to a local MS IIS6.0 web server running ASP.NET on Win2003. A component on the web server will construct a message that will be passed using MQSeries to a central data store running on an AS/400.
Can I install MQ Client on each of the 100 web servers and then have a box located centrally that is next to the AS/400 running MQ Server which all the MQ Clients pass there messages to before they are passed to the AS/400? Or do I have to install MQ Server on all the 100 web servers?
The reason I ask this is the cost of licensing 100 MQ Servers is rather a lot….
One thing that I think might be a problem is that each of the 10 users can generate a message that needs to be passed over MQ. In the current solution that I am working on this will mean that an instance of MQ Client will be started for each message. So for any one web server there could be 10 client connections from the web server to the MQ server…. will this be a problem?
Sorry if this is a bit cryptic but it has been a while since I was working with MQ.
Regards
Shay |
|
| Back to top |
|
 |
| Shay Ashton |
| Posted: Wed Dec 03, 2003 12:08 pm Post subject: Found the answer in mqseries.net |
|
|
Newbie
Joined: 03 Dec 2003
Posts: 3
|
|
| Back to top |
|
|
| kman |
| Posted: Wed Dec 03, 2003 10:45 pm Post subject: |
|
|
Partisan
Joined: 21 Jan 2003
Posts: 309
Location: Kuala Lumpur, Malaysia
|
Apart from PeterPotkay's observation, it is alos worth noting that the type of licensing you choose, whether Client or Server really depends on the business requirements.
Take for instance, a query order. A query by nature is OK to fail, and is acceptable that no response is received within a specified time - due to network congestion or backend unavailability. Query can be done at a later time. In this case, whether a Client or a Server makes no difference. When network is unavailable, no query can get a response - or no query can be made.
In the case of an update. Say an address update. Do you really think that the customer will have to wait for the network to be available in order to update his address? No. He should update the address at anytime, and let MQ ensures that his address update is sent to the backend for the actual update, eventually. So, in this case, a Server is a must. You can still use a Client, but that would mean your Client app has to be smart enough to know that the update must be done again when the network is back. And the error handling associated with that.
The cost of the infrastructure should not outweight the business needs. I would think that if my transaction needs to go through only once, and whenever I want it to be done, then the Server is the option. If my transactions can wait for the network, then Client it is.
I understand that for 100 server license that would be expensive. What about doing a regional hub, that could reduces the number of server licenses? What about the WMQ Express version? It is cheaper.
Good luck. |
|
| Back to top |
|
|
| Shay Ashton |
| Posted: Thu Dec 04, 2003 8:57 pm Post subject: |
|
|
Newbie
Joined: 03 Dec 2003
Posts: 3
|
Hi
Thanks for the comments.
In the product I am using it has its own build in Off-Line handling, so I will not be using any of the MQ functionality. The reason for this is that the product can use any communication protocal we wish to plug into it, like SNA, TCP/IP, MQ, etc and not all protocals support message delivery. So we need to support it in the product.
The product also monitors the communication state. This is connected to the transactions that the user can transmit to the back-end systems. We can configure for each transaction how it will operate in off-line conditions. So in the case of an enquire the transaction is rejected but an update transaction is stored in the offline storage and then posted later when the communication state changes.
The 100 or so installations is a combination of central, regional, and local web servers. We have already limited the distribution as it is an extreme nightmare when it comes to distributing and maintaining the system with upgrade etc.
WMQ Express???? I know nothing about this so will have to do some research on this.
Thanks for your comments they are much appreciated.
Regards
Shay |
|
| Back to top |
|
|
| kman |
| Posted: Thu Dec 04, 2003 10:39 pm Post subject: |
|
|
Partisan
Joined: 21 Jan 2003
Posts: 309
Location: Kuala Lumpur, Malaysia
|
MQ is not a communication protocols. Those protocols are TCP/IP, SNA, DECnet, etc. This protocol, in turn, is used by MQ for relaying the messages across. MQ is the middleware between your application and the network. Without the network, MQ ceases to function fully. So you can't call MQ a communication protocol when MQ itself requires a comm protocol to communicate across.
Channel configuration is the place where you decide which communication protocols is to use with MQ, and this is normally done outside of the application itself, and does not affect the application.
When using MQ Server, the application always think its operation was successful, because the only thing the application does was to 'put' the message to the queue. Whether network is available or not.
It is about messaging, a new way of doing application integration. Without MQ, you will have to do socket programming, or LU programming, or the likes, in RPC, +COM, etc. So, in effect, MQ handles the network programming for you.
WMQ Express is a little version of WMQ, with some limitation. You have to check it out what it offers with your IBM Rep, or their Business Partner.
 |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
