JBoss.orgCommunity Documentation

Chapter 4. Unsupported

4.1. Parallel
4.2. Global Escape
4.3. Raise
4.4. Unordered
4.4.1. Syntax
4.4.2. Usage
4.5. Merge
4.5.1. Syntax
4.5.2. Usage

This chapter describes constructs that are still work in progress.

This means that they may be included in the tool support for the notation, but may change in a future version. So any use of these constructs are not guaranteed to be supported in future versions of the tools.

4.1. Parallel

The parallel construct defines a set of paths that represent behaviour that should occur concurrently.

The syntax for the parallel construct is: 

parallel "{"
    ...
{ "}" and "{"
    ... }+
"}"

For example, 

parallel {
    CheckStock from Seller to Wholesaler;
    StockAvailability from Wholesaler to Seller;
} and {
    CreditCheck from Seller to CreditAgency;
    CreditReport from CreditAgency to Seller;
}

4.2. Global Escape

The concept of a 'global escape' is to support the abrupt termination of a set of activities based on the occurance of a situation. The situation may result from an interaction, or an internal condition within one of the co-operating participants, which subsequently results in the other parties being informed to 'escape' from their normal activities. 

try "{"
    ...
{ (
"}" catch [ "@" <Participant> {"," <Participant>}* ] <Type> "{"
...
|
"}" interrupt [ "@" <Participant> {"," <Participant>} ] "{"
    ...
) }*
"}"

There can be zero or more catch blocks, and zero or more interupt blocks.

The catch block represents a set of activities triggered based on an exception being raised at local participant (see the raise activity. If a located participant is specified, then this will be the participant at which the exception will be raised - and the initiator participant for any subsequent activity performed in the block. If more than one participant is specified, then each of these participants will need to be synchronized in their decision to escape from the try block.

The interrupt block represents a set of activities triggered by some internal condition. If a located participant is specified, then this will be the participant at which the interrupt will occur. As with the catch block, this will also be the initiator participant for any subsequent activity performed in the block. If more than one participant is specified, then each of these participants will need to be synchronized in their decision to escape from the try block.

The following example shows how internal decisions within the Buyer can be used to escape from the repetition of receiving quotes from the Seller, and result in either accept or cancel quote messages being sent to the Seller. 

try {
    repeat @ Seller {
        Quote from Seller to Buyer;
    }
} interrupt @ Buyer {
    AcceptQuote from Buyer to Seller
} interrupt @ Buyer {
    CancelQuote from Buyer to Seller
}

The following variation repetitively gets a quote from the Supplier until the Buyer decides to escape from the normal block by raising a Quit type that is caught at the Buyer and used to send a CancelQuote message to the Seller. 

try {
    Enquiry from Buyer to Seller;
    repeat @ Seller {
        Quote from Seller to Buyer;
        choice @ Buyer {
            raise @ Buyer Quit;
        } or {
            ...;
        }
    }
} catch @ Buyer Quit {
    CancelQuote from Buyer to Seller
}

4.3. Raise

The raise construct is used in conjunction with the global escape catch block, to enable a normal flow to terminate and jump to the appropriate catch block.

Note

How do we handle propagation - if no catch block exists for raised type, then it is passed out? Does this apply to sub-protocols? 

raise "@" <Participant> <Type>;

As shown in the previous section on global escape, the raise can be used to escape from a normal flow of activities into a catch block. 

try {
    Enquiry from Buyer to Seller;
    repeat @ Seller {
        Quote from Seller to Buyer;
        choice @ Buyer {
            raise @ Buyer Quit;
        }
    }
} catch @ Buyer Quit {
    CancelQuote from Buyer to Seller
}

4.4. Unordered

unordered "{"
    ( <Activity1> ";" )+
"}"

Note

Syntax to be defined. One possibility would be to find a symbol, other than ';' to represent an ordered relationship between the activities. However this is easy to misread, and therefore misunderstand the description. We could use a similar structure as with parallel, with each unordered activity being in a separate path - this would enable groups of activities to be unordered - but then this would get confusing with parallel. The syntax above is another possibility, so use the same ';' separate as sequence, but enclose in an 'unordered' region.

4.5. Merge