JMS and Traditional Broker Applications
webMethods Broker works with both "traditional" (that is, non-JMS) applications built with the Broker API and JMS applications.
Clients built using the
Broker API exchange data by publishing and subscribing to document types. Document types are created with
Software AG Designer running under
webMethods Integration Server.
The Broker API is a rich messaging API that allows a high degree of customizing. Compared to JMS messages, Broker documents have available a greater number of acknowledgment modes. Broker documents can be validated, and you can filter on any field (in a JMS message, you can only filter header and property fields). Generally, you want to use traditional Broker applications when your messaging environment has requirements such as the ones listed above that are not available under JMS.
See
Managing Clients for information about working with traditional
Broker applications.
JMS applications, which can be standalone applications,
webMethods Integration Server (IS) clients, or Java EE applications, exchange data with
Broker using JMS message producers and consumers. All of these applications are built using the JMS API.
Working with JMS allows you to implement a standards-based mechanism for your messaging environment. In most cases, JMS programs store their administered objects in a JNDI namespace, a vendor-neutral naming and directory API. Generally, you want to use JMS for messaging when using a standards-based messaging application or when portability is a primary consideration.