Problem solve Get help with specific problems with your technologies, process and projects.

Invoking EJB

We are currently investigating connectivity to and from a CICS v2.2 system running COBOL applications to a WebSphere application server. We have requirements for real-time queries and updates from the CICS application to an external J2EE application on WebSphere and vice versa. We do not think that MQ will be a good fit because of the real-time requirements.

One way that we thought of was to call a CICS EJB from the COBOL application and for the EJB to be accessible from the WebSphere application as well, hence fulfilling the two-way synchronous comms requirement. Do you think this approach is feasible?

If I understand correctly, you want to run some sort of work within WebSphere and that this work will be initiated either locally from within WebSphere but also from within CICS. The idea of using an EJB to get the work done in WebSphere arises because this can be called from both within WebSphere and from CICS -- so making the place from which this function is demanded transparent to where it runs.

This arrangement is certainly doable. I'd guess a StateLess Session Bean to be the desired design pattern for the EJB.

I should own up that I am by no means a WebSphere expert and you should run these comments past someone who knows about this area.

However, I know that WebSphere V5 supports EJB 2.0 whereas CICS supports EJB 1.1. This means that the EJB you use within WebSphere and invoke from CICS has to be written to the lower EJB 1.1 specification (no things like extended home methods or a local interface for the EJB methods) so that it can be invoked from both places.

As far as the CICS side of things are concerned, you will have to write a Java program (one that starts with a main() method) that invokes the EJB which resides inside of WebSphere. You then XC LINK to this with a Commarea to pass the parms with which to invoke the EJB.

You should also be aware that there is a UnitOfWork Boundary between the Cobol Application and the EJB executing within WebSphere. This may have transactional implications.

The invocation of this EJB would usually be coded to lookup the address of the WebSphere server using an external JNDI/LDAP database. However, if you always know where the WebSphere is located AND you don't want to worry about portability, etc. you can merely populate the relevant objects directly within the Java Wrapper program and get better performance.

When you execute this EJB directly from within WebSphere, then my comments are more unsure. I expect that as you are totally within the Java environment, the Java Transaction (in the sense of a CICS UnitOfWork) can extend over the invoking Java item into the EJB instance (according to the various deployment descriptors). This may of may not have implications for the EJB - it depends on how you want to cope with rollback situations. One thing is sure, that executing from CICS will use two UoWs whilst from within WebSphere either 1 or 2.

I cannot comment on the way one deploys this EJB into WebSphere or how one invokes it locally within WebSphere but as you are coding to the EJB 1.1 level then local interfaces are out and so you are always using remote interfaces. I suspect that one could arrange things so that remote interfaces are executed from CICS and locals from within WebSphere but I don't know if that arrangement, thus using EJB 2.0, would stop the remote interface from being accessible from CICS via EJB 1.1 protocols.

Robert Harris
CICS Technical Strategist -- CICS expert at Search390.com

Editor's note: Do you agree with this expert's response? If you have more to share, post it in one of our .VO7aaqqaAFk.0@/search390>discussion forums.

Dig Deeper on IBM system z and mainframe systems

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.