Re: Transaction Oriented Architecture (TOA)

H. S. Lahman wrote:
The basic problem is that the RDB paradigm is designed for generic, ad hoc access of data. IOW, it is optimized to be independent of what problem is being solved with the data. Once one is outside the CRUD/USER arena, applications are optimized to solve very specific problems. That optimization involves different approaches to things like relationship navigation (e.g., object-level instantiation vs. table-level). So the views of the data should be /expected/ to be different. Therefore one solves the business problem first and then worries about how one maps that solution view into the DB view.
So you're agreeing the data structures are different in the application than in the DB? The biggest difference between what you say above and the article is that the article recommends starting with the DB, proving it correct, then developing the application.

I sense, perhaps incorrectly, a disparaging view of CRUD/USER applications. You comments in both this thread and the thread "Relational Database & OO" seem to indicate an opinion that CRUD/USER applications are too simple to be representative of sophisticated OO designs.

Is that true, or am I reading something in your comments that isn't there?

In addition, a big advantage of encapsulating in a subsystem is large scale reuse. Once one abstracts the invariants of the DB paradigm de jour properly, then the subsystem can be reused across applications. Thus the RDB paradigm is abstracted exactly the same way regardless of the semantics of the data. That is, one encodes the invariants of the paradigm and leaves the details to data (e.g., mapping of table names, field names, etc.). To do that one just applies basic problem space abstraction to the RDB subject matter, so there it really costs very little extra to achieve that reuse.
Reuse is valuable and admirable, but the creation of an "encapsulating ... subsystem" may be unnecessary, and touting the benefits of reuse sounds like making virtue of necessity--except it may not be necessary in the first place.

