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...
> > 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.

Why is the storage even an issue? Surely we've abstracted above storage by now? A relational DBMS says what your data means - would you say that the Pick dictionary is "data storage"? The dicionary seems to be the "meaning" of your data, at least in a limited way. With relational languages like D4, you can say much, much more.

If people just think of a database as a way to write to disk, then I guess the conversation is fairly stymied already. Hmph.

> 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.

Why not Jabber? Why not something that can process Microsoft IDL?

Those items aren't design decisions - they're technologies. I'd say we need a declarative rules engine of some sort, which ideally could run on multiple platforms and which could be interrogated so that other technologies could use (or be generated from) its rules.

Well what do you know? I just described an RDBMS.

> I certainly wouldn't locate the validation on the client,

Why not?

> 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.

Jini is a nice technology - too bad Sun basically abandoned it (not officially, but with regard to PR). They apparently can't make as much $ as they can from J2EE licensing.

I agree that a service locator is a useful solution-domain component, but shouldn't we focus on WHAT the "rules engine" does, rather than how we get to it via various protocols?

> 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.

If (when) you have multiple UIs, the coordination becomes more difficult. Keep in mind that data load programs are also UIs, and there may be multiple languages involved, making it difficult to funnel through a single component in a single language. Until, of course, you get to that magical "back end."

> It turns 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.

Not really. It's key to not annoying users, but it's not at all key to clean data. What rules, data design, etc. would have prevented the above problem?

> Another advantage of this approach is that there is not a need for both a
> DBA who knows one language and an application developer who knows another
to
> either a) cross train so they are both competent in each or b) wait on
each
> other, often not exactly in a "team player" sort of way when a small
change
> is required in an application that requires a change in the type checking.

Certainly developers should understand the data definitions and its language... otherwise we have real problems (and we do). The DBA is more concerned with the implementation details of the DBMS, and how to keep it humming along.

Coordination can be an issue. However, I've seen some recent discussions of "agile" database management that rely on scripting, frequent builds and unit tests, etc. to help ease the burden. It's the same with QA, documentation, project management, etc. It's a people issue, not a technical one per se. Received on Wed Mar 03 2004 - 16:44:35 CET