Die Schnittstellen der OMG CORBAservices ([OMG96]) werden bei SOMobjects als abstrakte Basisklassen definiert. Die konkret implementierten Schnittstellen der SOM Object Services sind von diesen Basisklassen abgeleitet. In der folgenden Tabelle wird gezeigt, inwieweit CORBAservices in SOM/DSOM realisiert wurden.
| CORBAservice | SOM Object Service | Konformität |
| Naming | ja | ja |
| Event | ja | es wird nur generische Eventkommunikation unterstützt. |
| LifeCycle | ja | ja |
| Persistence | ja | ja |
| Externalization | ja | Methoden, die mit dem Relationship Service zusammenhängen, wurden nicht implementiert. |
| Transaction | ja | ja |
| Security | ja | nein |
| Concurrency | ja | ja |
| Factory | - | |
| Object Identity | - |
Mit Ausnahme des Event, Externalization und Security Service sind alle SOM Object Services mit dem entsprechenden OMG-Standard konform. Im SOMobjects Event Service sind sowohl das pull- als auch das push-Modell für die Ereigniskommunikation möglich. Wie beim CORBA Event Service kann ein Event Channel gleichzeitig ein push-supplier und ein pull-supplier sein. Allerdings wird die typisierte Eventkommunikation bei SOMobjects nicht unterstützt.
Ebenso unvollständig (im Bezug auf den entsprechenden CORBA-Service) wurde der SOM Externalization Service implementiert. Dieser Service enthält Klassen- und Methodendefinitionen, um Objekte als sog. streams (Datenströme) darzustellen. Damit werden die Daten eines Objektes ,,transportierbar``, d. h. sie können beispielsweise über das Netz verschickt werden. Wichtig ist, daß der Externalization Service dabei die Konvertierung zwischen maschinenarchitekturspezifischen Formaten (z. B. big/little-endian) übernimmt. In DSOM wird dieser Service benötigt, um Methodenaufrufe mit Objekten als pass_by_value-Parameter zu realisieren. Der SOM Externalization Service variiert nur geringfügig von der CORBA-Spezifikation des CORBA Externalization Service. So wurden beispielsweise die Methoden write_graph und read_graph in der Klasse CosStream::SteamIO nicht implementiert, da ein Relationship-Service, mit dem diese Funktionen im Zusammenhang stehen, nicht vorhanden ist.
Daß der Security-Service von SOMobjects nicht CORBA-konform ist, liegt daran, daß ein Standard für den Security Service der OMG noch nicht zur Verfügung stand. Der SOM Security Service von SOMobjects 3.0 ist allerdings auch in Hinsicht der gebotenen Funktionalität noch unvollständig: derzeit wird nur die Authentifizierung von Clients unterstützt. Mit dem Security Service können beispielsweise keine Passwörter zur Authorisierung der Aufrufer verwaltet werden.
Mit dem Factory Service bietet DSOM Mechanismen an, mit denen Applikationen Factories zum Erzeugen von Objekten auffinden können. Er ist gewissermaßen eine Verfeinerung des LifeCycle Service, der mit zusätzlicher Funktionalität das Finden von Factories und das Erzeugen von Objekten vereinfacht. Die Schnittstellen des Factory Service sind allerdings nicht CORBA-konform. Mit dem SOM Object Identity Service ist es möglich, Objekte untereinander auf Gleichheit zu überprüfen. Er wird benötigt, da das Vergleichen von Proxy-Objekten nicht ausreicht, um die Gleichheit der jeweiligen Zielobjekte festzustellen. Verschiedene Proxy-Objekte können nämlich auf dasselbe Objekt zeigen. Einen entsprechenden CORBAservice gibt es nicht.