ORTE is network middleware for distributed, real-time application development that uses the real-time, publish-subscribe model. The middleware is available for a variety of platforms including RTAI, RTLinux, Windows, and a several versions of Unix. The compilation system is mainly based on autoconf. ORTE is middleware composed of a database, and tasks. On the top of ORTE architecture is application interface (API). By using API users should write self application. The tasks perform all of the message addressing serialization/deserialization, and transporting. The ORTE components are shown in

The RTPS protocol defines two kinds of Applications: Manager: The manager is a special Application that helps applications automatically discover each other on the Network. ManagedApplication: A ManagedApplication is an Application that is managed by one or more Managers. Every ManagedApplication is managed by at least one Manager. The manager is mostly designed like separate application. In RTPS architecture is able to create application which contains manager and managedapplication, but for easy managing is better split both. The ORTE contains a separate instance of manager located in directory orte/manager. The manager is composed from five kinds of objects: WriterApplicationSelf: through which the Manager provides information about its own parameters to Managers on other nodes. ReaderManagers: CSTReader through which the Manager obtains information on the state of all other Managers on the Network. ReaderApplications: CSTReader which is used for the registration of local and remote managedApplications. WriterManagers: CSTWriter through which the Manager will send the state of all Managers in the Network to all its managees. WriterApplications: CSTWriter through which the Manager will send information about its managees to other Managers in the Network. A Manager that discovers a new ManagedApplication through its readerApplications must decide whether it must manage this ManagedApplication or not. For this purpose, the attribute managerKeyList of the Application is used. If one of the ManagedApplication's keys (in the attribute managerKeyList) is equal to one of the Manager's keys, the Manager accepts the Application as a managee. If none of the keys are equal, the managed application is ignored. At the end of this process all Managers have discovered their managees and the ManagedApplications know all Managers in the Network. The managedApplication is composed from seven kinds of objects: WriterApplicationSelf: a CSTWriter through which the ManagedApplication registers itself with the local Manager. ReaderApplications: a CSTReader through which the ManagedApplication receives information about another ManagedApplications in the network. ReaderManagers: a CSTReader through which the ManagedApplication receives information about Managers. WriterPublications: CSTWriter through which the Manager will send the state of all Managers in the Network to all its managees. ReaderPublications: a Reader through which the Publication receives information about Subscriptions. WriterSubscriptions: a Writer that provides information about Subscription to Publications. ReaderSubscriptions: a Reader that receives issues from one or more instances of Publication, using the publish-subscribe service. The ManagedApplication has a special CSTWriter writerApplicationSelf. The Composite State (CS) of the ManagedApplication's writerApplicationSelf object contains only one NetworkObject - the application itself. The writerApplicationSelf of the ManagedApplication must be configured to announce its presence repeatedly and does not request nor expect acknowledgments. The ManagedApplications now use the CST Protocol between the writerApplications of the Managers and the readerApplications of the ManagedApplications in order to discover other ManagedApplications in the Network. Every ManagedApplication has two special CSTWriters, writerPublications and writerSubscriptions, and two special CSTReaders, readerPublications and readerSubscriptions. Once ManagedApplications have discovered each other, they use the standard CST protocol through these special CSTReaders and CSTWriter to transfer the attributes of all Publications and Subscriptions in the Network. The ORTE stores all data in local database per application. There isn't central store where are data saved. If an application comes into communication, than will be created local mirror of all applications parameters. Parts of internal structures are shown in .

Following example shows communication between two nodes (N1, N2). There are applications running on each node - MA1.2 on node N1 and MA2.1, MA2.2 on node N2. Each node has it own manager (M1, M2). The example shows, what's happen when a new application comes into communication (MA1.1). MA1.1 introduces itself to local manager M1 M1 sends back list of remote managers Mx and other local applications MA1.x MA1.1 is introduced to all Mx by M1 All remote MAs are reported now to M1.1 MA1.1 is queried for self services (publishers and subscriberes) from others MAx. MA1.1 asks for services to others MAx. All MAs know information about others. The corresponding publishers and subscribers with matching Topic and Type are connected and starts their data communication.