There are often entities outside your corporation that you need to interact with. You may have trading partners, financial institutions, and vertical business portals to connect to and communicate with. These outside entities usually have established protocols that they already use for electronic communication. An Electronic Data Interchange (EDI) system may have nightly batch jobs that export flat files to an FTP site. A trading partner may expect to send and receive HTTP transmissions as its way of communicating with the outside world. A supply chain portal may require that you install one of their clients on your site in order to communicate with them through whatever protocol they dictate. Sometimes email is required as a way of sending a "Thank you for your order" message.

Ideally each of these outside entities would have a close working relationship with you, and would allow you to install a JMS client at each site. That would make communication very easy—but it's not how the world works. These other communication mechanisms may have been in place for a number of years, and their users aren't about to rip them out just because you want them to. They may not be capable of changing the way their systems work just to accommodate your JMS provider. These are "legacy systems"; in the future, they may gradually disappear, but for the time being, we have to figure out how to work with them.

Someday JMS may provide on-the-wire interoperability, and be ubiquitous. Until then, we are left to building bridges, or connectors to those other protocols. As illustrated in Figure 7.1, a connector is simply a JMS client. Its sole purpose is to receive data using the foreign protocol, create a JMS message, and send it along through your JMS-based system. Likewise an outbound connector would listen for messages from your JMS-based system and transmit the message out into the world using the protocol expected by the entity at the other end.

Figure 7.1. JMS clients can be dedicated as protocol connectors to the outside world

The JMS specification does not suggest this notion of connectors.^[7] However, legacy systems are a fact of life. In recognition of this, most JMS vendors are starting to provide connectors to legacy systems as a way to provide added value. If your JMS provider does not support the connector you are looking for, it is typically easy enough to write your own. In fact, this is an ideal situation for using CLIENT_ACKNOWLEDGE mode. As illustrated in Figure 7.2, a JMS consumer can explicitly acknowledge the receipt of the message once its data transmission has been successfully completed.

Figure 7.2. Using CLIENT_ACKNOWLEDGE, a JMS consumer can still ensure reliability when bridging to other protocols

It is important to know that end-to-end quality of service may not be guaranteed when using bridges to other protocols. In Figure 7.2, the HTTP send may succeed, yet the acknowledge( ) may fail.