Manejo de Servidores TCPIP

confidencialidad
Aviso: este documento es material confidencial y propiedad de everis.
Se prohbe el uso, reproduccin o la divulgacin del contenido de este
material sin permiso previo y por escrito de la empresa propietaria.
Derechos de Autor
2015, everis. All rights reserved.

1. Transferencia de datos TCP/IP

2. Nodos TCP/IP
3. Gestin de conexiones
4. Escenarios para WebSphere Message Broker y TCP/IP
5. Cmo trabajar con TCP/IP
6. Flujo de ejemplo

1. Transferencia de datos TCP/IP

Puede utilizar IBM Integration Bus para conectarse con aplicaciones que utilizan sockets TCP/IP en
bruto para la transferencia de datos.
TCP/IP proporciona un mecanismo para transferir datos entre dos aplicaciones que pueden estar
ejecutndose en sistemas distintos. La transferencia de los datos es bidireccional; siempre y cuando
se mantenga la conexin TCP/IP y no se pierde ningn dato, se conserva la secuencia de los datos.
Una ventaja considerable de utilizar directamente TCP/IP es que es rpido y sencillo de configurar, lo
que lo convierte en un mecanismo til para procesos que no requieran la persistencia de mensajes
(por ejemplo, la supervisin).

1. Transferencia de datos TCP/IP

La utilizacin de sockets de TCP/IP para transferir informacin entre programas tiene algunas
limitaciones:
No es transaccional
No es persistente (los datos se graban en un almacenamiento intermedio de memoria interna entre
el remitente y el receptor)
No tiene seguridad incorporada
No proporciona ninguna forma estndar de indicar el inicio y el final de un mensaje
Por estos motivos, puede ser preferible utilizar un mecanismo de transporte como WebSphere MQ,
que no tenga ninguna de estas limitaciones.

1. Transferencia de datos TCP/IP

1.La aplicacin de servidor est a la escucha en un puerto local de peticiones.
2.La aplicacin cliente solicita una conexin desde el puerto del servidor.
3.Cuando el servidor acepta la peticin, se crea un puerto en el sistema cliente y se conecta al puerto
del servidor.
4.Se crea un socket en ambos extremos de la conexin y el socket encapsula los detalles de la
conexin.
5.El puerto del servidor sigue estando disponible para escuchar ms solicitudes de conexin:

1. Transferencia de datos TCP/IP

El servidor puede aceptar ms conexiones de otras
aplicaciones de cliente. Estas conexiones pueden
estar en el mismo proceso, en proceso distintos del
mismo sistema o en un sistema diferente

1. Transferencia de datos TCP/IP

Solamente puede haber una aplicacin de servidor pero se puede conectar cualquier cantidad de
procesos de cliente distintos a la aplicacin de servidor. Cualquiera de estas aplicaciones (de cliente
o servidor) puede tener mltiples hebras, lo que les permite utilizar mltiples conexiones.
Cuando se haya establecido la conexin, existirn dos secuencias de datos: una para los datos
entrantes y la otra para los datos salientes.

2. Nodos TCP/IP
Nodos TCPIPServer
Todos los nodos TCPIPServer que utilicen el mismo puerto han de estar en el mismo grupo de
ejecucin debido a que el puerto est ligado al proceso de ejecucin.
Dentro de los dos conjuntos de nodos TCPIPServer, hay tres tipos de nodo:
TCPIPServerInput
TCPIPServerReceive
TCPIPServerOutput
Los nodos TCP/IP no son transaccionales en el sentido que interaccionan con TCP/IP, pero otros
nodos del mismo flujo pueden seguir siendo transaccionales (por ejemplo, los nodos de WebSphere
MQ).

2. Nodos TCP/IP
Nodo TCPIPServerInput
El nodo TCPIPServerInput escucha en un puerto y,
cuando un socket de cliente se conecta al puerto, el
socket de servidor crea una conexin para el cliente.
El nodo TCPIPServerInput acepta conexiones hasta un
valor mximo que se especifica en la propiedad
MaximumConnections
del
servicio
configurable
TCPIPServer.
Un nodo de entrada que tenga nicamente una entrada
adicional puede gestionar 1.000 conexiones TCP/IP.
Esta situacin es posible debido a que el nodo no
sondea las conexiones sino que se desencadena
cuando se cumplen las condiciones especificadas.

2. Nodos TCP/IP
Nodo TCPIPServerInput
El nodo TCPIPServerInput maneja mensajes en los siguientes dominios de mensajes:
DFDL
XMLNSC
DataObject
JSON
BLOB
MIME
MRM
JMSMap
JMSStream
XMLNS

2. Nodos TCP/IP
Nodos de recepcin
El nodo de recepcin se desencadena para leer
datos de una conexin cuando llega un mensaje a
su terminal de entrada (In). Espera a que lleguen
datos y, a continuacin, los enva al terminal de
salida (Out). Si el nodo se ha configurado para que
utilice cualquier conexin disponible, recibe datos
de la primera conexin que tenga datos disponibles.

