RE: RPG.NET

OK, unless someone else jumps into this thread this is my last post on the
topic. A back and forth between Joe and I (while fun) isn't all that
productive.

>From: Joe Pluta [mailto:joepluta@xxxxxxxxxxxxxxxxx] 
>you ... can report errors immediately, because the client is on the same
machine
>as the business logic.   

Ignoring performance, you could report errors immediately in the web
environment too. And as time passes performance is easier to ignore. The
number of trips to a server (iSeries or otherwise) I'm willing to take in a
transaction today is much higher than the number I was willing to take 5
years ago.

>Where does this logic reside?  

Where would you like it. In a simple project you could put this on the web
server. In a more complex project you'd have a business layer that did this.

>How much of this do you store locally on the workstation?  

Define workstation. If you mean the browser on the clients PC, none! That's
what sessions are for.

>When is it edited?  

Again, when would you like it edited. You can edit after you add each line,
or once before you post the order, or both (probably should be both). Also
depends on the interface you choose. If you're on the click-to-buy model of
Amazon then you check when you add the item to the shopping cart and again
on the order creation. If you're in the subfile-entry model (enter a bunch
of items and quantities and click submit) you'd check the items entered on
click and again on post. Reporting back to the user and problems ("We're
sorry, we've sold out of item 12345, it's due in stock on the 20th.
Backorder, or try item 67890?") 

>Not to mention the fact that commitment control across multiple 
>files in an order entry system is very expensive and has 
>serious performance implications.

Strange statement. I'd argue that the cost of not using commitment control
in a multi-file update scenario is much higher than the cost of using
commitment control.

>And how often do you pass this hypothetical XML document...

Again, how often do you want those error checks?

>Once again, subatomic error checking rears its ugly head.

Agreed. But that's always been a problem of any order-entry system. When do
you allocate the inventory? If you allocate as soon as they enter the line,
great. But if they cancel the order you need to deallocate (no problem) but
in the mean time you may have lost another order because there was no
available inventory. Then again, if you allocate at the end of the process
you may find you're out of stock. I've doe it both ways.

>It's clear to me that you haven't really designed one of these systems.

If my design experience can be clear to you from a couple of quick e-mails
we have a problem. As it happens I've designed a number of these (5250,
client/server and web) over the years.

>The concept of putting business logic on the workstation has been 
>demonstrated over and over to have fatal flaws,

Hey, we agree on something <G>

>And, in any event, you're NOT using the iSeries as a database machine.
>You're using it as a business rules repository.

OK, perhaps the words "use the iSeries like a large database" were poorly
chosen. But my point was that you don't need a special toolkit to call a
program, a stored proc call is just as good.

>I hope you're not serious... the concept of triggers doing business
>logic has been out of favor for some time now, Walden.

All depends on what you use the trigger for, but in this particular case I
would agree. I would have build the inventory allocations into the stored
procs. Note the <G>

>Yeah, you have the problem that you'll be running Windows servers.  

I'm in good company. 

>The number of servers that support ASP are FAR fewer than the number of
>servers that support JSP/servlet. Thus, ASP is the non-standard
>approach.

I'm not sure how the number of servers available to me addresses the UI
problem. My UI is on the client side, no? I consider the web-server part of
my back-end systems. 

>I am considering side-by-side testing of Web development in .NET and
>JSP, using VS.NET and WDSC.  My question is whether you consider VS.NET
>Pro to be as productive for ASP development as WDSC for JSP.

In the correct hands, yes, one is as productive as the other. Be careful
doing you own comparisons though. You know JSP quite well, you're going to
be more productive with JSP regardless of the tool. I know ASP.NET will,
I'll be more productive in ASP.NET regardless of the tool. You'd need to
compare a JSP person with WSDC to an ASP.NET person with VS.NET. (And no, I
don't have the time to try a code-off)

One parting note. I don't believe JSP/Java is a bad choice, that's not what
I'm saying. I simply believe that ASP.NET is as good a choice. Here's my
prediction for app dev in 3 years:
45% in Java/JSP, 45% in .NET/ASP.NET and 10% in everything else.

-Walden

------------
Walden H Leverich III
President
Tech Software
(516) 627-3800 x11
(208) 692-3308 eFax
WaldenL@xxxxxxxxxxxxxxx
http://www.TechSoftInc.com 

Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)