My experience has been that available tooling (Microsoft and Java) doesn't support Address lines that aren't URLs. Am I wrong about this? -Mark
-----Original Message----- From: owner-ogsa-wg@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Maguire_Tom@emc.com Sent: Tuesday, October 11, 2005 12:49 PM To: ogsa-wg@ggf.org Cc: ogsa-naming-wg@ggf.org; tuecke@univa.com; David.Snelling@uk.fujitsu.com Subject: [ogsa-wg] 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@UK.Fujitsu.com Cc: ogsa-naming-wg@ggf.org; tuecke@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@ggf.org [mailto:owner-ogsa-naming-wg@ggf.org] On Behalf Of Maguire, Tom Sent: Sunday, October 09, 2005 8:35 AM To: David.Snelling@UK.Fujitsu.com Cc: ogsa-naming-wg@ggf.org; tuecke@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@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@emc.com <mailto:maguire_tom@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)