Re: Web Services Adapter for 5250 Applications -- WEB400

Joe,

Thanks for the explanation of adapters for 5250 applications. You've obviously put more thought and work into this than I, so I'll defer to your expertise.

Regarding my comment about the Zend 5250 Bridge being unwieldy for developing web services adapters, that was just my first impression, and I should probably defer to Jon Paris or somebody from Zend, if they'd like to jump in. The thing that triggered my comment was the understanding that the Webfacing server doesn't know display file "field names", so the 5250 bridge generates names using sequential numbers based on field positions on the screen. If positions change sometime down the road, the developer would need to change the names in his PHP script. It seemed like an iterative, investigation process. Connect to the screen. Query the screen objects. Mentally map generated names to the names in the display file, and write code based on your investigation. And change your code when the screen changes.

Nathan M. Andelin

On Wed, Jul 2, 2008 at 7:14 AM, Joe Pluta wrote:

Nathan Andelin wrote:

Joe,

Let's see if I get the jist of this. To use 5250 applications under a Web services architecture you're suggesting a middleware "adapter" that bridges the differences between programs that control display file I/O and a Web services client?

Correct. The adapter will in effect encapsulate an interaction between a user and the software. You can think of it as a sophisticated keyboard macro.
I'm still pretty skeptical. It seems like the middleware adapter could get unwieldy.
It really depends on your software and your processes today. If the process to add an order is simple and streamlined, then the adapter will similarly be streamlined. If however your process requires accessing several programs and lots of screens, then the adapter will be similarly complex.

But it sounds like it may be worth comparing to Scott's suggestion to break out business logic in 5250 programs and turn them into callable procedures.

The point is that this provides an interim step. By using an adapter to convert the 5250-based process into a callable procedure, you have done the first half of what Scott suggested. The nice thing is that a lot of this part of the conversion can be automated, and the ROI is easily apparent because there are no fundamental changes to existing business logic.

Then you can pick and choose which business processes you want to really rewrite, and concentrate your resources on extracting the business logic from those. This is always the more time consuming part. By using this staged approach you can quickly put a new interface in front of your users, and then extract business logic as circumstances dictate.

IBM's IWS product is designed to interface with callable procedures. It generates PCML and WSDL interfaces between Java clients and ILE programs and procedures. Clients "call" procedures. I/O is handled via program parameters.

Since most 5250 programs aren't callable, this doesn't work very well.

IIRC, Zend 5250 bridge provides an interface between PHP scripts and the Webfacing server to enable PHP applications to talk to 5250 programs. It generates names for fields that map to display file fields, and enables PHP scripts to reference and update those fields. To me, that's unweildy.

Why?

Joe