The Soul of a New Language
Ben_Margolis 270001971J Visits (1795)
Cary, North Carolina features an office park where paths stretch around a wooded lake and beyond. If you walk the paths alone, you can have a productive meeting.
In the late 1980’s, a small software company won a contract with IBM and rented space in one of the park’s buildings. The company was required to invent a mechanism for transforming business-process diagrams into source code. The subject area is now called Model Driven Development (MDD).
This early attempt at MDD was expensive. Even the project’s tech writer—yours truly—was flown repeatedly between North Carolina and Arizona at short notice, primarily to type the minutes. With doubts and costs rising, IBM ended the experiment. And a few years later, Rational Software created what would ultimately be known as the Unified Modeling Language (UML), which is at the heart of MDD.
What is needed to fulfill the promise of MDD? One requirement is a language whose main constructs easily link the high-level business diagrams characteristic of the UML, on the one hand, with the low-level logic available in compiled code, on the other.
In the future (we believe), a business modeler will be able to select an EGL system definition (a stereotype, in UML terms) and place it on a process diagram. Each stereotype implies a specific kind of runtime behavior. For example, the modeler might select an SQLRecord stereotype to indicate that an automated process must access a relational database.
For now, a developer’s selection of a particular stereotype in EGL source code creates a particular, generated output. For example, if a developer declares an SQL record and includes that record in an EGL add statement, the EGL generator writes the appropriate SQL INSERT statement into the COBOL or Java source. The developer’s ability to affect the EGL system code in a simple, declarative way is central to how the technology works, under the covers.
What are the practical effects of these abstractions? First, the EGL developer can write code that does basic tasks in a single way, regardless of the runtime technology. Adding a row to a database is equivalent to adding a record to a file. Second, the language can better accommodate new runtime technologies such as Web 2.0. Third, the language is likely to be useful for business modeling as well as software development.
The upshot is that EGL is designed to be useful, now and later. For an overview that describes EGL as a technology, see the MC Press title Enterprise Web 2.0 with EGL.
Link to MC Press