| Author |
Message
|
| George Carey |
 Posted: Thu Oct 18, 2007 12:34 pm Post subject: Datapower and MQ |
 |
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
The DataPower gateway for MQ appears to be a track IBM is already proffering:
http://www.ibm.com/developerworks/websphere/library/techarticles/0703_crocker/0703_crocker.html
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Fri Oct 19, 2007 12:39 pm Post subject: Re: Best Practices or good options |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| George Carey wrote: |
Trying to stay with my intial quest for 'site to site' best practices/rules or good options. I see Peter P. giving the seed of what might be one with the comment:
| Quote: |
| The less control you have over the remote MQ Clients, the farther away they are physically, the more likley you should have them connect to their own QM and then have that QM connect to yours |
I try then to apply that to bruce2359 post with PC based clients doing time sheet submittals, and think that 'distance' in Peter P. rule of thumb should not be considered in physical or network distance but in business affliation proximity. |
Rather than say the farther away they are, to make my point I should say "the slower / less reliable the network connection is between them and you". In other words IBM spent a lot of effort insuring that the SNDR channel and the RCVR channel would not lose any messages, would not duplicate any messages and would automatically pick up where they left off when the connection broke. What are the odds that the developer coding the MQ Client app is going to do it as well when connecting from the PC in a banana hut in the South Pacific to your mainframe in a skyscraper in NYC? 
I don't know diddley about DataPower so I can't comment on how well it will work for you.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Oct 19, 2007 12:41 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20757
Location: LI,NY
|
| PeterPotkay wrote: |
| in a banana hut in the South Pacific |
Wishing you were there on vacation?  
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| George Carey |
| Posted: Fri Oct 19, 2007 2:01 pm Post subject: business or network |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
To emphasize my point-- even if the connection is highly reliable, and fast, I argue that for other security reasons a SDR/RCVR channel should still be used in place of MQ Client.
Allowing direct API calles to MQ Server with an MQ Client is more risk exposure even if mitigated with OAM than one should subject one's server to for a 'non-affliated' Business entity.
The file I/O oriented API of the MQ API which is fully functional by default to every MQ Client is potentially more risky than say an http protocol with a request(get,post) and response paradigm. No ?
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| George Carey |
| Posted: Tue Oct 23, 2007 2:32 pm Post subject: datapower gw option isn't one |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Looking back to a previous post the DATAPOWER example given is not after futher investigation what I thought it was. Though the web url talks about a MQClient to MQServer connection it was really nothing of the sort.
The example given might be a good way to show how one could replace an WMB broker with the DATAPOWER box. I am looking for options for site to site connectivity still, where HA, user authentication, data validation would all be nice features to have as well. The DATAPOWER box has these capabilities internally but appears to only do user/client level as opposed to server MQ functionality.
Multi-Million dollar idea for IBM... have the DATAPOWER unit emulate an MQ MCA and people will buy these like hotcakes for site to site linkage!!
Toss me a token million if you agree!
As is, it does not appear to be a site to site MQ option.
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Oct 23, 2007 3:59 pm Post subject: |
|
|
Guest
|
Looking back through this post, it seems to me that you are asking mq to be responsible for ensuring that your applications don't lose (message) data.
Ultimately, it is the responsibility of the application to ensure no loss or duplication of application data. MQ assures message delivery; but makes no assurances as to your applications use/abuse of messages.
The sending end application should keep track of request messages it sends, and which (if any) replies it receives. It should re-drive the request for missing replies. It should recognize and deal with duplicate replies, too.
Similarly, the receiving end aplication needs to keep track of the requests it received and the replies it sends. It should recognize if it receives duplicate or missing requests.
This best-practice application design no duplication or missing data whether MQ is involved or not. Yes, the client app has some additional risks; but it has advantages, as well. |
|
| Back to top |
|
|
| George Carey |
| Posted: Wed Oct 24, 2007 7:10 am Post subject: Assured delivery and |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Assured once and only once delivery is the wording used is it not?
Ok, best practices says to have an acknowledgement reply protocol for every message sent. How much can the receiving app depend on the tauted 'assured once and only once delivery' of MQ and avoid the additional acknowledgement replys. Thus leaving the burden of whether and which message was sent to the sender! In a site to site connection this is best handled by SDR/RCVR channels than SVRCONN is what appears to be being emphasized. Do you disagree?
A number of examples of problems of MQ Client connections for site to site have been discussed, you mention
| Quote: |
| 'but it has advantages, as well'. |
Can you itemize these for site to site connectivity:
....
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Oct 24, 2007 9:32 am Post subject: |
|
|
Guest
|
| Quote: |
| Assured once and only once delivery is the wording used is it not? |
Yes, MQ queue managers assure message delivery. The client is not a queue manager; and therefore comes with some constraints.
If site-to-site connectivity with all the assured stuff is a business requirement, then the client is not a good choice for you. |
|
| Back to top |
|
|
| George Carey |
| Posted: Mon Oct 29, 2007 11:59 am Post subject: Best Practices for site to site security |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
To this point discussion has been about +,- s of type of connection MQ Client or MQ server to MQ server for site to site connectivity.
What about best practices for securing a site to site connection. Assume an MQ Client is coming into an MQ Server via svrconn channel over a VPN. How safe or unsafe is this connection. The VPN is encrypted link, can man-in-middle or IP spoofing still be done, how about authentication, authorization, is MQS server-to-server channel any different/better/worse in this space. Looking again for best practices ideas.
Is custom security exit code required? The ESE package looks like it only works if you buy a Tivoli stack, is that true? ....
Thoughts/ideas for securing site to site channels. Implementation and maintenance effort needs to factor into value.
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| bower5932 |
| Posted: Mon Oct 29, 2007 12:46 pm Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
|
| Back to top |
|
|
| George Carey |
| Posted: Tue Oct 30, 2007 10:27 am Post subject: I'll say it's interesting |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Wowww!!! I'll say! More than interesting...
Thanks much!
Excellent link!
I highly recommend the video.
Regards,
GTC
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
|
|
