[OASIS Issue Tracker] Commented: (CMIS-14) Can we simplify our SOAPfault design?

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/CMIS-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16962#action_16962 ] 

Al Brown commented on CMIS-14:
------------------------------

JIRA Cleanup

> Can we simplify our SOAP fault design?
> --------------------------------------
>
>                 Key: CMIS-14
>                 URL: http://tools.oasis-open.org/issues/browse/CMIS-14
>             Project: OASIS Content Management Interoperability Services (CMIS) TC
>          Issue Type: Bug
>          Components: Web Services Binding
>    Affects Versions: Draft 0.50
>            Reporter: Gary Gershon
>            Priority: Minor
>             Fix For: Draft 0.60
>
>
> A primary purpose of WSDL modeled faults is to allow additional structured domain data to be returned in the fault beyond the limited capability of a SOAP unmodeled  fault.
> Thus we see typical examples of a stock quote service with domain-specific elements, such as a stock price service modeled fault that includes the stock symbol as an element, and a credit card example that includes a name and credit card number as fault elements.
> However, all 16 of the CMIS modeled faults have an identical structure with simply an errorCode (Integer) and an errorMessage (String).
> Could we reduce the 16 down to a single ContentManagementFault by adding just one more element with an errorType (String or Integer enumeration of 16 types)?
> Rationale:
> 1. A considerable amount of schema and WSDL definition effort goes into defining all the relevant faults for an operation, and thus the schemas and WSDLs become simpler for us, the provider, and the consumer.
> 2.  If we need to add a type of exception for an operation, then the interface (port) does not need to change -- we simply return another existing enumeration value or add one.  This provides flexibility to evolve while preserving the operation's interface.
> 3.  This would be consistent with other major persistence and messaging frameworks like SQL and MQ which essentially each have a single throwable exception (fault) that represents a myriad of exception types and situations via a few instance variables for error codes.
> 4.  A single fault would generally be easier to "catch" and process by the consumer.  Most of the CMIS faults are non-recoverable and thus the consumer will likely simply want to format a consistent message for logging or display.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira