From Wikipedia, the free encyclopedia
[edit] Viral marketing
The article says that "Websphere MQ (formerly MQ Series) is the de-facto standard for messaging across multiple platforms", but I, for one, have never even heard of it before. While I am, of course, far from omniscient, I would find it strange if I hadn't even heard the name of a de-facto standard.
Instead, might this not be a case of viral marketing from an IBM employee? I would at least appreciate it if anyone could verify the article.
Likewise, is this protocol really significant enough to be in the IP stack template? --Dolda2000 01:07, 29 September 2005 (UTC)
- An unbiased, non-marketing based response ...
- I am certainly no IBM bigot, however, I first came across references to MQ Series over 10 years ago when the original concepts of CORBA were being ironed out, and the vendors were coming forward with their own CORBA compliant 'Application Integration Frameworks'. At this time I had the opportunity to evaluate, at a high level, several of these products and in each case, when Message Oriented Middleware (MOM) was discussed (as it needed to be to enable asynchronous message passing such that the applications did not suddenly halt due to a lack of response) the MQ Series was quoted as a prime example.
- I have never used the product, or even recommended it, however it remains the most well known, and from my experience most widely implemented, MOM tool in use.
- With Networks becoming more reliable over time, the relevance of MOM may be seen to be in decline (particularly in LAN implementations), but it does still have a place in many EAI type environments and can make up for the defficiences of wide area application integration, though the later introduction of persistent Broker/Client type EAI tools, such as webMethods, clouds the issue even further.
- In my opinion, MOM tools certainly should be discussed in relation to Enterprise Networking. MQ Series is a prime example of such a tool, and if it really is deemed to be a de-facto standard, then maybe it should also be included.
-- Dave Cullen, 29th September, 2005
-
- Neither do I (an IBM employee). However, and at least, in Brazil MQ Series is a de facto standard. The Brazilian Central Bank defined a system knows as SPB (Sistema de Pagamentos Brasileiro - Brazilian Payment System) where MQ Series is a pre-requirement for banks could communicate with Central Bank. In some banks, (like Deutsche Bank and Bradesco) MQ Series is also used to internal processes. --- RodrigoLopes
-
- While IBM do say the same thing, a Google search for ' MQSeries de-facto ' shows that it's the view is upheld widely.
- —The preceding unsigned comment was added by 195.212.29.92 (talk • contribs) 15:43, 23 November 2005.
- While you may never have heard of IBM's MQSeries product, it practically created the category of messaging middleware, back in 1992. Most of the follow-on MOM systems defined themselves in terms of MQSeries' behavior, especially before Sun's JMS appeared. RossPatterson 21:00, 17 January 2006 (UTC)
- Re "Likewise, is this protocol really significant enough to be in the IP stack template?", that's a matter for Template talk:IPstack, and in fact it was already dealt with. RossPatterson 21:04, 17 January 2006 (UTC)
- I don't know if MQ is a standard, but it is indeed an industry REFERENCE. I've been working as an IT consultant, and more than half of my clients (in Canada) use MQ to "glue together" big corporate systems. It is the most reliable and cost effective method for connecting systems and data processes. Otherwise, they'd have to develop their own solutions, which are usually less robust and could lead to data losses (NOT a good idea in a corporate environment). And in-house development is usually mpre costly than paying for a license & customizing the tool. -- Hugo Dufort 06:50, 12 December 2006 (UTC)
[edit] "Barring Disk failure"
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)
- 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)
[edit] Requested move
- 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)
- Makes sense to me. PeteVerdon 21:21, 12 June 2006 (UTC)
[edit] Is it relevant?
[edit] 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.
[edit] 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”.
[edit] 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).
[edit] 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)
[edit] Other Companies Involved in WebSphere MQ
This section in the document is obviously spam. Please second a removal?
Piquin 21:06, 20 March 2007 (UTC)
