Cart
[Home] [By Thread] [By Date] [Recent Entries]
Thanks again everyone for the inputs. Awesome discussion! I have thought a lot about Amy's point: > Sometimes it makes sense to have silly-little-services > that aren't terribly exciting by themselves ... because one > can foresee that they will get aggregated. This makes sense. However, it is in direct contradiction to the practice of making course-grained XML messages. How can these be reconciled? I think that David Hunter's message is the solution: making course-grained XML messages is Best Practice "for scalability". So here's the latest summary, with a slight twist (note #6). Best Practice for Promoting Scalable Web Services 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. 6. Aggregation using replication. There will be Web services which serve to aggregate data from other Web services. One approach is to perform the aggregation on demand - the services which supply the data are invoked in real time, the data is aggregated, and returned to a requesting client. Alternatively, all the data from the supplier services may be retrieved during off-hours in one large, course-grained transaction. Thus, the aggregation is performed in real-time (rather than trying to retrieve the supplier data in real-time). The later is recommended whereever possible. Best Practice for Promoting Interoperable Web Services 1. 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. Comments? Suggestions? /Roger
|
