Rob's analysis is the right direction which you should follow. Having worked with web-service infrastructures that process 10GB of data per day, I can tell from real experience about the advantages of it.
Asynchronous processing becomes fairly important when dealing with large amounts of information, especially where inventories are updated. Let's say this interface has support for image data about the books as well, which may include book covers, page data... (no you can't just use amazon's book cover database .. that's cheating ), it really becomes a bottleneck for both the server and the client. ------------------------ As far as the XML structure goes. If the client does their homework correctly , then they'll probably use XSLT or some programmatic generation of the changes. That way if the publisher want's to upgrade, they change the XSLT, and possibly the structure of the datasets. XML should be the layer, not the core of an application. Rahul Singh -----Original Message----- From: Moderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Rob MacFadyen Sent: Thursday, December 11, 2003 4:50 AM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Web Service Design Question I'm not doing any web services... so take this with a grain of salt... The AccountName parameter... is that required? Shouldn't you be using WS-Security (et al) for handling authentication/authorization? In regards Rahul's suggestions of having one method for add/modify/delete... I'm not a big fan of this at all. Each operation is important in and of itself and I tend to favor defining these explicitly. But... depending on your use case with your clients an XML list of "changes" may be exactly what's needed (per Rahul's suggestion). I'd change the name though: AdjustBooksDetails(..) maybe. As to asynchronous handling... though it provides a quick response to your client you may have to build in some sort of failure/success mechanism. When done synchronously the client will receive a list of failed updates... how will the client be able to find this information out if it's being done synchronously. I think the criteria for asynchronicity is the timeliness of response vs the amount of work. If you always have too much work to do to meet your response time criteria then asynchronous processing may well help (assuming your system has idle time and is not running full out all the time). But... doing asynchronous processing properly, i.e. handling failure use cases, requires you to design for it. You have to examine how what will happen if things go very very wrong... eg. databases being restored, machines crashing/failing over, etc. For an asynchronous call name I'd suggest "AcceptPendingChangesToBooks(..)" and return some sort of identifier that can be queried later via: GetPendingChangesToBookResultsById(PendingChangeId) or even possibly GetPendingChangesToBookResultsByDate(ChangesDatetime). You may also need a way for a client to indicate that a new set of changes replaces a failed set of changes... but that's getting pretty extreme... it all really depends on what your clients are doing (i.e. the use cases). Regards, Rob -- RMTrack a great bug tracking tool! Fully customizable, automated workflow, e-mail notification, import utility, and much much more. Setup a demo at www.rmtrack.com (version 1.2.2 now available!) > -----Original Message----- > From: Moderated discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED] Behalf Of Rahul Singh > (Anant Systems, Inc.) > Sent: 10 December 2003 20:26 > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] Web Service Design Question > > > Accountname could be replaced with string xmlCredentials, otherwise you > should consider some other security mechanism > > Your set of methods are very similar to how the MetawebLog API works ( > http://www.xmlrpc.com/metaWeblogApi ) > > The metaweblogapi however deals with a lot of individual edits,adds,gets. > Since your publishers will most probably be doing changes in bulk, your > three methods can be further abstracted to > > AddNewBooks( string xmlCredentials, string xmlBooks ) > > Where in your xmlBookList, you have another attribute or node expressing > "add", "delete", "insert" > > <BookListProcessRequest> > <Version>1.0</Version> > <Book id=23> > <!-- your usual mumbo jumbo that deals with books goes here > --> > <Action>Add</Action> > </Book> > <Book id=24> > <!-- your usual mumbo jumbo that deals with books goes here > --> > <Action>Delete</Action> > </Book> > <Book id=25> > <!-- your usual mumbo jumbo that deals with books goes here > --> > <Action>Update</Action> > </Book> > </BookListProcessRequest> > > > Your process function can then take care of this asynchronously by sending > the appropriate actions to the appropriate methods responsible. This also > puts another level of control which you didn't have. As systems get larger > in size and traffic of information increases, utilizing the power of > asynchronous sequential queues will greatly affect the performance of your > system. If you can take this "process" list and be able to carry out the > actions in the background, the publisher or client interface doesn't need to > be waiting around. The way that you usually send a response back in this > situation is also a booklist, but like this. > > <BookListProcessResponse> > <Version>1.0</Version> > <Book id=23> > <Reaction>1</Reaction> <!-- success --> > </Book> > <Book id=24> > <Reaction>1</Reaction> <!-- success --> > </Book> > <Book id=25> > <Reaction>0</Reaction> <!-- failure --> > <Error>This book doesn't exist, so you can't delete > it</Error> <!-- only if there is an error --> > </Book> > </BookListProcessResponse> > > > Rahul Singh > Anant Systems, Inc. > > > -----Original Message----- > From: Moderated discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED] On Behalf Of steak > Sent: Wednesday, December 10, 2003 5:01 PM > To: [EMAIL PROTECTED] > Subject: [ADVANCED-DOTNET] Web Service Design Question > > Hello all, > > Looking for any feedback on web service design for the following scenario: > > Problem: > An on-line book store Acme.com needs a web service that allows book > publishers to maintain their own list of products available. > > Examples: > - Addison-Wesley calls the web service to add 100 titles > - MSPress call the web service to update pricing for 10 titles and remove > 3 discontinued titles from their existing list of books with Acme. > > Possible Design of Web Service interface: > AddNewBooks( string accountName, string xmlBooks ) > UpdatePricing( string accountName, string xmlBooks ) > RemoveBooksFromAvailbility( string accountName, string xmlBooks ) > > Where xmlBooks is a XML document something like this (simplified): > <BookList> > <Version>1.0</Version> > <Book id=23> > <Title>Great New Book</Title> > <ISBN>xxx-xxxx-xxx<ISBN> > <PriceTier id=3> > <Price>30.00</Price> > <QuantityRequired>1</QuantityRequired> > </PriceTier> > <PriceTier id=5> > <Price>25.00</Price> > <QuantityRequired>10</QuantityRequired> > </PriceTier> > </Book> > <Book id='38'> > <Title>Not so good Book</Title> > <ISBN>xxx-xxxx-xxx<ISBN> > <PriceTier id=6> > <Price>42.00</Price> > <QuantityRequired>1</QuantityRequired> > </PriceTier> > </Book> > </BookList> > > Questions: > So the question is really does this sound like a reasonable interface for > this type of problem? > > Would you have other ideas or have you seen other best practices for > dealing with inventories of items like this? > > Do these decision points below sound good or bad? > (1) All data is passed as a string representing a XML document. This > is to make it possible to add future data extensions while not requiring > clients to constantly call new API revisions. The schema of the XML > document would define what is sent/received. > > (2) There is Id attribute on the Book and PriceTier elements. I was > hesitant to add this because I want keep the web service abstracted away > from datastore details, but it seems even if a service is datastore > independent it is still reasonable to have a unique key to differentiate > items. > > Any comments appreciated - > Regards, > steak > > =================================== > This list is hosted by DevelopMentorR http://www.develop.com > Some .NET courses you may be interested in: > > NEW! Guerrilla ASP.NET, 26 Jan 2004, in Los Angeles > http://www.develop.com/courses/gaspdotnetls > > View archives and manage your subscription(s) at http://discuss.develop.com > > =================================== > This list is hosted by DevelopMentor. http://www.develop.com > Some .NET courses you may be interested in: > > NEW! Guerrilla ASP.NET, 26 Jan 2004, in Los Angeles > http://www.develop.com/courses/gaspdotnetls > > View archives and manage your subscription(s) at http://discuss.develop.com > =================================== This list is hosted by DevelopMentor. http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 26 Jan 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentorŪ http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 26 Jan 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com
