John Tibbetts, Kinexis (john@kinexis.com)

It's clear from reviewing the papers that have preceded this one that BTPS covers a lot of conceptual ground. We see a mixture of the metaphysical and the pragmatic, of domain analysis and infrastructure analysis. (I agree with Ralph Johnson's call for a taxonomy of this terrain). This paper will tend toward the abstract side. It deals with the actual shape of today's BTPS and how we might improve the way they are built and used.

My area of interest is in the relatively unexplored (certainly unarchitected) space between client and server, the space where actual applications get written. Whether we use function-oriented or object-oriented techniques, the standard software project still includes a great deal of low-level behavior that has to be created anew for each new application. This is the area that is probably most responsible for the always-bemoaned application backlog.

I believe that this application middle-ground can be approached in a much more formalized and generalized way. Doing so would, I believe, dramatically shorten development cycles while reducing development risks. I call this new approach a Proposal-Based Architecture (PBA).

If we examine the state of business software application architecture (no matter what the application and no matter whether the distribution model is monolithic, client/server, 3-tier, or distributed object), we can probably agree on the following points:

• Application software back-ends have some amount of architecture
  Whether the back end is a database server, application server, or object server, there exists a reasonable body of formalized knowledge about how to design and implement it. Many approaches may not suit our taste, but there are numerous techniques that help us think about our domain space. We know how to analyze, describe, diagram, model, and normalize the data assets of our organization. Weâre even making slow progress at working with the behavioral assets.
  
  In addition, we have a fairly well-developed view of how to implement these assets and protect them with the transactional ACID properties (Atomicity [integrity], Consistency [correctness], Isolation [locking], Durability [logging] ).
  

• Conversely, front ends are made up of gadgets, not architecture
  There are hundreds, if not thousands, of gadgets for building a user interface. Almost universally, these gadgets work at the level of the individual fields, buttons, and menus of the application. UI techniques deal with the atoms of the system (while the back end is up at the organic molecule level) and tend to have little semantic application content beyond the basic attributes from a field dictionary.

• We build "applications" to glue these two ends together
  Applications are the "exploitation region" where we have to link the semantically-low UI atoms to the semantically-high domain objects. We do this by writing code that implements a sort of hard-wired conversation between the two poles. For example, an order-entry application needs to organize the field atoms into pages, then further organize many pages into some logical document, ensure closure, interact with a server to populate and commit fields, define logical locking points to guarantee Isolation, etc. Later, when it comes time to modify either end, even a small change entails plenty of development work in the middle.

If we could come to a better understanding of this application middle-ground, perhaps we could abstract out reusable patterns and behaviors and make the application-building experience more streamlined, more stable, more like engineering.

I believe that we can do this. The key is to recognize the nature of this middle-ground as the space where units-of-work are formed and to design objects that are specialized to live in this world. They might best be called Proposal objects because they incarnate an emerging proposal for a subsequent transaction. Their life-cycle starts with the consumer's (whether human or machine) wish to initiate a change to enterprise resources and ends with the submission of a Proposal to an authoritative backend for implementation as a transaction. (Actually there is life for a proposal after commit, but that's a fine point).

A Proposal-based architecture looks at application architecture in a new way. Its insights come in three parts:

1. PBA thinks of the interaction between user and transactional back end as a highly ritualized conversation.
2. It turns this conversation into an object, which sits between the user and the back end but is independent of both.
3. Third, PBA architects into the infrastructure of this Proposal object the common housekeeping tasks that all transactions share, such as navigation, error handling, and versioning.

With the Proposal object as a buffer between front end and back end, transactional applications become dramatically more flexible. The close technological coupling between these two application pieces relaxes. The real-time connection between user and transaction monitor breaks. Suddenly we have a useful new entity: a tentative, in-process, potential change to the database; a proposed transaction that can be passed around, pended, annotated, refined, corrected, and submitted to the back-end when ready.

A proposal object encapsulates the full "state" of the transaction-in-preparation at a given point in its progress. Object-ized, it becomes instantly workflowable, innately pendable, and inherently disconnectable from the server.

In effect, PBA turns a real-time activity into a durable thing. This brings the many advantages of object orientation to a large area of the system that has until now been a sinkhole of programmer time and development dollars.

• Development is greatly simplified. Proposal-based architecture handles complex front-end problems with a reusable, generic infrastructure. This infrastructure contributes many features (undo/redo, annotation, etc) that would otherwise have to be programmed manually.
  

