Webmethods Broker

webMethods Broker:

A Broker is where the client programs connect, where document types are stored, and where client queues and subscriptions are monitored and stored.
Each Broker Server has one or more entities, called Brokers that reside on it.
When a Broker client publishes a document, the Broker determines which Broker clients have subscribed to that document and places the document in the matching Broker client queues.
webMethods Broker is the primary component & facilitates asynchronous, message based integration using the publish and subscribe model, in a WM integration environment.

Broker Server Host:

The system on which you install the webMethods Broker software is called the webMethods Broker Server Host.

Broker Architecture and Components:

webMethods Broker consists of two main components: Broker Server, the run‐time component with which publishers and subscribers interact.
Broker user interface, the administrative component that runs on My webMethods Server. You use the Broker user interface to configure, monitor, and manage one or more Broker Servers and the Brokers that they host.
The Broker user interface is a plug‐in that executes on my webMethods Server. It enables you to manage webMethods Broker from any browser‐equipped computer in your organization’s network.
Any machine that hosts a Broker Server will also host a Broker Monitor. The Broker Monitor is automatically installed when you install Broker Server.
Broker Monitor monitors all of the Broker Servers running on the machine where it is installed. It will automatically attempt to restart any Broker Server that stops running.

Publish-and-Subscribe Model:

publish‐and‐subscribe model is a specific type of message‐based solution in which applications exchange messages through a third entity called a broker.
Publishers: Applications that produce information & send the information to the broker entity.
Subscriber: Applications that require the information connect to the broker and retrieve the information from the broker entity.

In the pub‐sub model, information producers and consumers are de‐coupled, meaning they do not interact with one another directly. Instead, each participant interacts only with the message and the broker entity.

Participants in a pub‐sub solution interact asynchronously. A program that produces information does not have to wait for the consumer to acknowledge receipt of that information. It simply publishes the information to the broker and continues processing.

Document Type:

Documents are messages that travel over a network from a publisher to a subscriber, through the Broker.

Two Document Types:

If the Integration Server on which you have a session is connected to a Broker, when you make an IS document type publishable, the Integration Server automatically creates a Broker document type. The Integration Server automatically assigns the Broker document type a name.

Territories:

Brokers can share information about their document type definitions and client groups by joining a territory.
Documents can travel from clients on one Broker to clients on another Broker in the same territory.

Gateways:

Gateways are links that you establish between territories.
A gateway enables clients in one territory to receive documents that are published in another territory.

Publishing a document to broker:

Publishing Documents When the Broker Is Not Available:

If the Broker is not connected, the Integration Server routes guaranteed documents to an outbound document store. The documents remain in the outbound document store until the connection to the Broker is re‐established.

Publishing Documents and Waiting for a Reply:

In a publish‐and‐wait scenario, a service publishes a document (a request) and then waits for a reply document. This is sometimes called the request/reply model. A request/reply can be synchronous or asynchronous.
In a synchronous request/reply, the publishing flow service stops executing while it waits for a response. When the service receives a reply document from the specified client, the service resumes execution.
In an asynchronous request/reply, the publishing flow service continues executing after publishing the request document. That is, the publishing service does not wait for a reply before executing the next step in the flow service. The publishing flow service must invoke a separate service to retrieve the reply document.

Subscribe Path for Published Documents:

When a document is published or broadcast, the Broker places a copy of the document in the client queue for each subscribing trigger. Each subscribing trigger will retrieve and process the document.

The Subscribe Path for Delivered Documents:

A publishing service can deliver a document by specifying the destination of the document. That is, the publishing service specifies the Broker client that is to receive the document. When the Broker receives a delivered document, it places a copy of the document in the queue for the specified client only.

Triggers (Broker/Local Triggers):

Trigger, specifically Broker/local triggers establish subscriptions to publishable document types.
Triggers also specify the services that will process documents received by the subscription. Within a trigger, a condition associates one or more publishable document types with a service.

The Broker Server installation software creates a default Broker Server that runs on port number 6849.

Open Integration Server Administration page.(http://localhost:5555)
Click on Broker under Settings Tab in Navigation panel.
Now you can see in the above picture under Broker Connection that Connected filed is shown as No.
Now Click on Edit Broker Settings.

THANK YOU