This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/go/artf3310?nav=1 at Sun, 06 Nov 2022 04:26:43 GMT SourceForge : artf3310: (639) Should we use WS-Context in WSRF?

Project Home

Tracker

Documents

Tasks

Source Code

Discussions

File Releases

Wiki

Project Admin
Search Tracker
Project: OGSI-WG     Trackers > WS Resource Framework > View Artifact
Artifact artf3310 : (639) Should we use WS-Context in WSRF?
Tracker: WS Resource Framework
Title: (639) Should we use WS-Context in WSRF?
Description:
The similarity of WS-Context machanisms to those of Resource Properties raises the obvious question of using WS-Contect 
to carry Resource Idenity. .
Submitted By: David Snelling
Submitted On: 01/26/2004 5:53 AM EST
Last Modified: 05/21/2004 5:52 AM EST
Closed: 05/21/2004 5:52 AM EST

Status / Comments Change Log Associations Attachments  
Status  
Group: *
Status:* Closed
Category: *
Customer: *
Priority: * 0
Assigned To: * None
Reported in Release: *
Fixed in Release: *
Estimated Hours: * 0
Actual Hours: * 0
issue_type: * Feature request
Comments
David Snelling: 05/21/2004 5:52 AM EST
  Comment:
OOPS Forgot to close it.

This was picked up by the WSRF TC and will be delt with there. I close it 
here.
  Action: Update
David Snelling: 05/21/2004 5:52 AM EST
  Action: Update
artifact_status changed from Open to Closed
close_date changed from - to 2004-05-21 11:52:26
David Snelling: 05/21/2004 5:51 AM EST
  Comment:
This was picked up by the WSRF TC and will be delt with there. I close it here.
  Action: Update
David Snelling: 01/26/2004 6:03 AM EST
  Comment:
In reply:

Hey Jeff.

Aren't both ways of doing message correlation? What the service does
with regards to the message correlation is up to the service. If the
message decides that the correlated messages will refer to a particular
resource, that's up to the message. That begs the question why come up
with yet another way of doing message correlation, especially when the
WS-Context approach is scalable to multiple participants.

Regards,
--
Savas Parastatidis
----------------------------------------

This should provide enough of a perspective to open this issue formally later. I won't post more here, unless something really interesting comes up. -
 Dave Snelling

----------------------------------------
  Action: Update
David Snelling: 01/26/2004 5:56 AM EST
  Comment:
From Jeff Fry:

I agree with Ian. There is a subtle but important distinction. Context, as
referred to in WS-Context, is explicitly declared and meant to facilitate
an interoperable understanding between the client and the service. For
example, a transactional unit of work is something that can be established
by the client and sent to the service in a well known context that
accompanies the message to the web service. The same is true for contexts
that represent security function, etc. This is not the same as what we have
introduced with the WS-Resource. There is no need to declare the
WS-Resource context for interoperability reasons. The WS-Resource "context"
is not produced by the client. It is produced and consumed by the service.
It is carried in the EPR as an opaque construct to the client. There is no
need for the client to interpret or inspect the contents of the reference
properties. In fact, there is no additional "context" handler required at
all on the client side of the interaction other than what is already
generically specified in the WS-Addressing specification. So, while I can
understand that this appears to be the same at an abstract level of
understanding, we did not intend the identity of the resource as it is
treated in the EPR to be interpreted as "context" in the same way other
usage context is produced and consumed across the web service interaction
with the client.

In addition, while we know some have an aversion to the treatment of the
stateful resource as a "first class" addressable entity or as the implied
target of the interaction from the client., some do not. And if your view
is that the resource is the "target" of the message interchange from the
client the service, our view is that it should be treated as distinct from
other execution contexts which exist not for the purpose of identifying the
target of the message exchange, but to provide additional control over how
the target of the message exchange is to be treated. WS-Context should be
used to facilitate the contextual usage of the target of the message, not
the target of the message itself.

Jeffrey Frey
  Action: Update
David Snelling: 01/26/2004 5:53 AM 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/go/artf3310?nav=1 at Sun, 06 Nov 2022 04:26:47 GMT