2. Nodos TCP/IP
Nodo TCPIPServerOutput
El nodo TCPIPServerOutput escucha en un puerto
TCP/IP y espera a que un nodo de cliente establezca
una conexin con el puerto. Cuando el cliente se
conecta al puerto, el nodo de servidor crea una
conexin para el cliente. El nodo no realiza
directamente las conexiones sino que stas se
obtienen de una agrupacin de conexiones gestionada
por el servidor de integracin de IBM Integration Bus.

3. Gestin de conexiones
Conexiones de servidor
El gestor de conexiones del servidor empieza a escuchar conexiones de servidor cuando se inicia y
sigue aceptando conexiones hasta que se alcanza el nmero mximo de. Al llegar a este punto, se
rechazan todos los intentos de realizar conexiones. Los servidores TCP/IP no crean conexiones;
nicamente aceptan solicitudes de conexin de otras aplicaciones. Por tanto, no puede forzar la
creacin de conexiones dentro de un flujo de mensajes.

3. Gestin de conexiones
Conexiones de cliente
El gestor de conexiones del cliente se inicia y sigue haciendo conexiones de cliente hasta que se
alcanza el nmero mnimo de conexiones. De forma predeterminada, el nmero mnimo es cero, lo
que indica que no se han realizado conexiones. Siempre que el nmero de conexiones queda por
debajo del valor mnimo, el gestor de conexiones empieza a crear ms conexiones de cliente. Los
nodos de cliente de salida y de recepcin inician la creacin de nuevas conexiones de cliente siempre
que no queda ninguna disponible para que ser utilizada, a menos que se haya alcanzado el nmero
mximo.

3. Gestin de conexiones
Reserva y liberacin de conexiones
Cada conexin tiene una entrada y una salida y ambas tienen dos estados principales dentro del
gestor de conexiones: disponible y reservada.
Si no hay ninguna conexin disponible y el nodo es un nodo de cliente, nicamente se crea una
nueva conexin. Cuando una conexin est en estado reservado ningn otro nodo podr acceder a la
corriente sin especificar el ID de la conexin.
El mecanismo de reserva proporciona las siguientes opciones:
Dejar sin cambios
Reservar
Liberar
Reservar y liberar al final del flujo

4. Escenarios para WebSphere Message Broker y TCP/IP

WebSphere Message Broker se puede aadir a sistemas que utilizan TCP/IP para el transporte a fin
de generar una arquitectura ms flexible para la comunicacin entre componentes.

5. Cmo trabajar con TCP/IP

Transferencia de datos XML desde un socket de servidor TCP/IP a una cola WebSphere MQ
Transferencia de datos binarios (CWF) desde un socket de servidor TCP/IP a un archivo plano
Recepcin de datos en un socket de servidor TCP/IP y devolucin de datos a la misma conexin
Envo de datos XML desde una cola WebSphere MQ a un socket de cliente TCP/IP
Envo de datos CWF desde un archivo plano a un socket de cliente TCP/IP
Envo de datos a una conexin de cliente TCP/IP y recepcin de los datos en la misma conexin
(sncrona)
Establecimiento de una sesin de cliente a travs de una conexin TCP/IP
Difusin de datos a todas las conexiones disponibles actualmente
Configuracin de propiedades para TCP/IP
Configuracin de un socket de servidor para recibir datos XML que finalizan con un carcter nulo

6. Flujo de ejemplo
El apretn de manos
Los pasos siguientes muestran:
Solicitud: El cliente enva el mensaje de peticin al servidor.
Solicitud-Reconocimiento. El servidor enva un mensaje al cliente a reconocer que ha recibido la
solicitud y est listo para dar servicio a la misma.
Solicitud-Confirmacin. El cliente enva un mensaje al servidor para confirmar que la solicitud
debe ser atendida.
Responder: El servidor enva el resultado del servicio al cliente.
Responder-Reconocimiento. El cliente enva un acuse de recibo al servidor.
Responder-Confirmacin. El servidor enva una confirmacin al cliente de que el acuse de recibo
ha sido recibido

6. Flujo de ejemplo
El apretn de manos

Los retrasos pueden ocurrir durante el proceso:

Un tiempo de retardo puede ocurrir entre Solicitud y Solicitud-Reconocimiento, ya que el servidor
podra ser solicitudes de servicio ocupados de otros clientes.
El lapso de tiempo entre la tpica Request-Reconocimiento y Solicitud-Confirmacin es corto.
Un lapso de tiempo significativo podra ocurrir entre Request-Confirmacin y respuesta,
dependiendo de los recursos que se requieren para atender la solicitud, y la disponibilidad de
esos recursos. Por ejemplo, (, IO, por ejemplo CPU tablas de BD, etc.) podran existir otras
peticiones que utilizan los mismos recursos.
El lapso de tiempo entre la tpica respuesta-Reconocimiento y Reply-Confirmacin es corto.

