An Introduction to the Publish-and-Subscribe Model

Integration Server is the central run-time component of a publish-subscribe solution. It serves as the entry point for the systems and applications that you want to integrate, and is the system’s primary engine for the execution of integration logic. It also provides the underlying handlers and facilities that manage the orderly processing of information from resources inside and outside the enterprise. Integration Server publishes documents to and receives documents from Universal Messaging or Broker. For more information about Integration Server, see webMethods Integration Server Administrator’s Guide .

The messaging provider servers as the intermediary that routes documents between publishers and subscribers. The messaging provider receives, queues, and delivers documents. It provides the infrastructure for implementing synchronous or asynchronous, message-based solutions that are built on the publish-and-subscribe model or one of its variants, request/reply or publish-and-wait.

The webMethods suite includes two messaging providers that you can use:

• Universal Messaging
• Broker

For more information about these products, see the respective product documentation.

In an integration solution built on the publish-and-subscribe model, applications publish and subscribe to documents. Documents are objects that webMethods components use to encapsulate and exchange data. A document represents the body of data that a resource passes to webMethods components. Often it represents a business event such as placing an order (purchase order document), shipping goods (shipping notice), or adding a new employee (new employee record).

Each published document includes an envelope. The envelope is much like a header in an email message. The envelope records information such as the sender’s address, the time the document was sent, sequence numbers, and other useful information for routing and control. It contains information about the document and its transit through your webMethods system.

Every published document is associated with a publishable document type. A publishable document type is a named schema-like definition that describes the structure of a particular kind of document that can be published and subscribed to. An instance of a publishable document type can either be published locally within an Integration Server, or can be published to a to a messaging provider. In a publication environment that includes a messaging provider, each publishable document type is bound to a provider definition.

For more information about publishable document types, see webMethods Service Development Help .

Triggers, specifically webMethods messaging 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.

Prior to Integration Server 9.5 SP1, a webMethods messaging trigger was called a Broker/local trigger.

For more information about triggers, see webMethods Service Development Help .

Services are method-like units of work. They contain logic that Integration Server executes. You build services to carry out work such as extracting data from documents, interacting with back-end resources, and publishing documents to the messaging provider. When you build a trigger, you specify the service that you want to use to process the documents that you subscribe to.

For more information about building services, see webMethods Service Development Help .

Adapter notifications notify your webMethods system whenever a specific event occurs on an adapter's resource. The adapter notification publishes a document when the specified event occurs on the resource. For example, if you are using the Adapter for JDBC and a change occurs in a database table that an adapter notification is monitoring, the adapter notification publishes a document containing data from the event and sends it to Integration Server. Each adapter notification has an associated publishable document type. Integration Server assigns this document type the same name as the adapter notification but appends “PublishDocument” to the name.

You can use triggers to subscribe to the publishable document types associated with adapter notifications. The service associated with the publishable document type in the trigger condition might perform some additional processing, updating, or synchronization based on the contents of the adapter notification.

A canonical document is a standardized representation that a document might assume while it is passing through your webMethods system. A canonical document acts as the intermediary data format between resources.

For example, in an implementation that accepts purchase orders from companies, one of the steps in the process converts the purchase order document to a company’s standard purchase order format. This format is called the 'canonical' form of the purchase order document. The canonical document is published, delivered, and passed to services that process purchase orders.

By converting a document to a neutral intermediate format, subscribers (such as adapter services) only need to know how to convert the canonical document to the required application format. If canonical documents were not used, every subscriber would have to be able to decode the native document format of every publisher.

A canonical document is a publishable document type. The canonical document is used when building publishing services and subscribed to when building triggers. In flow services, you can map documents from the native format of an application to the canonical format.