1

Copyright © 1998

JVOPS &Conduits+

Framework

2

Copyright © 1998

Conduits+

•The implementation of a software protocol is nota trivial task.

•One design solution is to separate generic parts of protocols from detailed, protocol-specific components.

•This means that same software protocol components canbe 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

Copyright © 1998

Conduits+

•The Conduits+ is based on the Conduits Frameworkwhich was developed in the University of Illinoisin the Choices operation systems -project.

•Conduits+ utilises the so-called black-box framework principle: the components are reused mostly by composingobject instances.

•When using white-box frameworks, the componentsare reused mostly by inheritance, and the users tendto 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

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 distinctsides: sideA and sideB.

•It may be connected on each of its sides to other neighbour conduits.

•A conduit can accept and deliver information chunks froma neighbour conduit bidirectionally.

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 oneneighbour on sideB.

6

Copyright © 1998

A Protocol conduit

aProtocol sideB[ ]

isaConduit

[ ]sideA

7

Copyright © 1998

A Mux conduit

aMux sideB[ · · · ]

isaConduit

[ ]sideA

8

Copyright © 1998

An Adapter conduit

isaConduit

[ ]sideA

aAdapter

9

Copyright © 1998

A ConduitFactory conduit

aConduitFactory sideB[ ]

isaConduit

[ ]sideA

10

Copyright © 1998

The Protocol

•A communication protocol can be described by a finitestate machine (FSM).

•The protocol is implemented by a Protocol conduit, whichis where information chunks are produced, consumed andtested.

•The Protocol remembers the current state of the communication.

•The Protocol also provides commonly required facilitiessuch as counters, timers and storage for information chunks.

•A Protocol has exactly one neighbour conduit connected onboth of its sides.

11

Copyright © 1998

The Mux

•A Mux is a conduit that connects one sideA conduit toany number of sideB conduits.

•A Mux multiplexes information chunks arriving on sideBto the single neighbour conduit connected on its sideA.

•It may also demultiplex information chunks from sideAto one of the neighbour conduits connected on sideB.

•A Mux must be able to extract a dispatch address from aninformation chunk arriving from sideA and demultiplex the information chunk to the neighbour conduits on sideB.

•In the opposite direction, a Mux must provide an identifierthat represents the sender sideB conduit.

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 chunkfrom sideA addresses a non-existing conduit on sideB.

•These problems are solved by giving each Mux a defaultconduit that is a neighbour conduit connected on sideBof the Mux on the dedicated b0 channel.

•Each Mux has exactly one default conduit and zero or moreother sideB conduits.

13

Copyright © 1998

The ConduitFactory

sideB[ ]

[ ]sideA

aProtocol

sideB[ ]

[ ]sideA

aProtocol

[ ]b0 sideB[ · · · ]

[ ]sideA aMux

aConduitFactory

[ ]sideA

sideB[ ]

create

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 deliveredto its default conduit on channel b0.

•When the information chunk reaches the Conduit Factory,a new instance of the required protocol is installed onsideB 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 bedirectly handed to the new Protocol conduit.

15

Copyright © 1998

The Accessor

•To guarantee the reusability of the same Mux at differentplaces 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 accessthe relevant dispatch key within the information chunk.

•The Accessor has the following responsibilities:

1. Computing the index of the Mux sideB conduitto which the current information chunk should bedispatched, and

2. Computing the index for a new conduit whichis installed on sideB of the Mux.

16

Copyright © 1998

The Adapter

•An Adapter has no neighbour conduit on sideB.

•It is used to connect the framework to some othersoftware or hardware.

•The sideB implementation depends on the particularsoftware or hardware environment.

•For example, an Ethernet Adapter may provide interface with hardware and an UDP-client conduit acts as an adapterfor application programs.

•The Adapter converts information chunks to and froman external data format.

17

Copyright © 1998

The State

•A communications protocol is usually implemented bya 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 todifferent sets of events.

•Different protocols would require different interfaces,limiting the reusability of the Protocol conduit.

18

Copyright © 1998

The State

•The Protocol conduit is made reusable because onlymethod it offers is just the acceptation of the informationchunks.

•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

Copyright © 1998

The Messenger

•Defining direct operations on information chunks is notappropriate because raw ICs are often just arrays of bytes.

•Therefore, a Messenger class is used to carry the ICand 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 bereusable in different communication applications.

•The State class is tightly coupled to all Messenger classes.

20

Copyright © 1998

The Visitor

•A typical Messenger is routed through a Mux until itreaches a Protocol.

•Some operations must traverse the Conduit graphdifferently (e.g. when Conduits are added or removedfrom a Mux).

•Because the Messenger class hierarchy is stronglycoupled to the protocol-specific State classes, thebest way for the traverse implementation is usingnon-specific (reusable) alogorithms for conduittraversal in a separate class.

•The solution is the Visitor pattern.

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 onconduits 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 theywill not depend on the Messenger hierarchy.

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 sideBit encounters.

•The Visitor decides on the appropriate action basedon the conduit type, its own type and additional information it carries along.

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 ofa given name on their target object.

•The Visitors may do different things based on the kind ofconduit they encounter.

•The effect of a Messenger on a State (a transition) isdetermined by the State, but the effect of a Visitor ona conduit can be decided by the Visitor.

24

Copyright © 1998

The Prototype

•A conduit factory must be parametrized by the kindof conduits that it creates.

•Each conduit factory has a prototypical conduitthat it copies when it needs to create a new one.

•This is an example of the Prototype pattern, whichis specifying the kinds of objects to be created by using a prototypical instance.

•Using the Prototype pattern requires that conduitsare able to copy themselves.

25

Copyright © 1998

Framework classes

Messenger

ReleaseMsg

AlertingMsg

SetupMsg

Visitor

. . .

. . .MsgTransp Installer

State

Connected Releasing

. . .

Conduit

Protocol Mux

. . .

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

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

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