Introduction

Part 1 of this three-part series described the different Java™ environments that IBM® CICS® provides:

• The traditional pooled JVM, where only one CICS-based Java transaction runs in a JVM at a time.
• The CICS JVM server environment, where multiple Java program requests can be dispatched to the same JVM at the same time. Here are the CICS-provided Java environments that use the JVM server (but can't be mixed into a single JVM server):
  • The OSGi-based environment, which provides the OSGi dynamic module system with functionality such as dynamically adding and removing Java classes to the JVM, providing the OSGi registry, exposing only the interfaces to your Java module instead of all classes in the module, and specifying module dependencies to almost eliminate typical ClassNotFound problems.
  • The Axis2 open-source Web service engine, which lets you expose a POJO quickly and easily using JAX-WS annotations, and write handlers in the Axis2 style.
  • CICS Dynamic Scripting, which provides a quick way to develop Web applications using the PHP and Groovy scripting languages. The PHP and Groovy interpreters are implemented in Java, so there is a Java bridge to let you instantiate Java objects and invoke CICS programs
• CICS Transaction Gateway (CICS TG), which facilitates communications from a Java program running in a non-CICS environment to a CICS Transaction Server (CICS TS) program.

As you would expect, if you are working with Java classes within a single CICS-based Java program, you work with them as normal: you instantiate the object and invoke the object's methods. However, when your application is coded in Java, but you want to leverage the strengths of the different CICS-provided Java environments, or you want to distribute parts of your Java-based application over multiple CICS regions, using a Java-like approach to transporting Java data objects is preferable to the traditional series-of-bytes field-oriented approach to transporting data. This traditional approach to passing data is needed and performs well if you are using multiple programming languages, which is one of the strengths of CICS.

Part 1 described that the CICS version of a call, the EXEC CICS LINK command, which lets you invoke another program written in the same or a different programming language in a CICS environment. The CICS-architected facilities for passing data between CICS programs are the COMMAREA and channels and containers. The COMMAREA is a block of storage up to 32 KB, while a container is a named block of storage with no size limit. Containers are grouped into a channel, which can be passed from one CICS program to another. The COMMAREA, and channels and containers are mutually exclusive -- a program can receive data using only one of the two techniques at a time. When you LINK from program A to program B, program A can pass a COMMAREA or a channel, but not both.

When passing data between CICS programs, you usually place the data in a field-oriented series-of-bytes structure. Programs written in Java can participate in this environment, but when your CICS-based application is only using Java, a Java application programmer will find it more convenient to stay in the object-oriented Java world and pass Java data objects between your CICS-based Java programs. So Part 1 concluded that if a CICS-based application is only written in Java, and you need to move from one CICS Java environment to another, it is simpler to stay in a Java paradigm and pass Java data objects between the CICS-based Java environments. You can do that by serializing a Java data object into a CICS container, passing the container to another Java program running in a different CICS Java environment, and then deserializing the object in the target Java program.

Parts 1 and 2 discussed why a Java programmer would find it easier to pass Java data objects between CICS-based Java programs instead of the traditional CICS field-oriented series-of-bytes that you would use to pass data between programs implemented in different programming languages. Part 2 described a technique for passing Java data objects that uses object serialization, the CICS-provided Java API to place data into and get data out of CICS containers, and the CICS-provided Java API to LINK from one CICS program to another. Part 2 also provided sample Java classes that showed you how to write a generalized Java object that can transport Java data objects between different CICS Java environments. The technique described in Part 2 enables Java data objects to be passed between CICS-provided Java environments using the following coding approach:

     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
     }

Here is some sample code for the responding Java program to return data:

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;

A CICS TG Java client program can communicate to a CICS TS environment using channels and containers, so the same technique described in Part 2 for passing Java data objects between CICS TS-provided Java environments can be used to pass Java data objects between a CICS TG Java client program and a Java program running in CICS TS. You can even use the same object transporter class on the CICS TS side, but you need a different implementation of the object transporter on the CICS TG Java client side to accommodate the differences in the CICS TG programming API.

This article (Part 3), describes the API that enables CICS TG Java client programs to interact with a CICS TS program. It also provides an implementation of an object transporter that you can use in a CICS TG Java client along with the wizards in Rational Application Developer and Rational Developer for System z to generate code to communicate from a CICS TG Java client to a CICS TS program.

