I ran across the following, Dave. It may give you some ideas:
http://www.mrc-productivity.com/blog/2011/01/mobile-applications-why-architecture-matters/#more-1399
-Nathan
----- Original Message ----
From: BT Consulting <btconsulting@xxxxxxxxxxxxx>
To: web400@xxxxxxxxxxxx
Sent: Mon, January 24, 2011 9:15:20 PM
Subject: [WEB400] Accessing the iSeries from web/mobile devices; which
methodology/tools?
Gang,
In my search to find best methodology/tools for developing
web/mobile device accessing the iSeries (perhaps later to MVS and VM),
I've run across (of course) several methodology/tool camps and I'd
like your thoughts on which ones work and why, good news/bad news, etc.
In my search for a server-side (as much as possible) development methodology
for web/mobile device access to iSeries and maybe MVS and VM, I've run
across some competing methodologies, of course. One camp says use an
HTTP Server approach (doesn't that put an extra path/thread/stuff in the
access path to running programs and accessing data?), one says access directly
via JTOpen (using JDBC) or the like and there appear to be more. In addition,
some tend to prefer to run their code mostly on the client/web app (seems like a
slow
way to go) and some like to put as much code as possible on the iSeries box
(seems like using a bigger engine would be better, not to mention letting the
RDBMS do as much data access work as possible). Some, of course, like to do
their development using proprietary and often costly development tools and
others the "Open" route.
I'd like to hear your thoughts on these competing development
strategies/methodologies/tool boxes keeping in mind, rapid application
development/ease of development, performance, security, cost, etc; you know,
the usual important questions on deciding what technology/methodology/strategy/
tool box, to use. Also, keep in mind, the future... which of these
strategies look like they will survive... what about JTOpen, Net.Data, JDBC,
JSON, RPGOpenGUI, etc?
Thanks in advance for your time expended in your answer.
Sincerely,
David Odom
midrange.com
