On 4/11/2019 12:01 PM, Nathan Andelin wrote:
I'd like to request further clarification on one of your OA assertions,
which for me is like returning to a mine field, given some of the heavy
hitters who have been following this discussion.
6. From what I've seen, OA is a true hybrid. Since it acts as a
I'm not an OA expert; "From what I've seen" is meant to convey that.
:) But OA is a pretty straightforward premise, and what I do know
doesn't stray far from the concept - pass 5250 opcodes to the mediator
and return responses.
From my perspective OA replaces IBM i workstation data management with an
OA handler, replaces the 5250 data stream with JSON or XML or something
comparable, replaces DDS display files with JSON or XML or comparable
syntax, replaces the 5250 emulator with a JavaScript applet (for lack of a
better word).
<snip>
In your earlier writing you liked to distinguish between "server-client"
which was your label applied to IBM's workstation data management vs.
"client-server" which was applied to "newer architecture".
Given my observations about OA architecture and implementations (1-5, etc.)
How is that incrementally moving toward a newer architecture?
The issue is that refacing tools such as mine or HATS or most others
rely on the EXFMT being translated directly to a write to the browser
and a wait on a POST operation. OA gives you the ability to refactor
that. It's not a simple process, and it usually requires specific
knowledge of the application, but it can be done.
One example: you can without too much difficulty repurpose a customer
maintenance program with as a customer update web service. This
requires an initiator and a adapter. The initiator receives the update
request from the web service, makes the parameters accessible within the
job, and the calls the OA enabled adapter. The OA adapter then begins
processing requests, such as an initial screen where you enter the
customer number. The adapter grabs the customer number from the global
data and returns it with an enter key. The customer master program
continues on doing EXFMTs for the various panels, while the adapter
plugs in web request data.
You get the picture. The OA adapter acts as a conversational interface,
changing the aspect of the interaction. Once that's in place, you can
encapsulate the business logic at your leisure, eventually replacing the
web service OA adapter with a direct call to the business logic and also
changing the 5250 code to call the same encapsulated logic.
It's NOT simple by any means, but it's possible. It's even possible
with some of the more sophisticated third-party scrapers but that
entails writing the adapter logic in some third party syntax, whereas
with OA you can use ILE RPG (or whatever your language of choice may be).
And once again, let me be clear: I'm not an OA expert or advocate. It's
just that there are really only so many ways to solve a given class of
programming problem. This particular class is the one I'm most
intimately acquainted with (along with mechanical source code
manipulation) so I'm able to provide general insights.
midrange.com
