by John Tibbetts and Barbara Bernstein 

Object Magazine, November 1997 

     There is reasonable reuse of domain objects in the back and of UI gadgets at the front. Yet at the heart of the development job, at that stage devoted to creating the so-called application itself, reusable objects are virtually non-existent. These application middles are written as they always have been—on a case-by-case basis, almost entirely from scratch. Even a commonplace activity like relating master records to their detail records gets programmed anew for every new application. 
     The problem stems from a fundamental lack of clarity about what should happen in the stretch of an application that is called "businesss rules," "application logic," or "transactions."  The multiplicity of names is a tip-off that we lack a crisp undersanding of what the proper job is here. Conventional architectures leave it to individual designers and developers to bridge from UI to database in whatever idiosyncratic, opportunistic ways they can come up with. 

 

     No wonder these middle regions have resisted abstraction and re-use. Object modeling done here has missed the mark because it has tried to model a misconception, or at least a serious imprecision.We introduce here a more promising way of thinking in object terms about the central portions of transactional applications, and discuss our experiences in implementing an architecture based on this insight. 
 
What’s In A Name? 

     Object technology teaches the importance of accurate names that reflect clearly-delimited responsibilities, and this is what we have come up with:  The application middle is the region where proposed changes to enterprise resources are assembled. It is where transactional requests take shape, in a tentative and provisional form, before they are finally submitted to the back-end database manager or TP monitor. 
     The appropriate object here is something we call a Proposal. It encapsulates is all state and behavior associated with a given transaction-in-formation. Using this crisp name and clear role for the territory between front end and back end, as we hope to demonstrate in this article, brings the entire application design dramatically into focus. 
 

. 

     In the human world, a proposal—to buy a house, get married, do a certain job for a certain fee—is a necessary step between mulling something over and signing an iron-clad contract.  Proposals are how deals gets shaped. They tend to be tentative, negotiable, and probably not perfect right off the bat.  They may go through multiple versions.  And every proposal eventually reaches a point where it either turns into a contract or is abandoned. 
     A Proposal object serves a similar function in hammering out the transactional “contract.” It encapsulates the process of assembling a request for a change in enterprise resources. Since it is a “thing” and not an “activity,” it can be long-lived.  It can be worked on over time, passed from one user to another, rolled back to previous versions, firmed up as it moves through the organization, and tried out against the back-end resource manager multiple times until it “takes.” 
     Contrast Proposal characteristics with those of its more straight-laced cousin, the domain object. A domain object strives to be complete, synchronized, and 100% correct.  A Proposal object, by contrast, can tolerate erroneous, provisional and incomplete information. It is tentative rather than definitive, remember: a proposal, not a contract. 
 
Adding Proposal Space to Transactional Apps 

     Proposals revolutionize both the building and the use of transactional applications. On the building side, they provide developers with a great deal of reusable infrastructure.  Much of the code that now has to be done from scratch for every new type of application comes built in to the Proposal framework, ready to be picked up and used. 
     For starters, a Proposal takes over the job of mapping front-end input to back-end data structure. It contains an intelligent hierarchic framework that lets the programmer assign each field or group of fields to a certain level in the hierarchy.  The transactional request gets structured automatically, with Proposal fields automatically and rigorously mapped to domain fields. 
     Also “at no extra cost” to the developer, a Proposal provides advanced transaction-forming behaviors such as document navigation, error- and annotation-handling, versioning, and archiving. As a reusable object, it can implement features that would be too expensive to program into an individual application. 
     Since a Proposal is free-standing and disconnectable, it acts as a kind of universal connector. It can interact with a variety of front-ends, then turn around and interact with a variety of back ends. It well accommodates the increasing need to support various new front-end technologies. In fact, with front and back decoupled, most kinds of changes can be accomplished with localized programming rather than sweeping, application-wide rewrites. 
     Applications built according to a Proposal-based architecture make more effective use of both humans and computers. They model the way humans actually work— collaboratively, sporadically, sometimes on-line and sometimes off. Proposals represent a kind of a staging area for information where errors are not fatal and incompletions can be filled in later. And they increase the usefulness of computers as tools. Where current technology kicks in only at the end of what can be a long, collaborative, start-and-stop process that has to be assembled on paper and routed through the organization by people walking from desk to desk, Proposals get the computer involved from the beginning. For example, a new-hire procedure could start on the day a resume arrives, follow an applicant through the interview/background check/skills test process, and finally, if all goes well, turn into a formal AddEmployee request to the HR database. 
 

 Where Does a Proposal Live? 

     Proposals are not tied to any specific platform, tier, or machine. They move freely; in fact, they can change location on a moment-to-moment basis.  Proposals add a mobile element to systems where every other process is fixed in place. The front end has to be near the user, the back end has to be near the data, but a Proposal can be placed sometimes close to the front, sometimes close to the back, or anywhere in between. 
     In a client/server interaction, the Proposal would typically reside either on the client (fat client) or the server (thin client). In a three-tier system, it would probably occupy the middle tier. In a monolithic system, it would sit between user and data on the mainframe. Again, these are typical arrangements, but there is nothing imperative about them. 

