RE: WSDL Import/Include Locations

 

> -----Original Message-----
> From: Yaron Y. Goland [mailto:ygoland@bea.com] 
> Sent: 05 March 2004 19:28
> To: Martin Gudgin
> Cc: Arthur Ryman; www-ws-desc@w3.org
> Subject: Re: WSDL Import/Include Locations
> 
> As a member of this group I work hard to make productive 
> contributions. 

I apologize if my contributions have not been productive.

> I spend a lot of time preparing what I'm going to say. I 
> realize that this can still result in me saying silly things 
> but at least I try hard to prevent it.

Again, I apologize if my contributions have said silly things.

> 
> So if I'm now saying something silly I apologize. I've 
> thought this one through as best as I'm able and I just don't 
> understand the objections.
> 
> If someone defines a WSDL which imports/includes other 
> information then, generally speaking, the WSDL can't be run 
> unless that other information is available. 

This may not actually be the case. To be honest, it depends on what a
given WSDL processor is doing and what's is being imported/included.
There are several scenarios where imports/includes could be ignored and
a processor could still do it's job. For example, lets say that WSDL A
defines two interfaces I1 and I2 and imports WSDL B which defines
another interface, I3. Let's say that I2 is derived from I3 and that I1
is just a standalone interface. Let's say I define a service in WSDL C
that implements interface I1. So I import WSDL A, define a binding for
I1 and reference that binding in my service. Do I really need to import
WSDL B? I never use I2 and hence don't need I3.

> However endpoints 
> on the Internet, along with the Internet itself, are unreliable.

Agreed, but the contention at the FTF was that there are other,
lower-level, solutions to this problem.

> 
> One of the most common ways to deal with unreliability is to 
> make information available at distinct locations. The 
> advantage of making data available at distinct locations is 
> that not only does it provide reliability in the face of 
> endpoint failures but it also provides reliability in the 
> face of network failures.

I'm not sure why you'd distinguish endpoint failure from network failure
in this particular case.

> 
> If one has a list of possible locations then there are two 
> distinct strategies one can use in retrieving the data. One 
> can walk through the list serially or in parallel.
> 
> Generally speaking serially is preferred. Not only does it 
> reduce the load on the network but it also distributes the 
> load (assuming a random starting point in the list) amongst 
> the various endpoints. This later quality is especially nice 
> as many organizations do not have the resources to run 
> multiple endpoints so if they want to distribute their WSDL 
> they will need to ask other people for a favor. The beauty of 
> a serial based system is that the more people are willing to 
> carry a copy of the document the less load each volunteer has 
> to deal with. In other words, serial processing of alternate 
> locations encourages people to volunteer to replicate each 
> other's content. This is pure goodness.
> 
> Parallel processing also has its place. In cases where 
> performance is super critical it is can be reasonable to 
> download redundant data in parallel in order to reduce the 
> worst case performance scenario. But parallel processing of 
> location lists should be used sparringly. It puts a much 
> heavier load on the net and it actively discourages 
> volunteers to replicate data since each volunteer will have 
> to bear the full load of all requests regardless of how many 
> volunteers there are. This is the opposite of serial 
> processing where the larger the set of volunteers the less 
> load each volunteer has to carry.
> 
> If I understand what is being proposed below then in the case 
> of importing documents it would be legal to import the same 
> content multiple times. Which is a good thing. But, if the 
> only way to get robust behavior is to include multiple 
> redundant imports then we are forcing everyone, everywhere to 
> use parallel loading. This means we are actively discouraging 
> people from replicating each other's data. That just doesn't 
> seem like a good idea.

I don't understand why you would assume that processing of multiple
import elements mandates the parallel approach. If I write a WSDL
processor and I see 

<xs:import namespace='foo' location='blah1' />
<xs:import namespace='foo' location='blah2' />
<xs:import namespace='foo' location='blah3' />

I can process them in serial or in parallel. Or I can just process one
of them and ignore the rest. Or...

> 
> Allowing import/include to have more than one URI and 
> specifying that the list is to be processed serially with a 
> random start location is not a new design. It is well 
> understood, well proven and widely used. Why is there so much 
> resistence to something so obvious?

The WG resolved this issue at the face-to-face by declining to change
the definition of the location attribute on import/include. The status
quo for import/include is now as follows:

1.	You can have multiple wsdl:import elements whose namespace
attribute have the same value. This allows some failover behaviour.
2.	wsdl:import can be processed in a lazy fashion, a WSDL processor
is NOT required to fail just because a given location attribute fails to
resolve to a wsdl:definitions element.
3.	wsdl:include cannot be processed in a lazy fashion, a WSDL
processor MUST fail early if dereferencing any location attribute value
does not resolve to a wsdl:definitions element.

