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



Good points Scott. I just want to add my two cents in :-)

>If multiple tiers, back end databases, etc are important to you, .NET
should also be given serious consideration. 

I want to challenge this because I just don't understand (literally) the
benefit to going with .NET (which inherently means you have Windows and
IIS). Let me clarify that a little more by first saying that I don't
disagree that a language like C#.NET is powerful, but it's the other baggage
that comes with it (i.e. Windows and IIS). I just don't think Microsoft is
"Enterprise Server" ready. Yes they have good desktop software and email
software and, and, and, but let's remember how recently they have entered
into the enterprise server market and how long IBM has existed in the space.
Will they catch up to IBM fast? You bet! But they have a good five years
before they do so (very unscientific projection :-). 

The reason .NET gets such great adoption is because it is extremely easy to
program in.  Microsoft is a master at integration within themselves. Great!
You can get your programming done in 3/4 the time as a Java developer. The
thing that doesn't appear until later is the scaling problems and lack of
options in the event you aren't getting what you need. 

I think the thing that set me off the most was the "serious" portion of the
consideration :-)  I think .NET would be great for small businesses, but not
the right choice for enterprise or potential enterprise applications.

>Another Pro of using Java that you didn't list is that there's lots and
lots of functionality available.

Agree 100%.  It is almost to a fault how many choices one has with Java.
Just look at all of the different frameworks out there and the different
components you can have within each framework. It is truly amazing.

Shane, if you have Java knowledge I would head down that path. The web tier
event driven frameworks are getting better all the time. I don't think I
would go with raw JSP/Servlets but actually look into some "pre-packaged"
abilities like JSF (Java Server Faces) or Tapestry or Spring (haven't used).

Aaron Bartell


-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On
Behalf Of web400@xxxxxxxxxxxxxxxx
Sent: Friday, May 12, 2006 6:55 PM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] CGI vs JSP...


> CGI - Pros:
> You probably already know RPG.
> Easy to start with.

If you change "CGI" to "CGIDEV2" then I'll agree with that!  Getting started
with CGI when you aren't using CGIDEV2 (or a comparable toolkit) is not
easier.


> CGI - Cons:
> Doesn't always scale well.
> Locks you into using iSeries as your webserver and as your back-end.
> HTTP server and web application must be in same tier.
> Tough to hire people that know anything about RPG-CGI.

These are more the cons of RPG than they are of CGI.  Most of your
restrictions come from the fact that RPG really only runs on iSeries
systems.

It doesn't really lock you into using the iSeries as both the web server 
and back-end...   The web server does need to be iSeries to run RPG, but 
an RPG program can talk to other computers to get the data.  You could have
a back-end computer running DB2 and query it from RPG.  Or RPG could run a
web service on another computer, or communicate with another computer using
data queues or sockets.

It's just less common because there's such wider support for Java in the
industry.  JDBC drivers are easy to find, so communicating with databases
over a network from Java is much more common.

Like I said, your restrictions are really because of RPG, not CGI.

The major cons of CGI itself are:

a) It requires starting up a separate process outside of the web server.

On most platforms this is very expensive.  It'd be like submitting a new job
for every RPG program you run, waiting for it to finish before doing the
next step.  The overhead of submitting the job is significant.

However, on the iSeries it isn't such a big problem because the CGI jobs
remain active and are re-used.  You don't have to start new ones over and
over.  Plus, iSeries programs can remain in memory with their files open and
variables intact so that they can be called again very quickly.  In RPG we
think of this as ending with *INLR = *OFF, but it's available via activation
groups in other ILE languages as well.  Since no other platform has this
functionality, and iSeries is such a tiny niche of the market, this is still
considered a huge blemish on CGI in general.

b) CGI programs traditionally have the HTML hard-coded in them, making them
hard to update.

This isn't a problem with CGIDEV2 or similar toolkits.  Again, most
platforms dont' have these toolkits for CGI.  So the ease of encoding the
HTML in a JSP or PHP script is extremely attractive.  On the iSeries, we can
do something very similar with CGIDEV2 or similar, so the difference isn't
so big.

c) There's all of the work of decoding the variables from web forms, storing
them somehow where it's easy to utilize them, etc.

Again, CGIDEV2 and similar tools do that for you, but on other platforms the
tools that do this aren't very good, or do less of the work for you. 
For a long time, the standard on Unix systems was to code CGI in Perl using
a module called CGI.pl because it helped decode these variables.  It didn't
help with the HTML part of it, so when PHP had both the functionality of
CGI.pm and the ease of coding the HTML, it blew Perl out of the water.

Unfortunately, most people who have programmed in CGI aren't iSeries people
and haven't ever seen a toolkit like CGIDEV2.  To them, CGI is old and
awkward and slow because of the above reasons.

> JSP Pros:
> Easy to find people who know it.
> Can run web app tier on just about any platform.
> Can connect to multiple back-end databases.
> Can separate HTTP server tier from web app tier.
> Lots of open-source resources.

I actually haven't had much problem findint people familiar with CGIDEV2
programming.  But, there are more Java developers than iSeries *users*, so
it's definitely easier to find Java developers familiar with web
programming.  And drastically more open source resources, since 95% of the
iSeries community still doesn't understand open source.

However, there's even more PHP open source out there.  PHP is also extremely
widely used, at least as widely used as Java.

If multiple tiers, back end databases, etc are important to you, .NET should
also be given serious consideration.  There seem to be more .NET developers
out there than Java, as well, and aside from the open source aspect, it
matches all of the other pros of Java.

Another Pro of using Java that you didn't list is that there's lots and lots
of functionality available.  By that, I mean routines that assist you with
writing web applications.  Far more tools than CGIDEV2 provides. 
(Though, again, .NET and PHP have most of the same tools as Java)

> JSP Cons:
> You probably don't know it.
> Can be tough to get started if you don't have an experienced Java person.

Also, for a small shop, performance can be a big problem with Java. 
That's my biggest gripe about it.
--
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 ...

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.