9.8 Quality of service capabilities

< Day Day Up >

For a broker or router the Quality of Service capabilities are greatly affected by the qualities of the environment and that of the service providers. The following discussion focuses on the quality of service implications when using WebSphere Business Integration Message Broker.

9.8.1 Availability

By default, the WebSphere Business Integration Message Broker is a single point of failure. This is easily remedied by deploying two brokers on similar machines with an MQSeries cluster configuration. Where connection is by IP address, an IP switching facility is required.

9.8.2 Performance

Performance and capacity planning reports are available for the WebSphere Business Integration Message Broker in the form of SupportPacs from the WebSphere Business Integration Message Broker Web site at:

http://www.ibm.com/software/integration/support/supportpacs/

9.8.3 Security

Security provides confidentiality and non-repudiation by authenticating the parties involved, encrypting messages, and providing access control. Security has additional importance if the activity occurs over the public Internet. The service provider can have different approaches and levels of providing security depending on the service requestor.

SSL is available for the Internet and MQSeries protocols.

A new feature of WebSphere Business Integration Message Broker is the concept of quality of protection.

In public internet deployments, cryptographically-based protection of messages enhances security by preventing tampering and eavesdropping by hackers. The authentication services currently provided by WebSphere Business Integration Message Broker ensure that only legitimate event broker servers and clients can connect to each other. However, a hacker may still be able to observe messages in transit or tamper with messages on established connections. Message protection provides security against these kinds of attacks.

Message protection features consume processor time and can slow system throughput. However not all messages are equally sensitive, so message protection is configurable on a per-topic basis so that you get only the protection you really need. Some topics may get no message protection at all, others may get channel integrity (making it impossible for hackers to insert or delete messages undetected), or message integrity (making it impossible for hackers to alter messages undetected), or message privacy (making it impossible for hackers to observe message contents). The protection levels are cumulative, for example, if you request message privacy you get message integrity and channel integrity as well. If you request message integrity you also get channel integrity. The higher levels of protection consume more resources than the lower levels.

You may also set message protection on internal system topics. Unlike user topics this must be either enabled on all topics, or on none.

9.8.4 Transactionality

WebSphere Business Integration Message Broker provides transactional support via MQSeries or supported databases.

For external activity the message flow has to enlist in a global transaction such that all required resources are coordinated. If a message flow includes interaction with an external user database, the message flow can be configured such that all of its processing is coordinated within a transaction. This ensures that all processing is either successfully completed, or no processing is completed; thus all affected resources (queues, databases, and so on) can maintain or return to a consistent state, and data integrity is preserved.

If an error is generated in a message flow node, the default behavior taken by the broker depends on how you have created and connected the message flow, and whether the message being processed is under transactional control.

The way that the error is dealt with is determined by the following factors:

Whether you have connected the failure terminal of the node that detects the error.

Every built-in node has a failure terminal. If you connect this terminal to another node or sequence of nodes, the broker expects the error that has been detected by the node to be handled by the connected node. If you want the broker to take action to recover or report the error that has occurred in the node, do not connect the failure terminal.

Whether you have included a TryCatch node in the message flow, and connected its catch terminal to another node. See Error handling by the TryCatch node for information about error handling by the TryCatch node.
Whether you have included a Throw node in the message flow, or have thrown an exception using an ESQL THROW statement in a Compute, Database, or Filter node. You can include a Throw node at any point in the message flow, including within an error handling path. You can also force an exception using ESQL at any point in the message flow.
Whether the input message in the input node is persistent, or transactional, or both. See Error handling by the input node for information about error handling by the input node.
Whether the message itself is in error.

< Day Day Up >