To accomplish its job, a Proposal object must assume responsibility for keeping its own metadata and data, and for many navigational, organizational, and interfacing chores.  We have come up with the following: 

1. Knowing its own specification 
2. Acting as a container for proposal data 
3. Keeping versions of itself 
4. Retaining and tracking errors 
5. Holding annotations 
6. Protecting against stale data 
7. Interacting with the back-end server 
8. Interacting with consumers

1. Know Its Own Specification

•  Field definitions (name, type, size, description, default value)
•  Field consolidation into fieldGroups (which fields aggregate; which are key)
•  FieldGroup inter-relationships (parent-child or peer-peer relationships; whether   groups are required or optional)
•  Definitions of “Assumptions” used to detect and handle stale data
•  Any special processing, in the form of Java code.

2.  Act as a Container for Proposal Data

Data can be saved in any partially-completed form.  Hierarchic navigation through the data, a sort of “page-turning” through a complex document, comes built in, thanks to the hierarchic “map” contained within the PropSpec. Users move through and interact with the data in standardized ways. 

State: Proposal Data, the hierarchic collection of end-user supplied data 
Methods: Access allows outside objects access to Proposal data 
                 Navigate supports movement through the Proposal hierarchy 
                 Mutate performs reasonable data re-organization when metadata is changed 
 

3.  Keep Versions of Itself

State: Versions, each containing a summary of changed data, time of change, person making change, etc. 
Behavior: Undo/Redo 
 

4.  Retain and Track Errors

State:  Error Messages and what parts of the Proposal they are associated with 
Behavior:  Error Management involves searching for, locating, and summarizing errors 
 

5.  Hold Annotations

State: Annotations:  text of annotation, source, time, field attached to 
Behavior: Annotation Management involves searching for and summarizing Annotations 
 

6.  Protect Against Stale Data

• allow the adapter to indicate which fields are candidates for stale-data checking;
• implement a default response when stale data is detected, namely rolling back the commit and notifying the user;
• allow the adapter to include Java code specifying any customized detection, notification or fixup algorithms.

 

A Proposal has to both extract data from and submit data to a back-end data store.  It must be able to translate between its own hierarchic structure and a back end that could be either relational, function-oriented, or object-oriented. 
     The Proposal’s back-end interface is responsible for replicating data from the datastore to the Proposal object (populating the Proposal) and, later, submitting the Proposal to the back end and requesting a commit. 
     Because back ends come in three different styles, the Proposal provides a separate interface for each: 

• Interface to a database system (JDBC) can automate “data-mapped back ends.
• Interface to a transaction processor defines the protocol for “function-mapped” back ends.
• Interface to an OO database can automate “object-mapped” back ends.

State:  Interaction Mode defines various Proposal interaction patterns with the back end 
Behavior:  Populate/Submit 
 

8. Interface with Consumer

State:  Observer Registry of interested consumers 
Behavior:  Notify consumers of  changes to Proposal state 

 

