Tessellation Software LLC
Enterprise Solution for Scalable and Secure Performance


The Tessellation Software Framework

The Tessellation Software Framework (TSF) is a powerful application for developing:
applications and/or ASP services that are distributable over a local, regional, or global network and/or the public internet that is:

  • Deployable in a corporation's internal data center/internal cloud OR within Amazon's AWS.

    Built to deploy via Rancher-Kubernetes latest (RKE 2) platform, the TSF is deployed on each server within a containerd image (and may also be deployed directly on a farm of internal servers).

ring of five (click figure for a larger view)
server to server connection
Figure 1 shows a high-level conceptualization of how TSF framework components on the server side communicate with a TSF Framework component instantiated by each client to provide a highly secure, two-way authenticated connection between purchasing organization's client and server-side code. The TSF also supports insecure, internal, high-speed connections for services executing within an internal data center.

The TSF Framework on the server-side, effectively, executes pre-instantiated images of purchaser's code and passes requests and commands sent by purchaser's client side code or GUI. Server-side code can send asynchronous messages to the purchaser's client.

Thanks to the multi-threading built into the TSF client side component, purchaser's client code can handle these messages without requiring purchaser to write multi-threaded code to handle this information. Similarly, the TSF server automatically provides for handling multiple siumultaneous connections to purchaser's server code and even multi-threads purchaser's code within each connection - enabling server to process multiple requests from a single connection concurrently.

Figure 2 shows that the TSF on the server side may be configured to execute on any number of servers in a "TSF Grid" enabling not only communication between purchaser server services and purchaser clients, but also between different services developed by purchaser to execute within the TSF. Thus, the TSF supports inter-service communication for services executing on a set of servers in data centers or in the cloud. If services are executing in an internal grid, the TSF enables configuration of insecure connections for higher efficiency.

Why purchase the TSF?:

Your time: Spend your resources working on the code that is particular to your business and where your company has expertise -- not on the "plumbing".
It takes a team of highly skilled top-tier developers over a year to even develop a subset of the capabilities offered by the TSF. Writing code that can:
  • Communicate: Make requests and receive responses across an internal or external network -- especially code that is able to concurrently handle many requests on behalf of each connection is extremely difficult to achieve properly.
  • Provide secure connectivity and authentication enabling end-users to connect with your capabilities and services is very difficult. The TSF provides this out of the box -- well beyond the legal standard required for contract and document execution, health care records, or financial transactions.
  • Scale: The TSF scales your code within and across any number of servers enabling you to grow your business and end-user base without modifying your code.
  • Provide non-repudiation capabilities: When needed the TSF can automatically digitially sign requests sent through the client components of this framework and automatically verify and store these signed requests on the server side prior to passing to purchaser's server side code. This can be used as legal proof that the request was issued: By that end-user; on a device they own (with their private key installed); and, that the end-user performing the action logged in from said device with their userName and password tied to that device (not from anywhere on the internet). All of this functionality is built in.

How the framework enables your success:

Implementer's , which is typically, but not always, a GUI, functions through provided client-side software; and, implementer develops Purchaser's code contains the business logic specific to the system being implemented. Said server-specific code executes within the TSF, with the TSF providing communication between each instance of purchaser's client-specific code (through an instance of the TSF's client-side software) to purchaser's server-specific code (through TSF's server side software) over a single network (TCP/IP) connection.

Multi-threaded communication is provided over a single network connection, even though purchaser need only write single-threaded code (for its client front-end and server functionality) that executes with/within this framework. The client-side component of the TSF software is able to process synchronous and asynchronous messages received through the Framework from purchaser's server-specific code through the TSF server-side software, while simultaneously sending additional requests to client's code that is executing on the server. TSF Client-side software accomplishes this by utilizing its own independent threads that it manages to send said messages through the server-side software and to execute code within purchaser's client-specific code. These messages are, in turn, able to be processed concurrently by said server-side software, which also uses its own independent threads to concurrently execute said requests on implementer's server-specific code.
On neither the client-side nor the server-side does purchaser need to write multi-threaded code to achieve any of this.

Numerous mechanisms are incorporated in the design to ensure an extremely high-level of .

An ultra-high level of during and post communications is provided, seamlessly enabling implementers' applications with highly encrypted, authenticated communications and digitally signed and verified content as well as providing for non-repudiation over a local or wide area network, an extranet, or even over the public internet.

