CICS to EJB

This page is a guide to those of you out there who are familiar with "Traditional" Transaction Processing Monitor (TPM) and are now confronted with the need to deal with Enterprise Java Beans (EJB). It was first written at the turn of the century and then abandoned. Rediscovered, it has had its broken links and the obvious mistakes fixed and has now been published on the main web-site.

Before you start, you had best know that this page contains CICS-isms as examples of traditional TPM thinking. This page will be translated into Tuxedo-isms too, best if you are more familiar with BEA Systems products or the OSI terminology in general, shortly.

If you are reading this page it's likely that you are an old COBOL, PL/1 (or even C) hack from a "traditional" TPM background, like Mr. OLTP, it has to be added. So with all this EJB-ing going on all around you, you ask how can you program stuff you are familiar with with your new-found Java skills. We'll assume you've gone through a How to program in Java in 21 days for the very Stupid with a CD type book or have even been on a course.

SUN seem to have tried to cover every eventuality in their definition for EJB. This means that the specification has a number of transactional models and a number of database access methods. Much, by analogy and feel seems the same however ...

In the narrative we'll make the assumptions that the following hold true, or at least you as a CICS person believe it them to be (see the Addendum if any of these terms are unfamiliar).

• The best kind of Transaction Programs are non-Conversational.

• ECI is better than EPI, The folk who write clients should write EPI, and none of the Transaction Programs expect to manipulate masks.

• The DTP model is good and wholesome.

• It is good to split things up using AOR and TOR.

• Client state should be maintained at the Backend, if the data is high value, in recoverable storage.

• That the Business Logic, that's the Transaction Program should be as close to the Database as Possible.

One would hope that the above list reflects modern CICS thinking, but it is to be expected that there will be dissident voices. Taking each of these points in turn and discussing them in an EJB context:

Non-Conversational

