Re: Question about Node.JS and XMLSERVICE -- WEB400

Thanks for the reply, Aaron. But the question isn't about the syntax of SQL
paging. It's about how you manage DB state in a multi-user environment.

A number of IBM i Node.js examples follow a pattern something like:

var db = require('/QOpenSys/QIBM/ProdData/Node/os400/db2i/lib/db2');

db.init(...);
db.conn(...);
db.exec(...);
db.close(...);

But "stateful" DB interfaces require some way of pairing multiple
concurrent users with persistent DB connections. Do you write your own
"connection" manager, or rely on a pre-built framework?

On Thu, Aug 27, 2015 at 3:54 PM, Aaron Bartell <aaronbartell@xxxxxxxxx>
wrote:

How would one manage database state under Node.js?

SQL paging mechanisms can be used (i.e FETCH**).

**

http://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_72/db2/rbafzfets.htm

Aaron Bartell
litmis.com - Open Source and IBM i. No Limits.

On Thu, Aug 27, 2015 at 4:31 PM, Nathan Andelin <nandelin@xxxxxxxxx>
wrote:

Thanks for your replies, Aaron and Kevin.

Aaron, there was a tickle in the back of my brain of there being an
additional interface to XMLSERVICE via Node.js DB access. But the dots

were

not connecting in my mind. I found the following reference which
corroborates the information you shared:

https://www.ibm.com/developerworks/ibmi/library/i-native-js-app-ibmi-with-nodejs/

Figure 2. Node.js for IBM i infrastructure, was particularly

illustrative.

I'll assume for the moment that the diagram labeled "Node.js Toolkit for
IBM i" uses the XMLSERVICE REST Web Services interface. As an alternative
it seems pretty clear that the diagram labeled "DB2 for i Access

Library",

uses the SQL CLI interface.

I'd like to throw out another question. In my experience, complex

business

applications rely quite a bit on the "state" of database tables being
maintained for paging and other purposes. How would one manage database
state under Node.js?

Kevin, your comment about pulling data off a data queue and handling
"blocking" issues with child processes sounds interesting. If I

understand

correctly you're expressing a concern about "blocking". But I don't
understand the part about child processes.

I thought I read somewhere that although Node.js runs under one process,

it

uses threads internally, so that say DB I/O blocking does not adversely
affect its handling of multiple concurrent HTTP connections. Or is there

a

problem?

On Thu, Aug 27, 2015 at 2:10 PM, Aaron Bartell <aaronbartell@xxxxxxxxx>
wrote:

You are correct, you don't *need* Apache. Apache is just one way to

get

around the DB2foriAccess blocking issue (or dataqueue blocking, in your
case). Good idea on using child_process. I wonder how well a database
connection would work doing the same. Or maybe even a guy could route

an

entire request from start to finish to their own child_process

(effectively

an IBM i job) as a means to release the primary Node.js thread to

receive

in the next connection. That's potentially a lot of jobs :-( That's

one

advantage of the Apache approach is the Node.js processes wouldn't end

and

instead stay "alive" to process the next request (a lot like RPG CGI).

A complete side note, though on the blocking/non-blocking topic...

The following book helped me gain perspective on how and when things in
Node.js becoming blocking in nature. The book is more like a long

article

and is a quick read. The guy had a lot of the same questions I had and
cleared up a lot of questions.

http://bit.ly/node-beginner-book-manuel-kiessling

Aaron Bartell
litmis.com - Open Source and IBM i. No Limits.

On Thu, Aug 27, 2015 at 2:56 PM, Kevin Turner <
kevin.turner@xxxxxxxxxxxxxxxxxxxx> wrote:

I am using node.js and the IBM I toolkit and there is no Apache code

in

the mix as far as I know. I am running a node server that pulls data

off

a

data queue. That is also a blocking process so I am using a child

worker

to

do the job (basically a thread) using child_process.

On 27 Aug 2015, at 21:15, Aaron Bartell <aaronbartell@xxxxxxxxx>

wrote:

You are correct that XMLSERVICE can be used in two ways - database

stored

procedure and REST HTTP calls.

When doing 1-tier scenarios (i.e. Node.js is on same IBM i as the

DB2

you

are after) then the stored proc approach is best (a lot faster).

If

2-tier

(Node.js is running on Linux or other) then the REST HTTP approach

can

