<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://www.infra-repository.org/oiar-2013/index.php?action=history&amp;feed=atom&amp;title=BT.Message_Engine</id>
	<title>BT.Message Engine - Revision history</title>
	<link rel="self" type="application/atom+xml" href="https://www.infra-repository.org/oiar-2013/index.php?action=history&amp;feed=atom&amp;title=BT.Message_Engine"/>
	<link rel="alternate" type="text/html" href="https://www.infra-repository.org/oiar-2013/index.php?title=BT.Message_Engine&amp;action=history"/>
	<updated>2026-05-06T15:12:17Z</updated>
	<subtitle>Revision history for this page on the wiki</subtitle>
	<generator>MediaWiki 1.40.0</generator>
	<entry>
		<id>https://www.infra-repository.org/oiar-2013/index.php?title=BT.Message_Engine&amp;diff=584&amp;oldid=prev</id>
		<title>Jan Schoonderbeek: start</title>
		<link rel="alternate" type="text/html" href="https://www.infra-repository.org/oiar-2013/index.php?title=BT.Message_Engine&amp;diff=584&amp;oldid=prev"/>
		<updated>2012-11-11T23:22:21Z</updated>

		<summary type="html">&lt;p&gt;start&lt;/p&gt;
&lt;p&gt;&lt;b&gt;New page&lt;/b&gt;&lt;/p&gt;&lt;div&gt;{{Maturity|2|replaces sync and async message handling}}&lt;br /&gt;
{{Pageheaderbox4BBT&lt;br /&gt;
|name=Message Engine&lt;br /&gt;
|WorkingArea=Middleware (MW)&lt;br /&gt;
|version=0.1&lt;br /&gt;
|owner=J.A.H. Schoonderbeek&lt;br /&gt;
}}&lt;br /&gt;
This facility can receive, process and/or send messages on behalf of its clients (be they users or other applications). A &amp;quot;message&amp;quot; in this context means a combination of&lt;br /&gt;
* a message header, containing a.o. addressing data, and possibly more message meta-data, and&lt;br /&gt;
* a message body, containing the actual message data.&lt;br /&gt;
&lt;br /&gt;
The message engine can send and receives messages using one of the following two messaging styles:&lt;br /&gt;
&lt;br /&gt;
===Asynchronous messaging===&lt;br /&gt;
Asynchronous messaging is a way of data exchange that makes use of a specific data format in order to make this data routable at application level. It transmits data without making use of an internal coordination mechanism between sender and recipient. Common messaging styles:&lt;br /&gt;
* Request-reply (note that this can be both synchronous and asynchronous);&lt;br /&gt;
* Fire and forget;&lt;br /&gt;
* Publish-subscribe.&lt;br /&gt;
&lt;br /&gt;
Asynchronous messaging has some advantages over synchronous messaging:&lt;br /&gt;
* There is no communication overhead from synchronization/coordination between sender and recipient;&lt;br /&gt;
* The recipient of the message doesn&amp;#039;t have to be available or reachable at the moment the message is sent;&lt;br /&gt;
* The communication path that the message must travel need not be fixed and available; when a part of the communication path becomes unavailable while the message is in transit, a relay station may store the message until the path becomes available again (if a &amp;#039;&amp;#039;message store&amp;#039;&amp;#039; is available at that station) or reroute the message over another, available path;&lt;br /&gt;
* A recipient that was unavailable/unreachable at the moment of sending a message will still receive it, if a &amp;#039;&amp;#039;message store&amp;#039;&amp;#039; is used (often referred to as queue). The message can always be retrieved by the recipient at a later time from the store that retains the message;&lt;br /&gt;
* One sender can reach many recipients, by broadcasting (or multicasting) a message to a specific &amp;#039;&amp;#039;group recipient address&amp;#039;&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
Asynchronous messaging also has some disadvantages over synchronous messaging:&lt;br /&gt;
* Information required to detect and or/recover data from lost communication is not provided by the messaging facility itself. If detection of/recovery from message loss is needed, it should be provided by sender and receiver(s) separately, for example by making use of a separate set of (synchronous) messages or another way of data exchange.&lt;br /&gt;
* The very nature of asynchronous messaging precludes the sender to know when the recipient actually receives the message.&lt;br /&gt;
&lt;br /&gt;
Disadvantages can be overcome by the appliance of a [[BT.Message Store|Message Store]] facility.&lt;br /&gt;
&lt;br /&gt;
===Synchronous messaging===&lt;br /&gt;
Synchronous messaging transmits data in an established, synchronized relationship between sender and receiver. Messages are only sent when the sender knows that the receiver is ready to receive the data, and at the speed and/or data amount the sender knows the recipient can handle. The synchronization mechanism ensures sequentiality, e.g. by timing the communication to a fixed clock signal, or by using sequence numbers. &lt;br /&gt;
&lt;br /&gt;
Typically, an internal coordination mechanism is available to enable automated error detection and recovery (reliable message exchange).&lt;br /&gt;
&lt;br /&gt;
Synchronous messaging offers some distinct advantages over asynchronous messaging:&lt;br /&gt;
* The synchronization mechanism usually lends itself to promotion of &amp;#039;&amp;#039;reliable messaging&amp;#039;&amp;#039; where the sender has a certain level of certainty that the message that was sent is actually received;&lt;br /&gt;
* Synchronous messaging makes it possible for the sender to predict &amp;#039;&amp;#039;when&amp;#039;&amp;#039; the recipient actually receives the message.&lt;br /&gt;
&lt;br /&gt;
Synchronous messaging also has some disadvantages over asynchronous messaging:&lt;br /&gt;
* The recipient of the message must be available (reachable) at the moment the message is sent;&lt;br /&gt;
* All parts of the communication path that the message must travel need to be available. When a part of the communication path becomes unavailable while the message is in transit and no rerouting is possible, the sequentiality of the communication is lost;&lt;br /&gt;
* There is communication overhead from synchronization/coordination between sender and recipient.&lt;br /&gt;
&lt;br /&gt;
Examples for the use of Synchronous Messaging facilities are:&lt;br /&gt;
* instant messaging (IM).&lt;br /&gt;
&lt;br /&gt;
==Message processing==&lt;br /&gt;
Besides sending and receiving messages, a message engine can also perform other message-related tasks. While some of these tasks have been described in their own separate infrastructure functions (e.g. message filtering), all other tasks may be considered part of the message engine, a.o.:&lt;br /&gt;
* constructing messages for the client, based on the offered message data and addressing data (message encapsulation);&lt;br /&gt;
* deconstructing received messages for the client (message decapsulation);&lt;br /&gt;
* validating a message upon receiving it, or prior to sending it.&lt;br /&gt;
{{FunctionIcon&lt;br /&gt;
|image=Icon BBT Message Engine.png&lt;br /&gt;
}}&lt;br /&gt;
{{BBT Text Footer}}&lt;/div&gt;</summary>
		<author><name>Jan Schoonderbeek</name></author>
	</entry>
</feed>