The wizards provided with Rational Application Developer normally take a COBOL copybook as input and generate code to marshal the data to be passed into a COBOL-like field-oriented series-of-bytes. The two major advantages of this approach are that your CICS TG Java client program can pass data to a COBOL, PL/I, C, C++, Java, or Assembler program running in CICS TS, and this approach is fast. However, if both the client- and server-side programs are in Java, it will be easier for a Java application programmer to use a Java-like paradigm and pass Java data objects between the Java client and Java server programs. This article shows you how to use the provided object transporter with the Rational Application Developer wizards, giving you the benefits of code generation from the wizards and the convenience for the Java application programmer of passing Java data objects.

As described previously, the goal of this article series is to make it convenient for the Java application programmer to pass data objects between the different CICS-provided Java environments. Since there is some overhead to serializing and deserializing Java objects, you will need to benchmark your application to verify that this approach to passing Java data objects performs acceptably for your application. For more information on issues associated with Java object serialization, see Part 2.

CICS Transaction Gateway

CICS TG provides secure transactional communication to CICS from a variety of client programming languages, such as C#, Java, Microsoft® .NET, Microsoft Visual Basic, PowerBuilder, and workstation-based COBOL to a program running in CICS TS.

For a Java client running in a non-CICS environment, CICS TG implements Java Connector Architecture (JCA), which defines a standard way to communicate from Java programs to Enterprise Information Systems (EISs) such as CICS, IMS, JDEdwards, PeopleSoft, and SAP. JCA defines a way to implement managed or non-managed connections using a standard API called the Common Client Interface (CCI). Using a managed connection, a Java Enterprise Edition (JEE) application server can provide connection management, control transactionality, and propagation of a security context. This standard CCI API lets a Java programmer use a common API to access different EISs.

CICS TG can be set up in multiple configurations -- for more information, see CICS TG information center.

For a scenario where you have a CICS TG client program written in Java and your CICS server-side business logic also implemented in Java, you can use the techniques in this article to pass Java data objects from your CICS TG client program to the CICS-based Java program that implements your business logic.

Passing Java objects from a CICS TG Java client to a CICS-based Java program

Two APIs are available for working with the CICS TG and channels and containers: the original API provided when CICS TG first started supporting Java around 1996, and the JCA API (also called the Common Client Interface or CCI) that was added later. Although both APIs support channels and containers, this article focuses on the CCI because it is the strategic API for CICS TG. For additional details on using CCI with CICS TG, see the IBM Redbook Developing connector applications for CICS, and the two developerWorks articles by Phil Wakelin: Exploiting the J2EE Connector Architecture and Exploiting CICS channels and containers from Java clients.

When writing a CICS TG Java client using the CCI, you work with an ECIChannelRecord, which represents a channel and contains methods to work with the containers in a channel. The ECIChannelRecord is used in CICS TG Java client programs instead of the Channel and Container classes that were discussed for CICS TS programs in Part 2.

The ECIChannelRecord contains methods to put(), get(), and delete() containers, whereas for CICS TS, the put() and get() methods are used with a Container object, and you delete containers with a deleteContainer() method. Additionally, error checking is different between the CICS TG methods and the CICS TS methods. There are two types of containers: BIT and CHAR (described in Part 1). How you create and access a BIT versus a CHAR container using the CICS TG-provided ECIChannelRecord is different from using the CICS TS-provided Channel object. Also, with a CICS TS Java program you use a Program object and a link() method to invoke a program, but from a CICS TG Java client program, you use the execute() method on an Interaction obtained from a Connection (more on this in a few paragraphs).

The object serialization and deserialization is the same for any Java implementation, so you can use the same serialization and deserialization code in the CICS TG and CICS TS object transporters. The methods to get, add, and delete Java objects are similar for both object transporters, which provides a consistent interface to both transporters. But the underlying interactions with the Channel / Container objects versus the ECIChannelRecord object is quite different.

The DDW_CicsObjectTransporter (provided with Part 2) provides a thin façade on top of the existing CICS TS channel and container infrastructure. For the CICS TG object transporter, the ECIChannelRecord was extended into a DDW_CicsTg_ObjectTransporter, which allows the DDW_CicsTg_ObjectTransporter to be used anywhere an ECIChannelRecord can be used, including both the CCI and the Rational Application Developer wizards. Examples of both are provided below.

Using the CCI in a CICS TG Java client program

If you, as a CICS TG Java client programmer, were to code to CCI yourself instead of generating code using the Rational Application Developer wizards, it would look similar to the code snippet below. The CCI is straightforward: You create a connection object or get one from a pool of connections. From the connection, you create an Interaction, and use the execute() method of the Interaction to invoke the back-end program. These parts of the CCI are the same regardless of your back-end system -- CICS, IMS, JDEdwards, and so on.

