RE: Issue i0001 - Clarification of "identifier"

Steve,

 

I want to fully understand this scenario, so please let me know where I
have not accurately reflected understand of your scenario.

 

AIUI, you want to use ResourceID in the same sense that WSDL had been
talking about the "targetResource", that is an identifier for something
behind the interface that is equivalent across interfaces.  

 

The reason you want ResourceId is so that your company software can
determine which resource to do the interface operations on, roughly it's
the object identifier.

 

The reason you want XML for resourceIds is so that you can have XML
processing software do the determination.

 

To a certain extent, the resourceId is an implicit argument to all the
operations in your organization.  It adds a second object identifier to
each operation.  Instead of object.operation(arguments), you roughly
want address.operation(resourceId, arguments).

 

In your context, the resource that is being identified has nothing to do
with the "address" field in the EPR, it is up to your implementation of
RefPs.  In this case, a single ResourceId refP is the identifier.  But
nobody outside the scope of your organization knows that.

 

To try to do this in a "URI-centric" manner - I specifically do not use
RESTful because I'm not talking about a constrained verb set - you would
need to make the ResourceId available that supports a single identifier
and then the various operations.  Ie, resourceid.operation.  The reason
why this isn't that great from your perspective is 2-fold: 1) to offer
multiple protocol support to the same resource (which isn't mentioned by
your note); 2) to offer multiple interfaces to the same resource with
separate address spaces (your rationale).  In particular, having 2
separate address spaces enables you to manage and deploy your services
in a clean manner.  Comparing the 2 scenarios where a service is
deployed, then another service is added with a separate ACL.

 

RefP-centric

Service A with interface A(notification) deployed, ResId SGG deployed at
runtime to differentiate.  Security is done based upon the service, ie
notification has a particular acl

Service B with interface B(mgmt) deployed, same resId.  Security is
different for B than A.

 

URI-centric

Service A with interface A(notification) is deployed, ResId embedded in
Uri.  Security is based upon subset of URI + operation.

Service A is augmented with with interface B, ResId also embedded in
URI.  Security ACL is augmented with interface B operations.

 

The key difference from a security perspective is that the RefP centric
solution allows security to be on all operations at a given address,
whereas URI-centric requires the interface/operation to be included in
any ACL.  From a software perspective, it is easier to deploy
notification software at A/notification and mgmt software at A/mgmt than
to deploy 2 different interfaces at A.  

 

The above scenario is much more complicated by the multi-protocol
scenario, where there may be many different Address+RefP sets that are
to the same Resource.  

 

It is extremely important to observe that the Reference Properties are
NOT compared by clients for determining equivalence, this is only for
the context of your organization.  There is no scenario in your case
where a client would do something different if it had the same
RefProperty.  There is no "If (refp1==refp2) then {do stuff;} else {do
other stuff;}" scenario at the client.  To say again, there is no
context on the client in which it would do a compare (epr1, epr2).

 

Further, it is up to other protocols to specify what a client should do
with RefPs that are different.  For example, some hypothetical
WS-MultiProtocol-Callback spec that offered a variety of EPRs for
ReplyTos that were equivalent yet different protocols, would have to
specify what a receiver would do with the different EPRs and the
equivalence rules.

 

Dave

 

 

 

  _____  

From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Steve Graham
Sent: Tuesday, December 14, 2004 10:59 AM
To: Srinivas, Davanum M
Cc: David Booth; public-ws-addressing@w3.org;
public-ws-addressing-request@w3.org
Subject: RE: Issue i0001 - Clarification of "identifier"

 


