- From: Dale Moberg <dmoberg@cyclonecommerce.com>
- Date: Thu, 2 May 2002 11:04:38 -0700
- To: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>, <www-ws-desc@w3.org>
Hi, Despite your instruction to shelve the discussion, I think it is worth at least one more clarification because you have misrepresented my response to your question. This refers to the following snippet: >> Sanjiva> The problem with using an OUT operation to do that is >> that its not clear where the OUT is targetted to. >> Well, that info could be part of a binding for the >> actual implemented interfaces. It can be equally well said >> that the problem with an IN operation is that it is not >> clear who is targeting it. These interfaces are to be abstracted >> from some "bits on the wire" details, right? Sanjiva> No, the target of the OUT operation cannot be in the binding; if >so its a fixed target that can never change! If OUTs are like >events then one needs a subscription mechanism to register the >listeners etc.. So what I'm proposing is dropping the OUT operations >and adding first class support for events (and whatever else OUT >oriented stuff we find interesting). First, I was not saying that the current value under wsdl:port be taken as a target for an OUT operation. That makes no sense. The URL(s) that are needed for configuring the communications machinery for the OUT operation are obtained by some not yet specified (by wsdl) process. [ I might add that your objection about creating hard links also applies, probably harmlessly, to the inclusion of values for wsdl:port.] As far as how to enhance/alter WSDL to provide better support for OUT operations, I think that re-using or oveloading wsdl:port and its URL would just be too confusing to bother with. What might replace it, is a separate chunk of information, wsdl:registration, containing either 1. a reference to a service registration interface (IN flavor) (in WSDL naturally) or 2. a format for an interface with a datatype of anyURI, and a URL, that would allow you to subscribe to the service or 3. something else that actually allows configuration of the service. Maybe that is what your event stuff would do. If so, I look forward to seeing it.
Received on Thursday, 2 May 2002 14:05:09 UTC