1. 1 Copyright © 1998 JVOPS & Conduits+ Framework

2. 2 Copyright © 1998 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. 3 Copyright © 1998 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. 4 Copyright © 1998 Conduits+ The Conduits+ framework consists of two kinds of objects: 1. Conduits and 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. 5 Copyright © 1998 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. 6 Copyright © 1998 A Protocol conduit aProtocolsideB[ ] isaConduit [ ]sideA

7. 7 Copyright © 1998 A Mux conduit aMuxsideB[ · · · ] isaConduit [ ]sideA

8. 8 Copyright © 1998 An Adapter conduit isaConduit [ ]sideA aAdapter

9. 9 Copyright © 1998 A ConduitFactory conduit aConduitFactorysideB[ ] isaConduit [ ]sideA

10. 10 Copyright © 1998 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. 11 Copyright © 1998 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. 12 Copyright © 1998 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. 13 Copyright © 1998 The ConduitFactory sideB[ ] [ ]sideA aProtocol sideB[ ] [ ]sideA aProtocol [ ]b0 sideB[ · · · ] [ ]sideA aMux aConduitFactory [ ]sideA sideB[ ] create

14. 14 Copyright © 1998 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. 15 Copyright © 1998 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. 16 Copyright © 1998 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. 17 Copyright © 1998 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. 18 Copyright © 1998 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. 19 Copyright © 1998 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. 20 Copyright © 1998 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. 21 Copyright © 1998 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. 22 Copyright © 1998 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. 23 Copyright © 1998 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. 24 Copyright © 1998 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. 25 Copyright © 1998 Framework classes Messenger ReleaseMsg AlertingMsg SetupMsg Visitor... MsgTransp Installer State ConnectedReleasing... Conduit ProtocolMux...

26. 26 Copyright © 1998 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. 27 Copyright © 1998 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. 28 Copyright © 1998 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