On Mon, Mar 26, 2018 at 3:36 PM, Jim Oberholtzer <
midrangel@xxxxxxxxxxxxxxxxx> wrote:
Or a classic use case for remote data queues.
Way easier than a web service and faster by a whole bunch.
I think the performance of NATIVE web services would be essentially
equivalent to remote data queues. Both are connecting over TCP/IP. You may
have been thinking of overhead and latency pertaining to a web-service
middleware layer such as Java or PHP. Yes, that might bite.
In regard to data queues being easier than web services, I think that's
unfortunate. That's something that could be resolved with good web-services
tooling. I've been thinking lately about how granular web-service APIs can
offer advantages over generic interfaces that enable clients to invoke any
SQL statement, any IBM i command, call any IBM i program. There is a big
security exposure with the latter, for example.
I understand that my next statement is terribly forward thinking. But what
if in the future IBM i were viewed more as a web-service server than a
database server?
In other words, what if shops started closing down DDM services, and Host
services (*database, *dtaq, *file, *rmtcmd), and other services such as
*NETSVR for say security reasons, and began channeling most if not all
remote I/O through HTTPS?
midrange.com
