MSS Code Factory: A Fractal Programming System

The Manufactured Object Model
Useful and functional code supporting the business application
model is produced to support any generic business logic or
application code. This is the "Code Manufacturing" aspect of
the project and why it was called a "Factory".
The layers and modules currently produced include:
- [Project][Version]
- [Schema] - The data object Buff, Key, and Factories for them
- [Schema]Obj - The Obj and EditObj objects with their interfaces
- [Project]ram[Version]
- [Schema]Ram - The in-memory Ram "database", heavily used by the engine
- [Project]db2luw[Version]
- [Schema]Db2LUW - The DB/2 LUW 10.5 JDBC database IO layer
- [Project]mssql[Version]
- [Schema]MSSql - The Microsoft SQL Server 2012 Express Advanced Edition JDBC database IO layer
- [Project]mysql[Version]
- [Schema]MySql - The MySql 5.5 JDBC database IO layer
- [Project]oracle[Version]
- [Schema]Oracle - The Oracle 11gR2 JDBC database IO layer
- [Project]pgsql[Version]
- [Schema]PgSql - The PostgreSQL 9.4 JDBC database IO layer
- [Project]sybase[Version]
- [Schema]Sybase - The Sybase ASE 16.0 JDBC database IO layer
- [Project]xml[Version]
- [Schema]SaxLoader - The core XML SAX parser and .xsd
manufactured to specify the parser's input. This base
is then extended by each persistence-layer-specific
implementation of a SAX Loader for the storage layers.
- [Project]xmsg[Version]
- [Schema]XMsg - The core XML request and response message
formatters for the schema. Both are in the one code bundle.
- [Project]xmsgrqst[Version]
- [Schema]XMsgRqst - The XML request parser acts on the requests
being made of it, and then invokes the message formatters from
[Schema]XMsg to prepare an XML response message to the client.
- [Project]xmsgrspn[Version]
- [Schema]XMsgRspn - The XML response parser evaluates the response
messages from the server sent back in response to a request, and
collates the response buffers into an accessible data set for
processing by the invoker of the response parser. Note that the
necessary objects are realized during the processing of the response,
so there is no need to re-realize them in the invoking code.
- [Project]xmsgclient[Version]
- [Schema]XMsgClient - The XML messaging client incorporates a
response parser to evaluate the results of passing requests to
a server via a single send/receive method that has to be overloaded
by a subclass of the client. Thus the client can talk any protocol
you care to use, provided it can serialize and deserialize XML document
contents and invoke the request handler on the server end.
- [Project]saxramloader[Version]
- [Schema]SaxRamLoader - An in-memory "persisted" version
of the SAX Loader. Used primarily to exercise the parser
itself in preparation for "real" testing against the
database layers. Not particularly useful for much else
at this point, but it would make for an interesting server
cache code base.
- [Project]saxdb2luwloader[Version]
- [Schema]SaxDb2LUWLoader - A DB/2 LUW 10.5 persisted implementation
of the SAX Loader. Used primarily to exercise the database
persistence layers for CFDbTest22 to ensure that all atomic
data types can be persisted by a given database implementation.
Also very useful for loading and updating shared data, importing
data, and otherwise shifting around update documents based on
the manufactured XML Schema.
- [Project]saxmssqlloader[Version]
- [Schema]SaxMSSqlLoader - A Microsoft SQL Server 2012 Express
Edition persisted implementation of the SAX Loader. Used primarily
to exercise the database persistence layers for CFDbTest22 to
ensure that all atomic data types can be persisted by a given
database implementation. Also very useful for loading and updating
shared data, importing data, and otherwise shifting around update
documents based on the manufactured XML Schema.
- [Project]saxmysqlloader[Version]
- [Schema]SaxMySqlLoader - A MySql 5.5 persisted implementation
of the SAX Loader. Used primarily to exercise the database
persistence layers for CFDbTest22 to ensure that all atomic
data types can be persisted by a given database implementation.
Also very useful for loading and updating shared data, importing
data, and otherwise shifting around update documents based on
the manufactured XML Schema.
- [Project]saxoracleloader[Version]
- [Schema]SaxOracleLoader - An Oracle 11gR2 persisted implementation
of the SAX Loader. Used primarily to exercise the database
persistence layers for CFDbTest22 to ensure that all atomic
data types can be persisted by a given database implementation.
Also very useful for loading and updating shared data, importing
data, and otherwise shifting around update documents based on
the manufactured XML Schema.
- [Project]saxpgsqlloader[Version]
- [Schema]SaxPgSqlLoader - A PostgreSQL 9.4 persisted implementation
of the SAX Loader. Used primarily to exercise the database
persistence layers for CFDbTest22 to ensure that all atomic
data types can be persisted by a given database implementation.
Also very useful for loading and updating shared data, importing
data, and otherwise shifting around update documents based on
the manufactured XML Schema.
- [Project]saxsybaseloader[Version]
- [Schema]SaxSybaseLoader - A Sybase ASE 16.0 persisted implementation
of the SAX Loader. Used primarily to exercise the database
persistence layers for CFDbTest22 to ensure that all atomic
data types can be persisted by a given database implementation.
Also very useful for loading and updating shared data, importing
data, and otherwise shifting around update documents based on
the manufactured XML Schema.
- [Project]smwar[Version]
- [Schema]SMWar - The Security Manager web interface used to
request/register new accounts with email address verification,
and to upload the public keys provided by the Swing prototype
GUI client for device identification when logging in to the
XMsg server.
- [Project]xmsgsrvwar[Version]
- [Schema]XMsgSrvWar - The XMsg server which relies on CFTip privacy
to secure the communications between an XMsgClient and the
web messaging server. CFTip is vulnerable to man-in-the-middle
attacks because it does not verify the signing chain of the public
key provided by the server. Currently a privately signed key is
dynamically generated with each startup of the XMsg server, rather
than letting you specify a pre-determined key.
- [Project]javafx[Version]
- [Schema]JavaFX - The framework of JavaFX components GUI that
can be used to build a custom GUI.
What gets manufactured for a custom expert system?
When you enable "ExtendCFCore" for a schema, the system produces a
customized General Expansion Language (GEL) interpreter that is
designed to work with the business application model data that
you've specified.
This process goes far beyond a framework approach of creating a
catalog of objects that implement framework interfaces. Instead,
I create interpreter bindings that link the language directly
to the application data through custom code, which results in
astonishingly tight and fast execution despite the size of the
overall manufactured code base. You could do the same thing with
introspection and less code, but it would be slower.
- [Schema]MssCF -- Contains all the bindings, iterators, and
references for the CFCore customization, as well as an Engine
specialization that wires the custom code to the base engine
implementation from CFCore. The code for this module is
deposited in the core package module of the schema base objects,
so that it can be used in BL implementation code.
While the simple grammar of the GEL languages remains unchanged from one
application to the next, the syntax of the language as a whole adapts
itself using the business model's terminology to provide a richly
expressive syntax for navigating the data of that model.
See the Generic Expansion Language
(GEL) page for a better explanation of how MSS Code Factory
adapts the CFCore technology to define an expert
system capable of understanding your business application model.
The expert system itself is a functional signature matching language,
which means that the current scope and generation definition in
the context of the current expansion is considered when searching
for an expansion name during GEL expansion.
The fundamental expansion performed by the GEL interpreter is based on
the idea of inverting a LALR parser, so it produces predictable, uniform
code. The interpreter uses techniques common to functional languages
in the way that it considers the scope and generation definitions of
the current context when searching for expansion rules.