I believe it is true that for any "identifier" its usefulness to
determine "sameness" or difference between two resource instances must
be done in some context.  For example, all the resources in my company
(ie behind my company's firewall) may use the same value set for
<muws-xs-1:ResourceId/> of the resources exposed.  Therefore the
interpretation of <muws-xs-1:ResourceId/> used in EPRs referencing my
company's resources must be done in the context of my companies
services.  Note, however, that the resourceID is not specific to a
particular address.  Consider, for example, I have one resource,
identified by <muws-xs-1:ResourceId>sggRes1</muws-xs-1:ResourceId>.
Consider also that I have two Web services that can act upon that type
of resource.  WS1 provides base manageability characteristics (such as
state property retrieval), and one Web service provides notification
capabilities.  These two Web services may be deployed at different
endpoint addresses (value of wsa:Address in EPR is different), but each
EPR may have the exact same value for <muws-xs-1:ResourceId/>.  In this
case, the ResourceID is not specific to an address, but rather it is
specific to another context, that being "my organization". 

Does this help? 

sgg
++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++




"Srinivas, Davanum M" <Davanum.Srinivas@ca.com> 

12/14/2004 01:04 PM 

To

Steve Graham/Raleigh/IBM@IBMUS 

cc

"David Booth" <dbooth@w3.org>, <public-ws-addressing@w3.org>,
<public-ws-addressing-request@w3.org> 

Subject

RE: Issue i0001 - Clarification of "identifier"

 

 

 




ResourceId is specific to an "Address". right? don't u need both to be
able to converse with the resource? 
  
thanks, 
-- dims 

  _____  

From: Steve Graham [mailto:sggraham@us.ibm.com] 
Sent: Tuesday, December 14, 2004 1:00 PM
To: Srinivas, Davanum M
Cc: David Booth; public-ws-addressing@w3.org;
public-ws-addressing-request@w3.org
Subject: RE: Issue i0001 - Clarification of "identifier"


Isn't this the case that the <muws-xs-1:ResourceId/> is the identifier
and the EPR is still simply a reference?  That is the EPR is not an
identifier, but rather it contains an identifier? 

sgg 

++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++



"Srinivas, Davanum M" <Davanum.Srinivas@ca.com> 
Sent by: public-ws-addressing-request@w3.org 

12/14/2004 12:54 PM 

 

To

"David Booth" <dbooth@w3.org>, <public-ws-addressing@w3.org> 

cc

 

Subject

RE: Issue i0001 - Clarification of "identifier"

 

 

 






For those who want to make "EPRs be usable as "identifiers" in the
other, mathematical sense of the word", they can add the muws
ResourceId[1] (<muws-xs-1:ResourceId/>) as a Reference Property[2]. 

[1]
http://www.oasis-open.org/committees/download.php/10267/wd-wsdm-muws-par
t1-1.0-20041127.doc
[2]
http://devresource.hp.com/blogs/vambenepe/2004/12/01/1101930898000.html

-----Original Message-----
From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of David Booth
Sent: Monday, December 13, 2004 12:15 AM
To: public-ws-addressing@w3.org
Subject: Issue i0001 - Clarification of "identifier"


Unfortunately, the word "identifier" has more than one meaning.  

I believe Paco and Jeff are correct that there is a mathematical sense
of the word "identifier" in which identifiers are required to be unique,
i.e., if two identifiers are different, then they cannot refer to the
same thing.  (I cannot easily locate a citation for this sense of the
word, but I seem to remember this being discussed on the www-tag list at
w3.org a couple of years ago.)

I (and I think most members of the WS Addressing WG, judging by the
minutes of last week's meeting) have been using the word "identifier" in
the Web Architecture or programming language sense of the word, in which
two different identifiers can indeed refer to the same value, thing or
Web resource.

RFC 2396 defines the word "identifier" as:
[[
Identifier
 An identifier is an object that can act as a reference to
 something that has identity.  In the case of URI, the object is
 a sequence of characters with a restricted syntax.
]]

Issue #1 is about the use of URI+RefProps in the RFC 2396 / WebArch /
programming language sense of the word: something that can act as a
reference to a Web resource.  In this context, the words "address" or
"reference" would be just as good.  (Then again, we may discover
ambiguities with those terms also!)

If anyone is interested in having EPRs be usable as "identifiers" in the
other, mathematical sense of the word (such that different "identifiers"
MUST reference different resources), then that should be raised as a
separate issue.


-- 

David Booth
W3C Fellow / Hewlett-Packard