W3C home > Mailing lists > Public > www-ws-desc@w3.org > June 2003

Re: targetResource wording

From: Arthur Ryman <ryman@ca.ibm.com>
Date: Mon, 23 Jun 2003 10:21:14 -0400
To: "Sergey Beryozkin" <sberyozkin@zandar.com>
Cc: www-ws-desc@w3.org, www-ws-desc-request@w3.org
Message-ID: <OFB0C2F8AE.A55E1B4E-ON85256D4E.004D0539@torolab.ibm.com>

You wrote:
"I can see this practical implication, thanks. 
But a single service description with multiple ports can provide the same 
choice for a client, can't it ? Every port within a service is an 
alternative way to access a single interface in WSDL 1.2, which  allows to 
select both the best endpoint and the best binding."

In the case of the same interface and same targetResource, it is true that 
you could put all the endpoints in a single <service> element. However, 
there still might be some value in having several WSDL documents that used 
the same interface and targetResource. For example, consider the case of 
independently created mirror sites. Rather than continually update a 
single WSDL document whenever you add a mirror service, you could create 
the mirrors independently and register them in UDDI. Then a client 
application could query the UDDI registry for services that implemented 
the interface, retrieve their WSDL documents,  look at the targetResource, 
and pick the "best" endpoint, e.g. depending on geographic location, or 
maybe cycle through the list if the first one failed.

A concrete example of this might be a service to order books from 
MegaBookstore.com. Suppose the company is located in California but has 
national coverage. It may start with a server in California, and then as 
business expands, it may create servers in New York and Florida. All three 
services would implement the same BookOrder interface and have the same 
targetResource, e.g. http://www.MegaBookstore.com/orders, but each would 
have its own WSDL document with a <service> in it and each would have its 
own entry in UDDI. Each UDDI entry would contain a standard ISO 3166 
geographic classification code.

Arthur Ryman
Received on Monday, 23 June 2003 10:21:33 UTC

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