<Joe>
See, my original point was that I wouldn't use an RPG program here.  I
would use a servlet to intercept the external request, and then call the
RPG program.  By doing this, I can move the servlet off of the iSeries
box (because the Java toolbox makes it very easy to call a program on a
remote machine), thereby "decoupling" the web server from the business
logic.

See what I mean?
</Joe>

Yep, I see what you mean, but what portions of the Java toolbox are you
using to talk with the RPG program?  My point is that you can change your
backend without having to rewrite your Java code.  Yes I know you said the
iSeries will always be your choice, but if you are selling software, which
you do, and you want to write a set of Java Servlets to communicate with a
back end process, by using XML for the communication from servlet to backend
you can make that relationship more generic than it was before.

<Joe>
Here I agree!  I like XML as a platform- and protocol-neutral
communications medium, for situations where you have the bandwidth.  As
I'm sure you agree, there can be a lot of additional overhead with an
XML file, but as a sort of "buffer zone" between differing platforms
(especially when you're trying to be as open as possible), it's not bad.
</Joe>

Yep, definitely a bunch of extra overhead with XML (bandwidth, parsing the
document, etc).

<Joe>
Notice, though, that while we agree in one place (XML) and disagree in
another (servlet vs. RPG-CGI), neither of us is even mentioning web
services.  That's because they're really not relevant to the business
question.

Web services come into play when you're talking about finding a service
provider.  If you don't know where that provider is, then web services
are a sort of directory.  But short of that, I don't find them to add
anything to the basic concept of sending an XML file to a program and
waiting for one in response.

And frankly, I have a little trouble with the idea that I am going to
want my mission critical systems to go to some public directory to
determine where to send my sensitive information.  I think web services
may indeed be important for querying data, but probably less so for
transaction processing.
</Joe>

You don't need to publish your web services publicly, you can publish them
to a UDDI server on your PC if you want.  You are assuming that web services
are only on the World Wide Web, and I don't think that is where web services
are most used (opinion).  I think they are more used within intranets.  When
I say web services I mean a service that is available over HTTP with XML as
the protocol.  Within our corporation they are becoming more and more
prevalent.  It was just easier to pick a standard that any number of
languages and platforms could talk.

Aaron Bartell

-----Original Message-----
From: Joe Pluta [mailto:joepluta@xxxxxxxxxxxxxxxxx]
Sent: Thursday, September 04, 2003 2:32 PM
To: 'Web Enabling the AS400 / iSeries'
Subject: RE: [WEB400] XML and RPG-CGI, is XML needed. was -> HolyWar . .
..


> From: Bartell, Aaron L. (TC)
> 
> Ok, now we have something worth talking about.  I will give some
history
> to that statement. . .

Hee hee!  See, I knew we could get past that little "testosterone
moment" <chuckle>.


> In my experiences, passing values to a CGI program (RPG in this case)

See, my original point was that I wouldn't use an RPG program here.  I
would use a servlet to intercept the external request, and then call the
RPG program.  By doing this, I can move the servlet off of the iSeries
box (because the Java toolbox makes it very easy to call a program on a
remote machine), thereby "decoupling" the web server from the business
logic.

See what I mean?


> with a
> key value pair (Name=Aaron&State=MN for example) proved to be less
than
> adequate when you want to get a whole heap full of info into the
RPG-CGI
> program, and then what do you respond with, more key value pairs, XML?

Here I agree!  I like XML as a platform- and protocol-neutral
communications medium, for situations where you have the bandwidth.  As
I'm sure you agree, there can be a lot of additional overhead with an
XML file, but as a sort of "buffer zone" between differing platforms
(especially when you're trying to be as open as possible), it's not bad.


Notice, though, that while we agree in one place (XML) and disagree in
another (servlet vs. RPG-CGI), neither of us is even mentioning web
services.  That's because they're really not relevant to the business
question.

Web services come into play when you're talking about finding a service
provider.  If you don't know where that provider is, then web services
are a sort of directory.  But short of that, I don't find them to add
anything to the basic concept of sending an XML file to a program and
waiting for one in response.

And frankly, I have a little trouble with the idea that I am going to
want my mission critical systems to go to some public directory to
determine where to send my sensitive information.  I think web services
may indeed be important for querying data, but probably less so for
transaction processing.

But this area is definitely still up for grabs, and I'm just as likely
to be right as wrong; only time will tell.

Joe


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