Re: IBM i authentication and RESTful web service design

Kelly

I'm not a COBOL programmer so I have to ask if IBM I COBOL has the same
inline
SQL facilities that SQLRPGLE has.

To me SQL is a MUST for modern web development.

On Wed, May 20, 2015 at 10:38 AM, Kelly Cookson <KCookson@xxxxxxxxxxxx>
wrote:

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.

--
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.