Leverage legacy systems with a blend of XML, XSL, and Java
No matter which way you try it, interfacing a mainframe from an application server or servlet is never fun. Among other hurdles to overcome, the mainframe could exist on a different platform or use a different character set. Think you can simply access the data directly and rebuild your business logic? Perhaps, if your database is not hierarchical and you enjoy reinventing the wheel. However, a few tricks using XML, XSL, and Java can make it easier than you think.
XML describes the structure of the data you are sending. Add XSL to complete some simple transformations. Use Java to encapsulate it with a few simple classes. You will then leverage a host of legacy system transactions written decades ago and format them into an XML document. Once your data is in an XML format, manipulating it becomes a much less daunting task, and development becomes easier. In addition, the solution you employ is realtime, which circumvents the frustrations and problems that arise from working with an extract file or batch interface.
The versatile XML
While many may only think of XML in terms of marking up structured documents, you can use XML to describe anything that has a particular structure. For the purposes of this article, we shall assume that our legacy system stores data in a hierarchical database that may be accessed through COBOL programs residing on the system. Why not access the database directly to retrieve the information? While the hierarchical database offers some advantages for the mainframe system, directly accessing it requires extensive knowledge of the database. Usually, the underlying database features significant complexity, which makes traversing it exceedingly difficult, if not downright impossible. Since the COBOL programs are already available for that purpose, there remains no reason to undertake such a complicated task.
You must know the structure of the transaction you will interface in order to invoke the COBOL program. To obtain that knowledge, refer to the program copybook, which contains the directions for use. Those directions include information about the length of the field, name, left or right justification, etc. Think of those descriptors as a set of fields that are described by attributes. Those descriptors provide directions on how to format the request and how to parse the returning data from the subsequent call.
Using XML, you can now implement that copybook metadata to generate your copybook markup language.
Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world
Brian Proffitt
Microsoft/Novell: Breaking Down the Coupon Numbers
Esther Schindler
Drupal's Dries Buytaert on Building the Next Drupal
Tom Henderson
Top Ten General Operating Systems Rants
pasmith
PS3 motion controller delayed; goes up against Project Natal
sjvn
Neolithic Windows security hole alive and well in Windows 7
claird
Perl source code comparison makes for good reading
mikelgan
Cell phones don't create stress or interrupt much
Sandra Henry-Stocker
How to: The Unix Interview
Where Google Chrome security fails: the password
I heard mention that the Chrome OS will have some sort of encryption available a la bitlocker. If it's possible to encrypt personal data using another password or key, then it may have potential for very secure data.... And Ubuntu has an 'encrypt home directory' option, perhaps google should follow suit.
- Dann
Join the conversation here
Quick, practical advice for IT pros. Made fresh daily.
- Ubuntu advances: Why Ubuntu server installations will surge in 2010
- Social media marketing: How to make friends with benefits
- More...
Want to cash in on your IT savvy? Send your tip to tips@itworld.com. If we post it, we'll send you a $25 Amazon e-gift card.






