W3C home > Mailing lists > Public > www-ws-desc@w3.org > March 2004

Re: WSDL Import/Include Locations

From: Jacek Kopecky <jacek.kopecky@systinet.com>
Date: Thu, 18 Mar 2004 15:59:43 +0100
To: ygoland@bea.com
Cc: WS-Description WG <www-ws-desc@w3.org>
Message-Id: <1079621983.4245.16.camel@localhost>


in my opinion the goals below are not goals for WSDL. Location
redundancy is doable as an advantageous side-effect of the semantics of
the import statement, load balancing is not. 

While fairly simple, your proposal is totally out of scope for WSDL, it
can be done with indirection through a single URI whose implementation
implements the load balancing. Perhaps a URI scheme like 
"any:" URI ( "##" URI )*
would be advisable?

In fact, that idea would solve the same problem for every use of URI as
a locator in any specification out there.

Basically, this problem is necessary for WSDL to work, and it's not even
specific to WSDL, so we shouldn't deal with it.

One more comment: without additional wording you wouldn't get redundancy
with your proposal as an implementation could keep choosing randomly the
wrong URI out of the list. Or do you also want to prescribe the right
randomness? 8-) (tongue firmly in cheek here)

Best regards,

                   Jacek Kopecky

                   Systinet Corporation

On Thu, 2004-03-18 at 04:54, Yaron Y. Goland wrote:
> There are two goals in this area I think WSDL needs to achieve:
> Goal #1 - Location Redundancy
> Goal #2 - Load Balancing
> It is clear now to me from the comments on the list that Goal #1 can be 
> achieved today by WSDL as is. But I am still concerned that Goal #2 
> cannot be reasonably achieved.
> Let's take the example from my previous letter and expand it a little:
> Imagine I have a WSDL namespace FOO and two files, FileA and FileB that 
> both define components in namespace FOO. The two files do not define any 
> common components and the two files do not include each other. In other 
> words, each file is completely stand alone. For redundancy and load 
> balancing both files have been made available at multiple locations. The 
> result is that the imports for a WSDL for namespace BAR will be:
> <import namespace="f:oo" location="http://E.com/fileA"/>
> <import namespace="f:oo" location="http://E2.com/fileA"/>
> <import namespace="f:oo" location="http://E3.com/fileA"/>
> <import namespace="f:oo" location="http://E.com/fileB"/>
> <import namespace="f:oo" location="http://E2.com/fileB"/>
> <import namespace="f:oo" location="http://E3.com/fileB"/>
> Let's assume an extremely sophisticated WSDL processor who only executes 
> import statements on demand. On the first access to an element or 
> attribute from the FOO namespace the WSDL processor will go to it's 
> import statements and try to import http://E.com/fileA since it is the 
> first import statement.
> PERFORMANCE PROBLEM #1 - Because the WSDL is published and is static 
> which ever server is listed first on the import list is going to get a 
> disproportionate share of the file access traffic.  This robs 
> implementers of the most basic benefit of load distribution.
> Assuming that http://E.com/fileA contained the necessary elements the 
> WSDL will not process any additional import statements.
> At some point later the WSDL needs an element or attribute from the FOO 
> namespace that was not provided by the import of fileA. So the WSDL 
> engine goes to the next import statement.
> PERFORMANCE PROBLEM #2 - Because the WSDL engine isn't told that 
> http://E2.com/fileA and http://E3.com/fileA are actually just copies of 
> http://E.com/fileA, it will be necessary for the WSDL engine to download 
> both the example2 and example3 files. This means that example2 and 
> example3 are likely to be hit everytime the WSDL's imports are resolved. 
> In other words, there is no load distribution.
> Having gone through E2 and E3 the WSDL engine will eventually reach 
> http://E.com/fileB.
> PERFORMANCE PROBLEM #3 - This is really just a repeat of performance 
> problem #1. http://E.com/fileB is being hit disproportionately hard 
> because it is unlucky enough to be listed first.
> One can easily solve these load balancing problems by adopting a 
> slightly different import/include syntax:
> <import namespace="f:oo" location="http://example.com/fileB
>                                     http://example2.com/fileB
>                                     http://example3.come/fileB"/>
> with an instruction to randomly choose a starting point in the list.
> With this simple change we would get both redundancy and load balancing.
> 	Thanks,
> 		Yaron
Received on Thursday, 18 March 2004 09:59:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:39 UTC