Implied Abstract Name Profile
I'd like to make a case for the definition of an "Implied Abstract Name" profile for ws-addressing. By claiming to adhere to this profile, the EPR-minter would indicate that care has been taken with the construction of the EPR's address to provide it enough uniqueness properties such that it can be used as a "name" by itself. The observation is that if an EPR-minter can determine that the reference refers to a uniquely identifiable resource such that an "abstract name" can be constructed, then in many cases it could also add enough uniqueness properties to the EPR's address such that the address itself could be used as an alternative abstract name. For example, if a uuid could be generated as an abstract name, then the implementation may also be able to choose to base the dispatching information in the address' URI on that same uuid, which would give the address's URI and the abstract name's URI equivalent uniqueness properties. Now, in some cases, the resource identifiable information is not present in the address value, but is somewhere embedded in the optional reference parameters. Again, the EPR-minter may have a choice to make that resource identifier information for the reference parameters just as "unique" as the equivalent abstract name it could create. In those cases, one could standardize a recipe to construct a unique "implied abstract name" from the address and the reference parameter values. For example, one could concatenate the address and the base64-blob of the canonicalized reference parameters to yield a URI-value for the implied abstract name. (Or one could concatenate the address and the digest value of that base64 blob if you care about the length of the value... at the expense of being able to reconstruct the address+reference-parameters from that implied abstract name...) In summary, if the EPR-minter is able to generate a abstract name value for a resource, then in many implementations, the EPR-minter could also generate an address (+reference parameters) that would yield an implied abstract name with the same uniqueness properties. The EPR-minter could communicate the adherence to this "Implied Abstract Name" profile by labeling the EPR somehow. The spec shows that one can add attributes to the address element: /wsa:EndpointReference/wsa:Address/@{any} such that we could label such an address element with an attribute that would tell you the profile that this address value adheres to, like implied-abstract-name="true". Tom Maguire suggested (and prefers) an approach that attachs a claim (wsi:claim) to a wsdl element (likely a port or binding). wsi:claim="http://example.org/ImpliedAbstractName There may be other (better) ways... Now... why would this be any better or worse or why do we need this at all? The abstract name as it is defined now in the ws-naming spec is part of the EPR, but does not get communicated on the wire. In other words, once the soap message is constructed from the EPR according to the ws-addressing recipe, we loose the abstract name as it doesn't get mapped into the message header content. In other words, from the header information we can not derive any unique identifier for the resource this message is meant for. In order to enforce resource specific policy on a soap message or to write traceable information in audit logs, we somehow have to obtain a unique identifier for the resource. In some cases, and certainly when we're inside of the dispatching service itself, we can assume that that application can find the mapping back to the abstract name that was issued in the EPR. However, that mapping is application specific logic and therefor not easily accessible from within the runtime where transparent policy enforcement is applied. Also, any soap-routing intermediate won't have access to the abstract name. Hopefully, these example make the case for such an "Implied Abstract Name" profile, as it would allow one to obtain a unique identifier for the resource from a message that was generated from a profile compliant EPR. Note that this profile would not make the abstract name element obsolete as for resources that change their reference over their lifetime one needs a stable resolvable name. Having both an abstract name and an implied abstract name would allow one also to keep mapping tables outside of the EPR-minting applications, which is needed to correlate policy and audit trails for the same resources. --- If the requirement for an implied abstract name and the need for an associated profile hold water, then it may be appropriate for the ws-naming wg to add such a profile definition to its charter. Regards, Frank. -- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory
I'd like to make a case for the definition of an "Implied Abstract Name" profile for ws-addressing.
By claiming to adhere to this profile, the EPR-minter would indicate that care has been taken with the construction of the EPR's address to provide it enough uniqueness properties such that it can be used as a "name" by itself.
The observation is that if an EPR-minter can determine that the reference refers to a uniquely identifiable resource such that an "abstract name" can be constructed, then in many cases it could also add enough uniqueness properties to the EPR's address such that the address itself could be used as an alternative abstract name.
For example, if a uuid could be generated as an abstract name, then the implementation may also be able to choose to base the dispatching information in the address' URI on that same uuid, which would give the address's URI and the abstract name's URI equivalent uniqueness
Frank, I like the idea. wrt wsi:claim I meant that to be in addition to some other runtime indicator. +1 to this idea Tom owner-ogsa-wg@ggf.org wrote on 09/02/2005 12:38:27 AM: properties.
Now, in some cases, the resource identifiable information is not present in the address value, but is somewhere embedded in the optional reference parameters. Again, the EPR-minter may have a choice to make that resource identifier information for the reference parameters just as "unique" as the equivalent abstract name it could create. In those cases, one could standardize a recipe to construct a unique "implied abstract name" from the address and the reference parameter values. For example, one could concatenate the address and the base64-blob of the canonicalized reference parameters to yield a URI-value for the implied abstract name. (Or one could concatenate the address and the digest value of that base64 blob if you care about the length of the value... at the expense of being able to reconstruct the address+reference-parameters from that implied abstract name...)
In summary, if the EPR-minter is able to generate a abstract name value for a resource, then in many implementations, the EPR-minter could also generate an address (+reference parameters) that would yield an implied abstract name with the same uniqueness properties.
The EPR-minter could communicate the adherence to this "Implied Abstract Name" profile by labeling the EPR somehow.
The spec shows that one can add attributes to the address element:
/wsa:EndpointReference/wsa:Address/@{any}
such that we could label such an address element with an attribute that would tell you the profile that this address value adheres to, like implied-abstract-name="true".
Tom Maguire suggested (and prefers) an approach that attachs a claim (wsi:claim) to a wsdl element (likely a port or binding).
wsi:claim="http://example.org/ImpliedAbstractName
There may be other (better) ways...
Now... why would this be any better or worse or why do we need this at
all?
The abstract name as it is defined now in the ws-naming spec is part of the EPR, but does not get communicated on the wire. In other words, once the soap message is constructed from the EPR according to the ws-addressing recipe, we loose the abstract name as it doesn't get mapped into the message header content. In other words, from the header information we can not derive any unique identifier for the resource this message is meant for. In order to enforce resource specific policy on a soap message or to write traceable information in audit logs, we somehow have to obtain a unique identifier for the resource. In some cases, and certainly when we're inside of the dispatching service itself, we can assume that that application can find the mapping back to the abstract name that was issued in the EPR. However, that mapping is application specific logic and therefor not easily accessible from within the runtime where transparent policy enforcement is applied. Also, any soap-routing intermediate won't have access to the abstract name.
Hopefully, these example make the case for such an "Implied Abstract Name" profile, as it would allow one to obtain a unique identifier for the resource from a message that was generated from a profile compliant EPR.
Note that this profile would not make the abstract name element obsolete as for resources that change their reference over their lifetime one needs a stable resolvable name.
Having both an abstract name and an implied abstract name would allow one also to keep mapping tables outside of the EPR-minting applications, which is needed to correlate policy and audit trails for the same resources.
---
If the requirement for an implied abstract name and the need for an associated profile hold water, then it may be appropriate for the ws-naming wg to add such a profile definition to its charter.
Regards, Frank.
-- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory
participants (2)
-
Frank Siebenlist -
Tom Maguire