Introdução

A Parte 1 desta série de três partes descreveu os diferentes ambientes Java™ fornecidos pelo IBM® CICS® :

• O ambiente de JVM compartilhado tradicional, onde somente uma transação de Java baseada em CICS é executada por vez em uma JVM.
• O ambiente do servidor CICS JVM, onde várias solicitações de programa Java podem ser despachadas à mesma JVM e ao mesmo tempo. Estes são os ambientes Java fornecidos por CICS que usam o servidor JVM (mas não podem ser combinados em um único servidor JVM):
  • O ambiente baseado em OSGi, que fornece o sistema de módulo dinâmico OSGi com funcionalidades como a adição e remoção dinâmica de classes Java à JVM, fornecimento do registro OSGi, exposição apenas das interfaces para seu módulo Java em vez de todas as classes no módulo e especificação de dependências de módulo para praticamente eliminar problemas ClassNotFound comuns.
  • O mecanismo de serviço da web de software livre Axis2, que permite expor um POJO de forma rápida e fácil usando anotações JAX-WS e escrever manipuladores no estilo Axis2.
  • CICS Dynamic Scripting, que fornece uma maneira rápida de desenvolver aplicativos da web usando as linguagens de script PHP e Groovy. Os intérpretes de PHP e Groovy são implementados em Java e, portanto, há uma ponte Java para permitir que você instancie objetos Java e invoque programas CICS
• O CICS Transaction Gateway (CICS TG), que facilita as comunicações de um programa Java que executa em um ambiente não CICS com um programa de CICS Transaction Server (CICS TS).

Conforme o esperado, se você estiver trabalhando com classes Java em um único programa Java baseado em CICS, trabalhe com elas normalmente: instancie o objeto e invoque os métodos do objeto. No entanto, quando seu aplicativo é codificado em Java, mas você deseja aproveitar os pontos fortes dos diferentes ambientes Java fornecidos por CICS, ou deseja distribuir as partes de seu aplicativo baseado em Java em diversas regiões do CICS, o uso de uma abordagem parecida com Java para transportar os objetos de dados Java é preferível sobre a abordagem tradicional de série de bytes orientada ao campo para o transporte de dados. Essa abordagem tradicional de passagem de dados é necessária e funciona bem se você estiver usando diversas linguagens de programação, o que é um dos pontos fortes do CICS.

A Parte 1 descreveu a versão do CICS de uma chamada, o comando EXEC CICS LINK, que o permite chamar outro programa escrito com a mesma linguagem de programação, ou com outra diferente, em um ambiente CICS. As instalações arquitetadas por CICS para a passagem de dados entre programas CICS são a área de comunicação e os canais e contêineres. A área de comunicação é um bloco de armazenamento de até 32 KB, enquanto um contêiner é um bloco nomeado de armazenamento sem limite de tamanho. Os contêineres são agrupados em um canal, que pode ser passado de um programa CICS para outro. A área de comunicação e os canais e contêineres são mutuamente exclusivos, um programa pode receber dados usando somente uma das duas técnicas por vez. Quando você realiza um LINK do programa A para o programa B, o programa A pode passar uma área de comunicação ou um canal, mas não ambos.

Ao passar dados entre programas de CICS, você geralmente coloca os dados em uma estrutura de série de bytes orientada por campo. Os programas escritos em Java podem participar desse ambiente, mas, quando o seu aplicativo baseado em CICS só está usando Java, o programador de aplicativos Java achará mais conveniente permanecer na área de Java orientada a objetos e passar os objetos de dados entre os seus programas Java baseados em CICS. Assim sendo, a Parte 1 concluiu que, se um aplicativo baseado em CICS foi escrito só em Java e é necessário mover de um ambiente CICS Java para outro, é mais simples permanecer no paradigma Java e passar objetos de dados Java entre ambientes Java baseados em CICS. É possível fazer isso serializando um objeto de dados Java em um contêiner CICS, passando o contêiner para outro programa Java em execução em um ambiente CICS Java diferente e desserializando o objeto no programa Java de destino.

As partes 1 e 2 explicaram por que um programador Java teria mais facilidade de passar objetos de dados Java entre programas Java baseados em CICS em vez de usar a tradicional série de bytes orientada por campo do CICS que você usaria para passar dados entre programas implementados em linguagens de programação diferentes. A parte 2 descreveu uma técnica para passar objetos de dados Java que usa a serialização de objetos, a API de Java fornecida pelo CICS para colocar dados nos contêineres do CICS e pegar dados deles e a API de Java fornecida pelo CICS API para fazer o LINK de um programa de CICS para outro. A parte 2 também forneceu classes Java de amostra que mostraram como escrever um objeto Java generalizado que pode transportar objetos de dados Java entre ambientes CICS Java diferentes. A técnica descrita na parte 2 permite que os objetos de dados Java sejam passados entre os ambientes Java fornecidos pelo CICS usando a seguinte abordagem de codificação:

     String abc = "Some information to Pass";
