locked
Developing Windows Apps which use webservices RRS feed

  • Question

  • Hi Everyone,

    I am most used to developing asp.net 2.0 solutions which access an sql db for information on stock levels, availability etc.

    I would like to move to windows forms apps but I require help with architecture.

    I would like to develop a windows forms application which works disconnected so i would have to install sql express 2005 on each of the clients machines on which the app is installed. I know that this would work fine for a standalone app.

    What if I wanted to allow the clients to check availability of resources across multiple location? I would like it for the app to run disconnected as it does but also to check availability across their other locations over the internet.

    Would I create a webservice on each of the client machines and so access availability through the use of the webservice? And if I did this, would each of the webservices require their own ssl?

    Is there a better way that someone would do this?

    One example may be a group of hotels and each hotel would like to check availability at all of their locations from their windows app and I don't want to get into data synchronisation or anything like that, just if there is an internet connection, other locations can be checked.

    Thanks in advance to anyone who replies,

    Danny
    Monday, February 4, 2008 11:32 AM

Answers

  • Danny,

     

    You certainly could use web services to achieve what you want to achieve.

     

    Whilst I'm not familiar with what your requirements are, and hence could give you guidance on how I'd do it, I was trying to point out cleaner alternatives, that I believe would be more maintainable, cost effective and easy to work with in the long run.  I also agree that synchronization techniques can be tricky too, and that would probably be a long way down my list of good ideas!

     

    The other question I would have is, how up to date should the data be?  If you need the offline capability, then it seems that it isn't that important.  That would probably lead me to the conclusion that pulling data from a central store would be acceptible?

     

    I'm not sure I buy into the whole idea of a central store going down, as the same could be said of the web site hosting the web service that you query.  If that goes down then you're just as stuck?

     

    I don't want to bang on about the centralised idea, I just wanted to point out your requirements in the cold light of day, maybe get you thinking of the impact of doing this in a particular way?  Implementing the web services part is relatively straight forward, but living with the consequences may or may not be.

     

    So long as you're careful with how you  implement the web services you should be able to minimize any pain.  What I refer to is the dependency from one web service to another.  Make sure that whatever data is returned via the web service does not in any way couple it to the other web service, as you will open up a whole world of hurt for yourself it you do so!

     

    I hope this helps you,

     

    Good luck,

     

    Martin Platt.

     

    Tuesday, February 12, 2008 1:14 AM