Long gone are the days when one would write CICS Transaction Programs that manipulated masks, although one still has to deal with them. Modern thinking tends to surround a central Transaction Program with more colourful and adaptable technologies than the venerable 3270 terminal. These talk with the Transaction Program through the CICS client suite, using the Extended Programming Interface (EPI) leaving presentation worries to whatever Graphical User Interface Builder you have chosen (for example, Microsoft's Visual C++). In this system, state is not maintained with the Transaction Program, which is called, does its work and returns information to the client. The client maintains a degree of state and calls a series of Transaction Programs in turn.

The analogous EJB to that kind of Transaction Program that would be employed in such a role would be a Stateless Session Bean.

Conversational

EJBs cannot manipulate screens themselves like CICS Transaction Programs but there is the infamous "Shopping Trolley" example that pops up now and again which specifically uses Stateful Session Beans. Here the concept of state is introduced at the backend so think Conversational Transaction. A Transaction Program like this would use SEND MAP and RECEIVE MAP, interspersed with the appropriate calls to other Transaction Programs, probably via Distributed Program Link (ie the LINK PROGRAM call.

Just as the Conversational Transaction Program is considered deprecated in modern CICS systems because of the costs incurred in operating with it we believe that statefulness in EJB should be too.

Data Access and Beans

Data access in CICS programs is via a data-manipulation language. In EJB Data access is supposed to occur within Entity beans which are recoverable stateful efforts. There are two types to these Entity beans, ones where you've got to do fetch the data yourself using a data-manipulation language and ones where the data is presented just as you saved it, using the concept of persistent objects.

Unless there's a pressing need for something else, most folk will be using a Relational database (all be it with some objective extensions). The persistent data model, while attractive either enforces an object oriented database or some generated-on-the-fly, very ugly, poorly performing data-manipulation code using a more conventional database system. For most of the TP projects that we've been involved in there's been no need for such abstractions, indeed, while an old idea, Relational databases have a number of advantages in flexibility if not speed over Object Oriented databases.

Object persistence has been around almost as long as Relational databases and although each new generation finds it a powerful and interesting metaphor, its use is limited in commercial systems. So why go for all the complication of Entity beans? The answer is that we can see little advantage in them, easiest to access your data with a data-manipulation language from the recommended Stateless Session Beans.

We've used the term "data-manipulation" language a little coyly there. There seems to be no end of drum banging in the EJB front that would lead some to believe that one may manipulate data (if not with Persistence) then with dynamic SQL, all of which must please Larry Ellison and hardware sales teams the planet over, if nobody else. There are occasions, however, when a more lightweight solution would be advisable. The CICS programmer would reach for Temporary Data queues. These things are provided by CICS, they are lighter than going to a standard database in SQL. They need not be recoverable either, so they do not need to participate in or have the overhead of a Logical Unit of Work (LUW). There are a variety of these beasts in CICS but typically you would use: WRITEQ TS with ITEM set.

Our examination of the literature on the web would suggest that the Java wrapper to the Berkeley DB package (as supplied by Sleepy Cat) would be the first best fit, with LegacyJ's wrapper to ISAM being a possibility (although the latter is aimed at incorporating existing ISAM databases into EJB). It should be noted that if either of these choices are made then the system you build is immediately outside the EJB specification, which basically says there shall be naught but JDBC. There is, however, a relatively recent API which does allows this sort of thing, but only connected through Java Connection Architecture (JCA). At time of writing (late 2001) neither of these products conformed to this.

Shopping Trollies

Much is made of shopping trollies and the like, they seem to be the main reason why Stateful Session beans exist. It is implied that the customer's purchases would 'reside' in a Stateful Session bean, which would allow purchase to accumulate against a customer session. There would this be no need to keep this on the client side. This appears to the old CICS programmer as a Conversational Transaction and we've briefly discuss this above. A Conversational Transaction is a Transaction Program that is run on a per session basis that accumulates a customers purchases (if you will). This has found to be a resource-hog in CICS systems and mitigation (called a Pseudo-Conversational Transaction) was introduced, allowing the chaining of separate Transaction Programs together to mimic the a Conversational Transaction without quite such drastic overheads. Further carrying state over several invocations makes things very messy if you (or more probably the Container or TPM) attempts to scale by load balancing.

The more modern practice is to use a series of non-Conversational Transaction Programs (invoked through EPI), coordinating on a some temporary storage solution kept at the backend. The client maintains state by a token passed to and forward. Since these entities are stateless work can be distributed easily across a large number of instances, where these instances do not need to share the same CPU or even computer.

This mechanism can be be translated into EJB, by allowing only Stateless Session beans, and keeping a client's shopping trolley as data keyed by a token that is either a customer or session identity. This shopping trolley is stored on the backend, either in the primary SQL driven database or in some more lightweight solution (according to taste and the nature and cost of the goods involved). This customer or session ID can be identified by a token held in some manner on the front end either as a Cookie, or, since some of us are rejecting cookies as a privacy intrusion, as a Hidden Data in a Hidden HTML, the lowest common denominator in such instances.

Money or Double

Java was originally designed as a programming language for mobile agents. Later it was re-targeted at the client side of client-server interactions and now it's the server side. COBOL has traditionally been the language of choice for such server side systems and as such has outlived the more scientific FORTRAN, conceived at the same time. COBOL, and the `B' in its name stands for "Business", has a number of features which are designed to allow it to easily be used when manipulating monetary amounts such as one might find in modern e-commerce. While similar criticism can be levelled at C and latterly C++, Java neither provides a fundamental data-type nor a Foundation Class for manipulating money. The closest fit that it comes up with is BigDecimal that some folk recommend. This to us seems a bit of omission in what is widely touted as the new business language.

Happily a number of folk are publishing a Money Class, and it is recommend that one of them or at least BigDecimal be used. Better that than, for example, double which a number of, no, a large number, no, nearly all the EJB examples (including the famous Pet Shop) seem to think is a good fit. The one caveate to this advice that one can think of is that where as int (and indeed double) is a primitive data the recommendations are all Classes, they therefore incur appreciable overheads in construction and garbage-collection. So be aware of this should your application involves large to huge arrays of putative Money type things.

As a young man Mr. OLTP was told that "MONEY isn't REAL". You'll need to be an old FORTRAN programmer to understand that "in" joke too.

MOVE CUSTOMER-DETAIL TO OUT-REC

Much of the Business Logic of Transaction Programs in CICS is occupied with moving lumps of data from one place to another, just as much as performing simple calculations with Money and so forth. Java classes have acquired in recent releases System.arraycopy and you want to use this rather than a first-principles for loop for performance reasons (you get a bounds-checking overhead every time through the loop).

If anybody out there thinks that COBOL's

      MOVE SPACES TO OUT-REC.

was a bit of a bogosity they should consult Linden's FAQ (now sadly missing from the web) on Java array setting for why the equivalent in Java is:

public static void spacefill (byte[] array) {

    int len = array.length;

    if (len > 0)
        array[0] = (byte) ' ';

    for (int i = 1; i < len; i += i)
        System.arraycopy (array, 0, array, i,
             ((len - i) < i) ? (len - i) : i);
}

EJB vs CICS Naming

A surprise to most of the CICS programmers that come to EJB is the rather complicated method for finding remote methods and then calling them.

    ...
    try { 
        Context ic = new InitialContext ();

        Object o = ic.lookup ("FooBar");
        FooBarHome home = (FooBarHome) 
            PortableRemoteObject.narrow (o, FooBarHome.class);

        FooBar fb = home.create ();
        fb.doFooBar ();

    } catch (Exception e)
    ...

As such there's no such equivalent on CICS. One simply calls the Transaction Program that we're interested in and CICS figures out where it is.

      EXEC CICS LINK PROGRAM FOOBAR END-EXEC.

CICS can do this, or it can be said, was designed this way, because the name-space for CICS, and indeed TPM generally, is very small. This means name clashes are very rare, easily resolved and name-to-address resolution can be accomplished with relatively simple configuration file type mechanisms. Further down the protocol stack, VTAM can be relied upon for murky magic.

The complicated nature of naming in EJB owes much to the desire to make the Common Object Request Broker Architecture (CORBA) naming as general as possible. EJB follows CORBA naming practices because CORBA's the Internet Inter-ORB Protocol (IIOP) is used between EJBs. With the experience of CICS behind us and EJBs use as building blocks in a new Transactional frameworks this looks all over engineered and over-done. Unfortunately there is little that can be done about this bar using a template mechanism, as found in some Integrated Development Environments to generate the necessary code for you.

Summary and Recommendations

• Only use stateless session beans.
• Avoid heavy use of JDBC, use lighter storage methods as necessary.
• Keep state at the backend. Synchronise at the front end via lowest common denominator (cookies, hidden form-fields).
• Don't follow examples blindly.
• Find and use a Money class, or at least use the BigDecimal class.

Further Information

IBM have published a so called "SupportPac" which is a document with somewhat similar goals to this one. Entitled An Introduction to Enterprise JavaBeans for CICS System Programmers (now withdrawn from the web) it's written by Robert Harris who is senior in the CICS hiarchy at Hursley. As one can expect it is a good deal more detailed than this humble page and specifically address issues associated with running EJB in the later and latest CICS, which can function as an EJB container.

Addendum - CICS Terms

Some CICS Terms have been used which may be unfamiliar to the casual user:

TOR

Terminal Owning Region - A CICS address space (a "Region") which primarily concerns itself with managing client connections.

AOR

Application Owning Region - A CICS address space (a "Region") which primarily concerns itself with running the business logic. Together with TOR (above) this is known as Multi-Region Operation (MRO) and is common in large CICS installations.

ECI

External Client Interface - A CICS Client API so Client Programs look like a 3270 block-mode terminal and associated human.

EPI

External Program Interface - A CICS Client API so Client Programs look like other CICS Transaction Programs involved in Distributed Transaction Processing (DTP).

~Z~

Navigation

This is some navigation, it should appear at the side if the page is wide, and at the bottom if it is not.

Search

Seek enlightenment and wisdom: 

Example: "tuxedo".

Highlights

This site is mainly about On-Line Transaction Processing (OLTP). We've some other papers on this:

• Something for non-cognoscente.
• The executive summary.
• OLTP and big computers.
• OLTP and reliability.
• What Transactions are about.
• The need for scaling.
• Tuxedo.
• CICS.

Also of Interest

Juicy morsels from the rest of the site:

• Some site news; it's a sort of infrequently updated journal for the author too.
• Rather specific Technical Notes, the author can still bore people in the Historic Third-person.
• Of the little hacks that have been done recently, the Unofficial Jobcentre Plus Mirror seems to have gained the most traction.
• Other ephemeral, eclectic stuff. Mostly photographs.
• A series of Gormless Anecdotes, basically recycled e-mails.

About the Author

His name is Martin Sullivan. He's a fifty-something some-time computer programmer living in the quaintly named town of Cockermouth in north-west England.

The Company

ZOIS Limited is basically a vehicle for Martin and his OLTP work, he owns it. You can find out more about it elsewhere on the main site.

Pro-Bono Plug

Martin is currently on a health sabbatical, but is interested in the odd bit of pro-bono work by the way of therapeutic recovery. So, if you've anything that he can tackle on a non-commercial basis from his base in Cockermouth please let him know. Unsurprisingly, he's particularly interest in biology, again, and the application of computing to it.