Employee emp = new Employee("John Doe");
DDW_CicsObjectTransporter transporter =
    new DDW_CicsObjectTransporter();
transporter.addObject("abc",abc).
addObject("emp",emp).
          execute("TARGET");
     
     // and after the program return
     
     String errorString = (String)transporter.getObject("error");
     If (errorString != null) {
          processError();
     } else {
          Manager newManager = (Manager)transporter.getObject("mgr");
          // process/display Manager object that was returned
     }

Este é um código de amostra para que o programa Java que responde retorne dados:

DDW_CicsObjectTransporter transporter = new 
     DDW_CicsObjectTransporter();
Employee emp = (Employee)transporter.getObject("emp");
// work with employee object
transporter.removeObject("abc");    // can remove objects
Manger mgr = new Manger("Joe Bloggs");
transporter.addObject("mgr",mgr);  // add new or changed objects
return;

Um programa cliente Java de CICS TG pode se comunicar com um ambiente de CICS TS usando canais e contêineres. Portanto, é possível usar a mesma técnica descrita na parte 2 para passar objetos de dados Java entre os ambientes Java fornecidos pelo CICS TS para passar objetos de dados Java entre um programa Java CICS TG e um programa Java que executa no CICS TS. É possível até usar a mesma classe de transportador de objetos no lado do CICS TS, mas é necessária uma implementação diferente dele no lado do cliente de CICS TG Java para acomodar as diferenças na API de programação do CICS TG.

Este artigo (parte 3) descreve a API que permite que os programas cliente Java de CICS TG interajam com um programa de CICS TS. Também fornece uma implementação de um transportador de objetos que pode ser usado em um cliente Java de CICS TG Java juntamente com os assistentes do Rational Application Developer e do Rational Developer para System z para gerar código para se comunicar de um cliente Java CICS TG para um programa CICS TS.

Os assistentes fornecidos com o Rational Application Developer normalmente tomam um copybook COBOL como entrada e geram código para serializar os dados a serem passados em uma série de bytes orientada a campos semelhante ao COBOL. As duas principais vantagens dessa abordagem são que o programa cliente Java CICS TG pode passar dados para um programa em COBOL, PL/I, C, C++, Java ou Assembler que executa no CICS TS e a velocidade. Entretanto, se os programas no lado do cliente e do servidor estão em Java, será mais fácil para o programador de aplicativos Java usar um paradigma semelhante ao Java e passar objetos de dados Java entre o cliente Java e os programas do servidor Java. Este artigo mostra como usar o transportador de objetos fornecido com os assistentes do Rational Application Developer, oferecendo a você os benefícios da geração de códigos a partir dos assistentes e a conveniência, para o programador de aplicativos Java, de passar objetos de dados Java.

Conforme o descrito anteriormente, o objetivo dessa série de artigos é tornar conveniente, para o programador de aplicativos Java, a passagem de objetos de dados entre os diversos ambientes Java fornecidos pelo CICS. Já que a serialização e desserialização de objetos Java geram uma sobrecarga, será necessário tomar a referência do seu aplicativo para se certificar de que essa abordagem à passagem de objetos de dados Java tenha um desempenho aceitável para o seu aplicativo. Para obter mais informações sobre problemas associados à serialização de objetos Java, consulte a parte 2.

CICS Transaction Gateway

O CICS TG fornece uma comunicação transacional segura para o CICS a partir de uma variedade de linguagens de programação de cliente, como C#, Java, Microsoft® .NET, Microsoft Visual Basic, PowerBuilder e COBOL baseado em estação de trabalho para um programa executando no CICS TS.

Para um cliente Java que executa em um ambiente não CICS, o CICS TG implementa a Java Connector Architecture (JCA), que define uma forma padrão de se comunicar de programas Java para Enterprise Information Systems (EISs) como CICS, IMS, JDEdwards, PeopleSoft e SAP. A JCA define uma forma de implementar conexões gerenciadas ou não gerenciadas usando uma API padrão chamada Common Client Interface (CCI). Com uma conexão gerenciada, um servidor de aplicativos Java Enterprise Edition (JEE) pode fornecer o gerenciamento de conexão, transacionalidade de controle e propagação de um contexto de segurança. Essa API padrão de CCI permite que um programador Java use uma API comum para acessar EISs diferentes.

O CICS TG pode ser configurado de diversas maneiras. Para obter mais informações, consulte Centro de informações do CICS TG .

Para um cenário em que você tem um programa cliente de CICS TG escrito em Java e sua lógica de negócios do lado do servidor CICS implementada em Java, é possível usar as técnicas contidas neste artigo para passar objetos de dados Java de seu programa cliente CICS TG para o programa Java baseado em CICS que implementa sua lógica de negócios.

Passando objetos Java de um cliente Java CICS TG para um programa Java baseado em CICS

