[ogsa-wg] Re: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
Mark McKeown
zzalsmm3 at nessie.mcc.ac.uk
Fri Oct 21 07:39:44 CDT 2005
Hi Frank,
The question came to mind for a number of reasons:
1) The W3C TAG are discussing WS-RF, WSA and Grid, they are
approaching consensus on the following:
'"Use of the abstract properties of an EPR other than wsa:address
to identify resources is contrary to WebArch" For example, we note
that WS-RF specification uses EPRs to identify information resources
(such as for example experimental datasets in the Grid) which
prevents hypertext links from being made to them. We said that, and
then said that we realize that current tools may not make it easy
to do things that way, e.g. because of dispatch issues.'
http://lists.w3.org/Archives/Public/www-tag/2005Oct/0048.html
2) Tim Berners-Lee's excellent essay "What do HTTP URIs Identify?"
http://www.w3.org/DesignIssues/HTTP-URI.html
3) wsa:address identifies a resource, it has a IRI, but is that
the same thing that the AbstractName is ment to identify?
4) A WSRF WS-Resource has this concept of being composed of two things,
a Web Service and a resource -
http://docs.oasis-open.org/wsrf/wsrf-ws_resource-1.2-spec-pr-02.pdf
(personally I prefer to thing of a WS-Resource as a single thing)
- so is the AbstractName ment to identify the resource or the
Web Service. (Of course according to W3C Web Services Architecture
the Web service is a resource as well)
5) A scenario from RealityGrid (http://www.realitygrid.org)
- I am working in collaboration with others, I have a job running
on resource provider A's machine, the job has an EPR and the A gives
it an AbstractName, I migrate the job to another machine provided
by B, it has a new EPR and B gives it a different AbstractName. This
is not what I want - I want the job to have the same AbstractName
after I migrate it so that my fellow collaborators can find it.
Can a client add an AbstractName to an EPR, or is only the EPR
minter allowed to do that?
6) Can I use the AbstractName to identify a particular conversation
I am having with a Web service?
cheers
MArk
On Wed, 19 Oct 2005, Frank Siebenlist wrote:
> 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