O WebSphere Message Broker implementa o acesso aos fluxos de saída e entrada TCP/IP através de uma série de nós.
Existem dois conjuntos de nós TCP/IP: TCPIPServer e TCPIPClient. Os dois conjuntos têm uma função idêntica em termos de acesso aos fluxos de dados; no entanto, um conjunto utiliza conexões do cliente e o outro conjunto utiliza conexões do servidor. Como resultado, os nós estabelecem as conexões de diferentes maneiras mas usam os fluxos da mesma maneira quando as conexões foram estabelecidas.
A diferença principal entre as propriedades dos nós é que os nós TCPIPServer não permitem que o nome do host seja alterado (porque ele sempre deve ser host local). Todos os nós TCPIPServer que usam a mesma porta devem estar no mesmo grupo de execução porque a porta está conectada ao processo em execução. Os nós TCPIPClient na mesma porta podem ser usados em grupos de execução diferentes, mas conexões de clientes não podem ser compartilhadas porque estão ligadas a um grupo de execução específico, que é mapeado para um processo. Nos dois conjuntos de nós (TCPIPClient e TCPIPServer), há três tipos de nó:
Os nós de entrada e de recebimento acessam o fluxo de entrada para recuperar dados e os nós de saída acessam o fluxo de saída para enviar dados. Nenhum nó único pode acessar ambos os fluxos ao mesmo tempo. Para acessar ambos os fluxos simultaneamente, é necessário conectar vários nós em um fluxo de mensagens.
Os serviços configuráveis para nós TCPIPServer e TCPIPClient devem ser predefinidos por um administrador. Os detalhes de conexão para serviços configuráveis TCP/IP são definidos pelo administrador ao configurar o broker para teste ou produção. Os serviços configuráveis TCP/IP devem ser definidos antes de um fluxo de mensagens que os usa ser implementado, mesmo em um ambiente de teste. Para obter mais informações, consulte Configurando Propriedades para TCP/IP.
O nó de entrada permite o acesso a um fluxo de entrada da conexão. O nó é acionado pela chegada de dados no fluxo e inicia o processamento do fluxo de mensagens. O nó de entrada controla o gerenciamento de encadeamentos e de transações. Os nós TCP/IP não são transacionais na maneira com que interagem com TCP/IP, mas outros nós no mesmo fluxo podem ser transacionais (por exemplo, nós do WebSphere MQ). O nó de entrada não cria um encadeamento para cada conexão que está sendo utilizada, mas aguarda que dois requisitos sejam atendidos:
Por exemplo, 1.000 conexões TCP/IP podem ser manipuladas por um nó de entrada que possui apenas uma instância adicional. Essa situação é possível porque o nó não sonda as conexões, mas é acionado quando as condições especificadas são atendidas.
O nó de recebimento é acionado para ler dados de uma conexão quando chega uma mensagem em seu terminal In. Ele aguarda a chegada de dados, então os envia para o terminal de Saída. É possível configurar o nó de recebimento para usar uma conexão específica (especificando um ID de conexão) ou para usar qualquer conexão disponível. Se o nó estiver configurado para usar qualquer conexão disponível, ele recebe dados da primeira conexão que possui dados disponíveis.
O nó de saída envia dados para uma conexão. Ele é acionado por uma mensagem chegando em seu terminal de Entrada, então ele envia os dados contidos na mensagem para o fluxo. A mesma mensagem recebida no nó é enviada para o terminal Out.
Os seis nós cliente e servidor podem ser combinados para fornecer operações mais complexas. Por exemplo, um nó de saída seguido por um nó de recebimento permite um pedido síncrono de dados:
Cada conexão possui um identificador exclusivo designado a ela quando é criada. Sempre que um nó utilizar uma conexão, o ID que é utilizado é gravado no ambiente local. Os nós que a utilizarem posteriormente no fluxo poderão acessar a mesma conexão, especificando o ID; os nós de recebimento e de saída localizam o ID, procurando em um local especificado no ambiente local. Por padrão, o local no qual um nó grava seus detalhes de conexão é diferente do local no qual o próximo nó procura para ver se há um ID para utilização. Os nós podem ser configurados para utilizar o ID que foi enviado por um nó anterior. Por exemplo, a combinação dos nós de saída e de recebimento mostrada em Combinando Nós pode ser configurada para que o nó de recebimento utilize os dados WrittenDestination do nó de saída precedente.
A utilização do ID permite que uma série de nós acessem a mesma conexão, mas não impede que dois encadeamentos do fluxo de mensagens acessem a mesma conexão. Quando uma conexão é usada pela primeira vez, ela pode ser reservada de maneira que nenhum outro nó possa acessá-la a menos que conheçam o ID. Por exemplo, a combinação dos nós de saída e de recebimento mostrada em Combinando Nós reserva a conexão para que nenhum outro encadeamento possa acessá-la antes de ser utilizada pelo nó de recebimento. Por padrão, o nó de recebimento libera a conexão quando ela estiver concluída.
A capacidade de reservar conexões (e acessá-las especificando o ID correto) permite construir interações complexas com conexões TCP/IP que estendem fluxos inteiros e até mesmo vários fluxos de mensagens. Como resultado, interações TCP/IP podem ser utilizadas com outros mecanismos de transporte assíncronos como WebSphere MQ.
As conexões reservadas devem ser liberadas em algum ponto, caso contrário, permanecerão indisponíveis indefinidamente. Para obter informações adicionais sobre conexões reservadas e disponíveis, consulte Gerenciamento de Conexões.
Os nós TCP/IP podem ser utilizados em padrões assíncronos, nos quais os dados são enviados através de um nó de saída TCP/IP e recebidos de volta através de um nó de entrada TCP/IP. A amplitude de dois fluxos de mensagens faz com que qualquer estado no primeiro fluxo seja perdido e, portanto, fique inacessível no segundo fluxo. Os nós TCP/IP permitem armazenar alguns detalhes da resposta em uma conexão, e esses detalhes são disponibilizados para o nó de entrada utilizar quando um novo evento chegar à mesma conexão. Por padrão, estes dados são obtidos do ambiente local, mas é possível configurar os nós para obter os dados de qualquer local, incluindo o campo Correlid e IDs de mensagem em cabeçalhos do WebSphere MQ.