Services Real Time Messaging TIBCO - ASE 12.5.2

Introduction

Adaptive Server Enterprise 12.5.2 inclut une fonctionnalité de messaging avec le package RTDS : Real Time DataServices. Cette option simplifie le développement d’une application qui intéragit avec des systèmes de messaging et des bases de données.

RTDS permet de capturer les transactions dans une base de données Adaptive Server et de les délivrer à des applications externes en temps réel. Avec ce système, le développement de polling n’est plus nécessaire et les bus de messages en temps réel sont utilisés efficacement.

Les changements de données, ou évènements, sont délivrées aux applications à travers des bus de messages JMS (Java Messaging Services) fournis par TIBCO Enterprise for JMS ou IBM Websphere MQ (dans une version future). RTDS permet de délivrer des messages vers le fournisseur de messages JMS en Transact SQL (ou encore d’extraire des messages en Transact SQL).

Configuration de RTMS (Real Time Messaging Services)

Sybase RTMS est très simple à installer : Adaptive Server 12.5.2 avec la licence ASE_MESSAGING. Seuls quelques paramètres de configuration et l’installation de procédures stockées systèmes avec le script $SYBASE/$SYBASE_ASE/scripts/installmsgsvss sont nécessaires.

Installation des procédures stockées RTMS :

isql -Usa -S<ServerName> -i$SYBASE/$SYBASE_ASE/scripts/installmsgsvss

Le rôle messaging_role doit être attribué aux logins appropriés :

grant role messaging_role to <login>

Configuration du serveur pour l’utilisation des services RealTime Messaging :

exec sp_configure 'enable real time messaging', 1

Configuration de la mémoire serveur allouée aux services RealTime Messaging :

exec sp_configure 'messaging memory', <# de pages de 2K>

Ajout du serveur local dans sysservers si ce dernier n’est pas encore implémenté :

exec sp_addserver <ServerName>, local

Concepts RTMS

Les systèmes de messaging permettent aux émetteurs et récepteur d’être découplés. Tous les composants n’ont pas systématiquement besoin d’être up et connectés. Un système de messaging peut donc être asynchrone, dans le sens où une application peut envoyer des messages sans que l’application réceptrice soit présente.

JMS (Java Messaging Services) est une API qui définit la façon dont laquelle les clients communiquent avec les fournisseurs de messages. L’émetteur de messages et le récepteur de messages sont vus comme des clients vis-à-vis du fournisseur de messages.

RTMS fournit une méthode simple pour réaliser des opérations de messaging dans des commandes SQL ou des fonctions Transact SQL.

Modèles des messages

JMS définit deux modèles de messaging :

• publication-souscription (publish-and-subscribe)
• point-to-point (queues)

Modèle point-to-point (queues)

Dans le modèle point-to-point, tout message envoyé par l’émetteur ne peut être lu que par le destinataire (application réceptrice). La destination d’un message point-to-point est une queue. Une queue peut contenir plus d’un récepteur actif mais l’API de messaging assure que le message est délivré à un unique récepteur.

Modèle publication-souscription (publish-and-subscribe)

Le modèle publication-souscription est un modèle dans lequel l’application envoyant le message est appelé le producteur de messages (message producer) et les applications recevant le message les consommateurs de messages (message consumers).

Le producteur de messages n’est pas dépendant des consommateurs de messages dans le sens où l’émetteur publie les messages vers un topic, destination du modèle. Les consommateurs de messages établissent des souscriptions vers ce topic en fonction de l’intérêt des messages dans ce topic.

Il existe deux types de souscriptions qu’il est possible d’établir dans ce modèle :

• les souscriptions durables (Durable)
• les souscriptions non durables (Non durable)

• Une souscription durable retient les messages pour le consommateur de messages même si ce dernier n’est pas connecté. C’est le fournisseur de messages qui retient les messages.
• Une souscription non durable ne retient les messages que lorsque les applications consommatrices de message sont connectées au fournisseur de message.

Format des messages

Le format du message JMS comprend trois parties :

• l’entête du message
• le corps du message
• les propriétés du message

Sélecteurs de messages (Message Selectors)

Les sélecteurs de message (Message Selectors) fournissent la façon dont les consommateurs de messages (dans le modèle publication-souscription) peuvent filtrer le flux de messages et sélectionner les messages l’intéressant. Ces filtres sont des critères sur les propriétés des messages et leurs valeurs. Le sélecteur de message n’est ni plus ni moins qu’une clause Where SQL Ansi 92.

