It is this shift more than anything which will sound the death knell for
the architecture Aaron proposes, where the server program dictates the
screens.
In the end the solution that provides the best long-term viability will
win. Long-term viability means ease of maintenance. We will come to find
in the years ahead that frameworks (i.e. Flex, Silverlight, JavaFX,
HTML/Javascript/CSS) will struggle to find where to place the median of onus
between the client and server. Putting the Controller on the client reeks
of thick client deployment issues, because you know that the Model will also
seep into there and the size of updates to download before you can run the
app will become much more than what shops desire.
Eventually (sooner rather than later), servers will know nothing about UI
whatsoever, and will become pure message-based services. This is the SOA
model, and is a rational evolution (no pun intended) of the client/server
design.
The following comment isn't in contrast to your statement, but more of an
addition based on my experience.
Loosely coupled SOA will be greatly overused in the coming 5 years. We will
see organizations lose native functionality because of the inability to
choose a platform/language for longterm. For example, some might think it's
a good idea to put wrappers around ALL DB2 data access from RPG because some
day you *might* want to switch data bases. Why would you ever want to
switch out DB2 with MySQL for the majority of DB access? Instead patterns
should be observed and THEN implement exception programming to facilitate
loosly coupled SOA to meet that specific need. Note in loosely coupled SOA
you lose a lot of native functionality (in this case the ability to use
CHAIN/READ/READE/etc).
On the flip side, "tightly coupled SOA" is a great thing more times than
not. You could consider "tightly coupled SOA" similar to still creating a
separation of concern, but utilizing native functionality to the greatest
extent possible. For example, extensively use modular *SRVPGM's and use all
of the features of sub-procedure parameter lists. This rears it's ugly head
if you have ever tried to use an existing RPG sub proc from JT400 or SQL.
If your sub procs relied heavily on being called from JT400 or SQL then you
would want to make sure you adhered to their parm passing limitations, but
if the majority of the calls are NOT from those mediums then it benefits you
to use tightly coupled SOA and gain from RPG's very nice features.
Obviously the same things could apply to any language and platform trying to
generisize everything (boiling the ocean) vs. doing exception programming
through wrappers to offer SOA to other machines/platforms/languages.
Again, just based on my trials of trying things out that I thought were
great ideas at the time but ended up not providing the benefit I had hoped.
Aaron Bartell
http://mowyourlawn.com
midrange.com
