Meaningless Drivel is fun!
The moose likes EJB and other Java EE Technologies and the fly likes Messaging Newbie!! Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Head First Android this week in the Android forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Messaging Newbie!!" Watch "Messaging Newbie!!" New topic

Messaging Newbie!!

Romario Dominic

Joined: Feb 27, 2006
Posts: 26
I am not sure as how one could connect a J2EE application to a legacy system-eg DB2.What I mean to ask is what are the requisites that go into the connection.I am aware that there is the Connector which is akin to the JDBC driver for databases.Other than that do we need anything else?For eg inorder to retrieve or Update data from a DB2 database we have a JDBC driver which will do the job.Why do we need messaging?These questions may be pretty basic to a lot of you folks I guess.

Emanuel Kadziela
Ranch Hand

Joined: Mar 24, 2005
Posts: 187
First of all, you have to decide what your j2ee application is going to do. If you need persistance, you need some sort of database connectivity (JDBC, ORM, or whatever else have you). You can achieve that through connection managers, datasources, etc. If you need messaging, you will need message beans. If you need to persist you messages, queues, etc. you will need both.
You can run a j2ee application using legacy databases, systems, etc. as long as you can connect or interface with them somehow. DB2 has jdbc drivers which do the job quite nicely. Whatever else you need done you just have to see if the systems have supporting interfaces, plugins, etc.
Roger Chung-Wee
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
Briefly, you create a connection pool in your EJB server to connect to your DB2 DB. The vendor supplies documentation on drivers. You then create a data source which must be accociated with the connection pool.

The developer simply has to look up the data source from the server's JNDI tree and obtain a connection from the pool.

SCJP 1.4, SCWCD 1.3, SCBCD 1.3
Romario Dominic

Joined: Feb 27, 2006
Posts: 26
Thanks folks for the reply.But suppose I need to connect to the CICs part of the legacy system then JDBC connectivity is not the solution right?In ths case I probably need Messaging.

M Anderson

Joined: Mar 17, 2006
Posts: 25
I've been faced with the problem myself. The solution we chose is IBM's MQ Series (a.k.a., Websphere MQ). It's a bit of a different programming paradigm from just straight JDBC programming, but it's not so bad once you get used to it.

We talked to a mainframe that used whatever (maybe even VSAM, not sure...) to store data. On the mainframe side, there ran a COBOL program that monitored the queues and fired responses back to us. The application is a web app that needs access to the mainframe data. We used a stateless session bean to mediate requests from the end user to the mainframe and an MDB to monitor the response queue and update the little Oracle database table on the 'web' side. Thus, when the user returned to the website later to see the status of their transaction, the website would be updated with whatever happened on the mainframe. Overwall, we were pleased with IBM's implementation of JMS and using MDB's made things simple.

Let me know if that's enough info for you to get you started in the right direction, at least. Although, since there is a CICS interface, you might be able to write something your self to use that interface programmatically, but I'd think a messaging solution would be cleaner and more scalable.

Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Google for "Java CICS connectivity." There are many options: message queuing, ECI external call interface, run a Linux partition on the mainframe (way cool), DB2 connect, screen scraping (yuck), a number of proprietary 3rd party tools and many more. Years ago I used Remote CICS, APPC and LU6.2 protocols, too. If your company has a support relationship with IBM ask for help with the pros & cons of all these things. Attachmate is another vendor with several options.

My company has had great success with MQ. It's generally recommended for async fire-and-forget messaging rather than synchronous, but we get fabulous response time when we wait for a reply message. I've always had help marshalling and unmarshalling messages thru meta-data or generated code. That bit might be a bit o work.

A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
I agree. Here's the link:
subject: Messaging Newbie!!
It's not a secret anymore!