1 / 28

JVOPS & Conduits+ Framework

JVOPS & Conduits+ Framework. 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

duncan
Download Presentation

JVOPS & Conduits+ Framework

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related