MSS Code Factory: The Manufactured Object Model

# MSS Code Factory: A Fractal Programming System

Prev | Documentation Home | Next

## 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.