Re: IBM i authentication and RESTful web service design

Nathan,

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.

I like your idea of a utility. I assume we could get such a utility to work. That's all I need to know at this point. I'm simply gathering options at this point. Details and proofs of concepts will come later.

Again, though, I very much appreciate you taking the time to engage in this discussion with me. You've given me a lot to think about. You've pushed me to clarify my terminology and architecture; you've pointed to some potential red flags regarding Integrated Web Services; and you've given me the addition of another option--a custom utility--to consider. I sincerely appreciate the help.

Thanks,
Kelly


-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Nathan Andelin
Sent: Wednesday, May 20, 2015 11:26 AM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] 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.
--
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.