Product: Tessellation Software Framework

What TSF Is/Provides Advantages (Why use TSF?) How TSF Provides Advantages Comparison w/EJB

The Tessellation Software Framework (TSF) is a powerful application software framework for developing:

applications and/or ASP services that are distributable over a local, regional, or global network and/or the public internet.

Implementer's client-specific code, which is typically, but not always, a GUI, functions through provided client-side software; and, implementer develops server-specific code containing the business logic specific to the system being implemented, where said server-specific code functions within provided server-side software, and with communication provided by said framework between each instance of implementerís client-specific code through an instance of client-side software to implementerís server-specific code through said server side software over a single network (TCP/IP) connection. Multi-threaded communication is achievable over a single network connection, even where the implementer writes single-threaded code (for its client and server-specific code) that is to run with/execute within this framework. The client-side software is able to process synchronous and asynchronous messages received from implementer's server-specific code through the server-side software, while simultaneously sending additional messages to implementer's server-specific code that were passed to it by implementer's client-specific code. Client-side software accomplishes this by utilizing independent threads that it manages to send said messages through the server-side software. These messages are, in turn, able to be processed concurrently by said server-side software, which uses its own independent threads to concurrently execute said messages on implementer's server-specific code.

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

An ultra-high level of security 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 server-specific code to fit into this framework by complying with a very simple interface. The purchaser develops client-specific code which uses this framework 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 (and certainly not available w/EJB Ė which does automatically provide for the first two), 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 high performance 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 EJB, 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.