- From: Jim Webber <Jim.Webber@newcastle.ac.uk>
- Date: Wed, 14 Jul 2004 01:23:43 +0100
- To: <www-ws-desc@w3.org>
Prasad: > I can relate to leaving this to the complexities of server > side implementation to figure how to dispatch the message (to > the correct operation), even though I do see cases where this > can become difficult (having to parse the entire message to > determine the "real" operation (performance issue)) if not > totally ambiguous in the worst case. The performance of a service is not the consumer's responsibility. If you want a high-performance service then architect it that way, but don't delegate your service's needs to the consumer. > If we can make it easier for a client to direct a message at > an operation on the server in a guaranteed fashion (from the > client perspective), it is really useful IMO. This gets my > vote on "what the WG wants" vs what 114 means. No it's not useful because i)operations are imaginary (a function of a particular view of a message; and ii) this violates encapsulation and encourages consumers to bind to something that they shouldn't (both because it's intangible and because its yours not theirs). > 1. In promoting the client and server sides having the same > understanding on what is being invoked unambiguously (goes > towards interop). This is, I believe, emminently achievable through the structure and content of messages. > 2. Avoid debug head-aches on the server implementation when > things *do* go wrong. You're right here, sort of. The first time something breaks you've got a head start because you immediately know what operation is causing the problem. However over time as your service evolves and perhaps the wsdl:operation and the com.foo.Bar.operation() method become more detached (perhaps completely) then you're at the same place I am with just a bunch of messages that have to be matched to some back-end system. So in the general case you get nothing from mixing in operation names, apart from undesirable tight-coupling. Jim -- http://jim.webber.name
Received on Tuesday, 13 July 2004 20:21:54 UTC