A database API is reused everywhere applications interface with DBs. The mapping of the DB (like VW Smalltalk's EXDI or Java's JDBC) is reused--it makes the DB's API more language-malleable, and that's reused everywhere--regardless the application domain (I'm not aware of many people that have created their own replacements for either EXDI or JDBC).

You seem to be advocating the creation of a layer between the application the the language-DB interface that maps the application domain objects to the DB--I'm guessing classes to tables, instances to rows, and fields to columns. The /infrastructure/ you're describing (I'm guessing) gives OO instances behaviors that allow them to either instantiate themselves from or /persist/ themselves to the DB. It is this behavior, the endowing of DB-awareness (or persistence--a rose is a rose...) into our classes and their instances, which is characteristic of the denial I was talking about. It is the premise of object databases and their lesser incarnations of object-relational products that the boundary between application and DB is better buried than exposed. The simple fact that it /can/ be done proves to many that it /should/ be done. This is a Jedi mind trick.

If I'm right in understanding what you're saying (and what countless vendors, analysts, and pundits sell, present, and report), this is exactly where our designs part company and where Transaction Oriented Processing (or TOA--but I dislike the word architecture when used with software) proposes an alternative, thinner, and simpler model.

However, for that to work...

<snip>

One needs to design the interface to the problem solution's needs. Thus it is the interface that needs to be replaced during large scale reuse (think: Facade pattern). To be successful the interface needs to be a pure message-based interface so that each side can map the message ID and data packet into its own unique view. That, in turn, means a consistent mapping of identity on each side of the interface.
The belief that there needs to be symmetrical mappings on either side of the interface assumes their needs to be a mapping in the first place. That's surprisingly similar to petitio principii, the fallacy of assumption more commonly known as "begging the question." TOA/TOP proposes (and I know I haven't gotten that far in the article) the database and its application domain stored procedures are the only persistence mechanism necessary, and that the benefits of a focused, single, data-permeable gateway between application and database far exceed the benefits of O/R mappings--regardless of abstraction--and that its lightweight appearance shouldn't be dismissed as missing heavyweight kick.


Fortunately, that is usually easy for data, especially for paradigms like the RDM that are designed to provide generic identity. Half the work is done if the DBMS schema is available to the application. So one just needs a bunch of table lookups to map data packet elements into Table/Field identifiers to construct SQL strings. Those lookup tables get defined from external configuration data that maps the interface messages into the RDB schema.

The price of this is encode/decode of message data packets on each side of the interface. For a SQL RDB, that effectively means duplicated dataset encode/decode. Fortunately DB access is in milliseconds while encoding/decoding data packets is in microseconds so nobody is likely to notice anything except the developer's extra keystrokes, which don't count in the overall scheme of things.
It may be early in the AM (for me) but I'm not following what your talking about above.

When there actually is a 1:1 mapping between the solution and DB views, that message indirection is redundant. But that decoupling pays huge bonuses when the mapping is not 1:1, when the mapping changes in the future, and for large scale reuse across applications. The thing is that once one is outside the CRUD/USER realm when solving some customer problem, one can't know when the mapping will be 1:1 or when it might change.

So one should solve the customer problem without worrying about what the DB looks like. If some objects happen to map 1:1 that is transparent because the interface is designed to the solution's data needs (e.g., "Save this pile of data I call 'X' and give it back to me when I ask for 'X' later"). IOW, one should be able to solve the customer problem and design the DB access interface without knowing or caring how the stored data is ultimately organized.
But the customer problem can be solved without using OO. It can be solved in FORTRAN, COBOL, C, LISP, or JavaWOO (much of the Java I've seen isn't very OO at all so I wanted to include it in my list of non-OO languages--Java Without Object Orientation). The customer's problem and the DB are constants. Only languages and idioms lie between and may be interchangeable. In fact, if the DB domain requirements are consistent (its domain-API expressed through procedures) then suitable applications can be written in multiple languages without compromising the DB's design.

At another level, I don't see how you can advise not embedding SQL in the problem solution without providing the indirection of a message-based interface.
Use stored procedures. No mapping necessary.
Creating surrogate objects for the RDB that do construct SQL queries and letting other objects talk to them to do the grunt work doesn't really reduce the maintenance risk very much.
No, but it sprinkles SQL throughout the application. SQL is necessarily DB-design aware. If the DB design changes the SQL must necessarily change as well. I don't want to be in the SQL maintenance business.
When the schema changes you are still touching the solution subject matter's code and that implies risk of breaking the solution over a pure DB issue.
Not at all. We either believe complexity is hidden behind our interfaces or we don't. As proof, our application (commercial finance and paper trading) has regularly changed table designs without affecting stored procedures. The application talks to the DB through stored procedures to affect data changes. The application needn't change unless the stored procedures do.

This is identical to programming functions. I can change the implementation of a method, and as long as the method interface (name and arguments) don't change then no one calling it needs to change.

It will also be tempting to bend the solution around those surrogates, which can lead to a less optimal and maintainable solution. That is, if one has a preconceived notion of what the data looks like, one will be tempted to build the solution around that view. So the generic, ad hoc tail is wagging the solution dog.
But preconceived notions exist on both sides of the interface. As the saying (almost) goes, two preconceived notions don't make a right (notion). The database must be language neutral--but it can't be domain neutral. If it were domain neutral then we'd be implying its design didn't support the domain--which would defeat the purpose, no?

IOW, I think maintainability will be maximized when the subject matter concerns are clearly decoupled. The strongest way to do that is by encapsulating the DB access in a subsystem behind a pure message-based interface.
If you believe message-based interfaces are valuable, I propose TOA/TOP is a more faithful realization of it.

--
Visit <http://blogs.instreamfinancial.com/anything.php> to read my rants on technology and the finance industry.
.

Relevant Pages

  • Re: When is a function not a function?
    ... a DOM element and Array or a value with falseness. ... betrays very poor code design. ... subject of the test is expected to be any of a javascript function ... There is nothing to say that an object implementing the Node interface should not be a function object. ...
    (comp.lang.javascript)
  • Re: XP Requirement Analysis?
    ... and use TDD to force the same design to emerge. ... > These principles, used with other XP situations like pair programming, ... OK, but you need to know what that interface is, so you must do some ... to buy a business value. ...
    (comp.object)
  • Re: New to JUnit... Eclipse Question
    ... You create the interface to get the caller to compile then you have to write the implementation to get it to pass. ... I've argued before with someone claimed that according to YAGNI you would never create an interface until you have two classes that would implement the interface. ... its not a license for being dumb or lazy and making stupid design choices - see the end of this email for an account of when it did happen on one of my previous teams. ... So there are many good reasons for using interfaces even if you don't have a bona fide "need" yet. ...
    (comp.lang.java.programmer)
  • Re: OO applications (2)
    ... >> Thanks Alex for mentioning minimal interface; it is a more focussed expression ... >> 4) Is a desirable first step for any software design task. ... Imagine these steps are consecutive segments of a circle. ...
    (comp.os.os2.programmer.misc)
  • Re: Questions for DesginersArchiects
    ... I am familiar with the design you mention, I suppose I would just love to ... business classes might help to connect the data in the database with the ... a change is necessary in either the interface or the data? ... ..Net Developer ...
    (microsoft.public.dotnet.framework.aspnet)