Quale strategia utilizzare nella messaggistica client-server per attivare comportamenti specifici al loro interno?

0

Sto sviluppando un assistente virtuale per gestire le transazioni in un'azienda. Sto usando un servizio esterno per gestire Natural Language e ottenere intenti, azioni e parametri dalle richieste dei miei utenti.

Il client invia richieste come stringhe di testo alla logica della mia applicazione e la mia logica applicativa indirizza i messaggi alla PNL o al Business.

Quando un client ha bisogno dell'autenticazione per effettuare una transazione, mostro una finestra di dialogo modale per chiedere le sue credenziali. Quindi aggiungo un tag come '[XXX]' al stringhe così il mio componente di entrata può indirizzare il messaggio direttamente al servizio aziendale. Aggiungo anche lo stesso tag alle risposte dei client quando voglio client per attivare un comportamento specifico. Ad esempio:

  • Il client invia la stringa 'I wan to log in' al server.
  • Il server non vede il tag [XXX] , quindi consegna la stringa al servizio NLP.
  • Il servizio NLP risponde con l'azione 'UserLogIn' al server.
  • Server effettua una ricerca per l'azione e invia la stringa '[Require_Auth]' al Client.
  • Il client vede un tag [XXX] , quindi analizza la stringa, mostra una modale, chiede le credenziali e invia '[Username]ZZZZZZZZ[Password]ZZZZZZZZ' al server.
  • Il server vede un tag [XXX] , quindi analizza la stringa e passa i parametri al servizio Bussiness.
  • Business Service crea una sessione e la consegna al Server.
  • Sessione di segnalibri del server e invia la stringa 'Welcome "username"!' al client.
  • Il client non vede nessun tag [XXX] , quindi visualizza la stringa nella finestra.

Ciò significa che il client e i programmi server devono analizzare i messaggi per cercare i tag '[XXX]' per attivare un comportamento specifico.

Ritengo che questa soluzione sia negativa, quindi quale sarebbe un approccio migliore per attivare comportamenti specifici tramite messaggi tra client e server?

    
posta Gerardo Cauich 14.07.2016 - 23:08
fonte

1 risposta

0

Se capisco bene il tuo progetto, l'idea generale dell'interazione tra le parti del tuo sistema sarebbe simile a questa:

Quindistaiutilizzandoitagper2scopi:

  1. consentealserverdisapereselarichiestadeveessereanalizzata(senzatag)oselarichiestaèstataanalizzataefornisceiparametridaestrarre(tagcheindicauncomando/transazionedaeseguire)
  2. comunicaalclientsericeveunarispostadavisualizzare(nessuntag)osesonorichiesteulterioriinformazioni(tag,conparametridarichiedereocomandiclientdaeseguire)

Pertaggareonontaggare,...*

Inquestocontesto,pensereicheituoitagnonsianounabuonaidea,periseguentimotivi:

  • l'utentestessopotrebbeaggiungereparentesiquadre([...])nellasuarichiestaditestonormale.Ciòpotrebbevanificarelatualogicaecausareilfallimentodellerichieste.Equestopotrebbeessereusatoimpropriamenteseitagvengonoaggiuntidiproposito.
  • ilservizioaziendalepotrebbeancherestituiredatichecontengonoparentesiquadre.
  • iltuotagvieneutilizzatopersalvareunostatodielaborazionenellarichiesta.Tuttavia,inunoscenariopiùcomplesso,avrestibisognodipiùdatidistatodisponibilineltag.Adesempio,seilclienteemetteunarichiestadiquery("ottiene tutti i clienti che hanno acquistato producX") e successivamente affina questa query ("dammi solo quelli a LA"). Non puoi gestirlo solo con i tag.
  • Anche il tag è difficile da gestire se la risposta fornita dal client a una richiesta non è sufficiente (ad es. nel tuo esempio la password non è stata inserita o sembra non essere valida).

Alternative

Suggerirei di definire una struttura di messaggi al server che mostri chiaramente il comando da eseguire e i parametri forniti. Ad esempio:

  • tipi di utenti "Voglio accedere"
  • client invia al server un messaggio "PARSE", con parametro "Voglio loggarmi in ".
  • più avanti nell'interazione quando il client ha fornito tutti i dati: il client può quindi inviare un messaggio "LOGIN", con i parametri aggiuntivi previsti.

Le risposte da server a client dovrebbero seguire la stessa logica adottare un approccio strutturato (ad esempio comandi come "INFORM USER", "RISULTATO DISPLAY", "COMANDO PREPARA" e parametri corrispondenti).

Da un punto di vista pratico, potresti ad esempio utilizzare una struttura del messaggio ispirata alla sintassi dell'URL e per il rispondi, puoi optare per un JSON come formato. L'importante è che il formato del messaggio sia più strutturato di un semplice tag.

Conclusione

La prossima domanda è se vuoi che il tuo server utilizzi un restful approccio stateless, o se vuoi gestire il client sessioni e mantenere lo stato delle richieste client sul lato server). In considerazione dell'importanza del contesto nelle interazioni basate sulla PNL (vedere l'esempio precedente sul perfezionamento di una query) e poiché il server è responsabile del richiamo della PNL, il secondo approccio potrebbe essere più appropriato nel tuo caso.

    
risposta data 17.07.2016 - 19:26
fonte