Mastering Rational Rose RealTime Distributed Models and Connexis

Mastering Rational Rose RealTimeDistributed Models and Connexis

Objectives • Describe the importance of user-defined unwired ports • Describe the communication service offered by the RTS layer • Describe the main features and services available through Connexis

Topics • Distribution Overview • Dynamic Connections • Connexis

Processor 2 T e T a T c T d T b Process 1 Process 2 T x Process 1 Challenges of Distribution • Message (format, data type, encoding, ...) • Transport (TCP, UDP, RPC, shared memory, ...) • Addressing (reliability and high availability) • Performance Processor 1

Distributed Applications • Many nodes • Ethernet, backplanes, and more Administration Call Server Shelf Controller H/W Control ... COTS Server e-Infrastructure Element

Distribution Open socket. Establish connection. Receive msg to transmit. Encode and send msg. Processor 1 Processor 2 Capsule A Capsule B Open Socket. Establish connection. Listen. Decode msg framing. Decode msg header and data. Forward msg to destination.

Rose RealTime Generated Application Capsule A Capsule B portX portY Wired ports Wired Port Communication • Wired ports are defined at design time • Wired connections are created and destroyed with the capsule instance

Topics • Distribution Overview • Dynamic Connections • Connexis

Unwired ports Unwired Port Communication Unwired ports are: • Used to model dynamic communication channels • Registered or bound to other unwired ports • Dynamically connected at run time instead of at design time • Used for modeling client/server designs where a service is shared by a large number of clients Rose RealTime Generated Application Capsule A Capsule B portX portX

Internal Layer Service Internal Layer Service (ILS) The Internal Layer Service (ILS) is used to: • Connect unwired ports within the same executable or instance of the Target RSL • Register ports locally • Establish connections between local unwired ports (called “bindings”) Rose RealTime Generated Application Capsule A Capsule B portX portX portx.pong().send(); portX.ping().send();

Publisher-Subscriber Pattern • For a given service, there is: • One server, the publisher • Many clients, the subscribers • The service is uniquely identified by name • All subscribers are bound to the first publisher registered for binding under that name • Subscribers will be registered with the publisher up to the maximum replication factor of that publisher

No Publisher Available • If no publisher exists, the subscriber registrations are queued (in order) waiting for the publisher to register • Subscribers not bound continue to be queued until an instance of the publisher becomes available due to one of the following: • A subscriber deregistering • A publisher with a larger multiplicity registering • The publisher resizing

Published vs. Unpublished Ports • Service Access Point (SAP) • A term used to describe an unwired port that is participating in a connection as the subscriber (or client) • SAPs always have a maximum cardinality of 1 • Service Provision Point (SPP) • A term used to describe an unwired port that is participating in a connection as the publisher (or server) • SPPs typically have a cardinality of N > 1

Registering Unwired Ports • Unwired ports can be registered in two ways: • Automatic registration - using information contained in the “Registration override” box • Application registration - by the application developer

Automatic Registration Registration is attempted using the name provided in the “Registration override” box. If no text has been entered into the “Registration override” field, the port will be registered under its own name with the ILS. Registration is attempted once at startup. Application Registration Port registration must be handled by the application code. The “Registration override” box is ignored. Registration is done at run time when the application calls a communication service operation. Automatic vs. Application Registration

