This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/discussion/do/listPosts/projects.ggf-editor/discussion.rec_ws_naming_specification.topc4021 at Thu, 03 Nov 2022 23:21:15 GMT SourceForge : Post

Project Home

Tracker

Documents

Tasks

Source Code

Discussions

File Releases

Wiki

Project Admin
Project: Editor     Discussion > REC:WS-Naming Specification > Current Specification Assumes Single Address Targets > List of Posts
Forum Topic - Current Specification Assumes Single Address Targets: (2 Items)
View:  as 
 
 
Current Specification Assumes Single Address Targets
The current specification declares two port types for resolving location independent information to location dependent 
addressing.  In pseudo-code, these two interfaces are essentially

EndpointReferenceType resolveEPI (EndpointIdentifier: IRI) throws ResolveFailedFault;
EndpointReferenceType resolve () throws ResolveFailedFault;

Unfortunately, by virtue of the fact that these two resolution operations both return a single EPR, the specification 
assumes/implies that all endpoints have exactly one address.  However, this may not be the case.  It may be relevant for
 a web server to host web services on multiple ports or at multiple paths, or even at multiple host names to allow for 
various clients to contact it from various networks.  Perhaps some addresses are only accessible from behind a NAT while
 other addresses are public, but slower.  Also, maybe multiple protocols are supported.  Perhaps the resource can 
support both HTTP with message level encryption, and HTTPS without message level encryption.  Finally, there may be 
proprietary protocols that are much more efficient for local resources and clients, but not as globally recognized as 
SOAP over HTTP.  Resources may choose to support both in order to provide efficient communication for clients that 
implement the more advanced protocol while still allowing interoperable implementations to communication through more 
standard means.  Because of these things, I would rather see these operations changed to the following pseudo-
declarations:

EndpointReferenceType[] resolveEPI (EndpointIdentifier: IRI) throws ResolveFailedFault;
EndpointReferenceType[] resolve () throws ResolveFailedFault;
Re: Current Specification Assumes Single Address Targets
To my recolection this was discussed at a number of meeting/calls. The proposal is therefore an important one, but on 
that was not acted 0n by the WG earlier in the process.

Some rational:

1) There is no assumption that each resource has only one address.

2) However, this specification aims at being as simple as possible, hence the single EPR approach.

3) There were serious concerns with the meaning of multiple EPRs in a return response. Which one is preferred? Is there 
an implicit ranking? What if there are thousands on possible addessses? How do we restrict the answers that we get back?
 etc.

4) There is a mechanism to include enough information in the returned EPR to tell the resolver that should the client 
ask again, a duplicate of the previous one would not be provided.

In short, the current formulation meets all the use cases without imposing extra complexity on the implementation of 
either service of client.

I propose that we take no action wrt this Public Comment.

 
 


The Open Grid Forum Contact Webmaster | Report a problem | GridForge Help
This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/discussion/do/listPosts/projects.ggf-editor/discussion.rec_ws_naming_specification.topc4021 at Thu, 03 Nov 2022 23:21:16 GMT