Wyobraźmy sobie przypadek żądania od „klienta” (czyli od procesu wykonywanego w dowolnym miejscu w systemie rozproszonym) dla obiektu. Na przykład klient może chcieć wywołać obiekt TAXM, aby poradzić sobie z kalkulacją podatku. W implementacjach CORBA klient nigdy nie komunikuje się bezpośrednio z obiektem; żądanie zawsze przechodzi przez Object Request Broker (ORB), część oprogramowania CORBA, która działa jako bufor upraszczający między klientem a obiektem
Celem ORB jest ukrycie przed programistą aplikacji zawiłości radzenia sobie ze środowiskiem rozproszonym, które ponadto może składać się z heterogenicznego zestawu komputerów. ORB znajduje obiekt i obsługuje szczegółowe parametry żądania. Jego zadaniem jest zasadniczo zapewnienie przejrzystości lokalizacji i dostępu. Czyni to poprzez interfejsy IDL, jak pokazano. (Nawiasem mówiąc, można zauważyć, że ORB pasuje do naszej definicji obiektu CORBA.) W systemie rozproszonym może być kilka ORBów, każdy zamontowany na innym zestawie komputerów. Klienci wysyłają ich prośby do lokalnego ORB. Załóżmy, że poszukiwany obiekt nie znajduje się na obszarze objętym lokalnym ORB? Nie ma problemu, lokalny ORB po prostu komunikuje się z lokalnym ORBem obiektu
Kolejną zaletą tego podejścia jest to, że różne ORBy mogą znajdować się na platformach sprzętowych i programowych różnych dostawców i być napisane w zupełnie różnych językach, zgodnie z różnymi projektami wewnętrznymi. Wystarczy, że są w stanie zapewnić funkcje CORBA określone w ich interfejsach.