1st) I think most folks have seen Microsoft Outlook's thick and thin
client that communicates with the server. Assuming you are using the
MS IE browser there is only one vendor involved.
Point: with endless resources and years of tuning the web interface
pales in functionality, usability and speed/efficiency compared to the
windows native interface.
2nd) I do not understand the argument and conviction that all mission
critical iSeries apps should be web based? "you" must be using a
different Internet than what I see. Even if all business objects are
on the server side instead of Javascript complexities and your pages
are flawless, you will need about 10 web pages to replace a complex
5250 screen.
10 * 3 seconds = 30 seconds + validation and population I/O's. The
stateless programming paradigm is radically different than the windows
event driven model.
A web driven application is slower any way you slice it - and these
are under the best circumstances. The gmail interface I am using now
is deficient compared to native WIN of 10 years ago.
on the other hand - WEB has a zero deployment and I can save a draft
and finish in the kiosk at the airport.
Point: each deployment has it's place. Not everyone can seriously
consider "web deployment" as a viable target platform.
3rd) I doubt you will see anything here:
http://www-03.ibm.com/systems/i/roadmap/
that says: To preserve sanity, all green screens are being replaced by
browser based screen methodologies.
Point: I would start with the roadmap and consider all vendors that
fit your business requirements. There are solutions that you will not
outgrow that help us make our companies more competitive. Just
yesterday, it took 4 people at three different workstations and about
25 minutes of my time to change my air ticket and actually assign a
seat. I kept hearing them talk about codes like "2J" and "all 15 codes
must match" before you hit enter. This is pathetic and the opposite of
what we all want the customer to experience.
4th) I hope that we qualify some of our "excellent experiences" with
the fact that target code generation is within the confines of an
optimized tool set or paradigm. In other words, some tools are
designed for a limited set of OPTIMIZED solutions - and that is OK.
But it is not for everyone and a subset of where we should be going.
If I understand the proponents of the C# flavor, it sounds a lot like
you are shifting the business logic to the client. It belongs on the
server.
Point: how many skill sets are needed to rebuild your mission critical
applications.
5th) although I (and many) can list many more top 10 reasons to do
this or that. We could (with a little effort) reach a consensus that a
WYSIWYG just in time deployment of Windows or Linux native
applications that fit with the "state of the platform art" and all of
our business rules, logic, triggers, etc are on the server(s) might be
the best replacement method for the 5250 screen. Living with what is
practical is what we do.
Point: This is why deploying windows native is still a valid choice
for internal users. Those that seek out just-in-time deployment
services spend fewer Saturdays at work.
---End
midrange.com
