|
Nathan,
Hmm...this put me on a wholly different line of thought.
You're right. If we develop SPAs, then we don't need ASP.NET.
But here's my situation. Our shop currently does all web and mobile
development using ASP.NET. If we develop SPAs instead of 5250 green
screens for our IBM i users, our ASP.NET developers are going to say:
"When developing the server-side services for those SPAs, use ASP.NET
and the .NET Data Provider to perform SQL queries and stored
procedures on the IBM i. That way everybody is using the same server
side technologies and standards for our web and mobile development." And they have a good point.
It would help our shop with maintenance if everyone uses the same
technologies and standards for the server side of our web and mobile
solutions.
So why am I looking for alternatives? Because our shop tends to see
COBOL developers and ASP.NET developers as mutually exclusive developer pools.
A developer can move between pools. But a developer usually does not
do both COBOL development and ASP.NET development. So, if all of our
web and mobile development depends on ASP.NET, and developers belong
to only one pool (either COBOL or ASP.NET), then increasing demand for
web and mobile development means the number of COBOL developers will
decrease as they move to ASP.NET and those developers who stay with
COBOL will be shut out of web and mobile development. I've been trying
to find options for our COBOL developers to stay with COBOL but also get into web and mobile development.
However, it might be smarter to challenge the assumption that COBOL
developers and ASP.NET developers are mutually exclusive pools. Maybe
the right approach for our shop is to minimize the amount of ASP.NET
that our COBOL developers have to learn. We develop SPAs on the client
side using HTML, CSS, JavaScript and Angular. Then we only need to
learn enough ASP.NET to process an incoming HTTP request, use the .NET
Data Provider to perform SQL or stored procedures on the IBM i, and
format data from the IBM i into JSON for the HTTP response. This might
not be all that difficult to learn. And it might be possible to copy
code from previous apps and re-engineer it for new apps. If an
unusually difficult problem crops up, we can lean on our 100% ASP.NET developers to help us find a solution.
This didn't occur to me before because I wasn't considering SPAs before.
It was only when Buck mentioned the article on REST using Integrated
Web Services that I started thinking about SPAs with relatively thin
services on the server side. It just now occurred to me that our COBOL
developers could use a minimum amount of ASP.NET for thin services as well.
Thanks,
Kelly
-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Nathan
Andelin
Sent: Tuesday, May 19, 2015 3:13 PM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] IBM i authentication and RESTful web service
design
On Tue, May 19, 2015 at 7:44 AM, Kelly Cooksonwrote:
<KCookson@xxxxxxxxxxxx>
Why not just learn .NET web and mobile development and keepthe same standards?
everybody on
Given your preference for single page applications (SPAs) and
retaining "state" on clients, it seem to me that the only reason for
ASP.NET would be when clients need to access resources on Microsoft servers.
Wouldn't ASP.Net be completely superfluous, for clients that need to
access IBM i resources? No need for ASP.Net to dynamically generate
HTML because HTML would be static. No need for ASP.Net to maintain
sessions, because clients maintain their own state. No need for
ASP.Net to provide a gateway to IBM i data and other resources because
those resources could be accessed via an IBM i HTTP server and an IBM i Web Services Utility.
In the case of IBM i resources, it appears to me that ASP.Net would
just add latency, add a potential failure point, add complexity, add
needless security requirements, be a potential bottleneck, add cost,
and be completely unnecessary. It could save time, save money, improve
security, and improve the user experience by eliminating ASP.Net from the mix.
This perspective assumes that you have real intent to develop SPAs
which maintain client state, and control the interactions between the
client and an IBM i HTTP server. The HTTP server and an IBM i Web
Services Utility could be the gateway to IBM i resources.
Although the client's interactions with a Web Services Utility might
be via simple URI and an exchange of JSON objects, you might
streamline the interface via a JavaScript API which might be paired
with the functionality of the Web Services Utility.
var tableName = 'STUDENTS';
statusObject = wsuStatusObject();
studentRecord = wsuGetRecordObject(tableName);
studentRecord.lastName = form[0].lastName.value;
studentRecord.firstName = form[0].firstName.value;
studentRecord.middleName = form[0].middleName.value;
studentRecord.gradeLevel = form[0].gradeLevel.value;
wsuWriteRecord(studentRecord, statusObject);
if (statusObject.error) {
...
}
--
This is the Web Enabling the IBM i (AS/400 and 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.
--
This is the Web Enabling the IBM i (AS/400 and 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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