The part of the CCI that is different depending on the back-end system is the interaction specification (the specifics of the interaction) and the format of the data being passed. To invoke a CICS-based program, the interaction specification is an ECIInteractionSpec, which contains the name of the CICS program to be invoked, the userid and password, and other specifics of the interaction with the CICS-based program. In the code sample below, you pass an ECIChannelRecord that contains the containers to be passed or retrieved from the CICS TS program. The channel and container mechanism is specific to CICS TS and is not used with other 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

In the above code, note the ECIChannelRecord object that represents the channel, and the put() method of the ECIChannelRecord, where you specify both the name of the container and its contents. When you put a byte array in a container in the ECIChannelRecord, it becomes a BIT container. Neither CICS TS nor CICS TG will do any conversion on BIT containers. At the top of the code segment, you create a connection factory for a non-managed connection for simplicity in the code example. In a WebSphere Application Server or WebLogic Java program, you would get a connection from a connection pool maintained by the application server using a JNDI lookup. When using a connection pool maintained by the application server (called a managed connection), the application server can assist with maintaining the pool of connections, controlling transactionality, and propagating a security context to the CICS TS-based program.

In the code sample above, you delegate the construction of the ECIInteractionSpec to a method named getMyECIInteractionSpec(). This method creates an ECIInteractionSpec and assigns the appropriate properties (CICS TS program name, userid, password, and so on). For more information on the creation of an ECIInteractionSpec, see the CICS TG information center and the two developerWorks articles by Phil Wakelin: Exploiting the J2EE Connector Architecture and Exploiting CICS channels and containers from Java clients.

Using the DDW_CicsTg_ObjectTransporter with the CCI

To use the DDW_CicsTg_ObjectTransporter class to pass Java objects to a CICS TS Java program, the above code would look as shown below, since the DDW_CicsTg_ObjectTransporter class extends ECIChannelRecord. Everything is the same with the CCI -- the only difference is that the addObject() method of the DDW_CicsTg_ObjectTransporter class is used to serialize the specified Java object and add it to a container. The execute() method specifies the object transporter, which is allowed since it extends ECIChannelRecord. Upon return from the CICS TS Java program, use the getObject() method of the object transporter to access the returned Java data object.

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");

As before, in the code sample above, delegate the construction of the ECIInteractionSpec to a method named getMyECIInteractionSpec().

in any coding example that uses an ECIChannelRecord, you could use the DDW_CicsTg_ObjectTransporter.

Using the DDW_CicsTg_ObjectTransporter with the Rational Application Developer wizards

Although as you have seen above, the CCI API is straightforward, use of the J2C wizards in Rational Application Developer is quite popular. They use an ECIChannelRecord, so by having the DDW_CicsTg_ObjectTransporter extend the ECIChannelRecord, you can use the DDW_CicsTg_ObjectTransporter with the Rational Application Developer wizards.

Also with the Rational Application Developer wizards, you can generate an object that uses an unmanaged connection (as shown in the above code snippets), or gets a CICS TG connection from a connection pool provided by your Java Application Server (such as WebSphere Application server or WebLogic). Using a CICS TG connection pool provided by your Java application server lets you leverage your Java application server's ability to provide CICS TG connection pool management, provide transactionality, and propagate a security context to CICS.

The detailed steps to use the Rational Application Developer wizards are listed below, but at a high-level, you can copy the provided DDW_CicsTg_ObjectTransporter class to your project in Rational Application Developer, invoke the J2C => J2C Bean wizard, and:

1. Specify if you are using a managed or non-managed connection. If managed, specify the JNDI name of the CICS TG connection pool.
2. On the second page of the wizard, specify your project name, the name of the package to contain the generated code, and the interface and implementation name of the generated code.
3. On the third page of the wizard, specify the name of the method to be added to the generated code. Click Add to bring up a sub-wizard where you specify the class name, and for input, specify the DDW_CicsTG_ObjectTransporter.
4. On the next page, specify the target program name to be invoked on CICS TS as the function name, and then click Finish.

The next section shows you how to use the DDW_CicsTg_ObjectTransporter with the Rational Application Developer J2C wizards. The wizards are not installed into Rational Application Developer by default -- you must ask for them to be installed or added.

