Ssrc Web Wispers™ Distributed service-oriented Web development framework

Ssrc Web Wispers™ allows you to rapidly build scalable Web applications to be deployed on a cluster or wide-area network. In today's parlance, Web Wispers™ enables small to medium-scale cloud computing (up to 128 nodes), meeting the needs of most enterprise and publicly-facing Web applications. Call it a micro-cloud computing development framework if you will. Using C++ for performance or Lua for rapid development, Web Wispers™ makes it easy to program popular applications such as Wikis, Web forums, blogs, and Web-based instant messaging while building in fault-tolerance and scaling capabilities from the get-go.

Ssrc Web Wispers™ simplifies programming by encouraging the use of single-threaded I/O event-driven processes. Although it is possible to write multi-threaded services with Ssrc Web Wispers, you will produce more robust and flexible applications by using the process as a unit of parallelism instead of the thread. Processes can be distributed across multiple nodes in a cluster or wide-area network, whereas threads cannot. If your workload and/or data exceeds the capacity of a single process, you can partition the workload and/or data between multiple processes.

For more information, read the overview.

A Simple Example

The simplest form of Web application you can write with Web Wispers™ is a FastCGI program (either in C++ or Lua). Here is an example of a Lua FastCGI servlet that adds two numbers and produces an HTML page with the result.

Clearly, there are ease of programming problems with FastCGI servlets. First, you must explicitly parse and validate all parameters. Second, you have to inline dynamic content (however, it is possible to include a template processing library such as ltp). FastCGI servlets are most appropriate for simple Web services that return a value instead of rendering pages dynamically.

In addition to programming complexity, FastCGI servlets suffer from the requirement that each servlet maintain a socket connection to the HTTP server front-end. Each new servlet requires a change to each HTTP server configuration associating a URL mount point with a servlet. Web Wispers™ Web services decouple the HTTP server interface, parameter parsing, and output rendering from request processing. One or more relays (either co-located with or remotely located from the HTTP servers) maintain FastCGI connections with the HTTP servers and asynchronously relay requests to the appropriate Web service based on the URL. Web service parameters are converted automatically to C++ or Lua data structures, although the programmer still retains the ability to access the raw parameters if required.

Should a request require a synchronous response, a Web service sends results to the relay, which forwards them to the client after rendering them via an output template (using ltp). The same Web service method can be re-used to generate a Web page, a SOAP message, or a JSON result by mapping different request actions to the Web service method and specifying different output templates for the results. Asynchronous results can be delivered via an event queue, eliminating the need for the client to maintain a persistent connection for long-lived transactions.

Here is an example of the addition service implemented as a Lua Web service module.

Although seemingly more complex than the first example, the Web service module is in fact simpler to write. The bulk of the code is a declarative description of the Web service method properties. Parameters are automatically validated for the programmer, allowing the add function to simply add the two numbers and populate the response. In a real application, the Web service module wouldn't be implemented to execute the business logic directly. Instead, it would forward parameters to a business object and convert its results into a response for the relay. Web Wispers™ is all about decoupling processing units from one another to maximize flexibility in combining them for optimal performance and ease of software maintenance.

Web services can be implemented as Lua modules, C++ dynamically loaded modules, or as stand-alone C++ services. Which one you choose will depend on your development goals. Furthermore, Web services often delegate data access to Wisp services. A common use case is to use a Web service as a domain-specific load-balancer that routes requests to the appropriate Wisp service based on data-partitioning, computational load-balancing, or availability criteria. How many HTTP servers, relays, Web services, and Wisp services you deploy will depend on your performance and fault-tolerance requirements and their relationship to your workload and data scaling characteristics. Web Wispers™ gives you the flexibility to distribute your resources optimally to meet your specific needs.