Arbitrary protocols may be chosen for the internal communication between the fragments. For instance, this allows to hide real-time protocols (e.g., RTP for media streaming) behind a standard CORBA interface.
The internal structure of a fragmented object is arranged by the object developer/deployer. It may be client–server, hierarchical, peer-to-peer and others. Thus, a downward compatibility to stub based distribution is ensured.
As both the distribution of state and functionality are hidden behind the object interface, their respective distribution over the fragments is also arbitrary. In addition, an application using a fragmented object can also tolerate a change in distributions which is achieved by exchanging the fragment at one or multiple hosts. This procedure can either be triggered by a user who changes object properties or by the fragmented object itself (that is, the collectivity of its fragments,) e.g., when some fragment is considered to have failed. Of course, an exchange request may trigger one or more other internal changes. The object developer can migrate the state and the functionality over the fragments by providing different fragment implementations. Those dynamically change inside the fragmented objects. A flexible internal partitioning is achieved, providing transparent fault-tolerant replications as well.