Re: Impressions of EGL - Part Duex

Joe wrote:

But deploying desktop applications is a real problem.

I know, thats the main reason why businesses tend to migrate to web apps for their internal applications.

I think there is a place for both thick and thin (rich) client.

True, like with most technologies, the newer ones do not replace the older ones, but provide an alternative path. But one must always try to make the client as thin as possible, without compromising functionality and responsiveness. This means that for most business apps, thin clients will do (and i'm not talking about web apps only but also e.g. VB apps which just handle the UI). A graphical app for example which needs to communicate back many events like mouse movents a thick client would be more appropriate.

The only model that is going away is the green screen, and that's simply because it is needed less and less.

Of course, "green screen" is not a model, or architecture, it's just the way data is presented, and was never enhanced since the 70's. The reason the "i" is still popular, even with such an arcane UI, is evidence of the other qualities of the platform, stable and predictable, and businesses like that. With "arcane UI" i mean the presentation, not the underlying architecture.

Web applications are inherently more complex, but that's in a large part do to the fact that we still have to do most of the plumbing work.

Why should they be more complex? For a user they are not more complex (even simpler) than "traditional" client apps with a rich UI. Web apps are so complex to us, developers, because the underlying architecture (HTTP, HTML, etc) was not meant to be used as a rich app. Therefore there is so many plumbing to do (by hand or with a framework) to make things work. But the end result is not inherently more complex than "traditional" apps.

If you had to use the display station management APIs to write 5250 screens, you wouldn't find it very simple. It's the tooling, and the integration between display files and RPG that make it so easy.

The underlying architecture, APPN, LU6.2, 5250 protocol has been designed from the ground up to be used for applications that are built for it. The 5250 protocol is complex, no doubt, but this is due to all the functionality and complexities that are built in for a purpose (although a small subset is really used). I mean *functionaly* complex. See the many many DDS keywords, their combinations etc etc (of which i only use a subset like most a suppose). Writing directly to the 5250 stream is not comparable to writing directly to the standard output stream because its a byte oriented protocol not meant to be written with a normal editor or being read by human beings. HTTP/HTML is. The complexity with building web apps is due to the impedance mismatch between the server and the client. Every two weeks a new framework comes out to handle this mismatch (the plumbing). The last i believe is WEB4J which tries to keep things as simple as possible. The 5250 protocol was designed specifically to support business apps, with an API to access the underlying protocol. No need for frameworks and special tooling just to make simple things actually simple.

You can define a field in your JSF and access it directly from your EGL program. And if you then turn

around and call RPG business logic, I think it's still as robust. Only time will tell on that point, but nothing
I've seen leads me to believe it won't be. Remember, EGL/JSF is built on top of the very mature JSP
specification, which has been successful for some time.
Yes, true. Web apps are robust. Thats a direct result of the way they are deployed. The client has no state. Like with 5250 apps, where all state is also on the server (or host in this case).
Like i said, web apps have their place, but i think we're missing something, and IBM missed a great opportunity. It seems they are less and less making technology for "business", but go with the general flow. But making "business" machines is what made IBM the company they are. Like the bold and very succesful decision to build OS/360, an OS specifically for (large) business.

Date: Tue, 27 May 2008 07:58:46 -0500
From: joepluta@xxxxxxxxxxxxxxxxx
To: web400@xxxxxxxxxxxx
Subject: Re: [WEB400] Impressions of EGL - Part Duex

john e wrote:

But all this complexity just to replicate what we already have, with desktop apps, i.e. a "rich" user interface.

But deploying desktop applications is a real problem. Making sure
clients and servers are in sync is always an issue (although you get
around that to some degree with AJAX, where the server actually sends
the client to the browser).

Like i said, i find it interesting that the rest of the world uses the browser to solve the deployment problem. They already have "rich" apps, i.e. the traditional client server approach.

I think there is a place for both thick and thin (rich) client. The
only model that is going away is the green screen, and that's simply
because it is needed less and less. The idea of a heads-down data entry
clerk is disappearing. So we need a replacement, and the browser is a
good one, since it requires zero footprint.

But we are using EGL (or web apps in general) to solve a completely different
problem. We use it to easily build an "i" app with a modern user interface. And if we do, we loose those important features of our platform, simplicity, robustness and predictability.

As you point out, this is a bigger question than just EGL. Web
applications are inherently more complex, but that's in a large part do
to the fact that we still have to do most of the plumbing work. If you
had to use the display station management APIs to write 5250 screens,
you wouldn't find it very simple. It's the tooling, and the integration
between display files and RPG that make it so easy. If you define a
field in a display file, that field is available in your RPG program.

The same with EGL. You can define a field in your JSF and access it
directly from your EGL program. And if you then turn around and call
RPG business logic, I think it's still as robust. Only time will tell
on that point, but nothing I've seen leads me to believe it won't be.
Remember, EGL/JSF is built on top of the very mature JSP specification,
which has been successful for some time.

Joe
--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.

_________________________________________________________________
Check je Hotmail nu ook op je mobiel!
http://windowslivemobile.msn.com/BrowserServiceHotmail.aspx?lang=nl-nl