1. Create a Java project or a dynamic Web project and give it a name such as CICSTG-FUNDPROG-Client.
2. Copy the com.ibm.ddw.cicstg.object.transporter.DDW_CicsTg_ObjectTransporter and the com.ibm.ddw.cicstg.object.transporter.DDW_CicsTg_ObjectTransporterException (both are provided with this article) into your project. You may have some unresolved references to some J2C classes. The DDW_CicsTg_ObjectTransporter cannot be seen by the J2C wizards unless all references are resolved. You can resolve the references in a few different ways:
   • If you have a CICS TG ECI adapter project already in your workspace (the name of the project will be something like cicseci8001), then you can add that project to your project's build path: Right-click on your project and from the context menu, select Build Path => Java Build Path. Under the Projects tab, add the CICS TG ECI adapter project to your project's build path.
   • If you don't have the CICS TG ECI adapter project already in your workspace, you can add the CICS TG ECI adapter project by running through the J2C Bean wizard and creating a dummy implementation. You can then delete the classes for the dummy implementation.
   • To make a dummy implementation, right-click on your project and select New => Other, then select J2C => J2C Bean. On the Resource Adapter Selection page, select the ECIResourceAdapter and then click Next. On the Connector Import page, specify a Target server of WebSphere Application Server V7.0 and then click Next. On the Connection Properties page, specify a Managed or non-managed connection, depending on your desired environment. On the J2C Java Bean Output Properties page, specify a dummy package and a dummy interface name, and then click Finish. After the wizard completes you should have a CICS TG Adapter project in your workspace with a name something like cicseci8001, and that project should be in your project's build path. Delete the generated dummy package, interface, and impl class.
3. After using either of the above approaches to resolve the references in the DDW_CicsTg_ObjectTransporter class, the following items should be in your workspace:
   
4. Now that you have a CICS TG ECI Adapter project and it is in your project's build path, you can generate your real interface and implementation class.
5. Right-click on your project and select New => Other. From the Select a wizard dialog select J2C => New J2C Bean, and then click Next.
6. From the New J2C Bean dialog, select the CICS ECIResource Adapter project that was either already in your workspace or the one you created above:
   
7. From the Connections Properties page of the New J2C Bean dialog, specify whether you want a managed or non-managed connection and the connection characteristics, and then click Next. Configuration of CICS TG is beyond the scope of this article -- for more information, see the CICS TG information center.
8. From the J2C Java Bean Output Properties page of the New J2C Bean dialog, specify the name of package that will contain the generated classes. This article used com.ddw.cicstg.test for the package name with an interface name of FUNDPROG. Then click Next. FUNDPROG is also the name of the CICS-based program you are invoking. The name of the actual CICS TS program to be invoked is specified in a later step.
   
9. On the Java Methods page of the New J2C Bean dialog, click Add to specify the name of the method that will be generated into your J2C Bean. Click Add to open the Java Method dialog.
10. On the Java Method dialog, specify the name of the method that will be generated into your J2C Bean. This article used invokeProgram. Click Browse across from Input type.
11. In the Select a data type wizard, type ddw at the top, then select DDW_CicsTg_ObjectTransporter and click OK.
12. Back on the Java Method page, click Finish: .
    
13. Back on the Java Methods page, specify the name of the CICS program to be invoked as the Function name (in our case it is FUNDPROG), and then click Finish.

Writing a CICS TG Java Client Program using the implementation generated from the J2C Wizards

Assuming that when you ran the Rational Application Developer wizard, your implementation (generated object) name was FUNDPROGImpl, and the method name you specified to be added was invokeProgram(), you could invoke the generated implementation code from your CICS TG Java client program using the following code snippet:

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

Taking this approach has several advantages:

1. If you specify a managed connection, the code generated by Rational Application Developer uses the Java application server's capability to manage a pool of CICS TG connections, control transactionality (if you used the ECIXAResourceAdapter), and propagate a security context.
2. The generated code uses the JCA CCI API under the covers so that you don't need to know the details of the CCI API.
3. Your CICS TG Java client program doesn't have to deal with the details of the CICS TG connection.
4. And best of all, you can use the CICS TG object transporter from your CICS TG Java client program. The above example passes only one object, but you can pass as many objects as you need to and you are not limited to the object type (as long as the objects implement the Serializable interface, as described in Part 2).

Receiving Java objects into a CICS pooled JVM or a CICS OSGi-based JVMServer

The following code snippet can be used to receive Java objects from the CICS TG Java client into a CICS TS-based Java program running in a CICS pooled JVM or a CICS OSGi-based JVM server.

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;

The above code uses the DDW_CicsObjectTransporter class supplied with Part 2. All details associated with the DDW_CicsObjectTransporter were discussed in Part 2.

