Hi Nathan

I suspect that if the i is not acting as a database server, then it
probably is not doing anything at all.
I wonder if you really meant a database that is exposed via web services
instead of ODBC and the like.

Personally, I don't see this as happening as the tooling to create web
services on the i is (mostly) pretty primitive compared to other systems
which have the advantage of frameworks where web services can be created
and exposed at scale.

it appears you have built programming infrastructure to do this but this is
something of an exception.

On Tue, Mar 27, 2018 at 12:10 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

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?
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.