Re: Updating files from the web

I have no trouble with nicely insulated busisness logic accessing the DB.
That might even been done using SQL (Ok, not a fan).
My worries (and the worries of just that many Audit People) are about direct 
access from the actual webpages using any changeble, injectable, scriptable, 
whatever is received it tried to be executed way of working.
In my concept Stored SQL procedures are in that game (a little less tricky when 
executed from the insulated bussiness logic but still tricky). 
That is for the toys and the toy boys.

Burn me.

Kind regards,
Eduard.

----- Original Message ----
From: "richard@xxxxxxxxxxx" <richard@xxxxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx
Sent: Monday, November 27, 2006 1:05:31 AM
Subject: RE: Updating files from the web


Just so we're clear on this Joe, you think ODBC is bad, eh ? ;-)  (The eh, 
was my canadian/Minnesotan impression.)

Actually we work with the iSeries Access ODBC, .Net Provider and JDBC 
quite regularly and we typically achieve sub-second response times, so in 
my opinion based in experience, performance isn't much of an issue in 
today's environment. 

In terms of managing library lists, if we put SQL into a business object, 
we have properties that get set in the business object to control library 
lists for the data. We also qualify our SQL with the library name where 
the tables reside. Seems to work quite well and give us complete control 
over which library we're accessing. 

Your point about security can be mitigated somewhat by wrapping all SQL or 
database access into a business layer as I advocate and I believe you do 
as well with the messaging architecture that you recommend. You can 
definitely reduce the possibility for hacks if you use the message based 
approach, but since most other non-iSeries database applications support 
data access via direct SQL or business objects that use SQL, I don't think 
we can hang our hats on not using SQL.

Here's my thoughts on why:

<A little soapboxing>

I know the message based architecture concept is fast and safe and all 
that, but I am regularly running into people who are fighting to keep 
their iSeries systems alive in the realm of 30-something CIO's who want to 
dump the iSeries because of the green screen.  While this is not really a 
good business move, we can't continue to always fight the "I want to use 
SQL to access the iSeries, how do I do it"  complaints with "You need to 
write special iSeries code to keep the programmers and hackers safe from 
the system". If we do that, then the youngling's will eventually win the 
war and the iSeries will continue to get dumped. 

If we instead talk about the concepts of using safe business objects to 
wrap database access or messaging access so that the code is re-usable 
across applications and SQL is not embedded into pages directly, then 
maybe the young Linux/Windows-Generation will learn the value of writing a 
"business layer" instead of throwing a bunch of spaghetti SQL into some 
quick web pages. 

We sold a VB tool called DDA/400 back in the 90's in the early days of 
iSeries SQL and ODBC.  The main reason for this tool was record-level 
database access for speed.  With JT400 and other tools today, the need for 
a tool like DDA/400 has been eliminated but I can't count the number of 
calls we took where the PC developers would say "That record level thing 
sounds good, but we need to use SQL for flexibility".  In the late 90's we 
saw the handwriting on the wall in regards to SQL being used more and 
more, so I believe we must teach "safe SQL", not abstinance :-)

</A little soapboxing>

For the seasoned iSeries developers, a nice happy medium is the concept of 
using stored procedures to access data from a business layer.  The concept 
of calling an RPG stored procedure and returning a result set lets all the 
SQL access live in the iSeries database and within RPG programs. Then the 
logic can be used from another RPG program, an PC web page application or 
a business object written in Java or VB or C# or whatever......

At lease we're giving people food for discussion :-)

Regards,
Richard Schoen
RJS Software Systems Inc. 
"Providing Your....iNFORMATION NOW!"
Email: richard@xxxxxxxxxxxxxxx
Web Site: http://www.rjssoftware.com
Tel: (952) 898-3038
Fax: (952) 898-1781
Toll Free: (888) RJSSOFT
------------------------------
message: 4
date: Sat, 25 Nov 2006 11:19:51 -0600
from: "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>
subject: RE: Updating files from the web

I don't want to put words into Eduard's mouth, but I think the issue was
more about ODBC rather than SQL.

ODBC is bad.