Re: Web Services Solutions

From: richard@xxxxxxxxxxx

I don't get worked up about anything, but I find your passion for this
goofy
"cross-platform .NET" silliness to be very amusing.  It's as bizarre an
architecture as I can imagine (how many competing components are YOU going
to rely on in your system?).

Is it as bizarre or silly as Java to Data Queue to RPG to Data Queue to
Java as a suggested architecture ? :-)

Maybe, but I've never been accused of being normal anyway.

Uh oh, he's losing it...

My architecture is two languages, a platform-independent language for the UI
tier and a native language for the business logic, connected by arguably the
fastest inter-process connection you can have (data queues).

Yours is a language written for one platform which requires a third party
tool to convert it into bytecode to run on another platform in a different
language which is not even supported by the original vendor!  That to me is
frightening.

This is where we really differ.  Except for the world of thick clients,
J2EE
applications with RPG back ends are faster, more powerful, and more
feature
rich than SQL-based .NET applications.

Yes we do. Good generality Joe.

I would be happy to write a whitepaper with you doing performance
comparison of multiple environments.

Let's agree on a scenario that's close and do a comparison.

Loser buys at Portillo's or better yet - Weber Grill :-)

Works for me.  I'll be starting on such a thing over the next six months.
It will be good to compare the different approaches.

I suppose thick client technology is ancient, depending on if you're using
apps written in Windows 3.1.

No, I consider thick client ancient (maybe "archaic" is a better term) in
terms of distribution.  It's a pain in the butt to have to send new version
of the thick client code down to all of your workstations whenever you make
a change to the UI.  That's why I think thick client has a big future.

In .Net you can probably do a lot more sophisticated GUI stuff than with
AWT or RCP.

I don't think RCP technology is really the wave of the future.  Time will
tell if you're right on that one.

I'm not arguing about .NET vs. AWT, Swing or SWT.  Even though the Eclipse
RCP (Rich Client Platform) is a very powerful, feature-rich,
platfor-independent UI, it's still a layer on top of the OS, and because
.NET is tied directly to Windows, .NET still is more powerful than other
those technologies -- at least until you want to run on Linux or Macintosh.
But I digress.

When I say "Rich Client", I'm really talking more about things like XUL,
where you have a standard client on the workstation and you send UI
instructions down to the client, and it basically paints the entire UI on
the fly.  Keystrokes generate requests that go back to the server, which in
turn causes the UI to modify itself appropriately.

Ironically, Outlook Web Access is a great example of this.  But you get the
difference, right?  With thick client every business logic change and every
UI changes requires a new download of the client software.  Rich client
means that the client software is generic and responds to UI paint requests
from the host (much like 5250 or HTML).

I do agree that J2EE is better for server based stuff when cross platform
is involved.

Ah, we agree on more than that.  It's just this little place -- I think .NET
has its place, and I think you're using it for too much.

Yeah, okay.  But then again, that means anybody who implements your stuff
needs to be fluent in all those technologies as well, and also must rely
on
all the third-party tools you've downloaded off the Internet.  There is a
certain joy in the KISS principle: RPG with a thin browser front end sure
keeps it simple, and all the software is supported by IBM.

Sure Joe :-)

I'm glad you're passionate about what you know.  However you should really
broaden your horizons a bit.

Uh... not sure what you think I know, Richard.  Some day we can sit down and
compare resumes.  But I started out programming in assembly language -- I
wrote operating systems -- and my past includes everything from FORTRAN and
COBOL to C and Pascal.  So trying to pigeon-hole me as a one-trick pony is
probably a losing battle <smile>.

Again, you can't even debug RPG in Visual Studio.

Sure Joe :-)

Hmmmm... Can't debug in Visual Studio.  That's been in there since VB3
days back in the early 90's :-)

See, you're losing it.  You can't debug RPG in Visual Studio.  RPG, dude.
You know, the language your business logic should be written in?  Unless
you're one of those people who thinks they can write an ERP application in
BASIC.

Did you have a bad Basic experience at some point in your life ?

Counseling could cure your fear of VB.

Now you're drifting into the personal stuff.  I've coded lots of BASIC over
the years, starting in high school.  I also wore my hair down to my butt and
listened to Led Zeppelin really loud in those days.  There are lots of
things I outgrew over the years (okay, sometimes I still listen to Zeppelin
really loud).

Look at the real world.  There are companies everywhere using VB to write
production applications.

That doesn't mean I always agree with it, but VB does have a prominent
position in several companies including several of your own customers.

Your opinions won't change any of that.

I love it.  Your best argument for using a language is that "Lots of people
do it."  Your argument is a great one for someone trying to design solutions
for as many clients as possible.  In the meantime, I'm trying to help people
decide what is the best architecture available.  And for that, BASIC can't
hold a candle to RPG.

Speaking of a bag on a horse's butt... "Java to Data Queue to RPG to Data
Queue to Java" :-)

It is OK to touch the database with a business object or haven't you heard
that the iSeries has a database driver for Java ?

See, this is where you just drift down the rabbit hole, Richard.  Again you
compare a proper n-tier design to your strange multi-language, multi-vendor,
multi-generation miasma.  Two languages using a queued connection -- hell,
this is a standard OO design called an Adapter.  You, on the other hand,
have a language written by a tool from one vendor run through a tool from
another vendor to generate code to be run on a virtual machine from a third
vendor (a virtual machine the original vendor doesn't even support), and the
generated code can't even be debugged by the original tool.

You miss all the major points:

1. How do you debug generated bytecode running on the server from Visual
Studio?

2. How do you debug RPG on the server from Visual Studio?

3. You recommend architectures in which the iSeries is just a database
server.

Anyway, I'm sure this conversation has gone on long enough.  Nobody really
cares about our little tiffs.  It's good to get out the various points of
view and let other decide, but after about three volleys, I think our
conversations tend to degenerate a little bit... I mean really, "bag on a
horse's butt" (and yes, I know I started that)?  <grin>

Joe