Streaming de types de données d’objets volumineux dans l’adaptateur Oracle Database
L’adaptateur Microsoft BizTalk pour Oracle Database prend en charge la diffusion en continu pour les types de données Oracle grands objets (LOB). Avec l’adaptateur Oracle Database, les opérations sont appelées et les réponses sont retournées en échangeant des messages SOAP. Un corps de message SOAP est composé de nœuds XML.
Il existe deux types de diffusion de messages pris en charge par l’adaptateur :
Streaming de nœuds. Dans le streaming de nœud, chaque nœud est mis en mémoire tampon par l’adaptateur avant d’être envoyé à la base de données Oracle (ou retourné au client). Cela signifie que, pour un type de données métier, la valeur entière est lue dans une mémoire tampon.
Streaming de valeur de nœud. Dans le streaming de valeur de nœud, la valeur réelle du nœud peut être diffusée en blocs entre la base de données Oracle et le client. La diffusion en continu de valeur de nœud prend en charge la diffusion en continu de bout en bout de types de données métier entre le client de l’adaptateur et la base de données Oracle.
Ces deux modes de diffusion en continu s’appuient sur la prise en charge de la diffusion en continu de nœuds et de la diffusion en continu de valeur de nœud sur les messages dans WCF. Pour cette raison, la diffusion en continu pour les types métier est étroitement liée à la façon dont les messages sont créés et consommés à la fois par l’adaptateur et par une application cliente. L’un des résultats est que la prise en charge des types métier de streaming n’est pas la même pour tous les modèles de programmation.
Les sections de cette rubrique fournissent :
Informations de base sur la façon dont la diffusion en continu de messages est prise en charge dans WCF et comment elle est implémentée par l’adaptateur.
Informations sur la prise en charge de la diffusion en continu pour les types de données métier lorsque vous utilisez l’adaptateur dans chaque modèle de programmation.
Notions de base du streaming
La prise en charge de la diffusion en continu implémentée par l’adaptateur Oracle Database est une combinaison des éléments suivants :
Prise en charge de la diffusion en continu de messages dans WCF.
Prise en charge de la diffusion en continu dans la bibliothèque cliente Oracle (ODP.NET).
La façon dont les messages sont créés et consommés en interne par l’adaptateur.
Prise en charge de la diffusion en continu de messages dans WCF
La façon dont WCF prend en charge la diffusion en continu sur un message dépend à la fois de la façon dont le message est créé et de la façon dont le message est consommé.
Un message WCF est créé à l’aide de la méthode Create statique de System.ServiceModel.Channels.Message. Cette méthode présente plusieurs surcharges qui prennent en charge différentes façons de passer le corps du message. Un message WCF peut être créé en transmettant le corps du message à l’aide de :
Une System.Xml. XmlReader, ou
System.ServiceModel.Channels.BodyWriter.
Un message WCF peut être utilisé à l’aide de
Un XmlReader en appelant Message.GetReaderAtBodyContents(), ou
XmlDictionaryWriter en appelant Message.WriteBodyContents(XmlDictionaryWriter).
Le tableau suivant montre comment WCF se comporte pour différentes combinaisons de création et de consommation de messages.
| Message créé avec | Message consommé avec | Comportement WCF |
|---|---|---|
| XmlBodyWriter | Xmldictionarywriter | La diffusion en continu de valeur de nœud est prise en charge. WCF canalise les deux enregistreurs ensemble pour activer la diffusion en continu. XmlBodyWriter et XmlDictionaryWriter doivent prendre en charge le streaming de valeur de nœud pour qu’il se produise. |
| XmlBodyWriter | XmlReader | La diffusion en continu de nœuds est prise en charge. WCF met en mémoire tampon le XmlReader en interne. |
| XmlReader | Xmldictionarywriter | La diffusion en continu de nœuds est prise en charge. WCF met en mémoire tampon le XmlReader en interne et rappelle le XmlDictionaryWriter. |
| XmlReader | XmlReader | La diffusion en continu de nœuds est prise en charge. WCF met en mémoire tampon le XmlReader en interne. |
Prise en charge de la diffusion en continu dans la bibliothèque cliente Oracle (ODP.NET)
ODP.NET prend en charge la diffusion en continu de la manière suivante :
La diffusion en continu est prise en charge uniquement sur les types de données Métier Oracle.
Pour certaines opérations de table (et de vue), les types de données métier sont mis en mémoire tampon. Par conséquent, aucune diffusion en continu n’est prise en charge.
Gestion interne des messages par l’adaptateur
L’adaptateur prend en charge la diffusion en continu de la manière suivante :
L’adaptateur étend Message pour implémenter une classe de message personnalisée, Microsoft.AdapterUtilities.AdapterMessage. Il crée un AdapterMessage pour tous les messages WCF qu’il fournit au client de l’adaptateur ; cela inclut les messages de réponse pour toutes les opérations sortantes et le message de demande pour l’opération POLLINGSTMT. Cela permet à l’adaptateur de prendre en charge la diffusion en continu de valeur de nœud pour l’opération ReadLOB en fournissant un XmlReader qui prend en charge ReadValueChunk aux clients d’adaptateur.
L’adaptateur consomme tous les messages reçus du client à l’aide d’une implémentation personnalisée de XmlDictionaryWriter.
L’adaptateur crée tous les messages qu’il envoie au client à l’aide d’une implémentation personnalisée de XmlBodyWriter, à l’exception du message de réponse ReadLOB. (Cela inclut les messages de réponse pour toutes les opérations sortantes et le message de demande pour l’opération POLLINGSTMT.)
Prise en charge de la diffusion en continu dans le modèle de canal WCF
Le tableau suivant fournit des informations détaillées sur la prise en charge de la diffusion en continu dans le modèle de canal WCF.
| Opération | Streaming de nœuds | Node-Value Streaming | Description |
|---|---|---|---|
| Opération d’insertion de table | Pris en charge* | Non pris en charge entre l’adaptateur et la base de données Oracle. Pris en charge entre le client et l’adaptateur.* | La diffusion en continu de la valeur de nœud de bout en bout n’est pas prise en charge, car les valeurs des colonnes métier sont mises en mémoire tampon par ODP.NET, puis l’insertion est effectuée. Toutefois, la diffusion en continu de valeur de nœud entre le client et l’adaptateur est possible pour les colonnes métier, si le client crée le message avec un BodyWriter. |
| Opération De sélection de table | Pris en charge | Prise en charge | L’adaptateur utilise un BodyWriter pour créer le message de réponse. Si le client consomme le message à l’aide d’un XmlDictionaryWriter, la diffusion en continu de valeur de nœud pour les colonnes métier se produit. |
| Opération de mise à jour de table | Prise en charge | Non pris en charge entre l’adaptateur et la base de données Oracle. Pris en charge entre le client et l’adaptateur. | La diffusion en continu de la valeur de nœud de bout en bout n’est pas prise en charge, car les valeurs des colonnes métier sont mises en mémoire tampon par ODP.NET, puis la mise à jour est effectuée. Toutefois, la diffusion en continu de valeur de nœud entre le client et l’adaptateur est possible pour les colonnes métier si le client crée le message avec un BodyWriter. |
| Opération de suppression de table | Prise en charge | Non pris en charge entre l’adaptateur et la base de données Oracle. Pris en charge entre le client et l’adaptateur. | La diffusion en continu de la valeur de nœud de bout en bout n’est pas prise en charge, car les valeurs des colonnes métier sont mises en mémoire tampon par ODP.NET, puis la suppression est effectuée. Toutefois, la diffusion en continu de valeur de nœud entre le client et l’adaptateur est possible pour les colonnes métier si le client crée le message avec un BodyWriter. |
| Opération ReadLOB de table | Pris en charge | Pris en charge | L’opération ReadLOB est principalement conçue pour diffuser en continu des colonnes de données métier dans le modèle de service WCF. Dans le modèle de canal WCF, si le client consomme le message à l’aide d’un XmlReader (en appelant la méthode GetReaderAtBodyContents sur le message de réponse), la diffusion en continu de valeur de nœud de bout en bout se produit. Cela est dû au fait que l’adaptateur retourne un XmlReader qui prend en charge les appels ReadValueChunk pour le message de réponse ReadLOB. Toutefois, il est recommandé de ne pas utiliser l’opération ReadLOB à partir du modèle de canal WCF. Vous pouvez utiliser une opération Select ou une opération SQLEXECUTE à la place. |
| Opération UpdateLOB de table | Prise en charge | Pris en charge | L’adaptateur utilise un XmlDictionaryWriter pour consommer le message de demande. Si le client utilise un BodyWriter pour créer le message de demande, la diffusion en continu de la valeur de nœud de bout en bout pour les données métier se produit. |
| Opération SQLEXECUTE | Pris en charge | Prise en charge | L’adaptateur utilise un BodyWriter pour créer le message de réponse. Si le client utilise un XmlDictionaryWriter pour consommer le message de réponse, la diffusion en continu de la valeur de nœud de bout en bout pour les données métier se produit. La diffusion en continu de valeur de nœud de bout en bout n’est pas prise en charge pour le message de demande, car l’adaptateur doit mettre en mémoire tampon tous les opérandes avant de pouvoir appeler l’opération sur la base de données Oracle. |
| Procédure stockée et opération de fonction | Pris en charge | Pris en charge | L’adaptateur utilise un BodyWriter pour créer le message de réponse. Si le client utilise un XmlDictionaryWriter pour consommer le message de réponse, la diffusion en continu de la valeur de nœud de bout en bout pour les données métier se produit. (Cela signifie que la diffusion en continu est prise en charge pour les paramètres de procédure et de fonction OUT et IN OUT dans le message de réponse.) La diffusion en continu de valeur de nœud de bout en bout n’est pas prise en charge pour le message de demande, car l’adaptateur doit mettre en mémoire tampon tous les opérandes avant de pouvoir appeler l’opération sur la base de données Oracle. |
| Opération POLLINGSTMT | Pris en charge | Prise en charge | L’adaptateur utilise un BodyWriter pour créer le message de requête POLLINGSTMT. Si le client consomme le message à l’aide d’un XmlDictionaryWriter, la diffusion en continu de valeur de nœud pour les colonnes métier se produit. |
Pour plus d’informations sur l’implémentation du streaming de données métier dans votre code lorsque vous utilisez le modèle de canal WCF, consultez Streaming Oracle Database LOB Data Types Using the WCF Channel Model.
Prise en charge de la diffusion en continu dans le modèle de service WCF
La sérialisation et la désérialisation entre la représentation XML d’un message et la représentation par objet code managé de ce message nécessite l’écriture et la lecture de l’intégralité du message en mémoire. Pour cette raison, ni la diffusion en continu de nœuds ni la diffusion en continu de valeur de nœud ne sont prises en charge pour la plupart des opérations.
La seule exception à cela est l’opération ReadLOB. Cette opération est implémentée spécifiquement pour prendre en charge la diffusion en continu de bout en bout pour la lecture de la table et l’affichage des colonnes métier dans le modèle de service WCF.
Prise en charge de la diffusion en continu dans BizTalk Server
Le tableau suivant fournit des informations détaillées sur la façon dont la diffusion en continu est prise en charge dans BizTalk Server. (Toutes les références à l'« adaptateur » font référence à l’adaptateur Oracle Database ; l’adaptateur WCF-Custom est toujours référencé par son nom complet dans ce tableau.)
| Opération | Node Streaming | streaming Node-Value | Description |
|---|---|---|---|
| Opération d’insertion de table | Pris en charge* | Non pris en charge entre l’adaptateur et la base de données Oracle ; toutefois, les données sont diffusées entre BizTalk Server et l’adaptateur. | La diffusion en continu de valeur de nœud de bout en bout n’est pas prise en charge, car les valeurs des colonnes métier sont mises en mémoire tampon par ODP.NET, puis l’insertion est effectuée. Toutefois, la diffusion en continu de valeur de nœud entre BizTalk Server et l’adaptateur est prise en charge pour les types de données métier, car l’adaptateur WCF-Custom crée le message avec un BodyWriter. |
| Opération de sélection de table | Pris en charge | Pris en charge | L’adaptateur WCF-Custom utilise un XmlDictionaryWriter pour consommer le message de réponse. Ainsi, la diffusion en continu de valeur de nœud de bout en bout pour les types métier est prise en charge. |
| Opération de mise à jour de table | Pris en charge | Non pris en charge entre l’adaptateur et la base de données Oracle ; toutefois, les données sont diffusées entre BizTalk Server et l’adaptateur. | La diffusion en continu de la valeur de nœud de bout en bout n’est pas prise en charge, car les valeurs des colonnes métier sont mises en mémoire tampon par ODP.NET, puis la mise à jour est effectuée. Toutefois, la diffusion en continu de valeur de nœud entre BizTalk Server et l’adaptateur est prise en charge pour les types de données métier, car l’adaptateur WCF-Custom crée le message avec un BodyWriter. |
| Opération de suppression de table | Pris en charge | Non pris en charge entre l’adaptateur et la base de données Oracle ; toutefois, les données sont diffusées entre BizTalk Server et l’adaptateur. | La diffusion en continu de la valeur de nœud de bout en bout n’est pas prise en charge, car les valeurs des colonnes métier sont mises en mémoire tampon par ODP.NET, puis la suppression est effectuée. Toutefois, la diffusion en continu de valeur de nœud entre BizTalk Server et l’adaptateur est prise en charge pour les types de données métier, car l’adaptateur WCF-Custom crée le message avec un BodyWriter. |
| Opération ReadLOB de table | L’opération ReadLOB n’est pas prise en charge pour BizTalk Server. | L’opération ReadLOB n’est pas prise en charge pour BizTalk Server. | L’opération ReadLOB n’est pas prise en charge pour BizTalk Server. Utilisez plutôt l’opération Select ou une opération SQLEXECUTE. |
| Opération UpdateLOB de table | Prise en charge | Pris en charge | L’adaptateur WCF-Custom utilise un BodyWriter pour créer le message de demande. Ainsi, la diffusion en continu de valeur de nœud de bout en bout pour les types de données métier est prise en charge. |
| Opération SQLEXECUTE | Pris en charge | Prise en charge | L’adaptateur WCF-Custom utilise un XmlDictionaryWriter pour consommer le message de réponse. Ainsi, la diffusion en continu de valeur de nœud de bout en bout pour les types de données métier dans le message de réponse est prise en charge. La diffusion en continu de valeur de nœud de bout en bout n’est pas prise en charge pour le message de demande, car l’adaptateur doit mettre en mémoire tampon tous les opérandes avant de pouvoir appeler l’opération sur la base de données Oracle. |
| Procédure stockée et opération de fonction | Pris en charge | Pris en charge | L’adaptateur WCF-Custom utilise un XmlDictionaryWriter pour consommer le message de réponse. Ainsi, la diffusion en continu de valeur de nœud de bout en bout pour les types de données métier dans le message de réponse est prise en charge. (Cela signifie que la diffusion en continu est prise en charge pour les paramètres de procédure et de fonction OUT et IN OUT dans le message de réponse.) La diffusion en continu de valeur de nœud de bout en bout n’est pas prise en charge pour le message de demande, car l’adaptateur doit mettre en mémoire tampon tous les opérandes avant de pouvoir appeler l’opération sur la base de données Oracle. |
| Opération POLLINGSTMT | Pris en charge | Pris en charge | L’adaptateur WCF-Custom utilise un XmlDictionaryWriter pour consommer le message de requête (entrant), de sorte que la diffusion en continu de valeur de nœud de bout en bout pour les types de données métier est prise en charge. |