Há duas APIs disponíveis para trabalhar com o CICS TG e os canais e contêineres: a API original fornecida quando o CICS TG começou a suportar Java, por volta de 1996, e a API de JCA (também conhecida como Common Client Interface ou CCI) que foi incluída mais tarde. Embora as duas APIs suportem canais e contêineres, este artigo foca a CCI porque é a API estratégica para o CICS TG. Para ver mais detalhes sobre o uso da CCI com o CICS TG, consulte o IBM Redbook Developing connector applications for CICS, e os dois artigos do developerWorks de autoria de Phil Wakelin: Exploiting the J2EE Connector Architecture e Exploiting CICS channels and containers from Java clients.

Ao escrever um cliente Java de CICS TG usando a CCI, você trabalha com um ECIChannelRecord, que representa um canal e contém métodos para trabalhar com contêineres em um canal. O ECIChannelRecord é usado nos programas cliente Java de CICS TG em vez das classes Channel e Container que foram discutidas em relação aos programas de CICS TS na parte 2.

O ECIChannelRecord contém métodos para os contêineres put(), List e delete() , ao passo que, no caso do CICS TS, os métodos put() e List são usados com um objeto Container , e você exclui os contêineres com um método deleteContainer() . Além disso, a verificação de erros é diferente entre os métodos de CICS TG e os de CICS TS. Há dois tipos de contêineres: BIT e CHAR (descritos na parte 1). O modo de criar e acessar um contêiner BIT (em oposição ao contêiner CHAR) usando o ECIChannelRecord fornecido pelo CICS TG é diferente de usar o objeto Channel fornecido pelo CICS TS. Além disso, com um programa Java de CICS TS, você usa um objeto Program e um método link() para chamar um programa; entretanto, a partir de um programa CICS TG, você usa o método execute() em um Interaction obtido de um Connection (esse assunto será retomado alguns parágrafos adiante).

A serialização e desserialização de objetos é igual em qualquer implementação de Java. Portanto, é possível usar o mesmo código de serialização e desserialização nos transportadores de objetos do CICS TG e CICS TS. Os métodos para obter, incluir e excluir objetos Java são semelhantes nos dois transportadores de objetos, fornecendo-lhes uma interface consistente. No entanto, as interações subjacentes com os objetos Channel / Container em comparação com o objeto ECIChannelRecord são muito diferentes.

O DDW_CicsObjectTransporter (fornecido com a parte 2) oferece uma fachada thin sobre o canal e a infraestrutura de contêineres já existentes do CICS TS. No caso do transportador de objetos do CICS TG, o ECIChannelRecord foi ampliado em um DDW_CicsTg_ObjectTransporter, que permite que o DDW_CicsTg_ObjectTransporter seja usado em qualquer lugar em que um ECIChannelRecord pode ser usado, inclusive a CCI e os assistentes do Rational Application Developer. Abaixo, são apresentados exemplos dos dois casos.

Usando o CCI em um programa cliente Java de CICS TG

Se você, como programador de cliente Java CICS TG, tivesse que codificar a CCI por conta própria — em vez de gerar código usando os assistentes do Rational Application Developer, o código ficaria parecido com o fragmento abaixo. A CCI é objetiva: você cria um objeto de conexão ou obtém um a partir de um conjunto de conexões. A partir da conexão, você cria uma interação e usa o método execute() da mesma para chamar o programa backend. Essas partes da CCI são iguais, independentemente do sistema backend: CICS, IMS, JDEdwards, etc.

A parte da CCI que varia de acordo com o sistema backend é a especificação de interação (a parte específica da interação) e o formato dos dados que estão sendo passados. Para chamar um programa baseado em CICS, a especificação de interação é um ECIInteractionSpec, que contém o nome do programa de CICS a ser chamado, o ID do usuário e a senha e outros aspectos específicos da interação com o programa baseado em CICS. Na amostra de código abaixo, você passa um ECIChannelRecord que contém os contêineres a serem passados ou recuperados a partir do programa de CICS TS. O mecanismo de canal e contêiner é específico para o CICS TS e não é usado com outros EISs:

ConnectionFactory cf = createAConnectionFactory();  // non-managed connection
Connection conn = cf.getConnection();
Interaction interaction = conn.createInteraction();
byte [] someBytes = "some characters".getBytes();   // bytes for container 
ECIChannelRecord myChannel = new ECIChannelRecord(CHANNEL_NAME);
myChannel.put(REQUEST_INFO_CONTAINER, someBytes);  // BIT container
ECIInteractionSpec ixnSpec = getMyECIInteractionSpec();
interaction.execute(ixnSpec, myChannel, myChannel);  // invoke the target program

