RE: [ogsa-wg] RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSD L Binding
That may be true at the moment. But when the WS-Addressing - WSDL Binding spec is done (or shortly there after) that should not be true. Let me put it this way; if we have an EPR per protocol address we have failed miserably. I am sure you are not implying that the Naming architecture should be bounded by the current toolings limitations. Tom -----Original Message----- From: Mark Morgan [mailto:mmm2a@virginia.edu] Sent: Tuesday, October 11, 2005 12:57 PM To: Maguire, Tom; ogsa-wg@ggf.org Cc: ogsa-naming-wg@ggf.org; tuecke@univa.com; David.Snelling@uk.fujitsu.com Subject: RE: [ogsa-wg] RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding 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)
All I mean to imply is that WS-Naming v. 1.0 should and must be bound by the tooling limitations which are projected to exist at the time that that version of the specification is made public. -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 1:53 PM To: mmm2a@virginia.edu; ogsa-wg@ggf.org Cc: ogsa-naming-wg@ggf.org; tuecke@univa.com; David.Snelling@uk.fujitsu.com Subject: RE: [ogsa-wg] RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
That may be true at the moment. But when the WS-Addressing - WSDL Binding spec is done (or shortly there after) that should not be true. Let me put it this way; if we have an EPR per protocol address we have failed miserably.
I am sure you are not implying that the Naming architecture should be bounded by the current toolings limitations.
Tom
-----Original Message----- From: Mark Morgan [mailto:mmm2a@virginia.edu] Sent: Tuesday, October 11, 2005 12:57 PM To: Maguire, Tom; ogsa-wg@ggf.org Cc: ogsa-naming-wg@ggf.org; tuecke@univa.com; David.Snelling@uk.fujitsu.com Subject: RE: [ogsa-wg] RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
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)
I don't like the sound of this. For me, the real question is - if the existing tooling does not support some approach -- HOW DIFFICULT is it to manipulate the existing tooling (e.g., a small hunk of additional code, perhaps) and HOW SOON is this additional code projected to appear in the tooling itself (this projected date must be agreed-to via consensus)? It seems overly restrictive to say that if Sun and/or Microsoft et. al. don't support it today, then we can't do it. -- Marty
-----Original Message----- From: owner-ogsa-wg@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Mark Morgan Sent: Tuesday, October 11, 2005 2:01 PM To: Maguire_Tom@emc.com; ogsa-wg@ggf.org Cc: ogsa-naming-wg@ggf.org; tuecke@univa.com; David.Snelling@uk.fujitsu.com Subject: RE: [ogsa-wg] RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
All I mean to imply is that WS-Naming v. 1.0 should and must be bound by the tooling limitations which are projected to exist at the time that that version of the specification is made public.
-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 1:53 PM To: mmm2a@virginia.edu; ogsa-wg@ggf.org Cc: ogsa-naming-wg@ggf.org; tuecke@univa.com; David.Snelling@uk.fujitsu.com Subject: RE: [ogsa-wg] RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
That may be true at the moment. But when the WS-Addressing - WSDL Binding spec is done (or shortly there after) that should not be true. Let me put it this way; if we have an EPR per protocol address we have failed miserably.
I am sure you are not implying that the Naming architecture should be bounded by the current toolings limitations.
Tom
-----Original Message----- From: Mark Morgan [mailto:mmm2a@virginia.edu] Sent: Tuesday, October 11, 2005 12:57 PM To: Maguire, Tom; ogsa-wg@ggf.org Cc: ogsa-naming-wg@ggf.org; tuecke@univa.com; David.Snelling@uk.fujitsu.com Subject: RE: [ogsa-wg] RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
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)
I suspect though unfortunately that prototype implementations will be difficult to come by if they are to be written for specs that assume tooling not yet available. I guess in some circumstances it might be possible, but it seems like a hardway to do things and I don't like the idea of specs not having prototype implementations. -Mark
-----Original Message----- From: Marty Humphrey [mailto:humphrey@cs.virginia.edu] Sent: Tuesday, October 11, 2005 2:10 PM To: 'Mark Morgan'; Maguire_Tom@emc.com; ogsa-wg@ggf.org Cc: ogsa-naming-wg@ggf.org; tuecke@univa.com; David.Snelling@uk.fujitsu.com Subject: RE: [ogsa-wg] RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
I don't like the sound of this.
For me, the real question is - if the existing tooling does not support some approach -- HOW DIFFICULT is it to manipulate the existing tooling (e.g., a small hunk of additional code, perhaps) and HOW SOON is this additional code projected to appear in the tooling itself (this projected date must be agreed-to via consensus)?
It seems overly restrictive to say that if Sun and/or Microsoft et. al. don't support it today, then we can't do it.
-- Marty
-----Original Message----- From: owner-ogsa-wg@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Mark Morgan Sent: Tuesday, October 11, 2005 2:01 PM To: Maguire_Tom@emc.com; ogsa-wg@ggf.org Cc: ogsa-naming-wg@ggf.org; tuecke@univa.com; David.Snelling@uk.fujitsu.com Subject: RE: [ogsa-wg] RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
All I mean to imply is that WS-Naming v. 1.0 should and must be bound by the tooling limitations which are projected to exist at the time that that version of the specification is made public.
-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 1:53 PM To: mmm2a@virginia.edu; ogsa-wg@ggf.org Cc: ogsa-naming-wg@ggf.org; tuecke@univa.com; David.Snelling@uk.fujitsu.com Subject: RE: [ogsa-wg] RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
That may be true at the moment. But when the WS-Addressing - WSDL Binding spec is done (or shortly there after) that should not be true. Let me put it this way; if we have an EPR per protocol address we have failed miserably.
I am sure you are not implying that the Naming architecture should be bounded by the current toolings limitations.
Tom
-----Original Message----- From: Mark Morgan [mailto:mmm2a@virginia.edu] Sent: Tuesday, October 11, 2005 12:57 PM To: Maguire, Tom; ogsa-wg@ggf.org Cc: ogsa-naming-wg@ggf.org; tuecke@univa.com; David.Snelling@uk.fujitsu.com Subject: RE: [ogsa-wg] RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
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: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
<name:AbstractName>urn:guid:B94C4186-0923-4dbb-AD9C-39DFB8B54388 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)
You're making quite a leap from what I said. -- Marty
-----Original Message----- From: owner-ogsa-wg@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Mark Morgan Sent: Tuesday, October 11, 2005 2:14 PM To: 'Marty Humphrey'; Maguire_Tom@emc.com; ogsa-wg@ggf.org Cc: ogsa-naming-wg@ggf.org; tuecke@univa.com; David.Snelling@uk.fujitsu.com Subject: RE: [ogsa-wg] RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
I suspect though unfortunately that prototype implementations will be difficult to come by if they are to be written for specs that assume tooling not yet available. I guess in some circumstances it might be possible, but it seems like a hardway to do things and I don't like the idea of specs not having prototype implementations.
-Mark
-----Original Message----- From: Marty Humphrey [mailto:humphrey@cs.virginia.edu] Sent: Tuesday, October 11, 2005 2:10 PM To: 'Mark Morgan'; Maguire_Tom@emc.com; ogsa-wg@ggf.org Cc: ogsa-naming-wg@ggf.org; tuecke@univa.com; David.Snelling@uk.fujitsu.com Subject: RE: [ogsa-wg] RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
I don't like the sound of this.
For me, the real question is - if the existing tooling does not support some approach -- HOW DIFFICULT is it to manipulate the existing tooling (e.g., a small hunk of additional code, perhaps) and HOW SOON is this additional code projected to appear in the tooling itself (this projected date must be agreed-to via consensus)?
It seems overly restrictive to say that if Sun and/or Microsoft et. al. don't support it today, then we can't do it.
-- Marty
-----Original Message----- From: owner-ogsa-wg@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Mark Morgan Sent: Tuesday, October 11, 2005 2:01 PM To: Maguire_Tom@emc.com; ogsa-wg@ggf.org Cc: ogsa-naming-wg@ggf.org; tuecke@univa.com; David.Snelling@uk.fujitsu.com Subject: RE: [ogsa-wg] RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
All I mean to imply is that WS-Naming v. 1.0 should and must be bound by the tooling limitations which are projected to exist at the time that that version of the specification is made public.
-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 1:53 PM To: mmm2a@virginia.edu; ogsa-wg@ggf.org Cc: ogsa-naming-wg@ggf.org; tuecke@univa.com; David.Snelling@uk.fujitsu.com Subject: RE: [ogsa-wg] RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
That may be true at the moment. But when the WS-Addressing - WSDL Binding spec is done (or shortly there after) that should not be true. Let me put it this way; if we have an EPR per protocol address we have failed miserably.
I am sure you are not implying that the Naming architecture should be bounded by the current toolings limitations.
Tom
-----Original Message----- From: Mark Morgan [mailto:mmm2a@virginia.edu] Sent: Tuesday, October 11, 2005 12:57 PM To: Maguire, Tom; ogsa-wg@ggf.org Cc: ogsa-naming-wg@ggf.org; tuecke@univa.com; David.Snelling@uk.fujitsu.com Subject: RE: [ogsa-wg] RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
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: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
<name:AbstractName>urn:guid:B94C4186-0923-4dbb-AD9C-39DFB8B54388 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)
I'm sorry Marty, I didn't mean to. My bad -- I must have misread what you wrote. -Mark
-----Original Message----- From: owner-ogsa-wg@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Marty Humphrey Sent: Tuesday, October 11, 2005 2:16 PM To: 'Mark Morgan'; Maguire_Tom@emc.com; ogsa-wg@ggf.org Cc: ogsa-naming-wg@ggf.org; tuecke@univa.com; David.Snelling@uk.fujitsu.com Subject: RE: [ogsa-wg] RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
You're making quite a leap from what I said.
-- Marty
-----Original Message----- From: owner-ogsa-wg@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Mark Morgan Sent: Tuesday, October 11, 2005 2:14 PM To: 'Marty Humphrey'; Maguire_Tom@emc.com; ogsa-wg@ggf.org Cc: ogsa-naming-wg@ggf.org; tuecke@univa.com; David.Snelling@uk.fujitsu.com Subject: RE: [ogsa-wg] RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
I suspect though unfortunately that prototype implementations will be difficult to come by if they are to be written for specs that assume tooling not yet available. I guess in some circumstances it might be possible, but it seems like a hardway to do things and I don't like the idea of specs not having prototype implementations.
-Mark
-----Original Message----- From: Marty Humphrey [mailto:humphrey@cs.virginia.edu] Sent: Tuesday, October 11, 2005 2:10 PM To: 'Mark Morgan'; Maguire_Tom@emc.com; ogsa-wg@ggf.org Cc: ogsa-naming-wg@ggf.org; tuecke@univa.com; David.Snelling@uk.fujitsu.com Subject: RE: [ogsa-wg] RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
I don't like the sound of this.
For me, the real question is - if the existing tooling does not support some approach -- HOW DIFFICULT is it to manipulate the existing tooling (e.g., a small hunk of additional code, perhaps) and HOW SOON is this additional code projected to appear in the tooling itself (this projected date must be agreed-to via consensus)?
It seems overly restrictive to say that if Sun and/or Microsoft et. al. don't support it today, then we can't do it.
-- Marty
-----Original Message----- From: owner-ogsa-wg@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Mark Morgan Sent: Tuesday, October 11, 2005 2:01 PM To: Maguire_Tom@emc.com; ogsa-wg@ggf.org Cc: ogsa-naming-wg@ggf.org; tuecke@univa.com; David.Snelling@uk.fujitsu.com Subject: RE: [ogsa-wg] RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
All I mean to imply is that WS-Naming v. 1.0 should and must be bound by the tooling limitations which are projected to exist at the time that that version of the specification is made public.
-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 1:53 PM To: mmm2a@virginia.edu; ogsa-wg@ggf.org Cc: ogsa-naming-wg@ggf.org; tuecke@univa.com; David.Snelling@uk.fujitsu.com Subject: RE: [ogsa-wg] RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
That may be true at the moment. But when the WS-Addressing - WSDL Binding spec is done (or shortly there after) that should not be true. Let me put it this way; if we have an EPR per protocol address we have failed miserably.
I am sure you are not implying that the Naming architecture should be bounded by the current toolings limitations.
Tom
-----Original Message----- From: Mark Morgan [mailto:mmm2a@virginia.edu] Sent: Tuesday, October 11, 2005 12:57 PM To: Maguire, Tom; ogsa-wg@ggf.org Cc: ogsa-naming-wg@ggf.org; tuecke@univa.com; David.Snelling@uk.fujitsu.com Subject: RE: [ogsa-wg] RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
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)
Marty Humphrey wrote:
I don't like the sound of this.
For me, the real question is - if the existing tooling does not support some approach -- HOW DIFFICULT is it to manipulate the existing tooling (e.g., a small hunk of additional code, perhaps) and HOW SOON is this additional code projected to appear in the tooling itself (this projected date must be agreed-to via consensus)?
It seems overly restrictive to say that if Sun and/or Microsoft et. al. don't support it today, then we can't do it.
-- Marty
In the CDDLM implementations we demonstrated last week, we were 100% sure that we would not be able to demonstrate interoperability. How so? because the three different implementations of WS-A were all different -NET 1.1/WSE -Axis1.2.x+Apache Muse -Axis2/0.92 I ended up writing classes to try and map from the various different forms of WS-A that could be seen in messages to that of the stack, and had to give up on the reference paramaters bit because the underlying stack assumed they were string values. How can SOAP stacks get away with getting something as fundamental as the address wrong? Because there is not a single test for WS-A. Only now that the spec is nearly a release issue has a mailing list been set up, to which there is currently one whole proposed test: http://lists.w3.org/Archives/Public/public-ws-addressing-tests/2005Aug/0000.... How then can we blame the development teams when they dont get any way of verifying that they have got it right? It is not their fault, they have been given inadequate specifications with no means of verifying compliance with the specification. Similarly, the number of tests for WS-RF and WS-N appear to be less than that for WS-Addressing. Yet we are avocating it as the architecture for global scale, long-lived distributed systems. Marty (and anyone else) : if you are prepared to write the test cases for what constitutes a compliant implementation of WS-A, and get them accepted by the WS-A committe, I will personally integrate those tests into Axis2, which, by consequence of the no-ship-without-100%-tests-passing policy of the team, will then guarantee that Axis2 is compliant with the specification. Without those tests, all bets are off -you will have to take what you are given. Schedule-wise, Axis2 is at the 0.93 release, with a few more iterations before it ships at 1.0. Now is the best time to write those test documents if you want functional WS-A before the end of the year. I wouldnt worry about Sun's stack, and the MS stack is out of my control. Ask Savas about that one. -Steve
participants (4)
-
Maguire_Tom＠emc.com -
Mark Morgan -
Marty Humphrey -
Steve Loughran