Mq Tech Notes Ppt
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Mq Tech Notes Ppt as PDF for free.
More details
- Words: 5,954
- Pages: 54
®
IBM Software Group
GSE Nordic Technical Conference May 23rd – 25th 2005 – Riga Session S19. Introduction to WebSphere MQ Queue Managers Morten Sætra [email protected]
© 2004 IBM Corporation
IBM Software Group | WebSphere software
Agenda • Messaging Fundamentals • What is a message • Introduction to Queue Manager • The MQ API • Application connection topologies • Remote messaging • Administration • Security • WebSphere MQ and the Wider World
© IBM Corporation 2004
IBM Software Group | WebSphere software
Messaging Fundamentals
• A single, multi-platform API • •
Easy to use Message centric interface Network Independent
….faster application development
• Assured message delivery • Loosely coupled applications •
Asynchronous messaging
B X
A © IBM Corporation 2004
Y
IBM Software Group | WebSphere software
Messaging Fundamentals - notes The physical world is frequently organised in queues. Consider for a moment just how many queues you have been involved in today alone. We queue at the Post Office, Supermarket checkout, at traffic lights. We write shopping lists and to do lists. We use the postal service, voice mail, and of course, the ever present e-mail. The truth is that queuing is a natural model that allows us to function efficiently. Perhaps not surprisingly therefore it turns out that it is also a very useful model in which to organise our applications. Instead of application A talking synchronously to Application B have Application A 'send a message' to a queue which Application B will read. What WebSphere MQ (aka MQSeries) did was to recognise that for the queuing model to be successful and applicable to a wide range of applications that it must achieve two major goals : First it must be totally reliable. A message put to an WebSphere MQ queue is as safe as a record written to a database. e-mail just isn't reliable enough Secondly it should be available everywhere The postal service would be severely restricted if it only covered the local city.
© IBM Corporation 2004
IBM Software Group | WebSphere software
Messaging Fundamentals - Reducing Complexity
• Reliable, distributed computing • •
Complex Error prone
• WebSphere MQ eases the complexity • WebSphere MQ is not a substitute for: • • • •
Well written applications Robust network Good operational procedures Well managed system
© IBM Corporation 2004
IBM Software Group | WebSphere software
Messaging Fundamentals - Reducing Complexity notes The WebSphere MQ base product is available on all major platforms such as Windows,AIX, HP, Solaris, iSeries, z/OS and many others. A simple API, known as the MQI, is available with only around a dozen verbs which allows an application on one platform to communicate with an application on another platform without either application requiring any explicit knowledge of each other. The goals of MQ from an application standpoint are to provide :• Time Independence It is not necessary for both applications to be up and running at the same time • Platform Independence A sending application need not know what type of platform the receiving application is running on. • Location Transparency A sending application need not know where the receiving application is nor have any knowledge of the network or communications . • Data transparency With the advent of Brokers and message translation it is not even necessary for the two applications to exchange messages in a shared format.
© IBM Corporation 2004
IBM Software Group | WebSphere software
What's a Message? Message = Header + User Data Header Header
User UserData Data
AASeries SeriesofofMessage MessageAttributes Attributes Understood and augmented Understood and augmentedby bythe theQueue QueueManager Manager •Message Id •Message Id •Correlation •CorrelationIdId •Reply •Replyrouting routinginformation information •Message •Messagepriority priority •Message •Messagecodepage/encoding codepage/encoding •Message format •Message format ....etc. ....etc.
•Any sequence of bytes •Any sequence of bytes •Private to the sending and •Private to the sending and receiving programs receiving programs •Not meaningful to the Queue Manager •Not meaningful to the Queue Manager
•Message Types -Persistent ... recoverable -Non Persistent
•Up to 100MB message length
© IBM Corporation 2004
IBM Software Group | WebSphere software
What's a Message? - notes A message in WebSphere MQ is merely a sequence of bytes in a buffer of a given length. The current products support up to 100MB in a single message although the vast majority of messages are in the order of a few thousand bytes. Messages have various attributes associated with them such as their identifier, their priority and their format. Each application is free to define its own format for messages although there are a number of predefined formats. One common format for messages is XML for example. A key attribute of a message is its persistence. A message is either persistent or nonpersistent. This attribute tells the Queue Manager how important the message is. Persistent Persistent messages are written to disk and are logged. The Queue Manager will ensure that the messages are recovered in the case of a system crash or network failure. These messages are delivered once and only once to the receiving applications. Non persistent The messages are identified by the application as non-critical. The Queue Manager will make every effort to deliver these messages but since they are not written to disk they will be lost in the case of a system crash or network failure. Clearly with no disk IO involved these messages are much faster than persistent ones.
© IBM Corporation 2004
IBM Software Group | WebSphere software
What's a Queue ?
• Place to hold messages •Various Queue Types •Local,Alias,Remote,Model
• Queue creation •Predefined •Dynamic definition
• Message Access
•FIFO •Priority •Direct •Destructive & non-destructive access •In transactions
• Parallel access by applications •Managed by the queue manager
© IBM Corporation 2004
IBM Software Group | WebSphere software
What is a Queue ? - notes A Queue is a named object (up to 48 characters) which is defined with a queue type. Local Only queue type which can actually hold messages Alias A queue name which 'points' to another queue Remote A queue which 'points' to a queue on a remote machine Model A template definition which when opened will create a temporary local queue Applications open queues, by name, and can either put or get messages to/from the queue. Messages can be got from the queue either in FIFO order, by priority or directly using a message identifier or correlation identifier. As many applications as required can open a queue either for putting or for getting making it easy to have single server responding to many clients or even n servers responding to many clients. A key feature of WebSphere MQ is its transaction support. Messages can be both put and got from queues in a transaction. The transaction can be just local, involving just messaging operations or global involving other resource managers such as a database. A classic example, is an application which gets a message, updates a database and sends a reply message all within a single transaction. If there is a failure before the transaction commits, for example a machine crash, both the database update and the received message will be rolled back. On machine restart the request message will still be on the queue allowing the application to reprocess the request.
© IBM Corporation 2004
IBM Software Group | WebSphere software
What is a Queue Manager ? Put
Utilities Command Server Listener Channel Initiator Trigger Monitor Windows Explorer
Get
MQ API
Kernal Moving Message
Local Queuing
© IBM Corporation 2004
IBM Software Group | WebSphere software
What is a Queue Manager - notes A queue manager may - generally - be thought of as 3 components: The Kernel is the part of the queue manager that understands how to implement the MQ APIs. Given that the APIs are common across the queue manager family, it stands to reason that the Kernel is mostly common code across the set of queue managers. (The primary exception to this is the z/OS queue manager where the same functions are implemented differently to support the same APIs). The Local Queuing component is the part of the queue manager responsible for interacting with the local operating system. It manages memory, the file system and any operating system primitives such as timers, signals, etc. This component insulates the Kernel from any considerations of how the underlying operating system provides services and so enables the Kernel to be operating system independent. The Message Moving component is responsible for interacting with other queue managers and with MQI clients. For environments where all of the message queuing activity is local to a system then this component is unused - though this is a very rare case. The message moving functions are provided by specialised MQ applications, called Message Channel Agents.
© IBM Corporation 2004
IBM Software Group | WebSphere software
What is a WebSphere MQ Client ?
LAN Messaging Clients DG/UX HP3000 MPE/iX Java Windows: 3.1,95,98 .NET DOS VM Apple MacOS Stratus VOS 4690 Unisys A …
WAN
Messaging Servers OS/390, z/OS Linux, zLinux AIX Windows XP, 2000 Solaris: Intel & SPARC HP-UX OS/400 OS/2 Compaq OpenVMS Compaq NSK / NSS Compaq Tru64 UNIX VSE/ESA Digital UNIX SCO: Openserver, UnixWare IRIX Dynix/ptx NCR TPF DC/OSx Sinix Unisys 2200 Hitachi
…
© IBM Corporation 2004
IBM Software Group | WebSphere software
What's a WebSphere MQ MQI Client? - notes WebSphere MQ clients provide a low cost, low resource mechanism to gain access to MQ facilities. The client provides a remote API facility, allowing an WebSphere MQ application to run on a machine that does not run a queue manager. Each MQ API command is passed to a Server queue manager where a proxy executes the required API command. The connection between client and server is entirely synchronous providing an 'rpclike' mechanism - though NO regular (well-known) rpc mechanism is used ! Also, the client machine does not own any MQ resources - all resources are held by the Server machine. Thus, if local queuing capability is required then a server (rather than a client) must be used.
© IBM Corporation 2004
IBM Software Group | WebSphere software
The MQ API Program A MQBEGIN MQGET MQINQ MQOPEN MQCONN MQBACK MQPUT MQDISC MQCLOSE MQSET MQPUT1 MQCONN(X) MQCMIT
MQI Queue Manager Process Object
Queues © IBM Corporation 2004
Queue Manager Object
IBM Software Group | WebSphere software
MQ API - notes There are 13 verbs in the WebSphere MQ API, four of which are most heavily used and the rest have less frequent use. The most common verbs will be MQOPEN, MQCLOSE, MQPUT and MQGET which are concerned with the processing of messages on queues. The other verbs have important uses but will not be used as commonly as these four. There are many, many options associated with these verbs - approximately 250! However, in general, most of these options may be left to take their default values - and MQ provides a set of default structures to allow for easy assignment of these default values. The MQ API has both a procedural implementation and an object oriented implementation. This allows for straightforward usage in both of these programming environments. All of the popular languages and programming environments are supported, for example: Assembler (z/OS) C, C++, COBOL, PL/1 RPG (AS/400) Java, JMS LotusScript,SmallTalk,Visual Basic,COM Plus application environments, e.g. CICS, IMS,Encina, Tuxedo, TXSeries, WebSphere Application Server, MTS, ...
© IBM Corporation 2004
IBM Software Group | WebSphere software
Examples of how MQ queues can be used ‘Send and Forget’ Put Invoice-Q
Get Invoice-Q Program B
Program A Invoice-Q
Request / Response
Target Queue Program B
Program A
Reply-to-Queue
© IBM Corporation 2004
IBM Software Group | WebSphere software
Examples These examples show some of the ways in which MQ queues can be used and, thereby, shows some of the styles of applications that may benefit from the use of a message/queuing model. 'Send and Forget' This style is one where there is no (direct) response required to a message. The message/queuing layer will guarantee the arrival of the data without the application having to solicit a response from the receiver. Request/Response This style is typical of many existing synchronous applications where some response is required to the data sent. This style of operation works just as well in an asynchronous environment as in a synchronous one. One difference is that - in this case - the sender does not have to wait for a response immediately. It could pick up the response at some later time in its processing. Although this is also possible with the synchronous style, it is less common.
© IBM Corporation 2004
IBM Software Group | WebSphere software
Examples… Chain Program A
Program B
Program C
Workflow Program B
Program A
Program D
© IBM Corporation 2004
Program C
IBM Software Group | WebSphere software
Examples… Chain Data does not have to be returned to the originating application. It may be appropriate to pass a response to some other application for processing, as illustrated in a chain of applications. Workflow There may be multiple applications involved in the processing before a response comes back to the originating application. These various modes of interaction may be arbitrarily combined to provide as complex/sophisticated topology as is necessary to support a particular application. The loosely coupled nature of the message queuing model makes it ideal for this style of interaction. Furthermore, it makes it straightforward to develop applications in an iterative style.
© IBM Corporation 2004
IBM Software Group | WebSphere software
Examples …Publish / Subscribe Data
C
Data
A
A
D
Pub/Sub Broker
B Data
B
E A,B
Subscription (re-) Publication
B
© IBM Corporation 2004
F
IBM Software Group | WebSphere software
Examples…Publish/Subscribe - notes In this environment, the receiving applications notify an intermediate broker of their interest in particular sets of information. The receiving (or subscribing) application provides a subject and a queue where messages matching this subject may be delivered. The sending (publishing) applications generate information, together with a subject name, and sends the information to the broker. The broker contains a matching service which determines the subscribing applications interested in receiving this information. Note that the publish/subscribe model provides for the situation where a message may be published by an application using a subject which has no subscribers. In this instance the message data is discarded. There are many publish/subscribe products available in the marketplace today. MQ publish/subscribe differentiates itself by providing support for the publish/subscribe model and combining it with the exactly once delivery model of MQ message/queuing.
© IBM Corporation 2004
IBM Software Group | WebSphere software
Examples … Clustering Q Mgr 1
B Queue 1 Q Mgr 2
B Queue 1 Q Mgr 3 Q Mgr A
A
B
?
Queue 1 Q Mgr 4
B Queue 1
© IBM Corporation 2004
IBM Software Group | WebSphere software
Examples …. Clustering The final example given here (though not the last possibility by any means) is MQ Clustering. In order to enable highly scalable applications, MQ queue managers provide support for MQ Clusters. In this environment, there are several copies (or clones) of a particular target queue and each message is sent to exactly one of the possible choices. WebSphere MQ Cluster support also defines and manages all MQ resources, such as channels, automatically and provides automatic notification of failed or new queue managers in the environment.
© IBM Corporation 2004
IBM Software Group | WebSphere software
Goals of Clustering QSERVICE
MQPUT
QSERVICE
•Multiple Queues with single image •Failure isolation •Scalable throughput •MQI applications to exploit clusters transparently •Definition through usage (MQOPEN) •MQGet always local
QSERVICE
© IBM Corporation 2004
IBM Software Group | WebSphere software
Goals of Clustering - notes Here we see a client putting to the 'QSERVICE' queue that is available in the cluster on three server queue managers. A message is MQPUT by the client and is delivered to *one* of the servers. It is processed there and a response message sent to a ReplyToQueue on the client queue manager. If a server becomes unavailable, then it is not sent any further messages and all requests are routed to the servers which are still available. In addition, to handle new workload, additional servers can be added online without requiring the application take any action at all. Both these behaviours are achieved by existing MQI applications, i.e. without change. An applications need not be aware that it is operating in a cluster environment. We can see how a cluster can provide a highly available and scalable message processing system. The administration point in processing is MQOPEN as this is when a queue or queue manager is identified as being required by an application. Note that only one message is sent to a server; it is not replicated three times, rather a specific server is chosen and the message sent there. Also note that MQGET processing is still local, we are not extending MQGET into the network.
© IBM Corporation 2004
IBM Software Group | WebSphere software
Cross System Communication with WebSphere MQ QM 1
QM 2 Program A
Put Q2
Program B
Put Q1
Program C Get Q2
Get Q1 MQI
MQI
Messaging Messaging
and
and
Queuing
Queuing Transmission Q
Q2
Q1 TCP/IP, APPC etc © IBM Corporation 2004
IBM Software Group | WebSphere software
Cross System Communication with WebSphere MQ - notes In the diagram we see Program A sending messages to two other programs. to Program B In this case the actual physical queue that both applications access are the same. This therefore does not require any network communication. to Program C In this case Program A wants to put a message to queue Q2 on Queue Manager QM2. It can't do this directly without requiring that the network and QM2 Queue Managers are available so instead the message is put to a 'holding' queue called a transmission queue. Asynchronously another part of WebSphere MQ called a channel will read this transmission queue and deliver any messages to the queues on QM2. Any number of applications running on QM1 can send messages to QM2 via the same transmission queue and channel.
© IBM Corporation 2004
IBM Software Group | WebSphere software
WebSphere MQ Systems Management Scripting MQ Application MQ Explorer Programmable Command Format
Kernal Moving Message
Local Queuing
© IBM Corporation 2004
WebSphere MQ Events
System Management Applications E.g. BMC ComputerAssociates Landmark Nastel RYO Tivoli/Candle
IBM Software Group | WebSphere software
WebSphere MQ Systems Management - notes One of the key operational components of any system is management. WebSphere MQ enables systems management in a number of ways: There are facilities provided by the MQ base to enable MQ resources to be managed. There are 'internal' utility programmes (for example, MQSC, the TSO interface for z/OS and the command line interface for AS/400). There are also documented interfaces, most notably Programmable Command Format messages which are PUT to a well known queue and are processed accordingly by the queue manager. WebSphere MQ provides events. These events are themselves MQ messages which are PUT (by the queue manager) to well known queues and provide information on state changes for various queue manager resources. The format of the event messages is documented. Text based message logs (and Windows events) are also provided. So, WebSphere MQ queue managers provide a set of documented interfaces to allow control and configuration of resources and to inform external processes of state changes within the queue manager. These interfaces may be used by any application program. Typically, this occurs in 3 ways: There are MQ utilities which make use of these interfaces. Most notably, the MQ Explorer (provided for Windows NT and 2000 environments) enables management and configuration of both local and remote queue managers using PCF messages. The majority of the established systems management vendors use the facilities described above to provide MQ 'personalities' for their products. Customers may write their own utilities to provide systems management capabilities within their organisations. This style often makes use of the messaging APIs to utilise PCF and event messages. Also scripting languages (most notably PERL) are used to provide systems management scripts for WebSphere MQ and other environments. © IBM Corporation 2004
IBM Software Group | WebSphere software
WebSphere MQ Transactional Integration • Message level selection for unit of work • Single UoW active at any one time • WebSphere MQ messages in a unit of work •
MQCMIT and MQBACK control the unit of work
• Messages and other resources in a unit of work • Managed by a Transaction Manager • WebSphere Application Server, z/OS; CICS, IMS, z/OS RRS • Microsoft Transaction Server • Any XA Transaction Manager • Managed by WebSphere MQ • WebSphere MQ is an XA Transaction Manager • MQBEGIN, MQCMIT and MQBACK control the unit of work © IBM Corporation 2004
IBM Software Group | WebSphere software
WebSphere MQ Transactional Integration - notes WebSphere MQ supports logical units of work (UoW) where a set of resource updates may be considered as an atomic unit - either all of the changes are made or none of the changes are made. This support is particularly important when using WebSphere MQ in a commercial environment (it's primary focus) as transactions play a major part in this arena. WebSphere MQ allows messages to be included/excluded from a UoW at the message level. This differs from some other environments where a UoW starts and all subsequent actions are included in the UoW. Thus, a set of messages may be considered to be a UoW. Often, it is necessary to include both MQ messages and some other recoverable resources (typically database updates) in a UoW. Typically, this has required the use of some Transaction Monitor and WebSphere MQ works well with CICS and IMS on z/OS and with any XA compliant Transaction Manager. In situations where a Transaction Manager product is not available/suitable, WebSphere MQ itself may be used as the Transaction Manager. This does not mean that WebSphere MQ is transforming itself into a Transaction Monitor, it is just providing the Transaction Manager aspect of a Transaction Monitor product. The API used in handling transactions differs according to the environment. WebSphere MQ provides some verbs to handle UoWs. If a Transaction Monitor is used, however, its UoW verbs are used in place of the MQI.
© IBM Corporation 2004
IBM Software Group | WebSphere software
WebSphere MQ Security Application Security
B Commands
A
Context
Access Control Xmit Q 2
Queue 4
Transmission
Queue 1
Queue3
Queue 5 QMgr 2
QMgr 1
© IBM Corporation 2004
IBM Software Group | WebSphere software
WebSphere MQ Security - notes There are several aspects to WebSphere MQ security: Control of WebSphere MQ commands Access to MQ commands, like creating and starting queue managers, can be controlled through operating system facilities and also by MQ facilities; it is necessary to be in a particular authorisation group to be allowed to use these commands. Access to Queue Manager objects There is an access control component that is provided by the MQ Queue Manager, called the Object Authority Manager (OAM), which controls access to Queue Manager objects, particularly queues. The OAM can control access to resources at a very granular level, allowing access for different actions, such as GET, PUT, INQ, SET, etc. This access is (generally) based upon group memberships. This security service is a pluggable component of MQ. Thus, if the OAM does not meet the requirements of the environment it is possible to provide a different (or additional) component. Note that the OAM is used for all queue managers except for the z/OS queue manager which uses any SAF compliant security manager.
© IBM Corporation 2004
IBM Software Group | WebSphere software
WebSphere MQ Security – notes continued Channel Security WebSphere MQ 5.3 provides built-in SSL link level security MQ provides a set of exit points, available in the intercommunication component. These exit points allow a set of functions to be provided: The security exit allows for (mutual) authentication of partner systems when they connect to one another. The message exits allow for customisation at the message level, allowing individual messages to be protected, in terms of message integrity, message privacy and non-repudiation Application Security This level of security is not implemented directly by the Queue Manager but such facilities may be implemented at the application level, outside of the direct control of WebSphere MQ.
© IBM Corporation 2004
IBM Software Group | WebSphere software This page intentionally left blank
© IBM Corporation 2004
IBM Software Group | WebSphere software
WebSphere MQ & the Wider World
© IBM Corporation 2004
IBM Software Group | WebSphere software
WebSphere MQ and the Wider World - notes For a messaging engine to be really useful it should allow access to the messages from many different environments. We have already discussed MQs programming language and API support but what about the environments. The complexity of overall business applications is increasing every year as more and more applications are linked together in some way. WebSphere MQ dramatically reduces an individual applications complexity by providing a consistent, reliable and transactional method of communicating between applications from hundreds of different environments. We are now going to look briefly at where WebSphere MQ fits in the Business Reference Architecture and also at some of the other WebSphere Business Integration products that make up the portfolio
© IBM Corporation 2004
IBM Software Group | WebSphere software
IBM Business Integration Reference Architecture Model, design, development, test tools Common Runtime Infrastructure
Monitoring Services
User Interaction Services
Application Services
Information Services
Process Services
Community Integration Services
Enterprise Service Bus Application Access Services
Data Access Services
Enterprise applications
Enterprise data
© IBM Corporation 2004
IBM Software Group | WebSphere software
IBM Business Integration Reference Architecture WebSphere BI Modeler
Model, design, development, test tools
WebSphere Studio
Common Runtime Infrastructure
WebSphere BI Monitor
Monitoring Services User Interaction Services
WebSphere Portal Server
Application Services
Information Services
WebSphere Application Server
WebSphere MQ Everyplace
WebSphere MQ
Process Services WebSphere Process Choreographer
DB2 Information Integrator
Enterprise Service Bus
Web Services Gateway
Application Access Services
WebSphere BI Server WebSphere BI Server Foundation
Community Integration Services WebSphere Business Integration Connect
WebSphere BI Event/Message Broker
Data Access Services
WebSphere BI Adapters
DB2 Information Integrator
Enterprise applications
Enterprise data
© IBM Corporation 2004
IBM Software Group | WebSphere software
WebSphere MQ Everyplace
Customer Relationship Management (CRM)
Mobile workers
WebSphere MQ WebSphere MQ Everyplace
WebSphere MQ Event Broker WebSphere MQ Integrator Broker
Supply chain Management (SCM)
Retail stores Enterprise resource Planning (ERP)
WebSphere MQ Everyplace can extend your IT infrastructure to Mobile workers and remote machines
© IBM Corporation 2004
IBM Software Group | WebSphere software
WebSphere MQ Everyplace • Allows you to extend your infrastructure to the mobile environment with robust and dependable access to business critical applications anytime anywhere • Helps you gather transactions from the marketplace to enable realtime analysis • Supports publish and subscribe messaging when used with WebSphere MQ Integrator Broker and WebSphere MQ Event Broker • Supports fragile networks with messaging over satellite, phone lines and radio links.
© IBM Corporation 2004
IBM Software Group | WebSphere software
Adapter Architecture Integration Brokers WebSphere InterChange Server
A B C
JMS
D E
WBI Message Broker
WBI Adapter
MQOutput1
Compute2
EJB
MQOutput2
Connector
Compute1
WBI Server Foundation
MQ
JMS Adapter Framework
MQInput1
FAIL
JDBC
MDB
JMS
EJB
Servlet
MDB Web Service
Adapter Repository
BODs Configuration
© IBM Corporation 2004
JText
IBM Software Group | WebSphere software
WebSphere Business Integration Adapters - notes There is little value in providing a business integration infrastructure without providing the ‘last mile’ in terms of access to business applications and data. This is the task of this component. There are 3 separate sets of services that are provided: Adapters provide a set of capabilities for accessing business applications. These business applications generally fall into one of two categories: Custom Off The Shelf (COTS) applications are well known applications sold by vendors. As such, these applications have well defined interfaces (usually!!) for accessing the services of each application environment. Technology based adapters interact with business applications through the use of well known underlying technologies such as files, databases, queues, etc. Regardless of the type of adapter, there is a consistent infrastructure provided to enable business applications to be hooked into the business integration environment with minimal invasion of the applications. One hooked into the integration infrastructure, all of the components are available to provide integration with other application components. Many of today’s applications are available only through so-called ‘green screen’ interfaces … 3270 and 5250 interfaces. IBM BI provides a set of services to enable access to these applications within the business integration environment. There are very basic facilities for re-purposing green screens to a web based interface and then there are more programmatic capabilities available to enable programmed access and service based access to green screen based applications. Finally, there is a further set of data access components that are provided to enable access to z/OS based data. This set of components complete the diagram of Information Services that was shown earlier and allow access to a very wide spectrum of data types.
© IBM Corporation 2004
IBM Software Group | WebSphere software
Adapters to accelerate deployment WBI Adapters require implementation of WBI Server, WBI Brokers or WebSphere Application Server
Application Adapters ƒAriba Buyer ƒCentricity Gateway ƒClarify CRM ƒeMatrix ƒESRI Spatial Database ƒIndusConnect Framework ƒi2 ƒi2 Active Data Warehouse ƒJD Edwards OneWorld ƒManugistics Demand & Fulfillment Management ƒMaximo MEA ƒMetaSolv Application ƒmySAP.com ƒNightFire Applications ƒOracle Applications ƒPeopleSoft ƒPortal Infranet ƒQAD MFG/PRO ƒSAP Exchange Infrastructure ƒSiebel eBusiness Applications ƒSpirent Applications ƒTelcordia Applications ƒWebSphere Commerce
Technology Adapters ƒACORD XML ƒCOM ƒCORBA ƒe-mail ƒEnterprise JavaBean (EJB) ƒExchange ƒFIX Protocol ƒHealthcare Data Protocols ƒHTTP ƒiSeries ƒJMS ƒJText ƒJDBC ƒLotus Domino ƒSWIFT ƒXML ƒData Handler for XML ƒData Handler for EDI ƒWeb Services ƒWebSphere BI Message Broker ƒWebSphere MQ ƒWebSphere MQ Workflow
© IBM Corporation 2004
Mainframe Adapters ƒADABAS ƒCICS ƒDB2 Databases ƒIDMS Database ƒIMS Transaction Manager ƒIMS Database Manager ƒNatural ƒVSAM
e-Business Adapters ƒTrading Partner Interchange ƒiSoft Peer-to-Peer Agent
IBM WebSphere BI Adapters support ■ Multiple releases of the
application
■ Multiple application
transactions types
■ Frequent releases for
currency
IBM Software Group | WebSphere software
WebSphere Business Integration Event Broker
Internet reach in a security-rich environment
Enterprise Applications
Mobile devices
Mobile devices Inbound Information Web And Portals
Telemetry Sensors
Enterprise Applications
Event Monitoring And Control
WebSphere Business Integration Event Broker
Enterprise Integration bus, Web Services, Outbound Information Java Messaging Services
Web And Portals Telemetry Sensors
Routing Multicast Subscribers
WebSphere Business Integration Event Broker routes targeted messages in realtime from multiple devices and locations to people and applications throughout your enterprise – and beyond
© IBM Corporation 2004
IBM Software Group | WebSphere software
WebSphere Business Integration Message Broker
Internet reach in a security-rich environment
Enterprise Applications
Mobile devices
Mobile devices Inbound Information Web And Portals
Telemetry Sensors
Enterprise Applications
Event Monitoring And Control
WebSphere Business Integration Message Broker Routing Enrichment Transformation
Enterprise Integration bus, Web Services, Outbound Information Java Messaging Services
Web And Portals Telemetry Sensors
Multicast Subscribers
WebSphere Business Integration Message Broker routes targeted messages in realtime from multiple devices and locations to people and applications throughout your enterprise – and beyond © IBM Corporation 2004
IBM Software Group | WebSphere software
WebSphere Business Integration Brokers Event Broker and Message Broker enable disparate applications to be integrated without wholesale changes. Both point-to-point and publish subscribe architectures Extends the messaging model Acts as an intermediary for any-to-any application integration Routing based on message content
Application connectivity using a variety of transports:
MQ RealTime Multicast SCADA MQe
Message Broker Includes all the functions of Event broker (and is a seamless upgrade) Plus provides the function that enables complex message routing and transformation functions to be encapsulated outside of applications, in a (logically) central component.
© IBM Corporation 2004
IBM Software Group | WebSphere software
WebSphere Process Choreographer and WebSphere MQ Workflow
•Multiple applications, systems or services can be aggregated into a business process •May involve automatic as well as human interactive tasks © IBM Corporation 2004
IBM Software Group | WebSphere software
Choreography/Workflow management Separates the business logic (flow logic) from the implementation of the business functions Activity sequence can be easily updated/changed to represent changing business processes Generic interface to the process, interacting with the activities and their data rather than with applications directly Concurrency:-If a process contains parallel branches, the middleware guarantees that the branches are executed concurrently in parallel threads Recoverability:- If the system fails while executing a process based application, the execution of the application carries on where it left off – steps that have already been performed are not repeated © IBM Corporation 2004
IBM Software Group | WebSphere software
Representing the Choreography/Workflow People assignments determined by business rules invoke p1 invoke
invoke p2
Flow determined by externalized business rules
invoke
© IBM Corporation 2004
IBM Software Group | WebSphere software
WebSphere Process Choreography and WebSphere MQ Workflow - notes There are a number of services required to support business processes: • Specification of a set of activities that make up the business process. These process activities may be automated or may involve some end user (supported by user interaction services). A process that is composed entirely of automated activities is referred to as an automated process or as a straight-through process. • The activities are linked together or choreographed by use of a set of connectors. These are the black lines shown connecting together the activities. • It is possible to traverse any combination of activities (via the connectors) and so there needs to be a set of transition conditions controlling which activities are traversed. These are the predicates, labeled P1 and P2 in the picture. It is possible to traverse any combination of activities and so, for the process shown, it is possible to visit either or both of the activities in the middle of the picture. • Where there are staff activities, there needs to be some process for determining which users will be assigned which activities. This is known as staff resolution. • The business process has state – associated with all of the activities within the process. This state is maintained across the entire business process and is available to the various activities and the transition predicates. It is also available to the monitoring component of the BI architecture if required. • Business processes may be long running – especially if there are people involved in the process. Long running business process need to preserve their state so that they are recoverable in the case of failures within the environment. For this reason the state (and other data) of the process is regularly recorded in a recoverable store.
© IBM Corporation 2004
IBM Software Group | WebSphere software
IBM Business Integration Reference Architecture WebSphere BI Modeler
Model, design, development, test tools
WebSphere Studio
Common Runtime Infrastructure
WebSphere BI Monitor
Monitoring Services User Interaction Services
Application Services
Information Services
WebSphere Portal Server
WebSphere Application Server
DB2 Information Integrator
WebSphere MQ Everyplace
WebSphere MQ
Process Services
Community Integration Services
WebSphere BI Server WebSphere BI Server Foundation
WebSphere Business Integration Connect
WebSphere Process Choreographer
Enterprise Service Bus
Web Services Gateway
Application Access Services
WebSphere BI Event/Message Broker
Data Access Services
WebSphere BI Adapters
DB2 Information Integrator
Enterprise applications
Enterprise data
© IBM Corporation 2004
®
IBM Software Group
Thank You
© 2004 IBM Corporation
IBM Software Group
GSE Nordic Technical Conference May 23rd – 25th 2005 – Riga Session S19. Introduction to WebSphere MQ Queue Managers Morten Sætra [email protected]
© 2004 IBM Corporation
IBM Software Group | WebSphere software
Agenda • Messaging Fundamentals • What is a message • Introduction to Queue Manager • The MQ API • Application connection topologies • Remote messaging • Administration • Security • WebSphere MQ and the Wider World
© IBM Corporation 2004
IBM Software Group | WebSphere software
Messaging Fundamentals
• A single, multi-platform API • •
Easy to use Message centric interface Network Independent
….faster application development
• Assured message delivery • Loosely coupled applications •
Asynchronous messaging
B X
A © IBM Corporation 2004
Y
IBM Software Group | WebSphere software
Messaging Fundamentals - notes The physical world is frequently organised in queues. Consider for a moment just how many queues you have been involved in today alone. We queue at the Post Office, Supermarket checkout, at traffic lights. We write shopping lists and to do lists. We use the postal service, voice mail, and of course, the ever present e-mail. The truth is that queuing is a natural model that allows us to function efficiently. Perhaps not surprisingly therefore it turns out that it is also a very useful model in which to organise our applications. Instead of application A talking synchronously to Application B have Application A 'send a message' to a queue which Application B will read. What WebSphere MQ (aka MQSeries) did was to recognise that for the queuing model to be successful and applicable to a wide range of applications that it must achieve two major goals : First it must be totally reliable. A message put to an WebSphere MQ queue is as safe as a record written to a database. e-mail just isn't reliable enough Secondly it should be available everywhere The postal service would be severely restricted if it only covered the local city.
© IBM Corporation 2004
IBM Software Group | WebSphere software
Messaging Fundamentals - Reducing Complexity
• Reliable, distributed computing • •
Complex Error prone
• WebSphere MQ eases the complexity • WebSphere MQ is not a substitute for: • • • •
Well written applications Robust network Good operational procedures Well managed system
© IBM Corporation 2004
IBM Software Group | WebSphere software
Messaging Fundamentals - Reducing Complexity notes The WebSphere MQ base product is available on all major platforms such as Windows,AIX, HP, Solaris, iSeries, z/OS and many others. A simple API, known as the MQI, is available with only around a dozen verbs which allows an application on one platform to communicate with an application on another platform without either application requiring any explicit knowledge of each other. The goals of MQ from an application standpoint are to provide :• Time Independence It is not necessary for both applications to be up and running at the same time • Platform Independence A sending application need not know what type of platform the receiving application is running on. • Location Transparency A sending application need not know where the receiving application is nor have any knowledge of the network or communications . • Data transparency With the advent of Brokers and message translation it is not even necessary for the two applications to exchange messages in a shared format.
© IBM Corporation 2004
IBM Software Group | WebSphere software
What's a Message? Message = Header + User Data Header Header
User UserData Data
AASeries SeriesofofMessage MessageAttributes Attributes Understood and augmented Understood and augmentedby bythe theQueue QueueManager Manager •Message Id •Message Id •Correlation •CorrelationIdId •Reply •Replyrouting routinginformation information •Message •Messagepriority priority •Message •Messagecodepage/encoding codepage/encoding •Message format •Message format ....etc. ....etc.
•Any sequence of bytes •Any sequence of bytes •Private to the sending and •Private to the sending and receiving programs receiving programs •Not meaningful to the Queue Manager •Not meaningful to the Queue Manager
•Message Types -Persistent ... recoverable -Non Persistent
•Up to 100MB message length
© IBM Corporation 2004
IBM Software Group | WebSphere software
What's a Message? - notes A message in WebSphere MQ is merely a sequence of bytes in a buffer of a given length. The current products support up to 100MB in a single message although the vast majority of messages are in the order of a few thousand bytes. Messages have various attributes associated with them such as their identifier, their priority and their format. Each application is free to define its own format for messages although there are a number of predefined formats. One common format for messages is XML for example. A key attribute of a message is its persistence. A message is either persistent or nonpersistent. This attribute tells the Queue Manager how important the message is. Persistent Persistent messages are written to disk and are logged. The Queue Manager will ensure that the messages are recovered in the case of a system crash or network failure. These messages are delivered once and only once to the receiving applications. Non persistent The messages are identified by the application as non-critical. The Queue Manager will make every effort to deliver these messages but since they are not written to disk they will be lost in the case of a system crash or network failure. Clearly with no disk IO involved these messages are much faster than persistent ones.
© IBM Corporation 2004
IBM Software Group | WebSphere software
What's a Queue ?
• Place to hold messages •Various Queue Types •Local,Alias,Remote,Model
• Queue creation •Predefined •Dynamic definition
• Message Access
•FIFO •Priority •Direct •Destructive & non-destructive access •In transactions
• Parallel access by applications •Managed by the queue manager
© IBM Corporation 2004
IBM Software Group | WebSphere software
What is a Queue ? - notes A Queue is a named object (up to 48 characters) which is defined with a queue type. Local Only queue type which can actually hold messages Alias A queue name which 'points' to another queue Remote A queue which 'points' to a queue on a remote machine Model A template definition which when opened will create a temporary local queue Applications open queues, by name, and can either put or get messages to/from the queue. Messages can be got from the queue either in FIFO order, by priority or directly using a message identifier or correlation identifier. As many applications as required can open a queue either for putting or for getting making it easy to have single server responding to many clients or even n servers responding to many clients. A key feature of WebSphere MQ is its transaction support. Messages can be both put and got from queues in a transaction. The transaction can be just local, involving just messaging operations or global involving other resource managers such as a database. A classic example, is an application which gets a message, updates a database and sends a reply message all within a single transaction. If there is a failure before the transaction commits, for example a machine crash, both the database update and the received message will be rolled back. On machine restart the request message will still be on the queue allowing the application to reprocess the request.
© IBM Corporation 2004
IBM Software Group | WebSphere software
What is a Queue Manager ? Put
Utilities Command Server Listener Channel Initiator Trigger Monitor Windows Explorer
Get
MQ API
Kernal Moving Message
Local Queuing
© IBM Corporation 2004
IBM Software Group | WebSphere software
What is a Queue Manager - notes A queue manager may - generally - be thought of as 3 components: The Kernel is the part of the queue manager that understands how to implement the MQ APIs. Given that the APIs are common across the queue manager family, it stands to reason that the Kernel is mostly common code across the set of queue managers. (The primary exception to this is the z/OS queue manager where the same functions are implemented differently to support the same APIs). The Local Queuing component is the part of the queue manager responsible for interacting with the local operating system. It manages memory, the file system and any operating system primitives such as timers, signals, etc. This component insulates the Kernel from any considerations of how the underlying operating system provides services and so enables the Kernel to be operating system independent. The Message Moving component is responsible for interacting with other queue managers and with MQI clients. For environments where all of the message queuing activity is local to a system then this component is unused - though this is a very rare case. The message moving functions are provided by specialised MQ applications, called Message Channel Agents.
© IBM Corporation 2004
IBM Software Group | WebSphere software
What is a WebSphere MQ Client ?
LAN Messaging Clients DG/UX HP3000 MPE/iX Java Windows: 3.1,95,98 .NET DOS VM Apple MacOS Stratus VOS 4690 Unisys A …
WAN
Messaging Servers OS/390, z/OS Linux, zLinux AIX Windows XP, 2000 Solaris: Intel & SPARC HP-UX OS/400 OS/2 Compaq OpenVMS Compaq NSK / NSS Compaq Tru64 UNIX VSE/ESA Digital UNIX SCO: Openserver, UnixWare IRIX Dynix/ptx NCR TPF DC/OSx Sinix Unisys 2200 Hitachi
…
© IBM Corporation 2004
IBM Software Group | WebSphere software
What's a WebSphere MQ MQI Client? - notes WebSphere MQ clients provide a low cost, low resource mechanism to gain access to MQ facilities. The client provides a remote API facility, allowing an WebSphere MQ application to run on a machine that does not run a queue manager. Each MQ API command is passed to a Server queue manager where a proxy executes the required API command. The connection between client and server is entirely synchronous providing an 'rpclike' mechanism - though NO regular (well-known) rpc mechanism is used ! Also, the client machine does not own any MQ resources - all resources are held by the Server machine. Thus, if local queuing capability is required then a server (rather than a client) must be used.
© IBM Corporation 2004
IBM Software Group | WebSphere software
The MQ API Program A MQBEGIN MQGET MQINQ MQOPEN MQCONN MQBACK MQPUT MQDISC MQCLOSE MQSET MQPUT1 MQCONN(X) MQCMIT
MQI Queue Manager Process Object
Queues © IBM Corporation 2004
Queue Manager Object
IBM Software Group | WebSphere software
MQ API - notes There are 13 verbs in the WebSphere MQ API, four of which are most heavily used and the rest have less frequent use. The most common verbs will be MQOPEN, MQCLOSE, MQPUT and MQGET which are concerned with the processing of messages on queues. The other verbs have important uses but will not be used as commonly as these four. There are many, many options associated with these verbs - approximately 250! However, in general, most of these options may be left to take their default values - and MQ provides a set of default structures to allow for easy assignment of these default values. The MQ API has both a procedural implementation and an object oriented implementation. This allows for straightforward usage in both of these programming environments. All of the popular languages and programming environments are supported, for example: Assembler (z/OS) C, C++, COBOL, PL/1 RPG (AS/400) Java, JMS LotusScript,SmallTalk,Visual Basic,COM Plus application environments, e.g. CICS, IMS,Encina, Tuxedo, TXSeries, WebSphere Application Server, MTS, ...
© IBM Corporation 2004
IBM Software Group | WebSphere software
Examples of how MQ queues can be used ‘Send and Forget’ Put Invoice-Q
Get Invoice-Q Program B
Program A Invoice-Q
Request / Response
Target Queue Program B
Program A
Reply-to-Queue
© IBM Corporation 2004
IBM Software Group | WebSphere software
Examples These examples show some of the ways in which MQ queues can be used and, thereby, shows some of the styles of applications that may benefit from the use of a message/queuing model. 'Send and Forget' This style is one where there is no (direct) response required to a message. The message/queuing layer will guarantee the arrival of the data without the application having to solicit a response from the receiver. Request/Response This style is typical of many existing synchronous applications where some response is required to the data sent. This style of operation works just as well in an asynchronous environment as in a synchronous one. One difference is that - in this case - the sender does not have to wait for a response immediately. It could pick up the response at some later time in its processing. Although this is also possible with the synchronous style, it is less common.
© IBM Corporation 2004
IBM Software Group | WebSphere software
Examples… Chain Program A
Program B
Program C
Workflow Program B
Program A
Program D
© IBM Corporation 2004
Program C
IBM Software Group | WebSphere software
Examples… Chain Data does not have to be returned to the originating application. It may be appropriate to pass a response to some other application for processing, as illustrated in a chain of applications. Workflow There may be multiple applications involved in the processing before a response comes back to the originating application. These various modes of interaction may be arbitrarily combined to provide as complex/sophisticated topology as is necessary to support a particular application. The loosely coupled nature of the message queuing model makes it ideal for this style of interaction. Furthermore, it makes it straightforward to develop applications in an iterative style.
© IBM Corporation 2004
IBM Software Group | WebSphere software
Examples …Publish / Subscribe Data
C
Data
A
A
D
Pub/Sub Broker
B Data
B
E A,B
Subscription (re-) Publication
B
© IBM Corporation 2004
F
IBM Software Group | WebSphere software
Examples…Publish/Subscribe - notes In this environment, the receiving applications notify an intermediate broker of their interest in particular sets of information. The receiving (or subscribing) application provides a subject and a queue where messages matching this subject may be delivered. The sending (publishing) applications generate information, together with a subject name, and sends the information to the broker. The broker contains a matching service which determines the subscribing applications interested in receiving this information. Note that the publish/subscribe model provides for the situation where a message may be published by an application using a subject which has no subscribers. In this instance the message data is discarded. There are many publish/subscribe products available in the marketplace today. MQ publish/subscribe differentiates itself by providing support for the publish/subscribe model and combining it with the exactly once delivery model of MQ message/queuing.
© IBM Corporation 2004
IBM Software Group | WebSphere software
Examples … Clustering Q Mgr 1
B Queue 1 Q Mgr 2
B Queue 1 Q Mgr 3 Q Mgr A
A
B
?
Queue 1 Q Mgr 4
B Queue 1
© IBM Corporation 2004
IBM Software Group | WebSphere software
Examples …. Clustering The final example given here (though not the last possibility by any means) is MQ Clustering. In order to enable highly scalable applications, MQ queue managers provide support for MQ Clusters. In this environment, there are several copies (or clones) of a particular target queue and each message is sent to exactly one of the possible choices. WebSphere MQ Cluster support also defines and manages all MQ resources, such as channels, automatically and provides automatic notification of failed or new queue managers in the environment.
© IBM Corporation 2004
IBM Software Group | WebSphere software
Goals of Clustering QSERVICE
MQPUT
QSERVICE
•Multiple Queues with single image •Failure isolation •Scalable throughput •MQI applications to exploit clusters transparently •Definition through usage (MQOPEN) •MQGet always local
QSERVICE
© IBM Corporation 2004
IBM Software Group | WebSphere software
Goals of Clustering - notes Here we see a client putting to the 'QSERVICE' queue that is available in the cluster on three server queue managers. A message is MQPUT by the client and is delivered to *one* of the servers. It is processed there and a response message sent to a ReplyToQueue on the client queue manager. If a server becomes unavailable, then it is not sent any further messages and all requests are routed to the servers which are still available. In addition, to handle new workload, additional servers can be added online without requiring the application take any action at all. Both these behaviours are achieved by existing MQI applications, i.e. without change. An applications need not be aware that it is operating in a cluster environment. We can see how a cluster can provide a highly available and scalable message processing system. The administration point in processing is MQOPEN as this is when a queue or queue manager is identified as being required by an application. Note that only one message is sent to a server; it is not replicated three times, rather a specific server is chosen and the message sent there. Also note that MQGET processing is still local, we are not extending MQGET into the network.
© IBM Corporation 2004
IBM Software Group | WebSphere software
Cross System Communication with WebSphere MQ QM 1
QM 2 Program A
Put Q2
Program B
Put Q1
Program C Get Q2
Get Q1 MQI
MQI
Messaging Messaging
and
and
Queuing
Queuing Transmission Q
Q2
Q1 TCP/IP, APPC etc © IBM Corporation 2004
IBM Software Group | WebSphere software
Cross System Communication with WebSphere MQ - notes In the diagram we see Program A sending messages to two other programs. to Program B In this case the actual physical queue that both applications access are the same. This therefore does not require any network communication. to Program C In this case Program A wants to put a message to queue Q2 on Queue Manager QM2. It can't do this directly without requiring that the network and QM2 Queue Managers are available so instead the message is put to a 'holding' queue called a transmission queue. Asynchronously another part of WebSphere MQ called a channel will read this transmission queue and deliver any messages to the queues on QM2. Any number of applications running on QM1 can send messages to QM2 via the same transmission queue and channel.
© IBM Corporation 2004
IBM Software Group | WebSphere software
WebSphere MQ Systems Management Scripting MQ Application MQ Explorer Programmable Command Format
Kernal Moving Message
Local Queuing
© IBM Corporation 2004
WebSphere MQ Events
System Management Applications E.g. BMC ComputerAssociates Landmark Nastel RYO Tivoli/Candle
IBM Software Group | WebSphere software
WebSphere MQ Systems Management - notes One of the key operational components of any system is management. WebSphere MQ enables systems management in a number of ways: There are facilities provided by the MQ base to enable MQ resources to be managed. There are 'internal' utility programmes (for example, MQSC, the TSO interface for z/OS and the command line interface for AS/400). There are also documented interfaces, most notably Programmable Command Format messages which are PUT to a well known queue and are processed accordingly by the queue manager. WebSphere MQ provides events. These events are themselves MQ messages which are PUT (by the queue manager) to well known queues and provide information on state changes for various queue manager resources. The format of the event messages is documented. Text based message logs (and Windows events) are also provided. So, WebSphere MQ queue managers provide a set of documented interfaces to allow control and configuration of resources and to inform external processes of state changes within the queue manager. These interfaces may be used by any application program. Typically, this occurs in 3 ways: There are MQ utilities which make use of these interfaces. Most notably, the MQ Explorer (provided for Windows NT and 2000 environments) enables management and configuration of both local and remote queue managers using PCF messages. The majority of the established systems management vendors use the facilities described above to provide MQ 'personalities' for their products. Customers may write their own utilities to provide systems management capabilities within their organisations. This style often makes use of the messaging APIs to utilise PCF and event messages. Also scripting languages (most notably PERL) are used to provide systems management scripts for WebSphere MQ and other environments. © IBM Corporation 2004
IBM Software Group | WebSphere software
WebSphere MQ Transactional Integration • Message level selection for unit of work • Single UoW active at any one time • WebSphere MQ messages in a unit of work •
MQCMIT and MQBACK control the unit of work
• Messages and other resources in a unit of work • Managed by a Transaction Manager • WebSphere Application Server, z/OS; CICS, IMS, z/OS RRS • Microsoft Transaction Server • Any XA Transaction Manager • Managed by WebSphere MQ • WebSphere MQ is an XA Transaction Manager • MQBEGIN, MQCMIT and MQBACK control the unit of work © IBM Corporation 2004
IBM Software Group | WebSphere software
WebSphere MQ Transactional Integration - notes WebSphere MQ supports logical units of work (UoW) where a set of resource updates may be considered as an atomic unit - either all of the changes are made or none of the changes are made. This support is particularly important when using WebSphere MQ in a commercial environment (it's primary focus) as transactions play a major part in this arena. WebSphere MQ allows messages to be included/excluded from a UoW at the message level. This differs from some other environments where a UoW starts and all subsequent actions are included in the UoW. Thus, a set of messages may be considered to be a UoW. Often, it is necessary to include both MQ messages and some other recoverable resources (typically database updates) in a UoW. Typically, this has required the use of some Transaction Monitor and WebSphere MQ works well with CICS and IMS on z/OS and with any XA compliant Transaction Manager. In situations where a Transaction Manager product is not available/suitable, WebSphere MQ itself may be used as the Transaction Manager. This does not mean that WebSphere MQ is transforming itself into a Transaction Monitor, it is just providing the Transaction Manager aspect of a Transaction Monitor product. The API used in handling transactions differs according to the environment. WebSphere MQ provides some verbs to handle UoWs. If a Transaction Monitor is used, however, its UoW verbs are used in place of the MQI.
© IBM Corporation 2004
IBM Software Group | WebSphere software
WebSphere MQ Security Application Security
B Commands
A
Context
Access Control Xmit Q 2
Queue 4
Transmission
Queue 1
Queue3
Queue 5 QMgr 2
QMgr 1
© IBM Corporation 2004
IBM Software Group | WebSphere software
WebSphere MQ Security - notes There are several aspects to WebSphere MQ security: Control of WebSphere MQ commands Access to MQ commands, like creating and starting queue managers, can be controlled through operating system facilities and also by MQ facilities; it is necessary to be in a particular authorisation group to be allowed to use these commands. Access to Queue Manager objects There is an access control component that is provided by the MQ Queue Manager, called the Object Authority Manager (OAM), which controls access to Queue Manager objects, particularly queues. The OAM can control access to resources at a very granular level, allowing access for different actions, such as GET, PUT, INQ, SET, etc. This access is (generally) based upon group memberships. This security service is a pluggable component of MQ. Thus, if the OAM does not meet the requirements of the environment it is possible to provide a different (or additional) component. Note that the OAM is used for all queue managers except for the z/OS queue manager which uses any SAF compliant security manager.
© IBM Corporation 2004
IBM Software Group | WebSphere software
WebSphere MQ Security – notes continued Channel Security WebSphere MQ 5.3 provides built-in SSL link level security MQ provides a set of exit points, available in the intercommunication component. These exit points allow a set of functions to be provided: The security exit allows for (mutual) authentication of partner systems when they connect to one another. The message exits allow for customisation at the message level, allowing individual messages to be protected, in terms of message integrity, message privacy and non-repudiation Application Security This level of security is not implemented directly by the Queue Manager but such facilities may be implemented at the application level, outside of the direct control of WebSphere MQ.
© IBM Corporation 2004
IBM Software Group | WebSphere software This page intentionally left blank
© IBM Corporation 2004
IBM Software Group | WebSphere software
WebSphere MQ & the Wider World
© IBM Corporation 2004
IBM Software Group | WebSphere software
WebSphere MQ and the Wider World - notes For a messaging engine to be really useful it should allow access to the messages from many different environments. We have already discussed MQs programming language and API support but what about the environments. The complexity of overall business applications is increasing every year as more and more applications are linked together in some way. WebSphere MQ dramatically reduces an individual applications complexity by providing a consistent, reliable and transactional method of communicating between applications from hundreds of different environments. We are now going to look briefly at where WebSphere MQ fits in the Business Reference Architecture and also at some of the other WebSphere Business Integration products that make up the portfolio
© IBM Corporation 2004
IBM Software Group | WebSphere software
IBM Business Integration Reference Architecture Model, design, development, test tools Common Runtime Infrastructure
Monitoring Services
User Interaction Services
Application Services
Information Services
Process Services
Community Integration Services
Enterprise Service Bus Application Access Services
Data Access Services
Enterprise applications
Enterprise data
© IBM Corporation 2004
IBM Software Group | WebSphere software
IBM Business Integration Reference Architecture WebSphere BI Modeler
Model, design, development, test tools
WebSphere Studio
Common Runtime Infrastructure
WebSphere BI Monitor
Monitoring Services User Interaction Services
WebSphere Portal Server
Application Services
Information Services
WebSphere Application Server
WebSphere MQ Everyplace
WebSphere MQ
Process Services WebSphere Process Choreographer
DB2 Information Integrator
Enterprise Service Bus
Web Services Gateway
Application Access Services
WebSphere BI Server WebSphere BI Server Foundation
Community Integration Services WebSphere Business Integration Connect
WebSphere BI Event/Message Broker
Data Access Services
WebSphere BI Adapters
DB2 Information Integrator
Enterprise applications
Enterprise data
© IBM Corporation 2004
IBM Software Group | WebSphere software
WebSphere MQ Everyplace
Customer Relationship Management (CRM)
Mobile workers
WebSphere MQ WebSphere MQ Everyplace
WebSphere MQ Event Broker WebSphere MQ Integrator Broker
Supply chain Management (SCM)
Retail stores Enterprise resource Planning (ERP)
WebSphere MQ Everyplace can extend your IT infrastructure to Mobile workers and remote machines
© IBM Corporation 2004
IBM Software Group | WebSphere software
WebSphere MQ Everyplace • Allows you to extend your infrastructure to the mobile environment with robust and dependable access to business critical applications anytime anywhere • Helps you gather transactions from the marketplace to enable realtime analysis • Supports publish and subscribe messaging when used with WebSphere MQ Integrator Broker and WebSphere MQ Event Broker • Supports fragile networks with messaging over satellite, phone lines and radio links.
© IBM Corporation 2004
IBM Software Group | WebSphere software
Adapter Architecture Integration Brokers WebSphere InterChange Server
A B C
JMS
D E
WBI Message Broker
WBI Adapter
MQOutput1
Compute2
EJB
MQOutput2
Connector
Compute1
WBI Server Foundation
MQ
JMS Adapter Framework
MQInput1
FAIL
JDBC
MDB
JMS
EJB
Servlet
MDB Web Service
Adapter Repository
BODs Configuration
© IBM Corporation 2004
JText
IBM Software Group | WebSphere software
WebSphere Business Integration Adapters - notes There is little value in providing a business integration infrastructure without providing the ‘last mile’ in terms of access to business applications and data. This is the task of this component. There are 3 separate sets of services that are provided: Adapters provide a set of capabilities for accessing business applications. These business applications generally fall into one of two categories: Custom Off The Shelf (COTS) applications are well known applications sold by vendors. As such, these applications have well defined interfaces (usually!!) for accessing the services of each application environment. Technology based adapters interact with business applications through the use of well known underlying technologies such as files, databases, queues, etc. Regardless of the type of adapter, there is a consistent infrastructure provided to enable business applications to be hooked into the business integration environment with minimal invasion of the applications. One hooked into the integration infrastructure, all of the components are available to provide integration with other application components. Many of today’s applications are available only through so-called ‘green screen’ interfaces … 3270 and 5250 interfaces. IBM BI provides a set of services to enable access to these applications within the business integration environment. There are very basic facilities for re-purposing green screens to a web based interface and then there are more programmatic capabilities available to enable programmed access and service based access to green screen based applications. Finally, there is a further set of data access components that are provided to enable access to z/OS based data. This set of components complete the diagram of Information Services that was shown earlier and allow access to a very wide spectrum of data types.
© IBM Corporation 2004
IBM Software Group | WebSphere software
Adapters to accelerate deployment WBI Adapters require implementation of WBI Server, WBI Brokers or WebSphere Application Server
Application Adapters ƒAriba Buyer ƒCentricity Gateway ƒClarify CRM ƒeMatrix ƒESRI Spatial Database ƒIndusConnect Framework ƒi2 ƒi2 Active Data Warehouse ƒJD Edwards OneWorld ƒManugistics Demand & Fulfillment Management ƒMaximo MEA ƒMetaSolv Application ƒmySAP.com ƒNightFire Applications ƒOracle Applications ƒPeopleSoft ƒPortal Infranet ƒQAD MFG/PRO ƒSAP Exchange Infrastructure ƒSiebel eBusiness Applications ƒSpirent Applications ƒTelcordia Applications ƒWebSphere Commerce
Technology Adapters ƒACORD XML ƒCOM ƒCORBA ƒe-mail ƒEnterprise JavaBean (EJB) ƒExchange ƒFIX Protocol ƒHealthcare Data Protocols ƒHTTP ƒiSeries ƒJMS ƒJText ƒJDBC ƒLotus Domino ƒSWIFT ƒXML ƒData Handler for XML ƒData Handler for EDI ƒWeb Services ƒWebSphere BI Message Broker ƒWebSphere MQ ƒWebSphere MQ Workflow
© IBM Corporation 2004
Mainframe Adapters ƒADABAS ƒCICS ƒDB2 Databases ƒIDMS Database ƒIMS Transaction Manager ƒIMS Database Manager ƒNatural ƒVSAM
e-Business Adapters ƒTrading Partner Interchange ƒiSoft Peer-to-Peer Agent
IBM WebSphere BI Adapters support ■ Multiple releases of the
application
■ Multiple application
transactions types
■ Frequent releases for
currency
IBM Software Group | WebSphere software
WebSphere Business Integration Event Broker
Internet reach in a security-rich environment
Enterprise Applications
Mobile devices
Mobile devices Inbound Information Web And Portals
Telemetry Sensors
Enterprise Applications
Event Monitoring And Control
WebSphere Business Integration Event Broker
Enterprise Integration bus, Web Services, Outbound Information Java Messaging Services
Web And Portals Telemetry Sensors
Routing Multicast Subscribers
WebSphere Business Integration Event Broker routes targeted messages in realtime from multiple devices and locations to people and applications throughout your enterprise – and beyond
© IBM Corporation 2004
IBM Software Group | WebSphere software
WebSphere Business Integration Message Broker
Internet reach in a security-rich environment
Enterprise Applications
Mobile devices
Mobile devices Inbound Information Web And Portals
Telemetry Sensors
Enterprise Applications
Event Monitoring And Control
WebSphere Business Integration Message Broker Routing Enrichment Transformation
Enterprise Integration bus, Web Services, Outbound Information Java Messaging Services
Web And Portals Telemetry Sensors
Multicast Subscribers
WebSphere Business Integration Message Broker routes targeted messages in realtime from multiple devices and locations to people and applications throughout your enterprise – and beyond © IBM Corporation 2004
IBM Software Group | WebSphere software
WebSphere Business Integration Brokers Event Broker and Message Broker enable disparate applications to be integrated without wholesale changes. Both point-to-point and publish subscribe architectures Extends the messaging model Acts as an intermediary for any-to-any application integration Routing based on message content
Application connectivity using a variety of transports:
MQ RealTime Multicast SCADA MQe
Message Broker Includes all the functions of Event broker (and is a seamless upgrade) Plus provides the function that enables complex message routing and transformation functions to be encapsulated outside of applications, in a (logically) central component.
© IBM Corporation 2004
IBM Software Group | WebSphere software
WebSphere Process Choreographer and WebSphere MQ Workflow
•Multiple applications, systems or services can be aggregated into a business process •May involve automatic as well as human interactive tasks © IBM Corporation 2004
IBM Software Group | WebSphere software
Choreography/Workflow management Separates the business logic (flow logic) from the implementation of the business functions Activity sequence can be easily updated/changed to represent changing business processes Generic interface to the process, interacting with the activities and their data rather than with applications directly Concurrency:-If a process contains parallel branches, the middleware guarantees that the branches are executed concurrently in parallel threads Recoverability:- If the system fails while executing a process based application, the execution of the application carries on where it left off – steps that have already been performed are not repeated © IBM Corporation 2004
IBM Software Group | WebSphere software
Representing the Choreography/Workflow People assignments determined by business rules invoke p1 invoke
invoke p2
Flow determined by externalized business rules
invoke
© IBM Corporation 2004
IBM Software Group | WebSphere software
WebSphere Process Choreography and WebSphere MQ Workflow - notes There are a number of services required to support business processes: • Specification of a set of activities that make up the business process. These process activities may be automated or may involve some end user (supported by user interaction services). A process that is composed entirely of automated activities is referred to as an automated process or as a straight-through process. • The activities are linked together or choreographed by use of a set of connectors. These are the black lines shown connecting together the activities. • It is possible to traverse any combination of activities (via the connectors) and so there needs to be a set of transition conditions controlling which activities are traversed. These are the predicates, labeled P1 and P2 in the picture. It is possible to traverse any combination of activities and so, for the process shown, it is possible to visit either or both of the activities in the middle of the picture. • Where there are staff activities, there needs to be some process for determining which users will be assigned which activities. This is known as staff resolution. • The business process has state – associated with all of the activities within the process. This state is maintained across the entire business process and is available to the various activities and the transition predicates. It is also available to the monitoring component of the BI architecture if required. • Business processes may be long running – especially if there are people involved in the process. Long running business process need to preserve their state so that they are recoverable in the case of failures within the environment. For this reason the state (and other data) of the process is regularly recorded in a recoverable store.
© IBM Corporation 2004
IBM Software Group | WebSphere software
IBM Business Integration Reference Architecture WebSphere BI Modeler
Model, design, development, test tools
WebSphere Studio
Common Runtime Infrastructure
WebSphere BI Monitor
Monitoring Services User Interaction Services
Application Services
Information Services
WebSphere Portal Server
WebSphere Application Server
DB2 Information Integrator
WebSphere MQ Everyplace
WebSphere MQ
Process Services
Community Integration Services
WebSphere BI Server WebSphere BI Server Foundation
WebSphere Business Integration Connect
WebSphere Process Choreographer
Enterprise Service Bus
Web Services Gateway
Application Access Services
WebSphere BI Event/Message Broker
Data Access Services
WebSphere BI Adapters
DB2 Information Integrator
Enterprise applications
Enterprise data
© IBM Corporation 2004
®
IBM Software Group
Thank You
© 2004 IBM Corporation
Related Documents
Mq Tech Notes Ppt
June 2020 0
Nano Tech Ppt
June 2020 5
Tech Camp Notes
August 2019 9
Chem Notes Sep Tech
December 2019 2
Mq-216
May 2020 2