No código acima, observe o objeto ECIChannelRecord que representa o canal e o método put() de ECIChannelRecord, em que você especifica o nome do contêiner e seu conteúdo. Quando você coloca um array de bytes em um contêiner no ECIChannelRecord, ele se torna um contêiner BIT. O CICS TS e o CICS TG não fazem nenhuma conversão nos contêineres BIT. Na parte superior do segmento de código, você cria uma conexão fábrica para uma conexão não gerenciada, por motivos de simplicidade no exemplo de código. Em um programa do WebSphere Application Server ou WebLogic Java, você obteria a conexão a partir de um conjunto de conexões mantido pelo servidor de aplicativos usando uma consulta do JNDI. Ao usar um conjunto de conexões mantido pelo servidor de aplicativos (chamado de conexão gerenciada), o servidor de aplicativos pode ajudar a manter o conjunto de conexões, controlar a transacionalidade e propagar um contexto de segurança para o programa baseado em CICS TS.

Na amostra de código acima, você delega a criação do ECIInteractionSpec para um método chamadogetMyECIInteractionSpec(). Esse método cria um ECIInteractionSpec e designa as propriedades adequadas (nome do programa de CICS TS, ID do usuário, senha, etc.). Para obter mais informações sobre a criação de um ECIInteractionSpec, consulte o Centro de informações do CICS TG e os dois artigos do developerWorks de autoria de Phil Wakelin: Exploiting the J2EE Connector Architecture e Exploiting CICS channels and containers from Java clients.

Usando o DDW_CicsTg_ObjectTransporter com a CCI

Para usar a classe DDW_CicsTg_ObjectTransporter para passar objetos Java para um programa Java CICS TS, o código acima ficaria da forma mostrada abaixo, já que a classe DDW_CicsTg_ObjectTransporter estende ECIChannelRecord. Com a CCI, é tudo igual. A única diferença é que o método addObject() da classe DDW_CicsTg_ObjectTransporter é usado para serializar o objeto Java especificado e incluí-lo em um contêiner. O método execute() especifica o transportador de objetos, que é permitido, já que ele estende ECIChannelRecord. Ao retornar do programa Java de CICS TS, use o método getObject() do transportador de objetos para acessar o objeto de dados Java retornado.

DDW_CicsTg_ObjectTransporter transporter = new DDW_CicsTg_ObjectTransporter();
String inputData = "12345";
transporter.addObject("inputData", inputData);
// and 
ConnectionFactory cf = createAConnectionFactory();  // non-managed connection
Connection conn = cf.getConnection();
Interaction interaction = conn.createInteraction();
ECIInteractionSpec ixnSpec = getMyECIInteractionSpec();
interaction.execute(ixnSpec, transporter, transporter);  // invoke target program
// and
String responseData = (String)transporter.getObject("responseData");

Como antes, na amostra de código acima, delegue a criação de ECIInteractionSpec para um método chamado getMyECIInteractionSpec().

em qualquer exemplo de codificação que use um ECIChannelRecord, seria possível usar o DDW_CicsTg_ObjectTransporter.

Usando o DDW_CicsTg_ObjectTransporter com os assistentes do Rational Application Developer

Embora (como você viu acima) a API da CCI seja objetiva, o uso dos assistentes de J2C no Rational Application Developer é bastante difundido. Eles usam um ECIChannelRecord, portanto, ao fazer com que o DDW_CicsTg_ObjectTransporter estenda o ECIChannelRecord, é possível usar o DDW_CicsTg_ObjectTransporter com os assistentes do Rational Application Developer.

Além disso, com os assistentes do Rational Application Developer, é possível gerar um objeto que usa uma conexão não gerenciada (conforme o mostrado nos fragmentos de código acima) ou obtém uma conexão de CICS TG a partir de um conjunto de conexões fornecido pelo Java Application Server (como o WebSphere Application Server ou o WebLogic). O uso de um conjunto de conexões de CICS TG fornecido pelo seu servidor de aplicativos Java permite que você aproveite a capacidade que esse servidor tem de fornecer gerenciamento do conjunto de conexões do CICS TG, oferecer transacionalidade e propagar um contexto de segurança para o CICS.

As etapas detalhadas para usar os assistentes do Rational Application Developer estão listadas abaixo, mas de uma forma geral, pode-se copiar a classe DDW_CicsTg_ObjectTransporter fornecida para o seu projeto no Rational Application Developer, chamar o assistente J2C => J2C Bean e:

1. Especificar se você está usando uma conexão gerenciada ou não gerenciada. Se for gerenciada, especifique o nome JNDI do conjunto de conexões do CICS TG.
2. Na segunda página do assistente, especifique o nome do projeto, o nome do pacote que conterá o código gerado e o nome de implementação e interface do código gerado.
3. Na terceira página do assistente, especifique o nome do método a ser incluído no código gerado. Clique em Add para abrir um subassistente no qual se pode especificar o nome da classe; para entrada, especifique o DDW_CicsTG_ObjectTransporter.
4. Na próxima página, especifique o nome do programa de destino a ser chamado no CICS TS como o nome de função e, em seguida, clique em Finish.

