I i'm planning a DCOM project, i just which to ensure that the NET tecknology
is not a replacing distributed tecknology.
Will NET be a new COM/DCOM replcement platform, should I wait ?
Thanks for your time.
Printable View
I i'm planning a DCOM project, i just which to ensure that the NET tecknology
is not a replacing distributed tecknology.
Will NET be a new COM/DCOM replcement platform, should I wait ?
Thanks for your time.
Yes, .NET is a replacement for COM. As for DCOM, .NET remoting and web services
are replacements.
/Pat
"MrRolf" <rolf@ctrl-it.no> wrote:
>
>I i'm planning a DCOM project, i just which to ensure that the NET tecknology
>is not a replacing distributed tecknology.
>
>Will NET be a new COM/DCOM replcement platform, should I wait ?
>
>Thanks for your time.
Patrick, Can i conclude with your reply that My finish DCOM project in the
NET future will not have to be changed that much, due to the interfaces and
infrastructure.
(Assumes the NET remoting , are low level remote invocation )
"Patrick Troughton" <Patrick@Troughton.com> wrote:
>
>Yes, .NET is a replacement for COM. As for DCOM, .NET remoting and web services
>are replacements.
>
>/Pat
>
>"MrRolf" <rolf@ctrl-it.no> wrote:
>>
>>I i'm planning a DCOM project, i just which to ensure that the NET tecknology
>>is not a replacing distributed tecknology.
>>
>>Will NET be a new COM/DCOM replcement platform, should I wait ?
>>
>>Thanks for your time.
>
In article <3cebbc68$1@10.1.10.29> (from MrRolf <rolf@ctrl-it.no>),
> I i'm planning a DCOM project, i just which to ensure that the NET tecknology
> is not a replacing distributed tecknology.
>
> Will NET be a new COM/DCOM replcement platform, should I wait ?
"Is COM Dead?", MDSN Magzine, Dec 2000, Don Box
http://msdn.microsoft.com/msdnmag/is...om/com1200.asp
--
Patrick Steele
Microsoft .NET MVP
I'm just beginning to learn .NET Remoting myself so there's only so much I
can say. There are certainly differences between these two technologies.
.NET Remoting gives you a lot of more flexibility than DCOM. For example,
you can choose between HTTP or TCP as your protocol, you can choose to format
your messages as SOAP, as a binary format or even create your own format.
Unlike DCOM, .NET Remoting requires that you use a host for your distributing
objects. You can use IIS or create your own host. So there are some issues
that need to be addressed. If your objects keep the same interface, then
there shouldn't be too many changes (or any at all) on that end of things.
The actual VB6-to-VB.NET source code conversion will require more work than
the DCOM-to-.NET Remoting conversion. And again, you can also use web services
if you want.
Apress has a book on .NET Remoting called Advanced .NET Remoting. I've heard
some pretty good things about it and just ordered a copy myself....
http://www.apress.com/book/bookDisplay.html?bID=47
Having said that, hopefully someone else will step in and fill in the parts
I left out (and correct any mistakes I've made)....
/Pat
<vb.@127.0.0.1> wrote:
>
>Patrick, Can i conclude with your reply that My finish DCOM project in the
>NET future will not have to be changed that much, due to the interfaces
and
>infrastructure.
>
>(Assumes the NET remoting , are low level remote invocation )
>
>
>"Patrick Troughton" <Patrick@Troughton.com> wrote:
>>
>>Yes, .NET is a replacement for COM. As for DCOM, .NET remoting and web
services
>>are replacements.
>>
>>/Pat
"Patrick Steele [MVP]" <patrick@mvps.org> wrote in message > "Is COM Dead?",
MDSN Magzine, Dec 2000, Don Box
> http://msdn.microsoft.com/msdnmag/is...om/com1200.asp
>
That's one heckofa old article...in computing terms...
rgds
John Butler
In article <3cec1b68@10.1.10.29> (from John Butler
<nospamjrbutler@btinternet.com>),
>
> "Patrick Steele [MVP]" <patrick@mvps.org> wrote in message > "Is COM Dead?",
> MDSN Magzine, Dec 2000, Don Box
> > http://msdn.microsoft.com/msdnmag/is...om/com1200.asp
> >
>
> That's one heckofa old article...in computing terms...
<grin> Yeah, but it's got some good answers to those "COM vs .NET"
questions.
--
Patrick Steele
Microsoft .NET MVP
This seems to be a topic that Microsoft doesn't really want to talk about.
As you point out and this is also my understanding, Net Remoting requires
the server side component to be hosted by IIS or you have to write your own
hosting exe. This seems to me what COM+ and previously MTS was supposed
to do. I remember that the entire Microsoft pitch for MTS,COM+ was that
it was a transaction broker, object pool manager, etc. and it would make
a developer's life for n-tier development a joy to behold. Now I start reading
articles in MSDN that are basically saying the COM+, MTS is too much overhead
and you should now use Net Remoting. However, you'll have to host your server
side components in IIS using Web Services or you own version of Web Services
and you manage transactability and object pooling etc. I find this all too
confusing. It is still my assumption that a transaction/object broker like
COM+ is still a value for N-Tier development. But Microsoft is now delivering
a message that is attempting to steer developers away from COM+ services.
I have a suspicion that Microsoft's has run into problems in developing
an object/transaction broker for .Net components and they have not been able
to announce a product. So in the meantime, MS is telling everyone that COM+
is not the way to go anymore but you should use .Net but you figure how to
replicate the functionality provided by a object/transaction broker. But
sometime in 2003 or later, they'll announce a .Net object/transaction broker
and announcements will be made that N-Tier development should use this new
product because it will provide all the benefits of an object/transaction
broker plus more. Basically, they'll say that the features of COM+ are
still relevant but we were unable to deliver this functionality for .Net
so we steered you way from COM+ and left you in limbo for a couple of years.
And oh by the way, all the code you had to write to replicate the functionality
of COM+ as an interim stage was a waste of time. Thanks for buying Microsoft.
This has been one of my biggest concerns about the Microsoft Development
Message over the years. One year they will tell you that method A is the
best way to develop an applicaiton. Year two comes along and they will then
say that method A wasn't really very good and you should use method B. Year
three comes along and method B is now on the garbage heap. And so on and
so on. At some point, software development has to stop being a business
of tool development and use and more about delivering products that customers
need and want. As long as developers have to spend more time worrying about
new technology and how to use it and less time on delivering functionality,
the software business will continue to be a fringe industry in constant turmoil.
"Patrick Troughton" <Patrick@Troughton.com> wrote:
>
>I'm just beginning to learn .NET Remoting myself so there's only so much
I
>can say. There are certainly differences between these two technologies.
>.NET Remoting gives you a lot of more flexibility than DCOM. For example,
>you can choose between HTTP or TCP as your protocol, you can choose to format
>your messages as SOAP, as a binary format or even create your own format.
>Unlike DCOM, .NET Remoting requires that you use a host for your distributing
>objects. You can use IIS or create your own host. So there are some issues
>that need to be addressed. If your objects keep the same interface, then
>there shouldn't be too many changes (or any at all) on that end of things.
>The actual VB6-to-VB.NET source code conversion will require more work than
>the DCOM-to-.NET Remoting conversion. And again, you can also use web services
>if you want.
>
>Apress has a book on .NET Remoting called Advanced .NET Remoting. I've heard
>some pretty good things about it and just ordered a copy myself....
>
>http://www.apress.com/book/bookDisplay.html?bID=47
>
>Having said that, hopefully someone else will step in and fill in the parts
>I left out (and correct any mistakes I've made)....
>
>/Pat
>
><vb.@127.0.0.1> wrote:
>>
>>Patrick, Can i conclude with your reply that My finish DCOM project in
the
>>NET future will not have to be changed that much, due to the interfaces
>and
>>infrastructure.
>>
>>(Assumes the NET remoting , are low level remote invocation )
>>
>>
>>"Patrick Troughton" <Patrick@Troughton.com> wrote:
>>>
>>>Yes, .NET is a replacement for COM. As for DCOM, .NET remoting and web
>services
>>>are replacements.
>>>
>>>/Pat
>
Ed,
What's that? Do I hear the independant thought alarm going off? You'll
get no sympathy from many of the guys that post here, they can't think for
themselves. To them, everything MS says is like the word of god.
I couldn't agree with you more. Windows DNA was a complete and total flop.
I have friends at consulting companies that have worked closely with MS
and still had to abandon transaction server and Com+ apps in favor of a
solution based on stored procedures on the SQL server.
MS won't admit that something is a problem until they have an answer for
it. Remember when no one could possible want to lock an individual record
in SQL Server? When 7 came out it was suddenly a problem and they happened
to have a solution.
Someday the people here will wake up and see what a load they are being handed.
Tom
"Ed" <ed_raffin@hotmail.com> wrote:
>This has been one of my biggest concerns about the Microsoft Development
>Message over the years. One year they will tell you that method A is the
>best way to develop an applicaiton. Year two comes along and they will
then
>say that method A wasn't really very good and you should use method B.
Year
>three comes along and method B is now on the garbage heap. And so on and
>so on. At some point, software development has to stop being a business
>of tool development and use and more about delivering products that customers
>need and want. As long as developers have to spend more time worrying about
>new technology and how to use it and less time on delivering functionality,
>the software business will continue to be a fringe industry in constant
turmoil.
On 25 May 2002 20:58:10 -0800, "Tom Bennet" <fsdfds@fdsfds.com> wrote:
>Someday the people here will wake up and see what a load they are being handed.
No, I don't think they will. Too much loss of face. Easier just to
slumber on.
MM
"Ed" <ed_raffin@hotmail.com> wrote in message news:3cefc5db$1@10.1.10.29...
> This has been one of my biggest concerns about the Microsoft Development
> Message over the years. One year they will tell you that method A is the
> best way to develop an applicaiton. Year two comes along and they will
then
> say that method A wasn't really very good and you should use method B.
Year
> three comes along and method B is now on the garbage heap. And so on and
> so on.
How are other companies different?
The issue you raise is a valid concern but, any attempt to cast it as a
Microsoft [-only] problem is misguided IMO. Before J2EE all the J2EE vendors
were pushing/selling/positioning whatever products/technology they had at
the time as the OneTrueWay(r) weren't they?
> At some point, software development has to stop being a business
> of tool development and use and more about delivering products that
customers
> need and want.
I disagree. It has to be both. The advances in tool development drives the
ability to develop those products...
Kunle
The process of deprecation your talking about is not confined only to M$ platforms.
All technology platforms reinvent/refactor themselves. Maybe M$ has done
so in a more consistent basis (market driven), but the same can be said in
the java world (every new release of the JDK has methods depracated in the
framework.. design practices change in the java world , ok Sun, should we
or should we NOT use stored procedures to speed up retrievals! OK, do entity
beans suck or not?(I know the answer so dont bother)) They seem to change
their mind every two years..) Anyways, its probably because you work in the
MS world and not other tech circles that you feel the frustration of refactoring/relearning.
The fact is, they discover and create "better" ways to accomplish tasks
every day and want to relay that information to the customer. Also, M$'s
marketing department's a bunch a guys with their hair on fire who justify
their paychecks by re-"branding" M$ technologies (MTS<evolved-to/>COM+Services<evolved-to/>?).
Thats annoying, but thats big biz.. Being a programmer can be annoying too,
because once we feel like we got this platform down packed, they change it.
All in all, its the nature of this business.. There is no "silver-bullet"
technology that will never change (although the wheel is standing the test
of time..its been refactored a few times I guess..). my $.02
~aaron
"Ed" <ed_raffin@hotmail.com> wrote:
>
>This seems to be a topic that Microsoft doesn't really want to talk about.
> As you point out and this is also my understanding, Net Remoting requires
>the server side component to be hosted by IIS or you have to write your
own
>hosting exe. This seems to me what COM+ and previously MTS was supposed
>to do. I remember that the entire Microsoft pitch for MTS,COM+ was that
>it was a transaction broker, object pool manager, etc. and it would make
>a developer's life for n-tier development a joy to behold. Now I start
reading
>articles in MSDN that are basically saying the COM+, MTS is too much overhead
>and you should now use Net Remoting. However, you'll have to host your
server
>side components in IIS using Web Services or you own version of Web Services
>and you manage transactability and object pooling etc. I find this all
too
>confusing. It is still my assumption that a transaction/object broker like
>COM+ is still a value for N-Tier development. But Microsoft is now delivering
>a message that is attempting to steer developers away from COM+ services.
> I have a suspicion that Microsoft's has run into problems in developing
>an object/transaction broker for .Net components and they have not been
able
>to announce a product. So in the meantime, MS is telling everyone that
COM+
>is not the way to go anymore but you should use .Net but you figure how
to
>replicate the functionality provided by a object/transaction broker. But
>sometime in 2003 or later, they'll announce a .Net object/transaction broker
>and announcements will be made that N-Tier development should use this new
>product because it will provide all the benefits of an object/transaction
>broker plus more. Basically, they'll say that the features of COM+ are
>still relevant but we were unable to deliver this functionality for .Net
>so we steered you way from COM+ and left you in limbo for a couple of years.
> And oh by the way, all the code you had to write to replicate the functionality
>of COM+ as an interim stage was a waste of time. Thanks for buying Microsoft.
>
>This has been one of my biggest concerns about the Microsoft Development
>Message over the years. One year they will tell you that method A is the
>best way to develop an applicaiton. Year two comes along and they will
then
>say that method A wasn't really very good and you should use method B.
Year
>three comes along and method B is now on the garbage heap. And so on and
>so on. At some point, software development has to stop being a business
>of tool development and use and more about delivering products that customers
>need and want. As long as developers have to spend more time worrying about
>new technology and how to use it and less time on delivering functionality,
>the software business will continue to be a fringe industry in constant
turmoil.
Regarding the technical issues your talking about:
"Ed" <ed_raffin@hotmail.com> wrote:
>
>This seems to be a topic that Microsoft doesn't really want to talk about.
> As you point out and this is also my understanding, Net Remoting requires
>the server side component to be hosted by IIS or you have to write your
own
>hosting exe. This seems to me what COM+ and previously MTS was supposed
>to do.
.NET remoting is one of .NET's remoting mechanisms, COM+ services and MTS
are MS's application server service environments.
>I remember that the entire Microsoft pitch for MTS,COM+ was that
>it was a transaction broker, object pool manager, etc. and it would make
>a developer's life for n-tier development a joy to behold. Now I start
>reading
>articles in MSDN that are basically saying the COM+, MTS is too much >overhead
>and you should now use Net Remoting.
Where is the article that states this? Again, .NET remoting is MS .NET's
remoting mechanism, NOT the application server. COM+ enterprise services
have been "re-branded" to Enterprise Services in a Microsoft .NET server.
>However, you'll have to host your server
>side components in IIS using Web Services or you own version of Web Services
>and you manage transactability and object pooling etc. I find this all
too
>confusing. It is still my assumption that a transaction/object broker like
>COM+ is still a value for N-Tier development. But Microsoft is now delivering
>a message that is attempting to steer developers away from COM+ services.
They are trying to move people to Enterprise Services and not use COM+ services
because it delivers new features which may help you. (it has more features
so technically, its better)
http://msdn.microsoft.com/library/de...tml/pc0012.asp
> I have a suspicion that Microsoft's has run into problems in developing
>an object/transaction broker for .Net components and they have not been
able
>to announce a product. So in the meantime, MS is telling everyone that
COM+
>is not the way to go anymore but you should use .Net but you figure how
to
>replicate the functionality provided by a object/transaction broker. But
>sometime in 2003 or later, they'll announce a .Net object/transaction broker
>and announcements will be made that N-Tier development should use this new
>product because it will provide all the benefits of an object/transaction
>broker plus more. Basically, they'll say that the features of COM+ are
>still relevant but we were unable to deliver this functionality for .Net
>so we steered you way from COM+ and left you in limbo for a couple of >years.
again.. Your ascension out of limbo starts here..
http://msdn.microsoft.com/library/de...tml/pc0012.asp
> And oh by the way, all the code you had to write to replicate the >functionality
>of COM+ as an interim stage was a waste of time. Thanks for buying >Microsoft.
>
if your happy with COM+ Services, why change? If COM+ services fixed your
business problem, why change/upgrade? Its like saying I can't drive my audi80
because the A4 was released.?
>This has been one of my biggest concerns about the Microsoft Development
>Message over the years. One year they will tell you that method A is the
>best way to develop an applicaiton. Year two comes along and they will
then
>say that method A wasn't really very good and you should use method B.
Year
>three comes along and method B is now on the garbage heap. And so on and
>so on. At some point, software development has to stop being a business
>of tool development and use and more about delivering products that customers
>need and want. As long as developers have to spend more time worrying about
>new technology and how to use it and less time on delivering functionality,
>the software business will continue to be a fringe industry in constant
turmoil.
read my other post regarding this stuff..
my $.02
~aaron
Aaron,
The deprication methods Sun uses are far better than throwing out the language
wouldn't you agree? You get full notice of when an API will be depricated
as the compiler warns you of it. If you don't upgrade at that point, then
you had fair warning.
When Sun throws out Java and replaces it with a new computing platform, you
may have a point.
Tom
"Aaron Sevivas" <aaronsevivas@hotmail.com> wrote:
>
>The process of deprecation your talking about is not confined only to M$
platforms.
> All technology platforms reinvent/refactor themselves. Maybe M$ has done
>so in a more consistent basis (market driven), but the same can be said
in
>the java world (every new release of the JDK has methods depracated in the
>framework.. design practices change in the java world , ok Sun, should we
>or should we NOT use stored procedures to speed up retrievals! OK, do entity
>beans suck or not?(I know the answer so dont bother)) They seem to change
>their mind every two years..) Anyways, its probably because you work in
the
>MS world and not other tech circles that you feel the frustration of refactoring/relearning.
> The fact is, they discover and create "better" ways to accomplish tasks
>every day and want to relay that information to the customer. Also, M$'s
>marketing department's a bunch a guys with their hair on fire who justify
>their paychecks by re-"branding" M$ technologies (MTS<evolved-to/>COM+Services<evolved-to/>?).
> Thats annoying, but thats big biz.. Being a programmer can be annoying
too,
>because once we feel like we got this platform down packed, they change
it.
>All in all, its the nature of this business.. There is no "silver-bullet"
>technology that will never change (although the wheel is standing the test
>of time..its been refactored a few times I guess..). my $.02
>
>~aaron
On 27 May 2002 02:29:50 -0800, "Aaron Sevivas"
<aaronsevivas@hotmail.com> wrote:
>.....) They seem to change
>their mind every two years..)
Don't you see that as a problem? I certainly do! What other industry
can you think of which changes so much with the wind like Microsoft
software?Oh, and don't come and tell me "they're *all* doing it"
because they're not. Microsoft is the worst at goalpost moving, by
far.
MM
