[ogsa-wg] RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
Mark Morgan
mmm2a at virginia.edu
Tue Oct 11 11:57:25 CDT 2005
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 at ggf.org [mailto:owner-ogsa-wg at ggf.org] On
> Behalf Of Maguire_Tom at emc.com
> 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: [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 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