search

universAAL / middleware

The core software that uses semantic matchmaking for brokering messages among participants of an open distributed system.
10 stars 3 forks source link

Add Easy error management for ServiceResponses // making Error a semantic concept #3

Open amedranogil opened 7 years ago

amedranogil commented 7 years ago

I have seen the property: ServiceResponse.PROP_SERVICE_SPECIFIC_ERROR Which seems very useful to go beyond CallStatus.serviceSpecificFailure and provide the actual reasons for the specific error.

But since there aren't any methods to provide/read this property seems a bit obscure, maybe it is internal.

according to BLAME this was added by @vadimeisenbergibm

maybe it is about time to give this property some use: at least add getters (adders) and setters. maybe we want to define a "Java Exception" equivalent class to the service ontology?

Alfiva commented 7 years ago

IIRC that was indeed its purpose, but I dont remember if there were any more specs to it. I guess you can always get/set through the generic property getter/setters, but yes, proper methods would be in order. Personally I'm fine with it being an official feat.request/enhancement. I am not sold on the Java Exception equivalent though.

cstockloew commented 7 years ago

Looking at the code, this property was used to store any Java Exception (with the stacktrace serialized as String) that occurs during the handleCall method of the ServiceCallee. It is set by the bus (therefore no setter) and can be retrieved by the client as a normal output using

myServiceResponse.getOutput(ServiceResponse.PROP_SERVICE_SPECIFIC_ERROR)

therefore no getter.

amedranogil commented 7 years ago

I noticed the use of this property while reviewing the profile.server callee, it is being used to give more information about the service specific failure manually. But if I understood what you say, this information will be overridden in the event of unexpected exception during the call. So it is NOT a good idea to use it from service Callees. Previously to this I was using the RDF resource comment property on the service response to give a Human-readable explanation as to why of the error. But I think some means to add a semantic ("java exception like") mechanism for callers to automatically discriminate the error would be good.

cstockloew commented 7 years ago

I would like to avoid modelling java exception as they are java specific. Most of the Java Exceptions are way too specific to be used in a distributed setup (maybe even with uaal-implementation in different languages, like C++ or Swift). Also: What would a client do if the server answers with a OutOfMemoryException? I probably would not model these things and use the serviceSpecificFailure for all of them.

But generally, if you want to model something to be transferred between apps you do it by modelling it in an ontology. Maybe it's best to also model some of the errors in ontologies.

For example (just a very first idea): In DataRep (or ServiceBus) ontology, you model an "UnknownThing", which you extend in sub-ontologies. E.g. in Device-Ontology you create a subclass called "UnknownDevice" (among some other errors).

amedranogil commented 7 years ago

For example (just a very first idea): In DataRep (or ServiceBus) ontology, you model an "UnknownThing", which you extend in sub-ontologies. E.g. in Device-Ontology you create a subclass called "UnknownDevice" (among some other errors).

That was exactly the idea I was proposing, but expressing it as "java exception" might have been a lousy choice of words. The idea was to create a super concept "SomethingWentWrong" that could be extended in subsequent ontologies to better specify the problem: e.g: SomethingWentWrong < connectionProblem < SSLProblem < CertificationAuthorityNotValid

amedranogil commented 7 years ago

the idea behind this is for application to explain to the user what goes wrong, and what (s)he can do about it.

cstockloew commented 7 years ago

Not sure if this is not too specific (i.e. connectionProblem), but a general "InvalidInput" < CertificationAuthorityNotValid? We should always consider apps as a black box..

Are there any existing error-modelling ontologies out there? E.g RLOG (an RDF Logging Ontology) is for logging; we have the dependability ontology; but, is there something else? What is the state-of-the-art?

BTW: this would probably mean that most of the existing onts need to be extended...

amedranogil commented 7 years ago

We should always consider apps as a black box..

but even then there are common problems that are subsceptible of being taxonomized.

Are there any existing error-modelling ontologies out there? E.g RLOG (an RDF Logging Ontology) is for logging; we have the dependability ontology; but, is there something else? What is the state-of-the-art?

This certainly needs to be researched.

BTW: this would probably mean that most of the existing onts need to be extended...

This would only be an optional functionality

saiedt commented 7 years ago

I think, in oneM2M device management you may also find some error handling; see the following under http://www.onem2m.org/technical/published-documents :

amedranogil commented 6 years ago

This issue could be managed through https://github.com/universAAL/ontology/issues/8 : Once "semantized", there could be a super class for Error which could have "reason" (another Error), "description", and "possible actions" (multi-value String property containing possible actions the user could take to mitigate the problem). Error would be at the top of a Hierarchy which could be filled in at different levels, allowing also for applications to define their own errors.