Re: The IDS, the EDS and the DBMS

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Sat, 04 Sep 2004 17:32:59 +0200
Message-ID: <4139e02c$0$78749$e4fe514c_at_news.xs4all.nl>

Laconic2 wrote:
> mAsterdam wrote:

>>Laconic2 wrote:
>>> ...compare two very different reasons for using 
>>>a DBMS.  I'm calling them the "integrated data  
>>>store" (IDS) and the "encapsulated data store" (EDS).  

>>>...people who build an IDS and people who build  

>>>an EDS use the same ...
> techniques".

I would appreciate it if you would be more specific as to what techniques you are
referring to - it may shed some light in this unnecessarily dark area.

>>... The unit of integrity is the database.
> Yes. In other words, in my view, the application is one great

No! "*my* view" (emphasis mine).
One of the (your) purposes of talking EDS vs IDS was to get the discussion out of this them vs. us tone, right?

> big capsule. Evrything inside of it is encapsulated.
> And there is usually more than one application,
> and they don't "talk" to each other, except by
> writing and reading the data in the database.
>
> Therefore, data passed between applications and the
> database is the fullfillment of a contract to supply
> data between applications. Any application that doesn't
> fulfill its contract is a rogue. Rogues that read data
> do so at their own risk. Rogues that write data need
> to be brought into compliance.
>
> But this is the IDS vision of what a database is for.
>
> But the EDS vision is nearly the opposite. EDS designers
> "hide" the information in a database so that it will persist
> when the application is rebooted. But going into such a
> database to pull out information with SQL or any
> other tool is drilling into the capsule.

> It's hacking into information that was not written to be shared.

This is a very important observation, IMHO. It looks like it is shared data (because of the tools used) but it's not.

Traditionally, persistence in OO programing systems was achieved by dumping the system image to disk at some point in time
("serializing the objects", the addition of tags to be able to do the restore
at a somewhat more refined level, was the next step).
Not very shareable. OO design & analysis books hardly gave even just persistence
(let alone sharing) any consideration.
Maybe this is because when OO came en vogue, DBMS had achieved such a maturity level, that persistence could be thought of as
a problem mostly already taken care of.

OT: An anecdote comes to mind.
(it was told by G. Booch, any inaccuracies are mine).

The brandnew AWACS (Airborne Warning And Control System) software, developed strictly OO, was developed and deployed on AS/400, and used the OS/400 SQL facilities for persistence.

One serious integration issue was overlooked. When the first in-air tests began, the airplane would not fly steadily. Why?

The weigth difference between the
old mainframes and the AS/400
disturbed the balance of the plane.
Lead plates were needed to compensate.

>>The EDS's unit of integrity is the application.
>>I could very well imagine a system, consisting of
>>several EDS's, interconnected through well-defined
>>store/forward mechanisms. It could behave to the outside
>>world as one unit - establish a larger EDS.

>
> Doesn't EDI intend to accomplish this goal?

I don't think so. EDI is meant for bilateral or multilateral interbusiness communication. The only integrity concern in EDI is the integrity of one link or chain. EDI is not trying to make a whole business chain look as if it is one supplier or customer.

>>>Encapsulation is an important concept. 
>>>Used appropriately, it can contain the collateral
>>>damage done when a very large system is revised and
>>>extended.

>

>>>I call this collateral damage "the ripple effect".  In my structured
>>>programming years, I might have used modularity to contain collateral
>>>damage, damage,  but I think encapsulation clarifies   
>>>and expands the concept beyond
>>>my own concept of modularity.
>>
>>How so?

>
> Well, back when I was writing "structured programs", the basic tools for
> modularizing a big program were subprograms: procedures and functions.
> Procedures and functions have local variables (in a structured language
> like Pascal), but these local
> variables do not persist between invocations of the subprogram. If a
> subprogram wants to behave more like an object, and "remember" things
> between calls, it has to hide that information in plain view, by stashing
> it in some kind of global or dynamic data structure.
>
> That's persistent (so long as the program runs), but it's not
> encapsulated. Right?

ISTM that in order to share data some structure needs to be visible by all parties sharing it. Encapsulation is not a goal in itself, nor is it either there or not in the resulting system. What to encapsulate? As much of the complexity as is possible without losing purpose. Received on Sat Sep 04 2004 - 17:32:59 CEST