Robust communication is provided, in that lost links may be automatically restored.

The purchaser develops its to fit into this framework by complying with a very simple interface. The purchaser develops which uses this to communicate with its server-specific code by simply having its client-specific code instantiate (i.e., create) a single class in the client component of this framework. The client components (of this framework) provide for communication between the client-specific code (written by the purchaser) and the server-specific code (also written by the purchaser) by exposing a few simple methods that may be invoked.

The server components of this framework automatically multi-thread the server-specific code written by the purchaser and also automatically enable the server-specific code to be run across multiple machines. If the purchaser desires, its server-specific code may even be multi-threaded within a single connection. This last mentioned capability, which is unique to this framework, would enable the server-specific code to generate and send an asynchronous stream to the client in one thread, e.g., while responding to synchronous traffic with another. It also would enable the server-specific code to execute and respond to multiple asynchronous commands from a single client concurrently.

The client components of this framework automatically multi-thread the client-specific code, enabling it to, e.g., receive asynchronous messages from the server-specific code while still allowing the end-user to simultaneously interact with the server by sending synchronous and/or asynchronous requests/commands. (Or, alternatively, if the client-specific code is not an end-user GUI but some sort of system interface, this automatic multi-threading could enable the interface to pass back information from the server-specific code to the system it was interfacing from while simultaneously accepting commands from that from system and passing them to the server-specific code on the server side of the system implemented with this framework).

The purchaser does not need to write multi-threaded code in either their client-specific or server-specific code to accomplish this concurrency.1

The purchaser also need not write any code to specifically set up or handle communication between the client-specific code and the server-specific code.

Additionally, the purchaser need not write code on either side to handle security as this framework automatically sets up and manages a two-way authenticated and encrypted SSL channel between the client-specific and server-specific code that the purchaser develops. The validation process is further enforced by an ACL (Access Control List) that ties username-password pairs to particular digital certificates.

This framework also automatically digitally signs all messages on the sending side (if desired) and verifies signed messages on the receiving side. This capability combined with a signature server provides for legally enforceable non-repudiation capabilities enabling the purchaser to prove the ownership of requests and commands emanating from its client-specific code (or, although less commonly desired, from its server-specific code) even after the fact.

Because so much functionality is provided by this framework, and because the interface for both the client and server components was designed to be extremely easy and quick to implement, the learning curve for a team to use this interface is usually less than one day, and, the development of systems that use this framework requires little time and code beyond what is required to write the business logic for the server side and the client-specific code, which is Usually a GUI specific to the application.

Finally, in addition to simplicity of use, this framework was designed with as a primary objective. Preliminary performance analysis indicates that this objective was more than achieved. Although it is a little too early to claim that performance is unparalleled, it is expected that this is in fact the case.

