RE: "operation name" .. an alternate proposal

Mark:

> FWIW, I don't even think it's necessary to have the operation 
> name in the message.  All I request is that there's some 
> bit(s) in the message that can be mapped via public 
> specification to the operation name.  For example, I could 
> "say" via the IETF and IANA, that all messages arriving on 
> TCP port 15555 are supposed to be stored onto disk.  There, 
> the operation might be called "store", yet isn't in the 
> message, but the TCP port is part of the extended envelope of 
> the message, and therefore is sufficient to identify the operation.

I might be being dim here, but I don't see how that is possible.
Messages for different applications will have arbitrary structure and
content. I accept that within the scope of an application or service the
contents of a message can be mapped to some logical operation (within
the scope of the service) but I don't see how a public spec would help
here.

But I do agree that the operation name is implicit not explicit - though
I maintain it is implicit in the message and resolved by the Web
Service.

> I think that's the minimally acceptable scenario.  IMO, 
> receiving a message and not knowing what's being asked of 
> you, is simply not an option and should be actively discouraged.

This situation never occurs though does it? I advertise some contract
that says "Send me a 'WeatherUpdate' message" and since I advertised
that contract it would be ridiculous of me to then not understand those
messages.

Jim
--
http://jim.webber.name

Received on Friday, 9 July 2004 00:53:42 UTC