This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/sfmain/do/go/artf5303?nav=1&selectedTab=comments at Sun, 06 Nov 2022 09:03:10 GMT SourceForge : artf5303: (1231) ENDPOINTREFERENCE resilientReference element definition

Project Home

Tracker

Documents

Tasks

Source Code

Discussions

File Releases

Wiki

Project Admin

Glance

Calendar
Search Tracker
Project: OGSA-WG     Trackers > WSRF Basic Profile > View Artifact
Artifact artf5303 : (1231) ENDPOINTREFERENCE resilientReference element definition
Tracker: WSRF Basic Profile
Title: (1231) ENDPOINTREFERENCE resilientReference element definition
Description:
section 3.1.5.  Need to define the schema for normative description of resilientReference..
Submitted By: Tom Maguire
Submitted On: 01/28/2005 2:01 PM EST
Last Modified: 06/30/2008 10:48 PM EDT
Closed: 06/13/2005 6:02 AM EST

Status / Comments Change Log Associations Attachments  
Status  
Group: *
Status:* Closed
Category: * Version 1.0
Customer: *
Priority: * 2
Assigned To: * Mark Morgan
Reported in Release: *
Fixed in Release: *
Estimated Hours: * 0
Actual Hours: * 0
Comments
Andreas Savva: 06/30/2008 10:48 PM EDT
  Comment:
Assigned category due to minor expected tweaks as a result of the experience document
  Action: Update
Category set to Version 1.0
Andreas Savva: 06/13/2005 6:02 AM EST
  Comment:
Confirmed in draft 18 (gridforge draft 12) that the resilient references section has been deleted.
  Action: Update
Andreas Savva: 06/13/2005 6:02 AM EST
  Action: Update
artifact_status changed from Fixed to Closed
close_date changed from - to 2005-06-13 20:02:20
Tom Maguire: 06/06/2005 4:07 PM EST
  Comment:
fixed in v015
  Action: Update
Tom Maguire: 06/06/2005 4:07 PM EST
  Action: Update
artifact_status changed from Resolved to Fixed
Hiro Kishimoto: 05/23/2005 11:06 AM EST
  Comment:
at F2F meeting, ogsa-wg agree to take renewable reference from basic profile and put it in nameing spec. given that naming spec de-couple from 
abstract name.
  Action: Update
Hiro Kishimoto: 05/23/2005 11:06 AM EST
  Action: Update
artifact_status changed from Pending to Resolved
Hiro Kishimoto: 05/23/2005 10:56 AM EST
  Comment:
we really want to keep one mechanism for resolution.
at the same time, de-couple abstract name from re-binding.
  Action: Update
Hiro Kishimoto: 05/23/2005 10:56 AM EST
  Action: Update
artifact_status changed from Resolved to Pending
assigned_to changed from 100 to 6496
Tom Maguire: 04/20/2005 2:08 PM EST
  Action: Update
artifact_status changed from Pending to Resolved
Tom Maguire: 03/07/2005 8:31 PM EST
  Comment:
Move to OGSA Naming Profile
  Action: Update
Tom Maguire: 03/07/2005 8:28 PM EST
  Action: Update
artifact_status changed from Closed to Pending
SourceForge Administrator: 03/03/2005 4:30 AM EST
  Comment:
Pending expire
  Action: Update
artifact_status changed from Pending to Closed
close_date changed from - to 2005-03-03 03:30:05
Tom Maguire: 03/02/2005 8:46 PM EST
  Comment:
NOTE: To be moved to OGSA Naming Profile
  Action: Update
Tom Maguire: 03/02/2005 8:46 PM EST
  Action: Update
artifact_status changed from Open to Pending
Andreas Savva: 02/24/2005 3:19 AM EST
  Comment:
[Another comment from Frank; posted to the ogsa-wg ml]
 
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.
  Action: Update
Andreas Savva: 02/24/2005 3:17 AM EST
  Comment:
[From Frank Siebenlist; posted on ogsa-wg-ml]

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.
  Action: Update
Tom Maguire: 02/14/2005 12:43 PM EST
  Comment:
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>
  Action: Update
Tom Maguire: 02/14/2005 11:00 AM EST
  Action: Update
Priority changed from - to 2
Tom Maguire: 01/28/2005 2:01 PM EST
  Action: Create


 
 
 
< Previous
 
 
Next >
 


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/sfmain/do/go/artf5303?nav=1&selectedTab=comments at Sun, 06 Nov 2022 09:03:10 GMT