Would be interesting to know what they don't think is production ready with XMLSERVICE. Especially since it's now included with the OS by default.
However I do respect that there is a small crowd of one maintaining the .Net wrapper, however there's not really much to it if they need to troubleshoot it and they can always reach out if they need support on it.
Another option to jump in to .Net Core right away might be to look at the DB2 drivers and DB2 connect which already has a .Net Core DB driver layer.
Although it's also in the spend $$$ on DB2 connect category it gets them on the road if they decide not to use Node.Js.
Regards,
Richard Schoen
Director of Document Management
e. richard.schoen@xxxxxxxxxxxxxxx
p. 952.486.6802
w. helpsystems.com
---------------------------------------------------------------
Richard,
The .NET teams have been driving the recent interest in Node. I'm not a .NET developer, so I don't understand the issue deeply. I was told the .NET developers use ADO.NET to get data from DB2400 and to call stored procedures. I was also told they can't use ADO.NET with .NET Core. So Node interests them as an alternative way to interact with IBM i resources. That's the extent of my knowledge on this issue.
The .NET teams have considered the CGI approach. I'm not sure the CGI approach is ruled out yet. I just don't think CGI tops of their list of choices.
The .NET team also knows about your XMLSERVICE wrapper (I told them about it). They like the idea in principle. I could be wrong here, but my sense is:
1. The .NET developers really don't like working with XMLSERVICE for some reason. Not sure why.
2. The .NET developers would prefer a larger development community, or commercial support, for any XMLSERVICE wrappers.
Again, that's just my sense. I'm not on the .NET development side of the shop. The desire to get away from XMLSERVICE was the reason why I was asked to explore running Node with the node-jt400 module on a windows machine.
(BTW - My opinion of the node-jt400 module is that it's for Java developers who want in on the Node action. If you don't know Java, then you'll probably want to learn it. The moment something falls down with node-jt400 module, you're looking at Java call stacks in the error messages and likely digging through jt400.jar documentation to figure out what you need to do with the Java classes. Plus there is little documentation for node-jt400 module itself. I'm not saying it's a bad approach. I'm saying you might want to think twice if you're not a Java developer or willing to become one.)
Thanks,
Kelly Cookson
IT Project Leader
Dot Foods, Inc.
217-773-4486 ext. 12676
www.dotfoods.com<
http://www.dotfoods.com>
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Richard Schoen
Sent: Sunday, March 18, 2018 11:14 AM
To: web400@xxxxxxxxxxxx
Subject: [EXTERNAL] Re: [WEB400] Rise of Node
I don't believe your .Net teams need to get of the .Net database drivers to start moving to .Net core. They can develop with .Net core and .Net drivers as long as they deploy on Windows.
Or start using .Net core for most new stuff, but create a standard .Net data service so the .Net drivers are used in one web service layer.
I have also built an opensource .Net core wrapper around the XMLSERVICE component that works with .Net core on Windows, Linux or Mac.
You could also write CGI or Node on IBMi to create JSON web services for them to consume from .Net or .Net core.
Even the IBMi IWS server can do that.
And if they want to use the JT400 data services to IBMi, I wrapped JT400 to work with .Net using an open source component called IKVM.
I guess the takeaway on that is that whether they want to use Node or not with IBMi, there are multiple data options the team can use.
Regards,
Richard Schoen
Director of Document Management
e. richard.schoen@xxxxxxxxxxxxxxx<mailto:richard.schoen@xxxxxxxxxxxxxxx>
p. 952.486.6802
w. helpsystems.com
midrange.com
