|Re: PapyrusRT example for SPP and SAP [message #1800239 is a reply to message #1800179]
||Fri, 21 December 2018 16:36
| Ernesto Posse
Registered: March 2011
Hi. Yes, there is a simple (toy) example in the git repo under models/tests/executable called "SPPInheritance", which I'm attaching for convenience. |
This example illustrates not only SPPs and SAPs but also optional capsules, inheritance and the built in services (Log, Timing, Frame). It also shows an example of how to use command-line arguments.
There is a Top capsule with two parts called client (of type Client) and server of type Server. The server part is optional and it is incarnated by the Top capsule.
The Server capsule declares an SPP port of type Service, a protocol which has a "request" message and a "response" message. The Client declares an SAP also called service, of the same type. There is a Server1 capsule which is a subclass of Server, and refines some of the actions in its state machine. Top incarnates an instance of Server1 in its server part.
Both Server capsules wait for the request message on their SPP port, and after some time, they return a response.
The Client starts by waiting for the service to be ready by listening for the built-in 'rtBound' message on its 'service' port. An rtBound message will arrive on a (SAP or SPP) port whenever the port becomes wired, i.e. connected (which happens when both ends are "registered", see below). The Client also has a timeout in case no rtBound is received. If rtBound is received, its SAP is connected to the SPP of the server, so it sends a 'request' message and waits for the 'response' message (also with a timeout).
A thing to note about SPPs and SAPs is that these ports need to be registered for them to be connected, and this depends on their 'registration kind' property. There are three kinds: automatic, application, and automatic (locked). Ports with registration kind automatic are automatically registered when the capsule that owns them is instantiated/incarnated, with no action necessary. Ports of type "application" are registered in action code with the "registerSAP" and "registerSPP" operations on the port, so you can control when they are registered, and they can be deregistered to with "deregisterSAP" and "deregisterSPP". Finally, "automatic (locked)" is like automatic, but they are not allowed to be deregistered and re-registered by action code.
By the way, just as there is an 'rtBound' message to signal when a port is connected, there is an 'rtUnbound' message to signal when a port is disconnected. The connection and disconnection can happen not only with SAPs/SPPs, but also with normal ports when a capsule is instantiated/destroyed in an optional part.
So the example is rather simple, but illustrates how to use these ports. Note that while they could be used to dynamically change the wiring of capsule instances, SPPs and SAPs where intended to be used in the design of an application consisting of layers of services, where lower levels provide services to higher levels.
Powered by FUDForum
. Page generated in 0.01991 seconds