 |
|
|
 |
|
 |
Hi all,
Does anyone know if there is a commercial tool that can convert DCOM interface to tcp/ip interface?
Thank's,
Zahi
|
|
|
|
 |
|
 |
Hi, Zahi:
Try out our SocketPro at www.udaparts.com
|
|
|
|
 |
|
 |
We started working on an application with a thin-client UI a while ago, and when we analysed DCOM we found exactly the same problems. We implemented our own version too, but only supporting simple IDispatch-style interfaces, we didn't include full COM support. I'm glad that there are people out there who see the same problems, makes me feel more confident about the solution we chose.
|
|
|
|
 |
|
 |
But DCOM wasn't perfect; it introduced new complexities. Like COM, whenever a server-side component is updated using DCOM, the type library information changes due to binary incompatibility. With DCOM, these changes need to be propagated to existing client machines. DCOM doesn't provide a mechanism for dynamically updating and binding to type library information; such information is stored in the registry, or with COM+ in the COM+ catalog. DCOM is a "chatty" protocol, pinging clients regularly to see if the clients are still alive. And because it doesn't support batch operations, it takes almost a dozen roundtrips to the remote server to complete a single method call. Using DCOM through firewalls becomes problematic because it dynamically allocates one port per process (configurable through the registry) and requires UPD and TCP ports 135-139 to be open. An alternative for enabling DCOM through firewalls exists by defining Tunneling TCP/IP as the underlying transport protocol. This allows DCOM to operate through some firewalls via port 80. But it's not very reliable, doesn't work through all firewalls, and introduces other limitations (lack of callback support, etc.). DCOM has certainly evolved over the years, in an effort to accommodate the demands of a changing environment. But because of its roots in older binary and component-based protocols, it still fails to deliver the flexibility needed in today's enterprise. DCOM is still inefficient, cumbersome to deploy and requires a fair amount of manual maintenance.
From the site http://msdn.microsoft.com/library/en-us/dndotnet/html/webservicesdcom.asp
The author points out the problems of DCOM, but does not give out reasons clearly. I think the most fundamental problem of DCOM uses the net communication pattern 1!
Yuancai (Charlie) Ye
See 30 OLEDB samples
Use of free SocketPro for creating super client and server application
www.udaparts.com
|
|
|
|
 |
|
 |
Yes, DCOM has a lot of problems, but I just don't see web services being the silver bullet they think it is. Just take a look a SOAP and WSDL and you will see all the huge problems people have just trying to get clients and servers communicating with each other. Anybody who thinks changing from a binary protocol to text based will suddenly solve all these problems probably also owns ocean front land in Wyoming. Lord knows, as far as bandwidth, text based protocols are horribly inefficient when compared to well implemented binary protocols.
Web servers will be neat, but mark my words, we will just find ourselves battling a different set of hard to solve problems.
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
 |
|
 |
Hi, Tim: I put the MS DCOM statements here to highlight the DCOM problems only. In regards to MS web service, I dislike it in most cases. If you don't care for data movement efficiency over internet but just pay much attention to web interoperability, you can use it. If you care for speed, don't use it, please. In this point, we share the same opinion. Yuancai (Charlie) Ye See 30 OLEDB samples Use of free SocketPro for creating super client and server application www.udaparts.com
|
|
|
|
 |
|
 |
Yeah.
It seems to me that DCOM what just what it says it is, "Distributed COM". MS really didn't try to make a good solid high speed wire protocol, they just created a COM that goes over a wire.
I like DCOM. But it does have a lot of limitations.
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
 |
|
 |
Hi, Tim:
Here is my feedback to your following quoted statement.
Tim Smith wrote:
MS really didn't try to make a good solid high speed wire protocol, they just created a COM that goes over a wire.
After thinking for a while, I am sure that MS has no way to make a good solid fast wire DCOM protocol no matter how much effort MS put! It is one of fundamental limitations of DCOM.
Yuancai (Charlie) Ye
See 30 OLEDB samples
Use of free SocketPro for creating super client and server application
www.udaparts.com
|
|
|
|
 |
|
 |
I totally agree. IMHO most of the problem is with COM. It was never designed to be networked. Maybe if they had the chance of starting again and being able to redesign COM and DCOM they could do better.
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
 |
|
 |