I note your concern that not allowing multiple URIs in the location
attribute loses the notion that all those URIs identify a WSDL that
contains the same set of components. But the WG was not willing to
change the status quo. I would note that in the case of import any WSDL
processor is free to ignore the location attribute and/or augment it
with other locations determined as it sees fit. 

> 
> I apologize if I'm being block headed but I really don't 
> understand the source of contention.

I still maintain that specifying multiple URIs on wsdl:import is not
necessary given the latitude WSDL processors have regarding the
processing of that element anyway. That said, I did vote for allowing
multiple URIs in @location on wsdl:include because of the WGs earlier
decision regarding issue 127. However, the majority of the WG did not
want to make a change. 

As I stated at the face-to-face, I now believe our design to be
inconsisten with respect to wsdl:import and wsdl:include. But I was
out-voted and the status quo is now as I state above. And at this stage,
it feels like it's time to move on to Last Call and await comments.

Gudge

> 
> 	Thank you for your time and patience,
> 
> 		Yaron
> 
> 
> Martin Gudgin wrote:
> 
> > Yup. Agree completely.
> >  
> > Gudge
> > 
> >     
> --------------------------------------------------------------
> ------------------
> >     *From:* www-ws-desc-request@w3.org 
> [mailto:www-ws-desc-request@w3.org] *On
> >     Behalf Of *Arthur Ryman
> >     *Sent:* 04 March 2004 13:33
> >     *To:* www-ws-desc@w3.org
> >     *Subject:* RE: WSDL Import/Include Locations
> > 
> > 
> >     Gudge,
> > 
> >     I think we are forced to allow the same component to be 
> imported more than
> >     once because this will occur for diamond inheritance. 
> For example, suppose
> >     we have four interfaces in four WSDL documents.
> > 
> >     interface Person
> >     interface Manager extends Person
> >     interface Engineer extends Person
> >     interface EngineeringManager extends Manager, Engineer
> > 
> >     Manager.wsdl imports Person.wsdl
> >     Engineer.wsdl imports Person.wsdl
> >     EngineeringManager imports Manager.wsdl and Engineer.wsdl
> > 
> >     When EngineeringManager.wsdl gets processed its 
> component model includes the
> >     component models from both Manager.wsdl and 
> Engineer.wsdl, which means that
> >     the Person interface component gets added to the 
> component model of
> >     EngineeringManager twice. Since this was an important 
> use case (i.e. diamond
> >     inheritance) we agreed to allow duplicate component 
> definitions, provided
> >     they were the same. If they differ, it's an error.
> > 
> >     Generalizing this situation, we allow the same 
> definition to be added
> >     mutliple times via imports or includes, either directly 
> or indirectly.
> >     Therefore, it is permissible to import or include the 
> same document via many
> >     different URIs.
> > 
> >     Arthur Ryman,
> >     Rational Desktop Tools Development
> > 
> >     phone: +1-905-413-3077, TL 969-3077
> >     assistant: +1-905-413-2411, TL 969-2411
> >     fax: +1-905-413-4920, TL 969-4920
> >     mobile: +1-416-969-5063
> >     intranet: http://w3.torolab.ibm.com/DEAB/
> > 
> >     www-ws-desc-request@w3.org wrote on 03/04/2004 08:04:21 AM:
> > 
> >      > I could go either way. I'm certainly happy with what 
> you state below.
> >      >  
> >      > Gudge
> >      >
> >      > From: www-ws-desc-request@w3.org 
> [mailto:www-ws-desc-request@w3.org]
> >      > On Behalf Of Arthur Ryman
> >      > Sent: 04 March 2004 12:41
> >      > To: www-ws-desc@w3.org
> >      > Subject: Re: WSDL Import/Include Locations
> > 
> >      >
> >      > Gudge,
> >      >
> >      > My understanding is that it is OK to pull in the 
> same definition
> >      > twice. It is an error to pull in two definitions of the same
> >      > component if the definitions differ. Do you agree?
> >      >
> >      > Arthur Ryman,
> >      > Rational Desktop Tools Development
> >      >
> >      > phone: +1-905-413-3077, TL 969-3077
> >      > assistant: +1-905-413-2411, TL 969-2411
> >      > fax: +1-905-413-4920, TL 969-4920
> >      > mobile: +1-416-969-5063
> >      > intranet: http://w3.torolab.ibm.com/DEAB/
> >      >
> >      > www-ws-desc-request@w3.org wrote on 03/01/2004 06:02:17 PM:
> >      >
> >      > >
> >      > > Which means that if one did decide to use two 
> imports to pull in the
> >      > > same data for the purpose of robustness then if 
> both imports succeed,
> >      > > besides wasting time and resources, the WSDL would 
> be illegal since the
> >      > > same data would be pulled in twice.
> >      > >
>

Received on Monday, 8 March 2004 12:52:00 UTC