We need to get a diagram in place as that was a good explanation to give
understanding of what parts are involved and what can be ripped out and
replaced with something else (i.e. the Web Client) portion.
I did a project a few years ago that dynamically rendered a Java thick
client application based on an XML feed from an Apache server running
Perl. Once I have a fuller understanding of the JSON structures I could
morph that application to communicate with the Workstation Extender. Note
I am not saying that non-browser thick clients are the way to go, but the
thick client would only need to be installed once per machine (thinking
intranet) and that would be it. If nothing else it would be another way
to trigger other ideas and *maybe* be easily morphed into JavaFX.
Would that be worthwhile or a waste of time? I should be able to release
the code as open source because I would have to rewrite from the ground up
for the most part (many many proprietary API's were used to integrate with
hardware on the client side).
Aaron Bartell
http://mowyourlawn.com
Nathan Andelin wrote:
From: Pete Helgren
And to come full circle, if the 5250 data was in a standard format,
consumable by web client applications, then the two *would* converge.
There's just a lot of potential here. For emphasis, I'll again point out the salient architectural elements; starting with the Web client on the left:
Web Client <==> Workstation Extender <==> Virtual Terminal Interface <==> Workstation Application.
The simplicity, productivity, flexibility, efficiency, and congruity of the traditional Workstation Application (using display files) generated a lot of loyalty to the platform.
Niels new Virtual Terminal Interface is cool because it reduces unwieldy 5250 data streams to UI components that are easily referenced from the Workstation Extender. It offers a component view as opposed to a data stream view. I'm not aware of any other API that does that for RPG programmers.
The Workstation Extender is cool because it offers flexibility. Communicate with a browser, or with another type of Web client. Pass along the entire screen to the client, or part of it, in a simplified message format. Handle requests that the Workstation Application might not know how to handle. We're seeing a melding of two worlds.
Every component to the right of the Web Client, including the HTTP Server, runs natively under IBM i. The interfaces between them are efficient, using shared memory.
Good stuff.
Nathan.
midrange.com