I thought DCOM would be the 'holy grail', turned out to be a complete nightmare, problems I experienced:
a. Security mess bewteen different palforms (eg. NT/98 etc)
b. Slow performance with method calls
c. even slower performance with connection points.
We started a project using DCOM and ditched it after 2 months or to use raw tcp/ip.
Normski. - Professional Windows Programmer
|
|
|
|
 |
|
 |
no .Net is the 'Holy Grail' or will it be the 'holy @#!$%' I got bit again.
Guys...If you want high speed you got to get low in the code!
not too long ago, I was writing a GUI that kept hanging as I looked at network resources. So, I just wrote a seperate program and launched it in the background with a timer, and it reported changes in the networked assigned ports to the GUI via the message queue. Problem fixed with 3 routines...start process, handle message(x), end process on close. Gui never missed a step again.
Back on subject....The higher the level and 'EASIER' MS makes it for the programming challenged, the slower it will be! Case in point....How many Gigabytes was Windows95 ? (Hint...it fit on 3 diskettes). It use to be a big joke at the the company I worked that they and MS was in business to sell more hardware by writing bigger code. Hummm....wait...then they started measuring programmers productivity based on the amount of code they produced! (CUT/PAIST/Rename/CUT/PAIST/Rename) I got a raise.
I support eh use your sockets!!! Study your Berkly Sockets or at least the DOD Protocal Layers....better known as (TCP/IP)
LJ
Relax, Dont do it!
|
|
|
|
 |
|
 |
CPropertySheet has a memberfkt to SetWizardButtons() to enable / disable serveral buttons. The Cancel / Abort button however can not be disabled or hidden this way.
Any chance to disable that button?
Rainer
|
|
|
|
 |
|
 |
Hi, Rainer:
I don't think that this question is related with my articles.
|
|
|
|
 |
|
 |
Hi, All
I updated SocketPro with its documentation and more samples. See the site http://www.udaparts.com. It will takes a while for Codeproject to publish my this updated article
Yuancai (Charlie) Ye
|
|
|
|
 |
|
 |
After reading some of your articles around this web site, I totally agreed to some of the readers comment that your knowledge in n-tier/COM/DCOM/JB/MQ is total OUT! And yet you always want to promote your work comparing to these rather mature technology, by giving false and baseless information. Note that your article will mislead many of those who want to learn. Shame on you!!
I get a kind of thought that you don't want to open your source is because most of them, might be copied from DUNDAS TCP/IP package?! I hope I am wrong and wish not to see your article again unless you change your xxxx attitude.
|
|
|
|
 |
|
 |
Hi, Chee:
Don't be so crude to me!
Chee statement:
After reading some of your articles around this web site, I totally agreed to some of the readers comment that your knowledge in n-tier/COM/DCOM/JB/MQ is total OUT! And yet you always want to promote your work comparing to these rather mature technology, by giving false and baseless information. Note that your article will mislead many of those who want to learn. Shame on you!!
Please show me your points, and pinpoint what problems with my articles. Tell me what information is false and baseless. I am waiting for your response. I don't write any article to mislead people.
Chee statement:
I get a kind of thought that you don't want to open your source is because most of them, might be copied from DUNDAS TCP/IP package?! I hope I am wrong and wish not to see your article again unless you change your xxxx attitude.
Your guess is totally wrong!!! Don't use your anormal brain to judge me. Actually I open many source code (not all). I don't understand why you write such a conclusion on the web?!
|
|
|
|
 |
|
 |
Quote
On many systems including the major Linux and BSD distributions, yes (the GPL does not place restrictions on using libraries that are part of the normal operating system distribution).
On other systems, the situation is less clear. Some GPL software copyright holders claim that you infringe on their rights if you use OpenSSL with their software on operating systems that don't normally include OpenSSL.
If you develop open source software that uses OpenSSL, you may find it useful to choose an other license than the GPL, or state explicitly that "This program is released under the GPL with the additional exemption that compiling, linking, and/or using OpenSSL is allowed." If you are using GPL software developed by others, you may want to ask the copyright holder for permission to use their software with OpenSSL.
End Quote....
Does Microsoft support GPL?
Besides that, I personally dont care if you use this forum for personal gain or to promote your software...I think that was what his concern was! But I did kinda think it was a more of a GPL type Forum/service...I will look into that.
Relax, Dont do it!
|
|
|
|
 |