[MOBY-dev] [RFC] Exception Reporting in bioMOBY v1.7 - INBproposal

Fri Sep 2 10:32:04 UTC 2005

Martin Senger escribió:

>Thanks for the updated document. Before I express my comments to it
>here is a few bits regarding RFC procedure for this proposal (assuming
>that we agreed on an RFC procedure as, or close to, suggested in
>previous emails:
>
>1) I second the proposal (so it can become an RFC) 
>
Thanks. Let's move this quickly and go over the asynchony one ;-)

>2) I suggest to resolve it (accept or refuse) before September 15 (so
>this is an RFC calendar). Concretely, I propose that Mark will ask
>selected voters after this date to vote on it. (BTW, I like and
>support his idea to have a year-long tenure on the voting list (that's
>actually very close why OMG has its Architecture Board also with
>rotating, and *dedicated*, people).
>
>Now back to the proposal, here are my comments (I suggest that those
>comments that are acceptable by the INB authors, and that are not in
>contradiction with the email discussion, will be incorporate and a new
>draft will be circulated - perhaps already without reasoning).  
>
Here you have the new draft (version 1.7, version 1.6 was internal review)

>Generally, I like the proposal, my comments are only about details.
>
>1) The attribute names 'Value' and 'Description' are not
>intuitive. They should express more what they are about. What about
>"errorCode" (or only "code") and "errorMessage" (or only "message")? 
>
Changed to "exceptionCode" and "exceptionMessage" so we refer to all 
exceptions (errors, warnings and other information messages). 
"errorCode" sounds to me like "only for errors"...

>2) I know that the article name in Simples in Collection is an
>optional part of the proposal - but I agree with Mark that using there
>again the term "articleName" is bad (too overloaded). What about to
>use there a completely different tag, like "elementId"?
>
>>From this change (if accepted) follows at once that the attribute name
>in mobyException should not be "refArticleName" (because sometimes it
>refers to a non-article name) - so why not to call it just a "ref", or
>"refElement"?
>  
>
Let's name it refElement and keep on mentioning the optional part if 
Mark agrees that naming Simples inside Collections could be possible. 
Anyway, I keep on guessing what happens with my articleNames if I gather 
several Simples and build a Collection with them (in a workfow), or I 
split a Collection into its Simples and send them to other service(s) 
one by one (in a workflow), and how those articleNames relate to the 
"elementID"?

>3) I would like to have (in the exception API handling) a remark that
>the clients are obliged to be aware that a service can also raise an
>exception that will be delivered in the SOAP envelope (that is a
>standard way). As I said, good clients have to do it anyway (because
>your service does not have always full control what to return back) -
>so I would keep this option there.
>  
>
Is mentioned in the last part of the document, but there is nothing we 
propose about the structure and content of the SOAP Fail payload... 
Should that be discussed, or better we focus on the MOBY part and just 
mention that the clients should be aware that some exceptions could be 
in the SOAP layers (ie, write your SOAP exception handling code in your 
client for better exception catching in all the layers of the 
communication)?

>4) Just to keep in synch with other software projects, I would add one
>more severity level - a simple "message" (so we would have, errors,
>warnings, messages).
>  
>
That would be, for example:

a. Exception severity (*severity* attribute in *mobyException* tag)
Values: *error*  | *warning *|* information*

>5) The list of codes is not always clear:
>   - should the sub-phrases in 201 be distinguish by a separate code?
>   - 621 (service not available) means actually that the resources the
>service wishes to use are not available (because if it was a service
>itself, it would not have any chance to report it, that would be a
>soap exception mentioned above),
>   - 622 (malformed Moby response) - what is a response here? - and
>anyway, this may be difficult to catch (I know in SOAP::Lite you do
>not get control only when the whole XML is parsed)
>   - why do you call some codes "client-side detected errors"?
>
>   - generally, I would put less codes and rather to define how
>service providers can expressed their own service-specific codes (by
>saying in which range they should put such specific codes)
>  
>
Rewritten the errors part. The main objetive, in our opinion, is to list 
the common errors that could occur in the execution of a web service 
(list taken from LSAE) _and_ the errors common to all bioMOBY services 
(as extension to LSAE). Only the errors that are particular to specific 
services are should not be included. We are using the recommendations in 
LSAE to extend the error codes range.

Note that there are a number of errors (service not available, for 
example) that only the client can report. We can call them client-side 
detected errors and give some codes, or just skip them, reduce to scope 
of this proposal only to the bioMOBY errors reportable by the services, 
and give the clients the freedom to report client-side detected errors 
as they want.

>6) Some typos:
>   - articlename attribute should be articleName
>   - "<--- BioMOBY parameters --->" is a wrong term (a "parameter" is
>something else in Biomoby API)
>  
>
Changed that

>7) Attributes in mobyException (refArticleName, or whatever name we
>will agree on, and reqQuery) should be made optional - so an exception
>can refer to the whole response (or to a whole query if only reqQuery
>is present).
>  
>
I agree, that allows us to report an exception for the whole mobyContent 
(it was in the motivations but no clearly stated in the specification 
proposal). Already added.

>   With regards,
>   Martin
>  
>
Thanks for the comments and corrections,

David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0501INB-ExceptionReporting-v1.7.doc
Type: application/msword
Size: 187392 bytes
Desc: not available
Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20050902/938c216c/0501INB-ExceptionReporting-v1.7-0002.doc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dgpisano.vcf
Type: text/x-vcard
Size: 338 bytes
Desc: not available
Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20050902/938c216c/dgpisano-0002.vcf