System Notifications and Action Messages

As described in the H4v3n testing page, the ability to send batches of method calls in a single request method (along with the tolerant reader and built-in assertions within each method result) makes the implementation of remote end-to-end testing fairly simple.  One other facet of the request message batching of method calls is used to simplify the retrieval of system notifications and action messages.  It can best be described as a sort of polling mechanism, without any actual polling.

It works for each client application with a simple timestamp stored as a property of the object that handles client communication with the server.  Each time a request message is posted to the web service, the timestamp is compared with the current time.  If the interval between the two is greater than the defined minimum value (configurable), then a method call to retrieve system messages is automatically appended to the outbound request message.  This method call to retrieve system messages can retrieve many different types of messages from the system.

Any results of the query for system messages is handled automatically by the logic of the AppLib classes which process response messages received by the client.  System messages are structured somewhat like a request message, except they are a request from the server to execute logic within the client application.  They are processed by a mini-pipeline on the client just like on the server, complete with a controller to route the request to the proper internal method if properly authenticated.  Client authorization for the system messages is automatic, since any client-side data is partitioned per system.

This mechanism can be used for any type of automated processing that makes sense to be distributed down to each client application.

RUM: End-to-End Testing and Workload

RUM stands for “Real User Measurements”, and  are collected from software systems being used as they would be in actuality (prior to release) or during real-world use in production once that becomes possible.  There are two important rules to keep in mind when collecting Real User Measurements:  first, the system must be tested end-to-end, as it would be used in a real-world scenario; and second, the metrics depend a great deal on the workload the system was running at the time they were collected.  For example, a system will produce very different (higher) metrics with a single user than it would with many thousands of concurrent users.  A good shorthand way of looking at it is RUM = end-to-end testing + workload.

End-to-end system testing is not just the only way to collect realistic performance metrics, it is also the best way to test the functionality of a system.  Some complex issues will only occur while the system is under significant load (as various subsystems become performance bottlenecks).  End-to-end testing conducted while the system is processing a heavy workload is often the only way to expose these types of intermittent behavior.




The H4v3n native application contains test harness functionality used to run remote end-to-end tests of the API’s, as outlined in the diagram above (refer to the H4v3n Testing page for more specific information).  Any account assigned as a member of one of the testing roles can use this functionality.  The test files are essentially request messages that have been saved as files, and modified to include variables which are replaced with realistic values at runtime.  The test files also depend on the functionality of the Tolerant Reader parsing logic to be able to add extra elements to the request message that are needed by the test harness, yet do not “break” the parsing of the messages in the API pipeline.

In the environment shown above, remote end-to-end testing of the API methods tests the following functionality and/or performance (directly or indirectly):

  1. The remote end (number 1 above) starts with the client workstation network configuration, host OS configuration and security.
  2. [direct] The correct use of the keyfile for systems, connection endpoints and accounts.
  3. [direct] The connection from the client application to the chosen web service (endpoint URL), which includes the transport mode [cleartext message, compressed message, compressed and encrypted message] as well as the selected protocols (SOAP/RPC vs. HTTP/REST).
  4. [direct] The client application SDK library functionality (creation/format of request messages, etc).
  5. The remote user’s ISP network used to reach the organization’s DMZ firewall.
  6. The DMZ firewall rules which allow access to the reverse proxy.
  7. The DMZ network configuration.
  8. The reverse proxy configuration and functionality, which is generally only used as a port-forwarding pass-through.
  9. The internal firewall rules, which allow the reverse proxy to access the internal network load balancers.
  10. The internal network configuration.
  11. The internal load balancer configuration and functionality.
  12. The web server host OS configuration and security.
  13. The app server (IIS) configuration and security.
  14. [direct] The ASP.NET web service configuration and security, hosted under IIS.
  15. [direct] The web service message processing pipeline:
    • the request message was accepted and correctly parsed
    • the TTL check was successful
    • the authentication of the message account credentials was successful
    • the authorization of each specific method in the batch was successful
    • the mapping of the message to the correct API was successful
    • the mapping of message parameters to internal method parameters was successful
    • the DAC builder method correctly configured a SqlCommand object to be passed into a DAC utility method
    • the DAC utility method successfully executed the SqlCommand and results returned
    • when the batch of methods were all completed, the collection of results was returned back up the pipeline
  16. The database server host OS configuration and security.
  17. [direct] The app server (MySql) configuration and security.
  18. [direct] The response message was successfully serialized and returned to the client, with the correct compression and/or encryption.
  19. [direct] The client app SDK successfully parsed the response message.
  20. [direct] The returned results were the correct data and type.

The results of all the tests must be verified after they are run.  Positive tests are verified in the database server (number 2 above) by using the database server console to observe the data in the various tables, making sure the expected test records and values have been stored.  Negative tests are verified in the web service log files (number 3 above) using a text editor to observe that the error messages logged match the negative tests that were run.  Finally, database mirroring, replication and sharding (number 4 above) each require their own separate testing and verification.




Web applications test almost all of the same things as the API testing, but use a tool to automate the browser (Selenium in this case) to also test the functionality of the application itself.  The web application consists mainly of server-side logic to merge the data returned from the API method calls into the HTML rendered for each page.  Selenium scripts simulate the actions of a user as they navigate through the web application and use the functionality of each page.


The near term plans for the Distribware and H4v3n projects are as follows:

  1. Finish the functionality of the H4v3n project, which includes all of the Distribware core plus the custom H4v3n functionality built on top of it.
  2. Create new pages for this blog, with full instructions for installing H4v3n plus a matching zip file of scripts and executables to be downloaded.  H4v3n serves two purposes:  a)  it has a lot of useful functionality, sort of like a fully encrypted version of Sharepoint on steroids, and b) it acts as a tutorial to show how to build custom systems on top of the Distribware platform.
  3. Update all of the GitHub code repositories, and convert them to public.  GitHub will only be used for source control.
  4. Create additional pages with instructions for using the test harness along with a downloadable zip file of tests.

Additional posts will document the progress of these steps as they occur.  Once they are all complete, the next goal will be to move all documentation into an instance of H4v3n, along with a web portal to provide access to public content.

Distribware Platform

This blog contains some high to mid-level documentation for the Distribware .NET platform, intended to explain what is is and how it works without getting too bogged down in the low-level details.  Those details are best described by the open-source code, hosted on GitHub.

At the time of this post, the code repositories are private, due to the fact that I am still adding functionality.  When the prototype system (H4v3n) is complete, the repositories will be converted to public and the system will enter the beta phase of development.  More to come…