System Architecture
The Nuxleus Project platform is built on top of a system of simple XML messages that are passed from one process to the next until the original intent of any particular request has either completed successfully or failed completely. The core of this system relies upon the use of a logging mechanism for each sub-process (micro-process) within any given transaction process (macro-process) that insures that once the delivery of any particular message to any particular micro-process has completed successfully, it can forget about everything and move on to handling the next request that comes its direction. In other words, as a process is taking place, the start time, the end time, the parameter names and related values, and the result of the micro-process are sent to a queue server who's only task is to handle the logging of each completed request in such a way that if something goes wrong, the logging system can be queried, the entire process up until the point of failure reconstructed and returned, and the result of that query processed, analyzed, if at all possible fixed by the system itself, and if not, a blip notification sent to a particular URI for further review by a human.
The above process is similar to the process that takes place inside of an organic cell, the nucleus of that cell acting as the message review and routing system. It should then make sense that the core of the platform is built upon a variation on the spelling of nucleus, replacing the 'c' with an 'x', representative of the 'X' in the usage of XML as the core message format.
Nuxleus
Nuxleus is the core platform on which all other applications, services, and processes live upon and communicate through. As per above, at the core of Nuxleus exists a built-in logging system which records both the micro and macro transactions related to each and every request made to the system. All requests into the system are handled by "Agents". When an Agent receives a request that request is first authenticated to ensure that the requesting client has the proper permissions to perform the requested task. If the authentication fails, a response is made specifying as such. If it is successful, that process is given an ID in which the Agent then subscribes to for and in behalf of this request, hands the request off to the Nuxleus core which queues the request for processing by Xameleon, and then forgets about it and moves onto the next request.
Xameleon
Xameleon is the server side message and sequence operation processor and transformation engine that binds all of the other pieces of the platform together. While the Nuxleus engine handles the overall sending, receiving, authentication, routing, distribution, and delivery of messages, Xameleon handles the actual processing of each of message which it gains access to via it's delegated Agent which registers for the types of messages it is capable of processing. Where Nuxleus is the external mechanism for message processing, Xameleon is the internal mechanism for processing the contents of each individual message.
AtomicXML
AtomicXML is a LISP-influenced XML-based S-expression language syntax designed to allow a simple and straight forward way of describing a series (macro-process) of processes (micro-process) involved with a particular request, the data that should be used in the process, and where the result of any given micro-process should be passed for further processing and/or rendering to the output stream. In many ways this process can be compared to that of a message-based workflow in which the result of one micro-process can be routed to another micro-process based on the result of each preceding micro-process. To think of this another way, AtomicXML provides a mechanism for describing atomic transactions of which the primary purpose is either to complete successfully, or fail completely, leaving no "residue", so to speak, that a process was ever invoked past that of the information passed to and stored by the logging server.
Atomictalk
While AtomicXML describes a message-based workflow, Atomictalk defines the format of the resulting message for each request, controlling the process of rendering the content of each message based on an MVC-influenced architecture in which each client can adapt the output of the XML data returned by each request process in a format most desirable to the requesting client. In other words, AtomicXML is the intra-messaging atomic transaction framework, Atomictalk the inter-messaging framework in which encloses each atomic transaction request, the former describing how to process any given single request, the latter describing what to do with the result of that request once it has been received by the requesting client.
An important distinction between AtomicXML and Atomictalk is that while each AtomicXML transaction request is required to either complete successfully or fail completely, Atomictalk has no such obligation as it relates to the various messages it gains access to during each transformation session, weaving the results of each request into a self-contained view within any given page as specified by the requesting client. So, for example, a request might be made to be given access to several different Atom feeds related to a specific subject matter. If one of those request fails, the rendering of each self-contained view within the page are not required to fail as well. Instead its task is to report as much information as the response from each request provides to the requesting client. In the case of a permission failure, for example, the resulting message will have enough information for the Atomictalk engine to specify the reason for the failure was that this particular individual does not have the proper permissions to view the desired content of the requested feed.
lighttpd
lighttpd sits at the front of all requests coming into the system, passing any requests that match a specific regex to the specified proxy and handling all other requests as static file requests that are gzipped and hotcached for delivery to the client.
