Re: Action Item 2004-07-01 Solution to 168/R114

Jim Webber wrote:

>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.
>
I am not sure how you inferred the above from what I said. I did not 
imply that at all. No connection. And I agree with what you say above.

>>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).
>
Operations are imaginary? Why even have an interface then? Operations 
help describe the specific function offered by an interface and group 
requests and responses per the MEPs. Why does it violate encapsulation? 
How is this different in concept to method in a class (e.g. java)?  That 
is well accepted encapsulation.

>>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.
>
Yes, you can also do everything in assembly language(or binary for that 
matter) then why have anything else at a higher abstraction. You need to 
put the messages in context so that you are not required to design your 
messages in unique way.
This is simply making the life hard for everyone.

>>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) 
>
If this really the way you design and maintain things, you are right it 
does not matter if you had operations or not. Glad I don't buy software 
from you :)

>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 
>  
>