6. Flujo de ejemplo
Flujo de mensajes TCPIPMQVeneer
El flujo de mensajes es un barniz que hace el nuevo aspecto del servicio de WebSphere MQ como el
servicio TCP / IP original, en cuanto a la secuencia y el formato fsico de los datos intercambiados.

El flujo de mensajes TCPIPMQVeneer consta de tres subflujo.

6. Flujo de ejemplo
receiveRequest
Esta subflujo implementa el acuerdo de tres vas para recibir la solicitud del cliente TCP / IP

6. Flujo de ejemplo
recieveRequest subflujo
La solicitud se utiliza para rellenar el rbol mensaje en el nodo TCPIPServerInput. El reconocimiento y la
confirmacin tanto se construyen en el rbol de medio ambiente local. El mensaje de solicitud es sin
cambios por el subflujo.
Mira las clases MakeRequestAck y CheckRequestConf, que son utilizados por los nodos
MakeAcknowledgement y CheckConfirmation, para averiguar cmo se utiliza el entorno local para
construir el reconocimiento y utilizar la confirmacin. Estas clases no crean nuevos MbMessages. Todas
las modificaciones se realizan para el entorno local de entrada, que se propaga entonces en adelante.
El mensaje de entrada no se cambia, lo cual es importante porque:
El informe de informacin de TCP / IP que se escribe en el medio ambiente local por el nodo
TCPIPServerInput se encuentra todava en el medio ambiente local para los nodos
TCPIPServerOutput y TCPIPServerReceive.
El mensaje construido por el nodo TCPIPServerInput no se modifica por la presente subflujo.

6. Flujo de ejemplo
recieveRequest subflujo
El nodo TCPIPServerReceive tiene el tiempo de espera de espera de registro de datos (segundo)
propiedad establecida en 60 segundos, y la terminal de tiempo de espera del nodo no est cableada.
Por lo tanto, si el cliente enva una solicitud, pero luego no enva una confirmacin dentro de los 60
segundos de la acuse de ser enviado, una excepcin se produce por el nodo TCPIPServerReceive.
En la clase CheckRequestConf Java en el nodo CheckConfirmation, si el mensaje de confirmacin no
contiene el valor esperado, se asume una confirmacin negativa, y la solicitud se propaga al terminal
alternativo que est conectado a un nodo Throw. Por lo tanto, el cliente que enva una confirmacin
negativa tiene el mismo resultado que cuando el cliente no enva una confirmacin dentro de los 60
segundos. Es decir, una excepcin que se produce cancela la solicitud.

6. Flujo de ejemplo
invokeMQService
Este subflujo implementa el apretn de manos con WebSphere MQ, incluyendo la conversin de los
datos a formato XML.

6. Flujo de ejemplo
invokeMQService subflujo
Este subflujo implementa el apretn de manos con WebSphere MQ, incluyendo la conversin de los
datos a formato XML.
Esta subflujo:
Convierte la solicitud a XML
Enva la solicitud XML a WebSphere MQ.
Toma el ID de mensaje del mensaje de solicitud de WebSphere MQ y utilizarlo como el ID de
correlacin para obtener la correspondiente respuesta de WebSphere MQ.
Convierte la respuesta de XML a formato CWF.
Es esencial que el medio ambiente local es conservada o copiado, para asegurar que los nodos
TCPIP en el subflujo SendReply son capaces de utilizar la misma conexin como el subflujo
receiveRequest.

6. Flujo de ejemplo
SendReply
Esta subflujo implementa el acuerdo de tres vas para enviar la respuesta al cliente TCP / IP.

Este subflujo es similar a la subflujo receiveRequest de las siguientes maneras:

Utiliza el entorno local para construir el reconocimiento y confirmacin.
Se establece la propiedad ID de ubicacin a $LocalEnvironment / TCPIP / Entrada /
ConnectionDetails / ID para garantizar que la misma conexin se utiliza como aquello sobre lo
cual el nodo TCPIPServerInput recibi la solicitud.
Dispone de un nodo TCPIPServerReceive que tiene un tiempo de espera de 60 segundos.

Argentina
Blgica
Brasil
Chile
Colombia
Espaa
Francia
Italia
Mxico
Per
Portugal
Reino Unido
USA

Lima
Calle Dean Valdivia 148, Piso 8, Edificio Platinum
San Isidro, Lima, 15046 - Per
Tel.: +511 203 82 00
Fax: +511 203 82 00
www.everis.com
Lima
Calle Miro Quesada 139
Lima, Per
Tel.: +511 203 82 00
Fax: +511 203 82 00
www.everis.com