Device connectors connect the source and sink ports of devices. Device connectors are not responsible for matching the formats or flow parameters of device ports, and are therefore con-siderably simpler than the virtual connection objects of IMA-MSS that take a similar role.
They are instructed by the graph implementation about what formats and flow parameters to use for every port they manage. Device connectors have a public interface that allows applets and applications to control the connections between devices. They access the CORBA relation-ship service to establish relationrelation-ships between devices and themselves that allow to navigate the graph starting from a device or device connector. Two types of device connectors are defined, as can be seen in Figure 8.2. The auto connector is a simple device connector that automatically connects all the source ports that it manages to all sink ports. This connector is typically used for unicast and multicast connections among device ports. The connector box offers more degrees of freedom than that and allows to switch between predefined connection structures, called connectors, as was indicated in Figure 8.1. The connector box is more diffi-cult to use than the auto connector, which is not more than a plug.
A graph is defined in terms of devices and device endpoints connected by device connec-tors. The module::Bas defines a device endpoint as follows:
struct Endpoint {
Typ::ObjectHandle device;
PortKey port;
};
The member device is the object handle that the creator of the graph assigns to a device.
Object handles must be unique within a graph, which allows to use them together with a port key as an identifier for a device port. Auto connectors are defined as a set of endpoints. The connectors contained in connector boxes are equally defined in terms of endpoints. A connec-tor is identified via a connecconnec-tor key:
typedef unsigned short ConnectorKey;
A connector can be in the two principal states active and inactive. An active connector con-nects the endpoints that define it. Active connectors can further be in three sub-states depend-ing on success or failure of connection setup:
enum ConnectorState {INACTIVE,ACTIVE_OK,
ACTIVE_NOK,ACTIVE_FAILED};
The state ACTIVE_NOK indicates that one or more of the sink ports could not be connected.
The connector is in stateACTIVE_FAILED if the source port or none of the sink ports could be connected, or if the connector was defined to work in atomic rather than best-effort mode, and not all ports could be connected. Applications use the following type to define a connector:
struct Connector { ConnectorKey conid;
Typ::ExecSeman mode;
Typ::State active;
Endpoint out_port;
Endpoints in_port;
};
The application defines the connector itself with the members out_port andin_port. The member active indicates if the connector shall be activated right away. The member mode tells if the connector shall work in atomic or best-effort mode. If atomic mode is chosen the connector will either connect all ports or none.
Bas::AutoConnector and Bas::ConnectorBox inherit from the same base interface Bas::DeviceConnector. This interface defines the attribute contained_endpoints, which is the list of endpoints managed by the device connector. In the case of a connector box this corresponds to the union of all endpoints appearing in connector definitions. An endpoint may not be managed by more than one device connector. Another restriction is that a device connector may only manage source or sink ports of a device, but not the two at the same time.
This makes it impossible to loop a source port back to a sink port of the same device. Further restrictions are not required for the moment, but may become necessary as more experience is gained with graph structures.
The interface Bas::AutoConnector contains the two attributes failed_endpoints andmode:
readonly attribute Endpoints failed_endpoints;
readonly attribute Typ::ExecSeman mode;
The attribute failed_endpoints informs about the ports that could not be connected. The attributemode has the same meaning as themode member of the connector definition and tells if the auto connector works in atomic or best-effort mode. The interface Bas::Connector-Box offers considerably more functionality than that and allows to activate and deactivate con-nectors and groups of concon-nectors. A single connector is activated with the following operation:
void activate_connector(in ConnectorKey con, in boolean exclusive) raises (UnknownConnector,
ActivationProblem);
If theexclusive flag is set the connector box will transparently deactivate all other currently active connectors. The activate_connector() operation is supplemented by the acti-vate_connectors() operation for the activation of a connector group, and theactivate_
all() operation that activates all defined connectors. Similar operations exist for the deactiva-tion of connectors. Bas::ConnectorBox further defines a connector state change event for the case that the connector box is accessed by multiple clients.
A device connector uses thecreate_port() operation in the management interface of the device to create the ports that it manages. It calls the connect() operations in the interfaces Ports::OutPort and Ports::InPort to connect device ports and the disconnect() operation inPorts::Port to disconnect them. Before a device connector is removed it dis-connects all connected ports and deletes them with calls to remove() in Ports::Port. Device connectors implement thepause() andcontinue() operations in the base interface Bas::GraphObject by disconnecting and reconnecting ports. Figure 8.9 shows the two prin-cipal connection configurations. For unicast connections within the same address space it is possible to connect a source port directly to a sink port, as is illustrated in the upper half of Fig-ure 8.9. In the case of multicast connections, or connections across address spaces, the device connector must intercept the communication between source ports and sink ports. The source and sink ports seen by connected device ports are proxy ports that are implemented by the device connector. As part of apush() operation on the sink port proxy the device connector forwards a copy of the header container and a reference to the data buffer to all connected sink ports. This involves inter-process communication in case source and sink ports are distributed over multiple address spaces.
Right after a device connector has established a connection it will create a connect relation-ship between itself and the involved devices via the CORBA relationrelation-ship service. Figure 8.10
Figure 8.9. Two device connection configurations.
Ports::Inport
Ports::OutPort Bas::DeviceConnector
Device
Ports::Inport Ports::Outport
Connector
Ports::Inport
Device A
Device B
Device C
Bas::DeviceConnector
Device Connector
Ports::Outport
Device A
Ports::Inport
Device B
shows that a connection between two device ports is modeled as a ternary relationship between a source device, a sink device and the device connector that connects them. The source device takes the source role, the sink device the sink role, and the device connector the connects role.
These roles are defined as empty interfaces in::Bas: interface SourceRole : CosGraphs::Role;
interface SinkRole : CosGraphs::Role;
interface ConnectsRole : CosGraphs::Role;
The interfaceCosGraphs::Role is the role interface defined by the relationship service. The connect relationship is also represented by an interface:
interface ConnectRelation : CosRelationships::Relationship { readonly attribute Endpoint source;
readonly attribute Endpoint sink;
};
Thesource andsink attributes identify the device endpoints that are involved in the connec-tion. A device connector that wants to create a connect relationship first queries the roles_
of_node attribute of theCosGraphs::Node interfaces of the involved devices to see if they already contain the necessary source and sink roles. If not, the device connector creates the required roles via a role factory and adds them to the devices. Following that it creates the con-nect relationship via a relationship factory, which establishes relationship links to the source and sink roles of the devices and the connects role of the device connector. The device connec-tor can then set thesource andsink attributes of the new connect relationship. Once all con-nect relationships have been created within a graph it is possible to navigate the graph. The starting point for navigation can be an object reference to a device, a device connector, or a connect relationship. The relationship service defines theCosGraphs::Traversal interface that provides significant comfort for the navigation of graphs.
The connect relationships will be used by conspiring devices that need to locate each other, and by applets that need to retrieve object references for devices and device connectors within the graph. The control panel may use the connect relationships to query the structure of a graph, which allows it to offer the user direct control over devices and device connectors.
Debugging tools may use the connect relationships for realtime exploration of established graphs. In the future, connect relationships may provide support for compound life cycle con-trol and compound externalization of graphs. This in turn may be the basis for user session mobility support in APMT. It may also be possible to establish connect relationships that span the network, i.e., that model connections among the network ports of transport devices. As for now, connect relationships are local to a terminal.
Figure 8.10. Ternary relationship between two devices and a device connector.
Device
ConnectRelation source
sink source sink
Device Connector
connects