Page History
| Div | ||||||
|---|---|---|---|---|---|---|
| ||||||
|
The following chapters describe how to send and handle signals of persistent state objects.
After an object has been created, the only way to influence its behavior is to send signals targeted at this object. This can either be done by using the <<PersistentStateSignalAction>> or the <<PersistentStateBroadcastSignal>> adapter. Both send signals, either targeted at a certain object given by its handle or to a whole set of objects defined by search predicates
| Info | ||
|---|---|---|
| ||
Upon sending a signal, a correlation ID will be logged to the transaction log (see Contents of the Transaction Log). If a conversation ID is supplied, this will be the conversation ID. Otherwise, a unique value will be generated. |
Sending Signals
A handle can be used to send signals to the object instance represented by the handle. To send a signal the <<PersistentStateSignalAction>> stereotype is used.
...
When sending signals, the xUML Runtime puts them into an event queue where they stay until being delivered. However, it might happen that a signal cannot be delivered, because the target object is not in a state that accepts this very signal.
The xUML Runtime will try to deliver the signal once. If a signal cannot be delivered, the default signal handler is invoked. Signals that do not have a default signal handler will be silently discarded. Thus, it is strongly advisable for the modeler to use the default handler mechanism.
In the PurchaseOrder example, the persistent state class defines an operation closeSignalDefault (see figure A Persistent State Class ). For the use as a signal handler, this operation requires the stereotype <<PersistentSignalDefaultHandler>> and has to be defined as static. As parameters, it takes the undelivered signal and a structure of type Event. While signal is defined model specific, Event holds generic system information about the signal delivery. The most important attributes are:
| Element | Description | |||||
|---|---|---|---|---|---|---|
| id | is a unique identification of the event. | |||||
| classifier | is a reference to the signal class. | |||||
| objectID | is the unique identifier of the object the signal belongs to, this is identical to the objectID of an object handler. | |||||
| eventType | in this case is Signal. | |||||
| eventBlob | holds the content of the signal.
| |||||
| eventTS | holds the planned time of event delivery. In this case, it is the time of the last delivery trial. | |||||
| creationTS | holds the time when the event was created. In this case, it is the time when the signal was sent to the object. |
For example, the activity diagram below implements the default handler operation of the CloseSignal for the PurchaseOrder class. This means, if the CloseSignal cannot be delivered, this activity diagram closeSignalDefaultHandler will be invoked. The activity diagram gets the undeliverable signal closeSignal (not used here) and an object of type Event with system information as input.
...
Overview
Content Tools