be

used.

The XMLSERVICE DB stored proc approach is using the Node.js DB2

adapter

which is written in C and calls the SQL CLI APIs directly. There

is

no

ODBC or JDBC or MySQL layer in-between.

Here's the scenarios I have for calling RPG and accessing DB2,

respectively:

Browser<==>Apache<==>Node.js/Ruby<==>toolkitfori**<==>RPG
Browser<==>Apache<==>Node.js/Ruby<==>db2foriaccess***<==>DB2

It's worth nothing that Apache isn't required in all circumstances,

though

right now it is somewhat a necessity since the DB2foriAccess for

Node.js

is

blocking.

**http://bit.ly/nodejs_toolkitfori
***http://bit.ly/nodejs_db2foriaccess

What type of application code do you run under Node.JS?
What type of application code do you run under IBM i programs and

procedures?

This is where opinions can greatly differ, and I will offer up

mine...

- You get significantly faster development if your

<open-source-language>

can go directly to the DB. Here's where some will say "I don't

trust

those

Node.js devs, so they have to obtain all of their data via calls to

RPG".

Big productivity killer. Big slow-down in finding bugs. etc.

- It is wise to re-use existing RPG business logic because

rewriting

can

take long enough that the time savings of going with

<open-source-language>

would be lost. The toolkitfori (aka the XMLSERVICE interface for

Node.js)

is an excellent stop-gap. My customers have a mix of logic in
<open-source-language> and RPG.

- How much logic you put in <open-source-language> depends a lot on

the

shop's future direction. For example, I have some customers that

have

determined <open-source-language> is their new direction and will
eventually replace the majority of their existing code base. This

leads

them to leverage existing RPG with XMLSERVICE *sometimes*, but a

lot

of

logic is being put into <open-source-language>.

- <open-source-languages> have excellent packaging capabilities

(think

*SRVPGMs on steroids). For example, you could keep your Node.js

Order

Processing business logic in a Node Package Module (npm) and store

it

in

a

private repository. Then in your apps you could simply include

that

Order

Processing npm in the package.json file as an application

dependency

that

gets installed and updated in simple fashion (i.e. npm install
order_processing, npm update order_processing).

- It's very interesting to read about Walmart Labs and how they've

approach

adoption of Node.js. They have the same legacy issues as the IBM i

base

(their legacy is old-school Java Struts/Servlets from 10+ yrs ago).

Very good questions. These are the types of things every shop

adopting

open source needs to ask and spend some time doing tests.

Aaron Bartell
litmis.com - Open Source and IBM i. No Limits.

On Thu, Aug 27, 2015 at 1:33 PM, Nathan Andelin <

nandelin@xxxxxxxxx

wrote:

My understanding is that XMLSERVICE provides 2 interface options

for

various language environments:

1. XMLSERVICE via. ODBC / JDBC stored procedure calls (DB2

Interface).

2. XMLSERVICE via IBM i Apache-CGI calls (REST Web Service

Interface).

Since Node.js has an excellent reputation for supporting socket

I/O,

I'll

assume for the moment that the IBM i implementation makes calls to
XMLSERVICE via the REST Web Service Interface. But does anyone

know

for

sure?

The flow in my mind goes as follows:

Browser <==> Node.JS HTTP & Application Interfaces <==> IBM i

Apache

Interface <==> XMLSERVICE CGI <==> IBM i SQL and PGM resources.

Does that sound about right?

If so, what would be good guidelines for structuring applications

under

this flow?

What type of application code do you run under Node.JS?
What type of application code do you run under IBM i programs and
procedures?
--
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.

___________________________________________
This email has been scanned by iomartcloud.
http://www.iomartcloud.com/

________________________________

NOTICE: The information in this electronic mail transmission is

intended

by CoralTree Systems Ltd for the use of the named individuals or

entity

to

which it is directed and may contain information that is privileged

or

otherwise confidential. If you have received this electronic mail
transmission in error, please delete it from your system without

copying

or

forwarding it, and notify the sender of the error by reply email or

by

telephone, so that the sender's address records can be corrected.

--------------------------------------------------------------------------------

CoralTree Systems Limited
Company Registration Number 5021022.
Registered Office:
12-14 Carlton Place
Southampton
Hampshire
SO15 2EA
VAT Registration Number 834 1020 74.
--
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.

--
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.