Re: A DBA perspective.

[Farrukh Najmi <Farrukh.Najmi@east.sun.com>]

I want to point out that stored procedures are an implementation detail. IN
contrast the methods defined in RIM 0.54 (
http://lists.ebxml.org/archives/ebxml-regrep/200101/msg00086.html )

used by the OQL approach are elements of registry specifications. It should
be noted that the constrained OQL approach could be implemented to map the
speced relationship methods in RIM to stored procedures directly (as an
implementation choice). In my own implementation I personally would stay
clear of stored procedures based on a very long history of having
implemented database engines as well as query processors. They are a
maintainenec nightmare and are not implemented in a standard way across DBMS
(one loses DB portability).

I would instead choose to define methods on implementations of objects (e.g.
ManagedObjectImpl) defined by RIM to return a SQL query as a direct and
simple mapping of the relationship method. The OQL processor would call
these methods to resolve these methods calls to their equivalent SQL
queries. It would then apply any simple global optimization over the query
predicate and then simply pass the resulting SQL query to the relational
database.

The key difference in the 2 approaches being debated is that the constrained
OQL approach is based on standards (SQL, OQL) and is familiar to use for
most implementors, while the custom XML qyery syntax is a home brewed query
language syntax that does not have the strength of years of experience,
review and expert contribution that the former approach does.

--
Regards,
Farrukh


David RR Webber wrote:

> 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 whatever 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 believe we do need to listen to
> the DBA world - and that stored 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 may
>      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.   Experience has
> taught me that I can solve any information
> management 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 Rowley
> >
> Farrukh 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
>
> <


begin:vcard 
n:Najmi;Farrukh
tel;work:781-442-0703
x-mozilla-html:FALSE
url:www.sun.com
org:Sun Microsystems;Java Software
adr:;;1 Network Dr. MS BUR02-302;Burlington;MA;01803-0902;USA
version:2.1
email;internet:najmi@east.sun.com
fn:Farrukh Najmi
end:vcard