Re: Socket vs. Dataq (was: RPG, Java and Classpath practices)

There is, of course, another alternative:

Write the data out to an xml streamfile and have the java app poll the directory for new files.

The advantages are:

1) The xml file is structured and easily human-readable.
2) If the java app is not running you can see the files not yet processed. You can deliberately halt the java app, and the files will just pile up.
3) The directory can be local or remote. Also, your java app can be anywhere on your network.
4) If a failure occurs in your java app and the xml is moved your "errors" directory you can drag-n-drop the xml back into the active directory once all is working again. Try doing that easily using a direct socket call - where do you put the data when a failure occurs? Try re-filling your DTAQ as easily as moving your files from one directory to another.
5) You data is extensible - no DTAQ size restrictions, or byte[] with predefined sizes in your java.

The beauty of using xml streamfiles is also borne out when you see the abundant tools out there to work with them. It is the pre-eminant data container.

The beauty of using streamfiles and polling directories is the fact that each document is considered a unit-of-work and the directory it resides in determines the work to be done. The sockets/communications side of things is controlled by the APIs used to read/write move/delete the files. They are provided by the implementation and you don't need to worry about it (beyond the normal housekeeping a good application designer should always have).

Just a thought.

Cheers

Larry Ducie

_________________________________________________________________
Be part of history. Take part in Australia's first e-mail archive with Email Australia.
http://emailaustralia.ninemsn.com.au