1-Unlike competing frameworks, the purchaser is not prevented/forbidden from starting their own threads from within their server-specific code; although, due to the capabilities and flexibility of this framework, except in rare and extremely specialized situations, there is unlikely to be a need to do so.


  • Connectivity/Communications Capabilities
  • Enables the flow of information between client and server code without requiring development teams to write code to provide for this capability.

    Seamless, concurrent, synchronous AND asynchronous communication over the same socket. (Many frameworks can not handle asynchronous communication at all.)

    (The Tessellation Framework provides automatically for multi-threaded clients that can send a synchronous or asynchronous command while simultaneously receiving real-time information from commands previously sent. [E.g.: In a trading system, executions on orders previously placed, market data on items being watched, and results from reports executing in the background can all be sent back to the implementer's client-specific code {GUI} from multiple threads executing on the server-side of the framework {on implementer's server-specific code} while enabling the implementer's client-specific code to send new commands from the end-user simultaneously and over the same socket that is used to receive all of the aforesaid information and results.] Furthermore, the implementer need not write multi-threaded code on either the client or server side to achieve this capability. [I.e., The implementer is only required to write single-threaded client-specific code {e.g. a single-threaded GUI} that waits on end-user commands and sends these asynchronously or synchronously through the Tessellation Framework to implementer's single threaded server-specific code. The Tessellation Framework automatically multi-threads implementer's client-specific code to handle responses received AND automatically multi-threads implementer's server-specific code to enable it to execute multiple simultaneous commands within each single connection. {The TSF does not just multi-thread an implementer's server-specific code so that server can handle multiple connections.}])

    Seamless (asynchronous) delivery of highly-dynamic real-time information concurrent with provided capability enabling implementer's applicaton on the client side to continue to send commands that will also execute concurrently.

  • Rapid Application Development
  • This framework was developed with ease of use and implementation as a high priority. Among many features that provide for this are:

    Seamless/automatic provision for capabilities: The capabilities mentioned above (including Connectivity [w/simultaneous synchronous/asynchronous msgs over a single socket]; Security [w/automatic SSL handshaking; two-way authentication; signing/verifying/storing of msgs for non-repudiation; ACL checking; automatic execution and enforcement of connection protocol; etc.]; and, Scalability [n threads per machine x m machines w/a session server facilitating the execution of the server-specific code across machines]; etc. are all provided seamlessly and automatically without the purchaser developing any code in either their server-specific or client-specific components to make use of this functionality.

    Tiny learning curve: Due to its simplicity, this entire framework can usually be learned by development teams in less than one day and by teams that manage the configuration, deployment and setup in only a few days.

    Ease of development: No multi-staged compiles w/stubs and skeletons and no deployment descriptors. All that is needed is for implementer to implement a simple interface in his/her server-specific code, and to instantiate and use a provided class of client component of this framework in his/her client-specific code.

  • Functionality
  • This framework provides a number of important capabilities that are critical to designing highly-interactive, distributed applications:

    Automatically multi-threaded clients: This framework automatically multi-threads the purchaser's client-specific code enabling it to, e.g., seamlessly handle asynchronous traffic while simultaneously enabling the end-user to interact synchronously. This means that the capability for the GUI to receive real-time information while simultaneously enabling an end-user to interact with the server system is automatically provided.

    Automatic multi-threading on the server-side: This framework enables the multi-threading of implementers' server-specific code, not just for providing multiple simultaneous connections, but also for enabling the execution of processes per each connection. Therefore, if desired, the capability for a client to send requests to the server asynchronously and have an implementer's server-specific code process multiple requests from a single client simultaneously, is automatically provided even when, as will usually be the case, implementer's server-specific code is single threaded. Again, there is no work required from the standpoint of purchasers of this framework to accomplish this. A few examples:

    The client could send an asynchronous command to the server-specific code that would cause the server-specific code to start listening to (and transmitting real-time data back to the client) asynchronously. This would be accomplished by a separate thread managed by this framework and executing within the server-specific code so that another thread of this framework, perhaps executing within the same server-specific code instance, would be available to handle additional synchronous or asynchronous requests received from the client (perhaps received from an end-user's interaction with a GUI). Note: The code that subscribed to the hypothetical real-time data service could simply subscribe and wait (and not return) -- simply filtering and/or sending information sent to it by the real-time service to the client via this framework. While that framework thread would remain engaged, this framework provides other threads on a connection by connection basis that stand ready to execute additional requests/commands received. Therefore, to reiterate, the implementer's server-specific code may be single threaded and yet exhibit this multi-threaded behavior.

    The server might be a calculation engine and it might be desirable to have a single connection from another system (in this case, this other system would be the client) to be able to call on the server to price many trades (or run multiple scenarios) simultaneously (especially if the server is executing on a multi-processor machine).

Advantages related to functionality and capability:

The server components of the Tessellation Software Framework automatically multi-thread the server-specific code written by the purchaser and also automatically enable the server-specific code to be run across multiple machines. If the purchaser desires, its server-specific code may even be multi-threaded within a single connection. This last mentioned capability enables the server-specific code to generate and send an asynchronous stream to the client in one thread, e.g., while responding to synchronous traffic with another. It also would enable the server-specific code to execute and respond to multiple asynchronous commands from a single client concurrently (e.g., in a financial application built to run atop this framework: the ability to run a risk report on behalf of the request of an end-user while simultaneously executing other requests from that same end-user GUI [e.g., a trade execution]).

Other aspects where the TSF has tremendous performance advantages:
  • Pre-instantiation of Purchaser's Server-Specific Code and Re-initialization with a new connection (vs. reinstantiation).
  • Connections always kept alive until specifically dropped (enabling stateful interaction; preventing performance issues with necessity of swapping out and restoring code and state).