B2B & RegRep & 05 doc.

[David RR Webber <Gnosis_@compuserve.com>]

Although this is not required for the Tokyo PoC I would like
to make sure that we include functionality, at least in the 
high level diagrams for the B2B process actor and 
'support runtime view'.

Clearly B2B processes are going to be the largest single
consumer of Registry Services - so we need to reflect that
in the emphasis - so that they should be at the TOP of the
diagrams, with the human actors underneath.

This is clearly the UDDI focus too.

What is the impact?

Since we know from the EDI / BSR work that once an object
reaches 'approved' status, then 90%+ never change thereafter.

That means we need an Interface Service added to diagram
Figure 2 that is a queryObjectHistory(), and the reply in a
provideObjectHistory.

Essentially this then supports local caching.  If the registry
tells me that it has not changed, or the parent and related items,
or a specific object within, has not changed since my last query, 
then I can simply go with my locally cached copy.  Thereby 
saving having to issue any further queries to the registry.

This functionality is going to be the backbone of the distributed
registry model and is a key piece that UDDI is also seeking.

Therefore as we head into Tokyo my suggestion is that we
make it clear that this is included in our scope and show 
initial planning - and obviously once we are clear of the Tokyo
specification items - then we can focus on this and related
pieces.

Thanks, DW.