When you consider SOA as an architectural style to promote loosely-coupled components that encapsulate some business-logic then many technologies implement such a style such as WS (WebServices), JMS, Corba, DDS. If one was to classify those technologies based upon interaction-patterns then a separation between request/reply 'invocations' and pub/sub 'data-distribution' makes sense.
Then, in the category of information-centric cq. data-driven systems, DDS distinguises itself from other SOA technologies such as JMS, WS-notification by its focus on providing QoS policies related to the information (w.r.t. urgency, importance, reliability, persistence of each 'piece' of data to be distributed).
Another distinguishing factor between client/server and DDS is the level of coupling between the components: client/server interaction style typically relies on the 4W's e.g. "Who/Where" space coupling, "What" structual coupling and "When" time coupling. On the other hand with DDS there is only a structual "What" coupling since the information itself is the only thing shared between components (that can be decoupled in time & space i.e. are much more autonomous and loosely coupled)
Conclusion: DDS provides an excellent fit in information-centric SOA systems in that it allows to share information in real-time and in a very fault-tolerant way
The Service Oriented Architecture (SOA) is an architectural style focusing on Business Processes and their packaging into interoperable (loosely coupled) Services.
DDS, on the other hand, promotes an architectural style focused on the Data and Data Relations that constitute the fabric of Business Processes. The right angle to see DDS and the architectural pattern it supports are Event Driven Architectures (EDA). If you are interested in understanding how SOA and EDA compare, I suggest you take a look at the following WebCast http://www.opensplice.com/section-item.asp?snum=4&sid=224