[ogsa-wg] Re: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
Mark McKeown
zzalsmm3 at nessie.mcc.ac.uk
Wed Oct 19 06:29:12 CDT 2005
Stupid question really, but what is the AbstractName ment to
identify?
cheers
Mark
> 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
>
>
More information about the ogsa-wg
mailing list