[ogsa-wg] Re: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
Frank Siebenlist
franks at mcs.anl.gov
Wed Oct 19 12:42:43 CDT 2005
Mark McKeown wrote:
> Stupid question really, but what is the AbstractName ment to
> identify?
>
>
Hmmm - stupid question from Mark... sorry, but why don't we move on to
what your concern is ? ;-)
As for me, I'm just looking for *any* kind of identifier that I could
use to bind policy to the access of a service/resource, that is either
explicit or implicit part of an EPR, and that can also be deduced from
the messages that are sent to invoke the operation on that
service/resource. I hope that's not too much to ask...
-Frank.
>> I'd like to go back to the start of your discussion and talk about the
>> required properties of the Address.
>>
>> The assumptions for the AbstractName are:
>>
>> * The name MUST be globally unique in both space and time.
>> * The name conforms to URI syntax ("Uniform Resource Identifiers
>> (IRI): Generic Syntax", RFC 3987).
>>
>> I believe that we need more assumptions on the binding properties
>> itself, and an example may help.
>>
>> Suppose we have:
>>
>> <wsa:EndpointReference
>> xmlns:wsa="http://www.w3.org/2005/03/addressing"
>> xmlns:name="http://ggf.org/name">
>> <wsa:Address>
>> http://tempuri.org/example?Id=3
>> </wsa:Address>
>> <name:AbstractName>
>> urn:guid:B94C4186-0923-4dbb-AD9C-39DFB8B54388
>> </name:AbstractName>
>> </wsa:EndpointReference>
>>
>>
>> As you can see, we have an AbstractName that clearly looks unique in
>> space and time, and an Address that seems to have a service/resource
>> identifier (Id=3) that doesn't look that strong.
>>
>> Now suppose that this service application is implemented such that after
>> the hosting environment is recycled/restarted, the following EPR is valid:
>>
>> <wsa:EndpointReference>
>> <wsa:Address>
>> http://tempuri.org/example?Id=4
>> </wsa:Address>
>> <name:AbstractName>
>> urn:guid:B94C4186-0923-4dbb-AD9C-39DFB8B54388
>> </name:AbstractName>
>> </wsa:EndpointReference>
>>
>> (I've removed the name space identifiers for clarity)
>>
>> As you can see, the implementation has assigned a different Address to
>> the same AbstractName, and we can guess that the Id=4 is the changed
>> distinguishing parameter value used for dispatching to the same
>> service/resource.
>>
>> Now suppose that this same implementation will reuse the previous Id=3
>> for a different service/resource, like:
>>
>> <wsa:EndpointReference
>> xmlns:wsa="http://www.w3.org/2005/03/addressing"
>> xmlns:name="http://ggf.org/name">
>> <wsa:Address>
>> http://tempuri.org/example?Id=3
>> </wsa:Address>
>> <name:AbstractName>
>> urn:guid:B94C4186-0923-4dbb-AD9C-39DFB8B77777
>> </name:AbstractName>
>> </wsa:EndpointReference>
>>
>> So now the service implementation has reused the old Address with Id=3
>> for a new, different service/resource that is uniquely identified with a
>> new guid that ends with 77777 instead of 54388: we have two different
>> AbstractNames for two different services/resources that are bound to the
>> same Address, which could cause some confusion...
>>
>> One could claim that this is a "bad" implementation and that the
>> EPR-minter should *ensure* that this should not happen. However, this
>> application could work perfectly correct for the things that it's
>> supposed to do, and it is the mismatch in assumptions that causes the
>> problem.
>>
>> I believe that if we have a strong uniqueness claim for the
>> AbstractName, then the binding to an Address is only meaningful if that
>> Address (or the binding) has an equivalent strong uniqueness property.
>> In other words, the binding of the AbstractName that is "globally unique
>> in both space and time" to an Address, only makes sense if that Address
>> has the exact same property.
>>
>> Now the only one that can ensure that the Address is also "globally
>> unique in both space and time", is the implementation, i.e. the
>> EPR-minter, and those implementations that could be identified through a
>> profile for EPR-minters: the
>> globally-unique-Address-in-both-space-and-time EPR profile.
>>
>> So, binding a "globally unique in both space and time" AbstractName
>> would only make sense if one is assured that the implementation conforms
>> to the globally-unique-Address-in-both-space-and-time EPR profile.
>>
>> One could relax this requirement a little by considering the complete
>> binding instead of the Address only, and we could for example consider a
>> validity time-interval and a binding issuer. This would allow you to
>> localize the uniqueness requirement of the Address to the time-interval
>> or/and issuer. But so far we have punted the idea of dealing with an EPR
>> as a true assertion, which leaves us only the Address to play with.
>>
>> Summary: I believe that the "globally unique in both space and time"
>> requirement for the AbstractName MUST hold true also for the Address to
>> which it is bound, and that EPRs with such an Address constitute a
>> globally-unique-Address-in-both-space-and-time EPR-minter profile. One
>> can only bind AbstractNames to EPRs that adhere to the
>> globally-unique-Address-in-both-space-and-time EPR-minter profile.
>>
>> Note that if this all holds, then the Address of an EPR that conforms to
>> the globally-unique-Address-in-both-space-and-time profile, could also
>> be used as an AbstractName, which would be great as it would give us an
>> identifier that we could use to bind (authorization-) policy to and as a
>> side-benefit would also be available on the wire.
>>
>> Regards, Frank.
>>
>>
>>
>> Maguire_Tom at emc.com wrote:
>>
>>> As promised at the F2F in Boston I have started a thread of discussion on
>>> the subject line. I have reposted the thread to the this mailing list
>>> (ogsa-wg) in the hope that broader distribution will spur debate and
>>> discussion.
>>>
>>> Tom
>>>
>>> -----Original Message-----
>>> From: Maguire, Tom
>>> Sent: Sunday, October 09, 2005 4:51 PM
>>> To: Maguire, Tom; David.Snelling at UK.Fujitsu.com
>>> Cc: ogsa-naming-wg at ggf.org; tuecke at univa.com
>>> Subject: RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
>>>
>>> Dave you mentioned in one of your question:
>>>
>>>
>>>
>>>>> It appears that in the example that either the was:Address and the
>>>>> soap:address must be the same or that the wsa:Addess is irrelevant.
>>>>> I can't really believe the former so let's assume the later.
>>>>>
>>>>>
>>> It's not that the wsa:adddress is irrelevant it is that the wsa:address is
>>> logical as opposed to physical. This is precisely why I think we can use
>>> it....
>>>
>>> Tom
>>>
>>> -----Original Message-----
>>> From: owner-ogsa-naming-wg at ggf.org [mailto:owner-ogsa-naming-wg at ggf.org] On
>>> Behalf Of Maguire, Tom
>>> Sent: Sunday, October 09, 2005 8:35 AM
>>> To: David.Snelling at UK.Fujitsu.com
>>> Cc: ogsa-naming-wg at ggf.org; tuecke at univa.com
>>> Subject: RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
>>>
>>> Dave,
>>>
>>> I'll do my best to answer your questions inline below. Let me caution this
>>> thread a bit. The WSDL Binding specification is not complete and is clearly
>>> still evolving...
>>>
>>>
>>>
>>>>> It appears that in the example that either the was:Address and the
>>>>>
>>>>>
>>> soap:address must
>>>
>>>
>>>>> be the same or that the wsa:Addess is irrelevant. I can't really
>>>>> believe
>>>>>
>>>>>
>>> the
>>>
>>>
>>>>> former so let's assume the later.
>>>>>
>>>>>
>>> Yes, I believe that is the intent. As I mentioned in my note it is
>>> 'interesting' that they are the same. My guess is that makes
>>> implementations that are not <wsa:metadata> aware able to cope. I would
>>> expect that would be a 'best practice'. Not sure what the implications
>>> would be for us if that were the case...
>>>
>>>
>>>
>>>>> With a wsdl11:definitions section present, the wsa:Address field must
>>>>> be
>>>>>
>>>>>
>>> superseded
>>>
>>>
>>>>> by the soap:address chosen by the client. I assume that the
>>>>> soap:address gets copied to the was:To field in the soap header.
>>>>>
>>>>>
>>> Ultimately you are correct however I expect that the specification of that
>>> linkage would not be quite as explicit as that.
>>>
>>>
>>>
>>>>> There is no linkage in the wsdl11:definitions to connect the
>>>>> wsa:Address
>>>>>
>>>>>
>>> to it.
>>>
>>> No
>>>
>>>
>>>
>>>>> Q1) What happens with more than one wsdl11:definitions section in the
>>>>> was:Metadata?
>>>>>
>>>>>
>>> I have no idea what that would even mean. I presume they would limit that
>>> in the spec. As I said it is still evolving.
>>>
>>>
>>>
>>>>> Q2) In this case can we put any old junk in the wsa:Address?
>>>>> i.e. leave it out (except that the scheme saus [1..].
>>>>>
>>>>>
>>> <wsa:address> is required and I would assume that at a minimum there would
>>> be a statement of 'best practice' where the <wsa:address> is the 'default'
>>> address.
>>>
>>>
>>>
>>>>> Q3) If we use the wsa:Address as an Abstract Name, how do we know that
>>>>> is
>>>>>
>>>>>
>>> what
>>>
>>>
>>>>> we are doing? We could subtype the EPR to create a WS-Name as we do
>>>>> now, and bind the usage of the was:Address to type of the WS-Name.
>>>>>
>>>>>
>>> I would use a wsi conformance claim on both the wsdl and the EPR. The wsdl
>>> claim would be that the service is capable of generating WS-Names. The EPR
>>> claim would be that this EPR adheres to the additional semantics of a
>>> WS-Name.
>>>
>>>
>>>
>>>>> Q4) I thought WS-Addressing was NOT about naming or identity.
>>>>> How will this use (abuse) of the wsa:Address go down with the W3C folks?
>>>>>
>>>>>
>>> I think this is a misread on your part W3C objected to identity being
>>> encoded in something OTHER than a URI (IRI); in the WS-Addressing case they
>>> objected to ReferenceProperties. Ultimately ReferenceProperties were merged
>>> with ReferenceParameters which weakened (removed) the identity semantic. I
>>> think they would be extremely happy with the use of a URI as an identifier
>>> :-).
>>>
>>>
>>> Tom
>>>
>>>
>>> On 7 Oct 2005, at 12:41, Maguire_Tom at emc.com wrote:
>>>
>>>
>>>
>>>> This will be a fairly long note to discuss the current incarnation of
>>>> WS-Naming Abstract Names. An Abstract Name has the following
>>>> properties:
>>>>
>>>> * The name MUST be globally unique in both space and time.
>>>> * The name conforms to URI syntax ("Uniform Resource Identifiers
>>>> (IRI): Generic Syntax", RFC 3987).
>>>>
>>>> Let's leave aside the first point, for the time being, and focus on
>>>> the second point. The abstract name is an IRI which is an
>>>> internationalized URI. Currently this means that a WS-Name abstract
>>>> name would look like
>>>> this:
>>>>
>>>> <wsa:EndpointReference
>>>> xmlns:wsa="http://www.w3.org/2005/03/addressing"
>>>> xmlns:name="http://ggf.org/name">
>>>> <wsa:Address>http://tempuri.org/example</wsa:Address>
>>>>
>>>> <name:AbstractName>urn:guid:B94C4186-0923-4dbb-AD9C-39DFB8B54388</
>>>> name:Abstr
>>>> actName>
>>>> </wsa:EndpointReference>
>>>>
>>>> There are several built in assumptions in this particular rendering of
>>>> an
>>>> abstract name. First, there is an assumption that the <wsa:Address>
>>>> is the
>>>> [destination] MAP of the EPR. Second, the AbstractName does not need
>>>> to flow on the wire when 'dereferencing' this EPR.
>>>>
>>>> It may be ok for the AbstractName to not flow on the wire. I will
>>>> leave that discussion to others. Let's focus on the first
>>>> assumption...
>>>> If you assume that the <wsa:Address> is NOT necessarily a physical
>>>> address
>>>> (URL) then it is essentially the same as an AbstractName minus the
>>>> "MUST be globally unique in both space and time" property described
>>>> above.
>>>>
>>>> This is essentially how 'Web Services Addressing 1.0 - WSDL Binding'
>>>> defines
>>>> a <wsa:Address>. An example from that specfication:
>>>>
>>>> <wsa:EndpointReference
>>>> xmlns:wsa="http://www.w3.org/2005/03/addressing">
>>>> <wsa:Address>http://example.com/fabrikam/acct</wsa:Address>
>>>> <wsa:Metadata>
>>>> <wsdl11:definitions targetNamespace="http://example.com/fabrikam"
>>>> xmlns:fabrikam="http://example.com/fabrikam"
>>>> xmlns:abc="http://www.abccorp.com/"
>>>> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
>>>> xmlns:iiop="http://www.iiop.org/"
>>>> xmlns:wsdl11="http://schemas.xmlsoap.org/wsdl/">
>>>> <wsdl11:import namespace="http://example.com/fabrikam"
>>>> location="http://example.com/fabrikam/fabrikam.wsdl"/>
>>>> <wsdl11:import namespace="http://www.abccorp.com/"
>>>> location="http://www.abccorp.com/abc.wsdl"/>
>>>> <wsdl11:service name="InventoryService">
>>>> <wsdl11:port name="ep1" binding="abc:soap-http-binding">
>>>> <soap:address location="http://example.com/fabrikam/acct"/>
>>>> </wsdl11:port>
>>>> <wsdl11:port name="ep2" binding="abc:iiop">
>>>> <iiop:address location="..."/>
>>>> </wsdl11:port>
>>>> </wsdl11:service>
>>>> </wsdl11:definitions>
>>>> </wsa:Metadata>
>>>> </wsd:EndpointReference>
>>>>
>>>> And also from 'Web Services Addressing 1.0 - WSDL Binding'
>>>>
>>>> In particular, embedding a WSDL service component description MAY be
>>>>
>>>>
>>>
>>>> used by EPR issuers to indicate the presence of alternative addresses
>>>> and protocol bindings to access the referenced endpoint. The
>>>> alternatives are provided by the different endpoints of the embedded
>>>> service.
>>>>
>>>> It is interesting to note that in the above example that the
>>>> <wsa:address> matches the soap:address location.
>>>> So this says to me that the <wsa:address> is essentially equivalent
>>>> (or at least could be) to an abstract name.
>>>>
>>>> Thoughts?
>>>>
>>>>
>>>> Thanks,
>>>> Tom
>>>>
>>>> Senior Technologist, CTO Office
>>>> EMC�|SMARTS
>>>> 44 South Broadway
>>>> 7th Floor
>>>> White Plains, NY 10601
>>>> Office: +1-914-508-3477
>>>> Mobile: +1-845-729-4806
>>>> Email: maguire_tom at emc.com <mailto:maguire_tom at emc.com>
>>>>
>>>> If you want to build a ship, don't drum up people to collect wood and
>>>> don't assign them tasks and work, but rather teach them to long for
>>>> the endless immensity of the sea.
>>>>
>>>> Antoine de Saint-Exupery
>>>>
>>>>
>>>>
>>>>
>> --
>> Frank Siebenlist franks at mcs.anl.gov
>> The Globus Alliance - Argonne National Laboratory
>>
>>
>>
>
>
--
Frank Siebenlist franks at mcs.anl.gov
The Globus Alliance - Argonne National Laboratory
More information about the ogsa-wg
mailing list