Consider the implementation of Java RMI as a composite binding in Fractal. Discuss the extent to
which such a binding can be both configurable and reconfigurable.

What will be an ideal response?

Composite binding are like any other configuration in Fractal and can themselves be configured and
reconfigured. That is, a composite binding has an associated software architecture in terms of components and
bindings. It is therefore possible to provide a component-based implementation of Java RMI which teases apart
the different aspects of the implementation, for example components responsible for providing proxies,
naming, communication, location, and so on. The granularity of the composition can also be varied, for
example, the communication module could further be broken down into different aspects such as the
underlying transport protocol and the module implementing the required invocation semantics. This approach
clearly lends itself to a more configurable approach. For example, rather than offering a range of semantics in
an implementation (at-least-once, at-most-once and exactly-once) a given deployment could be configured to
offer one, as required by that context. Similarly, the transport protocol could be configured to TCP or to an
alternative transport mechanism, for example optimized for an ad hoc networking environment. Similarly, the
approach lends itself to reconfiguration, for example changing the invocation semantics or transport protocol
at runtime.