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

Walden,

I agree with your statements below, but would make a clear distinction
between COM and DCOM in this context.  DCOM never really took off, and
has been a security headache for Microsoft. At this point, if COM is
surviving, DCOM is on life support.  We have one application using it
here, and I have been counseling the group responsible for it to
strongly consider a different technology, as I expect that someday we
will see Microsoft just drop DCOM support in a new OS release. 

Jim Reinardy

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Walden H. Leverich
Sent: Thursday, December 15, 2005 8:35 AM
To: Midrange Systems Technical Discussion
Subject: RE: COM/DCOM - Good or Bad as access strategy to iSeries

>While I'm certainly not an expert on Microsoft development strategy, 
>it's my understanding that COM and DCOM are dead, Dead, DEAD!


Wow, you beat me to the punch here... And I _almost_ agree. If you were
going to start a new development project I'd say, without reservation,
that the only MS development strategy that makes sense is .NET. It's new
(not too new :)) performs well, handles network deployment wonderfully,
and is managed so you have things like garbage collection -- something
sorely missing w/COM. 

HOWEVER, Dave mentioned an "application currently in development" so
it's possible that the existing application is COM based (VB6?) and it
wouldn't be able to invoke .NET objects. Now, you can expose a COM
interface from a .NET object, but sometimes it's easier to just use COM.

Secondly, there are many places you can consume COM objects from, and
only a few you can consume .NET objects from. I can consume COM objects
from the command line (via scripting), from all the office products in a
VBA macro, from other development languages list ColdFusion,
PowerBuilder, Delphi, etc. Heck, I can consume COM objects from inside a
Client Access Emulation Session via a macro. Will all these eventually
support .NET objects, I'm sure, but today they only support COM objects.

Now, having said all that, I would plan on using .NET objects and
exposing COM interfaces where necessary, but I'd be aware of the fact
that in some cases COM development still makes lots of sense, and will
for several/many years.

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


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of DeLong, Eric
Sent: Wednesday, December 14, 2005 6:51 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: COM/DCOM - Good or Bad as access strategy to iSeries

Whoa!  Hold on a second......

While I'm certainly not an expert on Microsoft development strategy,
it's my understanding that COM and DCOM are dead, Dead, DEAD!  Do NOT
pursue development in COM/DCOM, as it has been replaced by .NET......  

Steve Richter?  Care to comment?

Eric DeLong
Sally Beauty Company
MIS-Project Manager (BSG)
940-297-2863 or ext. 1863



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Dave Odom
Sent: Wednesday, December 14, 2005 5:28 PM
To: midrange-l@xxxxxxxxxxxx
Subject: COM/DCOM - Good or Bad as access strategy to iSeries


Walden, Scott and any others that have experience with COM/DCOM/OBJECT
Theory and practical application AND application development AND 
SQL-based relational data base access.    This related to the iSeries.

Management here has been sold it is a general good to have a COM/DCOM
environment built for access to company critical application data on the
iSeries.   They not only believe that COM/DCOM is a "best way" to
provide access to iSeries for a Windows application currently in
development but can also provide a preferred access methodology for
future applications programmers to easily gain access to various
application's data without having to know anything about the data
structures, data relationships or how the data is manifest in the files
as put there by the various applications. 

I understand the overall concepts of the Object world and I understand
what it is SUPPOSED to do.  However, experience with large Object
application development projects in another life tells me putting the
theory into practice is no easy thing to accomplish and has often doomed
projects.   But my concern here is not only that.  I don't believe it
provides any real ROI/VALUE ADD in a non-software development intensive
environment.  

I understand that once all the projected data access, data manipulation,
trigger-like and stored procedure-like functions are done in COM
Objects, programmers and others will no longer need to worry about
"knowing" or understanding the data storage layer.  On the surface
that sounds like a good.   I understand the theory of the supposed gains
in productivity.    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.

Also with COM/DCOM, as it is a Microsoft environment, there is a need
for a PC and that adds in another thing to administer and, to me, a no
value "pipe/gate" between the iSeries data and the application wherever
it resides.

I like to keep an open mind and keep moving to new methodologies and
technologies where it really moves things to a new more valuable level. 
I guess I really question the true VALUE ADD of COM/DCOM in most shops
that aren't into doing lots of application development.

I'd like your opinions, war stories, fairy tails [hopefully you all know
the difference between a war story and a fairy tale].

Thanks in advance,

Dave 




--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.