• Navigation comes built in. A Proposal, self-aware like all objects and even more introspective than most, knows a great deal about its own structure. It knows the type of its contents, how the contents are arranged, and the validation criteria for its contents. It "turns pages" and skips to appropriate fields automatically. The complex programming currently required for multi-page, hierarchic documents is avoided, because navigational intelligence is part of the proposal object's infrastructure.
  

• A Proposal decouples the user interface from the transaction processor. The Proposal, not the user, addresses the back end. On the other end, the Proposal accepts input from virtually any user interface. (Since the essence of a Proposal is non-visual, viewers are "dumb" and easily created.) Thus, a single back end can support several different user interfaces (Internet, GUI, OOUI, proprietary interface, a device like a bar code reader or keypad) simultaneously or serially. A Proposal could be initiated on a scanner, sent over the Net to a human using a Mac, reviewed on a Web browser by his supervisor, and launched toward the TP monitor from a PC.

• Proposal-based architecture adds value throughout the process of preparing a unit-of-work. Current technology kicks in only at the very 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 around from desk to desk. Proposals get the computer involved from the beginning. They can tolerate tentative, half-done, interrupted, even erroneous data, and help shape it into a formal transaction. For example, a new-hire procedure could start the day the applicant comes in for the initial interview, follow her throughout the interview/background check/skills-test process, and finally, if all goes well, turn into a formal "AddEmployee" request to the HR database.

• Proposal-based architecture lets transactional applications take advantage of Workflow. The two technologies are strongly complementary: workflow provides the transport system, Proposals package up the contents of what is transported. A one-user/one-mainframe conversation cannot be transported around an organization, but an object can. Proposals turn transactional conversations into routable entities that a Workflow system can handle.
  

• Inherently independent of the server, proposals work equally well for on-line, real-time interactions and for off-line data gathering. They are ideal for mobile computing.
  

• Proposals concretize the transactional conversation. A transactional conversation--ephemeral, like all conversations--vanishes once completed or aborted, leaving no record of the process. A Proposal, on the other hand, contains a detailed history of its own evolution: preliminary attempts, annotations, approvals and overrides. Since it layers every step in its development like overlapping transparencies, a Proposal can be rolled back to any earlier point. Full n-level undo/redo is automatic. Proposal objects can also be archived, creating a full "paper trail" for later audit.

• PBA enables new-wave Internet security, including authorization, authentication and digital signatures. Individual versions can be set up to support reliable signatures indicating who requested what changes. A Proposal object can display both its current, cumulative state and also a linked list of changes, signatures, and dates and traces what happened at every point. The CIA could, for example, go back and identify every transaction that Aldrich Ames had a hand in.
  
• Since PBA "checks out" corporate data to work on over time, there is the possibility that the underlying data will have changed by submission time. PBA solves the stale data problem with optimistic locking. Built-in recovery frameworks compare assumptions with the current state of the data. Programmers can specify, on a field-by-field basis, whether a discrepancy should be handled with notification, rollback, commit-with-notification, or some user-supplied custom fixup.

None of the above capabilities is unheard of in transactional applications. But where they exist, they have been achieved with great effort, and on a one-time-only basis. The significance of PBA is that these capabilities are innate. They are built into the infrastructure, available to any application that wants to make use of them. In a sense, they come free.

The PBA approach to conceptualizing, object-izing, and architecting the vast application logic piece of transactional systems offers many advantages.

• Developers find a ready-made framework that contributed large chunks of useful infrastructure, dramatically reducing the time and effort of building transactional apps. They also get a formalized methodology for organizing that kind of development job.
  
• Users find an accommodating face on formerly unforgiving applications. If a TP monitor is like an impatient and demanding boss who will kick you out of his office if you havenât got all your duck in a row, a Proposal is like a sympathetic admin sitting out in the anteroom, helping you organize your presentation, gather your supporting documents, and checking in with the boss of your behalf.

• Organizations find their aging applications catapulted into the 90s. Adding Web front-ends, using Workflow, implementing mobile computing and collaborative computing become trivial jobs instead of major undertakings. And PBA restructures applications so they are ready to take advantage of new developments as they come along.

# # #

John Tibbetts is an independent consultant who, under his corporate name, Kinexis, has consulted with a wide variety of large corporations on their transactional architectures. His clients have included banks, insurance companies, railroads, telecommunications companies, and hardware and software vendors. His 1991 OOPSLA Keynote was an early and influential call for more transactional support within object technology. He was the author of the Digitalk Smalltalk CICS interface. Recently, he has been building a Java-based framework to support a Proposal-Based Architecture. With his partner, Barbara Bernstein, he writes a regular column in Information Week magazine.