[
Lists Home |
Date Index |
Thread Index
]
I agree with that. Unfortunately, one of the requirements
is 'ad hoc querying' and that opens up Pandora's Box. No
system we've ever built included true ad hoc querying. It
is something consultants tell customers they need for
data mining but if they understood the implications of
at-will cross-table queries, they'd fire the consultant.
Anyone who wants to understand the customer a bit better
should be watching the C-Span presentations of the 9/11
hearings. The IT gal last night described how security
for some kinds of information comes down to having only
one machine that can get it and it is locked inside a
closet so no one can look over the user's shoulder.
The guy with the gun vettes the user.
Now that's a real process environment solution.
The schema is never the solution. It is a contract for
an interface/service data and even then, it has no implications
to choreography. It's a prop design. That doesn't mean
it can't know that the prop is blue crystal and weighs
five ounces. It means that if it knows that and you
want to present that production in Selma instead of
New York, you may have to use a jelly jar glass instead.
len
From: w3c@drrw.info [mailto:w3c@drrw.info]
Ah!
This is why you have ebXML CPA - collobration protocol agreements and
asynchronous exchanges.
I agree - webservices are especially prone to this kinda creative "mining"
of
information, or abuse of access priveledges to resources. We first
encountered this problem in real-time EDI. Same sales pitch - same
outcomes.
So the CPA delimits what exchanges you can initiate - and they are part of a
perscribed business process - so it is most difficult to turn this into an
open
ended fishing expedition!
Now this kind of layering to the problem *does* make sense! Which is why I
mentioned I get al kinda cranky on people who insist on 'just define the
schema
for me' as the solution path. First start with the business needs, and then
work top down to the actual information exchange - which coincidently
happens
to be the *last* thing you end up creating - not the first!
|
