[
Lists Home |
Date Index |
Thread Index
]
Here's a summary based upon the responses. Thanks Mike and Len for your
inputs.
1. Stay away from using XML messaging to do fine-grained RPC. For
example, stay away from a service which returns the square root of a
number. Stay away from a service that returns a stock quote (this is
the classic-cited example of a Web service).
2. Conversely, use course-grained RPC. XML web services usually have to
be defined at a coarser granularity than ordinary software objects.
That is, use Web services that "do a lot of work, and return a lot of
information".
3. When the transport may be slow and/or unreliable, or the processing
is complex and/or long-running, consider an asynchronous messaging
model.
4. Always take the overall system performance into account. Don't
optimize until you know where the bottlenecks are, i.e., don't assume
that XML's "bloat" or HTTP's limitations are a problem until
they are demonstrated in your application.
5. Take the frequency of the messaging into account. A high rate of
requests might suggest that you load (replicate) some of the data and
processing back to the client. The client occassionally connects to
synch-up with the server, and get the lastest data. (Is this a
reasonable summary Len?)
6. Beware of vendor-specific entensions. The whole point of XML web
services is to leverage Web standards and experience with them to
maximize interoperability, so be wary of burying the core technology
within too many protocols and libraries and wizards.
Anything else? /Roger
|
