JVOPS & Conduits+ Framework

1. JVOPS & Conduits+ Framework

2. Conduits+ • The implementation of a software protocol is not • a trivial task. • One design solution is to separate generic parts of • protocols from detailed, protocol-specific components. • This means that same software protocol components can • be reused with several different protocol implementations. • This way also the protocol specific software parts become • simpler and easier to maintain. • Conduits+ is a generic protocol framework developed by • Hermann Hüni, Ralph Johnson and Robert Engel.

3. Conduits+ • The Conduits+ is based on the Conduits Framework • which was developed in the University of Illinois • in the Choices operation systems -project. • Conduits+ utilises the so-called black-box framework • principle: the components are reused mostly by composing • object instances. • When using white-box frameworks, the components • are reused mostly by inheritance, and the users tend • to know more about the implementation of the components. • Black-box frameworks are usually easier to use than • white-box frameworks, but are always harder to design.

4. Conduits+ • The Conduits+ framework consists of two kinds of objects: • 1. Conduitsand • 2. Information chunks. • A conduit is a software component with two distinct • sides: sideA and sideB. • It may be connected on each of its sides to other • neighbour conduits. • A conduit can accept and deliver information chunks from • a neighbour conduit bidirectionally.

5. Conduit types • There exist four main types of conduits: • Protocol • Mux • Adapter • ConduitFactory • All conduits may have one neighbour on sideA. • A Mux can have many neighbours on sideB. • An Adapter has no neighbour conduit on sideB. • A Protocol and ConduitFactory have exactly one • neighbour on sideB.

6. A Protocol conduit aProtocol sideB[ ] isaConduit [ ]sideA

7. A Mux conduit aMux sideB[ · · · ] isaConduit [ ]sideA

8. An Adapter conduit aAdapter isaConduit [ ]sideA

9. A ConduitFactory conduit aConduitFactory sideB[ ] isaConduit [ ]sideA

10. The Protocol • A communication protocol can be described by a finite • state machine (FSM). • The protocol is implemented by a Protocol conduit, which • is where information chunks are produced, consumed and • tested. • The Protocol remembers the current state of the • communication. • The Protocol also provides commonly required facilities • such as counters, timers and storage for information chunks. • A Protocol has exactly one neighbour conduit connected on • both of its sides.

11. The Mux • A Mux is a conduit that connects one sideA conduit to • any number of sideB conduits. • A Mux multiplexes information chunks arriving on sideB • to the single neighbour conduit connected on its sideA. • It may also demultiplex information chunks from sideA • to one of the neighbour conduits connected on sideB. • A Mux must be able to extract a dispatch address from an • information chunk arriving from sideA and demultiplex • the information chunk to the neighbour conduits on sideB. • In the opposite direction, a Mux must provide an identifier • that represents the sender sideB conduit.

12. The ConduitFactory • A problem concerning the Mux is that how to add new • sideB conduits to a Mux. • Also, a problem would arise when an information chunk • from sideA addresses a non-existing conduit on sideB. • These problems are solved by giving each Mux a default • conduit that is a neighbour conduit connected on sideB • of the Mux on the dedicated b0 channel. • Each Mux has exactly one default conduit and zero or more • other sideB conduits.

13. The ConduitFactory sideB[ ] sideB[ ] sideB[ ] create aProtocol aProtocol aConduitFactory [ ]sideA [ ]sideA [ ]sideA sideB[ · · · ] [ ]b0 aMux [ ]sideA

14. The ConduitFactory • When a new session has to be set up, the information • chunk received from sideA of the Mux will be delivered • to its default conduit on channel b0. • When the information chunk reaches the Conduit Factory, • a new instance of the required protocol is installed on • sideB of the Mux. • The same information chunk will then revisit the Mux and • will be correctly demultiplexed to the new Protocol conduit. • The following chunks with similar identifiers will be • directly handed to the new Protocol conduit.

15. The Accessor • To guarantee the reusability of the same Mux at different • places in the conduit graph, the Mux needs a dispatch • criteria.This is achieved with an Accessor. • The name of the Accessor comes from that they access • the relevant dispatch key within the information chunk. • The Accessor has the following responsibilities: • 1. Computing the index of the Mux sideB conduit • to which the current information chunk should be • dispatched, and • 2. Computing the index for a new conduit which • is installed on sideB of the Mux.

