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 Cookson <KCookson@xxxxxxxxxxxx>
wrote:
Why not just learn .NET web and mobile development and keep everybody
on
the same standards?
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.
midrange.com
