Say two clients machines recall a ticket. If one client makes a change, what is the best way to keep the second client in sync? Obviously I don't want the second client to overwrite the first one's changes, but additionally I want the second client to be updated because it may do an operation based on that ticket that needs to include the update the other machine made.
Some approaches I've considered:
MSMQ - our application actually used to use this but by the time I was hired it was just dead code that was no longer being used. I've thought about reinstating it but I don't feel that MSMQ quite offers the functionality I want in regard to not just notifying other clients of a change, but also distributing that change.
SQL Service Broker - it's been a while since I looked at this but I definitely remember it was not the route I wanted to go.
Web Service - Instead of having applications each access the database themselves, I think having a webservice to be in the middle to be responsible for forming the business objects and handing them out would be a partial fix, except for the fact that our application is purely windows forms. But surely there is another way to implement this without the need for an actual web server?
Sockets - I've thought about just creating a windows service that integrates with our business object and uses windows sockets to either a) Just tell other clients they need to call the database for updates or b) Actually give the clients the updates so they don't need to call the database.
This is new territory for me and I'm not aware of any good books or articles that address design patterns that deal with this issue so please direct me to any if you know of them.
With regards to your web-service option, be aware that WCF does not require a web-server. All it needs is a Host, and you can implement one yourself trivially. That host would probably be a Windows Service for your needs.
I m not sure but you can make use of
Observer
- Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
and implement it
Related
Good afternoon,
I'm trying to find a way to synchronize an ObservableCollection between applications. Basically, one would be the server that has a collection of strings, and the other would be the client which would have that same list and display it in a GUI. When a string is modified on the server, I want the modification to be reflected on the client.
I'm not very familiar with server-client architectures or frameworks and would like to know where to start. So far I have looked at the WCF architecture and it looks like it might be a bit overkill for what I'm trying to accomplish, but I could be wrong.
Any guidance will be greatly appreciated.
WCF is the standard way of performing inter-process and inter-machine communications for .NET applications and it works very well. You need your client application to connect to the server and get the current state of the collection. Then each time the collection changes the client needs to be notified so it can apply the same change locally. There are many resource on the Web and at MSDN describing how to create a WCF connection.
i have an requirements where i need to have two instances of the custom window service code running at the same time but only one should be doing the work until the other one fails or die.
i'm trying to come up with the clean and simple design to do this.
one way:
create a temp table
and have this two service talk to each other via the table
and if the running one goes down, using probably last modified date
time on the table
then the other one will start
but this is very manual. i'm using c# 4.0.
are there better ways to achieve this?
i saw there's something like EventWaitHandle but not sure if it would be simple to use it.
thanks
~m
Implement a kind of lock/mutex using a common database (as you mentioned)
If the instances on the different servers know of each other (config?), they can chat with each other and decide who's boss.
If the instances do not know of each other try using an UDP broadcast to announce themselves to each other and then decide who's boss.
If you are able to do #1 and do it generic exposing it through a web service that solution would be reusable for other applications as well. I use such a solution myself.
Consider exposing a ping api endpoint (simple Rest API ping method) on both services so that each can monitor the other service state.
Good afternoon,
I am looking to have a web service that deals other web services (and databases) to collect data that is then stored within its own database. This is all quite straight-forward as I can regularly poll these to gather changes.
now communicating with the clients is the problem here. The web service can be created in any language (although C# or Java are the main candidates). But they will need to push data to clients written in Silverlight and Android (and others to be decided).
Polling is of course possible but on mobile devices we don't want constant polling, and besides in as real time as possible comms is important here
If this was totally in C# then I would imagine I could use duplex channels but I need something that is more general in order to push. So the question is what is available to do this? Also it needs to be free in an ideal world.
Seems a simple thing, a way to push from a web service toa client but I suspect it is far from simple (but maybe I can be proved wrong, I hope!)
It seems that there is no platform independent way to do what I want and so the way forward has been decided as the following for now:
Silverlight clients will use a polling mechanism to get the data and Android clients will use XMPP to get the messages.
This does have disadvantages in the polling aspect however there are no readily available free libraries to do it that work with Silverlight but in the future we will move to using XMPP throughout when we have the cash
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I'm trying to bootstrap a micro ISV on my nights and weekends. I have an application at a very early stage of development. It is written in C# and consists mainly of a collection of classes representing the problem domain. At this point there's no UI or data persistence. (I haven't even settled on the .NET platform. Its early enough that I could change to Java or native executables)
My goal for this application is that it will be a hybrid single user/ occasionally connected multiuser application. The single user part will use an embedded database for local storage. This is a development model I'm familiar with.
The multiuser part is where I have no prior experience. I know each user will need two things:
IP based communication to a remote server on the public internet
User authentication and remote data storage
I have an idea of what services I want this server to provide (information lookup and user to user transactions) but beyond that I'm out of my element. The server will need to be hosted by a third party since I don't have resources to run my own server. Keeping in mind that I will be the sole developer for this project for the foreseeable future:
Which technologies would be the simplest way to implement the two things mentioned above? Direct access to the datastore/database or is it better to isolate it? Should I implement a webservice? If so, SOAP or REST?
What other things do I need to consider when moving to a multiuser application?
I know security is a greater concern in a multiuser application. Especially when your dealing with any kind of banking information(which I will). Performance can be an issue when dealing with a remote connection and large numbers of users. Anything else I'm overlooking?
Regarding moving to a multiuser application, centralising your data is the first step of course, and the simplest way to achieve it is often to use a cloud-based database, such as Amazon SimpleDB or MS Azure. You typically get an access key and a long 'secret' for authentication.
If your data isn't highly relational, you might want to consider Amazon SimpleDB. There are SDKs for most languages, which allow simple code to store/retrieve data in your SimpleDB database using a key and secret, anywhere in the world. You pay for the service based on your data storage and volume of traffic, so it has a very low barrier of entry, especially during development. It will also scale from a tiny home application up to something of the size of amazon.com.
If you do choose to implement your own database server, you should remember two key things:
Ensure no session state exists, i.e. the client makes a call to your web service, some action occurs, and the server forgets about that client (apart from any changed data in the database of course). Similarly the client should not be holding any data locally that could change as a result of interaction from another user. Cache locally only data you know won't change (or that you don't care if it changes).
For a web service, each call will typically be handled on its own thread, and so you need to ensure that access to the database from multiple threads is safe. If you use the standard .NET or Java ways of talking to a SQL database, this should be handled for you. However, if you implement your own data storage, it would be something you'd need to worry about.
Regarding the question of REST/SOAP etc., a key consideration should be what kinds of platforms/devices you want to use to connect to the database server. For example if you were implementing your server in .NET you might consider WCF for implementing your web services. However that might introduce difficulties if you later want to use non-.NET clients. SOAP is a mature technology for web services, but quite onerous to implement, and libraries to wrap up the handling of SOAP calls may not necessarily be available for a given client platform. REST is simple to implement (trivially easy if you use ASP.NET MVC on your server), accessible by any client that can handle HTTP POST/GET without the need for libraries, and easy to test, so REST would be my technology of choice.
If you are sticking with .net (my personal preference), I would expose data access calls via WCF. WCF configuration is really flexible and pretty easy to pick up and you'll want to hide your DB behind a service layer.
1.Direct access to db is the simplest, and the worst. Just think about how you'd auth the db access... I would just write a remote-able API with serializable parameters, and worry about which methods to connect later (web services, IIOP, whatever) - the communication details are all wrapped and hidden anyway.
2.none
I've been asked to research approaches to deal with an app we're supposed to be building. This app, hypothetically a Windows form written in C#, will issue commands directly to the server if it's connected, but if the app is offline, the state must be maintained as if it was connected and then sync up and issue data changes/commands to the server once it is connected.
I'm not sure where to start looking. This is something akin to Google Gears, but I don't think I have that option if we go a Winform route (which looks likely, given that there are other functions the application needs that a web app couldn't perform). Is the Microsoft Sync framework a viable option? Does Silverlight do anything like this? Any other options? I've Googled around a bit but would like the community input on what's best given the scenario.
The Microsoft Sync Framework definitely supports the scenario you describe, although I would say that it's fairly complicated to get it working.
One thing to understand about the Sync Framework is that it's really two quite distinct frameworks shipping in the same package:
Sync Framework
ADO.NET Sync services v. 2
The ADO.NET Sync services are by far the easiest to set up, but they are constrained to synchronizing two relational data stores (although you can set up a web service as a remote facade between the two).
The core Sync Framework has no such limitations, but is far more complex to implement. When I used it about six months ago, I found that the best source to learn from was the SDK, and particularly the File/Folder sync sample code.
As far as I could tell, there was little to no sharing of code and types between the two 'frameworks', so you will have to pick one or the other.
In either case, there are no constraints on how you host the sync code, so Windows Forms is just one option among many.
If I understand correctly, this doesn't sound like an actual data synchronization issue to me where you want to keep two databases in sync. it sounds more like you want a reliable mechanism for a client to call functions on a server in an environment where the connection is unstable, and if the connection is not present at the time, you want the function called as soon as the connection is back up.
If my understanding is right, this is one option. if not, this will probably not be helpful.
This is a very short answer to an in-depth problem, but we had a similar situation and this is how we handled it.
We have a client application that needs to monitor some data on a PC in a store. When certain events happen, this client application needs to update our server in the corporate offices, preferably Real-Time. However, the connection is not 100% reliable, so we needed a similar mechanism.
We solved this by trying to write to the server via a web service. If there is an error calling the web service, the command is serialized as an XML file in a folder named "waiting to upload".
We have a routine running in our client app on a timer set for every n minutes. When the timer elapses, it checks for XML files in this folder. If found, it attempts to call the web service using the information saved in the file, and so on until it is successful. Upon a successful call, the XML file is deleted.
It sounds hack-ish, but it was simple to code and has worked flawlessly for five years now. It's actually been our most trouble-free application all-around and we've implemented the pattern elsewhere successfully