Performance

There is overhead associated with object serialization and deserialization. When using the provided object transporter, benchmark your application early in the development life cycle to verify that your application has the performance characteristics you need. Although passing data between CICS-based Java programs using the traditional field-oriented series-of-bytes approach requires the Java application programmer to run additional utilities and know some details of a procedural language such as COBOL or PL/I, this traditional field-oriented series-of-bytes approach to passing data may perform better.

Error-checking was added to the sample transporter provided with this article and most of the error checking is enabled by default. To improve the performance of the provided transporter sample code, you can use the methods listed below to disable some of the error checking. Also, by default, when version mismatch errors are detected, a warning is issued and the transporter continues to function. If you would like the transporter to become disabled if a remote transporter at a different level is detected, use the setStopTransporterActivityIfLocalRemoteVersionsDifferent(true) method.

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

As indicated before, only use the object transporter when moving between CICS-based Java environments. When staying within a single CICS-based Java environment, use normal Java programming, instantiating objects and invoking methods.

The DDW_CicsTg_ObjectTransporter class is intended to implement a technique familiar to the Java application programmer, and to make passing objects simple. Since the object transporter is so easy to use for a Java application programmer, it is easy to get sloppy. If you pass objects that contain more information than you need to pass, or the objects you pass reference other objects that don't need to be passed, you will be wasting time needlessly serializing data and transferring extra data, both of which will decrease performance.

Debugging object-passing issues

For information on this topic, see Part 2.

Conclusion

This article (Part 3 of 3) showed you how to pass Java data objects from a CICS TG Java client to a CICS TS-based Java program running in an OSGi JVM server environment or in a CICS pooled JVM environment.

• Since CICS TG lets you pass a channel and containers, the same approach of passing serialized objects discussed in Part 2 can be used with CICS TG.
• Although CICS TG can work with a channel and containers, the API used in a CICS TG client program to interact with the channel and containers is different from the API used in a CICS TS-based Java program.
• Communications between your CICS TG Java client program and a CICS program uses the JCA CCI API. You can code to the CCI API directly or you can use wizards in Rational Application Developer to generate code that implements the communications. The generated code can leverage an application server's capability to control a pool of connections to a CICS region, control transactionality, and propagate a security context.
• This article provides a DDW_CicsTg_ObjectTransporter class that you can use in a CICS TG Java client program that can interoperate with a DDW_CicsObjectTransporter in a CICS TS-based Java program to enable passing Java data objects.
• The article provides code samples that use the DDW_CicsTg_ObjectTransporter with the CCI API, as well as detailed steps on how to use the DDW_CicsTg_ObjectTransporter with the J2C wizards in Rational Application Developer.
• Although the DDW_CicsTg_ObjectTransporter and the DDW_CicsObjectTransporter classes should work fine, they have not been submitted to official IBM testing and therefore should be considered "as-is" code, and intended only to illustrate the concepts in this article series.

For your CICS-based applications that are solely implemented in Java, give the object transporter a try and see if you agree that this approach provides a Java-friendly way to pass Java data objects between CICS-provided Java environments. This approach does involve object serialization and deserialization and its related overhead, so benchmark your application to verify that this approach to passing Java data objects performs as needed for your application.

Acknowledgements

The author would like to thank the following IBM colleagues for their help in reviewing this article and providing suggestions for content and improvement:

• Mark Cocker, CICS Technical Strategy and Planning, IBM UK
• Leigh Compton, Certified IT Specialist, CICS Advanced Technical Skills Team, IBM USA
• Steve Fowlkes, Certified IT Specialist, CICS Technical Support, IBM USA
• Phil Wakelin, CICS Technical Strategy and Planning, Java and Access to CICS, IBM UK

Back to top

Download

Information about download methods

Resources

