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 you 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 Version 6 or Version 6.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. You cannot change a bus name after the bus is
created, which means that you can only interoperate with
WebSphere MQ in the future if you use
compatible names. See the topic about
WebSphere MQ naming restrictions in the
related links.
- When you name your buses, you must ensure that the names are unique
because you cannot connect two buses with the same name. For example,
you 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 your 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.
- You 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 you can change the target
bus destination without changing the application.
- You should decide how you want to use the bus destinations as
you 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 you use a data store, the default database system for the data
store is Apache Derby Version 10.3. However, you might want to use
a different system, such as DB2®.
You 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 by 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 Configuring 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 WebSphere Application
Server Version 5.1 to use messaging resources on the bus.
WebSphere Application Server Version 5.1 uses a
WebSphere MQ queue manager as its JMS
provider so that
WebSphere Application Server Version
5.1 clients connect using the MQ link protocols. A
WebSphere MQ client link, in service
integration, provides an attachment capability that these clients
can use.
- Transaction logs
- Plan where transaction logs will be placed. See the topic about
transactional high availability in the related links.