Chaînes de transport

Les chaînes de transport représentent une pile de protocoles réseau utilisée pour les opérations d'E-S dans un environnement de serveur d'applications.

Elles font partie de la fonction de structure de canal qui fournit un service réseau commun pour tous les composants, y compris le bus d'intégration des services des technologies d'intégration des services IBM®, WebSphere Secure Caching Proxy et le service de passerelle du groupe central du gestionnaire de haute disponibilité.

Une chaîne de transport est constituée d'un ou de plusieurs types de canaux, chacun d'entre eux prenant en charge un type différent de protocole E/S, tel que TCP, DCS ou HTTP. Les ports réseau peuvent être partagés entre tous les canaux d'une chaîne. La fonction de structure de canal distribue automatiquement une requête qui arrive sur ce port au canal de protocole d'E-S approprié pour traitement.

[z/OS]A faire : Si vous disposez d'une routine qui émet un appel pour démarrer les transports lors du démarrage du serveur, vous devez modifier la routine pour qu'elle émette un appel de démarrage de chaînes de transport et non de transports si vous n'avez pas d'environnement mixte et que le serveur s'exécute dans un noeud 6.x. Le produit génère un message d'erreur s'il reçoit un appel pour démarrer les transports pour un serveur qui ne s'exécute pas dans un noeud 6.x.

Les paramètres de configuration de chaîne de transport déterminent les protocoles d'E-S pris en charge pour cette chaîne. Les types de canaux énoncés ci-après figurent parmi les plus courants. Des canaux personnalisés prenant en charge des exigences uniques pour un client ou un environnement particulier peuvent être également ajoutés à une chaîne de transport.

Canal DCS
Utilisé en environnement WebSphere Application Server, Network Deployment par le service de passerelle du groupe central, le service de réplication des données (DRS) et le gestionnaire de haute disponibilité pour transférer des données, des objets ou des événements entre serveurs d'applications.
Canal d'entrée HTTP
Utilisé pour activer des communications avec des serveurs éloignés. Il implémente les normes HTTP 1.0 et 1.1 et il est utilisé par d'autres canaux, tels que le canal du conteneur Web, pour répondre aux demandes HTTP et envoyer des informations spécifiques HTTP aux servlets attendant ce type d'informations.

Les canaux entrants HTTP sont utilisés au lieu des transports HTTP pour établir la file d'attente des demandes acheminées entre un plug-in de serveur Web et un conteneur Web dans lequel sont installés les modules Web d'une application.

Canal d'entrée du proxy HTTP
Utilisé pour gérer les requêtes HTTP entre un serveur proxy et des noeuds de serveurs d'applications.
Canal de tunnel HTTP
Utilisé pour fournir aux applications client des connexions HTTP persistantes aux hôtes éloignés qui sont bloqués par des pare-feux ou qui requièrent un serveur proxy HTTP, authentification comprise, ou les deux. Un canal de tunnel HTTP active l'échange de données d'application dans le corps d'une demande ou d'une réponse HTTP envoyée d'un serveur éloigné ou reçue par ce dernier. Un canal de tunnel HTTP active également des applications côté client pour interroger l'hôte éloigné et utiliser des requêtes HTTP pour envoyer des données du client ou en recevoir d'un serveur d'applications. Dans l'un ou l'autre cas, ni le client, ni le serveur d'applications n'est conscient qu'HTTP est utilisé pour l'échange des données.
Canal JFAP
Utilisé par le serveur JMS (Java™ Message Service) pour créer des connexions aux ressources JMS sur un bus d'intégration de services.
Canal MQ
Utilisé en association avec d'autres canaux, tels qu'un canal TCP, dans les limites de la prise en charge de WebSphere MQ pour faciliter les communications entre un bus d'intégration de services et un client ou un gestionnaire de files d'attente WebSphere MQ.
[z/OS]Canal du service ORB
[z/OS]Utilisé en combinaison avec d'autres canaux, comme le canal TCP, pour gérer les messages CORBA et RMI/IIOP pour le service ORB. Dans un environnement réseau réparti, il permet aux clients d'adresser des demandes aux serveurs et de recevoir des réponses de ces serveurs.
Canal SIP
Utilisé pour créer une passerelle dans la chaîne de transport entre un canal d'entrée SIP (Session Initiation Protocol), et un servlet et un moteur JavaServer Page.
Canal d'entrée du conteneur SIP
Utilisé pour gérer les communications entre le canal d'entrée SIP et le conteneur de servlet SIP.
Canal d'entrée SIP
Utilisé pour gérer les requêtes SIP entrantes depuis un client distant.
canal SSL
Utilisé pour associer un répertoire de configuration SSL (Secure Sockets Layer) avec la chaîne de transport. Ce canal n'est disponible que lorsque la prise en charge de la fonction SSL est activée pour la chaîne de transport. Un répertoire de configuration SSL est défini dans la console d'administration, sous Sécurité dans la page Répertoires de configuration SSL > Répertoires de configuration SSL.
Canal TCP
Utilisé pour fournir des connexions permanentes aux applications client au sein d'un réseau local (LAN) lorsqu'un noeud utilise le protocole Transmission Control Protocol (TCP) pour extraire les informations d'un réseau.
Canal UDP
Utilisé pour fournir des connexions permanentes aux applications client au sein d'un réseau local (LAN) lorsqu'un noeud utilise le protocole de datagramme utilisateur (UDP) pour extraire les informations d'un réseau.
Canal de conteneur Web
Utilisé pour créer une passerelle dans la chaîne de transport entre un canal entrant HTTP et un servlet et un moteur de pages JSP.

Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=crun_chain_transport
Nom du fichier : crun_chain_transport.html