Distributed Com
Distributed ComDCOM for short.
I forget who coined the phrase, but DCOM is often summed up as follows:
-- DrewMarsh
About Com:
DCOM is COM Remoting. It offers the ability to invoke components remotely. This may seem an odd addition to the EJB world, but it is a necessary one for COM, which evolved as a single-machine technology. DCOM extends that to remote machines as well.
DCOM by default uses ORPC, or what Microsoft calls Object RPC. This is a derivative of the DCE RPC, for remoting. It does depend on TcpIp, but can also travel over pipes.
DCOM over the Internet?
In answer to the desire to invoke components over the internet, at one point, Microsoft also attempted to tunnel DCOM (ORPC) over HTTP - this was messy and never succeeded.
DCOM to non-Windows platforms?
In answer to the desire for interoperability, Microsoft at one point advocated and developed (steady...) DCOM on Unix. I think it actually shipped on Solaris, but from what I hear, the number of customers who use this is in the single-digits worldwide. Again, not a success.
Other DCOM concerns
Even in a non-internet, 100% Windows environment, DCOM is less than completely satisfactory as a remoting or function-shipping technology, because, unlike the DCE RPC, or EJB, or even vanilla RMI, there is no distributed namespace. So when a client node wants to contact a remote object, the client node must have knowledge of where to find that remote component. In COM, that location info is stored in the Windows Registry, which is a meta-database on every Windows node in the network.
Consider the scenario where you're building an internal line-of-business application for a company, and deploying it to 1600 PCs. To use DCOM to get from the PC to the Component Server, you're going to have to (a) get the client software to each PC, and (b) update the registry on each of those 1600 PCs. Part (a) can be solved with a web download; but part (b) is trickier.
It also restricts the Server admin from re-deploying the app to a different IP or differently named server. Doing so means you gotta tell all the PCs the new server location. Ouch.
Obviously updating all of these PCs is not a practical idea, and there are many ways around this. But each one is somewhat manual or roll-yer-own. In this respect, DCOM shows its roots as a technology derived from a single-machine architecture (COM).
On SOAP
<advocate>
At this point Microsoft is talking up a good game about SOAP - which is another remoting technology, an alternative to ORPC. (Not necessarily an alternative to DCOM). SOAP itself is derivative of XML-RPC (see references elsewhere), and is based on HTTP and XML natively, and so there are no oddball tunnelling or firewall issues to confront. (Consider the Iona Wonderwall, and all the other protocol-specific firewalls that are necessary for binary RPC protocols). The goal of SOAP is to enable web-friendly remoting (hence HTTP) in a middleware-agnostic fashion (hence XML).
Thus any endpoint that wants to produce or consume SOAP requests can do so by producing or consuming SOAP-conformant XML, and by transmitting or receiving that XML stream over HTTP. In the future, COM will be trained to do this transparently, but there is nothing to prevent other object technologies (EJB, CORBA, etc.)from doing likewise. Also, MS is releasing a SoapToolkit to enable web services in the current COM+/Windows2000.
SOAP has the potential to be a useful interop protocol, if synchronous method requests across the internet is what you want.
For more on SOAP, see http://msdn.microsoft.com/xml/general/soapspec-v1.asp
</advocate>
-- DinoChiesa
Microsoft's .NET is the replacement for the above technologies, using reformulated SOAP.
MicrosoftSecurity and DCOM
WindowsXp SP2 has enhancements for applications using DCOM. It also means existing DCOM applications can seize up.
See ComponentObjectModel, ComPlus, ComIsNot, ComIsLove, InProcessComponent, OutOfProcessComponent, SurrogateProcess
EditText of this page
(last edited February 27, 2010)
or FindPage with title or text search