[ogsa-wg] RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
Mark Morgan
mmm2a at virginia.edu
Tue Oct 11 13:00:31 CDT 2005
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 at ggf.org [mailto:owner-ogsa-wg at ggf.org] On
> Behalf Of Maguire_Tom at emc.com
> Sent: Tuesday, October 11, 2005 1:53 PM
> To: mmm2a at virginia.edu; 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-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 at virginia.edu]
> Sent: Tuesday, October 11, 2005 12:57 PM
> To: Maguire, Tom; 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-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 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