[ogsa-wg] RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
Maguire_Tom at emc.com
Maguire_Tom at emc.com
Tue Oct 11 11:53:31 CDT 2005
Pardon my english
s/the thread to the/this thread to /g
-----Original Message-----
From: owner-ogsa-naming-wg at ggf.org [mailto:owner-ogsa-naming-wg at ggf.org] On
Behalf Of Maguire, Tom
Sent: Tuesday, October 11, 2005 12:49 PM
To: ogsa-wg at ggf.org
Cc: ogsa-naming-wg at ggf.org; tuecke at univa.com; David.Snelling at uk.fujitsu.com
Subject: RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
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
>
>
--
Take care:
Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
Fujitsu Laboratories of Europe
Hayes Park Central
Hayes End Road
Hayes, Middlesex UB4 8FE
+44-208-606-4649 (Office)
+44-208-606-4539 (Fax)
+44-7768-807526 (Mobile)
More information about the ogsa-wg
mailing list