- From: Sergey Beryozkin <sberyozkin@zandar.com>
- Date: Mon, 23 Jun 2003 15:38:43 +0100
- To: "Arthur Ryman" <ryman@ca.ibm.com>
- Cc: <www-ws-desc@w3.org>, <www-ws-desc-request@w3.org>
- Message-ID: <000f01c33995$32ea6bc0$1800a8c0@BERYOZKIN>
Hello Arthur, Thank you for explaining this, it was helpful. When reasoning about why would one create several service descriptions with the same interface and the same targetResource for the purposes of selecting different endpoints and(or) bindings, I started suspecting :-) that the latest WSDL 1.2 now probably says that there could be only a single interface and port per service description :-)... Cheers Sergey Beryozkin ----- Original Message ----- From: Arthur Ryman To: Sergey Beryozkin Cc: www-ws-desc@w3.org ; www-ws-desc-request@w3.org Sent: Monday, June 23, 2003 3:21 PM Subject: Re: targetResource wording Sergey, 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:38:52 UTC