All replies

  • Danny,

     

    Do you mean that you have an application, that would use sql express as the local store, but also be capable of synchronising with data from the database, for stock levels and such like?

     

    If so, then you could use a web service.  However, if you're then talking about checking availability of a hotel, then that would need to be in real time, rather than using a local database (as that woudl be out of date)

     

    My advice there is that working disconnected is probably a bad architecture choice, since the data will not be up to date, as well as having the issues associated with synchronisation, merging data, concurrency, and so forth.

     

    Using Web services would still be good, but to use them to query the server for availability of rooms, or stock levels or whatever it is that you are wanting to do.  Both stock levels and room availability aren't something that is likely to work well in a disconnected scenario at all.

     

    Adding orders, sending requests, and that sort of thing would work in a disconnected manner, as they can be resolved at any point, however, the presence of the disconnected order would not necessarily mean that it can be fulfilled, therefore you would need some sort of process to confirm or reject the order to make the process work fully.

     

    I hope that this helps you,

     

    Martin Platt.

    Tuesday, February 5, 2008 2:50 AM
  • Hi Martin,

    I agree. What i meant was that if there was no internet at one location for any reason then it would still function but not be able to check availability of other locations, it would simply say that the function is not available.  I think I mentioned in the post that I do not want to use synchronisation, I simply want to be able to check other hotel's local data if the connection is available.

    Hopefully this is now clearer, I apolagise if my first wasn't. With this agreed can you offer any further advice?

    Thanks
    Tuesday, February 5, 2008 9:11 AM
  • Danny,

     

    You have two choices, push, or pull the data.  Push is notifications, like subscription services that monitor some aspect of the system, and send the data back to the client.  That situation would not likely work, if you are offline, you miss the notification.

     

    The other alternative is something similar to what you were suggesting, calling a web service to return you all the latest changes from the system.  This would obviously require that your system have some way to identify where you are up to with pulling down the latest data.  For example, if the changes on the server could be arranged into batches, with an Id.  The web service could then be passed a number representing the last batch to be processed, so that the code behind the web service could then retrieve any data for batches greater than the batch Id supplied.

     

    How you arrange the transactions at the server into batches would be down to the frequency of the changes, and could be based on date or time grouping, or reaching a maximum number of transactions in the batch, or grouped by a particular hotel, or stock bin, or whatever fits your scenario.

     

    You could indeed use date and time stamps, if you can guarantee that the items are received in that order, and use a high water mark, remembering that you would have to set the new high water mark of the last item at the end of the operation. 

     

    Since you're not actually bothered about waiting for results, you could do this asynchronously, so that updates are done in the background.  In that instance you would have to be careful in ensuring that the receive order of the data is the same as the send order of the data, otherwise scenarios using a high water mark won't work, and instead you would have to try something by asking for a set of all data that has changed, and then comparing it to your local data, and seeing which data you need, then requesting it directly from a further web service.

     

    I hope that this helps you, and gives you some ideas of where to start, and how to approach the problem,

     

    Good luck,

     

    Martin Platt.

     

    Wednesday, February 6, 2008 3:35 AM
  • Thanks for taking the time to reply Martin but this isn't the way i want to go with it at all. From one site I want to access another sites data through a webservice and simply receive a dataset back which I can act on. I was just wondering if I install a webservice at every location for me to access their local data.

     

    Thanks

    Thursday, February 7, 2008 12:46 PM
  • Yes the first step would be for every location to have a webservice to be able to pull the data (one of Martins suggestions) but I would also suggest that you hade a central repository which the client talked to, that repository could then ask each location for it's data.

    Thursday, February 7, 2008 3:26 PM
  • This is one of those sorts of discussions that is getting a little "smelly"!

     

    The reason for that seems to be that data needs to be shared from one point to another, and the wrong questions are perhaps being asked of us.

     

    What it sounds like, is that you need to be able to share data, which would generally imply, as pointed out, a centralised store.  The the web apps could write to the central store, and read data from the central store?  That would be a lot neater. 

    Of course it might be that you have already existing sites, and want to communicate between them, but don't have much in the way of control between the two?  Obviously you have some if you have the ability to call web services, so I would say that the approach that is coming to the fore is the wrong choice since it feels to me like a workaround to a proper design?

     

    Sharing data between sites, is application integration, and there is a lot of literature and recommendations out there on how to handle such a situation.

     

    I don't know if that situation seems reasonable to you, or whether there is a good reason that you're asking specifically how to do things in this way?

     

    Hope this helps,

     

    Martin Platt.

     

    Friday, February 8, 2008 12:38 AM
  • Thanks for the continued replies Martin.

    The reason i didn't want a central store is so that if the internet connection drops at a site, that site can still remain functional. A way around this using a central store would be to synchronise data but I really don't want to get into synchronising data and handling conflicts etc.

    But I believe now that if I really wanted to go this route then I would need a web service for each location and i could add references to each service at every location so that the locations to be searched could be filtered?

    Thanks
    Monday, February 11, 2008 4:51 PM
  • Danny,

     

    You certainly could use web services to achieve what you want to achieve.

     

    Whilst I'm not familiar with what your requirements are, and hence could give you guidance on how I'd do it, I was trying to point out cleaner alternatives, that I believe would be more maintainable, cost effective and easy to work with in the long run.  I also agree that synchronization techniques can be tricky too, and that would probably be a long way down my list of good ideas!

     

    The other question I would have is, how up to date should the data be?  If you need the offline capability, then it seems that it isn't that important.  That would probably lead me to the conclusion that pulling data from a central store would be acceptible?

     

    I'm not sure I buy into the whole idea of a central store going down, as the same could be said of the web site hosting the web service that you query.  If that goes down then you're just as stuck?

     

    I don't want to bang on about the centralised idea, I just wanted to point out your requirements in the cold light of day, maybe get you thinking of the impact of doing this in a particular way?  Implementing the web services part is relatively straight forward, but living with the consequences may or may not be.

     

    So long as you're careful with how you  implement the web services you should be able to minimize any pain.  What I refer to is the dependency from one web service to another.  Make sure that whatever data is returned via the web service does not in any way couple it to the other web service, as you will open up a whole world of hurt for yourself it you do so!

     

    I hope this helps you,

     

    Good luck,

     

    Martin Platt.

     

    Tuesday, February 12, 2008 1:14 AM
  • Since this is an architecture forum, I will not go into implementation.

     

    However I would suggest following a SOA approach - the definition of which is beyond the scope of this forum.

     

    Tuesday, February 12, 2008 4:09 AM