[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Web Services Best Practice, summary 2

• To: "Roger L. Costello" <costello@m...>, xml-dev@l...
• Subject: Re: Web Services Best Practice, summary 2
• From: Amy Lewis <amyzing@t...>
• Date: Thu, 10 Jan 2002 12:53:40 -0500
• In-reply-to: <3C3DC496.7C4E47A6@m...>
• References: <3C3DC496.7C4E47A6@m...>
• User-agent: Mutt/1.3.24i

On Thu, Jan 10, 2002 at 11:43:02AM -0500, Roger L. Costello wrote:
>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".

Hmm.

I'm not entirely sure that I agree with these best practices, although
they are likely to be good rules of thumb.

Consider this scenario:

Online bookstore A supplies a web service that does very little: it
returns matching books, with identifying information (including unique
ID: ISBN) and price (a value local to bookstore A).

Online bookstore B provides a similar service, but requires ISBN,
returning price, availability, and shipping cost to specified
destination.

Online bookstores C, D, and E also provide services, which also vary
slightly.  The unifying point is that price and availability are
supplied in response to an ISBN query.

Online recreation area R supplies reviews of books, with links to other
related books and other interesting sorts of information.  One set of
reviews may be retrieved by several different ISBNs (same content,
different editions/formats).

Recreation area R also provides consumer reviews of various bookstores,
including A, B, D, and E.

Online portal P makes use of all these relatively fine-grained calls to
supply, via aggregation, a more extensive and interesting service: book
recommendations, with prices and reliability indications.

Note, please, that the coarser (and more useful) service is predicated
on the existence of the less-useful, finer-grained services.  Portal P
might reasonably try to set up the sorts of services supplied by
recreation area R, but it is unreasonable to expect it to be able to
obtain inventory information from six or more bookstores on its own. 
The more interesting services begin to grow out of primitive services.

(This example selected because there are interesting book finding
services already around, which don't have quite as easy a life as
simple aggregation of existing small services)

Note also that the larger service potentially feeds utility into the
smaller services--it may be that few people ever think of using
bookstore E's service (poor advertising/mindshare), but as part of the
larger recommendation service, it has better visibility (i.e., pays for
itself).

So: 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.

Amy!
-- 
Amelia A. Lewis          alicorn@m...          amyzing@t...
The less I seek my source for some definitive, the closer I am to fine.
		-- Indigo Girls

• Follow-Ups:
  • Re: Web Services Best Practice, summary 2
    • From: Mike Champion <mc@x...>

• References:
  • Web Services Best Practice, summary 2
    • From: "Roger L. Costello" <costello@m...>

• Prev by Date: RE: Another strong/loose decision tree node (was Re: InterestingXML-DIST-APP thread)
• Next by Date: Re: Web Services Best Practice, summary 2
• Previous by thread: Web Services Best Practice, summary 2
• Next by thread: Re: Web Services Best Practice, summary 2
• Index(es):
  • Date
  • Thread