The Xephr
The layer descriptions should be read as conceptual rather than implementational. They are intended to provide the user with a sense of the flow through the servlet stack rather than a definitive guide to actual code constructs.
Also refer to the accompanying Xephr Stack illustration.
The trigger service is serviced by a series of listeners (http, https, web service, scheduler service, interconnect service, message queue services, etc...). Each of these services responds to incoming requests and prepares the request for forwarding in a standard form, and then hands the service request off to the next layer.
The authentication filter determines if a session identifier is included in the service request and if that identifier is still valid. If so, the request is handed off to the next layer. The requested entity header is fetched from the repository to determine the authentication level required for execution. If the current user's authority level is sufficient to execute the request, then it is handed off to the next layer. If the user does not have sufficient authority, then an appropriate authentication adaptor is tasked with obtaining the needed authorization tokens from the user.
This layer retrieves the Xephr entity definition from the repository, determines for each data associated object the SQL interactions required. These may be inserts, updates, deletes, function calls or queries. Any data manipulation interactions are executed against the designated datasources and any required queries are executed by handing off the query to the appropriate datasource adaptor (database, web service, interconnect service, etc.). On query completion the returned data is assembled into an internal object that conforms to the standard Document Object Model (DOM). The formatting, formulas and other output specifiers stored in the entity definition are attached to the document as appropriate. The document is then handed off to the next layer.
Formulas are applied at the most detail level first and the least detail level last. If all formulas are not resolved by the end of such a pass, then the formula stack is evaluated repeatedly until all formulas have been completely resolved. This provides the ability to employ formulas that are dependent on other formulas executing first, or sums or averages being computed before formula execution, without the end user having to be concerned about the execution sequence of operations. For instance, a user may specify a formula that uses the value of an individual sale, the average of such sales for a customer for a period and the total of all such sales for all customers without being concerned about how such inputs to the formula might be obtained. Once all formulas have been resolved, the document is then handed off to the next layer.
The master output factory determines from the document what the output is intended to be, and matches that with an actual output factory (html, pdf, xls, xml, csv, etc...) and the factory processes the document into an output stream of the correct format, targeted for the capabilities of the output target. Output targets may be other programs or may be a user presentation tool such as a browser. The final output stream is directed on its way, and the task is complete.
Some entity types, such as executable xml definitions and Xephr interconnect requests, are not processed for output through an output factory, but are handed off as the internal document either as input to another local entity or are returned to the remote requesting entity for incorporation into the target object's document in process.
Xephr is a registered trademark of NDS Systems, LC.
Copyright