Buses [Collection]

A service integration bus supports applications using message-based and service-oriented architectures. A bus is a group of interconnected servers and clusters that have been added as members of the bus. Applications connect to a bus at one of the messaging engines associated with its bus members.

To view this page in the console, click the following path:

Service integration -> Buses.

To browse or change the properties of a listed item, select its name in the list.

To act on one or more of the listed items, select the check boxes next to the names of the items to act on, then use the buttons provided.

To change which entries are listed, or to change the level of detail displayed for those entries, use the Filter settings.

A messaging engine manages messaging resources and, through destinations assigned to the messaging engine, provides a connection point to which both local and remote applications connect to access messaging resources on the bus. If we add an application server or a server cluster as a bus member, a messaging engine is automatically created for this new member. If we add the same server as a member of multiple buses, the server is associated with multiple messaging engines (one messaging engine for each bus). Create additional messaging engines for use with server clusters that are bus members, for availability and scalability reasons. However, in its simplest form a bus can be realized by a single engine.

The functions of service integration buses comprise the SIB service, which is available on each application server in the WebSphere Application Server environment. By default, the SIB service is disabled, so when a server starts it cannot undertake any messaging. If we add the server to a service integration bus, the SIB service is automatically enabled. If required, we can disable the service again by configuring the server.

The bus appears to its applications as if it were a single logical entity, which means applications only have to connect to the bus and do not have to be aware of the bus topology. In many cases the knowledge of how to connect to the bus and of which bus resources are defined are handled by a suitable API abstraction, such as the administered JMS connection factory and JMS destination objects

Name

The name of the service integration bus. Choose a unique name.

The system is unable to differentiate between upper and lowercase characters in bus names. For example, we will not be able to create two buses named BUS1 and bus1 because they will not be recognized as different to each other.

Description

An optional description for the bus, for administrative purposes.

Security

Security of our service integration bus can be managed from here.

Buttons

Button	Description
New	Create a new administrative object of this type.
Delete	Delete the selected items.