Ciclo de vida del nodo de entrada definido por el usuario en C

En este tema se describen las diferentes fases del ciclo de vida de un nodo de entrada definido por el usuario escrito con el lenguaje de programación C. Se describen las siguientes fases de ciclo de vida de un nodo de entrada:

Registro

Durante la fase de registro, el intermediario detecta qué recursos están disponibles y los LIL que pueden proporcionarlos. En esta instancia, los recursos disponibles son nodos. La fase se inicia cuando se inicia un grupo de ejecución. Los LIL se cargan durante el arranque de un grupo de ejecución y el intermediario los consulta para saber qué recursos puede proporcionar.

Se crea una estructura CciFactory durante la fase de registro, cuando el nodo definido por el usuario llama a cniCreateNodeFactory.

Durante esta fase el intermediario llama a las API siguientes:
  • biGetMessageflowNodeFactory
  • bipGetParserFactory
Durante esta fase el nodo definido por el usuario llama a la siguiente API:
  • cniCreateNodeFactory

Creación de una instancia

Se crea una instancia de un nodo de entrada definido por el usuario cuando el mandato mqsistart inicia o reinicia el proceso del grupo de ejecución, o cuando se despliega un flujo de mensajes asociado al nodo.

Durante esta fase se llama a las API siguientes:
  • cniCreateNodeContext. Esta API asigna memoria para crear instancias de un nodo definido por el usuario que contenga los valores para los atributos configurados. Se llama una vez a esta API para cada flujo de mensajes que está utilizando el nodo de entrada definido por el usuario.
  • cniCreateInputTerminal. Esta API se invoca desde la API cniCreateNodeContext y se utiliza para indicar al intermediario qué terminales de entrada, si las hay, tiene el nodo de entrada definido por el usuario.
    Nota: El nodo de entrada definido por el usuario sólo tendrá terminales de entrada si también está actuando como un nodo de proceso de mensajes. Si este es el caso, generalmente lo mejor es separar el nodo de proceso de mensajes definido por el usuario de modo que procese el mensaje, en lugar de combinar ambas operaciones en un nodo más complejo.
  • cniCreateOutputTerminal. Esta API se invoca desde la API cniCreateNodeContext y se utiliza para indicar al intermediario qué terminales de salida tiene el nodo de entrada definido por el usuario.
  • cniSetAttribute. El intermediario llama a esta API para establecer los valores de los atributos configurados del nodo definido por el usuario.

Durante esta fase, se crea una estructura CciTerminal. Esta estructura se crea cuando se llama a cniCreateTerminal.

Proceso

La fase de proceso comienza cuando el intermediario llama a la función cniRun. El intermediario utiliza la funcióncniRun para determinar cómo procesar un mensaje, incluido determinar el dominio en el que se define un mensaje, y cómo invocar el analizador correspondiente para dicho dominio.

Se solicita una hebra de la agrupación del flujo de mensajes y se inicia en el método de ejecución del nodo de entrada. La hebra conecta con el gestor de colas del intermediario y retiene esta conexión durante su ciclo de vida. Cuando se asigna una hebra, el nodo entra en un bucle de proceso de mensajes mientras espera a recibir un mensaje. Permanecerá en el bucle hasta que se reciba un mensaje. Si se configura el flujo de mensajes para que utilice varias hebras, se activa el despacho de hebras.

Ahora los datos de mensajes se pueden propagar en sentido descendente.

Durante esta fase el intermediario llama a las API siguientes:
  • cniRun. El intermediario llama a esta función para determinar cómo procesar el mensaje de entrada.
  • cniSetInputBuffer. Esta función proporciona un almacenamiento intermedio de entrada o indica al intermediario dónde está el almacenamiento intermedio de entrada y lo asocia con un objeto de mensaje.

Destrucción

Un nodo de entrada definido por el usuario se destruye cuando se vuelve a desplegar el flujo de mensajes o cuando se utiliza mqsistop para detener el proceso del grupo de ejecución. Puede destruir el nodo implementando la función cniDeleteNodeContext.

Cuando se destruye un nodo de entrada definido por el usuario de uno de estos modos, debe liberar la memoria que utilice el nodo y liberar también los recursos que estén retenidos, por ejemplo, los sockets.

Durante esta fase el intermediario llama a las API siguientes:
  • cniDeleteNodeContext. El intermediario llama a esta función para destruir la instancia del nodo de entrada.
Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Su opinión
Copyright IBM Corporation 1999, 2006 Última actualización: 22/08/2006
as01391_