A próxima seção mostra como usar o DDW_CicsTg_ObjectTransporter com os assistentes de J2C do Rational Application Developer. Os assistentes não são instalados no Rational Application Developer por padrão. É necessário solicitar que eles sejam instalados ou incluídos.

1. Crie um projeto Java ou um projeto dinâmico da web e dê a ele um nome como CICSTG-FUNDPROG-Client.
2. Copie o com.ibm.ddw.cicstg.object.transporter.DDW_CicsTg_ObjectTransporter e o com.ibm.ddw.cicstg.object.transporter.DDW_CicsTg_ObjectTransporterException (os dois são fornecidos juntamente com este artigo) para o seu projeto. É possível que você tenha referências não resolvidas a algumas classes de J2C. O DDW_CicsTg_ObjectTransporter não pode ser visto pelos assistentes de J2C a menos que todas as referências sejam resolvidas. É possível resolver as referências de algumas formas diferentes:
   • Se você já tem um projeto de adaptador ECI de CICS TG na sua área de trabalho (o nome do projeto será algo como cicseci8001), é possível incluí-lo no caminho de criação do seu projeto: clique com o botão direito no seu projeto e, a partir do menu de contexto, selecione Build Path => Java Build Path. Sob a guia Projects, inclua o projeto de adaptador ECI do CICS TG no caminho de criação do seu projeto.
   • Se você ainda não tem o projeto de adaptador ECI do CICS TG na sua área de trabalho, é possível incluir o projeto de adaptador ECI do CICS TG executando por meio do assistente J2C Bean e criando uma implementação simulada. Em seguida, é possível excluir as classes da implementação simulada.
   • Para fazer uma implementação simulada, clique com o botão direito no seu projeto e selecione New => Other e, em seguida, selecione J2C => J2C Bean. Na página Resource Adapter Selection, selecione o ECIResourceAdapter e, a seguir, clique em Next. Na página Connector Import, especifique o servidor de destino WebSphere Application Server V7.0 e, a seguir, clique em Next. Na página Connection Properties, especifique uma conexão gerenciada ou não gerenciada, dependendo do ambiente desejado. Na página J2C Java Bean Output Properties, especifique um pacote simulado e um nome da interface simulado e, em seguida, clique em Finish. Depois que o assistente concluir, você deverá estar com um projeto de adaptador do CICS TG na sua área de trabalho, com um nome semelhante a cicseci8001, e esse projeto deve estar no caminho de criação do projeto. Exclua o pacote simulado que foi gerado, a interface e a classe impl.
3. Depois de adotar qualquer uma das abordagens acima para resolver as referências na classe DDW_CicsTg_ObjectTransporter , os seguintes itens devem estar na sua área de trabalho:
   
4. Agora que você tem um projeto do adaptador ECI do CICS TG ECI e ele está no caminho de criação do projeto, é possível gerar a interface e a classe de implementação verdadeiras.
5. Clique com o botão direito no projeto e selecione New => Other. No diálogo Select a wizard, selecione J2C => New J2C Bean e, a seguir, clique em Next.
6. No diálogo New J2C Bean, selecione o projeto CICS ECIResource Adapter que já estava na sua área de trabalho ou que você criou acima:
   
7. Na página Connections Properties do diálogo New J2C Bean, especifique se você deseja uma conexão gerenciada ou não gerenciada e as características da conexão e, em seguida, clique em Next. A configuração do CICS TG está além do escopo deste artigo. Para obter mais informações, consulte o Centro de informações do CICS TG .
8. Na página J2C Java Bean Output Properties do diálogo New J2C Bean, especifique o nome do pacote que conterá as classes geradas. Este artigo usou com.ddw.cicstg.test como nome do pacote com um nome de interface de FUNDPROG. Em seguida, clique em Next. FUNDPROG também é o nome do programa baseado em CICS que você está chamando. O nome do programa de CICS TS real a ser chamado é especificado em uma etapa posterior.
   
9. Na página Java Methods do diálogo New J2C Bean, clique em Add para especificar o nome do método que será gerado no seu bean de J2C. Clique em Add para abrir o diálogo Java Method.
10. No diálogo Java Method, especifique o nome do método que será gerado no seu bean de J2C. Este artigo usou invokeProgram. Clique em Browse a partir de Input type.
11. No assistente Select a data type, digite ddw na parte superior e, em seguida, selecione DDW_CicsTg_ObjectTransporter e clique em OK.
12. De volta à página Java Method, clique em Finish: .
    
13. De volta à página Java Methods, especifique o nome do programa CICS a ser chamado como o nome de Function (no nosso caso, é FUNDPROG) e, em seguida, clique em Finish.

Escrevendo um programa cliente Java de CICS TG usando a implementação gerada a partir dos assistentes do J2C

