by Andrei Popa
Nowadays, software applications are growing to never-imagined-before proportions, increasing the need for fast and efficient software development cycles. In this respect, software architects must take into consideration not only the existing code (what has been done) and the required code (what will be done), but, also, the future code (what might be done).
Arguably, the last part is the most difficult of the three. Following best practices, you can successfully plan short-term goals, but this is not applicable for long term ones, as new requirements and market trends can always emerge to thwart the most careful of plans. You cannot expect the unexpected.
One of these unplanned requirements could very well be the integration with external systems. This is not an issue as long as they have compatible architectures, but if that is not the case, it can be difficult and even unprofitable. To avoid this, development communities have come up with specifications, architectural templates which make such integrations effortless, as they share the same base architecture.
Specifications aren’t something new as they have been around for some time now, but nowadays the need for them is ever-growing. One example is the JMS (Java Message System) specification, created by Java Community and implemented by vendors such as Sonic and ActiveMQ.
Another specification is the OERA specification, short for OpenEdge Reference Architecture, which provides the base template for any business oriented application developed in OpenEdge ABL. This is done by separating the application into 3 layers: Service Interface, Business Logic and Data Access. The Service Interface layer is the common access point for both internal and external callers. It handles different access protocols and ensures that the following layers can provide a general, unitary implementation for any client type. The Business Logic layer, as the name suggests, is solely responsible for the business-oriented logic, separate from any other programming aspects. Lastly, the Data Access layer, is the only layer with direct access to the application’s data sources (databases, files, …).
The advantage of such layered architectures is the separation of concern, reusability of the layers, better testability and the possibility of developing layers concurrently. Despite its many advantages, OERA is quite lacking as it is limited only to the flow of data from the data source to the requesting client, whereas this is just a part of any modern application. In response to the need of a more complete specification the Common Component Specifications Project was started to define the OEAA (OpenEdge Application Architecture), an extension of OERA, which would provide a more complete template for a modern business application.