Coexistence and Migration Scenarios for XDS

1. Coexistence and Migration Scenarios for XDS Roberto Ruggeri XDS.b Editor

2. Conventions Used in This Presentation • “Actor(x)” supports XDS.x • Sample: Consumer(a) is a Document Consumer that only supports XDS.a • “Actor(~x)” does NOT supports XDS.x • “Actor(x,y)” supports XDS.x and XDS.y • Example: Registry(a,b) is a Document Registry that supports both XDS.a and XDS.b • “Actor” has non-stated and irrelevant support for either XDS.a, XDS.b or both • “(x)” stands for both a or b, but not both

3. Mixed Registry Scenarios Document Registry Document Source Document Repository Document Registry Document Consumer • Repository(a) talking to Registry(a,b) • Repository does not populate repositoryUniqueId, Registry returns the document metadata without the repositoryUniqueId attribute, Consumer(b) cannot retrieve the document via Web Services from Repository • Repository(b) talking to Registry(a,b) • Repository does not support HTTP interface and does not populate URI attribute, Registry returns the document metadata without the URI attribute, Consumer(a) cannot retrieve the document via HTTP • In this case Consumer is limited to be of the same type of Repository

4. Mixed Repository Scenarios Document Source Document Repository Document Consumer Document Source Document Repository Document Registry Document Consumer • Repository(a,b) talking to Registry(a) • Repository correctly populates both the repositoryUniqueId and URI attributes, Registry stores both attributes and returns them in the document metadata, Consumer(a,b) can retrieve the document via Web Services or HTTP • Repository(a,b) talking to Registry(b) • Same as above, just in this case the Registry will store and understand both • In this scenario Consumer can be both (a,b), as long as the Registry(a) stores the entire document metadata • No issues if Registry(b)

5. Migration Scenarios • Migrate from XDS.a to XDS.b to introduce Consumer(b) and Source(b) • Migrate from Registry(a) to Registry(a,b) • Migrate Repository(a) to Repository(a,b) • ISSUE: Registry(a) does not have Metadata(b), will have to get it from the Repository(b) once upgraded from Repository(a) • Repository(a,b) and Registry(a,b) will continue to exist until all Consumer(a) and Source(a) are present or bridging scenarios are implemented • Deploy Registry(b) and Repository(b) with legacy Consumer(a) and Source(a) • Add text here

6. Bridging ScenariosRegistry(b) in (a) Environment • Bridge needs to hold a translation map between Repository(a) and repositoryUniqueId. That can be inferred from the certificate of the calling Repository(a) per ATNA requirements • RegistryStoredQuery(a) • Input is passed to Registry(b) with no changes • Output metadata is returned to Consumer(a) with no changes as it already contains the URI attribute populated by Repository(a) • RegisterDocumentSet(a) • Input metadata will have to be enhanced with repositoryUniqueId based on the calling Repository(a). • Output is routed to Repository(a) with no changes

7. Bridging ScenariosRegistry(a) in (b) Environment • Bridge needs to store the repositoryUniqueId and its mapping to documentUniqueId as Registry(a) is not required to store that value • RegistryStoredQuery(b) • Input is passed to Registry(a) with no changes • Output metadata needs to be enhanced with the repositoryUniqueId based on the documentUniqueId • RegisterDocumentSet(b) • Input is passed to Registry(a) with no changes • Output is passed to Repository(b) with no changes

8. Bridging Scenarios • Repository(x) in (~x) environment • Consumer(x) in (~x) environment • Source(x) in (~x) environment

9. Thank You!