| Author |
Message |
|
Rob Hooke
#1 / 10
|
 .NET: COM vs NET Hi All, We are starting a large new project with C++, with an intended release date
of 2005. We are starting completely "from scratch", from design up. (or is
that design down?)
We intend to have:
* 80% of the code as pure, portable, C++ objects,
* 10% of the code as a simple client side UI app,
* and 10% of the code as some sort of COM layer that allows us to run the
whole lot on a single machine, and/or on 2 machines on a LAN, and/or on 2
machine across the Net.
We currently have some experimental code working with DCOM, and all is
working well.
Now, with .NET just around the corner, we are wondering if "COM" is the
direction we should be taking. We've looked at the Beta of VS-NET, and
VC.Net in particular. My VC6 DCOM code compiles thru VC7 just fine, and it
runs...
All the documentation seems to indicate that using the new "attributes"
makes "COM programming easier", and that (D)COM for RPCs is still valid, but
thats not what I am hearing from people supposedly in the "know".
My question is: Is (D)COM still a valid, and acceptable way to remote a
ClientUI from the ServerObjects, is there a better way? Is Microsoft telling
us we should drop COM, and use the .NET framework instead (and what doies
that even mean? Does it mean "use NET objects on the
CommonLanguageRuntime"?)
Any thoughts much appreciated,
Robert.
|
| Sun, 08 Jun 2003 21:58:13 GMT |
|
 |
|
Tomas Restrep
#2 / 10
|
.NET: COM vs NET Hi Rob, Quote: > My question is: Is (D)COM still a valid, and acceptable way to remote a
> ClientUI from the ServerObjects, is there a better way?
Is certainly valid. As to better or not, that very much depends on your needs, expectations and what you hope to accomplish. COM is not going away anytime soon, too much depends on it, but I can't predict what will happen 5 years from now :) Quote: > Is Microsoft telling
> us we should drop COM, and use the .NET framework instead (and what doies
> that even mean? Does it mean "use NET objects on the
> CommonLanguageRuntime"?)
Most likely. .NET can use multiple channels/transports/formatters(serializers). The most common will be those that ship with the runtime, which are SOAP over HTTP and a binarry formatter (or SOAP) on top of TCP, but you can extend the architecture to provide aditional channels/transports and formatters. --
Tomas Restrepo [VC++ MVP]
http://www.mvps.org/windev/
|
| Mon, 09 Jun 2003 02:12:34 GMT |
|
|
|
Frederic Clau
#3 / 10
|
.NET: COM vs NET Quote: > > Is Microsoft telling > > us we should drop COM, and use the .NET framework instead (and what doies > > that even mean? Does it mean "use NET objects on the > > CommonLanguageRuntime"?) > Most likely. .NET can use multiple
> channels/transports/formatters(serializers). The most common will be those
> that ship with the runtime, which are SOAP over HTTP and a binarry
formatter
> (or SOAP) on top of TCP, but you can extend the architecture to provide
> aditional channels/transports and formatters.
SOAP could be very easily integrated into VC6 with specific proxy/stubs (new version of MIDL) and a derived version of CIS for the transport. .NET 's considerations are elsewhere. BTW, I've not used the SOAP toolkit yet, what does it provide exactly ? --
Frederic Claux
|
| Tue, 10 Jun 2003 00:20:54 GMT |
|
|
|
Vagif Abilo
#4 / 10
|
.NET: COM vs NET Quote: > We are starting a large new project with C++, with an intended release
date
> of 2005. We are starting completely "from scratch", from design up. (or is
> that design down?)
Wow! You got plenty of time! I wish I had to release my stuff in 5 years. But then I would probably spend couple of years on prototyping, and only then decide which technology to use. If I had to ship in 2002, I would definitely choose .NET. --
Vagif Abilov
|
| Tue, 10 Jun 2003 00:58:05 GMT |
|
|
|
Todd
#5 / 10
|
.NET: COM vs NET 5 years?! you work for the federal government, don't you?
Quote: > Hi All, > We are starting a large new project with C++, with an intended release
date
> of 2005. We are starting completely "from scratch", from design up. (or is
> that design down?)
> We intend to have:
> * 80% of the code as pure, portable, C++ objects,
> * 10% of the code as a simple client side UI app,
> * and 10% of the code as some sort of COM layer that allows us to run the
> whole lot on a single machine, and/or on 2 machines on a LAN, and/or on 2
> machine across the Net.
> We currently have some experimental code working with DCOM, and all is
> working well.
> Now, with .NET just around the corner, we are wondering if "COM" is the
> direction we should be taking. We've looked at the Beta of VS-NET, and
> VC.NET in particular. My VC6 DCOM code compiles thru VC7 just fine, and it
> runs...
> All the documentation seems to indicate that using the new "attributes"
> makes "COM programming easier", and that (D)COM for RPCs is still valid,
but
> thats not what I am hearing from people supposedly in the "know".
> My question is: Is (D)COM still a valid, and acceptable way to remote a
> ClientUI from the ServerObjects, is there a better way? Is Microsoft
telling
> us we should drop COM, and use the .NET framework instead (and what doies
> that even mean? Does it mean "use NET objects on the
> CommonLanguageRuntime"?)
> Any thoughts much appreciated,
> Robert.
|
| Wed, 11 Jun 2003 00:08:21 GMT |
|
|
|
MSFT
#6 / 10
|
.NET: COM vs NET
Quote: > 5 years?! you work for the federal government, don't you?
> > Hi All,
> > We are starting a large new project with C++, with an intended release
> date
> > of 2005. We are starting completely "from scratch", from design up. (or
is
> > that design down?)
> > We intend to have:
> > * 80% of the code as pure, portable, C++ objects,
> > * 10% of the code as a simple client side UI app,
> > * and 10% of the code as some sort of COM layer that allows us to run
the
> > whole lot on a single machine, and/or on 2 machines on a LAN, and/or on
2
> > machine across the Net.
> > We currently have some experimental code working with DCOM, and all is
> > working well.
> > Now, with .NET just around the corner, we are wondering if "COM" is the
> > direction we should be taking. We've looked at the Beta of VS-NET, and
> > VC.NET in particular. My VC6 DCOM code compiles thru VC7 just fine, and
it
> > runs...
> > All the documentation seems to indicate that using the new "attributes"
> > makes "COM programming easier", and that (D)COM for RPCs is still valid,
> but
> > thats not what I am hearing from people supposedly in the "know".
> > My question is: Is (D)COM still a valid, and acceptable way to remote a
> > ClientUI from the ServerObjects, is there a better way? Is Microsoft
> telling
> > us we should drop COM, and use the .NET framework instead (and what
doies
> > that even mean? Does it mean "use NET objects on the
> > CommonLanguageRuntime"?)
In .NET, you would have a couple of options. You could use object remoting, which has a model that is similar to DCOM, in that you have static connections to objects. Or, you could use Web Services, which is a connectionless protocol, and uses
SOAP to send XML information across http.
Which one would work best for you depends upon your architecture and needs.
If you're planning on running across the internet (and not a local net),
SOAP can make life a lot easier, as you don't really have the DCOM setup
issues.
|
| Wed, 11 Jun 2003 00:40:24 GMT |
|
|
|
Rob Hooke
#7 / 10
|
.NET: COM vs NET Quote: > 5 years?! you work for the federal government, don't you?
Nope, I just work for that rarest of companies, large, rich, patient, and future thinking! Sometimes I pinch myself to make sure I'm not dreaming! haha. Quote: > In .NET, you would have a couple of options. You could use object
remoting,
> which has a model that is similar to DCOM, in that you have static
> connections to objects.
Hmmm ok, I think this sounds like us. The closest thing I can compare our app to is AutoC*D. Imagine that the AutoC*D objects and functionaliuty are pretty much pure C++ with no COM stuff, (about 80% of the code), followed by a 10% layout of COM or .NET or something on top of that. And finally a 10% UI which handles mouse, keyboard, screen draws etc, and can be on a different machine to the core. Under the "DCOM" model, this is working pretty well, and we'd be keen to use that same type of "model" in NET I think. Its also important to us that the package runs on single machine just as
well as on 2 machines on a LAN, just as well as 2 machines on the
Internet... preferable without having to change our code for those different
cases, and without having to have the "single machine" case needing to have
IIS and\or NT server installed....
DCOM seems to let us do all of that ok (the 2 machines on the internet case
is a bit more tricky admittedly).
We NET make it easier or harder to achieve this goal of "single machine" up
to "2 machines on the internet"?
Rob.
Quote:
> > 5 years?! you work for the federal government, don't you?
> > > Hi All,
> > > We are starting a large new project with C++, with an intended release
> > date
> > > of 2005. We are starting completely "from scratch", from design up.
(or
> is
> > > that design down?)
> > > We intend to have:
> > > * 80% of the code as pure, portable, C++ objects,
> > > * 10% of the code as a simple client side UI app,
> > > * and 10% of the code as some sort of COM layer that allows us to run
> the
> > > whole lot on a single machine, and/or on 2 machines on a LAN, and/or
on
> 2
> > > machine across the Net.
> > > We currently have some experimental code working with DCOM, and all is
> > > working well.
> > > Now, with .NET just around the corner, we are wondering if "COM" is
the
> > > direction we should be taking. We've looked at the Beta of VS-NET, and
> > > VC.NET in particular. My VC6 DCOM code compiles thru VC7 just fine,
and
> it
> > > runs...
> > > All the documentation seems to indicate that using the new
"attributes"
> > > makes "COM programming easier", and that (D)COM for RPCs is still
valid,
> > but
> > > thats not what I am hearing from people supposedly in the "know".
> > > My question is: Is (D)COM still a valid, and acceptable way to remote
a
> > > ClientUI from the ServerObjects, is there a better way? Is Microsoft
> > telling
> > > us we should drop COM, and use the .NET framework instead (and what
> doies
> > > that even mean? Does it mean "use NET objects on the
> > > CommonLanguageRuntime"?)
> In .NET, you would have a couple of options. You could use object
remoting,
> which has a model that is similar to DCOM, in that you have static
> connections to objects.
> Or, you could use Web Services, which is a connectionless protocol, and
uses
> SOAP to send XML information across http.
> Which one would work best for you depends upon your architecture and
needs.
> If you're planning on running across the internet (and not a local net),
> SOAP can make life a lot easier, as you don't really have the DCOM setup
> issues.
|
| Sun, 15 Jun 2003 15:01:16 GMT |
|
|
|
Andy Bolstridg
#8 / 10
|
.NET: COM vs NET do you really care? Consider your UI - is it Web base, or VB or x/motif or whatever!? If its only 10% and properly decoupled from your core application, I'm sure it doesn't exactly matter what technology you use for display, and besides general thinking on how it will look to the user, you don't have to implement it for years. The same applies to the distribution layer - DCOM/.NET/EJB/CORBA.. who
cares! Decide now on how you want it to be accessed (cosider things like
state and connection-oriented v connectionless, etc) and you can change the
distribution layer to be whatever is in vogue 4 years down the line.
Cheers, Andy.
Quote: > Hi All, > We are starting a large new project with C++, with an intended release
date
> of 2005. We are starting completely "from scratch", from design up. (or is
> that design down?)
> We intend to have:
> * 80% of the code as pure, portable, C++ objects,
> * 10% of the code as a simple client side UI app,
> * and 10% of the code as some sort of COM layer that allows us to run the
> whole lot on a single machine, and/or on 2 machines on a LAN, and/or on 2
> machine across the Net.
> We currently have some experimental code working with DCOM, and all is
> working well.
> Now, with .NET just around the corner, we are wondering if "COM" is the
> direction we should be taking. We've looked at the Beta of VS-NET, and
> VC.NET in particular. My VC6 DCOM code compiles thru VC7 just fine, and it
> runs...
> All the documentation seems to indicate that using the new "attributes"
> makes "COM programming easier", and that (D)COM for RPCs is still valid,
but
> thats not what I am hearing from people supposedly in the "know".
> My question is: Is (D)COM still a valid, and acceptable way to remote a
> ClientUI from the ServerObjects, is there a better way? Is Microsoft
telling
> us we should drop COM, and use the .NET framework instead (and what doies
> that even mean? Does it mean "use NET objects on the
> CommonLanguageRuntime"?)
> Any thoughts much appreciated,
> Robert.
|
| Wed, 25 Jun 2003 00:27:30 GMT |
|
|
|
Richard Grimes [MVP
#9 / 10
|
.NET: COM vs NET
Quote: > Now, with .NET just around the corner, we are wondering if "COM" is the
> direction we should be taking. We've looked at the Beta of VS-NET, and
> VC.NET in particular. My VC6 DCOM code compiles thru VC7 just fine, and it
> runs...
> All the documentation seems to indicate that using the new "attributes"
> makes "COM programming easier", and that (D)COM for RPCs is still valid,
but
> thats not what I am hearing from people supposedly in the "know".
> My question is: Is (D)COM still a valid, and acceptable way to remote a
> ClientUI from the ServerObjects, is there a better way? Is Microsoft
telling
> us we should drop COM, and use the .NET framework instead (and what doies
> that even mean? Does it mean "use NET objects on the
> CommonLanguageRuntime"?)
Depends on what you are using DCOM for. If you want connections over the internet or between several private networks on a WAN, then DCOM is not for you. If you are on a LAN, then DCOM is fine, it maintains the connections for you making sure that dead clients do not turn objects into zombies, has security integrated into NT etc. It is not clear yet what services MS will come up with in its '.NET
strategy', I'm not even sure I know what it is anyway. Thus it pays to be as
flexible as possible. If you have an experienced C++ team and intend to use
facilities that .NET does not cater for then it makes sense to do unmanaged
C++ development. But keep your options open and make sure that any class
that is useful has COM support (class factory, interfaces), this will allow
you to use the same _binary_ in managed code if you decide to move over to
.NET later.
Richard
--
www.grimes.demon.co.uk
|
| Fri, 25 Jul 2003 00:43:57 GMT |
|
| |
|
