Framework Overview
==================
-This package is a framework for writing Xapps in python. The framework
-reduces the amount of code required in an Xapp by providing common
-features needed by all Python-based Xapps including communication with
-the RIC message router (RMR) and the Shared Data Layer (SDL).
+This package is a framework for writing RAN Intelligent Controller
+(RIC) Xapps in python. The framework reduces the amount of code
+required in an Xapp by providing common features needed by all
+Python-based Xapps including communication with the RIC message router
+(RMR) and the Shared Data Layer (SDL).
The framework was designed to suport many types of Xapps, including
-applications that are purely reactive to RMR messages, and
+applications that are purely reactive to RMR messages, and general
applications that initiate actions according to other criteria.
+For complete documentation see the ReadTheDocs site for
+`xapp-frame-py <https://docs.o-ran-sc.org/projects/o-ran-sc-ric-plt-xapp-frame-py>`_.
+
Reactive Xapps
--------------
This type of application is constructed by creating callback functions
and registering them with the framework by message type. When an RMR
-message arrives, the appropriate callback is invoked. An Xapp may
-define and register a separate callback for each expected message
-type. Every Xapp must define a default callback function, which is
-invoked when a message arrives for which no type-specific callback was
-registered. An analogy of this is AWS Lambda: "execute this code
-every time an event comes in" (the code to execute can depend on the
-type of event).
+message arrives, the appropriate callback is invoked based on the
+message type. An Xapp may define and register a separate callback for
+each expected message type. Every Xapp must define a default callback
+function, which is invoked when a message arrives for which no
+type-specific callback was registered. An analogy of this is AWS
+Lambda: "execute this code every time an event comes in" (the code to
+execute can depend on the type of event).
General Xapps
-------------
A general Xapp acts according to its own criteria, which may include
receipt of RMR messages.
-This type of application is constructed by creating a function that
-gets invoked by the framework. Typically that function contains a
-`while (something)` event loop. If the function returns, the Xapp
-stops. In this type of Xapp, the Xapp must fetch its own data, either
-from RMR, SDL or other source. The framework does less work for a
-general application compared to a reactive application. The framework
-sets up an RMR thread and an SDL connection, then invokes the
-client-provided function.
+This type of application is constructed by creating a single function
+that is invoked by the framework after initialization. Typically that
+function contains a `while (something)` event loop. When the function
+returns, the Xapp stops. In this usage, the Xapp must fetch its own
+data, either from RMR, SDL or other source. The framework does less
+work for a general application compared to a reactive application; the
+framework only sets up an RMR thread and an SDL connection before
+invoking the client-provided function.
Threading in the Framework
--------------------------
from the framework-managed queue. The framework is implemented this
way so that a long-running client function (e.g., consume) will not
block RMR reads. This is important because RMR is *not* a persistent
-message bus, if an RMR client does not read fast enough, messages can
+message bus; if an RMR client does not read fast enough, messages can
be lost. So in this framework the client code is not in the same
thread as the RMR reads, to ensure that long-running client code will
not cause message loss.
reactive Xapps. When an RMR healthcheck message arrives, this handler
checks that the RMR thread is healthy (of course the Xapp cannot even
reply if the thread is not healthy!), and that the SDL connection is
-healthy. The handler responds accordingly via RMA. The Xapp can
+healthy. The handler responds accordingly via RMR. The Xapp can
override this probe handler by registering a new callback for the
-appropriate message type.
+healthcheck message type.
The framework provides no healthcheck handler for general Xapps. Those
applications must handle healthcheck probe messages appropriately when
--------
Two sample Xapps using this framework are provided in the `examples`
-directory of the git repository. The first, `ping`, is a general Xapp
+directory of the
+`git repository <https://gerrit.o-ran-sc.org/r/gitweb?p=ric-plt/xapp-frame.git;a=tree>`_.
+The first, `ping`, is a general Xapp
that defines a main function that reads its RMR mailbox in addition to
other work. The second, `pong`, is a reactive Xapp that only takes
action when a message is received.
Code Review / ric-plt / xapp-frame-py.git / blobdiff