There is a natural tendency in a networked environment to create entirely new application-level protocols as each new or seemingly unique combination of client, user agent, and server requirement arises.
While in many situations the definition of a new protocol is useful and justifiable, there are numerous features which have eventually been added to or required from each new protocol (or which become layered above them) as they evolve and become used in broader contexts.
A design goal of the DCOM protocol is the inherent support of standard features required by any distributed application communication protocol. In other words, to act as a framework to facilitate the construction of task- specific communication paths between distributed applications.
A common occurrence among user agents using the HTTP protocol today is the use of complex, task-specific Query URL syntax and HTTP POSTs. Also increasingly common is the POSTing and response with custom MIME types to and from resources which interpret the format and reply in same. While workable, there are drawbacks to this approach including increased complexity and work to produce and consume each new (and unique) format in the client and server, lessened ability to build task-specific firewalls for administration and security purposes, and in many cases definition of platform-centric formats.
DCOM utilizes the Network Data Representation (NDR) for arbitrary data types supported by DCE RPC.
DCOM leverages the authentication, authorization, and message integrity capabilities of DCE RPC. An implementation may support any level of DCE RPC security. Any connection or call can be made as secure or as insecure as negotiated by the client and the server.
In DCOM versioning of interfaces is done through identifiers which are universally unique (UUID's). To version a published interface, a new interface is defined with a different UUID to the updated specification. Multiple parties can simultaneously introduce "revisions" to interfaces by defining related but distinct interfaces without fear of colliding with each other's version numbers and without fear of breaking each other's down-level or up-level clients.
To date, the bulk of task-specific protocols (such as custom POSTs or MIME types using HTTP) have little or no concept of versioning at all, and simply "narrow" the incompatibility window by updating clients (typically pages which are being downloaded anyway) and servers (CGI scripts or other HTTP server infrastructure) simultaneously.