This page contains very early and roughly drafted documentation for "Holistic", a future Web 2.0 architecture using Language Oriented Programming(LOP) concepts and "Liaison", a design pattern for client/server data synchronization in Web 2.0 applications. In addition I have added some materials on subject-oriented programming, an enhancement to object-oriented programming which the Holistic architecture makes references to.
Holistic
Liaison
The liaison design pattern is one of the core patterns in the Holistic platform architecture. Liaison was designed to solve the following problems in Web 2.0:
- Clients often manipulate the database model directly
This results in a maintenance dependency: when the database model changes the clients have to change as well
- The data that makes up the model is often table-oriented no object-oriented
This introduces an impedance mismatch: programmers need to convert between table data and objects in one or both the client and server.
- Clients do not have access to the methods defined by the server classes that model the data
This (1) prevents the client from using useful business logic (e.g. validation) in the server or (2) causes duplication of business logic in the client or (3) forces complex and inefficient remote services to be implemented for simple things.
In some frameworks (like GWT) clients have some access but its limited to simple methods that don't rely on the state of other objects outside the container hierarchy of the object.
- Clients are not aware when changes to data occur even when that data is currently being displayed to the user
This means the data the user sees on screen is stale and the only way to get updated data is to the user to manually request a refresh. The refresh process is also inefficient as the client needs a full trip to the server and back. Some frameworks like SproutCore use the KVC/KVO patterns to solve this problem within the client but there is still no way to synchronize data for the entire network of server plus multiple clients.
- The format of the data model of the server and client is different to the format of the data required by GUI components
This requires client programmers to write custom code to translate the shared data model to a GIU framework specific data model. This kind of data translation code is trivial and therefore should not be done manually by the programmer: It should either be avoided by using standard data formats or automated somehow.
The liaison design pattern is based on abstract data types (ADTs). Instead of sending raw data (or objects) between client and server we send a full abstract data type complete with validation methods, knowledge of its structure and containers and generic operational methods that both client an server can use to modify the data. Obviously these ADTs need to be fully implemented on both the client and server sides which means more than one target language (e.g. Java nad Javascript). Additionally these ADTs implement network transparency meaning both the client and server sides are unaware whether the other is on the same host or in the same address space or not.
Stay tuned for more details on Liaison...
Example: The matrix ADT
-- 2D or maybe 3D , nD matrix data structure
-- row/column IDs are not necessarily numeric indexes
-- labels may be strings
-- an index is a tuple (ordered list of labels) e.g. non-literal "[sales, (thisYear - 1), cupertino]" or literal "sales.2008.cupertino"
implementation :
-- index into an nDimensional matrix is an nAry tuple (a list of n lables)
-- each significant element of the matrix is stored in a hashmap <tuple --> cell value> for efficiency
-- defaults may be set on a row/column/plane basis to replace empty cells with a valid cell value (e.g. 0 zero)
Features
-- matrix operations when element type is arithmetic
i.e. madd = m1 + m2 ; mscale = m1 * 2; msub = m1 - m2;
mmodify += m1
-- aggregate functions on rows/comumns/planes
-- aggregate closures
-- compound labels (e.g. sent row + received row == ordered compound row) with auto aggregation with "+"
-- spreadsheet like formulas in "derived" cells
e.g. instead of a literal cell value have a formula
-- formulas can reference properties in outside objects
-- formulas reference other cells by : matrix object reference + index
e.g. "= #finance sales 2008 cupertino * @form . proportion * Sally commission . amount(precision:2)"
note: form is not a matrix - its a normal object
note: the cell Sally commission is in out own matrix and contains an object with a function "amount"
note: # and @ are external references. # is a matrix, @ is an object
-- if unambiguous the # and @ can be dropped for readability :
-- referencing objects outside the current matrix requires some kind of parent container
-- stateful facades to manage efficient access (use cursors and back()/forth() eiffel style)
EXAMPLE USE :
For the sale order items in a retail POS software :
class QuantitativeLocationState
inherit Matrix<[state:State, location:Location], BigDecimal>
© 2008 Keith Foster. "The Daring Developer" was created for people who share an insane excitement about advanced software engineering.