[
Lists Home |
Date Index |
Thread Index
]
Mike Champion wrote:
>
> Maybe I don't follow, but this can't be "axiomatic" when one prominent
> use case for Web Services is to allow books to be ordered,
> schedules to be checked, etc. from very light wireless devices.
>
I have to admit I'm coming at this very much from an EAI point of view.
I'm not familiar with this use case and can't see much advantage to
using Web Services without client-side processing, except as a way of
documenting the query parameters. I still hope and trust that a Web
Services reply will contain less cruft than a Browser Query reply.
>
>>Web Services won't suport an advertising model,
>
> Again unless I'm misunderstanding, this appears to equate
> "Web Services" with RPC using XML and HTTP.
[async, loosely co-ordinated Web Services]
>
Ah, by "advertising" I meant "net-clogging visual cruft" rather than
"async publish and subscribe". We may be arguing at cross-purposes here
- I don't have any problem with the architecture you're describing, I
just disagree with the original assertion that Web Service protocols
will tend to fatten network traffic, and I disagree regardless of
whether the web services tend to get implemented on a sync or async model.
> On the other hand, I fully agree that the most realistic short-term use for
> SOAP/UDDI/WSDL is simply to do cleanly and interoperably with XML
> what is now done with all sorts of HTML and HTTP voodoo, hand-coding,
> and fragmentary documentation. When you have a fat client, exploit it!
>
Amen to that!
Francis.
|
