[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: B2B & RegRep & 05 doc.
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.
Powered by eList eXpress LLC