Separating The Business Interface from the Implementation
June 23, 2002
This is the fourth part of a series of articles
on component oriented languages from a Java perspective.
In earlier articles, component oriented languages were described as more evolved languages than object oriented languages. The principle reason being that component oriented languages formally separate type (data) from modules (architecture), and messages (interfaces) from methods (implementation). The premise upon which the evolutionary claim is made is that component oriented languages are closer to expressing the problem than object oriented languages.
In the final section of the last article, the concept of domain oriented languages was introduced. Domain oriented languages allow a domain to be expressed directly, including domain data, architecture and function. These languages can then compile into a working application. The idea of expressing a domain then creating a working application from that expression is not new; it was the basis of 4GL's, such as PowerBuilder. Domain oriented languages have important differences from component oriented languages which will be described below.
From a domain oriented perspective, data and architecture interfaces represent the domain model. From a component oriented perspective, data and architecture interfaces make no distinction between domain and technology, and there is no question of them being technology neutral. From a domain oriented perspective those interfaces can be implemented using different technologies, but should not expose them. For example a domain oriented architecture may expose generic findBy, save and remove mothods but they would not expose their implementation (e.g. EJBExceptions or EJBObject super class).
Domain oriented languages can be described as:
Separating the domain interfaces from their technical implementation
Domain oriented lanaguges rely heavily on code automation techniques, such as code generators, interpreters, proxies or compilers to create the technical implementation. When a domain oriented application is created, a programmer should be able to choose which particular technical implementation is going to implement the business interfaces. For example by choosing a JDBC or EJB option a different implementation of the interfaces would be created. This means that a programmer
can choose different architectural implementations for different situations.
When a project starts off, the programmer may wish to create an in memory or file based architectural implementation; later as the project develops a JDO or EJB architecture could be code automated.
Separating business interfaces from technical implementations means that a domain oriented system can be separated into domain data, architecture and function and technical data, architecture and function. Importantly data and architecture domain interfaces and technical implementation of these interfaces can be code automated. Domain function cannot be code automated and a policy
is required to integrate this into the compiled system.
Code automating an application from a domain expression (data, architecture and function) is immensively powerful. Key to this power is an understanding of software efficiency. Software efficiency is a key aspect to measuring the quality of any domain oriented language. Software efficiency measures the ratio between domain expression and code size. Code efficiency can be dramatically increased by using code automation.
Most programmers are not conscious of code efficiency when programming, but when a code automator is brought into the equation it can be measured. The simplest and most common inefficency is when variables are present that achieve the same generic function.
Code automation is driven by meta data. Java itself does not have sufficent meta data even in its feature descriptors to drive a code automation tool. A combination of Feature Descriptors and JDBC meta data could be used to provide some meta data, but it makes for a truly awful bodge, and would still need to be supplemented. For example EJB requires that column names be specified in alphabetical order. So once you've established the principle that supplementary meta data is required, it's best do to a good job in the first place.
For example a fragment of an Address table in a domain model can be expressed as follows:
line1 VARCHAR(30) NOT NULL
line2 VARCHAR(30) NOT NULL
line3 VARCHAR(30) NOT NULL
In the code the variables line1, line2 and line3 appear in numerous places, each achieving the same generic function. For example in the Address data interface as a get and set method:
* @param line1 of the address
public void setLine1( String line1 ) throws ValidationException;
* @return String line1 of the address
public String getLine1() throws ValidationException;
In these examples the property line1 appears 5 times, and we haven't even got to the implementation. If this method is fully implemented to handle empty string values, recursive setting, validation and property events, there is an efficiency level of 15.
protected String line1;
* @see com.javelin.furniture.Address#setLine1( java.lang.String line1 )
public void setLine1( String line1 ) throws ValidationException
if( line1 != null && line1.length() == 0 ) line1 = null;
if( AbstractBean.isEqual( this.line1, line1 ) ) return;
if( isValidated() ) getValidator().validateLine1( line1, this, "line1" );
firePropertyChange( "line1", this.line1, this.line1 = line1 );
In addition to this the line1 property can be specified in the following places:
In other words, enterprise applications operate at an efficiency level in the regions well above an order of magnitude. In our experience of Northwind, creating an optimized EJB produces 100 times as much code as the domain meta data. We were quite shocked by this, especially because it was very difficult to make any code redundant without sacrificing type safety.
- UI Setting values
- UI Getting Values
- Validation rules
- Data Loading
- Data Creation
- Data Updates
- Data Binding
- Data base definitions.
The example above shows domain oriented data. The architecture could also be domain oriented. For example an AddressSession class:
public class AddressSession
public void save( Address address )
throws CreateException, StoreException, ValidationException;
public void remove( Address address )
throws RemoveException, ValidationException;
public Address findByPrimaryKey( Object primaryKey )
throws FinderException, ValidationException;
public Address findByPostCode( String postCode )
throws FinderException, ValidationException;
The EJB version of this class would be the AddessHome or an AddessSession facade. The AddressHome class would extend the EJBObject and the methods would expose EJBExceptions so whilst the AddressHome interface would be a candidate for component oriented software they would not be a candidate for domain oriented software - because the interfaces expose the implementation.
A good example of a component that would fit into a domain oriented architecture is the
jdbc.RowSet. Whilst this is an architectural interface, from its point of view its business end is technology. The RowSet does not expose its own (vendor specific) implementation. The benefit for us is that the RowSet can be implemented in a number of different ways - either directly ontop of a ResultSet or as an In-Memory cache.
The use of Beans and EJB standards has helped to clarify the difference between the business data (beans) and the business architecture (homes and session), as well as technical data and technical architecture. The importance that Beans and EJB standards have legitimised the expression of business domains in interfaces; even if not perfectly.
Having said that developers are increasing criticising Javasoft and Microsoft application servers is because their designers have failed to make the distinction between technical and business programming. Whilst EJB and JTS are admirable for separating data from architecture and expressing business interfaces on the architecture, their complete failure to separate business interfaces from technical implementation can only be interpreted as evolutionary dead-ends. JDO has done slightly better but has its thinking in the same camp as EJB and JTS.
Many of the arguments between the genre of products such as EJB and JTS have been about technical details. There has been very little argument about how easy it is to express particular business domains and produce quality working solutions using different technologies.
To create a decent EJB or MTS system the programmer must be both a business and a technical expert. The quality of their solution is inevitably going to suffer as they must learn and keep up with the ever changing demands of the business and the technology.
To adapt Sun and Microsoft must make a huge break with their current thinking patterns and distinguish between expressing a business model and implementing it using a particular technology. The gulf between implementation programmers and business programmers should have been growing steadily over the few years. The reality is that they have been merging to meet solutions poorly conceived by technologists.
Most of the literature today confuses business architecture with technical architecture. The best architectures represent business interfaces, and technical architectures can come and go. This was the lesson of relational databases that the data model for a business will out live the implementations. Domain oriented programming also takes this lesson on board by creating business architectures based on type and module interfaces then code automating architectural implementations transparently.
With the current emphasis on return on investment (ROI) this is a direction many application architects are now looking because it allow the technology to change without throwing away the code base.
At Javelin Software, the JGenerator tool is a good example of a domain oriented tool that enables a domain model to be generated out to Memory, File, JDBC, JDO or EJB. This is done transparently and the programmer can choose to change implementations at compile time. To the uneducated JGenerator looks like many other object relational mapping tools. Its difference lies an understanding that it is actually a domain oriented language. The potency of the tool means that complete applications can be rendered very quickly once the business domain is well understood.
Currently JGenerator generates the code, as a massive pre-compiler for Java. In future domain oriented languages would skip the pre-compilation step out, however the principles identical.
Domain oriented languages represent a significant advance over component oriented languages, which in turn represent an advance over their more primitive object oriented cousins.
Next time you begin architecting a new software solution think about the 4 principles:
From component oriented languages
(1) Separate the interfaces from the implementation
(2) Separate the types (data) from the modules (architecture)
From domain oriented languages
(3) Separate business interface and technical implementation
(4) Automate architecture, data and source code
In the near future I'll describe a meta data system for Java.
Programming Language Lifecycles
Component Oriented Software - Java Perspectives
Component Oriented Thinking: Separating Data From Architecture
Automated Code Generation: The Fastest Way to Write Software?
<< Back to Design
<< Back to Software Reality