Talk:IBM MQ

message: Is it actually the case that a disk failure would cause a typical MQ installation to fail? If so, it's rather less omnipotent than I've been led to believe. PeteVerdon 22:10, 8 June 2006 (UTC)
replies: text: No, it wouldn't.  Not unless you were foolish enough to deploy a critical facility on hardware that isn't reliable and recoverable, isn't backed up, yadda yadda yadda.  I believe the phrase was intended to convey the fact that a message, once sent, will be delivered, period, surviving re-boots etc. RossPatterson 00:35, 9 June 2006 (UTC)
thread_title:  "Barring Disk failure" 

message: :The following discussion is an archived vote of an article move. The result was a move. Please do not modify it.
Websphere MQ → WebSphere MQ – Rationale: official product name has a capitalized "S" in WebSphere. The lead section's title text even lists it with a capital. …  --Bovineone 04:14, 12 June 2006 (UTC)
replies: text: Makes sense to me. PeteVerdon 21:21, 12 June 2006 (UTC)
thread_title: Requested move

message: ===Best Practices for WebSphere MQ Implementations===
WebSphere MQ best practices encompass generally accepted principles to promote usability and maintainability.  A selected few examples of best practices are included here to provide valuable insight and enlightenment as to how WebSphere MQ addresses key principles of standards-based computing.
 
A common problem new implementations of MQ stumble into is how user-defined applications are configured so that queue references bypass Queue Alias definitions referring directly to the Queue Local or Queue Remote definition.  This is a deviation from Best Practices and should be corrected when the administrator and/or programmer can correct it within time and scope parameters.  All references from user-defined Applications should point to Queue Aliases.  Then the Queue Aliases should point to the defined Queue Local or Queue Remote.
 
Queue Aliases allow flexibility for MQ administrators to resolve or relieve production problems quickly.  By using Queue Aliases, MQ administrators can redirect message flow, in the event of a service problem, without changes to the user-defined Application.  For example, if a Queue Local were overflowing, an MQ admin could change the Queue Alias to point to a temporary Queue Local, thereby allowing the user-defined application to continue it’s processing without interruption while the underlying root cause is corrected.
 
By pointing all user-defined Application references to Queue Aliases, it preserves the flexibility that MQ admins would have to help with Production issues that may occur.  If the Best Practice of Queue Aliases were not followed, the ability of an MQ Admin to help with a Production outage would be hindered.
 
===Role and Responsibility of a WebSphere MQ Analyst===
WebSphere MQ Information Systems Consultants hold and maintain proficiency in Middleware technologies. Middleware is a vertical skill within the WebSphere & Sun Java families that bring together diverse information systems. These include different hardware platforms (more than 80 different configurations and/or manufacturers), programming languages (COBOL, C, Java, and VB), operating systems, and communication links (local and wide area networks, including third-party business partners). Software that resides between applications and the components of the underlying infrastructure is called “Middleware”.
  
===Skills required of a WebSphere MQ Analyst===
Message queuing (“MQ”) is a middleware technology that greatly simplifies communication between the nodes of a system and between the nodes that connect systems together. Information System Consultants use Message Queuing as their skill base.  Upon this base, Information System Consultants add Workflow management, Message brokering, and cutting edge J2EE implementations using Java Virtual Machines (JVMs) and Message Driven Beans (MDBs).
 
===WebSphere MQ Security===
Because MQ is a cross-platform messaging tool, the sophistication of your WebSphere MQ Analysts are expected to be acute. People that are designing and implementing the MQ Message Flow need to fully understand how the MQ Security model on each target platform works.  This may include Windows, Unix, z/OS or AS/400.  
 
WebSphere MQ protects data in transit through PKI and SSL technology. Security certificates are procured from a Certification Authority and regularly deployed and updated on MQ Servers. This protects data while it is in-transit as it leaves one MQ Server and arrives on the next MQ Server in the chain. It does not protect data while data is at rest. 
 
Supplemental transmission security can augment the primary SSL measures that exist on your MQ Server.  These are SSL client authentication, DN filtering, CRL check by LDAP, and Using cryptographic hardware (IPSEC-level encryption).  This type of security is called "border-level security" because it only protects the data when it leaves your borders until it gets to your trading partner's borders.  It does not protect data once data has entered the border. IPSEC is the most efficient and least costly protection method.  SSL is the middle ground, with a balance between flexibility, resource consumption, and transmission time.
 
When data is at rest in queues, it is not protected by MQ. That is, data is in "plain text". Therefore, if the data contained in messages is so sensitive that you do not want your trusted MQ administrators to see this data, then it is essential that application-level data encryption be used. Application-level data security can be viewed by the cliché': "The best defense is a good offense." Examples of data which could be protected by this strategy include banking data (account numbers, banking transactions, etc.) Application-level transaction security is the most secure form of protection but also the most costly in terms of CPU and I/O bandwidth consumption of both the sending and receiving servers. It is also the least efficient.
 
