Re: Multiple specification of constraints

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c1ku71$jqu$1_at_news.netins.net...
> "Marshall Spight" <mspight_at_dnai.com> wrote in message
> news:9wd%b.121916$jk2.526707_at_attbi_s53...
> >
> > It is a real issue, but I don't agree with the direction you're taking.
> >
> > I think the optimal solution here is to have the constraints specified
> > declaratively and centrally, but to be able to *additionally* execute
> > them remotely, i.e., on the client. That last part, on the client, is
> actually
> > the least essential place for validation to occur; it's the only one that
> > can be omitted. It's always essential to have it enforced centrally, on
> the
> > server, because clients are typically not running on trusted computing
> > bases.
> >
> I agree they should be specified "centrally" but don't necessarily agree
> with what you mean by that. If you mean that they should be specified in a
> way that is tightly coupled with database storage services, I disagree.

To me, the constraints are a subset of the data that the dbms should manage.

> I would advocate for use of a design that might include an http server
> with a jvm as the location for all central rules/constraints processing.

This is exactly the architecture that I've worked on every day for the last two years and it doesn't work very well. For one thing, it introduces a requirement that all code that will write to the database has to go through the jvm. What do you do about your C++ code? What do you do about your code that cannot withstand the occasional garbage collection pause? What do you do about third party software you want to integrate that is written to use an industry standard interface such as jdbc or odbc? It also means that your constraints have to be written manually into procedural code instead of specified declaratively, and that means bugs, and *that* means corruption and constant maintenance.

> I
> certainly wouldn't locate the validation on the client, but might use the
> Service UI libraries with Jini for distributed computing -- in that case the
> compiled (to byte code) validation logic is executed on whichever platform
> it needs to be.

Something that allows the validation logic to be executed remotely is clearly very useful.

> Additionally, I would argue that the user interface is the MOST important
> place for knowing the constraints so that the user interface can be as
> intuitive as possible, preferably written so as not to permit any illegal
> data from even being entered (but where that isn't feasible, at least
> letting giving the user the opportunity to fix it immediately). The user
> interface makes a big difference in the accuracy of the information
> collected.

I disagree. This is a performance issue merely. If you have validation code only on the client, then other people will write code that skips the validation step and enters whatever data they want. People hack e-commerce sites in this way all the time.

I agree that user interface is important.

> I forget who wrote up the story of a major retail chain that built a new
> store in a certain zip code because their data said a lot of people go from
> that zip to another to go to this chain. They had to close the store for
> lack of customers. It turnes out that one of the retail clerks didn't like
> the constant question of what zip code the buyer was in, so she always
> entered her own to get past that question. Software usability is key to
> clean data. The GUI having full knowledge of the business rules
> (validations & all constraints) is critical to a usable GUI.

I agree that good UI is important. You example, however, illustrates an error in application design, not with integrity enforcement.

Worst case, it's possible to defer checking input until a round trip to the server is done; this is still secure and can be made into a decent UI, although it's clearly not idea. The alternative is to have insecure code.

> If the
> validation should be coded only once (which I agree with), it MUST be where
> it is usable by the user interface routines. And if we apply all integrity
> logic up front, so that nothing gets past our validation routines into the
> database CRUD services, then we don't have to have duplicate logic in the
> database, right?

I think the idea of having it be possible to automatically replicate the integrity checks on the client (or on whatever earlier tier) is the better approach to pursue.

Marshall Received on Fri Feb 27 2004 - 04:47:53 CET