RE: [Fwd: RE: on the issue of PartyId]

[Henry Lowe <hlowe@omg.org>]

DW,

Glad there's someone other than me worrying about efficiency.
However, I would suggest that there's no such thing as a "very 
high performance query" -- the number of messages sent is the 
same for a query as for a fetch and the number of disk accesses 
is probably identical (today's transmission speed say that the 
few extra bytes sent don't count for much).  The big things for 
efficiency are (a) number of messages, (b) disk access time, and 
(c) contect switches.

Your 90+% sounds about right (if not a bit low), but you're getting 
into caching policy which I don't know much about.  Who keeps the 
cache -- app or service provider?  Who decides the policy, ebXML 
for a standardized policy, vendor/implementors, app's themselves?
How often and when is refresh done -- on demand or during idle time?
Host of questions (and headaches unless we throw it over the wall ;-)

Best regards,
Henry
----------------------------
At 01:02 PM 09/22/2000 -0400, you wrote:
>Message text written by Henry Lowe
>>For effiency reasons, you don't want to force all TRP MS message 
>sent to include an access to a respository -- if you do, ebXML 
>will be a PIG and we will be just another footnote in IT history.
>Bandwidth is cheap, but remote accesses ain't!!
>
>Best regards,
>Henry<
>
>>>>>>>>>>>>>
>
>Henry,
>
>I raised this issue this week in RegRep - the ability to
>locally cache and to have a very high performance query
>to check if content has changed since last query.
>
>Clearly machine-2-machine accesses to the registry
>will be 99% of what is does - and we know from earlier
>registries that 90%+ of content never changes once it
>reaches 'approved' status. 
>
>This then also leads into distributed registries too, but
>that's definately RegReps bag to sort out....
>
>DW.