2014.12.02 Programmer's Notes

It's rather late to the game, but I just realize I don't cache misses in the client.
I'll need to do that to get peak performance and avoid hitting the backing store,
which is highly desirable in a client-server or web application environment.

I'm debating whether to add a Tomcat Servlet server for receiving the XMsgRqst messages,
and a corresponding client stub that you point to the Servlet's URL and perform puts to
send a message and receive an XMsgRspn message body for processing.  If I do so, I'll also
need to do something about thread-locking the client stub for the Swing prototype GUI.  Until
you get a response from the outstanding request, the prototype will just crudely block.

I want to add a request message class that sets a semaphore when it queues a message for
sending, and then blocks the current thread on that semaphore being cleared.  Some form
of process latching construct anyhow, so that the invoker of a client stub blocks before
returning from the send-receive processing.

When the response is recieved, the body of the response is set in the request message
instance and the semaphore is cleared so that the invoker can accept and process the response
to the request.

The request messages will be tagged with a client-generated UUID.  It's only going to be
assumed that that UUID is valid within the session.  I haven't decided whether to audit
requests and responses or not.  Doing so would slow down the server quite a bit, but I could
see the possibility of extreme security environments wanting to audit all requests and responses
in the raw.  Maybe I'll make that a configuration option for the SchemaDef, and let you
specify whether you want message logging or not.

A single client-side thread will be spun to process the queued messages.  Because of the
semaphores on the request message instances, if this thread dies, the client GUI would freeze up
with Swing.

When the message service thread is about to send out a request to the server, it invokes
a callback to the Swing desktop to set the "busy" cursor to display and client events to
act accordingly.  The custom widgets may need to have a few more classes added, so that all
of the custom widgets can check if the desktop is displaying the busy cursor before they
act on input events and actions.  Maybe I'll even make it play the alert ding, if I can.

I want a status bar on the main Swing desktop, with a message area and a "flashing light"
icon that can be toggled on some chunk processing events in the message send and receive
calls.  I'm presuming I can find an HTTPS request/response processing client package
that doesn't require a Tomcat jar.  I don't want to embed such heavy objects in the clients
if I can avoid it; I just want a formatting and transport API for building a single page post
that has the XML request embedded as a text field attribute of the page.  I *might* break
out common "header" attributes to form attributes as well.  I'd also like to hardcode a check
to refuse operation over a non-HTTPS/SSL connection.  I want "secure communications" to be the
default.

I forget whether Tomcat supports JNDI connection pooling or not.  I think it does.  I hope
it does.  I also need to look into my options for ensuring only a single request is processed
from a cookie-identified client at a time, because that have the same effect as multi-threaded
queueing of requests on the server side.  I might also wire some sort of "Cancel" message that
is allowed to be processed at any time, if I can.  Then all I need to do is add a volatile
"cancelled" attribute to the schema cache instance, and modify the server-side code to check
for whether that "cancelled" attribute is true or false before proceeding with each step of
a database service operation.  That's very much optional, though.  I'm quite content to block
clients on a single stream request/response conversation.