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



So my question still stands. Why would I use XMLSERVICE ever if I were using JDBC or ODBC calls ?

I would simply call a stored procedure directly via the JDBC/ODBC/QZDSAOINIT interface in the ODBC or JDBC drivers.

Personally I like the CGI REST interface for XMLSERVICE, but adding a layer to JDBC/ODBC seems redundant to me.

Regards,
Richard Schoen
RJS Software Systems Inc.
Where Information Meets Innovation
Document Management, Workflow, Report Delivery, Forms and Business Intelligence
Email: richard@xxxxxxxxxxxxxxx
Web Site: http://www.rjssoftware.com
Tel: (952) 736-5800
Fax: (952) 736-5801
Toll Free: (888) RJSSOFT

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

message: 1
date: Sat, 4 Aug 2012 17:00:23 -0400
from: Jon Paris <jon.paris@xxxxxxxxxxxxxx>
subject: Re: [WEB400] XMLSERVICE with .Net


On 2012-08-04, at 1:00 PM, web400-request@xxxxxxxxxxxx wrote:

I still don't understand. What is the difference between calling "xmlservice.pgm" from "xmlcgi.pgm" vs. calling it from "qzdasoinit.pgm"?

If you haven't benchmarked the CGI interface vs. the QZDASOINIT interface, then you're just spreading harmful FUD about CGI performance, no?

OK - maybe we should start over again because you have the wrong end of the stick Nathan.

There are two ways of accessing XMLSERVICE.

The first is as a rest-style web service. You pass an XML packet that describes the program you want to call, parms etc. (You can also use commands, PASE stuff, etc. but I'm sticking to programs for simplicity). Note it is _any_ program as described by the XML packet.

The second way is to make an SQL type connection (ODBC, JDBC, whatever) and call the XMLSERVICE's stored procedure directly. Again an XML packet is used to describe what you want it to do. It is essentially the same XML packet as in the REST service interface.

Here's why Brian is correct in saying that the rest service is slower than the stored procedure. There's no FUD here and no statement at all about CGI performance. Heck Brian's company builds tools for developing CGI apps - he's not likely to spread FUD is he. The reason that the rest service has to be slower is that once it has received the request in order to process it, it calls the _exact_same_ stored procedure. So the time spent in the CGI job has to be overhead. Not much - but it is inevitable.

Hope this makes it clearer for you.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com




As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.