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

[Sourceforge Tracker Monitor]

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)