Presentation is loading. Please wait.

Presentation is loading. Please wait.

RNS Experiences UVA Genesis II Group. Contents High Level Reaction Specific constructive criticisms Recommended Changes XML/UML for proposed changes.

Similar presentations


Presentation on theme: "RNS Experiences UVA Genesis II Group. Contents High Level Reaction Specific constructive criticisms Recommended Changes XML/UML for proposed changes."— Presentation transcript:

1 RNS Experiences UVA Genesis II Group

2 Contents High Level Reaction Specific constructive criticisms Recommended Changes XML/UML for proposed changes

3 High level Basic idea of RNS is very good – great mechanism for human friendly naming scheme for Web Service endpoints –We have an extensive RNS/ByteIO infrastructure that includes the OGSA-BP, OGSA-BSP 2.0, WS-Naming, WS-Secure Addressing, WS-Secure Communication, and a set of client tools to use them. Few problems around the edges Recommend re-factoring a RNS 2.0

4 Constructive Criticisms Notion of junctions is unnecessary and confusing – RNS_entries are sufficient, i.e., an extensible document containing at least the target EPR and a entry_name (human readable string). Query operation makes no sense – query is on junctions – yet no way to get EPR of junction unless you hold onto it. Move() implies atomicity which is difficult at best to ensure if target location differs from source – perhaps rename is a better choice. List() returns lists can easily be extremely large – some sort of iterator is needed in real environments with directories with tens of thousands of entries. People we know are more familiar with file patterns that regular expressions, e.g., fred*.txt rather than fred.*\.txt – we found it better to let the client do pattern matching. (also consider fred.txt, what does it mean?). First two are the most important!

5 Recommended Changes Eliminate junctions (and query) Introduce an iterator – we examined WS- Enumeration and it does not fit well with the other OGF specs we have seen Change move to rename – which only permits renames in a target RNS endpoint Modify both remove and list to take exact strings or NULL (i.e., no regular expressions)

6 RNS UML/XML RNS Port Type createtime: dateTime ? modtime: dateTime ? accesstime: dateTime ? entry-count: unsignedLong add(entryName: String ?, entryEndpoint: EPR ?): RNSEntry remove(entryName: String): RNSEntry rename(oldEntryName: String, newEntryName: String): RNSEntry lookup(entryName: String ?): LookupResults wsa:EndpointReferenceType xsd:any * Either an exact match, or, if the parameter is absent, list all entries. No Regular Expressions!

7 RNS UML/XML cont. RNSEntry * ? wsa:EndpointReferenceType ? WSIterable Port Type entry-count: unsignedLong nextBatch(start: unsignedLong, max-count: unsignedLong): BatchResults xsd:any * Notice that both the concrete results and the iterable are optional. This covers the cases of no entries, and combinations of pre-fetched entries along with iterable entries. Also note that iterable type not restricted to RNS entries.


Download ppt "RNS Experiences UVA Genesis II Group. Contents High Level Reaction Specific constructive criticisms Recommended Changes XML/UML for proposed changes."

Similar presentations


Ads by Google