Registration String • A registration string is used to identify a unique name and service under which subscribers and publishers will connect. • The string has the following format: [[[<service_name>]:][//<IP address>]/]<registration_name> If the service name is not provided, Rose RealTime defaults to the Internal Layer Service (ILS). • Here are some examples: • name • service1:name • service2:name • service3://address/name

Scenario: Publisher Registers with the ILS • port2 is registered with ILS • Two subscribers, port1 and port3, attempt to make connections to the publisher • port1 connects to port2 because port2 has been registered with the ILS • Only capable of connecting ports locally • port3 fails to connect to port2 because port3 is attempting to connect using the ILS • Only capable of connecting ports locally

Topics • Distribution Overview • Dynamic Connections • Connexis • Adding Connexis Support • Locator Services • Connexis Viewer • Distributed Design Using Connexis

C++ Introducing Connexis Connexis: A software development framework that extends Rational Rose RealTime and lets you model, build, deploy, and visualize distributed, embedded applications

C++ Connexis Benefits • Integrated with the Rose RealTime toolset • Full life cycle • Supports patterns for creating high-availability applications • Allows designers to focus on building revenue-generating features, not distribution code

C++ Processor 1 Processor 2 Capsule A Capsule B PingPong PingPong Distribution With Connexis • Communication infrastructure • Connection status and tracing • Fault tolerance • Flexible transports • UDP/IP • TCP/IP

C++ Connexis Architecture Rose RealTime Model Connexis Viewer Connexis Locator DCS Transport Target Agent Connexis Architecture Control Data

C++ Connexis Architecture (cont.) UML Model Locator Service Distributed Connection Service Transport Control Data Control Paths - components involved in registering and deregistering endpoints Data Path - data passes through Transport component

C++ Connexis Capsules • Development Configurations • RTDBase_Agent • RTDBase_Locator_Agent • Production Configurations • RTDBase • RTDBase_Locator

C++ Establishing Connexis Connections • Local connections • Explicit endpoint connections • Locator connections The connection method is determined at run-time by the registration string used when the port is registered with the Target Run-Time Services Library

C++ Connexis Customization • Configure connection audits • Adjust buffer counts and sizes • Adjust thread priorities and stack sizes • Adjust message delivery timing characteristics

C++ Topics • Distribution Overview • Dynamic Connections • Connexis • Adding Connexis Support • Locator Services • Connexis Viewer • Distributed Design Using Connexis

C++ Adding Connexis Support to a Model Adding Connexis support to a model involves the following steps: • Sharing the Connexis packages • Configuring a model for Connexis • Adding the appropriate port registration code • Initializing the Connexis capsule role • Configuring a component for Connexis • Adding Connexis command-line arguments

C++ Sharing the Connexis Packages • Connexis functionality is defined in a set of packages that must be shared into your model • The Connexis > Share Connexis Packages option under the Tools menu helps you to quickly include all Connexis elements

C++ Configuring a Capsule for Connexis • Select Configure Capsule for Connexis from a capsule’s context menu.

C++ Adding the Appropriate Port Registration Code • Connexis uses unwired ports • Unwired ports must be registered with the Connection Service by automatic or application registration • The registration string determines how the connection is established with Connexis

C++ Initializing the Connexis Capsule Role • The Connexis capsule role in the application must be initialized before any ports can be registered with it • The recommended approach for ensuring this is to subscribe to the RTDInitStatus publisher on the Connexis capsule and wait for the rtBound event The subscriber port can be created and configured by selecting DCS Initialization and Control Port in the Configure Capsule for Connexis dialog box

C++ Configuring a Component for Connexis • Select Connexis >Configure Component from a component’s context menu to create a component dependency to a DCS library.

C++ Adding Connexis Command Line Arguments • Several Connexis command-line options allow for configuring how an application behaves relating to Connexis • Can be added to the Parameters box in a Component Instance Specification or when starting the application from the command-line

C++ The Locator Service • Locator Service maintains a registry of publishers and subscribers and matches them. • Benefits: • Allows dynamic modification of the network topology • Load sharing, backup services

C++ Locator Service • Allows endpoint locations to remain transparent to the application • Can be used to find a service anywhere in the distributed application • Finds appropriate endpoints and feeds them back to the connection service

C++ Locator Registration Examples Example 1: Basic Locator registration • Publisher:<port_name>.registerSPP("dcs:/service1"); • Subscriber:<port_name>.registerSAP("dcs:/service1"); Example 2: Custom ranking • Publisher:<port_name>.registerSPP("dcs:/service1 (locator_rank, 1)"); Example 3: Specifying the protocol • Subscriber:<port_name>.registerSAP("dcs:/service1 (locator_transport, crm)");

C++ Scenario: Publisher Registers with the Locator

C++ Connexis Viewer • Examines connection status in realtime • Sees published services and subscriptions • Traces publishers, subscribers, transport, and locator events • Filters information • Sees applications in one or multiple instances • Collects and display metrics

C++ Connexis Viewer: Actual View

C++ Connexis Viewer: Tree Object Definitions Session Publisher Processor (from the Model) Subscriber (Bound) Processor (User defined) Subscriber (Unbound) Component Instance (from the Model) Bound Connection Filter (Active) Component Instance (User defined) Filter (Inactive) Named Service Waiting for Target Inactive Active Disconnected Component Instance “States”:

C++ Virtual Circuits Virtual circuits represent the Connexis connections that are currently established in the running model Indicates that the Ping capsule has a pingPong subscriber port registered with the “pingpong” service Indicates that the Pong capsule has a pingPong publisher port registered with the “pingpong” service and 1 out of 1 of its instances are connected Represents the virtual circuit (actual connection) between the Ping and Pong capsules

C++ Trace Windows • Event tracing is available on component instances, port references, and virtual circuits • Trace filters can be defined, saved, and applied easily

C++ Metrics Service The Metrics Service collects real-time DCS performance information for a component instance, which can then be used to tune the application

C++ Adding Viewer Support to a Model • The Viewer communicates with the executing model through the Target Agent using the Connexis endpoint (CNXep) • To include the Target Agent in the executable, select Target Agent (Viewer Debugging) in the Configure Connexis Capsule dialog box

C++ Connexis and High Availability • Redundant Locator Service • Automatic switching to backup service publishers • Load sharing between publishers • Automatically handle overflow situations • Configurable transport audits

C++ Patterns for High-Availability Shelf Controller Device Primary Locator Primary Locator Backup Locator Backup Locator

Mastering Rational Rose RealTime Distributed Models and Connexis