[ogsa-wg] Implied Abstract Name Profile

[Tom Maguire]

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 at ggf.org wrote on 09/02/2005 12:38:27 AM:

> 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 at mcs.anl.gov
> The Globus Alliance - Argonne National Laboratory
>