• CICS resources
  • CICS information centers
    Information centers for all CICS products and tools, including CICS Transaction Gateway and CICS Transaction Server.
  • CICS family product page
    Product descriptions, product news, training information, support information, and more.
  • CICS Transaction Gateway product page
    Product descriptions, product news, training information, support information, and more.
  • CICS Services
    IBM has a comprehensive range of services to help you plan, design, upgrade, secure, manage, and implement CICS solutions within your organization. IBM CICS Services can help you lower your costs, maximize your investment in CICS, and increase your competitive advantage.
  • IBM Redbook: Introduction to CICS dynamic scripting
    The CICS Transaction Server Feature Pack for Dynamic Scripting integrates WebSphere sMash into the CICS TS V4.1 run time, helping you reduce the time and cost of CICS application development. The Feature Pack provides a robust, managed environment for a wide range of situational applications, enabling PHP and Groovy developers to create reports, dashboards, and widgets, integrate CICS assets into mash-ups, and much more.
  • IBM Redbook: Developing connector applications for CICS
    Learn how to develop client applications that connect to CICS using CICS Transaction Gateway.
  • Additional CICS Redbooks
    IBM Redbooks covering basic to advanced topics related to CICS
  • developerWorks article: Exploiting the J2EE Connector Architecture
    Integrating CICS and WebSphere Application Server using XA global transactions -- This article shows you how to use J2EE Connector Architecture (JCA) and CICS Transaction Gateway to provide transactional integration of CICS applications and J2EE components deployed within WebSphere Application Server.
  • developerWorks article: Exploiting CICS channels and containers from Java clients
    Beyond the 32KB COMMAREA limit -- This article shows you how to use channels and containers in CICS, and includes step-by-step coding examples to use the ECIRequest class, together with CICS and Java client samples for use as a standalone Java client.
  
  
• Additional resources for this article
  • More information on Axis2
  • More information on Java
  • More information on OSGi
  • More information on Project Zero
  • More information on IBM Rational Application Developer
  • IBM Press book: Getting started with IBM WebSphere sMash
  
  
• WebSphere resources
  • developerWorks WebSphere developer resources
    Technical information and resources for developers who use WebSphere products. developerWorks WebSphere provides product downloads, how-to information, support resources, and a free technical library of more than 2000 technical articles, tutorials, best practices, IBM Redbooks, and online product manuals.
  • developerWorks WebSphere application integration developer resources
    How-to articles, downloads, tutorials, education, product info, and other resources to help you build WebSphere application integration and business integration solutions.
  • Most popular WebSphere trial downloads
    No-charge trial downloads for key WebSphere products.
  • WebSphere forums
    Product-specific forums where you can get answers to your technical questions and share your expertise with other WebSphere users.
  • WebSphere on-demand demos
    Download and watch these self-running demos, and learn how WebSphere products and technologies can help your company respond to the rapidly changing and increasingly complex business environment.
  • developerWorks WebSphere weekly newsletter
    The developerWorks newsletter gives you the latest articles and information only on those topics that interest you. In addition to WebSphere, you can select from Java, Linux, Open source, Rational, SOA, Web services, and other topics. Subscribe now and design your custom mailing.
  • WebSphere-related books from IBM Press
    Convenient online ordering through Barnes & Noble.
  • WebSphere-related events
    Conferences, trade shows, Webcasts, and other events around the world of interest to WebSphere developers.
  
  
• developerWorks resources
  • Trial downloads for IBM software products
    No-charge trial downloads for selected IBM® DB2®, Lotus®, Rational®, Tivoli®, and WebSphere® products.
  • developerWorks blogs
    Join a conversation with developerWorks users and authors, and IBM editors and developers.
  • developerWorks cloud computing resources
    Access the IBM or Amazon EC2 cloud, test an IBM cloud computing product in a sandbox, see demos of cloud computing products and services, read cloud articles, and access other cloud resources.
  • developerWorks tech briefings
    Free technical sessions by IBM experts to accelerate your learning curve and help you succeed in your most challenging software projects. Sessions range from one-hour virtual briefings to half-day and full-day live sessions in cities worldwide.
  • developerWorks podcasts
    Listen to interesting and offbeat interviews and discussions with software innovators.
  • developerWorks on Twitter
    Check out recent Twitter messages and URLs.
  • IBM Education Assistant
    A collection of multimedia educational modules that will help you better understand IBM software products and use them more effectively to meet your business requirements.
  
  

About the author

Dennis Weiand is a Client Technical Specialist for CICS, Web, and Java on the IBM Technical Sales team based in Dallas, TX. You can contact Dennis at dweiand@us.ibm.com.

Rate this article

Comments

Back to top

Table of contents

• Introduction
• CICS Transaction Gateway
• Passing Java objects from a CICS TG Java client to a CICS-based Java program
• Using the CCI in a CICS TG Java client program
• Using the DDW_CicsTg_ObjectTransporter with the Rational Application Developer wizards
• Performance
• Debugging object-passing issues
• Conclusion
• Download
• Resources
• About the author
• Comments

Next steps from IBM

• Try: Rational Application Developer for WebSphere Software
• Buy: Rational Application Developer for WebSphere Software

Dig deeper into WebSphere on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers