Throw and catch events come in several types including messages, signals, and errors. Let us consider these different types and when we might use each.
A message is a set of data based on some type definition (a data structure), which is sent from a sender to a receiver. The sender knows who the receiver is and addresses the message to the receiver. If the message cannot be delivered, the sender is informed and can then take the appropriate action, for example, they might retry sending the message later. In the context of the runtime environment, a message is a SOAP message sent from a service consumer to a service provider (or vice versa). The type definition is normally placed in an XSD for easy reuse, however, it may be in a WSDL file. It will often be in a WSDL file for pre-existing services.
A signal is a set of data, based on some type definition, which is broadcast from a sender and enters the Event Delivery Network as an event. If there are any subscribers for that particular type of event, the EDN will (most likely) deliver the event to them. We say "most likely" because the EDN does not offer the same guarantees about delivery as, for example, SOAP over JMS does.
The EDN does allow you to configure once and only once delivery, which is transactional—it is delivered in a global transaction—but it is not possible to create a durable subscriber. This means that if there is a system failure, signals may be lost and may not be delivered when the system is restarted.
Neither rollback nor retry mechanisms are provided by the EDN—except in the case of once and only once delivery. For this reason, signals are normally used when delivery is time sensitive and it no longer matters if a signal was delivered after a certain period of time has passed. The signal's type definition is also in XSD. Note that the sender (broadcaster) does not know whether there are any receivers (subscribers), how many there are, and whether the signals are ever delivered to them.
Note
The Event Delivery Network is a feature of the Oracle BPM Suite that provides a mechanism to publish events and optionally take various actions on them, such as pattern matching and to subscribe to events so that they will be delivered to the subscriber when they are generated. An in-depth discussion of its capabilities is beyond the scope of this volume.
Errors are exceptions. These would normally manifest as SOAP faults in the runtime environment. Exceptions are discussed in detail in Chapter 5, Handling Exceptions in Practice.