16. The Adapter • An Adapter has no neighbour conduit on sideB. • It is used to connect the framework to some other • software or hardware. • The sideB implementation depends on the particular • software or hardware environment. • For example, an Ethernet Adapter may provide interface with • hardware and an UDP-client conduit acts as an adapter • for application programs. • The Adapter converts information chunks to and from • an external data format.

17. The State • A communications protocol is usually implemented by • a finite state machine (FSM). • Each state of the protocol is represented by a separate • object. • Protocols delegate their behaviour to their State object. • This is done because different protocols respond to • different sets of events. • Different protocols would require different interfaces, • limiting the reusability of the Protocol conduit.

18. The State • The Protocol conduit is made reusable because only • method it offers is just the acceptation of the information • chunks. • The information chunk interacts with the State object, • usually invoking protocol-specific operations on it. • The State object offers a broad interface for the • information chunks, but the Protocol has a narrow • interface. • The Protocol performs the apply( ) operation on the • incoming information chunk, which then implements the • apply operation by invoking an operation on the State object.

19. The Messenger • Defining direct operations on information chunks is not • appropriate because raw ICs are often just arrays of bytes. • Therefore, a Messenger class is used to carry the IC • and define the apply( ) operation. • The Messenger and State classes are protocol specific. • The State classes are usually not reusable from one • communication application to another. • However, some Messenger classes might be • reusable in different communication applications. • The State class is tightly coupled to all Messenger classes.

20. The Visitor • A typical Messenger is routed through a Mux until it • reaches a Protocol. • Some operations must traverse the Conduit graph • differently (e.g. when Conduits are added or removed • from a Mux). • Because the Messenger class hierarchy is strongly • coupled to the protocol-specific State classes, the • best way for the traverse implementation is using • non-specific (reusable) alogorithms for conduit • traversal in a separate class. • The solution is the Visitor pattern.

21. The Visitor • The Visitor pattern represents an operation to be • performed on the elements of an object structure • (conduit graph). • The Visitor enables definition of new operations on • conduits without changing the classes of the conduits. • This is done by making these operations to be • subclasses of the abstract class Visitor. • Conduits will only have to deal with Visitors, so they • will not depend on the Messenger hierarchy.

22. The Visitor • The Visitor has several subclasses. • MsgTransporter carries a Messenger around the • conduit graph. • Installer usually originates from a conduit factory. • It installs a conduit object on the first Mux sideB • it encounters. • The Visitor decides on the appropriate action based • on the conduit type, its own type and additional • information it carries along.

23. The Visitor • The Messengers are commands for states. • Visitors can be thought of as commands for conduits. • The Messengers will always just execute a method of • a given name on their target object. • The Visitors may do different things based on the kind of • conduit they encounter. • The effect of a Messenger on a State (a transition) is • determined by the State, but the effect of a Visitor on • a conduit can be decided by the Visitor.

24. The Prototype • A conduit factory must be parametrized by the kind • of conduits that it creates. • Each conduit factory has a prototypical conduit • that it copies when it needs to create a new one. • This is an example of the Prototype pattern, which • is specifying the kinds of objects to be created by using • a prototypical instance. • Using the Prototype pattern requires that conduits • are able to copy themselves.

25. Framework classes Messenger State ReleaseMsg . . . AlertingMsg Connected Releasing SetupMsg . . . . . . . . . Protocol Mux MsgTransp Installer Conduit Visitor

26. JVOPS • intended to be an environment with fundamental • possibilities for Java-based applications in • distributed reliable computing system • supports the development of distributed • applications, providing transparent communication • mechanism, process migration, load balancing and • different degree of reliability to application

27. Components • jTask with subclasses jAdapter, jMux, jProtocol and • jFactory representing active components • jTransporters with subclasses representing synchronous and • asynchronous interactions between components • jScheduler which manages threads and the execution of • jTasks • jArch for System Architecture specification and instantiation • of jSchedulers, jTasks and their interconnections in each • given subsystem. • different underlying technologies such as RMI, transactional • RMI, CORBA IIOP will be encapsulated in jAdapter instances

28. Transporters and Schedulers • SynchTransporters are transported synchronously • between conduits i.e. other transporters are • blocked during the handling of synchTransporter • AsynchTransporters are transported • asynchronously between conduits • TaskBasicScheduler is a basic task scheduler that • schedules tasks in FIFO order • PriorityTaskScheduler is an interface for • schedulers that schedule priority tasks • TimeoutTaskScheduler is an interface for • schedulers that schedule timeout tasks