Gateway

waits for the Signal. The source of the Signal is NOT REQUIRED (and might not

even be a Participant in the Choreography). There are no specific recipients of

a Signal. All Participants of the Choreography (to comply) MUST be able to see

the Signal.

Multiple: in Normal Flow

Yes. But they can only be a collection of valid Catch Events. As in Orchestra-

tion, this acts like an OR. Any one of the incoming triggers will continue the

Choreography.

Multiple: Attached to

Yes. But they can only be a collection of valid Catch Events. As in Orchestra-

Activity Boundary

tion, this acts like an OR. Any one of the incoming triggers will interrupt the

Choreography Activity.

Type of Event

Usage in Choreography?

None

Yes. This is really just a graphical marker since the sending of the previous

Message in the Choreography is really the end of the Choreography. The

Participants of the Choreography would understand that they would not expect

any further Message at that point.

Message

No. A Message End Event, in a stand-alone Choreography, has no way to

show who the senders or receivers of the Message should be. A

Choreography Task should be used instead. Thus, a None End Event should

be used as a graphical marker for the “end” of the Choreography.

Error

No. These are Throw Events and there would be no way to indicate the

Participant that is the source of the Error.

Escalation

No. These are Throw Events and there would be no way to indicate the

Participant that is the source of the Escalation.

Cancel

No. These are Throw Events. As with a Message Event, there would be no

indicator as to who is the source of the Cancel.

Compensation

No. These are Throw Events. As with a Message Event, there would be no

indicator as to who is the source of the compensation.

Signal

No. These are Throw Events. As with a Message Event, there would be no

indicator as to who is the source of the Signal.

Business Process Model and Notation (BPMN), v2.0.2

343