- From: Arthur Ryman <ryman@ca.ibm.com>
- Date: Thu, 12 Jun 2003 16:08:17 -0400
- To: "Amelia A. Lewis" <alewis@tibco.com>
- Cc: WS Description List <www-ws-desc@w3.org>, www-ws-desc-request@w3.org
- Message-ID: <OFC6A354FA.9F125B99-ON85256D43.006C4A8F@torolab.ibm.com>
Amy, You wrote: "The use of "resource" as a larger thing than "service" is a reversal of common use. Commonest-of-all use of "resource" is in the terms "uniform resource locator" or "uniform resource identifier"; these terms implicitly define a resource as being an endpoint and an interface; the fact that multiple resources may point at the same abstract [something], or share its state, indicates that the general use of the term "resource" is to indicate a subset of an interface on a service." Look at the following section of the WSDL 1.1 spec: http://www.w3.org/TR/wsdl#_services "If a service has several ports that share a port type, but employ different bindings or addresses, the ports are alternatives. Each port provides semantically equivalent behavior (within the transport and message format limitations imposed by each binding). This allows a consumer of a WSDL document to choose particular port(s) to communicate with based on some criteria (protocol, distance, etc.)." Each endpoint is a resource, but there is also another resource which represents the "equivalence class" of the endpoints. This other resource is conceptually useful since it abstracts out the details of the protocol. For example, suppose a financial services company offers a Stock Quote service whose endpoint is http://www.finance.com/StockQuote. That's one endpoint. But after a while, some customers ask for a secure way to access the service, since they are worried there interests in certain stocks may be observed. The financial services company then makes the same function available at http://www.finance.com/StockQuote - same interface, same function, but different protocol. Now we have two endoints: 1. http://www.finance.com/StocKQuote 2. https://www.finance.com/StocKQuote We have two endpoint resources, but just one target resource of the service. We can lump these in a single <service> element, and not explicitly name the target resource, or we can have separate <service> elements and related them via the @targetResource attribute. Arthur Ryman
Received on Thursday, 12 June 2003 16:08:48 UTC