OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Web Services Best Practice, summary 3

[ Lists Home | Date Index | Thread Index ]

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





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS