SPE Concepts

SPE Core Concepts

There are five concepts that are central to the SPE which, when utilized by the pattern designer role and understood by component developers, are intended to simplify the definition and building of software components and software systems in general.

These core concepts are not necessarily new concepts in software development - some of them are used in some capacity by many developers, explicitly or implicitly. However, the SPE combines these concepts into a single system that is agnostic to the type of component(s) being built. The SPE is a framework built around these core concepts as a software development platform.

1 - Component Design as XML Schema

XML stands for eXtensible Markup Language, and is often used for the representation of arbitrary data structures. Schema systems exist to allow for the definition of XML-based languages. One of the schema systems defined by the W3C is XML Schema. XML Schema is a powerful XML language description tool, with support for namespaces, datatyping and abstraction.

A component pattern is defined in an XML Schema that can be adhered to in a predictable and systematic way to define a component that lends itself to the fulfillment of application requirements.

One important distinction about SPE component patterns is that they tend to be functional in nature and lend themselves directly to the fulfillment of an application's functional requirements. For instance, a "service locator" (which is used internally by the code to get access to a service) would not lend itself directly to the fulfillment of a functional requirement. A "business rule" would, however, and it's possible that in processing the business rule that the engine would create a service locator which is used internally by generated code to access the business rule.

2 - Components as XML

With XML schema(s) defined for the various types of components that can be built into the system, XML files are then produced which adhere to the schema. These XML files contain definitions of the actual components that will be part of the software system that's being built.

The intent is that the XML Schema allows the component developer to be concerned only with "what" the component is doing. The pattern designer who defines the XML schema creates a SPE plugin which can create the component implementation for valid permutations of the XML Schema.

While it is desirable to have as many component patterns as possible defined in XML schema, it is inevitable that a software system with a reasonable level of sophistication will have rules that cannot fit completely into a pre-determined software pattern. It is important to support the handling of handwritten components with appropriate hooks back into the SPE such that the SPE understands applicable variable types and system attributes defined by the handwritten code.

3 - Variable Types

Variable types represent the logical data- and service- types in the application that are implicitly or explicitly created by a component definition. When a component is read from XML its API is revealed as a set of rules (Service) or as a type of data (Data Object). Other components in the system may use this variable type by referring to the data or referencing a Service as a dependency.

4 - System Attributes

System attributes are the (many) pieces of data and functionality that make up the software system as a whole. From code representations of tables (via ORM tool) to data objects to services with operations, system attributes map object instance names (such as "person") to their appropriate variable types (such as "PersonData"). With the afore-mentioned example, every reference to "person" in a component of the software system has the same logical meaning.

Data and rules defined as system attributes form the building blocks of the software system. The SPE enforces the consistency of system attributes such that one attribute name may never have two variable types. This makes component references predictable in the software system as a whole, to the point where the SPE can determine implicitly how to process a rule invocation or even determine implicitly how to build a rule.

System attributes can also be an effective way to get non-software engineers to speak with software engineers in terms that are meaningful in the software system. These terms can serve as a useful bridge between the business- or non-technical- side of the software development shop, and the definition of what the components are of the software system. The ultimate goal of this system is to transform non-software engineers into developers who can create software components in XML, or in some interface that can create XML.

5 - Code Execution Context

Within a component processor that reads XML and generates code such as an application rule, the code execution context represents information about the system that is available to the application rule for use by the code being generated.