System 3 Layer Architecture

• System 3 Layer is a three-tier architecture that enforces clear separation of database, application, and front end with strict language and interface policies.
• It uses an XML-based Interface/Data Definition Language to generate SQL, Java, and HTML artifacts, ensuring modular code generation and consistent layer interfaces.
• Key benefits include enhanced maintainability, improved code clarity, and independent team operation, though it demands a steep learning curve and periodic code regeneration.

A “System 3 Layer” typically denotes a three-tier or three-layer architecture, a paradigm extensively employed in enterprise software engineering and, as a second meaning, a three-layer stratified system in physical sciences. Here, the primary focus is the rigorous implementation and formal separation of three logical tiers in software architecture, as described by Pidkameny and Sadikov (Sadikov et al., 2014), with a technical perspective aligning to system implementation, intermediate representation, code generation, and inter-layer messaging.

1. Structural Definition and Separation Criteria

The three-layer system enforces strict decoupling of three tiers:

• Tier 1: Database / Back End
  • Implementation: Structured exclusively with SQL stored procedures and a pure data model.
  • Exports: Only stored procedure signatures; ad-hoc SQL statements are precluded from application server code.
• Tier 2: Application Server
  • Implementation: Java servlets, wrapper classes, and business logic.
  • Imports: Only XML-defined interfaces for both GUI and stored procedures.
  • Contains: No inline SQL or HTML; only invokes generated wrappers.
• Tier 3: Front End
  • Implementation: Static HTML with XSL templates or a Java Swing client.
  • Imports: Only XML screen definitions; emits XML or CGI output.
  • Contains: No business logic or SQL.

A categorical rule enforces this separation: No file may contain more than one language type from {SQL, Java, HTML}. Interface definitions for all tiers are captured in a single, layer-independent XML Interface/Data Definition Language (IDL), from which all structural code artifacts, adapters, and stubs are generated (Sadikov et al., 2014).

2. Interface/Data Definition Language (IDL): Syntax and Semantics

The IDL is an XML-based formalism, with syntax specified in BNF-style notation and semantics grounded in multi-language code generation. Key constructs:

• <bean>: Defines an object with typed fields; generates a Java class extending CcBean with field accessors, validation, and XML/ResultSet marshalling support.
• <vector>: Denotes a java.util.Vector of a given bean or primitive type.
• <procedure>: Describes an SQL stored procedure and its Java wrapper class (including parameter mappings and execution workflow).
• <transaction>: Specifies a Java servlet interface—auto-generates a skeleton servlet and a handler subclass.
• <screen>: Defines the front-end screen bean and the contract for generated XSL templates.

Mathematical abstraction: Aggregated data structures may be denoted, e.g.,

$$\text{Person} \equiv \langle \text{FirstName}: \mathrm{CcName}; \text{LastName}: \mathrm{CcName} \rangle$$

$$\text{Address} \equiv \langle \text{Street}: \mathrm{CcString}; \text{City}: \mathrm{CcName}; \text{State}: \mathrm{CcString}; \text{Zip}: \mathrm{CcNumber} \rangle$$

These are encoded in the IDL and expanded across all tiers by automated tools (Sadikov et al., 2014).

3. Exemplars: Beans, Generated Artifacts, and Workflow

IDL Fragments and Artifacts

The following IDL fragment produces full-stack artifacts:

<bean name="Person"> <param name="FirstName" type="CcName"/> <param name="LastName" type="CcName"/> </bean> <procedure name="GetPeople"> <request> <param name="Name" type="CcString"/> </request> <response> <vector name="Result" type="Person"/> </response> </procedure>

Generated code/artifacts:

• Java Beans: Classes, e.g., Person extends CcBean, with validation and XML serialization.
• SQL Stub: CREATE OR REPLACE PROCEDURE GetPeople_Proc (Name IN VARCHAR2, Result OUT SYS_REFCURSOR) ...
• Servlet Skeletons: Abstract base and developer-supplied subclass to encapsulate business logic.
• HTML/XSL: OOML trees and data-binding templates derived from <screen> definitions.

This approach enables all cross-tier interfaces to be defined once, then propagated by code generation to SQL, Java, and HTML/XSL, reinforcing strict decoupling (Sadikov et al., 2014).

4. Automated Code Generation Pipeline

The full development pipeline consists of the following deterministic steps:

1. IDL Authoring: Write XML files defining beans, procedures, transactions, and screens.
2. Code Generation: Invoke the build system (Ant target generate-code), running a chain of XSLT stylesheets:
   • <bean>: Generates Java source (bean classes).
   • <procedure>: Generates SQL procedure stubs and Java wrappers.
   • <transaction>: Produces servlet skeletons and proxy classes.
   • <screen>: Generates screen beans and stubs for XSL/OOML structure.
3. Compilation: Ant compiles generated plus user-supplied Java business logic.
4. Assembly: Bundles into WAR or JAR for deployment.
5. Runtime Behavior:
   • JDBC wrappers manage connections and data mapping.
   • Servlets handle XML/CGI parsing, invoke business logic, emit responses.
   • Front end applies XSLT to compose final HTML from XML data and templates.

This unified process strictly enforces the one-language-per-file restriction and guarantees that all interface definitions remain layer-agnostic and reproducible (Sadikov et al., 2014).

5. Benefits, Limitations, and Performance Considerations

Documented Advantages

• Readability: Absence of embedded SQL/HTML in Java enhances code clarity.
• Maintainability: A single change in the IDL propagates to all affected artifacts via regeneration.
• Separation of Concerns: Backend, application, and frontend teams operate independently against explicit, contractually defined interfaces.
• Code Reuse: Beans, types, and wrappers are portable and reusable.

Trade-offs

• Learning Curve: Necessitates initial acclimation to the IDL and build pipeline.
• Code Regeneration Overhead: All code must be regenerated and recompiled after every schema/interface alteration.
• Performance: Minor runtime cost (<1%) from XSLT transformation, negligible impact from wrappers; possibility to cache XSLT outputs.
• Debugging Complexity: Logic relocated to stored procedures may require proficiency in both database and application environments (Sadikov et al., 2014).

6. Layer-to-Layer Messaging and Formal Communication Notation

Message Flow

A standardized, formalized message sequence:

1. User input populates an HTML form (bean-mapped field names).
2. Browser POSTs CGI parameters to servlet endpoint.
3. RequestHandler servlet parses parameters into beans, passes to business logic.
4. Business logic delegates to a procedure wrapper (JDBC → stored procedure → ResultSet → beans).
5. Servlet marshals output bean to XML, returns as HTTP response.
6. Browser merges XML with XSL using client-side XSLT engine, produces HTML.

Formal Notation

• FrontEnd →(HTTP/XML)→ AppServer
• AppServer →(JDBC/Callable)→ Database
• Database →(ResultSet)→ AppServer
• AppServer →(XML)→ FrontEnd

A strict boundary is maintained between all tiers, enforced at the level of source artifact generation and verified by the explicit “one language per file” policy.

7. Synthesis and Impact

Complete separation of the three logical tiers using explicit IDL definitions and automated code generation dramatically increases clarity, reduces defects stemming from multi-language file interleaving, and enables independent development and maintenance across tiers. Changes in data structures or interfaces necessitate only a single-point update and a regeneration step, with all structural contracts automatically maintained and enforced. By avoiding interwoven Java+SQL or Java+HTML, the approach achieves strong modularity, traceability of interface changes, and a clear demarcation of team responsibilities, yielding tangible long-term maintainability and scalability benefits (Sadikov et al., 2014).