[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: &lt;None&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