If I had a dime for every time I was asked the question, “Why should I use OPC instead of DDE”, I’d be a very rich man.  In fact, there was a good thread going on this not long ago on the Control.com site.  So why would you use OPC instead of DDE?  First a bit of background on Dynamic Data Exchange (DDE):

One of the ways Windows allows data transfer between applications, is the Dynamic Data Exchange (DDE) protocol.  The DDE protocol is a set of messages that uses shared memory to exchange data between applications.  Applications can be developed using two methods;  1) Raw or Message-based DDE, which uses the DDE protocol directly using Windows Messaging.  2)  Dynamic Data Exchange Management Library (DDEML), which is a dynamic-link library (DLL) that provides functions and messages to simplify adding DDE to an application.  DDEML has been available since Windows version 3.1 and still has support in Windows XP and the upcoming Vista release.

Network Dynamic Data Exchange (NetDDE) is an extension of the DDE protocol that has existed since the very early versions of Windows.  NetDDE extends all of the DDE capabilities and enables applications on two or more workstations to dynamically share information over a network. NetDDE is not a special form of DDE but rather a service that examines the information contained in a DDE conversation and looks for a special application name.  Much like using a remote printer or directory, a NetDDE Share must be configured before the applications can exchange data.  Due to the limited security model for NetDDE, support for this has been waning.  Although it is available on Windows XP and 2003 Server, it is disabled by default.  According to the latest Windows Vista documentation,  NetDDE is NOT available on this platform.

OPC is based on the COM/DCOM.  COM is a binary standard that enables objects to interoperate in a networked environment and includes ActiveX Controls, Automation, and object linking and embedding (OLE) technologies.  Since the release of Windows NT,  Microsoft recommended DCOM as the preferred method for data exchange between client/server applications over the network.  DCOM builds upon the remote procedure call (RPC) technology, and was designed to give developers more control over security, as compared to other interprocess communication mechanisms.

I don’t want to get into the truly gory details of Windows Messaging and COM.  If you really want to get in depth, check out MSDN.  However, from an implementer’s point of view, the following points are what should be considered:

1)  Supportability
2)  Interoperability
3)  Speed and Through-put
4 ) Scalability
5)  Robustness
6)  Security

Supportability:   You will continually hear ‘DDE is old and/or obsolete’.   The other side of  argument is ‘ It’s been working fine since 1986, it’s easier to implement than COM and Microsoft will never get rid of Windows Messaging’.  While these are valid statements, consider this:  my Walkman is simple and works fine, and I need to use my computer to load up my iPod, but I can’t say I will be making new mix tapes any time soon.  Jokes aside, although DDE has made the cut to Windows Vista, the fact that there is no support for remote access via NetDDE will be a severe body blow for DDE applications in the future.  Already many people with legacy DDE applications will use one of the many OPC Server for DDE on the market to network enable their applications.  If you are implementing a new system, the cards are stacked heavily in favor of OPC in terms of supportability.

Interoperability:  It would seem to be an obvious point, but what applications will be connecting to your system?   Are there more DDE clients or OPC clients available in the marketplace, and which are more likely to be developed in the future?   Consider also that OPC offers standardized compliance testing for servers, and OPC Interoperability testing for client applications.   Many of the DDE compatibility issues I’ve come across over the years where due mainly to poorly written applications.   Here’s a quote from the MSDN database ” Dynamic data exchange (DDE) is one of the least understood capabilities of the Microsoft® Windows ™ graphical environment. For the most part, this lack of understanding results from the absence of a highly detailed explanation of the correct protocol to use when performing DDE transactions.”  Admittedly, I’ve seen a few poor OPC clients as well, but they rarely are Compliance or Interoperability certified.

Speed and Through-put:  One of the main difference between DDE and COM applications, such as OPC, is how transactions are identified and processed.  Unlike COM which uses pointers to shared memory objects, DDE applications create and exchange string and data handles, which identify strings and memory objects.   Also the NetDDE service examines each DDE request, looking for the use of a special reserved application name, which is preceded by the name of the remote system.   The resulting string parsing and management results in slower performance.  COM is a truly binary standard, that is designed to process and move more data, more quickly.

Scalability:  Related to speed is the concept of scalability.   As the number of client connections or item requests goes up, how is performance affected?  When handling messages from more than one source, a DDE client or server must process the messages of a conversation synchronously.   On the other hand COM/OPC supports the concept of  non-blocking method calls.  OPC Clients can exploit parallelism without the pain of multi-threading, and servers can handle calls asynchronously for vastly improved scalability.   Another key feature of OPC, is that the OPC Server will cache the most current value, so only the values which have changed need to be reported back to the client application.   DDE updates all values, regardless whether or not they have changed.

Robustness:  In addition to the speed and scalability issues, a good error reporting and handling infrastructure is needed for a truly robust application.   In addition to standard COM error handling codes, the OPC specifications outline specific error codes to be returned under different scenarios.

Security:  Security in any networked architecture is another whole topic of discussion, but we can still hit the high points between DDE and OPC.  Network DDE uses trusted shares and security descriptors to control access to shares.  The user that created the NetDDE share must be logged on in order for the connection to occur.   OPC Security is controlled by Windows DCOM security configuration.  Whenever an OPC client calls a method, DCOM obtains the client’s current username, and passes it to the machine where the server is running. DCOM on the server’s machine then validates the username using the configured authentication mechanism and checks the access control list (ACL) for the component.   DCOM security is at the same time one of the strongest features, and biggest implementation headaches of OPC, but it works.

Hopefully this sheds some light on the difference between OPC and DDE.  Even this long and rambling post still doesn’t do the topic complete justice.  To sum up, here is my humble opinion on the subject.  DDE has been around for a long time, and will probably be with us for some time to come.  DDE probably still has it’s uses for simple, small-scale, non-networked applications.  However, the overwhelming majority of industrial applications I’ve dealt with over the years are non-trivial, large scale and involves multiple connections over the network.  If you need industrial strength, go with OPC.