Supondo que, quando você executou o assistente do Rational Application Developer, o nome da sua implementação (objeto gerado) era FUNDPROGImpl e o nome do método que você especificou para ser incluído era invokeProgram(), seria possível chamar o código da implementação gerada a partir do seu programa cliente Java de CICS TG usando o seguinte fragmento de código:

DDW_CicsTG_ObjectTransporter transporter = new DDW_CicsTG_ObjectTransporter();
String inputData = "12345";
transporter.addObject("inputData", inputData);
FUNDPROGImpl fundProg = new FUNDPROGImpl();  
// pass a transporter, receive a transporter
transporter = fundProg.invokeProgram(transporter); // invoke CICS TS program
String responseData = (String)transporter.getObject("responseData");
// work with the response data

Essa abordagem oferece várias vantagens:

1. Se você especifica uma conexão gerenciada, o código gerado pelo Rational Application Developer usa a capacidade que o servidor de aplicativo Java tem de gerenciar um conjunto de conexões do CICS TG, controlar a transacionalidade (se você usou o ECIXAResourceAdapter) e propagar um contexto de segurança.
2. O código gerado usa a API JCA CCI "por baixo dos panos" para que você não precise conhecer os detalhes da API da CCI.
3. O seu programa cliente Java de CICS TG não precisa lidar com os detalhes da conexão do CICS TG.
4. E o melhor de tudo é que é possível usar o transportador de objetos do CICS TG a partir do seu programa cliente Java do CICS TG. O exemplo acima passa somente um objeto, mas é possível passar tantos objetos quantos forem necessários e você não está limitado ao tipo de objeto (contanto que os objetos implementem a interface serializável, conforme o descrito na parte 2).

Recebendo objetos Java em um ambiente de JVM compartilhado de CICS ou um a JVMServer baseado em CICS OSGi

O seguinte fragmento de código pode ser usado para receber objetos Java provenientes do cliente Java de CICS TG em um programa Java baseado em CICS TS executando em um ambiente de JVM compartilhado de CICS ou um CICS servidor de JVM baseado em OSGi.

DDW_CicsObjectTransporter transporter = new 
     DDW_CicsObjectTransporter();
String inputData = (String)transporter.getObject("inputData");
// work with inputData object
String responseData = "Whatever the response data is";
transporter.addObject("responseData", responsedata); // new object
return;

O código acima usa a classe DDW_CicsObjectTransporter fornecida com a classe 2. Todos os detalhes associados ao DDW_CicsObjectTransporter foram discutidos na parte 2.

Desempenho

Há uma sobrecarga associada à serialização e desserialização de objetos. Ao usar o transportador de objetos fornecido, tome a referência do seu aplicativo em um estágio inicial do ciclo de vida do desenvolvimento para se certificar de que o seu aplicativo tenha as características de desempenho necessárias. Embora a passagem dos dados entre programas Java baseados em CICS usando a abordagem tradicional de séries de bytes orientadas a campos exija que o programador de aplicativos Java execute utilitários adicionais e conheça alguns detalhes de uma linguagem de procedimento como COBOL ou PL/I, essa abordagem à passagem dos dados tradicional de séries de bytes orientadas a campos pode ter um desempenho melhor.

A verificação de erros foi incluída no transportador de amostra fornecido com este artigo, e a maior parte da verificação de erros está ativada por padrão. Para melhorar o desempenho do código de amostra do transportador fornecido, é possível usar os métodos listados abaixo para desativar parte da verificação de erro. Além disso, quando são detectados erros de incompatibilidade de versão, um aviso é emitido por padrão e o transportador continua a funcionar. Se você quiser que o transportador seja desativado se um transportador remoto em um nível diferente for detectado, use o método setStopTransporterActivityIfLocalRemoteVersionsDifferent(true) .

setCheckForTransporterErrorsInChannel(false);
     // don't check for errors from previous requests
setCheckForSerialVersionUIDBeforeSerialization(false);
     // don't take time to check for serialVersionUID field on objects to be serialized
setCheckTheTransporterLevelWithWhichWeAreCommunicating(false);
     // don't take time to check if local and remote transporter are at same level

Conforme indicado anteriormente, use o transportador de objetos somente ao se movimentar entre ambientes Java baseados em CICS. Ao permanecer dentro de um único ambiente Java baseado em CICS, use a programação Java normal, instanciando os objetos e invocando os métodos.

Os DDW_CicsTg_ObjectTransporter tem a intenção de implementar uma técnica conhecida do programador de aplicativos em Java e simplificar a passagem de objetos. Já que o programador de aplicativos Java tem facilidade de usar o transportador de objetos, é fácil cometer um descuido. Se você passa objetos que contêm informações além das que devem ser passadas, ou se os objetos que você passa fazem referência a outros objetos que não precisam ser passados, você perderá tempo sem necessidade serializando dados e transferindo dados extras — e essas duas coisas prejudicam o desempenho.

Depurando problemas de passagem de objetos

Para obter informações sobre esse tópico, consulte a parte 2.

Conclusão

