EMS, or the messaging system, defines system standards for organizations so they can define their enterprise application messaging process with a semantically precise messaging structure. EMS encourages you to define a loosely coupled application architecture in order to define an industry-accepted message structure; this is to ensure that published messages would be persistently consumed by subscribers. Common formats, such as XML or JSON, are used to do this. EMS recommends these messaging protocols: DDS, MSMQ, AMQP, or SOAP web services. Systems designed with EMS are termed Message-Oriented Middleware (MOM).

Let's review the behavior offered by both asynchronous and synchronous communication on the part of applications while messaging.

Note the following about asynchronous communication:

• Both the applications need not be active when they communicate
• No "message received" acknowledgments are required
• Provides nonblocking calls
• Useful when massive communication processing is required
• Allows efficient usage of hardware resources

Note the following about synchronous communication:

• Both the applications need to be active when they communicate
• The sender receives a confirmation (acknowledgment/response) from the receiver
• Provides blocking calls
• Useful when an immediate response is required during message processing/communication

Take a look at the following diagram:

While designing a system with enterprise messaging standards, consider the following points:

• Application security: If the systems are integrated over public interfaces or in the enterprise with more than one messaging system, they should be encrypted. Two-way SSL is another recommended security feature that should be considered to ensure that messages are sent and received between known application names and servers.
• Routing: Message routing rules carry great importance with regard to safely passing through the routing system and delivering only those messages the subscribing system is subscribed for. Different message headers, message types, or XPath rules need to be considered while defining routing rules.
• Metadata: Metadata helps greatly in defining additional information that we want to send along with the message to help the receivers uniquely identify the message along with the publisher information; the message body should only contain the actual message transformed into the receiving system's format.
• Subscription: Each system needs to have a set of subscription rules and the ability to define its own subscription policy with rules to route the messages toward them. A single message may be delivered to more than one subscriber based on the commonality in the subscription rules they set up for routing.
• Policy: EMS's need to define a common policy across messages that would define the message access levels at the field level for each component and user role.