Nos modelos de programação de callout do IMS, o IMS atua como um cliente que interage com dados ou lógicas de negócios que residem em um MDB, em um componente EJB ou em um serviço da Web. Os aplicativos IMS chamam aplicativos Java™ externos emitindo pedidos de callout. Da perspectiva do WebSphere Application Server, ao contrário, essas mensagens dos aplicativos IMS são mensagens de entrada.
Dependendo se uma resposta do aplicativo Java externo é esperada e se a resposta é esperada iniciando o aplicativo IMS na mesma transação, diferentes modelos de programação podem ser implementados.
Um pedido de callout síncrono é um pedido que espera uma resposta do aplicativo Java externo ou de serviços da Web para retornar na mesma transação do mesmo aplicativo IMS.
Quando um aplicativo IMS emite um pedido de callout síncrono usando a chamada DL/I ICAL do IMS, um canal de transação (tpipe) do OTMA é usado para manter o pedido. O aplicativo IMS na região dependente permanece planejado e aguarda pela resposta. Depois que o aplicativo externo obtém a mensagem de pedido do tpipe, o tpipe permanece com um status de espera até que uma resposta seja retornada do aplicativo externo.
Para beans acionados por mensagens (MDBs), você pode beneficiar-se da especificação de entrada do J2EE Connector Architecture 1.5 e do suporte ao conjunto de ferramentas de vários ambientes de desenvolvimento integrado (IDE) do Rational ou do WebSphere. O IMS TM Resource Adapter atende a mensagens de callout do IMS Connect e manipula a correlação do pedido e sua resposta.
Para aplicativos não MDB, pesquisar o IMS Connect quanto a pedidos de callout na fila de suspensão é de responsabilidade do aplicativo. O aplicativo também precisa manipular o token correlacionador informado como uma propriedade da classe IMSInteractionSpec.
O principal benefício de se ter o pedido de callout e a resposta na mesma instância de transação é que a lógica de programação para emitir o pedido e para o processamento da resposta pode estar contida no mesmo aplicativo IMS. Essa abordagem, no entanto, não exige que o aplicativo IMS aguarde pela resposta e as regiões dependentes sejam bloqueadas.
Um pedido de callout assíncrono é um pedido que não espera uma resposta ou espera que a resposta retorne em uma transação diferente.
Depois que o aplicativo IMS emite o pedido de callout assíncrono usando a chamada ISRT ALPCB, um canal de transação (tpipe) ou um destino alternativo (como codificado em uma rotina de saída) do OTMA, é usado para manter o pedido. Depois que o aplicativo externo obtém a mensagem de pedido da fila de suspensão, o aplicativo IMS não é mais planejado na região dependente do IMS e a região dependente é liberada.
Se uma resposta for esperada, a mensagem de resposta será retornada como um novo pedido de transação do IMS, para o mesmo aplicativo IMS ou para um aplicativo diferente, com os dados de saída, dependendo do design do aplicativo.
O principal benefício de ter o retorno de resposta de forma assíncrona é evitar o bloqueio de regiões dependentes e, portanto, o bloqueio de recursos do IMS por um período de tempo excessivo. Entretanto, essa abordagem requer que, se uma resposta precisar ser processada, o aplicativo IMS deve ser projetado para ser capaz de manipular a saída em uma instância de transação separada. Também é de responsabilidade do aplicativo correlacionar essa resposta ao pedido.