Este artigo (parte 3 de 3) mostrou como passar objetos de dados Java de um cliente Java de CICS TG para um programa Java baseado em CICS TS que executa em um ambiente do servidor OSGi JVM ou um ambiente de JVM compartilhado de CICS.

• Já que o CICS TG permite passar um canal e contêineres, a mesma abordagem de passar objetos serializados que foi discutida na parte 2 pode ser usada com o CICS TG.
• Embora o CICS TG possa trabalhar com um canal e contêineres, a API usada em um programa cliente de CICS TG para interagir com o canal e os contêineres é diferente da API usada em um programa Java baseado em CICS TS.
• As comunicações entre o seu programa cliente Java de CICS TG e um programa de CICS usa a API de JCA CCI. É possível codificar para a API de CCI diretamente ou usar os assistentes do Rational Application Developer para gerar o código que implementa as comunicações. O código gerado pode aproveitar a capacidade que o servidor de aplicativos tem de controlar um conjunto de conexões para uma região de CICS, controlar a transacionalidade e propagar um contexto de segurança.
• Este artigo fornece uma classe DDW_CicsTg_ObjectTransporter que pode ser usada em um programa cliente Java de CICS TG que pode interoperar com um DDW_CicsObjectTransporter em um programa Java baseado em CICS TS para possibilitar a passagem de objetos de dados Java.
• O artigo fornece amostras de código que usam o DDW_CicsTg_ObjectTransporter com a API de CCI, bem como etapas detalhadas sobre como usar o DDW_CicsTg_ObjectTransporter com os assistentes de J2C no Rational Application Developer.
• Embora as classes DDW_CicsTg_ObjectTransporter e DDW_CicsObjectTransporter devam funcionar bem, elas não foram submetidas ao teste oficial da IBM e, portanto, devem ser consideradas como um código "tal como está", que se destina unicamente a ilustrar os conceitos desta série de artigos.

No caso dos aplicativos baseados em CICS que são implementados unicamente em Java, experimente o transportador de objetos e veja se você também acha que esta abordagem fornece uma forma conveniente para Java de passar objetos de dados Java entre ambientes Java fornecidos pelo CICS. Esta abordagem envolve, de fato, serialização e desserialização de objetos e a sobrecarga relacionada, portanto, tome a referência do seu aplicativo para se certificar de que esta abordagem à passagem de objetos de dados Java tenha o desempenho necessário para o seu aplicativo.

Agradecimentos

O autor gostaria de agradecer aos seguintes colegas da IBM pela ajuda em revisar este artigo e fornecer sugestões para o conteúdo e aprimoramentos:

• Mark Cocker, Planejamento e estratégia técnica de CICS, IBM Reino Unido
• Leigh Compton, Certified IT Specialist, Equipe de qualificações técnicas avançadas de CICS, IBM EUA
• Steve Fowlkes, Certified IT Specialist, Suporte técnica de CICS, IBM EUA
• Phil Wakelin, Planejamento e estratégia técnica de CICS, Java e acesso ao CICS, IBM Reino Unido

Voltar para parte superior

Download

Informações sobre métodos de download

Recursos

• Recursos CICS
  • Centros de informação CICS
    Centros de informações para todos os produtos e ferramentas CICS, incluindo CICS Transaction Gateway e CICS Transaction Server.
  • Página da família de produtos CICS
    Descrições do produto, notícias sobre o produto, informações de treinamento, informações de suporte, etc.
  • Página de produto do CICS Transaction Gateway
    Descrições do produto, notícias sobre o produto, informações de treinamento, informações de suporte, etc.
  • Serviços CICS
    A IBM tem uma ampla variedade de serviços para ajudá-lo a planejar, projetar, proteger, gerenciar e implementar soluções do CICS em sua organização. Os serviços IBM CICS podem ajudar a reduzir custos, maximizar seu investimento em CICS e aumentar sua vantagem competitiva.
  • IBM Redbook: Introduction to CICS dynamic scripting
    O CICS Transaction Server Feature Pack for Dynamic Scripting integra o WebSphere sMash ao tempo de execução do CICS TS V4.1, ajudando-o a reduzir o tempo e o custo do desenvolvimento de aplicativo CICS. O Feature Pack fornece um ambiente robusto e gerenciado para uma ampla variedade de aplicativos situacionais, permitindo que os desenvolvedores PHP e Groovy criem relatórios, painéis e widgets, integrem ativos CICS em mash-ups, e muito mais.
  • IBM Redbook: Developing connector applications for CICS
    Saiba como desenvolver aplicativos clientes que conectam o CICS usando CICS Transaction Gateway.
  • Outros Redbooks sobre CICS
    IBM Redbooks cobrindo tópicos básicos e avançados relacionados ao CICS
  • artigo do developerWorks: Exploiting the J2EE Connector Architecture
    Integrating CICS and WebSphere Application Server using XA global transactions ― Este artigo mostra como usar o J2EE Connector Architecture (JCA) e o CICS Transaction Gateway para fornecer integração transacional de aplicativos CICS e componentes J2EE implementados no WebSphere Application Server.
  • artigo do developerWorks: Exploiting CICS channels and containers from Java clients
    Beyond the 32KB COMMAREA limit ― Este artigo mostra como usar canais e contêineres no CICS e inclui exemplos detalhados de codificação para o uso da classe ECIRequest, junto com amostras de cliente CICS e Java para uso como um cliente Java independente.
  
  
