× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



>but the web developers don't want to callthe web service multiple times, so I'm stuck with finding a solution.

Did they give a reason *why* they don't want to call it multiple times? They might have a good reason, but more than likely they are ignorant or lazy. Returning 10k of records for each listing request wont scale real well if you have a lot of users hitting that web service. Instead they should be making multiple requests and stating which page of a result set they would like returned along with a page count.
Note that for blackbox applications where you own both ends of the spectrum, XML is quite the bloated middle-ware technology - though it does provide insulation from bad technology decisions (i.e. today your front end is .NET, but when it is realized that was a bad decision then they will try Java, and then PHP, and then RoR, etc). Just think of how many bytes of data would be required for 10k of records and then add on top of that the CPU cost to serialize and parse it - ouch.

You are right to question them Dean,
Aaron Bartell
http://mowyourlawn.com

p.s. if you are looking for a commercial solution check out www.rpg-xml.com (of which I am the lead developer)




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.


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.