A Platform for Data Communication

PDEBus is the underlying communication fabric which provides the vital glue that facilitates the operation of PDELab. The PDEBus provides a general communication medium for PDELab based on the software bus model.

The Software Bus. The software bus concept is an attempt to emulate the hardware bus mechanism that provides a standard hardware interface to attach additional capabilities to a machine. In a hardware bus, new units describe their capabilities to the bus controller, which then passes the information along to other units on the bus. In PDEBus, software components register their exported services with the software bus and rely on the software bus to invoke these services when requested by interested clients. The software bus is responsible for the application of any representation translators etc. as required for the valid invocation of the service. Thus, the software bus provides a mechanism where two tools can interoperate with each other without having explicit knowledge about each other and also provides the infrastructure for managing a set of distributed tools.

PDEBus Clients. The PDEBus software bus allows one to interconnect various types of clients (in terms of their execution model) that communicate in various communication protocols. The types of clients supported include reactive (or event-driven) clients, command-oriented clients and disconnected clients. Support for multiple types of clients is necessary as often we, as the developer of an application problem solving environment, do not have the option of adapting them to any preferred interaction model.

PDEBus supports three different client communication protocols currently: The software bus' own client interation protocol (for clients built with the software bus client library), raw-byte streams (for arbitrary communication) and a line-oriented protocol (for interacting with command-oriented clients).

PDEBus Services. The services provided by PDEBus to clients can be categorized into three groups: Location services, process management services and messaging services. For client/object location purposes, a global naming scheme based on uniform resource locators (URLs), a highly flexible emerging standard for naming arbitrary resources, is used. The software bus provides various directory services with URLs being the naming standard. The process management facilities provide by PDEBus include facilities to invoke and control both local and remote processes and facilities set up pre-wired configurations of clients and facilities. PDEBus' messaging services range from low-level byte stream messages to communicating arbitrary data structures (a)synchronously (via self-describing or network-transparent representations) to remote procedure calls.

PDEBus Architecture. The PDEBus architecture reflects the problem solving environment architectural model defined by PDELab. Clients are built using the PDEBus client library and, at run-time, connect to a manager process. A manager process exists per each user, application and machine and services as the clearinghouse of inter-client messages and client requests. (While inter-client messages travel via the manager by default, it is possible to establish direct, point-to-point links when necessary.) The manager processes themselves are connected to each other via multiple I/O channels. Interprocess communication occurs via TCP/IP sockets, pipes and shared memory or pseudo-terminals, depending on what the two components can support. In order to avoid being a bottleneck, the manager process generally uses shared memory to communicate with its clients and is multithreaded.

The PDEBus implementation respects all the standard access controls supported by the underlying operating environment. This is effected by following the usual mechanisms for getting access to a machine (to run a manager process) and by using a Kerberos-like security mechanism for authenticating and validating clients once the manager process is active.

Communication of arbitrary data types are supported in two ways. First, a self-describing data format can be used to inform the underlying communication medium of the types of data being communicated. Second, PDEBus allows clients to register their own convertors to/from the data structure and the transport representations. Using this latter mechanism, one can transmit and receive data in the eXternal Data Representation (XDR), for example.

For further information contact pdelab@cs.purdue.edu