Which strategy to use in Client-Server messaging to trigger specific behavior in them?

Question

I'm developing a virtual assistant to manage transactions in a business. I'm using an external service to handle Natural Language and get intents, actions and parameters from my user requests.

The client sends requests as text strings to my application logic and my application logic routes the messages to the NLP or the Business.

When a client needs authentication to make a transaction I show a modal dialog to ask for its credentials. Then I append a tag like '[XXX]' to the strings so my entry component can route the message directly to the Business service. I also add the same tag to client responses when I want the client to trigger a specific behavior. For example:

• Client sends the string 'I wan to log in' to Server.
• Server sees no [XXX] tag, so it hands the string to the NLP service.
• NLP service answers with the action 'UserLogIn' to the Server.
• Server makes a lookup for the action and sends the string '[Require_Auth]' to the Client.
• Client sees a [XXX] tag, so it parses the string, shows a modal, asks for credentials and sends '[Username]ZZZZZZZZ[Password]ZZZZZZZZ' to the Server.
• Server sees a [XXX] tag, so It parses the string and hands the parameters to the Bussiness Service.
• Business Service creates a session and hands it to the Server.
• Server bookmarks session and sends the string 'Welcome "username"!' to the Client.
• Client sees no [XXX] tag, so it displays the string in the window.

This means that the client and the server programs have to parse the messages to look for '[XXX]' tags to trigger specific behavior.

I consider this solution to be bad, so what would be a better approach to trigger specific behavior via messages between client and server?

Answer 1

If I understand well your design, the general idea of the interaction between the parts of your system would look somewhat like this:

So you are using tags for 2 purposes:

1. let the server know if the request is to be parsed (no tag) or if the request was parsed and provides parameters to be extracted (tag indicating a command/transaction to perform)
2. let the client know if it receives an answer to display (no tag) or if further info is to be requested (tag, with parameters to request or client commands to execute)

To tag or not to tag, ...*

In this context, I'd think that your tags are not a good idea, for the following reasons:

• the user might himself add square brackets ([...]) in his plain text request. This could defeat your logic and cause requests to fail. And this could be misused if tags are added on purpose.
• business service might also return data that contain square brackets.
• your tag is used to save a state of processing in the request. However in more complex scenario, you'd need more state data that available in the tag . For example if client issues a query request ("get all customers having bought producX") and later refines this query ("give me only those in LA"). You could not handle this only with tags.
• The tag is also difficult to manage if the answer provided by the client to a request is not sufficient (e.g. in your example password was not entered, or appears to be invalid).

Alternatives

I'd suggest to define a message structure to the server which clearly shows the the command to be performed, and the parameters provided. For example:

• user types "I want to log in"
• client sends to server a message "PARSE", with parameter "I want to log in".
• later in the interaction when the client has provided all the data: the client may then sent a message "LOGIN", with the expected additional parameters.

The replies from server to client should follow the same logic adopt a structured approach (e.g commands like "INFORM USER", "DISPLAY RESULT", "PREPARE COMMAND" and corresponding parameters).

From a practical point of view, you could for example use a message structure inspired from the url syntax and for the reply, you could opt for a JSON like format. The important thing is that the message format should be more structured than just a tag.

Conclusion

The next question is whether you want your server to use a restful stateless approach, or if you want to manage client sessions and keep the state of the client requests on the server side). In view of the importance of context in NLP based interactions (see example above about the refinement on a query), and as the server is responsible for invoking NLP, the second approach could be more appropriate in your case.