RE: COM/DCOM - Good or Bad as access strategy to iSeries

Dave,

>From what I've seen .NET is .ASP enhanced, which is to say 
>a programming language used mainly for web development. 

.NET is a lot more than that. ASP.NET is ASP enhanced. .NET support
client/server, server-only, command-line, thick-client, etc. It's not a
great analogy for many reasons, but if it helps, .NET == Java and
ASP.NET == JSP

>the only way I'll let his COM entity access the iSeries 
>business critical data is via stored procedures, triggers, views, etc.

Without a _very_ good reason to break it, my rule is read (select) from
the DB is ok, but ALL updates must go through stored procs. So yes,
we're on the same page. However, I will allow select against base
tables.

>cost of building and maintaining the COM AND the administration of a
>PC server upon which it runs.

COM doesn't need a server. Sounds like the vendor is proposing an n-tier
architecture where the client machines communicate via DCOM with a
application server which then communicates with the iSeries. That's not
a requirement w/in COM. If you're willing to have the client app
communicate directly w/the iSeries you can dispose of the DCOM and
server requirements. 

Also, if nothing is coded yet, why are you going thick-client? What's
the application requirement that prevents a browser-based solution? If
nothing is coded, I'd go .NET instead of COM. And w/o a good requirement
I'd go browser-based vs. thick client.

-Walden


------------
Walden H Leverich III
Tech Software
(516) 627-3800 x3051
WaldenL@xxxxxxxxxxxxxxx
http://www.TechSoftInc.com

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