Our first implementation of BAST was not based on the Strategy pattern, i.e., distributed algorithms were not objects, and protocol objects were not capable of participating in more than one protocol execution concurrently. Furthermore, protocol composition was only possible through single inheritance.
Because protocol objects are the basic addressable distributed entities in our approach, it is not possible to guarantee that there will never be more than one protocol execution involving each protocol object at a given time. For example, we cannot make sure that there will not be two concurrent multicast communications and/or transactions involving the same protocol objects. Allowing concurrency at this level is an essential feature. Moreover, as far as protocol composition is concerned, single inheritance is way beyond offering a satisfactory degree of flexibility.
For all these reasons, we made BAST evolve through a second implementation which main goal was to overcome the limitations mentioned above. We now discuss some design alternatives that were considered in the process of implementing this second prototype of BAST, together with design issues that we studied from other existing frameworks described in the literature.