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

Frank Siebenlist franks at mcs.anl.gov
Tue Feb 15 12:56:22 CST 2005 

One other thing that is missing is the resource-typing information in 
the resolver-EPRs.

The normal EPRs are enhanced with wsdl-information about the 
webservice-resource.

A resolver-EPR is essentially a handle, an indirection to the resource, 
and it will only hold the wsdl-info about that resolver-resource.

It would be useful to augment a resolver-EPR with the typing information 
of the resource such that program/tooling can anticipate the kind of EPR 
returned. (The reasons are very similar to why the EPR is decorated with 
the the interfacename&servicename.)

Maybe an (optional) "ReferencedInterfaceName" element could be used in 
the extensible section of the EndPointReference or in the Policy (?).

-Frank.

Frank Siebenlist wrote:

> 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

More information about the ogsa-wg mailing list