My take on this discussion is that there is no commercial
incentive for IBM or partners to introduce a "native" GUI.
Throw away the old 5250 datastream, but keep the underlying
architecture. I.e. programs "run" on the central host and use
terminals/devices for presentation. And of course, "modern"
presentations uses windowing and event-processing.
Client/Server is a mistake... for business applications.
For scientific apps with heavy processing / interactivity like
CAD etc client/server is scalable, but the "as/400" way is not.
X-Windows is very chatty (low level events / commands are send
over the networks) but is necessary to support all apps,
especially the graphically heavy apps.
For business apps, the kind of apps we in the as/400 community
have been building for ages, client/server is the wrong direction.
The reason the "old" but simple and straightforward host-based
architecture has been "thrown away" and replaced with client/server
and resulted in the mess we have today is only for historical
reasons, not because it works best for business apps. Same reason
we are stuck with Windoze. The complexity involved to build a
webapp (Javascript/CSS/HTML/HTTP etc) does not deliver any value,
except that we have a "web app".
The main reason we (the as/400 community) have to rewrite our apps
as "web apps" is to present a nice modern interface. This is the
only reason. We do not have scaling problems or other problems to
solve. The only problem we have to solve is that we dont want to
present a "green screen" to the user. For a user, the user
interface *is* the system.
The reason other developers build "web apps" is another one.
Not because it gives a modern user interface. We already had that
with desktop "traditional" client/server apps. But because of easy
deployment, especially in a business environment. In an as/400
environment we don't have this problem. We don't "deploy". We
simple run the program. Thanks to the platform, we also don't have
any scaling issues. Except when we're google or amazon. But most
of us aren't.
A client/server app is a distributed app. The app code is split
between server and client.
Rule 1 of distributed apps is: don't do it.
Rule 2 of distributed apps is: don't do it yet.
So, why do we need to completely revamp our apps just to present a
modern interface? There is no inherent technical reason. Why do we
need to completely rebuild our spaghetti apps? It's a good idea to
support MVC. But to support MVC one does not need to split the app
physically between client and server. Traditional green-screen apps
can also support MVC. For example a one-source RPG program with
separate procedures (or even subroutines) for the M, the V and the
C is "MVC". MVC is a about organizing your code so that responsibilities
are clearly defined. The benefit is maintenance, flexibility etc etc.
MVC is only the high-level view of the distribution of responsibilities.
But MVC, organizing your code into modules each having distinct and
clear responsibilities has nothing to do with GUI's, client / server
and the like. It's simply good software engineering. Not only on the
highest level but all levels and scales. E.g. within a single procedure
you could have different subroutines each having a well defined
responsibility (within the proc).
What we really need is a "native" (whatever that means) technology wich
takes the best of the as/400 world (simplicity, predictabilty, robustness,
etc) with the "client/server" world, i.e. a modern user interface.
I don't say client/server is bad perse. Being able to run part of an app
on a remote PC (i.e. locally where the user resides) is a good idea. But
only if it has a real advantage. Of not, then it should not be done
because it adds a lot to complexity without any return. Be default, the
app should run as a whole in one environment which should be as simple,
scalable etc as possible. We have that on the as/400. Only, the user
interface did not evolve beyond the '70s of the previous century.
X-Windows is not scalable (and quite complex) but this has reasons because
it evolved from the scientific/technical world. For business apps it should
be certainly possible to build something like thus but is also scalable.
For a business apps you really don't need to send each mouse event over
the line. The user interface could be "block-oriented". Where mouse clicks
etc are handled locally on the PC (client).
Point is, IBM and others dont have a commercial reason to bring a user
interface for which a complete rebuild is not necessary. They want to
provide the "services" (now or later) to help rebuild all green screen
apps into a client/server solution. A company like ASNA invests heavily
in this market, with complete development tools and accompanying services
to modernize a greenscreen app. Or, actually, simply to solve the "green
screen problem".
By providing a simple (aka "native") technique to provide a modern user
interface which does not demand a client/server architecture (i.e. in
theory you could simply replace a EXFMT into someyhing else) ASNA or IBM
or any other company would destroy the modernization industry. This is a
real industry which has a big potential. IBM tries to keep as/400 customers
happy because they want a piece of this big cake. Because, sooner or later,
each green screen program has to be modernized because users want it. And
modernizing apparantly means completely rebuilding it because we are
"supposed" to use client/server which requires a rebuild. There simply is
no ready-to-use technique to do this without "client/server".
IBM has completely lost the "M" and, unfortunately, the "B". To provide
value to business with a system that has the lowest TCO.
I can't blame IBM. Services is where the money is. Instead of giving a
completely packaged solution with low TCO (as/400) they invent SOA together
with M$ which is too complex to grasp for the average developer.... services!
What problem does SOA try to solve? I leave that question for you to answer.
Hopefully the tide will turn. And people realize that building client/server
business apps does not solve a problem in a business environment. In most
cases it only creates problems. Running app code locally can have advantages
but only there where this advantage is bigger that the disadvantage of having
more complexity and less robustness. In most business cases simply developing,
deploying and running an app completely on the single host works fine (the
as/400 is proof of that). The only problem client/server solves for us as/400
devs is that this way we can present a modern userinterface and still say
it's backed by the as/400. But 80% of the time/code is on the client. The
server (as/400) is then marginalized. Yes its much better than Unix but still,
unix is a commodity, everyone knows unix, it's not "strange". Having to
maintain specific knowlegde just for that 20% of the time spent on the server
does not add value. So the as/400 server will then be repaced in time with a
commodity box.
From: Jon.Paris@xxxxxxxxxxxxxx
To: midrange-l@xxxxxxxxxxxx
Subject: Re: what was the single mgmt decision made in mid-1990s. period
Date: Tue, 17 Feb 2009 22:10:01 -0500
On 17-Feb-09, at 9:29 PM, midrange-l-request@xxxxxxxxxxxx wrote:
but it seems to
me that updating RPG and not providing a GUI was putting the cart
before the
horse. IBM got that wrong. Of course I am speaking with the benefit of
hindsight.
You bet it's hindsight. RPG IV was introduced what - some 13+ years
ago. The development cycle was at least 3 years (I don't recall
now). The GUI options at the time would have been an X-term type
interface or slaved PCs in client/server mode - neither of which were
under serious consideration in Rochester. Things like the browser
that we think of today when we say GUI weren't really out there at the
time.
The timing of RPG IV was in many ways unfortunate - if we'd started it
some three years later it might have been very different.
Jon Paris
www.Partner400.com
www.SystemiDeveloper.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
_________________________________________________________________
Jouw nieuws en entertainment, vind je op MSN.nl!
http://nl.msn.com/
midrange.com
