JBoss Community has released the final release of HornetQ 2.3.0. This includes new features such as replication, multiple backups, multiple failover, fallback and STOMP 1.2 support as well as many other enhancements, fixes and performance tweaks.
A STOMP based Delphi and Free Pascal client library for HornetQ is available from Habarisoft.
With the current release of Habari Client for HornetQ, Delphi and Free Pascal applications can send messages to a HornetQ message broker at a rate of more than 11000 to 12000 messages per second (less than 80 microseconds per message) – on very modest hardware and running the HornetQ server on the same system, even while receiving more than 1000 messages per second from the same broker.
The next release will introduce support for STOMP level 1.2 and the HornetQ 2.3.0 open source message broker.
The next release of the Delphi and Free Pascal library Habari Client for HornetQ passed tests with HornetQ 2.3.0.CR2 in STOMP 1.2 protocol mode. In STOMP 1.2, message acknowledgment has been simplified and now uses a dedicated header.
April 2, 2013 – Habarisoft is pleased to announce release 2.0 of Habari Client for HornetQ. HornetQ is an open source project from the JBoss Community to build a multi-protocol, embeddable, very high performance, clustered, asynchronous messaging system. HornetQ is the default Java Message Service (JMS) provider in JBoss Application Server, but can also used stand-alone.
This library provides Delphi and Free Pascal developers access to production-ready and industry standard based cross-platform application integration, using the peer-to-peer or the publish/subscribe communication model.
The new release of Habari message broker client libraries introduces new features, including:
The full release notes are included in the “Getting Started” PDF documentation.
Habari Chat is a demo application for the Habari Client libraries, available with full source code and as executable in the demo downloads.
After choosing a chatroom name and a nickname, the user interface allows to send text messages. For system messages – for example when users enter or leave a chatroom – the code below is used:
The next release of Habari message broker client libraries includes an example for automatic reconnect in case of connection loss.
It uses two nested loops, where the outer loop connects and disconnects, and the inner loops processes (sends or receives) messages. If an exception occurs while sending or receiving data on the TCP socket, the program leaves the inner loop, closes the connection and restarts the outer loop.
The next major versions of Habari message broker client libraries for Delphi and Free Pascal are close to release. The new versions introduce options for easier detection of connection loss, reduced resource usage for synchronous operation mode, improved support for heart-beating (on STOMP 1.1 capable message brokers), source code refactorings, and have been tested with the open source message brokers Apache ActiveMQ 5.8.0, Apollo 1,6, HornetQ 2.3.0.CR1, OpenMQ 4.5.3 and RabbitMQ 3.0.4.
December 18, 2012 – Habarisoft is pleased to announce release 1.9 of Habari Client for HornetQ. HornetQ is an open source project from the JBoss Community to build a multi-protocol, embeddable, very high performance, clustered, asynchronous messaging system. HornetQ is the default Java Message Service (JMS) provider in JBoss Application Server, but can also used stand-alone.
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.
New in version 1.9:
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.
