DCOM for short.
I forget who coined the phrase, but DCOM is often summed up as follows:
- "DCOM is simply COM with a longer wire."
Essentially, the location transparency of COM is extended beyond the scope of apartments and local processes to include the possibility of components running on a completely separate machine. DCOM can use a wide array of PluggableProtocol?
s, by default it uses TcpIp
- COM (aka ComponentObjectModel) is used by developers to create re-usable software components, link components together to build applications, and take advantage of Windows services. COM objects can be created with a variety of programming languages.
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).
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.
- July2004 note - SoapToolkit death sentence defered till May05 at last minute.
Other vendors are producing SOAP-compliant proxies. I believe DevelopMentor
, longtime MS partner) has a download of a SOAP demo showing Perl5 invoking a remote COM object. Iona has made a statement,
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
Microsoft's .NET is the replacement for the above technologies, using reformulated
MicrosoftSecurity and DCOM
SP2 has enhancements for applications using DCOM. It also means existing DCOM applications can seize up.
- What is a common / typical scenario that will break an existing DCOM setup, once SP2 is implemented?