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

>But... I'm wondering is there any real positive ROI between COM 
>and providing essentially the same thing via native stored procedures,
>triggers, views, etc. along with some sort of data access 
>"dictionary" or catalog as to what is available.  It seems 
>administration of those entities vs. administration of the COM/DCOM 
>class library and XML catalog is about the same. 

Why are you putting the business rules into the COM objects? Why not
make the COM objects wrappers around the "native stored procedures,
triggers, views, etc."

One of the great advantages of COM (and .NET) vs the dictionary or
catalog approach is the fact that COM objects are self-describing. That
is, any self-respecting development environments shows you the
properties and methods available on an object. MS calls it Intellisense
in their tools, but other tools have the same thing. Basically the IDE
guides you through coding the call statement. Especially in an
environment where programmers aren't using these objects every day, 8
hours a day, to have the IDE guide you through the call is priceless.
Keep in mind, this isn't a wizard-like thing that gets in your way, it's
actually useful.

>putting the theory into practice is no easy thing to accomplish 
>and has often doomed projects

My experience says that those that hold onto the OO world with blinders
on are what cause OO projects to fail. Bottom line is sometimes it's
better to allow the programmer to query the database directly. An
intelligent use of objects is a boon to a application development
process, OO-extremeists are a curse.

>war stories, fairy tails [hopefully you all know the 
>difference between a war story and a fairy tale]

Isn't the Lord of the Rings a war story fairy tale? <G>

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