Subject: RE: Distributed Registry Proposal Approach
Joel,
I agree with you, and the current UDDI interface at this point in time. The
pragmatics of truncation at this point make sense until all of this is
commercially proven and solid, and then further thinking should take place
on iteration semantics with state-holding and timeout, etc, if it shows to
be needed.
Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074
"Munter, Joel D" <joel.d.munter@intel.com> on 03/30/2001 11:48:37 AM
To: ebxml-regrep@lists.ebxml.org
cc:
Subject: RE: Distributed Registry Proposal Approach
Darach, et al
The following two definitions are from the UDDI V1 API Programmers'
Reference Manual:
· maxRows: This special qualifier is found in the inquiry API
functions that are used to search (e.g. find_binding, find_business,
find_service, find_tModel). This argument is used to limit the number of
results returned from a request. When an Operator Site or compatible
instance returns data in response to a request that contains this limiting
argument, the number of results will not exceed the integer value passed.
If a result set is truncated as a result of applying this limit, the result
will include the truncated attribute with a value of true.
· truncated: The truncated attribute indicates that a maximum number
of possible results has been returned. The actual limit set for applying
this treatment is Operator Site policy specific, but in general should be a
sufficiently large number so as to not normally be an issue. No behaviors
such as paging mechanisms are defined for retrieving more data after a
truncated limit. The intent is to support the average query, but to allow
Operator Sites the leeway required to be able to manage adequate
performance.
I cannot speak from total certainty regrading their origins, as I joined
the
UDDI effort in October, but the truncated and maxRows values are the result
of practical considerations. The key phrase in the specification exerpt
above is "...should be a sufficiently large number so as to not be an
issue..." This to to protect a UDDI Operator from having to deliver an XML
response that is the in the high 100 thousands to millions of "records".
My
personal opinion is that practical considerations are critical to the
success of real business registries.
Recall that maxRows is a value that you can input to your UDDI query and as
stated above the [truncate] limit is something that a particular Operator
sets as Policy. If you have suggestions on a suitable Operator Policy
truncate limit value, please forward it.
Thanks,
Joel Munter
Intel Corporation
UDDI V2 Replication and Scalability Team Lead (and sometime lurker on
reg/rep)
-----Original Message-----
From: Darach Ennis [mailto:darach.ennis@iona.com]
Sent: Friday, March 30, 2001 9:25 AM
To: rawlins@metronet.com; ebxml-regrep@lists.ebxml.org
Subject: Re: Distributed Registry Proposal Approach
Hullo Mike, all.
Good point well made. As i've only relatively decloaked and unlurked
on this list I probably wouldn't have said it. Excellent usage of
our friend the asterisk too :)
It seems the potential requirements, so far on this discussion
involve:
1) Distributed
2) Registry group(s) and CRUD roles
* is reg-reg client access different, or plain old client?
3) Publish / Subscribe
4) Bulk and incremental replication
5) Suit both Sync and Async by design
6) QOS, Timeouts, Request/Response size Maxima/Minima
* I dont like the truncation in UDDI v1. Would have been
fine if it offerred batching the response instead of,
"sorry, truncated your response mate, try altering your
search criteria for a better honed search...". I dont
mind the limits, its the 'what if it is the best honed
search' case I worry about!
7.a) Data integrity: Object uniqueness, unique registry reference
7.b) Data integrity: Security! Security! Security
8) Distributed Query Mechanism with option to disable on a
per request basis. Search categorization (intensive, extensive,
local, distributed etc..) and context (drill-down, final etc..)
9) Load balancing?
10) and no doubt others...
I guess if we came up with approaches for fulfilling any potential
requirements, use-cases, or if not wanted an argument for not including
support for it then we're already on our way to somewhere :)
Is mise le meas,
Darach.
At 09:22 AM 3/30/01 -0600, Mike Rawlins wrote:
>I sometimes feel a bit silly and pedantic for always getting back to
>basics. However, even more than that I am amazed how often it seems
>appropriate. I'm sure that you all have much more experience and
>expertise in the registry area than I. However, I nonetheless offer a
>few observations and suggestions before I leave this problem in your
>capable hands.
>
>Observation 1: This is not a new problem. The distributed registry
>problem is essentially a special case of the well-known distributed
>database problem.
>
>Suggestion 1: Don't reinvent the wheel. Several proven approaches
>already exist. Pick one.
>
>Observation 2: Without a set of constraints (non-functional
>requirements) and their relative priorities there is no basis for
>picking one approach over another.
>
>Suggestion 2: Achieve consensus on constraints before even considering
>an approach. None of your documents to date address constraints and
>relative importance such as response time, integrity, etc. A few have
>been mentioned in this discussion, and there are several in the ebXML
>Requirements Spec. Decide *what* you need first, then decide *how* to
>do it.
>
>Observation 3: You need to do no homework to know that your highest
>priority constraint now is time. [Scott, you want to remind your team
>what the drop dead date is?] Opinion: You have barely enough time to
>agree on an overall approach for a fully distributed, transparent
>network of registries, not to mention fully flesh it out.
>
>Suggestion 3: Go for a two phase approach: Phase one as a
>registry/directory/list of registries using best available technology,
>completed within the time constraints; Phase two as the fully
>distributed network of registries.
>
>Proposal: For phase 1 use UDDI as the registry of registries (I am even
>more amazed to find myself agreeing with Klaus!). This, to me, has the
>best chance of satisfying your highest priority constraint. It also has
>marketing/mindshare advantages which, while they aren't strictly
>speaking technical constraints, certainly are important.
>
>Y'all have fun.
>
>--
>Michael C. Rawlins, Rawlins EC Consulting
>http://www.metronet.com/~rawlins/
>
>
>
>------------------------------------------------------------------
>To unsubscribe from this elist send a message with the single word
>"unsubscribe" in the body to: ebxml-regrep-request@lists.ebxml.org
>
>
------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-regrep-request@lists.ebxml.org
------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-regrep-request@lists.ebxml.org
Powered by
eList eXpress LLC