The Connexis programming model provides significant value:
Built for real-time Automatic mapping of UML communication ports onto a high-performance software backplane.
Product-ready, but flexible
The software is ready to run as soon as it has been installed but can be adapted to handle application-specific requirements.
Simple-to-use programming model
Supports client/server type name binding and asynchronous messaging.
Support for fault tolerance
Detects failures and provides a framework for dealing with faults.
Connexis has a flexible encoding and decoding strategy so that it can work in different types of hardware environments. The endian of the target environment is transparent to the executing application.
The Connexis Locator service provides location transparency for a distributed application. The application uses service names to refer to the endpoints that are being connected. As a result, the physical address of these endpoints never has to be revealed to the application. Locator features are available for services published on integrated transport addresses. Connexis also supports many different distribution options, which allow the design of the application to be very flexible.
The following are the most common types of connections supported:
For local connections within the same process, Connexis optimizes communication to be as efficient as directly wired ports. The endpoints of the local connections are registered using service names and Connexis takes care of binding the endpoints together. Once bound, these local connections have the same performance characteristics as two wired ports that have been bound together.
Connexis accepts registrations that use explicit endpoint addresses in the registration string. This can be used if the application knows the location of the services that it wants to access. In this way a client can bind to a service using an explicit location and the service name of the desired service.
The Connexis Locator service can be used to find a service (given the service name) anywhere in the distributed application. Once the Locator has been started, one side of the connection registers with it as the publisher, and the other side registers as the subscriber. The Connexis Locator finds the matching endpoints, and feeds them back to the connection service which establishes the connection when both endpoints are available.
Connexis supports a wide range of configuration options. This enables the use of Connexis to be very flexible and adaptable to different target environments. For example, configuration options can:
configure connection audits
adjust buffer counts and sizes
adjust thread priorities and stack sizes
adjust message delivery timing characteristics
The Target Agent and the Connexis Locator Service do not have to be a part of every Connexis application. If your application does not use the Locator service, these components can be left out of the executable’s configuration. This helps minimize the size of the Connexis code that gets linked in your executables.
Connexis allows multiple ports to be registered with the same service name. This, coupled with the standard Model RealTime support for port multiplicity, enables several common distribution patterns to be supported by Connexis. Patterns that are not directly supported can usually be implemented very easily in Model RealTime.
The Connexis model library is shipped with full source code. The library can be rebuilt if needed for a custom target configuration (see Porting Connexis to a New Target Configuration).
Fault tolerance and reliability are paramount to most real-time systems. Connexis has been designed with these requirements in mind. The following is a list of the different Connexis features that enhance fault tolerance and reliability:
The Locator Service can be run in simplex or duplex mode. A binary elector is used to determine the health of the primary locator. This provides redundancy and can avoid a "single point of failure" in the distributed application.
Connexis has been designed for true non-blocking behavior. All potentially blocking system calls are handled by a user-configurable set of helper threads. Name resolving is an example of an operation that makes use of helper threads.
A heart beat style audit is used over the UDP based connections to detect connection, process or processor failure. This audit is tuneable so that it can be used in a variety of environments. The audit is highly efficient since it monitors user messages to collect status information. This allows explicit "Are you alive?" messages to be avoided. And when explicit "Are you alive?" messages anyway are used, the number of such messages sent per unit of time can be capped to ensure that audits do not overutilize system resources. When a connection-oriented protocol (such as TCP) is used, only a very basic, "Is the connection alive?" protocol is used.
Buffering policies can be configured between the UML asynchronous messaging controller and the flow-controlled transport message router. This ensures that your model never hangs due to a slow or broken transport connection. When the queue fills up, messages are properly deleted from the system.
It is easy to build a set of components that meet application specific requirements for fault-tolerance and reliability. The standard generic events, rtBound and rtUnbound, are supported for all Connexis ports, but these notifications can be enabled on a per-port basis and utilized by the application with minimal additional complexity.
The underlying "try-forever" algorithm can be overridden by the application simply by deregistering the unwired port when certain quality of service parameters are not met.
Patterns for distribution can be implemented using Connexis as the underlying distribution mechanism. For example, a single publisher can actually hide multiple distributed connections to a replicated service.
Resource constraints can be placed on publishers of services to limit the number of subscribers per publisher.
The allocation of unwired ports to capsules is under the control of the designer and since the deployment of capsules onto threads also is under control of the application, the application can dynamically control which resources are being used.
Services can be ranked according to the preferred order of use. This ranking is done with full, dynamically updated knowledge of the resource limits. If a given service with a certain rank is full, one of a lower rank will be used, if available.
Configurable system audits verify that the internal system connection state matches across the entire system.