WAS v8.5 > WebSphere applications > Service integration > Service integration configurations > Bus configurations

Common issues with all bus configurations

There are planning issues and design decisions that apply to all types of service integration bus configuration.

When planning a service integration bus configuration, consider the following points:

• The volume of messages that a bus has to handle. Depending on the volume of messages anticipated, you might have to adjust the high message threshold setting for a bus or messaging engine.
• The transport chain to be used for communication between messaging engines. For more information, see Transport chains.
• Whether bus security is required. When bus security is enabled, access to the bus itself and to all destinations on the bus must be authorized. If we enable bus security, you might also want to define aliases for authenticating messaging engines and mediations accessing the bus. A single version bus does not require an authentication alias. However, if you create a mixed-version bus you must define an inter-engine authentication alias for a WebSphere Application Server v6 or v6.1 bus member, to enable it to establish trust with the other bus members of later versions.
• You must choose bus names that are compatible with the WebSphere MQ queue manager naming restrictions. We cannot change a bus name after the bus is created, which means that we can only interoperate with WebSphere MQ in the future if we use compatible names. See the topic about WebSphere MQ naming restrictions in the related links.

• When you name your buses, ensure the names are unique because we cannot connect two buses with the same name. For example, we cannot connect two buses with the same name in any of the following ways:
  • By creating an inter-bus link between two buses with the same name.
  • By attempting to connect to a remote bus from an application running in a remote cell where a bus with the same name is defined.
  • By creating a core group bridge between two cells containing buses with the same name.

Destinations

You must decide on the number and type of destinations, mediations, destination routing paths, and qualities of service for the destination for the configuration. For point-to-point messaging you define bus destinations as queues, whereas for publish/subscribe messaging you define bus destinations as topic spaces.

For point-to-point messaging only, you select one bus member as the assigned bus member that is to hold messages for the queue. This action automatically defines a queue point for each messaging engine in the assigned bus member.

We can also define alias destinations to provide a level of indirection between applications and the underlying target bus destinations. Applications interact with the alias destination, so we can change the target bus destination without changing the application.

You should decide how to use the bus destinations as we can configure a bus destination to prevent producers sending messages to the destination, or consumers receiving messages from the destination.

Message persistence

The reliability quality of service for messages on a destination has implications for performance and the amount of space required for a message store. Higher levels of reliability impact performance and increase the space a message store requires, because fewer messages are discarded.

When planning a message store configuration, remember that each messaging engine has a single message store, which can be either a file store or a data store. See Relative advantages of a file store and a data store. Remember that larger messages increase the space that a message store requires.

If we use a data store, the default database system for the data store is Apache Derby v10.3. However, you might want to use a different system, such as DB2 . We can select different data store configurations depending on your requirements; for more information see Configuration planning for a messaging engine to use a data store.

Application environment

An application attaches as a client to a messaging engine on the bus, either by an in-process call or across a network using a remote client. A remote client can run in either the Java EE application client environment or the Java EE application server environment. Various transport chains can be used.

Application connections

The way that a messaging engine is selected, and the mechanism that an application uses to reach it, is configured on a JMS connection factory. You need to decide which messaging engines the applications should connect to and on the transport chain to be used. For more information about connection factories, see Configure resources for the default messaging provider and on transport options, see Transport chains.

WebSphere MQ client links

WebSphere MQ client links allow JMS clients developed for WAS v5.1 to use messaging resources on the bus. WAS v5.1 uses a WebSphere MQ queue manager as its JMS provider so that WAS v5.1 clients connect using the MQ link protocols. A WebSphere MQ client link, in service integration, provides an attachment capability these clients can use.

Transaction logs

Plan where transaction logs will be placed. See the topic about transactional high availability in the related links.

Related concepts:

Bus configurations
Single-server bus
Interconnected buses

Related

Secure links between messaging engines

Reference:

WebSphere MQ naming restrictions

+

Search Tips   |   Advanced Search