RE: Issue i0001 - Clarification of "identifier"

Hi Dave:


"David Orchard" <dorchard@bea.com> wrote on 12/14/2004 02:50:45 PM:

> Steve,
> 
> I want to fully understand this scenario, so please let me know where I 
have not 
> accurately reflected understand of your scenario.
Thanks for taking the time to comment on my posting. 
> 
> 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. 
As I understand it, AIUI stands for As I Understand It?  Am I close? AIUI 
is a new one
for me. :-)

I believe that is the intention.  The targetResource discussion was 
happening just as
I was dropping out of the WSD WG, so I am not 100% sure.   But I vaguely 
recall that
the intent suggested by WSDM MUWS is the same as what targetResource was 
intended for. 
> 
> 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.
Right, it is the resource identifier.  The relationship between Resource, 
Resource Identifier
Web service and Reference are described in [1].
> 
> The reason you want XML for resourceIds is so that you can have XML 
processing 
> software do the determination.
Right, I have the need to expose the resources with Web services, taking 
advantage of all
the nice goodies that Web services provides, platform neutrality, etc., 
leveraging the
near-universal data serialization provided by the near-ubiquity of XML.
> 
> 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. 
A "second" object identifier?  To me it is THE resource identifier.  I 
don't know
which other resource identifier you were referring to.  I would also avoid 
the term
object, since that usually raises alarms etc.

> Instead of object.operation(arguments), you roughly want address.
> operation(resourceId, arguments).
Well with the approach using the wsa:ReferenceProperties to convey the 
identifier
the effect is more like resource.operation(arguments), avoiding the 
necessity of
having the resourceId in the message body, thereby keeping the means of 
resource identification
opaque to the resource provider (ie not explicitly part of the contract 
between the requestor
and the provider).

> 
> 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.
Well, the resource identified is independent of the address of the EPR, 
there is a 
relation in that the Web service identified by that address can actually 
meaningfully
cope with the refProperty (ie know its type) and meaningfully use the 
value of the
refProperty to appropriately dispatch the message in the context of the 
identified resource.

>  In this 
> case, a single ResourceId refP is the identifier.  But nobody outside 
the scope of 
> your organization knows that.
Right, no one outside my organization need understand the meaning of the 
identifier
type or the meaning of its value set.  This is not part of the contract 
between 
requestor and provider, it is opaque to the provider.

> 
> 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);
Right I didn't want to get into a lot of details in my posting, but 
multiprotocol 
access is a benefit.

I am also struggling with how I would handle this at all in a URI centric 
model. 
I know how this would look in cases where the refProp was a simple type. 
But in
many cases, the resourceID might be a complex type I am not sure how this 
would
map to URI.

> 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.
Right separate Web service endpoints acting on the same underlying 
resource may
have different policies.  They may have different resourceIDs as well, but 
if my
provider environment can limit this to a single resourceID, then I can do 
better 
resourceID correlation of messages etc.  Again, this correlation is 
isolated to my
environment, it is not something the requestor could do.
> 
> 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.
Right different policies for each endpoint.

> 
> URI-centric
> Service A with interface A(notification) is deployed, ResId embedded in 
Uri. 
> Security is based upon subset of URI + operation.
I would imagine different security considerations for Subscribe on 
different
underlying resources, yes.  And for a given resource different security 
considerations
between subscribe, and other messages.

> Service A is augmented with with interface B, ResId also embedded in 
URI.  Security
> ACL is augmented with interface B operations.
Not sure what you mean here.  By augmented, do you mean some sort of 
dynamic
change to the set of operations available at that Web service endpoint?

> 
> 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. 
I don't disagree.

> 
> 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. 
Yes, in the case of multiprotocol, it does add an additional 
multiplicative factor
in complexity.

> 
> 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. 
In general, identifiers cannot be compared for equality without some 
additional
information such as context.  It is inequality that is the hard bit to 
determine.

> 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.
Correct, refProperties are opaque to the client and should not be reasoned 
about by
the client.  The best the client can hope for is a service provided by the 
issuer
of the EPR that would compare two EPRs, ie IsSameResource(EPR1, EPR2) 
returns boolean.

>  To say again, there is no 
> context on the client in which it would do a compare (epr1, epr2).
Correct, the client unilaterally cannot compare EPRs, it needs a service 
provided
by the issuer of both EPRs to do the compare.

> 
> 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.
> 

[1]
http://docs.oasis-open.org/wsrf/2004/11/wsrf-WS-Resource-1.2-draft-02.pdf
> 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
> 
> 
> 
>