API Design: Jak by měly odlišné skupiny chyb být řešeny z asynchronní XMLHTTP volání?

hlasů
0

Mám VB6 aplikace dědictví, které potřebuje, aby asynchronní volání webové služby. Webová služba poskytuje searchzpůsob umožňuje koncovým uživatelům dotaz centrální databázi a prohlížet výsledky přímo z aplikace. Jsem pomocí MSXML2.XMLHTTP, aby žádosti, a napsal SearchWebServicetřídu, která zapouzdřuje služba volání web a kód pro zpracování odezvy asychronously.

V současné době se SearchWebServicezvyšuje jeden ze dvou akcí volajícímu: SearchCompleteda SearchFailed. SearchCompletedUdálost je aktivována, který obsahuje výsledky vyhledávání v parametr případě, pokud je hovor úspěšně dokončí. SearchFailedJe aktivována, když je zjištěn jakýkoli typ selhání, které může být cokoliv od nesprávně formátovaný URL (to je možné, protože adresa URL je konfigurovatelné uživatelem), chyby sítě na nízké úrovni, jako je „Hostitel nebyl nalezen“, HTTP chyby, například chyby interní server. Vrací chybové hlášení řetězec ke koncovému uživateli (který je extrahovaný z těla odpovědi webové služby, je-li přítomen, nebo z textu stavový kód HTTP, pokud je odezva nemá tělo, nebo přeloženo z kódu chyby sítě v případě, že chyba sítě dojde).

Vzhledem k různým požadavkům na bezpečnost, volající aplikace nemá přístup k webové služby přímo, ale místo toho přistupuje to přes proxy webový server běží na místě u zákazníka, což přistupuje k aktuální webové služby prostřednictvím prostřednictvím VPN. Nicméně, SearchWebServiceneví, že volající aplikace je přístup k webové služby prostřednictvím serveru proxy: je to prostě dostane URL a řekl, aby žádost. Existence proxy je požadavek na aplikační úrovni.

Problém je v tom, že z pohledu koncového uživatele, to je důležité, že volající aplikace moci rozlišovat mezi chybami sítě na nízké úrovni ve srovnání s chybami HTTP z webové služby, a odlišit chyby proxy z chyb vzdáleného serveru. Například aplikace potřebuje vědět, zda požadavek se nezdařil, protože proxy server je dole, nebo proto, že dálkové webová služba, která proxy přistupuje dolů. Se zpráva specifické pro aplikaci musí být předložena ke koncovému uživateli v každém případě, jako je například „Hledání webová služba proxy server se zdá být dolů. Může být zapotřebí proxy server je třeba restartovat“ versus „proxy je v současné době v provozu, ale vzdálená webový server se zdá být k dispozici. obraťte se prosím na (jméno osoby odpovědné za vzdáleného webového serveru).“ Mohl bych zvládnout přímo ve SearchWebServicetřídě, ale zdá se, špatně generovat tyto konkrétní aplikace chybové zprávy z takového generického třídy (a třídy mohou být použity v prostředí, které nevyžadují proxy, kde chybové zprávy by již dávat smysl).

Toto rozlišení je důležité pro řešení problémů: problém proxy server lze obvykle vyřešit zákazníka, ale vzdálený chyba web server musí manipulovat třetí stranou.

Myslel jsem, že jeden způsob, jak řešit tento problém, by bylo mít SearchWebServicetřída rozpoznat různé typy chyb a zvýšit různé události v každém případě. Například namísto jednoho SearchFailedudálosti, mohl bych mít NetworkErrorudálost chyby sítě na nízké úrovni (což by znamenat problém s přístupem k proxy serveru), což je ConfigurationErrorudálost neplatné nemovitostí na SearchWebServicetřídě (například předávání nesprávně formátovaný URL) a ServiceErrorchyby, které se vyskytují na vzdáleném webovém serveru (z čehož vyplývá, že proxy pracuje správně, ale vzdálený server vrátil chybu).

Teď, když se nad tím zamyslíte, je zde také další chyba scénář: to by mohlo být možné, že proxy server pracuje správně, ale vzdálený webový server je dole, nebo proxy server byl špatně nakonfigurovány.

Je přístup pomocí více chyb událostí pro klasifikaci různých tříd chyb rozumné řešení tohoto problému? V posledním případě (proxy je spuštěna, ale nelze dosáhnout vzdálený server), Hádám, budu muset nastavit proxy vrátit specifický kód chyby HTTP, takže klient může rozpoznat tuto situaci (tedy něco konkrétnější než 500 odpověď).

Původně jsem držel jednu SearchFailedakci a jednoduše přidá další errorCodeparametr události, ale který dostal chaotický rychle, a to zejména v případech, kdy nebylo logické chybový kód k použití (například v případě, že VB6 vznáší „skutečné“ chyba, tj pokud třídy XMLHTTP není registrován).

Položena 27/08/2009 v 05:38
zdroj uživatelem
V jiných jazycích...                            


1 odpovědí

hlasů
1

Myslím, že některé myšlenky jsem použít s Java výjimky zde mohou platit.

Mít velké množství různých výjimek dostane dost chaotický, ale musíme dát dostatek podrobností k uživateli, takže nechceme ztratit informace.

Z tohoto důvodu mám malý počet konkrétních výjimek, které jsem hádat by odpovídalo vašim akce:

  • InvalidRequestEvent: Používá se, když uživatel zadá špatné informace
  • TransientErrorEvent: používat tam, kde je to problémy v oblasti infrastruktury, když opakování by mohlo fungovat.

Mám ve zvyku pracovat v prostředí, kde máme clustery serverů, takže pokud žádost uživatel narazí na umírajícího server, pak v případě, že znovu odešle ho nejspíš mít dobrý, a proto z jeho pohledu jednoduché opakování často pracuje. Nicméně někdy je chyba se službou jako sítě nebo databáze a v takovém případě uživatel potřebuje diagnostické informace hlásit na helpdesk. Z tohoto důvodu se musíme rozhodnout o další informace, aby se do výjimky. To je (pokud dobře rozumím) na vaši otázku.

V případě InvalidRequestException bychom vsadit dát nějaké informace o problémech se vstupem. Mohlo by to být na tratích „nerovnocených Parenthese“ nebo „Unknown column CUTSOMER ve stolním order“. V případě TransientErrorException to mohlo být „Proxy server je mimo provoz“.

Nyní v závislosti na vašich přesných Poľadavky nemusí vlastně zvolit, aby tento text ve výjimce, ale číslo chyby, které prezentační vrstva převede na řetězec s specifické pro národní prostředí (angličtina, francouzština ...).

Takže buď Výjimka by mohla obsahovat něco takového (omlouvám se za tímto syntaxe jazyka Java, ale doufám, že tato myšlenka je jasná):

BaseException {
    String ErrorText;     // the error text itself

    // OR if you want to allow for internationaliation

    int ErrorCode;        // my application specific code, corresponds to text held by the UI
    String[] params;      // specific parameters to be substitued in the error text
                          // CUTSOMER and ORDER in my example above


    int SystemErrorCode;    // If you have an underlying error code it goes here


    String SystemErrorText; // any further diagnoistic you might need to give to 
                            // the user so that they can report the problem to the 
                            // help desk.

    // OR instead of the text (this is something I've seen done)

    int SystemErrorTag;     // A unique id for this particular error problem. 
                            // This server systems will label their message in the
                            // server logs. Users just tell the help desk this number
                            // they don't need to read detailed server error text.

}

Odpovězeno 27/08/2009 v 08:03
zdroj uživatelem

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more