Connexis allows multiple Model RealTime-generated executables to be connected in a robust and reliable manner. Executables are networked by connecting unwired ports across process boundaries.
A Model RealTime application that uses Connexis to implement its inter-process communication has the high-level architecture shown below. The control paths that are shown, indicate the components that are involved in registering and deregistering endpoints in the UML application. All data that is sent between endpoints in a Connexis-enabled application goes through the Transport component.
Let’s have a look at these different application layers.
In the UML application, ports are used to send messages between the capsules in your model. There are different kinds of ports. The most common type of port is a wired port. Wired ports are visibly connected to other wired ports by means of connectors. Wired ports are represented graphically with two connected squares in the oval part of the port icon.
Another type of port is the unwired port. Unwired ports are the primary method for establishing Connexis connections. Once you have created an unwired port, you can specify the connection service, protocol, and endpoint address that it will use by registering the port with the TargetRTS. This registration can either be done automatically (design-time) or through application code (run-time). The Connection Service shown in the picture below is the Distributed Connection Service of Connexis, i.e. the DCS is one implementation of a Connection Service.
The Distributed Connection Service (DCS) is the connection service that is provided with Connexis. It is responsible for maintaining information about the unwired ports that have been registered with it. The DCS is part of the system that is responsible for establishing connections between unwired ports. It does this by parsing the registration strings that are passed in when an unwired port is registered.
The Transport is the component that is responsible for sending and receiving data between processes. It manages any incoming or outgoing data buffers and encodes and decodes data. A more detailed break-down of the Transport component is shown below.
Another key component of a robust distributed system is a fault-tolerant name service. A name service is used to find the actual location of a service given a predetermined service name. A well-known example of a name service is the Domain Naming Service (DNS) that is widely used on the Internet. The principle function of a name service is to look up a specific address when it is given a service name. This isolates the calling application from changes in the physical addressing of network components. In Connexis, the Locator Service provides the name service functionality.
The Locator Service actually does a bit more than just operating as a name server. The Locator can be configured to arbitrate between more than one endpoint that provides the same service and it can also be set up to run in duplex mode, which allows a backup Locator to automatically take over when the primary Locator fails.
An endpoint is defined to be the combination of a transport protocol and the address of a specific port of an object in a distributed application. For example, cdm://address:port. If an explicit endpoint is provided, then the Locator service is not needed and the client will try to directly connect to the server at the specified endpoint location. However, if an explicit endpoint is not provided then the Locator is contacted. The Locator returns an endpoint that is then used by Connexis to choose the appropriate service provider or peer. The service name by which an endpoint is referred, is specified as part of the registration string of that endpoint.
The Connexis Locator Service supports both a primary and a backup locator. In this way, a distributed application can be made more robust by ensuring that the name server does not become a single point of failure.