>Mark Baker wrote:
>> On 5/19/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:
>>> Because SOAP application semantics are defined by the application and
>>> hence have nothing to do with HTTP semantics.
>>
>> That's simply not the case, Sanjiva.
>>
>> "GET" is as much a "SOAP application semantic" as "getStockQuote".
>> It's just more generic, that's all; getStockQuote's only good for
>> stock quotes, but GET is good for stock quotes, weather reports, and
>> in fact, all information.
>>
>
>Right, so GET is more generic but the result is that I can get back a
>much broader variety of information - How do I ensure I get back
>something I can actually process usefully?

You cannot ensure that, since we are dealing with distributed/networked systems. It is simply an illusion that non-uniform APIs free you from checking that what you expect is what you actually get.
This is of course not a problem; RSS aggregators for example work just fine despite not being sure what they receive upon a GET to a feed URL.

>Am I not just coding at whatever level of abstraction suits me with
>whatever protocol suits me to transfer whatever suits me.  I can
>transfer using TCP and I can transfer with HTTP?

Surely you can do any crazy thing and no architectural style can prevent that. The point is about constraining the design (and adhereing to the constraints of course) to being able to know that your system has certain properties (e.g. regarding extensibility, performance, visibility).
>

Jan

>Dan.
>
>
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>




SPONSORED LINKS
Computer software Computer aided design software Computer job
Soa Service-oriented architecture


YAHOO! GROUPS LINKS




Reply via email to