Middleware analyst

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”.

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.

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.