|
<OFF LIST>
Hi Maurice -
I'm really interested in using .Net to the full (<grin>) as opposed to
using PHP or Java. Do you have any sample programs you could share?
How about some good references?
Thanks loads!
- Michael
On Fri, Dec 12, 2008 at 11:02 AM, Maurice O'Prey
<maurice.oprey@xxxxxxxxx> wrote:
One nice feature of keeping the responsibility for collecting iSeries
data on the . Net server is the ability to set the command timeout value
So if someone issues an SQL statement that doesn't complete in say 30
milliseconds an exception is thrown and you can inform ( or tell ) the
user to refine their search criteria
Hence my preference for using . Net to the full ( although cgi comes
in useful at times )
User names and passwords can be encrypted on the . Net server and
since digital certificates will be served from there it would seem
( IMHO ) that you should focus more pn the . Net side of things
No doubt many will disagree :-)
Maurice O'prey
Sent from my iPhone
On 12 Dec 2008, at 15:08, "Aaron Bartell" <aaronbartell@xxxxxxxxx>
wrote:
As I was running a CGI page today that loads an absolute boatload of
records
(because I haven't taken the time to implement paging - yet) I
thought of
another reason why large result sets are problematic/dangerous.
As soon as I clicked submit I realized I had specified the wrong
criteria in
the submit form, so I hit stop in the browser, changed my criteria and
resubmitted the form. Note that the first CGI job on the AS400 is
*still*
running as it doesn't know I no longer want the first request. At
this
point there are two jobs consuming a fair amount of CPU.
I could repeatedly hit the submit button and enact a pseudo
denial-of-cpu-attack (new term? DOCPUA :-). As developers we get
to help
shield users from themselves by building software that will perform
even
when users don't use our applications responsibly.
It sounds like you have your hands tied somewhat in that you don't
get to
make the final decision, but you will be in a good position to say
"I told
you so" and wash your hands of the mistake when it does fail, but
also have
the solution to fix it when they ask how.
HTH,
Aaron Bartell
http://mowyourlawn.com
On Wed, Dec 10, 2008 at 12:26 PM, <Dean.Eshleman@xxxxxxxxxxxxxx>
wrote:
Hi,
I have some questions about web services and how we are designing
them. We
are using web services to provide data from our system i to
our .NET web
application. These web services are not intended to be used outside
of our
own application. One of our reasons for using web services was to
avoid
storing a user id and password on the .NET side.
Our current approach has been to create the RPG program to return
the data
and then use the functionality in WDSC to create the web service
front end
for the RPG program. Overall, this approach works pretty well for
most
situations. The only thing we don't like about this approach is
when we
are returning multiple records from the RPG. We set the size of the
output
multiple occurrence data structure to be large enough to handle
what we
think is the highest number we will run into. In one case it needs to
handle close to 10,000 records. Personally, I think that is to
large of a
number to return at one time, but the web developers don't want to
call
the web service multiple times, so I'm stuck with finding a solution.
The generated Java code from WDSC will return an XML document
matching the
number of occurrences output from the RPG. We would like it to only
return
the number of occurrences that actually contain data.
Since I don't know Java, my initial thought solve this problem was to
create an RPG program to replace the Java in this situation. The
RPG would
receive the input XML document, parse it and then call the RPG data
retrieval program. Next it would build the XML response document and
return that result. I thought I could do this using CGIDEV2 and Scott
Klement's port of the Expat parser (thanks Scott). This way, I can
control
the XML document that is output. Does this seem like a reasonable
solution?
I was able to test out the XML parsing and that seems to work okay.
Right
now, I'm trying to use CGIDEV2 to read the input XML and I'm not
sure how
to do that. All the examples I see involve reading input from a web
page.
Does anyone know what field would contain the XML after using the
zhbgetinput procedure?
One concern I have about the CGIDEV2 approach is how will I secure
the web
service? Only our application should be authorized to call it.
We are on V5R3 and won't be going to V5R4 until sometime next year
and
this needs to be solved before then.
Dean Eshleman,
MMA, Inc.
______________________________________________________________________
--Confidentiality Notice: This information is intended only for the--
individual or entity named. If you are not the intended recipient,
do not
use or disclose this information. If you received this e-mail in
error,
please delete or otherwise destroy it and contact us at (800) 348-7468
so we
can take steps to avoid such transmissions errors in the future.
Thank you.
--
This is the Web Enabling the AS400 / 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 AS400 / 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 AS400 / 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.
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
