My previous blog post, titled EATS Development Journal, provided a forward view of EATS development based on the Eclipse framework. This post announces the publication of the baseline code1 for that development effort. It provides the first in a series of posts which examine the code as a model for the infrastructure layer of the tool suite architecture.
What that means might best be understood by taking a brief look at the layered product architecture for the Element Architecture Tool Suite (EATS) as shown in Figure 1 below. (Click on the diagram for a larger, more readable, image.)
This layered conceptual architecture describes an EATS-based application as a series of layers, where each layer working up from the bottom is dependent on the lower layers to provide a virtual operating environment, or context, in which, or on which, the upper layer runs. This is sometimes refered to as a virtual machine abstraction layering pattern2. The purpose of this pattern is to insulate the upper layer from changes which may occur beyond its interface with its immediately lower layer. Layer 3 (in our case the core of EATS) should be completely unaffected by changes in Layer 1 (the Deployed Technology Infrastructure). Layer 2 (the EATS Infrastructure) defines a virtual machine that provides this protection. Another purpose is to provide the upper layers with increasingly sophisticated abstract machines, with increasing sophisticated features and capabilities, on which the new layer can develop its own program logic. Mundane technical details are accomplished in a consistent manner by lower layers, so that the logic at higher levels do not need to be unduly considered with these operations. (For example, how to send and correlate messages in a parellel processing environment.)
The Published Software
The published EATS baseline code implements a version of Layer 2, the EATS Infrastructure. This iteration of the Layer 2 code did not use an Eclipse framework as part of the Layer 1, Deployed Technology Infrastructure. Rather it was based on POJO, Plain Old Java Object, development. What this does do is to define an architectural framework, a set of standardized methods and procedures, for application processing which is used as the prescribed standard for EATS and EATS-based applications. This framework implements a distributed, extendable, inversion-of-control oriented operating environment that provides the foundation for the EATS application. The infrastructure is actually application agnostic and is designed to support arbitrary service-oriented, web delivered or workstation-based applications that conform with its architectural patterns. The remainder of the EATS architecture stack, Layers 3 and above, are constructed based on the architectural processing patterns defined by the EATS Infrastructure.
The published code is a series of four projects that define a prototype implementation of the EATS Infrastructure architecture. This Java implementation reflects lessons learned and strategies developed during a series of earlier projects where portions of the code were developed using C++, PHP and C# to ensure some degree of algorithmic compatibility and inter-operability between these environments. These earlier experiments culminated in the prototype termed EATS v1.09. That is the effort documented as the following four projects:
- EATS JavaCore — the implementation of the "core" infrastructure library
- EATS JavaServer — an implementation of an EATS server node based on the JavaCore foundation
- EATS JavaDesktop — an implementation of a GUI desktop node framework based on the JavaCore foundation
- AIR JavaDesktop — an implementation of a GUI desktop node based on the JavaDesktop framework
A fifth Java project, a web server implementation, was also developed as part of this exercise but is not included in the published code. The relationship of the projects to each other is as shown in Figure 2 and Figure 3 below.
The Infrastructure Projects
Figure 2 shows the packaging scheme for the EATS Infrastructure code. The diagram on the right hand side of the figure shows the relationship between three of the packages for which the code provided, and also shows the concept for the unpublished web server package (JavaWeb). The diagram on the left hand side of this same figure shows the deployment strategy for the code.
Figure 2EATS Infrastructure Packaging
As noted above, the EATS architecture supports the deployment and operation of a distributed network of interacting <em>architected nodes</em>. These nodes are currently defined to take one of three forms:
- Desktop Nodes — these are nodes which provide direct user presentation and interaction through a user interface of some sort. In most cases these would provide a Graphical User Interface, but that is not a strict requirement. The term desktop is also not meant to imply a specific hardware constraint. These would also include nodes implemented on notebook or tablet computers. These are simply nodes capable of execution of an Architected Service Facility and which provide user interface presentation facilities.
- Utility Server Nodes — these are nodes which have been configured as headless systems. They are unencumbered with presentation (user interface) logic. Service requests for these nodes are generated by other automated systems. The nodes themselves may be configured to support a number of needs from service request routing and management, service fulfillment, resource management, gateway services, or any combination of these.
- Web Server Nodes — these are nodes which implement web servers and provide a web presentation as the form of user interface.
The general architecture of the EATS Infrastructure is such that any one of these node types could be implemented on a standalone basis as a self-sufficient system. Or, a series of these node types can be configured as a distributed system. The choice of the implementation topology is a function of runtime configuration, not a function of the infrastructure's coding.
The software supporting these deployment options is configured into four major packages, as described above and shown on the right side of Figure 2. The JavaCore package is the primary package implementing the core functions of the EATS Infrastructure. Each of the node specific packages import3 from JavaCore to gain access to the common infrastructure facilities defined there.
Separate from Javacore, the JavaDesktop, JavaServer and JavaWeb packages only implement the features unique to their specific technological environments. Configuration and deployment of a particular node type to create an architected node consists of combining an instance of the JavaCore package with the appropriate package for the node type to be configured. Each of these combinations would be termed an Architected Service Facility4.
The Desktop Prototype Project
Figure 3 depicts the prototype implementation of a JavaDesktop Node. The Utility Server Nodes and Web Server Nodes require no technical specialization when they are deployed. For these two node types the specialization is accomplished through service and/or resource configuration. This same configuration capability exists with a Desktop Node; but Desktop Nodes present different challenges. One challenge is the interface of a single-threaded GUI environment with the multi-threaded orientation of the EATS Infrastructure. A second challenge was how to integrate the user interface for EATS features with other capabilities which may be desired as part of the same application. A complication on this second issue was a desire to leave the universe of EATS-based applications as open and unconstrained as possible. Some could be applications designed entirely to expose content structured in an EATS repository. Others might be applications which interface with EATS in an architected manner5, but then use and present the EATS content in some manner or context which has no apparent relationship to EATS whatsoever. Fully addressing both of these challenges within the implementation of the JavaDesktop became a major undertaking. Larger than I wanted to handle as a single developer. In fact, the second set of challenges played a major role in the desire to migrate to Eclipse6 as part of the Deployed Technology Infrastructure.
Figure 3EATS Desktop Prototype Configuration
The solution to the two challenges for the EATS prototype implementation was to use the design scheme shown in Figure 3. This design implements the JavaDesktop package as a non-runtime executable package which primarily is meant to address the first challenge: interface of the single-threaded and multi-threaded portions of the processing with one another. Within this scheme the JavaDesktop package provides core components which extend and interface to EATS JavaCore elements. It also provides a base set of GUI presentation components which assist with addressing the threading challenge. The scheme requires a different package to be implemented which extends the JavaDesktop to provide the runtime execution capability and to deliver the final GUI face for the application.
For the prototype the derived application, documented in the AIR JavaDesktop Doxygen materials, was a bare skeleton application. It was eventually intended to be a simple data capture and display utility for the Architecture Information Repository (AIR) subsystem of EATS. The framework developed for this project was used to launch test messages to demonstrate and prove the architecture but not developed to a full application. Full development of this application has now been deferred as an Eclipse project.
- 1. The software code related to here was developed as part of an EATS prototyping exercise. Portions of the code may be used unchanged in the next (Eclipse-based) iteration of the system. Other portions will need to be modified to adapt certain features to operate based on Eclipse tooling rather than home-grown mechanisms.
- 2. Please note that the EATS Infrastructure layer does not provide a true and complete virtual machine environment. It does not isolate the software layers above from the operating environment below. Rather, it provides a set of consistent operational extensions to the Deployed Technology Infrastructure layer which provide features and capabilities tailored to a specific approach to application development. From the perspective of the higher level layers, these feature appear as standard parts of the Deployed Technology Infrastructure.
- 3. A package is a Java version of a library. If library A is dependent on library B's features, library A will need to import library B to gain access to those features.
- 4. While it would be unusual, a single computer could implement more than one Architected Service Facility. One (not recommended and possibly poor) example would be a workstation running an instance of an EATS] Desktop periodically as an application, and running an instance of an EATS Server as a background task.
- 5. Conforming with EATS architectural principles and standard practices.
- 6. Providing a generic, fully-functional desktop abstraction is a complex task which has little or nothing to do with the fundamental objectives of EATS. Nor does it provide great benefit to others who may want to leverage EATS for their purposes. Instead, by using a desktop framework already widely adopted by others, integration and leveragability are enhanced.