[ogsa-wg] [ogsa-wg | Basic Profile - 1231] ENDPOINTREFERENCE resilientReference element definition

[Frank Siebenlist]

It's good to see those renewable/resilient/stable reference elements 
back in focus.

I believe there are two use cases that could be considered:

1. A resolver service has been identified but has not been used yet to 
register. The idea is that a service may only have to register an EPR 
with the resolver service after there is a need for it, like when the 
resource is rebound to a new endpoint. The registration is not needed 
before that time. So, a "stateless" service where we would pass the old 
EPR and would get a new EPR.

2. A resolving resource has been registered with the resolver service, 
and the most current EPR for our resource can be retrieved directly from 
the resolver. So, an EPR to a "statefull" webservice resource that would 
hold the new EPR.


The two cases would have resolver-EPRs of different porttypes associated 
with them:

The first one would have an EPR pointing at a resolver service that 
would expect a input message parameter that would identify the resource, 
and would return that resource's most current EPR (or fail if nothing 
has been registered yet).

The second porttype wouldn't need an inputmessage parameter as the 
resource identifier will be embedded "somehow" in the resolver's 
resource EPR, and would return the most current EPR.

Note that any "new" EPR returned from a stateless resolver could/should 
be an EPR to a resolver-resource.

What is unclear is the parameter-value that should be used to identify 
the resource. Can that simply be the address value now that the resource 
references are ousted?

Regards, Frank.






Sourceforge Tracker Monitor wrote:

>Tom Maguire changed 1231 on 2005-02-14 12:43:21
>
>
>
>Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1231&group_id=42 (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1231&group_id=42)
>
>Summary: ENDPOINTREFERENCE resilientReference element definition
>Project: Open Grid Services Architecture
>Tracker: Basic Profile
>Artifact ID: 1231
>Category: <None>
>Group: <None>
>Status: Open
>Priority: 2
>Last Modified By: Tom Maguire
>Last Modified: 2005-02-14 12:43:21
>Submitted By: Tom Maguire
>Submit Date: 2005-01-28 14:01:04
>Assigned To: &amp;lt;None&amp;gt;
>File(s): <None>
>Description: 
>section 3.1.5.  Need to define the schema for normative description of resilientReference.
>----------------------------------------------------------------------
>Comment By: Tom Maguire (2005-02-14 12:43:21)
>reliable endpoints are a basic necessity
>and that they are of such a key importance, that their placement in as low a
>level "profile" as possible is good.  Ideally, we'd like to see it in
>WS-Addressing itself.
>
>The logical choice (and the one we all came up with individually) was to
>start placing information into the extensibility elements of the
>WS-Addressing Endpoint Reference.  The specifics aren't important in
>general, but the idea was to have another EPR sitting inside one of these
>extensibility elements which could then be used (in the case of failure to
>communicate with a given endpoint) to re-bind to the endpoint.  In
>othrwords, if I try to communicate with EPR alpha, and I fail for some
>reason to reach him/her, then I can look for this extensibility element
>inside of EPR alpha's EPR which will in turn be another EPR that I should be
>able to go to and ask for a "new" binding to EPR alpha.
>
>The parts that we disucussed which weren't quite so identical were:
>		 a) That this extensibility element could have 0..unbounded EPR's
>inside of it
>		 b) That the abstract name would be part of it.
>
>A) I think is fine either way as long as you can have 0 or 1.  Andrew and I
>would tend to think that 0..unbounded gives you the most flexibility while
>not complicating a client's code unnecessarily.  If the service provider
>doesn't want to use more then 1 EPR for re-binds, then he doesn't have to.
>0 is important to "bottom" out the chain of binding agents.
>
>B) Is perhaps the more interesting thing to discuss.  The naming group has
>come up with a number of requirements for abstract names that include:
>		 * Globally Unique in time and space
>		 * Easy (and cheap) to compare one abstract name against another for
>equality.
>		 * Persistent for the entire lifetime of the endpoint to which it
>refers.
>Based on this, Andrew and I want to make it a first class entity as much as
>possible.  Making sure that the thing is easily comparable is very
>important.
>
>To be more concrete, ignoring XML syntax errors and my use of random and
>incorrect qnames, here is more or less what we were thinking an example EPR
>should look like....
>
><EPR>
>		 <Address>http://some-machine.org/some-path</Address>
>		 <ReferenceProperties>Whatever you want here</ReferenceProperties>
>		 <ExtensibilityPolicyWhatHaveYou>
>		 		 <OGSA-Bind-Info>
>		 
><AbstractName>509733A3-7850-4cb9-AB54-F1B83078F1B4</AbstractName>
>		 		 		 <RebindAgent>
>		 		 		 		 // some other EPR
>		 		 		 </RebindAgent>
>		 		 </OGSA-Bind-Info>
>		 </ExtensibilityPolicyWhatHaveYou>
></EPR>
>----------------------------------------------------------------------
>
>
>View the Basic Profile : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=780 (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=780)
>
>  
>

-- 
Frank Siebenlist               franks at mcs.anl.gov
The Globus Alliance - Argonne National Laboratory