[ogsa-wg] RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
Marty Humphrey
humphrey at cs.virginia.edu
Tue Oct 11 13:16:18 CDT 2005
You're making quite a leap from what I said.
-- Marty
> -----Original Message-----
> From: owner-ogsa-wg at ggf.org [mailto:owner-ogsa-wg at ggf.org] On Behalf Of
> Mark Morgan
> Sent: Tuesday, October 11, 2005 2:14 PM
> To: 'Marty Humphrey'; Maguire_Tom at emc.com; 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
>
> 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 at cs.virginia.edu]
> > Sent: Tuesday, October 11, 2005 2:10 PM
> > To: 'Mark Morgan'; Maguire_Tom at emc.com; 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
> >
> > 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 at ggf.org [mailto:owner-ogsa-wg at ggf.org]
> > On Behalf
> > > Of Mark Morgan
> > > Sent: Tuesday, October 11, 2005 2:01 PM
> > > To: Maguire_Tom at emc.com; 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
> > >
> > > 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