Re: IBM i authentication and RESTful web service design

Henrik,

Using PASE/XMLSERVICE could definitely work. 

My challenge has more to do with organization than with technology.

It will be practically impossible to sell my shop on any approach that introduces a new code base like Java, PHP, or Ruby. All of the web and mobile development in our shop is currently done with .NET.  Our .NET developers use the .NET Data Provider when they need to access files or programs on the IBM i. So, our shop does not perceive a need for learning a way to develop web applications on the IBM I using something like Java, PHP, or Ruby. That would introduce a whole new category of maintenance. Plus, if you have to learn Java, PHP, or Ruby, why not learn .NET instead and keep everybody on the same standards?

I considered using Node.JS and XMLSERVICE, since our .NET web and mobile developers already use JavaScript. It wouldn't be introducing a new code base. And Node.JS solutions could run on IBM i or Windows. However, Node.JS is basically just a run time environment for JavaScript. To produce enterprise quality web and mobile solutions with Node.JS you have to introduce a lot of JavaScript libraries and frameworks. Then you still have to come up with standard ways of doing things. The amount of effort expended on all of this rivals the amount of effort learning .NET. So, again, from the perspective of our shop, why not just learn .NET web and mobile development and keep everybody on the same standards?

I will probably have a hard time selling CGI because it's still not .NET and because it's an older technology. (Older does not mean bad. CGI is a solution that I'm still seriously considering.) The fact that CGI would let us leverage our COBOL skills might make it an acceptable approach. We could leverage our IBM I COBOL developers for web and mobile development more easily and more cheaply than by having them learn .NET. 

The idea of using single page applications (SPAs) that consume REST web services (via IBM I Integrated Web Services) using COBOL business logic might be the easiest sell--if it can work. It would let us leverage our COBOL skills. It minimizes the amount of learning needed to turn COBOL programs into web services. And, especially with the development of mobile websites and hybrid mobile apps, our shop is starting to use SPAs.  Assuming we can make this approach work at an enterprise level, this might be my easiest sell.

Thanks,
Kelly

-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Henrik Rützou
Sent: Tuesday, May 19, 2015 5:05 AM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] IBM i authentication and RESTful web service design

Kelly

You have overseen your maybe biggest problem of all and that is that COBOL isn’t very well supported in ILE web-development on IBM I since most ILE frameworks and tools are done in RPGLE/C and most others in PASE (Java, PHP, Ruby etc.) using XMLSERVICE ( http://yips.idevcloud.com/wiki/index.php/XMLService/XMLService ) to communicate with the ILE environment. You may be better off in the latter (PASE/XMLSERVICE).

On Tue, May 19, 2015 at 2:18 AM, Kelly Cookson <KCookson@xxxxxxxxxxxx>
wrote:

> @Nathan,
>
> >> Regarding library list munging at runtime, are you suggesting that 
> >> the IWS pass the necessary parameters to each and every procedure 
> >> in order for them to do that at runtime? Aside from complicating 
> >> the procedure interface, wouldn't users be affected by the 
> >> performance implications?
>
> >> Regarding constraints on the size of data sets which may be 
> >> transferred from a server to a client, I view that as an 
> >> application decision, which should not be an constrained by the 
> >> communication interface.
>
> >> When the list of students is ordered by grade-level and student 
> >> name, bound to a back-end SQL result set, one would need to retain 
> >> the state of the SQL result set on the server in order to support 
> >> such navigation on the client.
>
> I am at the end of my (newbie) knowledge in terms of being able to 
> respond to these issues. I just don't know enough about SPA 
> development patterns to know what might, or might not, be good ways of 
> dealing with these issues. I will definitely keep these issues in mind 
> as I learn more about the nuts and bolts of SPAs and the services they consume.
>
> >> Regarding the user profiles which IWS servers run under, the real 
> >> question is should every individual user be able to adopt the 
> >> authority of the IWS user profile?
>
> The user profile for the IWS service does not have to be the same user 
> profile that runs the COBOL program. We never have to use the IWS 
> default user profile if we don't want to do so. We have some amount of 
> flexibility in terms of configuring user profiles. However, until I 
> actually create a few IWS services, I won't know how we want to handle 
> the security and authority issue you bring up. I might seek some 
> guidance about this from IBM. I would hope the architects and 
> developers of IWS have thought about this at some point since releasing IWS back in V5R4.
>
> >> So the "answers" you find on the internet, relevant to REST may or 
> >> may not work for IWS configurations.
>
> Point taken. Like you've said, the devil is in the details.
>
> It's possible that SPAs with REST services via IWS won't work for us. 
> We might end up back on a CGI approach. But SPAs with IWS is too 
> enticing to not explore.
>
> Thanks,
> Kelly
>
>
> -----Original Message-----
> From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Nathan 
> Andelin
> Sent: Monday, May 18, 2015 6:40 PM
> To: Web Enabling the IBM i (AS/400 and iSeries)
> Subject: Re: [WEB400] IBM i authentication and RESTful web service 
> design
>
> Kelly,
>
> I'm glad my questions are provoking thought and research. Just to 
> clarify, my questions are relative to the IWS, not REST interfaces in 
> general. It appears to me that the IWS has some configuration 
> requirements
> (constraints) for mapping browser inputs to procedure inputs, and 
> mapping procedure outputs to JSON and XML.
>
> So the "answers" you find on the internet, relevant to REST may or may 
> not work for IWS configurations.
>
> I agree that an SPA may be a REST client; JavaScript provides that 
> capability.
>
> Regarding library list munging at runtime, are you suggesting that the 
> IWS pass the necessary parameters to each and every procedure in order 
> for them to do that at runtime? Aside from complicating the procedure 
> interface, wouldn't users be affected by the performance implications?
>
> Regarding constraints on the size of data sets which may be 
> transferred from a server to a client, I view that as an application 
> decision, which should not be an constrained by the communication interface.
>
> Regarding the user profiles which IWS servers run under, the real 
> question is should every individual user be able to adopt the 
> authority of the IWS user profile?
>
> In regards to page by page navigation, I meant navigating lists of 
> records, not leaving one SPA and navigating to another, though the 
> interface should support that too.
>
> When the list of students is ordered by grade-level and student name, 
> bound to a back-end SQL result set, one would need to retain the state 
> of the SQL result set on the server in order to support such 
> navigation on the client.
>
> I understand that your shop may not want to maintain server code that 
> generates HTML from COBOL; you may only want to generate JSON for 
> client consumption, and possibly have servers consume JSON sent from 
> clients. If that's your choice of architecture, so be it.
>
> Again, it's not REST that might constrain your user interfaces, but 
> rather the IWS procedure interfaces.
> --
> 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.
>
>


--
Regards,
Henrik Rützou

 http://powerEXT.com <http://powerext.com/>
--
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.