Cart
[Home] [By Thread] [By Date] [Recent Entries]
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
|