WebSphere MQ data channels can be set up to provide varying degrees of protection. A sender/receiver channel pair could be configured to provide IPSEC transport-level security not using SSL. A second sender/receiver pair could be configured to provide SSL border-to-border level security not using IPSEC. A third sender/receiver channel pair could be set up to provide application-level encryption. Using this scheme, you provision a wide selection of protection mechanisms from which your applications can choose at runtime. This offers your applications the ability to achieve best security when needed or more efficient security when data is not quite so sensitive.
Kmorozov 10:03, 12 October 2006 (UTC)
thread_title:  Is it relevant? 

message: Because MQ is a cross-platform messaging tool, the sophistication of your WebSphere MQ Analysts are expected to be acute. People that are designing and implementing the MQ Message Flow need to fully understand how the MQ Security model on each target platform works.  This may include Windows, Unix, z/OS or AS/400.  
 
WebSphere MQ protects data in transit through PKI and SSL technology. Security certificates are procured from a Certification Authority and regularly deployed and updated on MQ Servers. This protects data while it is in-transit as it leaves one MQ Server and arrives on the next MQ Server in the chain. It does not protect data while data is at rest. 
 
Supplemental transmission security can augment the primary SSL measures that exist on your MQ Server.  These are SSL client authentication, DN filtering, CRL check by LDAP, and Using cryptographic hardware (IPSEC-level encryption).  This type of security is called "border-level security" because it only protects the data when it leaves your borders until it gets to your trading partner's borders.  It does not protect data once data has entered the border. IPSEC is the most efficient and least costly protection method.  SSL is the middle ground, with a balance between flexibility, resource consumption, and transmission time.
 
When data is at rest in queues, it is not protected by MQ. That is, data is in "plain text". Therefore, if the data contained in messages is so sensitive that you do not want your trusted MQ administrators to see this data, then it is essential that application-level data encryption be used. Application-level data security can be viewed by the cliché': "The best defense is a good offense." Examples of data which could be protected by this strategy include banking data (account numbers, banking transactions, etc.) Application-level transaction security is the most secure form of protection but also the most costly in terms of CPU and I/O bandwidth consumption of both the sending and receiving servers. It is also the least efficient.
 
WebSphere MQ data channels can be set up to provide varying degrees of protection. A sender/receiver channel pair could be configured to provide IPSEC transport-level security not using SSL. A second sender/receiver pair could be configured to provide SSL border-to-border level security not using IPSEC. A third sender/receiver channel pair could be set up to provide application-level encryption. Using this scheme, you provision a wide selection of protection mechanisms from which your applications can choose at runtime. This offers your applications the ability to achieve best security when needed or more efficient security when data is not quite so sensitive.
Kmorozov 10:03, 12 October 2006 (UTC)
thread_title: WebSphere MQ Security

message: This section in the document is obviously spam. Please second a removal?
Piquin 21:06, 20 March 2007 (UTC)
thread_title: Other Companies Involved in WebSphere MQ

message: "WebSphere MQ is an excellent foundation..." blah blah blah.
 
The whole MQ and Web Services section is right out of a sales slick and should be removed.
--Gonzeaux (talk) 01:51, 10 December 2007 (UTC)
thread_title:  Bias 

message: The history section is hilarious. It say practically nothing about the history of MQ Series, and a whole lot of other things about the history of other IBM products that are only marginally related. If this was an article about the history of asynchronous systems, maybe these things would be relevant (plus a whole lot more). As it is this read like Whiggish  history at its worst, and gives no useful information about the history of the product.  —Preceding unsigned comment added by 71.202.236.97 (talk) 01:08, 19 August 2008 (UTC)
thread_title:  History 

message: The image :Image:Websphere logo.png is used in this article under a claim of fair use, but it does not have an adequate explanation for why it meets the requirements for such images when used here.  In particular, for each page the image is used on, it must have an explanation linking to that page which explains why it needs to be used on that page.  Please check
:* That there is a non-free use rationale on the image's description page for the use in this article.
:* That this article is linked to from the image description page.
This is an automated notice by FairuseBot. For assistance on the image use policy, see Wikipedia:Media copyright questions. --01:25, 5 November 2008 (UTC)
thread_title: Image copyright problem with Image:Websphere logo.png

message: The "product page" link is broken. Not sure which product page was intended.  —Preceding unsigned comment added by 66.193.41.123 (talk) 18:41, 27 October 2009 (UTC)
thread_title:  External Links 

message: This section kinda sucks.  It has a cheerleading "most popular" claim cited by a 10-year-old report (ancient in this field), opens by repeating stuff from the page info, and isn't clear on how WebSphere MQ differs from a generic MQ.  Frankly, it looks like it was copy/pasted from a sales brochure.
Anyone want to comment?  If not, I'm gonna return and cut it way down. --GrantBnet (talk) 17:33, 3 December 2010 (UTC)
thread_title:  Problems with "Message-oriented middleware" section 

message: I've uploaded an audio recording of this article for the Spoken Wikipedia project.  Please let me know if I've made any mistakes.  Thanks.  --Mangst (talk) 18:43, 10 December 2010 (UTC)
thread_title:  Spoken Wikipedia Audio Recording 

message: As of version 8.0 the product formerly known as "IBM Websphere MQ" was renamed to "IBM MQ". See the third paragraph of the abstract: http://www.redbooks.ibm.com/abstracts/sg248218.html?Open Mccammondwatts (talk) 15:01, 18 November 2014 (UTC)
thread_title:  Request Move