[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: A DBA perspective.
200101111217_MC2-C164-B59D@compuserve.com">Michael,
Reading your replies below I'm concerned that there is a major
disconnect here. I am grappling with the metrics here and perhaps
I can layout some so that I can see the differences correctly?
My particular view is based on a high level conceptual business
functional view, coupled with nearly 25 years of working with
literally every major database system on the planet, in some of the
largest installations on the planet, and then some research stuff
nobody has ever heard of - plus now working for a
vendor of a leading XML search tool - and having evaluated
much of the XML competition head-to-head.
So - where does this all take us? I'd like to think we can deliver
something here that is completely implementation agnostic.
Therefore to achieve that means explicitly NOT diving down into
specific foobarSQL or foobarXML, or what! ever syntax specifics.
Letting go of that - and saying - what business functional API
should we expose?
On the one hand we have been told - ad hoc querying - query
anything you like.
Hard experience is teaching us, and showing us here, that
this does not work. Why? First of all - users will need to
have far too much knowledge of the internals of the
Registry information model - and frankly this stuff is non-trivial
to ingest - as can be seen from your comments below -
stating this won't work, and that won't work - but this is
HIGHLY dependent on the information content itself and
how it is structured. Sometimes it may work, sometimes
not - depending who built the underlying coupling and how.
I suspect the only people running true ad hoc queries
will be the DBA's inside the firewall of the registry host - and
then we do not care what query language they pick for that!
So what is the solution? I belie! ve we do need to listen to
the DBA world - and that stor! ed procedures that have
documented behaviour just plain makes sense.
Yes you end up with a ton of these. Ever seen the
library the average DBA has? Bottom line is the
END USERS could not care less - all they want is
business results - and they do not want to have to
understand all the internals to get them - and frankly
neither do I at this point!
I've been in those trenches long enough - build SQL
for Oracle, Sybase, SQLServer, DB2, and having to
tweak statements to make them work across
implementations, and then have switch statements
inside of stored procedures for this that and the other.
But at the end of the day - the end user invokes the
stored procedure - passes in the business values
they want to query on - and gets the results. To them
it should just be an API.
Also - notice we should NOT be trying to solve world
hunger. This is version 1.0 - there is still so much
that is flux around! us - we should be focusing on a
limited simple and clear approach. TRP chose
MIME for these same reasons - its not perfect - but
it can get a job done - not all jobs.
A limited subset of ad hoc querying based on
pre-defined building blocks now appears to
be the best hope for us. Using these set queries
we should aim to answer the obvious business
needs. Why would someone want an adhoc
query anyway? Let's explore this (and BTW -
there are registries out there already with EDI
flavourings - so you can get a feel for this). These
show you that highly focused queries solve
a great deal of the access problems not covered
by drilldown alone, and the overwhelming
detail problem that a simple keyword search
delivers. That's the middle ground we need.
The three business cases that jump out are
business process and transactional, and
then business specific - ie.
1) show me business process entries to do! with
invoicing for blue cross blue shield (this m! ay
well be a menu option off a drill-down interface).
2) show me all element definitions for a
transaction schema foobar (obvious get details
shortcut to save time).
3) show me CPP entries for plumbers in
Cleveland, Ohio (coontent specific querying).
Foul - I hear you crying - we can't possibly
build all those procedures - and yes indeed
we cannot. But if we empower the deployment
staff who understand their industry and their
business needs - then we do not have to.
Reuse is all about this - and the Registry should
leverage reuse for its own purpose.
Exposing a drilldown access path to a Registry
that shows you the available ad hoc query
procedures is a simple and obvious mechanism.
These can be tied to forms to allow users to
point and click and add search values, and they
can be combined to allow smart filtering. Notice
DBA's are very good at all this stuff.
In a ! A2A environment - you can discover these
procedures and access that API set remotely,
(DBA's may choose to limit these procedures
depending on business volume and performance
impacts).
Therefore I am focusing on creating a mechanism
that is NOT tied to anyone query syntax, and
specifically does not allow completely random
ad hoc querying, and does not rely on any
specific implementation tricks with highly specific
lowlevel storage details in XML.
The storage relationships and partitioning should
conform to the information model - that is all we
care to know - and notice that
is also only the level of detail that OASIS have
specified.
OK - enough typing already - I need to get back
to the summary WP, I hope I have painted a
general picture here.
Looking again at the Q&A below - the exact details
of the querying 'how to' with a specific query
technology should not concern us. Experien! ce has
taught me that I can solve any information
ma! nagement problem given the ability to work from
a sound conceptual design. We have the design -
we need to stick with that - and not engage in this
foobar syntax can or cannot do ABC. Implementors
will take whatever steps are needed to solve those
issues - we do not have the bandwidth to solve them
for them - nor should we be trying to anticipate
what problems they may find - becuase we cannot.
What we can specify is the highlevel business
functional API.
I vote for a constrained external ad hoc querying
mechanism based on descrete stored procedures.
Internally developers can use whatever ad hoc
querying syntax they care to.
Thanks, DW.
=============================================
Message text written by Michael RowleyFarrukh and I tried to come up with a procedure-based scheme last Friday
and ran into problems, so that by the time we were out of time, it was
looking dubious.Here's the updated DTD and sample, and
a first cut at a list of RIM Procedures and Groups.
RIM Procedures
o Classification
- getClassifedObjects
Wouldn't you want to be able to get objects that have some specified
classification. Then, the next question is how to specify the
classification. You could do it by a "geography.asia.japan.tokyo" kind
of scheme, but you would probably want to be able to have wild cards for
a level or even for a set of levels.o Association
- getAssociatedObjects
Is the intent here that you are getting the objects that have been
associated with a designated object? Is the designated object the
source or target?
There are many attributes on associations. You may want to get all
associations from a designated source or taget role, or only
associations of a certain type, etc. This gets harry pretty fast.o Package
- get ObjectsByPackage
How would you specify the package. Packages don't have a global
name-space do they?
Wouldn't you also want to be able to get the packages that a specified
object is in?
In general, I believe this approach can work. The number of procedures
will be very large and some will be awkward due to a large number of
parameters that need to be specified.The ebXML Registry Ad Hoc Query Accessing
Pass an XML command container that consists
of:
1) Locator + comparitor + (value | valuelist) = query term(s).
a) Valid Locators:
(i) A tag name (any path context)
(ii) Tag root path (specific path context)
(iii) A supported Registry Procedure name.
(iv) GUID or UID or URN
(v) "*" = match any text (HTML style on content)
This section confuses me. By "tag name" do you mean any XML tag name
(i.e. element name) that exists in the registry? As soon as you doing
things along the lines of querying for XML elements whose contents match
some string, you are practially reinventing XPath.
I would have guessed that if you did not want to use a general purpose
query mechanism (like XPath) that you would not include queries of
arbitrary XML elements in the query language. Instead, I would expect
you to limit the search to the procedures you mention above, possibly
with the addition of unstructured keyword searching.
Michael
<
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC