Re: Multiple specification of constraints

"Marshall Spight" <mspight_at_dnai.com> wrote in message news:J5z%b.420838$na.810280_at_attbi_s04...
> "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.

These are good points, Marshall. The questions about the difference in language -- whether your C++ code needs to execute DBMS statements that employ the DBMS language specs or have to interface with your Java code in order to get to the database is a matter of getting implementations to the point where this is not an issue. There is no conceptual or theory issue here, but I appreciate the practical issue that needs to be addressed. The question of whether OO code (those OO types don't like to be called "procedural") or declarative code or whatever language is employed to "spec" the constraints is somewhat a matter of taste and efficiency. I prefer removal of all declarative code because it is data specified to a specific database implementation. While there is some similarlity with the various flavors of SQL, when we talk about the language used to code constraints in Oracle and those for SQL Server or DB2, we are not really talking about the same language.

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

This is only feasible if the validation logic (combination of the specs & the DBMS's use of the specs) is not tightly coupled with the storage & retrieval functions of the DBMS. I haven't seen RDBMS's that attempt anything like this, have you?

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

That's not what I intended to say -- my point was that the UI needs to have knowledge of validation information, such as T/F, radio button or check box data, etc It is critical that this be there -- the user needs the best, most-likely-to-produce-accurate-data-entry information it can get. I don't really have to argue for that since it isn't until some of the pathetic web-page forms that developers started considering not editing entries until late in the process. So I think that most people (including you) would agree that the UI needs this info. You point, I think, is that the UI could get this info from the DBMS. However, then the UI needs the logic engine that the DBMS uses to process such specs. I am in complete agreement that it should not be hosted by clients -- I agere it should be centralized. I just don't see the proprietary DBMS with its proprietary version of SQL and its proprietary engine for applying constraint logic and such moving out to the front of OS-independent and database independent applications and addressing this.

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

Yes, my point was that constraint checking is only part of the picture.

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

I'm missing the point of where the insecure code is? I would have the code running in a jvm on an http server, for example, with Jini Service UI (using jeri for security purposes, if I understand correctly). I think they have address the security issues with RMI in the Jini 2 software with JERI. But I could be missing your point about what you think is insecure.

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

Have you seen anyone try to do this? Do they end up with OS-independent applicaxtions? DB-independent? How do they do that? I'm not grasping the solution to this that includes only one set of validation specifications and hosts those in a proprietary database engine with a proprietary SQL implementation. It seems that any such solution would make the application tightly coupled with the database implementation, right?

Thanks for pursuing -- this is a difficult one for me to get my arms around. Is there any vendor out there that does this well? --dawn Received on Fri Feb 27 2004 - 05:56:45 CET