Re: IBM i authentication and RESTful web service design

But here's my situation. Our shop currently does all web and mobile
development using ASP.NET.

Under your proposed SPA architecture, developers would be doing the vast
majority of their "web and mobile development" using client-side
technologies; you indicated HTML, CSS, JavaScript, and Angular. No need for
ASP.NET there; all of it would run in a browser.

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.

Sorry, I don't see the point of "developing server-side services" using
ASP.NET, at all. ASP.NET doesn't really "perform SQL queries", nor "call
stored procedures". It provides a gateway for "sending messages" to a DB
server to perform those things, and return ODBC formatted data streams of
the results.

From those results (ODBC formatted data streams), ASP.NET would

traditionally merge them with HTML templates to generate browser documents
and applicable content.

In the case of SPAs, you don't need a middle-tier to transform the
ODBC-formatted data streams to HTML, nor to manage sessions; which is the
type of work that ASP.NET is designed for. You don't need a "middle" tier
at all.

ASP.NET is a 3-tier architecture, but SPA's require only 2-tiers; the
middle tier is superfluous. Likewise, there is no need for stored
procedures on the DB server.

Given a 2-tier architecture, your COBOL developers wouldn't need to learn
ASP.NET. Neither would they need to learn CGI nor any other traditional web
application tools. Again, that tier is superfluous.

SPAs are designed to consume JSON and XML objects directly. You don't need
server-side programs to generate JSON and XML. A Web Services Utility could
transform DB objects, including SQL result sets into JSON and XML without
any server-side programming. Similarly, a Web Services Utility could
transform JSON and XML objects received from SPAs into database objects,
without any server-side programming.

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.

COBOL developers would need to learn HTML, CSS, JavaScript, and Angular (if
you will), in order to do client-side development. ASP.NET, CGI, Stored
Procedures, would all be irrelevant.

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.

You're kind of repeating yourself. Rather than thinking in terms of a
"minimized amount of ASP.NET", how about thinking in terms of "zero"
middle-tier development.

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.

The IWS server that Buck referenced is a type of Web Services Utility,
which likewise would eliminate the need for a middle-tier. But it is
designed to call procedures. I'm suggesting a place for an even more
capable "utility", which eliminates the need for that type of interface,
and that type of programming as well.

If we can agree on this type of architecture, then next I could share an
idea and code sample for performing data validation, referential integrity
checks, and custom business logic, using "database event handlers" on IBM
i, which is where the COBOL skills would come into play.

HTH,

Nathan.