Re: Transaction Oriented Architecture (TOA)



topmind wrote:
<snip>
You have not shown this, only claimed it. Either approach is not a free
lunch and exchanges one kind of "coupling" for another. The changes
that I see most often in the field favor mostly embedding, for reasons
already described.
Your burden of proof isn't pragmatic--it seems more like willed denial. Anyway:

Given embedded SQL mapping an account /thing/ to the DB as:

select * from account where accountKey='...'

then the SQL is dependent on: an account table/view, its columns, and the explicit reference to accountKey.

Alternatively, and what the paper recommends, is using procedures. Procedure names and their arguments should be considered (and designed/implemented) as an API to the DB's solution domain. Instead of SQL with both explicit and implicit dependencies the API can be used:

exec getAccount @accountKey='...'

True, there's still a dependency on the return columns that remains explicit, but now the application is insulated from changes in the DB. I can rename the account table, I can rename the accountKey column, I can include another table in the procedure's SELECT, or add additional DB-level business rules or performance tuning. Even the explicit dependencies can be feigned by aliasing projected columns.

For a transaction processing system another parameter is added, like a session key, the procedure can use to validate the session has adequate privileges to retrieve that specific account's information and I can log the query to a query history table so I can track everything that session did.

If a wholesale change to the DB is made I can preserve the older, obsolescent, procedures for backward compatibility and create a new procedure supporting the new and extended DB design's functionality.

exec getAccountKey2 @sessionId=... @accountKey=...

Which can not be done as easily with embedded SQL. SQL-embedded applications would require being recompiled/packaged/tested/integrated/deployed which is time consuming, even using automated test tools. The fewer entities that need to be touched for any given fix/enhancement the better off everyone is.

For security reasons I could go a step further, and deny any user SELECT permission on tables and only grant them access to the DB through its API by only allowing users EXECUTE permission on procedures. Of course, this kind of interface (access to methods but not data) is common among object oriented languages and isn't a foreign concept to OO programmers.

In fact, after inspecting multiple C APIs for LDAP, iCAL, and other libraries it appears it's not even foreign to C programmers. Often a structure is used to hold state information for a connection to a resources, but the format of that information isn't exposed to API-users except through an API. Even when a method may only be returning a value from the structure, API programmers know that level of indirection affords them flexibility inside the structure they may use without negatively impacting all the API's users.

So a common pattern is used by both C and OO programmers. What my paper is promoting (and I'll try to do a better job explaining) is that the same pattern be applied to how OO programs access the DB.

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

Relevant Pages

  • Re: NullPointerException
    ... > programmers do make that assumption. ... I told them how they can prevent NullPointerExceptions. ... > public boolean hasAddress() ... It was returned from some API. ...
    (comp.lang.java.programmer)
  • Re: DllMain vs. DllMain
    ... obey the MSDN page that says what the API itself is? ... contains instructions for VC++6 programmers or descriptions of the APIs ... work this morning and fail this afternoon because undocumented behaviour is ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Encapsulating and Securing Pre-canned ADSI calls
    ... The OS will protect the credentials ... You could also set up the process account to use a specific admin identity ... Your business logic security layer ... > 1) Have the API obtain credentials of the user with admin rights in AD, ...
    (microsoft.public.dotnet.security)
  • Re: Shortage of qualified Java programmers
    ... library of Java is what you have computers for -- not people. ... every detail of the API. ... to figure out how a Comparator works given the Javadocs. ... programmers written by Bill Venners. ...
    (comp.lang.java.programmer)
  • Re: Shortage of qualified Java programmers
    ... candidates are very hard to come by in the Atlanta area. ... that a candidate will list every Java technology in the world on his ... API test.) ... questions might be too easy for programmers with 3+ years Java experience. ...
    (comp.lang.java.programmer)