Web Services Adapter for 5250 Applications

Nathan Andelin wrote:

Scott Klement wrote:
The notion of making a 5250 program into a web service
is something I'm not familiar with, and definitely sounds
like a treacherous slope!

A treacherous slope? How about quicksand? May look solid at a cursory glance. Before you know it, you're up to your neck in goo.

It really depends on what your ultimate goals are. Many people have written about the various methods of application modernization, and each has its place. Replacing, refacing and rewriting are the big three. The pros and cons of replacing are pretty straightforward; if you can find an off-the-shelf package that meets your needs with no disruption to your core business, then it's a great solution, if not, you're in a world of hurt.

Refacing using a method like HATS or my PSC iQ product or your technique of converting DDS to HTML has its own niche. the common feature of all those approaches is that your application still follows the standard 5250 paradigm: "Here's a form, fill it in and return it to me and I'll send you the next one". That screen-at-a-time approach in which the host controls the sequence of screens is fine for a lot of applications, but in the web world there are many where it no longer fits.

5250 and Web-service sound like contradictory terms when used in the same sentence. One designed to respond to discrete requests such as converting degrees centigrade to fahrenheit; the other for controlling complex workflows.

This is where rewriting comes into play. You have to think a little outside the box on this. The ultimate goal of rewriting (the better term is probably "re-engineering") is to do exactly what you're talking about: change the focus from a server/client view where the host controls the screen and the user responds to forms to a client/server focus where the client makes a discrete request and the server process it, returning success or failure.

This only makes sense when the ultimate goal is to abstract the business rules out of your existing monolithic 5250 applications. The idea is to be able to eventually have servers that treat complex workflows like "add an order" as discrete requests. This is nothing new; this goes back to EDI and it's been something programmers have wanted ever since the second computer was switched on.

5250 display files traditionally contain 4 - 400 record formats and one 5250 program may call other 5250 programs in a chain of programs that open their own dislay files.

That's the challenge: to somehow extract the business rules out of a half dozen programs, each of which contains multiple screens. It's hard enough to do on a simple master file maintenance program, much less a complex order entry screen. The problem is that you have to spend a lot of resources re-engineering your programs just to separate interface code and business logic, not to mention testing the heck out of it, and at the end of the day, you have basically the same process. Yeah, that's fun to justify to upper management.

What is needed is a way to quickly create some return on the investment, thus providing impetus for doing more of the work. One way to do this is to encapsulate the work flow in a server. You can do this through the WebFacing APIs, you can do it through Zend Bridge (which is essentially the same thing, as I understand it), or you can use a technique like my product which replaces the 5250 I/O with a data queue. None of these techniques inherently provides any benefits, but they have the advantage of requiring little investment in resources.

5250 and Web services? We're talking about different paradigms. Unless of course, one considers HATS and Webfaced applications as "web services".

Suppose we take a product like Zend 5250 bridge. After a connection is established, 5250 screens are exposed as arrays of fields [including row & column numbers, data types, display attributes, and conditioning indicators]. How is that data useful except to emulate 5250 screens with a lot of extra overhead?

And this is where the value-add comes in: you script a typical workflow, such as adding an order. You define the *entire* message - all the data that goes into the order, all the data that comes out, including errors - and you create a document for each direction. A request, if you will, and a response. Then you design an adapter object which can take the request document and then walk through each of the screens in the workflow, plugging data elements from the document into the screens. It retrieves the responses and then creates a response document.

It is this adapter which can then be used as a temporary way to expose your business logic.

What is the benefit of all this? Well, the primary benefit is that you can do it relatively quickly, without minimal modification of your existing programs. More importantly, the basic architecture is *correct* - it's a move in the right direction to distributed computing. And you're not locked into any specific user interface - you can use JSP or JSF or Rich Client or even ASP.NET if you want to, because your business logic is no longer tied to the interface.

Yes you still have your bulky old monolithic programs. But that can be fixed now as time and circumstances dictate; you don't have to rewrite everything immediately. You may want to immediately rewrite your order entry process into true servers in order to provide performance and feature benefits, but you may never re-engineer your item master maintenance program.

The point is, that you have the option. By using this staged approach to re-engineering you can immediately provide a return on your investment that can be presented to management and at the same time buy yourself some breathing room to redesign the crucial parts of your system into true business logic servers.

Joe

P.S. That's my original vision from back in 2000, when I wrote the original E-Deployment book!