Once a Proposal object joins the design scene, it acts as a natural “attractor” for task-specific application behaviors that would otherwise be dumped into domain objects. 
     Take an example from the human resources world. Many simplistic object designs show an Employee domain object that includes a method called HireEmployee. This seems superficially appropriate, but it results in a very cluttered Employee object, since “hiring” touches many other domain objects (JobHistory, EducationHistory, Position, BenefitsEnrollment, etc.). Rather than cramming all this cross-domain activity into the Employee object, it makes more sense to put it into a generic Proposal object called NewHire, whose job it is to link up with JobHistory, EducationHistory, etc. The Employee object becomes simplified and more specialized, with fewer collaborations to adjoining domain objects. 
     In general, Proposal objects suck task-dependent behaviors out of domain space and into their own. This not only shrinks domain objects but make the whole application structure significantly more coherent. 
 
Proposals Redefine Model/View Separation Concepts 

Most object designers use some form of Model/View separation (e.g. Smalltalk’s widely-copied MVC paradigm) to maximize understandability and reuse. This is a powerful design construct that we highly recommend. However, designers familiar with this notion sometimes shy away from Proposal-based architecture because it introduces a third entity that doesn’t seem to fit into the model/view dyad. 
     The key here is that Proposals (which, in our implementation at least, are completely non-visual) are just another kind of model. Proposal models can have their own proposal-oriented viewers, just as domain models have domain-oriented viewers. This taxonomy is simple to think about and adds new precision to the definitions used in application construction. 
 
Proposals Imply Workflow 

Once Proposals get designers thinking in terms of long-running, malleable, pendable business functions, it’s a short jump to thinking about controlling the definition and maintenance of the outer business process itself. This is workflow territory.  Workflow and Proposals are strongly compatible. Workflow is the train; the Proposal is the container that the train transports. 
     There are, it seems to us, actually three kinds of objects in a Proposal-based application architecture: Domain objects that support domain-specific behaviors; Proposal objects that encapsulate the proposed changes to domain objects; and FlowControllers that deploy, move, and submit Proposal objects. Simple applications may need only minimal FlowControllers or perhaps none at all, but as business re-engineering leads to increasingly collaborative applications, all three elements will need to be fully architected. 
     This larger picture lies beyond the scope of this paper, but it does show that once an insight like Proposals clear up a part of the picture, the more we suddenly see needs to be done. 
 
Metadata in the Middle 

New component-oriented visual construction techniques use some form of “data-aware control.” Think of those demos where a developer drags a bunch of GUI or Web components onto a blank window and builds an application that magically  knows how to make all the connections to the database. 
     Unfortunately, this appealing approach leads to a kind of architectural “squeeze play” that limits its usefulness in complex systems. Data-aware controls require easy access to the metadata of the objects that they are rendering. When that metadata living at the system’s back end—the only place it can live under conventional design—interesting middle-tier objects are impossible, for they would occlude the front-end objects from the back-end metadata. 
     Proposals solve this problem because they move metadata from the back of the architecture into the middle. (In fact, a Proposal carries considerably more metadata than a back-end object, since it also includes information about the relationships that domain objects have assumed to accomplish a particular task. For example, a ReorderPart Proposal knows exactly how the Product object relates to the Supplier objects.) 
     Once the self-aware Proposal object is in place, a “Proposal-aware” front-end component can automatically represent mid-tier assets. This moves much more of the system’s self knowledge forward in the architecture, where it can do the most good. 
 
Cascading Proposals 

We usually think of Proposals as preceding Domain objects in the application lifecycle.  But sometimes it’s useful for Domain objects to spawn Proposals. 
     Consider a NewHire Proposal that, upon submission, updates numerous domain objects. A business rule could be added to the Employee domain object so that it  would spawn several new Proposal objects--OrientationEnrollment, BenefitsEnrollment, and FootballPoolRegistration—and fire them off to the new employee. Business events can cause processes which fire further events. 
 
Life After Proposal Death 

Even after a Proposal has been submitted to domain space and resulted in a successfully committed transaction, it can be archived and continue to perform posthumous service. 
     Proposals contain far more detailed information than most domain spaces would ever consider holding. For example, a Proposal that has passed through four desktops before commitment carries a  record—right down to the field and timestamp level—of who made what changes when. It also contains (in the form of annotations) the “chatter” that reveals the rationales behind changes that are only summarized in the formal data. 
     Thus, an archive of Proposals provides a complete record of questions, comments, explanations, approvals, and changes that could prove invaluable in the case of later litigation, quality control, auditing, process re-engineering, etc.