• Recursos adicionais para este artigo
  • Mais informações sobre o Axis2
  • Mais informações sobre Java
  • Mais informações sobre OSGi
  • Mais informações sobre Project Zero
  • Mais informações sobre o IBM Rational Application Developer
  • IBM Press book: Getting started with IBM WebSphere sMash
  
  
• Recursos do WebSphere
  • Recursos para desenvolvedores WebSphere no developerWorks
    Informações técnicas e recursos para desenvolvedores que usam produtos WebSphere. O WebSphere no developerWorks fornece downloads de produtos, informações de instruções, recursos de suporte e uma biblioteca técnica grátis com mais de 2.000 artigos técnicos, tutoriais, melhores práticas, IBM Redbooks e manuais on-line de produtos.
  • Recursos do developerWorks para desenvolvedor de integração do aplicativo WebSphere
    Artigos de instruções, downloads, tutoriais, educação, informações de produto e outros recursos para ajudá-lo a desenvolver soluções de integração do aplicativo WebSphere e de integração de negócio.
  • Downloads de versão de teste do WebSphere mais populares
    Downloads de versão gratuita de teste dos principais produtos do WebSphere.
  • Fóruns do WebSphere
    Fóruns específicos do produto nos quais é possível obter respostas de perguntas técnicas e compartilhar o seu conhecimento com outros usuários de WebSphere.
  • Demos On Demand do WebSphere
    Faça o download e acompanhe essas demos de execução automática, e saiba como os produtos e tecnologias WebSphere podem ajudar sua empresa a responder a um ambiente de negócios em rápida mudança e com complexidade crescente.
  • Boletim semanal do WebSphere no developerWorks
    O boletim do developerWorks oferece artigos e informações mais recentes somente naqueles tópicos que interessam a você. Além do WebSphere, é possível selecionar entre Java, Linux, Open source, Rational, SOA, serviços da web e outros tópicos. Inscreva-se agora e indique as mensagens que deseja receber.
  • Livros da IBM Press relacionados ao WebSphere
    Compras on-line convenientes por meio da Barnes & Noble.
  • Eventos relacionados ao WebSphere
    Conferências, exposições, webcasts e outros eventos em todo o mundo que são do interesse dos desenvolvedores WebSphere.
  
  
• Recursos do developerWorks
  • Downloads de teste de produtos de software IBM
    Downloads de teste sem custo de produtos selecionados da IBM® DB2®, Lotus®, Rational®, Tivoli®e WebSphere® de ponta.
  • blogs do developerWorks
    Participe de uma conversa com os usuários e autores do developerWorks, e com editores e desenvolvedores da IBM.
  • Recursos de computação em nuvem do developerWorks
    Acesse a nuvem IBM ou Amazon EC2, teste um produto de computação em nuvem da IBM em um ambiente de simulação, acompanhe as demos de produtos e serviços de computação em nuvem, leia artigos sobre a nuvem e acesse outros recursos sobre a nuvem.
  • Briefings técnicos do developerWorks
    Sessões informativas técnicas grátis realizadas por especialistas IBM para acelerar a sua curva de aprendizagem e ajudá-lo a ter sucesso nos seus projetos de software mais desafiadores. As sessões informativas vão de sessões virtuais de uma hora a sessões ao vivo com meio dia e um dia inteiro de duração em cidades do mundo todo.
  • Podcasts do developerWorks
    Ouça entrevistas e discussões interessantes com inovadores de software.
  • o developerWorks no Twitter
    Confira as nossas mensagens e URLs recentes no Twitter.
  • IBM Education Assistant
    Uma coleção de módulos educacionais multimídia que ajudam a entender melhor os produtos de software IBM e usá-los de forma mais efetiva para atender aos seus requisitos de negócios.
  
  

Sobre o autor

Dennis Weiand é Client Technical Specialist em CICS, web e Java na equipe IBM Technical Sales localizada em Dallas, Texas. É possível entrar em contato com Dennis pelo email dweiand@us.ibm.com.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Introdução
• CICS Transaction Gateway
• Passando objetos Java de um cliente Java CICS TG para um programa Java baseado em CICS
• Usando o CCI em um programa cliente Java de CICS TG
• Usando o DDW_CicsTg_ObjectTransporter com os assistentes do Rational Application Developer
• Desempenho
• Depurando problemas de passagem de objetos
• Conclusão
• Download
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais