JBoss A-MQ is intended as a “lightweight” alternative to Red Hat’s own Enterprise Service Bus (ESB) and used to be known as Fuse Message Broker. The technology is mainly based on the Apache ActiveMQ messaging platform.
News blog (h-online.com): A new ESB and messaging platform join Red Hat’s middleware
Red Hat JBoss A-MQ product page
Red Hat JBoss A-MQ download page
Delphi and Free Pascal can connect to ActiveMQ using the native Habari Client libraries from Habarisoft.
The Apache ActiveMQ Project announced the availability of Apollo 1.6. This release introduces support for AMQP 1.0, STOMP 1.1 over WebSocket, support for message groups, management via REST with jolokia and more.
Client libraries are available for many programming languages, including Delphi and Free Pascal.
The Apache ActiveMQ developers released Apache ActiveMQ 5.8.0. This release resolves 160 issues. New features include support for AMQP (Advanced Message Queuing Protocol), JDK 7 support and management via REST with jolokia. Full details and a download link can be found in the release page http://activemq.apache.org/activemq-580-release.html.
A client library for Delphi and Free Pascal is available from Habarisoft.
Home page:
http://www.habarisoft.com/habari_activemq.html
Documentation (PDF):
http://www.habarisoft.com/download/HabariActiveMQGettingStarted.pdf
API documentation (HTML):
http://www.habarisoft.com/habari_activemq/3.3/docs/api
December 18, 2012 – Habarisoft is pleased to announce release 1.3 of Habari Client for Apollo. The new release is mainly a bug fix release.
Apollo is a messaging broker built from the foundations of the original ActiveMQ. It accomplishes this using a radically different threading and message dispatching architecture.
Habari Client libraries provide access to production-ready and industry standard based cross-platform application integration, using the peer-to-peer or the publish/subscribe communication model. They are available for the open source message brokers ActiveMQ, Apollo, HornetQ, OpenMQ and RabbitMQ.
Temporary queues are destinations with a scope limited to the connection that created it, and are removed on the server side as soon as the connection is closed. They are typically used for synchronous messaging (request/reply communication model). Their main advantage is that no queue management to provide unique destination names is required, because their uniqueness is provided by the server, and queues are removed automatically after use.
The article Designing Messaging Applications with Temporary Queues by Thakur Thribhuvan shows a typical use case. In his example, many clients send messages with healthcare system information to a static request queue destination, and pass the identity of their individual temporary queue in the ReplyTo header of the message. The recipient of the message processes incoming messages in the static request queue, and sends a reply to the temporary queue in the ReplyTo header. The originating client then consumes the reply from the temporary queue.
The author summarizes: “In this configuration, temporary destinations can be viewed as analogous to callbacks in synchronous processing, i.e., when the callee wants to reach out to the caller in a decoupled way, without the caller and callee having to know about each other in advance.“
The unit test for temporary queues in the Habari Client for RabbitMQ 1.5 demonstrates the interaction between a ‘client’ and a ‘server’ using a static queue for the requests and temporary queues for the replies.
The server code creates a static request queue (ServerRequestQueue) and a consumer for the request messages (RequestConsumer). The server then starts receiving requests (shown later, we first need to see the client side).
// SERVER: start a consumer waiting for request messages
ServerRequestQueue := Session.CreateQueue('StaticRequestQueue');
RequestConsumer := Session.CreateConsumer(ServerRequestQueue);
The client creates a destination object for the static request queue (ClientRequestQueue) and a message producer for the requests (RequestProducer). The client also a creates the temporary queue object (ClientTempQueue) and a consumer for the server response (ResponseConsumer).
// CLIENT: prepare a "normal" destination queue
ClientRequestQueue := OutSession.CreateQueue('StaticRequestQueue');
RequestProducer := OutSession.CreateProducer(ClientRequestQueue);
// CLIENT: create a temporary queue for responses
ClientTempQueue := OutSession.CreateTemporaryQueue;
// create a consumer for response messages
ResponseConsumer := OutSession.CreateConsumer(ClientTempQueue);
Now the client creates and sends a request (RequestMsg), which also specifies the temporary queue in the ReplyTo header:
// CLIENT: send message and specify a reply queue
RequestMsg := OutSession.CreateTextMessage('request');
// pass the temp queue name in the message header
RequestMsg.JMSReplyTo := ClientTempQueue;
// send it
RequestProducer.Send(RequestMsg);
The server runs a receive loop to consume requests from the static request queue:
// SERVER: get the request
RequestMsg := RequestConsumer.Receive(100);
if RequestMsg <> nil then
begin
// ... process the request
end
When the server completed the message processing, it sends the response back to the client:
// SERVER create reply queue based on message reply-to and send the response
ResponseQueue := Session.CreateQueue((RequestMsg.JMSReplyTo as IQueue).QueueName);
ResponseProducer := Session.CreateProducer(ResponseQueue);
ResponseMsg := Session.CreateTextMessage('response');
ResponseProducer.Send(ResponseMsg);
Finally, the client receives the response message:
// CLIENT: receive the ResponseMsg from the temporary queue
ReceivedResponseMsg := ResponseConsumer.Receive(100);
if ReceivedResponseMsg <> nil then
begin
// ... process the response
end else begin
// error: no response received
end;
This solution uses the terms “client” and “server” only to make the request/response communication clear: the client initiates the communication with a request, and the server responds. The “server” however is not necessarily a singular instance (a Delphi application). As the requests sent by the clients are stored in a single message queue on the message broker, it is possible to launch many identical Delphi applications, running the same logic shown above, to handle extra workload when needed.
The Apache ActiveMQ Project announced the availability of Apollo 1.5. ActiveMQ Apollo is a faster, more reliable, easier to maintain messaging broker built from the foundations of the original ActiveMQ.
This release fixes several bugs especially around Openwire and WebSockets and introduces a few improvements like support of STOMP 1.2, Auto-tuning of the per-connection buffers.
Client libraries are available for many programming languages, including Delphi and Free Pascal.
Firebird developers can use Firebird events to notify clients about changes in database record data. In the previous post, I showed and discussed some limitations of Firebird events. This post presents a solution based on message-oriented middleware.
The solutions in the first post used server-side logic in the Firebird database metadata, implemented with Firebird’s procedural language (PSQL). Information which can not be passed within Firebird events, such as the record ID of the new purchase order, can be stored in helper tables which then must be read by the database clients. So from a technical view, these solutions only replace the timer-triggered client-pull with event-triggered client-pull. This is a small step forward, at the price of increased complexity of database metadata.
Obviously, the client application which inserts a new purchase order could also send notifications to the other clients. The advantage would be that server-side PSQL code can be replaced by code written in your client-side programming language (Delphi/Free Pascal, C#, …). The PSQL code in the server-side solution looked like this:
CREATE TRIGGER PURCHASE_ORDER_INSERT FOR PURCHASE_ORDER AFTER INSERT
AS
BEGIN
POST_EVENT 'purchase_order_table_updated';
END
If we implement notifications in the client side application, similar code has to be be executed when a new order record has been inserted in the order table, using an inter-process communication method. The event notification code could look like this:
procedure TAppDataModule.PurchaseOrderAfterPost(DataSet: TDataSet); var Notification: INotification; begin Notification := NotificationService.CreateNotification(PURCHASE_ORDER_TABLE_UPDATED); Notification.SetIntProperty(PURCHASE_ORDER_ID, PurchaseOrderID.AsInteger); NotificationService.Send(Notification); end;
But advanced features like load balancing, or for notifying clients which currently are not listening, would need a high amount of custom code. Another difficult task would be the integration of clients or other systems written in an other programming languages (a PHP based order entry web app for example) – their integration with your application would only be possible after porting the notification system.
Firebird developers can use Firebird events to notify clients about changes in database record data. In this article, I will show and discuss some limitations of Firebird events and compare possible workarounds with a solution based on message-oriented middleware.
For this article we assume a common business use case:
In this scenario, repeated pulling data from the “purchase order” table causes network traffic from all client workstations – even if there are no new orders at all, and too many clients would cause network and/or server resource overload. But being a two-tier architecture, there is no service layer or application server between database and the client software which could handle the notifications. Our conclusion is that we need server side ‘push’ notifications, which will only cause network traffic when there is new data.
Habarisoft offers a special discount on software assurance for existing users of Habari Client libraries for Delphi and Free Pascal for the message brokers ActiveMQ, HornetQ, OpenMQ and RabbitMQ: two years additional software assurance are available with a 25% discount when the coupon code ‘habari251112′ is used with your purchase. This offer is limited until November 30, 2012.