ASE 12.5.2 - RTMS et le modèle Point-to-Point (Queues)

Avec les fonctions msgsend et msgrecv, les applications Transact-SQL peuvent envoyer des messages vers une queue JMS ou lire des messages dans une queue JMS.

Un corps de message peut être construit en utilisant la logique applicative, ou bien peut contenir des données chaînes de caractères ou binaires directement à partir des tables.

Les valeurs des propriétés des messages peuvent provenir des données relationnelles ou de la logique applicative, et spécifier alors les propriétés du message lors de l’envoi du message.

Les messages lus à partir de la queue JMS peuvent être traités par la logique applicative ou insérés directement dans des tables relationnelles. Pour filtrer les messages, il suffit de spécifier le sélecteur de message.

Envoi de messages vers une queue : msgsend

select msgsend (message_body, end_point [options_and_properties])

options_and_properties ::= [option_clause] [properties_clause]
option_clause::= [,] option option_string
properties_clause ::= [,] message property option_string
message_body := scalar_expression | (select_for_xml)
end_point := basic_character_expression

Exemples :

Envoi d’un message 'hello world' avec la propriété city valant Detroit :

select msgsend('hello world', 'tibco_jms:tcp://my_jms_host:7222?queue=queue.sample'
MESSAGE PROPERTY 'city=Detroit')

Envoi d’un message 'hello' avec plusieurs propriétés :

select msgsend ('hello', 'my_jms_provider?queue=queue.sample'
MESSAGE PROPERTY 'ttl=30,category=5, rate=0.57, rank=''top'',priority=6')

Envoi d’un message dont le corps contient le résultat SQLX d’une requête SQL :

select msgsend ((select * from pubs2..publishers FOR XML), 'tibco_jms:tcp://my_jms_host:7222?queue=queue.sample')

Réception de messages en provenance d’une queue : msgrecv

select msgrecv (end_point options_filter_and_returns)

options_filters_and_return ::= [option_clause] [filter_clause] [returns_clause]
option_clause::= [,] option option_string
filter_clause::= [,] message selector message_filter
message_filter::=basic_character_expression
returns_clause ::= [,] returns sql_type
end_point := basic_character_expression
sql_type ::=varchar(integer) | java.lang.String | text | varbinary( integer ) | image

Exemples :

Réception d’un message avec le sélecteur color=red et shape=squate :

declare @mymsg varchar (16384)
select @mymsg = msgrecv('my_jms_provider?queue=queue.sample',OPTION 'timeout=1000'
MESSAGE SELECTOR 'color = ''red'' and shape=''square''')

Réception d’un message et insertion dans une table :

create table T1(c1 numeric(5,0)identity, m text)
insert into T1
select msgrecv('my_jms_provider?queue=queue.sample',RETURNS text)

ASE 12.5.2 - RTMS et le modèle publication-souscription (Topics)

Souscriptions aux topics : sp_msgadmin

Pour publier ou consommer des messages, une souscription doit être définie au niveau du serveur à l’aide de la procédure stockée T-SQL sp_msgadmin 'register'

exec sp_msgadmin 'register', 'subscription', 'subscription_1',
'my_jms_provider?topic=topic.sample,user=user1,password=pwd',
'Supplier=12345',null, 'durable1', 'client'

Envoi de messages vers un topic : msgpublish

msgpublish émet un message vers un topic à travers une souscription créée avec sp_msgadmin

select msgpublish
('Sending order', 'subscription_1',
MESSAGE PROPERTY 'Supplier=12345')

Réception d’un message en provenance d’un topic : msgsubscribe, msgunsubscribe et msgconsume

La cinématique de consommation d’un message d’un topic défini au niveau du serveur ASE par une souscription se déroule de la façon suivante :

• appel de la fonction T-SQL msgsubcribe pour indiquer au fournisseur JMS de conserver les messages dans le topic jusqu’à ce que la logique applicative ait terminé le traitement.
• appel de la fonction msgconsume pour le traitement de la réception du message, en spécifiant éventuellement le sélecteur de message.
• appel de la fonction T-SQL msgunsubscribe pour indiquer au fournisseur JMS que l’application n’est plus intéressée par les messages. msgunsubscribe est capable de supprimer les messages durables au niveau du fournisseur JMS.

select msgsubscribe('subscription_1')
declare @mymsg varchar(16384)
select @mymsg = msgconsume('subscription_1')
select msgunsubscribe('subscription_1')