I like your idea of a utility. I assume we could get such a utility to
work. That's all I need to know at this point. I'm simply gathering options
at this point. Details and proofs of concepts will come later.
Kelly,
I debated with myself whether to follow-up further. You seem to be ready to
wrap up the discussion, which is fine. Earlier in the day I posted a code
sample at midrange.com which I thought I might share.
To recap briefly, the discussion about REST web services led to references
to IBM i IWS, which is a utility, which provides a neat Web service
interface between HTTP clients and ILE Procedures as follows:
SPAs <==> HTTP Server <==> IWS <==> ILE Procedures <==> IBM i DB
I'm suggesting a Web Services Utility (WSU) as an alternative to IWS and
ILE Procedures; adding DB Event Handlers as follows:
SPAs <==> HTTP Server <==> WSU <==> IBM i DB <==> DB Event Handlers
Why DB Event Handlers? They apply data validation, RI constraints, and
business rules regardless of the source of the I/O. The rules are enforced
whether DB events originate from an SPA, or ASP.NET, or PHP, or Java, or
RPG, or COBOL, or from say IBM i Data File Utility. They ensure DB
integrity. They can only be bypassed by an IBM i admin temporarily pausing
or stopping the service.
DB Event Handlers run out-of-process, separate from the JOBS that evoke
them. They may be configured to run asynchronously. They have a life-cycle.
They are automatically loaded into memory when a DB event occurs, and
unloaded after a configured period of inactivity. They have an
initialization step when first loaded, a process step when a DB event
occurs, and a cleanup step when unloaded.
Say a program writes a transaction to a table, an "event handler" may be
configured to update an account balance.
Here's a link to a code sample:
http://code.midrange.com/14a8f4a1d7.html
That is an RPG example. But handlers could just as well be written in
COBOL. They are service programs which export init(), process(), and term()
procedures.
In that example, the process() procedure is evoked before database insert
and update events for a particular table. It validates the record and
returns appropriate error messages. It could just as well modify the record
before the database update occurs.
COBOL programmers might write 200-300 line service programs, where the
business logic applies universally, for web clients, or otherwise.
midrange.com
