OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Issue 185 - Some thoughts

I can see three ways of addressing the problem of how to enforce that 
faults have a 1:1 mapping to fault type, something already required in 
WSDL but not in BPEL generated faults. Note that all of these proposals 
provide ways to resolve issue 182.

	Proposal 1 - Require that static analysis be performed on a BPEL to 
confirm that any time a fault is thrown with data or a fault handler is 
specified with a fault name and a fault type that the type used in the 
throws/catches all use the same type with the same fault name.
		Also specify that it is explicitly legal to catch a fault by its name 
and without specifying its type (if any). In that case the fault data 
won't be accessible in the fault handler. In the previous case a rethrow 
would be able to access the data.
		Pro: Requires no change to our syntax and minimum change to our behavior.
		Con: If there is a canonical definition in some document some place of 
what type belongs with which fault name and the programmer screws it up 
and uses the wrong type there is no way for BPEL to catch the error.

	Proposal 2 - Introduce a way to declare an association between a fault 
name and a fault type, probably as an extension to process and certainly 
as something that can be imported. We could then explicitly allow faults 
to be caught by name even if they have data associated with them. As 
before rethrow will rethrow the data as well even if it wasn't 
explicitly caught.
		Pro: Provides a way to centrally define faults (via import) and 
enforce their consistent usage across multiple BPELs.
		Con: Requires extending import, introducing a new file format and 
probably extending process as well.

	Proposal 3 - Don't require that faults have a 1:1 mapping to fault 
types. Explicitly specify that it's legal to catch a fault just by its 
name even if it has data associated with it. Rethrow in the previous 
case will rethrow the fault's data even if the fault was only caught by 
its name.
		Pro: Requires the smallest possible change to the existing spec.
		Con: Fault usage is likely to become a foul mess as people associate 
random data with faults.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]