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

Response to input from Eric DeLong, Walden H. Leverich and James
Reinardy... those are the people I've seen respond on this so far.

Eric... Wow, COM and DCOM  "dead, Dead, DEAD"...   heavens, that can't
be true because a "consultant"/developer told our management COM and
Object methodology was THE way to develop and vendors are basically
believed like gods.      Seriously, your note leaped off the page and
made me feel good.   However, I'm not sure how .NET provides something
similar/better in the way of the promise of COM which is to make access
to data, actions on data, etc., "transparent" to developers.  From what
I've seen .NET is .ASP enhanced, which is to say a programming language
used mainly for web development.

To clarify for you all... the new application in development I spoke
about... I believe it is developed in VB, probably the latest.  I'll
have to check with the programmer/vendor.   As to the COM thing... the
vendor/developer convinced management that he could deliver, in addition
to the application in development, a COM/DCOM facility that would make
access to their main business application's data easier for future
developers and he could also attached what he is developing to the COM
if and when necessary.  The COM "entity" is a separate deliverable.   
But, he says, COM is the way to go because as everyone knows, it is
acknowledged far and wide as the best way to create applications and
access data. (tongue in cheek)   

Walden... so why am I putting business rules in the COM???  The vendor
did in the COM he wrote for another city and what he is using as his
bona fides that his idea works and will work in our environment.   

I've told the vendor about a week ago the only way I'll let his COM
entity access the iSeries business critical data is via stored
procedures, triggers, views, etc.    So you and I are on the same
page... a "wrapper"  IF we go with the COM idea at all.

What management here doesn't realize yet is very little of what he did
for the other customer can be REUSED for us (hummmm, isn't that one of
the selling points of OO?).  Basically he will be paid for developing a
COM proof of concept with me creating what's under the wrapper (stored
procedures, etc. helping him understand the data structure and how the
data is stored, etc).   What he will create is the COM object and an XML
catalog.  

Walden, I'm still not convinced that a COM-like environment, for a shop
that doesn't have much development done by vendors or employees is worth
the cost of building and maintaining the COM AND the administration of a
PC server upon which it runs.   It would appear to me that unless you
have lots of development the ROI is just not there even with your
argument that infrequent use could be facilitated by a COM entity.   So,
convince me of the ROI based on what I just said.   I'll listen.

James... your insights to me via Walden are well taken.   I was
wondering where COM/DCOM set on the logarithmic scale of new, better
mousetrap, application tools, techniques and methodologies; ones that
really work.   I used to sell "silver bullets" for IBM and METAGroup,
and because of my IT and business background, knew which ones were
workable and which were "vaporware".

To all... bottom line... I can see where a COM methodology might be of
some value, but it sounds like building on that technology is a losing
proposition in favor or .NET.   So, if I haven't built the COM yet, why
do it?    Also bottom line... I'm still not convinced for a shop without
lots of development the cost of maintaining the COM or .NET
environments, as far as Object access to data, is worth the benefit when
compared to creating the necessary stored procedures, triggers, views,
etc., as necessary, along with some sort of document letting developers
know what access methods, triggers, etc., I've built for them.    But, I
can be convinced if someone will make sufficient arguments.

Thanks in advance,

Dave Odom