Issue #27: Fault handling semantics

[Subbu Allamaraju <subbu@bea.com>]

I'm summarizing the earlier discussion from the "Fault handling with 
handleEvents" thread as Issue #27.

Questions:

a. How to deal with multiple events when any number of them could 
generate a fault? Immediately return the first encountered fault or 
carry generated faults within the response structure?

The question arises because, unlike interactions, failure to handle one 
event should not always stop the producer from processing other events. 
At the same time, it is useful to let the Consumer to know what events 
failed.

There is a general preference for carrying faults in response with a 
general fault for event processing aborted, with the fault including one 
or more failure reasons.

b. Should the Consumer indicate whether event processing should be 
aborted on the first fault?

If Consumer sends such a flag, is the Producer required to obey it? 
Probably not, because the portlet/Producer is aware of consequences of 
failures. If the Producer/portlet thinks that it is harmless to 
continue, it should be allowed to continue with the rest of the events.

c. Would allowing parallel event processing require portlets to be 
re-entrant?

We need to determine if there is a need for allowing parallel 
processing, and then add a conformance statement.

d. Consensus that the semantics on the order of the event arrays be 
dropped to a SHOULD conformance level.

This was decided based on the fact the not all Producers may be able to 
process events in the same order, and that this is not a testable assertion.